All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Shawn O. Pearce" <spearce@spearce.org>
To: Johannes Schindelin <Johannes.Schindelin@gmx.de>
Cc: Junio C Hamano <gitster@pobox.com>, git@vger.kernel.org
Subject: Re: What's cooking in git.git (Nov 2008, #06; Wed, 26)
Date: Fri, 28 Nov 2008 11:20:33 -0800	[thread overview]
Message-ID: <20081128192033.GF23984@spearce.org> (raw)
In-Reply-To: <alpine.DEB.1.00.0811281225040.30769@pacific.mpi-cbg.de>

Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
> On Thu, 27 Nov 2008, Junio C Hamano wrote:
> > Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> > 
> > > I have a strong suspicion that the narrow stuff will make the worktree 
> > > mess pale in comparison.
> > >
> > > Note that I do not have time to review this myself (which is not 
> > > helped at all by it being no longer a trivial single patch, but a full 
> > > 10 patches!), but I really have a bad feeling about this.  IMO it is 
> > > substantially under-reviewed.
> > 
> > Well, "a bad feeling" is not a convincing enough argument either, is it? 
> > What kind of bad interaction are you fearing?
...
> And the worst part: I think that as with worktree, there has not been 
> enough of kicking forth and back ideas how to design the beast, so I fully 
> expect a subtle breakage that would require a redesign (which will be 
> painful, with existing users of the feature).
> 
> Maybe I am crying "wolf", but I _do_ want to caution against risking too 
> much, too fast, with that feature.
> 
> In other words, unless there is more interest in that feature, enough to 
> generate a well-understood design before a good implementation, I'd rather 
> see this patch series dropped.

Ack.  I agree with every remark made by Dscho, and also want to cry "wolf".

I haven't had time to read the patch series.  Its big and intrusive
and I just don't need the feature.

But I feel like if it were in fact merged I'll fall over some bug
in it sometime soon and be forced to stop and debug it.  Heck at
the least I'll have to go back to JGit's index code and implement
the new file format.  That shouldn't cause git.git's development to
stop, but I am whining (a little) about the file format change.  ;-)

-- 
Shawn.

  reply	other threads:[~2008-11-28 19:21 UTC|newest]

Thread overview: 37+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-11-27  0:28 What's cooking in git.git (Nov 2008, #06; Wed, 26) Junio C Hamano
2008-11-27 22:49 ` Johannes Schindelin
2008-11-28  2:06   ` Junio C Hamano
2008-11-28 11:47     ` Johannes Schindelin
2008-11-28 19:20       ` Shawn O. Pearce [this message]
2008-11-29  0:13         ` Junio C Hamano
2008-11-29  0:15           ` [PATCH] git add --intent-to-add: fix removal of cached emptiness Junio C Hamano
2008-11-29  3:51             ` [PATCH 1/3] builtin-rm.c: explain and clarify the "local change" logic Junio C Hamano
2008-11-29  3:55               ` [PATCH 2/3] git add --intent-to-add: fix removal of cached emptiness Junio C Hamano
2008-11-29 15:38                 ` Sverre Rabbelier
2008-11-30 19:21                   ` Jeff King
2008-11-29  3:56               ` [PATCH 3/3] git add --intent-to-add: do not let an empty blob committed by accident Junio C Hamano
2008-11-30 19:14                 ` Jeff King
2008-12-01  9:24                   ` Junio C Hamano
2008-11-29  1:25           ` What's cooking in git.git (Nov 2008, #06; Wed, 26) Daniel Barkalow
2008-11-29 13:02             ` Nguyen Thai Ngoc Duy
2008-11-30 10:29               ` Nguyen Thai Ngoc Duy
2008-11-30 21:26                 ` Daniel Barkalow
2008-12-06 17:26                   ` Nguyen Thai Ngoc Duy
2008-12-06 18:39                     ` Daniel Barkalow
2008-12-07 12:27                       ` Nguyen Thai Ngoc Duy
2008-12-07 21:26                         ` Daniel Barkalow
2008-12-08 12:51                           ` Nguyen Thai Ngoc Duy
2008-12-08 19:41                             ` Daniel Barkalow
2008-12-11 13:04                               ` Nguyen Thai Ngoc Duy
2008-12-11 20:30                                 ` Daniel Barkalow
2008-12-12  1:41                                   ` Junio C Hamano
2008-12-12  2:40                                     ` Daniel Barkalow
2008-12-12  3:12                                       ` Junio C Hamano
2008-12-12  3:36                                         ` Jeff King
2008-12-12 16:13                                     ` Nguyen Thai Ngoc Duy
2008-12-12 16:45                                       ` Johannes Sixt
2008-12-12 16:54                                         ` Nguyen Thai Ngoc Duy
2008-12-13  5:51                                           ` Junio C Hamano
2008-12-13  5:51                                       ` Junio C Hamano
2008-12-12 16:08                                   ` Nguyen Thai Ngoc Duy
2008-12-07  3:45                   ` 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=20081128192033.GF23984@spearce.org \
    --to=spearce@spearce.org \
    --cc=Johannes.Schindelin@gmx.de \
    --cc=git@vger.kernel.org \
    --cc=gitster@pobox.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 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.