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
