git@vger.kernel.org list mirror (unofficial, one of many)
 help / color / mirror / Atom feed
* git format-patch with useAutoBase = true
@ 2020-09-15  0:13 Jacob Keller
  2020-09-15 20:24 ` Junio C Hamano
  0 siblings, 1 reply; 2+ messages in thread
From: Jacob Keller @ 2020-09-15  0:13 UTC (permalink / raw)
  To: Git mailing list

Hi,

I just ran into a surprising and unexpected issue with git format-patch.

$  git format-patch -1 f7529b4ba3c98470b0e367ba447ad0da84dc308
fatal: base commit shouldn't be in revision list

It took me about 15 minutes to figure out this was referring to the
fact that I have "useAutoBase" set to true in the git config, so that
I get --base=auto by default.

It turns out, that if you, while this config is active, try to format
an ancient patch that is historical, you will get this failure.
Because --base wasn't specified on the command line, this made it very
unintuitive what was going wrong.

(I started to try a git bisect thinking it was a some bug in my
current version of git from the repo, which still failed..)

The failure occurs because the "automatic" base is newer than the
requested commit. I am wondering if it would make sense to relax this
restriction and make the format-patch automatically disable
useAutoBase if it would conflict like this?

At the very least it would be helpful if the error message was more
intuitive and potentially explained what was going on a bit better...
:)

Thanks,
Jake

^ permalink raw reply	[flat|nested] 2+ messages in thread

* Re: git format-patch with useAutoBase = true
  2020-09-15  0:13 git format-patch with useAutoBase = true Jacob Keller
@ 2020-09-15 20:24 ` Junio C Hamano
  0 siblings, 0 replies; 2+ messages in thread
From: Junio C Hamano @ 2020-09-15 20:24 UTC (permalink / raw)
  To: Jacob Keller; +Cc: Git mailing list

Jacob Keller <jacob.keller@gmail.com> writes:

> $  git format-patch -1 f7529b4ba3c98470b0e367ba447ad0da84dc308
> fatal: base commit shouldn't be in revision list
> ...
> The failure occurs because the "automatic" base is newer than the
> requested commit. I am wondering if it would make sense to relax this
> restriction and make the format-patch automatically disable
> useAutoBase if it would conflict like this?

I agree that it does make a horrible end-user experience to die with
the message like the above, trying to use a nonsense autobase.

^ permalink raw reply	[flat|nested] 2+ messages in thread

end of thread, other threads:[~2020-09-15 22:07 UTC | newest]

Thread overview: 2+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2020-09-15  0:13 git format-patch with useAutoBase = true Jacob Keller
2020-09-15 20:24 ` Junio C Hamano

git@vger.kernel.org list mirror (unofficial, one of many)

This inbox may be cloned and mirrored by anyone:

	git clone --mirror https://public-inbox.org/git
	git clone --mirror http://ou63pmih66umazou.onion/git
	git clone --mirror http://czquwvybam4bgbro.onion/git
	git clone --mirror http://hjrcffqmbrq6wope.onion/git

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V1 git git/ https://public-inbox.org/git \
		git@vger.kernel.org
	public-inbox-index git

Example config snippet for mirrors.
Newsgroups are available over NNTP:
	nntp://news.public-inbox.org/inbox.comp.version-control.git
	nntp://ou63pmih66umazou.onion/inbox.comp.version-control.git
	nntp://czquwvybam4bgbro.onion/inbox.comp.version-control.git
	nntp://hjrcffqmbrq6wope.onion/inbox.comp.version-control.git
	nntp://news.gmane.io/gmane.comp.version-control.git
 note: .onion URLs require Tor: https://www.torproject.org/

code repositories for the project(s) associated with this inbox:

	https://80x24.org/mirrors/git.git

AGPL code for this site: git clone https://public-inbox.org/public-inbox.git