Re: [PATCH] Detect renames in diff family.

quoted

quoted

quoted

quoted

"LT" == Linus Torvalds [off-list ref] writes:

LT> Hmm.. You're right, but it feels kind of wrong. Clearly we
LT> support removals in diff-files, but you're right, we can
LT> never have something show up as an addition, since we only
LT> ever compare against files that are already mentioned in the
LT> cache.

LT> Or am I just being confused and/or stupid?

No, you are not confused nor stupid.  We discussed something
related to this about three weeks ago.  We ended up not doing
what we discussed, but if we had adopted the convention of the
delayed addition to the cache I described as "magic SHA1" in the
quoted message below, that would have been the "intent to add"
that diff-files would report as an addition.

To:	Linus Torvalds <torvalds@osdl.org>
Cc:	git@vger.kernel.org
Subject: Re: [PATCH] Really fix git-merge-one-file-script this time.
From:	Junio C Hamano <redacted>
Date:	Sun, 01 May 2005 11:38:15 -0700
Message-ID: [ref]

 (... some discussion omitted ...)
I am wondering if the following changes would make sense and
make things easier for you:

 * git-merge-one-file-script is changed to register the path
   with --cacheinfo using magic SHA1 0{40} instead of using the
   resulting file on the filesystem.  Do keep the current
   behaviour of leaving the merge results of trivial merges
   (both kind) in the work tree.

 * git-write-tree is changed to refuse to write from a cache
   that records the magic SHA1.

 * git-ls-files acquires a new option --merged to notice the
   magic SHA1 and shows the paths that have such SHA1.

 * git-update-cache acquires a new option --resolve to notice
   the magic SHA1 and:

   - if the named path is not in the work tree anymore, delete
     the entry.

   - if the named path exists in the work tree, compute the
     latest SHA1 for that file and update the entry.

Changes other than the first two listed above are purely
optional, since the Porcelain layer can implement them without
the Plumbing support.  Not doing them would keep the Plumbing
somewhat cleaner by not having to know about this magic SHA1
convention.  On the other hand, we already use that convention
in git-diff-cache, so it may even be a consistent change to make
these optional changes.  Essentially, the magic SHA1 in the
cache means "I know the user wants me to keep an eye on this
path when it matters" [*2*].

[Footnotes]

 (... footnote *1* omitted ...)

*2* This convention would also make an implementation of "SCM
add" in the Porcelain layer a bit more efficient.  A typical
workflow without such a convention would consist of:

 * Create a file and start editing.
 * "SCM add" file, causing "git-update-cache --add -- file".
 * Do more changes, and review.
 * "SCM commit" which does"git-update-cache" changed files,
   "git-write-tree" and "git-commit-tree" to commit.

which wastes one extra blob object per "SCM add".  My gut
feeling is that more than 80% of the time "SCM add" is followed
by some edit to the added file before "SCM commit", unless it is
the initial import.  If we adopt that convention, "SCM add"
would register with --cacheinfo with the magic SHA1 without
creating the useless blob, and "SCM commit" will be written to
lazily pick things up from the work tree.