Re: Push to all repositories

[Jonathan Nieder <jrnieder@gmail.com>]

Martin von Zweigbergk wrote:

> However, rather than trying to make Git behave just like ClearCase
> dynamic views (there are many other things to consider than automatic
> updates), I think you would be better off if you actually use
> ClearCase dynamic views instead.

Yes.  Or a network filesystem + unionfs.  Or a wiki.

The part I did not mention is why git does not work this way out of
the box.  It has something to do with the nature of projects it has
been used on traditionally (computer programs that occasionally undergo
global changes in API).

Consider a project in a patches+tarballs workflow.  It begins like
this:

 1. Acquire a tarball with the version you want to base your work on.
 2. Untar.
 3. Copy the result to save the current state.
 4. Test it.
 5. Fix a bug or add a feature.
 6. Make a patch with "diff -pruN"
 7. Return to step 3.
    ...
 8. Looks good; email out the patches to get some feedback.

Now another person wants to test the patches; so she tries:

 1. Acquire a tarball with the version you want to test against.
 2. Untar.
 3. Apply patches with "patch -p1".

Wait a second --- the patches don't apply!  Or worse, they
apply but the result is broken.  Okay:

 4. Complain to the patch author.

Finally the patch author has more work to do:

 9. Acquire a newer tarball, and use either "patch --reject-file"
    or rcs "merge" to reconcile the differences.  Email out the
    result.

The result is a sequence of snapshots that have been _tested_ to work
correctly.  Now compare the svn workflow I briefly used at work:

 1. svn update
 2. hack hack hack
 3. svn update
 4. hack hack hack
 5. svn update
 6. hack hack hack
 7. send out a patch for feedback

Now another person wants to test the patch.  So she tries:

 1. svn update
 2. Apply patch with "patch -p1".

The result applies okay and works great.  So:

 8. svn update
 9. ... test ...
 10. svn commit

Unfortunately, the version committed (1) does not reflect the
development history and (2) is not even tested, if changes
happened in trunk between step 9 and step 10.

That is, letting projects briefly diverge from upstream

 - avoids unnecessary interruptions to work;

 - allows the development history to be published, even when that was
   "first write some code, then tweak it to match the new API";

 - increases the likelihood that each commited revision actually
   works, making later mining for the code that introduced a feature
   or bug ("git bisect") much easier.

Of course in the opposite direction is

 - changes to workflow can be hard for a team to adjust to

(i.e., "don't fix what isn't broken").

Sorry, that ended up more longwinded than I hoped.  Still,
hope that helps.

Regards,
Jonathan