From: Junio C Hamano <hidden> Date: 2016-06-15 22:56:32
Ramkumar Ramachandra [off-list ref] writes:
Junio C Hamano wrote:
quoted
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 of the superproject on the submodule after all, and
somewhere under $GIT_DIR/ of the superorject is not too wrong a
place to use as such a safe place.
Thanks for the explanation.
What do you _exactly_ mean by that? You understood why things are
arranged in that way, and no longer think that it is unnecessary,
ugly and unwieldy to stash the real copy of $GIT_DIR of submodules
away from their working trees and store them inside $GIT_DIR/modules
of the superproject?
The paths in .git/modules are unnecessary ugly and unwieldy,
especially in the case of multiple levels of nesting...
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 of the superproject on the submodule after all, and
somewhere under $GIT_DIR/ of the superorject is not too wrong a
place to use as such a safe place.
Thanks for the explanation.
What do you _exactly_ mean by that? You understood why things are
arranged in that way, and no longer think that it is unnecessary,
ugly and unwieldy to stash the real copy of $GIT_DIR of submodules
away from their working trees and store them inside $GIT_DIR/modules
of the superproject?
In essence, git commands are built to act on pure worktrees. It's
trivially Correct to pretend that an object store present in the
toplevel directory (as .git/) of the worktree doesn't exist, but it's
quite non-trivial to handle a .git directory anywhere else in the
worktree. Since we built git ground-up to act on a single
repository's worktree, embedding one repository inside another is a
hack: as a "workaround", we simply relocate the object store of the
submodule repository. 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 (no offense
Jens; it's a very hard problem).
Representing submodules as commit objects in the tree is also a hack.
I'm sorry, but a submodule is not a commit object. We need a fifth
object type if we want them to be first-class citizens.
Sorry, I'm deviating. I learnt why you think the hack is necessary
and not "too wrong". As I explained above, the entire design is
asymmetric and inelegant; I think we can do much better than this.
From: Jonathan Nieder <hidden> Date: 2016-06-15 22:56:32
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 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 git/cache.h
git commit --recurse-submodules
git push --recurse-submodules
, possibly with configuration to allow the --recurse-submodules to be
implied, and have everything work out well?
I think something like that is a goal for submodules in the long term,
with a caveat that there are complications in that different projects
(the parent project and subproject) can have different contribution
guidelines, review and release schedules, and so on.
If submodules are not working for you today, you may find some of
Jens's submodule improvement patches interesting, or you may want to
look into alternatives that make different assumptions, such as
entirely independent repositories and tools like "mr" that iterate
over them.
Hope that helps,
Jonathan
Am 27.03.2013 18:02, schrieb Ramkumar Ramachandra:
Junio C Hamano wrote:
quoted
Ramkumar Ramachandra [off-list ref] writes:
quoted
Junio C Hamano wrote:
quoted
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 of the superproject on the submodule after all, and
somewhere under $GIT_DIR/ of the superorject is not too wrong a
place to use as such a safe place.
Thanks for the explanation.
What do you _exactly_ mean by that? You understood why things are
arranged in that way, and no longer think that it is unnecessary,
ugly and unwieldy to stash the real copy of $GIT_DIR of submodules
away from their working trees and store them inside $GIT_DIR/modules
of the superproject?
In essence, git commands are built to act on pure worktrees. It's
trivially Correct to pretend that an object store present in the
toplevel directory (as .git/) of the worktree doesn't exist, but it's
quite non-trivial to handle a .git directory anywhere else in the
worktree. Since we built git ground-up to act on a single
repository's worktree, embedding one repository inside another is a
hack: as a "workaround", we simply relocate the object store of the
submodule repository.
Submodules work pretty well, no matter if you call them a "hack".
And what you call a "workaround" allows us to move, remove and
recreate submodules, which is one of *the* major inconveniences
submodules currently have.
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 (no offense
Jens; it's a very hard problem).
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. subtree - if you want to put stuff from different upstreams
into a single repo without keeping the distinction where all that
came from).
Representing submodules as commit objects in the tree is also a hack.
I'm sorry, but a submodule is not a commit object. We need a fifth
object type if we want them to be first-class citizens.
What else than a commit object should that be??? Submodules are
there to have a different upstream for a part of your work tree,
and that means a commit in that repo is the only sane thing to
record in the superproject. A lot of thought has been put into
this, and it is definitely a good choice [1].
Sorry, I'm deviating. I learnt why you think the hack is necessary
and not "too wrong". As I explained above, the entire design is
asymmetric and inelegant; I think we can do much better than this.
How? The "submodules suck, we should try a completely different
approach" thingy comes up from time to time, but so far nobody
could provide a viable alternative to what we currently do.
And apart from that, let's not forget we identified some valuable
improvements to submodules in this thread:
*) Get rid of the "toplevel" requirement
*) Add functionality to relocate the object store out of the work
tree (either "git submodule to-gitfile" or something similar,
maybe even as a separate script in contrib)
*) Add an option to "git submodule add" (and/or maybe a config
option) to relocate the object store immediately on adding an
already present submodule
All of those are topics I like to see materialize, and you are
welcome to tackle them.
[1]: http://article.gmane.org/gmane.comp.version-control.git/151857/
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. subtree - if you want to put stuff from different upstreams
into a single repo without keeping the distinction where all that
came from).
I acknowledge that it's a different repository. It's just that I
think that our current design has too many seams: why do you think
it's impossible to make it seamless?
git-subtree is not an answer to anything. Dumping all the history
into one repository has its limited usecases, but it is no solution.
What else than a commit object should that be??? Submodules are
there to have a different upstream for a part of your work tree,
and that means a commit in that repo is the only sane thing to
record in the superproject. A lot of thought has been put into
this, and it is definitely a good choice [1].
Linus argues that it shouldn't be a tree object, and I agree with
that. I don't see an argument that says that the commit object is a
perfect fit (probably because it's not).
How? The "submodules suck, we should try a completely different
approach" thingy comes up from time to time, but so far nobody
could provide a viable alternative to what we currently do.
My argument is not "submodules suck; we should throw them out of the
window, and start from scratch" at all. I'm merely questioning the
fundamental assumptions that submodules make, instead of proposing
that we work around everything in shell. We don't have to be married
to the existing implementation of submodules and try to fix all the
problems in shell.
And apart from that, let's not forget we identified some valuable
improvements to submodules in this thread:
[...]
All of those are topics I like to see materialize, and you are
welcome to tackle them.
Allow me a few days to think about changing the fundamental building
blocks to make our shell hackery easier.
Thanks.
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 git/cache.h
git commit --recurse-submodules
git push --recurse-submodules
, possibly with configuration to allow the --recurse-submodules to be
implied, and have everything work out well?
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). Some caveats:
- If we maintain one global index, and try to emulate git-subtree
using submodules, we've lost. It's going to take freakin' ages to
stat billions of files across hundreds of nested sumodules. One major
advantage of having repository boundaries is separate object stores,
indexes, worktrees: little ones that git is designed to work with.
- Auto-splitting commits that touch multiple submodules/ superproject
at once. Although git-subtree does this, I think it's horribly ugly.
- Auto-propagating commits upwards to the superproject is another big
challenge. I think the current design of anchoring to a specific
commit SHA-1 has its usecases, but is unwieldy when things become big.
We have to fix that first.
From: Jonathan Nieder <hidden> Date: 2016-06-15 22:56:33
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 you talking about? Yes, of course I realize that recursing
over subprojects that are managed as separate git repositories
requires writing new code. That's why people have started to write
such code. They seem to think it's worth it.
Meanwhile others with different designs in mind have written other
tools. Use cases even overlap a little, so they can compete. That is
exactly as it should be.
Am 28.03.2013 11:01, schrieb Ramkumar Ramachandra:
Jonathan Nieder wrote:
quoted
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 git/cache.h
git commit --recurse-submodules
git push --recurse-submodules
, possibly with configuration to allow the --recurse-submodules to be
implied, and have everything work out well?
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). Some caveats:
- If we maintain one global index, and try to emulate git-subtree
using submodules, we've lost. It's going to take freakin' ages to
stat billions of files across hundreds of nested sumodules. One major
advantage of having repository boundaries is separate object stores,
indexes, worktrees: little ones that git is designed to work with.
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).
- Auto-splitting commits that touch multiple submodules/ superproject
at once. Although git-subtree does this, I think it's horribly ugly.
You don't like it, but what technical argument is hidden here I'm
missing?
- Auto-propagating commits upwards to the superproject is another big
challenge. I think the current design of anchoring to a specific
commit SHA-1 has its usecases, but is unwieldy when things become big.
We have to fix that first.
What??? Again there is nothing to "fix" here, "anchoring to a specific
commit SHA-1" is *the* most prominent use case (think reproducibility
of the whole work tree), floating submodules are the oddball here.
Am 28.03.2013 10:16, schrieb Ramkumar Ramachandra:
Jens Lehmann wrote:
quoted
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. subtree - if you want to put stuff from different upstreams
into a single repo without keeping the distinction where all that
came from).
I acknowledge that it's a different repository. It's just that I
think that our current design has too many seams: why do you think
it's impossible to make it seamless?
git-subtree is not an answer to anything. Dumping all the history
into one repository has its limited usecases, but it is no solution.
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 bullet.
quoted
What else than a commit object should that be??? Submodules are
there to have a different upstream for a part of your work tree,
and that means a commit in that repo is the only sane thing to
record in the superproject. A lot of thought has been put into
this, and it is definitely a good choice [1].
Linus argues that it shouldn't be a tree object, and I agree with
that. I don't see an argument that says that the commit object is a
perfect fit (probably because it's not).
There was discussion about what to record in the index/commit of
the superproject in early submodule days (some time before I became
involved in Git, seems I currently cannot find a link to that). A
commit is the thing to record here because it *is* the perfect fit,
as some years of submodule experience show.
quoted
How? The "submodules suck, we should try a completely different
approach" thingy comes up from time to time, but so far nobody
could provide a viable alternative to what we currently do.
My argument is not "submodules suck; we should throw them out of the
window, and start from scratch" at all. I'm merely questioning the
fundamental assumptions that submodules make, instead of proposing
that we work around everything in shell. We don't have to be married
to the existing implementation of submodules and try to fix all the
problems in shell.
You cannot simply change the fundamental assumptions of submodules
and expect them to be the same thing afterwards. And it doesn't
matter at all if we "fix all the problems in shell" or in C-code,
we'll fix the remaining problems that are fixable in whatever part
of Git it makes sense. And I don't have the impression you have an
idea about what submodules are good at, where they can be improved
and what problems they'll probably never solve.
quoted
And apart from that, let's not forget we identified some valuable
improvements to submodules in this thread:
[...]
All of those are topics I like to see materialize, and you are
welcome to tackle them.
Allow me a few days to think about changing the fundamental building
blocks to make our shell hackery easier.
Please go ahead, but if your goal is "to make our shell hackery
easier" I'm not interested. I want to improve the user experience
of submodules and don't care much in what language we achieve that.
And I can't see anything fundamental being wrong with submodules but
strongly believe they are a perfect match for some very important
use cases (some of which I see happening at my $dayjob for some
years now), so I still don't see what you are trying to "fix" here.
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 in what language we achieve that.
You missed the point entirely. If git didn't have a commit object,
would you use a special kind of blob and code around everything to
avoid fixing a more fundamental issue?
What happens when you rename "magit" to "foo" in that branch and want
to check out an older commit of the same branch? That is one of the
reasons why that belongs in to a checked in .gitmodules and not
someplace untracked.
Good point. I learnt something new.
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?
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 bullet.
That's the core of your argument: submodules already solve what it
was meant to, and we can't get it to solve a larger class of problems.
In other words, you're implying that it's impossible to build a tool
that will be able to compose git repositories in a way that solves a
very large class of problems. I don't see conclusive proof for this,
so I have to disagree.
To summarize, everyone seems to be elated with the current state of
submodules and is vehemently defending it. I'm a little unhappy, but
am unable to express my discontent in better prose. Let's just go
back to writing patches, and come back to this if and when I have a
full design.
From: Jonathan Nieder <hidden> Date: 2016-06-15 22:56:35
Ramkumar Ramachandra wrote:
Jens Lehmann wrote:
quoted
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 defending it. I'm a little unhappy, but
am unable to express my discontent in better prose. Let's just go
back to writing patches, and come back to this if and when I have a
full design.
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 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.
Hope that helps,
Jonathan
From: Phil Hord <hidden> Date: 2016-06-15 22:56:35
On Sun, Mar 31, 2013 at 4:34 PM, Ramkumar Ramachandra
[off-list ref] wrote:
Thanks for taking the time and effort to review my thoughts.
Jens Lehmann wrote:
quoted
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.
quoted
I want to improve the user experience
of submodules and don't care much in what language we achieve that.
You missed the point entirely. If git didn't have a commit object,
would you use a special kind of blob and code around everything to
avoid fixing a more fundamental issue?
quoted
What happens when you rename "magit" to "foo" in that branch and want
to check out an older commit of the same branch? That is one of the
reasons why that belongs in to a checked in .gitmodules and not
someplace untracked.
Good point. I learnt something new.
quoted
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?
quoted
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 bullet.
That's the core of your argument: submodules already solve what it
was meant to, and we can't get it to solve a larger class of problems.
In other words, you're implying that it's impossible to build a tool
that will be able to compose git repositories in a way that solves a
very large class of problems. I don't see conclusive proof for this,
so I have to disagree.
I think it is possible to solve larger classes of problems with
submodules, but it is a harder problem than you seem to think. In any
case I do not think you need to re-engineer submodules to improve
them.
Sumodules are good for preserving history. When properly managed,
they answer the question git always answers, "Where was my code in the
past?" I would like proper management to be easier, but I understand
why it is difficult; and I see it getting easier.
Some users also want submodules to handle other tasks, like "Import
branch-tracked upstream changes (i.e. git pull origin master)." This
too is useful, but it is a different problem than submodules'
primarily try to solve. But they do already solve _part_ of that
problem ("Show me how these modules are related"), so it seems a
trivial thing to ask them also to handle the "floating branch" task.
The trick is to handle this task in a way that does not break the task
they are designed and used for already.
Some other users want submodules to solve the problem of composition,
like "Show me the combined log of all these submodules." (Replace
"show log" with "diff", "merge", "bisect" or even "rebase" if you
like.) I think this is where Jens is leaning when working to improve
the user experience. But this direction does not require
re-architecting the fundamentals of submodules.
To summarize, everyone seems to be elated with the current state of
submodules and is vehemently defending it.
That's a gross overstatement. Everyone understands that is
complicated and dangerous tweak a machine in operation. Such tweaks
should be safe, prudent and justifiable, in roughly that order.
Phil
Am 31.03.2013 22:34, schrieb Ramkumar Ramachandra:
quoted
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 work tree changes inside the submodules too. It
was really easy to forget to commit accompanying submodule changes
when preparing a superproject commit before that (and that broke
quite some builds at my $dayjob until we fixed that).
quoted
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 bullet.
That's the core of your argument: submodules already solve what it
was meant to, and we can't get it to solve a larger class of problems.
In other words, you're implying that it's impossible to build a tool
that will be able to compose git repositories in a way that solves a
very large class of problems. I don't see conclusive proof for this,
so I have to disagree.
To summarize, everyone seems to be elated with the current state of
submodules and is vehemently defending it. I'm a little unhappy, but
am unable to express my discontent in better prose.
I just think it is too early for the "let's do things differently
and redesign stuff" phase. Before doing that we have to clear up
the things that currently don't work for you or are confusing you
about submodules and see if they are already solved (which could
lead to a documentation update) or what it would take to fix them
using current submodule infrastructure. I have the strong feeling
that after we did that, no design changes are necessary anymore.
On Sun, Mar 31, 2013 at 4:34 PM, Ramkumar Ramachandra
[off-list ref] wrote:
quoted
Jens Lehmann wrote:
quoted
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 bullet.
That's the core of your argument: submodules already solve what it
was meant to, and we can't get it to solve a larger class of problems.
In other words, you're implying that it's impossible to build a tool
that will be able to compose git repositories in a way that solves a
very large class of problems. I don't see conclusive proof for this,
so I have to disagree.
I think it is possible to solve larger classes of problems with
submodules, but it is a harder problem than you seem to think. In any
case I do not think you need to re-engineer submodules to improve
them.
Sumodules are good for preserving history. When properly managed,
they answer the question git always answers, "Where was my code in the
past?" I would like proper management to be easier, but I understand
why it is difficult; and I see it getting easier.
Exactly.
Some users also want submodules to handle other tasks, like "Import
branch-tracked upstream changes (i.e. git pull origin master)." This
too is useful, but it is a different problem than submodules'
primarily try to solve. But they do already solve _part_ of that
problem ("Show me how these modules are related"), so it seems a
trivial thing to ask them also to handle the "floating branch" task.
The trick is to handle this task in a way that does not break the task
they are designed and used for already.
But I think we recently learned to support that use case with
submodules. I think there are two floating models:
- Tracked:
Follow a branch in the submodule and let git help you to advance
the submodule to the tip of that branch at certain times, but
still record a certain SHA-1 in the superproject to maintain
reproducibility. We support this since 1.8.2 (see 06b1abb5 by
Trevor).
- 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 this
is because they are used to SVN externals, which I believe work
that way). You throw away reproducibility, which I think is not
good and not the way I expect Git to work. But that use case is
achieved with a simple script and some config settings telling
Git to don't even look for changes in the submodule anymore, and
submodule infrastructure will set up everything for you after
cloning the superproject. You run your custom script from time
to time and have a truly floating submodule.
So to me it looks we support both floating models with current Git's
submodule infrastructure.
Some other users want submodules to solve the problem of composition,
like "Show me the combined log of all these submodules." (Replace
"show log" with "diff", "merge", "bisect" or even "rebase" if you
like.) I think this is where Jens is leaning when working to improve
the user experience. But this direction does not require
re-architecting the fundamentals of submodules.
Correct. The only major change needed for that was to move the .git
directories into the .git directory of the superproject to prepare
for recursive update. But that is done under the hood and didn't
touch the fundamentals of using gitlinks and .gitmodules, it is just
a change in the layout of the local clone.
From: Phil Hord <hidden> Date: 2016-06-15 22:56:35
On Mon, Apr 1, 2013 at 8:14 AM, Jens Lehmann [off-list ref] wrote:
Am 01.04.2013 01:50, schrieb Phil Hord:
quoted
On Sun, Mar 31, 2013 at 4:34 PM, Ramkumar Ramachandra
[off-list ref] wrote:
quoted
Jens Lehmann wrote:
quoted
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 bullet.
That's the core of your argument: submodules already solve what it
was meant to, and we can't get it to solve a larger class of problems.
In other words, you're implying that it's impossible to build a tool
that will be able to compose git repositories in a way that solves a
very large class of problems. I don't see conclusive proof for this,
so I have to disagree.
I think it is possible to solve larger classes of problems with
submodules, but it is a harder problem than you seem to think. In any
case I do not think you need to re-engineer submodules to improve
them.
Sumodules are good for preserving history. When properly managed,
they answer the question git always answers, "Where was my code in the
past?" I would like proper management to be easier, but I understand
why it is difficult; and I see it getting easier.
Exactly.
quoted
Some users also want submodules to handle other tasks, like "Import
branch-tracked upstream changes (i.e. git pull origin master)." This
too is useful, but it is a different problem than submodules'
primarily try to solve. But they do already solve _part_ of that
problem ("Show me how these modules are related"), so it seems a
trivial thing to ask them also to handle the "floating branch" task.
The trick is to handle this task in a way that does not break the task
they are designed and used for already.
But I think we recently learned to support that use case with
submodules. I think there are two floating models:
- Tracked:
Follow a branch in the submodule and let git help you to advance
the submodule to the tip of that branch at certain times, but
still record a certain SHA-1 in the superproject to maintain
reproducibility. We support this since 1.8.2 (see 06b1abb5 by
Trevor).
Thanks. I followed that thread closely, but I thought the patch had
stalled again. I'm glad to see it in master
- 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 this
is because they are used to SVN externals, which I believe work
that way). You throw away reproducibility, which I think is not
good and not the way I expect Git to work. But that use case is
achieved with a simple script and some config settings telling
Git to don't even look for changes in the submodule anymore, and
submodule infrastructure will set up everything for you after
cloning the superproject. You run your custom script from time
to time and have a truly floating submodule.
So to me it looks we support both floating models with current Git's
submodule infrastructure.
Well, for that matter, the "tracked" floating tip was also a simple
script once a upon a time. To say we support both is nothing new.
You could say we supported both in 1.8.1, and now we support "Tracked"
a little bit better in 1.8.2.
I think the difference is that everyone's expectation for "Untracked"
is a little bit different; or maybe it is just dangerous enough that
it should not be a core feature.
But I ain't complainin'.
Phil
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 presenting fragments
of my thoughts, hoping that it turn into concrete actionable work
after exchanging a few emails. I'm also annoyed that it didn't
happen.
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 taking a local dump to
search using real tools is just too painful; does someone already have
a local dump?
From: Jeff King <hidden> Date: 2016-06-15 22:56:36
On Tue, Apr 02, 2013 at 11:14:49PM +0530, Ramkumar Ramachandra wrote:
quoted
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 taking a local dump to
search using real tools is just too painful; does someone already have
a local dump?
Yes, I have a maildir with the complete list archive, which I index
using mairix (or sometimes grep if I'm doing something particularly
tricky). I find the search on gmane to be abysmal.
I'm happy to make my dump available to anyone who wants it, but it's
kind of big (about 1.4G uncompressed).
-Peff
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 this
is because they are used to SVN externals, which I believe work
that way). You throw away reproducibility, which I think is not
good and not the way I expect Git to work.
[...]
Nope, it has nothing to do with SVN externals; I've never used them.
And no, all repositories aren't created equal. I should be able to
add in magit.git into my dotfiles repository without worrying about
which commits the other repositories were at a particular commit. If
my project depends on the bleeding edge of poppler and girarra, I
should always be able to tell what commits in each subproject the
build was passing in. In other words, I should be able to freely
mixed floating and fixed submodules. There's no reason for one to be
Right, and the other to be a shunned second-class citizen.
From: Jonathan Nieder <hidden> Date: 2016-06-15 22:56:36
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 reconstitute your dotfiles on a new machine. From then
on, when acting on the dotfiles repository (with "git status", "git
commit", etc) git should not pay attention to the magit subdirectory
at all, because there is no coupling between the two.
Did I get that right?
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 git
uses the same scripts Junio does:
$ git clone git://repo.or.cz/git.git
Cloning into 'git'...
remote: Counting objects: 151283, done.
remote: Compressing objects: 100% (38546/38546), done.
remote: Total 151283 (delta 111004), reused 151073 (delta 110797)
Receiving objects: 100% (151283/151283), 36.39 MiB | 7.66 MiB/s, done.
Resolving deltas: 100% (111004/111004), done.
Don't forget to "git clone -b todo git://repo.or.cz/git.git git/Meta"
for maintenance scripts.
$
That would allow you to include an arbitrary setup script (including
cloning dependencies as well as running "autoreconf" or whatever) and
give people cloning a quick reminder to inspect it if paranoid and
then run it.
Jonathan
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 git
uses the same scripts Junio does:
$ git clone git://repo.or.cz/git.git
Cloning into 'git'...
remote: Counting objects: 151283, done.
remote: Compressing objects: 100% (38546/38546), done.
remote: Total 151283 (delta 111004), reused 151073 (delta 110797)
Receiving objects: 100% (151283/151283), 36.39 MiB | 7.66 MiB/s, done.
Resolving deltas: 100% (111004/111004), done.
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
the same way either. In other words: I'm not sitting in an office and
working with my colleagues on exactly the same things, in exactly the
same way; wasn't that the Subversion age? Some might decide to
initialize a few submodules, change the URLs of some, and remove some.
I'd want my private fork to have commits changing "initialize
submodule quux" to "don't initialize submodule quux", and be able to
rebase that on top of upstream. Why are you leaning towards solutions
for very narrow usecases?
From: Jonathan Nieder <hidden> Date: 2016-06-15 22:56:37
Ramkumar Ramachandra wrote:
Jonathan Nieder wrote:
quoted
$ git clone git://repo.or.cz/git.git
[...]
quoted
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
the same way either. In other words: I'm not sitting in an office and
working with my colleagues on exactly the same things, in exactly the
same way; wasn't that the Subversion age? Some might decide to
initialize a few submodules, change the URLs of some, and remove some.
Can't a script pointed to in README handle all these things?
I'd want my private fork to have commits changing "initialize
submodule quux" to "don't initialize submodule quux", and be able to
rebase that on top of upstream.
These would be patches to comment or uncomment repositories in the
list used by your "setup" script.
Why are you leaning towards solutions
for very narrow usecases?
I don't think this hostile way of explaining things is warranted. :/
Yours,
Jonathan
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
the same way either. In other words: I'm not sitting in an office and
working with my colleagues on exactly the same things, in exactly the
same way; wasn't that the Subversion age? Some might decide to
initialize a few submodules, change the URLs of some, and remove some.
Can't a script pointed to in README handle all these things?
If it came to that, it's quite possible to write one giant Perl script
to do whatever I want (see: git-slave).
What will I be merging and rebasing? One configuration file stuffed
with miscellaneous repositories. Don't you think this is highly
unpleasant? Why would I want to write slightly different scripts for
each of my repositories? I'd want to write down several different
adjustable knobs to use something that's well-integrated into core
git, like we do in .git/config (except we can't share a .gitconfig
yet).
I don't think this hostile way of explaining things is warranted. :/
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 an
alternative)?
Yes, you're right: a simple script with a configuration file can
manage only floating submodules quite well.
Am 02.04.2013 19:44, schrieb Ramkumar Ramachandra:
Jonathan Nieder wrote:
quoted
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 presenting fragments
of my thoughts, hoping that it turn into concrete actionable work
after exchanging a few emails. I'm also annoyed that it didn't
happen.
But didn't we already note three worthwhile patches (get rid of the
top-level requirement and relocate a .git directory at "add" time
and anytime later)?
Am 02.04.2013 20:35, schrieb Ramkumar Ramachandra:
Jens Lehmann wrote:
quoted
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 this
is because they are used to SVN externals, which I believe work
that way). You throw away reproducibility, which I think is not
good and not the way I expect Git to work.
[...]
Nope, it has nothing to do with SVN externals; I've never used them.
And no, all repositories aren't created equal. I should be able to
add in magit.git into my dotfiles repository without worrying about
which commits the other repositories were at a particular commit. If
my project depends on the bleeding edge of poppler and girarra, I
should always be able to tell what commits in each subproject the
build was passing in. In other words, I should be able to freely
mixed floating and fixed submodules. There's no reason for one to be
Right, and the other to be a shunned second-class citizen.
But you can currently mix floating and fixed submodules, as each
submodule can be configured differently. Or am I missing something
here?