On Wed, May 17, 2017 at 04:36:48PM +0200, Jehan Pagès wrote: > Hi, > > On Wed, May 17, 2017 at 4:30 PM, Zbigniew Jędrzejewski-Szmek > <zbys...@in.waw.pl> wrote: > > On Wed, May 17, 2017 at 04:25:09PM +0200, Jehan Pagčs wrote: > >> Hi, > >> > >> On Wed, May 17, 2017 at 2:44 PM, Carlos Soriano <csori...@protonmail.com> > >> wrote: > >> > Ah, I see what you mean now. But then you can rebase yourself in master > >> > right? And the build time would be exactly the same no? > >> > >> Not sure what you mean. You don't want to rebase master under any > >> circumstances (unless you rebase over origin/master to be able to push > >> new commits of course). Anyway you usually won't be able to, since > >> force push should be forbidden in master. And in any cases, this does > >> not solve the issue I was talking about. > >> > >> What I want is rebasing a patch branch over master. And no, you cannot > >> do it *from* master. You have to first checkout the branch so that you > >> can rebase. Once you checked out, it's too late. Timestamps of various > >> files are changed even though they didn't change between master and > >> the rebased branch (but they changed in the in-between step). > > > > 'git cherry-pick ..branch' ? > > That's what I said I would likely do indeed a few emails ago. :P > But I was answering about the problems of rebasing for timestamp as an > alternative. > > cherry-pick still has a problem though. Unless the patch is trivial > and looks like it's totally good from reading the diff (I would still > do a quick build just to be sure), I don't really like to work on > master with commits. You never know, some day, just a reflex, you git > push… Hopefully it has never happened, but still. That's like working > on a production server. Yeah, I have pushed to master a few times by mistake… Embarrassing *and* permanent ;(
There's always git cherry-pick -n. That works as long as the PR has only one commit. Apart from that, I don't think there's a general solution to this problem… You could always play with setting branch.master.pushRemote to your private repo, so that an explicit 'git push origin' is required to actually push. But once you get into the habit of doing that, you're back to square one. So I don't think any automatic solution is possible. > That's why I like to work on master (so that I don't checkout outdated > branches and have long builds), but with git apply as a first step. One option is to improve the build system… Gnome is in the process of switching to meson, and meson does much better in this regard. So that might make this issue moot — by the time gitlab is implemented, branching might be cheap again. Zbyszek _______________________________________________ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
