Re: simple cvs-like git wrapper

["Ed S. Peschko" <esp5@pge.com>]

> One thing (besides horrible branching and even worse merging)  which I
> hated in multi-user CVS is the "cvs update", namely the fact that if
> you want to commit changes, you _have_ to rebase them on top of
> current work. So when you are ready to commit, when you have tested
> everything, you are sometimes forced to resolve a merge to be able to
> commit... and have to test resolved merge... and perhaps again, and
> again.

Yeah, I realize that it's not exactly the best solution for every
project, but for projects tied to a piece of hardware (ie: a database, a
particular box, etc), its much more important to be in sync, to have 
'one true view' of the world rather than to have the freedom to have 
multiple views.

In our case, our code is tied to a database and a database instance. An
environment equals attachment to a given oracle SID. If someone is out of sync
with other people's changes, then that person's environment is wrong.


> Working on branches is much nicer IMVHO. And it allows to separate
> changes into series of small, incremental commits[*1*]. If you want to
> work in centralized or semi-centralized way, you probably would want
> to use rebase based workflow, with "git pull --rebase" (which just got
> implemented).


I agree with you, however, with the working on branches. We need the 
ability to do the small incremental commits, and then tie them back to
SOX requirements (bleah). 

Hence the hope for the automatic merging along with a given branch - that, 
when you do an 'gvs update', it takes all the outstanding deltas on all the
branches that have been uploaded into the central repository, and applies 
them, one by one, to your local repository, and keeps the branch intact.

That it basically does the perfect patch series functionality you are
talking about, but in an automatic way..


A couple of questions:

	1. How do you get a list - on a shared, remote, repository - of all the 
       branches that a shared repository contains, from the point of
	   view of a client? ie: git-branch shows local branches..

    2. Could the above 'gvs update' be implemented in terms of a series 
	   of 'git pull --rebase' or even 'git pull' merges from the
	   centralized repository based on the output from the command 
       above?

Anyways, I wouldn't mind it if 'gvs update' paused at the end of
each merge - that you'd do a 'gvs update', it would show you exactly what
was going to merge before it did it (maybe even via a vimdiff of old and 
new side by side), and would allow you to do a regression test after
each patchset was applied..

After all, it's my wrapper so I'll implement it the way I like it.. ;-)

Thanks,

Ed


> 
> Footonotes:
> ===========
> [*1*] I'd like to point to LKML post about creating perfect patch
> *series*, but I have forgot to bookmark it, and canot find it again
> (IIRC somebody posted link some time ago here on git mailing list).
> 
> -- 
> Jakub Narebski
> Poland
> ShadeHawk on #git