Martin Koegler <mkoegler@xxxxxxxxxxxxxxxxx> wrote: > On Sun, Feb 24, 2008 at 07:08:39PM -0800, Junio C Hamano wrote: > > > > I'd rather see a series does not depend on things in next that > > you do not have to depend on, pretty please? > > I usually develop my patch on next. I can offer you two things: > * base my patches on something different (master?) > * add fsck.h/o some lines above > > What do you prefer? Don't build patch series against "next" unless they will trivially apply *and function correctly* also on "master". E.g. a trivially obvious one liner may be OK to develop on "next", but everything else should be done against "master", or if you must the tip of the topic in "next" that you desire to build upon. E.g. when I was working on the builtin-fetch debugging and I was building on top of that topic in next, not all of next itself. > > For example, I do not think you can use this to mark reachable > > objects. Even if you find error walking the first parent > > history, you would want to still mark a healthy second parent > > history reachable. > > How should I define the return value of fsck_walk in the presence of > multiple errors? > > It would not be necessary for all my users: > > * in unpack-object and index-pack (I'll send an updated patch in the > next days), any error means that we can abort. Further checking would > mean wasting of resources. > > * in fsck (patch 2) the error is signaled by the errors_found variable, so > all callbacks can return 0, even in the case of an error. Checking the > return value of fsck_walk would mean duplicate error messages. So the return value is more about "keep walking" than it is about an error (or lack there of)? -- Shawn. - 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
