On Tue, Aug 23, 2011 at 16:09, Matthieu Moy <Matthieu.Moy@xxxxxxxxxxxxxxx> wrote: > Jonathan Nieder <jrnieder@xxxxxxxxx> writes: > >> Michael Witten wrote: >>> On Mon, Aug 22, 2011 at 15:18, R. Diez <rdiezmail-temp2@xxxxxxxx> wrote: >> >>>> I still don't quite understand how git works, but let me >>>> risk a naive statement here. If "a-b-c-M" were 'master', >>>> and "d-e-f" were 'new-feature', then on April 1st the >>>> current version on 'master' is 'b', because I merged the >>>> 'new-feature' branch at a later point in time. Does that >>>> make sense? >>> >>> O! for the love all that is Holy! >> >> Wait, what's wrong with what R. Diez said? It's exactly what >> --first-parent gives you. > > Not really. Suppose, on April 1st, I have > > A--B--C <-master > \ > D--E <-new-feature > > Then, I merge from upstream > > A--B-----C <-master > \ \ > D--E--F <-new-feature > > and then I push to master, or master fast-forward-pulls from me: > > A--B-----C > \ \ > D--E--F <-new-feature, master > > Then, what used to be in master on April 1st is C, but --first-parent > will give you E instead. Indeed. That example makes perfect sense when so-called `branches' master and new-feature are rightfully thought of as the `pointers' (or, `references') that they are. Moreover, Jonathan, can't you see that your more knowledgeable mind has automatically smoothed over the inaccuracies presented by R. Diez's description? In particular, a `branch' has nothing to do with walking a commit object's ancestry. -- 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