quoted
quoted
quoted
quoted
"DB" == Daniel Barkalow [off-list ref] writes:
DB> On Sat, 4 Jun 2005, Junio C Hamano wrote:
quoted
BTW, don't we want to have them renamed to git-ssh-pull (and
git-ssh-push) for consistency with other transports, before 1.0
happens?
DB> I think that would be good, but I'm still using a really old version of
DB> git for my development, so I don't have your diff rename support; could
DB> you send a patch to do it?
I am sorry, but you lost me. I am afraid that I do not
understand what you are asking me to send you: a patch to do
what? Tell your old git how to do -M/-C? That would be "the
tip of Linus repository"...
Ah (lightbulb!), are you asking me to send the patch in the
git-extended rename diff format, like this?
$ git-diff-cache -p -B -C HEAD
diff --git a/Documentation/git-rpull.txt b/Documentation/git-ssh-pull.txt
similarity index 89%
rename old Documentation/git-rpull.txt
rename new Documentation/git-ssh-pull.txt
--- a/Documentation/git-rpull.txt
+++ b/Documentation/git-ssh-pull.txt
@@ -1,20 +1,20 @@
-git-rpull(1)
-============
+git-ssh-pull(1)
+===============
v0.1, May 2005
...
I am not sure if this is suitable for patch submission. I did
the rename/copy stuff mostly for software archaeology purposes
(meaning, you examine what is in your repository), not to
generate patches for submission via e-mail.
It certainly is a good test for the git-apply stuff Linus has
been working on, and in addition it would have a good amusement
value to see how well it would work (or how badly it would barf
;-), but I suspect Linus (or, rather, his "dotest" script) would
appreciate it more if it came in the traditional diff format
that does not use the rename stuff. I dunno. Let's ask Linus
first.
Linus, can your workflow grok things like this, or do you prefer
patch submission to use traditional diff format without renames?
On Sat, 4 Jun 2005, Junio C Hamano wrote:
Ah (lightbulb!), are you asking me to send the patch in the
git-extended rename diff format, like this?
$ git-diff-cache -p -B -C HEAD
diff --git a/Documentation/git-rpull.txt b/Documentation/git-ssh-pull.txt
similarity index 89%
rename old Documentation/git-rpull.txt
rename new Documentation/git-ssh-pull.txt
--- a/Documentation/git-rpull.txt
+++ b/Documentation/git-ssh-pull.txt
@@ -1,20 +1,20 @@
-git-rpull(1)
-============
+git-ssh-pull(1)
+===============
v0.1, May 2005
...
Right. I hadn't actually been following the discussion entirely, but it
certainly seems like one major benefit of the rename/copy stuff is that it
will generate more readable diffs. That is, I can see what you changed in
the process of renaming the file, and don't have to inspect all the lines
you didn't change to see that they're the same.
I am not sure if this is suitable for patch submission. I did
the rename/copy stuff mostly for software archaeology purposes
(meaning, you examine what is in your repository), not to
generate patches for submission via e-mail.
I think that examination by mailing list subscribers is a very similar
situation, and it makes sense to apply exactly the patch that has been
checked.
It certainly is a good test for the git-apply stuff Linus has
been working on, and in addition it would have a good amusement
value to see how well it would work (or how badly it would barf
;-), but I suspect Linus (or, rather, his "dotest" script) would
appreciate it more if it came in the traditional diff format
that does not use the rename stuff. I dunno. Let's ask Linus
first.
I think I like best what you actually did: send it both ways. Having a
test case that's a real change someone wants to make as well as a
reference for how it should come out helps a lot in debugging. And I can
tell that the rename-using version is what I wanted, and the
non-rename-using version is also must be good if the results match.
-Daniel
*This .sig left intentionally blank*
On Sat, 4 Jun 2005, Junio C Hamano wrote:
Linus, can your workflow grok things like this, or do you prefer
patch submission to use traditional diff format without renames?
I haven't made "git-apply" do the final part yet: it doesn't actually
apply anything. So I'm still using standard patch in my workflow.
But that's largely been because I haven't been hugely motivated to fixing
it yet. I will now correct that.
Let's see if I can do the last mile now.
Linus