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