Thomas Rast <trast@xxxxxxxxxxxxxxx> writes:
> Robin Rosenberg wrote:
>> Git itself does not even look at this directory.
Modern git Porcelains write remote definitions solely to .git/config, but
still reads from .git/{branches,remotes}. What we do not do is to update
these locations, and we do not need to have these locations to operate.
So "not even look at" is too strong; it just "not touch".
I do not think there is reason to change that part of the equation. For
people who need to fetch and merge hundreds of random places, it is a lot
handier to be able to do
echo "$url#$branch" >.git/branch/$nickname
rm .git/branch/$nickname
to manage the set of locations added to and deleted from the daily
compose. Andrew Morton explicitly asked for this to be kept a few years
ago and I do not see a reason to deprecate this.
Now, not installing an empty .git/branch directory does break the above
workflow. You would need to mkdir _once_ yourself, but I do not think
that is such a big deal.
On the other hand, I do not think it is such a big deal to have otherwise
unused .git/branches/ directory, either. Robin wrote:
Shawn and other wants to stop JGit from creating this directory on
init with the motivation that newer Git version doesn't create it
anymore. This patch would make that assertion true.
and after re-reading it, I realize "the motivation" is not a motivation at
all---it is merely an excuse ("after this patch is applied, git wouldn't
create it anymore"---so JGit will have an excuse not to do so). It does
not say _why_ it shouldn't be there in the first place. IOW, we need to
fill in the blank in: "JGit is merely following suit; the reason git
stopped creating the directory is ________").
This patch alone breaks tests in the t55?? series quite a lot, and I am
tempted to revert it. My time is more valuable than fixing the fallouts
from this change, when the real purpose of the change is not yet stated.
--
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