# gitignore and shared worktrees (was: finding the right remote branch for a commit) 3 messages from 2007-07-17 to 2007-08-17. Participants: martin f krafft, Johannes Schindelin. Thread: https://gitlist.dev/t/9070 ## martin f krafft, 2007-07-17 13:09 Subject: gitignore and shared worktrees (was: finding the right remote branch for a commit) Message-ID: <20070717130936.GA19724@piper.oerlikon.madduck.net> URL: https://gitlist.dev/e/20070717130936.GA19724%40piper.oerlikon.madduck.net ``` Sorry for the somewhat late reply, I just found time on the weekend to check out this suggestion by Johannes (http://marc.info/?l=git&m=118418927823760&w=2) also sprach Johannes Schindelin [2007.07.11.2126 +0200]: > Come to think of it, this is maybe what I would have done, but it > appears to me that this is the _ideal_ use case for worktree: > > In $HOME/gits: > > $ mkdir vim.git && cd vim.git > $ git --work-tree=$HOME init > $ cat >> info/exclude < EOF > * > !/.vimrc > EOF > > Then you could do all Git operations like push, fetch, pull, log in > $HOME/gits/vim.git, and all editing in $HOME. This actually seems to work really nicely, but I am somewhat displeased by the gitignore/exclude handling, since it's local. What I want to do is synchronise the vim configuration across many workstations with git, and I don't want to have to modify $GIT_DIR/info/exclude on each machine. So I am tempted to use .gitignore, but that lives in the worktree, and since the suggestion is to share worktrees between different git repos, I can only ever have one .gitignore file, which would have to list ignores for *all* repos in $HOME/gits, which breaks my head. Do you have any other idea on how to handle ignores? I guess one alternative is just to ignore git status output altogether, but that's not really nice. Would people consider honoring .gitignore-* in addition to just .gitignore? Or maybe even honouring .gitignore/*, if .gitignore is a directory, not a file? Cheers, -- martin; (greetings from the heart of the sun.) \____ echo mailto: !#^."<*>"|tr "<*> mailto:" net@madduck spamtraps: madduck.bogus@madduck.net "i like .net for the same reason i like gentoo. it keeps all the people with no clue from writing c code, which is much harder for me to identify and eliminate from my systems. in the same way that gentoo gives those people a place to be that isn't in debian" -- andrew suffield ``` ## martin f krafft, 2007-08-16 10:22 Subject: gitignore and shared worktrees (resend) Message-ID: <20070816102225.GA5351@piper.oerlikon.madduck.net> URL: https://gitlist.dev/e/20070816102225.GA5351%40piper.oerlikon.madduck.net In-Reply-To: <20070717130936.GA19724@piper.oerlikon.madduck.net> ``` I sent the following message a month ago to the mailing list and never got a reply. Just to make sure it didn't simply get overlooked, I am reposting. Basically the issue is with using multiple git repos all sharing the same worktree, and that I cannot come up with a sensible way to maintain the .gitignore file such that it is part of the repo (and thus exists in other clones as well). I found that one can actually add and commit $GIT_DIR/info/exclude to a repo (quite possibly a bug), but the checkout fails without -f, so this is not really an option. I could set core.excludesfile to some unique name, but that again is not saved in the repository and requires manual intervention after cloning. I still like best the suggestion to honour .gitignore/* in case .gitignore is a directory instead of a file. Would people be interested in a patch for this? ----- Forwarded message from martin f krafft ----- Date: Tue, 17 Jul 2007 15:09:36 +0200 From: martin f krafft To: git@vger.kernel.org Cc: Johannes Schindelin Subject: gitignore and shared worktrees (was: finding the right remote branch for a commit) Message-ID: <20070717130936.GA19724@piper.oerlikon.madduck.net> Sorry for the somewhat late reply, I just found time on the weekend to check out this suggestion by Johannes (http://marc.info/?l=git&m=118418927823760&w=2) also sprach Johannes Schindelin [2007.07.11.2126 +0200]: > Come to think of it, this is maybe what I would have done, but it > appears to me that this is the _ideal_ use case for worktree: > > In $HOME/gits: > > $ mkdir vim.git && cd vim.git > $ git --work-tree=$HOME init > $ cat >> info/exclude < EOF > * > !/.vimrc > EOF > > Then you could do all Git operations like push, fetch, pull, log in > $HOME/gits/vim.git, and all editing in $HOME. This actually seems to work really nicely, but I am somewhat displeased by the gitignore/exclude handling, since it's local. What I want to do is synchronise the vim configuration across many workstations with git, and I don't want to have to modify $GIT_DIR/info/exclude on each machine. So I am tempted to use .gitignore, but that lives in the worktree, and since the suggestion is to share worktrees between different git repos, I can only ever have one .gitignore file, which would have to list ignores for *all* repos in $HOME/gits, which breaks my head. Do you have any other idea on how to handle ignores? I guess one alternative is just to ignore git status output altogether, but that's not really nice. Would people consider honoring .gitignore-* in addition to just .gitignore? Or maybe even honouring .gitignore/*, if .gitignore is a directory, not a file? Cheers, -- martin; (greetings from the heart of the sun.) \____ echo mailto: !#^."<*>"|tr "<*> mailto:" net@madduck fashions have done more harm than revolutions. -- victor hugo spamtraps: madduck.bogus@madduck.net ``` ## Johannes Schindelin, 2007-08-17 22:21 Subject: Re: gitignore and shared worktrees (resend) Message-ID: URL: https://gitlist.dev/e/Pine.LNX.4.64.0708172320380.20400%40racer.site In-Reply-To: <20070816102225.GA5351@piper.oerlikon.madduck.net> ``` Hi, On Thu, 16 Aug 2007, martin f krafft wrote: > Basically the issue is with using multiple git repos all sharing the > same worktree, and that I cannot come up with a sensible way to maintain > the .gitignore file such that it is part of the repo (and thus exists in > other clones as well). I saw your message, but I could not come up with a reasonable solution. Ciao, Dscho ```