On Fri, 15 Apr 2005, Daniel Barkalow wrote: > > Is there some reason you don't commit before merging? All of the current > merge theory seems to want to merge two commits, using the information git > keeps about them.
Note that the 3-way merge would _only_ merge the committed state. The thing is, 99% of all merges end up touching files that I never touch myself (ie other architectures), so me being able to merge them even when _I_ am in the middle of something is a good thing. So even when I have dirty state, the "merge" would only merge the clean state. And then before the merge information is put back into my working directory, I'd do a "check-files" on the result, making sure that nothing that got changed by the merge isn't up-to-date. > How much do you care about the situation where there is no best common > ancestor I care. Even if the best common parent is 3 months ago, I care. I'd much rather get a big explicit conflict than a "clean merge" that ends up being debatable because people played games with per-file merging or something questionable like that. > I think that the time spent on I/O will be overwhelmed by the time spent > issuing the command at that rate. There is no time at all spent on IO. All my email is local, and if this all ends up working out well, I can track the other peoples object trees in local subdirectories with some daily rsyncs. And I have enough memory in my machines that there is basically no disk IO - the only tree I normally touch is the kernel trees, they all stay in cache. Linus - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html