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 " should be (almost) demoted to plumbing, leaving only the "reset " that reverses "add " 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 "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 "reset"s, 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 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" Kevin Bracey wrote: On 01/06/2014 07:26, Atsushi Nakagawa wrote: > Kevin Bracey 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] [|] -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 '. (...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 ]. 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?
Atsushi Nakagawa wrote: > Kevin Bracey wrote: > > On 31/05/2014 08:46, Atsushi Nakagawa wrote: > > >`git checkout -B ` > > > > > > 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 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 wrote: > On 01/06/2014 07:26, Atsushi Nakagawa wrote: > > Kevin Bracey 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] [|] -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 '. (...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 ]. 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 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 wrote: > Maybe we just need to tighten up the EXAMPLES section? Give it > easy-to-locate /--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?
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~ git reset HEAD~ git reset --keep HEAD~ git reset --keep ORIG_HEAD git reset --keep @{} git reset --keep (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 /--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 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?
Junio C Hamano writes: > Atsushi Nakagawa 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 ` >> >> 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 " 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?
Atsushi Nakagawa 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 ` > > 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?
On 01/06/2014 07:26, Atsushi Nakagawa wrote: Kevin Bracey 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 @{}" - see git-reflog(1)). "git reset --keep" is a safe alternative to "--hard", and is roughly equivalent to "git checkout -B ". "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 peopl
Re: Reset by checkout?
Felipe Contreras 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 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 wrote: > On 31/05/2014 08:46, Atsushi Nakagawa wrote: > >`git checkout -B ` > > > > 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 ". 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 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?
Andreas Schwab wrote: > Atsushi Nakagawa 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 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 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?
On 31/05/2014 08:46, Atsushi Nakagawa wrote: `git checkout -B ` 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 ". 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?
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?
Atsushi Nakagawa 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