Alexey Muranov <alexey.mura...@gmail.com> writes:
> On 18 Aug 2012, at 22:39, Junio C Hamano wrote:
>> Do we _know_ already what the "ultimate destination" looks like?
>> If the answer is yes, then I agree, but otherwise, I doubt it is a
>> good idea to introduce unnecessary complexity to the system that may
>> have to be ripped out and redone.
>> I didn't get the impression that we know the "ultimate destination"
>> from the previous discussion, especially if we discount the tangent
>> around "having next and next/foo at the same time" which was on
>> nobody's wish, but I may be misremembering things.
> Excuse me if i miss something again, but i might be willing to
> discuss the "ultimate destination". Could you possibly state in
> simple terms what the problem with determining the "ultimate
> destination" is?
Decide if it makes sense to break backward compatibility of loose
ref representation merely to support having a branch "next" and
another branch "next/foo" in the same repository, and if it does,
what the new loose ref representation looks like.
> I hope my opinion might be useful because i do not know anything
> about the actual implementation of Git,...
That sounds like contradiction.
> To just give a quick idea of my ideas, i thought that 'fetching'
> in Git was an inevitable evil that stands apart from other
> operations and is necessary only because the computer
> communication on Earth is not sufficiently developed to keep all
> Git repositories constantly in sync,...
It is a feature, not a symptom of an insufficiently developed
technology, that I do not have to know what random tweaks and
experiments are done in repositories of 47 thousands people who
clone from me, and I can sync with any one of them only when I know
there is something worth looking at when I say "git fetch".
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html