* Junio C Hamano <gitster@xxxxxxxxx> [091217 23:44]: [order of replies changed for the sake of answers] > On the other hand, a branch that will be rebased to keep up with others is > by definition private, and I don't see a reason to mark with "-s ours" to > cauterize history of an unrelated side branch that tried to do something > similar to what the branch is trying to achieve in that setting. You can > instead ignore such a side branch and not merge with it. So I don't know > how a sane history you are going to rebase ends up containing a "-s ours" > merge to begin with. Think of a team working to prepare a complicated change that is to be presented as multiple easily reviewable patches. If you do something like that alone on a single computer, you will usually have a branch, collect some commits and merge fixes for previous commits together with rebase -i. If it takes a longer time you also rebase to upstream from time to time, fixing all the conflicts and so on. (You can also just collect and hope to still separate them into different patches at the end, but that usually gets messy in my experience). Those rebases will make you lose some history, which you can work around by having some extra branches with older states. If you work on different computers, pulling and pushing the current state of the branch around needs special care as the non-fast-forward needed all the time might also easily overwrite and newer with an older state (and keeping track of the older branches is a big mess unless you have one central repository). If there are multiple people working on this, things will not get easier. In this case having the new clean branch containing a trivial merge with second parent the old history will both allow easy push and pull and keep the history so one can look at older states. (see http://marc.info/?l=git&m=125959221911443&w=2) A special case for this are modifications in Debian packages. The patches have to be rebased to every new upstream, while at the same time should always be in a state so they can be sent upstream and upstream can pick some of them. (And ideally the debian source package does include the patches as nice topic separated patch files, so other distributions/users can easily pick those independent of what vcs they use). > A branch that merges with "-s ours" is typically done so that others can > pull and build against (and "-s ours" is used to cauterize the history of > a bad side branch), and good bits merged into it would also have come from > a different clean branch that is merged into that branch. It might make > more sense to format-patch that clean branch when preparing for upstream > submission, than the "aggregated mesh of commits" branch with "-s ours" > fix-ups. format-patch has to choose a parent. Choosing the first one make the most sense for me (as the first is the only real 'special' one). In the workflows I envision the first parent would also be the one with the clean history. Hochachtungsvoll, Bernhard R. Link -- "Never contain programs so few bugs, as when no debugging tools are available!" Niklaus Wirth -- 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