Question

I’d like to contribute to an open source project on Github. Before my workflow was the following (no VCS used):

1. I kept a ‘working’ folder and a ‘clean’ folder on my hard drive. I’ve update the reference version when there was a change and kept working on my ‘working’ version.
2. When I wanted to do a pull-request I compared the files in a visual comparing program and went to Github.com / source / edit file, manually edited the different files and sent a pull request on the web interface.

Now I wanted to modernise this workflow (while avoiding Git) but I’m absolutely stuck after 5 hours of trial and error. I did the following:

1. Forked the Github repro to my own
2. Cloned the forked repro and edited the url to git+ssh://[e-mail] to make pushes possible. Github – hg-Git – Mercurial works perfecly so far.
3. Started editing on the forked repro like usual. Modified files, etc.
4. Now what can I do if I want to submit a pull-request for some of my edited files? I’ve tried cloning into an other repro and only modifying there, but I didn’t see how could that help me.

So far the only idea I could come up with is to keep two forked repros on the hard drive, one ‘clean’ and one ‘work’. Then I would physically copy files from ‘work’ to ‘clean’ and only create a commit in the ‘clean’ repro from those files. But this seems to be such a ‘hackish’ way of doing things, I’m sure there must be a clean way with bookmarks / cloned repros or something elegant.

Can you tell me what would be the best workflow for sending selective pull requests using Mercurial?

Answer 1

You can’t do a pull request that has only a part of changeset — changesets are non-separable in both Mercurial and Git.

You also can’t push or pull (or request pull of) a changeset without pulling all of its ancestors too, so even committing two separate times, with different files each time, won’t get you what you want if you commit the stuff you don’t want to push/pull/submit before the stuff you do.

Which is why you need to use feature branches to separate your submissions into logically distinct lines of development.

If the upstream repo looks like this:

[A]---[B]---[C]---[D]

and you clone it so now you have this:

[A]---[B]---[C]---[D]

and then you make a changeset that has some stuff you want to submit as a pull request and some you don’t:

[A]---[B]---[C]---[D]---[E]

you’re out of luck. You can’t push a part of E without pushing all of it. You need to separate the stuff you want to push into one changeset (F) and the stuff you don’t (yet?) want to push (or request to have pulled) into another changeset (E):

[A]---[B]---[C]---[D]---[E]---[F]

You’re still out of luck because you can’t push (or request to have pulled F) without also including E, since E is an ancestor of F.

Instead you need to make your E and F work siblings, not parent child. Like this:

[A]---[B]---[C]---[D]---[E]
                     \
                      --[F]

Now you can push F to your fork without E and can request that F be pulled in without them ever even seeing E.

That branching command looks different whether you’re using Mercurial:

hg clone THEIRS # now you have A through D
... work ...
hg commit # now you created E, which you don't want to push
hg update D  # current directory no longer shows E
... work ...
hg commit # now you have F which is a child of D and a sibling of E
hg push -r .    # send F (but not E)

or git:

git clone THEIRS # now you have A through D
git checkout -b feature_e
... work ...
git commit # now you have created E, which you don't want to push
git checkout master # current directory no longer shows E
git checkout -b feature_f
... work ...
git commit # now you have created F, which you do want to share
git push -u origin feature_f  # send F but not E 

And now you’ll have a branch up there with only the F work and not the E work and can make the pull request you want.

TL;DR: By the time you’ve mixed contributions and non-contributions in the same commit or branch you’re out luck. You need to separate them or create a patch and submit a patch rather than a pull request.