Agreed! And, if you follow the second approach, you can cope no matter what. If you follow the first approach, you can get entangled. Caveat trudor [1].
[1] http://translate.google.com/#la/en/trudo 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. > > > 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 > > > | - - - > > > -- | - - - | Bill Havanki | Solutions Architect, Cloudera Government Solutions | - - -
