git@vger.kernel.org mailing list mirror (one of many)
 help / color / mirror / code / Atom feed
From: Junio C Hamano <gitster@pobox.com>
To: Denton Liu <liu.denton@gmail.com>
Cc: Git Mailing List <git@vger.kernel.org>
Subject: Re: [PATCH] format-patch: make format.outputDirectory relative to worktree
Date: Tue, 24 Dec 2019 11:25:18 -0800	[thread overview]
Message-ID: <xmqq36d95xwh.fsf@gitster-ct.c.googlers.com> (raw)
In-Reply-To: <9422e4225143b2b908bd1fed9a510b9333bf34a2.1577191015.git.liu.denton@gmail.com> (Denton Liu's message of "Tue, 24 Dec 2019 07:37:50 -0500")

Denton Liu <liu.denton@gmail.com> writes:

> Currently, when format-patch outputs patches to the path specified by
> the `format.outputDirectory` configuration variable, it is relative to
> the current working directory. However, it would make more sense for the
> path to be relative to the worktree if it exists so that patches will be
> placed in one location even if a user were to change directories.

Would it make more sense?  If a user is deep in the hierarchy, after
running

	$ git format-patch master..

the next thing the user would want to do is to go to the directory
and give them final review and edit the patches before sending out.
That would involve going up some levels depending on where s/he is,
in other words, the location the patches are found would be different
and this change makes it a lot more cumbersome to go there with a
relative path.  The only people who benefit from the change is those
who have their working trees at very shallow hierarchy so that it is
not cumbersome for them to give the full path to the top of them.

So I think this cuts both ways, and "it would make more sense" is
overselling.  Besides, those who can easily give the full path to
the top of the working tree (because they are short) can spell that
short path to outputDirectory configuration variable just once and
be done with it, no?

> Rewrite the output directory logic for format-patch so that it will be
> relative to the worktree of the directory. An escape hatch is provided
> for if the previous behaviour is desired by prepending "./" to the
> variable.

Anything that forces existing users to change their existing
settings is not an escape hatch.  It merely is a regression with a
possible workaround.

So I dunno.  I probably would have accepted a patch that *adds*
outputDirectory configuration that behaves the way you are proposing
in this patch if we did not have the variable yet in the system
(i.e. three or four years ago), but I am not sure if it is a good
idea to change it after these years.

  reply	other threads:[~2019-12-24 19:26 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-12-24 12:37 [PATCH] format-patch: make format.outputDirectory relative to worktree Denton Liu
2019-12-24 19:25 ` Junio C Hamano [this message]
2019-12-24 22:05   ` Denton Liu
2019-12-25  2:26     ` Junio C Hamano

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

  List information: http://vger.kernel.org/majordomo-info.html

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=xmqq36d95xwh.fsf@gitster-ct.c.googlers.com \
    --to=gitster@pobox.com \
    --cc=git@vger.kernel.org \
    --cc=liu.denton@gmail.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.
Code repositories for project(s) associated with this public inbox

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

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).