Re: Bug Report: git add
- From
Junio C Hamano <gitster@pobox.com>
- Date
- Apr 11, 2011, 17:55 UTC
- Message-ID
- <7v1v18y8oc.fsf@alter.siamese.dyndns.org>
- In-Reply-To
- <m31v1a4keq.fsf@localhost.localdomain>
Jakub Narebski <jnareb@gmail.com> writes:
> Currently I have TODO file in gitweb/ subdirectory, which is stored in > gitweb/.git repository. Still it doesn't prevent me from "git add"-ing > e.g. 'gitweb/gitweb.perl' to git repository itself.
I would have to say that it is somewhat a sensible thing to want to do from an individual contributor's point of view to keep track of personal notes on a subpart of a project in a separate repository.
It however directly contradicts with the approach I suggested earlier, which resulted in Peff's patch
http://thread.gmane.org/gmane.comp.version-control.git/170937/focus=171040
and will be broken, I think.
We could skip the check for a directory D where there already is a path D/P (where P has one or more path components, e.g. "file", "subdir/file") tracked and check only if D/.git is a git directory when adding path in D if there is no other D/P is tracked (and perhaps require --force), if we really wanted to keep supporting what you are doing. But I do not think it is worth doing, considering the possibility that such a loophole would lead to even more confusing behaviour to new users.
If there is an equally easy way of keeping track of personal notes in a subpart of a larger project like you do, without having an unrelated .git/ directory in a worktree that is controlled by a project and mixing files in a single directory in such a way that some belong to the main project while others belong to the unrelated "personal notes" project, I would rather see us recommend such an approach, and declare that your use case is forbidden, as it would give us a far easier to explain rule: "files in one directory can be controlled only by one .git/ directory".
Besides, if the subpart of the project you are interested in and want to have personal notes about were at the top-level of the project, you wouldn't be using the same workflow as you currently do, as you cannot obviously have two .git/ at the same level.