Elijah Newren <newren@xxxxxxxxx> writes: > On Tue, Feb 19, 2019 at 11:10 AM Junio C Hamano <gitster@xxxxxxxxx> wrote: >> >> Junio C Hamano <gitster@xxxxxxxxx> writes: >> >> > I am getting the impression that to save typing, you would want to >> > make "--index --worktree" the default (i.e. among the above, only >> > --no-index and --no-worktree need to be spelled explicitly), but >> > there is one glitch. Updating from the index must be spelled >> > explicitly with "--no-index --worktree". >> >> And after getting reminded by Elijah, the default pair is >> <--no-index, --worktree>. > > Why would you want --no-index or --no-worktree as flags? That seems > to presume a default of modifying both the index and the working tree, > as these names imply undoing pieces of such a default. By "flags" I think you mean "treat them as two orthogonal booleans"? It was just how I read Duy's examples (especially the "both --index and --worktree given" example where "--source <tree>" becomes mandatory). I do not have strong preference either way myself, but I tend to think that treating these as two independent booleans would be a way to make it clear that the new design departs from what we have been doing (i.e. "--index" means "both", "--cached" means "index only" and if we were to introduce the "cat-file -p >" variant that would be called "--worktree-only"; in these, there is no "two orthogonal booleans" that can be mixed---instead they come premixed). > I'd rather have a flag like --worktree which alone only modifies the > working tree and is presumed to be the default (but useful to be > explicit or as mentioned later), have a flag for applying the changes > to the index instead (--index?), and treat applying to both the > working tree and the index as unusual and require either both flags > (--worktree --index ?) or some special flag that likely has a longer > name (--worktree-and-index?). So you are in favor of pre-mixed set of options, all are mutually exclusive. Which I am perfectly fine with. I however do think "both worktree and index" is quite common when tweaking the tree to prepare for the next commit. A path with contents freshly taken out of an existing tree may not match exactly what you plan to record in your next commit, and you would not be recording it immediately in a commit as-is. But having the contents taken from an existing tree recorded as the baseline in the index would make "git diff (no tree-ish) <path>" a handy tool to review your progress toward the next commit since that baseline state, in addition to "git diff HEAD <path>" that is the usual "how does the overall change relative to the parent of the commit I am preparing for look like". So I'd hesitate to endorse "a deliberately longer and harder to type option" to populate both the index and the working tree files at the same time.
