On Tue, 5 Feb 2008, Junio C Hamano wrote: > Daniel Barkalow <barkalow@xxxxxxxxxxxx> writes: > > > On Tue, 5 Feb 2008, Johannes Schindelin wrote: > > ... > >> > 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. > > Absolutely. That is the original motivation I did the_index > thing for. > > But "re-reading" may not be quite nice. It would defeat the > optimization introduced by the change to use CE_UPTODATE flag to > avoid unnecessary lstat(2) calls. For now, I want to re-read the index, because I need the changes undone and I don't have any way of reverting them. That's another reason to have unpack_trees return with the index unchanged: it may have a better way of getting there than the caller does, such as having never changed that memory in the first place. I'll add doing it efficiently to my list of things to do, but I want to keep it from being necessary for correctness of this series. -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
