Re: [PATCH 3/3] prevent HEAD reflog to be interpreted as current branch reflog

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

 



On Fri, 2 Feb 2007, Lars Hjemli wrote:

> On 2/2/07, Johannes Schindelin <Johannes.Schindelin@xxxxxx> wrote:
> > Hi,
> >
> > On Fri, 2 Feb 2007, Jakub Narebski wrote:
> >
> > > Perhaps we should use @{...} to refer to reflog for HEAD, or use yet
> > > another special notation?
> >
> > No.
> >
> > IMHO "bla@{yesterday}" should give you what "bla" pointed to, yesterday.
> > In that sense, the proposed reflog on "HEAD" makes perfect sense.
> 
> Since HEAD is a synonym for "current branch" everywhere else in git,
> while .git/logs/HEAD will be a log of detached HEAD (plus branch
> switches, I guess), I think the following makes perfect sense:
> 
>  "HEAD@{yesterday}" = current branch, yesterday
>  "@{yesterday}"     = detached head (no branch), yesterday

No it doesn't.

HEAD is a moving pointer.  Sometimes it means the current branch, 
sometimes it doesn't.

So HEAD is _NOT_ a synonym for "current branch" everywhere already.

And it is really nice to reflog the switching between branch which makes 
sense only if HEAD has a reflog of its own.

If I want to know where HEAD was yesterday, then the only way to get to 
this info is with a separate reflog for HEAD.  IF HEAD was a synonym for 
the current branch then it is impossible to know where HEAD was 
yesterday because you only get the info about where the current branch 
was yesterday.  But it is all possible that the yesterday's current 
branch wasn't the same as today's current branch.


Nicolas
-
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]