All of lore.kernel.org
 help / color / mirror / Atom feed
From: Junio C Hamano <gitster@pobox.com>
To: Dennis Kaarsemaker <dennis@kaarsemaker.net>
Cc: git@vger.kernel.org
Subject: Re: [PATCH] Makefile: don't hardcode HEAD in dist target
Date: Mon, 02 Jun 2014 11:53:36 -0700	[thread overview]
Message-ID: <xmqq4n035ej3.fsf@gitster.dls.corp.google.com> (raw)
In-Reply-To: <20140531202507.GA9101@spirit> (Dennis Kaarsemaker's message of "Sat, 31 May 2014 22:25:10 +0200")

Dennis Kaarsemaker <dennis@kaarsemaker.net> writes:

> Instead of calling git-archive HEAD^{tree}, use $(GIT_VERSION)^{tree}.
> This makes sure the archive name and contents are consistent, if HEAD
> has moved, but GIT-VERSION-FILE hasn't been regenerated yet.
>
> Signed-off-by: Dennis Kaarsemaker <dennis@kaarsemaker.net>
> ---
> I have a somewhat odd setup in which I share a .git between multiple
> checkouts for automated builds. To minimize locking time for parallel
> builds with different options, there's only a lock around checkout and
> running git describe $commit > version, the builds themselves run in
> parallel.
>
> This works just fine except during 'make dist', which is hardcoded to
> package up HEAD, but that's not always the commit that is actually
> checked out, another process may have checked out something else.
>
> I realize this setup is somewhat strange, but the only change necessary
> to make this work is this one-line patch, so I hope that's acceptable.

The "dist" target happens to do a clean checkout to a temporary
directory with "git archive" and then muck with its contents before
tarring up the result, so moving HEAD around may appear to work for
this particular target, but htmldocs/manpages targets use what is in
the current checkout of Documentation/ area.  Turning the HEAD^{tree}
into $(GIT_VERSION)^{tree} would make the inconsistency between the
two worse, wouldn't it?

If we were to change the "dist" rules, we may want to go in the
opposite direction.  Instead of using "git archive" to make a
temporary copy of a directory from a commit, make such a temporary
copy from the contents of the current working tree (or the index).
And then tar-up a result after adding configure, version etc. to it.
That would mean what will be in the tarball can be different from
even HEAD, which is more consistent with the way how documentation
tarballs are made.

Alternatively, you can update the dist-doc rules to make a temporary
copy of documentation area and generate the documentation tarballs
out of a pristine source of a known version---which would also make
these two consistent.  I am not sure which one is more preferrable,
though.

Why are you sharing the .git/HEAD across multiple checkouts in the
first place?  If they are to build all different versions, surely
these working trees are derived from different commits, no?  Have
you considered using contrib/workdir/git-new-workdir, perhaps?

I dunno.

>  Makefile | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/Makefile b/Makefile
> index a53f3a8..63d9bac 100644
> --- a/Makefile
> +++ b/Makefile
> @@ -2433,7 +2433,7 @@ git.spec: git.spec.in GIT-VERSION-FILE
>  GIT_TARNAME = git-$(GIT_VERSION)
>  dist: git.spec git-archive$(X) configure
>  	./git-archive --format=tar \
> -		--prefix=$(GIT_TARNAME)/ HEAD^{tree} > $(GIT_TARNAME).tar
> +		--prefix=$(GIT_TARNAME)/ $(GIT_VERSION)^{tree} > $(GIT_TARNAME).tar
>  	@mkdir -p $(GIT_TARNAME)
>  	@cp git.spec configure $(GIT_TARNAME)
>  	@echo $(GIT_VERSION) > $(GIT_TARNAME)/version

  reply	other threads:[~2014-06-02 18:53 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-05-31 20:25 [PATCH] Makefile: don't hardcode HEAD in dist target Dennis Kaarsemaker
2014-06-02 18:53 ` Junio C Hamano [this message]
2014-06-02 19:34   ` Dennis Kaarsemaker
2014-06-02 20:27     ` Junio C Hamano

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=xmqq4n035ej3.fsf@gitster.dls.corp.google.com \
    --to=gitster@pobox.com \
    --cc=dennis@kaarsemaker.net \
    --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.