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

Re: [PATCH] git-am: Handle "git show" output correctly

From
Dan Johnson <computerdruid@gmail.com>
Date
Sep 12, 2012, 22:31 UTC
Message-ID
<CAPBPrntXCDHwWkYV3pnj3+d8FCZCmEVPHkSxyVg0Jzd0tzZsGA@mail.gmail.com>
In-Reply-To
<7vhar2c29s.fsf@alter.siamese.dyndns.org>
On Wed, Sep 12, 2012 at 6:19 PM, Junio C Hamano <gitster@pobox.com> wrote:
Show 19 quoted lines
> Dan Johnson <computerdruid@gmail.com> writes:
>
>>> Not really.  If we start encouraging people to use "git show" output
>>> as a kosher input to "am", we would have to support such use
>>> forever, and we end up painting ourselves in a corner we cannot get
>>> out of easily.
>>
>> If git am emitted a warning when accepting "git show" output, it seems
>> like it would support Peter's use-case without encouraging bad
>> behavior?
>
> Are you seriously suggesting me to sell to our users a new feature
> saying "this does not work reliably, we would not recommend using
> it, no, really, don't trust it." from the day the feature is
> introduced, especially when we know it will not be "the feature does
> not work well yet, but it will, we promise" but is "and it may become
> worse in the future"?
>
> I do not see much point in doing that.
Fair enough.
Show 5 quoted lines
> Besides, what bad behaviour do we avoid from encouraging with such
> an approach?  As Peter said, the problem is not on the part of the
> user who ended up with an output from "git show", when he really
> wants output from "git format-patch".  Giving the warning to the
> user of "git am" is too late.

I was assuming Peter would accept the patch, and reply with a "in the future, please submit the output of format-patch", thus correcting the submitter's behavior. This warning would serve someone who did not know that they wanted the output of format-patch, and hopefully teach them to send such a reply message.

Show 6 quoted lines
> I may be able to be pursuaded to swallow a new script somewhere in
> the contrib/ hierarchy that takes a "git show" output and formats it
> to look like "format-patch" output to be fed to "git am".  That way,
> when a user has trouble with its parsing of "git show" output, at
> least we can ask for the output of the format massaging step to help
> us diagnose where the problem lies.
That sounds like a better approach to me as well.
-- 
-Dan
Previous: Junio C HamanoNext: Junio C Hamano
Message 19 of 21 in “Handle "git show" output correctly.”
  1. Handle "git show" output correctly.Peter Jones, Sep 12, 2012
  2. Handle "git show" output correctly.Peter Jones, Sep 12, 2012
  3. Matthieu MoySep 12, 2012
  4. [git-am] Handle "git show" output correctlyPeter Jones, Sep 12, 2012
  5. Matthieu MoySep 12, 2012
  6. Junio C HamanoSep 12, 2012
  7. Peter JonesSep 12, 2012
  8. Junio C HamanoSep 12, 2012
  9. Handle "git show" output correctly.Peter Jones, Sep 12, 2012
  10. Matthieu MoySep 12, 2012
  11. Peter JonesSep 12, 2012
  12. git-am: Handle "git show" output correctlyPeter Jones, Sep 12, 2012
  13. Junio C HamanoSep 12, 2012
  14. Peter JonesSep 12, 2012
  15. git-am: Handle "git show" output correctlyPeter Jones, Sep 12, 2012
  16. Junio C HamanoSep 12, 2012
  17. Dan JohnsonSep 12, 2012
  18. Junio C HamanoSep 12, 2012
  19. Dan JohnsonSep 12, 2012
  20. Junio C HamanoSep 12, 2012
  21. Andreas EricssonSep 12, 2012

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.