Ludovic Rousseau wrote: > Merging a pull request from github adds a "merge pull request" commit. > The history is then not very nice (linear) but I don't know a better > way using the github web interface.
It isn't neccessary to use the github web interface just because github is used to host the repository. It works just as well to pull from any remotes and create fast-forward merges. But of course that will then work around the pull request workflow that github enforces. Greg Troxel wrote: > >> You should rebase your patches above OpenSC/OpenSC master. > > > > Ok, but pardon my git ignorance: I thought that one should never > > rebase a tree that will be published and pulled from? Or only if it's > > published and someone tries to *base a new tree* off of it? > > This is somewhat controversial, but from my experience in both open > source and large private projects, the key issue is not to rebase > branches that other people have made commits on top of, or merged into > other branches. I disagree that rebasing is controversial. This is just a tool. Rewriting history is never a problem, as long as everyone who is working together wants to understand how repositories work and how easy it is to resync with rewritten branches. Given a local branch foobar that tracks contributor/master here's what to do when the contributor has rewritten her master: git checkout -b orig_contrib_master contributor/master && \ git fetch contributor && \ git rebase --onto contributor/master orig_contrib_master foobar Clean up after the rebase is done: git branch -D orig_contrib_master Since rebase of the local branch is required, of course it is important that the mechanics of rebase are well understood. > I find that it's helpful to rebase branches proposed for merging. There are arguments both ways. I like the look of linear history. On the other hand, depending on the development model, merges may be a more accurate representation of the code history. Viktor Tarasov wrote: > I also vote for rebase of the feature branch before merging it to > the master branch. Note that any testing and review of the branch should happen *after* that rebase, to avoid a lot of wasted effort. > If this procedure seems annoying, then use cherry-pick, especially > when it's going about the minor changes. cherry-pick is almost the only thing that rebase does. It's often easier to just use interactive rebase to do the picking. //Peter _______________________________________________ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
