Re: merging .gitignore

From: martin f krafft <madduck@madduck.net>
Date: Oct 2, 2007, 19:51 UTC
Message-ID: <20071002195148.GA14171@lapse.madduck.net>
In-Reply-To: <Pine.LNX.4.64.0710011457120.28395@racer.site>

also sprach Johannes Schindelin <Johannes.Schindelin@gmx.de> [2007.10.01.1457 +0100]:

> You might be interested in writing a merge driver.  See 
> Documentation/gitattributes.txt.

This is an excellent idea; thanks.

also sprach Andy Parkins <andyparkins@gmail.com> [2007.10.01.1448 +0100]:

Show 6 quoted lines

> Then, assuming the conflicts you get now occur for a reason, you
> will get conflicts within the .gitignore.d/ directory.  Let's say
> branchCignores adds *.o and branchFignores removes *.o from the
> ignores.  Who is right?  Who knows, and worse than that you didn't
> see the conflict when it happened so it wasn't resolved and the
> master branch was left with conflicts in it.

Well, with gitignore I am ready to say that merges should be resolved in an additive way. Remember that I am talking about an intergration branch, and if feature branches A and B used to ignore .o files, and now B suddenly does not ignore them anymore, the only real reason I can think of is that it was rewritten in a languages other than C*. So then you *still* want to ignore .o files in the integration branch.

Basically I am saying that it should be

  cat $gitignore_files | sort -u

and obviously, this is something for a specific merge driver, as Johannes suggested.

Thanks for the feedback,

-- 
martin;              (greetings from the heart of the sun.)
  \____ echo mailto: !#^."<*>"|tr "<*> mailto:" net@madduck
 
minchinhampton (n.): the expression on a man's face when he has just
zipped up his trousers without due care and attention.
                               -- douglas adams, the meaning of liff
 
spamtraps: madduck.bogus@madduck.net