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.
--
Sincerely,
Stephen R. van den Berg.
"People who think they know everything are annoying to those of us who do."
