[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Referring to revisions in the git future.
From: |
Stefan Monnier |
Subject: |
Re: Referring to revisions in the git future. |
Date: |
Thu, 30 Oct 2014 09:19:10 -0400 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/25.0.50 (gnu/linux) |
> as useless as SHA1s would be. The overhead of pulling just to get the
> commit under discussion swamps any difference in convenience as far as
> I'm concerned. YMMV, of course, that's just me.
I largely agree, and for that reason I basically never use revnos in
discussions. I find dates to work much better: humans can relate to
them very well, and since you'll have to add your own contextual info
(which branch is under discussion) and then go through a tool if you
need/want to get more details, you might as well use dates.
FWIW, I find this same argument makes me prefer dates over revids.
> For example, in response to my earlier post, Stefan responded that
> SHA1s aren't that easy to recognize and you'll get too many false
> positives. My initial rebuttal was "Eh?!", but a more constructive
> response is, so we establish a convention of prefixing with "sha:" or
> "SHA:".
I'd rather go with "git:", but yes that's also the first obvious answer
that came to my mind.
> The issue of "which repo" (especially for ELPA) is real, too, but
> again context is likely to give you a very good first guess, and after
> that you can configure some kind of variable to improve
> Emacs's guessing.
I guess that could work, but it requires a bit more setup than I like.
Especially since Git doesn't support shared repositories very well, so
I'll probably have to live with multiple Git repositories (compared to
the single Bzr repository I use now shared between 4-6 lightweight
checkouts). This in turn means that the "auto-handle git revids" tool
would have to try all of those repositories.
And if I don't place the repositories for the various projects where
I care about revids at the same place on every host, then sharing
that config-setup work between those various hosts doesn't work as well.
> This ain't rocket science, and it's the kind of thing Emacsen are
> *very* good at.
Kind of. The thing is, in 99% of the cases, the main thing I want to
know from a "revision identifier" is the rough age of that revision
(this is useful info because if it's very recent, then I can probably
guess exactly which commit this is referring to). For that "date" is
the best description there is.
Stefan
- Re: DVCS design philosophy, (continued)
- Re: Referring to revisions in the git future, Eli Zaretskii, 2014/10/31
- Re: Referring to revisions in the git future., Stephen J. Turnbull, 2014/10/29
- Re: Referring to revisions in the git future., Barry Warsaw, 2014/10/30
- Re: Referring to revisions in the git future., Stephen J. Turnbull, 2014/10/30
- Re: Referring to revisions in the git future., David Kastrup, 2014/10/30
- Re: Referring to revisions in the git future., Alex Bennée, 2014/10/31
- Re: Referring to revisions in the git future.,
Stefan Monnier <=
- Re: Referring to revisions in the git future., Stephen J. Turnbull, 2014/10/31
- Re: Referring to revisions in the git future., David Kastrup, 2014/10/31
- Re: Referring to revisions in the git future., Stephen J. Turnbull, 2014/10/31
Re: Referring to revisions in the git future., Stefan Monnier, 2014/10/28
Re: Referring to revisions in the git future., David Kastrup, 2014/10/29