Skip to Content.
Sympa Menu

sm-discuss - Re: [SM-Discuss] git feedback

sm-discuss AT lists.ibiblio.org

Subject: Public SourceMage Discussion List

List archive

Chronological Thread  
  • From: seth AT swoolley.homeip.net
  • To: sm-discuss AT lists.ibiblio.org
  • Subject: Re: [SM-Discuss] git feedback
  • Date: Fri, 28 Jul 2006 15:21:51 -0700

On Sat, Jul 29, 2006 at 12:12:24AM +0200, Arwed von Merkatz wrote:
> On Fri, Jul 28, 2006 at 04:32:43PM -0500, Jeremy Blosser wrote:
> > On Jul 28, Arwed von Merkatz [v.merkatz AT gmx.net] wrote:
> > > > It shows up more often on the history files because of the specific
> > > > way in
> > > > which RCS' /usr/bin/merge makes bad assumptions, but yes, it shows up
> > > > elsewhere as well. The fix for this would be general in nature.
> > >
> > > Merging in perforce was far from perfect too, but it was fitting our
> > > work model a little bit better. There definitely is the possibility to
> > > make the merging work better for us due to git just using external
> > > tools, but all I did in that area was a proof-of-concept so far.
> >
> > Can you provide the code you had for that if you still have it?
>
> I will if I find it again, but it was really simple. /usr/bin/merge is a
> 3-way merge tool, you basically start with 3 files:
> - original from branch you cherry-pick to
> - previous version from branch you cherry-pick from
> - current version from branch you cherry-pick from
>
> merge tries to be smart and does a real 3-way comparison between those
> files, which doesn't work too well for ChangeLog/HISTORY type files.
> What I did was basically replicate the way p4 does merges:
> - do a plain diff (i.e. not context or unified) between previous and
> current version on the branch to cherry-pick from
> - apply that as a patch to original on branch to cherry-pick to
>
> This leads to less conflicts because it doesn't use context/unified
> diffs, instead it just records removed/added lines without context.
> I wouldn't want an algorithm like that in general as it's too fault
> tolerant, but for HISTORY/ChangeLog type merging, it works pretty well.

So we just need to have this script act as a wrapper for both, trying
the first one and if that doesn't succeed, try the second, and if that
doesn't succeed, return failure.

Or does git allow you to have mutliple merge algorithms inherently?

Seth




Archive powered by MHonArc 2.6.24.

Top of Page