[cfe-dev] Questions about Workflow & Submitting Patches

[Bruce Hoult via cfe-dev]

On Tue, Oct 16, 2018 at 1:55 AM, Whisperity via cfe-dev <
cfe-dev at lists.llvm.org> wrote:

> After this "inner review" is done, we usually introduce them to the
> biggest bane of all Git works: rebasing. If their checker works on the
> local fork (whichever latest release of master they did), we, of
> course, require them to do a rebase


It's not like this is any easier with a different CVS. Certainly not with
svn. Git just lets you find the problems faster :-)

I *highly* recommend git-imerge https://github.com/mhagger/git-imerge

With simple "git rebase" you learn that your commit conflicts with
*something* in the firehose of maybe thousands of commits on master. But
which one? No idea.

With a git-imerge rebase you learn precisely *which* master commit
conflicts with precisely which of your local commits. You see the commit
messages of both commits, so you know what was trying to be achieved. And
there are no other diffs unrelated to the two conflicting commits.

git-imerge takes a bit longer than a standard git rebase, but it's mostly
your computer doing the work, not you. You can go to lunch (or go to sleep)
and then fix the problems it found.

 # unrelated to git-imerge, recommended with normal merge/rebase too
git config merge.conflictstyle diff3

git checkout master
git imerge start --name=my-new-rebased-branch --goal=rebase my-branch

# if merge error
# fix the problems. Compile, test, etc

git add ...
git imerge continue

git imerge finish
# test your new branch more extensively then rename branches as desired
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20181016/a201a266/attachment.html>