Sitaram Chamarty <sitaramc@xxxxxxxxx> writes: > Let me explain where I'm coming from: this is very often needed when you > maintain customer specific branches, and the workflows in both your > posts in this thread so far are too complex for, err, me <sheepish grin> > :-) > > Would it not be easier to do something like this? (I suck at 2-d > drawing, even line... but this should still be understandable) What you drew is a detailed discussion on a technique to use to group together common part and customer specific part, and I think it is Ok to do whatever you feel comfortable with. It is essentially the same as my "in real life, 'git diff >P.diff' is not how I would do this" example, just going into more detail on what you would do to sift 'common only' vs 'specific to work branch' apart, and I think what you are doing is sane. But if you wrote it as a draft of a document to explain how-to to new people, I think you need to clarify a few things. It is unclear in your description how the "common" branch progressed in the whole process, and how the resulting history looks. I can guess that you meant commits marked with alphabet letters are of common kind and numbers are of work kind, but you do not want to force readers to guess. It also is not quite clear that you are using a temporary branch in addition to common and work, and where in your sequence you are doing "git checkout" to switch branches. -- 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
