> 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
-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
