How to say HEAD~"all the way back - 1"

Git "indexing" of commits has a way to "go back":

% git diff HEAD~3

Can I say "all the way back", or "all the way back - 1" somehow?

Bill

On Thu, Feb 22, 2007 at 08:17:17PM CET, Bill Lear wrote:

What would that mean? :)

Do you mean to the "root" of the history? The trouble is, there can be many of such roots (coming up from merges of previously disjunct histories); even the git project itself has several. Which one to choose?

Petr Baudis wrote:

Actually HEAD~n follows first parent, so it would be only one such root.

The git project has 4 or 5 roots for mainline + 3 separate disjoint branches with separate roots (html, man, todo).

On Friday, February 23, 2007 at 18:52:22 (+0100) Jakub Narebski writes:

Exactly what I was after.  Something like:

% git diff HEAD~-1

or

% git diff ^HEAD~0

whatever ...

Bill

Bill Lear <rael@zopyra.com> writes:

<amusement>

        $ git rev-parse HEAD~4096
        fatal: ambiguous argument 'HEAD~4096': unknown revision or path ...
        $ git rev-parse HEAD~2048
        231af8322...
        $ git rev-parse HEAD~3072
        723c31fea...
        $ git rev-parse HEAD~3584
        ....
        $ git rev-parse HEAD_3952
        e83c5163316f89bfbde7d9ab23ca2e25604af290

</amusement>

If you somehow need to know where the root is all the time, you could do the above once and say:

	$ git tag root-commit e83c5163316f89bfbde7d9ab23ca2e25604af290

Bill Lear <rael@zopyra.com> writes:

Sorry, there is no such shorthand, but you could obviously say:

	$ git rev-list --parents HEAD | grep -v ' '

A way to find the root commit seems to be one of the things people new to git want at least once, once they start futzing with the tool. But I suspect that is only because they need that information to see how the tool works (say "what different output would I get out of 'git show $commit' for root and other commits?"), and not because they need that information for any real life use.

Really, what useful purpose does it serve for you to find out the root commit, OTHER THAN being able to say "the development history of this project starts at this commit"?

On Thursday, February 22, 2007 at 12:12:45 (-0800) Junio C Hamano writes:

Just today, I got a bug report from one of our developers. The git update hook we had in place before the conversion to 1.5 had this:

chmod -R ug+w $GIT_DIR

to avoid problems when people used 'git ssh://...", due to different umasks (yeah, a hack).

So, moving to 1.5, I updated our script (and, had been updating it for quite some time, so many revisions, maybe 20 or so), and well, now when people use ssh, they leave behind directories others can't read (as git now allows push through "git://", we'll be weaning people off of ssh soon).

So, I wanted to say "give me the first version of this, so I can cut-n-paste the chmod command, since I can't remember if it was chmod, or chown, or some combination ...", and thus the desire to to:

% git log -p HEAD~"All the way back" update

or something similar.

Bill

Bill Lear <rael@zopyra.com> writes:

But in that use case "root" commit is not necessarily what you wanted to say, isn't it? It is more like "I want *earlier* history, not latest ones as the command usually gives, of this file".

$ git log --reverse -p HEAD -- update

would give you the changes that touch the path in the reverse order than usual (I think this was merged post 1.5.0).

But my point is, you may happen to know it was in your root commit, but that is a special case. You may happen to know other things to limit the output. The timeperiod you made that change (e.g. --until=2006-05-31), for example.

By the way, on the face of it:

$ git log --reverse -4 -p HEAD -- update

(or whatever number of commits you are interested in viewing) might be closer to what you want to express, but the --reverse option does not work like that, unfortunately for this particular use case, because the way the semantics of interaction between --reverse and --max-count is defined.

Given the above command line, the current implementation limits the traversal to four items and then reverses the output, instead of traversing normally as if --max-count limitation is not there, reversing the result and then limiting the output to four items, which would have made the sample command line above a bit more useful.

But I would recommend against changing it. Being able to view the latest four commits in reverse is much more useful in practice than being able to view the four commits at the beginning of time in reverse. Having both options is certainly a possibility but I doubt it is worth it.

On Thu, Feb 22, 2007 at 12:12:45PM -0800, Junio C Hamano wrote:

I occasionally want to reference commits not relative to "all the way back" but to "all the way back on this branch". So, e.g., what's the next-to-last commit before "topic" meets up with "origin"?

I can do something like

	git rev-list origin..topic | tail -2 | head -1

but in practice it's faster just to fire up gitk origin.. and cut-n-paste object id's.

--b.

Hi,

On Thu, 22 Feb 2007, J. Bruce Fields wrote:

Or something like

	git rev-list --reverse origin..topic | sed -n 2p

But that's even longer! (Although conceptually shorter...)

Ciao, Dscho