Tools for tracking git cherry-picks.
Latest commit 585af97 Jul 22, 2013 @kergoth Add LICENSE file (MIT)
Failed to load latest commit information.
src/git_origin Initial handling of nonexistant origins and nonexistant refs/notes/or… Dec 11, 2009
LICENSE.txt Add LICENSE file (MIT) Jul 22, 2013



Tools for tracking git cherry pick operations

These are most useful when dealing with multiple long lived branches, where
one is cherry picking in both directions.  If one does a cherry pick and has
to change the patch to make it apply, the patch-id is no longer the same, and
git's existing tools are unable to associate it with the original.  As a
result, it's quite difficult to get an accurate list of commits that still
need to go from A to B, or from B to A.

Note that one commit can have multiple origins, and multiple commits can have
the same origin.  This is to facilitate the cases where you split a commit, or
squash multiple commits, when pulling the changes over.

:git-origin: Add/set/remove/list origins on a commit.
    Mark a commit as blacklisted--will be shown as
    existing in both branches without associating an
    origin or origins.  This is useful for internal-only
    changes you don't need to see when checking against
    upstream.  This is also useful for handling git-revert
    commits, but I'd like to find a better solution for
    Command like git-cherry but which obeys the origin data
    rather than the patch-ids.
    Wrapper around git-cherry-origins which provides a
    git-log-like interface.  If 'tig' is available, it will use
    it as the pager by default, otherwise it falls back to less
    or more.
    Populates origin information using patch-id
    information to identify identical commits.
    Fetches the origins ref from a remote repository and merges it into our
    origins, possibly dropping the user into the temporary checkout to resolve
    any conflicts.

- git-fetch-origins/git-pull-origins: Implement.
- git-populate-origins: Implement.
- Convert all the git origin scripts to subcommands of a git-origin script.
- git-python: repo.commit(<some merge commit>) seems to ignore the merge
              commit, returning the next non-merge commit.
- git-python: getting the commit corresponding to a ref is not as easy as it
              should be.  You have to call find_all and grab the first
              element, which seems silly.  I think we should add a
              Commit.rev(ref) which calls rev-parse, then cat-file and parses
              that into a new Commit.  Either that, or we handle refs being
              passed into a Commit constructor.  You can do that today, but
              then the .id will point to the ref, it doesn't call rev-parse
              against it itself.
- Switch everything to the logger module.
- Split up the cmd module.
- git-log-origins: Implement.
- git-python: Add our _rev function to Repo as a rev_parse method.

- git-python: add Index class from git-origin.
- git-python: Make Repo utilize Index.
- git-python: Allow passing custom work tree and index in Repo's constructor.
              I really don't know if this would be useful, because it would
              still be using the default HEAD ref.  If you were to run
              repo.git.checkout() with a non-standard index and work tree, it
              would still update the HEAD ref, which would no longer match the
              primary checkout.  It would make it slightly more convenient for
              non-porcelain commands like read-tree/write-tree, but that's
              about all the usefulness I can see.

.. vim: set encoding=utf-8 ft=rst: