I am trying to sort out a tangled (in the sense that I several branches that
split a long time ago, but are reasonably close subsets of each other)
repository of mine using git rebase. I want to isolate the commits that
cause the key differences so that I can then easily enhance the code but
carry forward the variants (using git-rebase again probably).
I have some questions which are causing me some grief after merge conflicts.
Can someone help me.
1) I often edit a merge conflicted file to the state I expect it to be in at
the end. This sometimes means that I edit it to a state where no change is
seen. git-update-index notices this and doesn't do anything, but when I try
git-rebase --continue it won't because it says git-update-index has not been
run. What am I supposed to do then? [Is the answer git-rebase --skip ?]
2) Some files get completely munged with conflict resolution markers every
few lines. Is there a simple way to say "don't use this file, but use the
[stage2/stage3] sources of the merge". (ie one of the original inputs to the
merge - and if so, which one is which)
3) I sometime hit a merge conflict in a file which I know will actually be
deleted at the tip of the topic I am rebasing. Is there a way at this point
to just tell the conflict resolution to say make this file go away.
4) I repeat the question I asked in a thread above. What is the --merge
switch on git-rebase actually do. The man page starts talking about merge
strategies, but there already is a -s switch for that.
--
Alan Chandler
alan@xxxxxxxxxxxxxxxxxxxxx
(via webmail - normally means I am not at my computer)
-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html