Re: 'next'ed --allow-unrelated-histories could cause lots of grief

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Yaroslav Halchenko <yoh@xxxxxxxxxxxxxx> writes:

> I have decided to try 2.8.1.369.geae769a available from debian
> experimental and through our (datalad) tests failing I became
> aware of the 
>
>     https://github.com/git/git/pull/158/commits/e379fdf34fee96cd205be83ff4e71699bdc32b18
>     merge: refuse to create too cool a merge by default
>
> which is planned for the next release.

See http://thread.gmane.org/gmane.linux.kernel.gpio/15365/focus=15401
for the backstory.

As this is to allow maintainers at higher levels of hierarchy not to
have to worry about stupid mistakes happen at maintainers at lower
levels, I'm afraid that turning this into an opt-in safety would
defeat the point of the change in a major way.

> ... BUT not sure if it is so
> important as to cause a change in behavior on which some projects using
> git through the cmdline interface might have been relying upon for
> years!

It is not very productive to make such an emotional statement
without substantiating _why_ a merge that adds a new root, which was
declared in the thread above as "crap" (in the context of the kernel
project), is necessary and is a good idea in "some projects".  Maybe
there is a valid use case that those from the kernel land didn't
think about.

> Given that git is quite 'self-healing', i.e. if someone has managed to
> make a merge he didn't intend to, there is always a way back (e.g., as
> simple as git reset --hard HEAD^),

That is only true if people notice.  A mere warning would not be an
effective prevention measure for a user who has to perform dozens of
merges a day.

I am personally on the fence, but right now I am on the side of
keeping the behaviour as implemented and documented, simply because
I haven't heard anything concrete to convince me why some people
need to regularly do a "crap" merge (in other words, in what context
these are not "crap" merges but ability to create them is a valuable
part of everyday workflow).
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html



[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]