Ramkumar Ramachandra [off-list ref] writes:
Junio C Hamano wrote:
quoted
Ramkumar Ramachandra [off-list ref] writes:
quoted
Does git diff/ commit/ add/ rm or any other command you can think of
rely on a special file in the worktree (aka .gitmodules) to be checked
out?
Try "git add foo~" with usual suspect in .gitignore ;-)
First, it's not a hard requirement: in the worst case, git add will
add the file even without a -f.
In the same sense .gitmodules is not a hard requirement, either. I
use a submodule without .gitmodules in one of my repositories (the
top-level houses the source to generete my dotfiles and is cloned to
my environment at work, but the submodule houses my private files
that live only at home). The gitlink entry in the index and the
tree and presence of the .git repository in the submodule checkout
(where it exists) is sufficient to make the layout work.
If your complaints were "I cannot make X work with the current
system, even with changes to git-submodule and some core part of the
system, and I think the reason is because the way module information
is stored is in a separate file .gitmodules", with a concrete X,
people who are more versed with the submodule subsystem may be able
to help you come up with a cleaner solution without throwing the
baby with the bathwater, but I do not think we saw any concrete X
mentioned.
The same sentence followed by "... and with an object of a new type
stored at the path of the submodule, I can make it work by doing A,
B and C", with concrete A, B and C, some people may be interested in
pursuing that avenue with you, but I do not think we saw such
combinations of <X, A, B, C> either.
If all of your argument starts from "I think .gitmodules is ugly
because it is not an object of a separate type stored at the path of
the submodule, and here are the reasons why I think it is ugly", I
have nothing more to say to you. That "ugly" is at best skewed
aesthetics, and each and every example that comes up in this
discussion, like this "'git add' works with .gitignore", and the one
I sent on ".gitattributes vs .gitmodules on the default" in the
nearby subthread to Jonathan, makes me realize that .gitmodules is
_more_ in line with the rest of the system, not less.
This is going nowhere. You're stuck at making the current submodule
system work, not answering my questions, diverting conversation,
repeatedly asking the same stupid questions, labelling everything that
I say "subjective", and refusing to look at the objective counterpart
(aka, the code). It's clear to me that no matter how many more emails
I write, you're not going to concede.
I'm not interested in wasting any more of my time with this nonsense.
I give up.
Junio C Hamano wrote:
If all of your argument starts from "I think .gitmodules is ugly
because it is not an object of a separate type stored at the path of
the submodule, and here are the reasons why I think it is ugly", I
have nothing more to say to you.
_This_ is how you summarize the seven points and the follow-up emails
I wrote out for you? Seriously?
I enjoy good debate, and would've loved to be beaten in argument. But
that's not what happened here. I was just too frustrated with your
stupidity to continue.
From: "Ramkumar Ramachandra" <redacted>
Sent: Monday, April 08, 2013 10:03 PM
This is going nowhere. You're stuck at making the current submodule
system work, not answering my questions, diverting conversation,
repeatedly asking the same stupid questions, labelling everything that
I say "subjective", and refusing to look at the objective counterpart
(aka, the code). It's clear to me that no matter how many more emails
I write, you're not going to concede.
I'm not interested in wasting any more of my time with this nonsense.
I give up.
--
Please don't "give up". It is a bit of a 'wicked' problem [1].
Yes to taking a rest, stepping back and trying to summarise/review what
was discussed.
I couldn't keep up with all the discussion, and I doubt many others kept
up, especially those who have been frustrated in their (mis-) use of
submodules. Do remember that Junio has multiple roles which belie the
softness of the word 'maintainer'. It includes "Defender of the
Heritage" in the same way that keepers of ancient monuments will want
visitors to enjoy the site, but rail against a garish new stainless
steel and glass entrance to the Colosseum (choose you local heritage
site) (see [1] again).
I get confused (about sub-modules) with msysgit where git.git is a
sub-module, and is the fastest moving (an inversion of control issue),
and when hacking at (just) the msys level when the git sub-module isn't
in sync.
In many ways sub-module tracking is like file renames and empty
directories (both of which come up a lot). The submodule meta
information issue has great similarity to the empty directories issue.
It's about meta information, not about content (which is certified
verified by sha1), and about how users know what is going on and get a
(natural) feeling of control (without upsetting other users/controllers)
.
regards
Philip
[now to schedule some time to do the catch up reading. $dayjob beckons]
[1] www.poppendieck.com/wicked.htm