All of lore.kernel.org
 help / color / mirror / Atom feed
From: Joey Hess <id@joeyh.name>
To: Yaroslav Halchenko <yoh@onerussian.com>
Cc: Git Gurus hangout <git@vger.kernel.org>,
	Benjamin Poldrack <benjaminpoldrack@gmail.com>
Subject: Re: 'next'ed --allow-unrelated-histories could cause lots of grief
Date: Thu, 21 Apr 2016 14:19:17 -0400	[thread overview]
Message-ID: <20160421181917.GA3628@kitenet.net> (raw)
In-Reply-To: <20160421161043.GK7907@onerussian.com>

[-- Attachment #1: Type: text/plain, Size: 1203 bytes --]

Yaroslav Halchenko wrote:
> which is planned for the next release.  I guess it is indeed a
> worthwhile accident-prevention measure 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!

Not only through the command line interface. The git-annex webapp has
common use cases that will be broken by this change.

> Moreover, it was explicitly stated that "no configuration variable to
> enable this by default exists and will not be added", which would cause
> 3rd party scripts/code/projects relying on previous behavior  to provide
> version specific handling (either to add that
> --allow-unrelated-histories or not)... very cumbersome!

Agreed, a configuration setting that could be passed via -c would be
much less cumbersome than checking the version of git in order to only
pass the option to git versions that understand it. This would also
provide a way to get git pull to allow such merges.

Compare with, for example, the change to default to an interactive
merge, where GIT_MERGE_AUTOEDIT=no was provided to ease compatability.

-- 
see shy jo

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 811 bytes --]

      parent reply	other threads:[~2016-04-21 18:19 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
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 [this message]

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=20160421181917.GA3628@kitenet.net \
    --to=id@joeyh.name \
    --cc=benjaminpoldrack@gmail.com \
    --cc=git@vger.kernel.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.