Re: Fast-forward able commit, otherwise fail

From: "Stefan Haller" Junio C Hamano wrote: Another thing to consider is that the proposed workflow would not scale if your team becomes larger. Requiring each and every commit on the trunk to be a merge commit, whose second parent (i.e. the tip of

Re: Fast-forward able commit, otherwise fail

li...@haller-berlin.de (Stefan Haller) writes: > I have read and re-read this thread a hundred times now, but I still > don't understand why it makes much of a difference whether or not Bob > rebases his branch onto master before pushing his merge. In both cases, > Alice and Bob have this race as

Re: Fast-forward able commit, otherwise fail

Junio C Hamano wrote: > Another thing to consider is that the proposed workflow would not > scale if your team becomes larger. Requiring each and every commit > on the trunk to be a merge commit, whose second parent (i.e. the tip > of the feature branch) fast-forwards to the

Re: Fast-forward able commit, otherwise fail

On Fri, Jul 8, 2016 at 3:19 PM, Junio C Hamano wrote: > David Lightle writes: >> In fact, I just noticed that GitLab has built in the functionality I'm >> looking for even, which is what they call "Merge commit with >> semi-linear history" but I'm asking

Re: Fast-forward able commit, otherwise fail

David Lightle writes: > In your above scenario with Alice & Bob, wouldn't that same issue come > up in _any_ rebase workflow (--ff-only)? From what I've read this is > a typical consequence of requiring fast-forward merges; to be > effective, the rebase step must be more

Re: Fast-forward able commit, otherwise fail

I've been trying to think of just what to say in response, so it has taken me some time as well as I've been experimenting with our workflow to try some alternate approaches while we still can. In your above scenario with Alice & Bob, wouldn't that same issue come up in _any_ rebase workflow

Re: Fast-forward able commit, otherwise fail

Junio C Hamano writes: > However, Git as a tool is not opinionated strongly enough to make it > hard to do these two things (independently). I do not think it is > unreasonable to add a new mode of "merge" that rejects a resulting > history that is not shaped the way you

Re: Fast-forward able commit, otherwise fail

David Lightle writes: > I know that I have read that --ff-only and --no-ff are contradictory, > but I believe that is somewhat ambiguously correct -- I believe the > two flags contradict in the sense of "what to do with the merge > commit", but not necessarily on the "when it

Fast-forward able commit, otherwise fail

Hello, I am trying to build a git workflow in our enterprise and am almost evenly torn between a "rebase workflow" and git-flow (which uses merge instead of rebase, obviously). We are using Bitbucket for pull requests as code reviews (right or wrong). I apologize if my inexperience with git