From: Marc Branchaud <marcnarc@xiplink•com>
To: Johan Herland <johan@herland•net>
Cc: git@vger•kernel.org, Sverre Rabbelier <srabbelier@gmail•com>,
Junio C Hamano <gitster@pobox•com>,
Jonathan Nieder <jrnieder@gmail•com>,
Shawn Pearce <spearce@spearce•org>, Kenny Root <kroot@google•com>,
Thomas Rast <trast@student•ethz.ch>
Subject: Re: Tag refspecs (was Re: [PATCH] Remove restriction on notes ref base)
Date: Fri, 05 Nov 2010 11:11:34 -0400 [thread overview]
Message-ID: <4CD41EA6.1090003@xiplink.com> (raw)
In-Reply-To: <201011050202.16931.johan@herland.net>
On 10-11-04 09:02 PM, Johan Herland wrote:
> On Thursday 04 November 2010, Marc Branchaud wrote:
>> On 10-11-03 08:49 PM, Johan Herland wrote:
>>> I'd probably suggest a more straightforward (and hopefully less
>>> confusing)
>>>
>>> setup like this:
>>> Remote repo -> Local repo
>>> ------------------------------------------------
>>> refs/heads/* refs/remotes/$remote/heads/*
>>> refs/tags/* refs/remotes/$remote/tags/*
>>> refs/notes/* refs/remotes/$remote/notes/*
>>>
>>> ...and these would all be set in the config, i.e. no implicit/magic
>>> refspecs.
>>
>> I'll second this proposal, at least as far as tags go. I can offer two
>> reasons to support this.
>>
>>
>> First, I think the assumption that tags are immutable is too strong. In
>> our repo, we try to keep our topic branches mergeable into both the
>> "master" and "maintenance-of-the-latest-release" branches.
>>
>> This means the topic branches need to be based at the point where the
>> maintenance and master branches diverged. Making this rule easy to
>> follow is best accomplished with a tag, e.g. "topic-base", but that tag
>> will move when we create a new maintenance branch for a new release.
>> With the current tag semantics, when that happens everyone has to delete
>> their local topic-base tags and get the new one from the common/shared
>> repo. People who forget to do this end up basing their topics on
>> outdated code, with predictable results.
>>
>> It would be much easier to be able to just use an "origin/topic-base" tag
>> instead, one that that tracks the topic-base tag in the origin repo.
>
> Actually, this is not a valid reason. To me, it sounds like your "topic-
> base" tag _really_ should be a "topic_base" _branch_. The branch is
> initialized to the merge-base between "master" and "maintenance-of-the-
> latest-release" branches, and when you create a new maintenance branch, the
> "topic-base" branch is fast-forwarded along the master branch until it
> reaches the merge-base with the new maintenance branch. (Remember that
> branches really are nothing but named pointers into the commit graph, and as
> long as the "topic-base" branch stays within the history of the "master"
> branch, it does not constitute a proper "branch", i.e. a fork in the commit
> history.)
I understand how a branch can, with careful management, mechanically achieve
the behaviour I want.
But the problem with that approach is that it breaks as soon as someone
commits to the topic-base branch (an easy mistake to make, especially for
rookie users). Then that person would base later topics on the wrong commit,
and worse, if they pushed their "topic-base" branch to our shared repo then
everyone would be affected.
A hook in the shared repo could prevent the pushing of the topic-base branch,
but that that's just a complicated, half-baked way of making a branch behave
like a tag. A tag doesn't need the careful management that a branch would.
Anyway, regardless of whether or not the scenario I described is valid, I
still wonder if tag immutability makes sense when remote tags live in the
repo's namespace. If a repo first sets tag "foo" to point to commit 'A' then
later changes "foo" to point to 'B', shouldn't my clone's "repo/foo" tag
update automatically to reflect that? I see little point in keeping my
"repo/foo" tag pointing at commit 'A'.
M.
next prev parent reply other threads:[~2010-11-05 15:10 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-11-02 0:16 [PATCH] Remove restriction on notes ref base Kenny Root
2010-11-02 6:52 ` Jonathan Nieder
2010-11-02 8:48 ` Johan Herland
2010-11-02 14:11 ` Shawn Pearce
2010-11-02 14:29 ` Jeff King
2010-11-02 15:24 ` Johan Herland
2010-11-02 17:41 ` Junio C Hamano
2010-11-02 22:58 ` Johan Herland
2010-11-02 23:28 ` Chris Forbes
2010-11-03 6:41 ` Jonathan Nieder
2010-11-03 16:17 ` Junio C Hamano
2010-11-03 16:30 ` Sverre Rabbelier
2010-11-04 0:49 ` Johan Herland
2010-11-04 1:00 ` Sverre Rabbelier
2010-11-04 14:35 ` Tag refspecs (was Re: [PATCH] Remove restriction on notes ref base) Marc Branchaud
2010-11-05 1:02 ` Johan Herland
2010-11-05 15:11 ` Marc Branchaud [this message]
2010-11-04 14:58 ` [PATCH] Remove restriction on notes ref base Jeff King
2010-11-05 1:29 ` Johan Herland
2010-11-05 14:55 ` Jeff King
2010-11-03 16:35 ` Jonathan Nieder
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=4CD41EA6.1090003@xiplink.com \
--to=marcnarc@xiplink$(echo .)com \
--cc=git@vger$(echo .)kernel.org \
--cc=gitster@pobox$(echo .)com \
--cc=johan@herland$(echo .)net \
--cc=jrnieder@gmail$(echo .)com \
--cc=kroot@google$(echo .)com \
--cc=spearce@spearce$(echo .)org \
--cc=srabbelier@gmail$(echo .)com \
--cc=trast@student$(echo .)ethz.ch \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
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