All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jakub Narebski <jnareb@gmail.com>
To: Ilari Liusvaara <ilari.liusvaara@elisanet.fi>
Cc: Nguyen Thai Ngoc Duy <pclouds@gmail.com>,
	Jonathan Nieder <jrnieder@gmail.com>,
	"Dmitry S. Kravtsov" <idkravitz@gmail.com>,
	git@vger.kernel.org, Shawn Pearce <spearce@spearce.org>
Subject: Re: Tracking empty directories
Date: Tue, 1 Feb 2011 19:31:38 +0100	[thread overview]
Message-ID: <201102011931.40559.jnareb@gmail.com> (raw)
In-Reply-To: <20110201181509.GA2370@LK-Perkele-VI.localdomain>

Dnia wtorek 1. lutego 2011 19:15, Ilari Liusvaara napisał:
> On Wed, Feb 02, 2011 at 12:54:35AM +0700, Nguyen Thai Ngoc Duy wrote:
> > On Wed, Feb 2, 2011 at 12:28 AM, Jonathan Nieder <jrnieder@gmail.com> wrote:
> > 
> > Could it be done with an index extension? Interesting.
> > 
> > > Certainly one ought to register an extension name or bump the version
> > > number to avoid confusing gits that don't know about the feature.
> > 
> > Index extension with lowercase name are "necessary for correct
> > operation". Older git will abort on unknown required extensions. If
> > you add to the main part of the index, better bump version number.
> 
> Worse problem than the index: Tree entries. Those are actually transferable
> and IIRC older (current?) git versions don't handle empty subdirectories
> (pointing entry of type directory to empty tree hash) all too well...

What did you mean by "don't handle" here?  The following entry

  040000 tree 22d5826c087c4b9dcc72e2131c2cfb061403f7eb	empty

should be not a problem; empty tree is hardcoded and also shouldn't there
be a problem with such object.  Is the problem when checking out such tree
(writing to index and/or working area)?

> Worse yet, there isn't easy way to break the tree parser to avoid current
> git versions from screwing things up (IIRC, when I tested, invalid octal
> numbers finally broke it, invalid file types didn't do the trick)...

Well, then 1.8.0 version could be good place to break backwards 
compatibility; we did similar thing when introducing submodule entries,
isn't it?

-- 
Jakub Narebski
Poland

  reply	other threads:[~2011-02-01 18:31 UTC|newest]

Thread overview: 36+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-01-29 10:01 Features from GitSurvey 2010 Dmitry S. Kravtsov
2011-01-29 23:13 ` Jonathan Nieder
2011-02-01 13:51   ` Jakub Narebski
2011-02-01 15:52     ` Nguyen Thai Ngoc Duy
2011-02-01 16:33       ` Shawn Pearce
2011-02-01 16:27     ` Shawn Pearce
2011-02-01 17:05       ` Nguyen Thai Ngoc Duy
2011-02-01 21:27         ` Junio C Hamano
2011-02-01 21:44         ` Nicolas Pitre
2011-02-01 17:11       ` Nguyen Thai Ngoc Duy
2011-02-01 17:34         ` Shawn Pearce
2011-02-01 21:51           ` Nicolas Pitre
2011-02-02  0:26             ` Shawn Pearce
2011-02-02  2:11               ` Nicolas Pitre
2011-02-02  2:23                 ` david
2011-02-03 14:38             ` Geert Bosch
2011-02-03 17:39               ` Narrow clone (Re: features from GitSurvey 2010) Jonathan Nieder
2011-02-03 21:23                 ` Geert Bosch
2011-02-03 21:33                   ` Jonathan Nieder
2011-02-03 21:38                   ` Jonathan Nieder
2011-02-03 21:33               ` Features from GitSurvey 2010 Nicolas Pitre
2011-02-01 17:28     ` Tracking empty directories Jonathan Nieder
2011-02-01 17:54       ` Nguyen Thai Ngoc Duy
2011-02-01 18:15         ` Ilari Liusvaara
2011-02-01 18:31           ` Jakub Narebski [this message]
2011-02-01 19:09             ` Ilari Liusvaara
2011-02-01 18:35         ` Jonathan Nieder
2011-02-01 19:03           ` Jakub Narebski
2011-02-02  3:54             ` Nguyen Thai Ngoc Duy
2011-02-02 12:31               ` Kevin P. Fleming
2011-02-01 21:36     ` Features from GitSurvey 2010 Nicolas Pitre
2011-02-01 22:50     ` big files in git was: " david
2011-02-03  6:25       ` Nicolas Pitre
2011-02-01 17:44   ` Matthieu Moy
2011-02-01 18:42     ` Jonathan Nieder
2011-02-01 20:23       ` Matthieu Moy

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=201102011931.40559.jnareb@gmail.com \
    --to=jnareb@gmail.com \
    --cc=git@vger.kernel.org \
    --cc=idkravitz@gmail.com \
    --cc=ilari.liusvaara@elisanet.fi \
    --cc=jrnieder@gmail.com \
    --cc=pclouds@gmail.com \
    --cc=spearce@spearce.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.