The man page for git-config says about "push.default = matching": "It is not appropriate for pushing into a repository shared by multiple users, since locally stalled branches will attempt a non-fast forward push if other users updated the branch."
This is actually the default for git versions <2.0, and if I understand the warning correctly, it will not guarantee avoiding the race conditions we're trying to avoid by pushing in order, even if it did push in order (which I can't find any documentation indicating that it does, or that it is guaranteed to). -- Christopher L Tubbs II http://gravatar.com/ctubbsii On Thu, Feb 20, 2014 at 7:50 PM, Keith Turner <[email protected]> wrote: > On Thu, Feb 20, 2014 at 7:12 PM, Mike Drob <[email protected]> wrote: > >> I recommend "git push apache : -n" where 'apache' is the name I have given >> > > Will this push the branches in the correct order? > > >> the asf remote and ':' indicates to push matching branches, and -n is dry >> run. >> >> >> On Thu, Feb 20, 2014 at 6:41 PM, Christopher <[email protected]> wrote: >> >> > Definitely avoid git push --all. I don't think the order is well >> > defined. But, I do agree that a good workflow is to do all the merges >> > in order, then go back and do all the pushes in order. >> > >> > -- >> > Christopher L Tubbs II >> > http://gravatar.com/ctubbsii >> > >> > >> > On Thu, Feb 20, 2014 at 5:32 PM, Keith Turner <[email protected]> wrote: >> > > On Thu, Feb 20, 2014 at 5:05 PM, Mike Drob <[email protected]> >> wrote: >> > > >> > >> I think the difference in workflow is that some committers push and >> > merge >> > >> branches one at a time, while other committers merge everything >> locally >> > and >> > >> then push all at once. I strongly prefer the second approach. >> > >> >> > > >> > > The second approach is best. Still need to be careful. AFAICT git >> push >> > > -all is not an atomic operation across all branches. Need to push the >> > > oldest branch first. Will 'git push -all' do this? If not, then >> should >> > > push branches in correct order. >> > > >> > > >> > > >> > > >> > > >> > >> >> > >> >> > >> On Thu, Feb 20, 2014 at 4:54 PM, Christopher <[email protected]> >> > wrote: >> > >> >> > >> > I agree you definitely don't want to be skipping specific commits >> when >> > >> > merging... but that's not what Mike nor I suggested. Rather, our >> > >> > suggestion was that you can do a regular merge of any parentage, >> > >> > before doing a -sours merge of your commit. >> > >> > >> > >> > To John's point, this is essentially what the previous committer >> > >> > should have done (in this case, me) before your commit arrived. >> > >> > However, there is a race condition here... and the previous >> committer >> > >> > may be in the process of doing this when you come on the scene. So, >> > >> > you should always be extra careful about merging.... especially with >> > >> > -sours. >> > >> > >> > >> > -- >> > >> > Christopher L Tubbs II >> > >> > http://gravatar.com/ctubbsii >> > >> > >> > >> > >> > >> > On Wed, Feb 19, 2014 at 4:21 PM, Bill Havanki < >> > [email protected] >> > >> > >> > >> > wrote: >> > >> > > John's strategy can certainly work [1]. I don't think it's a good >> > idea >> > >> to >> > >> > > make it a typical part of workflow, though. It's complicated, and >> I >> > >> don't >> > >> > > want to have to look back through the history before each merge (3 >> > of >> > >> > them >> > >> > > for a 1.4 change) for commits to skip. >> > >> > > >> > >> > > Also, skipped commits are still left behind, unmergeable, >> requiring >> > a >> > >> > > cherry-pick to be rescued later. So, to be safe, you'd have to >> wait >> > to >> > >> > find >> > >> > > out what to do with them before skipping. >> > >> > > >> > >> > > I don't know a better tactic, but I have the feeling it must >> involve >> > >> less >> > >> > > branches or less merging. >> > >> > > >> > >> > > [1] >> > >> > > >> > >> > >> > >> >> > >> http://stackoverflow.com/questions/727994/git-skipping-specific-commits-when-merging >> > >> > > >> > >> > > >> > >> > > On Wed, Feb 19, 2014 at 3:20 PM, Christopher <[email protected] >> > >> > >> > wrote: >> > >> > > >> > >> > >> As Mike pointed out, you can't do it if there is unmerged >> parents. >> > You >> > >> > >> have to merge the parents first, then your commit. If there's any >> > >> > >> commits which are children of the commit you want to merge with >> > >> > >> -sours, you can single out your specific commit by referencing >> the >> > >> > >> sha1 in the merge instead of the branch name. That will leave the >> > >> > >> children unmerged, still, but will isolate your -sours to just >> that >> > >> > >> commit. Then you can merge the remaining children in a separate >> > merge. >> > >> > >> >> > >> > >> -- >> > >> > >> Christopher L Tubbs II >> > >> > >> http://gravatar.com/ctubbsii >> > >> > >> >> > >> > >> >> > >> > >> On Wed, Feb 19, 2014 at 3:03 PM, Bill Havanki < >> > >> > [email protected]> >> > >> > >> wrote: >> > >> > >> > Popping this out of JIRA since I am changing the subject >> > somewhat. >> > >> > >> > >> > >> > >> > Christopher (or anyone, really): Can you give me an example of >> > >> doing a >> > >> > >> > merge with -sours but only with specific commits, as >> > recommended? It >> > >> > >> makes >> > >> > >> > sense that this is safer vs. sweeping in HEAD. Just trying to >> > refine >> > >> > my >> > >> > >> > workflow. Thanks! >> > >> > >> > >> > >> > >> > Bill >> > >> > >> > >> > >> > >> > ---------- Forwarded message ---------- >> > >> > >> > From: Christopher Tubbs (JIRA) <[email protected]> >> > >> > >> > Date: Wed, Feb 19, 2014 at 2:36 PM >> > >> > >> > Subject: [jira] [Commented] (ACCUMULO-1961) Fix trivial >> > >> > compiler/javadoc >> > >> > >> > warnings >> > >> > >> > To: [email protected] >> > >> > >> > >> > >> > >> > [ >> > >> > >> > >> > >> > >> >> > >> > >> > >> >> > >> https://issues.apache.org/jira/browse/ACCUMULO-1961?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13905940#comment-13905940 >> > >> > >> ] >> > >> > >> > >> > >> > >> > Christopher Tubbs commented on ACCUMULO-1961: >> > >> > >> > --------------------------------------------- >> > >> > >> > >> > >> > >> > It looks like you are right. Be careful about -sours. You >> should >> > >> > probably >> > >> > >> > only use that with specific commits, not the HEAD of the >> branch, >> > >> which >> > >> > >> > could reference multiple commits. >> > >> > >> > >> > >> > >> > Don't worry about fixing it. I'll redo. There's some other >> > javadoc >> > >> > >> > errors/warnings and other trivial warnings in master that need >> > to be >> > >> > >> fixed >> > >> > >> > anyway. >> > >> > >> >> > >> > > >> > >> > > >> > >> > > >> > >> > > -- >> > >> > > | - - - >> > >> > > | Bill Havanki >> > >> > > | Solutions Architect, Cloudera Government Solutions >> > >> > > | - - - >> > >> > >> > >> >> > >>
