That is still undecided. I would rather make it git, main reason being that it is possible to merge in whole histories from (possibly personal) branches into the main tree. That'd be very handy when developing e.g. the multicore support, since the initial development can take place on a separate branch without upsetting the main tree (things probably won't even compile for several weeks), and then rebased and merged with it without losing the history (i.e. it all won't become a gigantic commit with a single laconic message like "Multicore support."). Afaik svn doesn't handle that, but maybe I'm wrong?

Doesn't git-svn allow this functionality?

On Wed, Nov 12, 2008 at 07:00:03PM +0000, Martin Stjernholm, Roxen IS @ Pike developers forum wrote:

developing e.g. the multicore support, since the initial development can take place on a separate branch without upsetting the main tree and then rebased and merged with it without losing the history

if you use git you would not loose the history anyways. why do you want a rebase?

there is no problem to do the development with git and then rebase, and after that commit to svn though. you could even take an svn branch, check it out with git and use git to rebase it, then git-svn to commit it back.

(bill, sorry for my last comment, i think this is what you meant. it's not a feature of git-svn however, but of git itself. i try to avoid using git-svn as much as possible though, only git-svn fetch and git-svn dcommit)

(i.e. it all won't become a gigantic commit with a single laconic message like "Multicore support."). Afaik svn doesn't handle that, but maybe I'm wrong?

i don't understand what's wrong with a merge commit? it would point to two branches (in git now, but i think also in svn with the merge tracking in 1.5)

that said, i am definetly in favour of using git :-) git-svn is nice as far as svn is concerned but not as good as it could be from a git perspective.

On Thu, Nov 13, 2008 at 11:05:03AM +0000, Martin Stjernholm, Roxen IS @ Pike developers forum wrote:

It's natural that a single line is easier to visualize and follow than a tree.

the problem with a rebased tree is that you loose the information of the exact state of the tree when a commit happened, and instead you get a series of states that never existed in reality and have not been tested. (assuming that tests are run for every commit at least on the main branch) this in turn should make it harder to go back and find out which commit breaks a test.

this situation is of course still better than a single huge commit without any access to the detailed commits at all.

(In practice I'd continuously rebase my development branch to keep it on top of the main trunk.)

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.

greetings, martin.

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.