Walking commits from the first

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

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

In most repositories, you can do this:

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

but...

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

Thanks for the command

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.

On Mon, Feb 15, 2010 at 10:33 PM, Pavan Kumar Sunkara <pavan.sss1991@gmail.com> wrote:

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.

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.

On Tue, Feb 16, 2010 at 1:05 AM, Jon Seymour <jon.seymour@gmail.com> wrote:

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.