core-git and porcelains

core-git and porcelains

[Pazu]

I'm a newcomer to git, and for the last few days, I've been struggling 
to learn how to better use git in my day to day. One particular thing 
that has been puzzling me is how much git is self-sufficient, and how 
much I should depend on porcelains.

Apparently, I'm not alone in this: 
http://thread.gmane.org/gmane.comp.version-control.git/6194/focus=6194

The above post was made about three months ago; where things stand now? 
Do you feel that git-core should suffice for most developers, or should 
I really look into something like Cogito?

Depending on the project, my git usage would fit one of two profiles. I 
run some standalone projects, where I'm the sole developer. I was 
looking into using cogito for this scenario, but one thing that baffled 
me is how git-core and cogito use different branch representations.

For the larger part of my day, however, I'm looking into using git as a 
personal tool in a very large corporate project; This project is 
currently controlled using subversion, and my idea is to use git as a 
'staging' system, where I work (possibly offline) before pushing changes 
to the upstream (remote, slow as hell) subversion repository. Here, 
git-svn seems to be my best friend.

Any advice to this poor newbie?

-- Marcus

Re: core-git and porcelains

[Shawn Pearce]

Pazu <pazu@pazu.com.br> wrote:
> I'm a newcomer to git, and for the last few days, I've been struggling 
> to learn how to better use git in my day to day. One particular thing 
> that has been puzzling me is how much git is self-sufficient, and how 
> much I should depend on porcelains.
> 
> Apparently, I'm not alone in this: 
> http://thread.gmane.org/gmane.comp.version-control.git/6194/focus=6194
> 
> The above post was made about three months ago; where things stand now? 
> Do you feel that git-core should suffice for most developers, or should 
> I really look into something like Cogito?
> 
> Depending on the project, my git usage would fit one of two profiles. I 
> run some standalone projects, where I'm the sole developer. I was 
> looking into using cogito for this scenario, but one thing that baffled 
> me is how git-core and cogito use different branch representations.
> 
> For the larger part of my day, however, I'm looking into using git as a 
> personal tool in a very large corporate project; This project is 
> currently controlled using subversion, and my idea is to use git as a 
> 'staging' system, where I work (possibly offline) before pushing changes 
> to the upstream (remote, slow as hell) subversion repository. Here, 
> git-svn seems to be my best friend.
> 
> Any advice to this poor newbie?

I would just stick with core Git.  I haven't used Cogito in almost
a year so I can't say what I'm missing there, but core Git works
very well for all of my needs.  I use it in a lot of different
projects, some which require git-svn, others which require some
bastard git-svn-workalike for non-SVN systems, and others which
are just Git projects and don't have to cooperate with others.

Git has come a long way in terms of user interface.  It still has a
few rough edges but I think that there are less rough edges on core
Git's command line user interface than there are on the Subversion
command line client or the CVS command line client.

-- 
Shawn.

Re: core-git and porcelains

[Pazu]

Shawn Pearce wrote:

> I would just stick with core Git.  I haven't used Cogito in almost
> a year so I can't say what I'm missing there, but core Git works
> very well for all of my needs.  I use it in a lot of different
> projects, some which require git-svn, others which require some
> bastard git-svn-workalike for non-SVN systems, and others which
> are just Git projects and don't have to cooperate with others.

Thanks for the advice, Shawn. Would you mind expanding on how you work 
with git-svn, however? Specially, how's your everyday work, and how do 
you deal with multiple upstream branches.

-- Marcus

Re: core-git and porcelains

[Shawn Pearce]

Pazu <pazu@pazu.com.br> wrote:
> Shawn Pearce wrote:
> 
> >I would just stick with core Git.  I haven't used Cogito in almost
> >a year so I can't say what I'm missing there, but core Git works
> >very well for all of my needs.  I use it in a lot of different
> >projects, some which require git-svn, others which require some
> >bastard git-svn-workalike for non-SVN systems, and others which
> >are just Git projects and don't have to cooperate with others.
> 
> Thanks for the advice, Shawn. Would you mind expanding on how you work 
> with git-svn, however? Specially, how's your everyday work, and how do 
> you deal with multiple upstream branches.

I don't use multiple upstream branches in SVN fortunately, but the
git-svn documentation suggests there is a way to change the Git
branch name from 'refs/remotes/git-svn' to another name such that
you can create one Git branch for each remote SVN branch.  Of course
you need to set that environment variable before invoking git-svn.

As for my daily work with git-svn, I run "git svn fetch" to fetch any
changes that had occurred in SVN along the branch I follow, then if
any changes did exist I merge them into my Git working branch with
"git pull . refs/remotes/git-svn".  When I'm ready to send stuff
back up to SVN I do "git svn dcommit refs/remotes/git-svn..master",
where master is the name of the Git branch I want to send.

-- 
Shawn.

Re: core-git and porcelains

[Seth Falcon]

I second Shawn's suggestion to stick with core Git.  I have similar
uses as you describe: projects where I'm the lone developer and using
git to help track projects that use svn.

+ seth

Re: core-git and porcelains

[Pazu]

Shawn Pearce wrote:

> I don't use multiple upstream branches in SVN fortunately, but the
> git-svn documentation suggests there is a way to change the Git
> branch name from 'refs/remotes/git-svn' to another name such that
> you can create one Git branch for each remote SVN branch.  Of course
> you need to set that environment variable before invoking git-svn.

I was reading git-svn documentation and just found about multi-init. 
Seems like you're describing, execept that no branch get init'ed as the 
"default" branch, and you always need to specify the the branch name 
before doing a fetch/dcomic/etc. I hope this works for me -- I'll need 
to switch between two or three remote branches quite frequently.

> As for my daily work with git-svn, I run "git svn fetch" to fetch any
> changes that had occurred in SVN along the branch I follow, then if
> any changes did exist I merge them into my Git working branch with
> "git pull . refs/remotes/git-svn".  When I'm ready to send stuff
> back up to SVN I do "git svn dcommit refs/remotes/git-svn..master",
> where master is the name of the Git branch I want to send.

Sounds a lot like what I do today with svk. If git works for me just as 
good as svk, the speed increase alone will make the switch worth.

-- Marcus

Re: core-git and porcelains

[Robin Rosenberg]

onsdag 11 oktober 2006 16:39 skrev Pazu:
[...]
> For the larger part of my day, however, I'm looking into using git as a
> personal tool in a very large corporate project; This project is
> currently controlled using subversion, and my idea is to use git as a
> 'staging' system, where I work (possibly offline) before pushing changes
> to the upstream (remote, slow as hell) subversion repository. Here,
> git-svn seems to be my best friend.

I work against a CVS repo in the way you want to use SVN and I find StGIT
to be a perfect fit for my needs. StGIT's doesn't replace GIT's command so I 
use StGIT for it's patch management and the standard git commands for the 
rest.  I can't see that working agains SVN should be any different, except 
the git-svn* vs git-cvs commands.  

The GIT commands aren't that hard to understand. The difficulty is to know 
which commands to use.  I use these commands

stg init, new, add, remove push, pop, refresh, status, pull, goto, diff (and a 
new command float that I wrote which simplified some pop-push sequences)

git log push, diff

In addition I use qgit for browsing when git log isn't comfortable enough and 
occasionally the standard patch command.

-- robin