On Wed, Jun 20, 2012 at 12:37:14PM -0400, Jeff King wrote: > > But suggesting that we are supposed to ignore the FORCE just leaves > > the reader wondering why the same patch does not also urgently need > > to make additional changes such as the following, no? > > > > builtin/branch.o builtin/checkout.o builtin/clone.o \ > > builtin/reset.o branch.o transport.o: branch.h > > > > to > > > > builtin/branch.sp builtin/branch.o builtin/branch.s \ > > [...] > > Those lines were not updated because I did not notice them, as I was > keeping the scope of the updates to generated headers and files like > GIT-CFLAGS. IOW, my patch is a step in what I think is the right > direction, but it does not remove all issues, only one class of them. > > As a side note, I have to wonder if those lines are really worthwhile. > [...] Here's an updated series that drops these lines and I hope will address the commit message issues you brought up: [01/11]: Makefile: sort LIB_H list [02/11]: Makefile: fold MISC_H into LIB_H New in this iteration to get rid of these largely pointless manual dependencies. [03/11]: Makefile: do not have git.o depend on common-cmds.h New in this iteration. I noticed while double-checking that this dependency is pointless. [04/11]: Makefile: apply dependencies consistently to sparse/asm targets Updated based on earlier patches, and with a new commit message explaining a little more of what's going on. [05/11]: Makefile: do not replace @@GIT_USER_AGENT@@ in scripts [06/11]: Makefile: split GIT_USER_AGENT from GIT-CFLAGS [07/11]: Makefile: split prefix flags from GIT-CFLAGS [08/11]: Makefile: do not replace @@GIT_VERSION@@ in shell scripts [09/11]: Makefile: update scripts when build-time parameters change [10/11]: Makefile: build instaweb similar to other scripts [11/11]: Makefile: move GIT-VERSION-FILE dependencies closer to use The rest are largely the same, but with a few minor textual updates to accomodate the earlier changes. -Peff -- 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