[LLVMdev] svn mirror git?
garious at gmail.com
Fri Nov 16 15:45:44 PST 2012
David A. Green wrote:
> However, I don't think rebase is really the issue here.
Thanks David. After a bit of experimentation, I see you are quite
right, my "rebase" problem is actually a "squash" problem. As it
turns out, every time I've rebased, and then a later pull caused a
manual merge, it was because I had also squashed in changes from a
So here's the problematic workflow:
1) fork mainline
2) add patch to fork
3) submit patch to mainline for review
4) patch the patch as part of review process
5) squash "patch of patch" into "patch"
6) mainline accepts squashed patch
7) merge into private fork, and kaboom!
In this workflow, git can't possibly know whether I want the patch or
patched-patch. They represent different solutions to the same
An automation-friendly workflow:
4.5) submit "patch of patch" to private fork.
Then, when you merge, the history will include your original patch,
the patched-patch, and the squashed patch, and a 'merge' patch that
tells git that little mess is no problem.
I retract my proposal and apologize for the noise. I guess I'll have
to find some other reason to throw a big party. Suggestions welcome.
On Fri, Nov 16, 2012 at 2:30 PM, <dag at cray.com> wrote:
> Greg Fitzgerald <garious at gmail.com> writes:
>> In my humble opinion, there is a one biggest problem with git-svn and
>> svn. It requires the maintainer to rebase before committing, and in
>> git, this changes the the patch's unique ID.
> I didn't totally follow your argument so I'm sure I missed something.
> However, I don't think rebase is really the issue here. Linux kernel
> developers rebase all the time. It's required before merging to
> mainline. Of course at the point of the merge your feature branch
> should go away so the rebase is moot.
> I _think_ the "rebase" problem you describe is more to do with an
> innappropriate use of git - keeping branches around through multiple
> merges. I totally understand the attraction of doing that but with a
> rebase policy (common in the git world) it's going to cause issues of
> the type your described. Still, the merge often works just fine even in
> the presence of the rebase - git is often smart enough to recognize when
> a commit is already applied locally.
> The git-svn argument has been settled a while ago, so best not to stir
> that pot right now. But moving to git should _not_ mean we drop linear
> history. There is no reason it must.
More information about the llvm-dev