Zenaan Harkness <zen@xxxxxxxxxxxx> writes:
> When should a commit, commit twice?
>
> When one or more git mv file renames/ moves are involved.
> ...
> Does this make sense?
Anything that feels right to you is right for _your_ project, so
asking that question does not add much value, but I would not
personally do that myself. I may have pure rename commits that
move files around without changing any contents in my history,
but that is only because there happened to be no need to change
the contents in those commits, not because I followed an
artificial "a rename-only commit, followed by a commit that
edits" dogma you seem to be suggesting.
If I move file common.c to lib/common.c and common.h to
include/common.h, I would definitely NOT record that as two
events, if common.c used to include common.h. My commit that
moves these two files will definitely contain edit to common.c
(now lib/common.c) that changes at least one line:
-#include "common.h"
+#include "../include/common.h"
in the same commit. If you split this as two events, your first
"rename only" commit would not even build.
-
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
