Re: [PATCH] add -e: ignore dirty submodules

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Dear Junio C Hamano,

On Mon, 6 Feb 2012, Junio C Hamano wrote:

> Johannes Schindelin <Johannes.Schindelin@xxxxxx> writes:
> 
> > We cannot add untracked/modified files in submodules anyway.

The purpose of "add -e" is to stage changes. It does so by presenting a
diff which the user can edit (and applying it after recounting the numbers
in the hunk headers).

If the diff does not apply, it does not make sense to present it to the
user.

Offering to add changes represented by a diff like

diff --git <blub>
<header>
-deadbeef...
+deadbeef...-dirty

does not make sense.

Even a diff like

diff --git <blah>
<header>
-deadbeef...
-coffeebabe...-dirty

would be refused by git-apply.

Indeed, due to the design of the submodules, it is impossible to stage
dirty files in a submodule and a supercommit at the same time. Oh, and this
discussion is not the place to wish for a feature like that, just in case
you want to ask me to implement that in order to be allowed to have my puny
little patch applied. (I guess this is the reason why I waited so long
before I dared to submit the patch to the mailing list.)

Now, due to these concerns, even stripping out the -dirty part can lead to
a comically non-sensical diff like

diff --git <blergh>
<header>
-deadbeef...
+deadbeef...

So keeping the diff generation as-is but preparing the patch by munching
away the -dirty suffix would not fix the problem.

Also, it would be wrong to assume that the user asked to get a status
update. git add -e != git status. If the user wanted to know what changes
are in the worktree, including the worktrees of the submodules, but only
those that have been checked out, git status would be the command to call
(even if it was touted as a git commit --dry-run once upon a time, which
is kind of wrong, see above, you cannot commit the untracked or dirty
files in a submodule, yet git status shows them).

So: showing the fact that a submodule has untracked or dirty files in the
patch that the user wants to edit with git add -e is wrong, wrong, wrong.

The only submodule-related thing we should ever present to the user who
called git add -e is a diff like

diff --git <narf>
<header>
-deadcad...
+beda551ed...

because that is a stageable change.

Alas, salvation is nigh! Yes, just a little line which asks for the level
"dirty" (which implies "untracked", as detailed by diff-options.txt, uhm,
sorry, I was asked to be precise, Documentation/diff-options.txt) fixes
that!

With this flag, there are no more "-dirty" lines in the submodule diffs.
None! Only diffs between different submodule commits are shown, and even
if the worktree of the submodule is dirty, or has untracked files, the
-dirty suffix is omitted. Just what you need for git-apply to work! Yay!

As a plus, it makes the diff generation faster because what cannot be
staged anyway is not even discovered! Super-yay!

I actually enjoyed writing this text so much, may I respectfully ask to
include it verbatim in the commit message?

Thank you very much,
Johannes Schindelin
--
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


[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]