On Tue, Sep 9, 2008 at 3:50 PM, Steven Walter <stevenrwalter@xxxxxxxxx> wrote: > On Tue, Sep 9, 2008 at 4:19 PM, Elijah Newren <newren@xxxxxxxxx> wrote: >> it), but it's fairly straightforward to say any of: >> >> eg revert --since HEAD~3 # Undo all changes since HEAD~3 >> eg revert --in HEAD~8 # much like git revert HEAD~8, but no >> commit by default >> eg revert --since HEAD foo.py # Undo changes to foo.py since last commit >> eg revert foo.py # Same as above >> eg revert --in trial~7 bar.c baz. # Undo changes made in trial~7 to bar.[ch] > [...] >> Are these kinds of "reverting data" really so different that there >> should need to be different commands, or that some of these operations >> shouldn't be supported by the simple revert command? Sure, most users >> most of the time will probably use the "eg revert FILE1 FILE2..." >> form, but I didn't see the harm in supporting the extra capabilities. > > The harm I see in trying to support every possible use case is that it > makes it exponentially more difficult to fully understand the tool. > Using yap as an example, I think it should be easy enough for a user > to read the help blurb for every command and understand what it does > and when to use it (this is easy for me to say as the author, but I > think it would hold true for a "typical SCM user.") Having a mode > the seems to act like another SCM (revert --since) seems great at > first blush. The user will see that and think, "Wonderful, this will > work just like svn and I don't have to think about it." As I mention > in another email, that's all well and good until the user runs "git > diff" and makes a liar of you. In svn, there would be no diff, > because the files all match their respective upstream versions. In > git, you would see changes because the file no longer matches the last > commit. Now your user is confused because his mental model was > violated. Um, no, git diff won't make a liar of me -- it'll come up empty as expected. :-) My suggestion for revert does make it a logical extension of svn's, and includes git revert's behavior (with two minor tweaks). See my follow up post to Junio's elsewhere in this thread. > Obviously, there is a trade-off here between power and usability. As > shown by the Hole Hawg[1], there is a limit to the amount of power it > is useful for the average user to have. The git community has already > admitted this by dividing the git command set into two classes: > plumbing, and porcelain. "The plumbing," you say, "is very powerful, > but you shouldn't have to use it." My contention is that there is a > class of users that is not well served by the current definition of > porcelain. It is that class of users that I have tried to target with > yap. Fair enough. I too had to make decisions on what to focus on as well in Easy Git. Since my goal was more along the lines of "make it easy to learn how to use git, and particularly easy to transition to and from git and eg" that gives me a much different frame of reference than interoperating with svn (which I essentially ignored). I thought that this particular case didn't add much complexity (and potentially even removed it elsewhere), but that may just be my frame of reference. yap looks pretty cool; I'll have to take a look sometime. -- 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
