[llvm-dev] [RFC] One or many git repositories?
Bruce Hoult via llvm-dev
llvm-dev at lists.llvm.org
Mon Jul 25 08:10:43 PDT 2016
git-imerge can run an arbitrary script to decide whether a commit is good
or bad. Lack of textual merge conflicts is only the most basic test -- you
can check that it compiles, run tests .. whatever you want and have time to
On Tue, Jul 26, 2016 at 2:12 AM, Robinson, Paul via llvm-dev <
llvm-dev at lists.llvm.org> wrote:
> > -----Original Message-----
> > From: Renato Golin [mailto:renato.golin at linaro.org]
> > Sent: Monday, July 25, 2016 7:11 AM
> > To: Daniel Sanders
> > Cc: Robinson, Paul; llvm-dev at lists.llvm.org
> > Subject: Re: [llvm-dev] [RFC] One or many git repositories?
> > On 25 July 2016 at 14:55, Daniel Sanders <Daniel.Sanders at imgtec.com>
> > wrote:
> > > I know of a way but it's not very nice. The gist of it is to checkout
> > the
> > > downstream branch just before the bad merge and then merge the first
> > > 100 commits from upstream. If the result is good then merge the next
> > > 100, but if it's bad then 'git reset --hard' and merge 10 instead.
> > You'll
> > > eventually find the commit that made it bad. Essentially, the idea is
> > > make a throwaway branch that merges more frequently. I do something
> > > similar to rebase my work to master since gradually rebasing often
> > > causes all the conflicts to go away.
> > This is essentially what git-imerge does, you only need to define
> > "good merge" in the form of a script or CI job.
> > cheers,
> > -renato
> Except I understood git-imerge to be looking for physical conflicts,
> not "when did this test start failing." If it does the latter also,
> that would be awesome.
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the llvm-dev