On Fri, Feb 27, 2015 at 8:20 AM, Lasse Kliemann <lasse@xxxxxxxxxxxxxxxx> 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@xxxxxxxxxxxxxxx
> More majordomo info at http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html