Am 05.04.2013 07:27, schrieb Duy Nguyen:
On Fri, Apr 5, 2013 at 3:53 PM, Junio C Hamano gits...@pobox.com 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.
Junio C Hamano gits...@pobox.com writes:
Jonathan Nieder jrnie...@gmail.com 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
On Thu, Apr 4, 2013 at 5:40 PM, Junio C Hamano gits...@pobox.com 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
Duy Nguyen pclo...@gmail.com 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
On Fri, Apr 5, 2013 at 3:53 PM, Junio C Hamano gits...@pobox.com 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
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
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 good, and
Jonathan Nieder jrnie...@gmail.com 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
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 (I suspect
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
Jonathan Nieder jrnie...@gmail.com 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'...
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 clones
Seth Robertson wrote:
In message
CALkWK0=csuawqwk5guf0pbc4_zeoziwqpamcrvbgz5lj0qg...@mail.gmail.com,
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
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 in exactly
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 mandatory for everyone to
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 of
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 of
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 patches
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 checked out in
the
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 the user
Am 01.04.2013 01:50, schrieb Phil Hord:
On Sun, Mar 31, 2013 at 4:34 PM, Ramkumar Ramachandra
artag...@gmail.com 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
On Mon, Apr 1, 2013 at 8:14 AM, Jens Lehmann jens.lehm...@web.de wrote:
Am 01.04.2013 01:50, schrieb Phil Hord:
On Sun, Mar 31, 2013 at 4:34 PM, Ramkumar Ramachandra
artag...@gmail.com wrote:
Jens Lehmann wrote:
Guess what: submodules are the solution for a certain set of use
cases, and
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 much
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 vehemently
On Sun, Mar 31, 2013 at 4:34 PM, Ramkumar Ramachandra
artag...@gmail.com 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
In message
CALkWK0=csuawqwk5guf0pbc4_zeoziwqpamcrvbgz5lj0qg...@mail.gmail.com, 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
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.
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-submodules
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
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
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
... edit edit
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/branch, which in turn looks like:
[submodule git]
origin =
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 whole
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
context
Ramkumar Ramachandra artag...@gmail.com 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
Junio C Hamano wrote:
Ramkumar Ramachandra artag...@gmail.com 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
Ramkumar Ramachandra artag...@gmail.com 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
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
and
Jonathan Nieder jrnie...@gmail.com 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
Am 27.03.2013 18:02, schrieb Ramkumar Ramachandra:
Junio C Hamano wrote:
Ramkumar Ramachandra artag...@gmail.com 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
Ramkumar Ramachandra artag...@gmail.com 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
41 matches
Mail list logo
