git@vger.kernel.org mailing list mirror (one of many)
 help / color / mirror / code / Atom feed
From: Johannes Schindelin <Johannes.Schindelin@gmx.de>
To: Lars Hjemli <hjemli@gmail.com>
Cc: git@vger.kernel.org, "Junio C Hamano" <gitster@pobox.com>,
	"René Scharfe" <rene.scharfe@lsrfire.ath.cx>
Subject: Re: [RFC/PATCH v3 3/3] archive.c: add basic support for submodules
Date: Sat, 24 Jan 2009 14:51:53 +0100 (CET)	[thread overview]
Message-ID: <alpine.DEB.1.00.0901241443270.13232@racer> (raw)
In-Reply-To: <8c5c35580901240044y452b465fj94df82fc2b8f7ee9@mail.gmail.com>

Hi,

On Sat, 24 Jan 2009, Lars Hjemli wrote:

> On Fri, Jan 23, 2009 at 20:57, Johannes Schindelin
> <Johannes.Schindelin@gmx.de> wrote:
> >
> >  in all of Git, we try to assume that only reachable objects are valid 
> >  objects.
> 
> I don't think this is true (most git commands accepts their arguments
> as valid objects without verifying if they are reachable from a ref).

The fact that a user can ask for some object directly, and that we do not 
try to validate it in that case has nothing to do with said assumption.

If something is pushed to a remote, and the connection fails, some commit 
could be pushed already, but some of its reachable objects lacking.

The user on the remote side can still try to salvage parts by accessing 
the objects directly, by their name.

But the only guarantee that the objects are reachable is to start from a 
ref.

Concretely, if your patch is applied as-is, such a half-pushed state could 
affect git-archive in a nasty way: even if the user started from a ref, 
there could be missing objects!

> Do you feel it is necessary to perform a reachability check of the 
> gitlink'd commit before traversing into a submodule tree?

No.  Because HEAD is a ref, too.

Now, there is still a problem when your submodule is missing the objects 
for the commit your superproject is referring to.

IMO that is a serious issue, as it just asks for confused users.

> > - presence of a specific commit in the supermodule is a _lousy_ 
> >   indicator that the user wants to include that submodule in the 
> >   archive.
> 
> This is the issue I tried to address with my
> `--submodules=[a|c|r][g:<name>]` proposal in the commit message for
> this patch.

Nope, doing this "in the future" does not please me one bit.

Besides, I find the semantics, uhm, "interesting".  (The other word would 
be "unintuitive".  Why do you have to be so cryptic that I have to read 
the proposal to understand what the heck "c" is about?)

Ciao,
Dscho

  reply	other threads:[~2009-01-24 13:53 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-01-22 21:17 [RFC/PATCH v3 0/3] Add support for `git archive --submodules` Lars Hjemli
2009-01-22 21:17 ` [RFC/PATCH v3 1/3] tree.c: teach read_tree_recursive how to traverse gitlink entries Lars Hjemli
2009-01-22 21:17   ` [RFC/PATCH v3 2/3] sha1_file: prepare for adding alternates on demand Lars Hjemli
2009-01-22 21:17     ` [RFC/PATCH v3 3/3] archive.c: add basic support for submodules Lars Hjemli
2009-01-22 23:44       ` Johannes Schindelin
2009-01-23 18:40         ` Lars Hjemli
2009-01-23 19:23           ` Junio C Hamano
2009-01-23 20:15             ` Lars Hjemli
2009-01-23 20:50               ` Junio C Hamano
2009-01-23 21:15                 ` Lars Hjemli
2009-01-23 19:57           ` Johannes Schindelin
2009-01-24  8:44             ` Lars Hjemli
2009-01-24 13:51               ` Johannes Schindelin [this message]
2009-01-24 19:26                 ` Lars Hjemli
2009-01-24 19:52                   ` Johannes Schindelin
2009-01-24 20:02                     ` Lars Hjemli
2009-01-22 23:43     ` [RFC/PATCH v3 2/3] sha1_file: prepare for adding alternates on demand Johannes Schindelin
2009-01-23 18:35       ` Lars Hjemli
2009-01-23 19:54         ` Johannes Schindelin

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

  List information: http://vger.kernel.org/majordomo-info.html

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

  git send-email \
    --in-reply-to=alpine.DEB.1.00.0901241443270.13232@racer \
    --to=johannes.schindelin@gmx.de \
    --cc=git@vger.kernel.org \
    --cc=gitster@pobox.com \
    --cc=hjemli@gmail.com \
    --cc=rene.scharfe@lsrfire.ath.cx \
    /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.
Code repositories for project(s) associated with this public inbox

	https://80x24.org/mirrors/git.git

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 read-only IMAP folder(s) and NNTP newsgroup(s).