From: Pierre Habouzit <madcoder@debian.org>
To: martin f krafft <madduck@madduck.net>
Cc: git@vger.kernel.org, Andy Parkins <andyparkins@gmail.com>,
Johannes Schindelin <Johannes.Schindelin@gmx.de>
Subject: Re: merging .gitignore
Date: Tue, 02 Oct 2007 22:13:18 +0200 [thread overview]
Message-ID: <20071002201318.GD16776@artemis.corp> (raw)
In-Reply-To: <20071002195148.GA14171@lapse.madduck.net>
[-- Attachment #1: Type: text/plain, Size: 2135 bytes --]
On Tue, Oct 02, 2007 at 07:51:48PM +0000, martin f krafft wrote:
> 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
Except that this would not work, just take that example (for the sake
of conciseness I put lines as members of a set):
Common ancestor content: (bar, foo, quux)
Left child: (bar, baz, foo, quux)
Right child: (bar, quux)
This one is a conflict, and if you apply your method, the merge always
"works" (as in has no cases where it fails) and would yield a result
like:
(bar, baz, foo, quux) whereas it's probably (bar, baz, quux) that
would be the proper one (aka left branch added a new ignore `baz` and
the right one removed it).
The proper way for gitignore is probably to work on the sets
operations, like diff does with lines, but without taking ordering into
account. What gets harder is when your lists are:
Ancestor: (aa*, aaa, bbb)
Left child: (aa*, bbb) <-- remove aaa because aa* covers it
Right child: (aaa, aabcd, bbb, cc*) <-- remove aa* and be explicit
The proper result is probably: (aaa, aabcd, bbb, cc*) but is in fact a
case of conflict, because the "left" child could have used the fact that
aa* was present and hide say a aaXXX that the right child did not had,
and the merge would be wrong.
Of course, .gitignore aren't _that_ important and if you ignore one
less file, or one too many, git will continue to behave properly, but
well, merge implementations aren't _that_ trivial.
--
·O· Pierre Habouzit
··O madcoder@debian.org
OOO http://www.madism.org
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
next prev parent reply other threads:[~2007-10-02 20:13 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-10-01 13:03 merging .gitignore martin f krafft
2007-10-01 13:48 ` Andy Parkins
2007-10-02 19:51 ` martin f krafft
2007-10-02 19:55 ` Junio C Hamano
2007-10-02 20:20 ` martin f krafft
2007-10-02 20:13 ` Pierre Habouzit [this message]
2007-10-02 20:47 ` Pierre Habouzit
2007-10-02 20:56 ` martin f krafft
2007-10-02 21:07 ` Pierre Habouzit
2007-10-02 21:49 ` martin f krafft
2007-10-02 22:07 ` Pierre Habouzit
2007-10-03 8:42 ` martin f krafft
2007-10-03 8:58 ` Pierre Habouzit
2007-10-02 21:02 ` Pierre Habouzit
2007-10-03 8:23 ` Andy Parkins
2007-10-03 9:28 ` Johan Herland
2007-10-03 12:41 ` Johannes Schindelin
2007-10-03 13:06 ` Johan Herland
2007-10-03 19:38 ` Junio C Hamano
2007-10-01 13:57 ` Johannes Schindelin
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20071002201318.GD16776@artemis.corp \
--to=madcoder@debian.org \
--cc=Johannes.Schindelin@gmx.de \
--cc=andyparkins@gmail.com \
--cc=git@vger.kernel.org \
--cc=madduck@madduck.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).