[PATCH 0/3] diff overhaul

[PATCH 0/3] diff overhaul

[Junio C Hamano]

Here are three patches to update diff we discussed earlier.

  [PATCH 1/3] Update mode-change strings in diff output.
  [PATCH 2/3] Rename git-diff-tree-helper to git-diff-helper.
  [PATCH 3/3] Rename git-diff-tree-helper to git-diff-helper (part 2).

The first one is to normalize the mode bits output to be more
machine friendly, which we discussed.

The second commit records only renames for two files and there
is no content change.  The third one is to change the Makefiles,
documentation, and also usage string in git-diff-helper itself.

I am deliverately doing the 2 and 3 in separate steps for two
reasons.  (1) to reduce the possibility of mistakes during the
rename for myself; (2) people doing the git repository browser
can use the commit trail for practicing their rename detection
logic.  So please keep these two steps separate when you commit.

Rename tracking

[Petr Baudis]

Dear diary, on Sat, May 14, 2005 at 03:39:24AM CEST, I got a letter
where Junio C Hamano <junkio@cox.net> told me that...
> Here are three patches to update diff we discussed earlier.
> 
>   [PATCH 1/3] Update mode-change strings in diff output.
>   [PATCH 2/3] Rename git-diff-tree-helper to git-diff-helper.
>   [PATCH 3/3] Rename git-diff-tree-helper to git-diff-helper (part 2).
> 
> The first one is to normalize the mode bits output to be more
> machine friendly, which we discussed.

I'll postpone it for another while since there is still some discussion
about tuning the output.

> The second commit records only renames for two files and there
> is no content change.  The third one is to change the Makefiles,
> documentation, and also usage string in git-diff-helper itself.
> 
> I am deliverately doing the 2 and 3 in separate steps for two
> reasons.  (1) to reduce the possibility of mistakes during the
> rename for myself; (2) people doing the git repository browser
> can use the commit trail for practicing their rename detection
> logic.  So please keep these two steps separate when you commit.

I buy that it is nice for now to keep the changes to the renamed files
separate, but I don't see why should I withhold changing other files
in parallel with the rename.

But I think we really need explicit rename tracking, since this really
sucks. And even if someone would written a hyperintelligent content
moves heuristic tracker, it would be horribly slow on longer distances,
and more importantly it could still be confused when renaming several
similar or same files in parallel.

I'm thinking about using "\n---\n\n" in commit message to separate some
"internal data" like this. cg-log (and web interfaces and other
toolkits, if we get to agree on something common) could then by default
hide it. Below it would contain something which we could hopefully embed
in patches too (actually less work for extracting patches by cg-mkpatch
or similar tools). What do you think?

-- 
				Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
C++: an octopus made by nailing extra legs onto a dog. -- Steve Taylor

Re: Rename tracking

[Junio C Hamano]

>>>>> "PB" == Petr Baudis <pasky@ucw.cz> writes:

PB> I'll postpone it for another while since there is still some discussion
PB> about tuning the output.

What discussion did I miss???

PB> I'm thinking about using "\n---\n\n" in commit message to separate some
PB> "internal data" like this. cg-log (and web interfaces and other
PB> toolkits, if we get to agree on something common) could then by default
PB> hide it. Below it would contain something which we could hopefully embed
PB> in patches too (actually less work for extracting patches by cg-mkpatch
PB> or similar tools). What do you think?

Since I have not been particularly interested in rename tracking
(because I myself personally have not felt the need for it), I
do not offhand have much idea worth to offer.  Sorry.

Re: Rename tracking

[Petr Baudis]

Dear diary, on Sat, May 14, 2005 at 06:05:30PM CEST, I got a letter
where Junio C Hamano <junkio@cox.net> told me that...
> >>>>> "PB" == Petr Baudis <pasky@ucw.cz> writes:
> 
> PB> I'll postpone it for another while since there is still some discussion
> PB> about tuning the output.
> 
> What discussion did I miss???

Mainly

From: Petr Baudis <pasky@ucw.cz>
Date: Sat, 14 May 2005 17:03:56 +0200
Subject: Re: [PATCH] Resurrect diff-tree-helper -R
Message-ID: <20050514150356.GK3905@pasky.ji.cz>

> PB> I'm thinking about using "\n---\n\n" in commit message to separate some
> PB> "internal data" like this. cg-log (and web interfaces and other
> PB> toolkits, if we get to agree on something common) could then by default
> PB> hide it. Below it would contain something which we could hopefully embed
> PB> in patches too (actually less work for extracting patches by cg-mkpatch
> PB> or similar tools). What do you think?
> 
> Since I have not been particularly interested in rename tracking
> (because I myself personally have not felt the need for it), I
> do not offhand have much idea worth to offer.  Sorry.

Well, I'd say that with those renaming patches we are feeling the need
for it?

-- 
				Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
C++: an octopus made by nailing extra legs onto a dog. -- Steve Taylor

Re: Rename tracking

[Junio C Hamano]

>>>>> "PB" == Petr Baudis <pasky@ucw.cz> writes:

PB> Well, I'd say that with those renaming patches we are feeling the need
PB> for it?

Again, not me.  What I did (and asked you to do) was to help
_others_ who are interested in rename tracking, not me.  Find
the following message in the archive if you want to know why I
am not in urgent need for rename tracking.

    To:	Linus Torvalds <torvalds@osdl.org>
    Cc:	David Greaves <david@dgreaves.com>, git@vger.kernel.org
    Subject: GIT blame (was Re: Quick command reference)
    From:	Junio C Hamano <junkio@cox.net>
    Date:	Fri, 06 May 2005 02:32:30 -0700
    X-Mailing-List:	git@vger.kernel.org

    >>>>> I == Junio C Hamano <junkio@cox.net> said:

    JCH> Linus, please pull from git-jc.git archive at:
    JCH>     http://members.cox.net/junkio/git-jc.git/

    Since that message I have added a couple more commits there.
    One of the things is a backport of -t (tag) flag to git-ls-files
    from Cogito fork.

    The reason I am writing this message is not because I am excited
    about the backport [*1*], but because I find it quite cool the
    way I found out which commit in Pasky's development line
    introduced the change.  It demonstrates your previous "renames
    does not matter when doing CVS blame" argument actually works.

    Here is what I did: ... (the rest omitted) ...