Junio C Hamano <gitster@xxxxxxxxx> writes: > Yuck; I can see what you are doing but can you imitate what the more > experienced people (e.g. peff, mhagger) do when restructuring > existing code and do things in smaller increments? Seconded. Some reasons/guide to split: * Split trivial and non-trivial stuff. I can quickly review a "rename-only" patch even if it's a bit long (essentially, I'll check that you did find-and-replace properly), but reviewing a mix of renames and actual code change is hard. * Split controversial and non-controversial stuff. For example, you changed the ordering of fields in a struct. Perhaps it was not a good idea. Perhaps it was a good idea, but then you want this reordering to be alone in its patch so that you can explain why it's a good idea in the commit message (you'll see me use the word "why" a lot when talking about commit messages; not a coincidence). * Split code movement and other stuff. For example extraction of match_name_as_path() would be trivial if made in its own patch. I'd also make a separate patch "introduce the ref_list data-structure" to introduce struct ref_list and basic helper functions (constructors, mutators, destructors). It will take time and may appear to be counter-productive at first, but you'll get used to it, and you'll end up being actually more productive this way (well, maybe not "you" but the set "you + reviewers"). -- Matthieu Moy http://www-verimag.imag.fr/~moy/ -- 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