On Wed, Jul 15, 2009 at 12:31:00PM -0700, Junio C Hamano wrote: > "Michael S. Tsirkin" <mst@xxxxxxxxxx> writes: > > > So, let me summarize the issues: > > - if the tree is pushed into while files are being actively read > > (e.g. built from), the build will get an inconsistent state > > - even worse if one of the files is open for editing or is being written > > into: the file will get corrupted > > - if there are uncommitted changes in the tree, the push is denied > > > > Are there others? > > - If you choose to detach-on-push, the user who _thought_ was advancing > the history of a branch using the work tree will get very confusing > results. The branch will be advanced by the push, and the work tree > user is required to notice the situation, later at some point merging > the work done in the work tree that went to the detached HEAD state. I never use detach on push. Let's remove that option for now? > - What happens if the automerge gets conflict? push is denied, unless you push with -f, then I think you get the new head. Note that merge is not the right word here: only fast forward is done I think. Right, Dscho? > Having said that, I think it is a _wrong_ approach to try summarizing the > issues along these lines, without stating the most fundamental restriction. Sure. I am just trying to figure out all the details before I try to write this up. The coordination issue is obviously the main thing, I was trying to enumerate the less obvious ones. > If the push-from-sideways is done without any coordination between the > person pushes and the person who uses the work tree, _any_ solution that > modifies the work tree behind the back of that work-tree person will not > work without surprising him, so listing the possible surprises is > pointless. > > On the other hand, all of the above "issues" (including yours) will become > only implementation details of a workflow when there is a coordination > between the pusher and the work-tree person. In the most trivial case, > both are you, and the repository with the work tree is your private > working area. > > So I would suggest stressing the need for this coordination before > starting to list the "issues". > > Be it "detach" or "automerge", the workflow helped with the patch is > merely a deviation of the mothership-satellite configuration (look for > "satellite" in the FAQ) where you push from satellite to mothership (each > has its own work tree) to achieve logically what you would want to perform > with a pull in the other direction, that is: > > satellite$ git push mothership:project master:refs/remotes/satellite/master > satellite$ ssh mothership 'cd project && git merge remotes/satellite/master' > > The necessary "coordination" between the two repositories is that the last > step, "merge what was pushed", must be done when the work tree checked out > in the mothership repository is in a state that is suitable for performing > the merge, e.g. no extra change to the index that is unrelated to the > merge, no local change that interferes with the merge, etc. > > The auto-merge-upon-push patch by Dscho, however, places a further > restriction on top of the stock satellite-mothership configuration, > exactly because it is automated. In an unautomated workflow, you can > afford to choose _when_ to merge, independent from when to push: > > satellite$ git push mothership:project master:refs/remotes/satellite/master > satellite$ ssh mothership > mothership$ cd project > ... work further to finish off what you did on the mothership ... > mothership$ git commit > mothership$ git merge remotes/satellite/master > > Typically, when you are done (for the day, for example) on satellite, you > push it out to the mothership, even though the mothership repository's > work tree may have independent local changes (aka WIP) you have left when > you last worked there. After switching to work in the mothership, you > can continue working on the WIP to finish it before merging what you did > on the satellite the previous day. > > The automated way will trade this flexibility off with convenience (you do > not have to have the interactive session on the mothership only to perform > the merge), so you will be required to leave the mothership work tree and > the index in a good shape any time you might want to push into it from the > satellite. It is a small price to pay, and depending on the situation > (the most obvious is when you do not even have an interactive shell access > to the mothership) you may not even have that flexibility to begin with, > in which case there is no downside. Thanks for the explanation. -- 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