Please try to keep to the 80-character lines. W dniu 2016-07-24 o 20:12, Jon Forrest pisze: > Those of us who write instructional material about Git all face the > same problem. This is that we can't write step by step instructions > that show the results of making a commit because users will always > see different commit IDs. This is fundamental to the design of Git. > > Even if the instructional material tells users to use standard author > and committer information, (e.g. john.doe@xxxxxxxxxxx) and shows the > text of the file being committed and the commit message to add, the > resulting commit ID will differ from reader to reader since the > commit will presumably take place at different times. There are two options: first, to tell the reader upfront that objects id would be different / would change. This has the advantage that you do not need to update those objects when you change instructions in the middle. Note that commit objects are not the only things that change; for example the result of `ls -l` would also be slightly different. Another possibility is to set authordate and committerdate to some specified time by the way of appropriate environment variables. > > What if it were possible, for instructional purposes only, to somehow > tell Git to relax this requirement. By this I mean, the commit date > would *not* be included when constructing the commit ID. This would > allow tutorials to show exactly what to expect to see when running > commands. What I think you don't realize is that "commit" objects are not treated in any way special. Object identifiers of all objects are SHA-1 hash of uncompressed loose representation of said object (type + length + contents). Well, you could not record dates in commit object, but I think Git considers such objects broken. > > I realize that questions would remain such as how to turn on this > behavior (e.g. command line flags, environment variables) and whether > 'git log' (and maybe other commands) should somehow distinguish > these mutant commits. There would probably be other issues to > consider. > > Again, this is for instructional purposes only, and only when the > committer explicitly chooses to use this option. I'm *not* proposing > a general change to Git's behavior. > > Is such a thing to ridiculous to even consider? Is there a better way > to achieve the same result IMVHO it would require heavy surgery of Git for little benefit (see the beginning of reply for alternate solutions). -- Jakub Narębski -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html