All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jonathan Nieder <jrnieder@gmail.com>
To: Tomas Carnecky <tom@dbservice.com>
Cc: git@vger.kernel.org, Sverre Rabbelier <srabbelier@gmail.com>,
	David Michael Barr <david.barr@cordelta.com>,
	Ramkumar Ramachandra <artagnon@gmail.com>
Subject: Re: [PATCH 1/6] Remote helper: accept ':<value> <name>' as a response to 'list'
Date: Mon, 4 Oct 2010 21:00:35 -0500	[thread overview]
Message-ID: <20101005020035.GA10818@burratino> (raw)
In-Reply-To: <1286108511-55876-1-git-send-email-tom@dbservice.com>

Hi,

Tomas Carnecky wrote:

>                                                          The ref is first stored
> as 'impure', meaning that it doesn't have any representation within git. Only
> after the remote helper fetches that version into git, it can tell us which
> git object (SHA1) that revision maps to.

Hmm.

The existing ls-remote output looks something like

	<object id>	HEAD
	<object id>	<refname>
	<object id>	<refname>
	...
	<object id>	<tag refname>
	<object id>	<tag refname>^{}
	...

In particular, each line has a 40-character object id, a tab character,
and then something like a refname.

If we want to extend that, wouldn't we need to do something like

	0000...0000	<refname>
	0000...0000	<refname> is r11

to avoid breaking people's scripts?  For example, I wouldn't be surprised
if scripts are relying on the following two properties:

 - each object id is 40 characters (e.g., the old fetch--tool
   in contrib/examples relies on this)
 - each object id contains no whitespace

simply because they are convenient to script with.

  reply	other threads:[~2010-10-05  2:04 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-10-03 11:33 [RFC] New type of remote helpers Tomas Carnecky
2010-10-03 12:21 ` [PATCH 1/6] Remote helper: accept ':<value> <name>' as a response to 'list' Tomas Carnecky
2010-10-05  2:00   ` Jonathan Nieder [this message]
2010-10-07 21:17     ` Sverre Rabbelier
2010-10-03 12:21 ` [PATCH 2/6] Allow more than one keepfile in the transport Tomas Carnecky
2010-10-05  2:11   ` Jonathan Nieder
2010-10-03 12:21 ` [PATCH 3/6] Allow the transport fetch command to add additional refs Tomas Carnecky
2010-10-05  2:18   ` Jonathan Nieder
2010-10-03 12:21 ` [PATCH 4/6] Rename get_mode() to decode_tree_mode() and export it Tomas Carnecky
2010-10-05  2:23   ` Jonathan Nieder
2010-10-03 12:21 ` [PATCH 5/6] Introduce the git fast-import-helper Tomas Carnecky
2010-10-03 15:31   ` Jonathan Nieder
2010-10-03 15:45     ` Tomas Carnecky
2010-10-03 15:53       ` Sverre Rabbelier
2010-10-03 17:39         ` Tomas Carnecky
2010-10-03 23:15           ` Sverre Rabbelier
2010-10-03 12:21 ` [PATCH 6/6] Add git-remote-svn Tomas Carnecky
2010-10-05  2:26   ` Jonathan Nieder
2010-10-03 13:56 ` [RFC] New type of remote helpers Sverre Rabbelier
2010-10-03 15:13   ` Jonathan Nieder
2010-10-03 17:07     ` Ramkumar Ramachandra

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=20101005020035.GA10818@burratino \
    --to=jrnieder@gmail.com \
    --cc=artagnon@gmail.com \
    --cc=david.barr@cordelta.com \
    --cc=git@vger.kernel.org \
    --cc=srabbelier@gmail.com \
    --cc=tom@dbservice.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 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.