Re: Proposal: create meaningful aliases for git reset's hard/soft/mixed
Martin von Zweigbergk martinv...@gmail.com writes: On Wed, Nov 23, 2011 at 10:51 AM, Junio C Hamano gits...@pobox.com wrote: I am guilty of introducing git reset --soft HEAD^ before I invented commit --amend during v1.3.0 timeframe to solve the issue soft reset originally wanted to. I do use commit --amend a lot, but I still appreciate having reset --soft. For example, to squash the last few commits: git reset --soft HEAD^^^ git commit --amend Yeah, I do that sometimes myself, but the key word is sometimes. These days, I think most users (not just mortals but experienced ones) use rebase -i to squash them altogether, either with fixup, with which you lose the messages from the follow-up fixes, just like the soft reset to an old one with an amen,) or with squash, with which you can pick pieces of messages from the follow-up fixes while updating the message from the original one. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Proposal: create meaningful aliases for git reset's hard/soft/mixed
On Mon, Dec 17, 2012 at 10:34:07PM -0800, Martin von Zweigbergk wrote: On Wed, Nov 23, 2011 at 10:51 AM, Junio C Hamano gits...@pobox.com wrote: I am guilty of introducing git reset --soft HEAD^ before I invented commit --amend during v1.3.0 timeframe to solve the issue soft reset originally wanted to. I do use commit --amend a lot, but I still appreciate having reset --soft. For example, to squash the last few commits: git reset --soft HEAD^^^ git commit --amend Me too. Another one I use is: $ hack hack hack $ git commit -m wip $ git checkout something-else ... time passes ... $ git checkout orig-branch $ git reset --soft HEAD^ $ hack hack hack $ git diff $ git add -p $ git commit which ends up with the same history as commit --amend, but in between the reset and the commit, the bogus WIP commit is thrown away entirely. And things like diff and add -p do what you want, instead of showing your progress on top of the WIP. -Peff -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Proposal: create meaningful aliases for git reset's hard/soft/mixed
On Wed, Nov 23, 2011 at 12:49 AM, Matthieu Moy matthieu@grenoble-inp.fr wrote: Philippe Vaucher philippe.vauc...@gmail.com writes: Optional: a new mode would be introduced for consistency: --worktree (or maybe --tree): only updates the worktree but not the index That would be an alias for git checkout rev -- path, right? Not quite, in two ways, I think. First, it _would_ update the index, wouldn't it? Second, git checkout rev -- path doesn't delete files that are deleted in rev as compared to head. I'm considering implementing support for an operation that would do what I expected git checkout rev -- path and git reset --hard rev -- path to do. I'm currently planning for it to be exactly git reset --hard rev -- path (which is currently simply not allowed), but perhaps it would be more natural as an option to checkout (--also-deleted or something)? -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Proposal: create meaningful aliases for git reset's hard/soft/mixed
On Wed, Nov 23, 2011 at 10:51 AM, Junio C Hamano gits...@pobox.com wrote:
I am guilty of introducing git reset --soft HEAD^ before I invented
commit --amend during v1.3.0 timeframe to solve the issue soft reset
originally wanted to.
I do use commit --amend a lot, but I still appreciate having reset
--soft. For example, to squash the last few commits:
git reset --soft HEAD^^^ git commit --amend
or undo commit --amend:
git reset --soft HEAD@{1} git commit --amend
Maybe there's a better way of doing that?
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Proposal: create meaningful aliases for git reset's hard/soft/mixed
On Wednesday 2012-10-03 21:03, Junio C Hamano wrote: I said that git reset --keep started out as an ugly workaround for the lack of git checkout -B $current_branch. Now we have it, so we can afford to make reset --keep less prominently advertised in our tool set. As I already said back then, reset --soft also has outlived its usefulness when commit --amend came, so that leaves only these modes of reset: Soft is still useful, partway. Consider patch splitting (where easily possible): $ git add foo.c bar.c $ git commit -m foo,bar [other commits] $ git rebase -i FOOBARCOMMIT^ [mark foo,bar for edit] $ git reset --soft HEAD^ $ git reset bar.c $ git commit -m foo $ git add bar.c $ git commit -m bar $ git rebase --continue -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Proposal: create meaningful aliases for git reset's hard/soft/mixed
Phil Hord phil.h...@gmail.com writes: I flagged this for followup in my MUA, but I failed to follow-up after the holidays. I apologize for that, and I really regret it because I liked where this was going. I really regret to see you remembered it, actually. 1) Newbie user clones/pulls a repository from somewhere. He hacks around and then things go bad, and he decides to scratch away everything he did to make sure things are like they're supposed to be. He'd then type git checkout --force --clean master. If he didn't introduce new files, he would simply type git checkout --force master I like this just fine. I think we can explicitly say that HEAD is the implied default refspec, yes? git checkout --force --clean That depends on what the hacks around involved. Where is he now, what damage did he cause, and what can you depend on to take him to a clean state, where the definition of clean happens to match this hypothetical Newbie user? Did he do git checkout of another branch? Did he commit? Did he reset to other commit while on the 'master' branch? Is he still on master branch when he says git checkout --force --clean master? Can he say git checkout --force --clean master~4 and what does that even mean? Is he trying to go into the detached HEAD state, or is he somehow trying to rewind master? -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Proposal: create meaningful aliases for git reset's hard/soft/mixed
Junio C Hamano gits...@pobox.com writes: Phil Hord phil.h...@gmail.com writes: I flagged this for followup in my MUA, but I failed to follow-up after the holidays. I apologize for that, and I really regret it because I liked where this was going. I really regret to see you remembered it, actually. Having said that, I am glad that you brought the old discussion thread to our attention. In http://thread.gmane.org/gmane.comp.version-control.git/185825/focus=185863, I said that git reset --keep started out as an ugly workaround for the lack of git checkout -B $current_branch. Now we have it, so we can afford to make reset --keep less prominently advertised in our tool set. As I already said back then, reset --soft also has outlived its usefulness when commit --amend came, so that leaves only these modes of reset: reset --hard [$commit] reset [$commit] reset --merge I am not sure if it makes sense to give a commit different from HEAD to reset --merge, and to a lessor degree, reset --mixed to flip the HEAD to another commit while retaining the working tree contents does not make much sense, either, in a common workflow. It _might_ be possible to merge the --mixed and --merge if we think things through to reduce the often-used options even further, but I haven't done so, and I suspect nobody has (yet). -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
