David Jeske wrote: > 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 The thing is 'force' is not always the most descriptive word for the behavior that you propose enabling with --force. For the reset command in particular there is a --soft counterpart to --hard. They are both modifiers on the term 'reset' i.e. a 'soft reset' or a 'hard reset'. The default is wbat is called a 'mixed reset'. 'gc' is another command that has been mentioned along with its '--aggressive' option. --force does not seem to make sense here either, since we are not necessarily forcing anything to happen in the sense of overriding some safe guard. What is happening is that possibly more cpu-intensive options are being selected when repacking (compressing) the repository. > Consider branch which has > both "branch -[MD]" and "branch -f" in the same subcommand. What's wrong with > "branch -[md] -f"? I am inclined to agree here. I'm not sure why the options for 'git branch' were created this way. I too have thought that a -f modifier on -m and -d would be more intuitive. > 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 think the reason it only says that uncommitted changes are lost is because the committed changes are not lost even though they may become unreachable from the head of the current branch. They are still reachable at least from the reflog, so they are not lost. The uncommitted changes _are_ lost and are unrecoverable. > 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.". Uncommited working tree changes are gone immediately. Anything that has already been committed will be garbage collected only after it is not referenced by anything else in the repository. A reference will be maintained in the reflog for at least 30 days (by default). > > -- 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. I think 'git checkout origin/master' would be a little odd since this is usually a remote tracking branch. 'git checkout -b mymaster origin/master' or similar would be more common. This creates a new branch named 'mymaster'. -brandon -- 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
