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.
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
From: Randal L. Schwartz <hidden> Date: 2016-06-15 22:42:16
quoted
quoted
quoted
quoted
"Linus" == Linus Torvalds [off-list ref] 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
[off-list ref] <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!
From: Peter Eriksen <hidden> Date: 2016-06-15 22:42:16
On Fri, Jan 13, 2006 at 10:57:04AM -0800, Randal L. Schwartz wrote:
quoted
quoted
quoted
quoted
quoted
"Linus" == Linus Torvalds [off-list ref] 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
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!
On Sat, 14 Jan 2006 07:39:28 -0800
walt [off-list ref] wrote:
Linus Torvalds wrote:
quoted
On Fri, 13 Jan 2006, walt wrote:
quoted
And it was all so easy I never broke a sweat. Amazing!
quoted
...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
On Sat, 14 Jan 2006 07:39:28 -0800
walt [off-list ref] wrote:
[...]
quoted
quoted
quoted
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.
quoted
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.
quoted
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.
From: Randal L. Schwartz <hidden> Date: 2016-06-15 22:42:16
quoted
quoted
quoted
quoted
"walt" == walt [off-list ref] 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
[off-list ref] <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!
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
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.
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