git/list[1] front-page[2] threads[3] people[4] search[5] about
 

Re: Problem: staging of an alternative repository

From
PBPasha Bolokhov <pasha.bolokhov@gmail.com>
Date
May 17, 2014, 16:31 UTC
Message-ID
<CAKpPgvdC3VEHoW4eqmjoPtr4Duh8hkaeHL-JehaVMVUAdGhLAw@mail.gmail.com>
In-Reply-To
<CACsJy8C4bO_ZB-DMOkbJc9cJd_LmR6z0RZ1UZB3wKPEX005xmA@mail.gmail.com>
        Hi again
    I've come up with a fix for this. It's just two and a half lines,
and required more studying the code than typing.
A lot of path-processing work has been implemented in "abspath.c" and
"dir.c", including the symlinks and checking whether one path is a
subdirectory of another. I just added an "exclude" for GITDIR without
touching anything else.
    Now the best place to add that exclude would probably be "git.c",
right after the option "--git-dir" is processed. But this is not
actually the place where excludes are initialized or used any how.
Since initialization of excludes is done more or less individually by
each command concerned about them, the most "centralized" place
happens to be dir:setup_standard_excludes(), and that's where I did
it. One of the (side?) effects is that the excludes work in such a way
that any directory named ".metadata" in the directory tree will be
ignored once "-git-dir=.metadata" has been given
    Now if you guys don't see anything against this, I would shoot out a patch?
    regards
Pasha
On Thu, May 1, 2014 at 11:20 PM, Duy Nguyen <pclouds@gmail.com> wrote:
Show 25 quoted lines
> On Thu, May 1, 2014 at 4:35 AM, Jonathan Nieder <jrnieder@gmail.com> wrote:
>>>     Now I know, the '--git-dir' option may usually be meant to use
>>> when the repository is somewhere outside of the work tree, and such a
>>> problem would not arise. And even if it is inside, sure enough, you
>>> can add this '.git_new' to the ignores or excludes. But is this really
>>> what you expect?
>>
>> I think it's more that it never came up.  Excluding the current
>> $GIT_DIR from what "git add" can add (on top of the current rule of
>> excluding all instances of ".git") seems like a sensible change,
>> assuming it can be done without hurting the code too much. ;-)
>
> I think it came up before. Changes could be very messy (but I did not
> check carefully) because right now we just compare $(basename $path)
> with ".git", one path component, simple and easy. Checking against
> $GIT_DIR means all path components. You also have to deal with
> relative and absolute paths and symlinks in some path components. You
> may also need to think if submodule detection code (checking ".git"
> again) is impacted. On top of that, read_directory() code is already
> messy (or at least scary to me) with all kinds of shortcuts we have
> added over the years. A simpler solution may be ignoring all
> directories whose last component is  "$GIT_DIR_NAME" (e.g.
> GIT_DIR_NAME=.git_new).
> --
> Duy
Previous: Pasha BolokhovNext: Duy Nguyen
Message 6 of 7 in “Problem: staging of an alternative repository”
  1. Pasha BolokhovApr 30, 2014
  2. Jonathan NiederApr 30, 2014
  3. Pasha BolokhovMay 2, 2014
  4. Duy NguyenMay 2, 2014
  5. Pasha BolokhovMay 7, 2014
  6. Pasha BolokhovMay 17, 2014
  7. Duy NguyenMay 19, 2014

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.