* Re: git-rev-tree
From: Linus Torvalds @ 2005-11-08 3:35 UTC (permalink / raw)
To: Dave Jones; +Cc: git
In-Reply-To: <20051108025755.GA22243@redhat.com>
On Mon, 7 Nov 2005, Dave Jones wrote:
>
> (18:47:37:davej@hera:agp2)$ export KERNEL=master.kernel.org:/pub/scm/linux/kernel/git/
> (18:47:43:davej@hera:agp2)$ git fetch $KERNEL/torvalds/linux-2.6 master:linus
> davej@master.kernel.org's password:
> Packing 35335 objects
> Unpacking 35335 objects
> 100% (35335/35335) done
> * committish: d27ba47e7e8c466c18983a1779d611f82d6a354f
> branch 'master' of master.kernel.org:/pub/scm/linux/kernel/git//torvalds/linux-2.6
> * refs/heads/linus: storing branch 'master' of master.kernel.org:/pub/scm/linux/kernel/git//torvalds/linux-2.6
>
> which looks ok, but then when I do the git log linus..HEAD, I get no output at all.
You've got the right "linus" commit.
However, are you aware that I did pull from you? If you don't have
anything new, "no output at all" is the right thing.
> *click*, ahh wait, I didn't have a 'linus' branch before I did that fetch.
> For the above to work, do I need there to be a 'linus' branch before
> I start making changes ? Or am I barking up the wrong tree ?
No, the above will have created the "linus" branch as needed.
Linus
^ permalink raw reply
* Re: Expected Behavior?
From: Jon Loeliger @ 2005-11-08 3:07 UTC (permalink / raw)
To: git
> It appears that as the everyday workhorse, using Daniel's
> git-merge-resolve is stable through git-merge have proven stable
> enough. So here is a question. Do people mind if 'git-resolve'
> and 'git-octopus' are dropped before 1.0? This means 2 less
> programs in your /usr/bin ;-).
It's OK with me. :-)
jdl
^ permalink raw reply
* Re: git-rev-tree
From: Dave Jones @ 2005-11-08 2:57 UTC (permalink / raw)
To: Linus Torvalds; +Cc: git
In-Reply-To: <Pine.LNX.4.64.0511071819510.3247@g5.osdl.org>
On Mon, Nov 07, 2005 at 06:33:30PM -0800, Linus Torvalds wrote:
> export KERNEL=master.kernel.org:/pub/scm/linux/kernel/git/
> git fetch $KERNEL/torvalds/linux-2.6 master:linus
>
> which will just fetch my "master" branch into the local "linus" branch.
>
> - then just do
>
> git log linus..HEAD
>
> and you'll see exactly what you wanted: what exists in your HEAD but
> not in mine.
>
> No complex script required.
Ok, I must be doing something totally bone-headed. Because this is what
I tried to do before I headed down the path of making that script work.
Doing the above yields ...
(18:47:37:davej@hera:agp2)$ export KERNEL=master.kernel.org:/pub/scm/linux/kernel/git/
(18:47:43:davej@hera:agp2)$ git fetch $KERNEL/torvalds/linux-2.6 master:linus
davej@master.kernel.org's password:
Packing 35335 objects
Unpacking 35335 objects
100% (35335/35335) done
* committish: d27ba47e7e8c466c18983a1779d611f82d6a354f
branch 'master' of master.kernel.org:/pub/scm/linux/kernel/git//torvalds/linux-2.6
* refs/heads/linus: storing branch 'master' of master.kernel.org:/pub/scm/linux/kernel/git//torvalds/linux-2.6
which looks ok, but then when I do the git log linus..HEAD, I get no output at all.
Whatever I'm doing wrong, I'm doing it consistently, as this happens
in all my trees both locally, and on k.o
*click*, ahh wait, I didn't have a 'linus' branch before I did that fetch.
For the above to work, do I need there to be a 'linus' branch before
I start making changes ? Or am I barking up the wrong tree ?
Dave
^ permalink raw reply
* [PATCH] Add bug isolation howto, scraped from Linus.
From: Jon Loeliger @ 2005-11-08 2:45 UTC (permalink / raw)
To: git
Signed-off-by: Jon Loeliger <jdl@freescale.com>
---
You know, eventually this will all be fully documented.
The trick is to catch Words To The Wise as the flow past you.
Documentation/howto/isolate-bugs-with-bisect.txt | 65 ++++++++++++++++++++++
1 files changed, 65 insertions(+), 0 deletions(-)
create mode 100644 Documentation/howto/isolate-bugs-with-bisect.txt
applies-to: 71213f57daeac18b52439d6d8acd5baba9bf05c7
4e0819ff782b33d149634a397fb539f4759ef1f4
diff --git a/Documentation/howto/isolate-bugs-with-bisect.txt b/Documentation/howto/isolate-bugs-with-bisect.txt
new file mode 100644
index 0000000..4009495
--- /dev/null
+++ b/Documentation/howto/isolate-bugs-with-bisect.txt
@@ -0,0 +1,65 @@
+From: Linus Torvalds <torvalds () osdl ! org>
+To: git@vger.kernel.org
+Date: 2005-11-08 1:31:34
+Subject: Real-life kernel debugging scenario
+Abstract: Short-n-sweet, Linus tells us how to leverage `git-bisect` to perform
+ bug isolation on a repository where "good" and "bad" revisions are known
+ in order to identify a suspect commit.
+
+
+How To Use git-bisect To Isolate a Bogus Commit
+===============================================
+
+The way to use "git bisect" couldn't be easier.
+
+Figure out what the oldest bad state you know about is (that's usually the
+head of "master", since that's what you just tried to boot and failed at).
+Also, figure out the most recent known-good commit (usually the _previous_
+kernel you ran: and if you've only done a single "pull" in between, it
+will be ORIG_HEAD).
+
+Then do
+
+ git bisect start
+ git bisect bad master <- mark "master" as the bad state
+ git bisect good ORIG_HEAD <- mark ORIG_HEAD as good (or
+ whatever other known-good
+ thing you booted laste)
+
+and at this point "git bisect" will churn for a while, and tell you what
+the mid-point between those two commits are, and check that state out as
+the head of the bew "bisect" branch.
+
+Compile and reboot.
+
+If it's good, just do
+
+ git bisect good <- mark current head as good
+
+otherwise, reboot into a good kernel instead, and do (surprise surprise,
+git really is very intuitive):
+
+ git bisect bad <- mark current head as bad
+
+and whatever you do, git will select a new half-way point. Do this for a
+while, until git tells you exactly which commit was the first bad commit.
+That's your culprit.
+
+It really works wonderfully well, except for the case where there was
+_another_ commit that broke something in between, like introduced some
+stupid compile error. In that case you should not mark that commit good or
+bad: you should try to find another commit close-by, and do a "git reset
+--hard <newcommit>" to try out _that_ commit instead, and then test that
+instead (and mark it good or bad).
+
+You can do "git bisect visualize" while you do all this to see what's
+going on by starting up gitk on the bisection range.
+
+Finally, once you've figured out exactly which commit was bad, you can
+then go back to the master branch, and try reverting just that commit:
+
+ git checkout master
+ git revert <bad-commit-id>
+
+to verify that the top-of-kernel works with that single commit reverted.
+
---
0.99.9.GIT
^ permalink raw reply related
* Re: Errors cloning over http -- git-clone and cg-clone fail to fetch a reachable object...
From: Martin Langhoff @ 2005-11-08 2:37 UTC (permalink / raw)
To: Nick Hengeveld; +Cc: Git Mailing List
In-Reply-To: <20051107171446.GA4070@reactrix.com>
On 11/8/05, Nick Hengeveld <nickh@reactrix.com> wrote:
> You might try this to see exactly what request/response headers
> curl thinks are passing back and forth.
It definitely looks like it's doing a few requests in parallel and
getting them mixed up. BTW, this repo is public and sitting on a box
that doubles up as kernel mirror -- feel free to hit it ;-)
> GET /git/moodle.git/objects/f0/6a06d24eee0b7819e2aaf48ad0e255301394e0 HTTP/1.1
Host: locke.catalyst.net.nz
Accept: */*
* Connected to locke.catalyst.net.nz (202.78.240.39) port 80
* Couldn't find host locke.catalyst.net.nz in the .netrc file, using defaults
* About to connect() to locke.catalyst.net.nz port 80
* Trying 202.78.240.39... > GET
/git/moodle.git/objects/d9/6d5ee03a225ab4e750fb864dbea35d42c51b8b
HTTP/1.1
Host: locke.catalyst.net.nz
Accept: */*
* Connected to locke.catalyst.net.nz (202.78.240.39) port 80
* The requested URL returned error: 404
* Closing connection #0
* The requested URL returned error: 404
* Closing connection #0
> GET /git/moodle.git/objects/5e/0e0d41f781d53344fa67b5e5a0138b586e2946 HTTP/1.1
Host: locke.catalyst.net.nz
Accept: */*
* The requested URL returned error: 404
* Closing connection #0
* The requested URL returned error: 404
* Closing connection #0
error: Unable to get pack file
http://locke.catalyst.net.nz/git/moodle.git//objects/pack/pack-9cbe4a5eb777d4ee535f08feb471e812208ed3a5.pack
The requested URL returned error: 404
error: Unable to find 7004cdf821ab5ddcded7819dea34015b0e84cd9a under
http://locke.catalyst.net.nz/git/moodle.git/
Cannot obtain needed blob 7004cdf821ab5ddcded7819dea34015b0e84cd9a
while processing commit b065a5cb7f757dd6e271249cb49e19e8c34b26ce.
cg-fetch: objects fetch failed
cg-clone: fetch failed
cheers,
martin
^ permalink raw reply
* Re: git-rev-tree
From: Linus Torvalds @ 2005-11-08 2:33 UTC (permalink / raw)
To: Dave Jones; +Cc: git
In-Reply-To: <20051108021232.GB10835@redhat.com>
On Mon, 7 Nov 2005, Dave Jones wrote:
>
> Can someone remind me what the deprecated git-rev-tree command did,
> or how this should be fixed up to use newer git commands?
It was basically the same as "git-rev-list", except:
- it output the date (as a raw number) in front, so pretty much everybody
ended up using "cut" to remove it, sometimes after sorting the output
numerically.
Sorting numerically is unnecessary with git-rev-list, since the output
is already sorted (not necessarily exactly by date, but by "recency"
and/or by other even stricter sorting rules)
- it was limited to a certain number of heads maximum (I forget, but I
think it was 16).
- it parsed the whole tree before outputting anything.
> I'm trying to get git-changes-script working, but all the
> variants I've found on the web use this deprecated tool.
The git-changes-script was pretty broken.
You're _much_ better off doing it by:
- fetch the "remote" branch into the local repository. The
"git-changes-script" thing required that you fetch the remote branch
into _another_ repository, but still local. These days, just use a
local branch in the same repo.
So, for example, tracking my tree
export KERNEL=master.kernel.org:/pub/scm/linux/kernel/git/
git fetch $KERNEL/torvalds/linux-2.6 master:linus
which will just fetch my "master" branch into the local "linus" branch.
- then just do
git log linus..HEAD
and you'll see exactly what you wanted: what exists in your HEAD but
not in mine.
No complex script required.
Now, I've told some people that the diffstat is just the same (ie using a
simple "git diff linus..HEAD | git-apply --stat") but that was because
I've been muching some really awesomely bad 'shrooms. Clearly that doesn't
work well at all, since it will show all the stuff I have in my branch
reversed (since your head doesn't have it).
The way to get a diff is really to do a merge, and throw the merge away
after creating the diff. Ie something like this should work:
git checkout -b merge-branch
git merge "dummy merge" master linus &&
git-diff linus.. | git-apply --stat
git checkout -f master
git branch -D merge-branch
which will also tell you if the merge failed (in which case you might not
want to send me a "please pull", but instead try the merge locally and fix
it up, and then try again)
All of the above is obviously totally untested.
Linus
^ permalink raw reply
* git-rev-tree
From: Dave Jones @ 2005-11-08 2:12 UTC (permalink / raw)
To: git
Can someone remind me what the deprecated git-rev-tree command did,
or how this should be fixed up to use newer git commands?
I'm trying to get git-changes-script working, but all the
variants I've found on the web use this deprecated tool.
Any clues ?
Dave
^ permalink raw reply
* Re: Real-life kernel debugging scenario
From: Linus Torvalds @ 2005-11-08 1:31 UTC (permalink / raw)
To: walt; +Cc: git
In-Reply-To: <dkosr7$f4s$1@sea.gmane.org>
On Mon, 7 Nov 2005, walt wrote:
>
> Okay. On rare occasions I get a kernel panic on reboot. So...
> I know that something Linus committed in the last 24 hours is
> responsible for the problem.
>
> The last two times this happened I was able to guess which
> commit caused the problem and I emailed the developer off-
> list and got the problem fixed very quickly. (This is why
> I love open-source software!)
>
> My worry: what happens when I'm not smart enough to guess
> which developer to email? My first instinct is to back out
> the most recent commits one-by-one until the bug goes away.
No. This is what "git bisect" is there for.
It works wonderfully well. To the point where I don't even try to be smart
about things: I've had two cases in the last month of merges that caused
problems for me, and instead of even trying to guess which patch it was, I
just bisected it.
> First: is this an optimal tactic?
>
> Second: how to back out individual commits using git or
> cogito? I suppose this is already spelled out in the docs,
> but I invite everyone to point me to the relevant places
> in the docs that have escaped my attention so far.
First, try "git bisect". It doesn't depend on backing out individual
commits, instead it starts a special "bisect" branch, and (as the name
implies) does a binary search within that branch to figure out what is
wrong.
The way to use "git bisect" couldn't be easier.
Figure out what the oldest bad state you know about is (that's usually the
head of "master", since that's what you just tried to boot and failed at).
Also, figure out the most recent known-good commit (usually the _previous_
kernel you ran: and if you've only done a single "pull" in between, it
will be ORIG_HEAD).
Then do
git bisect start
git bisect bad master <- mark "master" as the bad state
git bisect good ORIG_HEAD <- mark ORIG_HEAD as good (or
whatever other known-good
thing you booted laste)
and at this point "git bisect" will churn for a while, and tell you what
the mid-point between those two commits are, and check that state out as
the head of the bew "bisect" branch.
Compile and reboot.
If it's good, just do
git bisect good <- mark current head as good
otherwise, reboot into a good kernel instead, and do (surprise surprise,
git really is very intuitive):
git bisect bad <- mark current head as bad
and whatever you do, git will select a new half-way point. Do this for a
while, until git tells you exactly which commit was the first bad commit.
That's your culprit.
It really works wonderfully well, except for the case where there was
_another_ commit that broke something in between, like introduced some
stupid compile error. In that case you should not mark that commit good or
bad: you should try to find another commit close-by, and do a "git reset
--hard <newcommit>" to try out _that_ commit instead, and then test that
instead (and mark it good or bad).
You can do "git bisect visualize" while you do all this to see what's
going on by starting up gitk on the bisection range.
Finally, once you've figured out exactly which commit was bad, you can
then go back to the master branch, and try reverting just that commit:
git checkout master
git revert <bad-commit-id>
to verify that the top-of-kernel works with that single commit reverted.
Linus
^ permalink raw reply
* Re: Real-life kernel debugging scenario
From: Junio C Hamano @ 2005-11-08 1:30 UTC (permalink / raw)
To: walt; +Cc: git
In-Reply-To: <dkosr7$f4s$1@sea.gmane.org>
walt <wa1ter@myrealbox.com> writes:
> First: is this an optimal tactic?
Not if you are a git user.
> Second: how to back out individual commits using git or
> cogito? I suppose this is already spelled out in the docs,
> but I invite everyone to point me to the relevant places
> in the docs that have escaped my attention so far.
git-bisect(1).
^ permalink raw reply
* Re: Real-life kernel debugging scenario
From: David Lang @ 2005-11-08 0:59 UTC (permalink / raw)
To: walt; +Cc: git
In-Reply-To: <dkosr7$f4s$1@sea.gmane.org>
On Mon, 7 Nov 2005, walt wrote:
> My worry: what happens when I'm not smart enough to guess
> which developer to email? My first instinct is to back out
> the most recent commits one-by-one until the bug goes away.
>
> First: is this an optimal tactic?
it will work, but it's not optimal. this is exactly what git bisect is
designed for.
you tell it that the prior night's version was good and the current
version is bad. It picks a version 'halfway' in between the two and you
test that. tell git if the test failed or not and it will then give
you the next one to try. repeat until you identify exactly which commit
triggers the problem.
unfortunantly I can't trivially point you at the right place in the docs.
David Lang
--
There are two ways of constructing a software design. One way is to make it so simple that there are obviously no deficiencies. And the other way is to make it so complicated that there are no obvious deficiencies.
-- C.A.R. Hoare
^ permalink raw reply
* Re: Comments on recursive merge..
From: Junio C Hamano @ 2005-11-08 0:59 UTC (permalink / raw)
To: Linus Torvalds; +Cc: git, Fredrik Kuivinen
In-Reply-To: <Pine.LNX.4.64.0511071629270.3247@g5.osdl.org>
Linus Torvalds <torvalds@osdl.org> writes:
> On Mon, 7 Nov 2005, Junio C Hamano wrote:
>>
>> This is the first time I see you pleased by something in git
>> that was done without very close supervision from you.
>
> That sounds like a backhanded way of saying that I'm micromanagering,
> picky and difficult to work with ;)
Sorry, that is not what I meant to say at all.
You used to micromanage, but it was _very_ good for git back
then. I admit that only once I found you too picky and
difficult to work with while I was fixing a bad premature-free
bug in the diffcore-rename code, but overall your attention to
detail well paid off.
Since I inherited the project, we added quite a lot of stuff,
but I was still unsure if we are making good progress, or just
stagnating with only small enhancements and obvious fixes.
But Fredrik merge turns out to be a spectacular success as you
found out, which is a triumph for Fredrik, but at the same time
it means I was not doing too bad myself ;-).
^ permalink raw reply
* Real-life kernel debugging scenario
From: walt @ 2005-11-08 0:51 UTC (permalink / raw)
To: git
This describes a real problem I've had twice in the last two
years while tracking Linus's kernel tree:
I update my local kernel sources every morning using cg-update
(formerly bk-pull) and compile and install and reboot the new
kernel.
Okay. On rare occasions I get a kernel panic on reboot. So...
I know that something Linus committed in the last 24 hours is
responsible for the problem.
The last two times this happened I was able to guess which
commit caused the problem and I emailed the developer off-
list and got the problem fixed very quickly. (This is why
I love open-source software!)
My worry: what happens when I'm not smart enough to guess
which developer to email? My first instinct is to back out
the most recent commits one-by-one until the bug goes away.
First: is this an optimal tactic?
Second: how to back out individual commits using git or
cogito? I suppose this is already spelled out in the docs,
but I invite everyone to point me to the relevant places
in the docs that have escaped my attention so far.
Thanks!
^ permalink raw reply
* Re: Comments on recursive merge..
From: Linus Torvalds @ 2005-11-08 0:33 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Fredrik Kuivinen
In-Reply-To: <7vll00ov2l.fsf@assigned-by-dhcp.cox.net>
On Mon, 7 Nov 2005, Junio C Hamano wrote:
>
> This is the first time I see you pleased by something in git
> that was done without very close supervision from you.
That sounds like a backhanded way of saying that I'm micromanagering,
picky and difficult to work with ;)
> Another thing to consider is if it is fast enough for everyday
> trivial merges.
Hmm. True. The _really_ trivial in-index case triggers for me pretty
often, but I haven't done any statistics. It might be only 50% of the
time.
Is the recursive thing noticeably slower for the "easy" cases (ie things
that the old regular resolve strategy does well)?
It's certainly an option to just do what I just did, namely use the
default one until it breaks, and then just do "git reset --hard" and re-do
the pull with "-s recursive". A bit sad, and it would be good to have
coverage on the recursive strategy..
Linus
^ permalink raw reply
* Re: Comments on recursive merge..
From: Junio C Hamano @ 2005-11-08 0:13 UTC (permalink / raw)
To: Linus Torvalds; +Cc: git, Fredrik Kuivinen
In-Reply-To: <20051107225807.GA10937@c165.ib.student.liu.se>
Fredrik Kuivinen <freku045@student.liu.se> writes:
> On Mon, Nov 07, 2005 at 08:48:06AM -0800, Linus Torvalds wrote:
>>
>> Guys,
>>
>> I just hit my first real rename conflict, and very timidly tried the
>> "recursive" strategy in the hopes that I wouldn't need to do things by
>> hand.
>>
>> It resolved things beautifully. Good job.
>
> I'm glad that it worked.
This is the first time I see you pleased by something in git
that was done without very close supervision from you. All the
credits for this one goes to Fredrik, of course, but it is a
small victory for me as the maintainer as well, and I am very
happy about it.
>> ..., I'd almost suggest making "recursive" the default. I'm a
>> bit nervous about it, but knowing how it works would probably
>> put most of that to rest.
Another thing to consider is if it is fast enough for everyday
trivial merges.
In any case, I've been thinking about teaching git-merge to look
into .git/config to make it overridable which strategy to use by
default. This would eliminate the hardcoded 'resolve for
two-head, octopus for more' rule from git-pull. Then we could
ship git-merge with the default rule of 'recursive for two-head,
octopus for more', and if it turns out to be premature, you can
update your config file to use resolve for two-head case while
we sort things out. That way, recursive would get wider test
coverage, and people who really need a working merge this minute
can choose to run resolve in emergency without specifying '-s
resolve' on the command line of 'git pull' every time.
^ permalink raw reply
* Re: [PATCH] merge-recursive: Only print relevant rename messages
From: Junio C Hamano @ 2005-11-07 23:54 UTC (permalink / raw)
To: Fredrik Kuivinen; +Cc: Linus Torvalds, Git Mailing List
In-Reply-To: <20051107231944.GA11327@c165.ib.student.liu.se>
Fredrik Kuivinen <freku045@student.liu.se> writes:
> @@ -178,7 +181,7 @@ def mergeFile(oPath, oSha, oMode, aPath,
> sha = bSha
> else:
> if aSha != oSha and bSha != oSha:
> - merge = True
> + merge = MERGE_TRIVIAL
The rest looks good to me, but are you sure about this part? I
have a feeling that the above "and" should be "or", meaning, we
check to see if there is _any_ change, and default to TRIVIAL,
but later we would find that we need a real merge and then
promote it to MERGE_3WAY.
^ permalink raw reply
* Re: [PATCH] Cogito: Support for implicit remote branches in cloned repositories
From: Junio C Hamano @ 2005-11-07 23:45 UTC (permalink / raw)
To: Petr Baudis; +Cc: Linus Torvalds, git
In-Reply-To: <20051107232122.GZ1431@pasky.or.cz>
Petr Baudis <pasky@suse.cz> writes:
> This loses the pretty nice property that 'origin' refers to the HEAD
> branch of the remote repository,...
I think the code actually honors what your HEAD points at;
I did not go into that detail in the above description.
>> *1* I say "by default" here; I think there should be an
>> operating mode for git clone that acts as a straight copy, not
>> even the current "HEAD" -> "origin" renaming. In fact that is
>> what you do with low-level git-clone-pack.
>
> What would it be useful for?
Cheap back-up, Linus style.
^ permalink raw reply
* Re: Problem in update from the linux-2.6 repository
From: Nick Hengeveld @ 2005-11-07 23:22 UTC (permalink / raw)
To: Marcel Holtmann; +Cc: git
In-Reply-To: <1131401931.5824.149.camel@blade>
On Mon, Nov 07, 2005 at 11:18:51PM +0100, Marcel Holtmann wrote:
> forget about this thing. The reason for this problem was the kernel.org
> mirroring and the repository wasn't in a sane state. However it would be
> great if we can detect this somehow.
Is this an issue with the two servers (or virtual servers?) behind the
kernel.org DNS name being out of sync?
Would it make sense to configure the individual servers to be http-alternates
of each other?
--
For a successful technology, reality must take precedence over public
relations, for nature cannot be fooled.
^ permalink raw reply
* Re: [PATCH] Cogito: Support for implicit remote branches in cloned repositories
From: Petr Baudis @ 2005-11-07 23:21 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Linus Torvalds, git
In-Reply-To: <7v8xw216q9.fsf@assigned-by-dhcp.cox.net>
Dear diary, on Sun, Nov 06, 2005 at 10:11:10AM CET, I got a letter
where Junio C Hamano <junkio@cox.net> told me that...
> Just for discussion, I'd suggest a less structured approach as
> an alternative, and making it just a convention.
The problem is that at least Cogito defaults to the 'origin' branch when
pulling/merging, so if you'll have 'origin/master' instead of 'origin',
I will have to hack that around. So it's not _just_ a convention but
something reflected in some code as well.
> - clone by default [*1*] creates .git/refs/heads/origin/*
> heads; your "master" becomes my "origin/master".
> Interestingly but logically, if your repository was cloned
> from somewhere else, you would have "origin/master", which
> would become my "origin/origin/master".
This loses the pretty nice property that 'origin' refers to the HEAD
branch of the remote repository, no matter how is it called (well, it is
nice as long as the remote repository doesn't _switch_ the HEAD to some
non-superset branch; but repositories you're cloning from shouldn't do
that). So you should either have origin/HEAD locally, or make the
'master' branch more "socially canonical".
> *1* I say "by default" here; I think there should be an
> operating mode for git clone that acts as a straight copy, not
> even the current "HEAD" -> "origin" renaming. In fact that is
> what you do with low-level git-clone-pack.
What would it be useful for?
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
VI has two modes: the one in which it beeps and the one in which
it doesn't.
^ permalink raw reply
* [PATCH] merge-recursive: Only print relevant rename messages
From: Fredrik Kuivinen @ 2005-11-07 23:19 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Junio C Hamano, Fredrik Kuivinen, Git Mailing List
In-Reply-To: <Pine.LNX.4.64.0511070848440.3193@g5.osdl.org>
On Mon, Nov 07, 2005 at 08:56:07AM -0800, Linus Torvalds wrote:
>
> Btw, one thing that it does is print out too much information.
>
> In particular, I had renames on both sides of the merge (in case anybody
> wants to see which one I'm talking about: it's the current top-of-head
> commit in the kernel archives: 333c47c847c90aaefde8b593054d9344106333b5).
>
> Now, renames that you've done yourself you really don't want to hear
> about, at least if the other side didn't change anything in that file.
>
> Renames that the _other_ side has done (the one you're merging) you may or
> may not want to know about, regardless of whether they happened to files
> that are changed. But since "git pull" will do a "git-apply --stat" at the
> end and show the renames there, I'd argue that the merge strategy itself
> should be quiet about any renames that are trivial.
>
> So how about talking about renames only if you end up also doing a
> file-level merge? As it is, doing the merge talked about renames that I
> had merged earlier in my own branch, which is just confusing.
>
Sounds like a good idea. How about something like the following?
--
It isn't really interesting to know about the renames that have
already been committed to the branch you are working on. Furthermore,
the 'git-apply --stat' at the end of git-(merge|pull) will tell us
about any renames in the other branch.
With this commit only renames which require a file-level merge will
be printed.
Signed-off-by: Fredrik Kuivinen <freku045@student.liu.se>
---
git-merge-recursive.py | 22 +++++++++++++++-------
1 files changed, 15 insertions(+), 7 deletions(-)
applies-to: 5af1b5b93257ecfe993bb24975bf596faa342758
89c029b439603630a53ee4e4d0cb7931111afd2a
diff --git a/git-merge-recursive.py b/git-merge-recursive.py
index 626d854..9983cd9 100755
--- a/git-merge-recursive.py
+++ b/git-merge-recursive.py
@@ -162,10 +162,13 @@ def mergeTrees(head, merge, common, bran
# Low level file merging, update and removal
# ------------------------------------------
+MERGE_NONE = 0
+MERGE_TRIVIAL = 1
+MERGE_3WAY = 2
def mergeFile(oPath, oSha, oMode, aPath, aSha, aMode, bPath, bSha, bMode,
branch1Name, branch2Name):
- merge = False
+ merge = MERGE_NONE
clean = True
if stat.S_IFMT(aMode) != stat.S_IFMT(bMode):
@@ -178,7 +181,7 @@ def mergeFile(oPath, oSha, oMode, aPath,
sha = bSha
else:
if aSha != oSha and bSha != oSha:
- merge = True
+ merge = MERGE_TRIVIAL
if aMode == oMode:
mode = bMode
@@ -207,7 +210,8 @@ def mergeFile(oPath, oSha, oMode, aPath,
os.unlink(orig)
os.unlink(src1)
os.unlink(src2)
-
+
+ merge = MERGE_3WAY
clean = (code == 0)
else:
assert(stat.S_ISLNK(aMode) and stat.S_ISLNK(bMode))
@@ -577,14 +581,16 @@ def processRenames(renamesA, renamesB, b
updateFile(False, ren1.dstSha, ren1.dstMode, dstName1)
updateFile(False, ren2.dstSha, ren2.dstMode, dstName2)
else:
- print 'Renaming', fmtRename(path, ren1.dstName)
[resSha, resMode, clean, merge] = \
mergeFile(ren1.srcName, ren1.srcSha, ren1.srcMode,
ren1.dstName, ren1.dstSha, ren1.dstMode,
ren2.dstName, ren2.dstSha, ren2.dstMode,
branchName1, branchName2)
- if merge:
+ if merge or not clean:
+ print 'Renaming', fmtRename(path, ren1.dstName)
+
+ if merge == MERGE_3WAY:
print 'Auto-merging', ren1.dstName
if not clean:
@@ -653,14 +659,16 @@ def processRenames(renamesA, renamesB, b
tryMerge = True
if tryMerge:
- print 'Renaming', fmtRename(ren1.srcName, ren1.dstName)
[resSha, resMode, clean, merge] = \
mergeFile(ren1.srcName, ren1.srcSha, ren1.srcMode,
ren1.dstName, ren1.dstSha, ren1.dstMode,
ren1.srcName, srcShaOtherBranch, srcModeOtherBranch,
branchName1, branchName2)
- if merge:
+ if merge or not clean:
+ print 'Renaming', fmtRename(ren1.srcName, ren1.dstName)
+
+ if merge == MERGE_3WAY:
print 'Auto-merging', ren1.dstName
if not clean:
^ permalink raw reply related
* Re: git-daemon enabled on kernel.org
From: Petr Baudis @ 2005-11-07 23:11 UTC (permalink / raw)
To: H. Peter Anvin; +Cc: Git Mailing List
In-Reply-To: <43554D4F.7040403@zytor.com>
Dear diary, on Tue, Oct 18, 2005 at 09:30:23PM CEST, I got a letter
where "H. Peter Anvin" <hpa@zytor.com> told me that...
> I consider this experimental so far, and if it imposes an unacceptable
> load I'll have to disable it. It currently runs with an inetd-imposed
> limits of 10 instances per server.
I'm curious - how well does it do wrt. the load so far? Do you have any
statistics about the number of users and how CPU-intensive is it?
Thanks,
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
VI has two modes: the one in which it beeps and the one in which
it doesn't.
^ permalink raw reply
* Re: Comments on recursive merge..
From: Fredrik Kuivinen @ 2005-11-07 22:58 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Junio C Hamano, Fredrik Kuivinen, Git Mailing List
In-Reply-To: <Pine.LNX.4.64.0511070837530.3193@g5.osdl.org>
On Mon, Nov 07, 2005 at 08:48:06AM -0800, Linus Torvalds wrote:
>
> Guys,
>
> I just hit my first real rename conflict, and very timidly tried the
> "recursive" strategy in the hopes that I wouldn't need to do things by
> hand.
>
> It resolved things beautifully. Good job.
I'm glad that it worked.
> My only worry is that I don't read python, so I don't really know how it
> does what it does, which makes me nervous. Can somebody (Fredrik?) add
> some documentation about the merge strategy and how it works.
I will write something up.
> Considering that the stupid resolve strategy really requires you to know
> how git works when rename conflicts happen (things left in unmerged state
> are really quite hard to handle by hand unless you know exactly what
> you're doing), I'd almost suggest making "recursive" the default. I'm a
> bit nervous about it, but knowing how it works would probably put most of
> that to rest.
It would be great if the recursive strategy could get some more
testing. I have tested it on a thousand commits or so in a few kernel
repositories and haven't found any bugs, but it could be due to errors
in the test setup, testing the wrong repositories or just being lucky. Some
real-world testing would be great.
- Fredrik
^ permalink raw reply
* Re: git versus CVS (versus bk)
From: Petr Baudis @ 2005-11-07 22:56 UTC (permalink / raw)
To: Joel Becker
Cc: Martin Langhoff, Linus Torvalds, Johannes Schindelin, walt, git
In-Reply-To: <20051101091533.GB11618@pasky.or.cz>
Dear diary, on Tue, Nov 01, 2005 at 10:15:33AM CET, I got a letter
where Petr Baudis <pasky@suse.cz> told me that...
> That said, with a big warning, I would be willing to do something like
> cg-merge -s and cg-update -s (s as squash), with a big warning that this
> is suitable only for topical branches. And I think it'd be still much
> better to spend the work making StGIT able to track history of changes
> to a particular patch.
FWIW, cg-merge -s and cg-update -s is supported now.
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
VI has two modes: the one in which it beeps and the one in which
it doesn't.
^ permalink raw reply
* Re: [PATCH] Support for passing path to custom map in git-shortlog.perl
From: Junio C Hamano @ 2005-11-07 22:44 UTC (permalink / raw)
To: Petr Baudis; +Cc: git
In-Reply-To: <20051107215412.GU1431@pasky.or.cz>
Petr Baudis <pasky@suse.cz> writes:
> ... I think it can be useful - either when you
> want to work on readonly tree, or when you want to support custom
> mailmap in addition to the default project's one without interference...
Ah, that sort of makes sense. On the other hand you could run
git-shortlog in a separate directory right now by piping the
git-log output to "(cd somewhere && git-shortlog)", so...
Come to think of it, why not make git-shortlog take the same set
of parameters as git-log takes (perhaps except --pretty)? Then
the issues you raised starts to make sense and we would
certainly want -m MAPFILE option there.
^ permalink raw reply
* Re: Problem in update from the linux-2.6 repository
From: Marcel Holtmann @ 2005-11-07 22:28 UTC (permalink / raw)
To: Petr Baudis; +Cc: git
In-Reply-To: <20051107222353.GV1431@pasky.or.cz>
Hi Petr,
> > > I run into a weird problem when trying to update my clone of the
> > > linux-2.6 repository from Linus:
> > >
> > > ---
> > > # cg-update -f
> > > 17:09:00 URL:http://www.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git/HEAD [41/41] -> "refs/heads/.origin-fetching" [1]
> > > Getting alternates list
> > > Getting pack list
> > > error: Unable to find 2ed5e6d09e266bd2288d49aaaf240ed8c468c13c under http://www.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git/
> > >
> > > Cannot obtain needed object 2ed5e6d09e266bd2288d49aaaf240ed8c468c13c
> > > while processing commit 0000000000000000000000000000000000000000.
> > > cg-fetch: objects fetch failed
> > > ---
> >
> > forget about this thing. The reason for this problem was the kernel.org
> > mirroring and the repository wasn't in a sane state. However it would be
> > great if we can detect this somehow.
>
> well, we did detect this and error out. ;-) What else would you like
> GIT/Cogito to do? Anything particular that could make this less
> confusing?
I actually have no real idea, but the "object fetch failed" doesn't tell
me anything besides that an object seems to be missing. Maybe this is a
problem we have to live with when using the kernel.org mirroring.
Regards
Marcel
^ permalink raw reply
* Re: Problem in update from the linux-2.6 repository
From: Petr Baudis @ 2005-11-07 22:23 UTC (permalink / raw)
To: Marcel Holtmann; +Cc: git
In-Reply-To: <1131401931.5824.149.camel@blade>
Hi,
Dear diary, on Mon, Nov 07, 2005 at 11:18:51PM CET, I got a letter
where Marcel Holtmann <marcel@holtmann.org> told me that...
> > I run into a weird problem when trying to update my clone of the
> > linux-2.6 repository from Linus:
> >
> > ---
> > # cg-update -f
> > 17:09:00 URL:http://www.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git/HEAD [41/41] -> "refs/heads/.origin-fetching" [1]
> > Getting alternates list
> > Getting pack list
> > error: Unable to find 2ed5e6d09e266bd2288d49aaaf240ed8c468c13c under http://www.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git/
> >
> > Cannot obtain needed object 2ed5e6d09e266bd2288d49aaaf240ed8c468c13c
> > while processing commit 0000000000000000000000000000000000000000.
> > cg-fetch: objects fetch failed
> > ---
>
> forget about this thing. The reason for this problem was the kernel.org
> mirroring and the repository wasn't in a sane state. However it would be
> great if we can detect this somehow.
well, we did detect this and error out. ;-) What else would you like
GIT/Cogito to do? Anything particular that could make this less
confusing?
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
VI has two modes: the one in which it beeps and the one in which
it doesn't.
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox