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 subm
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 clone.subm
From: "Ramkumar Ramachandra"
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.
It's probably worth
Duy Nguyen 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 paths (that may not
Duy Nguyen wrote:
> On Wed, Apr 17, 2013 at 9:56 PM, Ramkumar Ramachandra
> 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 cod
On Wed, Apr 17, 2013 at 9:56 PM, Ramkumar Ramachandra
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 slurp and give
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
On Wed, Apr 17, 2013 at 9:06 PM, Ramkumar Ramachandra
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 toplevel [submod
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 ] section separated by newlines, to
a path marked with multiple "ke
On Mon, Apr 8, 2013 at 7:23 AM, Jonathan Nieder 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 .gitmodules?
From: "Ramkumar Ramachandra"
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
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 i
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 se
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 ho
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 c
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 disadvant
Ramkumar Ramachandra writes:
> Junio C Hamano wrote:
>> Ramkumar Ramachandra 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 .git
Junio C Hamano wrote:
> Ramkumar Ramachandra 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 hard requi
Ramkumar Ramachandra 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 ;-)
--
To unsubscribe from this list: send the line "unsubscribe
Junio C Hamano wrote:
> Ramkumar Ramachandra 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
Ramkumar Ramachandra 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 to the index an
Junio C Hamano writes:
> Jonathan Nieder 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, an
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 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 ann
Ramkumar Ramachandra 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
> deranged), but
Jonathan Nieder 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 minded a design
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.
The
On Mon, Apr 8, 2013 at 9:06 PM, Ramkumar Ramachandra 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 argue t
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 wholehear
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 s
On Mon, Apr 8, 2013 at 7:08 PM, Ramkumar Ramachandra 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 integrated in
On Fri, Apr 5, 2013 at 5:55 AM, Jonathan Nieder 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 fixed.
>
> Yep
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
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 funda
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
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 .gita
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
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
Jonathan Nieder wrote:
> What's stopping the core object code of git parsing .gitmodules?
Nothing, except that it's perversely unnatural for object parsing code
to parse something outside the object store.
> What
> is the core object code?
parse_link_buffer(): the conventions have already been s
Christian Couder wrote:
> About generation numbers, please have a look at the thread leading to this
> message:
>
> http://thread.gmane.org/gmane.comp.version-control.git/177146/focus=177586
>
> In short, generation numbers were not such a good idea because there were
> already existing ways to get
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 m
John Keeping wrote:
> I do. I quite often use "git add -p" to sort things out and submodules
> currently fit into that seamlessly: I can add the submodule and then
> wait until later to commit it, without needing to either clone and
> remember to "submodule add" later or commit and play with rebas
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
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
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 visi
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 wa
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.
Ramkumar Ramachandra wrote:
>> The only proposed change that seems to me to be impossible with the
>> current .gitmodules approach is the "submodule in a non-initialized
>> submodule" feature, but I've never seen anyone ask for that and it seems
>> likely to open a whole can of worms where the beha
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 firs
On Sun, Apr 07, 2013 at 08:34:27PM +0200, 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.
With the clarifications Ram's provided in this
Jens Lehmann wrote:
> Ram is plain wrong here (just like he is on "git rm" and "git mv",
> even though the latter is currently still in pu). This use case is
> handled by submodules for years now. Take a look at the "ignore"
> setting in .gitmodules which give you full control of the stat()s
> in s
John Keeping wrote:
> I can't see how this gets me a dirty working tree. Since the link needs
> to be stored somewhere, I assume it's in the index; so I can have staged
> changes, but not unstaged changes.
If you have changes in the index, your worktree is classified as
"dirty". See git-sh-setup
Am 07.04.2013 20:21, schrieb John Keeping:
> On Sun, Apr 07, 2013 at 11:37:02PM +0530, Ramkumar Ramachandra wrote:
>> John Keeping wrote:
>>> On Sun, Apr 07, 2013 at 10:52:50PM +0530, Ramkumar Ramachandra wrote:
3. Ability to have very many large submodule repositories without the
perform
Ramkumar Ramachandra wrote:
> You can't control the most fundamental thing, stat(): this is the
> primary killer of performance on a large worktree. There is currently
> no way to block stat(): new-style submodules offers a way to configure
> which submodules to block the stat() on.
Let me try to
On Sun, Apr 07, 2013 at 11:37:02PM +0530, Ramkumar Ramachandra wrote:
> John Keeping wrote:
> > 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...
>
> Yes!
>
> >> 0.
John Keeping wrote:
> 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...
Yes!
>> 0. Great UI/UX. No more cd-to-toplevel, and a beautiful set of native
>> commands that ar
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 desi
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.
On Sun, Apr 07, 2013 at 10:12:28PM +0530, Ramkumar Ramachandra wrote:
> 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 invo
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 wi
On Sun, Apr 07, 2013 at 09:21:44PM +0530, Ramkumar Ramachandra wrote:
> 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
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 base
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_.
Ramkumar Ramachandra 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 won't even
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
> tha
Ramkumar Ramachandra 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 yet.
You may
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 hol
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
Ramkumar Ramachandra 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 hav
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", a
On Thu, Apr 4, 2013 at 1:04 PM, Ramkumar Ramachandra 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 worktree is not o
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
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
Ramkumar Ramachandra 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 dupliate v
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
Ramkumar Ramachandra 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. If the in
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
>
Jens Lehmann 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 still isn't). So
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 ma
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 fle
Am 04.04.2013 21:17, schrieb Junio C Hamano:
> Linus Torvalds 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
>> refname field in .sub
Ramkumar Ramachandra wrote:
> Just take the link's buffer with you everywhere. All you have to do
> is git edit-link 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 .
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 thi
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
> tha
Linus Torvalds wrote:
> On Thu, Apr 4, 2013 at 12:36 PM, Ramkumar Ramachandra
> 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
>
On Thu, Apr 4, 2013 at 12:36 PM, Ramkumar Ramachandra
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 use-case.
I don't
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
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 j
Linus Torvalds 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
> refname field in .submodules? I dunno)..
Just on this part.
I think Heik
On Thu, Apr 4, 2013 at 11:52 AM, Ramkumar Ramachandra
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 flexibility; you
> can
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,
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
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:
> 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 t
On Thu, Apr 4, 2013 at 11:30 AM, 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.
I
Hi,
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.
It's an entire beautiful design + UI/UX package. To demo it now:
96 matches
Mail list logo
