emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: feature/package+vc 04c4c578c7 3/4: Allow for packages to be installe


From: Stefan Monnier
Subject: Re: feature/package+vc 04c4c578c7 3/4: Allow for packages to be installed directly from VCS
Date: Sun, 30 Oct 2022 10:00:40 -0400
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/29.0.50 (gnu/linux)

> I guess so.  Here is a possible patch that should behave close enough to
> elpa-admin.el using "blame"

Why do you use `blame` rather than `log` like `elpa-admin.el`?

> (an obvious exception is the missing handler for the new :merge
> property, but I have been wondering if it might also be fair to always
> add "--first-parent" for Git).

We considered using `--first-parent` but it tends to point to more
recent merge commits than to the actual commit that bumped the
`Version:`.  If you add to that the fact that order of parents in Git is
somewhat arbitrary and rarely taken into consideration, I'd rather not
go there.

For `:merge` we didn't really have a choice, and (to make up for that)
we get to control how the merge is done and thus which one is the
first parent.

> The default handler just wraps vc-annotate, so it is a bit more fragile.

Hmm... the code I see in your patch uses `vc-region-history` (which is
only supported for Git and Hg, currently, and is fairly difficult to
support in a generic way) rather than `vc-annotate`.
Am I missing something?

> Invoking `package-vc-install' with a prefix argument will now check out
> the specific commit that bumps the version tag.  At least for git, the
> slight problem here is that this means the head is in a detached state,
> not connected to any specific branch.  I don't know if there is any
> elegant solution to this problem, or if it should even be "solved".

I suspect a better option is to use something like `git reset` instead
of `git checkout`, so we end up at the right revision but still on the
main branch.  But yes, it's kind of ugly if you want to try and preserve
local changes.  I think doing it right requires distinguishing whether
we're moving forward or backward (moving forward can be done with `git
merge`, which is well-behaved, whereas moving backward is poorly
supported, AFAICT).

You might want to take a look at `elpaa--select-revision` where I try to
solve this problem (for a slightly more restricted case, admittedly, but
it's already unsatisfactory).

Maybe there's a better way to do that?


        Stefan




reply via email to

[Prev in Thread] Current Thread [Next in Thread]