* Re: blame now knows -S
From: Junio C Hamano @ 2006-04-08 20:39 UTC (permalink / raw)
To: Fredrik Kuivinen; +Cc: Martin Langhoff, git
In-Reply-To: <20060408114240.GA10137@c165.ib.student.liu.se>
Fredrik Kuivinen <freku045@student.liu.se> writes:
> There is another possible optimisation with respect to xdiff. Instead
> of producing the diff on the xdiff side and parsing the diff in
> blame.c, we could add another call back which just gets the relevant
> information from the hunk header. I don't know how much we would gain
> from this, but it might be worth a try.
I've tried and then it turned out it did not make much of a
difference.
^ permalink raw reply
* Re: [PATCH] Fix test for command line syntax.
From: Peter Eriksen @ 2006-04-08 20:29 UTC (permalink / raw)
To: git
In-Reply-To: <20060408202450.GA5548@bohr.gbar.dtu.dk>
On Sat, Apr 08, 2006 at 10:24:50PM +0200, Peter Eriksen wrote:
>
> Signed-off-by: Peter Eriksen <s022018@student.dtu.dk>
>
>
> ---
>
> test-delta.c | 2 +-
> 1 files changed, 1 insertions(+), 1 deletions(-)
Please ignore this. Sorry for the noise.
Peter
^ permalink raw reply
* [PATCH] Fix test for command line syntax.
From: Peter Eriksen @ 2006-04-08 20:24 UTC (permalink / raw)
To: git
Signed-off-by: Peter Eriksen <s022018@student.dtu.dk>
---
test-delta.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
3e2552fff69fb01249fed53380e24e11754afcdf
diff --git a/test-delta.c b/test-delta.c
index 1be8ee0..94b47f0 100644
--- a/test-delta.c
+++ b/test-delta.c
@@ -27,7 +27,7 @@ int main(int argc, char *argv[])
void *from_buf, *data_buf, *out_buf;
unsigned long from_size, data_size, out_size;
- if (argc != 5 || (strcmp(argv[1], "-d") && strcmp(argv[1], "-p"))) {
+ if (argc != 5 || (strcmp(argv[1], "-d") || strcmp(argv[1], "-p"))) {
fprintf(stderr, "Usage: %s\n", usage);
return 1;
}
--
1.3.0.rc1.g40e9
^ permalink raw reply related
* Re: [PATCH] Script for automated historical Git tree grafting
From: Nicholas Miell @ 2006-04-08 20:04 UTC (permalink / raw)
To: Petr Baudis; +Cc: Andrew Morton, torvalds, linux-kernel, git
In-Reply-To: <20060408030936.GN27631@pasky.or.cz>
On Sat, 2006-04-08 at 05:09 +0200, Petr Baudis wrote:
> Dear diary, on Fri, Apr 07, 2006 at 02:52:46AM CEST, I got a letter
> where Andrew Morton <akpm@osdl.org> said that...
> > Petr Baudis <pasky@suse.cz> wrote:
> > >
> > > This script enables Git users to easily graft the historical Git tree
> > > (Bitkeeper history import) to the current history.
> >
> > What impact will that have on the (already rather poor) performance of
> > git-whatchanged, gitk, etc?
>
> Negative. ;-)
>
> I didn't try gitk myself, but according to Nick Riviera it eats 1.6G...
> Otherwise, assuming that you have at least git-1.2.5, git-whatchanged on
> the whole tree should be roughly equally fast as it was before grafting,
> but git-whatchanged on individual paths is _significantly_ slower.
>
> That said, 1.3.0rc2 should already have Linus' optimization which should
> fix or at least mitigate the performance hit on narrowed-down
> git-whatchanged.
Actually, it ate more than 1.6G -- that was just the resident size, and
it likes to allocate more memory in between you closing the window and
it finally exiting (or, you killing it before it OOMs the box, whichever
comes first).
qgit has absolutely no problem with the grafted full history, though,
and those previously mentioned rev-list changes by Linus should fix
git-whatchanged.
Unfortunately, this does nothing to fix the disturbing lack of useless
Simpsons trivia knowledge in the git community. Keith Packard made the
same mistake last week.
--
Nicholas Miell <nmiell@comcast.net>
^ permalink raw reply
* strange behavior when pulling updates / get uptodate with git.git
From: Nicolas Vilz 'niv' @ 2006-04-08 19:57 UTC (permalink / raw)
To: git
Hello guys,
I experience a loss of tags- and branch-updates, when I try to update my
repository.
I normaly do following
git checkout master
git pull origin
my .git/remotes/origin-file looks like this:
URL: git://git.kernel.org/pub/scm/git/git.git
Pull: refs/heads/master:refs/heads/origin
Pull: refs/heads/todo:refs/heads/todo
Pull: refs/heads/maint:refs/heads/maint
Pull: refs/heads/pu:refs/heads/pu
Pull: refs/heads/man:refs/heads/man
Pull: refs/heads/next:refs/heads/next
Pull: refs/heads/html:refs/heads/html
so i suppose, if i try to pull origin, and i am in master, i should be
able to pull these remote heads each in the correct local head...
But I obviously don't.
after deleting the actual git-repository directory and recloning with
git clone <url>
I have obviously more tags than git was trying to merge before at git
pull origin..
I use git version 1.3.0.rc1.g4c0f (located in the next-tree).
Any hints how this could be better on my system?
Sincerly
Nicolas
^ permalink raw reply
* Re: Funny repack behaviour
From: Nicolas Pitre @ 2006-04-08 19:44 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git
In-Reply-To: <Pine.LNX.4.63.0604081233170.3283@wbgn013.biozentrum.uni-wuerzburg.de>
On Sat, 8 Apr 2006, Johannes Schindelin wrote:
> Hi,
>
> I just accidentally reran "git-repack -a -d" on a repository, where I just
> had run it. And I noticed a funny thing: Of about 4000 objects, it reused
> all but 8. So I reran it, and it reused all but 2. I ran it once again,
> and it reused all.
>
> The really funny thing is: it created the same pack every time!
Probably not. Subsequent packs were most probably even smaller !
> It is not critical, evidently, but I'd like to know what is causing this
> rather undeterministic behaviour. (Before you ask: no, I did not make a
> backup before running the tests, so I unfortunately cannot reproduce it).
To reproduce, or rather to reset the pack state, just use
"git-repack -a -f -d" then "git-repack -a -d" multiple times again.
For example, on the current git archive:
$ git-repack -a -f -d
[...]
Total 16548, written 16548 (delta 11007), reused 5390 (delta 0)
Pack pack-af9d39abfcb5fd6fd554f7fc8d1704f8dd2329e0 created.
pack size = 6032083 bytes.
$ git-repack -a -d
[...]
Total 16548, written 16548 (delta 11030), reused 16525 (delta 11007)
Pack pack-af9d39abfcb5fd6fd554f7fc8d1704f8dd2329e0 created.
pack size = 5976610 bytes
$ git-repack -a -d
[...]
Total 16548, written 16548 (delta 11030), reused 16548 (delta 11030)
Pack pack-af9d39abfcb5fd6fd554f7fc8d1704f8dd2329e0 created.
Pack size = 5976610 bytes
So in this case it took 2 itterations before converging on a smaller
pack by 55473 bytes.
I thought the reuse logic might sacrifice a bit on compression given the
speed boost, but I don't get why it is the opposite in practice and that
-f doesn't produce the smallest pack up front.
Nicolas
^ permalink raw reply
* Re: How to create independent branches
From: Jakub Narebski @ 2006-04-08 18:28 UTC (permalink / raw)
To: git
In-Reply-To: <20060408180244.GA4807@xp.machine.de>
Peter Baumann wrote:
> Another question. I'd like to create a totaly independent branch (like
> the "todo" branch in git). Is there a more user friendly way than doing
>
> git-checkout -b todo
> rm .git/refs/heads/todo
> rm .git/index
> rm <all_files_in_your_workdir>
>
> ... hack hack hack ...
> git-commit -a
Wouldn't it be better and more natural to go back to first commit, or even
empty repository state at the beginning, and branch there? Or make separate
repository?
--
Jakub Narebski
Warsaw, Poland
^ permalink raw reply
* How to create independent branches
From: Peter Baumann @ 2006-04-08 18:02 UTC (permalink / raw)
To: git
In-Reply-To: <7vr749i48s.fsf@assigned-by-dhcp.cox.net>
On Fri, Apr 07, 2006 at 12:18:27PM -0700, Junio C Hamano wrote:
> Peter Baumann <peter.baumann@gmail.com> writes:
>
> > How can I get the inital commit as a patch?
>
> format-patch is designed to get a patch to send to upstream, and
> does not handle the root commit. In your two revisions
> repository, you could do something like this:
>
> $ git diff-tree -p --root master~1
>
> Or more in general:
>
> $ git rev-list master |
> git diff-tree --stdin --root --pretty=fuller -p
>
> BTW, I've been meaning to add --pretty=patch to give
> format-patch compatible output to diff-tree, but haven't got
> around to actually do it. Another thing I've been meaning to do
> is "git log --diff" which is more or less "git whatchanged".
>
Ok. That did it.
Another question. I'd like to create a totaly independent branch (like
the "todo" branch in git). Is there a more user friendly way than doing
git-checkout -b todo
rm .git/refs/heads/todo
rm .git/index
rm <all_files_in_your_workdir>
... hack hack hack ...
git-commit -a
I looked all over the docs, but can't find anything obvious.
-Peter
^ permalink raw reply
* Re: [PATCH] xdiff/xdiffi.c: fix warnings about possibly uninitialized variables
From: Davide Libenzi @ 2006-04-08 17:18 UTC (permalink / raw)
To: Marco Roeland; +Cc: git
In-Reply-To: <20060408152720.GA11125@fiberbit.xs4all.nl>
On Sat, 8 Apr 2006, Marco Roeland wrote:
> Compiling this module gave the following warnings (some double dutch!):
>
> xdiff/xdiffi.c: In functie 'xdl_recs_cmp':
> xdiff/xdiffi.c:298: let op: 'spl.i1' may be used uninitialized in this function
> xdiff/xdiffi.c:298: let op: 'spl.i2' may be used uninitialized in this function
> xdiff/xdiffi.c:219: let op: 'fbest1' may be used uninitialized in this function
> xdiff/xdiffi.c:219: let op: 'bbest1' may be used uninitialized in this function
>
> A superficial tracking of their usage, without deeper knowledge about the
> algorithm, indeed confirms that there are code paths on which these
> variables will be used uninitialized. In practice these code paths might never
> be reached, but then these fixes will not change the algorithm. If these
> code paths are ever reached we now at least have a predictable outcome. And
> should the very small performance impact of these initializations be
> noticeable, then they should at least be replaced by comments why certain
> code paths will never be reached.
These paths are never reached because of the way data is prepared before
and passed to the function. Unfortunately the compiler cannot know this.
Using them as -1 or XDL_LINE_MAX won't help either, since those are out of
domain values. You can leave it there and the algo won't suffer, or you
can relax a little the warning level when building the file.
- Davide
^ permalink raw reply
* [PATCH] xdiff/xdiffi.c: fix warnings about possibly uninitialized variables
From: Marco Roeland @ 2006-04-08 15:27 UTC (permalink / raw)
To: git; +Cc: Davide Libenzi
Compiling this module gave the following warnings (some double dutch!):
xdiff/xdiffi.c: In functie 'xdl_recs_cmp':
xdiff/xdiffi.c:298: let op: 'spl.i1' may be used uninitialized in this function
xdiff/xdiffi.c:298: let op: 'spl.i2' may be used uninitialized in this function
xdiff/xdiffi.c:219: let op: 'fbest1' may be used uninitialized in this function
xdiff/xdiffi.c:219: let op: 'bbest1' may be used uninitialized in this function
A superficial tracking of their usage, without deeper knowledge about the
algorithm, indeed confirms that there are code paths on which these
variables will be used uninitialized. In practice these code paths might never
be reached, but then these fixes will not change the algorithm. If these
code paths are ever reached we now at least have a predictable outcome. And
should the very small performance impact of these initializations be
noticeable, then they should at least be replaced by comments why certain
code paths will never be reached.
Some extra initializations in this patch now fix the warnings.
---
xdiff/xdiffi.c | 5 +++--
1 files changed, 3 insertions(+), 2 deletions(-)
0b0bf00d67a66b3ef47862cc51b1d37763f4b99b
diff --git a/xdiff/xdiffi.c b/xdiff/xdiffi.c
index e81bca6..641362d 100644
--- a/xdiff/xdiffi.c
+++ b/xdiff/xdiffi.c
@@ -218,7 +218,7 @@ static long xdl_split(unsigned long cons
if (ec >= xenv->mxcost) {
long fbest, fbest1, bbest, bbest1;
- fbest = -1;
+ fbest = fbest1 = -1;
for (d = fmax; d >= fmin; d -= 2) {
i1 = XDL_MIN(kvdf[d], lim1);
i2 = i1 - d;
@@ -230,7 +230,7 @@ static long xdl_split(unsigned long cons
}
}
- bbest = XDL_LINE_MAX;
+ bbest = bbest1 = XDL_LINE_MAX;
for (d = bmax; d >= bmin; d -= 2) {
i1 = XDL_MAX(off1, kvdb[d]);
i2 = i1 - d;
@@ -296,6 +296,7 @@ int xdl_recs_cmp(diffdata_t *dd1, long o
} else {
long ec;
xdpsplit_t spl;
+ spl.i1 = spl.i2 = 0;
/*
* Divide ...
--
1.3.0.rc3.gad0b
^ permalink raw reply related
* Re: blame now knows -S
From: Marco Costalba @ 2006-04-08 13:53 UTC (permalink / raw)
To: Fredrik Kuivinen; +Cc: Junio C Hamano, Martin Langhoff, git
In-Reply-To: <20060408114240.GA10137@c165.ib.student.liu.se>
On 4/8/06, Fredrik Kuivinen <freku045@student.liu.se> wrote:
> On Fri, Apr 07, 2006 at 02:28:40AM -0700, Junio C Hamano wrote:
> > I've made a few changes to "git blame" myself:
> >
> > - fix breakage caused by recent revision walker reorganization;
> > - use built-in xdiff instead of spawning GNU diff;
> > - implement -S <ancestry-file> like annotate does.
> >
> > Depending on the density of changes, it now appears that blame
> > is 10%-30% faster than annotate. I thought CVS emulator might
> > be interested to give it a whirl..
> >
>
> Nice work!
>
> There is another possible optimisation with respect to xdiff. Instead
> of producing the diff on the xdiff side and parsing the diff in
> blame.c, we could add another call back which just gets the relevant
> information from the hunk header. I don't know how much we would gain
> from this, but it might be worth a try.
>
If I can comment on this thread, I would like to note IMHO that given
the differences in
languages (C vs Perl) and the use of almost the same algorithm, just a
10%-30% in speed difference between blame and annotate it means that
any further optimization can gain little because the bottleneck is
elsewhere.
And I think is in getting the revision's history. Call it
git-rev-list, although both
blame and annotate use directly the library revision.h
After the new xdiff merge, git-rev-list accounts for almost whole the time.
Normally more then 80% in qgit.
Although the qgit annotation algorithm is different from both blame
and annotate I think
that a faster git-rev-list <path> or revison history walker as you may
want to call it it's a key
in really speed-up annotation stuff.
Marco
^ permalink raw reply
* Re: blame now knows -S
From: Fredrik Kuivinen @ 2006-04-08 11:42 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Martin Langhoff, git, Fredrik Kuivinen
In-Reply-To: <7v1ww9loon.fsf@assigned-by-dhcp.cox.net>
On Fri, Apr 07, 2006 at 02:28:40AM -0700, Junio C Hamano wrote:
> I've made a few changes to "git blame" myself:
>
> - fix breakage caused by recent revision walker reorganization;
> - use built-in xdiff instead of spawning GNU diff;
> - implement -S <ancestry-file> like annotate does.
>
> Depending on the density of changes, it now appears that blame
> is 10%-30% faster than annotate. I thought CVS emulator might
> be interested to give it a whirl..
>
Nice work!
There is another possible optimisation with respect to xdiff. Instead
of producing the diff on the xdiff side and parsing the diff in
blame.c, we could add another call back which just gets the relevant
information from the hunk header. I don't know how much we would gain
from this, but it might be worth a try.
- Fredrik
^ permalink raw reply
* Re: [ANNOUNCE] qgit-1.2rc1
From: Marco Costalba @ 2006-04-08 11:07 UTC (permalink / raw)
To: git; +Cc: linux-kernel
In-Reply-To: <e5bfff550604080244y40b36292ja5cfecac28e1e749@mail.gmail.com>
On 4/8/06, Marco Costalba <mcostalba@gmail.com> wrote:
> qgit is a very fast git GUI viewer with a lot of features .
>
> The biggest new feature this time is *code range filtering*
>
Before hitting the warning pop-up about git version compatibility at
qgit launch,please note that a git with --boundary option support
is required.
git-rev-list --boundary has been merged after git-1.3.0.rc1, so better
upgrade git to latest upstream snapshot git-1.3.0rc3
Of course final qgit-1.2 will be out only _after_ released git-1.3.0
Marco
^ permalink raw reply
* Funny repack behaviour
From: Johannes Schindelin @ 2006-04-08 10:41 UTC (permalink / raw)
To: git
Hi,
I just accidentally reran "git-repack -a -d" on a repository, where I just
had run it. And I noticed a funny thing: Of about 4000 objects, it reused
all but 8. So I reran it, and it reused all but 2. I ran it once again,
and it reused all.
The really funny thing is: it created the same pack every time!
It is not critical, evidently, but I'd like to know what is causing this
rather undeterministic behaviour. (Before you ask: no, I did not make a
backup before running the tests, so I unfortunately cannot reproduce it).
Ciao,
Dscho
P.S.: This is the output:
$ git-repack -a -d
Generating pack...
Done counting 4259 objects.
Deltifying 4259 objects.
100% (4259/4259) done
Writing 4259 objects.
100% (4259/4259) done
Total 4259, written 4259 (delta 3391), reused 4241 (delta 3379)
Pack pack-66bd976bbdc2ac6da623b8af02037218ecd72ef0 created.
$ git-repack -a -d
Generating pack...
Done counting 4259 objects.
Deltifying 4259 objects.
100% (4259/4259) done
Writing 4259 objects.
100% (4259/4259) done
Total 4259, written 4259 (delta 3393), reused 4257 (delta 3391)
Pack pack-66bd976bbdc2ac6da623b8af02037218ecd72ef0 created.
$ git-repack -a -d
Generating pack...
Done counting 4259 objects.
Deltifying 4259 objects.
100% (4259/4259) done
Writing 4259 objects.
100% (4259/4259) done
Total 4259, written 4259 (delta 3393), reused 4259 (delta 3393)
Pack pack-66bd976bbdc2ac6da623b8af02037218ecd72ef0 created.
^ permalink raw reply
* [ANNOUNCE] qgit-1.2rc1
From: Marco Costalba @ 2006-04-08 9:44 UTC (permalink / raw)
To: git; +Cc: linux-kernel
qgit is a very fast git GUI viewer with a lot of features .
The biggest new feature this time is *code range filtering*
Select a file and open the file/annotation viewer, then wait for
annotation finished and then select a history revision just to be sure
annotation info is displayed.
You will see the new 'filter' button (in annotation window tool
bar, not in main view tool bar) enabled. Press it and the file history
will be shrinked to show only revisions that modified the selected lines.
Selected code region is also highlighted for better browsing.
Filter button is a toggle button, so just press again it to release the filter.
NOTE NOTE: Range filtering it's _slippery_ code, there are a lot of
subtle details involved, so may be something it's still missing/bogous,
qgit-1.2rc1 it's here to let properly test before final release.
DOWNLOAD
Tarball is at
http://prdownloads.sourceforge.net/qgit/qgit-1.2rc1.tar.bz2?download
Git archive is at
http://digilander.libero.it/mcostalba/scm/qgit.git
See http://digilander.libero.it/mcostalba/ for detailed download information.
INSTALLATION
To install from tarball use:
./configure
make
make install-strip
To install from git archive:
autoreconf -i
./configure
make
make install-strip
Or check the shipped README for detailed information.
CHANGELOG
- add support for code range filtering
- much improved graph for partial repos views. Use new --boundary
git-rev-list option
- pressing ESC in startup dialog make application to quit
- add support for quick open of latest visited repositories
- add support for launching an external diff viewer
- speed-up git commands execution using usleep() in external program launcher
- highlight filter matches in revision logs
- add git version compatibility check
- fix duplicated unapplied patches in StGIT when qgit is called with
--all option
- fix run from subdirectory regression
Marco
^ permalink raw reply
* GIT 1.3.0-rc3
From: Junio C Hamano @ 2006-04-08 8:07 UTC (permalink / raw)
To: git
I do not think there are any more remaining major issue for a
real 1.3.0, so here is hopefully the final round of rc. Testing,
fixing and polishing are appreciated.
Changes since v1.3.0-rc2 are as follows:
* documentation (Francis Daly, Jon Loeliger, Marco Roeland)
* add regexp to pickaxe (Petr Baudis)
* add git-clean (Pavel Roskin)
* cvsimport fix (Johannes Schindelin)
* svnimport fix (Karl Hasselström)
* imap-send updates (Mike McCormack)
* assorted build and porting fixes (Johannes Schindelin)
* gitk updates (Keith Packard, Mark Wooding, Paul Mackerras, Pavel Roskin
Rutger Nijlunsing, Stephen Rothwell)
* http-fetch can use PROPFIND in place of objects/info/packs (Nick Hengeveld)
* deltifier bounds safety (Nicolas Pitre)
* clone fix
* fix blame, broken by recent revision walker updates
* use built-in-xdiff in combine-diff
* use built-in-xdiff in blame
* support -S in blame
* diff_flush() memory leak fix when NO_OUTPUT
* make human-date parsing friendlier to our European friends.
* optimize thin-pack generation by pack-objects
^ permalink raw reply
* Re: [PATCH] Script for automated historical Git tree grafting
From: Petr Baudis @ 2006-04-08 3:09 UTC (permalink / raw)
To: Andrew Morton; +Cc: torvalds, linux-kernel, git
In-Reply-To: <20060406175246.3bd1c972.akpm@osdl.org>
Dear diary, on Fri, Apr 07, 2006 at 02:52:46AM CEST, I got a letter
where Andrew Morton <akpm@osdl.org> said that...
> Petr Baudis <pasky@suse.cz> wrote:
> >
> > This script enables Git users to easily graft the historical Git tree
> > (Bitkeeper history import) to the current history.
>
> What impact will that have on the (already rather poor) performance of
> git-whatchanged, gitk, etc?
Negative. ;-)
I didn't try gitk myself, but according to Nick Riviera it eats 1.6G...
Otherwise, assuming that you have at least git-1.2.5, git-whatchanged on
the whole tree should be roughly equally fast as it was before grafting,
but git-whatchanged on individual paths is _significantly_ slower.
That said, 1.3.0rc2 should already have Linus' optimization which should
fix or at least mitigate the performance hit on narrowed-down
git-whatchanged.
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
Right now I am having amnesia and deja-vu at the same time. I think
I have forgotten this before.
^ permalink raw reply
* Re: git/cogito suggestion: tags with descriptions
From: Petr Baudis @ 2006-04-08 2:35 UTC (permalink / raw)
To: Zack Brown; +Cc: Junio C Hamano, git
In-Reply-To: <20050912010051.GJ15630@pasky.or.cz>
Dear diary, on Mon, Sep 12, 2005 at 03:00:51AM CEST, I got a letter
where Petr Baudis <pasky@suse.cz> said that...
> Dear diary, on Mon, Sep 05, 2005 at 11:24:31PM CEST, I got a letter
> where Zack Brown <zbrown@tumblerings.org> told me that...
> > I'm not sure. I'm not as familiar with the low-level git commands as I am with
> > cogito. But cogito has a -d option for giving a tag description. I guess what
> > would be closest to what I was thinking about would be this:
> >
> > $ cg-tag -d "First draft, everything in place." 0.3 7540e503b9b9c1b03e44ee7fd700c844b2a02224
> > $ cg-tag-ls
> > 0.1 Initial idea complete f953b71b21a0bea682c2bed91362f2dce2cc204f
> > 0.3 First draft, everything in place. 7540e503b9b9c1b03e44ee7fd700c844b2a02224
> > $
> >
> > or something like that. Currently when I do the above cg-tag command,
> > a subsequent cg-tag-ls gives just:
> >
> > $ cg-tag-ls
> > 0.1 f953b71b21a0bea682c2bed91362f2dce2cc204f
> > 0.3 7540e503b9b9c1b03e44ee7fd700c844b2a02224
> >
> > In fact, I probably wouldn't even be interested in seeing the actual hash key
> > unless I gave a special flag, maybe -f (for "full"):
> >
> > $ cg-tag-ls
> > 0.1 Initial idea complete
> > 0.3 First draft, everything in place.
> > $ cg-tag-ls -f
> > 0.1 Initial idea complete f953b71b21a0bea682c2bed91362f2dce2cc204f
> > 0.3 First draft, everything in place. 7540e503b9b9c1b03e44ee7fd700c844b2a02224
>
> That's a nice idea (except that I'd prefer -l). I'll implement this
> after cogito-0.14.
So, I did. ;-) (In the master branch now.) The format is slightly
different from the proposed one:
S cogito-0.16rc2 7766e3ba0664
S cogito-0.17 51392f2dd82a Poetic cogito-0.17.
S cogito-0.17rc1 7cb4d8972d5b Behold, cogito-0.17rc1! Plenty new features and cool stuff.
% cogito-0.8 f9f0459b5b39
% cogito-0.9 cc5517b4ea41
test 05862786175d
Object IDs are still shown, but abbreviated so they shouldn't get in the
way too much; the full first line is shown in the list output,
untrimmed. The initial flag column denotes signed tags by 'S', "direct
tags" (not pointing to a tag object) by '%' and broken tags by '!'.
P.S.: Also, cg-tag received a lot of improvements in the last two days.
Now features the same cool editor as cg-commit (but only if ran with
-e), -d was renamed to -m (but will stay aliased for quite some time),
cg-tag now also accepts multiple -m options for creating multi-paragraph
descriptions from the commandline, and bunch of other minor stuff was
implemented.
Thanks for the idea,
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
Right now I am having amnesia and deja-vu at the same time. I think
I have forgotten this before.
^ permalink raw reply
* [ANNOUNCE] Cogito-0.17.2
From: Petr Baudis @ 2006-04-08 1:06 UTC (permalink / raw)
To: git; +Cc: linux-kernel
Hello,
to join the series of git-related announcements, Cogito-0.17.2, the next
maintenance release on the current stable (v0.17) branch of Cogito, the
human-friendly version control system on top of Git, is available now.
There are only very few changes, it looks that we are pretty stable:
Chris Wright:
cogito spec BuildRequires update
Dennis Stosberg:
cogito: Push tags over http
Petr Baudis:
Improved cg-version output (use cg-object-id -d)
cg-patch -c: Stop also at ^diff --git when slurping the commit message
Fixed embarassing cg-admin-rewritehist bug
Make cg-add/rm warnings less confusing: s/files/items/
cogito-0.17.2
P.S.: Visit us at #git @ FreeNode!
Happy hacking,
--
Petr "Stable 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
* [ANNOUNCE] GIT 1.2.6
From: Junio C Hamano @ 2006-04-08 0:56 UTC (permalink / raw)
To: git; +Cc: linux-kernel
The latest maintenance release GIT 1.2.6 is available at the
usual places:
http://www.kernel.org/pub/software/scm/git/
git-1.2.6.tar.{gz,bz2} (tarball)
RPMS/$arch/git-*-1.2.6-1.$arch.rpm (RPM)
These fixes are my birthday present to git ;-). I'll also do
the 1.3.0-rc3 tonight.
----------------------------------------------------------------
Changes since v1.2.5 are as follows:
Junio C Hamano:
parse_date(): fix parsing 03/10/2006
diff_flush(): leakfix.
count-delta: match get_delta_hdr_size() changes.
Nicolas Pitre:
check patch_delta bounds more carefully
^ permalink raw reply
* [ANNOUNCE] Stacked GIT 0.9
From: Catalin Marinas @ 2006-04-07 22:05 UTC (permalink / raw)
To: git
Stacked GIT 0.9 release is available from http://www.procode.org/stgit/
StGIT is a Python application providing similar functionality to Quilt
(i.e. pushing/popping patches to/from a stack) on top of GIT. These
operations are performed using GIT commands and the patches are stored
as GIT commit objects, allowing easy merging of the StGIT patches into
other repositories using standard GIT functionality.
The main features in this release:
# Faster three-way merge by using 'git-read-tree --aggressive' and
dealing with conflicts internally (gitmergeonefile.py removed)
# StGIT repositories are now 'git prune'-safe
# 'show' command for displaying a given patch
# 'uncommit' command for reversing the effects of 'commit'
# '--series' option added to the 'import' command
# '--merged' option added to the 'push' and 'pull' commands to check
for patches merged upstream
# '--undo' option added to 'refresh'
# Patch refreshing can be done for individual files only
# '--stdout' option added to 'export'
# '--mbox' option added to 'mail'
# 'smtpdelay' configuration option for delays between messages sending
# $PAGER or the 'pager' configuration option used for the 'show' and
'diff' commands
# '--force' option removed from the 'new' command
# Bug fixes
Acknowledgements (generated with 'git shortlog'):
Catalin Marinas:
Fix the clone command failure
Fix the 'status --reset' for individual files
Remove the --force option for new
Allow patch refreshing for some files only
Use the GIT-specific environment as default
Check whether the file exists in the fold command
Add prune-safety to StGIT
Allow tag objects to be passed on the command line
Add --stdout option to export
Add --mbox option to the 'mail' command
Fix the e-mail address escaping
Fix the reset command to set HEAD to a proper id
Allow stg to be loaded in pydb and not run main()
Print a shorter usage message with the --help option
Add a merged upstream test for pull and push
Add --series to import
Cache the base_dir value for subsequent calls
Pass the --aggressive flag to git-read-tree
gitmergeonefile.py should use git.get_base_dir()
Deal with merge conflicts directly
Add the --patch option to export
Add the --strip option to import
Fix the patch name stripping in import
Update the TODO file
The gitmergeonefile config section is deprecated
Add the "smtpdelay" config option
Create stgit/basedir.py for determining the .git directory
Remove the checking for the default configuration values
Add extra headers to the e-mail messages
Add the '--undo' option to 'refresh'
Add a 'show' command
Remove the basedir exception throwing
Use a pager for diff and show commands
Use 'git-*' instead of 'git *'
Release 0.9
Chuck Lever:
"stg pull" says "popping all patches" even when it doesn't
Use a separate directory for patches under each branch subdir
Add an option to "stg branch" to convert the internal format
Karl Hasselström:
[PATCH 2/2] Add 'stg uncommit' command
Use --refid option even when sending a cover mail
Change the signature start string to "-- \n"
Update .git/refs/heads/base after patch deletion
Kirill Smelkov:
[trivial] fix spelling typos
Paolo 'Blaisorblade' Giarrusso:
Stgit - gitmergeonefile.py: handle removal vs. changes
Pass --directory to git-ls-files for stg status
Pavel Roskin:
stgit: typo fixes
Make tutorial a valid asciidoc article.
stg export: check if there are any patches to export
Treat "stg --help cmd" and "stg help cmd" like "stg cmd
Improve "stg uncommit" help text.
Sam Vilain:
common: parse 'email (name)' correctly
--
Catalin
^ permalink raw reply
* [PATCH] Fix paths on FreeBSD by processing gitk like other scripts
From: Eric Anholt @ 2006-04-07 21:03 UTC (permalink / raw)
To: git
[-- Attachment #1.1: Type: text/plain, Size: 327 bytes --]
The paths for python and tk are not /usr/bin for FreeBSD, so I moved
gitk to gitk.tk and added a rule to sed in the proper path to "wish" in
making gitk, and also added the appropriate default path for python.
--
Eric Anholt anholt@FreeBSD.org
eric@anholt.net eric.anholt@intel.com
[-- Attachment #1.2: git-freebsd.diff --]
[-- Type: text/x-patch, Size: 1635 bytes --]
diff --git a/.gitignore b/.gitignore
index b5959d6..e9d5a7b 100644
--- a/.gitignore
+++ b/.gitignore
@@ -121,6 +121,7 @@ git-verify-tag
git-whatchanged
git-write-tree
git-core-*/?*
+gitk
test-date
test-delta
common-cmds.h
diff --git a/Makefile b/Makefile
index 3367b8c..de28dec 100644
--- a/Makefile
+++ b/Makefile
@@ -136,6 +136,9 @@ SCRIPT_PERL = \
SCRIPT_PYTHON = \
git-merge-recursive.py
+SCRIPT_TK = \
+ gitk.tk
+
SCRIPTS = $(patsubst %.sh,%,$(SCRIPT_SH)) \
$(patsubst %.perl,%,$(SCRIPT_PERL)) \
$(patsubst %.py,%,$(SCRIPT_PYTHON)) \
@@ -174,6 +177,15 @@ # Backward compatibility -- to be remove
PROGRAMS += git-ssh-pull$X git-ssh-push$X
# Set paths to tools early so that they can be used for version tests.
+ifeq ($(uname_S),FreeBSD)
+ ifndef PYTHON_PATH
+ PYTHON_PATH = /usr/local/bin/python
+ endif
+ ifndef WISH_PATH
+ WISH_PATH = /usr/local/bin/wish8.4
+ endif
+endif
+
ifndef SHELL_PATH
SHELL_PATH = /bin/sh
endif
@@ -183,6 +195,9 @@ endif
ifndef PYTHON_PATH
PYTHON_PATH = /usr/bin/python
endif
+ifndef WISH_PATH
+ WISH_PATH = wish
+endif
PYMODULES = \
gitMergeCommon.py
@@ -484,6 +499,12 @@ common-cmds.h: Documentation/git-*.txt
-e 's|@@GIT_PYTHON_PATH@@|$(GIT_PYTHON_DIR_SQ)|g' \
-e 's/@@GIT_VERSION@@/$(GIT_VERSION)/g' \
$@.py >$@
+ chmod +x $@
+
+$(patsubst %.tk,%,$(SCRIPT_TK)) : % : %.tk
+ rm -f $@
+ sed -e "s|exec wish|exec $(WISH_PATH)|" \
+ $@.tk >$@
chmod +x $@
git-cherry-pick: git-revert
diff --git a/gitk b/gitk.tk
similarity index 100%
rename from gitk
rename to gitk.tk
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 187 bytes --]
^ permalink raw reply related
* Re: realloc
From: Junio C Hamano @ 2006-04-07 20:35 UTC (permalink / raw)
To: git
In-Reply-To: <118833cc0604071311v1da93f83n112cc2ea44552ca9@mail.gmail.com>
"Morten Welinder" <mwelinder@gmail.com> writes:
> I could be wrong, but shouldn't
>
> var = realloc (var, whatever);
>
> be changed to call xrealloc? That, or assign to a different variable and check
> for NULL.
>
> This should affect the last four hits below.
>
> M.
>
>
>
>
> /scratch/welinder/git> grep -w realloc *.c
> daemon.c: newlist = realloc(socklist, sizeof(int) *
> (socknum + 1));
> diff-delta.c: out = realloc(out, outsize);
> git.c: cmdname = realloc(cmdname, cmdname_alloc * sizeof(*cmdname));
> ls-files.c: which->excludes = realloc(which->excludes,
> sha1_file.c: buf = realloc(buf, size);
There is no excuse for not using xrealloc() in git.c,
ls-files.c, and sha1_file.c.
The diff-delta.c code wants to be independent from the rest of
git code, so it probably should check the returned value itself.
Historically to a certain degree daemon.c also wanted to be
independent from the rest of git, but I suspect it still is the
case (it uses small pieces from packet interface but that is
about it).
^ permalink raw reply
* realloc
From: Morten Welinder @ 2006-04-07 20:11 UTC (permalink / raw)
To: GIT Mailing List
I could be wrong, but shouldn't
var = realloc (var, whatever);
be changed to call xrealloc? That, or assign to a different variable and check
for NULL.
This should affect the last four hits below.
M.
/scratch/welinder/git> grep -w realloc *.c
daemon.c: newlist = realloc(socklist, sizeof(int) *
(socknum + 1));
diff-delta.c: out = realloc(out, outsize);
git.c: cmdname = realloc(cmdname, cmdname_alloc * sizeof(*cmdname));
ls-files.c: which->excludes = realloc(which->excludes,
sha1_file.c: buf = realloc(buf, size);
^ permalink raw reply
* Re: Can't export whole repo as patches
From: Junio C Hamano @ 2006-04-07 19:18 UTC (permalink / raw)
To: Peter Baumann; +Cc: git
In-Reply-To: <20060407184701.GA6686@xp.machine.de>
Peter Baumann <peter.baumann@gmail.com> writes:
> How can I get the inital commit as a patch?
format-patch is designed to get a patch to send to upstream, and
does not handle the root commit. In your two revisions
repository, you could do something like this:
$ git diff-tree -p --root master~1
Or more in general:
$ git rev-list master |
git diff-tree --stdin --root --pretty=fuller -p
BTW, I've been meaning to add --pretty=patch to give
format-patch compatible output to diff-tree, but haven't got
around to actually do it. Another thing I've been meaning to do
is "git log --diff" which is more or less "git whatchanged".
^ 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