git equivalent to hg mq?

Question

I just started using Git alongside Mercurial to familiarize myself with Git.

I use the mq extension in Mercurial extensively to manage local patches, and I\'m lookin

Answer 1

Check out "Patch-management Interface layers" section of Interfaces, Frontends And Tools page on Git Wiki. There are listed two patch management interfaces, roughly equivalent to Mercurials 'mq' extension:

• StGIT (Stacked Git), older of the two, written in Python, uses two snapshots to represent patch
• Guilt (formerly 'gq'), written as series of bash scripts, series file and the patches (one per file) are stored as plain text file.
• pg (Patchy Git) is deprecated, and no longer maintained.

But if you don't need more advanced usage, you can use instead "git rebase --interactive" to reorder, squash and split patches. And to manage your branch against current version of upstream, "git rebase" usually would suffice.

Answer 2

Just use a branch and rebase it against your upstream branch regularly. This is both easier to manage and safer than using mq (to which I've lost data in the past).

Answer 3

Git doesn't really provide this feature itself. Depending on your uses, you might be able to get by with "git stash" and/or branches, but it'll be pretty basic. If people have more advanced patch management needs with git, they seem to turn to Quilt or StGit: see http://git.or.cz/gitwiki/PatchManagement

Answer 4

Disclaimer: I'm not an hg user, so I have read about hg but don't have much first hand experience of using it.

git provides several very powerful and flexible tools for managing branches in a 'patch queue' style so for many basic (and even some quite complex) use cases, native git is sufficiently powerful.

Typically, most projects keep a central stable master branch which only gains new commits and is never 'rewound' so commits in the master branch are fixed.

On top of this a maintainer (or a developer) may maintain one or more fluid branches of work-in-progress patches (i.e. commits) which are based on the stable branch.

Typical patch managing activities include:

rebasing the patch queue onto the lastest stable branch - use git rebase,

duplicating the patch queue onto an old maintentance branch - use git branch and git rebase,

reordering patches in the queue - use git rebase --interactive (aka git rebase -i) using a text editor to reorder the queue.

squashing patches - use git rebase -i with the squash directive

altering patches or patch commit messages - use git rebase -i (spot a theme?) with the edit directive.

Any activity that alters a patch in any way (i.e. its contents, description or parentage) will create a new commit with a new commit id for that patch. The fact that the old commits may be thrown away and replaced regularly before they are promoted to the stable master branch is the only thing that makes them a 'patch queue' rather than a branch, but this is a project convention rather than any physical difference in the data that makes up the commits. To git they are identical objects.

To promote a patch to a 'real' commit is just moving the patch to the front of the queue and merging it into the master branch. After moving the patch to the front of the queue, it is just the same as a normal commit based on the master branch, so merging it just fast-forwards the master branch pointer to point at the patch commit.

Publishing this commit as a 'stable' master patch is the act that says: this is now a commit that will not change and is part of the immutable history of the project.