git-pull-script on my linus tree fails..

git-pull-script on my linus tree fails..

[Dave Airlie]

I had a git archive from just after 2.6.12-rc6, which I've not touched on
my local system..

Now I've just done

cd linux-2.6
git-pull-script rsync://rsync.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git

And I get:
sent 69638 bytes  received 17423079 bytes  52928.04 bytes/sec
total size is 135185594  speedup is 7.73
Updating from 27198d855abbfc82df69e81b6c8d2f333580114c to
1d345dac1f30af1cd9f3a1faa12f9f18f17f236e.
Destroying all noncommitted data!
Kill me within 3 seconds..
fatal: Entry 'Documentation/DocBook/scsidrivers.tmpl' would be overwritten
by merge. Cannot merge.

but I haven't touched that tree so I shouldn't get merge issues..

whatsup?

Dave.


-- 
David Airlie, Software Engineer
http://www.skynet.ie/~airlied / airlied at skynet.ie
Linux kernel - DRI, VAX / pam_smb / ILUG

Re: git-pull-script on my linus tree fails..

[Linus Torvalds]

On Tue, 21 Jun 2005, Dave Airlie wrote:
>
> fatal: Entry 'Documentation/DocBook/scsidrivers.tmpl' would be overwritten
> by merge. Cannot merge.
> 
> but I haven't touched that tree so I shouldn't get merge issues..
> 
> whatsup?

The most common issue is that your index is not in sync. For many 
operations, that's just goign to slow things down a lot (ie a diff migth 
take a long time instead of being instantaneous), but for a merge it's 
considered an error.

Does "git-diff-files -p" show any output? That's a dead give-away.

Do "git-update-cache --refresh" to make sure your index file matches your 
working directory.

I guess I can make the "git pull" script do that automatically (some other
scripts do, like "git commit", which also depends on having an up-to-date
index).

		Linus

Re: git-pull-script on my linus tree fails..

[Jeff Garzik]

Linus Torvalds wrote:
> I guess I can make the "git pull" script do that automatically (some other
> scripts do, like "git commit", which also depends on having an up-to-date
> index).

Slight tangent...  it would be nice if you would write a 2-line 
git-checkout-script, which provides the modern version of

	git-read-tree -m HEAD && git-checkout-cache -q -f -u -a

Note that I do depend on this command blowing away working dir changes, 
but maybe you would want that to be a separate arg.

Then you could add a "-u" arg, or somesuch, to the situations like git 
pull that want an up-to-date index.

	Jeff

Re: git-pull-script on my linus tree fails..

[Linus Torvalds]

On Tue, 21 Jun 2005, Jeff Garzik wrote:
> 
> Slight tangent...  it would be nice if you would write a 2-line 
> git-checkout-script, which provides the modern version of
> 
> 	git-read-tree -m HEAD && git-checkout-cache -q -f -u -a
> 
> Note that I do depend on this command blowing away working dir changes, 
> but maybe you would want that to be a separate arg.

Added. Feel free to try it out, but it's very lightly tested.

You can do just "git checkout" and it will checkout the current HEAD, but 
won't overwrite anything old. Use the "-f" flag to force overwrite. 

It can also take a new HEAD, ie you can check out the parent of the 
current HEAD by doing

	git checkout HEAD^


and if you actually want to set the HEAD to that parent you can do so with 
the "-u" flag, so

	git checkout -u HEAD^

is basically equivalent to "undo the topmost commit".

It's not quite your "switch", though, because it will always _write_ to
the current HEAD, it won't be switching the current HEAD around to another
branch. I almost think that behavkiour would be more useful, I'll think
about how to do it sanely.

		Linus

Re: git-pull-script on my linus tree fails..

[Jeff Garzik]

Linus Torvalds wrote:
> It's not quite your "switch", though, because it will always _write_ to
> the current HEAD, it won't be switching the current HEAD around to another
> branch. I almost think that behavkiour would be more useful, I'll think
> about how to do it sanely.

The reason I requested git-checkout-script is to make git-switch-tree 
pretty much trivial.  The new git-switch-tree will sit on top of 
git-checkout-script, like

	if $1
		switch HEAD to refs/heads/$1
	git-checkout-script

So, as created, git-checkout-script is a useful foundation for other 
scripts.

As of right now, I only have two[1] scripts that are non-vanilla:

git-switch-tree:	retarget .git/HEAD to refs/heads/$1
git-new-branch:		cp refs/heads/master refs/heads/$1

With git-checkout-script, both of these are now trivial and obvious.

	Jeff



[1] Actually I have a third, 'git-changes-script'.  The only reason I 
use this is that it supports the old BitKeeper syntax of

	cd my-repo-2.6
	git-changes-script -L ../linux-2.6

to obtain a list of changes that are _only_ present in my-repo-2.6, and 
not in ../linux-2.6 repo.  git-changes-script works with .git/HEAD at 
the repo level, and knows nothing of branches (which is fine).

Re: git-pull-script on my linus tree fails..

[Linus Torvalds]

On Tue, 21 Jun 2005, Jeff Garzik wrote:
> 
> The reason I requested git-checkout-script is to make git-switch-tree 
> pretty much trivial.  The new git-switch-tree will sit on top of 
> git-checkout-script, like
> 
> 	if $1
> 		switch HEAD to refs/heads/$1
> 	git-checkout-script

Actually, I'd suggest doing the git-checkout-script _first_. That way you 
_can_ use the careful version, which refuses to switch if it would cause 
information to be lost. Ie something like

	git-checkout-script $1 && switch HEAD to refs/heads/$1

should do it.

(And then you can choose to use the "-f" flag or not to
git-checkout-script depending on whether you want to force it).

Anyway, I think the branch switching behaviour is useful enough that I 
should make git-checkout-script understand the notion of switching to a 
new branch natively.

		Linus

Re: git-pull-script on my linus tree fails..

[Jeff Garzik]

Linus Torvalds wrote:
> Actually, I'd suggest doing the git-checkout-script _first_. That way you 
> _can_ use the careful version, which refuses to switch if it would cause 
> information to be lost. Ie something like
> 
> 	git-checkout-script $1 && switch HEAD to refs/heads/$1
> 
> should do it.


If I want my working dir updated to reflect the desired branch -- the 
whole purpose of git-switch-tree -- I would have to do

	git-checkout-script && switch HEAD && git-checkout-script

which is a bit silly.

	Jeff

Re: git-pull-script on my linus tree fails..

[Linus Torvalds]

On Tue, 21 Jun 2005, Jeff Garzik wrote:
> 
> If I want my working dir updated to reflect the desired branch -- the 
> whole purpose of git-switch-tree -- I would have to do
> 
> 	git-checkout-script && switch HEAD && git-checkout-script

No, you don't understand. The git-checkout-script already takes a 
parameter to indicate _what_ to check out. It just defaults to head.

So you'd do

	git-checkout-script branch && switch branch

and you'd be done.

Anyway, I liked the branch semantics for "git checkout" so much that I 
just made it do that by default. In other words, if you do

	git checkout 'branch'

it will both check out the new branch contents and switch HEAD to branch. 
It will refuse to overwrite any data, but as before, you can force that 
with "git checkout -f branch" instead.

If the argument to "git checkout" isn't a branch-name, but some other 
name (like "v2.6.12" or an extended expression like "HEAD^" for "parent of 
HEAD"), it will just check it out, but it obviously won't be switching any 
branches around (and it will leave HEAD untouched).

These seem like sane and useful semantics, and your "switch" script should 
really fall out as "git checkout -f".

		Linus

Re: git-pull-script on my linus tree fails..

[Jeff Garzik]

Linus Torvalds wrote:
> No, you don't understand. The git-checkout-script already takes a 
> parameter to indicate _what_ to check out. It just defaults to head.
> 
> So you'd do
> 
> 	git-checkout-script branch && switch branch
> 
> and you'd be done.

ah, ok.


> Anyway, I liked the branch semantics for "git checkout" so much that I 
> just made it do that by default. In other words, if you do
[...]
> These seem like sane and useful semantics, and your "switch" script should 
> really fall out as "git checkout -f".

If git-checkout-script switches the .git/HEAD symlink properly, rather 
than updating the symlink target's contents, then my git-switch-tree 
script can just go away :)

Thanks,

	Jeff

Re: git-pull-script on my linus tree fails..

[Linus Torvalds]

On Tue, 21 Jun 2005, Jeff Garzik wrote:
> 
> If git-checkout-script switches the .git/HEAD symlink properly, rather 
> than updating the symlink target's contents, then my git-switch-tree 
> script can just go away :)

Well, you should test it. I sure didn't ;)

It's there on master.kernel.org now, but it hasn't percolated to the 
mirrors (including webgit) yet. The thing that I _think_ should work has a 
top commit of "git checkout: fix default head case".

		Linus

Re: git-pull-script on my linus tree fails..

[Jeff Garzik]

Linus Torvalds wrote:
> 
> On Tue, 21 Jun 2005, Jeff Garzik wrote:
> 
>>If git-checkout-script switches the .git/HEAD symlink properly, rather 
>>than updating the symlink target's contents, then my git-switch-tree 
>>script can just go away :)
> 
> 
> Well, you should test it. I sure didn't ;)

hmmm, I tried

	git checkout -f ncq

on libata-dev.git and it didn't seem to switch the symlink.

	Jeff

Re: git-pull-script on my linus tree fails..

[Jeff Garzik]

Jeff Garzik wrote:
> Linus Torvalds wrote:
> 
>>
>> On Tue, 21 Jun 2005, Jeff Garzik wrote:
>>
>>> If git-checkout-script switches the .git/HEAD symlink properly, 
>>> rather than updating the symlink target's contents, then my 
>>> git-switch-tree script can just go away :)
>>
>>
>>
>> Well, you should test it. I sure didn't ;)
> 
> 
> hmmm, I tried
> 
>     git checkout -f ncq
> 
> on libata-dev.git and it didn't seem to switch the symlink.

It does seem to hit the final branch in the script:

> [jgarzik@pretzel libata-dev]$ sh -x /usr/local/bin/git-checkout-script -f ncq
> + : .git
> ++ git-rev-parse HEAD
> + old=7df551254add79a445d2e47e8f849cef8fee6e38
> + new=
> + force=
> + branch=
> + '[' 2 '!=' 0 ']'
> + arg=-f
> + shift
> + case "$arg" in
> + force=1
> + i=1
> + '[' 1 '!=' 0 ']'
> + arg=ncq
> + shift
> + case "$arg" in
> ++ git-rev-parse ncq
> + rev=d032ec9048ff82a704b96b93cfd6f2e8e3a06b19
> + '[' -z d032ec9048ff82a704b96b93cfd6f2e8e3a06b19 ']'
> + '[' '' ']'
> + new=d032ec9048ff82a704b96b93cfd6f2e8e3a06b19
> + '[' -f .git/revs/heads/ncq ']'
> + i=2
> + '[' 0 '!=' 0 ']'
> + '[' -z d032ec9048ff82a704b96b93cfd6f2e8e3a06b19 ']'
> + '[' 1 ']'
> + git-read-tree --reset d032ec9048ff82a704b96b93cfd6f2e8e3a06b19
> + git-checkout-cache -q -f -u -a
> + '[' 0 -eq 0 ']'
> + '[' '' ']'
> + rm -f .git/MERGE_HEAD

Regards,

	Jeff

Re: git-pull-script on my linus tree fails..

[Linus Torvalds]

On Tue, 21 Jun 2005, Jeff Garzik wrote:
> Jeff Garzik wrote:
> 
> It does seem to hit the final branch in the script:
> 
> > [jgarzik@pretzel libata-dev]$ sh -x /usr/local/bin/git-checkout-script -f ncq
> > + new=d032ec9048ff82a704b96b93cfd6f2e8e3a06b19
> > + '[' -f .git/revs/heads/ncq ']'

Oops. Typo of mine. "revs" is incorrect, it should be "refs".

So because it's testing the wrong directory for the branch name, it
obviously won't find the branch, and decides that you used just a regular 
commit name.

I bet that one-character fix will fix it. Pushed out, 

		Linus

Re: git-pull-script on my linus tree fails..

[Jeff Garzik]

Linus Torvalds wrote:
> Oops. Typo of mine. "revs" is incorrect, it should be "refs".
> 
> So because it's testing the wrong directory for the branch name, it
> obviously won't find the branch, and decides that you used just a regular 
> commit name.


git-checkout-script is now switching branches correctly :)

Now stay tuned for my next email, where I demonstrate how to reproduce 
git-prune-script eating data :)

	Jeff

Re: git-pull-script on my linus tree fails..

[Linus Torvalds]

On Tue, 21 Jun 2005, Jeff Garzik wrote:
> 
> git-checkout-script is now switching branches correctly :)

Goodie.

> Now stay tuned for my next email, where I demonstrate how to reproduce 
> git-prune-script eating data :)

Before you demonstrate that, let me give you a quick warning on a very 
useful but also very peculiar and perhaps baffling feature of my version 
of "git checkout" as opposed to your "git switch".

In particular, think about what happens when you have changes in your
working directory, and you use "git checkout <newbranch>" (that is,
without the "-f" flag).

Now, if those changes actually _clash_ with the difference in the branch
you're switching to, you'll get an error (something like "Entry 'filename'
not uptodate. Cannot merge."). But if you have only edited files that are
the _same_ in both branches, then when you switch branches, those edits
will literally _follow_ you into the new branch.

Before, with your "git switch" script, any pending dirty state just got
thrown away.

Now, I'm convinced this is actually exactly the behaviour you want, but I 
thought I'd mention it before you notice it on your own and get confused.

And hey, if you don't like the feature, you can always just use the "-f"  
flag, which will act the way your old script did, and always just throw
any pending changes away when you check out a new branch.

			Linus

Re: git-pull-script on my linus tree fails..

[Jeff Garzik]

Linus Torvalds wrote:
> And hey, if you don't like the feature, you can always just use the "-f"  
> flag, which will act the way your old script did, and always just throw
> any pending changes away when you check out a new branch.

hehe, that's what I am doing ;-)

For fast-forward merges, I use "git checkout".  For everything else in 
my workflow, I use "git checkout -f $branch"

I'm not sure that I, personally, will ever use "git checkout $branch" 
without "-f".

	Jeff