* Re: What's in git.git and announcing v1.4.1-rc1
From: Junio C Hamano @ 2006-06-22 20:16 UTC (permalink / raw)
To: git
In-Reply-To: <7v8xnpj7hg.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano <junkio@cox.net> writes:
> * The 'pu' branch, in addition, has these.
>
> Johannes Schindelin:
> Teach diff about -b and -w flags
I am hoping to coordinate the inclusion of this upstream first
and have this hopefully in the real 1.4.1 release.
> Lukas Sandström:
> Make it possible to call cmd_apply multiple times
> Make git-am a builtin
Last time I tried this, it did not work for me, so I am putting
it on hold. I feel, however, "am" is a high-enough-level tool
that we would prefer to keep it scriptable for quick tweaks.
If it is hurting portability because it is written in shell,
maybe this can be moved to all Perl (especially when Pasky's
Git.pm is ready) or Python. Personally I think Windows minded
folks who cannot stand command-line interface Cygwin port gives
would not be satisfied anyway, until somebody writes a native
drag-this-mail-and-drop-on-that-brach tool, so porting the
command out of shell may not be even worth doing. I dunno.
^ permalink raw reply
* Re: Incremental CVS update
From: Jon Smirl @ 2006-06-22 20:08 UTC (permalink / raw)
To: Martin Langhoff; +Cc: Keith Packard, git
In-Reply-To: <46a038f90606221236j2c5c9692yecef924aa769c1c9@mail.gmail.com>
On 6/22/06, Martin Langhoff <martin.langhoff@gmail.com> wrote:
> On 6/23/06, Jon Smirl <jonsmirl@gmail.com> wrote:
> > cvsps keeps it's incremental status in ~/.cvps/*. parsecvs might want
> > to keep it's status in the .git repository and use tags to locate it.
> > You could even have a utility to show when and what was imported. By
> > keeping everything in git it doesn't matter who runs the incremental
> > update commands.
>
> Jon,
>
> what cvsps keeps is a cache of what it knows about the repo history,
> to ask only for new commits. Now, cvsps will always write to STDOUT
> the full history, and git-cvsimport discards the commits it has
> already seen, based on reading the state of each git head.
The cache is 723MB for the Mozilla repo. Since the info gets cached in
my home directory anyone else who needs to sync the repo doesn't get
to use the cache.
[jonsmirl@jonsmirl .cvsps]$ pwd
/home/jonsmirl/.cvsps
[jonsmirl@jonsmirl .cvsps]$ ls -l
total 707492
-rw-rw-r-- 1 jonsmirl jonsmirl 723758657 Jun 15 16:10 #home#mozcvs##mozilla
[jonsmirl@jonsmirl .cvsps]$
Keith is rewriting parsecvs. If you analyze all of the data
structures, the info needed for the conversion should be able to fit
into well under 100MB instead of the ~2GB the current programs are
using.
There are lots of ways to reduce memory consumption. You can turm CVS
revisions into git IDs as soon as the revision is seen. That lets you
get away from tracking file names and long CVS revision numbers. It
also works to turn the author/log fields immediately into a hash. When
possible switching to arrays instead of linked list is smaller too.
Some stats:
1M revisions
200K unique changesets (author/log combos)
200KB symbols
1,800 branches
cvsps has the lowest memory consumption, it uses 1200 bytes per
revision. It looks like it is possible to lower this to less than 100
bytes per rev.
>
> So cvsps + git-cvsimport don't keep any extra data around, and I am
> 100% certain that parsecvs don't need that either.
>
> cheers,
>
>
> martin
>
--
Jon Smirl
jonsmirl@gmail.com
^ permalink raw reply
* Re: [GIT PATCH] USB patches for 2.6.17
From: Sam Ravnborg @ 2006-06-22 20:01 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Andrew Morton, Greg KH, linux-kernel, git, linux-usb-devel
In-Reply-To: <Pine.LNX.4.64.0606221239100.5498@g5.osdl.org>
> I'm just constantly surprised by how people don't even seem to realize
> what it can do sometimes. Part of it is that development has been pretty
> active (and some of the things it can do simply weren't there three months
> ago), but part of it must be because people don't even expect it to be
> able to do something like that.
Personally I'm still missing two things:
1) A command to let me see what this Linus guy have applied compared to
my tree - without touching anything in my tree. bk changes -R
2) A dry-run of a fetch+pull. I can do that if I really study the man
pages I know. But "git pull --dry-run" would be more convinient.
Other than that I will say that I'm pleased with the funtionality that
I use - that's maybe 10% of the possibilities...
Sam
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
_______________________________________________
linux-usb-devel@lists.sourceforge.net
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
^ permalink raw reply
* What's in git.git and announcing v1.4.1-rc1
From: Junio C Hamano @ 2006-06-22 19:49 UTC (permalink / raw)
To: git; +Cc: linux-kernel
I've merged quite a bit of stuff and tagged the tip of "master"
as GIT 1.4.1-rc1.
As promised, 1.4.X series will be managed slightly differently,
and this is in preparation of the first installment of it. The
releases will come from the "master" branch to contain both
fixes and enhancements from now on. Hotfix releases when
necessary would have 1.4.X.Y revision numbers, but I am hoping
that we do not have to do that very often.
Since all the exciting and potentially risky developments are to
happen on the "next" branch and they are supposed to graduate to
"master" branch after they are reasonably well cooked, this
change will help the end-users to stay reasonably current
without hopefully not introducing unexpected problems. The
older scheme left out all the enhancements if people followed
packaged versions, and gave big surprises when upgrading from
version X.Y.Z to X.(Y+1).0 which was not so nice.
Notable improvements since v1.4.0 are:
- PPC SHA1 routine can grok more than half-gig of data (Paul
Mackerras)
- rev-list and object-layer in general is less (much less)
space hungry (Linus).
- the source is more friendly to stricter compilers such as
Sun's (Florian Forster).
- git rebase --merge (Eric Wong). This uses the usual 3-way
merge machinery while running rebase, and you can rebase
across renames if you use the recursive strategy which is the
default.
- gitweb updates -- mostly cleanups (Jakub Narebski with help
from Pasky and Timo Hirvonen).
- diff --color (Johannes).
- ~/.gitconfig and $ENV{GIT_CONFIG} (Pasky and Johannes).
- core.sharedrepository can take umask, group or world (Linus
and I)
- "git checkout -f" removes files that becomes untracked from
the working tree
- "git clone/fetch" from a corrupt repository does not
propagate brokenness to the downloaders.
- "git clone/fetch" over the network gives better progress
updates; this may also help TCP timeout problems for people
behind NAT.
- Many more commands are built-in (Lukas Sandström)
- git can now be used on Kiritimati (Paul Eggert)
----------------------------------------------------------------
* The 'master' branch has these since the last announcement.
Andre Noll:
object-refs: avoid division by zero
David Woodhouse:
Log peer address when git-daemon called from inetd
Dennis Stosberg:
Make t8001-annotate and t8002-blame more portable
Fix t8001-annotate and t8002-blame for ActiveState Perl
Eric W. Biederman:
Fix git-format-patch -s
Check and document the options to prevent mistakes.
Eric Wong:
git-svn: fix --rmdir when using SVN:: libraries
rebase: Allow merge strategies to be used when rebasing
rebase: error out for NO_PYTHON if they use recursive merge
git-svn: fix commit --edit flag when using SVN:: libraries
Florian Forster:
Remove ranges from switch statements.
Initialize FAMs using `FLEX_ARRAY'.
Don't instantiate structures with FAMs.
Cast pointers to `void *' when used in a format.
Don't use empty structure initializers.
Change types used in bitfields to be `int's.
Remove all void-pointer arithmetic.
Jakub Narebski:
Move gitweb style to gitweb.css
gitweb: safely output binary files for 'blob_plain' action
gitweb: text files for 'blob_plain' action without charset by default
Fix gitweb stylesheet
Make CSS file gitweb/gitweb.css more readable
gitweb: add type="text/css" to stylesheet link
Fix: Support for the standard mime.types map in gitweb
gitweb: A couple of page title tweaking
gitweb: style done with stylesheet
gitweb: whitespace cleanup
Add git version to gitweb output
Move $gitbin earlier in gitweb.cgi
gitweb: Make use of $PATH_INFO for project parameter
gitweb: whitespace cleanup around '='
Johannes Schindelin:
diff options: add --color
Initialize lock_file struct to all zero.
Fix setting config variables with an alternative GIT_CONFIG
Read configuration also from $HOME/.gitconfig
repo-config: Fix late-night bug
git_config: access() returns 0 on success, not > 0
Junio C Hamano:
read-tree: --prefix=<path>/ option.
write-tree: --prefix=<path>
read-tree: reorganize bind_merge code.
fetch-pack: give up after getting too many "ack continue"
shared repository: optionally allow reading to "others".
fix rfc2047 formatter.
xdiff: minor changes to match libxdiff-0.21
Restore SIGCHLD to SIG_DFL where we care about waitpid().
checkout -f: do not leave untracked working tree files.
upload-pack: avoid sending an incomplete pack upon failure
upload-pack: prepare for sideband message support.
Retire git-clone-pack
upload-pack/fetch-pack: support side-band communication
Add renaming-rebase test.
daemon: send stderr to /dev/null instead of closing.
rebase --merge: fix for rebasing more than 7 commits.
Makefile: do not force unneeded recompilation upon GIT_VERSION changes
Linus Torvalds:
Shrink "struct object" a bit
Move "void *util" from "struct object" into "struct commit"
Some more memory leak avoidance
Remove "refs" field from "struct object"
Add specialized object allocator
Add "named object array" concept
Fix grow_refs_hash()
Lukas Sandström:
Make git-write-tree a builtin
Make git-mailsplit a builtin
Make git-mailinfo a builtin
Make git-stripspace a builtin
Make git-update-index a builtin
Make git-update-ref a builtin
Paul Eggert:
date.c: improve guess between timezone offset and year.
Paul Mackerras:
Fix PPC SHA1 routine for large input buffers
Petr Baudis:
Support for extracting configuration from different files
Support for the standard mime.types map in gitweb
Rene Scharfe:
git-tar-tree: Simplify write_trailer()
git-tar-tree: documentation update
git-tar-tree: no more void pointer arithmetic
Make release tarballs friendlier to older tar versions
Timo Hirvonen:
gitweb: Use $hash_base as $search_hash if possible
Uwe Zeisberger:
Fix possible out-of-bounds array access
Yakov Lerner:
auto-detect changed prefix and/or changed build flags
Pass -DDEFAULT_GIT_TEMPLATE_DIR only where actually used.
* The 'pu' branch, in addition, has these.
Johannes Schindelin:
Teach diff about -b and -w flags
Lukas Sandström:
Make it possible to call cmd_apply multiple times
Make git-am a builtin
^ permalink raw reply
* You gape for shooting like you had seen in those films
From: Lassiter @ 2006-06-22 20:09 UTC (permalink / raw)
To: glenn
Do you wish to increase your volume by up to 500%? http://beauti-full.com/gall/gsm Every man wishes it. It’s absolutely true – just take one before startWorried it won't work?Increase your volume in just days
^ permalink raw reply
* Re: [PATCH] [RFC] Introduce Git.pm
From: Petr Baudis @ 2006-06-22 19:37 UTC (permalink / raw)
To: Junio C Hamano, Eric Wong; +Cc: git
In-Reply-To: <7v64iuxard.fsf@assigned-by-dhcp.cox.net>
Dear diary, on Thu, Jun 22, 2006 at 03:03:02AM CEST, I got a letter
where Junio C Hamano <junkio@cox.net> said that...
> Petr Baudis <pasky@suse.cz> writes:
>
> > Currently Git.pm just wraps up exec()s of Git commands, but even that
> > is not trivial to get right and various Git perl scripts do it in
> > various inconsistent ways. And things will get much more interesting
> > when we get to XS-izing libgit.
>
> We would probably need some moderate to major surgery before
> doing that depending on which parts. Worrisome are object layer
> that holds onto parsed objects and keeps flag bits from the
> previous runs, and lockfile that are cleaned up via atexit() --
> there may be others.
Yes, I'm aware of that. Still, some parts should be quite easy...
Dear diary, on Thu, Jun 22, 2006 at 04:31:05AM CEST, I got a letter
where Eric Wong <normalperson@yhbt.net> said that...
> XS-ising libgit would be awesome with all the git-hash-object calls in
> git-svn (and other importers, too, I imagine).
...so I couldn't resist that and did add hash_object() xs-ized
function. Looks pretty sweet:
$ time perl -w -I/home/xpasky/lib/perl5/site_perl/5.8.8 -MGit -le 'print Git::generic_oneline("hash-object", "Makefile") for (1..1000)' >/dev/null
real 0m4.800s
user 0m2.072s
sys 0m2.560s
$ time perl -w -I/home/xpasky/lib/perl5/site_perl/5.8.8 -MGit -le 'print Git::hash_object("Makefile") for (1..1000)' >/dev/null
real 0m0.179s
user 0m0.144s
sys 0m0.032s
Dear diary, on Thu, Jun 22, 2006 at 03:03:02AM CEST, I got a letter
where Junio C Hamano <junkio@cox.net> said that...
> > @@ -618,6 +622,7 @@ GIT-CFLAGS: .FORCE-GIT-CFLAGS
> > @FLAGS='$(TRACK_CFLAGS)'; \
> > if test x"$$FLAGS" != x"`cat GIT-CFLAGS 2>/dev/null`" ; then \
> > echo 1>&2 " * new build flags or prefix"; \
> > + echo 1>&2 " * $$FLAGS != `cat GIT-CFLAGS 2>/dev/null`"; \
> > echo "$$FLAGS" >GIT-CFLAGS; \
> > fi
> >
>
> Offtopic; do people mind if we drop $GIT_VERSION from
> TRACK_CFLAGS? Every time I switch branches or make a new commit
> it ends up rebuilding everything needlessly.
Please, please, _do_! :-)
I'm sorry about this hunk, I added it to just figure out why the heck it
keeps rebuilding everything from scratch and forgot to drop it.
> > sub current_branch {
> > - my ($bra) = qx{git-symbolic-ref HEAD};
> > + my ($bra) = $repo->generic_oneline('symbolic-ref', 'HEAD');
> > chomp($bra);
> > $bra =~ s|^refs/heads/||;
> > if ($bra ne 'master') {
>
> Your *_oneline chomps so chomp($bra) is not needed anymore, I think.
Ah, thanks.
> > +require Exporter;
>
> Not "use"?
The idiom is to require, I guess; we don't need to import anything.
I don't think it matters and I'm not entirely sure about all the
implications of the difference between the two, so if you wish,
I can change it.
> > +# Methods which can be called as standalone functions as well:
> > +@EXPORT_OK = qw(generic generic_oneval generic_vocal);
>
> I am not sure generic_xxx is a good name. Perhaps command_xxx?
Technically, other methods can be commands, too. ;-) But yet, it sounds
better. I've changed it.
> Also as you say in the comment, "vocal" sounds a bit funny.
> I wonder if we can use wantarray to detect the case where the
> caller wants _no_ value, and do the "not piping" optimization in
> that case.
I think that would be rather confusing since generic_vocal does not make
the output go away but makes it go to stdout, while if you just throw
away return value of generic(), you expect it to go nowhere.
At least I will change 'vocal' to 'noisy' so that it does not sound
so weird.
Dear diary, on Thu, Jun 22, 2006 at 04:31:05AM CEST, I got a letter
where Eric Wong <normalperson@yhbt.net> said that...
> Petr Baudis <pasky@suse.cz> wrote:
> > + my $pid = open(my $fh, "-|");
> > + if ($pid < 0) {
> > + die "generic($cmd, @args) open: $!";
>
> In Perl, fork returns undef instead of $pid < 0 on failure.
Thanks!
> Doing join(' ',@args) will also make the error message more readable, too :)
@args should get automagically interpolated by having the members
separated by $" (space by default).
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
A person is just about as big as the things that make them angry.
^ permalink raw reply
* Re: Incremental CVS update
From: Martin Langhoff @ 2006-06-22 19:36 UTC (permalink / raw)
To: Jon Smirl; +Cc: Keith Packard, git
In-Reply-To: <9e4733910606220526o14ebe76ala4d327f012a0e8f5@mail.gmail.com>
On 6/23/06, Jon Smirl <jonsmirl@gmail.com> wrote:
> cvsps keeps it's incremental status in ~/.cvps/*. parsecvs might want
> to keep it's status in the .git repository and use tags to locate it.
> You could even have a utility to show when and what was imported. By
> keeping everything in git it doesn't matter who runs the incremental
> update commands.
Jon,
what cvsps keeps is a cache of what it knows about the repo history,
to ask only for new commits. Now, cvsps will always write to STDOUT
the full history, and git-cvsimport discards the commits it has
already seen, based on reading the state of each git head.
So cvsps + git-cvsimport don't keep any extra data around, and I am
100% certain that parsecvs don't need that either.
cheers,
martin
^ permalink raw reply
* Re: [PATCH] Pass -DDEFAULT_GIT_TEMPLATE_DIR only where actually used.
From: Junio C Hamano @ 2006-06-22 18:58 UTC (permalink / raw)
To: Petr Baudis; +Cc: git
In-Reply-To: <20060622175815.GC21864@pasky.or.cz>
Petr Baudis <pasky@suse.cz> writes:
> ... while the Git.pm module should be available systemwide even
> for non-Git applications, so it's really best to leave it to Perl where
> to put it.
OK, if that is the intention passing prefix might be sensible.
^ permalink raw reply
* Re: [PATCH] Make -p --stat and --stat -p behave like --patch-with-stat
From: Junio C Hamano @ 2006-06-22 18:58 UTC (permalink / raw)
To: Timo Hirvonen; +Cc: junkio, git
In-Reply-To: <20060622162511.4788505e.tihirvon@gmail.com>
Timo Hirvonen <tihirvon@gmail.com> writes:
> git log log only
> git log --stat log with stat
> git log -p log with patch
> git log --stat -p log with patch (no stat!)
> git log -p --stat log with stat (no patch!)
> git log --patch-with-stat log with patch and stat
>
> This patch makes -p --stat and --stat -p work like --patch-with-stat.
>
> Signed-off-by: Timo Hirvonen <tihirvon@gmail.com>
> ---
>
> Maybe DIFF_FORMAT_* should be reworked instead but this was easy.
>
> Only negative impact of this patch is that if you have a alias
>
> l=log --stat
>
> then you can't override --stat with "git l -p", it will still show
> diffstat, but I don't think it matters.
I do not think it matters that much either, but DIFF_FORMAT_*
really should be reworked regardless. --with-foo should really
be independent switches that can be added together, perhaps.
So how would we go about this? A strawman.
The diff output has four parts, each of which can independently
be enabled. When no options are specified on the command line,
each command has its own default but in general the low-level
commands default to raw output only, and the higher-level ones
default to patch output only.
The four parts are controlled with a bit each, and are output in
the fixed order (iow the order of the options given from the
command line does not matter): raw, stat, summary and patch.
When --name-only or --name-status is specified, that would be
the only thing that is output (iow the above four parts would
not be shown, just names optionally with the status are shown).
The four switches are: --raw, --stat, --summary and --patch.
Existing flags are supported as obvious shorthands to turn on
the corresponding bits:
-p, -u --patch
--patch-with-raw --raw --patch
--patch-with-stat --stat --patch
Anybody interested in doing a patch?
^ permalink raw reply
* [PATCH 3/3] Teach diff about whitespace options.
From: Junio C Hamano @ 2006-06-22 18:58 UTC (permalink / raw)
To: Davide Libenzi; +Cc: git, Johannes Schindelin
From: Johannes Schindelin <Johannes.Schindelin@gmx.de>
This adds XDF_IGNORE_WHITESPACE and XDF_IGNORE_WHITESPACE_CHANGE
to the set of flags that can be passed to xdl_change_compact(),
to implement -b (--ignore-space-change) and -w (--ignore-all-space)
options.
Signed-off-by: Johannes Schindelin <Johannes.Schindelin@gmx.de>
Signed-off-by: Junio C Hamano <junkio@cox.net>
---
* The original done by Johannes named a new function
xdl_line_match(), but that collided with what is in
xpatchi.c, so I renamed it to xdl_recmatch().
xdiff.h | 3 +++
xdiffi.c | 12 ++++++------
xdiffi.h | 1 -
xmacros.h | 1 -
xprepare.c | 16 ++++++++++------
xutils.c | 51 ++++++++++++++++++++++++++++++++++++++++++++++++++-
xutils.h | 3 ++-
7 files changed, 71 insertions(+), 16 deletions(-)
diff --git a/xdiff.h b/xdiff.h
index f4af41b..224bd12 100644
--- a/xdiff.h
+++ b/xdiff.h
@@ -29,6 +29,9 @@ #endif /* #ifdef __cplusplus */
#define XDF_NEED_MINIMAL (1 << 1)
+#define XDF_IGNORE_WHITESPACE (1 << 2)
+#define XDF_IGNORE_WHITESPACE_CHANGE (1 << 3)
+#define XDF_WHITESPACE_FLAGS (XDF_IGNORE_WHITESPACE | XDF_IGNORE_WHITESPACE_CHANGE)
#define XDL_PATCH_NORMAL '-'
#define XDL_PATCH_REVERSE '+'
diff --git a/xdiffi.c b/xdiffi.c
index b95ade2..ed7ad20 100644
--- a/xdiffi.c
+++ b/xdiffi.c
@@ -45,7 +45,7 @@ static long xdl_split(unsigned long cons
long *kvdf, long *kvdb, int need_min, xdpsplit_t *spl,
xdalgoenv_t *xenv);
static xdchange_t *xdl_add_change(xdchange_t *xscr, long i1, long i2, long chg1, long chg2);
-static int xdl_change_compact(xdfile_t *xdf, xdfile_t *xdfo);
+static int xdl_change_compact(xdfile_t *xdf, xdfile_t *xdfo, long flags);
@@ -397,7 +397,7 @@ static xdchange_t *xdl_add_change(xdchan
}
-static int xdl_change_compact(xdfile_t *xdf, xdfile_t *xdfo) {
+static int xdl_change_compact(xdfile_t *xdf, xdfile_t *xdfo, long flags) {
long ix, ixo, ixs, ixref, grpsiz, nrec = xdf->nrec;
char *rchg = xdf->rchg, *rchgo = xdfo->rchg;
xrecord_t **recs = xdf->recs;
@@ -440,7 +440,7 @@ static int xdl_change_compact(xdfile_t *
* the group.
*/
while (ixs > 0 && recs[ixs - 1]->ha == recs[ix - 1]->ha &&
- XDL_RECMATCH(recs[ixs - 1], recs[ix - 1])) {
+ xdl_recmatch(recs[ixs - 1]->ptr, recs[ixs - 1]->size, recs[ix - 1]->ptr, recs[ix - 1]->size, flags)) {
rchg[--ixs] = 1;
rchg[--ix] = 0;
@@ -468,7 +468,7 @@ static int xdl_change_compact(xdfile_t *
* the group.
*/
while (ix < nrec && recs[ixs]->ha == recs[ix]->ha &&
- XDL_RECMATCH(recs[ixs], recs[ix])) {
+ xdl_recmatch(recs[ixs]->ptr, recs[ixs]->size, recs[ix]->ptr, recs[ix]->size, flags)) {
rchg[ixs++] = 0;
rchg[ix++] = 1;
@@ -546,8 +546,8 @@ int xdl_diff(mmfile_t *mf1, mmfile_t *mf
return -1;
}
- if (xdl_change_compact(&xe.xdf1, &xe.xdf2) < 0 ||
- xdl_change_compact(&xe.xdf2, &xe.xdf1) < 0 ||
+ if (xdl_change_compact(&xe.xdf1, &xe.xdf2, xpp->flags) < 0 ||
+ xdl_change_compact(&xe.xdf2, &xe.xdf1, xpp->flags) < 0 ||
xdl_build_script(&xe, &xscr) < 0) {
xdl_free_env(&xe);
diff --git a/xdiffi.h b/xdiffi.h
index dd8f3c9..d3b7271 100644
--- a/xdiffi.h
+++ b/xdiffi.h
@@ -55,6 +55,5 @@ void xdl_free_script(xdchange_t *xscr);
int xdl_emit_diff(xdfenv_t *xe, xdchange_t *xscr, xdemitcb_t *ecb,
xdemitconf_t const *xecfg);
-
#endif /* #if !defined(XDIFFI_H) */
diff --git a/xmacros.h b/xmacros.h
index 78f0260..4c2fde8 100644
--- a/xmacros.h
+++ b/xmacros.h
@@ -33,7 +33,6 @@ #define XDL_ABS(v) ((v) >= 0 ? (v): -(v)
#define XDL_ISDIGIT(c) ((c) >= '0' && (c) <= '9')
#define XDL_HASHLONG(v, b) (((unsigned long)(v) * GR_PRIME) >> ((CHAR_BIT * sizeof(unsigned long)) - (b)))
#define XDL_PTRFREE(p) do { if (p) { xdl_free(p); (p) = NULL; } } while (0)
-#define XDL_RECMATCH(r1, r2) ((r1)->size == (r2)->size && memcmp((r1)->ptr, (r2)->ptr, (r1)->size) == 0)
#define XDL_LE32_PUT(p, v) \
do { \
unsigned char *__p = (unsigned char *) (p); \
diff --git a/xprepare.c b/xprepare.c
index add5a75..1be7b31 100644
--- a/xprepare.c
+++ b/xprepare.c
@@ -43,12 +43,13 @@ typedef struct s_xdlclassifier {
xdlclass_t **rchash;
chastore_t ncha;
long count;
+ long flags;
} xdlclassifier_t;
-static int xdl_init_classifier(xdlclassifier_t *cf, long size);
+static int xdl_init_classifier(xdlclassifier_t *cf, long size, long flags);
static void xdl_free_classifier(xdlclassifier_t *cf);
static int xdl_classify_record(xdlclassifier_t *cf, xrecord_t **rhash, unsigned int hbits,
xrecord_t *rec);
@@ -63,9 +64,11 @@ static int xdl_optimize_ctxs(xdfile_t *x
-static int xdl_init_classifier(xdlclassifier_t *cf, long size) {
+static int xdl_init_classifier(xdlclassifier_t *cf, long size, long flags) {
long i;
+ cf->flags = flags;
+
cf->hbits = xdl_hashbits((unsigned int) size);
cf->hsize = 1 << cf->hbits;
@@ -103,8 +106,9 @@ static int xdl_classify_record(xdlclassi
line = rec->ptr;
hi = (long) XDL_HASHLONG(rec->ha, cf->hbits);
for (rcrec = cf->rchash[hi]; rcrec; rcrec = rcrec->next)
- if (rcrec->ha == rec->ha && rcrec->size == rec->size &&
- !memcmp(line, rcrec->line, rec->size))
+ if (rcrec->ha == rec->ha &&
+ xdl_recmatch(rcrec->line, rcrec->size,
+ rec->ptr, rec->size, cf->flags))
break;
if (!rcrec) {
@@ -173,7 +177,7 @@ static int xdl_prepare_ctx(mmfile_t *mf,
top = blk + bsize;
}
prev = cur;
- hav = xdl_hash_record(&cur, top);
+ hav = xdl_hash_record(&cur, top, xpp->flags);
if (nrec >= narec) {
narec *= 2;
if (!(rrecs = (xrecord_t **) xdl_realloc(recs, narec * sizeof(xrecord_t *)))) {
@@ -268,7 +272,7 @@ int xdl_prepare_env(mmfile_t *mf1, mmfil
enl1 = xdl_guess_lines(mf1) + 1;
enl2 = xdl_guess_lines(mf2) + 1;
- if (xdl_init_classifier(&cf, enl1 + enl2 + 1) < 0) {
+ if (xdl_init_classifier(&cf, enl1 + enl2 + 1, xpp->flags) < 0) {
return -1;
}
diff --git a/xutils.c b/xutils.c
index a776706..695a458 100644
--- a/xutils.c
+++ b/xutils.c
@@ -483,12 +483,61 @@ long xdl_guess_lines(mmfile_t *mf) {
return nl + 1;
}
+int xdl_recmatch(const char *l1, long s1, const char *l2, long s2, long flags)
+{
+ int i1, i2;
+
+ if (flags & XDF_IGNORE_WHITESPACE) {
+ for (i1 = i2 = 0; i1 < s1 && i2 < s2; i1++, i2++) {
+ if (isspace(l1[i1]))
+ while (isspace(l1[i1]) && i1 < s1)
+ i1++;
+ else if (isspace(l2[i2]))
+ while (isspace(l2[i2]) && i2 < s2)
+ i2++;
+ else if (l1[i1] != l2[i2])
+ return l2[i2] - l1[i1];
+ }
+ if (i1 >= s1)
+ return 1;
+ else if (i2 >= s2)
+ return -1;
+ } else if (flags & XDF_IGNORE_WHITESPACE_CHANGE) {
+ for (i1 = i2 = 0; i1 < s1 && i2 < s2; i1++, i2++) {
+ if (isspace(l1[i1])) {
+ if (!isspace(l2[i2]))
+ return -1;
+ while (isspace(l1[i1]) && i1 < s1)
+ i1++;
+ while (isspace(l2[i2]) && i2 < s2)
+ i2++;
+ } else if (l1[i1] != l2[i2])
+ return l2[i2] - l1[i1];
+ }
+ if (i1 >= s1)
+ return 1;
+ else if (i2 >= s2)
+ return -1;
+ } else
+ return s1 == s2 && !memcmp(l1, l2, s1);
-unsigned long xdl_hash_record(char const **data, char const *top) {
+ return 0;
+}
+
+unsigned long xdl_hash_record(char const **data, char const *top, long flags) {
unsigned long ha = 5381;
char const *ptr = *data;
for (; ptr < top && *ptr != '\n'; ptr++) {
+ if (isspace(*ptr) && (flags & XDF_WHITESPACE_FLAGS)) {
+ while (ptr < top && isspace(*ptr) && ptr[1] != '\n')
+ ptr++;
+ if (flags & XDF_IGNORE_WHITESPACE_CHANGE) {
+ ha += (ha << 5);
+ ha ^= (unsigned long) ' ';
+ }
+ continue;
+ }
ha += (ha << 5);
ha ^= (unsigned long) *ptr;
}
diff --git a/xutils.h b/xutils.h
index 5a3e13b..275fa74 100644
--- a/xutils.h
+++ b/xutils.h
@@ -35,7 +35,8 @@ void *xdl_cha_alloc(chastore_t *cha);
void *xdl_cha_first(chastore_t *cha);
void *xdl_cha_next(chastore_t *cha);
long xdl_guess_lines(mmfile_t *mf);
-unsigned long xdl_hash_record(char const **data, char const *top);
+int xdl_recmatch(const char *l1, long s1, const char *l2, long s2, long flags);
+unsigned long xdl_hash_record(char const **data, char const *top, long flags);
unsigned int xdl_hashbits(unsigned int size);
int xdl_num_out(char *out, long val);
long xdl_atol(char const *str, char const **next);
--
1.4.0.gbf9e
^ permalink raw reply related
* [PATCH 2/3] xdiffi.c: squelch compiler warnings.
From: Junio C Hamano @ 2006-06-22 18:58 UTC (permalink / raw)
To: Davide Libenzi; +Cc: git, Marco Roeland
From: Marco Roeland <marco.roeland@xs4all.nl>
This initializes a few variables that are judged to be used uninitialized
by the compiler.
---
xdiffi.c | 5 +++--
1 files changed, 3 insertions(+), 2 deletions(-)
diff --git a/xdiffi.c b/xdiffi.c
index b1297d4..b95ade2 100644
--- a/xdiffi.c
+++ b/xdiffi.c
@@ -220,7 +220,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;
@@ -232,7 +232,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;
@@ -298,6 +298,7 @@ int xdl_recs_cmp(diffdata_t *dd1, long o
} else {
long ec;
xdpsplit_t spl;
+ spl.i1 = spl.i2 = 0;
/*
* Divide ...
--
1.4.0.gbf9e
^ permalink raw reply related
* [PATCH 1/3] Optionally emit function names in the hunk headers.
From: Junio C Hamano @ 2006-06-22 18:58 UTC (permalink / raw)
To: Davide Libenzi; +Cc: git, Mark Wooding
From: Mark Wooding <mdw@distorted.org.uk>
This is a patch on top of libxdiff 0.21 we use in the git project.
---
xdiff.h | 5 ++++-
xemit.c | 41 ++++++++++++++++++++++++++++++++++++++++-
xpatchi.c | 2 +-
xutils.c | 31 ++++++++++++++++++++++---------
xutils.h | 3 ++-
5 files changed, 69 insertions(+), 13 deletions(-)
diff --git a/xdiff.h b/xdiff.h
index d051216..f4af41b 100644
--- a/xdiff.h
+++ b/xdiff.h
@@ -34,7 +34,9 @@ #define XDL_PATCH_NORMAL '-'
#define XDL_PATCH_REVERSE '+'
#define XDL_PATCH_MODEMASK ((1 << 8) - 1)
#define XDL_PATCH_IGNOREBSPACE (1 << 8)
-
+
+#define XDL_EMIT_FUNCNAMES (1 << 0)
+
#define XDL_MMB_READONLY (1 << 0)
#define XDL_MMF_ATOMIC (1 << 0)
@@ -82,6 +84,7 @@ typedef struct s_xdemitcb {
typedef struct s_xdemitconf {
long ctxlen;
+ unsigned long flags;
} xdemitconf_t;
typedef struct s_bdiffparam {
diff --git a/xemit.c b/xemit.c
index 2e5d54c..ad5bfb1 100644
--- a/xemit.c
+++ b/xemit.c
@@ -69,10 +69,43 @@ static xdchange_t *xdl_get_hunk(xdchange
}
+static void xdl_find_func(xdfile_t *xf, long i, char *buf, long sz, long *ll) {
+
+ /*
+ * Be quite stupid about this for now. Find a line in the old file
+ * before the start of the hunk (and context) which starts with a
+ * plausible character.
+ */
+
+ const char *rec;
+ long len;
+
+ *ll = 0;
+ while (i-- > 0) {
+ len = xdl_get_rec(xf, i, &rec);
+ if (len > 0 &&
+ (isalpha((unsigned char)*rec) || /* identifier? */
+ *rec == '_' || /* also identifier? */
+ *rec == '(' || /* lisp defun? */
+ *rec == '#')) { /* #define? */
+ if (len > sz)
+ len = sz;
+ if (len && rec[len - 1] == '\n')
+ len--;
+ memcpy(buf, rec, len);
+ *ll = len;
+ return;
+ }
+ }
+}
+
+
int xdl_emit_diff(xdfenv_t *xe, xdchange_t *xscr, xdemitcb_t *ecb,
xdemitconf_t const *xecfg) {
long s1, s2, e1, e2, lctx;
xdchange_t *xch, *xche;
+ char funcbuf[40];
+ long funclen = 0;
for (xch = xche = xscr; xch; xch = xche->next) {
xche = xdl_get_hunk(xch, xecfg);
@@ -90,7 +123,13 @@ int xdl_emit_diff(xdfenv_t *xe, xdchange
/*
* Emit current hunk header.
*/
- if (xdl_emit_hunk_hdr(s1 + 1, e1 - s1, s2 + 1, e2 - s2, ecb) < 0)
+
+ if (xecfg->flags & XDL_EMIT_FUNCNAMES) {
+ xdl_find_func(&xe->xdf1, s1, funcbuf,
+ sizeof(funcbuf), &funclen);
+ }
+ if (xdl_emit_hunk_hdr(s1 + 1, e1 - s1, s2 + 1, e2 - s2,
+ funcbuf, funclen, ecb) < 0)
return -1;
/*
diff --git a/xpatchi.c b/xpatchi.c
index dc984f8..da4e018 100644
--- a/xpatchi.c
+++ b/xpatchi.c
@@ -530,7 +530,7 @@ static int xdl_reject_hunk(recfile_t *rf
c2 = pch->hi.c1;
}
s1 += pch->ps.adds - pch->ps.dels;
- if (xdl_emit_hunk_hdr(s1 + 1, c1, s2 + 1, c2, rjecb) < 0) {
+ if (xdl_emit_hunk_hdr(s1 + 1, c1, s2 + 1, c2, NULL, 0, rjecb) < 0) {
return -1;
}
diff --git a/xutils.c b/xutils.c
index 2fe09d8..a776706 100644
--- a/xutils.c
+++ b/xutils.c
@@ -542,7 +542,8 @@ long xdl_atol(char const *str, char cons
}
-int xdl_emit_hunk_hdr(long s1, long c1, long s2, long c2, xdemitcb_t *ecb) {
+int xdl_emit_hunk_hdr(long s1, long c1, long s2, long c2,
+ const char *func, long funclen, xdemitcb_t *ecb) {
int nb = 0;
mmbuffer_t mb;
char buf[128];
@@ -552,23 +553,35 @@ int xdl_emit_hunk_hdr(long s1, long c1,
nb += xdl_num_out(buf + nb, c1 ? s1: s1 - 1);
- memcpy(buf + nb, ",", 1);
- nb += 1;
+ if (c1 != 1) {
+ memcpy(buf + nb, ",", 1);
+ nb += 1;
- nb += xdl_num_out(buf + nb, c1);
+ nb += xdl_num_out(buf + nb, c1);
+ }
memcpy(buf + nb, " +", 2);
nb += 2;
nb += xdl_num_out(buf + nb, c2 ? s2: s2 - 1);
- memcpy(buf + nb, ",", 1);
- nb += 1;
+ if (c2 != 1) {
+ memcpy(buf + nb, ",", 1);
+ nb += 1;
- nb += xdl_num_out(buf + nb, c2);
+ nb += xdl_num_out(buf + nb, c2);
+ }
- memcpy(buf + nb, " @@\n", 4);
- nb += 4;
+ memcpy(buf + nb, " @@", 3);
+ nb += 3;
+ if (func && funclen) {
+ buf[nb++] = ' ';
+ if (funclen > sizeof(buf) - nb - 1)
+ funclen = sizeof(buf) - nb - 1;
+ memcpy(buf + nb, func, funclen);
+ nb += funclen;
+ }
+ buf[nb++] = '\n';
mb.ptr = buf;
mb.size = nb;
diff --git a/xutils.h b/xutils.h
index 4ceae33..5a3e13b 100644
--- a/xutils.h
+++ b/xutils.h
@@ -39,7 +39,8 @@ unsigned long xdl_hash_record(char const
unsigned int xdl_hashbits(unsigned int size);
int xdl_num_out(char *out, long val);
long xdl_atol(char const *str, char const **next);
-int xdl_emit_hunk_hdr(long s1, long c1, long s2, long c2, xdemitcb_t *ecb);
+int xdl_emit_hunk_hdr(long s1, long c1, long s2, long c2,
+ const char *func, long funclen, xdemitcb_t *ecb);
--
1.4.0.gbf9e
^ permalink raw reply related
* libxdiff patches
From: Junio C Hamano @ 2006-06-22 18:57 UTC (permalink / raw)
To: Davide Libenzi; +Cc: git
I'm sending three patches that should apply cleanly on top of
libxdiff 0.21; we use the first two with the copy of
libxdiff/xdiff as built-in difff generator in git.
The first patch is to add an option to emit function names in
the hunk headers, by Mark Wooding. I think this is a good
addition to the upstream libxdiff itself.
The second one is to squelch compilation warnings on (seemingly)
uninitialized variables, by Marco Roeland. You have already
explained on the git list that these warnings are harmless (IOW
the compiler is being stupid), but squelching these warnings
would help spot other real problems.
The primary reason I am sending these to you is to keep the
changes between your version and the copy git uses to the
minimum, so we can keep up with your future updates. Right
now, the differences are mostly that the copy git uses is
stripped down (generalization like s_memallocator and s_mmblock
are not used in our copy, for example), and these two patches
are the only real additions we have.
The third patch, by Johannes Schindelin, teaches whitespaces to
xdiff: -b (--ignore-space-change) and -w (--ignore-all-space).
I haven't merged this into the mainline of git yet. If you are
interested in adding this to upstream (I think it would be a
good addition -- sanity checking is appreciated, though), and if
you are going to do that slightly or majorly differently, I
would prefer to use the change from upstream in order to avoid
carrying git-only local changes in my tree.
^ permalink raw reply
* Re: gitweb refactoring
From: Jakub Narebski @ 2006-06-22 18:37 UTC (permalink / raw)
To: git
In-Reply-To: <e7ed1r$9ve$1@sea.gmane.org>
Another approach to refactoring gitweb would be to look at it's output.
Currently (with the exception of summary view), we have four main types of
views:
1. 'short listing' view, using zebra tables, which list "objects", each with
some number of columns usually not hyperlinked, object name/title,
sometimes shortened, sometimes post-processed which is link to the object,
then some object related links. Actions using this type of view: shortlog,
history, tree, tags, heads, blame; files affected part of commit view.
Examples of columns:
Age, Author, Title[*1*] (link), commit|commitdiff for shortlog
Mode, Filename (link), tree or blob|history for tree
2. 'single object' view, with fixed number of blocks. Actions using this
type of view: commit, tag.
3. 'long listing' view, which list "object"; description of each object
takes more than one line. Actions using this type of view: log, search.
4. 'large object' view, in which "object", optionally with some header, is
written line by line, with some syntax highlighting, sometimes with line
numbering, with at least one div per line. Actions using this type of view:
blob, commitdiff, blobdiff. Currently diffs are not splitted into chunks at
the HTML level (chunks are not encompassed in div; perhaps they should,
perhaps not - HTML like header structure vs DocBook nesting).
5. 'other' non HTML output, including blob_plain, commitdiff_plain,
blobdiff_plain, rss, opml, git_logo; perhaps in the future commitdiff_email
(for git-am or sending to the list), snapshot (tar, tar.gz, tar.bz2),
git_favicon.
Some views have subviews of other type.
Page as whole consist of:
* page header (which includes searchbox, what is not obvious) with
breadcrumbs up to action,
* two part navigation bar:
- first part is always single hash action listing
summary | shortlog | log | commit | commitdiff | tree
with and exception of base (first) commit which doesn't have commitdiff.
- second part is either "pager" for log and shortlog, i.e.
HEAD . prev . next
or "type selection" for commitdiff, blobdiff and blob, sometimes
including head (why not HEAD?).
* sometimes empty title of current hash or hash_base (current commit),
or empty and linking to summary page.
* path (filename) header for tree and blob
* body of the page
* page footer with project description, and RSS link.
[*1*] Processed and shortened title (first line of commit), tooltip using
title attribute of link if shortened (gitweb-xmms2 broke that with
ntroduction of committags), tags which references this commit shown (now
only for summary I think, and tag(s) length is not taken into account when
shortening title/oneline description)
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
^ permalink raw reply
* Re: [PATCH] Pass -DDEFAULT_GIT_TEMPLATE_DIR only where actually used.
From: Petr Baudis @ 2006-06-22 17:58 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vodwlp12i.fsf@assigned-by-dhcp.cox.net>
Dear diary, on Thu, Jun 22, 2006 at 07:11:49PM CEST, I got a letter
where Junio C Hamano <junkio@cox.net> said that...
> Petr Baudis <pasky@suse.cz> writes:
>
> > Dear diary, on Thu, Jun 22, 2006 at 09:19:52AM CEST, I got a letter
> > where Junio C Hamano <junkio@cox.net> said that...
> >> For that matter, I do not think tracking prefix_SQ makes much
> >> sense since what matters are bindir, gitexecdir and template_dir
> >> which are already covered, and prefix is merely a convenience to
> >> set these three (four, counting GIT_PYTHON_DIR; we probably
> >> should add it to TRACK_CFLAGS).
> >
> > $(prefix) will be passed to perl/Makefile.PL.
>
> Then probably it shouldn't; instead we woulld probably want to
> pass the moral equivalent of GIT_PYTHON_DIR.
I'm not sure about what the rationale behind GIT_PYTHON_DIR was, but it
seems to be used only by a library supposedly internal to some Git
commands, while the Git.pm module should be available systemwide even
for non-Git applications, so it's really best to leave it to Perl where
to put it.
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
A person is just about as big as the things that make them angry.
^ permalink raw reply
* Re: Tracking CVS
From: Junio C Hamano @ 2006-06-22 17:43 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git
In-Reply-To: <e7ej5o$1p6$1@sea.gmane.org>
Jakub Narebski <jnareb@gmail.com> writes:
> Junio C Hamano wrote:
>
>> Petr Baudis <pasky@suse.cz> writes:
>
>>> Perhaps we might make a special command which would sync the index set
>>> with the working copy set...
>>
>> I think that makes sense. Something like what "git-commit -a"
>> does before making a commit.
>
> Isn't that what "git update-index --again" does?
No.
^ permalink raw reply
* Re: Tracking CVS
From: Jakub Narebski @ 2006-06-22 17:14 UTC (permalink / raw)
To: git
In-Reply-To: <7vveqtp1dl.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano wrote:
> Petr Baudis <pasky@suse.cz> writes:
>> Perhaps we might make a special command which would sync the index set
>> with the working copy set...
>
> I think that makes sense. Something like what "git-commit -a"
> does before making a commit.
Isn't that what "git update-index --again" does?
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
^ permalink raw reply
* Re: [PATCH] Pass -DDEFAULT_GIT_TEMPLATE_DIR only where actually used.
From: Junio C Hamano @ 2006-06-22 17:11 UTC (permalink / raw)
To: Petr Baudis; +Cc: git
In-Reply-To: <20060622131235.GA21864@pasky.or.cz>
Petr Baudis <pasky@suse.cz> writes:
> Dear diary, on Thu, Jun 22, 2006 at 09:19:52AM CEST, I got a letter
> where Junio C Hamano <junkio@cox.net> said that...
>> For that matter, I do not think tracking prefix_SQ makes much
>> sense since what matters are bindir, gitexecdir and template_dir
>> which are already covered, and prefix is merely a convenience to
>> set these three (four, counting GIT_PYTHON_DIR; we probably
>> should add it to TRACK_CFLAGS).
>
> $(prefix) will be passed to perl/Makefile.PL.
Then probably it shouldn't; instead we woulld probably want to
pass the moral equivalent of GIT_PYTHON_DIR.
^ permalink raw reply
* Re: Tracking CVS
From: Junio C Hamano @ 2006-06-22 17:05 UTC (permalink / raw)
To: Petr Baudis; +Cc: git
In-Reply-To: <20060622135831.GB21864@pasky.or.cz>
Petr Baudis <pasky@suse.cz> writes:
> If you want to be safe even with filenames containing newlines, you need
> to go at the Git level:
>
> git-ls-files -z --others | \
> xargs -0 git-update-index --add --
If you want to avoid "xargs -0", you can replace it with
"git-update-index -z --stdin" I think.
> Perhaps we might make a special command which would sync the index set
> with the working copy set...
I think that makes sense. Something like what "git-commit -a"
does before making a commit.
^ permalink raw reply
* Re: [PATCH 4/4] upload-pack/fetch-pack: support side-band communication
From: Jon Loeliger @ 2006-06-22 16:22 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Git List
In-Reply-To: <7vpsh2xcv1.fsf@assigned-by-dhcp.cox.net>
On Wed, 2006-06-21 at 19:17, Junio C Hamano wrote:
> > Somehow this does not work when connecting to git daemon that
> > runs under inetd. Fixes appreciated.
>
> This seems to fix it.
> - fclose(stderr); //FIXME: workaround
> + freopen("/dev/null", "w", stderr);
>
Sweet. Thanks!
jdl
^ permalink raw reply
* gitweb refactoring
From: Jakub Narebski @ 2006-06-22 15:30 UTC (permalink / raw)
To: git
Junio C Hamano wrote:
> Jakub Narebski <jnareb@gmail.com> writes:
> > Jakub Narebski wrote:
>>
>>> * Refactor generation of navigation bar. There are at least two
>>> implementations of that. With hash dispatch it would be easy to
>>> list all possibilities.
>>
>> Actually I think that whole gitweb.cgi needs refactoring, badly.
>> Generation of navigation bar is only one, admittedly worst,
>> example of code duplication.
>
> Yes. I liked what xmms2 folks did to the navbar exactly for
> that reason. We would be better off to first clean up what we
> currently have before starting to build too much on it.
So lets talk about gitweb refactoring.
Currently gitweb subroutines can be divided into following categories:
1. "Action" subroutines, which do all the work, i.e. they output whole
contents of the page. Currently they are named git_$action, e.g.
git_summary(), git_log(), git_blob(), git_heads(),... , git_blame().
The list includes "hidden" actions, namely git_logo(), git_opml(), and
git_project_list(). There is nothing 'git' about those subroutines.
How should they be named? What prefix to use? action_summary(),
write_summary(), output_summary(), out_summary(), gitweb_summary()?
2. Miscelanous "HTML" subroutines, outputting fragments of HTML code, like
git_header_html, git_footer_html and die_error; or returning fragment of
HTML code, like format_log_line_html. Refactoring should put all the work
into such subroutines.
3. Many helper subroutines:
- related o HTML or HTTP: esc_param, esc_html, mimetype_guess_file,
mimetype_guess, git_blob_plain_mimetype, age_class
- mangling git output: unquote, age_class, age_string, mode_str, file_type
- other helper subroutines: chop_str, date_str, get_file_owner,
validate_input
4. Subroutines which invoke git commands, usually using "-|" LIST magic
output call: git_get_type($hash), git_get_project_config($key) and
git_get_project_config_bool($key), git_get_hash_by_path($base, $path).
Including git_read_tag($hash) and git_read_commit($hash) which fills
%tag/%co object with information from parsing tag/commit.
Unusual in this set git_read_head($project) which sets $ENV{GIT_DIR}
temporarily and git_diff_print($from_id, $from_name, $to_id, $to_name,
$format = "html") which does the work for blobdiff and blobdiff_plain using
temporary files (new git probably can do this without need for temporaru
files)
5. Subroutines which directly access git repository, sometimes calling
subroutines mentioned above, including: git_read_hash (which needs
refactoring itself I think), git_read_description, git_read_projects,
read_info_ref, git_read_refs (instead of using git-branch or git-tag -l,
which also parses information into %ref_item hash).
6* Listed in the sets above are suroutines which parse info into hash or
array of hashes/hashrefs: git_read_tag, git_read_commit, git_read_refs.
Other multi-line output like 'ls-tree' output is parsed and output line by
line.
Some of those subroutines probably will find the way to Git.pm. But in all
they need to be cleanly separated into classed if possible, and reworked to
do one thing and do it well. Passing parameters instead of relying on
global variables would help porting to mod_perl, for example.
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
^ permalink raw reply
* Re: [RFC] gitweb wishlist and TODO list
From: Ryan Anderson @ 2006-06-22 14:47 UTC (permalink / raw)
To: Dennis Stosberg; +Cc: Jakub Narebski, git
In-Reply-To: <20060622100024.G7f491d4a@leonov.stosberg.net>
On Thu, Jun 22, 2006 at 12:00:25PM +0200, Dennis Stosberg wrote:
> Jakub Narebski wrote:
>
> > So now you have extra git redirector being spawned, instead of extra shell
> > being spawned.
>
> Most of the commands that Gitweb uses are built-ins, so there
> shouldn't be any extra overhead by calling "git command" instead of
> "git-command". If I haven't missed one, git-annotate is the only one
> which is not a built-in.
git-annotate is a Perl script anyway, so it's not unreasonable to
consider making it a .pm module and just using it directly in gitweb.
--
Ryan Anderson
sometimes Pug Majere
^ permalink raw reply
* Re: Tracking CVS
From: Jon Smirl @ 2006-06-22 14:17 UTC (permalink / raw)
To: Petr Baudis; +Cc: git
In-Reply-To: <20060622135831.GB21864@pasky.or.cz>
On 6/22/06, Petr Baudis <pasky@suse.cz> wrote:
> Dear diary, on Thu, Jun 22, 2006 at 02:41:16PM CEST, I got a letter
> where Jon Smirl <jonsmirl@gmail.com> said that...
> > I'm tracking cvs using this sequence.
> >
> > cvs update
> > cg rm -a
> > cg commit
> > cg add -r .
> > cg commit
> >
> > Is there a way to avoid the two commits? If you do the add with out
> > the intervening commit it just adds the files back.
>
> I think the most straightforward way is:
>
> cvs update
> cg-rm -a
> cg-status -wns \? | xargs cg-add
> cg-commit
>
> If you want to be careful about filenames polluted by non-newline
> whitespaces,
>
> cg-status -wns \? | tr '\n' '\0' | xargs -0 cg-add
>
> If you want to be safe even with filenames containing newlines, you need
> to go at the Git level:
>
> git-ls-files -z --others | \
> xargs -0 git-update-index --add --
>
> Perhaps we might make a special command which would sync the index set
> with the working copy set...
How about a cg-sync? Tracking cvs (or other SCM) with git is probably
a common activitiy while you try to convince the other CVS users to
switch. It is probably worth a little write up in the readme on the
best way to do it.
cg-sync should probably default to having a prompt before actually
adding/removing the files. Add a -f or something to get rid of the
prompt.
--
Jon Smirl
jonsmirl@gmail.com
^ permalink raw reply
* Added macro support to qgit
From: Marco Costalba @ 2006-06-22 14:04 UTC (permalink / raw)
To: git; +Cc: proski
I have pushed some patches that add macros to qgit.
>From menu bar it is possible to run a macro created by a fancy new
dialog invoked by 'Macros->Setup macros...' menu.
See http://digilander.libero.it/mcostalba/macros_menu.png
http://digilander.libero.it/mcostalba/macros_dialog.png
A macro can be associated to a any sequence of commands or to an
external script.
In case of commands sequence, these will be wrapped up in a temporary
script and executed as a whole.
A macro can also ask for command line arguments before to be run so to
allow for maximum flexibility. In case of multi commands sequence
given command line arguments will be bounded to first one only.
While a macro is running a terminal window is shown to display the
corresponding output.
qgit repository is: git://git.kernel.org/pub/scm/qgit/qgit.git
Comments and feedback are welcomed.
Marco
^ permalink raw reply
* Re: Tracking CVS
From: Petr Baudis @ 2006-06-22 13:58 UTC (permalink / raw)
To: Jon Smirl; +Cc: git
In-Reply-To: <9e4733910606220541y15d66fa6t33ab0c80ae05f764@mail.gmail.com>
Dear diary, on Thu, Jun 22, 2006 at 02:41:16PM CEST, I got a letter
where Jon Smirl <jonsmirl@gmail.com> said that...
> I'm tracking cvs using this sequence.
>
> cvs update
> cg rm -a
> cg commit
> cg add -r .
> cg commit
>
> Is there a way to avoid the two commits? If you do the add with out
> the intervening commit it just adds the files back.
I think the most straightforward way is:
cvs update
cg-rm -a
cg-status -wns \? | xargs cg-add
cg-commit
If you want to be careful about filenames polluted by non-newline
whitespaces,
cg-status -wns \? | tr '\n' '\0' | xargs -0 cg-add
If you want to be safe even with filenames containing newlines, you need
to go at the Git level:
git-ls-files -z --others | \
xargs -0 git-update-index --add --
Perhaps we might make a special command which would sync the index set
with the working copy set...
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
A person is just about as big as the things that make them angry.
^ 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