When should a commit, commit twice?
When one or more git mv file renames/ moves are involved.
In such a case the commit ought to be split into two. Perhaps move the
files in the first commit, then make the changes needed to support the
move in the build chain (including changes in the moved files) in the
second commit.
This keeps a clean record of the move, making the move, and the
associated changes (as two commits) a clean cherry.
Does this make sense?
I develop in the java world, and we use packages (directories, and
subdirectories, sub-sub... etc) a lot, and so it is not uncommon in my
10 years development, to decide to reorganise some package/dir every now
and then, and files, and whole dirs, get moved.
I've only been using git for a few weeks, but finding it truly awesome!
A little demanding in the initial learning curve - took me three days of
reading and a little experiementation here and there, before I finally
felt comfortable with rebasing, branching, etc, to effect my work
pattern.
Have used arch/tla, a little bzr, aegis for a couple of years long time
ago, some cvs, and bk for four months or so.
I'm hoping that the above workflow, which has just crystallized for me
in the last two days, makes sense.
zen
--
Homepage: www.SoulSound.net -- Free Australia: www.UPMART.org
Please respect the confidentiality of this email as sensibly warranted.
On Dec 23, 2007 1:03 PM, Zenaan Harkness [off-list ref] wrote:
When should a commit, commit twice?
When one or more git mv file renames/ moves are involved.
In such a case the commit ought to be split into two. Perhaps move the
files in the first commit, then make the changes needed to support the
move in the build chain (including changes in the moved files) in the
second commit.
This keeps a clean record of the move, making the move, and the
associated changes (as two commits) a clean cherry.
Does this make sense?
Not particularly. Git commits are not (conceptually) changes or
deltas; they are snapshots of a tree of files at a particular time.
How does the tree state at your above first commit make any sense? It
is broken. Git's rename/move detection is smart enough to notice that
a rename + small-changes is close enough to a rename, so just trust
that to get it right.
Dave.
David Symonds wrote:
On Dec 23, 2007 1:03 PM, Zenaan Harkness [off-list ref] wrote:
quoted
When should a commit, commit twice?
When one or more git mv file renames/ moves are involved.
In such a case the commit ought to be split into two. Perhaps move the
files in the first commit, then make the changes needed to support the
move in the build chain (including changes in the moved files) in the
second commit.
This keeps a clean record of the move, making the move, and the
associated changes (as two commits) a clean cherry.
Does this make sense?
Not particularly. Git commits are not (conceptually) changes or
deltas; they are snapshots of a tree of files at a particular time.
How does the tree state at your above first commit make any sense? It
is broken. Git's rename/move detection is smart enough to notice that
a rename + small-changes is close enough to a rename, so just trust
that to get it right.
Moreover renames detection during merges is based on three states:
ours, theirs and ancestor, and it would not take into account
"pure rename" commit it is there in the middle of one of chains.
Besides broken (not compiling) commit makes it harder for bisect to find
true bug later.
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git