a few beginner git questions

a few beginner git questions

[Thomas Anderson]

A few questions.

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"?

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?

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.

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?

Re: a few beginner git questions

[Allan Wind]

On 2010-03-06T00:42:40, Thomas Anderson wrote:
> 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"?

The former gives you one commit and the latter two comments.  
Staging (git add) is local while commits can shared with others 
(git push).

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

pushing is how you copy the data to another repository while 
merging is integrating multiple versions in into a single new 
version.

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

git checkout master (which is the default name for "trunk")

<http://git.wiki.kernel.org/index.php/GitFaq#How_do_I_access_other_branches_in_a_repository.3F>

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

<http://git.wiki.kernel.org/index.php/GitFaq#Why_won.27t_I_see_changes_in_the_remote_repo_after_.22git_push.22.3F>


/allan
-- 
Allan Wind
Life Integrity, LLC
<http://lifeintegrity.com>

Re: a few beginner git questions

[Tait]

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

> 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

Re: a few beginner git questions

[Thomas Anderson]

On Sat, Mar 6, 2010 at 1:05 AM, Tait <git.git@t41t.com> wrote:
>> 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.

What's the difference, then, between doing "stage, stage, commit" as
opposed to "stage, commit"?  Why not just make all commits stage
automatically?

Re: a few beginner git questions

[Dmitry Potapov]

On Sat, Mar 06, 2010 at 08:23:18PM -0600, Thomas Anderson wrote:
> 
> What's the difference, then, between doing "stage, stage, commit" as
> opposed to "stage, commit"?

Probably none... If you stage twice the exactly same file, it does not
change anything. But if you "stage, stage" means to stage two different
files while "stage" is to stage just one then the outcome will be
different.

> Why not just make all commits stage automatically?

The goal of the stage area is to mark what changes you want to commit.
So, one commit will contain only one semantic change and not everything
what you have in your working tree at that moment. CVS also allows to
not commit all changes at the same time (you can specify what files to
commit in the command line), but with Git you can not only to choose
what files but also what change in each file you want to commit now.
More importantly, git allows you to look at the stage area and see what
you are going to commit.

In simple cases, you can just do "git commit -a" which means to commit
all changes for all tracked files or "git commit somefile" to commit
changes only in "somefile".


Dmitry

Re: a few beginner git questions

[Thomas Anderson]

On Sat, Mar 6, 2010 at 1:05 AM, Tait <git.git@t41t.com> wrote:
>> 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.

How, then, do I update code?  ie. I perform my initial clone, make
some changes and commit / push them.  Someone else then comes along,
makes some changes and commits them.  The next day, I do Remote ->
Fetch from -> origin to update my code to the latest in Git but
c:\git\test\clone\README is exactly the same as it was before.  How do
I update the initial clone such that I can edit the updated files?

Re: a few beginner git questions

[Dmitry Potapov]

On Sat, Mar 06, 2010 at 11:02:20PM -0600, Thomas Anderson wrote:
> 
> How, then, do I update code?  ie. I perform my initial clone, make
> some changes and commit / push them.  Someone else then comes along,
> makes some changes and commits them.  The next day, I do Remote ->
> Fetch from -> origin to update my code to the latest in Git but
> c:\git\test\clone\README is exactly the same as it was before.  How do
> I update the initial clone such that I can edit the updated files?

There are a few ways to do that. It depends on what you actually wants.

First of all, you can merge 'origin/master' (or whatever its name).
If you do not have any local commit then merge will just fast-forward
your branch to the same point. However, if you do have changes, then
it will create a new merge commit. If you have many such merge commits,
it can make the upstream unhappy, because your changes are intervene
with merges, so it is more difficult to inspect your actual changes.

Another option is to rebase your changes on top of the 'origin/master'.
Rebasing your changes on top origin/master is more close to what happens
when you do 'cvs update' does, except that in git you rebase committed
changes, so if something goes wrong during this process, you can abort
and redo it again. So, all your work will not be lost. The advantage of
'rebase' is that you have a clean and linear history. The disadvantage
is that you re-write all your commits, so you should not do that on
"published" history. Also, re-writing may introduce a problem even if
rebased had no conflict. While merge may also produced a non-working
result, 'merge' preserves the original history while rebase produces a
new one, which is not tested. So, I would not recommend to rebase any
long series of patches or anything non-trivial unless it is absolutely
necessary.

Finally, a typical workflow with Git is to use feature branches. You
create a new branch to implement some feature, do all your work on it
(without any "update") and then merge it to the upstream (either you
merge and push the result or send a pull request to the maintainer).
After your changes have been merged, you just delete this branch. For
each new work, you start a new branch from the current origin/master.


Dmitry

Re: a few beginner git questions

[Tait]

> How, then, do I update code?  ie. I perform my initial clone, make
> some changes and commit / push them.  Someone else then comes along,
> makes some changes and commits them.  The next day, I do Remote ->
> Fetch from -> origin to update my code to the latest in Git but
> c:\git\test\clone\README is exactly the same as it was before.  How do
> I update the initial clone such that I can edit the updated files?

As Dmitry already said, you can either merge in the upstream changes,
or rebase your own changes on top of the upstream changes. I usually
rebase.

Here's my typical workflow. It may not be elegant, but it works well
for me. Hopefully it's useful for you, because understanding workflow
was one of the most intimidating parts of learning git for me.

git pull   # equivalent of git fetch + git merge
           # ... my local master is always clean; this is a fast-forward
git checkout -b exp_smoothing 
           # create a new branch to work
vi         # start making my intended changes
git add    # stage my changes
vi         # make some more changes I don't want to commit, like enabling 
           # debug, bypassing some uninteresting code, etc.
gcc        # oops, there were syntax errors
vi
git add    # to stage just the relevant fixes (or git add -p)
git commit # save my progress
run        # discover some things to fix
...        # repeat the bit from gcc to here many times over
run        # It works ..  maybe it's a few days since I started
           # By now, my history is an ugly mess
git rebase -i exp_smoothing^
           # I re-order, combine, and split commits
           # When I'm done, the history is neat and logical
git checkout master
           # switch back to master (which is still clean)
git pull origin
           # get any updates from the last couple days
           # there will be no conflicts; it's a fast-forward

My history looks like this:

               exp_smoothing branch
              |-- a <-- b <-- c <-- d
              v
master: Z <-- Y <-- X <-- W <-- V

Before switching back to master and doing pull, I only knew about Z
and Y, and in my own local repository, I added a, b, c, d, which are
the cleaned-up version of my exp_smoothing development. When I did
a git pull, I incorporated X, W, and V.

Picking up with the workflow again...

git checkout exp_smoothing
           # back to my work-in-progress branch
git rebase master
           # replay exp_smoothing on top of the new master (now 
           # at V instead of Y)
           # resolve conflicts, if X, W, V conflict with a, b, c, d

History is now:
                         exp_smoothing branch
                        |-- a' <-- b' <-- c' <-- d'
master:                 v
Z <-- Y <-- X <-- W <-- V

git checkout master
git merge exp_smoothing
           # because I resolved all the conflicts during the rebase
           # this should merge conflict-free, as a fast-forward.
git push origin
           # publish my changes (to master) for the rest of the world
git branch -d exp_smoothing
           # exp_smoothing is merged into master; no need to keep it 
           # around anymore

The last four steps occur very quickly. The final history is:

master: Z <-- Y <-- X <-- W <-- V <-- a' <-- b' <-- c' <-- d'

Given my workflow, why branch at all? Sometimes I may be working
on more than one branch at a time, or I may get interrupted on
exp_smoothing development to make a regression fix to master, or
maybe I discover that I don't want to merge exp_smoothing until the
next major version release. It's just easier to manage as a separate
branch up until the last four or six steps. I can rebase exp_smoothing
on top of master over and over again until I finally merge and publish
it.

Tait

Re: a few beginner git questions

[Junio C Hamano]

Thomas Anderson <zelnaga@gmail.com> writes:

> 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"?

"git add file" is a way to let you say "I have examined the changes since
the last commit to this file, and I do not want to see them in the output
from my later invocations of 'git diff'".  The intent is to let you focus
on one detail without getting distracted by other changes.

So typically you repeat the following steps:

 - change your files in the working tree;
 - run 'git diff' to check your progress _incrementally_; and
 - run 'git add that-file' to mark that the changes so far is satisfactory.

"add then commit" would be just running the above cycle once between
commits.  "add, add then commit" would be running the cycle twice.

This doesn't help you very much when you are always making small commits.
You might never encounter a case where you need to do more than one cycle
of the above before creating a commit.  But in real-life, the extent of
changes that need to be contained in a single logically independent unit
you would want to record as a commit is sometimes large enough that it
helps to be able to work incrementally.  Also often people keep small
changes that they do not want to commit yet in their working tree (and of
course they never say "git add" on them until they are ready).  If you are
interested, you can read more on this:

  http://thread.gmane.org/gmane.comp.version-control.git/15148/focus=15476

Other times, you can always do "commit -a".

Also, all of the above doesn't really matter in projects that tolerate
incoherent and/or unfocused commits, as they do not care how well you
choose commit boundaries.