Hi, On Wed, 15 Jul 2009, Michael S. Tsirkin wrote: > 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? I do not use it. But I added it upon explicit request. > > - 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? Lemme look at that patch (it is pretty old by now...). Actually, my patch has nothing to do with allowing only fast-forwards unless the push is forced. The documentation states that a read-tree -u -m HEAD is performed. This can fail when a file is not up-to-date. As far as I can tell, read-tree -u -m HEAD refuses to update the index in such a situation. So if there are files to be updated by the push which are dirty, the push will update the ref as requested, nevertheless error out, the index will be untouched, and so will be the working directory (unless I fscked up the patch, which is quite possible, as I was writing this just to get a quieter mailing list again). One thing I got right, though, was the commit message. > > 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. Happily enough, it is the duty of the local guy to actually set the config variable. And to allow the other guy (who might be one and the same guy a la "I am schizophrenic and me too") is also the privilege of the local guy. Ciao, Dscho -- 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