All of lore.kernel.org
 help / color / mirror / Atom feed
From: Andy Parkins <andyparkins@gmail.com>
To: git@vger.kernel.org
Cc: martin f krafft <madduck@madduck.net>,
	Johannes Schindelin <Johannes.Schindelin@gmx.de>
Subject: Re: merging .gitignore
Date: Wed, 3 Oct 2007 09:23:20 +0100	[thread overview]
Message-ID: <200710030923.22767.andyparkins@gmail.com> (raw)
In-Reply-To: <20071002195148.GA14171@lapse.madduck.net>

On Tuesday 2007 October 02, 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

Okay; *.o was obviously not a good example.  A more detailed one: how about a 
change like this to a makefile (excuse bastardised diff format)

diff Makefile
-include depends.make
+include depends.mak

diff .gitignore
-depends.make
+depends.mak

>   cat $gitignore_files | sort -u

Now, say there is another branch that makes exactly this change but 
chooses "depends.inc" as the filename.  Your "additive only" merge 
of .gitignore will not flag the conflict and will leave a .gitignore with

depends.mak
depends.inc

The makefile conflict will have been resolved one way or the other but the 
gitignore conflict will not.  While it's not a serious fault it is wrong, and 
no one was signalled that it was wrong.

I am still having difficult seeing why you want to hide conflicts 
in .gitignore.  It's just as possible to get and resolve conflicts in 
gitignore as in any other file.


Andy
-- 
Dr Andy Parkins, M Eng (hons), MIET
andyparkins@gmail.com

  parent reply	other threads:[~2007-10-03  8:23 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
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 [this message]
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=200710030923.22767.andyparkins@gmail.com \
    --to=andyparkins@gmail.com \
    --cc=Johannes.Schindelin@gmx.de \
    --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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.