[StGIT PATCH 0/9] Refactoring of command handling

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



While working on hydra support, I've hit a couple of issues which I
have handled with a set of relatively large patches: nearly every line
of code under stgit/commands/ gets reindented, because of functions
being changed to instance methods.

I submit this patchset early, despite it being very young, because of
the high risk of conflict with other work and the large amount work it
would require to maintain in parallel - also, since the testsuite does
not cover everything, it is likely that I left a couple of errors
somewhere, and I'd be grateful to have other people shake the code as
well.  Now this set of patches would be a great candidate for a "pu"
branch :)

The next refactoring pass (already in the works but with no
stabilized design yet) will tackle git_id(), which should be
available at generic level, not at the command level.  I'm heading
towards changing it to be a method of a new stgit.Repository class,
pointed to by Commands and PatchSets.

Here is a quick summary:

      Refactor command definition with a Command class.
      Promote more common functions to Command methods.
      Replace crt_series uses with a method call.
	=> those are the heart of the refactoring: we suppress the
	   crt_series global and only create the Series object when
	   needed.  This is a step towards a PatchSet factory which
	   will be able to instantiate a Series or an Hydra from a
	   head name, without a need for the called to be aware of the
	   existence of PatchSet subclasses.

      Fixed thinko in error message.
      Add a constructor to PatchSet.
      Cleanup the use of the Series class.
      Changed sync not to use -b which has other semantics.
	=> cleanup needs discovered while refactoring

      Fix contrib/stg-whatchanged way of identifying a conflict.
	=> fixing the tools that help getting the patches done :)
      Revert part of the reverted commit that we want to keep.
	=> mostly here so we don't loose it, and limit the conflicts
	  when I pulled from you :)

Best regards,
-- 
Yann Dirson    <ydirson@xxxxxxxxxx> |
Debian-related: <dirson@xxxxxxxxxx> |   Support Debian GNU/Linux:
                                    |  Freedom, Power, Stability, Gratis
     http://ydirson.free.fr/        | Check <http://www.debian.org/>
-
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

[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]

  Powered by Linux