Am 05.04.2013 07:27, schrieb Duy Nguyen:
> On Fri, Apr 5, 2013 at 3:53 PM, Junio C Hamano wrote:
>>> A brief summary or outcome from these links in the comment would
>>> be nice.
>>
>> A summary of what to consider in Documentation/technical/ somewhere
>> may be a very welcome addition. Thanks fo
On Fri, Apr 5, 2013 at 3:53 PM, Junio C Hamano wrote:
>> A brief summary or outcome from these links in the comment would
>> be nice.
>
> A summary of what to consider in Documentation/technical/ somewhere
> may be a very welcome addition. Thanks for volunteering ;-).
No thanks :-) I did not rea
Duy Nguyen writes:
> Should someone add these links to the source code (maybe as a comment
> in submodule.c, or above the definition of S_IFGITLINK in cache.h)?
They were given in response to a request for reading material to
learn background. Most of the straw-man outlines raised in these old
d
On Thu, Apr 4, 2013 at 5:40 PM, Junio C Hamano wrote:
>> Not on the current design but the discussion before that round that
>> influenced the outcome greatly was this:
>>
>> http://thread.gmane.org/gmane.comp.version-control.git/14486/focus=14492
>>
>> where we discussed a separate "gitlink" ty
Junio C Hamano writes:
> Jonathan Nieder writes:
>
>> If you are curious, at a quieter time it might be useful to ask for
>> pointers to the discussions that led to the current design, and folks
>> on the list might be glad to help.
>
> Not on the current design but the discussion before that ro
Am 02.04.2013 20:35, schrieb Ramkumar Ramachandra:
> Jens Lehmann wrote:
>> But I think we recently learned to support that use case with
>> submodules. I think there are two floating models:
>>
>> - Tracked:
>> [...]
>>
>> - Untracked:
>> Some people just want "the newest" tip of a branch checke
Am 02.04.2013 19:44, schrieb Ramkumar Ramachandra:
> Jonathan Nieder wrote:
>> Elated is probably not the right word. More "annoyed at being told
>> their work is ugly without an accompanying concrete and actionable bug
>> report". :)
>
> If I had an actionable report, I'd have started hammering
Ramkumar Ramachandra wrote:
> What will I be merging and rebasing? One configuration file stuffed
> with miscellaneous repositories. Don't you think this is highly
> unpleasant?
I spoke too fast. Isn't that exactly what we do with .gitmodules
today (I'm not saying it's ideal, but I can't think
Jeff King wrote:
> I'm happy to make my dump available to anyone who wants it, but it's
> kind of big (about 1.4G uncompressed).
Thanks. Can you put it up publicly somewhere (Dropbox comes to mind),
and send me a link?
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body
Jonathan Nieder wrote:
> Ramkumar Ramachandra wrote:
>> Jonathan Nieder wrote:
>
>>> $ git clone git://repo.or.cz/git.git
> [...]
>>> Don't forget to "git clone -b todo git://repo.or.cz/git.git
>>> git/Meta"
>>> for maintenance scripts.
>>> $
>>
>> Nope, it's not ma
Ramkumar Ramachandra wrote:
> Jonathan Nieder wrote:
>> $ git clone git://repo.or.cz/git.git
[...]
>> Don't forget to "git clone -b todo git://repo.or.cz/git.git git/Meta"
>> for maintenance scripts.
>> $
>
> Nope, it's not mandatory for everyone to use dotfiles.git
Seth Robertson wrote:
>
> In message
> ,
> Ramkumar Ramachandra writes:
>
> As a user inexperienced with recursive submodules (I've only used them
> in this repository), I found it highly confusing. Thanks for clearing
> them up.
>
> You may want to investigate third party alternativ
Jonathan Nieder wrote:
> That sounds similar to what Junio does with the Meta subdirectory in
> his git development worktree. I don't think submodules are a good
> fit, but it might make sense to start respecting a .motd file to allow
> the following in a hypothetical world where everyone who clon
Jonathan Nieder writes:
> ..., but it might make sense to start respecting a .motd file to allow
> the following in a hypothetical world where everyone who clones git
> uses the same scripts Junio does:
>
> $ git clone git://repo.or.cz/git.git
> Cloning into 'git'...
> remote: C
Ramkumar Ramachandra wrote:
> I should be able to
> add in magit.git into my dotfiles repository
For this, ideally what we'd want is a file that lists repositories
that should be cloned at the same time as cloning the dotfiles
repository, to reconst
Jens Lehmann wrote:
> But I think we recently learned to support that use case with
> submodules. I think there are two floating models:
>
> - Tracked:
> [...]
>
> - Untracked:
> Some people just want "the newest" tip of a branch checked out in
> the submodule and update that from time to time
Jonathan Nieder writes:
> If you are curious, at a quieter time it might be useful to ask for
> pointers to the discussions that led to the current design, and folks
> on the list might be glad to help.
Not on the current design but the discussion before that round that
influenced the outcome gr
On Tue, Apr 02, 2013 at 11:14:49PM +0530, Ramkumar Ramachandra wrote:
> > If you are curious, at a quieter time it might be useful to ask for
> > pointers to the discussions that led to the current design, and folks
> > on the list might be glad to help.
>
> Will do. The search on GMane is no go
Jonathan Nieder wrote:
> Elated is probably not the right word. More "annoyed at being told
> their work is ugly without an accompanying concrete and actionable bug
> report". :)
If I had an actionable report, I'd have started hammering patches
instead of wasting everyone's time here. I'm was pr
On Mon, Apr 1, 2013 at 8:14 AM, Jens Lehmann wrote:
> Am 01.04.2013 01:50, schrieb Phil Hord:
>> On Sun, Mar 31, 2013 at 4:34 PM, Ramkumar Ramachandra
>> wrote:
>>> Jens Lehmann wrote:
Guess what: submodules are the solution for a certain set of use
cases, and tools like subtree are a s
Am 01.04.2013 01:50, schrieb Phil Hord:
> On Sun, Mar 31, 2013 at 4:34 PM, Ramkumar Ramachandra
> wrote:
>> Jens Lehmann wrote:
>>> Guess what: submodules are the solution for a certain set of use
>>> cases, and tools like subtree are a solution for another set of
>>> use cases. There is no silver
Am 31.03.2013 22:34, schrieb Ramkumar Ramachandra:
>> Are you aware that current Git code already stats all files across
>> all submodules recursive by default? So (again) no problem here, we
>> do that already (unless configured otherwise).
>
> I didn't know that. Why does it do this?
To show t
In message
, Ramkumar
Ramachandra writes:
As a user inexperienced with recursive submodules (I've only used them
in this repository), I found it highly confusing. Thanks for clearing
them up.
You may want to investigate third party alternatives like gitslave
http://gitslave.sf.net
On Sun, Mar 31, 2013 at 4:34 PM, Ramkumar Ramachandra
wrote:
> Thanks for taking the time and effort to review my thoughts.
>
> Jens Lehmann wrote:
>> A
>> commit is the thing to record here because it *is* the perfect fit
>
> Might be, but saying that doesn't help one bit. I want to know why.
>
Ramkumar Ramachandra wrote:
> Jens Lehmann wrote:
>> A
>> commit is the thing to record here because it *is* the perfect fit
>
> Might be, but saying that doesn't help one bit. I want to know why.
[...]
> To summarize, everyone seems to be elated with the current state of
> submodules and is vehe
Thanks for taking the time and effort to review my thoughts.
Jens Lehmann wrote:
> A
> commit is the thing to record here because it *is* the perfect fit
Might be, but saying that doesn't help one bit. I want to know why.
> I want to improve the user experience
> of submodules and don't care mu
Am 28.03.2013 10:16, schrieb Ramkumar Ramachandra:
> Jens Lehmann wrote:
>> Unless you acknowledge that submodules are a different repo, you'll
>> always run into problems. I believe future enhancements will make
>> this less tedious, but in the end they will stay separate repos
>> (which is the wh
Am 28.03.2013 12:48, schrieb Ramkumar Ramachandra:
> Okay, here's a first draft of the new design. The new mediator object
> should look like:
>
> name = git
> ref = v1.7.8
>
> The name is looked up in refs/modules/, which in turn looks like:
>
> [submodule "git"]
> origin =
Am 28.03.2013 11:01, schrieb Ramkumar Ramachandra:
> Jonathan Nieder wrote:
>> Do you mean that you wish you could ignore subrepository boundaries
>> and use commands like
>>
>> git clone --recurse-submodules http://git.zx2c4.com/cgit
>> cd cgit
>> vi git/cache.h
>>
Ramkumar Ramachandra wrote:
> Do you realize how difficult this is to implement? We'll need to
> patch all the git commands to essentially do what we'd get for free if
> the submodule were a tree object instead of a commit object (although
> I'm not saying that's the Right thing to do).
What are
Junio C Hamano wrote:
> As I said in another thread, your top-level may be only a part in
> somebody else's project, and what you consider just a part of your
> project may be the whole project to somebody else. If you pick one
> location to store both for the above clone, e.g. cgit/.git (it could
Jonathan Nieder wrote:
> Do you mean that you wish you could ignore subrepository boundaries
> and use commands like
>
> git clone --recurse-submodules http://git.zx2c4.com/cgit
> cd cgit
> vi git/cache.h
> ... edit edit edit ...
> git add --recurse-submodule
Jens Lehmann wrote:
> Unless you acknowledge that submodules are a different repo, you'll
> always run into problems. I believe future enhancements will make
> this less tedious, but in the end they will stay separate repos
> (which is the whole point, you'd want to use a different approach
> - e.g
Am 27.03.2013 18:02, schrieb Ramkumar Ramachandra:
> Junio C Hamano wrote:
>> Ramkumar Ramachandra writes:
>>> Junio C Hamano wrote:
So you have to stash it somewhere. We could have made it to move
them to $HOME/.safeplace or somewhere totally unrelated to the
superproject. So in
Junio C Hamano wrote:
> I however do not see the implementation detail of having (or not
> having) separate $GIT_DIR for component projects having anything to
> do with the goal of that ideal.
Yeah, I think the current gitlink-instead-of-full-git-dir-for-submodules
implementation that can allow "
Jonathan Nieder writes:
> Ramkumar Ramachandra wrote:
>
>>Even then, working with one worktree embedded
>> inside another is something git never designed for: it explains why I
>> have to literally fight with git when using submodules
>
> Do you mean that you wish you coul
Ramkumar Ramachandra wrote:
>Even then, working with one worktree embedded
> inside another is something git never designed for: it explains why I
> have to literally fight with git when using submodules
Do you mean that you wish you could ignore subrepository boundaries
a
Ramkumar Ramachandra writes:
> Sorry, I'm deviating. I learnt why you think the hack is necessary
> and not "too wrong".
OK.
> As I explained above, the entire design is
> asymmetric and inelegant; I think we can do much better than this.
I personally find the "explained above" part making no
Junio C Hamano wrote:
> Ramkumar Ramachandra writes:
>> Junio C Hamano wrote:
>>> So you have to stash it somewhere. We could have made it to move
>>> them to $HOME/.safeplace or somewhere totally unrelated to the
>>> superproject. So in that sense, the repositories are *not* owned by
>>> the su
Ramkumar Ramachandra writes:
> Junio C Hamano wrote:
>> So you have to stash it somewhere. We could have made it to move
>> them to $HOME/.safeplace or somewhere totally unrelated to the
>> superproject. So in that sense, the repositories are *not* owned by
>> the superproject in any way. Howe
Junio C Hamano wrote:
> So you have to stash it somewhere. We could have made it to move
> them to $HOME/.safeplace or somewhere totally unrelated to the
> superproject. So in that sense, the repositories are *not* owned by
> the superproject in any way. However, you are working within the
> con
Ramkumar Ramachandra writes:
> Apart from the implementation glitches, I don't like the design;
> submodules don't compose well:
>
> 1. There's an inherent asymmetry between the superproject and each of
> the subprojects, because the superproject owns all the object stores.
> Why is it absolutely
(Changed subject)
(+CC: Peff; I suspect he'll be interested in the repository
composition discussion)
Jens Lehmann wrote:
> Am 25.03.2013 20:57, schrieb Ramkumar Ramachandra:
>> Okay, I'll do it step-by-step now, with a live example:
>> [...]
>> What is going on, seriously?
>
> Pilot error, mostl
43 matches
Mail list logo
