* Re: [ANNOUNCE] pg - A patch porcelain for GIT
From: Petr Baudis @ 2006-02-10 21:47 UTC (permalink / raw)
To: git
In-Reply-To: <20060210213818.GB1604@spearce.org>
Dear diary, on Fri, Feb 10, 2006 at 10:38:18PM CET, I got a letter
where Shawn Pearce <spearce@spearce.org> said that...
> But two things happened:
>
> 1) Cogito didn't run well on a Solaris box I wanted to try and
> use it in; apparently we don't have enough GNU shell commands
> available and Cogito fell over. (But right now I'd bet pg
> will behave the same if not worse. I haven't had time to try
> it. *sigh*)
I'm always listening for bugreports. Besides requiring bash, Cogito _is_
expected to run on POSIX stuff!
> 2) I found myself suddenly typing 'pg-log' and 'pg-diff' rather
> than 'git-log' and 'git-diff'. Call it future muscle memory?
> I hadn't written either of these scripts so I was getting a lot
> of '-bash: pg-log: command not found' errors from my shell.
> So they both became 1 line wrappers around the git-core
> versions, just to save my sanity.
I see. IIRC Catalin gave the similar reasoning. (Obviously, my
egoistical me might be just hurt by it not wrapping Cogito. ;))
> > But while it claims to be compatible with all the porcelains, it at
> > least cannot be clone by them. ;) The GIT repository is not quite a
> > valid GIT repository since it is missing the HEAD and Cogito clones
> > based on this file instead of just assuming that your head is on the
> > master branch.
>
> Fixed.
Thanks.
> > Also, when cloning it gives me a little unnerving errors like
> >
> > error: File 6427c0154400f578d9cdff178e01e946db6f714f
> > (http://www.spearce.org/projects/scm/pg.git/objects/64/27c0154400f578d9cdff178e01e946db6f714f)
> > corrupt
>
> I've seen the same. I think it is either a bug in my rsync script
> or a bug in the GIT http clone code; because that is the current
> tip commit of the master branch. And I've only seen that error for
> the tip commit, and only if the object doesn't exist in the object
> directory because I've done git-pack && git-prune-packed.
On a second thought, this is probably simply caused by the web server
not reporting 404 on missing files.
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
Of the 3 great composers Mozart tells us what it's like to be human,
Beethoven tells us what it's like to be Beethoven and Bach tells us
what it's like to be the universe. -- Douglas Adams
^ permalink raw reply
* Re: [ANNOUNCE] pg - A patch porcelain for GIT
From: Shawn Pearce @ 2006-02-10 21:38 UTC (permalink / raw)
To: git
In-Reply-To: <20060210211740.GO31278@pasky.or.cz>
Petr Baudis <pasky@suse.cz> wrote:
> One thing I dislike on both StGIT and pg is that they both try to
> build a full-fledged porcelain on top of GIT, instead of just focusing
> on the patch management, doing it well and providing a convenient user
> interface (well, can't say about pg's interface, didn't try it yet).
> Instead of having pg-add, pg-log, or pg-status it might be more fruitful
> to contribute the features you are missing to git-core or Cogito.
Very valid points. Before writing pg I used Cogito exclusively
and found git-core too cumbersome to use directly. When I started
writing pg I didn't intend on replacing everything GIT and Cogito
offers; I was trying to only create the patch stack but still use
the Cogito tools for everything else.
But two things happened:
1) Cogito didn't run well on a Solaris box I wanted to try and
use it in; apparently we don't have enough GNU shell commands
available and Cogito fell over. (But right now I'd bet pg
will behave the same if not worse. I haven't had time to try
it. *sigh*)
2) I found myself suddenly typing 'pg-log' and 'pg-diff' rather
than 'git-log' and 'git-diff'. Call it future muscle memory?
I hadn't written either of these scripts so I was getting a lot
of '-bash: pg-log: command not found' errors from my shell.
So they both became 1 line wrappers around the git-core
versions, just to save my sanity.
I would agree with trying to integrate some of the workflow idealogy
presented by StGIT and pg into something more mainstream such as
git-core or Cogito. Right now I'm using pg as a proving ground to
feel out how some of that might work in one particular environment:
A development team I work with is stuck using PVCS Version
Manager 6. Moving source code from a developer to a tester is a
huge nightmare; not only must the developer check the code into
the version control system but he/she must also write a bug report
in a bug database to tell someone else to get the source file
and give it to the tester. Its a horrible workflow. GIT + pg +
additional custom scripts seems to be easing the pain somewhat;
but sadly we can't just rip out PVCS Version Manager and use GIT.
> > And for those so inclined:
> >
> > Homepage: http://www.spearce.org/projects/scm/pg/
> > GIT Repository: http://www.spearce.org/projects/scm/pg.git
>
> But while it claims to be compatible with all the porcelains, it at
> least cannot be clone by them. ;) The GIT repository is not quite a
> valid GIT repository since it is missing the HEAD and Cogito clones
> based on this file instead of just assuming that your head is on the
> master branch.
Fixed. That's my fault - my hosting provider doesn't have GIT
installed and thus I had to publish my repository over rsync+ssh.
But git-push doesn't support that protocol type anymore. :-| So
I packed everything into pack files, pruned the object directory,
and rsync'd it up. I guess my rsync script didn't copy HEAD.
> Also, when cloning it gives me a little unnerving errors like
>
> error: File 6427c0154400f578d9cdff178e01e946db6f714f
> (http://www.spearce.org/projects/scm/pg.git/objects/64/27c0154400f578d9cdff178e01e946db6f714f)
> corrupt
I've seen the same. I think it is either a bug in my rsync script
or a bug in the GIT http clone code; because that is the current
tip commit of the master branch. And I've only seen that error for
the tip commit, and only if the object doesn't exist in the object
directory because I've done git-pack && git-prune-packed.
--
Shawn.
^ permalink raw reply
* Re: Git 1.1.6.g4d44 make test FAILURE report
From: Junio C Hamano @ 2006-02-10 21:38 UTC (permalink / raw)
To: gitzilla; +Cc: git, junkio
In-Reply-To: <43ED0368.7020204@gmail.com>
Thanks; good catch. I think we should export GIT_*_{NAME,EMAIL}
variables explicitly for this particular problem. We probably
do _not_ want to do the same for GIT_*_DATE though.
^ permalink raw reply
* Re: Comments on "status -v"
From: Linus Torvalds @ 2006-02-10 21:35 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Carl Worth, git
In-Reply-To: <7vaccyx6ne.fsf@assigned-by-dhcp.cox.net>
On Fri, 10 Feb 2006, Junio C Hamano wrote:
> Carl Worth <cworth@cworth.org> writes:
>
> > 1) I think the patch should come after the traditional status summary,
> > not before. If something is obviously "wrong" (non-updated file,
> > etc.) that will be more obvious in the summary, so it's good to
> > present that up front, and not bury it after the patch, (which
> > might make it initially invisible without scrolling).
>
> Maybe. A time for a quick poll.
I think I agree. Especially if doing "git commit -v", the _top_ of the
status message is what you'd normally be most aware of. I think.
Especially if the patch is large, you'd grow bored looking at it long
before you saw what followed.
Linus
^ permalink raw reply
* Re: [PATCH] Ignore commits for which cvsps can't identify a branch
From: Junio C Hamano @ 2006-02-10 21:21 UTC (permalink / raw)
To: Christian Biesinger; +Cc: git
In-Reply-To: <200602102102.k1AL2Xkd010415@biesi.no-ip.org>
Christian Biesinger <cbiesinger@web.de> writes:
> cvps sometimes can't identify a branch for a specific revision, it shows
> messages like:
> WARNING: revision 1.36.2.2 of file Makefile.in on unnamed branch
> and uses #CVSPS_NO_BRANCH as branch name in its output.
>
> This checkin makes it so that git-cvsimport ignores such branches,
> and when they
> appear as ancestor branch, it maps them to HEAD.
Does continuing with this kind of "fixups" produce usable
history, perhaps just some changes missing but trees contained
in other commits are still faithful reproductions of what the
CVS repository would have given you? Or does it result in
unusable history?
Depending on the nature of corruption and its expected use,
sometimes silently corrupt conversion result is worse than not
having it at all. If you are going to use it primarily for
archaeology, it is much more useful to have a more-or-less
correct conversion than not having anything at all, but if you
are building on top of it, you at least would want to have the
correct tree at the tip of the branch you build upon. I cannot
offhand tell how this workaround affects the conversion result,
hence this question.
> I hope I did this right, I'm not so familiar with git...
The only gripe I might have is your log message is too wide.
Other than that it looks like it properly follows the the
formatting and submitting convention.
^ permalink raw reply
* Git 1.1.6.g4d44 make test FAILURE report
From: A Large Angry SCM @ 2006-02-10 21:19 UTC (permalink / raw)
To: git; +Cc: junkio
Running "make test" from an account with an empty gcos field fails test
6 of t1200-tutorial.sh.
If the gcos field is a single space character, "make test" fails test 3
of t3500-cherry.sh.
^ permalink raw reply
* Re: [ANNOUNCE] pg - A patch porcelain for GIT
From: Petr Baudis @ 2006-02-10 21:17 UTC (permalink / raw)
To: git
In-Reply-To: <20060210195914.GA1350@spearce.org>
Hi,
Dear diary, on Fri, Feb 10, 2006 at 08:59:14PM CET, I got a letter
where Shawn Pearce <spearce@spearce.org> said that...
> I just posted the first public version of pg, a GIT porcelain for
> managing patches. Think StGIT, but better in some ways:
it sounds interesting. I've been thinking about wrapping some patch
queue tool in Cogito (post-1.0) and pg might be a better choice than
StGIT.
One thing I dislike on both StGIT and pg is that they both try to
build a full-fledged porcelain on top of GIT, instead of just focusing
on the patch management, doing it well and providing a convenient user
interface (well, can't say about pg's interface, didn't try it yet).
Instead of having pg-add, pg-log, or pg-status it might be more fruitful
to contribute the features you are missing to git-core or Cogito.
> And for those so inclined:
>
> Homepage: http://www.spearce.org/projects/scm/pg/
> GIT Repository: http://www.spearce.org/projects/scm/pg.git
But while it claims to be compatible with all the porcelains, it at
least cannot be clone by them. ;) The GIT repository is not quite a
valid GIT repository since it is missing the HEAD and Cogito clones
based on this file instead of just assuming that your head is on the
master branch.
Also, when cloning it gives me a little unnerving errors like
error: File 6427c0154400f578d9cdff178e01e946db6f714f
(http://www.spearce.org/projects/scm/pg.git/objects/64/27c0154400f578d9cdff178e01e946db6f714f)
corrupt
(but strangely, fsck-objects later does not complain).
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
Of the 3 great composers Mozart tells us what it's like to be human,
Beethoven tells us what it's like to be Beethoven and Bach tells us
what it's like to be the universe. -- Douglas Adams
^ permalink raw reply
* Re: How to pull a single changeset from a child branch into a parent branch?
From: Ben Greear @ 2006-02-10 21:16 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vzmkzyfhh.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano wrote:
> Ben Greear <greearb@candelatech.com> writes:
>
>
>>I have a linux-2.6 repo with two branches off of 2.6.13.
>>
>>One branch (ben_v13) has just my own changes.
>>A second branch (work_v13) has the 2.6.13.5 patch, and I've also pulled
>>ben_v13 into it.
>
>
> "2.6.13.5"
> o---o---o---o
> / \ "work_v13"
> ---o "2.6.13" .---*
> \ /
> o---o---o
> "ben_v13"
>
> 'o' are commits, '*' is a merge.
>
>
>>Now, I made a small change to work_v13,
>
>
> "2.6.13.5"
> o---o---o---o
> / \ "work_v13"
> ---o "2.6.13" .---*---x
> \ / (new change)
> o---o---o
> "ben_v13"
>
>
>>... and I'd like to pull only
>>that changeset into ben_v13. Is there a way to do that w/out
>>having to export and apply a patch?
>
>
> I would have done things differently.
Yeah, the main problem is that I test in the combined tree
and forgot to change to the ben_v13 tree before making
my changes...
I'll try out the cherry-pick option..and if that doesn't
work, I'll just manually patch the changes into the ben_v13
tree.
Thanks,
Ben
--
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc http://www.candelatech.com
^ permalink raw reply
* Re: Comments on "status -v"
From: Junio C Hamano @ 2006-02-10 21:09 UTC (permalink / raw)
To: Carl Worth; +Cc: git
In-Reply-To: <87u0b7uf91.wl%cworth@cworth.org>
Carl Worth <cworth@cworth.org> writes:
> 1) I think the patch should come after the traditional status summary,
> not before. If something is obviously "wrong" (non-updated file,
> etc.) that will be more obvious in the summary, so it's good to
> present that up front, and not bury it after the patch, (which
> might make it initially invisible without scrolling).
Maybe. A time for a quick poll.
> 2) Using the "^---$" separator to separate the the edited contents
> into a commit message and ignored content seems risky to me.
>
> Moving the patch after the summary (as discussed above) would help
> greatly in avoiding the clobbered separator, but wouldn't address
> the separator-appears-in-commit-message problem.
That is a good argument for (1). Since the diff output never
has '^---$' in itself, instead of discarding everything after
the first '^---$', we could change the log cleanser to discard
after the _last_ '^---$'. But coding this sanely is much
trickier with sed ;-).
^ permalink raw reply
* Re: [ANNOUNCE] pg - A patch porcelain for GIT
From: Shawn Pearce @ 2006-02-10 21:04 UTC (permalink / raw)
To: Greg KH; +Cc: git
In-Reply-To: <20060210204143.GA18784@kroah.com>
Greg KH <greg@kroah.com> wrote:
> On Fri, Feb 10, 2006 at 02:59:14PM -0500, Shawn Pearce wrote:
> > I just posted the first public version of pg, a GIT porcelain for
> > managing patches. Think StGIT, but better in some ways:
> >
> > Feature Summary:
>
> Hm, is there any way to import an existing patch into pg?
Doh! I haven't needed to do that yet. I'll code up a pg-import
later tonight. But since git and pg play nice together you can
do this:
pg-new Patch-Name
git-apply the-patch-file.patch
pg-ci -m"Importing the-patch-file.patch..."
or even:
pg-new Patch-Name
git-am mbox
and keep the 'history' stored in the mailbox.
So pg-import won't amount to a very long script. :-|
^ permalink raw reply
* [PATCH] Handle the case where cvsps claims a branch is an ancestor of itself
From: Christian Biesinger @ 2006-02-10 21:02 UTC (permalink / raw)
cvsps sometimes claims that a branch is an ancestor of itself. That confuses
cvsimport. This checkin makes it change the ancestor to HEAD instead.
Signed-off-by: Christian Biesinger <cbiesinger@web.de>
---
On the mozilla.org CVS repository, cvsps managed to output a branch as an
ancestor of itself... This patch allows cvsimport to handle that, although
I'm not sure if this is a good idea (a better fix might be to make cvsps not
do that. I haven't debugged yet why it does this)
git-cvsimport.perl | 4 ++++
1 files changed, 4 insertions(+), 0 deletions(-)
71f7fdb5fd6eccf75ca3c9e070391f94f013dd7e
diff --git a/git-cvsimport.perl b/git-cvsimport.perl
index 4b8ca95..74d6e10 100755
--- a/git-cvsimport.perl
+++ b/git-cvsimport.perl
@@ -811,6 +811,10 @@ while(<CVS>) {
print "In patchset $patchset: ancestor branch unknown, setting to $opt_o" if $opt_v;
$ancestor = $opt_o;
}
+ if ($ancestor eq $branch) {
+ print "CVSPS INCONSISTENCY: Branch is an ancestor of itself. Setting ancestor to $opt_o\n";
+ $ancestor = $opt_o;
+ }
if(-f "$git_dir/refs/heads/$branch") {
print STDERR "Branch $branch already exists!\n";
$state=11;
--
1.1.6
^ permalink raw reply related
* [PATCH] Ignore commits for which cvsps can't identify a branch
From: Christian Biesinger @ 2006-02-10 21:02 UTC (permalink / raw)
cvps sometimes can't identify a branch for a specific revision, it shows
messages like:
WARNING: revision 1.36.2.2 of file Makefile.in on unnamed branch
and uses #CVSPS_NO_BRANCH as branch name in its output.
This checkin makes it so that git-cvsimport ignores such branches, and when they
appear as ancestor branch, it maps them to HEAD.
Signed-off-by: Christian Biesinger <cbiesinger@web.de>
---
I tried to import the Mozilla CVS Repository into git, just for fun, and it
failed. This is one of the patches that are required for it.
I hope I did this right, I'm not so familiar with git...
Documentation/SubmittingPatches says to mail patches to the maintainer, who is
that? :)
git-cvsimport.perl | 11 +++++++++++
1 files changed, 11 insertions(+), 0 deletions(-)
ed142593c84ba76580e780ce8f12244214023213
diff --git a/git-cvsimport.perl b/git-cvsimport.perl
index 00fc3ba..4b8ca95 100755
--- a/git-cvsimport.perl
+++ b/git-cvsimport.perl
@@ -799,7 +799,18 @@ while(<CVS>) {
$state = 11;
next;
}
+ if ($branch eq "#CVSPS_NO_BRANCH") {
+ # skip
+ print "skip patchset $patchset: unknown branch\n" if $opt_v;
+ $state = 11;
+ next;
+ }
if($ancestor) {
+ if ($ancestor eq "#CVSPS_NO_BRANCH") {
+ # skip
+ print "In patchset $patchset: ancestor branch unknown, setting to $opt_o" if $opt_v;
+ $ancestor = $opt_o;
+ }
if(-f "$git_dir/refs/heads/$branch") {
print STDERR "Branch $branch already exists!\n";
$state=11;
--
1.1.6
^ permalink raw reply related
* Re: [ANNOUNCE] pg - A patch porcelain for GIT
From: Greg KH @ 2006-02-10 20:41 UTC (permalink / raw)
To: git
In-Reply-To: <20060210195914.GA1350@spearce.org>
On Fri, Feb 10, 2006 at 02:59:14PM -0500, Shawn Pearce wrote:
> I just posted the first public version of pg, a GIT porcelain for
> managing patches. Think StGIT, but better in some ways:
>
> Feature Summary:
Hm, is there any way to import an existing patch into pg?
thanks,
greg k-h
^ permalink raw reply
* Re: [PATCH] delta micro optimization
From: Nicolas Pitre @ 2006-02-10 20:38 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vhd77vv9o.fsf@assigned-by-dhcp.cox.net>
On Fri, 10 Feb 2006, Junio C Hamano wrote:
> That looks obviously correct but it really is micro. Have you
> benched it? On which architectures? Does it help everywhere or
> register starved ones benefit more than others?
I doubt the performance difference would be measurable on i386 although
the code is a bit smaller.
On ARM it causes a code reduction of 12.5% in count-delta.o.
Nicolas
^ permalink raw reply
* Comments on "status -v" (was: Two crazy proposals for changing git's diff commands)
From: Carl Worth @ 2006-02-10 20:32 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Linus Torvalds, git
In-Reply-To: <7vmzgzy46f.fsf@assigned-by-dhcp.cox.net>
[-- Attachment #1: Type: text/plain, Size: 1816 bytes --]
On Fri, 10 Feb 2006 01:05:28 -0800, Junio C Hamano wrote:
>
> Linus Torvalds <torvalds@osdl.org> writes:
>
> > Under that logic, "git status -v" would show all the diffs (not just
> > filenames) and "git commit -v .." would be the same as "git commit .." but
> > the "-v" flag would have been passed down to the "git status" call, so the
> > commit message file would be pre-populated with the diff.
>
> Now that is done and sitting at the tip of "next".
Thanks. This does look quite useful.
A couple of comments, though:
1) I think the patch should come after the traditional status summary,
not before. If something is obviously "wrong" (non-updated file,
etc.) that will be more obvious in the summary, so it's good to
present that up front, and not bury it after the patch, (which
might make it initially invisible without scrolling).
2) Using the "^---$" separator to separate the the edited contents
into a commit message and ignored content seems risky to me.
One risk is that the user might put that magic string in the commit
message. Perhaps the risk is low, but it would be a silent
destruction of historical data, which seems like a bad trap.
A second risk is that with the current patch-then-summary order it
is actually quite easy to inadvertently clobber the separator while
editing the commit message. Particularly because the separator is
placed exactly where the user must begin editing. So it would be
easy to leave the separator trailing on a line of
commit message comments or else introducing some initial
whitespace that would break it.
Moving the patch after the summary (as discussed above) would help
greatly in avoiding the clobbered separator, but wouldn't address
the separator-appears-in-commit-message problem.
-Carl
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: [PATCH] delta micro optimization
From: Junio C Hamano @ 2006-02-10 20:00 UTC (permalink / raw)
To: Nicolas Pitre; +Cc: git
In-Reply-To: <Pine.LNX.4.64.0602101335160.5397@localhost.localdomain>
That looks obviously correct but it really is micro. Have you
benched it? On which architectures? Does it help everywhere or
register starved ones benefit more than others?
^ permalink raw reply
* [ANNOUNCE] pg - A patch porcelain for GIT
From: Shawn Pearce @ 2006-02-10 19:59 UTC (permalink / raw)
To: git
I just posted the first public version of pg, a GIT porcelain for
managing patches. Think StGIT, but better in some ways:
Feature Summary:
- Maximum compatibility with other GIT porcelains.
pg was designed to interoperate with core GIT and the other
GIT porcelains as much as possible. GIT favorites like git-am
can be used to modify a pg managed patch, and vice-versa,
and without requiring changes to the other GIT tools.
- Simplified command line user interface.
pg tries to simplify GIT by 'hiding' the index and behaving like
more traditional SCMs which only look at `HEAD` (last commit)
and the working directory (files).
- Preserves change history of patches.
The complete change history associated with each patch is
maintained directly within GIT. By storing the evolution of a
patch as a sequence of GIT commits standard GIT history tools
such as gitk can be used.
- Its prune proof.
The metadata structure is stored entirely within the refs
directory and the object database, which means you can safely use
git-prune without damaging your work, even for unapplied patches.
- Preserves patch series during clone.
The metadata structure used by pg allows git-clone to preserve
the patch series information, without changes required to
git-clone. (Patch series information is not preserved during
git-pull/git-push however.)
- Mix and matching of changes (bug fixes/features).
By maintaining changes as individual patches it is possible to
apply individual changes to the current working directory and
to unapply them just as easily.
- Automatic detection (and cancellation) of returning patches.
pg automatically detects when a patch is received from
the upstream GIT repository during a pg-rebase and deletes
(cancels) the local version of the patch from the patch series.
The automatic cancelling makes it easy to use pg to track and
develop changes on top of a GIT project.
- Fast
pg operations generally perform faster than StGIT operations,
at least on my large (~7000 file) repositories.
And for those so inclined:
Homepage: http://www.spearce.org/projects/scm/pg/
GIT Repository: http://www.spearce.org/projects/scm/pg.git
--
Shawn.
^ permalink raw reply
* Re: git-apply segfault.
From: Dave Jones @ 2006-02-10 19:41 UTC (permalink / raw)
To: Linus Torvalds; +Cc: git
In-Reply-To: <Pine.LNX.4.64.0602101120440.19172@g5.osdl.org>
On Fri, Feb 10, 2006 at 11:22:46AM -0800, Linus Torvalds wrote:
>
>
> On Fri, 10 Feb 2006, Dave Jones wrote:
> >
> > (gdb) bt
> > #0 0x0000003287f73474 in memset () from /lib64/libc.so.6
> > #1 0x0000003287f6c92a in calloc () from /lib64/libc.so.6
> > #2 0x0000000000407399 in read_cache () at read-cache.c:537
>
> Ouch. Looks like malloc heap corruption.
Indeed. Self-inflicted in this case.
> > git on hera is 1.1.6-1
> Can you try running "valgrind" on it? That should show what corrupts the
> heap.
Actually it's a glibc bug (fixed last September, but not backported to older releases).
Jakub is working on an FC4 update.
(It also only hits you if you're a loony and have something like
export MALLOC_PERTURB_=$(($RANDOM % 255 + 1))
in your ~/.bashrc)
Dave
^ permalink raw reply
* Re: git-apply segfault.
From: Linus Torvalds @ 2006-02-10 19:22 UTC (permalink / raw)
To: Dave Jones; +Cc: git
In-Reply-To: <20060210183745.GI22611@redhat.com>
On Fri, 10 Feb 2006, Dave Jones wrote:
>
> (gdb) bt
> #0 0x0000003287f73474 in memset () from /lib64/libc.so.6
> #1 0x0000003287f6c92a in calloc () from /lib64/libc.so.6
> #2 0x0000000000407399 in read_cache () at read-cache.c:537
Ouch. Looks like malloc heap corruption.
> git on hera is 1.1.6-1
Can you try running "valgrind" on it? That should show what corrupts the
heap.
Linus
^ permalink raw reply
* [PATCH] delta micro optimization
From: Nicolas Pitre @ 2006-02-10 18:42 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
My kernel work habit made me look at the generated assembly for the
delta code, and one obvious albeit small improvement is this patch.
Signed-off-by: Nicolas Pitre <nico@cam.org>
---
diff --git a/delta.h b/delta.h
index 31d1820..a15350d 100644
--- a/delta.h
+++ b/delta.h
@@ -19,14 +19,14 @@ extern void *patch_delta(void *src_buf,
static inline unsigned long get_delta_hdr_size(const unsigned char **datap)
{
const unsigned char *data = *datap;
- unsigned char cmd = *data++;
- unsigned long size = cmd & ~0x80;
- int i = 7;
- while (cmd & 0x80) {
+ unsigned char cmd;
+ unsigned long size = 0;
+ int i = 0;
+ do {
cmd = *data++;
size |= (cmd & ~0x80) << i;
i += 7;
- }
+ } while (cmd & 0x80);
*datap = data;
return size;
}
^ permalink raw reply related
* git-apply segfault.
From: Dave Jones @ 2006-02-10 18:37 UTC (permalink / raw)
To: git
I managed to get git-apply to segfault.
(18:35:37:davej@hera:agpgart)$ apply-mbox ~/Mail/mbox
Applying 'help text updates'
/home/davej/bin/applypatch: line 64: 17990 Segmentation fault (core dumped) git-apply --index $PATCHFILE
(18:35:40:davej@hera:agpgart)$ file core
core: ELF 64-bit LSB core file AMD x86-64, version 1 (SYSV), SVR4-style, from 'git-apply'
(18:35:45:davej@hera:agpgart)$ gdb `which git-apply` core
GNU gdb Red Hat Linux (6.3.0.0-1.84rh)
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB. Type "show warranty" for details.
This GDB was configured as "x86_64-redhat-linux-gnu"...Using host libthread_db library "/lib64/libthread_db.so.1".
Core was generated by `git-apply --index .dotest/patch'.
Program terminated with signal 11, Segmentation fault.
Reading symbols from /usr/lib64/libz.so.1...done.
Loaded symbols for /usr/lib64/libz.so.1
Reading symbols from /lib64/libcrypto.so.5...done.
Loaded symbols for /lib64/libcrypto.so.5
Reading symbols from /lib64/libc.so.6...done.
Loaded symbols for /lib64/libc.so.6
Reading symbols from /lib64/libdl.so.2...done.
Loaded symbols for /lib64/libdl.so.2
Reading symbols from /lib64/ld-linux-x86-64.so.2...done.
Loaded symbols for /lib64/ld-linux-x86-64.so.2
#0 0x0000003287f73474 in memset () from /lib64/libc.so.6
(gdb) bt
#0 0x0000003287f73474 in memset () from /lib64/libc.so.6
#1 0x0000003287f6c92a in calloc () from /lib64/libc.so.6
#2 0x0000000000407399 in read_cache () at read-cache.c:537
#3 0x0000000000404e1b in apply_patch (fd=-1) at apply.c:1749
#4 0x0000000000405632 in main (argc=3, argv=0x7fffff841c38) at apply.c:1860
#5 0x0000003287f1c3cf in __libc_start_main () from /lib64/libc.so.6
#6 0x0000000000402459 in _start ()
#7 0x00007fffff841c28 in ?? ()
#8 0x0000000000000000 in ?? ()
git on hera is 1.1.6-1
Dave
^ permalink raw reply
* Re: [PATCH] count-delta.c: Match the delta data semantics change in version 3.
From: Junio C Hamano @ 2006-02-10 17:19 UTC (permalink / raw)
To: Nicolas Pitre; +Cc: git
In-Reply-To: <Pine.LNX.4.64.0602101017420.5397@localhost.localdomain>
You are right about that comment. Thanks.
^ permalink raw reply
* Re: Two crazy proposals for changing git's diff commands
From: Mark Wooding @ 2006-02-10 17:06 UTC (permalink / raw)
To: git
In-Reply-To: <7vfyms0x4p.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano <junkio@cox.net> wrote:
> In order to rewrite this mess to be more manageable, I would
> first do "diff master topic", to extract the changes into a
> single patch, start picking pieces from it to get logically
> self-contained units, and start building on top of "master":
[etc.]
Oh, good. It's not just me, then! ;-)
This is more or less exactly how I built the various patches I submitted
here. The main difference is that I used StGIT because I'm less
competent than Junio and didn't always manage to get all my changes in
the right places to begin with.
(I really look forward to a StGIT which can withstand git-prune.)
-- [mdw]
^ permalink raw reply
* RE: What's in git.git
From: Luck, Tony @ 2006-02-10 17:03 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
[-- Attachment #1: Type: text/plain, Size: 1604 bytes --]
> Yup. Sorry I did not make that clear. You deserve the credit.
Thanks (and that wasn't a grumble, just a point of information)
> I am beginning to feel this workflow might benefit from some
> tool support, but I haven't had enough experience to talk about
> exactly what they are yet.
I feel that I have settled into a rut. My topic workflow works
fairly well, so I'm not really working on cleaning any remaining
rough edges. It will be good to have some other eyes (especially
some eyes that have been keeping a close eye on all the new features
that have been added to the rest of git) looking at this.
> For example, listing topics that have ever been merged into a
> particular branch, listing topics that have not been fully
> merged into a particular branch, etc. are things I find myself
> doing frequently. I vaguely recall seeing your post that has
> these things.
At the end of the using-topic-branches file there is an example
"status" script. My real script has had some updates (see attached)
that reports on extra bits (like whether Linus as made new packfiles
that I should pull down). And ignoring some special (to me) branch
names when reporting. But it has lots of hard-coded paths for my
workflow. Branches "linus", "release" and "test" are very special.
I have no "master" or "origin" branches at all. But the net output
seems to be what you want ... for each topic branch it reports
whether that branch has already been merged to the test/release/linus
branches, and whether I have commits in my release branch that are
not in test.
-Tony
[-- Attachment #2: tl-status --]
[-- Type: application/octet-stream, Size: 2073 bytes --]
#!/bin/bash
# report on status of my ia64 GIT tree
gb=$(tput setab 2)
rb=$(tput setab 1)
restore=$(tput setab 9)
# Get status of trees @ kernel.org
eval $(socksify ssh master.kernel.org '\
echo release=$(cat scm/linux-2.6.git/refs/heads/release) ; \
echo test=$(cat scm/linux-2.6.git/refs/heads/test) ; \
echo linus=$(cat torvalds/linux-2.6.git/refs/heads/master) ; \
echo packfiles=\"$(ls torvalds/linux-2.6.git/objects/pack)\" ')
cd /home/aegl/GIT/work
echo $gb ======= linus ====== $restore
local=`cat .git/refs/heads/linus`
if [ "$linus" = "$local" ]
then
echo -e "\tUp to date"
else
echo -e "\tNeed to pull from kernel.org"
fi
eval $(echo mypackfiles=\"$(ls .git/objects/pack)\")
if [ "$packfiles" != "$mypackfiles" ]
then
echo $rb New packfiles in Linus tree $restore
echo He has "<$packfiles>"
echo I have "<$mypackfiles>"
fi
for branch in release test
do
echo $gb ======= $branch ====== $restore
local=`cat .git/refs/heads/$branch`
if [ "${!branch}" = "$local" ]
then
echo -e "\tUp to date"
else
echo -e "\tNeed to push to kernel.org"
fi
if [ `git-rev-list linus ^$branch | wc -l` -gt 0 ]
then
echo -e "\tNeeds merge from linus"
fi
done
if [ `git-rev-list release --no-merges ^test | wc -c` -gt 0 ]
then
echo $rb Warning: commits in release that are not in test $restore
git-whatchanged release ^test | git-shortlog
fi
for branch in `ls -rt .git/refs/heads | awk '{print $NF}'`
do
case "$branch" in
linus | release | test | base-* | bad-* | EXP-* )
continue
;;
esac
age=$(git-cat-file commit $branch | grep '^author' | awk '{print $(NF-1)}')
echo -n $gb ======= $branch "(`showtime $age`)" ====== $restore " "
status=
for ref in test release linus
do
if [ `git-rev-list $branch ^$ref | wc -c` -gt 0 ]
then
status=$status${ref:0:1}
fi
done
case $status in
trl)
echo $rb Need to pull into test $restore
;;
rl)
echo "In test"
;;
l)
echo "Waiting for linus"
;;
"")
echo $rb All done $restore
;;
*)
echo $rb "<$status>" $restore
;;
esac
git-whatchanged $branch ^linus | git-shortlog
done
^ permalink raw reply
* Re: What's in git.git
From: Junio C Hamano @ 2006-02-10 15:02 UTC (permalink / raw)
To: Tony Luck; +Cc: git
In-Reply-To: <12c511ca0602091514p35c3904bha8d5d406e5472969@mail.gmail.com>
Tony Luck <tony.luck@intel.com> writes:
> On 2/8/06, Junio C Hamano <junkio@cox.net> wrote:
> [ ... about the "next" branch ... ]
>
> This is pretty much the workflow in my test/release branches (mostly
> documented in Documentation/howto/using-topic-branches.txt).
Yup. Sorry I did not make that clear. You deserve the credit.
I am beginning to feel this workflow might benefit from some
tool support, but I haven't had enough experience to talk about
exactly what they are yet.
For example, listing topics that have ever been merged into a
particular branch, listing topics that have not been fully
merged into a particular branch, etc. are things I find myself
doing frequently. I vaguely recall seeing your post that has
these things.
^ 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