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 
for "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

Reply via email to