From: Jon Forrest Date: Sun, 24 Jul 2016 19:57:50 GMT Subject: Re: [RFC] A Change to Commit IDs Too Ridiculous to Consider? Message-ID: 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