From: Robin Rosenberg <robin.rosenberg@dewire.com>
To: Junio C Hamano <gitster@pobox.com>
Cc: git@vger.kernel.org
Subject: Re: [PATCH] Add --no-rename to git-apply
Date: Thu, 27 Sep 2007 21:12:29 +0200 [thread overview]
Message-ID: <200709272112.29608.robin.rosenberg@dewire.com> (raw)
In-Reply-To: <7vbqbozo7t.fsf@gitster.siamese.dyndns.org>
torsdag 27 september 2007 skrev Junio C Hamano:
> Robin Rosenberg <robin.rosenberg@dewire.com> writes:
>
> > With this option git-apply can apply a patch with a rename
> > onto the original file(s).
>
> This is troubling from both design and implementation point of
> view.
>
> * Why would this be useful? What's the point of producing the
> renaming patch if you know you would want to apply while
> ignoring the rename?
The point of producing the rename info is to find out which renames
are in it. It's only that I don't want to perform them straight away.
> * The change looks too special purpose to me. If you are
> giving the ability to deposit the result to somewhere other
> than where the patch intendes to, why limit it only to the
> preimage name? Aren't there cases where A is renamed to B
> sometime in the history, and you have a patch that talks
> about the content change A->A but the tree you have has the
> contents already in B, and you would want to apply that
> patch? It feels that this and your "ignore rename" could be
> handled much more cleanly and flexibly by preprocessing the
> patchfile.
Well it is special *purpose*, but not tied to a particuar tool. I'm
not sure whether it is necessary with other tools though. I'll
consider the preprocessing and will retry the rename-back that
Johannes suggested.
>
> * By disabling the parsing of rename header lines, you are
> disabling the sanity checking of the input done in
> gitdiff_verify_name() called from gitdiff_oldname() and
> gitdiff_newname(). I think it is wrong for --no-rename
> option to affect the parsing of the input. If we were to do
> this, perhaps write_out_results() or one of its callee would
> be a better place to do so.
Hopefully git produces sane things so the checking shouldn't be that
important, but I also do a check before beginning with checkouts and
so on, much like git-cvsexportcommit. The check is performed without
the switch.
-- robin
prev parent reply other threads:[~2007-09-27 19:10 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-09-26 21:26 [PATCH] Add --no-rename to git-apply Robin Rosenberg
2007-09-26 22:31 ` Robin Rosenberg
2007-09-27 5:12 ` Junio C Hamano
2007-09-27 10:24 ` Johannes Schindelin
2007-09-27 19:04 ` Robin Rosenberg
2007-09-27 19:12 ` Robin Rosenberg [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=200709272112.29608.robin.rosenberg@dewire.com \
--to=robin.rosenberg@dewire.com \
--cc=git@vger.kernel.org \
--cc=gitster@pobox.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 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 NNTP newsgroup(s).