There should never be a conflict merging .bzrignore

I think the general feeling is right, but I'm not sure what the best way to solve this is.

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Martin Albisetti wrote:
> I think the general feeling is right, but I'm not sure what the
> best way to solve this is.
There has been talk about file-type-specific merges. Perhaps a custom
merge handler specific to .bzrignore would be an option here?

Cheers,

Jelmer
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)

iJwEAQECAAYFAkpnUw0ACgkQDLQl4QYPZuUzNQP/fZQYz8tb9IGVi8b/WUvBIYBo
fIoeSPSJN3BkQ7U4cONfg2GIFhUGs56ASt89jgmYGQOCDVAUCgAHEFjNOXYaq0zV
SVGAeIACiTpCehkp2b7D4y9HHUewrAVPOmsrY0nRhNZcuVBbuMeAjfbo0zigRoij
h+dhZlCM6mGV4rVlY94=
=Yurv
-----END PGP SIGNATURE-----

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Martin Albisetti wrote:
> I think the general feeling is right, but I'm not sure what the best way
> to solve this is.
>
> ** Changed in: bzr
> Importance: Undecided => Wishlist
>
> ** Changed in: bzr
> Status: New => Triaged
>

I can delete an ignore that you modify.

I can modify an ignore that you modify.

There are lots of ways that .bzrignore *could* conflict that are genuine
conflicts.

I can understand that in a common case of 2 people adding an ignore it
is unclear. One could argue that you should always add both. However, it
is also possible that 2 people solved the ignore issue in different ways.

For example, if I added:
  *.pyc

And you added
  *.py[co]

Which is 'better'? The latter ignores everything the former does, so it
seems a bit silly to have both.

Anyway, we could certainly do better about merging .bzrignore in a
*logical* fashion, rather than a *textual* fashion. But that doesn't
mean that real-world *logical* changes can't conflict.

John
=:->

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (Cygwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAkpnU2wACgkQJdeBCYSNAAP61ACdHxDiSGkgYPiUme4Jt2hVpsbN
KAQAoKXFO6r35ee3GbOsd0tIyKjfUCH1
=Zm3c
-----END PGP SIGNATURE-----

On Wed, 2009-07-22 at 17:59 +0000, John A Meinel wrote:
> Anyway, we could certainly do better about merging .bzrignore in a
> *logical* fashion, rather than a *textual* fashion. But that doesn't
> mean that real-world *logical* changes can't conflict.

Sure, I guess that I'm arguing that in the case of where I've used "bzr
ignore" to add entries to the end it should work. In cases where I've
gone and hand modified the file things are different. I'd guess, for
most users, the use the built in command more than they edit the file.

2009/7/23 Ted Gould <email address hidden>:
> On Wed, 2009-07-22 at 17:59 +0000, John A Meinel wrote:
>> Anyway, we could certainly do better about merging .bzrignore in a
>> *logical* fashion, rather than a *textual* fashion. But that doesn't
>> mean that real-world *logical* changes can't conflict.
>
> Sure, I guess that I'm arguing that in the case of where I've used "bzr
> ignore" to add entries to the end it should work.  In cases where I've
> gone and hand modified the file things are different.  I'd guess, for
> most users, the use the built in command more than they edit the file.

It'd probably be reasonable to say this should run a file-specific
merge hook that, if lines are just added in both sides, with no
deletions, just takes both of them. This would handle Ted's case.
You could possibly still generate cases by hand where it gives silly
results, but it's also possible for people to review the diff and
correct it.

--
Martin <http://launchpad.net/~mbp/>

On Sun, 2011-03-13 at 20:31 +0000, Jelmer Vernooij wrote:
> ** Tags added: ignore

While I understand why this tag is called "ignore" that is a tag name
that might make some users upset. Probably "cmd-ignore" or something
would be better.

I was going to change this, but there are a couple more bugs that are also tagged this way. I can somewhat understand the issue with using just "ignore" (though from the context it should seem obvious that this tag doesn't mean ignoring this bug report), but I'd rather keep the same tag for all of them.