On Tue, 5 Feb 2008, Johannes Schindelin wrote: > Hi, > > On Mon, 4 Feb 2008, Daniel Barkalow wrote: > > > This will allow builtin-checkout to suppress merge errors if it's going > > to try more merging methods. > > I saw one error() in twoway_merge(), one in bind_merge(), and one in > onway_merge() that were not guarded by o->gently. > > Also, I'd call it "silent", not "gently". > > > Additionally, if unpack_trees() returns with an error, but without > > printing anything, it will roll back any changes to the index (by > > rereading the index, currently). This obviously could be done by the > > caller, but chances are that the caller would forget and debugging this > > is difficult. > > Granted, it is easy to forget. But maybe the caller does not need the > index? Or maybe it wants a different one? I'd prefer the caller to clean > up, if necessary. That's what makes it "gently" instead of just "silent"; it has no effect if it doesn't succeed. Longer term, I'd like to have unpack_trees() unpack into a separate index, which should actually be faster (since it doesn't have to keep shifting the entries in the index it's working on) and make this moot. In any case, it only rolls it back with the option that's only used by a caller that wants the index unchanged on failure, currently. If a caller turns out to just want a return code and not care about the index or the error message, and the code hasn't been reworked, we can add a separate flag then. I'd done some analysis at the time that suggested that, if you didn't want to give a message on failure, you must want to do something else to the index to replace what hadn't worked, so you must want the index reset, but I've forgotten why I was so sure at the time, aside from that nobody's wanted it before now. -Daniel *This .sig left intentionally blank* - 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
