> /.../ but i am imagining somehow that git-bisect could dig up false > positives on a rebased tree.
Yes, but my point is that it can do that anyway. The few times I've used that approach to find bugs in Pike in the past, I've had problems with unrelated commits that messed up my test case. > in short, rebasing ends up creating a lot of work that would just > disappear if you would accept merges. True, but I think the key issue is the extent of the patches in the rebased tree, not the number of people using it. They can rebase as long as it works, and when it gets too cumbersome due to the amount of conflicts, they can just say "ok, let's stop this and merge later instead". Personally I'm prepared to spend some time fixing rebase conflicts though, since I think a linear history is worth it. If I'm rebasing a big dev tree, and you have just a few small patches on top of it, then I would also do most of the conflict resolution work, while your small patches would be pretty undisturbed on the top, wouldn't they? > well, actually hashes that make up the diff do exist. they are just not > visible usually and i don't think you can tag them. I know, but that wouldn't be good enough. I'd like to identify a commit as that particular commit, even if stuff inside it changes. If a commit is rebased the diff might change slightly, so the diff hash is not completely stable. > when reproducing issues, being able to verify that my tree is identical > to yours is a big advantage. /.../ Perhaps, but the hashes could still be there; they just wouldn't be the only way to identify a commit, and I can imagine things would be easier in rebase scenarios if parent pointers etc used uuids instead of hashes.
