On Wed, Oct 3, 2012 at 9:35 AM, Angelo Borsotti <angelo.borsotti@xxxxxxxxx> wrote: > Hi Phil > >> >> 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 true only if the root commit also has binaries. Otherwise it is fine to push a branch with the common ancestor. Suppose A does not have binaries but B and C do. A---B---C Now we need to make a new branch ending at C' which has no binaries: A---B---C \ ---B'---C' A already has no binaries, so we did not need to make an A'. Now we can push C' to the server and no binaries will be pushed. That is because the server will receive only these commits: A---B'---C' > 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. Every commit is time-dependent. You tried to make a _unique_ empty commit, and this is where you ran into trouble. I think your uniqueness constraint is overkill. >> 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). You need not be concerned with the time on the commit, nor the uniqueness of the SHA1. >> 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. > >> >> 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. Doesn't this force git always to push new commits even though the contents match commits already on the server? >> 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. It seems to me that you are creating unnecessary work for the server and for your scripts. But perhaps I do not fully understand your use case. > 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. You may suggest improvements to the documentation. But be careful to understand the existing documentation completely before you do. Thanks for helping. Phil -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html