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 co
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
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" all
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 p
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
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 separa
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_HEA
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 th
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 b
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
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 ri
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"
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
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
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
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
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 u
17 matches
Mail list logo
