Re: Everyone, please stop making my life more difficult

[Joshua Judson Rosen <rozzin@geekspace.com>]

Sam Steingold <sds@gnu.org> writes:
>
> I thought that rebase _moves_ commits, not _creates_ them anew.

I have found it helpful to think of it like this, so maybe you will too:

    * A commit in git or bzr is a node in a linked list; the node's cdr
      is the commit's parent-commit, so cdr'ing through the list takes
      you back through history toward the branch origin.

    * You can't "just move" a node in a linked list without changing any
      of its content.

    * The reasons that you'd want to create a new node when "moving" a
      commit, rather than just modifying it in place, are largely the
      same as the reasons that you might want to re-cons nodes onto the
      head of a list rather than just setcdr'ing the existing cons cells
      in place.


> Just like "mv" does not change ctime of a file,
> rebase must not change the commit time.

If you mv a subdirectory to a different parent directory,
the subdirectory does need to be written to have its
".." link updated, which should update its ctime....

(and even regular files actually may have their ctime updated,
 for reasons that I can't seem to find a way of fitting into
 the VC analogy)

-- 
"'tis an ill wind that blows no minds."