Re: newbie questions about git design and features (some wrt hg)

From: Jakub Narebski <jnareb@gmail.com>
Date: Feb 3, 2007, 20:55 UTC
Message-ID: <200702032155.16987.jnareb@gmail.com>
In-Reply-To: <20070203200638.GA6888@xanadu.kublai.com>

On 03.02.2007, Brendan Cully <brendan@kublai.com> wrote:

> On Friday, 02 February 2007 at 20:56, Jakub Narebski wrote:

Show 15 quoted lines

>> For example you are on branch 'master', you tag current release
>> e.g. v1.3.4, then you checkout branch 'devel'... and you don't have
>> v1.3.4 tag available unless you merge in .hgtags from 'master'.
>> At least from what I understand of Mercurial tags behaviour.
> 
> This would be bad, if it were true.
> 
> $ hg up devel
> 2 files updated, 0 files merged, 0 files removed, 0 files unresolved
> $ cat .hgtags
> 6acda9aa5d8c621b3db2f2daab878d8de726d227 base
> $ hg tags
> tip                                4:b1f003583d8e
> v1.3.4                             2:87e43e86318f
> base                               0:6acda9aa5d8c

The above sequence of commands is not enough to reproduce the situation I want to talk about, namely situation (repository structure) as in below:

                    /-\ 
   1---a---2---3---T---t---b   .... 'master' branch
        \ 
         \-2'--3'--c           .... 'devel' branch

where 'a' is branching point (merge base) of 'master' and 'devel' branches, 'T' is tagged changeset (revision, commit), 't' is commit where .hgtags with 'T' tag was committed. Changesets (revisions) 'b' and 'c' are tips of 'master' and 'devel' branch, respectively.

If .hgtags was an ordinary file, then at revision marked in above graph as '2' it wouldn't have tag 'T'. Documentation (Mercurial HOWTO to be more exact) tells that hg uses .hgtags version from the tip. But when we are at branch 'devel', the version from the tip is version 'c' without 'T', not version 'b' with 'T'... if .hgtags would behave as described in documentation.

It looks however (if what you say above is true also for the situation as in above graph, i.e. when at 'devel' branch we have 'T' in .hgtags) that Mercurial always uses _latest_ version of .hgtags file (as in external wall time, having notihing to do with the history as represented in repository). But then we cannot say that we can merge .hgtags file, so it is probably not the case. It is also contrary to what I gathered from documentation.

If above was true, i.e. .hgtags doesn't behave at all as normal file in working area, then what the heck it is doing there, and not somewhere under .hgtags!?!

> As mentioned before, hg has local tags which sound an awful lot like
> git tags.

Git tags can be propagated. hg local tags cannot be propagated. hg tags "in history" always are propagated.

> It also has properly versioned tags.

Reusing in-tree version control to version tags is IMVHO not a good idea. Git has reflogs if you truly need to have history of tags.

> And, by the way, if you  
> push a branch, you only push the tags that were committed on that
> branch. Furthermore, you can push based on a tag name that isn't
> committed in the branch you're pushing.

It seems awfully complicated.

Show 6 quoted lines

> I think the "globally global" 
> nonsense elsewhere in this thread may be a result of not understanding
> this.
> 
> I'm probably done with this thread too. There's too much ignorant
> speculation to make it very productive.

-- 
Jakub Narebski
Poland