Re: What's cooking in git.git (Mar 2009, #06; Sat, 21)
- From
Wincent Colaiuta <win@wincent.com>
- Date
- Mar 22, 2009, 15:54 UTC
- Message-ID
- <FC18101D-268C-40DF-9733-598EE25CAFA6@wincent.com>
- In-Reply-To
- <7vskl6ekve.fsf@gitster.siamese.dyndns.org>
El 21/3/2009, a las 20:28, Junio C Hamano escribió:
Show 16 quoted lines
> Wincent Colaiuta <win@wincent.com> writes: > >>> Given that git-difftool shares basically all the same options as >>> "git diff", I think a good long-term plan would be looking at adding >>> the "--tool" option to "git diff" itself so that users wouldn't have >>> to learn a new subcommand, just a new option. >> >> What do people think? > > I am not "people" but since I was "To:"ed not "Cc:"ed... > > I did not comment on it because personally I was not very interested > in > it; admittedly, I do not use difftool myself, but: > > (1) "git diff --tool" is more to type than "git difftool"; and
True, although an alias would fix that.
> (2) it requires adding more code to "git diff" for a dubious benefit > from > end user's point of view.
Fair enough. I was just wondering if we could avoid adding yet another command to the already long list of installed commands. I understand that "diff" is actually a thin dispatcher for different modes of operation, but seeing as all of those modes basically boil down to "show me the difference between two things", and that happens to be the purpose of "difftool" as well, I thought it might make sense to combine them.
Show 27 quoted lines
> When an end user says "I want to compare two things with these > settings > (e.g. use color, with 5 lines of context, only inside Documentation/ > howto > directory, detect renames with lower-than-usual threashold, ...)", the > mental model is same whether the two things being compared happens > to be > index-vs-worktree or tree-vs-index from the end user's point of > view. It > makes a lot of sense for "git diff --options" to invoke both modes of > operations with a similar-looking command line. > > Even though the --no-index mode of operation internally does not fit > very > well compared to the original four modes from the implementation > point of > view, it still naturally fits the end user's mental model and that > is why > it is given as an option to "git diff". > > Does "git difftool" fit well in the end user's mental model in a > similar > way to "git diff"? I somehow suspect it doesn't. What does it mean > to > give "-U8 --color --stat --summary -p --ignore-space-at-eol" options > when > you invoke it, for example?
Good question. Seeing as right now "difftool" just passes all options through to "diff", I guess it's up to the user to pass in options which actually make sense.
Cheers, Wincent