feature request: git-log should accept sth like v2.6.26-rc8-227

feature request: git-log should accept sth like v2.6.26-rc8-227

[Toralf Förster]

[-- Attachment #1: Type: text/plain, Size: 455 bytes --]

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

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 197 bytes --]

Re: feature request: git-log should accept sth like v2.6.26-rc8-227

[Junio C Hamano]

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.

Re: feature request: git-log should accept sth like v2.6.26-rc8-227

[Jakub Narebski]

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

[Toralf Förster]

[-- Attachment #1: Type: text/plain, Size: 340 bytes --]

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

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 197 bytes --]

Re: feature request: git-log should accept sth like v2.6.26-rc8-227

[Junio C Hamano]

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.

Re: feature request: git-log should accept sth like v2.6.26-rc8-227

[Johannes Schindelin]

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

Re: feature request: git-log should accept sth like v2.6.26-rc8-227

[Junio C Hamano]

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.

Re: feature request: git-log should accept sth like v2.6.26-rc8-227

[Jakub Narebski]

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

Re: feature request: git-log should accept sth like v2.6.26-rc8-227

[Johannes Schindelin]

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

Re: feature request: git-log should accept sth like v2.6.26-rc8-227

[Linus Torvalds]

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

Re: feature request: git-log should accept sth like v2.6.26-rc8-227

[Johannes Schindelin]

[-- Attachment #1: Type: TEXT/PLAIN, Size: 309 bytes --]

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

[Toralf Förster]

[-- Attachment #1: Type: text/plain, Size: 842 bytes --]

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

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 197 bytes --]

Re: feature request: git-log should accept sth like v2.6.26-rc8-227

[Johannes Schindelin]

[-- Attachment #1: Type: TEXT/PLAIN, Size: 1356 bytes --]

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

[Toralf Förster]

[-- Attachment #1: Type: text/plain, Size: 850 bytes --]

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

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 197 bytes --]

Re: feature request: git-log should accept sth like v2.6.26-rc8-227

[Dmitry Potapov]

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

[Toralf Förster]

[-- Attachment #1: Type: text/plain, Size: 1338 bytes --]

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

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 197 bytes --]

Re: feature request: git-log should accept sth like v2.6.26-rc8-227

[Dmitry Potapov]

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

Re: feature request: git-log should accept sth like v2.6.26-rc8-227

[Johannes Schindelin]

[-- Attachment #1: Type: TEXT/PLAIN, Size: 706 bytes --]

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

Re: feature request: git-log should accept sth like v2.6.26-rc8-227

[Johannes Schindelin]

[-- Attachment #1: Type: TEXT/PLAIN, Size: 1833 bytes --]

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]