All of lore.kernel.org
 help / color / mirror / Atom feed
From: Michael Haggerty <mhagger@alum.mit.edu>
To: David Turner <dturner@twopensource.com>, git@vger.kernel.org
Subject: Re: [PATCH/RFC 0/9] Pseudorefs
Date: Mon, 03 Aug 2015 00:48:05 +0200	[thread overview]
Message-ID: <55BE9E25.6050902@alum.mit.edu> (raw)
In-Reply-To: <1437713129-19373-1-git-send-email-dturner@twopensource.com>

On 07/24/2015 06:45 AM, David Turner wrote:
> This series is another chunk of the pluggable refs backend work.  The
> major reason it is listed as "PATCH/RFC" is beacuse it breaks
> t9300-fast-import.sh, because fast-import wants to create a ref called
> TEMP_TAG, which would now be a pseudoref.  The commit that introduces
> this test says that cvs2svn creates a tag called TAG_FIXUP "as a branch
> name for temporary work needed to cleanup the tree prior to creating
> an annotated tag object."
> 
> It appears that cvs2svn still does this.  So I'm not quite sure what to
> do about this particular case.
> 
> As we discussed earlier, the motivation for this series is that refs
> backends other than the files-based backend need to treat per-worktree
> refs (HEAD) and pseudorefs (FETCH_HEAD) differently from other refs;
> other refs are per-repo rather than per-worktree.

Sorry, I missed this email while on vacation.

cvs2git needs to create a temporary reference for cobbling together
tagged commits. Originally I was going to use the name `TAG_FIXUP`, as
suggested by git-fast-import(1) [1]. But that functionality turned out
to be buggy in `git fast-import` at the time. So I reported the bug but
changed cvs2git to use `refs/heads/TAG.FIXUP` [2]. The bug in `git
fast-import` was fixed, including the test case that you found, but I
never changed cvs2git back to using the originally-planned name. The
fact that the test case uses a name different than `TAG_FIXUP` probably
means that Shawn thought that any references named similarly should be
allowed.

Summary: support for a reference named `TAG_FIXUP` is not needed by
cvs2git. However, its use is a documented recommendation of `git
fast-import`, so it is quite possible that other importers are using
this name.

I expect that such importers would slightly prefer that this reference
be worktree-specific, but I doubt that anybody really cares that much.
It seems unlikely that people will run `git fast-import` in multiple
worktrees simultaneously.

Michael

[1] http://git-scm.com/docs/git-fast-import#_use_tag_fixup_branches
[2]
https://github.com/mhagger/cvs2svn/blob/master/cvs2svn_lib/git_output_option.py#L502-L509

-- 
Michael Haggerty
mhagger@alum.mit.edu

      parent reply	other threads:[~2015-08-02 22:48 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-07-24  4:45 [PATCH/RFC 0/9] Pseudorefs David Turner
2015-07-24  4:45 ` [PATCH 1/9] refs: Introduce pseudoref and per-worktree ref concepts David Turner
2015-07-24  7:34   ` Eric Sunshine
2015-07-24 19:20   ` Junio C Hamano
2015-07-24 20:13     ` David Turner
2015-07-24 20:44       ` Junio C Hamano
2015-07-24 19:52   ` Philip Oakley
2015-07-24 20:14     ` David Turner
2015-07-24  4:45 ` [PATCH 2/9] notes: replace pseudorefs with real refs David Turner
2015-07-24  4:45 ` [PATCH 3/9] bisect: do not use update-ref for BISECT_HEAD David Turner
2015-07-24  4:45 ` [PATCH 4/9] tests: treat FETCH_HEAD as a pseudoref David Turner
2015-07-24  4:45 ` [PATCH 5/9] tests: use --create-reflog option to git update-ref David Turner
2015-07-24  4:45 ` [PATCH 6/9] pseudorefs: create and use pseudoref update and delete functions David Turner
2015-07-24 19:25   ` Junio C Hamano
2015-07-24 20:17     ` David Turner
2015-07-24 20:53       ` Junio C Hamano
2015-07-24  4:45 ` [PATCH 7/9] am/rebase: update pseudorefs by writing files David Turner
2015-07-24  4:45 ` [PATCH 8/9] rebase: use write_pseudoref David Turner
2015-07-24  4:45 ` [PATCH 9/9] refs: forbid pseudoref updates through ref update API David Turner
2015-08-02 22:48 ` Michael Haggerty [this message]

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=55BE9E25.6050902@alum.mit.edu \
    --to=mhagger@alum.mit.edu \
    --cc=dturner@twopensource.com \
    --cc=git@vger.kernel.org \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.