Hi Junio, > It does create one; it just is the same one you already happen to have, > when you record the same state on top of the same history as the > same person at the same time. >
No, it does not create one: as you can see from the trace of the execution of my script, the sha of the commit is the same as that of the other, which means that in the .git/objects there is only one such commit object, and not two with the same sha. The meaning of the word "create" is to bring into being something that did not exist before. There is no "creation" if the object already exists. > > And how would it help what to insert a sleep for 1 second (or 1 year > for that matter)? As you said, it reads from the system clock, and > there are millions of systems in the world that have Git installed. > You may record the same state on top of the same history as the same > person on two different machines 5 minutes in wallclock time in > between doing so. These two machines may end up creating the same > commit because one of them had a clock skewed by 5 minutes. I understood that the command does not create a new commit if all its data, i.e. tree, committer, ... and date are the same, representing the date with 1 second precision. Sleeping for 1 second guarantees that there is no commit in the repo that has the same time as the time after the sleep, i.e. that the command creates a (new) commit. > > What problem are you really trying to solve? You mentioned > importing from the foreign SCM, I quoted a piece of the man page of git commit, that states that --allow-empty bypasses the safety check that prevents to make a new commit. That piece incidentally states that it is "primarily" used by foreign SCM interface scripts. But of course it can be used in any script that needs to build a commit on top of another. > > You also did not seem to have read what I wrote, or deliberately > ignored it (in which case I am wasting even more time writing this, > so I'll stop). I did not deliberately ignore what you wrote. I might have missed some point though. > This does not have anything to do with "--allow-empty"; removing > "the option" would not help anything, either. I am reporting a problem with --allow-empty, so why you say that this does not have anything to do with it? Removing the option removes a behavior that is not predictable. Often it is better to remove a feature that turns out to be inconsistent than to leave it in the software. Of course a much better avenue is to make it consistent. > Run the following on a fast-enough machine. > I did, and obtained most of the times "I was quick enough" and sometimes "I was not quick enough", which is the same kind of behavior of my script. The problem I am trying to solve is to push to a remote server the source files only, while keeping in the local repo both sources and binaries. To do it, I keep an orphan branch, say "sources". When I make a commit on the master branch, I make also a commit on the sources one after having un-staged (git rm --cached) the binaries. The script that does this must cope also with the particular case in which in the commit on the master branch there are no sources. Basically the script does: # this is the commit on the master branch git init echo "aaa" >f1 git add f1 git commit -m A # this is the piece of the script that builds the sources branch git checkout --orphan sources # git rm --cached ... remove binaries, if any" git commit -m A --allow-empty git rev-list --all --pretty=oneline When there are binaries in the commit A, they are removed, and the tree for the second git commit is then different, and the commit is actually created. When there are no binaries (as in the script above, in which the removal is commented out), the second git commit would not create any new commit, and I would not have an orphan branch. Thence the --allow-empty to force it to create a new commit. Unfortunately, it creates a new commit only if the system clock changes the seconds of the system time between the two git commits. If you insert a "sleep 1" before the second git commit, the commit is really created. I spent many hours to spot this time-dependent error .... -Angelo -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
