COmanage Developers List

[Steve Olshansky <>]

Thanks for the use cases, very helpful. I will request it and keep you posted.
        /s

On Jun 11, 2012, at 10:01 AM, Heather Flanagan wrote:

> Hi SteveO -
> 
> I'm a bit behind on this request, but you and I did chat about it very 
> briefly at the I2 meeting and you suggested I send this on to you.  The 
> COmanage dev team would like to know if TSG would be willing to consider 
> putting up a git repository.  We have several use cases describing how git 
> would be make things flow more smoothly for us, listed below.  This is not 
> an urgent request; we do have work around's.  But if it is something they'd 
> be willing to consider or if they've had anyone else request such a thing, 
> we'd like to add our voice to the desire for a git hub.
> 
> 
> ----
> Use case 1 (from Scott Koranda)
> 
> So I just edited CoPeopleController.php to address CO-242 and I
> have sent you a diff and am waiting for you to comment.
> 
> In the meantime to work efficiently I am moving onto CO-231.
> 
> Investigating that bug, however, requires I edit
> CoPeopleController.php.
> 
> I don't want to edit that file since I have a pending commit
> based on it. So I can either make a svn branch (a very costly
> operation and I have to follow a policy we have all agreed
> upon) or I can move the file out of the way and hope I save it
> and remember later to put in the "right" version before I
> commit it.
> 
> If, however, we were using git then my workflow would be
> 
> git branch CO-242
> git checkout CO-242
> make edits
> git add
> git commit
> git diff
> 
> send diff to Benn
> 
> git checkout master
> git branch CO-231
> git checkout CO-231
> 
> investigate new bug
> 
> get email from Benn saying go ahead and commit
> 
> git stash
> git checkout master
> git merge CO-242
> git push
> git checkout CO-231
> git stash pop
> 
> keep working away on CO-231
> 
> The branches would all be *local* and not bother you or Marie
> and I would not have to worry at all about what I want to name
> them. I can keep them around forever if I want, or blow them
> away.
> 
> In the time it has taken me to compose this email I would have
> already gone through most of the proposed git workflow...
> 
> -----
> Use Case 2 (from Scott Koranda)
> We need as developers to update core.php in order to turn on
> debugging, yet we never want to commit such changes to the
> repository. Subversion has no easy way to "ignore that file
> and its changes for now".
> 
> With git it is easy:
> 
> $ git update-index --assume-unchanged Config/core.php
> $ git status
> # On branch master
> nothing to commit (working directory clean)
> 
> No danger of my locally edited version of core.php being
> committed to the repository now.
> 
> ----
> Use Case 3 (from Benn Oshrin)
> svn makes it really hard to get revision history when a file is
> deleted. We deleted a *lot* of files for Cake 2 (eg:
> foo_controller.php became FooController.php).
> 
> Using git, however:
> 
> git log --follow -- foo
> 
> will show the history for the file 'foo' even if it has since
> been renamed to Foo, or if it has been deleted from the
> repository (or both).
> 
>

Attachment: smime.p7s
Description: S/MIME cryptographic signature