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