threads / patch / 606

patch, 3 partsdiff overhaul

Subject: [PATCH 0/3] diff overhaul

## tl;dr

5 messages between May 14, 2005 and May 14, 2005. Diffs are folded; open one to read it.

replies: 4people: 2as markdown or json

Junio C Hamano· May 14, 2005, 01:39 UTC · lore

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.

Petr Baudis· May 14, 2005, 15:11 UTC · re: Junio C Hamano · lore

Rename tracking

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...

Show 8 quoted lines

> 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.

Show 9 quoted lines

> 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

Junio C Hamano· May 14, 2005, 16:05 UTC · re: Petr Baudis · lore

Re: Rename tracking

>>>>> "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.

Petr Baudis· May 14, 2005, 16:21 UTC · re: Junio C Hamano · lore

Re: Rename tracking

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...

Show 6 quoted lines

> >>>>> "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>

Show 10 quoted lines

> 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

Junio C Hamano· May 14, 2005, 16:36 UTC · re: Petr Baudis · lore

Re: Rename tracking

>>>>> "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) ...