All of lore.kernel.org
 help / color / mirror / Atom feed
From: Junio C Hamano <junkio@cox.net>
To: Andy Parkins <andyparkins@gmail.com>
Cc: git@vger.kernel.org
Subject: Re: git submodule support feedback
Date: Thu, 26 Apr 2007 14:35:46 -0700	[thread overview]
Message-ID: <7vfy6mstsd.fsf@assigned-by-dhcp.cox.net> (raw)
In-Reply-To: <200704262228.46864.andyparkins@gmail.com> (Andy Parkins's message of "Thu, 26 Apr 2007 22:28:44 +0100")

Andy Parkins <andyparkins@gmail.com> writes:

> On Thursday 2007, April 26, Andy Parkins wrote:
>
>> I'll report further as I come across any stumbling blocks; but here
>
> The submodule support requires the latest version of git right?  That's 
> going to cause trouble for people running different versions of git 
> (I've already experienced it in my own limited way - I had to upgrade 
> all the copies of git I have on my various computers before fetching 
> and pushing would work).  If the repository contains a submodule 
> reference it effectively becomes inaccessible by a version of git 
> without submodule support.
>
> I think that we might be able to avoid that problem though - am I right 
> in thinking that the problem is that all the tools need teaching not to 
> follow the gitlink object because that hash doesn't exist in _this_ 
> tree it is a reference to a commit in another tree.
>
> Wouldn't it be better if the gitlink reference pointed at an object in 
> this tree which in turn referred to the submodule commit?  That way the 
> old versions of git would still work with submodule objects in the 
> repository because they would just see submodules as pointing at a 
> blob.
>
> Have I oversimplified it in my head?

I think older tools do not expect to find anything but tree or
blob in a tree object to begin with.  Now your experimental
repository has a commit, which they do not expect to see and I
think they will be unhappy.

If you replace the commit objects in your trees with a new type
of object 'gitlink', your older tools will have exactly the same
problem, won't they?

  parent reply	other threads:[~2007-04-26 21:35 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-04-26 11:38 git submodule support feedback Andy Parkins
2007-04-26 11:56 ` Marco Costalba
2007-04-26 12:08   ` Andy Parkins
2007-04-26 21:28 ` Andy Parkins
2007-04-26 20:59   ` David Lang
2007-04-26 21:35   ` Junio C Hamano [this message]
2007-04-26 21:49     ` Andy Parkins

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=7vfy6mstsd.fsf@assigned-by-dhcp.cox.net \
    --to=junkio@cox.net \
    --cc=andyparkins@gmail.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.