git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Jakub Narebski <jnareb@gmail.com>
To: Junio C Hamano <gitster@pobox.com>
Cc: Brian Gernhardt <benji@silverinsanity.com>,
	Russ Dill <russ.dill@gmail.com>,
	"Stephen Sinclair" <radarsat1@gmail.com>,
	git@vger.kernel.org, mercurial@selenic.com
Subject: Re: branch description
Date: Wed, 16 Apr 2008 21:56:26 +0200	[thread overview]
Message-ID: <200804162156.27435.jnareb@gmail.com> (raw)
In-Reply-To: <7vfxtmtlm0.fsf@gitster.siamese.dyndns.org>

On Wed, 16 April 2008, Junio C Hamano <gitster@pobox.com> wrote:
> Jakub Narebski <jnareb@gmail.com> writes:
> 
> > Please, let's don't repeat Mercurial mistake of placing unversioned
> > information (such as branch names in case of Mercurial, or branches
> > descriptions in this case) in-tree, i.e. version it.

I'm sorry, I meant here "tags" not "branch names"... I think...

> Is it really a "mistake" in Mercurial's context?

If we are talking about tags support in Mercurial, I think it is
mistake or at least bad design decision.  Tags are, and should be,
unversioned (or at least versioned separately) but propagated (or
rather propagatable).  Mercurial offers either in-tree .hgtags,
which are always automatically propagated (not merely propagatable);
but this mechanism is by default versioned, and Mercurial does
complicated dance to get reasonable tags semantic.  And there is
[theoretical] problem of merging .hgtags file; perhaps solved by
specialized merge strategy for this file.

Alternatively Mercurial offers so called local tags, which are not
versioned, but not propagated (and AFAIK non propagatable).

So yes, it is a bad design in my opinion.

> I thought that their named branches do have defined "starting point", and
> it is not a mistake at all for them to version "from this point on, this
> lineage of history is associated with this symbolic name (which is a
> branch)".

What happens if there is branching point _after_ such "branch naming tag"?
Unless branch names are purely local and non-propagatable, and Mercurial
can use local revision numbers or something  like this...

I find this CVS legacy to branching (doesn't Subversion use also
something like that) to be stupid.

> It probably does not make sense in the context of git where a branch is
> defined to be "illusion" (at least currently).

BTW. another tool that has yet another idea of what "branch" is
is Monotone, which AFAIK understands branch in reflog sense, via
Monotone's signature signatures ;-)

P.S. Cc-ed mercurial mailing list, to give them chance to respond
to those "accusations"... if it is not subscribe only...
-- 
Jakub Narebski
Poland

  reply	other threads:[~2008-04-16 20:07 UTC|newest]

Thread overview: 26+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-04-15 16:51 branch description Stephen Sinclair
2008-04-15 17:31 ` Russ Dill
2008-04-15 18:01   ` Brian Gernhardt
2008-04-15 19:12     ` Junio C Hamano
2008-04-15 19:19       ` Jeff King
2008-04-15 22:37         ` Jeff King
2008-04-15 22:56           ` Junio C Hamano
2008-04-15 20:53       ` Stephen Sinclair
2008-04-15 21:04         ` Brian Gernhardt
2008-04-16  1:33       ` Jakub Narebski
2008-04-16  2:55         ` Jeff King
2008-04-16  3:28         ` Stephen Sinclair
2008-04-16  5:55           ` Mike Hommey
2008-04-16  3:46         ` Matt Graham
2008-04-16  8:29           ` Johan Herland
2008-04-18 21:58             ` Jakub Narebski
2008-04-19  9:18               ` Johan Herland
2008-04-19 17:43                 ` Junio C Hamano
2008-04-19 18:09                   ` Johan Herland
2008-04-19 21:05                 ` Jakub Narebski
2008-04-16  5:27         ` Junio C Hamano
2008-04-16 19:56           ` Jakub Narebski [this message]
2008-04-15 18:36   ` Jakub Narebski
  -- strict thread matches above, loose matches on Subject: below --
2008-04-22 17:57 Michael Dressel
2008-04-22 18:46 ` Johan Herland
2008-04-22 18:59 ` Jakub Narebski

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=200804162156.27435.jnareb@gmail.com \
    --to=jnareb@gmail.com \
    --cc=benji@silverinsanity.com \
    --cc=git@vger.kernel.org \
    --cc=gitster@pobox.com \
    --cc=mercurial@selenic.com \
    --cc=radarsat1@gmail.com \
    --cc=russ.dill@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).