Re: vcs_info patch-format/applied-string awareness?

[Manuel Jacob <me@manueljacob.de>]

On 2020-06-20 11:54, Daniel Shahaf wrote:
> Manuel Jacob wrote on Fri, 19 Jun 2020 22:48 +00:00:
>> On 2020-06-19 12:46, Daniel Shahaf wrote:
>> > Daniel Shahaf wrote on Fri, 19 Jun 2020 10:07 +0000:
>> >> Manuel Jacob wrote on Fri, 19 Jun 2020 04:06 +0200:
>> >> > I’m concerned that most people won’t use the feature because they’re
>> >> > not aware that it exists.
>> >>
>> >> Fair point.  Let's first see if we can enable the feature without user
>> >> interaction at all.  If that doesn't pan out, then we can see about
>> >> addressing the lack of awareness.
>> >
>> > By the way, I think this point applies to the "show patch series"
>> > functionality too.  That functionality is used by several vcs backends
>> > (e.g., quilt, hg mq, git rebase), but is not enabled by default and
>> > I suspect many people don't know it exists.
>> >
>> > I'm referring to this:
>> >
>> > [[[
>> > $ cd Functions/VCS_Info/
>> > $ rm -rf vcs-test/
>> > $ zsh ./test-repo-git-rebase-apply
>> > ⋮
>> > CONFLICT (content): Merge conflict in iota
>> > ⋮
>> > zsh: exit 1     zsh ./test-repo-git-rebase-apply
>> > $ (cd vcs-test/ && zsh)
>> > myref/rebase/+ f973ee0a1fe5
>> > [5+2=7] ea03c123a587 r7: Append a line
>> > %
>> > ]]]
>> >
>> > See the "[5+2=7] ea03c123a587 r7: Append a line" line.  (That line was
>> > generated by setting zstyles to values such as those given in comments
>> > at the top of ./test-repo-git-rebase-apply, plus some fine-tuning by
>> > zshrc hooks.)
>> >
>> > So, should we have patch series information displayed by default?  The
>> > information about applied patches is parsed by default, but not shown
>> > by default because the %m expando isn't in the default
>> > formats/actionformats
>> > values.
>> >
>> > Or alternatively, should we increase awareness of it?
>> 
>> MQ is deprecated and discouraged and any support for it doesn’t need 
>> any
>> more awareness. Personally, I neither want to spend time thinking 
>> about
>> how to improve MQ support nor answer any questions from MQ users that
>> keep using it because zsh support improved. ;)
> 
> Fair enough as far as the hg backend is concerned.
> 
> However, my question was not specific to the hg backend; I was 
> expressly
> asking also about the git and quilt backends, and my question stands
> with respect to them.

I neither use MQ nor quilt, as modern Mercurial makes history editing 
very nice.

For rebase, I see how it could be useful, but not as much as showing the 
current revision or branch. If I hit a merge conflict, I will usually 
try to solve it as soon as possible, without context-switching. After a 
context-switch and reopening a terminal in some directory, the first 
thing I want to know is where I am.

When reordering a stack of changesets, I use histedit only if I have a 
clear idea beforehand of how I want it to look like or if I want to 
mass-edit some commit messages.

When doing something more complex, I have a GUI (TortoiseHg) open and do 
it stepwise. With modern Mercurial (with changeset evolution), you can 
rebase single changesets. The GUI will show which changeset "obsoleted" 
which changeset. The descendants of the obsoleted changesets will be 
shown as "orphan". Piece-by-piece the new stack grows while old stack 
with the orphans gets smaller. During that, I usually have a clear idea 
of where I am. When solving merge conflicts or editing some revision, 
I’ll usually do it quickly without context-switches, so I don’t really 
have to be reminded.

When doing it stepwise, showing the current position in the "patch 
series" is not as useful as it is with `git rebase -i` or `hg histedit`. 
For showing the whole branch, there’s the GUI or the `hg stack` command.

> Cheers,
> 
> Daniel
> 
>> > Cheers,
>> >
>> > Daniel
>> >
>> > P.S.  The hg backend doesn't seem to support equivalent
>> > functionality for the rebase/histedit commands; see the VCS_INFO_set-patch-format
>> > call. hg mq support is present but not enabled by default.