On Wed, 25 Nov 2009, Mike Jarmy wrote: > Junio C Hamano wrote: > > I take it to mean that even though v[345] have diverged, the area that the > > particular change you have in mind has to touch haven't changed since they > > forked. > > Correct. Sometimes, there might be unrelated changes to a given file > or files, in which case conflict resolution will be done manually. > But generally speaking, bugfixes will tend to go on quite cleanly. > > > Instead, you can fork such a topic from the latest common. > > > > o--o--o--o--o--o--o--o v4 > > / > > --o--x--x--x--x--x--x--x v3 > > \ > > Y---Y > > your change(s) > > > > and merging this to v3 and v4 will have the desired effect. > > > > o--o--o--o--o--o--o--o---------M v4 > > / / > > --o--x--x--x--x--x--x--x---M v3 / > > \ / / > > Y---Y----------------.-----. > > your change(s) > > > > The merges will incorporate this particular change alone without dragging > > anything else. When you merge it to v4, none of the unrelated 'x' will be > > merged into it. > > That sounds a whole lot like what I need. > > Right now I'm thinking that the right approach is that once we have > released v3, and started working on v4 heavily, we will probably not > want to check any commits directly into v3. Bugfixes will have their > own branch. If there is a whole new project or whatever being done > on top of v3, it will have its own branch as well. > > So once v3 is in beta or whatever and we declare a code freeze, we > could have a rule that all commits must be merge-commits coming from > dedicated branches with descriptive, intelligible names. For each > dedicated branch, some thought will have to be given as to just where > off of v3 to branch it from (not just carelessly off the latest tip). > Meanwhile, new development will continue on v4, with lots of commits > going right into the branch (or into v4 sub-branches with occasional > merge-commits into v4). It's worth noting that you don't have to have any general visibility to the dedicated branch. If you look at Junio's graph, there are only two branches marked: v3 and v4. The stuff in the bottom line only appears as the second parent in the merge commits. Git's data model doesn't require a branch for a commit to be "on" like many other VCSes, so it's perfectly reasonable for a developer to make a temporary branch, create the fix in some private repository, merge it to each applicable official branch, and then discard the temporary branch. (The temporary branch is only needed at all so that the developer has some way to refer to the fix while merging it, and the name only matters in that humans will see it in the merge commit message.) -Daniel *This .sig left intentionally blank*