threads / discuss / 14396
Subject: feature request: git-log should accept sth like v2.6.26-rc8-227
Hello,
git-describe gives an informative string about the current status: tfoerste@n22 ~/devel/linux-2.6 $ git describe v2.6.26-rc9-56-g6329d30
I appended those strings to the names of my UML kernel executables. Unfortunately I didn't used the commit id and now I'm wondering whether git could accept v2.6.26-rc9-56 as well in future.
-- MfG/Sincerely Toralf Förster pgp finger print: 7B1A 07F4 EC82 0F90 D4C2 8936 872A E508 7DB6 9DA3
Junio C HamanoRe: feature request: git-log should accept sth like v2.6.26-rc8-227
Toralf Förster <toralf.foerster@gmx.de> writes:
> git-describe gives an informative string about the current status: > tfoerste@n22 ~/devel/linux-2.6 $ git describe > v2.6.26-rc9-56-g6329d30 > > I appended those strings to the names of my UML kernel executables. > Unfortunately I didn't used the commit id and now I'm wondering whether git > could accept v2.6.26-rc9-56 as well in future.
It does take v2.6.26-rc9-56-g6329d30.
It will never take v2.6.26-rc9-56. The world is not linear.
Jakub NarebskiRe: feature request: git-log should accept sth like v2.6.26-rc8-227
Junio C Hamano <gitster@pobox.com> writes:
> Toralf Förster <toralf.foerster@gmx.de> writes: > > > git-describe gives an informative string about the current status: > > tfoerste@n22 ~/devel/linux-2.6 $ git describe > > v2.6.26-rc9-56-g6329d30 > > > > I appended those strings to the names of my UML kernel executables. > > Unfortunately I didn't used the commit id and now I'm wondering whether git > > could accept v2.6.26-rc9-56 as well in future. > > It does take v2.6.26-rc9-56-g6329d30. > > It will never take v2.6.26-rc9-56. The world is not linear.
Nevertheless it _could_ be unique.
Besides, it would be nice to have some command (git-rev-parse perhaps?) which could take ambiguous commit-ish, and list all commit which matches it.
-- Jakub Narebski Poland ShadeHawk on #git
Re: feature request: git-log should accept sth like v2.6.26-rc8-227
At Thursday 10 July 2008 21:42:53 Jakub Narebski wrote :
> Besides, it would be nice to have some command (git-rev-parse perhaps?) > which could take ambiguous commit-ish, and list all commit which matches > it.
Oh yes :-)
-- MfG/Sincerely Toralf Förster pgp finger print: 7B1A 07F4 EC82 0F90 D4C2 8936 872A E508 7DB6 9DA3
Junio C HamanoRe: feature request: git-log should accept sth like v2.6.26-rc8-227
Jakub Narebski <jnareb@gmail.com> writes:
> Besides, it would be nice to have some command (git-rev-parse perhaps?) > which could take ambiguous commit-ish, and list all commit which matches > it.
Have fun writing it and send in a patch.
Johannes SchindelinRe: feature request: git-log should accept sth like v2.6.26-rc8-227
Hi,
On Thu, 10 Jul 2008, Junio C Hamano wrote:
> Jakub Narebski <jnareb@gmail.com> writes: > > > Besides, it would be nice to have some command (git-rev-parse > > perhaps?) which could take ambiguous commit-ish, and list all commit > > which matches it. > > Have fun writing it and send in a patch.
Note that this really could be a patch, but not for rev-parse. Patch revision.c instead to parse the argument into _all_ matching revisions.
The :/ notation I no longer like so much should give you a lot of inspiration.
Good luck, Dscho
Junio C HamanoRe: feature request: git-log should accept sth like v2.6.26-rc8-227
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> On Thu, 10 Jul 2008, Junio C Hamano wrote: > >> Jakub Narebski <jnareb@gmail.com> writes: >> >> > Besides, it would be nice to have some command (git-rev-parse >> > perhaps?) which could take ambiguous commit-ish, and list all commit >> > which matches it. >> >> Have fun writing it and send in a patch. > > Note that this really could be a patch, but not for rev-parse. Patch > revision.c instead to parse the argument into _all_ matching revisions.
As Linus pointed out, that is "all _locally_ matching revisions". It is of dubious value in a distributed environment.
Jakub NarebskiRe: feature request: git-log should accept sth like v2.6.26-rc8-227
Junio C Hamano wrote:
> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes: >> On Thu, 10 Jul 2008, Junio C Hamano wrote: >>> Jakub Narebski <jnareb@gmail.com> writes: >>> >>>> Besides, it would be nice to have some command (git-rev-parse >>>> perhaps?) which could take ambiguous commit-ish, and list all commit >>>> which matches it. >>> >>> Have fun writing it and send in a patch. >> >> Note that this really could be a patch, but not for rev-parse. Patch >> revision.c instead to parse the argument into _all_ matching revisions. > > As Linus pointed out, that is "all _locally_ matching revisions". It is > of dubious value in a distributed environment.
It can be useful for example in situation where shortened sha-1 of a commit (for example to 6 characters) stops being ambiguous...
-- Jakub Narebski Poland
Johannes SchindelinRe: feature request: git-log should accept sth like v2.6.26-rc8-227
Hi,
On Thu, 10 Jul 2008, Junio C Hamano wrote:
> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes: > > > On Thu, 10 Jul 2008, Junio C Hamano wrote: > > > >> Jakub Narebski <jnareb@gmail.com> writes: > >> > >> > Besides, it would be nice to have some command (git-rev-parse > >> > perhaps?) which could take ambiguous commit-ish, and list all commit > >> > which matches it. > >> > >> Have fun writing it and send in a patch. > > > > Note that this really could be a patch, but not for rev-parse. Patch > > revision.c instead to parse the argument into _all_ matching revisions. > > As Linus pointed out, that is "all _locally_ matching revisions". It is > of dubious value in a distributed environment.
Right. Judging from some of the conversations on IRC (and even on this list), it seems that the word "local" for the reflogs is lost on some, and there is no reason to expect otherwise for the currently proposed thing.
So strike my suggestions, Dscho
Linus TorvaldsRe: feature request: git-log should accept sth like v2.6.26-rc8-227
On Thu, 10 Jul 2008, Jakub Narebski wrote:
> > Nevertheless it _could_ be unique.
NO IT COULD NOT!
It doesn't matter if it's unique in _one_ repository. What matters is if it is globally unique!
Otherwise, people will start sending these version numbers out in emails, and now somethign that was unique in the senders repo is actually not unique at the receivers side (or _is_ unique, but points to something totally different).
So no. A revision number like "v2.6.26-rc8-227" is fundamentally and utterly broken. No way it should ever be accepted, even as a "helpful" thing, because it's not helpful at all. It would be a sure way to crap.
Linus
Johannes SchindelinRe: feature request: git-log should accept sth like v2.6.26-rc8-227
Hi,
On Thu, 10 Jul 2008, Toralf Förster wrote:
> I appended those strings to the names of my UML kernel executables. > Unfortunately I didn't used the commit id and now I'm wondering whether > git could accept v2.6.26-rc9-56 as well in future.
If that were unambiguous, yes. But it is not.
Ciao, Dscho
Re: feature request: git-log should accept sth like v2.6.26-rc8-227
At Thursday 10 July 2008 21:29:07 Johannes Schindelin wrote :
> Hi, > > On Thu, 10 Jul 2008, Toralf Förster wrote: > > > I appended those strings to the names of my UML kernel executables. > > Unfortunately I didn't used the commit id and now I'm wondering whether > > git could accept v2.6.26-rc9-56 as well in future. > > If that were unambiguous, yes. But it is not. > > Ciao, > Dscho >
Ok, following the thread I understand why this feature isn't wanted by all. But for the given example (where I only pulled from another git tree) this could work, isn't it : ?
tfoerste@n22 ~/devel/linux-2.6 $ git-log v2.6.26-rc9.. | perl -e '@c = grep { /^commit/ } <>; print map { $#c - $i++ . "\t" . $_ } @c'-- MfG/Sincerely Toralf Förster pgp finger print: 7B1A 07F4 EC82 0F90 D4C2 8936 872A E508 7DB6 9DA3
Johannes SchindelinRe: feature request: git-log should accept sth like v2.6.26-rc8-227
Hi,
On Fri, 11 Jul 2008, Toralf Förster wrote:
> At Thursday 10 July 2008 21:29:07 Johannes Schindelin wrote :
>
> > On Thu, 10 Jul 2008, Toralf Förster wrote:
> >
> > > I appended those strings to the names of my UML kernel executables.
> > > Unfortunately I didn't used the commit id and now I'm wondering
> > > whether git could accept v2.6.26-rc9-56 as well in future.
> >
> > If that were unambiguous, yes. But it is not.
>
> Ok, following the thread I understand why this feature isn't wanted by
> all. But for the given example (where I only pulled from another git
> tree) this could work, isn't it : ?
>
> tfoerste@n22 ~/devel/linux-2.6 $ git-log v2.6.26-rc9.. | perl -e '@c = grep { /^commit/ } <>; print map { $#c - $i++ . "\t" . $_ } @c'The question is not so much if it would work, but what people would do with this. They would probably include something in a mail to you like "v2.6.26-rc9-111 stopped working!", you would test "v2.6.26-rc9-111" and go back "but it still works!".
Because you are talking about two different things.
So, in what workflow would v2.6.26-rc9-111 actually be helpful? For yourself working in your own lil' branch? I do not think so. HEAD~23 is much more helpful in that case, since locally, you do not work so much relative to a given tag, but relative to your current HEAD.
Hth, Dscho
Re: feature request: git-log should accept sth like v2.6.26-rc8-227
At Friday 11 July 2008 16:36:07 Johannes Schindelin wrote :
> The question is not so much if it would work, but what people would do > with this. They would probably include something in a mail to you like > "v2.6.26-rc9-111 stopped working!", you would test "v2.6.26-rc9-111" and > go back "but it still works!". > > Because you are talking about two different things. > > So, in what workflow would v2.6.26-rc9-111 actually be helpful? For > yourself working in your own lil' branch? I do not think so. HEAD~23 is > much more helpful in that case, since locally, you do not work so much > relative to a given tag, but relative to your current HEAD. > > Hth, > Dscho
Ah yes, this clarified it for me.
-- MfG/Sincerely Toralf Förster pgp finger print: 7B1A 07F4 EC82 0F90 D4C2 8936 872A E508 7DB6 9DA3
Dmitry PotapovRe: feature request: git-log should accept sth like v2.6.26-rc8-227
On Fri, Jul 11, 2008 at 5:39 PM, Toralf Förster <toralf.foerster@gmx.de> wrote:
>
> Ok, following the thread I understand why this feature isn't wanted by all. But
> for the given example (where I only pulled from another git tree) this could
> work, isn't it : ?
>
> tfoerste@n22 ~/devel/linux-2.6 $ git-log v2.6.26-rc9.. | perl -e '@c = grep { /^commit/ } <>; print map { $#c - $i++ . "\t" . $_ } @c'No, it does not. Running your script, I have
... 56 commit 803a9067e19714ea7b7da760fe92f0d53bfa6994 ...
Now, let's see what git-describe thinks about it $ git describe 803a9067e19714ea7b7da760fe92f0d53bfa6994 v2.6.26-rc9-38-g803a906
Your script is obviously incorrect. It is written in the assumption that history is linear, but it is not. Even if you pull only from one repo, this repo still contains *many* branches. Along any branch, you may have the same number.
Dmitry
Re: feature request: git-log should accept sth like v2.6.26-rc8-227
At Friday 11 July 2008 16:44:23 Dmitry Potapov wrote :
> On Fri, Jul 11, 2008 at 5:39 PM, Toralf Förster <toralf.foerster@gmx.de> wrote:
> >
> > Ok, following the thread I understand why this feature isn't wanted by all. But
> > for the given example (where I only pulled from another git tree) this could
> > work, isn't it : ?
> >
> > tfoerste@n22 ~/devel/linux-2.6 $ git-log v2.6.26-rc9.. | perl -e '@c = grep { /^commit/ } <>; print map { $#c - $i++ . "\t" . $_ } @c'
>
> No, it does not. Running your script, I have
>
> ...
> 56 commit 803a9067e19714ea7b7da760fe92f0d53bfa6994
> ...
>
> Now, let's see what git-describe thinks about it
> $ git describe 803a9067e19714ea7b7da760fe92f0d53bfa6994
> v2.6.26-rc9-38-g803a906
>
> Your script is obviously incorrect. It is written in the assumption that
> history is linear, but it is not. Even if you pull only from one repo,
> this repo still contains *many* branches. Along any branch, you may have
> the same number.
>
> Dmitry
> Yes,
$> git-log v2.6.26-rc9.. --pretty=short | grep "^commit" | cut -f2 -d' ' | xargs -n 1 git describe | grep '\-56\-'
I used eventually to get the commit id for the (broken) UML kernel 2.6.26-rc9-56
-- MfG/Sincerely Toralf Förster pgp finger print: 7B1A 07F4 EC82 0F90 D4C2 8936 872A E508 7DB6 9DA3
Dmitry PotapovRe: feature request: git-log should accept sth like v2.6.26-rc8-227
On Fri, Jul 11, 2008 at 04:58:40PM +0200, Toralf Förster wrote:
> > $> git-log v2.6.26-rc9.. --pretty=short | grep "^commit" | cut -f2 -d' ' | xargs -n 1 git describe | grep '\-56\-'
The fastest way to do the same would be:
git rev-list v2.6.26-rc9.. | xargs git describe | grep '\-56\-'
Dmitry
Johannes SchindelinRe: feature request: git-log should accept sth like v2.6.26-rc8-227
Hi,
On Fri, 11 Jul 2008, Dmitry Potapov wrote:
> On Fri, Jul 11, 2008 at 04:58:40PM +0200, Toralf Förster wrote: > > > > $> git-log v2.6.26-rc9.. --pretty=short | grep "^commit" | cut -f2 -d' ' | xargs -n 1 git describe | grep '\-56\-' > > The fastest way to do the same would be: > > git rev-list v2.6.26-rc9.. | xargs git describe | grep '\-56\-'
You forgot the "--all" option to rev-list.
And I doubt it would be the "fastest" way, in terms of execution speed.
Also, it leaves out this case:
rc9 - A - B - C - D - F
\ /
----- E -----F would be "rc9-5", but also "rc9-2".
Oh, and this would leave out reflogs, too.
Can we please let this concept die now?
Hth, Dscho
Johannes SchindelinRe: feature request: git-log should accept sth like v2.6.26-rc8-227
Hi,
On Fri, 11 Jul 2008, Johannes Schindelin wrote:
> On Fri, 11 Jul 2008, Dmitry Potapov wrote: > > > On Fri, Jul 11, 2008 at 04:58:40PM +0200, Toralf Förster wrote: > > > > > > $> git-log v2.6.26-rc9.. --pretty=short | grep "^commit" | cut -f2 -d' ' | xargs -n 1 git describe | grep '\-56\-' > > > > The fastest way to do the same would be: > > > > git rev-list v2.6.26-rc9.. | xargs git describe | grep '\-56\-' > > You forgot the "--all" option to rev-list. > > And I doubt it would be the "fastest" way, in terms of execution speed. > > Also, it leaves out this case: > > rc9 - A - B - C - D - F > \ / > ----- E ----- > > F would be "rc9-5", but also "rc9-2". > > Oh, and this would leave out reflogs, too. > > Can we please let this concept die now?
Heh, just as an intellectual exercise, I could not resist trying to brush up my l33t py7h0n sk1llz (and I am sure somebody will teach me something useful again):
-- snipsnap -- #!/usr/bin/python
import os import sys
if len(sys.argv) != 2: print 'Usage:', sys.argv[0], '<pseudo-describe>'
# split argument dash = sys.argv[1].rindex('-') tag = sys.argv[1][0:dash] generation = int(sys.argv[1][dash + 1:])
# get sha1 of given tag's commit pipe = os.popen('git rev-parse ' + tag + '^{commit}') sha1 = pipe.readlines()[0].strip() pipe.close()
# 'number' will contain (positive) distance to given commit number = dict() number[sha1] = set() number[sha1].add(0)
pipe = os.popen('git rev-list ^' + sha1 + ' --all --parents') rev_list = pipe.readlines() pipe.close()
rev_list.reverse()
for line in rev_list:
list = line.strip().split(' ')
number[list[0]] = set()
for parent in list[1:]:
if parent in number:
for n in number[parent]:
number[list[0]].add(n + 1)
for n in number[list[0]]:
if n == generation:
print list[0]