On Fri, Jun 27, 2008 at 4:14 PM, Junio C Hamano <gitster@xxxxxxxxx> wrote: > "Robert Anderson" <rwa000@xxxxxxxxx> writes: > >> There are good reasons for desiring a workflow that does not routinely >> change history as part of the usual workflow. Maybe there are clones >> of your repo. Maybe as part of your workflow discipline you do not >> want HEAD states that cannot be pushed to public, because you don't >> want to manually keep track of when it is ok and when it is not ok to >> push HEAD to public, since git cannot tell you this. > > Surely you can arrange that. You keep track of what you pushed out, and > you refrain from rebasing beyond that point. First, the constraint of achieving this workflow when there are clones of the repo in question removes any need for additional rationales. That being said... In the existing model which is being suggested as a way to get the desired workflow, there are two distinct classes of commits: commits that are "for real", and commits that are "temporary", that are being used as some kind of workspace for orthogonalizing a set of changes, which will eventually be replaced by "for real" commits. Yet git has no metadata to distinguish these two types of commits. When only "for real" commits exist, I can push HEAD. When "temporary" commits exist, I cannot, or insidious problems will ensue. This metadata concerning "for real" or "temporary" commits is only maintained manually in the developer's head. But, this is the sort of thing that computers are for, and should not be the burden of the developer to maintain this information in his mental cache, especially when the price of making an error can be quite high. It would be very easy to forget that you intended to do more work on your last N commits, and push HEAD because somebody asks you to make sure you've pushed your latest work. Your tools should prevent this kind of scenario. Git cannot, because it doesn't know what you intend when you "commit" because two different ideas are being conflated with "commit" in this model. In my proposed model, there is a clear distinction, kept track of by git, not the developer, between changes which are in the "temporary workspace" which is still being worked on, and changes which are "for real", that can be shared, either through a push to a public repo or if there are clones of my repo. They become "for real" when they are committed. That's the purpose of a "commit" in this workflow. To bless a change as ready for viewing by others, even if you do not want to make it available yet (by a push to a public repo). I can walk away from a working tree for six months, come back, and there can be no confusion about which changes were "temporary" and possibly in need of revision, and which changes are blessed as ready for public consumption. If I come back to a branch on which there are several commits which have not been pushed yet, how do I know which are "temporary" and which are "for real" commits? I cannot. It is impossible. The information is not there. But, all of this is moot when you consider the simple case of a repo which has been cloned, on which you'd like to make partial commits, and test the committed state before doing so. Thanks, Bob -- 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
