* Re: How to create independent branches
From: colin @ 2006-04-08 23:15 UTC (permalink / raw)
To: peter.baumann; +Cc: git
669 git-symbolic-ref HEAD refs/heads/slave
670 echo "ref: refs/heads/master" > .git/HEAD
671 git-symbolic-ref HEAD refs/heads/slave
672 git add bar
> 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.
If I undertstand, you basically want to create a second
initial commit, so you have two trees in your repository.
Well, an initial commit is just a commit object with no parents.
Try:
- Set up the workdir the way you want. You have to git-add
any newly added files, but git-update-index (called by
git-commit -a) will remove from the index any files
removed from the working directory, so you don't have to
worry about those.
- Make sure refs/heads/todo doesn't exist
- "git-symbolic-ref HEAD refs/heads/todo"
This makes HEAD a symlink (well, symref) to refs/heads/todo,
which doesn't exist.
- git-commit -a
Since the HEAD link doesn't exist, this does an initial
commit.
It's not supremely user friendly, because multiple initial commits can
lead to problems down the road trying to merge, so you'd better know what
you're doing.
Another option is to just set up a second working directory, with a
shared object store, and do the checkin from there. You can have the
.git/refs directories shared (via a symlink) or not. If they're not
shared, you can later make them shared by copying over the relevant refs.
Oh, yes, note that if you fat-finger the "git-symbolic-ref HEAD" command,
any attempts to fix it will complain "not a git repository".
That's because a reference to refs/heads/ in HEAD is how git
identifies a repository. "echo ref: refs/heads/master > .git/HEAD"
will fix it.
^ permalink raw reply
* Re: Funny repack behaviour
From: Johannes Schindelin @ 2006-04-08 22:11 UTC (permalink / raw)
To: Nicolas Pitre; +Cc: git
In-Reply-To: <Pine.LNX.4.64.0604081528070.2215@localhost.localdomain>
Hi,
On Sat, 8 Apr 2006, Nicolas Pitre wrote:
> 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 !
Oh, you're right. I was tricked by the identical pack-names. Somehow I
forgot that the pack name just reflects a hash of the _unpacked_ objects,
not the pack file itself.
Sorry for the noise.
Ciao,
Dscho
^ permalink raw reply
* Re: How to create independent branches
From: Johannes Schindelin @ 2006-04-08 22:09 UTC (permalink / raw)
To: Petr Baudis; +Cc: git
In-Reply-To: <20060408205747.GT27689@pasky.or.cz>
Hi,
On Sat, 8 Apr 2006, Petr Baudis wrote:
> Dear diary, on Sat, Apr 08, 2006 at 10:49:04PM CEST, I got a letter
> where Junio C Hamano <junkio@cox.net> said that...
> >
> > My "todo" branch is not even part of my main git repository. I
> > just have two independent repositories (git and todo) locally,
> > and push into the same public repository.
>
> Wouldn't it be better to separate it to two distinct public repositories
> as well? It's confusing people and encouraging a practice that really
> isn't very feasible and practical in Git.
How so? I find it highly practical, and do it myself. For example, I track
a project which is not version-controlled at all. So I have a "branch" in
git where I keep the tools to fake that version-controlling. And git makes
it easy to just fetch the changes of both the project and my tools.
Ciao,
Dscho
^ permalink raw reply
* Re: strange behavior when pulling updates / get uptodate with git.git
From: Nicolas Vilz 'niv' @ 2006-04-08 21:19 UTC (permalink / raw)
To: git
In-Reply-To: <7vmzeveqin.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano wrote:
> Most likely it is aborted by the "pu" branch not
> fast-forwarding.
>
> Pull: +refs/heads/pu:refs/heads/pu
>
> or dropping "pu" altogether if you are not interested in it,
> would help.
Thank you, the +-sign helped me out.
Sincerly
Nicolas
^ permalink raw reply
* Re: How to create independent branches
From: Junio C Hamano @ 2006-04-08 21:00 UTC (permalink / raw)
To: Petr Baudis; +Cc: git
In-Reply-To: <20060408205747.GT27689@pasky.or.cz>
Petr Baudis <pasky@suse.cz> writes:
> Wouldn't it be better to separate it to two distinct public repositories
> as well? It's confusing people and encouraging a practice that really
> isn't very feasible and practical in Git.
That's mainly historical. I haven't bothered to check it
recently, but /pub/scm/git was not writable by me on kernel.org
machine, only /pub/scm/git/git.git/ was.
^ permalink raw reply
* Re: How to create independent branches
From: Petr Baudis @ 2006-04-08 20:57 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Peter Baumann, git
In-Reply-To: <7vsloneqtb.fsf@assigned-by-dhcp.cox.net>
Dear diary, on Sat, Apr 08, 2006 at 10:49:04PM CEST, I got a letter
where Junio C Hamano <junkio@cox.net> said that...
> Peter Baumann <peter.baumann@gmail.com> writes:
>
> > 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.
>
> My "todo" branch is not even part of my main git repository. I
> just have two independent repositories (git and todo) locally,
> and push into the same public repository.
Wouldn't it be better to separate it to two distinct public repositories
as well? It's confusing people and encouraging a practice that really
isn't very feasible and practical in Git.
--
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: strange behavior when pulling updates / get uptodate with git.git
From: Junio C Hamano @ 2006-04-08 20:55 UTC (permalink / raw)
To: Nicolas Vilz 'niv'; +Cc: git
In-Reply-To: <4438158C.1080208@iaglans.de>
Nicolas Vilz 'niv' <niv@iaglans.de> writes:
> 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.
Most likely it is aborted by the "pu" branch not
fast-forwarding.
Pull: +refs/heads/pu:refs/heads/pu
or dropping "pu" altogether if you are not interested in it,
would help. My repositories (the ones I fetch/pull from for
testing) have only these:
URL: git://git.kernel.org/pub/scm/git/git.git
Pull: refs/heads/master:refs/heads/origin
Pull: refs/heads/next:refs/heads/next
Pull: +refs/heads/pu:refs/heads/pu
Pull: refs/heads/maint:refs/heads/maint
^ permalink raw reply
* Re: How to create independent branches
From: Junio C Hamano @ 2006-04-08 20:49 UTC (permalink / raw)
To: Peter Baumann; +Cc: git
In-Reply-To: <20060408180244.GA4807@xp.machine.de>
Peter Baumann <peter.baumann@gmail.com> writes:
> 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.
My "todo" branch is not even part of my main git repository. I
just have two independent repositories (git and todo) locally,
and push into the same public repository.
^ permalink raw reply
* 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
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