Re: improving our workflow with better tools - let's test things.

[Joseph Rushton Wakeling]

On 21/10/13 06:13, Carl Sorensen wrote:
> Even though it can be a pain to rebase commits, when it's done on the
> current Lilypond process I feel like the commit messages are much better
> than the ones that show up by default on Gitlab (merging branch xyz).

I'll test this out on GitLab just to see what it's like.  Working on GitHub I 
have never had any particular issue with rebases, but what I see as an issue may 
not be what you see as an issue, and vice versa ... :-)

> I don't like the proliferation of branches on Gitlab.  I realize they can
> be automatically deleted when the merge is accepted (and that's the
> workflow I've been following, at least some of the time).  But then that
> leaves an unmerged branch on the local system that it can be hard to tell
> when it is safe to delete.  I don't like lots of branches hanging around
> in my local repository.  I only like to have branches for issues I'm
> currently working on.

I don't really understand the concern here, there's no reason why there should 
be more branches than for features/issues that are currently being worked on. 
Or do you mean that it bothers you that users are encouraged to clone the repo 
so there is a proliferation of project repositories?

This latter thing bothered me too initially (with GitHub) as I was used to just 
pulling from the main repo to my local machine and submitting patches via email; 
but I quickly realized that it was actually sensible, and that those user repos 
are just places to publish one's own branches, which can then be submitted to 
the central project for merging.

A consequence of that is that you don't need many people to have commit access 
to the main repo, and that can be kept very clean -- in fact, in well-managed 
project, the only writes to the main repository should be merges, with 
everything getting reviewed before it's committed.

As for when it's safe to delete a branch: when it's been merged.  GitLab should 
auto-detect that and recommend it via the UI, while on your local machine, git 
branch -d branchname will only carry out the deletion if it's safe.

> I don't like the fact that the commit message is different on origin that
> it is on my remote.

Can you elaborate?  This is odd for me because one reason I reacted badly to the 
existing Lilypond setup was that the commits I sent were being rewritten (e.g. 
my patch was automatically rebased with different author info, using my gmail 
address).  I don't anticipate any similar problems with GitLab.

Is it that, because GitLab asks for a merge request summary, you find that this 
gets used in the mainline commit history?  But that's natural given that it's 
the summary for the _merge_; the commits that are merged in should preserve 
their own commit messages.

> I find the Rietveld interface for reviewing patches friendlier than the
> Gitlab interface, but that may be just because of my familiarity.

Any particular features that you have in mind here?

> I haven't found a nice connection between issues and merge requests.  I
> guess there isn't a nice connection in the current LilyPond toolset,
> either, but I was hoping that using an integrated system would make it
> easier.  I didn't find it so.

That's disappointing, but looks like it's a known issue that should be fixed 
soon: https://github.com/gitlabhq/gitlabhq/pull/4507

> I had hoped that I could use the milestone facility in Gitlab to help with
> the connection between issues and merge requests, but haven't found a good
> way to do so.

I suspect it's down to the same problem referenced above.

> As an overview (not really specific), I only have about 25 issues on my
> Gitlab project, but I feel more out of control about it than I do with the
> thousands of issues on LilyPond.
>
> I recognize that much of this could just be familiarity.  It's difficult
> to teach an old dog new tricks, and I'm turning into an old dog.

I'd be happy to take a look at how you're organizing things and see if I can 
suggest some better solutions.  Out of curiosity, what were you using before you 
tried GitLab?  Or is it a new project?

> I'm not opposed to having you and Janek work on an improved system.  But
> for my little project (3 developers), I'm seriously thinking of junking
> Gitlab because the benefit seems to be more promised than realized.

What kind of workflow are you trying to achieve?  I wonder with so few 
developers if you're used to a setup where everyone is trusted and just has push 
access to the main repository, and GitHub, GitLab etc. do rather militate 
against that.  I think that's a feature, but obviously not everyone is going to 
feel the same.