Hi, On Fri, 1 Feb 2008, Kate Rhodes wrote: > I'm leaning towards agreement with Shawn that you're a little confused > as to how syncing works or you're not adequately expressing what you're > really hoping for and why git isn't doing it and we're misunderstanding > you. Well, the thing is: git (plumbing) does not really care about syncing and how that works. The core of git is "just" a very clever object database, geared towards revision control. So in theory, Ed could just go and write a porcelain for git, which does _exactly_ what he wants, yet would be mostly interoperable with other git porcelains. I imagine that the "cvsish update" would boil down to fetching upstream, updating the index with what the user has in the working directory (something like "git add -u"), then write out a tree from that, and call merge-recursive on that tree and the upstream's current tree. Force fast forward master, but keep the index, keeping the error output of merge-recursive. Done. However, you need to understand the internals of git enough to do that. Especially the conflict management, and its relation with the index. And I cannot see how that understanding would not lead to abandoning that work-flow as suboptimal. But hey, that's just my private opinion. Ciao, Dscho - 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
