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

README.txt

git-origin
==========

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.

Tools
-----
:git-origin: Add/set/remove/list origins on a commit.
:git-origin-blacklist:
    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
    that.
:git-cherry-origins:
    Command like git-cherry but which obeys the origin data
    rather than the patch-ids.
:git-log-origins:
    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.
:git-populate-origins:
    Populates origin information using patch-id
    information to identify identical commits.
:git-fetch-origins/git-pull-origins:
    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.

TODO
----
- 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.

Uncertain:
- 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: