On 2009-01-14, skillzero@xxxxxxxxx <skillzero@xxxxxxxxx> wrote: > I guess maybe a better question is how do people normally handle > situations like mine where I did some work on branch X and I later > realize I need only a portion of that work on branch Y? I'm not sure > how I can change my workflow to completely eliminate these situations. > For example, I often start a branch to add a new feature and I end up > fixing bug A on that branch. Then other people on my team decide they > need the fix for bug A immediately and can't wait for me to finish my > feature branch and do a full merge. > > Is there some way I can change my workflow such that I can fix bug A > (maybe on a separate branch?) and somehow apply it to both both > branches in a way that won't result in duplicate commits? > > Does this kind of thing ever happen with the Linux kernel or git > itself: somebody does a fix as part of their topic branch and the > Linux kernel or git master wants that particular fix now, but is not > ready for the full topic branch? Would they just suggest the fix be > separated into its own topic branch and that merged? If so, how would > that new topic branch merge into the original topic branch without > resulting in a duplicate commit when it's later merged into master? If I understand you right, you're talking about a situation where a particular change is in two different branches, but the SHA is different. And yet, in your scenario, both of these branches somehow get merged into the final branch. In other words, a DAG of branches merging itself has a merge, if that makes sense :-) You may need to think about how commits flow from branch to branch, and what branches are private, and therefore can be rebased or change history, and what are public, and how often and when the private ones rebase off of the public ones. -- 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
