[Q] `git push', branch management, and "(forced update)"?

[Q] `git push', branch management, and "(forced update)"?

[Brian Foster]

Hello,

   A colleague of mine will be asking for my help when he
  returns later this week, and I'm not too certain what's
  going on.  My instant reaction is what he's doing may not
  be a good idea (an example of rebasing a branch that others
  pull, which I understand should be avoided).  However, I'm
  not a gitpert, and am also sufficiently confused it's worth
  asking for help/advice.  My apologies for the length....

   What we have is four (4) repositories, L, B, R, and M:

     L is my colleague's (local) working repository.
     B is a bare repository.
     R is one (or more?) remote repositories.
     M is a bare repository.

  The model is work is done in R, patches are sent (by e-mail)
  to my colleague, who applies them to L, often does some fixes
  (in L), pushes the resultant applied-patch-plus-fixes to B;
  and R pulls every now and then from B.  The cycle repeats.
  (M, as such, does not enter the picture at this point.)

   More specifically, what my colleague does (I think, I may
  not have this completely correct) is apply the patches to
  a topic branch TOPIC.  His fixes are separate commits, also
  on TOPIC, so (in theory) TOPIC grows in a nice linear manner
  (`r' came from R via e-mail, `f' is a local fix):

     o--o--o--o master
               \
                r--r--f--f TOPIC

   L is a clone of M, where other work has also been committed,
   in master.  So now-and-then my colleague pulls M into L:

     o--o--o--o--*--* master
               \
                r--r--f--f TOPIC

  My colleague then pushes the result to B.  End result is B
  is essentially M plus TOPIC.

   As it happens (mostly by design), the changes on TOPIC
  are independent of the `*' ones on master.  So, working
  in L, my colleague often rebases, and this is (always?)
  a fast-forward:

     o--o--o--o--*--* master
                     \
                      r--r--f--f TOPIC

  He now wants to push that structure to B, so that R can
  later pull the updated world.  Based on some experiments,
  he does (in L):

     $ git checkout master
     $ git push --tags ssh://.../B.git  +:

  (I'm not sure why he is using `--tags', or `+:' instead
  of a simple `:') but reports what happens is the `push'
  gets the error(?):

     fatal: remote part of refspec is not a valid name in +:

   Given that `git help push' (1.6.2.2) lists/describes the
  `+:' <refspec>, I'm (extra) baffled.  What's going on?

   Each of the repositories L, B, R, and M are on different
  machines, and it is highly probable different versions of
  git are being used.

   In a simple simulation test I tried, it not only worked
  for me, but the subsequent pull from simulated-B into
  simulated-R said the TOPIC was a "(forced update)".
  What does that mean?

   And what is it my colleague should consider doing (or,
  reading?)?

  Again, apologies for the length!

cheers,
	-blf-

-- 
“How many surrealists does it take to   | Brian Foster
 change a lightbulb? Three. One calms   | somewhere in south of France
 the warthog, and two fill the bathtub  |   Stop E$$o (ExxonMobil)!
 with brightly-coloured machine tools.” |      http://www.stopesso.com

Re: [Q] `git push', branch management, and "(forced update)"?

[Junio C Hamano]

Brian Foster <brian.foster@innova-card.com> writes:

>    L is a clone of M, where other work has also been committed,
>    in master.  So now-and-then my colleague pulls M into L:
>
>      o--o--o--o--*--* master
>                \
>                 r--r--f--f TOPIC
>
>   My colleague then pushes the result to B.  End result is B
>   is essentially M plus TOPIC.
>
>    As it happens (mostly by design), the changes on TOPIC
>   are independent of the `*' ones on master.  So, working
>   in L, my colleague often rebases, and this is (always?)
>   a fast-forward:
>
>      o--o--o--o--*--* master
>                      \
>                       r--r--f--f TOPIC

When he rebases the TOPIC, he is not making this topology.
Instead, this is what he is making:

                       r'-r'-f'-f' TOPIC
                      /
      o--o--o--o--*--* master
                \
                 r--r--f--f

The tip of the TOPIC before (the rightmost commit on the lower side branch
in this picture) is not an ancestor of the tip of the TOPIC after the
rebase.  It is not a fast-forward.

>    In a simple simulation test I tried, it not only worked
>   for me, but the subsequent pull from simulated-B into
>   simulated-R said the TOPIC was a "(forced update)".
>   What does that mean?

The remote side B (and its mirror R) still points at the rightmost commit
on the lower side branch with TOPIC.  He forces a non-fast-forward push to
B using "+:" (that is "leading plus to force a push" followed by "solitary
colon to mean push matching refs"), violating a simple rule "do not rebase
what others already have seen".  Push from B to its mirror R then will be
in the same situation.

This may be a good food-for-thought:

    http://www.mail-archive.com/dri-devel@lists.sourceforge.net/msg39091.html

Incidentally the message explains why it would be bad if your
"now-and-then" above is too often.