Re: How to check out the repository at a particular point in time

[Michael Witten <mfwitten@gmail.com>]

On Tue, Aug 23, 2011 at 16:09, Matthieu Moy
<Matthieu.Moy@grenoble-inp.fr> wrote:
> 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.