My takeaways from this thread: - THANKS! to all of you for the detailed discussion, and for making git. Even though it's still unfamiliar to me, I really enjoy (g)it! - I don't think anyone here thinks git is beyond improvement. This discussion did change my mind on a few things since my original post. I started this discussion to share my "unacclimated usability suggestions", because after I acclimate to git, I'll be telling new users that these idiosyncrasies are all no big deal too. :) I still think there is value in this list of suggestions. I'll work on submitting patches... - improve the man page description of "reset --hard" (see below) - standardize all the potentially destructive operations (after gc) on "-f / --force" to override - add "checkout" to the git-gui history right-click menu, and make the danger of "reset --hard" more obvious and require a confirmation dialog (the gui equivilant of -f) ---------- a couple more specific responses below.. -- Rogan Dawes wrote: > -- David wrote: > > Let me guess, you're always running euid==0. :) > Do you also ask the gnu coreutils folks to remove the -f option from their utilities? -- Johannes Gilger wrote: > I think the name of the command "reset" itself is a name which should > prompt everyone to read a manpage before using it. [snip ] > Nobody complains about rm --force or anything. Isn't it nice that they standardized on "-f" and "--force" across ALL commands? I would be inclined to talk to coreutils if it was "rm -f", "cp -R" (vs cp -r), and "mv --aggressive" to do the respective non-safe versions. It would simplify git's command-line-ui and cognitive load if it did the same thing. Pick one standard for "overriding dangerous commands", instead of "danger caps" and "danger --reset" and "danger -f". Consider branch which has both "branch -[MD]" and "branch -f" in the same subcommand. What's wrong with "branch -[md] -f"? Of course --hard encourages one to read the manpage. However, git is using a bunch of new terms for things, and uses at least those three different methods to indicate command danger. Lets look at the working on the manpage: "Matches the working tree and index to that of the tree being switched to. Any changes to tracked files in the working tree since <commit> are lost." ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ I interpreted this as "any [non committed changes] to tracked files in the working tree since <commit> are lost." I don't this this was a naive interpretation. I still think that's the way it reads after this whole conversation. I'll work on my first patch for git: -> "References to any working tree changes, and pulled changes, AND COMMITTED CHANGES to tracked files in the branch after <commit> will be dropped, causing them to be removed at the next garbage collect.". -- Brandon Casey wrote: > After saying all of that, here is how I think you _should_ have done things. > Notice I _did_not_ use 'reset --hard'. I was told that I can safely do "git checkout origin/master" instead of "reset --hard" to get back to the pull point, in case I didn't branch ahead of time. The wrinkle being that my "master" branch-pointer still points to my local changes, so I need to move onto a different branchname before I push if I want to avoid those changes going to the server, which is fine.. > git clone <master_repo> > cd master_repo > git checkout -b feature1 # we create our feature branch immediately since > # creating branches is so effortless in git. A > # private feature branch should _always_ be created > # and used for development. I'm beginning to see why I would always work this way, though if "private feature branches should always be created and used for development", then I'm unclear about why this isn't the default. git could implicitly create them when I checkin a change on the head of a pulled branch. (i.e. user/branchname/id, or something else). I'm reaching here, I'll need to use git more with other developers to understand this better. ------------------- Thanks again for all the detailed responses and explanations! - David -- 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
