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

From: Jon Forrest <nobozo@gmail.com>
Date: Jul 24, 2016, 19:57 UTC
Message-ID: <c0af7511-a5d5-29bb-d279-66b6c3e0519c@gmail.com>
In-Reply-To: <20160724185132.GN25141@sdfg.com.ar>

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