Re: a few beginner git questions

From: Tait <git.git@t41t.com>
Date: Mar 6, 2010, 07:05 UTC
Message-ID: <20100306070533.GL2480@ece.pdx.edu>
In-Reply-To: <15b345f1003052242r7d812fe4q6ade253283696304@mail.gmail.com>

> 1. When do you commit changes and when do you stage changes?  Or maybe
> more to the point, what's the difference between doing "stage, commit,
> stage, commit" and "stage, stage, commit"?

Staging changes is a prerequisite to committing them. With stage, commit, stage, commit you will have two commits in history. With stage, stage, commit you will have only one commit in history. What you stage (or neglect to stage) is not part of recorded history in the repository. What you commit, is.

> 2. What's the difference between merging and pushing?  In CVS, you
> merge code by manually adding changes.  ie. the CVS client doesn't do
> the merging - you do.  Yet in Git Gui, there's a Merge menu button, as
> if it's now supposed to be somehow automated?

Merging is (sort-of) like merging in CVS. You are taking two separate lines (branches) on the history graph and combining them together. Unlike CVS, git keeps a record of the merge.

Push is simply copying changes in your local repository to another repository. What configuration you've set and what arguments you give to push control what gets copied.

> 3. Creating branches in Git Gui is easy enough but it's unclear to me
> how to switch back to the trunk once you've created a branch.

This depends on what you mean by "switch back". You can change the target
of your commits by using "git checkout".
	> git checkout master
	# Now new commits get added to the tip of master
	> git checkout -b newbranch
	# Now you created a new branch, "newbranch"
	# And you switched to it, so new commits are added
	# to newbranch instead of master
	> git checkout master
	# Now you're back on branch master and your commits
	# to newbranch aren't visible
	> git checkout newbranch
	# Back to newbranch again

If you meant "switch back" like "this branch is done, I'm going to stop working on it" then you can merge it back into master or some other branch, or leave it unmerged. Then you may wish to leave it rot or delete it, perhaps depending on whether you think you'll ever revisit that branch in the future (to fix a bug, maybe).

Show 7 quoted lines

> 4. I clone git://github.com/symfony/symfony.git to c:\git\test\root
> and clone that to c:\git\test\clone.	I then blank
> c:\git\test\clone\README, stage it, commit it and push it and the
> change does not appear in c:\git\test\root\README.  I then reopen Git
> Gui and open root and there I see the blanked README as an uncommited
> state change.  I commit it and the change still does not appear in
> c:\git\test\root\README.  Is this what Git should be doing?

You shouldn't push into a non-bare repository (unless you know what you're
doing and really mean it). This:
	http://git.wiki.kernel.org/index.php/GitFaq#Why_won.27t_I_see_changes_in_the_remote_repo_after_.22git_push.22.3F
explains a bit more on the subject.

Tait