Copyright 2004 by M. Uli Kusterer Fri, 29 Nov -1901 11:06:32 GMT Comments on article blog-so-git at Zathras.de http://www.zathras.de/angelweb/blog-so-git.htm blog-so-git Comments witness_dot_of_dot_teachtext_at_gmx_dot_net (M. Uli Kusterer) witness_dot_of_dot_teachtext_at_gmx_dot_net (M. Uli Kusterer) en-us Comment 7 by Rafael Bugajewski http://www.zathras.de/angelweb/blog-so-git.htm#comment7 http://www.zathras.de/angelweb/blog-so-git.htm#comment7 Rafael Bugajewski writes:


Like other already told you, Git should handle renames even if you do not rename via the Git command.


Comment 6 by Vincent Driessen http://www.zathras.de/angelweb/blog-so-git.htm#comment6 http://www.zathras.de/angelweb/blog-so-git.htm#comment6 Vincent Driessen writes:
Hi there Uli,

If you are just starting with Git, you probably don't see the use of the staging area (the index), but as your usage of Git is getting more advanced, you will start appreciating it to tailor your commit together exactly as you want it before actually committing. Especially, the use of git add -p is a blessing.

If you are still looking for a Git workflow for bringing forth your software releases, you might find a write-up I did about a month ago on our successful branching strategy interesting. It's available at http://nvie.com/archives/323

Cheers,
Vincent
Comment 5 by Patrick Stein http://www.zathras.de/angelweb/blog-so-git.htm#comment5 http://www.zathras.de/angelweb/blog-so-git.htm#comment5 Patrick Stein writes:
git remote add --help

I use different remotes for the different backup systems. I

git push

for my default server. And

git push gitmasterbackup

to my backupserver for example.

About the two/three phase commit push. I do think it's worth it to first ensure locally that the commit went through ( maybe you have a git commit hook ) and then use the push and see what errors might happen there. Btw. on the commandline it's usually a four step move for me.

git status
git add -A / git add -u / git add filename
git commit -m
git push

I wonder if you can create a git commit hook to push it after commiting. Then a git commit -am would suffice.

Regards - Patrick Stein

---
author of: ScreenRecycler, JollysFastVNC, SmartSleep, SmartSokoban and more.
Comment 4 by Colin Wheeler http://www.zathras.de/angelweb/blog-so-git.htm#comment4 http://www.zathras.de/angelweb/blog-so-git.htm#comment4 Colin Wheeler writes:
you can do git commit -a -m 'commit msg' to both stage all the (tracked) files and then commit them. I usually just do 'git commit -a -m 'msg'' then 'git push origin master' periodically. You've got to remember that with git you have control over all the commits and can fix/ammend them before pushing to a public location (so it looks like you write perfect code all the time.)

the stage/commit/push is a workflow that's been accepted as common practice in DVCS's. In git's case that it there to give you full control over what gets comitted every time vs commiting all changes every time.

git will catch name changes since it's tracking content & not files. It'll auto discover that there is a new file with the content of part of it's last tree and if you commit from the terminal it'll just say 'renaming old.m => new.m'

on github you fork a project and can commit to it like crazy. Github has it's own mechanisms on the page where you can request that Andy (the sparkle owner) can pull your changes and merge it into his and then you can pull his changes. Github has some info on this ( http://help.github.com/forking/ .) They have the mechaisms on their page to easily do all of this without going to the command line.

if you need more help this is a great site for git rescources http://gitready.com/
Comment 3 by Ron http://www.zathras.de/angelweb/blog-so-git.htm#comment3 http://www.zathras.de/angelweb/blog-so-git.htm#comment3 Ron writes:
Some answers to your questions above - hopefully they're helpful.

* I usually do things in the 3 stages you mention in question one, however if I'm making a quick change that I know I want pushed, I will simply do a git commit -am "some comment" and then push. Still two steps, but less than 3.
* Git will show you what files you renamed, even in finder. I just ran a test where I renamed one file to another name. I added the file of the new name (build.xml -> ron.xml - added ron.xml after git told me it was deleted). Running git diff -M HEAD^ after commit shows me the following:

git diff -M HEAD^
diff --git a/build.xml b/ron.xml
similarity index 100%
rename from build.xml
rename to ron.xml

So it looks like git will tell you what was renamed, but there is still a manual add that is required and you have to tell it to tell you.

For #3, set up an account on Github and go to http://github.com/andymatuschak/Sparkle. You'll see a 'fork' button at the top of the screen. When you press it, you'll have your own sparkle repository. You can then clone it locally, work on branches there, and when you are done push it to your github repository. You can then send the author a 'pull request' to pull your changes from your public github repository.

Hope this helps.
Comment 2 by Pieter http://www.zathras.de/angelweb/blog-so-git.htm#comment2 http://www.zathras.de/angelweb/blog-so-git.htm#comment2 Pieter writes:
In the command line, you can do 'git commit -am"message"' to commit all changes, and then push those, which makes it 2 steps instead of 3.

If you want to blame a file that has been renamed or contains code from another file, try git blame -M or git blame -C -M, which turns on rename detection. Renames in Git are done with heuristics rather than explicitly in the commits.

You can add multiple remotes, by defoult the 'origin' remote will be used. So if you have your own sparkle branch as origin, add the official repository with something like 'git remote add sparkle git@github.com:sparkle/sparkle.git', then you can push to that with 'git push sparkle'. If you do 'git push', it'll push to origin, which is your own branch of sparkle.

You can also add something like this in your ~/.gitconfig:

[url "git://github.com/"]
insteadOf = "gh:"
[url "git@github.com:"]
insteadOf = "ghp:"

then you can push to private repositories by using something like 'git push ghp:sparkle/sparkle.git' or pull from other repositories by using something like 'git pull gh:pieter/gitx.git master', which saves you a few characters :)
Comment 1 by Anthony Mittaz http://www.zathras.de/angelweb/blog-so-git.htm#comment1 http://www.zathras.de/angelweb/blog-so-git.htm#comment1 If I do my own branch of, e.g. Sparkle, how would I set up a repository to always push to my own github account, but let me push to the Sparkle repository when I think the changes are ready for general consumption? Ideally without re-typing the URL constantly?

-- You can add another remote to your repository that point to the main Sparkle repository, you can then decide to push to this remote when changes should be made on the main Sparkle repository, if not you still push to your personal repository using a standard push (push origin master) compared to (push origin (name given to the main Sparkle repo, when adding it with git remote add mainSparkl GIT_URL)