Re: [RFC] A Change to Commit IDs Too Ridiculous to Consider?

From: Philip Oakley <philipoakley@iee.org>
Date: Jul 26, 2016, 14:26 UTC
Message-ID: <EF592E1B359D4D8F87EC40A9465D3736@PhilipOakley>
In-Reply-To: <c0af7511-a5d5-29bb-d279-66b6c3e0519c@gmail.com>

From: "Jon Forrest" <nobozo@gmail.com>

Show 11 quoted lines

> On 7/24/2016 11:51 AM, Rodrigo Campos wrote:
>> And what is the problem with that, if you are doing it with instructional
>> purposes? Let's assume that this helps and not confuses later when the 
>> commits
>> *do* change. What is the problem you face?
>
> A lot of instructional material contains stuff like "Do [xxx] and you'll
> see [zzz]. If you don't then something went wrong so try to figure out
> what happened and do it again."
>
> Git, as it stands, for good reason doesn't allow this approach.

You may want to look at how the test suite handles the need for well defined commit sequences.

It's not something I've really studied, but I am aware of the test_tick to increment the time and similar helpers.

There is a big learning step that needs to be got over by many beginners who have no concept of a DVCS, nor of multiple master copies (which to most is an oxymoron!), nor why the sha is a good solution and serial numbers are a bad solution!.

Being able to do a few "Hello World" commits starting at unix t=0, and then progressing on to see how they differ when it's unix=now time, or they use their own user IDs could be a useful step for those that need it.

Show 25 quoted lines

>
> I don't think a Git beginner, when using a version of Git that somehow
> works the way I proposed, will be confused. The fact that performing the
> same steps results in the same commit IDs won't be something that
> they'll care about or even notice. The material can include a callout
> mentioning the difference between "real" Git and "learners" Git.
>
>> I mean, for some examples you can use HEAD, HEAD^, HEAD~4, etc. and that 
>> always
>> works, no matter the commit id.
>
> This will work in some cases, but should come later in a Git book.
> But, in many cases using relative commit IDs, rather than absolute,
> will be less clear (I believe).
>
>> In which cases do you want/need the commit ids to be equal?
>> Can you be more specific?
>
> Sure. Take a look at the 2nd or 3rd chapter of Pro Git Reedited, 2nd
> Edition (or just Pro Git 2nd Edition - it doesn't matter). You see
> lots of output showing 'git commit' commands and the commit IDs that
> result. I suspect you'd see the same in almost any book about Git.
>
> Jon
> --

Philip