git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: "Ed S. Peschko" <esp5@pge.com>
To: git@vger.kernel.org
Subject: simple cvs-like git wrapper
Date: Tue, 29 Jan 2008 12:40:48 -0800	[thread overview]
Message-ID: <20080129204048.GA9612@venus> (raw)

hey all,

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.


Hence, I was hoping that people could suggest ways of 
simplifying git, making a cvs-like frontend for people to use. 

I was thinking of something like this:

gvs branch <branch name>: 

	creates a branch for people to start making edits on in their
	localized copy.

gvs commit:

	commits that branch to a centralized git repository.

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. 

gvs list:

	lists all the branches that have been merged into the current
	workspace.


In other words, what I'm looking for is sort of 'cvs+'.  Instead of
working on one, synchronized branch as per cvs, we want to work on several,
parallel, branches that synchronize on intervals.

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.

Anyways, hope this makes sense. I'm not sure how feasible the above is - 
it's meant to be as simple it can be, with as much DWIM-ness as possible.  
Any feedback is appreciated.


Ed

(
ps - We could just use CVS of course, but that's just too simple, 
with no easy way of managing which change goes along with which 
feature request... 
)

             reply	other threads:[~2008-01-29 21:24 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-01-29 20:40 Ed S. Peschko [this message]
2008-01-29 22:28 ` simple cvs-like git wrapper Jakub Narebski
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=20080129204048.GA9612@venus \
    --to=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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).