From: Jakub Narebski <jnareb@gmail.com>
To: "Ed S. Peschko" <esp5@pge.com>
Cc: git@vger.kernel.org
Subject: Re: simple cvs-like git wrapper
Date: Tue, 29 Jan 2008 14:28:02 -0800 (PST) [thread overview]
Message-ID: <m3hcgw8dz7.fsf@localhost.localdomain> (raw)
In-Reply-To: <20080129204048.GA9612@venus>
"Ed S. Peschko" <esp5@pge.com> writes:
> We've been trying out git here for a while now, and we've noticed two
> things that we both like and dislike: git's flexibility, and git's
> flexibility.
>
>
> Git's flexibility is great in the sense that power users can basically
> bend git to their will, but its' flexibility is also causing workflow
> issues in our environment, where beginning users can get lost in all
> the options that it has, and this is causing communication issues for
> these folks with the rest of our team.
[...]
> gvs update:
>
> Takes the latest changes, from all branches, that everyone
> else has committed into the centralized git repository, and merges
> them onto the current branch.
[...]
> We basically want this for managing related changesets - we want
> to be able to switch from one patch branch to another and commit them
> separately - but we don't want to sacrifice the automatic integration
> that you get from cvs by doing:
>
> cvs update
>
> on a given branch.
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.
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).
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
next prev parent reply other threads:[~2008-01-29 22:28 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-01-29 20:40 simple cvs-like git wrapper Ed S. Peschko
2008-01-29 22:28 ` Jakub Narebski [this message]
2008-01-30 2:10 ` Ed S. Peschko
2008-01-30 4:00 ` Shawn O. Pearce
2008-01-30 22:52 ` Ed S. Peschko
2008-01-31 4:08 ` Shawn O. Pearce
2008-01-31 5:41 ` Ed S. Peschko
2008-01-31 6:01 ` Shawn O. Pearce
2008-01-31 6:17 ` Junio C Hamano
2008-01-30 19:49 ` Daniel Barkalow
2008-02-01 13:05 ` Kate Rhodes
2008-02-01 13:25 ` Johannes Schindelin
2008-02-01 15:35 ` Jakub Narebski
2008-02-01 7:29 ` Uwe Kleine-König
2008-02-01 9:58 ` Jakub Narebski
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=m3hcgw8dz7.fsf@localhost.localdomain \
--to=jnareb@gmail.com \
--cc=esp5@pge.com \
--cc=git@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.