On Thu, Nov 13, 2008 at 12:40:02PM +0000, Martin Stjernholm, Roxen IS @ Pike developers forum wrote:
Most of the time I think it wouldn't be very much different to go back among the commits in such a rebased sequence than elsewhere, since there can be unrelated commits that affects the testing in any case, and it's not like we have a strict rule that every commit _must_ be self-contained and return the tree to green build status in the development branch.
that's true, and without having experienced this it is hard to say, but i am imagining somehow that git-bisect could dig up false positives on a rebased tree.
that only works if you are the only one working on that branch, a branch that is continuously rebased is very hard to use for anyone else.
Would it be that hard? If I have my own changes on top of this dev branch, and someone else rebases it, then it wouldn't be much harder to rebase my changes on top of the new dev branch as any other rebase, would it?
for this case i do have some actual experience. keeping up with a rebased branch is a lot of work, i am doing that in my current job. it's a tiny branch and fortunately it is not under active development, but i need to keep my work on top of it and it forces me to pay attention to get the rebase just right. the hard part comes from having to do this even if i am not working on that branch but only want to keep it up to date so i can test it and make sure it works with the latest changes.
in short, rebasing ends up creating a lot of work that would just disappear if you would accept merges.
fortunately there is no risk in trying. those that do want to work with your branch will complain soon enough if to much rebasing creates extra work or makes things difficult.
The changing hashes would be a nuisance mostly since you can't reliably refer to a commit using them. The way they are calculated on the whole tree in git is a drawback in my view.
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.
It's nice in an extremely decentralized dev environment to have the security built into the commit id's, but that decentralized model is not the reason I want to use git. I'd rather see uuid's or something as commit id's and hashes only as an optional tool to "sign" trees.
when reproducing issues, being able to verify that my tree is identical to yours is a big advantage. i had a case with darcs where i was not able to do that, and i ended up having to throw away my clone everytime it failed to build because i couldn't find a tool that would tell me the difference between my clone and the origin. (darcs claimed that i had all patches, and no local changes, but there must have been a difference because i got different results than with a fresh clone)
greetings, martin.