> -----Original Message----- > From: Stanislav Malyshev [mailto:smalys...@gmail.com] > Sent: Thursday, May 21, 2015 9:28 AM > To: Remi Collet; internals@lists.php.net > Subject: Re: [PHP-DEV] About merging Pull Request workflow > > Hi! > > > Current workflow described in > > https://wiki.php.net/vcs/gitworkflow#merge_a_pull_request > > > > Problem, git history only give info about a "merge" > > If you merge from a pull, the history should contain both original commit and > the merge commit. So you know both who created the patch and who merged > it. At least for me it always did. Unless you use some special tricks to edit > the > history, such as --no-commit. >
I've just made an exercise as I wanted to backport that PR to 5.5. So I went by Remi's way. As "git am" worked cleanly, I've just pushed it. Result - the original author credit is kept, the person who did "git am" is the commiter, no merge commit. Plus, IMO a big plus - the commits from the PR are put on the top. Say if there's a branch with commits made a year ago, those commits won't be seen with the current approach from the wiki. They'll be possibly too far in the history. So all in all, Remi's suggestion sounds eligible. Credits held, commiter is recorded, cleaner history and commits on the top as a bonus :) If we could integrate it with the current github automatics, that were an improvement, IMHO. Regards Anatol -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
