Re: Proposal to deploy GitLab on

On Wed, May 17, 2017 at 04:36:48PM +0200, Jehan Pagès wrote:

On Wed, May 17, 2017 at 4:30 PM, Zbigniew Jędrzejewski-Szmek
<zbyszek in waw pl> wrote:
On Wed, May 17, 2017 at 04:25:09PM +0200, Jehan Pagčs wrote:

On Wed, May 17, 2017 at 2:44 PM, Carlos Soriano <csoriano 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

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.


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]