On Fri, 10 Jul 2011, Michael Nahas wrote: > Jakub Narebski wrote: > > 'git diff' / 'git diff --cached' / 'git diff HEAD' is about use cases > > (or "user stories"). 'git diff NEXT WTREE' / 'git diff HEAD NEXT' / > > / 'git diff HEAD WTREE' are about mechanism. > > Would you say that the UNIX commands "find", "grep", and "xargs" are > about use cases? I rarely use them by themselves. They clearly > manipulate concepts: files and lines. So, it's easy for me to think > what this does: > > find . | grep "\.h" | xargs grep MyClass | grep public You do know that this is way suboptimal, even if you don't have 'ack' installed, and don't use "git grep --no-index"? > > I'm trying to find concepts the concepts that git manipulates and I > think NEXT and WTREE are part of those concepts. > > It is my opinion that if we focus on concepts, we'll be able to create > general commands and that the user will be able to combine the > commands in new and interesting ways, like I combined the UNIX > commands above. > > I believe in "common" use cases. The common case should be fast. I > have always recommended still allowing "git diff" by itself. > > > BUT if we focus only on use cases, we'll create tools that are > specific to ONE thing and are NOT general. They will be harder for > users to conceptualize and harder to combine in new and interesting > ways. But if it is the angle you want to play, then don't advertise it as a feature meant for _new users_! But if you go that route (e.g. as a way to compare BASE with THEIRS, for whatever reason), then you probably would need to invent some notation that is obvious that these are not refs, like HEAD, ORIG_HEAD, MERGE_HEAD and FETCH_HEAD are. Something that is easy to remember, won't go in the way of either git or shell; see e.g. http://thread.gmane.org/gmane.comp.version-control.git/175262/focus=175407 in "[RFC/PATCH] git put: an alternative to add/reset/checkout" thread. -- Jakub Narebski Poland -- 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