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 > | - - -
