Re: More Beginning Git Questions

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

 



On 26 September 2011 10:56, tactical <a5158017@xxxxxxxxx> wrote:
> 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).
>
>> As I understand, by switching between branches in Mercurial you mean
>> switching between directories with clones;
>
> No.  Clones are a different topic.
>
>> As to branches, they do have names in Git but they are very loosely
>> coupled with their names: tag a tip of some branch (to still have a
>> handle on that tip commit) then delete that branch--there will be no
>> traces of that branch's name left, the branch's name is not encoded in
>> its history in any way.
>
> Git branch names are basically the same as Mercurial bookmarks.  The
> difference is that in Mercurial you don't *have* to use bookmarks.
>
>> 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.
>

I am no expert on this, however git can (of course) do 'anonymous
branching' just as simply as mercurial, with one caveat; for most
intents and purposes (as far as I have seen/heard discussed) git and
mercurial are homomorphic, and in the situations they are not git is
the more general system.

The flow that you are using for anonymous branching in mercurial is
easily reproducible in git, using detached heads. Checkout a revision
(note: not a ref)
  git checkout HEAD@{1}
hack + commit. Repeat as often as you like. Your concern is that these
will (eventually) be garbage collected. Again, I am not an expert in
this so please correct me if I have this incorrect, but the man page
for gc says:

       git-gc tries very hard to be safe about the garbage it collects. In
       particular, it will keep not only objects referenced by your current
       set of branches and tags, but also objects referenced by the index,
       remote tracking branches, refs saved by git-filter-branch in
       refs/original/, or reflogs (which may references commits in branches
       that were later amended or rewound).

As any commits you make in a detached state are in the reflog until
they expire (by default 30 days I think?) you have more than enough
time to decide if you want to keep the work - which you can do very
easily by assigning it a name. If the default time is not long enough,
simply extend it in your config
  git config gc.reflogExpire = 10000 years <- syntax might not be correct
The reason this is not true by default is that _most_ people don't
work exclusively in anonymous branches, and it is far nicer
performance wise to have git clean up for you.

So you don't *have* to use branches in git - they just make it much
easier to get around. They cost practically nothing to use, so I don't
really understand why you wouldn't want to for anything other than
just a quick throwaway test or scratch idea.

I hope that clears it up a little.

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