On Mon, Feb 15, 2010 at 10:33 PM, Pavan Kumar Sunkara <pavan.sss1991@xxxxxxxxx> 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@xxxxxxxxxxxxxxx > More majordomo info at http://vger.kernel.org/majordomo-info.html > -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html