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: Arwed von Merkatz <v.merkatz AT gmx.net>
  • To: sm-discuss AT lists.ibiblio.org
  • Subject: Re: [SM-Discuss] git feedback
  • Date: Sat, 29 Jul 2006 00:42:10 +0200

On Fri, Jul 28, 2006 at 03:21:51PM -0700, seth AT swoolley.homeip.net wrote:
> 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?

I don't think it does. I was thinking of a wrapper that checks the file
name/type and uses appropriate merge tools based on that. A "stupid"
merge like I outlined above can lead to pretty bad merges when dealing
with functional files like BUILD, ..., so I'd prefer to only use it for
HISTORY and grimoire ChangeLog.

--
Arwed v. Merkatz Source Mage GNU/Linux developer
http://www.sourcemage.org




Archive powered by MHonArc 2.6.24.

Top of Page