Push to all repositories

Will git let me push my changes to every member of the team?

I find a big problem with CVS & SVN is that I have to explicitly update my code in order to keep in sync. This is a real pain-point as I often have to do it several times a day and it can be very slow. We still regularly get problems caused by developers being out of sync. Most people become reluctant to do an update at all as they fear it will cause errors.

Clearcase has a great solution to this, "dynamic views". Whenever I check in some code, the whole team magically get's my changes straight away. Normally, they don't even notice, they're just forced to stay in sync. This drastically reduces the number of 'code conflicts' where people make changes to 'stale' files. This enforces the practise of "catching errors early". It also keeps developers "honest" as they have to keep the quality of their checkins high lest they get shouted at by the rest of the team.

Will git let a team stay in sync without everyone having to do manual updates? Basically, I want every developer to be able to push their code to the whole team.

Kevin Sheedy wrote:

What does this mean, in practice? Do you want (1) the code in their working directories to change under their feet, (2) the code you've written to be immediately available to them in case they pull out the network cable, or something else?

If case (2), then git currently provides support for fetching from multiple repositories at once:

	$ git fetch --multiple alice bob sam

but does not include such support for pushing. One can do so explicitly like so:

	$ for repo in alice blob sam
	  do
		git push $repo *:refs/remotes/kevin/*
	  done

Regards, Jonathan

I would like (1), have the code changed under my feet. Obviously, this would exclude my locally modified files. Also, a user could lock local files or turn off automatic updates altogether.

Clearcase dynamic views are a lovely way to collaborate with a team (despite their many technical problems). They remove the need to perform manual updates. Teams just stay in sync by default. There are fewer code collisions. Problems get spotted and fixed sooner. It you don't want something changed under your feet, that's supported too.

I guess the question is: "By default, do you want the latest code or not?" (This is similar to how the Google Chrome Browser defaults to giving you updates. When you're not looking, it just updates itself in the background. You just trust that it will use this power wisely, and it does.)

It could work something like this: Every time a repository is cloned, the location of the new clone would be added to the repository. When a user does a push, it gets pushed out to everyone repository on this list. Each user could retain total control over these updates.

Do you see any reason why this couldn't be added as an enhancement to git?

Cheers Kev

In summary, I think it would be cool if there was a programmatic way of saying: "Hey everybody, I've changed some code on branch x and I think you should have it"

Everyone else would then have the choices:
1) Always accept, I trust you (but don't blow away my current work,
obviously)
2) Always ignore, I'll get it when I'm good and ready

Kev

On Thu, Dec 9, 2010 at 7:36 PM, Kevin Sheedy <kevinsheedy@gmail.com> wrote:

See "update" hook in githooks man page. Add "pushall" alias for "for repo in..." from Jonathan's mail.

On Thu, Dec 9, 2010 at 7:36 AM, Kevin Sheedy <kevinsheedy@gmail.com> wrote:

I think the closest thing would be a cron job that runs "git pull" every minute or so. A difference from dynamic views is that it would no longer update your work tree once your changes start conflicting with the upstream changes (in dynamic views, all unmodified files would be updated).

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.

This is of course the easy case; just run "git pull" manually.

/Martin

Martin von Zweigbergk wrote:

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

* Jonathan Nieder <jrnieder@gmail.com> wrote:

Compared to git:

1. Clone repo and checkout the desired version
2. Fix a bug or add a feature and commit to your local branch
3. Do your tests and cleanups (eg. cleanups w/ interactive rebase)
3. Push your branch to some place others can catch it and
   announce it to others

Now another person wants to test your version:

1. Clone your repo and checkout your branch.
--> there is nothing that could fail to apply - everything's consistant
    by design (assuming the repo was cleanly cloned ;-o)
2. Possibly become an author yourself:
   a. rebase to a newer upstream version
   --> same as above

SVN has a quite bad idea of branches and isn't even near to support things like rebasing anyhow.

The idea of having everything in a big trunk is, aehm, quite suboptimal.
Better: have each issue in its own branch, that gets rebased to the
mainline frequently and merged back there when properly tested.

Well, many people tend to stick in old ideas (including workflows), no matter what newer developments are made. I currently have to cope with that in an customer project: most of the people here don't even consider using branches since the only vcs'es they know have no really usable support for this (TFS, etc ;-o), and they refuse to learn something new as long as their old way seems to work somehow (no matter of costs). I've estimated the productivity loss caused by sticking backwards cruft like TFS on factors of 5..10 - nobody cares. (actually, not really bad for me: the longer it takes, the more money I earn ;-P)

cu

* Kevin Sheedy <kevinsheedy@gmail.com> wrote:

Hi,

Are you sure you *really* want this ? I'd strongly advise against that.

Better have some central branch (maybe on a dedicated remote) where everybody can push to, and the others fork off from there and frequently rebase or merge if they like.

My preferred workflow is to have per-issue branches (eg. per bug, per feature, etc), which frequently get rebased to the mainline and are only pushed upwards if they're finished (IOW: only one person is actively working on an small issue at a time, others may just read but dont write). Once some issue branch seems to be ready, it gets rebased to latest master and cleaned up, others might do some reviews and if it passed all tests (and only then!) it gets pushed upwards.

cu