Lasse Kliemann <la...@lassekliemann.de> writes:
> 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!
I do not think I agree with the premise of the above in the first
place.
The person whose push is failing is not a "victim". Everybody who
pushes is working together with others to advance what is hosted in
the repository he or she is pushing into.
If your work you failed to push is independent from others, then
"fetch-merge-push" will be conflict-less and that is no basis to
complain that you had to do extra work to get your change to the
commons.
If your work does conflict, what does it mean? It means that other
people did some work in the same area as you just have worked on.
Who are the best equipped to resolve such a conflict?
True, you are not the only one who can understand the conflict.
Those whose work in the same area that caused the conflict may know
the nature of their own changes just as well as you know your
changes, so they are equally qualified as you are. But you are
among the people a lot better qualified to understand and resolve
this conflict correctly than a random joe who was not involved in
changes that happened during the time your work was done offline
while the shared commons were advancing.
Unlike your view to see conflict resolution is a "burden", implying
"after I push my changes out, it is other people's problem to
correctly integrate their changes, and it will not be my problem if
they break the change I did before they did with the merges", the
workflow Git suggests when it rejects a non-fast-forward push
encourages more effective collaboration by making sure that the
opportunity to integrate _your_ own changes correctly to the shared
common is given to _you_.
Having said all that.
There may be cases where you are far less qualified to resolve the
conflict than other people who were involed in it. After
$ git push
... results in no-ff
$ git pull
... results in conflict
the changes that overlap with your work can be found in this:
$ git log ..MERGE_HEAD
And those who worked on them may know the area you and they both
worked on a lot better than you. And I fully understand and agree
with you that you and they need a way to communicate and makes it
easy for you to ask them for help.
I however do not think an anonymous "split head" (i.e. 'master' that
is split 47 ways because different people punted on their conflict
resolution and left their work based on older state not usable by
the collective commons) is the best way to do so. Your option (3)
encourages a workflow where it is OK to punt after saying "I gave
random others to resolve if/when they feel like it", while making
it more difficult for you to communicate those others that are more
qualified to help you---you have to say which one of 47 split heads
you want them to take a look to help you.
Your message to ask somebody for help would say what your changes
were for, what changes from them conflicted with that, and because
you do not understand some of their changes you do not know how best
to adjust your changes on top of theirs (yes, adjusting your changes
to the updated shared commons is what a merge resolution is about).
As a part of that communication, pushing your work, that is based on
an older shared common from their point of view, to a branch whose
name is taken after the topic you were working on, i.e. what your
changes were for, would help (or a non-branch ref, such as
refs/helpme/lasse-<topic>) a lot better than "Hey, here is a random
unexplained half-done work based on an older version of 'master'.
Feel free to grab it and integrate. I don't bother understanding
and resolving the conflicts with more recent state of the project",
which is how Option (3) seems to be aiming at.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
