source-1232778113.txt

   1 Thoughts about ''interactive rebase''
   2
   3 Somebody mentioned that my ''my-next'' branch is a mess, as it mixes all
   4 kinds of topics.
   5
   6 That is undeniably true, however, there is a good reason that I do not
   7 have a lot of topic branches: I work on more than just one computer.
   8
   9 To make sure that I do not lose a commit by mistake, I always ''rebase -i''
  10 the ''my-next'' branch of the computer I happen to work on on top of the
  11 ''my-next'' branch I fetch from repo.or.cz.
  12
  13 To rebase a lot of topic branches at the same time seems a bit complicated.
  14 But that is actually what the ''-p'' option (preserve merges) is all about.
  15
  16 The only problem is that the code for ''rebase -i -p'' has been messed up
  17 recently, quite successfully, I might add.
  18
  19 Worse, some people are pushing for a completely and total unintuitive syntax.
  20
  21 So maybe I will start to work on ''-p'' again, for my own use (I should learn
  22 to heed the principle more: work on things I can use myself).
  23
  24 My current idea is to implement a "goto" statement that will jump to another
  25 commit.  To make it easily usable, I will add the semantics that "goto" will
  26 always try to go to the _rewritten_ version of the given commit; if the user
  27 wanted to have the original commit, she has to paste the unabbreviated commit
  28 name.
  29
  30 The more I think about it, the more I actually like this idea :-)
  31
  32 Of course, working on this little project means that I will have to cope with
  33 that ugly code again.  *urgh*