Re: EasyGit Integration

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 2009.06.13 01:30:38 +0300, Felipe Contreras wrote:
> On Sat, Jun 13, 2009 at 1:05 AM, Jakub Narebski<jnareb@xxxxxxxxx> wrote:
> > On Fri, 12 Jun 2009, Felipe Contreras wrote:
> >> On Sat, Jun 13, 2009 at 12:21 AM, Jakub Narebski<jnareb@xxxxxxxxx> wrote:
> >
> >>> Nope. 'git reset' always reset some part of state to a given commit,
> >>> HEAD by default.  It can reset current branch with --soft, branch plus
> >>> index with --mixed (default), and branch plus index plus working
> >>> directory with --hard.  Source is always commit.
> >>
> >> You said it: 'git reset --hard' gets something out of the repository
> >> and into the working directory.
> >>
> >> Try this:
> >> git checkout <random sha-1 with no ref>
> >>
> >> Then what is the difference between:
> >> git checkout HEAD^
> >> git reset --hard HEAD^
> >>
> >> In this case they do exactly the same thing, don't they?
> >
> > No, they don't.  "git checkout HEAD^" modifies HEAD detaching it.
> > "git reset --hard HEAD^" modifies branch that HEAD points to (well,
> > unless HEAD is detached).
> 
> Read again:
> >> git checkout <random sha-1 with no ref>
> 
> The HEAD is detached, so they do exactly the same in this case.

Not if there are uncommitted changes to tracked files.

Björn
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]