From: Junio C Hamano <gitster@pobox.com>
To: Yaroslav Halchenko <yoh@onerussian.com>
Cc: Git Gurus hangout <git@vger.kernel.org>,
Benjamin Poldrack <benjaminpoldrack@gmail.com>,
Joey Hess <id@joeyh.name>,
Linus Torvalds <torvalds@linux-foundation.org>
Subject: Re: 'next'ed --allow-unrelated-histories could cause lots of grief
Date: Thu, 21 Apr 2016 09:41:32 -0700 [thread overview]
Message-ID: <xmqqbn52ud6r.fsf@gitster.mtv.corp.google.com> (raw)
In-Reply-To: <20160421161043.GK7907@onerussian.com> (Yaroslav Halchenko's message of "Thu, 21 Apr 2016 12:10:43 -0400")
Yaroslav Halchenko <yoh@onerussian.com> 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).
next prev parent reply other threads:[~2016-04-21 16:41 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-04-21 16:10 'next'ed --allow-unrelated-histories could cause lots of grief Yaroslav Halchenko
2016-04-21 16:41 ` Junio C Hamano [this message]
2016-04-21 18:55 ` Yaroslav Halchenko
2016-04-21 19:37 ` Junio C Hamano
2016-04-21 20:36 ` Yaroslav Halchenko
2016-04-21 22:57 ` Joey Hess
2016-04-21 23:17 ` Junio C Hamano
2016-04-21 18:19 ` Joey Hess
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=xmqqbn52ud6r.fsf@gitster.mtv.corp.google.com \
--to=gitster@pobox.com \
--cc=benjaminpoldrack@gmail.com \
--cc=git@vger.kernel.org \
--cc=id@joeyh.name \
--cc=torvalds@linux-foundation.org \
--cc=yoh@onerussian.com \
/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.