On Oct 7, 2019, at 3:22 PM, Gerald Combs <gerald@xxxxxxxxxxxxx> wrote:
> For new contributors, getting up and running with GitLab should be easier. GitLab doesn't require pushing to a special remote reference and doesn't require a special Change ID in the commit message. It should also be more familiar. For better or worse, the world seems to be standardizing on Git{Hub,Lab} and their respective workflows and tooling.
>
> For existing contributors and core developers, the review process would change a fair amount. The current [-2 .. +2] approval system would either change or go away depending on the flavor of GitLab we use[2][3]. It also looks like you can't edit a commit message in the web UI before merging[4].
1) Can you push (or whatever) a proposed commit to GitLab and then do a git commit --amend, changing either code or commit message, and then push and have that amend the commit-on-GitLab, without polluting the history?
2) Will this cause merge commits, such as the crap that GitHub dumps in there by default:
https://github.com/the-tcpdump-group/libpcap/commit/b43fdf882a3bd71391535362b3bf560ec54e77ef
to pollute the history?
3) Will I be forced to use branches in my local repository or can I do all my work in the default branch?
