git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Junio C Hamano <gitster@pobox.com>
To: Sergio Callegari <sergio.callegari@gmail.com>
Cc: git@vger.kernel.org
Subject: Re: symbolic link management in git-archive
Date: Thu, 27 Mar 2008 12:05:25 -0700	[thread overview]
Message-ID: <7vd4pg9edm.fsf@gitster.siamese.dyndns.org> (raw)
In-Reply-To: <loom.20080327T175844-199@post.gmane.org> (Sergio Callegari's message of "Thu, 27 Mar 2008 18:34:30 +0000 (UTC)")

Sergio Callegari <sergio.callegari@gmail.com> writes:

> Unless Y is also in the tracked project...
> ...
> Note that if Y is outside of the tracked project and I make an archive,
> and then I give the archive to my friend X, Mr. X will see the same
> symbolic link, but still a completely and randomly different content
> than I do, depending on where he is unpacking the archive.

If you _do_ keep track of Y in a separate repository, I think two archives
(the one that has a pointer to Y, and the other that is taken from the
repository Y _at the revision you are using_), would solve that more
naturally.  Then the version markers recorded in the archives would still
be valid.

	Side note.  If we ever teach git-archive to create a recursive
	tarball that contains a submodule, we should be doing something
	like that, not necessarily as two separate tarballs but possibly
	with a single tarball that has two comments that describe the
	revision of the toplevel and the submodule.

> ...  In the end git archive is a nice shorthand for a checkout and a
> successive run of zip or tar and both zip and tar have a switch to
> control this dereferencing behaviour (BTW, zip on my distro dereferences
> by default, the switch is to store symbolic links).

Under such an option, at least the comment in the archive (both for zip
and tar) that notes which revision the tarball was taken from should be
omitted.  As long as that is done, I think it is Ok to have such an
optional behaviour.

  reply	other threads:[~2008-03-27 19:06 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-03-27 11:29 symbolic link management in git-archive Sergio Callegari
2008-03-27 11:40 ` Miklos Vajna
2008-03-27 11:44   ` Johannes Schindelin
2008-03-27 12:11     ` Sergio Callegari
2008-03-27 16:31 ` Junio C Hamano
2008-03-27 18:34   ` Sergio Callegari
2008-03-27 19:05     ` Junio C Hamano [this message]
2008-03-27 19:20       ` Sergio Callegari
2008-03-31 20:44     ` René Scharfe
2008-03-31 22:12       ` Sergio Callegari

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=7vd4pg9edm.fsf@gitster.siamese.dyndns.org \
    --to=gitster@pobox.com \
    --cc=git@vger.kernel.org \
    --cc=sergio.callegari@gmail.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 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 NNTP newsgroup(s).