llvm dev - Jun 2016 - [cfe-dev] [lldb-dev] GitHub anyone?

Have you tried the git-imerge add-on?

https://www.youtube.com/watch?v=FMZ2_-Ny_zc


On Tue, Jun 7, 2016 at 5:17 AM, Robinson, Paul via llvm-dev <
llvm-dev at lists.llvm.org> wrote:
>
>
> > -----Original Message-----
> > From: llvm-dev [mailto:llvm-dev-bounces at lists.llvm.org] On Behalf
Of
> David
> > A. Greene via llvm-dev
> > Sent: Thursday, June 02, 2016 7:48 PM
> > To: Matthias Braun via llvm-dev
> > Subject: Re: [llvm-dev] [cfe-dev] [lldb-dev] GitHub anyone?
> >
> > Matthias Braun via llvm-dev <llvm-dev at lists.llvm.org> writes:
> >
> > > - Even in the long term I would vote to stay with linear history,
I
> > > see little benefits in having "correct" origin
information of a commit
> > > that the merging model provides.
> >
> > We often revert entire feature merges when problem arise.  It's
much
> > easier to do in a merging workflow because you have a single commit to
> > revert.  In the end I don't really care which model LLVM uses.  I
just
> > want to provide as much working knowledge as I can based on experience
> > doing exactly this kind of SVN->git transition.
> >
> > > On the other hand I find merge commits in the history unfriendly
to
> > > readers (esp. the merges themselfes where you suddenly see
conflicts
> > > of multiple commits getting resolved),
> >
> > It's certainly true that merge commits make history harder to
follow
> > with "git log."  I find "git log --oneline --graph
--decorate" to be
> > pretty useful.
> >
> > > bisection also gets a lot harder with merges in the history as it
is
> > > hard to decide which branch to follow.
> >
> > I don't understand this statement at all.  git-bisect handles
merges
> > just fine.  We use a heavily branching/merging model and we've
never had
> > a problem bisecting.
>
> We have a pile of local changes in our branches, and big merges from the
> upstream branch are a huge pain.  If a bisection tries to follow the
> upstream branch then we lose all our local changes on that iteration.
> Mostly that means the bisection can't identify where the problem began
> (or ended) within the big merge-from-upstream; all we know is that it
> happened somewhere within the big merge.
>
> We are trying to change our processes to make merges from upstream as
> small as possible, ideally single commits, but this is a disruptive
> change and not one that everybody can manage.
> --paulr
>
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20160607/78524fdc/attachment.html>

On 7 Jun 2016, at 09:34, Bruce Hoult via llvm-dev <llvm-dev at
lists.llvm.org> wrote:
> 
> Have you tried the git-imerge add-on?
You beat me to it - I was just about to suggest the same thing.  Merges from
LLVM upstream have been a lot more CPU-intensive, but a lot less human-intensive
since I started using it.  It’s worth noting though that not having the clang
repo as a submodule makes bisection very hard for clang-related changes.

If you have upstream and downstream, git-imerge’s rebase-with-history is very
useful, as your tree ends up looking as if it’s been rebased onto upstream, but
downstream users can still pull from any of your pre-merge commits and merge (or
rebase) that into their own tree.

David

> -----Original Message-----
> From: Dr D. Chisnall [mailto:dc552 at hermes.cam.ac.uk] On Behalf Of David
> Chisnall
> Sent: Tuesday, June 07, 2016 2:52 AM
> To: Bruce Hoult
> Cc: Robinson, Paul; llvm-dev at lists.llvm.org
> Subject: Re: [llvm-dev] [cfe-dev] [lldb-dev] GitHub anyone?
> 
> On 7 Jun 2016, at 09:34, Bruce Hoult via llvm-dev <llvm-
> dev at lists.llvm.org> wrote:
> >
> > Have you tried the git-imerge add-on?
> 
> You beat me to it - I was just about to suggest the same thing.  Merges
> from LLVM upstream have been a lot more CPU-intensive, but a lot less
> human-intensive since I started using it.  It’s worth noting though that
> not having the clang repo as a submodule makes bisection very hard for
> clang-related changes.
I did look at git-imerge, and very much liked what I saw.
However our local repo is not set up like upstream, and it's not clear
we could paste everything together with imerge in a straightforward way,
or possibly even make it work at all.
It is clear (and we have the hardware resources to support it) that we
can iterate merging each individual upstream commit.  If we were starting
over from scratch instead of building on what we already have, I'd much
rather do it differently!

I could see git-imerge working extremely well for downstream projects that
were essentially a series of patches on top of the upstream projects.
--paulr
> 
> If you have upstream and downstream, git-imerge’s rebase-with-history is
> very useful, as your tree ends up looking as if it’s been rebased onto
> upstream, but downstream users can still pull from any of your pre-merge
> commits and merge (or rebase) that into their own tree.
> 
> David