# Re: why is git destructive by default? (i suggest it not be!) 8 messages from 2008-06-24 to 2016-08-14. Participants: David Jeske, Brandon Casey, Matthieu Moy, Jing Xue. Thread: https://gitlist.dev/t/14118 ## David Jeske, 2008-06-24 10:01 Subject: Re: why is git destructive by default? (i suggest it not be!) Message-ID: <21109.6734311015$1214304662@news.gmane.org> URL: https://gitlist.dev/e/21109.6734311015%241214304662%40news.gmane.org In-Reply-To: ``` As a more practical question, how do I do this workflow illustrated below? It's sort of similar to the workflow that "git stash" is trying to support, except that I have a bunch of commits instead of a bunch of uncommitted-changes. I pull a repository that looks like this: . a<--b<--c <--master Then I hack away to this, and then throw my own branch on the end, along with master: . a<--b<--c<--d<--e<--f<--g <--master (jeske) . <--feature1 (jeske) While the server looks like this: . a<--b<--c<--1<--2<--3 <--master (server) I want to get my repository to look something like this: . a<--b<--c<--1<--2<--3 <--master (jeske) . \ . d<--e<--f<--g <-- feature1 (jeske) So I can then do this: . a<--b<--c<--1<--2<--3<--zz <--master (jeske) . \ . d<--e<--f<--g <-- feature1 (jeske) ..and then push zz onto the server after 3. ..and I want to do it with safe commands that won't leave any dangling references. (say if I forget to put the feature1 branch on) How do I do that? ``` ## Brandon Casey, 2008-06-24 15:29 Subject: Re: why is git destructive by default? (i suggest it not be!) Message-ID: URL: https://gitlist.dev/e/U-ySqQANiPRpld4kgzdXbovGgsj6LfOEdRmtTDU2yyvITSG3LnZAsQ%40cipher.nrlssc.navy.mil In-Reply-To: ``` David Jeske wrote: > As a more practical question, how do I do this workflow illustrated below? > > It's sort of similar to the workflow that "git stash" is trying to support, > except that I have a bunch of commits instead of a bunch of > uncommitted-changes. > > I pull a repository that looks like this: > > . a<--b<--c <--master git clone cd master_repo > > Then I hack away to this, and then throw my own branch on the end, along with > master: > > . a<--b<--c<--d<--e<--f<--g <--master (jeske) > . <--feature1 (jeske) hack hack hack git commit -a -m 'd' hack hack hack git commit -a -m 'e' hack hack hack git commit -a -m 'f' hack hack hack git commit -a -m 'g' git branch feature1 > > While the server looks like this: > > . a<--b<--c<--1<--2<--3 <--master (server) git fetch > I want to get my repository to look something like this: > > . a<--b<--c<--1<--2<--3 <--master (jeske) > . \ > . d<--e<--f<--g <-- feature1 (jeske) git reset --hard origin/master Side Note: you probably should have been developing on 'feature1' branch from the start. 'reset --hard' is a special case. If feature1 is a private branch for developing in, you may want to rebase it ontop of master and retest before merging into master and pushing so that you can maintain a nice linear history when possible. Or you can just merge into master and then push. > So I can then do this: > > . a<--b<--c<--1<--2<--3<--zz <--master (jeske) > . \ > . d<--e<--f<--g <-- feature1 (jeske) hack hack hack git commit -a -m 'zz' > > ..and then push zz onto the server after 3. git push > ..and I want to do it with safe commands that won't leave any dangling > references. (say if I forget to put the feature1 branch on) _Don't_ forget. 'reset --hard' is named that way for a reason. If you do forget, git makes it _easy_ to recover from. Let's say you _did_ forget. You did the 'reset --hard' on master and then you committed the 'zz' change without creating the 'feature1' branch. You can still create the feature1 branch since git saved the previous state in the reflog. It is two changes back. git branch feature1 master@{2} If you didn't know it was two changes back, then you can look through the reflog using 'git log -g master'. The commit message is there along with a reflog message describing what action was performed. After saying all of that, here is how I think you _should_ have done things. Notice I _did_not_ use 'reset --hard'. git clone 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. hack hack hack git commit -a -m 'd' # Make our 4 commits on the feature branch hack hack hack git commit -a -m 'e' hack hack hack git commit -a -m 'f' hack hack hack git commit -a -m 'g' git checkout master # Let's go back to master git pull # Fetch and merge the changes from the server git checkout -b 'master_zz' # Create a branch for developing the zz feature hack hack hack git commit -a -m 'zz' # Commit the zz feature git checkout master # Go back to master git merge master_zz # Merge zz git push # And push master out git branch -d master_zz # Now we're done with master_zz since it's all merged in Now you're in the same place you were above, you can continue developing your feature on feature1 branch by checking it out. This is also were rebase comes in handy, since you may want to rebase feature1 on top of the new current master. Once it is done and retested, you merge it into master and push it out. -brandon ``` ## David Jeske, 2008-06-24 17:41 Subject: Re: why is git destructive by default? (i suggest it not be!) Message-ID: <22283.5020781078$1214329638@news.gmane.org> URL: https://gitlist.dev/e/22283.5020781078%241214329638%40news.gmane.org In-Reply-To: ``` 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 are lost." ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ I interpreted this as "any [non committed changes] to tracked files in the working tree since 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 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 > 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 ``` ## Brandon Casey, 2008-06-24 18:55 Subject: Re: why is git destructive by default? (i suggest it not be!) Message-ID: <2S4y4AAYvrk5mQlxSrErW9bgimc0ab_fh8jlpjxj84k@cipher.nrlssc.navy.mil> URL: https://gitlist.dev/e/2S4y4AAYvrk5mQlxSrErW9bgimc0ab_fh8jlpjxj84k%40cipher.nrlssc.navy.mil In-Reply-To: ``` 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 > are lost." > > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > > I interpreted this as "any [non committed changes] to tracked files in the > working tree since 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 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 ``` ## Matthieu Moy, 2008-06-25 12:20 Subject: Re: why is git destructive by default? (i suggest it not be!) Message-ID: URL: https://gitlist.dev/e/vpqtzfhr9i3.fsf%40bauges.imag.fr In-Reply-To: ``` "David Jeske" writes: > - standardize all the potentially destructive operations (after gc) on "-f / > --force" to override Depending on the definition of "potentially destructive", most commands are "potentially destructive". git pull loses the point where the branch used to point when the reflog expires. git add loses the old content of the index. ... And adding too many --force options removes its real value. Many people type "rm -fr" any time they just want "rm", just because they were annoyed by the multiple interactive confirmations of plain "rm" (if aliased to "rm -i"). Asking people to type --force all the time make one fingers type --force mechanically, and removes all its value. -- Matthieu ``` ## Jing Xue, 2008-06-25 17:56 Subject: Re: why is git destructive by default? (i suggest it not be!) Message-ID: <20080625135647.wiohgih5hc0scgw0@intranet.digizenstudio.com> URL: https://gitlist.dev/e/20080625135647.wiohgih5hc0scgw0%40intranet.digizenstudio.com In-Reply-To: ``` Quoting David Jeske : > - 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) Is that really necessary? The way it works now, when I choose "reset foo branch to here", a dialog prompts me to pick from the three reset modes, with 'Mixed' being the default. So I'd have to explicitly pick 'Hard', which has a message "discards ALL local changes" right next to it. If people are so conditioned to ignore that, I doubt it'll take very long for them to be conditioned to just automatically confirm the confirmation dialog. The same applies to the command line as well I guess - if having to manually type "--hard" does not make one stop and think about what they are doing, I can hardly see how "--hard --force" would do any better. Cheers. -- Jing Xue ``` ## David Jeske, 2016-08-14 00:43 Subject: Re: why is git destructive by default? (i suggest it not be!) Message-ID: URL: https://gitlist.dev/e/willow-jeske-01l5oJ%3D64%3D91FEDjCgQT In-Reply-To: ``` As a more practical question, how do I do this workflow illustrated below? It's sort of similar to the workflow that "git stash" is trying to support, except that I have a bunch of commits instead of a bunch of uncommitted-changes. I pull a repository that looks like this: . a<--b<--c <--master Then I hack away to this, and then throw my own branch on the end, along with master: . a<--b<--c<--d<--e<--f<--g <--master (jeske) . <--feature1 (jeske) While the server looks like this: . a<--b<--c<--1<--2<--3 <--master (server) I want to get my repository to look something like this: . a<--b<--c<--1<--2<--3 <--master (jeske) . \ . d<--e<--f<--g <-- feature1 (jeske) So I can then do this: . a<--b<--c<--1<--2<--3<--zz <--master (jeske) . \ . d<--e<--f<--g <-- feature1 (jeske) ..and then push zz onto the server after 3. ..and I want to do it with safe commands that won't leave any dangling references. (say if I forget to put the feature1 branch on) How do I do that? ``` ## David Jeske, 2016-08-14 00:43 Subject: Re: why is git destructive by default? (i suggest it not be!) Message-ID: URL: https://gitlist.dev/e/willow-jeske-01l5xqJDFEDjCftd In-Reply-To: ``` 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 are lost." ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ I interpreted this as "any [non committed changes] to tracked files in the working tree since 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 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 > 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 ```