i'm pretty sure the simpler answer to this is to always merge, never use a fastfoward, never rebase and to accept history as what it is instead of trying to cha

i'm pretty sure the simpler answer to this is to always merge, never use a fastfoward, never rebase and to accept history as what it is instead of trying to change it to make it 'more manageable' or whatever. changing the past to make a single linear thread is just weird imo. depending on what rebaseWithoutConflictsPossible() is doing it might be helpful though - doing a rebase is an opportunity for the merging algorithms to cause subtle problems, and taking things out of the context in which they were actually made reduces the utility of the history for seeing what was done. the more people you have working on different things at once, the more likely these problems will manifest as something real. if this rebaseWithoutConflictsPossible() check is looking for any potential conflict, not just the ones the algorithms get stuck on then i can see the utility... but its still not necessary if you never rebase and never fast-forward. "git recursive merge doesn't screwup x% of merges in some linux kernel repo" isn't an argument for it being useful in x% of cases so much as an argument for it causing damage in (100-x)% of cases. the many options available to tweak its behaviour to make it safer should be a giveaway that the merge feature is dangerous out of the box... the difficulty of resolving conflicts and dealing with merges is usually greatly overstated. a lot of programmers seem to have 'mergephobia'... i'm pretty sure we should just suck it up and do our jobs - learn that merges aren't that hard, and spend our time thinking about more important things. :)