Re: [PATCH] pathspec: adjust prefixlen after striping trailing slash

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

 



Am 21.04.2015 um 23:08 schrieb Junio C Hamano:
Duy Nguyen <pclouds@xxxxxxxxx> writes:

On Mon, Apr 20, 2015 at 12:37 PM, Junio C Hamano <gitster@xxxxxxxxx> wrote:
Duy Nguyen <pclouds@xxxxxxxxx> writes:

But if you look at it another way, "cd subrepo; git add ." should be
the same as "git add subrepo" ...

Once you cd into "subrepo", you are in a different world, a world
different from the toplevel project.  "git add ." over there should
mean "add everything in subproject's working tree to subproject's
index", shouldn't it?  On the other hand, "git add subrepo" without
leavingin the working tree of the superproject is about binding the
submodule to the superproject's index.

I do not think these two should be the same.  Where am I mistaken?

I think I wrote this sentence and deleted it: I didn't say which way
was right.

OK.

I looked at the test script update.  The new test does (I am
rephrasing to make it clearer):

     mkdir -p dir/ectory
     git init dir/ectory ;# a new directory inside top-level project
     (
         cd dir/ectory &&
         >test && git add test && git commit -m test
     )
     git add dir/ectory

to set it up.  At this point, the top-level index knows dir/ectory
is a submodule.

Then the test goes on to turn it a non submodule by

     mv dir/ectory/.git dir/ectory/dotgit

At this point, I think there are two valid things that can happen.

  (1) "git add test" inside dir/ectory removes the submodule entry
      "dir/ectory" and then adds dir/ectory/test as an individual
      entry.  After all that is what happens when you replace a file
      with a directory, e.g.

        >folder && git add folder
        rm folder
        mkdir folder && >folder/file &&
        git -C folder add file

      will first register a regular file "folder" and then replace
      that with paths underneath.

      It would be the same if you did any of the following:

        git -C . add dir/ectory/test
        git -C dir add ectory/test
        git -C dir/ectory add test

  (2) "git add test" inside "dir/ectory" would barf, saying
      "dir/ectory is supposed to be a submodule and you have to first
      remove it".  Again, it would be the same if you did so from any
      directory with relative paths.

I think (2) is less optimal than (1), but it could be the best we
could do if the submodule infrastracture around .gitmodules and
links to $GIT_DIR/modules/$name may have to get involved in an
operation like this (I didn't check).

We already do (2) in the cases you describe:

   $ git add subrepo/a
   fatal: Pathspec 'subrepo/a' is in submodule 'subrepo'
   $ git -C subrepo add a
   fatal: Pathspec 'a' is in submodule 'subrepo'

And I believe that is better than (1), because when removing a
submodule its entry in .gitmodules should also be removed. And
I suspect that adding a file in a submodule to the superproject
will happen more by accident than on purpose (which cannot
happen for files because when you add a new file in a directory
for which git still records a file the latter can be safely
removed as that entry cannot be a file in the worktree anymore).

So I'd vote to have (2) also for "git -C subrepo add .", which
is what started this thread.

In my quick test, it appeared that the behaviour with this patch
applied was neither of the two and instead to silently do nothing,
and if that is the case I think it is quite wrong.

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