Re: why is git destructive by default? (i suggest it not be!)

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?

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 wrote:

git clone <master_repo> cd master_repo

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

git fetch

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.

hack hack hack git commit -a -m 'zz'

git push

_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 <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.
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

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:

utilities?

-- Johannes Gilger wrote:

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:

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..

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

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:

utilities?

-- Johannes Gilger wrote:

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:

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..

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

David Jeske wrote:

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.

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.

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.

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).

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

"David Jeske" <jeske@google.com> writes:

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.

Quoting David Jeske <jeske@google.com>:

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.