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

2016-07-26 Thread Philip Oakley
From: "Jon Forrest" 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 materia

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

2016-07-25 Thread Junio C Hamano
Junio C Hamano writes: > Jon Forrest writes: > >> 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

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

2016-07-25 Thread Junio C Hamano
Jon Forrest writes: > 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 Gi

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

2016-07-24 Thread Jon Forrest
Another possibility is to set authordate and committerdate to some specified time by the way of appropriate environment variables. To follow up, Jakub's approach works great without requiring any changes to Git. For example, the following test script always produces the same commit ID:

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

2016-07-24 Thread Jakub Narębski
W dniu 2016-07-24 o 21:20, Jon Forrest pisze: > On 7/24/2016 11:46 AM, Jakub Narębski wrote: >> >> Another possibility is to set authordate and committerdate to some >> specified time by the way of appropriate environment variables. > > That sounds like a great idea. Assuming it > works the way I

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

2016-07-24 Thread Jon Forrest
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

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

2016-07-24 Thread Jon Forrest
On 7/24/2016 11:46 AM, Jakub Narębski wrote: Please try to keep to the 80-character lines. Sorry. Another possibility is to set authordate and committerdate to some specified time by the way of appropriate environment variables. That sounds like a great idea. Assuming it works the way I e

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

2016-07-24 Thread Rodrigo Campos
On Sun, Jul 24, 2016 at 11:12:12AM -0700, Jon Forrest wrote: > > 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 ID

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

2016-07-24 Thread Jakub Narębski
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 alw

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

2016-07-24 Thread Jon Forrest
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 instructiona