Am 18.04.2013 01:17, schrieb Philip Oakley:
Would it be possible to summarise the key points and proposals of where the
subject is now?
Here you go, time to post our third iteration of the comparison
list, containing two updates:
- easier coding was removed from the advantages
- git
Philip Oakley wrote:
Would it be possible to summarise the key points and proposals of where the
subject is now?
Sure.
If you want an update from the current approach, wait for a v2; I'm
cooking it for some time, and getting some resulting ideas merged into
upstream early (look for
On Mon, Apr 8, 2013 at 7:23 AM, Jonathan Nieder jrnie...@gmail.com wrote:
Ramkumar Ramachandra wrote:
It's about the core object code of git parsing links, as
opposed to a fringe submodule.c/ submodule.sh parsing .gitmodules.
What's stopping the core object code of git parsing
Duy Nguyen wrote:
Somewhat related to the topic. Why can't .gitattributes be used for
storing what's currently in .gitmodules?
It can. It's just a small syntax change from key = value attributes
inside a toplevel [submodule name] section separated by newlines, to
a path marked with multiple
On Wed, Apr 17, 2013 at 9:06 PM, Ramkumar Ramachandra
artag...@gmail.com wrote:
Duy Nguyen wrote:
Somewhat related to the topic. Why can't .gitattributes be used for
storing what's currently in .gitmodules?
It can. It's just a small syntax change from key = value attributes
inside a
Duy Nguyen wrote:
Include me to those everyone. url feels like a local thing that should
not stay in object database (another way of looking at it is like an
email address: the primary one fixed in stone in commits with .mailmap
for future substitution).
We've been over this several times in
On Wed, Apr 17, 2013 at 9:56 PM, Ramkumar Ramachandra
artag...@gmail.com wrote:
why not reuse tag object with some nea header lines?
Or a unified blob, which is currently what we have. The point is to
have structured parseable information that the object-parsing code of
git code and easily
Duy Nguyen wrote:
On Wed, Apr 17, 2013 at 9:56 PM, Ramkumar Ramachandra
artag...@gmail.com wrote:
why not reuse tag object with some nea header lines?
Or a unified blob, which is currently what we have. The point is to
have structured parseable information that the object-parsing code of
Duy Nguyen pclo...@gmail.com writes:
Somewhat related to the topic. Why can't .gitattributes be used for
storing what's currently in .gitmodules?
You _could_ use gitattributes to encode, but it goes against what a
gitattributes file does or is for. It is a mechanism to associate
groups of
From: Ramkumar Ramachandra artag...@gmail.com
Sent: Wednesday, April 17, 2013 12:56 PM
We've been over this several times in earlier emails. [...]
Again, I'm not saying that my approach is Correct and Final. What I'm
saying is: Here's what I've done. Something interesting is going on.
From: Ramkumar Ramachandra artag...@gmail.com
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
Junio C Hamano wrote:
Ramkumar Ramachandra wrote:
2. If we want to make git-submodule a part of git-core (which I think
everyone agrees with), we will need to make the information in
.gitmodules available more easily to the rest of git-core.
Care to define more easily which is another
Am 07.04.2013 23:30, schrieb Ramkumar Ramachandra:
Jonathan Nieder wrote:
What's stopping the core object code of git parsing .gitmodules?
Just to clarify that: git core already does that. A git grep
gitmodules_config shows it is parsed by some git core commands:
checkout, commit, the diff
Jens Lehmann wrote:
Hmm, at least the unstaged .gitmodules file has to be parsed from
the file system.
You seem to be touting it as a distinct advantage. In my opinion,
.gitmodules is a wart that needs to be done away with: it should _not_
be on the filesystem, just like a commit object isn't
Hi Ram,
Ramkumar Ramachandra wrote:
In my opinion,
.gitmodules is a wart that needs to be done away with: it should _not_
be on the filesystem, just like a commit object isn't on the
filesystem.
What do you think of .gitignore and
Ramkumar Ramachandra wrote:
Jens Lehmann wrote:
Hmm, at least the unstaged .gitmodules file has to be parsed from
the file system.
You seem to be touting it as a distinct advantage.
To clarify what I said in a side thread: yes, as long as the submodule
metadata includes the hostname I am
Jonathan Nieder wrote:
What do you think of .gitignore and .gitattributes? Should they be
somewhere other than the filesystem as well?
I would argue that .gitignore and .gitattributes are done right. They
are integrated into a very mature part of git-core very well, and
their nature is
Jonathan Nieder wrote:
git grep -l -F -e oldhost.example.com |
xargs sed -i -e s/oldhost.example.com/newhost.example.com/g
Yes, I've had to do this too: in a proxied environment I had to
s/git:\/\//https:\/\//. So yes, we will have features to operate on
multiple links at the
On Fri, Apr 5, 2013 at 5:55 AM, Jonathan Nieder jrnie...@gmail.com wrote:
Ramkumar Ramachandra wrote:
1. 'git add' should not go past submodule boundaries. I should not be
able to 'git add clayoven/' or 'git add clayoven/LICENSE'. In
addition, the shell completion also needs to be
On Mon, Apr 8, 2013 at 7:08 PM, Ramkumar Ramachandra artag...@gmail.com wrote:
Jonathan Nieder wrote:
What do you think of .gitignore and .gitattributes? Should they be
somewhere other than the filesystem as well?
I would argue that .gitignore and .gitattributes are done right. They
are
Duy Nguyen wrote:
Probably off-topic, but I'm starting to find .gitignore can be found
in every directory a burden to day-to-day git operations. So imo it's
not done right entirely ;-)
Why is it a burden? I would argue that the tooling support is not yet
there, but git check-ignore is a step
Duy Nguyen wrote:
Probably off-topic, but I'm starting to find .gitignore can be found
in every directory a burden to day-to-day git operations. So imo it's
not done right entirely ;-)
Or are you saying it's hard to implement elegantly and efficiently in
git-core? If so, I agree
On Mon, Apr 8, 2013 at 9:06 PM, Ramkumar Ramachandra artag...@gmail.com wrote:
Duy Nguyen wrote:
Probably off-topic, but I'm starting to find .gitignore can be found
in every directory a burden to day-to-day git operations. So imo it's
not done right entirely ;-)
Why is it a burden? I would
Duy Nguyen wrote:
Good luck. Bug such a big work usually requires more than one
volunteer. If you haven't convinced (*) the community it's right,
maybe you should take a few days thinking about it again before
implementing.
Yes, I'm thinking about it before rushing in to implement it.
There
Jonathan Nieder jrnie...@gmail.com writes:
[snipped everything I agree with...]
On the other hand, the single .gitmodules file will be a pain to merge
if multiple branches modify it. So I do look forward to a merge
strategy that deals more intelligently with its content, and wouldn't
have
Ramkumar Ramachandra artag...@gmail.com writes:
As far as I can tell, I'm completely unbiased: I have no vested
interests in either implementation,...
...
Frankly, I was hoping that atleast one or two people on the thread
would take my side of the argument (or atleast tell me that I'm not
Junio C Hamano wrote:
Would it be possible that (at least some part of, or possibly all
of) your ideas had some merit, but with all your hostility against
the current system and the work that went behind it, you did not
communicate well enough to make others understand you?
Agreed. My
Christian Couder wrote:
What if instead of a git submodule I want to have an hg, or, God/Linus/deity
forbid, an SVN submodule, inside my git worktree?
What if I just want a very big movie or .tgz downloaded from somewhere else?
Since the link object is rooted to the tree, it's impossible to
Junio C Hamano gits...@pobox.com writes:
Jonathan Nieder jrnie...@gmail.com writes:
[snipped everything I agree with...]
On the other hand, the single .gitmodules file will be a pain to merge
if multiple branches modify it. So I do look forward to a merge
strategy that deals more
Ramkumar Ramachandra artag...@gmail.com writes:
1. Having a toplevel .gitmodules means that any git-core command like
add/ rm/ mv will be burdened with looking for the .gitmodules at the
toplevel of the worktree and editing it appropriately along with
whatever it was built to do (ie. writing
Junio C Hamano wrote:
Ramkumar Ramachandra artag...@gmail.com writes:
1. Having a toplevel .gitmodules means that any git-core command like
add/ rm/ mv will be burdened with looking for the .gitmodules at the
toplevel of the worktree and editing it appropriately along with
whatever it was
Junio C Hamano wrote:
Ramkumar Ramachandra artag...@gmail.com writes:
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
Ramkumar Ramachandra artag...@gmail.com writes:
Junio C Hamano wrote:
Ramkumar Ramachandra artag...@gmail.com writes:
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
Ok, here comes an updated version of our comparison list which
I updated with what I read in recent discussions. As I said
earlier, please speak up if I missed anything (or forgot to add
anyone to the CC).
I picked up one advantage (no need to cd-to-toplevel to edit
.gitmodules) two new
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
On Mon, Apr 08, 2013 at 10:41:57PM +0200, Jens Lehmann wrote:
(While it is easier to merge the link object, a .gitmodules
aware merge driver would work just as well)
I have not been following this thread that closely, so apologies if I
missed it, but one thing I have not seen mention of is how
Junio C Hamano wrote:
I think it is too premature to discuss _your_ code. The patches do
not even tell us anything about how much more work is needed to
merely make Git with your patches work properly again. For one
thing, I suspect that you won't even be able to repack a repository
that
Ramkumar Ramachandra artag...@gmail.com writes:
Junio C Hamano wrote:
I think it is too premature to discuss _your_ code. The patches do
not even tell us anything about how much more work is needed to
merely make Git with your patches work properly again. For one
thing, I suspect that you
Your overall hostility is unappreciated. The burden of proof is on
me, while you calmly sit back and criticize anything that breaks the
current working state, and refuse to look at the implementation.
Anyway, here we go again.
Junio C Hamano wrote:
Not at all. And please do not start _coding_.
I suspect you're overtly worried about the fallout of such a
disruptive change. If so, you could've just said: Ram, I like the
idea. But what breakages do you estimate we'll have to deal with?
instead of attacking the idea and repeatedly questioning its purpose.
So, I'll make a rough guess based
John Keeping wrote:
Meaning that every repository using submodules need to have a flag day
when all of the people using it switch to the new Git version at once?
No, I would be totally against a migration that involves a flag-day.
What I meant is that having old-style submodule side-by-side
John Keeping wrote:
So not a flag day, but still some point at which the repository
transitions to will not work with Git older than version X. And if
you need to add a new submodule then you cannot delay that transition
any longer.
Yes, that is true. I don't see any way out of this.
I
On Sun, Apr 07, 2013 at 10:52:50PM +0530, Ramkumar Ramachandra wrote:
Sure, I'll write it out for you from an end-user perspective:
To play Devil's Advocate for a bit...
0. Great UI/UX. No more cd-to-toplevel, and a beautiful set of native
commands that are consistent with the overall design
John Keeping wrote:
With the clarifications Ram's provided in this thread, I think there are
also some important regressions in functionality in his proposal (at
least as it currently stands), particularly losing the .gitconfig
overrides.
If we want the entire feature list in the very first
This reminds me of the commit generation numbers thread.
But how can we determine ancestry?
Use the commit timestamp.
But what if there are clock skews?
Put in a slop.
It breaks existing stuff, and it's hard to show any end-user benefit.
I fear this proposal will meet with the same fate.
--
To
Am 07.04.2013 20:44, schrieb Ramkumar Ramachandra:
Jens Lehmann wrote:
The whole feature list is full of red herrings like this which
have nothing to do with the advantages of a new object, but talk
about UI issues which are easy to solve in both worlds.
Really? git-submodule.sh was
Jens Lehmann wrote:
Just to be sure: I think we agree that both approaches are capable
of allowing all relevant use cases, because they store the same
information?
Yes.
Disclaimer: I am not opposed to the link object per se, but after
all we are talking about severely changing user visible
Jens Lehmann wrote:
* Easier coding, as we find all information in a single object.
It's not just the difference between a single location versus multiple
locations. It's about the core object code of git parsing links, as
opposed to a fringe submodule.c/ submodule.sh parsing .gitmodules.
When
On Mon, Apr 08, 2013 at 02:19:10AM +0530, Ramkumar Ramachandra wrote:
Jens Lehmann wrote:
* A link object has no unstaged counterpart that a file easily
has. What would that mean for adding a submodule and then
unstaging it (or how could we add a submodule unstaged, like
you
Ramkumar Ramachandra wrote:
It's about the core object code of git parsing links, as
opposed to a fringe submodule.c/ submodule.sh parsing .gitmodules.
What's stopping the core object code of git parsing .gitmodules? What
is the core object code? How does this compare to other
Hi again,
So we've thought about it for some time, and I really need you to
start reviewing the code now.
I'll just summarize what we've discussed so far:
1. The malleability argument doesn't hold, because we're proposing a
link object with optional fields.
2. The local-fork argument doesn't
Ramkumar Ramachandra artag...@gmail.com writes:
So we've thought about it for some time, and I really need you to
start reviewing the code now.
I'll just summarize what we've discussed so far:
...
I do not think we have heard anything concrete and usable about what
you are trying to achieve
Ramkumar Ramachandra wrote:
After some discussion, I hope to be able to finalize a list of fields
that will suffice for (nearly) everything.
The task is actually much easier than this. All we have to do is
finalize the list of fields that will mandatorily be written to the
link object. As I
On Thu, Apr 4, 2013 at 1:04 PM, Ramkumar Ramachandra artag...@gmail.com wrote:
Linus Torvalds wrote:
Or you could also just edit and carry a dirty .gitmodules around for
your personal use-case.
I'm sorry, but a dirty worktree is unnecessarily painful to work with.
Bzzt. Wrong.
A dirty
Linus Torvalds wrote:
So you absolutely need a dirty worktree. You need it for testing, and
you need it for merging. Having a model where you don't have a
in-progress entity that works as a temporary is absolutely and
entirely wrong.
I agree entirely. My comment was just a by the way, and
Ramkumar Ramachandra artag...@gmail.com writes:
Junio C Hamano wrote:
git log -p .gitmodules would be a way to review what changed in
the information about submodules. Don't you need git log-link for
exactly the same reason why you need git diff-link in the first
place?
So you may not
Junio C Hamano wrote:
Once you start recording the latter also at path A, it becomes
unclear what git diff A should show.
That is what I said in the message, to which you invented diff-link
as a solution to the unclear-ness.
I just thought it would be a stopgap until we get diff to support
On Thu, Apr 4, 2013 at 11:30 AM, Ramkumar Ramachandra
artag...@gmail.com wrote:
The purpose of this series is to convince you that we've made a lot of
fundamental mistakes while designing submodules, and that we should
fix them now. [1/7] argues for a new object type, and this is the
core of
Ramkumar Ramachandra wrote:
The purpose of this series is to convince you that we've made a lot of
fundamental mistakes while designing submodules, and that we should
fix them now. [1/7] argues for a new object type, and this is the
core of the idea.
Oh, dear.
Shouldn't it be possible to
Linus Torvalds wrote:
I don't dispute that a new link object might be a good idea, but
there's no explanation of the actual format of this thing anywhere,
and what the real advantages would be. A clearer this is the design,
this is the format of the link object, and this is what it buys us
Ramkumar Ramachandra wrote:
1. 'git add' should not go past submodule boundaries. I should not be
able to 'git add clayoven/' or 'git add clayoven/LICENSE'. In
addition, the shell completion also needs to be fixed.
Yep. This is a bug.
2. An empty directory containing a .git file is
Jonathan Nieder wrote:
Ramkumar Ramachandra wrote:
The purpose of this series is to convince you that we've made a lot of
fundamental mistakes while designing submodules, and
[...]
Shouldn't it be possible to explain the same thing using a test
script illustrating intended UI?
Sorry, I sent
On Thu, Apr 4, 2013 at 11:52 AM, Ramkumar Ramachandra
artag...@gmail.com wrote:
1. upstream_url: this records the upstream URL. No need to keep a
.gitmodules.
2. checkout_rev: this records the ref to check out the submodule to.
As opposed to a concrete SHA-1, this allows for more
Linus Torvalds wrote:
So the thing is (and this was pretty much the original basis for
.gitmodules) that pretty much *all* of the above fields are quite
possibly site-specific, rather than globally stable.
So I actually conceptually like (and liked) the notion of a link
object, but I just
Linus Torvalds wrote:
don't seem fundamentally antithetical to the
current model
I don't think it's fundamentally antithetical either. This basically
makes the life of git-submodule much simpler, and eventually obsolete
it away completely.
--
To unsubscribe from this list: send the line
On Thu, Apr 4, 2013 at 12:36 PM, Ramkumar Ramachandra
artag...@gmail.com wrote:
Let's compare the two alternatives: .gitmodules versus link object.
If I want my fork of .gitmodules, I create a commit on top.
Or you could also just edit and carry a dirty .gitmodules around for
your personal
Linus Torvalds wrote:
On Thu, Apr 4, 2013 at 12:36 PM, Ramkumar Ramachandra
artag...@gmail.com wrote:
Let's compare the two alternatives: .gitmodules versus link object.
If I want my fork of .gitmodules, I create a commit on top.
Or you could also just edit and carry a dirty .gitmodules
Junio C Hamano wrote:
I think Heiko and Jens's (by the way, why aren't they on the Cc:
list when this topic is clearly discussing submodules? Don't we
want to learn how the current submodule subsystem is used to solve
what real-world problems?) .gitmodules updates is exactly going in
that
Linus Torvalds wrote:
Or you could also just edit and carry a dirty .gitmodules around for
your personal use-case.
I'm sorry, but a dirty worktree is unnecessarily painful to work with.
I don't think anyone objects to committing, if they can understand
basic rebase.
--
To unsubscribe from this
Ramkumar Ramachandra wrote:
Just take the link's buffer with you everywhere. All you have to do
is git edit-link name and paste the file's contents there, instead
of opening .gitmodules directly in your editor.
On this. The buffer doesn't have to conform to a tight spec: we can
just expose a
Am 04.04.2013 21:17, schrieb Junio C Hamano:
Linus Torvalds torva...@linux-foundation.org writes:
... The features you seem to be after (ie that whole
floating/refname thing) don't seem fundamentally antithetical to the
current model (a commit SHA1 of all zeroes for floating, with a new
Am 04.04.2013 21:04, schrieb Linus Torvalds:
My gut feel is that yes, .gitmodules was always a bit of a hack, but
it's a *working* hack, and it does have advantages exactly because
it's more fluid than an actual git object (which by definition has to
be set 100% in stone).
Exactly. The
Jens Lehmann wrote:
Exactly. The flexibility of the .gitmodules file will really help us
when it comes to the next feature that submodules are going to learn
after recursive update:
That's like saying that the flexibility of a blob is invaluable: let's
throw out all the other objects, and make
Jens Lehmann jens.lehm...@web.de writes:
While starting to grok submodules I was wondering myself if the data
stored in .gitmodules would better be stored in an extended gitlink
object, but I learned soon that the scope of the data that has to be
stored there was not clear at that time (and
Junio C Hamano wrote:
When you are changing information _about_ submodules (e.g. you may
be updating the recommended URL to fetch it from), you can use the
usual tools like git diff to see how it changed, just like changes
to any other file. If the information _about_ a submodule A is
stored
Ramkumar Ramachandra artag...@gmail.com writes:
Junio C Hamano wrote:
When you are changing information _about_ submodules (e.g. you may
be updating the recommended URL to fetch it from), you can use the
usual tools like git diff to see how it changed, just like changes
to any other file.
Junio C Hamano wrote:
Sounds like you are saying that you can pile a new command on top of
new command to solve what the existing tools people are familar with
can already solve in a consistent way without adding anything new.
Are you going to dupliate various options to git diff and git
log
Ramkumar Ramachandra artag...@gmail.com writes:
Junio C Hamano wrote:
Sounds like you are saying that you can pile a new command on top of
new command to solve what the existing tools people are familar with
can already solve in a consistent way without adding anything new.
Are you going to
Junio C Hamano wrote:
git log -p .gitmodules would be a way to review what changed in
the information about submodules. Don't you need git log-link for
exactly the same reason why you need git diff-link in the first
place?
So you may not have suggested it, but I suspect that was only
79 matches
Mail list logo
