{"thread":{"id":"31710","subject":"erratic behavior commit --allow-empty","startedAt":"2012-10-02T07:51:56Z","lastAt":"2013-01-16T12:26:15Z","messageCount":53,"participants":["Angelo Borsotti","Johannes Sixt","Junio C Hamano","PJ Weisberg","Philip Oakley","Matthieu Moy","Andreas Schwab","Tomas Carnecky","Phil Hord","Lars Noschinski","Jan Engelhardt","Joachim Schmitz"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"200312","messageId":"CAB9Jk9BynCunFHRFhGKoyDA-qof1iu6w952sAgSs2_JWb8+U3A@mail.gmail.com","threadId":"31710","inReplyTo":null,"subject":"erratic behavior commit --allow-empty","fromName":"Angelo Borsotti","fromEmail":"angelo.borsotti@gmail.com","sentAt":"2012-10-02T07:51:56Z","receivedAt":"2012-10-02T07:51:56Z","isPatch":false,"sender":{"key":"angelo.borsotti@gmail.com","avatar":null},"body":"Hi\n\nI have noticed an erratic behavior of git commit --allow-empty: sometimes\nit creates a new commit, but sometimes not.\nI have executed two times the following script, emptycommit:\n\n#!/bin/bash\nset -x\nrm -rf local\nmkdir local\ncd local\ngit init\necho \"aaa\" >f1\ngit add f1\ngit commit -m A\ngit checkout --orphan feature\ngit commit -m A --allow-empty\ngit rev-list --all --pretty=oneline\n\nThis is the log of the first execution:\n\n$ emptycommit\n+ rm -rf local\n+ mkdir local\n+ cd local\n+ git init\nInitialized empty Git repository in d:/gtest/local/.git/\n+ echo aaa\n+ git add f1\nwarning: LF will be replaced by CRLF in f1.\nThe file will have its original line endings in your working directory.\n+ git commit -m A\n[master (root-commit) 07e7d37] A\nwarning: LF will be replaced by CRLF in f1.\nThe file will have its original line endings in your working directory.\n 1 file changed, 1 insertion(+)\n create mode 100644 f1\n+ git checkout --orphan feature\nSwitched to a new branch 'feature'\n+ git commit -m A --allow-empty\n[feature (root-commit) 2297c4e] A\nwarning: LF will be replaced by CRLF in f1.\nThe file will have its original line endings in your working directory.\n 1 file changed, 1 insertion(+)\n create mode 100644 f1\n+ git rev-list --all --pretty=oneline\n2297c4e34ec27f3cdeca8c0dcdcd61b4a079f411 A\n07e7d379c2339ed375ed4903f6196d627367b7bf A\n\n>>>>> note that git commit -m A --allow-empty creates a commit\n\nThis is the log of the second execution:\n\n$ emptycommit\n+ rm -rf local\n+ mkdir local\n+ cd local\n+ git init\nInitialized empty Git repository in d:/gtest/local/.git/\n+ echo aaa\n+ git add f1\nwarning: LF will be replaced by CRLF in f1.\nThe file will have its original line endings in your working directory.\n+ git commit -m A\n[master (root-commit) 1b86218] A\nwarning: LF will be replaced by CRLF in f1.\nThe file will have its original line endings in your working directory.\n 1 file changed, 1 insertion(+)\n create mode 100644 f1\n+ git checkout --orphan feature\nSwitched to a new branch 'feature'\n+ git commit -m A --allow-empty\n[feature (root-commit) 1b86218] A\nwarning: LF will be replaced by CRLF in f1.\nThe file will have its original line endings in your working directory.\n 1 file changed, 1 insertion(+)\n create mode 100644 f1\n+ git rev-list --all --pretty=oneline\n1b8621851f6ae2943347da655661e9d5dc978208 A\n\n>>>>> note that git commit -m A --allow-empty DOES NOT create a commit\n\nThe script has been run on Windows 7 with git version 1.7.11.msysgit.1\n\n-Angelo\n"},{"id":"200316","messageId":"506AA51E.9010209@viscovery.net","threadId":"31710","inReplyTo":"CAB9Jk9BynCunFHRFhGKoyDA-qof1iu6w952sAgSs2_JWb8+U3A@mail.gmail.com","subject":"Re: erratic behavior commit --allow-empty","fromName":"Johannes Sixt","fromEmail":"j.sixt@viscovery.net","sentAt":"2012-10-02T08:26:06Z","receivedAt":"2012-10-02T08:26:06Z","isPatch":false,"sender":{"key":"j6t@kdbg.org","avatar":"https://avatars.githubusercontent.com/u/14810926?v=4"},"body":"Am 10/2/2012 9:51, schrieb Angelo Borsotti:\n> This is the log of the second execution:\n> \n> $ emptycommit\n> + rm -rf local\n> + mkdir local\n> + cd local\n> + git init\n> Initialized empty Git repository in d:/gtest/local/.git/\n> + echo aaa\n> + git add f1\n> warning: LF will be replaced by CRLF in f1.\n> The file will have its original line endings in your working directory.\n> + git commit -m A\n> [master (root-commit) 1b86218] A\n> warning: LF will be replaced by CRLF in f1.\n> The file will have its original line endings in your working directory.\n> 1 file changed, 1 insertion(+)\n> create mode 100644 f1\n> + git checkout --orphan feature\n> Switched to a new branch 'feature'\n> + git commit -m A --allow-empty\n> [feature (root-commit) 1b86218] A\n> warning: LF will be replaced by CRLF in f1.\n> The file will have its original line endings in your working directory.\n> 1 file changed, 1 insertion(+)\n> create mode 100644 f1\n> + git rev-list --all --pretty=oneline\n> 1b8621851f6ae2943347da655661e9d5dc978208 A\n> \n>>>>>> note that git commit -m A --allow-empty DOES NOT create a commit\n\nNote that git commit -m A --allow-empty *DID* create a commit. Only, that\nit received the same name (SHA1) as the commit you created before it\nbecause it had the exact same contents (files, parents, author, committer,\nand timestamps). Obviously, your script was executed sufficiently fast\nthat the two commits happend in the same second.\n\n-- Hannes\n"},{"id":"200317","messageId":"CAB9Jk9B9MBkm1_N+Ejc+KqunHL7S8czXH1NGyu-71Z1XidjLSA@mail.gmail.com","threadId":"31710","inReplyTo":"506AA51E.9010209@viscovery.net","subject":"Re: erratic behavior commit --allow-empty","fromName":"Angelo Borsotti","fromEmail":"angelo.borsotti@gmail.com","sentAt":"2012-10-02T08:49:37Z","receivedAt":"2012-10-02T08:49:37Z","isPatch":false,"sender":{"key":"angelo.borsotti@gmail.com","avatar":null},"body":"Hi\n\nhaving such a time-dependent behavior is not nice. It means that the user must\nknow it, and wait patiently before issuing the command, or in a script\nadd a sleep\nbefore the command.\nThe choice is then between adding a warning in the man page (\"please\nwait at least\na second before executing the command\") or adding a sleep inside the command\nitself.\nObviously, the second alternative looks much more appealing.\n\nThank you\n-Angelo\n"},{"id":"200349","messageId":"7vzk449449.fsf@alter.siamese.dyndns.org","threadId":"31710","inReplyTo":"506AA51E.9010209@viscovery.net","subject":"Re: erratic behavior commit --allow-empty","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2012-10-02T17:27:02Z","receivedAt":"2012-10-02T17:27:02Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Johannes Sixt writes:\n\n> Note that git commit -m A --allow-empty *DID* create a commit. Only, that\n> it received the same name (SHA1) as the commit you created before it\n> because it had the exact same contents (files, parents, author, committer,\n> and timestamps). Obviously, your script was executed sufficiently fast\n> that the two commits happend in the same second.\n\nCorrect.\n\nAnd this does not have anything to do with --allow-empty. You can\n\"reset --soft HEAD^\" immediately after committing a change and redo\nit to get the same effect. If you commit the same state with the\nsame history with the same message as the same person at the same\ntime, you will reliably get the same commit object.\n\nAnd that is fundamental property called reproducibility. There is\nnothing to be alarmed by this exercise.\n"},{"id":"200361","messageId":"CAB9Jk9CSW0ObJtgsfSwjf+k438=V8i7dP0p+YUehqdh2Z0k6tA@mail.gmail.com","threadId":"31710","inReplyTo":"7vzk449449.fsf@alter.siamese.dyndns.org","subject":"Re: erratic behavior commit --allow-empty","fromName":"Angelo Borsotti","fromEmail":"angelo.borsotti@gmail.com","sentAt":"2012-10-02T19:34:56Z","receivedAt":"2012-10-02T19:34:56Z","isPatch":false,"sender":{"key":"angelo.borsotti@gmail.com","avatar":null},"body":"Hi Junio,\n\nif I put on my head the implementor's hat, I would agree with you: that command\nafter all behaves as implemented.\nHowever, if I put the user's hat I would reason differently. What I\nneed are predictable\ncommands, and that by all means is not. This because the time at which a command\nis executed is not predictable (more precisely, the statement in it\nthat reads the system\ncalendar). So, even if an implementor thinks that this behavior is\nreliable, a user\nthinks that it is not predictable. Actually, I called that command\nfrom within a script,\nand thus I could not count on it being executed within 1 second from\nthe last commit.\nRead also the paragraph in the man page that describes it:\n\n\"Usually recording a commit that has the exact same tree as its sole\nparent commit is a mistake, and the command prevents you from making\nsuch a commit. This option bypasses the safety, and is primarily for\nuse by foreign SCM interface scripts.\"\n\nI cannot find any clue in it that lets me know that is does not create\na commit if the time is\nwithin the same second as the other commit.\n\nMy suggestion is either to include a sleep in the command so as to\nguarantee that a commit\nis created, or to remove the option.\n\n-Angelo\n"},{"id":"200366","messageId":"7vhaqc7in6.fsf@alter.siamese.dyndns.org","threadId":"31710","inReplyTo":"CAB9Jk9CSW0ObJtgsfSwjf+k438=V8i7dP0p+YUehqdh2Z0k6tA@mail.gmail.com","subject":"Re: erratic behavior commit --allow-empty","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2012-10-02T19:56:13Z","receivedAt":"2012-10-02T19:56:13Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Angelo Borsotti writes:\n\n> \"Usually recording a commit that has the exact same tree as its sole\n> parent commit is a mistake, and the command prevents you from making\n> such a commit. This option bypasses the safety, and is primarily for\n> use by foreign SCM interface scripts.\"\n>\n> I cannot find any clue in it that lets me know that is does not\n> create a commit if the time is within the same second as the other\n> commit.\n\nIt does create one; it just is the same one you already happen to have,\nwhen you record the same state on top of the same history as the\nsame person at the same time.\n\n> My suggestion is either to include a sleep in the command so as to\n> guarantee that a commit is created, or to remove the option.\n\nAnd how would it help what to insert a sleep for 1 second (or 1 year\nfor that matter)? As you said, it reads from the system clock, and\nthere are millions of systems in the world that have Git installed.\nYou may record the same state on top of the same history as the same\nperson on two different machines 5 minutes in wallclock time in\nbetween doing so. These two machines may end up creating the same\ncommit because one of them had a clock skewed by 5 minutes.\n\nWhat problem are you really trying to solve? You mentioned\nimporting from the foreign SCM, but in that case, you would be\nbuilding commits on top of other commits, and some commits may\nnot have any change recorded in them, i.e. you could validly\nhave (as always, time flows from left to right)\n\n\t---o---o---o---o---A---B---C\n\nwhere differences between A and B is nothing, and differences\nbetween B and C is nothing. You may be a script that records these\ncommits in rapid succession.\n\nWhen you create B and C, you may be recording the same state as the\nsame person with the same timestamp. *BUT* you are not recording\nthese two commits on top of the same history. B is done on top of\nthe history leading to A, but C is done on top of the history\nleading to B. They will get different commit object name.\n\nSo what problem are you trying to solve?\n\nYou also did not seem to have read what I wrote, or deliberately\nignored it (in which case I am wasting even more time writing this,\nso I'll stop).\n\nThis does not have anything to do with \"--allow-empty\"; removing\n\"the option\" would not help anything, either. Run the following on\na fast-enough machine.\n\n git init\n >file\n git add file\n git commit -m initial\n echo foo >file\n git add file\n git commit -a -m second\n H1=$(git rev-parse HEAD)\n git reset --soft HEAD^\n git commit -a -m second\n H2=$(git rev-parse HEAD)\n if test \"$H1\" = \"$H2\"\n then\n\techo I was quick enough\n else\n\techo I was not quick enough\n fi\n"},{"id":"200371","messageId":"CAB9Jk9D-eJ8goYx7LWqGcWcLgRDS8+qLZVUsvvJ+QOtryP9-zg@mail.gmail.com","threadId":"31710","inReplyTo":"7vhaqc7in6.fsf@alter.siamese.dyndns.org","subject":"Re: erratic behavior commit --allow-empty","fromName":"Angelo Borsotti","fromEmail":"angelo.borsotti@gmail.com","sentAt":"2012-10-02T21:56:14Z","receivedAt":"2012-10-02T21:56:14Z","isPatch":false,"sender":{"key":"angelo.borsotti@gmail.com","avatar":null},"body":"Hi Junio,\n\n> It does create one; it just is the same one you already happen to have,\n> when you record the same state on top of the same history as the\n> same person at the same time.\n>\n\nNo, it does not create one: as you can see from the trace of the execution\nof my script, the sha of the commit is the same as that of the other,\nwhich means\nthat in the .git/objects there is only one such commit object, and not two with\nthe same sha. The meaning of the word \"create\" is to bring into being something\nthat did not exist before. There is no \"creation\" if the object already exists.\n\n>\n> And how would it help what to insert a sleep for 1 second (or 1 year\n> for that matter)? As you said, it reads from the system clock, and\n> there are millions of systems in the world that have Git installed.\n> You may record the same state on top of the same history as the same\n> person on two different machines 5 minutes in wallclock time in\n> between doing so. These two machines may end up creating the same\n> commit because one of them had a clock skewed by 5 minutes.\n\nI understood that the command does not create a new commit if all its data, i.e.\ntree, committer, ... and date are the same, representing the date with 1 second\nprecision. Sleeping for 1 second guarantees that there is no commit in the repo\nthat has the same time as the time after the sleep, i.e. that the\ncommand creates\na (new) commit.\n\n>\n> What problem are you really trying to solve? You mentioned\n> importing from the foreign SCM,\n\nI quoted a piece of the man page of git commit, that states that\n--allow-empty bypasses\nthe safety check that prevents to make a new commit. That piece\nincidentally states\nthat it is \"primarily\" used by foreign SCM interface scripts. But of\ncourse it can be used\nin any script that needs to build a commit on top of another.\n\n>\n> You also did not seem to have read what I wrote, or deliberately\n> ignored it (in which case I am wasting even more time writing this,\n> so I'll stop).\n\nI did not deliberately ignore what you wrote. I might have missed some\npoint though.\n\n> This does not have anything to do with \"--allow-empty\"; removing\n> \"the option\" would not help anything, either.\n\nI am reporting a problem with --allow-empty, so why you say that this\ndoes not have\nanything to do with it?\nRemoving the option removes a behavior that is not predictable.\nOften it is better to remove a feature that turns out to be\ninconsistent than to leave it\nin the software. Of course a much better avenue is to make it consistent.\n\n> Run the following on a fast-enough machine.\n>\n I did, and obtained most of the times \"I was quick enough\" and\nsometimes \"I was not quick enough\", which is the same kind of behavior\nof my script.\n\nThe problem I am trying to solve is to push to a remote server the\nsource files only,\nwhile keeping in the local repo both sources and binaries. To do it, I\nkeep an orphan\nbranch, say \"sources\". When I make a commit on the master branch, I make also a\ncommit on the sources one after having un-staged (git rm --cached) the binaries.\nThe script that does this must cope also with the particular case in\nwhich in the commit\non the master branch there are no sources. Basically the script does:\n\n# this is the commit on the master branch\ngit init\necho \"aaa\" >f1\ngit add f1\ngit commit -m A\n\n# this is the piece of the script that builds the sources branch\ngit checkout --orphan sources\n# git rm --cached ... remove binaries, if any\"\ngit commit -m A --allow-empty\ngit rev-list --all --pretty=oneline\n\nWhen there are binaries in the commit A, they are removed, and the\ntree for the second\ngit commit is then different, and the commit is actually created.\nWhen there are no binaries (as in the script above, in which the\nremoval is commented out),\nthe second git commit would not create any new commit, and I would not\nhave an orphan\nbranch. Thence the --allow-empty to force it to create a new commit.\nUnfortunately, it creates a new commit only if the system clock\nchanges the seconds of\nthe system time between the two git commits.\nIf you insert a \"sleep 1\" before the second git commit, the commit is\nreally created.\n\nI spent many hours to spot this time-dependent error ....\n\n-Angelo\n"},{"id":"200378","messageId":"CAJsNXTm9ADZv4SbabAR_WzGrZO8wDjvk+9Lsis0STHGo1EhqwQ@mail.gmail.com","threadId":"31710","inReplyTo":"CAB9Jk9D-eJ8goYx7LWqGcWcLgRDS8+qLZVUsvvJ+QOtryP9-zg@mail.gmail.com","subject":"Re: erratic behavior commit --allow-empty","fromName":"PJ Weisberg","fromEmail":"pj@irregularexpressions.net","sentAt":"2012-10-03T02:10:01Z","receivedAt":"2012-10-03T02:10:01Z","isPatch":false,"sender":{"key":"pj@irregularexpressions.net","avatar":"https://gravatar.com/avatar/aa2c1edcc61b536cc5c9f37fbce084e655446e2309f9818d43f13d47304a602b?d=mp&s=160"},"body":"On Tue, Oct 2, 2012 at 2:56 PM, Angelo Borsotti\n wrote:\n> Hi Junio,\n>\n>> It does create one; it just is the same one you already happen to have,\n>> when you record the same state on top of the same history as the\n>> same person at the same time.\n>>\n>\n> No, it does not create one: as you can see from the trace of the execution\n> of my script, the sha of the commit is the same as that of the other,\n> which means\n> that in the .git/objects there is only one such commit object, and not two with\n> the same sha. The meaning of the word \"create\" is to bring into being something\n> that did not exist before. There is no \"creation\" if the object already exists.\n\nIt's also impossible to create two identical files in Git. If you\ntry, you'll find that they both have the same SHA1, and thus are\nrepresented by the same object in .git/objects.\n\nYou have a script that creates two commits that are identical in every\nway. What practical difference does it make whether they're\nrepresented by one object or two?\n\n-PJ\n\nGehm's Corollary to Clark's Law: Any technology distinguishable from\nmagic is insufficiently advanced.\n"},{"id":"200379","messageId":"506BCF19.7020800@viscovery.net","threadId":"31710","inReplyTo":"CAB9Jk9D-eJ8goYx7LWqGcWcLgRDS8+qLZVUsvvJ+QOtryP9-zg@mail.gmail.com","subject":"Re: erratic behavior commit --allow-empty","fromName":"Johannes Sixt","fromEmail":"j.sixt@viscovery.net","sentAt":"2012-10-03T05:37:29Z","receivedAt":"2012-10-03T05:37:29Z","isPatch":false,"sender":{"key":"j6t@kdbg.org","avatar":"https://avatars.githubusercontent.com/u/14810926?v=4"},"body":"Am 10/2/2012 23:56, schrieb Angelo Borsotti:\n> The problem I am trying to solve is to push to a remote server the\n> source files only,\n> while keeping in the local repo both sources and binaries. To do it, I\n> keep an orphan\n> branch, [...] \n> \n> # this is the commit on the master branch\n> git init\n> echo \"aaa\" >f1\n> git add f1\n> git commit -m A\n> \n> # this is the piece of the script that builds the sources branch\n> git checkout --orphan sources\n> # git rm --cached ... remove binaries, if any\"\n> git commit -m A --allow-empty\n> git rev-list --all --pretty=oneline\n> \n> When there are binaries in the commit A, they are removed, and the\n> tree for the second\n> git commit is then different, and the commit is actually created.\n> When there are no binaries (as in the script above, in which the\n> removal is commented out),\n> the second git commit would not create any new commit, and I would not\n> have an orphan\n> branch. Thence the --allow-empty to force it to create a new commit.\n> Unfortunately, it creates a new commit only if the system clock\n> changes the seconds of\n> the system time between the two git commits.\n\nBut the existing-and-not-created-commit has exactly the content that you\nwanted. What's the point in insisting that it is different from any other\ncommit?\n\n-- Hannes\n"},{"id":"200380","messageId":"CAB9Jk9DH4Gx-8oJzb8H=ytohhZnMbA92pwj5P25AehmZ3PMmcg@mail.gmail.com","threadId":"31710","inReplyTo":"506BCF19.7020800@viscovery.net","subject":"Re: erratic behavior commit --allow-empty","fromName":"Angelo Borsotti","fromEmail":"angelo.borsotti@gmail.com","sentAt":"2012-10-03T06:22:14Z","receivedAt":"2012-10-03T06:22:14Z","isPatch":false,"sender":{"key":"angelo.borsotti@gmail.com","avatar":null},"body":"Hi PJ and Hannes,\n\ntry to run the last script that I posted, with and without a sleep 1\nbefore the last commit:\n\ngit init\necho \"aaa\" >f1\ngit add f1\ngit commit -m A\ngit checkout --orphan sources\ngit commit -m A --allow-empty\n\nand\n\ngit init\necho \"aaa\" >f1\ngit add f1\ngit commit -m A\ngit checkout --orphan sources\nsleep 1\ngit commit -m A --allow-empty\n\nIn the first one, no new commit is created, and the \"sources\" branch\nis not orphan (you can easily see it with the git gui).\nIn the second one, a new commit is created, and the \"sources\" branch\nis orphan, as expected.\n\n-Angelo\n"},{"id":"200381","messageId":"506BDADE.4010803@viscovery.net","threadId":"31710","inReplyTo":"CAB9Jk9DH4Gx-8oJzb8H=ytohhZnMbA92pwj5P25AehmZ3PMmcg@mail.gmail.com","subject":"Re: erratic behavior commit --allow-empty","fromName":"Johannes Sixt","fromEmail":"j.sixt@viscovery.net","sentAt":"2012-10-03T06:27:42Z","receivedAt":"2012-10-03T06:27:42Z","isPatch":false,"sender":{"key":"j6t@kdbg.org","avatar":"https://avatars.githubusercontent.com/u/14810926?v=4"},"body":"Not answering questions does not help anyone.\n\nMy question was: What is the point in insisting that there is a *really*\nnew commit when the one commit that already existed has exactly the\ncontent that you wanted?\n\n-- Hannes\n"},{"id":"200382","messageId":"506BE577.900@viscovery.net","threadId":"31710","inReplyTo":"CAB9Jk9AgtNQfWDr31CWbXf2ag=11du-aruu-0+nOZ3KaaG9=og@mail.gmail.com","subject":"Re: erratic behavior commit --allow-empty","fromName":"Johannes Sixt","fromEmail":"j.sixt@viscovery.net","sentAt":"2012-10-03T07:12:55Z","receivedAt":"2012-10-03T07:12:55Z","isPatch":false,"sender":{"key":"j6t@kdbg.org","avatar":"https://avatars.githubusercontent.com/u/14810926?v=4"},"body":"Cc restored; please reply to all.\n\nAm 10/3/2012 8:32, schrieb Angelo Borsotti:\n> Hi Hannes,\n> \n> well, I thought I replied to your question:\n> \n> \"What is the point in insisting that there is a *really*\n> new commit when the one commit that already existed has exactly the\n> content that you wanted?\"\n> \n> I wanted to create an orphan branch. I did it with a git checkout\n> --orphan sources.\n> This command alone does not create a branch; it needs a commit to be done on\n> it, but a \"real\" one. If it is not a \"real\" one, the branch is\n> created, but it is not an\n> orphan one.\n\nWhen you do 'git checkout --orphan sources', you request (nothing more and\nnothing less than) that the next commit you make on the new branch\n\"sources\" does not have a parent. But this is exactly what happens: The\nnext commit you make does not have a parent.\n\nPerhaps you are confused by the fact that the commit you made first does\nnot have a parent, either. But that is just a \"side effect\" that it\nhappened to be the very first commit that you made after 'git init'.\n\nIOW, the second commit that you made has all properties that you\nrequested. (It just so happens that it is exactly identical to the first\ncommit you made.) Your case does not demonstrate a bug in git.\n\nWhy don't you use a different commit message to ensure that there is a\ndifference between the commits?\n\n-- Hannes\n"},{"id":"200385","messageId":"90464C79DA97415C9D66846A77ECAA4A@PhilipOakley","threadId":"31710","inReplyTo":"CAB9Jk9D-eJ8goYx7LWqGcWcLgRDS8+qLZVUsvvJ+QOtryP9-zg@mail.gmail.com","subject":"Re: erratic behavior commit --allow-empty","fromName":"Philip Oakley","fromEmail":"philipoakley@iee.org","sentAt":"2012-10-03T07:29:37Z","receivedAt":"2012-10-03T07:29:37Z","isPatch":false,"sender":{"key":"philipoakley@iee.email","avatar":"https://avatars.githubusercontent.com/u/914343?v=4"},"body":"From: \"Angelo Borsotti\" \n> Hi Junio,\n>\n>> It does create one; it just is the same one you already happen to \n>> have,\n>> when you record the same state on top of the same history as the\n>> same person at the same time.\n>>\n>\n> No, it does not create one:\n\nAngelo\nThis is a semantics problem. It is like the confusion as to whether zero \nis a natural number that can be used in counting.\n\nIn this case we have created two commits. However they are, by design \nand definition, identical to each other for this case of identical \ncontent and identical administration fields. They cannot be \ndistinguished.\n\nSo when the file system is asked to 'write' the second commit, it (the \nfile system in conjunction with the git code) does a no-op, and reports \n'done'.\n\nIt is a common (systems) engineering problem. Software engineering \nusually allows an empty subroutine to exist, while physical engineering \nwouldn't. Git cannot have two unique but identical commits (a \ncontradiction in terms).\n\nNormally git will create a new (different & unique) commit for each and \nevery commit, but in this special case a second identical commit was \n'created', but the uniqueness requirement means it _is_ the same as the \nfirst commit.\n\n> as you can see from the trace of the execution\n> of my script, the sha of the commit is the same as that of the other,\n> which means\n> that in the .git/objects there is only one such commit object, and not \n> two with\n> the same sha. The meaning of the word \"create\" is to bring into being \n> something\n> that did not exist before. There is no \"creation\" if the object \n> already exists.\n>\n>>\n>> And how would it help what to insert a sleep for 1 second (or 1 year\n>> for that matter)? As you said, it reads from the system clock, and\n>> there are millions of systems in the world that have Git installed.\n>> You may record the same state on top of the same history as the same\n>> person on two different machines 5 minutes in wallclock time in\n>> between doing so. These two machines may end up creating the same\n>> commit because one of them had a clock skewed by 5 minutes.\n>\n> I understood that the command does not create a new commit if all its \n> data, i.e.\n> tree, committer, ... and date are the same, representing the date with \n> 1 second\n> precision. Sleeping for 1 second guarantees that there is no commit in \n> the repo\n> that has the same time as the time after the sleep, i.e. that the\n> command creates\n> a (new) commit.\n>\n>>\n>> What problem are you really trying to solve? You mentioned\n>> importing from the foreign SCM,\n>\n> I quoted a piece of the man page of git commit, that states that\n> --allow-empty bypasses\n> the safety check that prevents to make a new commit. That piece\n> incidentally states\n> that it is \"primarily\" used by foreign SCM interface scripts. But of\n> course it can be used\n> in any script that needs to build a commit on top of another.\n>\n>>\n>> You also did not seem to have read what I wrote, or deliberately\n>> ignored it (in which case I am wasting even more time writing this,\n>> so I'll stop).\n>\n> I did not deliberately ignore what you wrote. I might have missed some\n> point though.\n>\n>> This does not have anything to do with \"--allow-empty\"; removing\n>> \"the option\" would not help anything, either.\n>\n> I am reporting a problem with --allow-empty, so why you say that this\n> does not have\n> anything to do with it?\n> Removing the option removes a behavior that is not predictable.\n> Often it is better to remove a feature that turns out to be\n> inconsistent than to leave it\n> in the software. Of course a much better avenue is to make it \n> consistent.\n>\n>> Run the following on a fast-enough machine.\n>>\n> I did, and obtained most of the times \"I was quick enough\" and\n> sometimes \"I was not quick enough\", which is the same kind of behavior\n> of my script.\n>\n> The problem I am trying to solve is to push to a remote server the\n> source files only,\n> while keeping in the local repo both sources and binaries. To do it, I\n> keep an orphan\n> branch, say \"sources\". When I make a commit on the master branch, I \n> make also a\n> commit on the sources one after having un-staged (git rm --cached) the \n> binaries.\n> The script that does this must cope also with the particular case in\n> which in the commit\n> on the master branch there are no sources. Basically the script does:\n>\n> # this is the commit on the master branch\n> git init\n> echo \"aaa\" >f1\n> git add f1\n> git commit -m A\n>\n> # this is the piece of the script that builds the sources branch\n> git checkout --orphan sources\n> # git rm --cached ... remove binaries, if any\"\n> git commit -m A --allow-empty\n> git rev-list --all --pretty=oneline\n>\n> When there are binaries in the commit A, they are removed, and the\n> tree for the second\n> git commit is then different, and the commit is actually created.\n> When there are no binaries (as in the script above, in which the\n> removal is commented out),\n> the second git commit would not create any new commit, and I would not\n> have an orphan\n> branch. Thence the --allow-empty to force it to create a new commit.\n> Unfortunately, it creates a new commit only if the system clock\n> changes the seconds of\n> the system time between the two git commits.\n> If you insert a \"sleep 1\" before the second git commit, the commit is\n> really created.\n>\n> I spent many hours to spot this time-dependent error ....\n>\n> -Angelo\n> --\n> To unsubscribe from this list: send the line \"unsubscribe git\" in\n> the body of a message to majordomo@vger.kernel.org\n> More majordomo info at http://vger.kernel.org/majordomo-info.html\n>\n>\n> -----\n> No virus found in this message.\n> Checked by AVG - www.avg.com\n> Version: 2012.0.2221 / Virus Database: 2441/5305 - Release Date: \n> 10/02/12\n> \n"},{"id":"200386","messageId":"CAB9Jk9BczA0KjU2oKm=S_Ms6mqBFNHg8RO3xvb+PNEsMxQih+A@mail.gmail.com","threadId":"31710","inReplyTo":"506BE577.900@viscovery.net","subject":"Re: erratic behavior commit --allow-empty","fromName":"Angelo Borsotti","fromEmail":"angelo.borsotti@gmail.com","sentAt":"2012-10-03T07:35:47Z","receivedAt":"2012-10-03T07:35:47Z","isPatch":false,"sender":{"key":"angelo.borsotti@gmail.com","avatar":null},"body":"Hi Hannes,\n\n>\n> Perhaps you are confused by the fact that the commit you made first does\n> not have a parent, either. But that is just a \"side effect\" that it\n> happened to be the very first commit that you made after 'git init'.\n\nWell, I know that, and this is why I added --allow-empty. The man page of\ngit commit (\"This option bypasses the safety, ...\"). I thought that it\nwould unconditionally\ncreate a brand new, commit.\n\n> Your case does not demonstrate a bug in git.\n\nThe bug is that the git commit --allow-empty does a different action\ndepending on\nwhether the system clock has changed its seconds right before the command.\nThis is a time-dependent behavior, and it is very harmful. Our applications must\nnever behave differently depending on the time they are run or on the processor\nspeed. It is an issue of correctness and robustness of software. To\nhave a predictable\nbehavior, i.e. to create a brand new commit with git commit\n--allow-empty, the command\nin a script must ALWAYS be preceded by a sleep 1 so as to make sure\nthat the date\nand time it will use are for sure different from any other commits'.\nBut then it would be a lot better to embed such a sleep in the command.\nIf that is not possible, then the users must be warned in the man page\nthat the command\nsometimes may not create a brand new commit, and that if the user\ninstead wants it s/he\nshould change something in the commit, like, e.g. the message.\n\n>\n> Why don't you use a different commit message to ensure that there is a\n> difference between the commits?\n>\n\nThis is what eventually I did to force the creation of a brand new commit.\n\n-Angelo\n"},{"id":"200387","messageId":"CAB9Jk9ARWnE-cWVjqMUFiua21QjqGEX3VhYjKQMBSotVYXXK1Q@mail.gmail.com","threadId":"31710","inReplyTo":"90464C79DA97415C9D66846A77ECAA4A@PhilipOakley","subject":"Re: erratic behavior commit --allow-empty","fromName":"Angelo Borsotti","fromEmail":"angelo.borsotti@gmail.com","sentAt":"2012-10-03T07:45:36Z","receivedAt":"2012-10-03T07:45:36Z","isPatch":false,"sender":{"key":"angelo.borsotti@gmail.com","avatar":null},"body":"In reply to Philip,\n\nI understand what the implementation does, but I am stating that it is\nnot what the\nuser (by reading the man page) expects.\nThe user adds --allow-empty to have a different & unique commit, such seems to\nbe the purpose of the option.\nUnfortunately, it gets that only sometimes, depending on the exact\ninstant in time\nthe command is executed, which is out of his/her control.\nI think that you would agree with me that this is not a nice\nbehaviour. How could a user\never use a command that is not predictable?\nIf it is not possible to change the implementation, at least warn the\nuser in the man page.\n\n-Angelo\n"},{"id":"200389","messageId":"vpq626s6kwu.fsf@grenoble-inp.fr","threadId":"31710","inReplyTo":"CAB9Jk9ARWnE-cWVjqMUFiua21QjqGEX3VhYjKQMBSotVYXXK1Q@mail.gmail.com","subject":"Re: erratic behavior commit --allow-empty","fromName":"Matthieu Moy","fromEmail":"matthieu.moy@grenoble-inp.fr","sentAt":"2012-10-03T08:04:49Z","receivedAt":"2012-10-03T08:04:49Z","isPatch":false,"sender":{"key":"matthieu.moy@grenoble-inp.fr","avatar":"https://gravatar.com/avatar/72c8a2705971a25dfaff23cece15130d405685845d911aedd5667ace277f3fc5?d=mp&s=160"},"body":"Angelo Borsotti writes:\n\n> I think that you would agree with me that this is not a nice\n> behaviour.\n\nThis is fundamentally how Git works. You probably didn't notice it, but\nif you do\n\necho 'some content' > file1.txt\ngit add file1.txt\ngit commit -m \"file1\"\n\necho 'some content' > file2.txt\ngit add file2.txt\ngit commit -m \"file2\"\n\nThen the second commit does not \"create\" a new blob object for\nfile2.txt, because it has the same content as an existing one. But the\npoint is: you really don't care, or indeed, you care about sharing the\nblob objects to save disk space.\n\n> How could a user ever use a command that is not predictable?\n\nIt is predictible: give it twice the same inputs in the same conditions,\nand it will yield the same output.\n\nYou still didn't tell us where the problem was. You are unhappy with\nhaving twice the same sha1 for the same object, but what concrete bad\nconsequence does this have? (except for saving bandwidth in addition to\ndisk space when trying to push your commit)\n\n-- \nMatthieu Moy\nhttp://www-verimag.imag.fr/~moy/\n"},{"id":"200393","messageId":"CAB9Jk9DFb2s4s00yCNUytxFdrOQKPEKZGsXpKzwZDo5WAOdXaQ@mail.gmail.com","threadId":"31710","inReplyTo":"vpq626s6kwu.fsf@grenoble-inp.fr","subject":"Re: erratic behavior commit --allow-empty","fromName":"Angelo Borsotti","fromEmail":"angelo.borsotti@gmail.com","sentAt":"2012-10-03T08:24:00Z","receivedAt":"2012-10-03T08:24:00Z","isPatch":false,"sender":{"key":"angelo.borsotti@gmail.com","avatar":null},"body":"Hi Matthiew,\n\n> Then the second commit does not \"create\" a new blob object for\n> file2.txt, because it has the same content as an existing one. But the\n> point is: you really don't care, or indeed, you care about sharing the\n> blob objects to save disk space.\n\nThat is fine, and it is well documented.\n\n> It is predictible: give it twice the same inputs in the same conditions,\n> and it will yield the same output.\n\nWell, I have some difficulties to hit the return key while watching the system\nclock at the same time so as to make sure that the command is executed\nbefore the seconds change. So, it theory it would be predictable, but not\nin practice. Note that commands must be predictable for the user that writes\nthem, i.e. the user must be able to figure out what the result is. Which is\ncertainly not the case here.\n\n>\n> You still didn't tell us where the problem was.\n\nI described it few mails above. I wanted to create an orphan branch. The command\nto create it is git checkout --orphan. However, the branch is not\nactually created\nuntil a commit is done on it. Then I did such a commit (all this is\nplaced in a script\nto be used by my developers), but if there are no changes, git commit does not\ncreate a new one. To force it to create a brand new one I added\n--allow-empty to it\nbecause the man page stated that it would bypass the check that prevents to make\na new one. The I discovered that sometimes --allow-empty does not behave as\nexpected.\n\n\n-Angelo\n"},{"id":"200398","messageId":"m2fw5vooem.fsf@linux-m68k.org","threadId":"31710","inReplyTo":"CAB9Jk9ARWnE-cWVjqMUFiua21QjqGEX3VhYjKQMBSotVYXXK1Q@mail.gmail.com","subject":"Re: erratic behavior commit --allow-empty","fromName":"Andreas Schwab","fromEmail":"schwab@linux-m68k.org","sentAt":"2012-10-03T10:12:01Z","receivedAt":"2012-10-03T10:12:01Z","isPatch":false,"sender":{"key":"schwab@linux-m68k.org","avatar":"https://avatars.githubusercontent.com/u/2175493?v=4"},"body":"Angelo Borsotti writes:\n\n> The user adds --allow-empty to have a different & unique commit\n\nWhere does the manual say that --allow-empty implies a different and\nunique commit?\n\nAndreas.\n\n-- \nAndreas Schwab, schwab@linux-m68k.org\nGPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5\n\"And now for something completely different.\"\n"},{"id":"200400","messageId":"vpqvcer4xvo.fsf@grenoble-inp.fr","threadId":"31710","inReplyTo":"CAB9Jk9DFb2s4s00yCNUytxFdrOQKPEKZGsXpKzwZDo5WAOdXaQ@mail.gmail.com","subject":"Re: erratic behavior commit --allow-empty","fromName":"Matthieu Moy","fromEmail":"matthieu.moy@grenoble-inp.fr","sentAt":"2012-10-03T11:07:39Z","receivedAt":"2012-10-03T11:07:39Z","isPatch":false,"sender":{"key":"matthieu.moy@grenoble-inp.fr","avatar":"https://gravatar.com/avatar/72c8a2705971a25dfaff23cece15130d405685845d911aedd5667ace277f3fc5?d=mp&s=160"},"body":"Angelo Borsotti writes:\n\n>> You still didn't tell us where the problem was.\n>\n> I described it few mails above. I wanted to create an orphan branch.\n\nAnd you did. The branch happens to point to the same commit as another\nexisting commit, but this is a very common situation. Try this:\n\n# do arbitrary hacking and commit on branch master\ngit checkout -b new-branch\ngitk\n\nYou will see branches \"master\" and \"new-branch\" pointing to the same\ncommit (but you HEAD points to new-branch, as \"git branch\" will tell\nyou).\n\nYou still did not describe a _problem_. Up to now, the only \"problem\" I\nsee is that you have twice the same sha1 showing up, but you did not\ndescribe somethine concrete that you wanted to do and did not work.\n\n> However, the branch is not actually created until a commit is done on\n> it.\n\nRight, but the definition of \"done\" in your sentence includes \"reusing\nan object in the object database\".\n\nI just tried this:\n\nrm -fr test\ngit init test\ncd test\ndate > foo.txt\ngit add .\ngit commit --allow-empty -m foo\ngit checkout --orphan new-branch\ngit commit --allow-empty -m foo\n\nI ended up with a branch \"master\" and a branch \"new-branch\", both\npointing to the same commit. The new branch _is_ created.\n\n(BTW, --allow-empty is useless here as you have no parent)\n\n-- \nMatthieu Moy\nhttp://www-verimag.imag.fr/~moy/\n"},{"id":"200403","messageId":"CAB9Jk9Dqoom-hBQPG5iqe2JyiJtVoFWZ9-5W9ktUsa9F9mbXRQ@mail.gmail.com","threadId":"31710","inReplyTo":"m2fw5vooem.fsf@linux-m68k.org","subject":"Re: erratic behavior commit --allow-empty","fromName":"Angelo Borsotti","fromEmail":"angelo.borsotti@gmail.com","sentAt":"2012-10-03T11:37:27Z","receivedAt":"2012-10-03T11:37:27Z","isPatch":false,"sender":{"key":"angelo.borsotti@gmail.com","avatar":null},"body":"Hi Andreas,\n\n>\n> Where does the manual say that --allow-empty implies a different and\n> unique commit?\n>\n\nIn the git commit man page:\n\n\"--allow-empty\n\n Usually recording a commit that has the exact same tree as its\nsole parent commit is a mistake, and the command prevents you from\nmaking such a commit. This option bypasses the safety, and is\nprimarily for use by foreign SCM interface scripts.\"\n\nBy reading: \"the command prevents\" I understand that a new commit is\nnot created, and \"This option bypasses\" that it is instead created.\n\nPerhaps my reading was a bit straightforward, but a man page is not a\nsort of ancient holy writing that the reader has to sift every word to\nunderstand hidden meanings, it should be something\nclear and plain.\n\n-Angelo\n"},{"id":"200404","messageId":"CAB9Jk9BTCaV7RDx6_K+MKOeJTdOQPOwvnGM0UNxg9S8KMo4D4Q@mail.gmail.com","threadId":"31710","inReplyTo":"vpqvcer4xvo.fsf@grenoble-inp.fr","subject":"Re: erratic behavior commit --allow-empty","fromName":"Angelo Borsotti","fromEmail":"angelo.borsotti@gmail.com","sentAt":"2012-10-03T11:52:52Z","receivedAt":"2012-10-03T11:52:52Z","isPatch":false,"sender":{"key":"angelo.borsotti@gmail.com","avatar":null},"body":"Hi\n\n>>> You still didn't tell us where the problem was.\n\nI thought I did, but here it is: I have private and a public\nrepositories. In the private ones the developers keep both the sources\nand the binaries. In the public ones they keep only the sources. They\ndo not want the binaries there because binaries are very large and\nrequite much time to be pushed. Besides that, they are not even needed\nbecause they must be rebuilt anyway.\nTo push the sources only they keep in the private repositories an\norphan branch in which commits are done taking the relevant commits in\nthe (say) master branch and removing the binaries from the index.\nPushing directly the master branch would push also the binaries even\nif they were removed from its index (the history gets pushed): thence\nthe need for an orphan branch. Scripts have been provided to do this\neasily and safely. Now, it could happen that a developer does not have\n(yet) binaries, but want to push all the same. The script has to take\ncare for this special case, in which no binaries are removed, but a\ncommit on the orphan branch is done all the same. And here is the\nproblem since git commit does not produce a brand new, different &\nunique commit all the times, making then the orphan branch point to\nthe master one, i.e. becoming a non-orphan one.\n\n> I ended up with a branch \"master\" and a branch \"new-branch\", both\n> pointing to the same commit. The new branch _is_ created.\n>\n\nExactly, it is created, but it is not an orphan ... or more precisely,\nit is sometimes, depending on how fast you are to enter the second\ncommit command. This time-dependent behaviour is what I am talking\nabout.\n\n-Angelo\n"},{"id":"200407","messageId":"1349267146-ner-5314@calvin","threadId":"31710","inReplyTo":"CAB9Jk9DFb2s4s00yCNUytxFdrOQKPEKZGsXpKzwZDo5WAOdXaQ@mail.gmail.com","subject":"Re: erratic behavior commit --allow-empty","fromName":"Tomas Carnecky","fromEmail":"tomas.carnecky@gmail.com","sentAt":"2012-10-03T12:25:46Z","receivedAt":"2012-10-03T12:25:46Z","isPatch":false,"sender":{"key":"tomas.carnecky@gmail.com","avatar":null},"body":"On Wed, 03 Oct 2012 10:24:00 +0200, Angelo Borsotti wrote:\n> create a new one. To force it to create a brand new one I added\n> --allow-empty to it\n> because the man page stated that it would bypass the check that prevents to make\n> a new one. The I discovered that sometimes --allow-empty does not behave as\n> expected.\n\nThe documentation only states that it will skip the 'same tree as parent'\ncheck, not that it will *always* create a new commit.\n"},{"id":"200410","messageId":"CABURp0pbX4Fk4sNWCicfF7Gm52-KTMBrasdi_XHnjtE2zmSBFg@mail.gmail.com","threadId":"31710","inReplyTo":"CAB9Jk9CSW0ObJtgsfSwjf+k438=V8i7dP0p+YUehqdh2Z0k6tA@mail.gmail.com","subject":"Re: erratic behavior commit --allow-empty","fromName":"Phil Hord","fromEmail":"phil.hord@gmail.com","sentAt":"2012-10-03T12:59:11Z","receivedAt":"2012-10-03T12:59:11Z","isPatch":false,"sender":{"key":"phil.hord@gmail.com","avatar":"https://avatars.githubusercontent.com/u/123908?v=4"},"body":"On Tue, Oct 2, 2012 at 3:34 PM, Angelo Borsotti\n wrote:\n>\n> \"Usually recording a commit that has the exact same tree as its sole\n> parent commit is a mistake, and the command prevents you from making\n> such a commit. This option bypasses the safety, and is primarily for\n> use by foreign SCM interface scripts.\"\n\nPerhaps the confusion arises from the the meaning of \"the safety\". In\nthis case, the safety mechanism in place is to prevent you from\ncreating a child commit which has the same \"tree\" contents (working\ndirectory) as the parent commit. It will not be the same commit\nbecause it has different parent(s) than its parent commit; but the\ntree (working directory) is the same and git normally prevents you\nfrom doing this because normally this is an accident, a mistake.\n\n--allow-empty tells git you intend to do this and so it should bypass\nthis \"no changed files\" safety mechanism. It is not a safety to\nprevent you creating a new commit with the exact same sha1; the safety\nis concerned only with the exact same \"working directory\" file\ncontents.\n\nCan you suggest a rewrite of this description which would make it more clear?\n\nPhil\n"},{"id":"200412","messageId":"CAB9Jk9Au32hGf-UB2PRa46qaA6GtpJ3jWL=SWWXns=Jc6O97KQ@mail.gmail.com","threadId":"31710","inReplyTo":"1349267146-ner-5314@calvin","subject":"Re: erratic behavior commit --allow-empty","fromName":"Angelo Borsotti","fromEmail":"angelo.borsotti@gmail.com","sentAt":"2012-10-03T13:08:21Z","receivedAt":"2012-10-03T13:08:21Z","isPatch":false,"sender":{"key":"angelo.borsotti@gmail.com","avatar":null},"body":"Hi Thomas,\n\n> The documentation only states that it will skip the 'same tree as parent'\n> check, not that it will *always* create a new commit.\n\nOk, understood: you believe that the documentation is clear, and I\nthat it is somehow not.\nI would prefer to have it more plain.\n\nBut that is not all the story. The behavior of the command remains\ntime-dependent,\nso that a user cannot reliably predict its result. I think that this\nis an ill-specified option.\nI would not insist in removing it (although that would be the correct\nsolution), but at\nleast to warn the user about this possibly unexpected behavior.\n\n-Angelo\n"},{"id":"200413","messageId":"CAB9Jk9DmFQcgd2jT4c1eMx91mikchVcKfNVLsmfjxaZL_G3vTQ@mail.gmail.com","threadId":"31710","inReplyTo":"CABURp0oHez6j8+FPG8Zm52TGVyC1XwWhE55TBDrXRGFrW6kWww@mail.gmail.com","subject":"Re: erratic behavior commit --allow-empty","fromName":"Angelo Borsotti","fromEmail":"angelo.borsotti@gmail.com","sentAt":"2012-10-03T13:35:31Z","receivedAt":"2012-10-03T13:35:31Z","isPatch":false,"sender":{"key":"angelo.borsotti@gmail.com","avatar":null},"body":"Hi Phil\n\n>\n> I think what you are missing here is that the script does _not_ have\n> to take care for this special case. The script can do the same thing\n> it does for all the other cases and it will work just fine. This is\n> because your goal, as I understand it, is this:\n>\n> A. Take this branch,\n> B. Copy it but remove the binaries,\n> C. Push it to the remote (with no binaries)\n>\n> If the branch has no binaries to begin with, then B is a no-op. Your\n> insistence that the new commits get unique SHA1's is unnecessary and\n> is what is causing your trouble.\n\nSuppose the branch has binaries. Then the only way to avoid to push\nthem is to create an orphan branch (one that has no parents),\notherwise git push will upload also the parent with its binaries.\nThis is why there is a need to make the script perform different\nactions depending on the presence of the binaries. In the attempt to\nmake the script handle both cases in a simple way I tried to make an\nempty commit, and discovered the time-dependent behavior of it.\n\n>\n> Consider this analogous operation:\n>\n> A. Take this file,\n> B. Remove every line that does not contain foo,\n> C. Cat the result to the console (with only foo lines)\n>\n\nThis example differs from the commit one in that the user has to cope\nwith data that s/he can fully control (the contents of files), while\nin the other s/he has to cope with the passing of time, which s/he\ncannot control. So, taking the files I can predict the result, but\ntaking the commits, I cannot because I do not know exactly when they\nwill actually be run. Time is a sort of independent variable that I\nknow only approximately (or very approximately when the commands are\nembedded in scripts).\n\n>\n> It seems to those more familiar with git that you are saying that this\n> is \"the problem\", that the operation did not work because the results\n> are not unique each time.\n\nExactly.\n\n>\n> But if you ignore the SHA1 of the commits and just rely on the branch\n> names, I think you will be happier. This is because two branches can\n> refer to the same SHA1 commit without causing any problem. You may\n> find that sometimes when you push there is no update applied to the\n> server. But this is not a mistake. It is simply that the server\n> already has the same contents as you are pushing, even though your\n> local branch name is different than it was before.\n\nActually I ignore the SHA1 of the commits, and rely on the branch\nnames I have topic branches and /src/topic branches. Developers push\nwhen they have something new. Of course the scripts must take care of\nwhen they are called and there is nothing to push, but that is not a\nbig problem.\nI eventually found a workaround, which is to change the commit\nmessage, forcing then git commit to create a brand new commit.\n\n> I think when you say \"orphan\" you mean it has a different SHA1 than\n> any other commit. But this is not what \"orphan\" means.\n\nNo, I mean that it has no parents.\n\nActually, in the special case in which there are no binaries, I could\ncreate a branch that points to the same commit as the branch that it\nis mirroring, and push it. However, this has two disadvantages: 1.\nthat it will not be an orphan while in the more general case it is,\nand 2, that the history of commits will be pushed to the remote\nserver, while in the general case (with an orphan) it will not. I\npreferred to have a unique branch topology so as to make the picture\nas simple as possible for the developers.\n\nNote that eventually I solved the problem with a tweak. I still\nbelieve that the git commit command does not behave properly, and that\nchanging nothing (implementation or documentation) leaves a drifting\nmine on which someone (or even myself) will stumble sooner or later. I\nam spending time to write all this because I care for git and I would\nreally see it improving over time removing weak spots, and believe\nthat you do the same.\n\n-Angelo\n>\n> Phil\n"},{"id":"200417","messageId":"m2r4pf1xh6.fsf@igel.home","threadId":"31710","inReplyTo":"CAB9Jk9Dqoom-hBQPG5iqe2JyiJtVoFWZ9-5W9ktUsa9F9mbXRQ@mail.gmail.com","subject":"Re: erratic behavior commit --allow-empty","fromName":"Andreas Schwab","fromEmail":"schwab@linux-m68k.org","sentAt":"2012-10-03T13:44:37Z","receivedAt":"2012-10-03T13:44:37Z","isPatch":false,"sender":{"key":"schwab@linux-m68k.org","avatar":"https://avatars.githubusercontent.com/u/2175493?v=4"},"body":"Angelo Borsotti writes:\n\n> By reading: \"the command prevents\" I understand that a new commit is\n> not created, and \"This option bypasses\" that it is instead created.\n\nBut where does it say \"different and unique\"?\n\nAndreas.\n\n-- \nAndreas Schwab, schwab@linux-m68k.org\nGPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5\n\"And now for something completely different.\"\n"},{"id":"200419","messageId":"vpqfw5v1wva.fsf@grenoble-inp.fr","threadId":"31710","inReplyTo":"CAB9Jk9BTCaV7RDx6_K+MKOeJTdOQPOwvnGM0UNxg9S8KMo4D4Q@mail.gmail.com","subject":"Re: erratic behavior commit --allow-empty","fromName":"Matthieu Moy","fromEmail":"matthieu.moy@grenoble-inp.fr","sentAt":"2012-10-03T13:57:45Z","receivedAt":"2012-10-03T13:57:45Z","isPatch":false,"sender":{"key":"matthieu.moy@grenoble-inp.fr","avatar":"https://gravatar.com/avatar/72c8a2705971a25dfaff23cece15130d405685845d911aedd5667ace277f3fc5?d=mp&s=160"},"body":"Angelo Borsotti writes:\n\n> [...] making then the orphan branch point to the master one, i.e.\n> becoming a non-orphan one.\n\nI understand both parts of the sentense, but not the \"i.e.\".\n\nAnd I still don't see a concrete problem. \"two branches point to the\nsame commit\" is not a problem, it's an observation. I have branches\npointing to the same commit all the time.\n\n>> I ended up with a branch \"master\" and a branch \"new-branch\", both\n>> pointing to the same commit. The new branch _is_ created.\n>\n> Exactly, it is created, but it is not an orphan ... or more precisely,\n> it is sometimes, depending on how fast you are to enter the second\n> commit command. This time-dependent behaviour is what I am talking\n> about.\n\nYou don't understand what an orphan branch is.\n\nWhat \"git checkout --orphan && git commit\" does is that it creates a\ncommit that doesn't have parent (hence the name orphan, btw). It does in\nyour case. You _do_ create an orphan commit regardless of the timing.\n\nThe fact that another branch points to the same commit is a different\nmatter, and you still didn't explain why this was problematic.\n\n-- \nMatthieu Moy\nhttp://www-verimag.imag.fr/~moy/\n"},{"id":"200420","messageId":"CABURp0okOXpZGGawAUfUEUq3ahSHic-80qsfr5oJ4jX5ZFUh4g@mail.gmail.com","threadId":"31710","inReplyTo":"CAB9Jk9DmFQcgd2jT4c1eMx91mikchVcKfNVLsmfjxaZL_G3vTQ@mail.gmail.com","subject":"Re: erratic behavior commit --allow-empty","fromName":"Phil Hord","fromEmail":"phil.hord@gmail.com","sentAt":"2012-10-03T14:15:42Z","receivedAt":"2012-10-03T14:15:42Z","isPatch":false,"sender":{"key":"phil.hord@gmail.com","avatar":"https://avatars.githubusercontent.com/u/123908?v=4"},"body":"On Wed, Oct 3, 2012 at 9:35 AM, Angelo Borsotti\n wrote:\n> Hi Phil\n>\n>>\n>> I think what you are missing here is that the script does _not_ have\n>> to take care for this special case. The script can do the same thing\n>> it does for all the other cases and it will work just fine. This is\n>> because your goal, as I understand it, is this:\n>>\n>> A. Take this branch,\n>> B. Copy it but remove the binaries,\n>> C. Push it to the remote (with no binaries)\n>>\n>> If the branch has no binaries to begin with, then B is a no-op. Your\n>> insistence that the new commits get unique SHA1's is unnecessary and\n>> is what is causing your trouble.\n>\n> Suppose the branch has binaries. Then the only way to avoid to push\n> them is to create an orphan branch (one that has no parents),\n> otherwise git push will upload also the parent with its binaries.\n\nThis is true only if the root commit also has binaries. Otherwise it\nis fine to push a branch with the common ancestor.\n\nSuppose A does not have binaries but B and C do.\n\nA---B---C\n\nNow we need to make a new branch ending at C' which has no binaries:\nA---B---C\n \\\n ---B'---C'\n\nA already has no binaries, so we did not need to make an A'. Now we\ncan push C' to the server and no binaries will be pushed. That is\nbecause the server will receive only these commits:\n\nA---B'---C'\n\n\n> This is why there is a need to make the script perform different\n> actions depending on the presence of the binaries. In the attempt to\n> make the script handle both cases in a simple way I tried to make an\n> empty commit, and discovered the time-dependent behavior of it.\n\nEvery commit is time-dependent. You tried to make a _unique_ empty\ncommit, and this is where you ran into trouble. I think your\nuniqueness constraint is overkill.\n\n\n>> Consider this analogous operation:\n>>\n>> A. Take this file,\n>> B. Remove every line that does not contain foo,\n>> C. Cat the result to the console (with only foo lines)\n>>\n>\n> This example differs from the commit one in that the user has to cope\n> with data that s/he can fully control (the contents of files), while\n> in the other s/he has to cope with the passing of time, which s/he\n> cannot control. So, taking the files I can predict the result, but\n> taking the commits, I cannot because I do not know exactly when they\n> will actually be run. Time is a sort of independent variable that I\n> know only approximately (or very approximately when the commands are\n> embedded in scripts).\n\nYou need not be concerned with the time on the commit, nor the\nuniqueness of the SHA1.\n\n\n>> It seems to those more familiar with git that you are saying that this\n>> is \"the problem\", that the operation did not work because the results\n>> are not unique each time.\n>\n> Exactly.\n>\n>>\n>> But if you ignore the SHA1 of the commits and just rely on the branch\n>> names, I think you will be happier. This is because two branches can\n>> refer to the same SHA1 commit without causing any problem. You may\n>> find that sometimes when you push there is no update applied to the\n>> server. But this is not a mistake. It is simply that the server\n>> already has the same contents as you are pushing, even though your\n>> local branch name is different than it was before.\n>\n> Actually I ignore the SHA1 of the commits, and rely on the branch\n> names I have topic branches and /src/topic branches. Developers push\n> when they have something new. Of course the scripts must take care of\n> when they are called and there is nothing to push, but that is not a\n> big problem.\n> I eventually found a workaround, which is to change the commit\n> message, forcing then git commit to create a brand new commit.\n\nDoesn't this force git always to push new commits even though the\ncontents match commits already on the server?\n\n>> I think when you say \"orphan\" you mean it has a different SHA1 than\n>> any other commit. But this is not what \"orphan\" means.\n>\n> No, I mean that it has no parents.\n>\n> Actually, in the special case in which there are no binaries, I could\n> create a branch that points to the same commit as the branch that it\n> is mirroring, and push it. However, this has two disadvantages: 1.\n> that it will not be an orphan while in the more general case it is,\n> and 2, that the history of commits will be pushed to the remote\n> server, while in the general case (with an orphan) it will not. I\n> preferred to have a unique branch topology so as to make the picture\n> as simple as possible for the developers.\n\nIt seems to me that you are creating unnecessary work for the server\nand for your scripts. But perhaps I do not fully understand your use\ncase.\n\n> Note that eventually I solved the problem with a tweak. I still\n> believe that the git commit command does not behave properly, and that\n> changing nothing (implementation or documentation) leaves a drifting\n> mine on which someone (or even myself) will stumble sooner or later. I\n> am spending time to write all this because I care for git and I would\n> really see it improving over time removing weak spots, and believe\n> that you do the same.\n\nYou may suggest improvements to the documentation. But be careful to\nunderstand the existing documentation completely before you do.\n\nThanks for helping.\n\nPhil\n"},{"id":"200421","messageId":"CAB9Jk9CdYXZzPcM=YiwOUyKNQ=4uKpfs+HY7WpWBmqgQRw4SyA@mail.gmail.com","threadId":"31710","inReplyTo":"CABURp0pbX4Fk4sNWCicfF7Gm52-KTMBrasdi_XHnjtE2zmSBFg@mail.gmail.com","subject":"Re: erratic behavior commit --allow-empty","fromName":"Angelo Borsotti","fromEmail":"angelo.borsotti@gmail.com","sentAt":"2012-10-03T14:25:57Z","receivedAt":"2012-10-03T14:25:57Z","isPatch":false,"sender":{"key":"angelo.borsotti@gmail.com","avatar":null},"body":"Hi Phil,\n\n> Perhaps the confusion arises from the the meaning of \"the safety\". In\n> this case, the safety mechanism in place is to prevent you from\n> creating a child commit which has the same \"tree\" contents (working\n> directory) as the parent commit. It will not be the same commit\n> because it has different parent(s) than its parent commit; but the\n> tree (working directory) is the same and git normally prevents you\n> from doing this because normally this is an accident, a mistake.\n>\n> --allow-empty tells git you intend to do this and so it should bypass\n> this \"no changed files\" safety mechanism. It is not a safety to\n> prevent you creating a new commit with the exact same sha1; the safety\n> is concerned only with the exact same \"working directory\" file\n> contents.\n>\n> Can you suggest a rewrite of this description which would make it more clear?\n\nInstead of:\n\n\"Usually recording a commit that has the exact same tree as its sole\nparent commit is a mistake, and the command prevents you from making\nsuch a commit. This option bypasses the safety, and is primarily for\nuse by foreign SCM interface scripts.\"\n\nI would suggest:\n\n\"Usually recording a commit that has the exact same tree as its sole\nparent commit is not allowed, and the command prevents you from making\nsuch a commit. This option allows to disregard this condition, thereby\nmaking a commit even when the trees are the same. Note that when the\ntree, author, parents, message and date (with the precision of one\nsecond) are the same as those of an existing commit object, no new\ncommit object is created, and the identity of the existing one is\nreturned.\"\n>\n> Phil\n"},{"id":"200422","messageId":"CAB9Jk9Bqq=fs4v-oAj_TiaSw5WOiQQFsm_WEZP_ECyPW1L_DHg@mail.gmail.com","threadId":"31710","inReplyTo":"m2r4pf1xh6.fsf@igel.home","subject":"Re: erratic behavior commit --allow-empty","fromName":"Angelo Borsotti","fromEmail":"angelo.borsotti@gmail.com","sentAt":"2012-10-03T14:37:01Z","receivedAt":"2012-10-03T14:37:01Z","isPatch":false,"sender":{"key":"angelo.borsotti@gmail.com","avatar":null},"body":"Hi Andreas,\n\n> But where does it say \"different and unique\"?\n\nIt does not, but it says: \"Usually recording a commit that has the\nexact same tree as its sole parent commit is a mistake, and the\ncommand prevents you from making such a commit.\", followed by \"This\noption bypasses the safety ...\" leading to thing that the option\nnegates that \"prevents\" above.\nI do understand that by reading very carefully each word of these\nsentences one can eventually figure out that the option removes the\ncheck on the tree only, and that all the others remain, including the\none on the identity of the time. However, it does not say that the\ntime must be equal with the approximation of one second. Apart from\nthis detail, it does not state plainly that no commit object is\ncreated.\n\n-Angelo\n"},{"id":"200423","messageId":"CAB9Jk9Ar3PbbBu-8AEBsNGDAUeghyi2maLCbdZjSdpMCWseq6w@mail.gmail.com","threadId":"31710","inReplyTo":"vpqfw5v1wva.fsf@grenoble-inp.fr","subject":"Re: erratic behavior commit --allow-empty","fromName":"Angelo Borsotti","fromEmail":"angelo.borsotti@gmail.com","sentAt":"2012-10-03T14:46:51Z","receivedAt":"2012-10-03T14:46:51Z","isPatch":false,"sender":{"key":"angelo.borsotti@gmail.com","avatar":null},"body":"Hi Matthiew,\n\n>\n> You don't understand what an orphan branch is.\n\nI do not think so. I wanted to create a branch with a commit that has no parent,\nand I think that this is called \"orphan branch\".\n\nI wanted also to have another branch, pointing to a different commit,\nthe difference\nbeing that this contains binaries, and the other does not.\nSo, having two references pointing to the same commit is not a problem for me,\nbut it is not either the solution.\n\n-Angelo\n"},{"id":"200425","messageId":"vpqr4pfboam.fsf@grenoble-inp.fr","threadId":"31710","inReplyTo":"CAB9Jk9Ar3PbbBu-8AEBsNGDAUeghyi2maLCbdZjSdpMCWseq6w@mail.gmail.com","subject":"Re: erratic behavior commit --allow-empty","fromName":"Matthieu Moy","fromEmail":"matthieu.moy@grenoble-inp.fr","sentAt":"2012-10-03T14:52:49Z","receivedAt":"2012-10-03T14:52:49Z","isPatch":false,"sender":{"key":"matthieu.moy@grenoble-inp.fr","avatar":"https://gravatar.com/avatar/72c8a2705971a25dfaff23cece15130d405685845d911aedd5667ace277f3fc5?d=mp&s=160"},"body":"Angelo Borsotti writes:\n\n> Hi Matthiew,\n>\n>>\n>> You don't understand what an orphan branch is.\n>\n> I do not think so. I wanted to create a branch with a commit that has no parent,\n> and I think that this is called \"orphan branch\".\n\nYes, and this is what you did.\n\n> I wanted also to have another branch, pointing to a different commit,\n> the difference\n> being that this contains binaries, and the other does not.\n\nIf they contain different content, they will be different commits, with\ndifferent sha1.\n\n> So, having two references pointing to the same commit is not a problem\n> for me,\n\nSo, you have no problem.\n\nEnd of discussion for me, sorry.\n\n-- \nMatthieu Moy\nhttp://www-verimag.imag.fr/~moy/\n"},{"id":"200430","messageId":"CAJsNXTm5uhWYB+oiz=3WQQKFQ=i=+oO0L6cgGBB+2cm5BgfFCg@mail.gmail.com","threadId":"31710","inReplyTo":"CAB9Jk9CdYXZzPcM=YiwOUyKNQ=4uKpfs+HY7WpWBmqgQRw4SyA@mail.gmail.com","subject":"Re: erratic behavior commit --allow-empty","fromName":"PJ Weisberg","fromEmail":"pj@irregularexpressions.net","sentAt":"2012-10-03T16:06:25Z","receivedAt":"2012-10-03T16:06:25Z","isPatch":false,"sender":{"key":"pj@irregularexpressions.net","avatar":"https://gravatar.com/avatar/aa2c1edcc61b536cc5c9f37fbce084e655446e2309f9818d43f13d47304a602b?d=mp&s=160"},"body":"On Wed, Oct 3, 2012 at 7:25 AM, Angelo Borsotti\n wrote:\n> Hi Phil,\n>\n>> Perhaps the confusion arises from the the meaning of \"the safety\". In\n>> this case, the safety mechanism in place is to prevent you from\n>> creating a child commit which has the same \"tree\" contents (working\n>> directory) as the parent commit. It will not be the same commit\n>> because it has different parent(s) than its parent commit; but the\n>> tree (working directory) is the same and git normally prevents you\n>> from doing this because normally this is an accident, a mistake.\n>>\n>> --allow-empty tells git you intend to do this and so it should bypass\n>> this \"no changed files\" safety mechanism. It is not a safety to\n>> prevent you creating a new commit with the exact same sha1; the safety\n>> is concerned only with the exact same \"working directory\" file\n>> contents.\n>>\n>> Can you suggest a rewrite of this description which would make it more clear?\n>\n> Instead of:\n>\n> \"Usually recording a commit that has the exact same tree as its sole\n> parent commit is a mistake, and the command prevents you from making\n> such a commit. This option bypasses the safety, and is primarily for\n> use by foreign SCM interface scripts.\"\n>\n> I would suggest:\n>\n> \"Usually recording a commit that has the exact same tree as its sole\n> parent commit is not allowed, and the command prevents you from making\n> such a commit. This option allows to disregard this condition, thereby\n> making a commit even when the trees are the same. Note that when the\n> tree, author, parents, message and date (with the precision of one\n> second) are the same as those of an existing commit object, no new\n> commit object is created, and the identity of the existing one is\n> returned.\"\n\nBut that's true of 'git commit' generally; it has nothing to do with\n--allow-empty.\n\n-PJ\n\nGehm's Corollary to Clark's Law: Any technology distinguishable from\nmagic is insufficiently advanced.\n"},{"id":"200433","messageId":"m2fw5va4jc.fsf@igel.home","threadId":"31710","inReplyTo":"CAB9Jk9Bqq=fs4v-oAj_TiaSw5WOiQQFsm_WEZP_ECyPW1L_DHg@mail.gmail.com","subject":"Re: erratic behavior commit --allow-empty","fromName":"Andreas Schwab","fromEmail":"schwab@linux-m68k.org","sentAt":"2012-10-03T16:44:55Z","receivedAt":"2012-10-03T16:44:55Z","isPatch":false,"sender":{"key":"schwab@linux-m68k.org","avatar":"https://avatars.githubusercontent.com/u/2175493?v=4"},"body":"Angelo Borsotti writes:\n\n> it does not state plainly that no commit object is created.\n\nBut the commit object _is_ created, it just doesn't have a unique name.\n\nAndreas.\n\n-- \nAndreas Schwab, schwab@linux-m68k.org\nGPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5\n\"And now for something completely different.\"\n"},{"id":"200435","messageId":"CAB9Jk9D5c-7QKkUFtur4rxBfiaPFzGaMi-+m=Owje_Aaoc6XJQ@mail.gmail.com","threadId":"31710","inReplyTo":"CAJsNXTm5uhWYB+oiz=3WQQKFQ=i=+oO0L6cgGBB+2cm5BgfFCg@mail.gmail.com","subject":"Re: erratic behavior commit --allow-empty","fromName":"Angelo Borsotti","fromEmail":"angelo.borsotti@gmail.com","sentAt":"2012-10-03T17:34:16Z","receivedAt":"2012-10-03T17:34:16Z","isPatch":false,"sender":{"key":"angelo.borsotti@gmail.com","avatar":null},"body":"HI PJ,\n\ntake a git commit without --allow-empty: if the trees are equal, it\ncreates no commit,\nand if the trees are different it creates one.\nTake then a git commit --allow-empty: if the trees are equal it may\ncreate a commit or\nnot depending on the parent, message, author and date; if the trees\nare different it\ncreates a commit.\nSo, the statement does not apply to commits in general.\n\n-Angelo\n"},{"id":"200436","messageId":"CAB9Jk9Aa4d4H5q1euCJ4hdc_K9iBrfiJFnyAYQ+BRNX3D023gg@mail.gmail.com","threadId":"31710","inReplyTo":"m2fw5va4jc.fsf@igel.home","subject":"Re: erratic behavior commit --allow-empty","fromName":"Angelo Borsotti","fromEmail":"angelo.borsotti@gmail.com","sentAt":"2012-10-03T17:37:06Z","receivedAt":"2012-10-03T17:37:06Z","isPatch":false,"sender":{"key":"angelo.borsotti@gmail.com","avatar":null},"body":"Hi Andreas,\n\n> But the commit object _is_ created, it just doesn't have a unique name.\n\nThe command may internally create the commit object, compute its sha and then\nseeing that there is already one in the repo with the same sha, throw it away.\nBut this is an implementation detail. The net result for the user is\nthat after the\ncommand there are no new objects.\n\n-Angelo\n"},{"id":"200446","messageId":"m2iparnztj.fsf@igel.home","threadId":"31710","inReplyTo":"CAB9Jk9Aa4d4H5q1euCJ4hdc_K9iBrfiJFnyAYQ+BRNX3D023gg@mail.gmail.com","subject":"Re: erratic behavior commit --allow-empty","fromName":"Andreas Schwab","fromEmail":"schwab@linux-m68k.org","sentAt":"2012-10-03T19:03:04Z","receivedAt":"2012-10-03T19:03:04Z","isPatch":false,"sender":{"key":"schwab@linux-m68k.org","avatar":"https://avatars.githubusercontent.com/u/2175493?v=4"},"body":"Angelo Borsotti writes:\n\n> that after the command there are no new objects.\n\nThat is an uninteresting implementation detail.\n\nAndreas.\n\n-- \nAndreas Schwab, schwab@linux-m68k.org\nGPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5\n\"And now for something completely different.\"\n"},{"id":"200448","messageId":"m2ehlfnzoz.fsf@igel.home","threadId":"31710","inReplyTo":"CAB9Jk9D5c-7QKkUFtur4rxBfiaPFzGaMi-+m=Owje_Aaoc6XJQ@mail.gmail.com","subject":"Re: erratic behavior commit --allow-empty","fromName":"Andreas Schwab","fromEmail":"schwab@linux-m68k.org","sentAt":"2012-10-03T19:05:48Z","receivedAt":"2012-10-03T19:05:48Z","isPatch":false,"sender":{"key":"schwab@linux-m68k.org","avatar":"https://avatars.githubusercontent.com/u/2175493?v=4"},"body":"Angelo Borsotti writes:\n\n> Take then a git commit --allow-empty: if the trees are equal it may\n> create a commit or not depending on the parent, message, author and\n> date; if the trees are different it creates a commit.\n\nThe commit is _always_ created, with a name depending on the parent,\nmessage, author and date.\n\nAndreas.\n\n-- \nAndreas Schwab, schwab@linux-m68k.org\nGPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5\n\"And now for something completely different.\"\n"},{"id":"200455","messageId":"CAB9Jk9De4h=X3A8ypW6FG6L3B8katmTxhaPY9zhQ+UP1WJd6gg@mail.gmail.com","threadId":"31710","inReplyTo":"m2iparnztj.fsf@igel.home","subject":"Re: erratic behavior commit --allow-empty","fromName":"Angelo Borsotti","fromEmail":"angelo.borsotti@gmail.com","sentAt":"2012-10-03T19:11:22Z","receivedAt":"2012-10-03T19:11:22Z","isPatch":false,"sender":{"key":"angelo.borsotti@gmail.com","avatar":null},"body":"Hi Andreas,\n\nas a user, and owner of a repository I do care about the objects that are in it.\nI do not care about the way they are names, be it numbers or sha's, but for\nsure about their existence.\nSo, for me it is important if a command creates a new commit or not.\n\n> The commit is _always_ created, with a name depending on the parent,\n> message, author and date.\n\nI do not understand this: I have produced several examples that show that\nit is not created, i.e. that the very same objects are present in the repository\nafter the command execution as they were before it.\nIt is possible, though, that you use the word \"create\" with a\ndifferent meaning.\nMost dictionaries state: \"to cause to come into existence\", i.e. before creation\nthe thing does not exist, and after creation it does.\n\n\n-Angelo\n"},{"id":"200447","messageId":"CAJsNXT=Q3wOEJR6wR+e3pMM=PZLbj-9AWF+aT7i-HhkYLMOxiQ@mail.gmail.com","threadId":"31710","inReplyTo":"CAB9Jk9D5c-7QKkUFtur4rxBfiaPFzGaMi-+m=Owje_Aaoc6XJQ@mail.gmail.com","subject":"Re: erratic behavior commit --allow-empty","fromName":"PJ Weisberg","fromEmail":"pj@irregularexpressions.net","sentAt":"2012-10-03T19:43:39Z","receivedAt":"2012-10-03T19:43:39Z","isPatch":false,"sender":{"key":"pj@irregularexpressions.net","avatar":"https://gravatar.com/avatar/aa2c1edcc61b536cc5c9f37fbce084e655446e2309f9818d43f13d47304a602b?d=mp&s=160"},"body":"On Wed, Oct 3, 2012 at 10:34 AM, Angelo Borsotti\n wrote:\n> HI PJ,\n>\n> take a git commit without --allow-empty: if the trees are equal, it\n> creates no commit,\n> and if the trees are different it creates one.\n> Take then a git commit --allow-empty: if the trees are equal it may\n> create a commit or\n> not depending on the parent, message, author and date; if the trees\n> are different it\n> creates a commit.\n> So, the statement does not apply to commits in general.\n\nBut that same thing applies to git commit without --allow-empty. If\nyou create the same object twice then only one copy is stored,\nregardless of how you create it. In fact, the commits you were\ncreating in your example were orphans, so --allow-empty couldn't have\nhad an effect on them in any case.\n\n-PJ\n\nGehm's Corollary to Clark's Law: Any technology distinguishable from\nmagic is insufficiently advanced.\n"},{"id":"200457","messageId":"m2a9w3nvr6.fsf@igel.home","threadId":"31710","inReplyTo":"CAB9Jk9De4h=X3A8ypW6FG6L3B8katmTxhaPY9zhQ+UP1WJd6gg@mail.gmail.com","subject":"Re: erratic behavior commit --allow-empty","fromName":"Andreas Schwab","fromEmail":"schwab@linux-m68k.org","sentAt":"2012-10-03T20:30:53Z","receivedAt":"2012-10-03T20:30:53Z","isPatch":false,"sender":{"key":"schwab@linux-m68k.org","avatar":"https://avatars.githubusercontent.com/u/2175493?v=4"},"body":"Angelo Borsotti writes:\n\n> as a user, and owner of a repository I do care about the objects that are in it.\n\nThere is no need to care.\n\n> I do not understand this: I have produced several examples that show that\n> it is not created, i.e. that the very same objects are present in the repository\n> after the command execution as they were before it.\n\nThat is just an implementation detail. All you need to know is that a\nref has been created or modified.\n\nAndreas.\n\n-- \nAndreas Schwab, schwab@linux-m68k.org\nGPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5\n\"And now for something completely different.\"\n"},{"id":"200450","messageId":"7vvcer2sdo.fsf@alter.siamese.dyndns.org","threadId":"31710","inReplyTo":"506BE577.900@viscovery.net","subject":"Re: erratic behavior commit --allow-empty","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2012-10-03T20:49:23Z","receivedAt":"2012-10-03T20:49:23Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Johannes Sixt writes:\n\n> Why don't you use a different commit message to ensure that there is a\n> difference between the commits?\n\nThat sounds like a workaround, and unnecessary one at that, as it is\nentirely unclear why there _needs_ to be a different commit.\n\nPerhaps OP fears that the orphan branch \"foo\" in his example,\nbecause it happens to point at the same commit object as the\n\"master\", will not stay the same and follow along the advancement of\n\"master\" if some new commits are added to it, and that is the reason\nhe wants a different commit?\n\nOf course, starting from \"master\" and \"foo\" pointing at the same\ncommit (or different commit, for that matter), \"foo\" won't change if\nyou commit on \"master\", so that fear is unnecessary.\n"},{"id":"200469","messageId":"A75F75C4DE3C47C7AF43D39355C873F7@PhilipOakley","threadId":"31710","inReplyTo":"CAB9Jk9BTCaV7RDx6_K+MKOeJTdOQPOwvnGM0UNxg9S8KMo4D4Q@mail.gmail.com","subject":"Re: erratic behavior commit --allow-empty","fromName":"Philip Oakley","fromEmail":"philipoakley@iee.org","sentAt":"2012-10-03T22:32:49Z","receivedAt":"2012-10-03T22:32:49Z","isPatch":false,"sender":{"key":"philipoakley@iee.email","avatar":"https://avatars.githubusercontent.com/u/914343?v=4"},"body":"From: \"Angelo Borsotti\" \nSent: Wednesday, October 03, 2012 12:52 PM\n> Hi\n>\n>>>> You still didn't tell us where the problem was.\n>\n\nI've split up the explanation of your problem you have seen, to see if I \ncan understand where the 'missing' aspect is within the extended \ndicussions.\n\n> I thought I did, but here it is:\n\n> I have private and a public\n> repositories. In the private ones the developers keep both the sources\n> and the binaries. In the public ones they keep only the sources. They\n> do not want the binaries there because binaries are very large and\n> requite much time to be pushed. Besides that, they are not even needed\n> because they must be rebuilt anyway.\n\n> To push the sources only, they keep in the private repositories an\n> orphan branch in which commits are done taking the relevant commits in\n> the (say) master branch and removing the binaries from the index.\n\n> Pushing directly the master branch would push also the binaries even\n> if they were removed from its index (the history gets pushed): thence\n> the need for an orphan branch.\n\n> Scripts have been provided to do this\n> easily and safely. Now, it could happen that a developer does not have\n> (yet) binaries, but want to push all the same.\n\n> The script has to take\n> care for this special case, in which no binaries are removed, but a\n> commit on the orphan branch is done all the same.\n\n>And here is the\n> problem since git commit does not produce a brand new, different &\n> unique commit all the times, making then the orphan branch point to\n> the master one, i.e. becoming a non-orphan one.\n\nWhat isn't clear is how the master branch is created and maintained at \nthis point.\n\nDoes the script create it afresh each time, so that it is also, \nimplicitly, an --orphan branch?\n\n>\n>> I ended up with a branch \"master\" and a branch \"new-branch\", both\n>> pointing to the same commit. The new branch _is_ created.\n>>\nIn such a case (a new master being created every time the script runs), \nthen you can suffer the situation you describe where you have a common \nsentinel commit being used for both branches, even though you thought \nthey were orphaned from each other. - a very special case.\n\nHowever one has to ask how the rest of the script would work in such \nsituations with such a truncated master branch.\n\nIf the master branch has a true history, then you would get different \ncommits being created on the two branches because the parents would be \ndifferent.\n\nOr finally, you have a truly special test (initialisation) case when you \nare starting master (which will later grow) and comparing it to the very \nfirst test case of the --orphan branch and in that special case you \ncould get a common commit. But that is a one off special case, and would \nnot recur in practice.\n\nCan you say more about the script?\n\n> Exactly, it is created, but it is not an orphan ... or more precisely,\n> it is sometimes, depending on how fast you are to enter the second\n> commit command. This time-dependent behaviour is what I am talking\n> about.\n>\n> -Angelo\n> --\n"},{"id":"200515","messageId":"CAB9Jk9C4Y2LSzZW5Nkz=4f===8_gk4uAG4EKDxT17kUHu4VX1A@mail.gmail.com","threadId":"31710","inReplyTo":"A75F75C4DE3C47C7AF43D39355C873F7@PhilipOakley","subject":"Re: erratic behavior commit --allow-empty","fromName":"Angelo Borsotti","fromEmail":"angelo.borsotti@gmail.com","sentAt":"2012-10-04T07:07:47Z","receivedAt":"2012-10-04T07:07:47Z","isPatch":false,"sender":{"key":"angelo.borsotti@gmail.com","avatar":null},"body":"Hi Philip and all,\n\nlet me explain in full what is the problem that I tried to solve, and\nhow along the way I stumbled in something that seems to me a git bug\n(at least a documentation one).\n\nThere is an R&D team developing software using a workflow that is\nsimilar to the integerator-manager one (the one described by Scott\nChacon in chapter 5 of ProGit).\nDevelopers implement features using a local repository hosted on their\nworkstations, and when finished push on a server; integrators pull\nfrom it and put all the contributions together.\nSince integrators rebuild always the software after merging all\ncontribution, there is no need for the developers to push the\nbinaries. Not pushing them speeds up uploading.\nIn order to make life simpler and safer, scripts are provided to\nperform the pushing, pulling, etc. operations. So, most of the git\ncommands shown below are actually run from within scripts.\nThe development of each feature is done in a dedicated topic branch,\nand the commits done in it contain both the sources and the binaries\n(to allow to recover fully a previous snapshot when a later change\nbroke a previous one). When pushing, there are these needs:\n\n 1. push the sources only\n 2. push only the last commit of the topic branch (not the whole history)\n\nA note on point 2: the integrators are not interested in seeing all\nthe commits that developers did while implementing their features.\nHaving all the history makes their repositories cluttered.\n\nIn order to avoid pushing all the history, orphan branches are used to\nparallel the topic ones.\nWhen pushing, first a commit is done on the topic branch, and then a\nsnapshot is created in the parallel branch with the same files,\nbinaries removed. The general case is:\n\n source branch D'\n :\n topic branch A----B----C---D\n\nIn the picture, the developer made 4 commits, and pushed the sources\nof the last one, D.\nA D' is created on the source branch (the relationship with D is\nindicated with a dotted line).\nThe push script must cope with all the cases that may occur:\n\n 1. the general one (the one in the previous figure)\n 2. none of the commits in the topic branch with binaries (i.e. D\nand D' with the same tree)\n 3. push done immediately after the first commit (A)\n 4. a push done after another\n\nThe script:\n\n 1. creates the source branch if it does not exist yet (git\ncheckout --orphan),\n otherwise makes HEAD point to it\n 2. sets a .git/info/exclude file that excludes the binaries\n 3. removes the binaries from the index (git rm)\n 4. creates a commit on the source branch\n 5. pushes it\n 6. restores the HEAD and index as they were before\n\nThe operation that caused problems was nr. 4. In all the cases\nenlisted above, a git commit creates a brand new and unique commit\nbecause either it has a parent that is different from that of any\nother commit, or because its tree is different. All, except case nr 3\nwhen there are no binaries:\n\n source branch A'\n :\n topic branch A\n\nIn this case the parent is the same as that of A, i.e. none, and also\nthe tree is the same. In order to try to force the creation of a brand\nnew and unique commit even when the trees are the same --allow-empty\nhas been used, but this did not avail because git commit creates a\nbrand new one only when the seconds of the system clock have ticked\nbefore it.\n\nSome of you have suggested to create an A' that is not orphan in such\na case, which is a workaround, and some others to change the message\nin it, and this is another. I choose the latter because it allows to\nkeep the source branch orphan in all cases. So, there are workarounds,\nand the script has eventually been implemented and tested, but the\nunexpected, time-dependent behavior of git commit is there and someone\ncould stumble on it sooner or later.\n\n-Angelo\n"},{"id":"200504","messageId":"CABURp0pgE=J9yCa+nUa7J0MZ-O-6bUHrj58zLQZ9mToh6YcOFw@mail.gmail.com","threadId":"31710","inReplyTo":"CAB9Jk9C4Y2LSzZW5Nkz=4f===8_gk4uAG4EKDxT17kUHu4VX1A@mail.gmail.com","subject":"Re: erratic behavior commit --allow-empty","fromName":"Phil Hord","fromEmail":"phil.hord@gmail.com","sentAt":"2012-10-04T13:24:19Z","receivedAt":"2012-10-04T13:24:19Z","isPatch":false,"sender":{"key":"phil.hord@gmail.com","avatar":"https://avatars.githubusercontent.com/u/123908?v=4"},"body":"On Thu, Oct 4, 2012 at 3:07 AM, Angelo Borsotti\n wrote:\n...\n> The operation that caused problems was nr. 4. In all the cases\n> enlisted above, a git commit creates a brand new and unique commit\n> because either it has a parent that is different from that of any\n> other commit, or because its tree is different. All, except case nr 3\n> when there are no binaries:\n>\n> source branch A'\n> :\n> topic branch A\n>\n> In this case the parent is the same as that of A, i.e. none, and also\n> the tree is the same.\n\nAnd why is this a problem?\n\nIs there a process or person watching the server for a new commit?\n\nIs it not enough to notice that the pushed-to branch has a new HEAD?\n\nPhil\n"},{"id":"200534","messageId":"CAB9Jk9CDXE_Qgsm8e8EFHV-77W_bK9mu4xMyw_OzYTnn_XNb+A@mail.gmail.com","threadId":"31710","inReplyTo":"CABURp0pgE=J9yCa+nUa7J0MZ-O-6bUHrj58zLQZ9mToh6YcOFw@mail.gmail.com","subject":"Re: erratic behavior commit --allow-empty","fromName":"Angelo Borsotti","fromEmail":"angelo.borsotti@gmail.com","sentAt":"2012-10-04T19:00:38Z","receivedAt":"2012-10-04T19:00:38Z","isPatch":false,"sender":{"key":"angelo.borsotti@gmail.com","avatar":null},"body":"Hi Phil,\n\n\\>\n> And why is this a problem?\n>\n> Is there a process or person watching the server for a new commit?\n>\n> Is it not enough to notice that the pushed-to branch has a new HEAD?\n>\n\nYes, the developers use the git gui to see the graph of branches and commits.\nThe simpler and uniform it is, the better.\n\n-Angelo\n"},{"id":"200552","messageId":"20C3105FC8D94F749FAEB7444325B34A@PhilipOakley","threadId":"31710","inReplyTo":"CAB9Jk9C4Y2LSzZW5Nkz=4f===8_gk4uAG4EKDxT17kUHu4VX1A@mail.gmail.com","subject":"Re: erratic behavior commit --allow-empty","fromName":"Philip Oakley","fromEmail":"philipoakley@iee.org","sentAt":"2012-10-04T21:17:04Z","receivedAt":"2012-10-04T21:17:04Z","isPatch":false,"sender":{"key":"philipoakley@iee.email","avatar":"https://avatars.githubusercontent.com/u/914343?v=4"},"body":"From: \"Angelo Borsotti\" \nSent: Thursday, October 04, 2012 8:07 AM\n> Hi Philip and all,\n>\n> let me explain in full what is the problem that I tried to solve, and\n> how along the way I stumbled in something that seems to me a git bug\n> (at least a documentation one).\n>\n> There is an R&D team developing software using a workflow that is\n> similar to the integerator-manager one (the one described by Scott\n> Chacon in chapter 5 of ProGit).\n\nThis has the developers having a full copy/history of the integrators \nrelevant branches, so that when the pull of the developers branch occurs \nthere is a proper link to the integrators history.\n\n> Developers implement features using a local repository hosted on their\n> workstations, and when finished push on a server; integrators pull\n> from it and put all the contributions together.\n> Since integrators rebuild always the software after merging all\n> contribution, there is no need for the developers to push the\n> binaries. Not pushing them speeds up uploading.\n> In order to make life simpler and safer, scripts are provided to\n> perform the pushing, pulling, etc. operations. So, most of the git\n> commands shown below are actually run from within scripts.\n> The development of each feature is done in a dedicated topic branch,\n> and the commits done in it contain both the sources and the binaries\n> (to allow to recover fully a previous snapshot when a later change\n> broke a previous one). When pushing, there are these needs:\n>\n> 1. push the sources only\n> 2. push only the last commit of the topic branch (not the whole \n> history)\n>\n> A note on point 2: the integrators are not interested in seeing all\n> the commits that developers did while implementing their features.\n> Having all the history makes their repositories cluttered.\n>\n> In order to avoid pushing all the history, orphan branches are used to\n> parallel the topic ones.\n\nThere are other ways to create a branch which has all the developers \nfeature history removed, rather tha using an --orphan, which removes the \nintegrators history as well.\n\n> When pushing, first a commit is done on the topic branch, and then a\n> snapshot is created in the parallel branch with the same files,\n> binaries removed. The general case is:\n>\n> source branch D'\n> :\n> topic branch A----B----C---D\n>\n> In the picture, the developer made 4 commits, and pushed the sources\n> of the last one, D.\n> A D' is created on the source branch (the relationship with D is\n> indicated with a dotted line).\n\nThe disconnection of the D' source branch makes it sound like you have a \nsecond SCM system that you have to put stuff into, which is independent \nof the development teams git repos. I have this [hassle] at my \n$dayjob -one almost has to hide git from the powers-that-be.\n\n> The push script must cope with all the cases that may occur:\n>\n> 1. the general one (the one in the previous figure)\n> 2. none of the commits in the topic branch with binaries (i.e. D\n> and D' with the same tree)\n> 3. push done immediately after the first commit (A)\n> 4. a push done after another\n>\n> The script:\n>\n> 1. creates the source branch if it does not exist yet (git\n> checkout --orphan),\n> otherwise makes HEAD point to it\n> 2. sets a .git/info/exclude file that excludes the binaries\n> 3. removes the binaries from the index (git rm)\n> 4. creates a commit on the source branch\n> 5. pushes it\n> 6. restores the HEAD and index as they were before\n>\n> The operation that caused problems was nr. 4. In all the cases\n> enlisted above, a git commit creates a brand new and unique commit\n> because either it has a parent that is different from that of any\n> other commit, or because its tree is different. All, except case nr 3\n> when there are no binaries:\n>\n> source branch A'\n> :\n> topic branch A\n>\n> In this case the parent is the same as that of A, i.e. none, and also\n> the tree is the same.\nTrue.\n\n>In order to try to force the creation of a brand\n> new and unique commit even when the trees are the same --allow-empty\n> has been used, but this did not avail because\n\nIt was --orphan, --allow-empty (a common tree), the --root commit, and \nscripted with both branches using the same clock tick...\n\n> git commit creates a\n> brand new one only when the seconds of the system clock have ticked\n> before it.\n>\n> Some of you have suggested to create an A' that is not orphan in such\n> a case, which is a workaround, and some others to change the message\n> in it, and this is another. I choose the latter\n\nA reasonable solution. You can also create a sentinel (--root) commit \nfor any time that you need to create the source branch, just so it (the \nreal source code commit) has a different parent when on source branch to \nthat on the binaries branch.\n\nHowever, personally, I'd have wanted the source branch to show real \nhistory and actually match with the integrators repo history, but no \ndoubt local conditions & politics have their influence.\n\n> because it allows to\n> keep the source branch orphan in all cases. So, there are workarounds,\n> and the script has eventually been implemented and tested, but the\n> unexpected, time-dependent behavior of git commit is there and someone\n> could stumble on it sooner or later.\n>\n> -Angelo\n"},{"id":"200561","messageId":"CAB9Jk9CiDNNBM9V-VvwCK6q-N0JNwEbf4vJj0ffT82iLnrUwog@mail.gmail.com","threadId":"31710","inReplyTo":"20C3105FC8D94F749FAEB7444325B34A@PhilipOakley","subject":"Re: erratic behavior commit --allow-empty","fromName":"Angelo Borsotti","fromEmail":"angelo.borsotti@gmail.com","sentAt":"2012-10-04T22:09:39Z","receivedAt":"2012-10-04T22:09:39Z","isPatch":false,"sender":{"key":"angelo.borsotti@gmail.com","avatar":null},"body":"Hi Philip,\n\n> This has the developers having a full copy/history of the integrators\n> relevant branches, so that when the pull of the developers branch occurs\n> there is a proper link to the integrators history.\n\nTrue.\n>\n> There are other ways to create a branch which has all the developers feature\n> history removed, rather tha using an --orphan, which removes the integrators\n> history as well.\n\nThe topic branches are populated only by the developers. The integrators merge\nall the topic branches into branches dedicated to the integration. In\ncase of need,\nthe developers can pull these (with all the integrators' history).\n\n>\n> The disconnection of the D' source branch makes it sound like you have a\n> second SCM system that you have to put stuff into, which is independent of\n> the development teams git repos. I have this [hassle] at my $dayjob -one\n> almost has to hide git from the powers-that-be.\n\nWell, there is another way to see this: think to a distributed SCM in\nwhich there are some parts of the contents that are shared and some\nthat are not.\nThe technique to use disconnected branches is only a way of implementing this.\nIf, say, git push had an option to filter out the binaries there would\nbe no need for disconnected branches.\n\n>\n> A reasonable solution. You can also create a sentinel (--root) commit for\n> any time that you need to create the source branch, just so it (the real\n> source code commit) has a different parent when on source branch to that on\n> the binaries branch.\n\nDo you mean I could create an empty root commit to be used as parent for the\nreal source commit? Or that there is some --root option to be used?\n\n-Angelo\n"},{"id":"200571","messageId":"74938A94D25C4F1887F30C281A02B35F@PhilipOakley","threadId":"31710","inReplyTo":"CAB9Jk9CiDNNBM9V-VvwCK6q-N0JNwEbf4vJj0ffT82iLnrUwog@mail.gmail.com","subject":"Re: erratic behavior commit --allow-empty","fromName":"Philip Oakley","fromEmail":"philipoakley@iee.org","sentAt":"2012-10-04T22:42:49Z","receivedAt":"2012-10-04T22:42:49Z","isPatch":false,"sender":{"key":"philipoakley@iee.email","avatar":"https://avatars.githubusercontent.com/u/914343?v=4"},"body":"From: \"Angelo Borsotti\" \nSent: Thursday, October 04, 2012 11:09 PM\n\n>>\n>> A reasonable solution. You can also create a sentinel (--root) commit\n>> for\n>> any time that you need to create the source branch, just so it (the\n>> real\n>> source code commit) has a different parent when on source branch to\n>> that on\n>> the binaries branch.\n>\n> Do you mean I could create an empty root commit to be used as parent\n> for the\n> real source commit? Or that there is some --root option to be used?\n\nI was using \"--root\" in a colloquial way. It is used in some other\ncommands when the very first commit is to be included in its operation.\n\nAt the point where you do the 'git checkout --orphan \n' you could have separate start points ready for the source\nbranch and the binaries branch, and immediately do a 'git commit' to\ncreate the unique sentinel commit before you re-checkout the developers\nlatest and greatest (with --force), and then do your commits on the \nsource branch as before.\n\nAnother technique could be to simply switch to the sources branch, and \nthen use a 'git clean -x' with an updated .gitignore ('reset' the file \nfrom the source branch)[or use the exclude file] to remove those now \nignored binaries, before doing the commit.\n\nPhilip\n"},{"id":"200572","messageId":"CAB9Jk9Br7urkZnQZtZ-2nc=BJ221LQQRVP684OW4OR6Adf=VVg@mail.gmail.com","threadId":"31710","inReplyTo":"74938A94D25C4F1887F30C281A02B35F@PhilipOakley","subject":"Re: erratic behavior commit --allow-empty","fromName":"Angelo Borsotti","fromEmail":"angelo.borsotti@gmail.com","sentAt":"2012-10-04T23:10:21Z","receivedAt":"2012-10-04T23:10:21Z","isPatch":false,"sender":{"key":"angelo.borsotti@gmail.com","avatar":null},"body":"Hi Phil,\n\n>\n> Another technique could be to simply switch to the sources branch, and then\n> use a 'git clean -x' with an updated .gitignore ('reset' the file from the\n> source branch)[or use the exclude file] to remove those now ignored\n> binaries, before doing the commit.\n>\n\nActually, the first time I make a git checkout --orphan to create the\nbranch, and the following times a git symbolic-ref HEAD to switch to\nit. Then I set a proper exclude file and do a list=`git ls-files -c -i\n--exclude-standard` to get the paths of the files to remove from the\nindex. Then I remove them with git rm --cached. Then all is ready to\nmake a git commit. At this point I restore the HEAD and the index as\nthey were before.\nThis allows me to keep the work tree pristine, no files removed or\nloaded in it from the repo,\nwhich makes the script quite fast.\n\n-Angelo\n"},{"id":"200611","messageId":"loom.20121004T190952-797@post.gmane.org","threadId":"31710","inReplyTo":"CAB9Jk9D5c-7QKkUFtur4rxBfiaPFzGaMi-+m=Owje_Aaoc6XJQ@mail.gmail.com","subject":"Re: erratic behavior commit --allow-empty","fromName":"Lars Noschinski","fromEmail":"lars@public.noschinski.de","sentAt":"2012-10-05T08:15:12Z","receivedAt":"2012-10-05T08:15:12Z","isPatch":false,"sender":{"key":"lars@public.noschinski.de","avatar":"https://gravatar.com/avatar/ca62bd8b265f2e26c89d39a4bfe7e390bfa6b16d6400e186e222d1c2382c66f2?d=mp&s=160"},"body":"Angelo Borsotti gmail.com> writes:\n> take a git commit without --allow-empty: if the trees are equal, it\n> creates no commit,\n> and if the trees are different it creates one.\n> Take then a git commit --allow-empty: if the trees are equal it may\n> create a commit or\n> not depending on the parent, message, author and date; if the trees\n> are different it\n> creates a commit.\n> So, the statement does not apply to commits in general.\n\nIt does (as already shown to you). The ID of a commit object depends on\nthe author, the time, the tree, and the commit message (did I forget\nsomething?). If all these are equal, no new physical object will be\ncreated.\n\nIndependent of this: If you are on a branch \"foo\" pointing to a commit A\nand successfully do a commit (with --allow-empty or not), \"foo\" will\nafterwards point to a commit B different from A. So, a successful\n\"git commit (--allow-empty)\" will always add a commit to the branch\nyou are on.\n\n -- Lars.\n"},{"id":"206612","messageId":"alpine.LNX.2.01.1301121927350.15558@nerf07.vanv.qr","threadId":"31710","inReplyTo":"506AA51E.9010209@viscovery.net","subject":"Re: erratic behavior commit --allow-empty","fromName":"Jan Engelhardt","fromEmail":"jengelh@inai.de","sentAt":"2013-01-12T18:30:36Z","receivedAt":"2013-01-12T18:30:36Z","isPatch":false,"sender":{"key":"jengelh@inai.de","avatar":"https://avatars.githubusercontent.com/u/8861948?v=4"},"body":"\nOn Tuesday 2012-10-02 10:26, Johannes Sixt wrote:\n>\n>Note that git commit -m A --allow-empty *DID* create a commit. Only, that\n>it received the same name (SHA1) as the commit you created before it\n>because it had the exact same contents (files, parents, author, committer,\n>and timestamps). Obviously, your script was executed sufficiently fast\n>that the two commits happend in the same second.\n\nWhat about introducing nanosecond-granular timestamps into Git?\n"},{"id":"207047","messageId":"kd669a$q15$1@ger.gmane.org","threadId":"31710","inReplyTo":"alpine.LNX.2.01.1301121927350.15558@nerf07.vanv.qr","subject":"Re: erratic behavior commit --allow-empty","fromName":"Joachim Schmitz","fromEmail":"jojo@schmitz-digital.de","sentAt":"2013-01-16T12:26:15Z","receivedAt":"2013-01-16T12:26:15Z","isPatch":false,"sender":{"key":"jojo@schmitz-digital.de","avatar":"https://avatars.githubusercontent.com/u/1786669?v=4"},"body":"Jan Engelhardt wrote:\n> On Tuesday 2012-10-02 10:26, Johannes Sixt wrote:\n>>\n>> Note that git commit -m A --allow-empty *DID* create a commit. Only,\n>> that it received the same name (SHA1) as the commit you created\n>> before it because it had the exact same contents (files, parents,\n>> author, committer, and timestamps). Obviously, your script was\n>> executed sufficiently fast that the two commits happend in the same\n>> second.\n>\n> What about introducing nanosecond-granular timestamps into Git?\n\nNot every platform (supported by git) does have a nanosecond clock \nresolution\n\nBye, Jojo \n"}]}