Push to all repositories

Push to all repositories

[Kevin Sheedy]

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.
-- 
View this message in context: http://git.661346.n2.nabble.com/Push-to-all-repositories-tp5816069p5816069.html
Sent from the git mailing list archive at Nabble.com.

Re: Push to all repositories

[Jonathan Nieder]

Kevin Sheedy wrote:

> Basically, I want every developer to be able to push their code to the whole
> team.

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

Re: Push to all repositories

[Kevin Sheedy]

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
-- 
View this message in context: http://git.661346.n2.nabble.com/Push-to-all-repositories-tp5816069p5817177.html
Sent from the git mailing list archive at Nabble.com.

Re: Push to all repositories

[Kevin Sheedy]

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
-- 
View this message in context: http://git.661346.n2.nabble.com/Push-to-all-repositories-tp5816069p5818757.html
Sent from the git mailing list archive at Nabble.com.

Re: Push to all repositories

[Nguyen Thai Ngoc Duy]

On Thu, Dec 9, 2010 at 7:36 PM, Kevin Sheedy <kevinsheedy@gmail.com> wrote:
>
> 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"

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

Re: Push to all repositories

[Martin von Zweigbergk]

On Thu, Dec 9, 2010 at 7:36 AM, Kevin Sheedy <kevinsheedy@gmail.com> wrote:
>
> 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)

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.

> 2) Always ignore, I'll get it when I'm good and ready

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



/Martin

Re: Push to all repositories

[Jonathan Nieder]

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

Re: Push to all repositories

[Enrico Weigelt]

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

Hi,

> 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.

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
-- 
----------------------------------------------------------------------
 Enrico Weigelt, metux IT service -- http://www.metux.de/

 phone:  +49 36207 519931  email: weigelt@metux.de
 mobile: +49 151 27565287  icq:   210169427         skype: nekrad666
----------------------------------------------------------------------
 Embedded-Linux / Portierung / Opensource-QM / Verteilte Systeme
----------------------------------------------------------------------

Re: Push to all repositories

[Enrico Weigelt]

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

> 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.

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

> 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

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

> 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.

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.

> 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").

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
-- 
----------------------------------------------------------------------
 Enrico Weigelt, metux IT service -- http://www.metux.de/

 phone:  +49 36207 519931  email: weigelt@metux.de
 mobile: +49 151 27565287  icq:   210169427         skype: nekrad666
----------------------------------------------------------------------
 Embedded-Linux / Portierung / Opensource-QM / Verteilte Systeme
----------------------------------------------------------------------