git/list[1] front-page[2] threads[3] people[4] search[5] about
 

Re: [PATCH 1/2] format-patch: fix dashdash usage

From
Björn Steinbrink <b.steinbrink@gmx.de>
Date
Nov 26, 2009, 23:37 UTC
Message-ID
<20091126233749.GA26228@atjola.homenet>
In-Reply-To
<7v7htc3mqo.fsf@alter.siamese.dyndns.org>
On 2009.11.26 15:11:27 -0800, Junio C Hamano wrote:
Show 31 quoted lines
> Felipe Contreras <felipe.contreras@gmail.com> writes:
> > On Thu, Nov 26, 2009 at 9:57 PM, Junio C Hamano <gitster@pobox.com> wrote:
> >> I actually have a bigger question, though.  Does it even make sense to
> >> allow pathspecs to format-patch?  We sure are currently loose and take
> >> them, but I doubt it is by design.
> >
> > Not everyone has clean branches only with pertinent patches.
> >
> > I stumbled upon this trying to re-create (cleanly) a "branch" that was
> > constantly merged into another "master" branch that had a lot more
> > stuff. Maybe there was a smarter way to do that with 'git rebase', but
> > that doesn't mean format-patch -- <path> shouldn't work.
> >
> >> The patch itself looks good and is a candidate 'maint' material, if the
> >> answer to the above question is a convincing "yes, because ...".
> >
> > Yeah, I also think this should go into 'maint'.
> 
> Hmm, I have not seen a clear "yes, because..." yet.
> 
> For one thing, Documentation/git-format-patch.txt does not even hint that
> you can give pathspecs.  builtin_format_patch_usage[] doesn't, either.  As
> I wrote the initial version of format-patch I can say with some authority
> that use with pathspecs were never meant to be supported---if it works, it
> works by accident, giving long enough rope to users to potentially cause
> themselves harm.
> 
> I am inclined to think that we shouldn't encourage use of pathspecs (just
> like we never encouraged use of options like --name-only that never makes
> sense in the context of the command) but I am undecided if we also should
> forbid the use of pathspecs (just like we did for --name-only recently).

A year ago, there was someone who had done a subtree merge and had commits that changed the subtree in the "supertree" branch. He wanted to generate patches to send them to upstream, and ended up using format-patch with --relative and pathspecs.

http://thread.gmane.org/gmane.comp.version-control.git/101742

I guess this could be done by some "git rebase -s subtree ..." invocation though, to first get commits that sit directly on the subtree branch, and then you could turn them into patches as usual... Hmm..

Björn
Previous: Junio C HamanoNext: Felipe Contreras
Message 10 of 11 in “format-patch: fix dashdash”
  1. 0/2 format-patch: fix dashdashFelipe Contreras, Nov 26, 2009
  2. 1/2 format-patch: fix dashdash usageFelipe Contreras, Nov 26, 2009
  3. Junio C HamanoNov 26, 2009
  4. Felipe ContrerasNov 26, 2009
  5. Junio C HamanoNov 26, 2009
  6. Felipe ContrerasNov 26, 2009
  7. Junio C HamanoNov 27, 2009
  8. Felipe ContrerasNov 28, 2009
  9. Junio C HamanoNov 26, 2009
  10. Björn SteinbrinkNov 26, 2009
  11. 2/2 format-patch: add test for dashdashFelipe Contreras, Nov 26, 2009

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.