Re: Reset by checkout?
On 07/06/2014 17:52, Philip Oakley wrote:
Just to say there has been a similar confusion about 'git reset'
reported on the Git Users group for the case of reset with added
(staged), but uncommitted changes being wiped out, which simlarly
reports on the difficulty of explaining some of the conditions
especially when some are wrong ;-)
https://groups.google.com/forum/#!topic/git-users/27_FxIV_100
I'm coming around to the view that git reset mode should be (almost)
demoted to plumbing, leaving only the reset file that reverses add
file as everyday Porcelain.
I think reset --keep and --merge were a step in the wrong direction,
at least for the Porcelain - trying to make reset mode more useful,
rather than less necessary. Normal users shouldn't be needing to touch
these hard-to-explain-and-slightly-dangerous commands.
The addition of --abort to merge and other commands was much more
solid. They helped a lot, and I think we should follow that model by
adding --undo to various commands. That would mop up all the common
resets, in conjunction with Atsushi's proposed checkout -u
alternative to -B, which I quite like.
Main few:
commit --undo = reset --soft HEAD^
merge --undo = reset --keep HEAD^
rebase --undo = reset --keep ORIG_HEAD [bug report: rebase -p doesn't
set ORIG_HEAD reliably]
pull --undo = merge/rebase --undo depending on rebase settings [could we
go nuts and undo the fetch too?]
Bonus:
commit --amend --undo: reset --soft HEAD@{1}
The undos can also have a bit of extra veneer that checks the log/reflog
for whether it matches the proposed undo, and also checks the upstream
to see if the thing being undone is already public.
Given those, I honestly don't think I'd ever need to explain git reset
mode to anyone again. Which would be nice...
(Note I propose no --mixed equivalent for the commit undos, but it's
easy enough to follow the commit --undo with a normal git reset. I'd
rather re-document the normal git reset under commit --undo than add
and document yet another option).
Kevin
--
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: Reset by checkout?
From: Atsushi Nakagawa at...@chejz.com Kevin Bracey ke...@bracey.fi wrote: On 01/06/2014 07:26, Atsushi Nakagawa wrote: Kevin Bracey ke...@bracey.fi wrote: The original git reset --hard used to be a pretty top-level command. It was used for aborting merges in particular. But I think it now stands out as being one of the only really dangerous porcelain commands, and I can't think of any real workflow it's still useful for. My thoughts exactly. I think the 'reset --soft/--mixed/--hard' pattern is so ingrained, that many people just don't realize there's a safer alternative. (I've heard work mates on more than one occasion recommending 'reset --hard' as the go-to command for discarding commits.) I believe this is likely because many third party GUI tools just don't support 'reset --keep', and these tools present a Reset... dialog with the de facto Soft/Mixed/Hard options. (Even 'gitk' does this.) True on the GUI - hard really needs demotion. It would help if the documentation explained better straight off what the different reset modes are intended /for/ in a more practical way, rather than the technical jargon. On one hand, I agree that improving man git-reset and making it easier to understand would be of benefit. However, one of the main culprits of confusion here seems to be the mere existance of '--keep', which is somewhat of a conceptual black sheep. The --soft/--mixed/--hard trio seems quite easy to explain, /if/ you didn't need to also explain --keep... To that end, I'm wondering if it's better to just deprecate 'reset --keep' and shift the use-case over to 'checkout': checkout [-u|--update] [commit|branch] -u --update Rather than checking out a branch to work on it, check out a commit and reset the current branch to that commit. This is functionally equivalent to 'checkout -B CURRENT_BRANCH commit'. (...Maybe a warning here about commits becoming unreachable...) Then, as an added bonus, anything I've staged is kept intact. *And*, I can attempt 'checkout -u --merge' if I'm feeling particulary careless. --hard All [] changes are dropped[] and the [working tree] and index are forcibly reset to the [state of commit]. Note that this is dangerous if used carelessly. ALL uncommitted changes to ALL tracked files will be lost[]. Older documentation often recommends git reset --hard to undo commits; the newer --keep option is [safer and is now the recommended] alternative [for use in this situation]. I like this explaination of '--hard' and prefer it over current, which doesn't much explain the gravity of the command. I've made some edits above. --merge Performs the operation of git merge --abort, intended for use during a merge resolution - see git-merge(1) for more information. This form is not normally used directly. Aha, so that's what that's for. I couldn't really understand the explanation in the current manpage, but your version at least tells me that it's an option I don't need to worry about. Just to say there has been a similar confusion about 'git reset' reported on the Git Users group for the case of reset with added (staged), but uncommitted changes being wiped out, which simlarly reports on the difficulty of explaining some of the conditions especially when some are wrong ;-) https://groups.google.com/forum/#!topic/git-users/27_FxIV_100 -- Philip -- 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: Reset by checkout?
Kevin Bracey ke...@bracey.fi wrote: On 01/06/2014 07:26, Atsushi Nakagawa wrote: Kevin Bracey ke...@bracey.fi wrote: The original git reset --hard used to be a pretty top-level command. It was used for aborting merges in particular. But I think it now stands out as being one of the only really dangerous porcelain commands, and I can't think of any real workflow it's still useful for. My thoughts exactly. I think the 'reset --soft/--mixed/--hard' pattern is so ingrained, that many people just don't realize there's a safer alternative. (I've heard work mates on more than one occasion recommending 'reset --hard' as the go-to command for discarding commits.) I believe this is likely because many third party GUI tools just don't support 'reset --keep', and these tools present a Reset... dialog with the de facto Soft/Mixed/Hard options. (Even 'gitk' does this.) True on the GUI - hard really needs demotion. It would help if the documentation explained better straight off what the different reset modes are intended /for/ in a more practical way, rather than the technical jargon. On one hand, I agree that improving man git-reset and making it easier to understand would be of benefit. However, one of the main culprits of confusion here seems to be the mere existance of '--keep', which is somewhat of a conceptual black sheep. The --soft/--mixed/--hard trio seems quite easy to explain, /if/ you didn't need to also explain --keep... To that end, I'm wondering if it's better to just deprecate 'reset --keep' and shift the use-case over to 'checkout': checkout [-u|--update] [commit|branch] -u --update Rather than checking out a branch to work on it, check out a commit and reset the current branch to that commit. This is functionally equivalent to 'checkout -B CURRENT_BRANCH commit'. (...Maybe a warning here about commits becoming unreachable...) Then, as an added bonus, anything I've staged is kept intact. *And*, I can attempt 'checkout -u --merge' if I'm feeling particulary careless. --hard All [] changes are dropped[] and the [working tree] and index are forcibly reset to the [state of commit]. Note that this is dangerous if used carelessly. ALL uncommitted changes to ALL tracked files will be lost[]. Older documentation often recommends git reset --hard to undo commits; the newer --keep option is [safer and is now the recommended] alternative [for use in this situation]. I like this explaination of '--hard' and prefer it over current, which doesn't much explain the gravity of the command. I've made some edits above. --merge Performs the operation of git merge --abort, intended for use during a merge resolution - see git-merge(1) for more information. This form is not normally used directly. Aha, so that's what that's for. I couldn't really understand the explanation in the current manpage, but your version at least tells me that it's an option I don't need to worry about. Cheers, -- Atsushi Nakagawa at...@chejz.com Changes are made when there is inconvenience. -- 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: Reset by checkout?
Atsushi Nakagawa at...@chejz.com wrote: Kevin Bracey ke...@bracey.fi wrote: On 31/05/2014 08:46, Atsushi Nakagawa wrote: `git checkout -B current-branch-name tree-ish` This is such an useful notion that I can fathom why there isn't a better, first-tier, alternative.q ... I guess in theory using checkout allows fancier extra options like --merge and --patch, but I don't think I've ever used those with checkout, let alone this mode, where I really do just want a reset, with safety checks. It does indeed have those fancier options. However, I just noticed there's even a 'reset --merge'! And like you say, I can't remember ever using 'checkout --merge' together with 'checkout -B'. I'd assumed 'reset --merge' was like 'checkout --merge' and was elated.., but it was something else entirely. Cheers, -- Atsushi Nakagawa at...@chejz.com Changes are made when there is inconvenience. -- 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: Reset by checkout?
On 03/06/2014 00:54, Junio C Hamano wrote:
Not that I can think of a better way to update these descriptions,
and not that I am opposing to update these descriptions to make it
easier for new people to learn, but I am not sure if these treat
ORIG_HEAD and the changes since that commit as separate entities
is a good approach to do so.
Somewhat frustrated, not by your patch but by being unable to
suggest a better way X-.
I know. I started off myself knowing what I meant to say, and then got
bogged down somewhat trying to be detailed enough for a full
explanation. I think it's just inherently very hard for anyone to
visualise what these do in the /general/ case.
This is one of those commands where the structure of a man page gets in
the way. We have to give a summary of what the mode options /do/, but
that's not what people want to know. They want to know what they're /for/.
(And, to some extent, reset, like checkout, is two separate commands.
One being the path manipulator, the other being the HEAD manipulator.
Just bogs us down further).
I think these are the most important HEAD resets, covering 95%+ of uses:
git reset --soft HEAD~n
git reset HEAD~n
git reset --keep HEAD~n
git reset --keep ORIG_HEAD
git reset --keep @{n}
git reset --keep some other arbitary place
(and possibly
git reset --merge
although I think this should be fully covered by git xxx --abort -
maybe a couple of those missing like git stash pop/apply --abort?)
Anything more than those, I think, are pretty far-fetched. I can't 100%
grok --soft/--mixed onto a different branch, for example. (But at
least we do define those cases in the A/B/C/D discussion section for
the real geeks.)
Maybe we just need to tighten up the EXAMPLES section? Give it
easy-to-locate path/--soft/--mixed/--keep subheadings, covering all
those common use cases (in clean trees...), including a before/after git
status views. Then normal users could skip the top technical section
waffling about indexes and go straight there instead.
Kevin
--
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: Reset by checkout?
Kevin Bracey wrote: Maybe we just need to tighten up the EXAMPLES section? Give it easy-to-locate path/--soft/--mixed/--keep subheadings, covering all those common use cases (in clean trees...), including a before/after git status views. Then normal users could skip the top technical section waffling about indexes and go straight there instead. Or maybe we need to have sane options, like --stage, --work, and --keep. -- Felipe Contreras -- 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: Reset by checkout?
Atsushi Nakagawa at...@chejz.com writes: One of the more underrepresented command I use in git use on a regular basis is this reset by checkout. It's what's currently achieved by this convoluted expression: `git checkout -B current-branch-name tree-ish` This is such an useful notion that I can fathom why there isn't a better, first-tier, alternative. Hmph. checkout *is* the first-tier way to do this. Why do you even want to do it via reset? Is it because you learned reset first and then learned how checkout with various modes all do useful things? -- 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: Reset by checkout?
Junio C Hamano gits...@pobox.com writes: Atsushi Nakagawa at...@chejz.com writes: One of the more underrepresented command I use in git use on a regular basis is this reset by checkout. It's what's currently achieved by this convoluted expression: `git checkout -B current-branch-name tree-ish` This is such an useful notion that I can fathom why there isn't a better, first-tier, alternative. Hmph. checkout *is* the first-tier way to do this. Why do you even want to do it via reset? Is it because you learned reset first and then learned how checkout with various modes all do useful things? Ahh, the branch to be checked out being the current branch is indeed strange. That is what reset --keep was invented for. I use git checkout -B something-else commit all the time, and somehow I thought that was what you were talking about. Sorry for the noise. -- 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: Reset by checkout?
Kevin Bracey ke...@bracey.fi writes: Maybe something like this: I like the overall direction to re-organize the description by operations, but the new description seem to introduce a bit of new confusion. All modes move the current branch pointer so that HEAD now points to the specified commit. ORIG_HEAD is set to the original HEAD location. The modes differ in what happens to the contents of ORIG_HEAD, that are no longer on the reset branch; and also what happens to your not-yet-committed changes. --soft Retains the contents of ORIG_HEAD in the index+work area, leaving the difference as changes to be committed. This (and everything that talks about ORIG_HEAD) asks the user to think of the working tree state as a combination of the state the commit you were on represents plus the changes you made relative to it. Given that everything Git records is a whole-tree snapshot, state (not changes), and that is how tutorials teach Git, I wonder if the what is done to ORIG_HEAD and changes gets the user into right mindset to understand various modes of operations. And with that ORIG_HEAD and changes mindset, a --soft reset becomes very hard to explain. ORIG_HEAD and changes (you had before you issued the 'reset --soft' command) are left in the index/work, HEAD becomes the named commit, changes from that updated HEAD becomes the original changes (you had since ORIG_HEAD) mixed with the differences between ORIG_HEAD and HEAD. If you explain this in terms of state, a --soft reset will keep the state of the index and the working tree as-is and changes the HEAD pointer to point at a different commit. git reset --soft HEAD~1 would be the first step if you want to remove the last commit, but intend to recommit most or all of its changes. git status after reset --soft shows: To be committed: Changes in ORIG_HEAD relative to HEAD (+Any initial staged changes) There would be overlapping parts of Any initial staged changes and Changes in ORIG_HEAD relative to HEAD. They may be mixed, they may be partly reverted, or they may totally cancel out, depending on the changes the user made since starting to work on ORIG_HEAD. Not staged: (Any initial unstaged changes) --mixed (default) Retains the contents of ORIG_HEAD in the work area, leaving the difference as unstaged changes. I am confused by the above the same way. If the operation retains the contents of ORIG_HEAD in the working tree, would that mean the edit I made is somehow reverted? No, because you say leaving the difference ..., but then the operation is not really retaining the contents of ORIG_HEAD. It is leaving the state I had in my working tree as-is, regardless of ORIG_HEAD and/or HEAD that is updated. Not that I can think of a better way to update these descriptions, and not that I am opposing to update these descriptions to make it easier for new people to learn, but I am not sure if these treat ORIG_HEAD and the changes since that commit as separate entities is a good approach to do so. Somewhat frustrated, not by your patch but by being unable to suggest a better way X-. -- 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: Reset by checkout?
On 01/06/2014 07:26, Atsushi Nakagawa wrote:
Kevin Bracey ke...@bracey.fi wrote:
The original git reset --hard used to be a pretty top-level command.
It was used for aborting merges in particular. But I think it now
stands out as being one of the only really dangerous porcelain
commands, and I can't think of any real workflow it's still useful
for.
My thoughts exactly. I think the 'reset --soft/--mixed/--hard' pattern
is so ingrained, that many people just don't realize there's a safer
alternative. (I've heard work mates on more than one occasion
recommending 'reset --hard' as the go-to command for discarding commits.)
I believe this is likely because many third party GUI tools just don't
support 'reset --keep', and these tools present a Reset... dialog with
the de facto Soft/Mixed/Hard options. (Even 'gitk' does this.)
True on the GUI - hard really needs demotion.
It would help if the documentation explained better straight off what
the different reset modes are intended /for/ in a more practical way,
rather than the technical jargon.
There is the EXAMPLES section, but I think the problem is that it's
not clearly laid out by mode, meaning people checking to see what git
reset can do are inclined to go first to the --xxx mode list in
DESCRIPTION, and stop there, baffled, probably not finding any example
for that mode. Maybe the examples should have clearer --option
subheadings? (And all the existing examples for --hard should really
suggest --keep instead).
But given that the DISCUSSION section now has the full internal
details on what exactly each mode does in every state, and now that we
have more than the simple soft/mixed/hard to deal with, I think the
main DESCRIPTION could be simplified for end users.
Most useful for visualisation, I feel, would just showing what git
status will look like afterwards, primarily from the point of view of a
backwards reset to HEAD~n. In particular, normal users don't think in
terms of the absolute contents of the index, but rather in terms of diffs.
Maybe something like this:
All modes move the current branch pointer so that HEAD now points to
the specified commit. ORIG_HEAD is set to the original HEAD location.
The modes differ in what happens to the contents of ORIG_HEAD, that are
no longer on the reset branch; and also what happens to your
not-yet-committed changes.
--soft
Retains the contents of ORIG_HEAD in the index+work area, leaving
the difference as changes to be committed. git reset --soft HEAD~1
would be the first step if you want to remove the last commit, but
intend to recommit most or all of its changes.
git status after reset --soft shows:
To be committed:
Changes in ORIG_HEAD relative to HEAD
(+Any initial staged changes)
Not staged:
(Any initial unstaged changes)
--mixed (default)
Retains the contents of ORIG_HEAD in the work area, leaving the
difference as unstaged changes. git reset HEAD~1 would be the first
step if you want to remove the last commit, and think again from scratch
about which of its changes should be committed.
git status after reset --mixed shows:
Not staged:
Changes in ORIG_HEAD relative to HEAD
(+Any initial staged changes)
(+Any initial unstaged changes)
--keep
The contents of ORIG_HEAD are dropped, leaving the work area and
index containing the new HEAD; your uncommitted changes to unaffected
files are retained. If you have uncommitted changes to any files that
differ in the proposed new HEAD, the operation is refused; you would
need to git stash first. git reset --keep HEAD~1 can be used to
totally remove the last commit. (This removal can itself be undone with
another git reset --keep ORIG_HEAD, or git reset --keep
branch@{n} - see git-reflog(1)). git reset --keep is a safe
alternative to --hard, and is roughly equivalent to git checkout -B
current-branch-name.
git status after reset --keep shows:
Not staged
(Any initial staged changes) [should these be left staged, as
per git checkout?]
(+Any initial unstaged changes)
--hard
All other changes are dropped, and the work area and index are
forcibly reset to the new HEAD. Note that this is dangerous if used
carelessly: ALL uncommitted changes to ALL tracked files will be lost,
even if you were only trying to drop an unrelated commit that didn't
touch those files. Older documentation often recommends git reset
--hard to undo commits; the newer --keep option is a much better
alternative in almost all cases.
git status after reset --hard shows:
Work area clean (or untracked files present)
--merge
Performs the operation of git merge --abort, intended for use
during a merge resolution - see git-merge(1) for more information. This
form is not normally used directly. [Not really true? Still the best
command to abort git checkout --merge/git stash pop|apply? Do those
need --abort?]
If people just forgot about
Re: Reset by checkout?
Atsushi Nakagawa at...@chejz.com writes: Ok, the typical use case is: I'm on 'master' and I make a few test commits. Afterwards, I want to discard the commits and move back to 'origin/master'. I could type 'reset --hard origin/master' and risk blowing away dirty files if I'm not careful. Or, I could use reset by checkout and be carefree. I think that is what 'reset --keep' is doing. Andreas. -- Andreas Schwab, sch...@linux-m68k.org GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 And now for something completely different. -- 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: Reset by checkout?
Atsushi Nakagawa wrote: Ok, the typical use case is: I'm on 'master' and I make a few test commits. Afterwards, I want to discard the commits and move back to 'origin/master'. I could type 'reset --hard origin/master' and risk blowing away dirty files if I'm not careful. Or, I could use reset by checkout and be carefree. Doesn't 'git reset orign/master' do that? -- Felipe Contreras -- 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: Reset by checkout?
On 31/05/2014 08:46, Atsushi Nakagawa wrote: `git checkout -B current-branch-name tree-ish` This is such an useful notion that I can fathom why there isn't a better, first-tier, alternative.q I'm 100% in agreement. Reset current branch to X is an extremely common operation, and I use this all the time. But having to actually name the current branch is silly, and like you, I'm prone to swapping the parameters. I guess in theory using checkout allows fancier extra options like --merge and --patch, but I don't think I've ever used those with checkout, let alone this mode, where I really do just want a reset, with safety checks. The original git reset --hard used to be a pretty top-level command. It was used for aborting merges in particular. But I think it now stands out as being one of the only really dangerous porcelain commands, and I can't think of any real workflow it's still useful for. Maybe it could now be modified to warn and require -f to overwrite anything in the working tree? While digging into this, it seems git reset --keep is actually pretty close to git checkout -B current branch. It certainly won't lose your workspace file, but unlike checkout it /does /forget what you've staged, which could be annoying. Maybe that could be modified to keep the index too? (I like your alias.become - might try that). Kevin -- 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: Reset by checkout?
Felipe Contreras wrote: Atsushi Nakagawa wrote: Ok, the typical use case is: I'm on 'master' and I make a few test commits. Afterwards, I want to discard the commits and move back to 'origin/master'. I could type 'reset --hard origin/master' and risk blowing away dirty files if I'm not careful. Or, I could use reset by checkout and be carefree. Doesn't 'git reset orign/master' do that? Unless you want to keep the staged files, in which case adding the --stage and --work options I originally suggested[1] would help. So you could do `git reset --no-stage --no-work origin/master` Which is essentially the same as `git update-ref refs/heads/master origin/master`. [1] http://article.gmane.org/gmane.comp.version-control.git/247086 -- Felipe Contreras -- 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: Reset by checkout?
Andreas Schwab sch...@linux-m68k.org wrote: Atsushi Nakagawa at...@chejz.com writes: Ok, the typical use case is: I'm on 'master' and I make a few test commits. Afterwards, I want to discard the commits and move back to 'origin/master'. I could type 'reset --hard origin/master' and risk blowing away dirty files if I'm not careful. Or, I could use reset by checkout and be carefree. I think that is what 'reset --keep' is doing. I must admit, I didn't know about 'reset --keep'. As you've pointed out, it does look like the command I was after all along! And to think that it's been around since 1.7.1. Thanks! -- Atsushi Nakagawa at...@chejz.com Changes are made when there is inconvenience. -- 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: Reset by checkout?
Kevin Bracey ke...@bracey.fi wrote: On 31/05/2014 08:46, Atsushi Nakagawa wrote: `git checkout -B current-branch-name tree-ish` This is such an useful notion that I can fathom why there isn't a better, first-tier, alternative.q ... I guess in theory using checkout allows fancier extra options like --merge and --patch, but I don't think I've ever used those with checkout, let alone this mode, where I really do just want a reset, with safety checks. It does indeed have those fancier options. However, I just noticed there's even a 'reset --merge'! And like you say, I can't remember ever using 'checkout --merge' together with 'checkout -B'. The original git reset --hard used to be a pretty top-level command. It was used for aborting merges in particular. But I think it now stands out as being one of the only really dangerous porcelain commands, and I can't think of any real workflow it's still useful for. My thoughts exactly. I think the 'reset --soft/--mixed/--hard' pattern is so ingrained, that many people just don't realize there's a safer alternative. (I've heard work mates on more than one occasion recommending 'reset --hard' as the go-to command for discarding commits.) I believe this is likely because many third party GUI tools just don't support 'reset --keep', and these tools present a Reset... dialog with the de facto Soft/Mixed/Hard options. (Even 'gitk' does this.) Maybe it could now be modified to warn and require -f to overwrite anything in the working tree? If people just forgot about '--hard' and used '--mixed/--keep' for regular cases, '--hard' would effectively be -f. ;) While digging into this, it seems git reset --keep is actually pretty close to git checkout -B current branch. It certainly won't lose your workspace file, but unlike checkout it /does /forget what you've staged, which could be annoying. Maybe that could be modified to keep the index too? Yes, I didn't realize that 'reset --keep' existed and now I'm feeling a bit silly for asking. The index preservation artefact of 'checkout -B' could be useful, though I can't remember at this point if I've relied on it in the past. The documetation for 'reset --keep' is ambiguous about what happens to index entries of differing files, so modifying it may be an option if there's demand.. I'm going to try out 'reset --keep' for a while and see if it does get annoying. Cheers, -- Atsushi Nakagawa at...@chejz.com Changes are made when there is inconvenience. -- 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: Reset by checkout?
Felipe Contreras felipe.contre...@gmail.com wrote: Felipe Contreras wrote: Atsushi Nakagawa wrote: Ok, the typical use case is: I'm on 'master' and I make a few test commits. Afterwards, I want to discard the commits and move back to 'origin/master'. I could type 'reset --hard origin/master' and risk blowing away dirty files if I'm not careful. Or, I could use reset by checkout and be carefree. Doesn't 'git reset orign/master' do that? Unless you want to keep the staged files, in which case adding the --stage and --work options I originally suggested[1] would help. ... [1] http://article.gmane.org/gmane.comp.version-control.git/247086 What I was looking for is basically what 'git checkout' does to the working tree when it moves from one commit to another, as well as the semantic checks it offers such that I'm incapable of making an unrecoverable change (i.e. It aborts if I'm about to blow away changes that aren't committed.). I was introduced to 'git reset --keep' in another reply and that for most intent and purpose is what I think I was after. Cheers, -- Atsushi Nakagawa at...@chejz.com Changes are made when there is inconvenience. -- 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
Reset by checkout?
Hi all, One of the more underrepresented command I use in git use on a regular basis is this reset by checkout. It's what's currently achieved by this convoluted expression: `git checkout -B current-branch-name tree-ish` This is such an useful notion that I can fathom why there isn't a better, first-tier, alternative. i.e. How come there's no 'git reset --checkout'? The command above even prints Reset branch 'current-branch-name'. The problem with 'checkout -B' is it's so easy to mistype! If I had a yen for every time I accidentally left off the 'current-branch-name' part and created a branch named tree-ish at HEAD... So, I defined alias.become '!git checkout -B $(git symbolic-ref --short HEAD)' and was happy for a while. Now, the lack is glaring every time I'm explaining workflows to people who don't have the the alias. Ok, the typical use case is: I'm on 'master' and I make a few test commits. Afterwards, I want to discard the commits and move back to 'origin/master'. I could type 'reset --hard origin/master' and risk blowing away dirty files if I'm not careful. Or, I could use reset by checkout and be carefree. Any ideas? Am I doing something wrong or unconventional? Cheers, -- Atsushi Nakagawa at...@chejz.com Changes are made when there is inconvenience. -- 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
