[PATCH] Export pcibios_bus_to_resource

tree 209aa1f61d73f84046bd8735c7b4ef306b30e3cc parent b7561524765a30334bf31c56b523aeb3c1a04c7d author Keith Owens [EMAIL PROTECTED] Wed, 24 Aug 2005 16:06:25 +1000 committer Linus Torvalds [EMAIL PROTECTED] Thu, 25 Aug 2005 00:22:44 -0700 [PATCH] Export pcibios_bus_to_resource

[PATCH] cpu_exclusive sched domains build fix

tree d7db18d3d5f75fe4309ddc7aa373f3213f845b41 parent 40bb0c3ef52d872de348e1eb5432a43a147d author Paul Jackson [EMAIL PROTECTED] Wed, 24 Aug 2005 18:15:10 -0700 committer Linus Torvalds [EMAIL PROTECTED] Wed, 24 Aug 2005 23:40:45 -0700 [PATCH] cpu_exclusive sched domains build fix As reported

[PATCH] m68k: fix broken macros causing compile errors

tree fb0a64a7e4c53fa05a75d1ebb429a27b5c44de3b parent 0572e3da3ff5c3744b2f606ecf296d5f89a4bbdf author Andreas Schwab [EMAIL PROTECTED] Wed, 24 Aug 2005 17:36:21 +0200 committer Linus Torvalds [EMAIL PROTECTED] Wed, 24 Aug 2005 23:37:40 -0700 [PATCH] m68k: fix broken macros causing compile errors

[PATCH] x86_64: update defconfig - reenable fusion

tree e45d7e074f82778666db9d51d15dd0e66f8efdbb parent 5477d30e841e0f707fd2daddc8cb6949858476ee author Andi Kleen [EMAIL PROTECTED] Wed, 24 Aug 2005 07:37:37 +0200 committer Linus Torvalds [EMAIL PROTECTED] Thu, 25 Aug 2005 00:22:44 -0700 [PATCH] x86_64: update defconfig - reenable fusion I

Re: baffled again

[EMAIL PROTECTED] writes: So I have another anomaly in my GIT tree. A patch to back out a bogus change to arch/ia64/hp/sim/boot/bootloader.c in my release branch at commit 62d75f3753647656323b0365faa43fc1a8f7be97 appears to have been lost when I merged the release branch to the test

git-archimport-script - 2nd iteration

Gave the code another pass. The code should be more readable, and make a bit more sense. It now: - handles commit timestamps correctly - handles binary files correctly - uses parselog() to tell git-update-cache what's been added/deleted/modified - much faster commits on large trees - gets the

Tool renames? was Re: First stab at glossary

So when this gets all settled, will we see a lot of tool renaming? While it would cause me and my team some personal effort (we have a special-purpose porcelain), it would be welcome to have a lexicon that is sane and consistent, and in tune with all the documentation. Others may feel

Re: baffled again

On Wed, 24 Aug 2005, Junio C Hamano wrote: [EMAIL PROTECTED] writes: So I have another anomaly in my GIT tree. A patch to back out a bogus change to arch/ia64/hp/sim/boot/bootloader.c in my release branch at commit 62d75f3753647656323b0365faa43fc1a8f7be97 appears to have been

Query about status of http-pull

Hi, Recently cogito again say that the rsync method will be deprecated in future (due to http-pull now supporting pack objects I suppose), but it seems to me that it still have other issues: - lycan linux-2.6 # git pull origin Fetching HEAD using http Getting pack list error: Couldn't get

Re: Query about status of http-pull

On Wed, 24 Aug 2005, Martin Schlemmer wrote: Hi, Recently cogito again say that the rsync method will be deprecated in future (due to http-pull now supporting pack objects I suppose), but it seems to me that it still have other issues: - lycan linux-2.6 # git pull origin Fetching

Re: [RFC] undo and redo

Oops. I forgot to actually exit from the script if git-diff-files is non-empty. Also, looking at it now, I don't think keeping undo information in a stack is the right thing. But keeping more than just one would be good. Oh well, my first shot is never perfect. ;-) Carl On Wed, Aug 24, 2005

Re: Query about status of http-pull

Daniel Barkalow [EMAIL PROTECTED] writes: It looks like pack-c24bb5025e835a3d8733931ce7cc440f7bfbaaed isn't in the pack list. I suspect that updating this file should really be done by anything that creates pack files, because people forget to run the program that does it otherwise and then

Re: [RFC] undo and redo

Carl Baldwin [EMAIL PROTECTED] writes: Attached are the two scripts. Comments and criticism are welcome. An obligatory non-technical comment. I would have liked to see this not in a MIME multipart format, which made commenting on it a bit harder than necessary. Content-Type: text/plain;

Re: Query about status of http-pull

On Wed, 24 Aug 2005, Junio C Hamano wrote: Added at the end of git-repack-script (Linus can disable it by giving an '-n' flag when packing his private repositories). No, I just haven't updated my git on master.kernel.org in a while. So nothing to disable. I ran git-update-server-info

Re: baffled again

On Wed, 24 Aug 2005, Linus Torvalds wrote: Basically, he had two branches, A and B, and both contained the same patch (but _not_ the same commit). One undid it, the other did not. There's no real way to say which one is correct, and both cases clearly merge perfectly, so both outcomes

Re: [RFC] undo and redo

On Wed, 24 Aug 2005, Carl Baldwin wrote: Oops. I forgot to actually exit from the script if git-diff-files is non-empty. Also, looking at it now, I don't think keeping undo information in a stack is the right thing. But keeping more than just one would be good. Oh well, my first shot

Re: Fix git-rev-parse breakage

On Wed, 24 Aug 2005, Junio C Hamano wrote: that is not a right thing so get rid of that assumption (which I agree is a good change, and the last sentense says opposite... Well, the patch makes it an _explicit_ assumption, instead of a very subtly hidden one from the code-flow. It was the

Re: baffled again

On Wed, 24 Aug 2005, Linus Torvalds wrote: Now, if the shared patch hadn't been a patch, but a shared _commit_, then the thing would have been unambiguous - the shared commit would have been the merge point, and the revert would have clearly undone that shared commit. Actually, it was a

Re: [RFC] undo and redo

On Wed, Aug 24, 2005 at 11:51:32AM -0700, Linus Torvalds wrote: On Wed, 24 Aug 2005, Carl Baldwin wrote: Oops. I forgot to actually exit from the script if git-diff-files is non-empty. Also, looking at it now, I don't think keeping undo information in a stack is the right thing.

Re: [RFC] undo and redo

On Wed, Aug 24, 2005 at 11:18:42AM -0700, Junio C Hamano wrote: Carl Baldwin [EMAIL PROTECTED] writes: Attached are the two scripts. Comments and criticism are welcome. An obligatory non-technical comment. I would have liked to see this not in a MIME multipart format, which made

RE: baffled again

I think git did the right thing, it just happened to be the thing that Tony didn't want. Which makes it the wrong thing, of course, but from a purely technical standpoint, I don't think there's anything really wrong with the merge. On the plus side ... at least it wasn't a dumb user error this

Re: [RFC] undo and redo

On Wed, 24 Aug 2005, Carl Baldwin wrote: This brings up a good point (indirectly). git prune would destroy the undo objects. I had thought of this but decided to ignore it for the time being. If you made undo store the tree under refs somewhere, git prune would preserve it. -Daniel

[PATCH] Rationalize output selection in rev-parse.

Earlier rounds broke 'whatchanged -p'. In attempting to fix this, make two axis of output selection in rev-parse orthogonal: --revs-only tells it not to output things that are not revisions nor flags that rev-list would take. --no-revs tells it not to output things that

[PATCH] Gitk tree view (correction)

I'm sorry for sending a non-working patch. Apparently I got lost in /tmp. So here is the patch for gitk that allows you to browse the entire tree for every revision. The patched gitk script and some screenshots can be found at: http://public.efil.de/gitk/ For my personal use it's rather

Re: [RFC] undo and redo

Daniel Barkalow [EMAIL PROTECTED] writes: Generally, each subdirectory of refs/ has refs to objects of the same type, and heads/ is commits, but other directories are other things. tags/ is all tag objects, and you could have undo/ be trees. That's OK from the prune front, but I am not sure

Re: Tool renames? was Re: First stab at glossary

Tim Ottinger [EMAIL PROTECTED] writes: So when this gets all settled, will we see a lot of tool renaming? I personally do not see it coming. Any particular one you have in mind? - To unsubscribe from this list: send the line unsubscribe git in the body of a message to [EMAIL PROTECTED] More

[ANNOUNCE] GIT 0.99.5

I've pushed out all of what has been in the proposed updates branch, along with documentation updates. Many changes all over: - pulling from packed repository. - cvsimport. - documentation coverage. - usability. - terminology clarification. - hooks for updates and commits. - updated gitk.

Re: [RFC] Looking at multiple ancestors in merge

Daniel Barkalow wrote: I'm starting to work on letting the merging process see multiple ancestors, and I think it's messy enough that I should actually discuss it. Review of the issue: It is possible to lost reverts in cases when merging two commits with multiple ancestors, in the

Re: [RFC] undo and redo

So, I've tried cloning, pulling to|from, pushing to|from and resolving merges in a repository with undo information stored under .git/refs/undo. None of these operations seem to notice the existence of this directory. I think this is good. What I meant was that, when undo/bar is a tree

Re: [RFC] Looking at multiple ancestors in merge

On Wed, 24 Aug 2005, A Large Angry SCM wrote: Daniel Barkalow wrote: I'm starting to work on letting the merging process see multiple ancestors, and I think it's messy enough that I should actually discuss it. Review of the issue: It is possible to lost reverts in cases when

Re: baffled again

* Even if it does always choose the nicer choice of the two, Tony was lucky (no pun intended). Rather, we were lucky that Tony was observant. A careless merger may well have easily missed this mismerge (from the human point of view). Actually I can't take credit here. This was a