Reset by checkout?

Reset by checkout?

[Atsushi Nakagawa]

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
<atnak@chejz.com>
Changes are made when there is inconvenience.

Re: Reset by checkout?

[Andreas Schwab]

Atsushi Nakagawa <atnak@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, schwab@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: Reset by checkout?

[Atsushi Nakagawa]

Andreas Schwab <schwab@linux-m68k.org> wrote:
> Atsushi Nakagawa <atnak@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
<atnak@chejz.com>
Changes are made when there is inconvenience.

Re: Reset by checkout?

[Kevin Bracey]

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

Re: Reset by checkout?

[Atsushi Nakagawa]

Kevin Bracey <kevin@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
<atnak@chejz.com>
Changes are made when there is inconvenience.

Re: Reset by checkout?

[Kevin Bracey]

On 01/06/2014 07:26, Atsushi Nakagawa wrote:
> Kevin Bracey <kevin@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 '--hard' and used '--mixed/--keep' for
> regular cases, '--hard' would effectively be -f. ;)

True, but this is quite a big shift. And I think "--keep" isn't a clear 
name in isolation. It's named relative to "--hard", rather than 
absolutely...  "Soft/Mixed/Keep" is a sensible 3-way choice, but it 
doesn't sound like it. "Keep" keeps less than soft or mixed!

Maybe a new parallel naming scheme is in order? Could we instead phrase 
it from the point of view of what we want to do with the stuff in 
ORIG_HEAD? "--to-index"/"--to-workspace"/"--drop"? (--hard deliberately 
excluded...)

Kevin

Re: Reset by checkout?

[Junio C Hamano]

Kevin Bracey <kevin@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-<.

Re: Reset by checkout?

[Kevin Bracey]

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

Re: Reset by checkout?

[Felipe Contreras]

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

Re: Reset by checkout?

[Atsushi Nakagawa]

Kevin Bracey <kevin@bracey.fi> wrote:
> On 01/06/2014 07:26, Atsushi Nakagawa wrote:
> > Kevin Bracey <kevin@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
<atnak@chejz.com>
Changes are made when there is inconvenience.

Re: Reset by checkout?

[Philip Oakley]

From: "Atsushi Nakagawa" <atnak@chejz.com>
> Kevin Bracey <kevin@bracey.fi> wrote:
>> On 01/06/2014 07:26, Atsushi Nakagawa wrote:
>> > Kevin Bracey <kevin@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 

Re: Reset by checkout?

[Kevin Bracey]

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

Re: Reset by checkout?

[Atsushi Nakagawa]

Atsushi Nakagawa <atnak@chejz.com> wrote:
> Kevin Bracey <kevin@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
<atnak@chejz.com>
Changes are made when there is inconvenience.

RE: Reset by checkout?

[Felipe Contreras]

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

RE: Reset by checkout?

[Felipe Contreras]

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

Re: Reset by checkout?

[Atsushi Nakagawa]

Felipe Contreras <felipe.contreras@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
<atnak@chejz.com>
Changes are made when there is inconvenience.

Re: Reset by checkout?

[Junio C Hamano]

Atsushi Nakagawa <atnak@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?

Re: Reset by checkout?

[Junio C Hamano]

Junio C Hamano <gitster@pobox.com> writes:

> Atsushi Nakagawa <atnak@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.