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.

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

Reply via email to