threads / discuss / 5885

core-git and porcelains

Subject: core-git and porcelains

## tl;dr

7 messages between Oct 11, 2006 and Oct 11, 2006.

replies: 6people: 4as markdown or json

Pazu· Oct 11, 2006, 14:39 UTC · lore

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

Shawn Pearce· Oct 11, 2006, 15:08 UTC · re: Pazu · lore

Re: core-git and porcelains

Pazu <pazu@pazu.com.br> wrote:

Show 25 quoted lines

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

Pazu· Oct 11, 2006, 16:45 UTC · re: Shawn Pearce · lore

Re: core-git and porcelains

Shawn Pearce wrote:

Show 6 quoted lines

> 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

Shawn Pearce· Oct 11, 2006, 16:54 UTC · re: Pazu · lore

Re: core-git and porcelains

Pazu <pazu@pazu.com.br> wrote:

Show 12 quoted lines

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

Pazu· Oct 11, 2006, 17:13 UTC · re: Shawn Pearce · lore

Re: core-git and porcelains

Shawn Pearce wrote:

Show 5 quoted lines

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

Show 6 quoted lines

> 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

Seth Falcon· Oct 11, 2006, 17:01 UTC · re: Shawn Pearce · lore

Re: core-git and porcelains

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

Robin Rosenberg· Oct 11, 2006, 18:08 UTC · re: Pazu · lore

Re: core-git and porcelains

onsdag 11 oktober 2006 16:39 skrev Pazu: [...]

Show 6 quoted lines

> 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