All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Greg A. Woods" <woods@planix.com>
To: The Git Mailing List <git@vger.kernel.org>
Cc: Dmitry Potapov <dpotapov@gmail.com>
Subject: Re: multiple working directories for long-running builds (was: "git merge" merges too much!)
Date: Tue, 01 Dec 2009 12:59:58 -0500	[thread overview]
Message-ID: <m1NFX19-000kn4C@most.weird.com> (raw)
In-Reply-To: <20091201054734.GB11235@dpotapov.dyndns.org>

[-- Attachment #1: Type: text/plain, Size: 2257 bytes --]

At Tue, 1 Dec 2009 08:47:34 +0300, Dmitry Potapov <dpotapov@gmail.com> wrote:
Subject: Re: "git merge" merges too much!
> 
> On Mon, Nov 30, 2009 at 07:24:14PM -0500, Greg A. Woods wrote:
> > 
> > Things get even weirder if you happen to be playing with older branches
> > too -- most build tools don't have ability to follow files that go back
> > in time as they assume any product files newer than the sources are
> > already up-to-date, no matter how much older the sources might become on
> > a second build.
> 
> No, files do not go back in time when you switch between branches. The
> timestamp on files is the time when they are written to your working
> tree

Hmmm, I didn't really say anything in particular about file timestamps
-- I meant the file content may go back in time.  More correctly I
should have said that the file content may become inconsistent with the
state of other files that have just been compiled.

If the timestamps do not get set back to commit time, but rather are
simply updated to move the last modify time to the time each change is
made to a working file (which is as you said, to be expected),
regardless of whether its content goes back in time or not, then this
may or may not help a currently running build to figure out what really
needs to be re-compiled.  Likely it won't even for a recursive-make
style update build, but certainly not for one where all build actions
are pre-determined before any of them are started.

If the content of one or more files goes back in time to an earlier
state while the compile is happening then ultimately the result must be
considered to be undefined.  The best you can hope for is a break in the
compile.

This is why I agreed with you that a build should never be done in a
working directory where any file editing or VCS action is occurring
simultaneously.

I just disagreed that "git archive" was a reasonable alternative to
leaving the working directory alone during the entire time of the build.
It is not really reasonable for large projects any more than stopping
all work on the sources is reasonable.

-- 
						Greg A. Woods
						Planix, Inc.

<woods@planix.com>       +1 416 218 0099        http://www.planix.com/

[-- Attachment #2: Type: application/pgp-signature, Size: 186 bytes --]

  reply	other threads:[~2009-12-01 18:00 UTC|newest]

Thread overview: 33+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-11-29  3:21 "git merge" merges too much! Greg A. Woods
2009-11-29  5:14 ` Jeff King
2009-11-30 18:12   ` Greg A. Woods
2009-11-30 19:22     ` Dmitry Potapov
2009-12-01 18:52       ` Greg A. Woods
2009-12-01 20:50         ` Dmitry Potapov
2009-12-01 21:58           ` Greg A. Woods
2009-12-02  0:22             ` Dmitry Potapov
2009-12-02 10:20         ` Nanako Shiraishi
2009-12-02 20:09     ` Jeff King
2009-12-03  1:21       ` Git documentation consistency (was: "git merge" merges too much!) Greg A. Woods
2009-12-03  1:34         ` Git documentation consistency Junio C Hamano
2009-12-03  7:22           ` Greg A. Woods
2009-12-03  7:45             ` Jeff King
2009-12-03 15:24               ` Uri Okrent
2009-12-03 16:22             ` Marko Kreen
2009-12-09 19:56               ` Greg A. Woods
2009-12-03  2:07         ` Git documentation consistency (was: "git merge" merges too much!) Jeff King
2009-11-29  5:15 ` "git merge" merges too much! Junio C Hamano
2009-11-30 18:40   ` Greg A. Woods
2009-11-30 20:50     ` Junio C Hamano
2009-11-30 21:17     ` Dmitry Potapov
2009-12-01  0:24       ` Greg A. Woods
2009-12-01  5:47         ` Dmitry Potapov
2009-12-01 17:59           ` Greg A. Woods [this message]
2009-12-01 18:51             ` multiple working directories for long-running builds (was: "git merge" merges too much!) Dmitry Potapov
2009-12-01 18:58               ` Greg A. Woods
2009-12-01 21:18                 ` Dmitry Potapov
2009-12-01 22:25                   ` Jeff Epler
2009-12-01 22:44                   ` Greg A. Woods
2009-12-02  0:10                     ` Dmitry Potapov
2009-12-03  5:11                       ` Greg A. Woods
2009-12-02  2:09                   ` multiple working directories for long-running builds 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=m1NFX19-000kn4C@most.weird.com \
    --to=woods@planix.com \
    --cc=dpotapov@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.