From mboxrd@z Thu Jan 1 00:00:00 1970 From: Michael Witten Subject: Re: Branches & directories Date: Tue, 23 Aug 2011 14:46:04 +0000 Message-ID: References: <7vvctvdf5r.fsf@alter.siamese.dyndns.org> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: QUOTED-PRINTABLE Cc: Kyle Moffett , Junio C Hamano , Evan Shelhamer , Git Mailing List To: Hilco Wijbenga X-From: git-owner@vger.kernel.org Tue Aug 23 16:46:51 2011 Return-path: Envelope-to: gcvg-git-2@lo.gmane.org Received: from vger.kernel.org ([209.132.180.67]) by lo.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1QvsFd-0000J3-LU for gcvg-git-2@lo.gmane.org; Tue, 23 Aug 2011 16:46:50 +0200 Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753879Ab1HWOqp convert rfc822-to-quoted-printable (ORCPT ); Tue, 23 Aug 2011 10:46:45 -0400 Received: from mail-yi0-f46.google.com ([209.85.218.46]:39712 "EHLO mail-yi0-f46.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753247Ab1HWOqo convert rfc822-to-8bit (ORCPT ); Tue, 23 Aug 2011 10:46:44 -0400 Received: by yie30 with SMTP id 30so139389yie.19 for ; Tue, 23 Aug 2011 07:46:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding; bh=zFojgpMuSX9XYU447mAcQ2onbjIV00sFNunZbnN7BQs=; b=gMJMmVEJSdgiwBUxi1HWQ4ADCx5/84vLVT/wpk4tImS+9KT3XvVTyhn8UpKvQqy9Eu M1ZEjI5OdietwJVc0rlqMg4Yck46hbqsGHBdkiF8olMGpMANn8bJxrnKNfPOEcohNQry vzDO8jHGak8bc50NIV9iZ8/l25uXc+7ZX2oB8= Received: by 10.42.75.194 with SMTP id b2mr3663030ick.62.1314110803159; Tue, 23 Aug 2011 07:46:43 -0700 (PDT) Received: by 10.42.138.66 with HTTP; Tue, 23 Aug 2011 07:46:04 -0700 (PDT) In-Reply-To: Sender: git-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: git@vger.kernel.org Archived-At: On Mon, Aug 22, 2011 at 20:10, Hilco Wijbenga wrote: > On 22 August 2011 12:31, Kyle Moffett wrote: >> On Mon, Aug 22, 2011 at 14:49, Hilco Wijbenga wrote: >>> On 22 August 2011 05:46, Kyle Moffett wrote: >>>> On Mon, Aug 22, 2011 at 01:36, Hilco Wijbenga wrote: >>>>> On 21 August 2011 20:01, Kyle Moffett wrot= e: >>>> In particular, even "git stash" intentionally does not preserve fi= le times, >>>> so you would end up rebuilding everything anyways because all of y= our >>>> source files would be as new as your object files. >>> >>> Yes, I just noticed that. Why do you say "intentionally"? Is extra >>> work being done to make it so? If yes, then shouldn't that be >>> configurable? >> >> Well, there's 2 reasons: >> >> (1) The GIT data-structures simply have no place for file timestamps= , and >> "git stash" is simply a special way of dumping files into a temporar= y commit. > > That's what I thought. The "intentionally" threw me off. It's not > intentional, it's just a side effect. No, it's intentional. This discussion about timestamps is not new; the mailing list is littered with people wondering about it. The data structures are the way they are for intentional reasons, as suggested by Kyle's example. >> (2) You almost always *don't* want to preserve timestamps. =C2=A0For= example: >> >> $ git checkout -b my-feature origin/master >> $ vim some-file.c >> $ make >> $ git add some-file.c && git commit -m "A new feature" >> $ git checkout -b my-bugfix origin/master >> $ vim other-file.c >> $ make >> >> If GIT preserved timestamps, the second "make" would fail to rebuild= the >> product "some-file.o" because "some-file.c" is still older than it, = even >> though "some-file.c" has changed since the last build!!! >> >> Really, GIT is only intended for storing source code. =C2=A0If you w= ant to store >> other kinds of things (like timestamps, permissions, etc), then you = need to >> turn them into source code (IE: a text file and a "make install" tar= get) and >> then store them that way. > > Yep, that all makes sense. I just wish there was at least an option t= o > keep the timestamp (and possibly other such things). Even Subversion > can do that... ;-) After all, not everybody uses C & make. Yes, well, the crux there is `(and possibly other such things)'. That is an open-ended specification because nobody can agree on what such things should include. One of git's major design goals has been efficiency, so it's natural that git only handles what is necessary for its prime purpose of managing a history of line-oriented textual content. However, other tools have been built on top of git's infrastructure in order to store all manner of metadata (usually for the purposes of backing up files with all of their special metadata). Essentially, only *you* know what `other such things' *you* need, so it's up to you to design a way of storing such information and retrieving it yourself. After all, not everybody (indeed, nearly nobody, I'd wager) has your specific difficulties.