Re: [GIT PATCH] USB patches for 2.6.17

Re: [GIT PATCH] USB patches for 2.6.17

[Sam Ravnborg]

> I'm just constantly surprised by how people don't even seem to realize 
> what it can do sometimes. Part of it is that development has been pretty 
> active (and some of the things it can do simply weren't there three months 
> ago), but part of it must be because people don't even expect it to be 
> able to do something like that.

Personally I'm still missing two things:
1) A command to let me see what this Linus guy have applied compared to
my tree - without touching anything in my tree. bk changes -R
2) A dry-run of a fetch+pull. I can do that if I really study the man
pages I know. But "git pull --dry-run" would be more convinient.

Other than that I will say that I'm pleased with the funtionality that
I use - that's maybe 10% of the possibilities...

	Sam

Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
_______________________________________________
linux-usb-devel@lists.sourceforge.net
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel

Re: [GIT PATCH] USB patches for 2.6.17

[Petr Baudis]

Dear diary, on Thu, Jun 22, 2006 at 10:01:47PM CEST, I got a letter
where Sam Ravnborg <sam@ravnborg.org> said that...
> Personally I'm still missing two things:
> 1) A command to let me see what this Linus guy have applied compared to
> my tree - without touching anything in my tree. bk changes -R

You can cg-fetch / git fetch and then either "cg-log -m" or
"git log -r ..origin".

> 2) A dry-run of a fetch+pull. I can do that if I really study the man
> pages I know. But "git pull --dry-run" would be more convinient.

What would that involve? Isn't git pull --no-commit enough?

-- 
				Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
A person is just about as big as the things that make them angry.

Re: [GIT PATCH] USB patches for 2.6.17

[Linus Torvalds]

On Thu, 22 Jun 2006, Sam Ravnborg wrote:
> 
> Personally I'm still missing two things:
> 1) A command to let me see what this Linus guy have applied compared to
> my tree - without touching anything in my tree. bk changes -R

	git fetch linus
	git log ..linus

Yes, it will fetch the things into your database, unlike BK, but that's 
kind of the point. That's what makes branches so powerful (you can do a 
lot more than "bk changes -R").

> 2) A dry-run of a fetch+pull. I can do that if I really study the man
> pages I know. But "git pull --dry-run" would be more convinient.

Hmm? Again, do

	git fetch <thing-to-be-fetched>

into a local branch first. That gets it into your repo, so that you can do 
things.

After that, I'm not quite sure what you mean by "--dry-run". Do you mean 
to know about file-level conflicts? You do need to do the merge in order 
to know whether the conflicts can be resolved, but even without doing the 
merge you can look for _file_level_ conflicts by other means.

I don't think anybody has done it, but a script like

	OTHER="$1"
	BASE=$(git-merge-base HEAD $OTHER) || exit
	git-merge-tree $BASE HEAD $OTHER | grep -v '^0'

will show if there were file-level conflicts (in a pretty strange format, 
admittedly).

Of course, 99% of the time, a three-way merge will just handle those fine 
(the output from "git-merge-tree" is enough to know to do a three-way 
merge on temp-files, if you want to try that).

		Linus

Re: [GIT PATCH] USB patches for 2.6.17

[Linus Torvalds]

On Thu, 22 Jun 2006, Linus Torvalds wrote:
> 
> After that, I'm not quite sure what you mean by "--dry-run". Do you mean 
> to know about file-level conflicts? You do need to do the merge in order 
> to know whether the conflicts can be resolved, but even without doing the 
> merge you can look for _file_level_ conflicts by other means.

Btw, what you can always do is just

	git pull <other-end>
	.. look at the result ..
	git reset --hard ORIG_HEAD

and you should be ok. It's obviously not a dry-run, it's more of a "do it 
and then undo it", but hey, it should _work_.

(Look out for dirty state, though. "git pull" will happily pull into a 
dirty tree if the changes don't actually affect any dirty files. The "git 
reset --hard" thing will undo all dirty state, though).

		Linus

Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
_______________________________________________
linux-usb-devel@lists.sourceforge.net
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel