Re: Proposal to deploy GitLab on gnome.org

[Zbigniew Jędrzejewski-Szmek <zbyszek in waw pl>]

On Wed, May 17, 2017 at 01:23:43PM +0200, Christoph Reiter wrote:
> On Wed, May 17, 2017 at 12:47 PM, Jehan Pagès
> <jehan marmottard gmail com> wrote:
> > The only thing I am annoyed at is this forking workflow. Both as a
> > contributor, and as a code committer/reviewer. Having to fetch a new
> > remote for every single-commit contribution out there is terrible.
>
> In case you didn't know, just like with github you can fetch the PRs
> from the main remote if you adjust the git config accordingly:
> https://docs.gitlab.com/ce/user/project/merge_requests/#checkout-merge-requests-locally
>
> $ git fetch
> $ git branch -a # look for PR branch
> $ git checkout origin/merge-requests/42
> $ git checkout master

I have the following config (for github):

[alias]
        pr-fetch = "!f() { git fetch -fu ${2:-origin} refs/pull/$1/head:pr/$1; }; f"
        pr = "!f() { git fetch -fu ${2:-origin} refs/pull/$1/head:pr/$1 && git checkout pr/$1; }; f"
        pr-merge = "!f() { git fetch -fu ${2:-origin} refs/pull/$1/head:pr/$1 && git merge pr/$1 --no-ff 
--edit -m 'Merge pull request #'$1; }; f"
        pr-clean = "!git for-each-ref refs/heads/pr/* --format=\"%(refname)\" | while read ref ; do 
branch=${ref#refs/heads/} ; git branch -D $branch ; done"

(git pr NNNN checks out the PR as a new branch, and git pr-fetch NNNN
just creates the new branch but does not check out.)
IIUC, you want to rebase the PR onto your master to do a ff-merge. This should be
fairly easy to do with 'git cherry-pick ..pr/NNNN'.


> From another mail:
> When it's a separate remote, I even wonder if git will still make the
> link between the 2 remotes? Will it try to rebuild everything from
> scratch? This would be absolutely terrible.
I think there's some confusion as to what git is doing when you switch branches.
All it does is:
1. compare the two trees from the old commit and new commit,
2. write out the files that are different, delete files that are missing from the new tree.
So it does not touch any files that are identical between two trees.

When git writes out files, it doesn't do anything special, so the os updates
the mtime to "now". This means that the build system will rebuild everything
which has the updated files as deps. How much is rebuilt is depends on the
build system and the changeset... autotools will usually rebuild almost everything
if configure.ac was touched, but that's an issue with autotools, and git just
dumbly updates the files it is told to. (In particular, whether the commits
you are switching between are from the same remote, or different remotes, or
even from two trees which do not share a common parent — doesn't matter. Only
the SHA1 of the contents is relevant.)

Zbyszek