
Github's fork queue is dangerous - toni
http://rjbs.manxome.org/rubric/entry/1755
======
defunkt
The Fork Queue is a replacement for email patch management, not a merge tool.
It is for cherry picking changes from contributors, not merging branches.

This is why the author information is retained and --signoff is used.

As Hongli Lai says in the comments: _Most of the time, people who fork my
projects make a bunch of changes, some which I want and some which I do not
want. Cherry-picking instead of pulling totally makes sense in these
situations._

This is the situation it was designed for - reviewing and signing off on
individual commits, not merging branches.

I think the takeaway from this article is that we need to do a better job
explaining the feature and what it's for. I understand now how someone new to
the site would have no concept of email patch management or git cherry-pick
and assume this is a nice interface for `git merge`.

As a first step, I've improved the text in the help dialogue to be more clear
and link to the blog post + intro video more prominently. Maybe a next step
would be making the actual help link itself (it's a small question mark next
to Your <project> Fork Queue) more visible.

Also we could detect if it was your first time using the Fork Queue and offer
help - that seems to be a popular idiom for web apps these days.

Perhaps in the future we can even offer a first class merge tool as the author
suggests, but for now I've been extremely happy with how the Fork Queue
compliments (but doesn't replace) my offline workflow.

~~~
rjbs
That all sounds like good stuff. A lot of people -- and in this case, I do
mean highly technical users -- think that the Fork Queue is a fantastic place
to see what's going on and merge it as if it was a "real" merge. I always
thought this seemed nuts, and now I'm glad to see that it's not the intended
use.

Personally, I never visit the fork queue, and instead use the network diagram
-- which really is the bee's knees. Can you imagine clicking on a head and
saying, "merge this?" I can. That would be awesome.

------
swombat
Seems to me that the title of this article is a bit exaggerated.

The author should have titled it "I think Github should use pulling/merging
instead of cherry-picking when dealing with forks". Of course, that would
probably not have been voted to #1 on HN.

~~~
FooBarWidget
I think the choice of cherry-picking over pulling/merging is the right one.
Often I do not want to pull in all changes but only specific changes that I
approve. Cherry-picking is perfect for this.

~~~
davidw
I'm new to git. Can you/someone explain a bit further the advantages and
disadvantages of both, and what they mean in terms of how things are actually
set up in git? Articles like this make me wary of a tool that looks like it
involves far too much fiddling and not enough "just working".

~~~
jemmons
You mean the difference between a pull and a cherry-pick? I've been a user of
git for a year now and this is my understanding:

git pull is just a synonym for two commands: git fetch and git merge. git
fetch gets a copy of the remote branch you specify, git merge merges that
branch into your local one.

For the sake of this conversation we're mostly interested in git merge. The
primary function of git merge (in this context) is to create a new commit with
your local head and the head of the remote branch you just fetched as its
parents.

git cherry-pick is different. Instead of creating a commit with two other
commits as a parent, it creates a commit with just your local head as its
parent. So a cherry-pick doesn't bring two branches together. It just extends
your local branch by one more node.

"Well," I suppose the OP is arguing, "If the point is to take a remote's code
and merge it with mine, why would I ever want to pop those changes on top of
my own branch, extending it, instead of making a nice tidy commit that merges
both branches?"

The answer is sometimes (especially when you're working on public projects
with anonymous contributers), you don't want _all_ of the changes in a remote
branch. You only want _some_ of them. Just the _good_ ones.

In those cases, you can't create a commit with the remote head as one of the
parents because that would tell git that _all_ of that branch's changes should
be merged in, and that's not what you want. What you really want is a ways to
rebase just one or two commits from the remote branch onto your local branch.

And that is exactly what cherry-pick does. It lets you specify a single
commit, then rebases that commit on top of your local branch, extending it.

I think the author's problem is he was using this tool thinking it would
create commits with both remote and local parents -- that it would _merge_ his
branch and the remote one. Instead it created commits that had only his branch
as a parent -- that is, it _extended_ his branch.

When a tool does something unexpected, it can be scary. But in this case
there's no cause for concern. If what he really wanted was to merge the remote
and local branches, he cans still do that. Git is smart enough to know which
remote commits have already been applied to the local branch via cherry-pick
(or any other means). It then just skips those when resolving merges.

~~~
rjbs
I agree with all the technical things you said. The issue isn't that I don't
know what the Fork Queue does -- I do. It's that many users do not, and it is
unclear. Before I did know what it did, I thought it was a good way to let
some of the less-technical members of my team deal with simple cases of
collaboration without having to think about merging too much. Because it's
cherry-picking whole trees (in a manner of speaking), it led to confusion all
around, and would continue to do that.

The two solutions that defunkt and I both seem to like are (a) make it clear
that the Fork Queue is not a general-purpose merge tool and (b) add a merge
tool, someday.

