* [PATCH] merge-recursive implicitely depends on trust_executable_bit
From: Alex Riesen @ 2006-11-06 10:38 UTC (permalink / raw)
To: git; +Cc: Junio C Hamano
[-- Attachment #1: Type: text/plain, Size: 134 bytes --]
Read the configuration in to get core.filemode value for this
particular repository.
Signed-off-by: Alex Riesen <raa.lkml@gmail.com>
[-- Attachment #2: 0001-merge-recursive-implicitely-depends-on-trust_executable_bit-core.filemode.txt --]
[-- Type: text/plain, Size: 806 bytes --]
From 193ac65259b5de19fae1a1bd5d4adb55988086f6 Mon Sep 17 00:00:00 2001
From: Alex Riesen <raa.lkml@gmail.com>
Date: Mon, 6 Nov 2006 09:24:17 +0100
Subject: [PATCH] merge-recursive implicitely depends on trust_executable_bit (core.filemode).
Read the configuration in to get its value for this particular repository
---
merge-recursive.c | 1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/merge-recursive.c b/merge-recursive.c
index 2ba43ae..c81048d 100644
--- a/merge-recursive.c
+++ b/merge-recursive.c
@@ -1308,6 +1308,7 @@ int main(int argc, char *argv[])
const char *branch1, *branch2;
struct commit *result, *h1, *h2;
+ git_config(git_default_config); /* core.filemode */
original_index_file = getenv("GIT_INDEX_FILE");
if (!original_index_file)
--
1.4.3.3.gb2828
^ permalink raw reply related
* Re: git bug? + question
From: Andy Whitcroft @ 2006-11-06 9:53 UTC (permalink / raw)
To: Josef Weidendorfer
Cc: Shawn Pearce, Sean, Junio C Hamano, Miles Bader, git,
Karl Hasselström
In-Reply-To: <200611041852.23867.Josef.Weidendorfer@gmx.de>
Josef Weidendorfer wrote:
> On Saturday 04 November 2006 06:03, Shawn Pearce wrote:
>> After reading your reply you are probably correct. I can see there
>> may be workflows that want every remote branch also created as a
>> local branch.
>>
>> I could certainly live with a command line option to clone, e.g.:
>>
>> git clone --only vmdvt,vmtip user@host:/path...
>
> Still missing here: What branch should be checked out after
> cloning?
Does any need to be checked out? Or perhap I should put it another way,
when we make a virgin repository we default to master checked out but
its not joined to the DAG. Perhaps we can just init-db and fetch the
specified branches and we are done. The user will then checkout things
as they need and if they do not need master they can lose it.
>
> Perhaps it is better to extend git-checkout to allow to do the
> correct thing when the user specifies a read-only branch from
> refs/remotes. E.g. with refs/remotes/origin/vmdvt,
>
> git checkout origin/vmdvt
>
> should create a new local branch refs/heads/vmdvt which forks
> from remotes/origin/vmdvt (and abort with
> error if refs/heads/vmdvt already exists without being the local
> development branch for remotes/origin/vmdvt), add to .git/config
>
> [branch "vmdvt"]
> remote = origin
> merge = remotes/origin/vmdvt
>
> and switch to this new created branch.
>
> Given this addition to git-checkout, the implicit default
> action after cloning with --use-separate-remote should be
>
> git checkout origin/master
>
> where "master" can be changed on the git-clone command line
> to another branch, e.g. "--checkout vmdvt".
>
> IMHO, this addition to git-checkout would make it a lot
> easier to work with --use-separate-remote, as there,
> every branch other the master is read-only.
>
> And if you have two remote repositories with a master branch
> each, and you want to develop locally on both, this could
> be accomplished with
>
> git checkout -b othermaster remotes/otherrepo/master
-apw
^ permalink raw reply
* [PATCH] git-pickaxe -C -C -C
From: Junio C Hamano @ 2006-11-06 9:08 UTC (permalink / raw)
To: git
Three -C options makes the command to look for copied lines from _any_
existing file in the parent commit, not just changed files.
This is of course _very_ expensive.
Some numbers and observations.
* git-pickaxe -C revision.c
2.22user 0.02system 0:02.24elapsed 100%CPU (0avgtext+0avgdata 0maxresident)k
0inputs+0outputs (0major+5263minor)pagefaults 0swaps
num read blob 486
* git-pickaxe -C -C -C revision.c
35.42user 0.27system 0:37.66elapsed 94%CPU (0avgtext+0avgdata 0maxresident)k
0inputs+0outputs (14major+115543minor)pagefaults 0swaps
num read blob 43277
Comparing the output from the above two, with this option, it
finds that some lines were copied from diff.c, diff-tree.c and
merge-cache.c; they are obvious patterns justifiably repeated.
- list of parameters to a function (ll. 214-217, 247-249);
- definitions of local variables (ll. 260-263);
- loops over all cache entries (ll. 581-584).
This change probably falls into the category of "I did this not
because it is useful in practice but just because I could".
Nevertheless, looking at the output was very interesting.
Signed-off-by: Junio C Hamano <junkio@cox.net>
---
builtin-pickaxe.c | 10 +++++++---
1 files changed, 7 insertions(+), 3 deletions(-)
diff --git a/builtin-pickaxe.c b/builtin-pickaxe.c
index f12b2d4..619a8c6 100644
--- a/builtin-pickaxe.c
+++ b/builtin-pickaxe.c
@@ -19,7 +19,7 @@
#include <sys/time.h>
static char pickaxe_usage[] =
-"git-pickaxe [-c] [-l] [-t] [-f] [-n] [-p] [-L n,m] [-S <revs-file>] [-M] [-C] [-C] [commit] [--] file\n"
+"git-pickaxe [-c] [-l] [-t] [-f] [-n] [-p] [-L n,m] [-S <revs-file>] [-M] [-C] [-C] [-C] [commit] [--] file\n"
" -c, --compatibility Use the same output mode as git-annotate (Default: off)\n"
" -l, --long Show long commit SHA1 (Default: off)\n"
" -t, --time Show raw timestamp (Default: off)\n"
@@ -48,6 +48,7 @@ static int num_commits;
#define PICKAXE_BLAME_MOVE 01
#define PICKAXE_BLAME_COPY 02
#define PICKAXE_BLAME_COPY_HARDER 04
+#define PICKAXE_BLAME_COPY_HARDEST 010
/*
* blame for a blame_entry with score lower than these thresholds
@@ -885,8 +886,9 @@ static int find_copy_in_parent(struct sc
* and this code needs to be after diff_setup_done(), which
* usually makes find-copies-harder imply copy detection.
*/
- if ((opt & PICKAXE_BLAME_COPY_HARDER) &&
- (!porigin || strcmp(target->path, porigin->path)))
+ if (((opt & PICKAXE_BLAME_COPY_HARDER) &&
+ (!porigin || strcmp(target->path, porigin->path))) ||
+ (opt & PICKAXE_BLAME_COPY_HARDEST))
diff_opts.find_copies_harder = 1;
diff_tree_sha1(parent->tree->object.sha1,
@@ -1569,6 +1571,8 @@ int cmd_pickaxe(int argc, const char **a
blame_move_score = parse_score(arg+2);
}
else if (!strncmp("-C", arg, 2)) {
+ if (opt & PICKAXE_BLAME_COPY_HARDER)
+ opt |= PICKAXE_BLAME_COPY_HARDEST;
if (opt & PICKAXE_BLAME_COPY)
opt |= PICKAXE_BLAME_COPY_HARDER;
opt |= PICKAXE_BLAME_COPY | PICKAXE_BLAME_MOVE;
--
1.4.3.4.g9f05
^ permalink raw reply related
* Re: git reset --soft a merged commit
From: Jakub Narebski @ 2006-11-06 9:01 UTC (permalink / raw)
To: git
In-Reply-To: <fcaeb9bf0611052048r11816e76p88d568e3478c354b@mail.gmail.com>
Nguyen Thai Ngoc Duy wrote:
> I did "git reset --soft HEAD~1" where HEAD is a merged commit and
> committed again (nothing changed). The new commit was not recorded as
> a merged commit. Is it intentional?
Yes, you have chosen to go back to 1st parent. The information about other
parents got lost.
If you want to correct commit, even if it is merge commit, use
git commit --amend
instead.
Or you can muck with MERGE_HEAD instead.
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
^ permalink raw reply
* "git clone" can't clone a gitweb URL
From: Liu Yubao @ 2006-11-06 8:32 UTC (permalink / raw)
To: git
$ git clone http://repo.or.cz/w/i18n.git
error: Can't lock ref
rm: cannot remove directory `i18n/.git/clone-tmp': Directory not emp
ty
At last I found the URL was a gitweb URL not for mirroring.
It's better git provides clear information like "This is maybe a
gitweb URL, view it in web browser for more information", or
gitweb can send a redirection response to git client. Even more,
git-daemon also can send redirection response to tell git client
that the service is offline temporarily and it can use an alternative
^ permalink raw reply
* Re: [PATCH] Add a MIME-Version header to e-mails
From: Karl Hasselström @ 2006-11-06 7:56 UTC (permalink / raw)
To: Catalin Marinas; +Cc: git
In-Reply-To: <20061106074532.10376.60478.stgit@localhost>
On 2006-11-06 08:45:32 +0100, Karl Hasselström wrote:
> OK, this is a test to see if adding MIME-Version makes the problem
> go away. I don't have any other way to test this than sending a
> patch to the list. :-)
All right, it seems to have worked! When I send patches to myself,
they arrive still 8bit-encoded, and when I get them through the list,
they have been properly QP-encoded by whatever part of the chain
didn't like 8bit.
Catalin, this should replace the QP-encoding patch. (But not the
RFC2047-encoding patch -- the headers are required to always be ascii,
if I've not misunderstood something.)
Thanks everyone!
--
Karl Hasselström, kha@treskal.com
^ permalink raw reply
* [PATCH] Add a MIME-Version header to e-mails
From: Karl Hasselström @ 2006-11-06 7:45 UTC (permalink / raw)
To: Catalin Marinas; +Cc: git
In-Reply-To: <eile19$p7r$1@sea.gmane.org>
From: Karl Hasselström <kha@treskal.com>
This is required by some mail servers that want to change the transfer
encoding of the mail.
Signed-off-by: Karl Hasselström <kha@treskal.com>
---
OK, this is a test to see if adding MIME-Version makes the problem go
away. I don't have any other way to test this than sending a patch to
the list. :-)
stgit/commands/mail.py | 12 +++++-------
1 files changed, 5 insertions(+), 7 deletions(-)
diff --git a/stgit/commands/mail.py b/stgit/commands/mail.py
index 45f7438..c428d67 100644
--- a/stgit/commands/mail.py
+++ b/stgit/commands/mail.py
@@ -271,13 +271,11 @@ def __get_signers_list(msg):
return addr_list
def __build_extra_headers():
- """Build extra headers like content-type etc.
- """
- headers = 'Content-Type: text/plain; charset=utf-8; format=fixed\n'
- headers += 'Content-Transfer-Encoding: 8bit\n'
- headers += 'User-Agent: StGIT/%s\n' % version.version
-
- return headers
+ """Build extra headers like content-type etc."""
+ return ('MIME-Version: 1.0\n'
+ 'Content-Type: text/plain; charset=utf-8; format=fixed\n'
+ 'Content-Transfer-Encoding: 8bit\n'
+ 'User-Agent: StGIT/%s\n' % version.version)
def edit_message(msg):
^ permalink raw reply related
* Re: how-to "backup" a repository
From: Junio C Hamano @ 2006-11-06 6:21 UTC (permalink / raw)
To: Wink Saville; +Cc: git, Shawn Pearce
In-Reply-To: <454ED27F.8060106@saville.com>
Wink Saville <wink@saville.com> writes:
> This sounds easy enough, but how-to "create a remote"?
> I looked in .git/remotes and see origin which contains:
>
> URL: git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git
> Pull: refs/heads/master:refs/heads/origin
>
> But where is the syntax defined?
man git-push -- where else ;-)?
http://www.kernel.org/pub/software/scm/git/docs/git-push.html
^ permalink raw reply
* Re: how-to "backup" a repository
From: Shawn Pearce @ 2006-11-06 6:18 UTC (permalink / raw)
To: Wink Saville; +Cc: git
In-Reply-To: <454ED27F.8060106@saville.com>
Wink Saville <wink@saville.com> wrote:
> This sounds easy enough, but how-to "create a remote"?
> I looked in .git/remotes and see origin which contains:
>
> URL: git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git
> Pull: refs/heads/master:refs/heads/origin
>
> But where is the syntax defined?
See http://www.kernel.org/pub/software/scm/git/docs/git-push.html#URLS
> Also, how do I setup git on my server so that it becomes a server?
So long as you can ssh to it and Git is installed in your PATH then
there's nothing else to do; Git will login via SSH and execute Git
on the remote side to run the server.
--
^ permalink raw reply
* Re: how-to "backup" a repository
From: Wink Saville @ 2006-11-06 6:13 UTC (permalink / raw)
To: Shawn Pearce; +Cc: git
In-Reply-To: <20061106055224.GA23126@spearce.org>
Shawn Pearce wrote:
> Wink Saville <wink@saville.com> wrote:
>> I've been working with git for a little while, but still very
>> much a neophyte. One thing I'd like to do is be able to backup
>> my work on a server located on my network.
>>
>> Currently I have cloned the Linux 2.6 tree on my personal computer
>> and have been backing it up by tar'ing the subdirectory with the
>> cloned repository and then using scp to copy it to my server.
>>
>> I suspect there is a better way, probably using git itself:)
>>
>> How is the typically handled?
>
> Create a remote (in .git/remotes) which refers to your backup
> location. Then use 'git push' to push your branch(es) of
> interest to the backup.
>
Shawn,
This sounds easy enough, but how-to "create a remote"?
I looked in .git/remotes and see origin which contains:
URL: git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git
Pull: refs/heads/master:refs/heads/origin
But where is the syntax defined?
Also, how do I setup git on my server so that it becomes a server?
Sorry for are naive questions, but looking at my git tree and
the Internet didn't turn up any obvious answers. Hopefully you can
point to the appropriate documents.
Thanks,
Wink
^ permalink raw reply
* Re: how to show log for only one branch
From: Junio C Hamano @ 2006-11-06 6:12 UTC (permalink / raw)
To: Liu Yubao; +Cc: git
In-Reply-To: <454EAEDB.8020909@gmail.com>
Liu Yubao <yubao.liu@gmail.com> writes:
> I have heard git treats all parents equally in a merge operation, so I
> am curious how git decides which parent is HEAD^1.
The first parent you see when you do "git cat-file commit HEAD"
is the HEAD^1, the second one is HEAD^2, etc.
With typical Porcelains (including git-core), when you make a
true merge by pulling another branch while on one branch, the
tip of the branch you were on when you initiated the merge
becomes the HEAD^1 of the resulting merge commit.
However, that does not mean HEAD^1 is any special in the global
history. It is only locally special when viewed by you who did
the merge, and only immediately after you made the merge. After
a while, even you yourself would feel less special about HEAD^1.
Imagine the following scenario.
. You fork off from Linus's tip, and you do a great work on the
kernel for a while.
o---o---o---o Liu
/
---o Linus
. Linus's tip progresses, and there are semantically some
overlapping changes; you merge from Linus to make sure your
great work still works with the updated upstream. This merge
commit (marked '*' in the picture below) has _your_ last
change as HEAD^1 and Linus's tip as HEAD^2.
o---o---o---o---* Liu
/ /
---o---o---o---o---o Linus
. It still works great and you let Linus know about your great
work. He likes it and pulls from you.
At this point, the revision history would still look like this:
o---o---o---o---* Liu = Linus
/ /
---o---o---o---o---o
That is, the DAG did not change since you pulled from Linus.
The only thing that changed was that Linus's tip now points at
the merge commit _you_ made.
Then Linus keeps working, building commits on top of that merge.
Liu
o---o---o---o---*---o---o---o---o Linus
/ /
---o---o---o---o---o
Now, we can say two things about this history.
If you view the development community "centered around Linus",
then when somebody looks back the history from Linus's tip,
whatever great work you did, that is merely "one of the many
contributions from many people". The "mainline" from this point
of view is still "what Linus saw at each point as the tip of his
development track", and among the commits you made (the ones
between the fork point and '*' in the above picture), the last
one, the merge you made was the only one that was once the tip
of Linus; everything else was "random work that happend in a
side branch". But HEAD^1 is not special if you wanted to have
this view.
In massively parallel and distributed development, whose track
of development is "mainline" is not absolute, and it all depends
on what you are interested in when you do the archaeology.
Let's say that your work on the side branch was in one specific
area (say, a device driver work for product X), and nobody
else's work in that area appeared on Linus's development track
since you forked until your work was merged.
To somebody who is digging from Linus's tip in order to find out
how that driver evolved, your side branch is much more important
than what happened on Linus's branch (which everybody would
loosely say _the_ "mainline"). On the other hand, when somebody
is interested in some other area that was worked on in Linus's
development track while your work was done in the side branch,
following your development track is not interesting; and the
person who is interested in this "other area" could be you. In
that case, you would want to follow Linus's development track.
What's mainline is _not_ important, and which parent is first is
even less so. It solely depends on what you are looking for
which branch matters more. Putting too much weight on the
difference between HEAD^1 vs HEAD^2 statically does not make any
sense.
Reflecting this view of history, git log and other history
traversal commands treat merge parents more or less equally, and
_how_ you ask your question affects what branches are primarily
followed. For example, if somebody is interested in your device
driver work, this command:
git log -- drivers/liu-s-device/
would follow your side branch. On the other hand,
git log -- fs/
would follow Linus's development track while you were forked, if
you did not do any fs/ work while on that side branch and
Linus's development track had works in that area, _despite_ the
merge you gave Linus has your development track as its first
parent.
^ permalink raw reply
* Re: how-to "backup" a repository
From: Shawn Pearce @ 2006-11-06 5:52 UTC (permalink / raw)
To: Wink Saville; +Cc: git
In-Reply-To: <454ECC23.6010503@saville.com>
Wink Saville <wink@saville.com> wrote:
> I've been working with git for a little while, but still very
> much a neophyte. One thing I'd like to do is be able to backup
> my work on a server located on my network.
>
> Currently I have cloned the Linux 2.6 tree on my personal computer
> and have been backing it up by tar'ing the subdirectory with the
> cloned repository and then using scp to copy it to my server.
>
> I suspect there is a better way, probably using git itself:)
>
> How is the typically handled?
Create a remote (in .git/remotes) which refers to your backup
location. Then use 'git push' to push your branch(es) of
interest to the backup.
--
^ permalink raw reply
* how-to "backup" a repository
From: Wink Saville @ 2006-11-06 5:46 UTC (permalink / raw)
To: git
Hello,
I've been working with git for a little while, but still very
much a neophyte. One thing I'd like to do is be able to backup
my work on a server located on my network.
Currently I have cloned the Linux 2.6 tree on my personal computer
and have been backing it up by tar'ing the subdirectory with the
cloned repository and then using scp to copy it to my server.
I suspect there is a better way, probably using git itself:)
How is the typically handled?
Cheers,
^ permalink raw reply
* Re: git reset --soft a merged commit
From: Shawn Pearce @ 2006-11-06 4:50 UTC (permalink / raw)
To: Nguyen Thai Ngoc Duy; +Cc: git
In-Reply-To: <fcaeb9bf0611052048r11816e76p88d568e3478c354b@mail.gmail.com>
Nguyen Thai Ngoc Duy <pclouds@gmail.com> wrote:
> Hi,
> I did "git reset --soft HEAD~1" where HEAD is a merged commit and
> committed again (nothing changed). The new commit was not recorded as
> a merged commit. Is it intentional?
Yes, you undid the merge. :-(
--
^ permalink raw reply
* git reset --soft a merged commit
From: Nguyen Thai Ngoc Duy @ 2006-11-06 4:48 UTC (permalink / raw)
To: git
Hi,
I did "git reset --soft HEAD~1" where HEAD is a merged commit and
committed again (nothing changed). The new commit was not recorded as
a merged commit. Is it intentional?
--
^ permalink raw reply
* how to show log for only one branch
From: Liu Yubao @ 2006-11-06 3:41 UTC (permalink / raw)
To: git
I'm some confused by `git log', here is a revision graph:
a-----> b ---> c ----------------> f ---> g --- master
\ /
`------> d ----------> e ---- test
I hope `git log ...` shows g, f, c, b, a.
`git log master` shows g, f, e, d, c, b, a;
`git log master ^test` shows g, f, c.
`git log --no-merges master` shows g, e, d, c, b, a.
That's to say, I want to view master, master~1, master~2, master~3, ...
until the beginning, no commits in other branches involved.
I have heard git treats all parents equally in a merge operation, so I
am curious how git decides which parent is HEAD^1.
I feel the HEAD^1 branch is more special than HEAD^2 branch, because HEAD^1
is usually the working branch and the target branch of merging operation.
it's a little more convenient to see only commits that really happen in
current branch, especially for people who come from CVS and Subversion (yes,
I think git is more interesting than CVS and Subversion:-).
^ permalink raw reply
* On performance characteristics of pickaxe with -M, -C, and -C -C
From: Junio C Hamano @ 2006-11-05 22:27 UTC (permalink / raw)
To: git
I've been brewing parts of git-pickaxe in "pu" for the last week
to fix both correctness and performance issues, and it appears
it is now in a good enough shape to even replace git-blame for
everyday use, so I've placed my recent work in "next".
- Under -M or -C, it tried to find lines that are copied
around, but it did its scan only once. When a scan result
splits the blame for a block of lines into three blocks:
original span of blame <----------------------------->
lines matched by -M/-C <----->
==>
result of split <---------><.....><----------->
the middle part that matched passed the blame to the parent,
but the new two parts created by this split was not
re-scanned by the old code and the blame stayed with the
commit we were inspecting. The updated code re-scans for
these two new parts and allows them to pass blame to their
parents.
- The implementation of -C -C (aka "find copies harder") was
very broken. Under this flag, the program should try all the
paths in the parent as the candidates of copies for a path
that is new (that is, not a modification from the original
path, nor rename/copy from an existing path). However, it
used diffcore incorrectly and used only the paths that were
changed from parent to child (i.e. the same as a single -C).
The updated code works as advertised. This is very expensive
but the option exists in case when you know you want to pay
the price to find out all the possible cuts-and-pastes.
- The old code was reading each blob typically twice -- once as
the "parent's blob" when a commit is compared with its
parent, and then as the "child's blob" when that parent was
trying to pass the blame to its parent. The updated code
reuses these blobs between the parent and the child and is
much more efficient.
The following is by no means a scientific test, but here are two
comparisons using blame and pickaxe with or without -M/-C/-C -C.
One is our own revision.c, and the other is kernel/sched.c from
the kernel project. The number of minor faults in 'time' output
gives a rough indication of the memory footprint of the process.
----------------------------------------------------------------
* git-blame revision.c
0.76user 0.01system 0:00.77elapsed 99%CPU (0avgtext+0avgdata 0maxresident)k
0inputs+0outputs (0major+3269minor)pagefaults 0swaps
reads blob 82 times
* git-pickaxe revision.c
0.78user 0.00system 0:00.78elapsed 100%CPU (0avgtext+0avgdata 0maxresident)k
0inputs+0outputs (0major+2500minor)pagefaults 0swaps
reads blob 92 times
These two give comparable results. The only difference is
that git-blame says line 319 is from a41e109c (2006-03-12)
while git-pickaxe says it is from 8efdc326 (2006-03-10).
Manual inspection of both tells me that they are both valid
and reasonable.
* git-pickaxe -M revision.c
0.95user 0.02system 0:00.97elapsed 100%CPU (0avgtext+0avgdata 0maxresident)k
0inputs+0outputs (0major+2410minor)pagefaults 0swaps
reads blob 92 times
This notices that ll. 528-531, 695-701 and 791-794 are not
new lines introduced by the commits git-blame and
git-pickaxe without -M place blame on, but the commits just
shuffled existing lines. For an example, look at output
from:
git show 53069686 -- revision.c
The commit moved around the code to parse --min-age= option;
git-pickaxe -M does not blame 53069686 for it, but git-blame
and git-pickaxe without -M do.
Because this flag does not cause the command to look for
copied lines across files (other than the usual rename
detection), the set of blobs it works on is the same as the
command without -M.
* git-pickaxe -C revision.c
2.52user 0.03system 0:02.55elapsed 99%CPU (0avgtext+0avgdata 0maxresident)k
0inputs+0outputs (0major+5262minor)pagefaults 0swaps
reads blob 486 times
This starts noticing that a lot of the code actually came
from rev-list.c as mentioned in an earlier message by Linus.
Message-ID: <Pine.LNX.4.64.0610201630000.3962@g5.osdl.org>
To find new suspects that are not the same path (or renamed
path) in the parent, the program inspects files that were
changed from its parent and that is how it finds that many
lines came from rev-list.c. Because it needs to work on
more blobs than the above cases, it is a heavier weight
operation.
* git-pickaxe -C -C revision.c
10.60user 0.06system 0:10.66elapsed 100%CPU (0avgtext+0avgdata 0maxresident)k
0inputs+0outputs (0major+19762minor)pagefaults 0swaps
reads blob 1839 times
This does not notice anything new compared to the above for
this file's history.
----------------------------------------------------------------
* git-blame kernel/sched.c
4.68user 0.63system 0:05.31elapsed 100%CPU (0avgtext+0avgdata 0maxresident)k
0inputs+0outputs (0major+276957minor)pagefaults 0swaps
reads blob 177 times
* git-pickaxe kernel/sched.c
5.63user 0.66system 0:06.29elapsed 100%CPU (0avgtext+0avgdata 0maxresident)k
0inputs+0outputs (0major+276274minor)pagefaults 0swaps
reads blob 181 times
The above two produce identical results.
* git-pickaxe -M kernel/sched.c
9.62user 1.35system 0:10.96elapsed 100%CPU (0avgtext+0avgdata 0maxresident)k
0inputs+0outputs (0major+388517minor)pagefaults 0swaps
reads blob 181 times
The story is the same as in our earlier example on revision.c.
For example, look for comments about "task_timeslice()" in:
git show 91fcdd4e -- kernel/sched.c
* git-pickaxe -C kernel/sched.c
12.94user 1.08system 0:14.04elapsed 99%CPU (0avgtext+0avgdata 0maxresident)k
0inputs+0outputs (0major+407624minor)pagefaults 0swaps
reads blob 667 times
This notices that many lines came from arch/ia64/kernel/domain.c
* git-pickaxe -C -C kernel/sched.c
13.09user 1.02system 0:14.11elapsed 100%CPU (0avgtext+0avgdata 0maxresident)k
0inputs+0outputs (0major+407626minor)pagefaults 0swaps
reads blob 667 times
For the kernel history (since 2.6.12-rc2) kernel/sched.c is not
a new file, so there is no difference in the output or
performance between -C and -C -C.
^ permalink raw reply
* Re: [PATCH] Fix git-runstatus for repositories containing a file named HEAD
From: Jeff King @ 2006-11-05 22:22 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Rocco Rutte
In-Reply-To: <11627635702846-git-send-email-pdmef@gmx.net>
On Sun, Nov 05, 2006 at 09:52:50PM +0000, Rocco Rutte wrote:
> The wt_status_print_updated() and wt_status_print_untracked() routines
> call setup_revisions() with 'HEAD' being the reference to the tip of the
> current branch. However, setup_revisions() gets confused if the branch
> also contains a file named 'HEAD' resulting in a fatal error.
Ack. This is definitely a bug, and the patch fixes it. I wonder if it
would be slightly more readable to simply get rid of the argv nonsense.
Junio, please apply whichever you find more readable.
-- >8 --
The wt_status_print_updated() and wt_status_print_untracked() routines
call setup_revisions() with 'HEAD' being the reference to the tip of the
current branch. However, setup_revisions() gets confused if the branch
also contains a file named 'HEAD' resulting in a fatal error.
Instead, don't pass an argv to setup_revisions() at all; simply give it no
arguments, and make 'HEAD' the default revision.
Bug noticed by Rocco Rutte <pdmef@gmx.net>.
Signed-off-by: Jeff King <peff@peff.net>
---
wt-status.c | 11 +++--------
1 files changed, 3 insertions(+), 8 deletions(-)
diff --git a/wt-status.c b/wt-status.c
index 7dd6857..9692dfa 100644
--- a/wt-status.c
+++ b/wt-status.c
@@ -154,10 +154,8 @@ void wt_status_print_initial(struct wt_s
static void wt_status_print_updated(struct wt_status *s)
{
struct rev_info rev;
- const char *argv[] = { NULL, NULL, NULL };
- argv[1] = s->reference;
init_revisions(&rev, NULL);
- setup_revisions(2, argv, &rev, NULL);
+ setup_revisions(0, NULL, &rev, s->reference);
rev.diffopt.output_format |= DIFF_FORMAT_CALLBACK;
rev.diffopt.format_callback = wt_status_print_updated_cb;
rev.diffopt.format_callback_data = s;
@@ -168,9 +166,8 @@ static void wt_status_print_updated(stru
static void wt_status_print_changed(struct wt_status *s)
{
struct rev_info rev;
- const char *argv[] = { NULL, NULL };
init_revisions(&rev, "");
- setup_revisions(1, argv, &rev, NULL);
+ setup_revisions(0, NULL, &rev, NULL);
rev.diffopt.output_format |= DIFF_FORMAT_CALLBACK;
rev.diffopt.format_callback = wt_status_print_changed_cb;
rev.diffopt.format_callback_data = s;
@@ -225,10 +222,8 @@ static void wt_status_print_untracked(co
static void wt_status_print_verbose(struct wt_status *s)
{
struct rev_info rev;
- const char *argv[] = { NULL, NULL, NULL };
- argv[1] = s->reference;
init_revisions(&rev, NULL);
- setup_revisions(2, argv, &rev, NULL);
+ setup_revisions(0, NULL, &rev, s->reference);
rev.diffopt.output_format |= DIFF_FORMAT_PATCH;
rev.diffopt.detect_rename = 1;
run_diff_index(&rev, 1);
--
1.4.3.3.ga02d-dirty
^ permalink raw reply related
* [PATCH] Fix git-runstatus for repositories containing a file named HEAD
From: Rocco Rutte @ 2006-11-05 21:52 UTC (permalink / raw)
To: git; +Cc: Rocco Rutte
The wt_status_print_updated() and wt_status_print_untracked() routines
call setup_revisions() with 'HEAD' being the reference to the tip of the
current branch. However, setup_revisions() gets confused if the branch
also contains a file named 'HEAD' resulting in a fatal error.
The fix is to append the '--' delimiter to the setup_revisions() call so
that it knows for sure that the 'HEAD' argument is a revision and not a
filename.
Signed-off-by: Rocco Rutte <pdmef@gmx.net>
---
wt-status.c | 8 ++++----
1 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/wt-status.c b/wt-status.c
index 7dd6857..7c0dbdb 100644
--- a/wt-status.c
+++ b/wt-status.c
@@ -154,10 +154,10 @@ void wt_status_print_initial(struct wt_s
static void wt_status_print_updated(struct wt_status *s)
{
struct rev_info rev;
- const char *argv[] = { NULL, NULL, NULL };
+ const char *argv[] = { NULL, NULL, "--", NULL };
argv[1] = s->reference;
init_revisions(&rev, NULL);
- setup_revisions(2, argv, &rev, NULL);
+ setup_revisions(3, argv, &rev, NULL);
rev.diffopt.output_format |= DIFF_FORMAT_CALLBACK;
rev.diffopt.format_callback = wt_status_print_updated_cb;
rev.diffopt.format_callback_data = s;
@@ -225,10 +225,10 @@ static void wt_status_print_untracked(co
static void wt_status_print_verbose(struct wt_status *s)
{
struct rev_info rev;
- const char *argv[] = { NULL, NULL, NULL };
+ const char *argv[] = { NULL, NULL, "--", NULL };
argv[1] = s->reference;
init_revisions(&rev, NULL);
- setup_revisions(2, argv, &rev, NULL);
+ setup_revisions(3, argv, &rev, NULL);
rev.diffopt.output_format |= DIFF_FORMAT_PATCH;
rev.diffopt.detect_rename = 1;
run_diff_index(&rev, 1);
--
1.4.3.4.g50f39-dirty
^ permalink raw reply related
* Re: Push and remote refs
From: Jeff King @ 2006-11-05 21:50 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vveltoa0l.fsf@assigned-by-dhcp.cox.net>
On Sun, Nov 05, 2006 at 01:31:54PM -0800, Junio C Hamano wrote:
> post-update hook rewinds the tip we just pushed, it is the same
> thing as in the case where the post-update hook did not do
> anything but somebody else, a human user, did the equivalent
> rewinding of the branch, and the pretended fetch happened
Yes, I think this is a sensible way of looking at it. I withdraw my
question. :)
^ permalink raw reply
* Re: git-am vs. git-applymbox
From: linux @ 2006-11-05 21:42 UTC (permalink / raw)
To: jnareb; +Cc: git
> git-applymbox - Apply a series of patches in a mailbox
> git-am - Apply a series of patches in a mailbox
>
> What are the differences between thos two commands, UI-wise and capability
> (feature) wise? Which one should I use? Which one do _you_ use?
git-applymbox was one of the first git porcelain scripts ever written,
by Linus. (In fact, it's original name of "dotest" is visible in some
of the temp files.) It has its rough edges, but Linus is used to it,
so it is retained for his convenience.
git-am is a rewrite with a nicer (but different) command line. If you
are starting, it's the one you should learn and use.
In particular, git-am has options like "--resolved" and "--skip"
for resuming from an interrupted patch series. Restarting
git-applymbox requires a detailed knowledge of its workings.
^ permalink raw reply
* Re: Push and remote refs
From: Junio C Hamano @ 2006-11-05 21:31 UTC (permalink / raw)
To: Jeff King; +Cc: git
In-Reply-To: <20061105210607.GA28320@coredump.intra.peff.net>
Jeff King <peff@peff.net> writes:
> On Sun, Nov 05, 2006 at 11:37:08AM -0800, Junio C Hamano wrote:
>
>> I recall discussing this exact behaviour with Pasky when he
>> added it to Cogito. I think we concluded that it is a very
>> sensible thing to pretend we fetched immediately after we
>> successfully pushed and got the same thing back, and there is no
>> risk of data loss or user confusion, as long as we catch failure
>> from the push and refrain from doing this update, which Cogito
>> did implement correctly when we discussed this.
>
> Is it possible for hooks on the receiving side to change the tip commit
> in some way? For example, the 'update' hook could do some markup on the
> commit message or contents, creating a new commit and using it instead
> of the pushed one; in this case, the sending side ends up with an
> incorrect (and unrelated) SHA1. Is this simply too insane to worry
> about?
I do not think it is sane for the update hook to muck with tips
in any way (they are meant for making policy decision whether to
allow the push -- we do not enforce this, partly because the
majorly lockless nature of git makes it impossible to, but then
update hook is free to invoke "rm -rf $GIT_DIR" and nobody
prevents it from doing so. It is the same kind of user shooting
at his foot).
The post-update hook is free to do anything what it wants. But
that does not make the Cogito's "pretend we have fetched
immediately after we pushed" semantics invalid. If the
post-update hook rewinds the tip we just pushed, it is the same
thing as in the case where the post-update hook did not do
anything but somebody else, a human user, did the equivalent
rewinding of the branch, and the pretended fetch happened
between the time the push successfull finished and the time that
somebody else did the rewinding, so this is nothing new. The
next push would notice that the tip does not fast forward in
either case.
^ permalink raw reply
* Re: Push and remote refs
From: Jeff King @ 2006-11-05 21:06 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Daniel Barkalow, git
In-Reply-To: <7vhcxdu1ln.fsf@assigned-by-dhcp.cox.net>
On Sun, Nov 05, 2006 at 11:37:08AM -0800, Junio C Hamano wrote:
> I recall discussing this exact behaviour with Pasky when he
> added it to Cogito. I think we concluded that it is a very
> sensible thing to pretend we fetched immediately after we
> successfully pushed and got the same thing back, and there is no
> risk of data loss or user confusion, as long as we catch failure
> from the push and refrain from doing this update, which Cogito
> did implement correctly when we discussed this.
Is it possible for hooks on the receiving side to change the tip commit
in some way? For example, the 'update' hook could do some markup on the
commit message or contents, creating a new commit and using it instead
of the pushed one; in this case, the sending side ends up with an
incorrect (and unrelated) SHA1. Is this simply too insane to worry
about?
^ permalink raw reply
* Re: Push and remote refs
From: Junio C Hamano @ 2006-11-05 19:37 UTC (permalink / raw)
To: Daniel Barkalow; +Cc: git
In-Reply-To: <Pine.LNX.4.64.0611051333210.9789@iabervon.org>
Daniel Barkalow <barkalow@iabervon.org> writes:
> Usually, I use the same computer to do this multiple times in a row, and
> it's a bit inconvenient that, after pushing local "for-mainline" to remote
> "master", I have to fetch remote "master" to local "mainline". It would be
> nice if git would update local tracking of remote refs when it pushes to
> those remote refs.
I recall discussing this exact behaviour with Pasky when he
added it to Cogito. I think we concluded that it is a very
sensible thing to pretend we fetched immediately after we
successfully pushed and got the same thing back, and there is no
risk of data loss or user confusion, as long as we catch failure
from the push and refrain from doing this update, which Cogito
did implement correctly when we discussed this.
^ permalink raw reply
* Re: [PATCH] Allow hand-editing of patches before sending
From: Jakub Narebski @ 2006-11-05 19:29 UTC (permalink / raw)
To: git
In-Reply-To: <20061105190400.GC25259@diana.vm.bytemark.co.uk>
Karl Hasselström wrote:
> These are the headers that StGIT uses without my patch -- that is, the
> headers used to get that error message:
>
> Content-Type: text/plain; charset=utf-8; format=fixed
> Content-Transfer-Encoding: 8bit
>
> Which is obviously not good enough for some picky part of the SMTP
> chain.
I think you are missing MIME-Version: header.
[...]
> Well, it added these headers:
>
> MIME-Version: 1.0
> Content-Transfer-Encoding: QUOTED-PRINTABLE
> Content-Type: TEXT/PLAIN; charset=ISO-8859-1
>
> Maybe MIME-Version was the only thing missing? I'll have to try.
MIME-Version _is_ important. I remember that Outlook Express sent news
messages without this header, and those posts were either mangled by news
server, or news readers didn't parse MIME headers without MIME-Version:
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
^ 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