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? I hope my opinion
might be useful because i do not know anything about the actual implementation
of Git, but for a while i thought i was understanding it's intended
mathematical model, until i ran into unexpected for me default behavior of not
pruning when fetching.
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, and because one might prefer to
work with a somewhat dated snapshot of a remote than with the constantly
changing current version. I thought "snapshot" could be a good alternative name
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