Re: 'git add' option to non-interactively stage working tree changes

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hrvoje NikÅiÄ <hniksic@xxxxxxxxx> writes:

> Thanks for the tip. I'll note that this is not exactly easy to
> discover, though, and it's quite some typing. Since git add -p and git
> add -i seem capable of determining the root themselves, maybe there
> should be a way to do the same for -u? Or even make it the default?

The general design principle when talking about an operation to build
towards the next commit is to limit the operation to the current working
directory when working from a subdirectory, so I would have to say that
what -p and -i do is wrong, but this is already a very well established
behaviour and there is no way to change the default (the same thing can be
said for what -u does).

I think it might be Ok to introduce a --full-tree option to "git add" (and
"git grep"), though.  But introduction of corresponding configuration
variable to flip the default needs to be done carefully in steps across
major version boundaries as usual (i.e. first introduce --no-full-tree,
wait for 9 to 12 months to make sure scripts are updated, then start
honoring add.fullTree and grep.fullTree configuration variables).
--
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


[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]