On Fri, Mar 25, 2011 at 12:59:34PM -0500, Neal Kreitzinger wrote:
> We deleted (git-rm) a file from the repo by mistake. Several commits later
> we restored it (git-checkout, git-commit). Git status shows "added" for
> this file. IMHO, it seems like git status should be "restored" or
> "unremoved", etc, for this file. Git detects renames and copies so it seems
> like it could detect restores.
I am mildly negative on the idea, though I think it is mostly just
because I would not find that information useful at all.
But what gives me pause is that it is adding a totally new dimension to
git-status. Currently status is about three things:
1. What's in your index, and how does it differ from what's in HEAD.
2. What's in your working tree, and how does it differ from what's in
your index.
3. What untracked files are in your working tree.
So it is only about HEAD, the index, and the working tree, and we only
have to look at those things. We detect copies and renames, yes, but
only in the diffs between those points.
But what you are proposing requires looking backwards in history to see
if we used to have something like the thing that has been added. So that
introduces a few questions:
1. What are we claiming to have "used to have"? Some arbitrary content
at the same path, or similar content at the same path, or similar
content at any path?
2. Which history do we look at? Do we start traversing backwards from
HEAD? If so, how far back do we go (you probably don't want to go
to the roots, which is expensive)? Is it useful to see similar
files on other branches (e.g., instead of "you are adding foo,
which is being resurrected from 'HEAD~20: remove foo'", you would
find out that "you are adding foo, which has also been added on
branch 'topic'").
3. How expensive is the test going to end up? For generating a commit
template or running "git status", it's probably OK. But keep in
mind also that people run "git status --porcelain" to generate
their shell prompt. So it needs to either be really fast, or it
needs to be easy to turn it off in some cases.
-Peff
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html