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

[Jon Forrest <nobozo@gmail.com>]

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.

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