Re: Re* [RFC] submodule+shallow clone feature request

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Wed, Feb 10, 2010 at 10:19:42PM -0800, Junio C Hamano wrote:
> Johannes Schindelin <Johannes.Schindelin@xxxxxx> writes:
> 
> > On Wed, 10 Feb 2010, Junio C Hamano wrote:
> >
> >> Johannes Schindelin <Johannes.Schindelin@xxxxxx> writes:
> >> 
> >> > Yes. Note, though, that the problems of enhancing git-submodule are 
> >> > not technical, as we can learn from the recent history, including the 
> >> > lack of support for rebasing submodules (there _were_ patches!).
> >> 
> >> Sorry I don't recall.  Were they of 'next' quality?  How well were they 
> >> reviewed?
> >
> > Obviously not, otherwise you would have applied them, no?
> >
> > OTOH I found the technical details rather trivial, so maybe they were 
> > 'next' quality, but there was another reason you did not apply them.
> 
> Well, I spent some time digging the mail archive myself.  I think you were
> talking about this thread:
> 
>     http://thread.gmane.org/gmane.comp.version-control.git/116918
> 
> If this is not the thread you were talking about, please discard/disregard
> the remainder of this message, and give me a better pointer instead.
> 
> The thread ends with you asking me:
> 
>     Junio, how about it? post 1.6.3 or not?  It is a well contained change, 
>     with little chance of breaking something, but offers a more sensible 
>     workflow here.
> 
> and I said:
> 
>     I am afraid it is a bit too late for "improvements" after -rc1.
>     People survived without the new feature until now, and they can wait a
>     bit longer for the next one....
> 
> Obviously, after that nothing happened.  We have some people who send
> reminders for good topics after the original thread died without producing
> a visible result.  I'd ask you to do the same (when you can---as everybody
> else, you don't work full time on git; neither do I).

[...]

> To restart the discussion so that we can have it (if it is a good change)
> after 1.7.0 ships, here is a pointer to the last revision of the patch.
> 
>     http://article.gmane.org/gmane.comp.version-control.git/117394/raw

Thanks for CCing me, I'm not on the list at the moment.
FWIW, Johannes pinged me about this patch a few weeks after that, but after
revisiting it a few times I found some issues with it. Here's the email I
sent to Johannes on April 24, my apologies that this was a private email
only and did not reach the list.

"Sorry about the delay again, I've been a bit busy lately.
I've thought about it a bit more and tbh. I don't think this patch - even if
rebased - should be merged.

The original idea was that a module can be marked for auto-rebasing in
.gitmodules. The issue with that is that AFAIK git submodule does not store
branch info. So such auto-rebasing would only work provided it would be on
the master branch. Anything else would require a fancier script than my
patch including specifying which branch should be checked out in the
original clone.

Right now, I don't have the time to design such a patch and I'm not even
sure how much it is needed.
With git submodule foreach it's relatively simple to just do the auto-rebase
setting for all modules and I would not be surprised if the majority of
use-cases require auto-rebasing on all modules anyway.

Does that make sense?
"

So in this particular case the patchset was withdrawn by me for technical
reasons (and the lack of time to sort out the details). It should have
communicated better - again, my apologies for that.

Cheers,
  Peter


--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]