Re: simple cvs-like git wrapper

["Shawn O. Pearce" <spearce@spearce.org>]

"Ed S. Peschko" <esp5@pge.com> wrote:
> 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.

Surely not every single code change impacts the database schema
and meaning of column values?  If that were truely the case then
I'd say you have bigger issues to tackle.

There's perfectly valid reasons a user (or several users) may go
off on a branch for a little while.  Like maybe they are working
together to refactor a chunk of front end user interface, to better
handle result sets >100 rows, something that wasn't anticipated
would ever happen when the system was first built.  It happens.
There may not be any database changes involved on that but it may
be distrubtive enough that you don't want to see their changes
until its mostly done.

I've been there, done that with Oracle and CVS.  Having Git makes
it a whole lot easier to go off on a side branch when refactoring
a chunk of UI, as you don't have to impact all of your coworkers
right away.
 
> 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). 

So, uh, mention the requirement using some sort of unique requirement
identifier in each commit message, and use a commit-msg hook to
make sure you didn't forget to include the requirement number.
We make links like that in our issue tracking system with "lpmNNNN"
keywords, where NNNN is the issue tracker number.

If you ever want to know what changes were done for a particular
requirement, pop open gitk and search for contains "soxNNNN", or use
`git log --grep=soxNNN`, and there's your list.
 
> 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.

I don't think you fully understand what git-merge does.  It retains
the full history of every individual change made along that branch,
as well as who performed the merge, and when.  Git also tracks if
the merge makes changes that weren't on either parent branch, and
correctly blames such changes to the individual who did the merge.
Most older SCMs are simply not able to do such detailed reporting.
Heck, some modern SCMs also can't do it.

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

Yea, git-merge is totally freaking automatic.  Except when there is
a conflict.  Then you have to fix up a few things.  But Git isn't
a mind reader (yet) so there will always be cases where it doesn't
quite do what you wanted it to without a little additional guidence.
 
> 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..

I think you are talking about `git ls-remote --heads url`.
 
>     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?

Yes, but why are you merging all of the available branches?
Why aren't you merging a single specific branch?  It seems very odd
to me that you want to merge every branch available.  I just cannot
see how that gives you any benefit over just having a single branch
called "master" that you rebase your changes onto before pushing
them, thus enforcing a mostly linear history.

Only linear history has its downsides.  It doesn't really quite show
you what the commits were developed against.  So it may be possible
that after a rebase the end result compiles and works, but an
earlier commit that used to work now doesn't, due to other changes.

If you are really worried about SOX requirements, I'd imagine you
are also worried about SOX auditing.  In which case I would think
that for most changes that are going to be part of your permenant
history don't want to use rebase, but instead merge, to show the
original history of every change.

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

One of my favorite ways to regression test every commit in a series
during a rebase is to use git-rebase -i:

	$ git rebase -i
	... editor opens ... which is vi ...
	:%s/^pick /edit /
	:wq

	... so now it stops between every patch ...
	$ while test -d .git/.dotest-merge; do \
	make clean test && git-rebase --continue || break; done

If anything breaks, you are right there on the broken change and
you can use `git show` to see it, `git commit --amend` to fix it up,
you can test the fix, and finally then continue the rebase to move
onto the next change.

I've got a 67 patch series I'm in the middle of doing at day-job
using that exact process.  Takes a few minutes per commit as our
build cycle is slow, but it works darn well.  I'm letting it run
overnight as I expect it to get about 70% through before it finds
a problem, if it is going to find one.

-- 
Shawn.