Re: [PATCH/RFC] git add: do not add files from a submodule
On Wed, Jul 23, 2008 at 06:31:16PM +0000, Junio C Hamano wrote:
Show 19 quoted lines
> Pierre Habouzit <madcoder@debian.org> writes:
>
> > On Wed, Jul 23, 2008 at 06:40:20AM +0000, Junio C Hamano wrote:
> > ...
> >> If we started the process of diagnosing and fixing these issues earlier,
> >> and had plausible code to address the issue already in 'next' before the
> >> current -rc cycle started, the topic would have been an obvious candidate
> >> for the coming release and I'd further say it would be even worth delaying
> >> the release for a few weeks if it takes more time. But I have to say it
> >> is too late for 1.6.0 now if we are just noticing and starting the
> >> discussion.
> >
> > Well given that we now use submodules at work, and that git is
> > nowadays somewhere in the top 5 of my most consciously (as opposed to
> > the compiler that I rarely call by hand) used software suites (among my
> > editor, my MUA, my shell and my tiling WM), I'm very much interested in
> > tackling some things about what is (not) done with submodules yet.
>
> Surely the effort is appreciated.
okay I'll try to work on this on the git wiki so that collaboration is
possible.
Show 10 quoted lines
>
> >> This comment goes to the issue Pierre raised last night as well.
> >
> > You mean the git checkout issue?
>
> Oh, no; that misuse of parse_opt() that forgot KEEP_DASHDASH one was not
> what I had in mind. I meant to say that your "switch branches between an
> old pre-submodule rev and a new one that has a submodule at where a blob
> or directory used to be" issue with a good explanation material was a good
> starting point for submodule improvements for the next cycle.
> I'd like the release schedule not too heavily based on "per feature", but
> more time-based.
Yeah, we've seen in the past how it makes a release slip. Though it'd
be great to say e.g. that we won't do a 1.7.0 release[0] until we have
an UI for submodules we are prood of. It doesn't mean that we won't have
a 1.6.21 because it's slow to get into shape ;)
IOW I'm all for time based releases, with some big milestones that
when completed bump the git version significantly. And hinting on what
are those milestones would probably be quite nice. I mean git
developpement is kind of a hit and run thing: people have an issue, come
with patches, and go back to their lives (except for a mere 20 regular
contributors with more than 50 patches). Maybe we should hint some
direction we would like to see a bit more. examples of such big
directions are:
* submodules UI ;
* sparse checkouts ;
* ...
[0] I don't really *mean* we must do it for 1.7.0, It's merely an
example.Pierre Habouzit <madcoder@debian.org>