Re: GIT_CEILING_DIRECTORY
On Mar 09, 2016, at 09:29 AM, Junio C Hamano wrote: >Let me understand the use case. You have $HOME/.git that governs >everything under $HOME, but there are parts of $HOME/, such as >$HOME/projects/*, that will never be controled by $HOME/.git? Correct. >Two obvious reactions are: > > - hopefully $HOME/.gitignore covers these non-git parts by having > entries like '/projects/'; this should not affect the behaviour > of CEILING though. Correct. In this case, $HOME/.gitignore has `projects` so `git status` etc. in $HOME does the right thing. > - typing "git status" inside $HOME/projects/ does not make much > sense in the first place. True, and normally I wouldn't do this explicitly, but it comes up because I have a bash prompt that shows me the status of the current directory ($GIT_PS_*) so even when I just cd to ~/projects I see status for $HOME. >I _think_ the "are we in a Git-managed working tree and if so, then >where is the .git directory?" discovery works like this: [...] >So setting $HOME/projects as one of the elements in the CEILING list >would not stop us going up if you are actually at $HOME/projects, >but we would stop if you started from $HOME/projects/python. And indeed, that works great. >This somehow sounds a bit inconsistent to me, but I say "a bit >inconsistent" because "Why do we give different answer to 'is >$HOME/projects/python governed by $HOME/.git?' depending on where we >start the discovery process?" is a non-argument (i.e. that is not >the question CEILING is answering). > >I have a feeling that we must have done that for a reason. It may >be interesting to see what breaks in t1504 if the above logic is >updated to stop when you start at a CEILING (unlike the current code >where it stops only when you start below a CEILING). That would be interesting; it seems like it would solve my use case. Cheers, -Barry pgpmdzd7gaNBk.pgp Description: OpenPGP digital signature
GIT_CEILING_DIRECTORY
I put my home directory under git (recently converted from bzr), but since I have some subdirectories under $HOME that are not under git (and some that are) I want to stop e.g. `git status` from traversing up into $HOME. For example, I have a ~/projects directory with lots of subdirectories so when I'm in e.g. my CPython Mercurial checkout (~/projects/python), I don't want git to go higher than ~/projects GIT_CEILING_DIRECTORIES seems like exactly the thing I want, so I set it to ::$HOME/projects and this works great... unless I'm actually in ~/projects in which case `git status` shows me the status of the $HOME repository. I tried setting this to just $HOME, but that has the undesired side-effect of blocking $HOME status when I'm in a subdirectory that *is* part of the base repo, e.g. ~/env. IOW, with GIT_CEILING_DIRECTORIES=$HOME and I cd into ~/env, I don't get any status. So I'm wondering whether this should be considered a bug in git, or if there's some other way to handle this corner case, or whether it's working as intended and I just have to live with it. Cheers, -Barry pgpQCGQi2SG0P.pgp Description: OpenPGP digital signature
Re: Git's inconsistent command line options
On Sep 01, 2015, at 09:42 AM, Junio C Hamano wrote: >That way, you are forcing all the existing scripts to be updated to >say "git -c ..." for _all_ invocations of Git they have, aren't you? No, why? If the default value enables the current ui, then no scripts need changing. Users can enable the new ui for their own benefit at their own pace. If you eventually want to make the new ui the default, provide a sufficient transition period. Cheers, -Barry pgpxOXAlcusGr.pgp Description: OpenPGP digital signature
Re: Git's inconsistent command line options
On Sep 01, 2015, at 02:28 AM, David Aguilar wrote: >While a script writer could write, "git -c core.cliversion=1 ...", >no one does that, no one wants to do that, and it just seems >like a bad idea that's best left unexplored. Sure, no one will do that from the command line, but I don't think people generally change their preferences that often. Much more likely is that they'll `git config` a more permanent choice for their shell usage and then just use straight up "git" with the new ui. -c would be reserved for scripts which hard code a particular ui. >Otherwise, this entire thread seems like a big non-issue. The existing CLI >hasn't hurt adoption... A significant factor driving git adoption is network effects. That's highly motivating to overcome discomfort or confusion with the cli. Once you've lost your beginner's mind, you are much less aware of the cli inconsistencies and disconnects from other vcses. The latter might not affect new users whose only experience with vcses is git, but it presents a steeper learning curve for folks migrating from other tools. >...and tossing a config option at it only makes it worse. The best config is >no config. git already has no shortage of configuration options. ;) Cheers, -Barry pgp26Yg4JQ0kL.pgp Description: OpenPGP digital signature
Re: Git's inconsistent command line options
On Aug 31, 2015, at 05:10 PM, Duy Nguyen wrote: >I'm probably shot down for this. But could we go with a clean plate >and create a new command prefix (something like git-next, git2, or >gt...)? We could then redesign the entire UI without worrying about >backward compatibility. At some point we can start to deprecate "git" >and encourage to use the new command prefix only. Of course somebody >has to go over all the commands and options to propose some consistent >UI, then more discussions and coding so it could likely follow the >path of pack v4.. `git` itself could also be a thin wrapper which consulted a configuration variable to see which version of the ui to expose. "All problems in computer science can be solved by another level of indirection" Cheers, -Barry pgpFxZ3we9pOm.pgp Description: OpenPGP digital signature
