Re: More Beginning Git Questions

[Jakub Narebski <jnareb@gmail.com>]

tactical <a5158017@nepwk.com> writes:
> Konstantin Khomoutov wrote:
> 
>>>>> From what I read, detached heads are subject to garbage collection.
>>>>  
>>>> No, HEAD is protected against garbage collecting.  To be sure you
>>>> should name a branch when switching branches, though reflog would
>>>> protect you for 30 days (by default) even if you don't do that.
>>> 
>>> So Git doesn't really support anonymous branching as part of a normal
>>> workflow.
>> 
>> I perceive a certain logical fallacy here: you cannot switch between
>> anything anonymous because to switch, you should somehow identify
>> something to switch to--a name in whatever sense we put into this word.
> 
> In Mercurial, you can just update to a particular changeset (and you
> identify that changeset by repository-local revision number or globally
> unique ID) and then commit again.  The point is that there's no need to
> give a label to a head in Mercurial (although you can if you want to, using
> Mercurial bookmarks, which are basically the same as what Git uses).
> 
> Here's an example of anonymous branching:
> 
>     c:\test>hg init
> 
>     c:\test>echo test>foo
> 
>     c:\test>hg commit --addremove -m initial
>     adding foo
> 
>     c:\test>echo first>>foo
> 
>     c:\test>hg commit -m first
> 
>     c:\test>hg log
>     changeset:   1:3e895ec28d6c
>     tag:         tip
>     user:        tactical
>     date:        Mon Sep 26 01:39:46 2011 +0100
>     summary:     first
> 
>     changeset:   0:b51644bb3450
>     user:        tactical
>     date:        Mon Sep 26 01:39:40 2011 +0100
>     summary:     initial
> 
>     c:\test>hg update 0
>     1 files updated, 0 files merged, 0 files removed, 0 files unresolved
> 
>     c:\test>echo second>>foo
> 
>     c:\test>hg commit -m second
>     created new head
> 
>     c:\test>hg glog
>     @  changeset:   2:35c82a7e7de1
>     |  tag:         tip
>     |  parent:      0:b51644bb3450
>     |  user:        tactical
>     |  date:        Mon Sep 26 01:40:10 2011 +0100
>     |  summary:     second
>     |
>     | o  changeset:   1:3e895ec28d6c
>     |/   user:        tactical
>     |    date:        Mon Sep 26 01:39:46 2011 +0100
>     |    summary:     first
>     |
>     o  changeset:   0:b51644bb3450
>        user:        tactical
>        date:        Mon Sep 26 01:39:40 2011 +0100
>        summary:     initial
> 
> I now have two anonymous branches, and these will never be garbage
> collected.  I can easily update to either branch with "hg update 1" or "hg
> update 2" (or "hg update 0" again, if i want to create yet another
> anonymous branch).

In my opinion the need to examine either log ('hg glog') or heads
('hg heads'?) to see how to switch to anonymous branch is a PITA
that far outweights the need to name branches (to give a temporary,
local-only branch name) in Git.
 
Nb. by using "detached HEAD" for anonymous branch I meant the
following:

  $ git checkout --detach
  $ ...
  $ <work on detached head>

  worth saving?

  Y. $ git branch -b t foo/temp
     $ git checkout <other branch>
    
  N. $ git checkout <other branch>

> > The branch names is just a way to not mess with
> > SHA-1 names of commits (and to have references to those commits to keep
> > them out of consideration for garbage collection).
> > Hence the idea to demand support for anonymous branches in Git's model
> > is just unfounded.
> 
> I think it's simply a weakness of Git.  There are zero problems with
> anonymous branching in Mercurial, and it's a very powerful and simple
> system.
 
IMVVVHO it is just remains of bad initial design decision of Mercurial
about representing branches ;-PPPPPPP

Only now Mercurial has something (transferable bookmarks) which
approaches flexibility and usability of Git branches.  It took them
how long... and even then there is a [supposedly] user-friendly but
flexibility-reducing notion that branch (bookmark) names are global.


Not that Git didn't and doesn't have its share of bad design decisions
(like autimatically committing a merge).

-- 
Jakub Narębski