Re: How to check out the repository at a particular point in time
- From
Michael Witten <mfwitten@gmail.com>
- Date
- Aug 23, 2011, 16:23 UTC
- Message-ID
- <CAMOZ1BuMfUT4D_UasLXsjDrXRKDw4EF_U-CV8tsS9W7AP+f8ow@mail.gmail.com>
- In-Reply-To
- <vpqliuk85ze.fsf@bauges.imag.fr>
On Tue, Aug 23, 2011 at 16:09, Matthieu Moy <Matthieu.Moy@grenoble-inp.fr> wrote:
Show 37 quoted lines
> Jonathan Nieder <jrnieder@gmail.com> writes: > >> Michael Witten wrote: >>> On Mon, Aug 22, 2011 at 15:18, R. Diez <rdiezmail-temp2@yahoo.de> 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.