On Mon, Feb 9, 2009 at 12:06 AM, Theodore Tso <tytso@xxxxxxx> wrote: > On Sun, Feb 08, 2009 at 08:47:26PM -0500, Jay Soffian wrote: >> >> [receive] >> prefix = refs/remotes/incoming >> >> Then a push to refs/heads/master was automatically stored as >> refs/remotes/incoming/master instead. > > What happens when the next person pushes to the same remote repo, and > their refs/heads/master push is not a fast-forward merge of the > current refs/remotes/incoming/master? > > Do you lose the first user's push at that point? Or do you refuse the > push? The idea initially was to give a place to store the push head for the checked-out branch, but that isn't what HEAD points to. But it seemed confusing to do this for just the checked-out branch, so I was playing with having all incoming pushes go into their own namespace, hence the prefix. Also, the use case I have in mind here is an individual with a workstation and a laptop, and the repository on the workstation and its clone on the laptop are both non-bare. There are not multiple individuals pushing to the non-bare repo. Someone please correct me if I'm wrong, but it is my impression that these are the users that have motivated the receive.denyCurrentBranch option (and its eventual default changing to refuse) in the first place. In that case, the work-flow is typically: server$ mkdir repo && cd repo && git init server$ ... add, commit, add, commit ... [...time passes...] laptop$ git clone ssh://server/~/repo laptop$ ... add, commit, add, commit ... laptop$ git push laptop$ ssh server server$ cd repo server$ git merge incoming/master server$ git branch -dr incoming/master But, to answer your question, the non-fast-forward push is rejected, unless the user forces it, unless receive.denyNonFastForwards prevents the force. j. -- 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
