My first git success

My first git success

[walt]

All the help you guys have given me lately has at least
fixed one kernel bug :o)

After using git-bisect to find the responsible commit,
I emailed the maintainer who sent me back a patch to try.

I used git-checkout to make a new test branch, applied
and tested the patch (which fixed the bug) and I just
sent off an email to the maintainer to confirm.

And it was all so easy I never broke a sweat.  Amazing!

So thank you all again for the help and your great work.

Re: My first git success

[Linus Torvalds]

On Fri, 13 Jan 2006, walt wrote:
> 
> And it was all so easy I never broke a sweat.  Amazing!

Heh. You're the "good tester" kind of person. Most people don't bother to 
explain their problems well, and don't even bother to listen. And they 
never call it "easy" if they had to get explanations.

I still hope the exchanges will result in more docs, or at least other 
lurkers on the list also learning a new trick or two..

			Linus

Re: My first git success

[Randal L. Schwartz]

>>>>> "Linus" == Linus Torvalds <torvalds@osdl.org> writes:

Linus> I still hope the exchanges will result in more docs, or at least other 
Linus> lurkers on the list also learning a new trick or two..

I've also enjoyed a bit of success putting a website under git.  I started
working on AJAX-ing some of the code, but I needed to do maintainence on the
live site, so I've just simply done "git-checkout master" to work on that, and
"git-checkout ajax; git-pull . master" when I want to continue work on the
ajax upgrades.

However, before I bug-fix, I have to "snapshot" any working changes in the
ajax branch or I would lose them on "git-checkout master", which gives me
commits that look like "snapshot".  Am I doing that wrong?  Is there a better
way to do parallel development of a "live vs upgrade" branch, and make commits
only when I make progress?

-- 
Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095
<merlyn@stonehenge.com> <URL:http://www.stonehenge.com/merlyn/>
Perl/Unix/security consulting, Technical writing, Comedy, etc. etc.
See PerlTraining.Stonehenge.com for onsite and open-enrollment Perl training!

Re: My first git success

[Junio C Hamano]

merlyn@stonehenge.com (Randal L. Schwartz) writes:

> However, before I bug-fix, I have to "snapshot" any working changes in the
> ajax branch or I would lose them on "git-checkout master", which gives me
> commits that look like "snapshot".  Am I doing that wrong?  Is there a better
> way to do parallel development of a "live vs upgrade" branch, and make commits
> only when I make progress?

Although I am sure others would suggest to use more than one
working tree, here are what I generally do, which does not
require more than one.

-- >8 --

Interrupted workflow
--------------------

When you are in the middle of a large change, you can get
interrupted.  The files in your working tree is not in any shape
to be committed, but you need to get to the other branch for a
quick fix.

------------
: on ajax; work work work
: on ajax; git commit -a -m 'snapshot WIP' <1>
: on ajax; git checkout master
: on master; fix fix fix
: on master; git commit ;# commit with real log
: on master; git checkout ajax
: on ajax; git reset --soft HEAD^ ;# go back to WIP state <2>

<1> This commit will get blown away so short log message is just fine.
<2> This removes the 'WIP' commit from the commit history, and makes
    your working tree in the state just before you made that snapshot.

------------

The only difference between the state immediately before <1> and
immediately after <2> is that files you committed in <1> are
still registered in index at state <2>, so your "git diff" would
not give you what you were in the middle of doing at point <2>
and you need to say "git diff HEAD" instead.  You could do a

------------
: on ajax; git read-tree -m HEAD
------------

immediately after the soft reset, which sets your index file to
the last commit you were basing your ajax work on.

Re: My first git success

[Peter Eriksen]

On Fri, Jan 13, 2006 at 10:57:04AM -0800, Randal L. Schwartz wrote:
> >>>>> "Linus" == Linus Torvalds <torvalds@osdl.org> writes:
> 
> Linus> I still hope the exchanges will result in more docs, or at least other 
> Linus> lurkers on the list also learning a new trick or two..
> 
> I've also enjoyed a bit of success putting a website under git.  I started
> working on AJAX-ing some of the code, but I needed to do maintainence on the
> live site, so I've just simply done "git-checkout master" to work on that, and
> "git-checkout ajax; git-pull . master" when I want to continue work on the
> ajax upgrades.
> 
> However, before I bug-fix, I have to "snapshot" any working changes in the
> ajax branch or I would lose them on "git-checkout master", which gives me
> commits that look like "snapshot".  Am I doing that wrong?  Is there a better
> way to do parallel development of a "live vs upgrade" branch, and make commits
> only when I make progress?

I've been wondering this myself.  Perhaps the following way would work?

    git checkout ajax          # Work on the ajax branch.
    git diff HEAD >ajaxdiff
    git checkout -f master     # Work on the bug fix in master.
    git commit -a -m "Bug fix in master"
    git checkout ajax
    git apply ajaxdiff
    git commit -a -m "Finished commit in ajax"

This is untested, so it's only for inspiration.

Regards,

Peter

Re: My first git success [not quite]

[walt]

Linus Torvalds wrote:
> 
> On Fri, 13 Jan 2006, walt wrote:
>> And it was all so easy I never broke a sweat.  Amazing!

>  ...Most people don't bother to 
> explain their problems well...

I see I still have a problem:  my mental model of how git
works is still wrong.

I used 'git-checkout -b test' to create a disposable place
to test the patch I was given.

Okay, making sure I'm now sitting in 'test', I apply the
patch to foo.c and do my testing.

Now, intending to delete my 'test' branch, I do git-checkout
master.  My mental model predicts that 'master' should still
be identical to 'origin' because I did the patching in 'test'.
Am I right so far?

The problem I see is that, after switching back to 'master',
foo.c is the patched version, not your original version.  I
figured that the git-checkout would overwrite any changes I
made to foo.c, but that doesn't seem to be the case.  To get
your original version back I had to delete foo.c and do a
git-checkout foo.c (or git-checkout -f master).

So, I clearly don't understand what git-checkout does.  It
doesn't seem to touch the already-checked-out sources at
all, which is what I would expect it to do.

Can someone hit me with the clue-stick here?  Thanks!

Re: My first git success [not quite]

[sean]

On Sat, 14 Jan 2006 07:39:28 -0800
walt <wa1ter@myrealbox.com> wrote:

> Linus Torvalds wrote:
> > 
> > On Fri, 13 Jan 2006, walt wrote:
> >> And it was all so easy I never broke a sweat.  Amazing!
> 
> >  ...Most people don't bother to 
> > explain their problems well...
> 
> I see I still have a problem:  my mental model of how git
> works is still wrong.
> 
> I used 'git-checkout -b test' to create a disposable place
> to test the patch I was given.
> 
> Okay, making sure I'm now sitting in 'test', I apply the
> patch to foo.c and do my testing.
> 
> Now, intending to delete my 'test' branch, I do git-checkout
> master.  My mental model predicts that 'master' should still
> be identical to 'origin' because I did the patching in 'test'.
> Am I right so far?
> 
> The problem I see is that, after switching back to 'master',
> foo.c is the patched version, not your original version.  I
> figured that the git-checkout would overwrite any changes I
> made to foo.c, but that doesn't seem to be the case.  To get
> your original version back I had to delete foo.c and do a
> git-checkout foo.c (or git-checkout -f master).
> 
> So, I clearly don't understand what git-checkout does.  It
> doesn't seem to touch the already-checked-out sources at
> all, which is what I would expect it to do.
> 
> Can someone hit me with the clue-stick here?  Thanks!
> 

Hi Walt,

When you switch branches _uncommitted_ changes will stay in
your working directory.   This lets you change to a different
branch before committing something you're working on for
instance.   So likely, even though you had switched to your
test branch to apply the patch, you didn't actually commit
it into that branch before switching back to master.

Here's a little example that should show the difference:


Create a test repo:
	$ mkdir walt ; cd walt
	$ git-init-db
	defaulting to local storage area

Create a simple file and commit it on the master branch:
	$ echo A > file
	$ git add file
	$ git commit -m "initial"
	Committing initial tree a9e3325a07117aa5381e044a8d96c26eb30d729d

Create and checkout a new branch named "test":
	$ git checkout -b test
	$ git branch
	  master
	* test

Modify (ie. patch) the file:
	$ echo B > file
	$ cat file
	B

Now, if you switch back to the master branch, the file is still patched:
	$ git checkout master
	$ cat file
	B

Switch back to the test branch and commit the change this time:
	$ git checkout test
	$ git commit -m "test branch" file
	$ cat file
	B

Now, this time when you switch back to master, you'll get what you expect:
	$ git checkout master
	$ cat file
	A


HTH,
Sean

Re: My first git success [not quite]

[walt]

sean wrote:
> > On Sat, 14 Jan 2006 07:39:28 -0800
> > walt <wa1ter@myrealbox.com> wrote:
[...]
>> >> So, I clearly don't understand what git-checkout does.  It
>> >> doesn't seem to touch the already-checked-out sources at
>> >> all, which is what I would expect it to do.

> > Hi Walt,
> >
> > When you switch branches _uncommitted_ changes will stay in
> > your working directory.   This lets you change to a different
> > branch before committing something you're working on for
> > instance.

Ah!  The underlying reason is what I was missing.

> >   So likely, even though you had switched to your
> > test branch to apply the patch, you didn't actually commit
> > it into that branch before switching back to master.

Right.  And *my* reasoning (FWIW) is that I was intending
to throw the entire branch away so I didn't see any need to
commit.  (But men always have that problem ;o)

I suppose the underlying problem is that I don't think like
a developer.  My wish for a future improvement for git would
be a bonehead<-->expert switch that would turn on some basic
warning messages.  In this particular example, I would have
welcomed a warning message that said:  "You have uncommitted
changes!  Hit 'D' to discard them or <Enter> to keep them without
committing".  An experienced git user would want to turn that off,
most likely.

Thanks for the clue-stick, and I very much appreciate your
patience.

Re: My first git success [not quite]

[Randal L. Schwartz]

>>>>> "walt" == walt  <wa1ter@myrealbox.com> writes:

walt> I suppose the underlying problem is that I don't think like
walt> a developer.

Well, I'm a developer and *I* also had that problem while working
on my "ajax" branch.

Maybe git-checkout should by default *warn* when it is leaving
things in the tree that are indexed but not updated in the index
(committed?).  And you'd have to add a --no-warn thingy to turn
that off.  Then beginners wouldn't be quite as confused.  I'm not
talking about things that are .gitignore'd... just things like
walt's example.

-- 
Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095
<merlyn@stonehenge.com> <URL:http://www.stonehenge.com/merlyn/>
Perl/Unix/security consulting, Technical writing, Comedy, etc. etc.
See PerlTraining.Stonehenge.com for onsite and open-enrollment Perl training!

Re: My first git success [not quite]

[Junio C Hamano]

merlyn@stonehenge.com (Randal L. Schwartz) writes:

> Well, I'm a developer and *I* also had that problem while working
> on my "ajax" branch.
>
> Maybe git-checkout should by default *warn* when it is leaving
> things in the tree that are indexed but not updated in the index...

What Linus already said.  But you may find this on top of the
current "master" branch useful.

Likes, dislikes?

-- >8 --
[PATCH] checkout: show dirty state upon switching branches.

This shows your working file state when you switch branches.  As
a side effect, "git checkout" without any branch name (i.e. stay
on the current branch) becomes a more concise shorthand for the
"git status" command.

Signed-off-by: Junio C Hamano <junkio@cox.net>
---
diff --git a/git-checkout.sh b/git-checkout.sh
index bd7f007..d99688f 100755
--- a/git-checkout.sh
+++ b/git-checkout.sh
@@ -164,6 +164,9 @@ else
 	esac
 	exit 0
     )
+    saved_err=$?
+    git diff-files --name-status
+    (exit $saved_err)
 fi
 
 # 

Re: My first git success [not quite]

[Linus Torvalds]

On Sat, 14 Jan 2006, walt wrote:
> 
> I see I still have a problem:  my mental model of how git
> works is still wrong.
> 
> I used 'git-checkout -b test' to create a disposable place
> to test the patch I was given.
> 
> Okay, making sure I'm now sitting in 'test', I apply the
> patch to foo.c and do my testing.
> 
> Now, intending to delete my 'test' branch, I do git-checkout
> master.  My mental model predicts that 'master' should still
> be identical to 'origin' because I did the patching in 'test'.
> Am I right so far?

Yes.

> The problem I see is that, after switching back to 'master',
> foo.c is the patched version, not your original version.

Ahh. This is very much done on purpose.

Something that hasn't been committed (it is "dirty" in git terms) is 
really not associated with any branch _at_all_. It's purely associated 
with the checked-out directory.

Now, what happens is that when you change branches with a dirty tree, the 
"git checkout" will do one of two things:

 - if the dirty files are _identical_ in both branches, the dirty state 
   (remember: it's not associated with any particular branch) will follow 
   the branch switch.

   This is very convenient. You've edited a file, but you realized that 
   you did this in the wrong branch. For example, you realize that you are 
   in the main development branch, but that your edit is pretty damn 
   experimental. So what you do is _not_ to undo your edit, but to create 
   a new branch and switch to it, and then commit it _there_.

		git checkout -b experimental
		git commit --all

   (you might have an old experimental branch too, in which case you don't 
   need to create it, but then you can only switch to it if the file you 
   edited is the same as in your development branch)

 - otherwise, the switch will fail, and you'll have to either commit the 
   changes in that branch, or you'll have to undo them.

Now, Junio has patches (maybe they even got merged in mainline) to relax 
the "exactly the same" rule a bit, and instead try to merge any dirty 
state into the branch you're switching to. Conceptually nothing changed: 
dirty state is branchless, so when you switch to another branch, the dirty 
state follows you. 

> I figured that the git-checkout would overwrite any changes I
> made to foo.c, but that doesn't seem to be the case.  To get
> your original version back I had to delete foo.c and do a
> git-checkout foo.c (or git-checkout -f master).

Yes. You can either undo the dirty state, or you can do a "forced 
checkout" that will start from scratch. And the dirty state will be _gone_ 
in both cases. It won't be saved away in the "original branch". Again, 
this is 100% consistent with the notion that dirty state is branchless. 
Only _committed_ state is committed to a particular branch.

> So, I clearly don't understand what git-checkout does.  It
> doesn't seem to touch the already-checked-out sources at
> all, which is what I would expect it to do.

No, you understand exactly what git-checkout does, you just didn't realize 
that dirty state was different from committed state.

		Linus

Re: My first git success [not quite]

[walt]

Linus Torvalds wrote:
[...]
> Now, what happens is that when you change branches with a dirty tree, the 
> "git checkout" will do one of two things:
> 
>  - if the dirty files are _identical_ in both branches...

I'm sorry to be quibbling over semantics, truly I am!  But here
is my confusion:  if modified-but-uncommitted (hence dirty) files
are not associated with *any* branch, then how could 'dirty' files
be 'in' both branches (or 'in' any branch at all)?

Thanks for your continued patience with me!  I hate to distract you
from your real work -- I can only hope that others are learning as
much from your answers as I am.

Re: My first git success [not quite]

[Junio C Hamano]

walt <wa1ter@myrealbox.com> writes:

> Linus Torvalds wrote:
> [...]
>> Now, what happens is that when you change branches with a dirty tree, the 
>> "git checkout" will do one of two things:
>> 
>>  - if the dirty files are _identical_ in both branches...
>
> I'm sorry to be quibbling over semantics, truly I am!  But here
> is my confusion:  if modified-but-uncommitted (hence dirty) files
> are not associated with *any* branch, then how could 'dirty' files
> be 'in' both branches (or 'in' any branch at all)?

"If the paths that you have dirty are the same in both
branches".

That is:

* "master" branch has Makefile file, as taken from git.git

* "my-work" branch was made out of "master" branch, but
  has not modified Makefile file.

	git-diff-tree master my-work Makefile

  would yield nothing.

* You are on "master" branch.  You have added a new target to
  your Makefile in the working tree and the path is dirty.

Then:

	git checkout my-work

would notice that the path "Makefile" are identical between two
branches "master" you are switching from and "my-work" you are
switching to.  The "Makefile" in your working tree does not
match either tree, but that difference is carried over while
switching branches.

As Linus mentioned, with '-m' flag to "git checkout", it can
merge your local modifications even when "master" and "my-work"
disagrees on "Makefile" in this example.

        

Re: My first git success [not quite]

[Linus Torvalds]

On Sat, 14 Jan 2006, walt wrote:
>
> Linus Torvalds wrote:
> [...]
> > Now, what happens is that when you change branches with a dirty tree, the 
> > "git checkout" will do one of two things:
> > 
> >  - if the dirty files are _identical_ in both branches...
> 
> I'm sorry to be quibbling over semantics, truly I am!  But here
> is my confusion:  if modified-but-uncommitted (hence dirty) files
> are not associated with *any* branch, then how could 'dirty' files
> be 'in' both branches (or 'in' any branch at all)?

The file itself is associated with the branch. It's just that the _dirty_ 
part isn't.

Of course, you can also truly have files that aren't associated with 
either branch at all: files that haven't gotten committed at all. They're 
also "dirty state", and exactly like modifications to known files, they 
are carried along with the switch, so they'll exist in the directory tree 
after a "git checkout".

Anyway, in git, a "branch" is technically really nothing more than "top of 
a commit chain". If you look into the files that describe a branch, you'll 
literally just find the name of the top commit. Do a

	cat .git/refs/heads/master

to see. 

So anything that isn't described by that commit is by definition "dirty 
state", whether it's because you've edited something (but not checked it 
in) or because there's some random generated file in the working tree.

So when you switch branches, you really should think of it as "ok, the 
committed state was switched around", and everything else was just "moved 
along".

		Linus

Re: My first git success [not quite]

[Junio C Hamano]

Linus Torvalds <torvalds@osdl.org> writes:

> Now, Junio has patches (maybe they even got merged in mainline) to relax 
> the "exactly the same" rule a bit, and instead try to merge any dirty 
> state into the branch you're switching to. Conceptually nothing changed: 
> dirty state is branchless, so when you switch to another branch, the dirty 
> state follows you. 

FYI, I pushed this out, along with some other changes.

 * checkout -m can be used to merge while switching branches.
 * format-patch now always does --mbox and shows RFC2822 Date.
 * clone --naked can be used for creating "project.git" style repository.
 * octopus allows hand resolving in limited form.
 * show-branch user interface updates.
 * push --tags to push all tags; it does not fall back on "matching" refs.