Walking commits from the first

Walking commits from the first

[Pavan Kumar Sunkara]

Hi,

 When you clone a big git repository and would like to read and
understand the source code, you need to checkout and read every commit
right from the first commit. As per my knowledge, there is no command
(even with flags) to checkout the first commit of the repository.

If there is some command, please put it in user's manual

Also if we somehow managed to do it by a series of commands, after we
finish reading it then we need to redo it all over again to checkout
the next commit.

So, what i would like to have is something like this:
1) git checkout --first
   Checksout the commit #1 of the git repository
2) git checkout --next
   Checksout the next commit

What I think:

I know that every git commit is a vertice in a DAG which has it's edge
pointed to it's parent. So, walking from the latest commits to old
commits is easy but the reverse is not.
I would like to know if there is any problem if we make the walking
bidirectional. What i mean is, when a new commit is created, create an
edge not only from it to it's parent but also from it's parent to it.
Also, have something for the first commit of the repo which can be
referred as INIT (similiar to HEAD)

-pavan

Re: Walking commits from the first

[Jeff King]

On Mon, Feb 15, 2010 at 10:09:02AM +0530, Pavan Kumar Sunkara wrote:

>  When you clone a big git repository and would like to read and
> understand the source code, you need to checkout and read every commit
> right from the first commit. As per my knowledge, there is no command
> (even with flags) to checkout the first commit of the repository.
> 
> If there is some command, please put it in user's manual

In most repositories, you can do this:

  git checkout `git rev-list --reverse HEAD | head -n 1`

but...

> I know that every git commit is a vertice in a DAG which has it's edge
> pointed to it's parent. So, walking from the latest commits to old
> commits is easy but the reverse is not.
> I would like to know if there is any problem if we make the walking
> bidirectional. What i mean is, when a new commit is created, create an
> edge not only from it to it's parent but also from it's parent to it.
> Also, have something for the first commit of the repo which can be
> referred as INIT (similiar to HEAD)

It is not as simple as that, for two reasons.

For walking backwards, you can take multiple paths from merge commits
(which have multiple parents). So there may actually be several "first
commits" if unrelated lines of development were merged together. For
example, in git.git:

  $ git log --format='%h %p' |
    grep ' $'
  16d6b8a
  cb07fc2
  161332a
  1db95b0
  2744b23
  e83c516

There are six root commits. You can see what they are by piping the
above into "tr -d ' ' | git log --no-walk --stdin".

For your "--next" suggestion, it is even worse. There may be an infinite
number of commits that point to a given commit as the parent. So there
is no such thing as "what came next from X". You can only ask
"leading up to some commit Y which is a descendant of X, what was the
commit that came after X". But while there are a finite number of
answers, there is not necessarily just one. If two branches diverged at
X and then remerged before Y, they are both equally "next".

-Peff

Re: Walking commits from the first

[Pavan Kumar Sunkara]

> In most repositories, you can do this:
>
>  git checkout `git rev-list --reverse HEAD | head -n 1`
>

Thanks for the command

> It is not as simple as that, for two reasons.
>
> For walking backwards, you can take multiple paths from merge commits
> (which have multiple parents). So there may actually be several "first
> commits" if unrelated lines of development were merged together. For
> example, in git.git:
>
>  $ git log --format='%h %p' |
>    grep ' $'
>  16d6b8a
>  cb07fc2
>  161332a
>  1db95b0
>  2744b23
>  e83c516
>
> There are six root commits. You can see what they are by piping the
> above into "tr -d ' ' | git log --no-walk --stdin".
>
> For your "--next" suggestion, it is even worse. There may be an infinite
> number of commits that point to a given commit as the parent. So there
> is no such thing as "what came next from X". You can only ask
> "leading up to some commit Y which is a descendant of X, what was the
> commit that came after X". But while there are a finite number of
> answers, there is not necessarily just one. If two branches diverged at
> X and then remerged before Y, they are both equally "next".
>
> -Peff
>

My bad. I never thought of branch merging while writing this
So, if i want to get the second commit, Is this enough or will i get
the problem of branch diverging, if there is a branch diverging from
there.

git checkout `git rev-list --reverse HEAD | head -n 2`

Even though we have the problem branches to travel reversely, we can
do it in another way. As, we have the timestamp for every commit, then
it will be easy to implement --next. Take the next commit in timeline
and checkout. Even though it's completely different branch, no problem
as long as we are going in order.

Also we can have git checkout --next --same-branch to checkout the
next commit in timeline of the same branch.

Re: Walking commits from the first

[Jon Seymour]

On Mon, Feb 15, 2010 at 10:33 PM, Pavan Kumar Sunkara
<pavan.sss1991@gmail.com> wrote:
>> In most repositories, you can do this:
>>
>>  git checkout `git rev-list --reverse HEAD | head -n 1`
>>
>
> Thanks for the command
>
>> It is not as simple as that, for two reasons.
>>
>> For walking backwards, you can take multiple paths from merge commits
>> (which have multiple parents). So there may actually be several "first
>> commits" if unrelated lines of development were merged together. For
>> example, in git.git:
>>
>>  $ git log --format='%h %p' |
>>    grep ' $'
>>  16d6b8a
>>  cb07fc2
>>  161332a
>>  1db95b0
>>  2744b23
>>  e83c516
>>
>> There are six root commits. You can see what they are by piping the
>> above into "tr -d ' ' | git log --no-walk --stdin".
>>
>> For your "--next" suggestion, it is even worse. There may be an infinite
>> number of commits that point to a given commit as the parent. So there
>> is no such thing as "what came next from X". You can only ask
>> "leading up to some commit Y which is a descendant of X, what was the
>> commit that came after X". But while there are a finite number of
>> answers, there is not necessarily just one. If two branches diverged at
>> X and then remerged before Y, they are both equally "next".
>>
>> -Peff
>>
>
> My bad. I never thought of branch merging while writing this
> So, if i want to get the second commit, Is this enough or will i get
> the problem of branch diverging, if there is a branch diverging from
> there.
>

It's not merging that's the problem - it's forking. Merges are easy to
comprehend - a merge has a finite number of input branches all of
which are immediately discoverable with an O(1) operation. A merge,
once performed, is immutable for all time.  The number of forks from a
given commit is fundamentally unbounded and requires comprehensive
knowledge of the entire history of the repository.

> git checkout `git rev-list --reverse HEAD | head -n 2`
>
> Even though we have the problem branches to travel reversely, we can
> do it in another way. As, we have the timestamp for every commit, then
> it will be easy to implement --next. Take the next commit in timeline
> and checkout. Even though it's completely different branch, no problem
> as long as we are going in order.
>
> Also we can have git checkout --next --same-branch to checkout the
> next commit in timeline of the same branch.

If your goal is to understand the source code, then reviewing commits
in time order from start to finish is unlikely to be
very helpful.

The reason is that two adjacent commits in this order will unlikely to
have any semantic relationship of any value unless they happen to be
on the same stream of development.

The history is useful for understanding how something came to be -
commits followed backwards down one merge branch will tend to have
some semantic relationship to each other unless your committers are on
acid. Trying to comprehend the evolution of history by replaying it
forwards and keeping track of n parallel threads of development as
they diverge seems like an unnecessarily complicated way of trying to
comprehend the world.

jon.

> --
> To unsubscribe from this list: send the line "unsubscribe git" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>

Re: Walking commits from the first

[Jon Seymour]

On Tue, Feb 16, 2010 at 1:05 AM, Jon Seymour <jon.seymour@gmail.com> wrote:
> On Mon, Feb 15, 2010 at 10:33 PM, Pavan Kumar Sunkara
>
> The history is useful for understanding how something came to be -
> commits followed backwards down one merge branch will tend to have
> some semantic relationship to each other unless your committers are on
> acid. Trying to comprehend the evolution of history by replaying it
> forwards and keeping track of n parallel threads of development as
> they diverge seems like an unnecessarily complicated way of trying to
> comprehend the world.
>

That said, of course, git once had an option to rev-list that I
contributed (--merge-order) that attempted to create the best possible
linear history by performing a topological sort that minimised the
number of "jumps" between semantically unrelated commits in the linear
order. The algorithm was kind of cool (based as it was on a
conservation of mass analogy), but it eventually got stripped out for
various eminently understandable reasons (like no-one was using it, I
wasn't maintaining it and it was the only remaining use of a
dependency on the open-ssl infinite precision integer arithmetic
libraries that complicated the build).

git rev-list --topo-order will do a topological sort that guarantees
that you never visit a commit before visiting all its ancestors.


> jon.
>
>> --
>> To unsubscribe from this list: send the line "unsubscribe git" in
>> the body of a message to majordomo@vger.kernel.org
>> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>>
>