Alexey Muranov <alexey.muranov@xxxxxxxxx> 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 majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html