threads / patch / 4623

patchRe: [GIT PATCH] USB patches for 2.6.17

Subject: Re: [GIT PATCH] USB patches for 2.6.17

## tl;dr

4 messages between Jun 22, 2006 and Jun 22, 2006. Diffs are folded; open one to read it.

replies: 3people: 3as markdown or json

Sam Ravnborg· Jun 22, 2006, 20:01 UTC · lore

Show 5 quoted lines

> 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

Petr Baudis· Jun 22, 2006, 20:52 UTC · re: Sam Ravnborg · lore

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.

Linus Torvalds· Jun 22, 2006, 21:01 UTC · re: Sam Ravnborg · lore

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

Linus Torvalds· Jun 22, 2006, 21:07 UTC · re: Linus Torvalds · lore

On Thu, 22 Jun 2006, Linus Torvalds wrote:

Show 5 quoted lines

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