bug-gnu-emacs
[Top][All Lists]
Advanced

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

bug#38044: 27.0.50; There should be an easier way to look at a specific


From: Eli Zaretskii
Subject: bug#38044: 27.0.50; There should be an easier way to look at a specific vc commit
Date: Wed, 20 Nov 2019 18:34:55 +0200

> Cc: larsi@gnus.org, stephen.berman@gmx.net, 38044@debbugs.gnu.org,
>  juri@linkov.net
> From: Dmitry Gutov <dgutov@yandex.ru>
> Date: Wed, 20 Nov 2019 14:19:47 +0200
> 
> > I was talking about the VC level, not the vc-git level.  vc-git could
> > have a show command, but the user of VC would still invoke a variant
> > of vc-diff.
> 
> How would that even work? vc-diff will always delegate to vc-git-diff.

It will work if we program either vc-diff or vc-git-diff to call "git
show" under some specific circumstances.

> >> IMO the log message is more important because it describes and justifies
> >> what happened. Showing the diff is good as well.
> > 
> > That's not relevant to the issue at hand.  Like it or not, VCSes other
> > than Git describe a revision by the diffs alone.
> 
> It's 100% relevant, and the fact that certain older VCSes can't do this 
> should have no bearing on whether we implement a satisfactory UI in VC 
> or not. That's the whole purpose of VC: make interacting with different 
> VS systems easier.

Easier, yes.  But also present the results in a familiar enough form.
If users are accustomed to seeing a revision described by diffs, then
this is what they should by default see in VC, IMO.

> >> Maybe the other VCSes don't have a simple command to do the same, but
> >> they can either be called twice, or use special formatting. For
> >> instance, Hg can use this command:
> >>
> >> hg log -r <REV> -p
> > 
> > IMO, this is over-engineering.  If the VCS developers don't see the
> > need to have a commands which shows meta-data together with the diffs,
> > we should not force that on that VCS.
> 
> They added the '-p' flag. So apparently they did see the need.

Then maybe the hg back-end should indeed call "log -r -p", if that's
what hg users are used to (I don't use hg).  What I mean is that we
should show a revision like users are accustomed to see it with the
particular back-end; jumping through hoops to produce Git-like display
where users don't really expect it is IMO over-engineering.

And I'm also saying that conceptually a revision's description is a
kind of "diff" operation, so it should preferably be a sub-command of
"C-x v =".





reply via email to

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