Re: erratic behavior commit --allow-empty

From: Angelo Borsotti <angelo.borsotti@gmail.com>
Date: Oct 3, 2012, 13:35 UTC
Message-ID: <CAB9Jk9DmFQcgd2jT4c1eMx91mikchVcKfNVLsmfjxaZL_G3vTQ@mail.gmail.com>
In-Reply-To: <CABURp0oHez6j8+FPG8Zm52TGVyC1XwWhE55TBDrXRGFrW6kWww@mail.gmail.com>

Hi Phil

Show 13 quoted lines

>
> I think what you are missing here is that the script does _not_ have
> to take care for this special case.  The script can do the same thing
> it does for all the other cases and it will work just fine.  This is
> because your goal, as I understand it, is this:
>
> A. Take this branch,
> B. Copy it but remove the binaries,
> C. Push it to the remote (with no binaries)
>
> If the branch has no binaries to begin with, then B is a no-op.  Your
> insistence that the new commits get unique SHA1's is unnecessary and
> is what is causing your trouble.

Suppose the branch has binaries. Then the only way to avoid to push them is to create an orphan branch (one that has no parents), otherwise git push will upload also the parent with its binaries. This is why there is a need to make the script perform different actions depending on the presence of the binaries. In the attempt to make the script handle both cases in a simple way I tried to make an empty commit, and discovered the time-dependent behavior of it.

Show 7 quoted lines

>
> Consider this analogous operation:
>
> A. Take this file,
> B. Remove every line that does not contain foo,
> C. Cat the result to the console (with only foo lines)
>

This example differs from the commit one in that the user has to cope with data that s/he can fully control (the contents of files), while in the other s/he has to cope with the passing of time, which s/he cannot control. So, taking the files I can predict the result, but taking the commits, I cannot because I do not know exactly when they will actually be run. Time is a sort of independent variable that I know only approximately (or very approximately when the commands are embedded in scripts).

>
> It seems to those more familiar with git that you are saying that this
> is "the problem", that the operation did not work because the results
> are not unique each time.

Exactly.

Show 8 quoted lines

>
> But if you ignore the SHA1 of the commits and just rely on the branch
> names, I think you will be happier.  This is because two branches can
> refer to the same SHA1 commit without causing any problem.  You may
> find that sometimes when you push there is no update applied to the
> server.  But this is not a mistake.  It is simply that the server
> already has the same contents as you are pushing, even though your
> local branch name is different than it was before.

Actually I ignore the SHA1 of the commits, and rely on the branch names I have topic branches and /src/topic branches. Developers push when they have something new. Of course the scripts must take care of when they are called and there is nothing to push, but that is not a big problem. I eventually found a workaround, which is to change the commit message, forcing then git commit to create a brand new commit.

> I think when you say "orphan" you mean it has a different SHA1 than
> any other commit.  But this is not what "orphan" means.

No, I mean that it has no parents.

Actually, in the special case in which there are no binaries, I could create a branch that points to the same commit as the branch that it is mirroring, and push it. However, this has two disadvantages: 1. that it will not be an orphan while in the more general case it is, and 2, that the history of commits will be pushed to the remote server, while in the general case (with an orphan) it will not. I preferred to have a unique branch topology so as to make the picture as simple as possible for the developers.

Note that eventually I solved the problem with a tweak. I still believe that the git commit command does not behave properly, and that changing nothing (implementation or documentation) leaves a drifting mine on which someone (or even myself) will stumble sooner or later. I am spending time to write all this because I care for git and I would really see it improving over time removing weak spots, and believe that you do the same.

-Angelo

>
> Phil