Martin B?hr wrote:
On Mon, Jul 28, 2008 at 11:15:02PM +0000, Martin Stjernholm, Roxen IS @ Pike developers forum wrote:
g. Anyone having local branches which are based off of commits in the old git repository will have to rebase those
How do you go about that? Manually rebasing every branch
yes.
Say you have the following two aliases in /etc/gitconfig: [alias] makepatch = format-patch -k --stdout applypatch = am -k --whitespace=nowarn
Say you have a local branch called mybranch with commits: A-B-c-d-e Where A-B are part of the public repository. Then I'd do a: git checkout mybranch git makepatch B >/tmp/mybranchinpatchformat Then resync the repository/branches to the history-changed master repository. Then: git checkout mybranch git applypatch </tmp/mybranchinpatchformat
And you'd end up with: A'-B'-c'-d'-e'
Even if it's simple to rebase, I think it'd be best to avoid steps f-h as much as possible.
I don't think there is any arguing here. I was actually planning to fix the repository once, and be done with it, we just have to get all hens on deck for people to check most of it. And only if we missed a large enough amount of things, we'd ever repeat it, but most likely not.
git can work just fine with a shared repository too. I wouldn't like to see the plethora of branches and merges on the server, though.
agreed.
Let me emphasize this: IMO the best model would be to have a central git repository with just (currently) the main branches:
0.5 0.6 7.0 7.2 7.4 7.6 7.7 nt-tools extra_tests
Nothing more, nothing less. Commits on those branches are linear, but backports or forward ports/merges can be done directly and hence are visible when viewed in gitk (unless you use --first-parent which strips all the merge/porting links).
A nice linear sequence of commits on each version branch keeps things simple. We've been working that way for years now and I haven't seen any real reason to change that. But that shouldn't be a big problem to accomplish just by dictating policy, I guess.
i think for us a mixed model makes the most sense. people with write access push into the core branches, but other potential contributers can still be pulled from by a core developer and then pushed from there.
Quite. On the central repository new and/or temporary branches should not be created. People can do that on their own repos as much as they want; temporary branches on the central repo should be the exception rather than the rule.
Zino has good points that svn fits better on the server: It's more mature,
more mature in what sense? if everyone uses git on the client side then the maturity of svn on the server does not muy anything because you still have to deal with git. it only adds hassle which wouldn't exist otherwise.
Same question. More mature in which way? Git is maturing at an amazing rate (codebase wise), most open source projects either start with git or move from CVS or SVN to git these days.
it's closer to cvs so that the server tools around it don't need much change,
the largest change should be in the fact that the rcs files are not accessible anymore but have to be replaced with calls to the svn module. at the same time calls to git can be added.
Indeed, for every CVS/SVN command, there is an equivalent git command. So rewriting the tools to SVN or git is just as much effort.
and it's afterall built with that sharing model in mind.
it has been built with a "this is all we know, so this is all you get" mindset. git is being built with a "there are many ways to do it, and we want to support all of them" mindset.
I dare say that most deployments of Git use the central repository model (like CVS/SVN). It's just that Linux development uses the more purely distributed model due to its sheer size and depth of the project.
Maybe a good way to accomplish both ends is to use the bidirectional git-svn bridge? Afaict it's made for the case when the primary repo is in svn. It advices against doing git-style heavily branched development, which is good on the server side (see above). And using svn for storage allows properties, which git lacks. I will play around a bit with git-svn.
Which properties are you missing (git has properties, like file modes, BTW)?
git-svn is the most featureful dcvs-svn bridge i came accross (only bzr might be a bit better, but it is less mature), but it has it's
Having SVN as a central repository would work, of course, but it would be inconvenient at best, because SVN is not as good with merges (both the actual process, as well as recording the merge history).
Also, a rather large drawback (I think) for SVN is that it is immutable. Case in point: if someone (by mistake) checks in a large 50MB Yahoo-UI binary blob, then this blob will be part of the SVN repository forever and cannot easily be removed. The only thing you can do is painstakingly dump the whole repository, filter out the bad commits (which sometimes is complicated enough) and read it back in again.
Git gives you tools to actually fix that with a small price to pay: anyone who already synced from that branch, will have to rebase, but other than that, there is no downtime, no complicated dump-editing; it's all less-filling and easy to use.