Re: Reset by checkout?

2014-06-09 Thread 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 
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?

2014-06-07 Thread Philip Oakley

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?

2014-06-06 Thread Atsushi Nakagawa
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?

2014-06-06 Thread Atsushi Nakagawa
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?

2014-06-03 Thread 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

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

2014-06-03 Thread 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
--
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?

2014-06-02 Thread Junio C Hamano
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?

2014-06-02 Thread Junio C Hamano
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?

2014-06-02 Thread Junio C Hamano
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?

2014-06-01 Thread Kevin Bracey

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?

2014-05-31 Thread Andreas Schwab
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?

2014-05-31 Thread 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
--
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?

2014-05-31 Thread 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

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

2014-05-31 Thread 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
--
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?

2014-05-31 Thread Atsushi Nakagawa
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?

2014-05-31 Thread Atsushi Nakagawa
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?

2014-05-31 Thread Atsushi Nakagawa
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