Theodore Tso <tytso@xxxxxxx> writes: > With git.git, we are essentially throwing away development history > while it is in 'pu', but once a commit graduates to 'next', we do keep > the development history forever. The downside to this is that > development 'crud' can build up in next; even if all substantive > commits in 'next' end up graduating to 'master', there will still be > lots of merge commits that will only be in 'next'. > > I have an emotional bias which tends to treat that excess history as > toxic waste to be avoided at all costs, but that's probably because > when you have a git tree as huge as the kernel, life is easier if the > history is kept as clean as possible. > > Which I suppose is easy enough to do in the git.git model; if you > throw away the 'next' branch and then rewind it so it is forked off of > 'master' all of that history essentially gets flushed. You can view 'next' as if it is sort of -mm. Following 'master' is like following Linus tree, whose development is without those numerous 'merge improvements again' merges into 'next'. > The downside > is that people maintaining topics branches which were forked against > the old 'next' will need to do some grotty work to rebase their > patches, so any attempt to rewind next would probably require the > central maintainer to give plenty of notice, and then on the flag day, > save 'next' as 'old-next' before rewinding to allow the other > developers to more easily rebase any private branches they might have. An alternative is to give an easier access to the tips of individual topic branch head, at least to the ones that have been merged to 'next' as they will never be rewound once they are in 'next', and encourage people to fork off of them, instead of 'next' directly. Then 'next' will be more like 'pu'. > Hmm, interesting. A lot of this is quite subtle, or at least the > impacts of different choices in the git workflow really didn't become > obvious to me until I started trying I stepped into the central > maintainer role for a project using git! Very true. - 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
