Easy Non-Fast-Forward Pushes

As far as I understand, a push will always modify (or add) a ref in the
remote repository. When pushing to branch B, then the ref pointing to the
last commit in this branch will be moved, provided that this can be done in
a fast-forward way. Otherwise the push will fail.

The following options exist:

(1) force the push
(2) fetch, merge, then push
(3) push to a different branch

I don't want (1), for obvious reasons.

Option (2) implies that a particular person has to do the merge, namely the
person for whom the push is failing, or in other words: the person
unfortunate enough not being the first to push. (This reminds me of
Subversion: whoever tries to commit after someone else has committed will
have the burden of an update and possible merge.)

Option (3) allows others to recognize the situation, and anyone with
repository access can do a merge. This is a good thing. However, I am
confused as to what branch name should be used for this. In Mercurial, we
would say that a new "head" is created, and anyone can recognize this by
using "hg heads" and do a merge if he feels competent enough. (A "head" in
Mercurial is a revision without children.) Can something similar be done in
Git? I'd like to provide my co-workers with a command which they can always
use to push their changes to a central repository in order that I can see
what has happened and do merges accordingly. In Mercurial, such a command
would simply be "hg commit && hg push -f". Then I can use "hg heads" to see
if any new heads have grown, and if so, do merges. Upon their next pull,
these merges would manifest themselves in the repositories of my co-workers,
and everything will be fine for them. So, im looking for the equivalent of
that workflow in Git. Thanks a lot!

On Fri, Feb 27, 2015 at 8:20 AM, Lasse Kliemann [off-list ref] wrote:

As far as I understand, a push will always modify (or add) a ref in the
remote repository. When pushing to branch B, then the ref pointing to the
last commit in this branch will be moved, provided that this can be done in
a fast-forward way. Otherwise the push will fail.

The following options exist:

(1) force the push
(2) fetch, merge, then push
(3) push to a different branch

I don't want (1), for obvious reasons.

Option (2) implies that a particular person has to do the merge, namely the
person for whom the push is failing, or in other words: the person
unfortunate enough not being the first to push. (This reminds me of
Subversion: whoever tries to commit after someone else has committed will
have the burden of an update and possible merge.)

Option (3) allows others to recognize the situation, and anyone with
repository access can do a merge. This is a good thing. However, I am
confused as to what branch name should be used for this. In Mercurial, we
would say that a new "head" is created, and anyone can recognize this by
using "hg heads" and do a merge if he feels competent enough. (A "head" in
Mercurial is a revision without children.) Can something similar be done in
Git? I'd like to provide my co-workers with a command which they can always
use to push their changes to a central repository in order that I can see
what has happened and do merges accordingly. In Mercurial, such a command
would simply be "hg commit && hg push -f".

For a high level workflow with pure git, everything must be a branch
or a tag IMHO,
(I cannot really think of other ways).

So maybe you create a bash alias for
alias gitup='git push origin HEAD:${USER}/$(date -Iseconds)'
which would push your current tip of the repository to the remote with
quite a unique name.

Then you could also do a "git commit -a && gitup" to push your changes
to the server
As the integrator you could then integrate branches with
    "git fetch origin && git merge origin/sbeller/2015-02-27T09:34:47-0800"

So it is doable. Though I am not convinced of the workflow.
Maybe you want to look at Gerrit or GitLab  (both are open
source web userinterfaces, where you can push changes to
and approve them)

Then I can use "hg heads" to see
if any new heads have grown, and if so, do merges. Upon their next pull,
these merges would manifest themselves in the repositories of my co-workers,
and everything will be fine for them. So, im looking for the equivalent of
that workflow in Git. Thanks a lot!

--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Stefan Beller [off-list ref] writes:

So maybe you create a bash alias for
alias gitup='git push origin HEAD:${USER}/$(date -Iseconds)'
which would push your current tip of the repository to the remote with
quite a unique name.

Then you could also do a "git commit -a && gitup" to push your changes
to the server
As the integrator you could then integrate branches with
    "git fetch origin && git merge origin/sbeller/2015-02-27T09:34:47-0800"

So it is doable. Though I am not convinced of the workflow.

This solution is not too bad, I thought, but there should be a way to
remove those branches once I have integrated them. Otherwise the
repository might get cluttered, and I found that those branches are
particularly annoying when viewing a graphical representation of the
commit graph.

Deleting is possible, using 'git push origin :BRANCH'. But then, anyone
with pushing capabilities could do this! I don't like the possibility of
one team member messing up another's commit, be it on purpose or
accidentally.

In Gitlab, branches can be protected. For this to work, however, I would
need fixed names. So I would assign one branch to each team member, make
those branches (let's call them "personal branches" for now) protected,
and then configure their systems (by shell aliases, scripts, ...) to the
following:

1. Try pushing to origin/master. If it works, fine. If not, goto 2.

2. Push to the appropriate personal branch.

This system does not prevent someone pushing to another's personal
branch, thereby possibly making a fast-forward push impossible. So step
number 2 may fail due to this, but this might be an acceptable risk.

Thanks a lot for your thoughts.