* Re: What's in git.git
From: Martin Langhoff @ 2006-03-05 9:21 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vacc5jza6.fsf@assigned-by-dhcp.cox.net>
On 3/5/06, Junio C Hamano <junkio@cox.net> wrote:
> - Emacs interface (Alexandre Julliard)
> contrib/emacs: Add an Emacs VC backend.
> git.el: Added customize support for all parameters.
> git.el: Added support for Signed-off-by.
> git.el: Automatically update .gitignore status.
> git.el: Portability fixes for XEmacs and Emacs CVS.
> git.el: Set default directory before running the status mode setup hooks.
I'm somewhat confused by the fact that there are two emacs modes, both
by Alexandre. Which one should I use? Also -- the killer app for
emacs+git would be to leverage the great patch-editing mode in emacs.
Can we get a new merge conflict mode that generates .rej files? Emacs
is superb at dealing with conflicts formatted that way. OTOH, it may
be able to deal smartly with diff3-style conflicts if it knows how to
talk with the VC backend -- I think the cvs mode can do that.
Linus has mentioned several times that it is more important to have
well oiled tools to deal with conflicts when they happen -- easy
visualization of what the different versions were, commit msgs,
highlight characters that don't match in a line that looks the same at
first glance, etc -- than to try and magically resolve conflicts. I'm
in violent agreement, and keen on seeing the emacs vc stuff fill that
gap.
(of course, if xxdiff and others can help, that'd be cool too, but
currently they seem strangely unable to deal with files with diff3
conflict markers.)
> - git-cvsserver updates (Martin Langhoff)
Wohoo! This needs testers -- give it a whirl, please! BTW, the
workarounds for Eclipse mentioned in the doco are no longer needed.
Still, you do want to give Documentation/git-cvsserver.txt a quick
read.
cheers,
martin
^ permalink raw reply
* Re: Managing topic branches
From: Martin Langhoff @ 2006-03-05 9:35 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vzmk5lkmo.fsf@assigned-by-dhcp.cox.net>
On 3/5/06, Junio C Hamano <junkio@cox.net> wrote:
> I could have done without the "questionable octopus leg", but I
> did so that when Martin pulled my "next" into his cvsserver
...
> The moral of the story is not to try to be nice to others
> without thinking about its concequences ;-). I should have just
> done without the "questionable octopus leg", and asked Martin to
> discard and rebase his tip of the development to my "next" after
> this merge.
No good deed goes unpunished as they say ;-)
In any case, this was perhaps based on a misunderstanding/error on my
side. To start off, I didn't understand how you were managing next.
I assumed next would be a 'rewind often' branch, a volatile thing that
I shouldn't build upon. But as I was in the awkward situation of
depending on something in next, I had to, and didn't think of the
consequences. As the branch I published for you to pull was based on
next, which meant you couldn't merge my stuff into master.
So it was a thinko on my side. I just though -- damn, I'll have to
work based on next, with the downside of having to be alert for
rewinds. Didn't think of the implications for you.
It's sorted now, but at great pains for you. I guess all I can suggest
is to put something in the name of the branch that means both "rewinds
often" and "don't base real work on this". I guess that would be
anything but master/maint, but the rules around pu are sometimes
tricky too (rewinds often, but some people have no option but to build
against it, unless you are treating it same as you treat next).
Anyway -- sorry to have caused so much trouble. My work "pending" is
at the most a patch or two, easy to extract and reapply. If something
like this comes up again, just do whatever is easiest and tell me to
rewind/rebase/cherrypick at my end.
cheers,
martin
^ permalink raw reply
* [PATCH 1/3] git.c: Kill type mismatch warning.
From: Mark Wooding @ 2006-03-05 9:36 UTC (permalink / raw)
To: git
In-Reply-To: <20060305093351.26650.84677.stgit@metalzone.distorted.org.uk>
From: Mark Wooding <mdw@distorted.org.uk>
GCC objects when you pass a `char **' where a `const char **' is wanted.
The cast shuts the compiler up, and does the right thing generally.
Signed-off-by: Mark Wooding <mdw@distorted.org.uk>
---
Unfortunately, the warning is fair enough. I can pass a `T' where
someone was expecting a `const T', but that would mean that the callee
was expecting a `char *const *'.
---
git.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/git.c b/git.c
index a547dbd..69df070 100644
--- a/git.c
+++ b/git.c
@@ -261,7 +261,7 @@ static int cmd_log(int argc, char **argv
int show_parents = 0;
const char *commit_prefix = "commit ";
- argc = setup_revisions(argc, argv, &rev, "HEAD");
+ argc = setup_revisions(argc, (const char **)argv, &rev, "HEAD");
while (1 < argc) {
char *arg = argv[1];
if (!strncmp(arg, "--pretty", 8)) {
^ permalink raw reply related
* [PATCH 0/3] Build fixes for v1.2.4-gc9e9f1a
From: Mark Wooding @ 2006-03-05 9:33 UTC (permalink / raw)
To: git
The master branch, as of c9e9f1ad8aae4bd49791d53cc0cd501120884850,
doesn't build cleanly for me. There's a warning about git.c, warnings
about Documentation/git-cvsserver.txt, and an abject failure to process
Documentation/git-tools.txt.
The following patches fix these problems, at least for me.
For reference, I'm running
* gcc (GCC) 4.0.3 20060212 (prerelease) (Debian 4.0.2-9)
* asciidoc 7.0.2
-- [mdw]
^ permalink raw reply
* [PATCH 2/3] Documentation/Makefile: Some `git-*.txt' files aren't manpages.
From: Mark Wooding @ 2006-03-05 9:36 UTC (permalink / raw)
To: git
In-Reply-To: <20060305093351.26650.84677.stgit@metalzone.distorted.org.uk>
From: Mark Wooding <mdw@distorted.org.uk>
In particular, git-tools.txt isn't a manpage, and my Asciidoc gets upset
by it. The simplest fix is to Remove articles from the list of manpages
the Makefile.
Signed-off-by: Mark Wooding <mdw@distorted.org.uk>
---
Documentation/Makefile | 6 +++++-
1 files changed, 5 insertions(+), 1 deletions(-)
diff --git a/Documentation/Makefile b/Documentation/Makefile
index a3bca86..f4cbf7e 100644
--- a/Documentation/Makefile
+++ b/Documentation/Makefile
@@ -1,4 +1,7 @@
-MAN1_TXT=$(wildcard git-*.txt) gitk.txt
+MAN1_TXT= \
+ $(filter-out $(addsuffix .txt, $(ARTICLES) $(SP_ARTICLES)), \
+ $(wildcard git-*.txt)) \
+ gitk.txt
MAN7_TXT=git.txt
DOC_HTML=$(patsubst %.txt,%.html,$(MAN1_TXT) $(MAN7_TXT))
@@ -11,6 +14,7 @@ ARTICLES += howto-index
ARTICLES += repository-layout
ARTICLES += hooks
ARTICLES += everyday
+ARTICLES += git-tools
# with their own formatting rules.
SP_ARTICLES = glossary howto/revert-branch-rebase
^ permalink raw reply related
* [PATCH 3/3] Documentation/git-cvsserver.txt: Fix list numbering.
From: Mark Wooding @ 2006-03-05 9:36 UTC (permalink / raw)
To: git
In-Reply-To: <20060305093351.26650.84677.stgit@metalzone.distorted.org.uk>
From: Mark Wooding <mdw@distorted.org.uk>
Asciidoc complains about the bogus list item numbers in the installation
instructions. Fix them.
Signed-off-by: Mark Wooding <mdw@distorted.org.uk>
---
Documentation/git-cvsserver.txt | 4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/Documentation/git-cvsserver.txt b/Documentation/git-cvsserver.txt
index 19c9c51..0c4948d 100644
--- a/Documentation/git-cvsserver.txt
+++ b/Documentation/git-cvsserver.txt
@@ -44,13 +44,13 @@ INSTALLATION
n.b. you need to ensure each user that is going to invoke server.pl has
write access to the log file.
-5. On each client machine you need to set the following variables.
+3. On each client machine you need to set the following variables.
CVSROOT should be set as per normal, but the directory should point at the
appropriate git repo.
CVS_SERVER should be set to the server.pl script that has been put on the
remote machine.
-6. Clients should now be able to check out modules (where modules are the names
+4. Clients should now be able to check out modules (where modules are the names
of branches in git).
$ cvs co -d mylocaldir master
^ permalink raw reply related
* Re: What's in git.git
From: Alexandre Julliard @ 2006-03-05 9:58 UTC (permalink / raw)
To: Martin Langhoff; +Cc: Junio C Hamano, git
In-Reply-To: <46a038f90603050121u6bccbb71ve78de69ae45b96ad@mail.gmail.com>
"Martin Langhoff" <martin.langhoff@gmail.com> writes:
> I'm somewhat confused by the fact that there are two emacs modes, both
> by Alexandre. Which one should I use? Also -- the killer app for
> emacs+git would be to leverage the great patch-editing mode in emacs.
You can use both. The VC backend is a per-file mode, that's handy when
you are editing a file and want a quick diff/revert/commit of just
that file; the commands are executed directly from the buffer
containing the file. When making bigger changes, you should use the
git-status mode (the one in git.el), which is a tree browser that
gives you a view of the whole project.
> Can we get a new merge conflict mode that generates .rej files? Emacs
> is superb at dealing with conflicts formatted that way. OTOH, it may
> be able to deal smartly with diff3-style conflicts if it knows how to
> talk with the VC backend -- I think the cvs mode can do that.
What emacs mode do you use to resolve conflicts? From the git-status
buffer, if you edit a file with 'f' it will automatically turn on
smerge mode if there are conflicts, or you can edit it in ediff merge
mode with 'd E' like under pcl-cvs. Is that what you mean?
--
Alexandre Julliard
julliard@winehq.org
^ permalink raw reply
* Re: What's in git.git
From: Junio C Hamano @ 2006-03-05 10:10 UTC (permalink / raw)
To: Martin Langhoff; +Cc: Junio C Hamano, git
In-Reply-To: <46a038f90603050121u6bccbb71ve78de69ae45b96ad@mail.gmail.com>
"Martin Langhoff" <martin.langhoff@gmail.com> writes:
> I'm somewhat confused by the fact that there are two emacs modes, both
> by Alexandre. Which one should I use? Also -- the killer app for
> emacs+git would be to leverage the great patch-editing mode in emacs.
They are different styles. I've been in VC camp but my
understanding is pcl-cvs style integration is closer to
whole-tree than VC which is more per-file. I still haven't
adjusted to pcl-cvs style yet..
> (of course, if xxdiff and others can help, that'd be cool too, but
> currently they seem strangely unable to deal with files with diff3
> conflict markers.)
I had pleasant experiences with "xxdiff -U".
^ permalink raw reply
* [PATCH] cvsserver: updated documentation
From: Martin Langhoff @ 2006-03-05 10:11 UTC (permalink / raw)
To: git, junkio; +Cc: Martin Langhoff
... and stripped trailing whitespace to appease the Gods...
Signed-off-by: Martin Langhoff <martin@catalyst.net.nz>
---
Documentation/git-cvsserver.txt | 87 +++++++++++++++++++++++++++------------
1 files changed, 61 insertions(+), 26 deletions(-)
a67387be3b0dd572f78da9befe27303b20e9cbf1
diff --git a/Documentation/git-cvsserver.txt b/Documentation/git-cvsserver.txt
index 19c9c51..4dc13c3 100644
--- a/Documentation/git-cvsserver.txt
+++ b/Documentation/git-cvsserver.txt
@@ -5,14 +5,12 @@ NAME
----
git-cvsserver - A CVS server emulator for git
-
SYNOPSIS
--------
[verse]
export CVS_SERVER=git-cvsserver
'cvs' -d :ext:user@server/path/repo.git co <HEAD_name>
-
DESCRIPTION
-----------
@@ -27,48 +25,85 @@ plugin. Most functionality works fine wi
LIMITATIONS
-----------
-Currently gitcvs only works over ssh connections.
+Currently cvsserver works over SSH connections for read/write clients, and
+over pserver for anonymous CVS access.
+
+CVS clients cannot tag, branch or perform GIT merges.
INSTALLATION
------------
-1. Put server.pl somewhere useful on the same machine that is hosting your git repos
+
+1. If you are going to offer anonymous CVS access via pserver, add a line in
+ /etc/inetd.conf like
+
+ cvspserver stream tcp nowait nobody git-cvsserver pserver
+
+ Note: In some cases, you need to pass the 'pserver' argument twice for
+ git-cvsserver to see it. So the line would look like
+
+ cvspserver stream tcp nowait nobody git-cvsserver pserver pserver
+
+ No special setup is needed for SSH access, other than having GIT tools
+ in the PATH. If you have clients that do not accept the CVS_SERVER
+ env variable, you can rename git-cvsserver to cvs.
2. For each repo that you want accessible from CVS you need to edit config in
the repo and add the following section.
[gitcvs]
enabled=1
+ # optional for debugging
logfile=/path/to/logfile
- n.b. you need to ensure each user that is going to invoke server.pl has
- write access to the log file.
+ Note: you need to ensure each user that is going to invoke git-cvsserver has
+ write access to the log file and to the git repository. When offering anon
+ access via pserver, this means that the nobody user should have write access
+ to at least the sqlite database at the root of the repository.
+
+3. On the client machine you need to set the following variables.
+ CVSROOT should be set as per normal, but the directory should point at the
+ appropriate git repo. For example:
+
+ For SSH access, CVS_SERVER should be set to git-cvsserver
+
+ Example:
+
+ export CVSROOT=:ext:user@server:/var/git/project.git
+ export CVS_SERVER=git-cvsserver
+
+4. For SSH clients that will make commits, make sure their .bashrc file
+ sets the GIT_AUTHOR and GIT_COMMITTER variables.
+
+5. Clients should now be able to check out the project. Use the CVS 'module'
+ name to indicate what GIT 'head' you want to check out. Example:
-5. On each client machine you need to set the following variables.
- CVSROOT should be set as per normal, but the directory should point at the
- appropriate git repo.
- CVS_SERVER should be set to the server.pl script that has been put on the
- remote machine.
-
-6. Clients should now be able to check out modules (where modules are the names
- of branches in git).
- $ cvs co -d mylocaldir master
+ cvs co -d project-master master
Eclipse CVS Client Notes
------------------------
To get a checkout with the Eclipse CVS client:
-1. Create a new project from CVS checkout, giving it repository and module
-2. Context Menu->Team->Share Project...
-3. Enter the repository and module information again and click Finish
-4. The Synchronize view appears. Untick "launch commit wizard" to avoid
-committing the .project file, and select HEAD as the tag to synchronize to.
-Update all incoming changes.
-
-Note that most versions of Eclipse ignore CVS_SERVER (which you can set in
-the Preferences->Team->CVS->ExtConnection pane), so you may have to
-rename, alias or symlink git-cvsserver to 'cvs' on the server.
+1. Select "Create a new project -> From CVS checkout"
+2. Create a new location. See the notes below for details on how to choose the
+ right protocol.
+3. Browse the 'modules' available. It will give you a list of the heads in
+ the repository. You will not be able to browse the tree from there. Only
+ the heads.
+4. Pick 'HEAD' when it asks what branch/tag to check out. Untick the
+ "launch commit wizard" to avoid committing the .project file.
+
+Protocol notes: If you are using anonymous acces via pserver, just select that.
+Those using SSH access should choose the 'ext' protocol, and configure 'ext'
+access on the Preferences->Team->CVS->ExtConnection pane. Set CVS_SERVER to
+'git-cvsserver'. Not that password support is not good when using 'ext',
+you will definitely want to have SSH keys setup.
+
+Alternatively, you can just use the non-standard extssh protocol that Eclipse
+offer. In that case CVS_SERVER is ignored, and you will have to replace
+the cvs utility on the server with git-cvsserver or manipulate your .bashrc
+so that calling 'cvs' effectively calls git-cvsserver.
Clients known to work
---------------------
@@ -106,7 +141,7 @@ Authors: Martyn Smith <martyn@catalys
Documentation
--------------
-Documentation by Martyn Smith <martyn@catalyst.net.nz> and Martin Langhoff <martin@catalyst.net.nz>Matthias Urlichs <smurf@smurf.noris.de>.
+Documentation by Martyn Smith <martyn@catalyst.net.nz> and Martin Langhoff <martin@catalyst.net.nz> Matthias Urlichs <smurf@smurf.noris.de>.
GIT
---
--
1.2.4.g0a60
^ permalink raw reply related
* Re: Managing topic branches
From: Junio C Hamano @ 2006-03-05 10:14 UTC (permalink / raw)
To: Martin Langhoff; +Cc: git
In-Reply-To: <46a038f90603050135j41eaf935kd48ab68212218836@mail.gmail.com>
"Martin Langhoff" <martin.langhoff@gmail.com> writes:
> In any case, this was perhaps based on a misunderstanding/error on my
> side. To start off, I didn't understand how you were managing next.
No nononononono nooooo.
If I sounded like you were the guilty party I apologize. I did
not mean it that way.
It was my mistake. I encouraged people to experiment and build
upon "next". It was just the way I pulled the stuff in was bad.
^ permalink raw reply
* Re: What's in git.git
From: Martin Langhoff @ 2006-03-05 10:15 UTC (permalink / raw)
To: Alexandre Julliard; +Cc: Junio C Hamano, git
In-Reply-To: <87irqtjjr1.fsf@wine.dyndns.org>
On 3/5/06, Alexandre Julliard <julliard@winehq.org> wrote:
> You can use both. The VC backend is a per-file mode, that's handy when
> you are editing a file and want a quick diff/revert/commit of just
> that file; the commands are executed directly from the buffer
> containing the file. When making bigger changes, you should use the
> git-status mode (the one in git.el), which is a tree browser that
> gives you a view of the whole project.
So I should use a combination of both? Hmmm. Worth exploring, can you
give us a quick guide on getting started with it? (Or where should I
read? I'm not that good with emacs)...
> > Can we get a new merge conflict mode that generates .rej files? Emacs
> > is superb at dealing with conflicts formatted that way. OTOH, it may
> > be able to deal smartly with diff3-style conflicts if it knows how to
> > talk with the VC backend -- I think the cvs mode can do that.
>
> What emacs mode do you use to resolve conflicts? From the git-status
> buffer, if you edit a file with 'f' it will automatically turn on
> smerge mode if there are conflicts, or you can edit it in ediff merge
> mode with 'd E' like under pcl-cvs. Is that what you mean?
Oh. Ah. Ok! I'll have to try this! So far, I've had good luck
following this guide:
http://wiki.gnuarch.org/Process_20_2a_2erej_20files
which is targetted pretty much at dumb emacs users. Like me ;-)
martin
^ permalink raw reply
* [PATCH] git-blame: Make the output human readable
From: Fredrik Kuivinen @ 2006-03-05 11:03 UTC (permalink / raw)
To: git; +Cc: junkio
The default output mode is slightly different from git-annotate's.
However, git-annotate's output mode can be obtained by using the
'-c' flag.
Signed-off-by: Fredrik Kuivinen <freku045@student.liu.se>
---
Makefile | 4 ++
blame.c | 164 +++++++++++++++++++++++++++++++++++++++++++++++++++++++-------
2 files changed, 149 insertions(+), 19 deletions(-)
3459b7c5032d1462d5857cf6afc2d3e3ef61b93b
diff --git a/Makefile b/Makefile
index b6d8804..eb1887d 100644
--- a/Makefile
+++ b/Makefile
@@ -534,6 +534,10 @@ git-rev-list$X: rev-list.o $(LIB_FILE)
$(CC) $(ALL_CFLAGS) -o $@ $(ALL_LDFLAGS) $(filter %.o,$^) \
$(LIBS) $(OPENSSL_LIBSSL)
+git-blame$X: blame.o $(LIB_FILE)
+ $(CC) $(ALL_CFLAGS) -o $@ $(ALL_LDFLAGS) $(filter %.o,$^) \
+ $(LIBS) -lm
+
init-db.o: init-db.c
$(CC) -c $(ALL_CFLAGS) \
-DDEFAULT_GIT_TEMPLATE_DIR='"$(template_dir_SQ)"' $*.c
diff --git a/blame.c b/blame.c
index 7308c36..6dccae5 100644
--- a/blame.c
+++ b/blame.c
@@ -5,6 +5,7 @@
#include <assert.h>
#include <time.h>
#include <sys/time.h>
+#include <math.h>
#include "cache.h"
#include "refs.h"
@@ -17,8 +18,15 @@
#define DEBUG 0
-struct commit **blame_lines;
-int num_blame_lines;
+static const char blame_usage[] = "[-c] [-l] [--] file [commit]\n"
+ " -c, --compability Use the same output mode as git-annotate (Default: off)\n"
+ " -l, --long Show long commit SHA1 (Default: off)\n"
+ " -h, --help This message";
+
+static struct commit **blame_lines;
+static int num_blame_lines;
+static char* blame_contents;
+static int blame_len;
struct util_info {
int *line_map;
@@ -388,9 +396,8 @@ static void init_first_commit(struct com
alloc_line_map(commit);
util = commit->object.util;
- num_blame_lines = util->num_lines;
- for (i = 0; i < num_blame_lines; i++)
+ for (i = 0; i < util->num_lines; i++)
util->line_map[i] = i;
}
@@ -412,6 +419,9 @@ static void process_commits(struct rev_i
util = commit->object.util;
num_blame_lines = util->num_lines;
blame_lines = xmalloc(sizeof(struct commit *) * num_blame_lines);
+ blame_contents = util->buf;
+ blame_len = util->size;
+
for (i = 0; i < num_blame_lines; i++)
blame_lines[i] = NULL;
@@ -499,32 +509,128 @@ static void process_commits(struct rev_i
} while ((commit = get_revision(rev)) != NULL);
}
+struct commit_info
+{
+ char* author;
+ char* author_mail;
+ unsigned long author_time;
+ char* author_tz;
+};
+
+static void get_commit_info(struct commit* commit, struct commit_info* ret)
+{
+ int len;
+ char* tmp;
+ static char author_buf[1024];
+
+ tmp = strstr(commit->buffer, "\nauthor ") + 8;
+ len = index(tmp, '\n') - tmp;
+ ret->author = author_buf;
+ memcpy(ret->author, tmp, len);
+
+ tmp = ret->author;
+ tmp += len;
+ *tmp = 0;
+ while(*tmp != ' ')
+ tmp--;
+ ret->author_tz = tmp+1;
+
+ *tmp = 0;
+ while(*tmp != ' ')
+ tmp--;
+ ret->author_time = strtoul(tmp, NULL, 10);
+
+ *tmp = 0;
+ while(*tmp != ' ')
+ tmp--;
+ ret->author_mail = tmp + 1;
+
+ *tmp = 0;
+}
+
+char* format_time(unsigned long time, const char* tz)
+{
+ static char time_buf[128];
+ time_t t = time;
+
+ strftime(time_buf, sizeof(time_buf), "%Y-%m-%d %H:%M:%S ", gmtime(&t));
+ strcat(time_buf, tz);
+ return time_buf;
+}
+
int main(int argc, const char **argv)
{
int i;
struct commit *initial = NULL;
unsigned char sha1[20];
- const char* filename;
+
+ const char *filename = NULL, *commit = NULL;
+ char filename_buf[256];
+ int sha1_len = 8;
+ int compability = 0;
+ int options = 1;
+
int num_args;
const char* args[10];
struct rev_info rev;
- setup_git_directory();
-
- if (argc != 3)
- die("Usage: blame commit-ish file");
+ struct commit_info ci;
+ const char *buf;
+ int max_digits;
+
+ const char* prefix = setup_git_directory();
+
+ for(i = 1; i < argc; i++) {
+ if(options) {
+ if(!strcmp(argv[i], "-h") ||
+ !strcmp(argv[i], "--help"))
+ usage(blame_usage);
+ else if(!strcmp(argv[i], "-l") ||
+ !strcmp(argv[i], "--long")) {
+ sha1_len = 20;
+ continue;
+ } else if(!strcmp(argv[i], "-c") ||
+ !strcmp(argv[i], "--compability")) {
+ compability = 1;
+ continue;
+ } else if(!strcmp(argv[i], "--")) {
+ options = 0;
+ continue;
+ } else if(argv[i][0] == '-')
+ usage(blame_usage);
+ else
+ options = 0;
+ }
+ if(!options) {
+ if(!filename)
+ filename = argv[i];
+ else if(!commit)
+ commit = argv[i];
+ else
+ usage(blame_usage);
+ }
+ }
- filename = argv[2];
+ if(!filename)
+ usage(blame_usage);
+ if(!commit)
+ commit = "HEAD";
+
+ if(prefix)
+ sprintf(filename_buf, "%s%s", prefix, filename);
+ else
+ strcpy(filename_buf, filename);
+ filename = filename_buf;
{
- struct commit* commit;
- if (get_sha1(argv[1], sha1))
- die("get_sha1 failed");
- commit = lookup_commit_reference(sha1);
+ struct commit* c;
+ if (get_sha1(commit, sha1))
+ die("get_sha1 failed, commit '%s' not found", commit);
+ c = lookup_commit_reference(sha1);
- if (fill_util_info(commit, filename)) {
- printf("%s not found in %s\n", filename, argv[1]);
+ if (fill_util_info(c, filename)) {
+ printf("%s not found in %s\n", filename, commit);
return 1;
}
}
@@ -533,7 +639,7 @@ int main(int argc, const char **argv)
args[num_args++] = NULL;
args[num_args++] = "--topo-order";
args[num_args++] = "--remove-empty";
- args[num_args++] = argv[1];
+ args[num_args++] = commit;
args[num_args++] = "--";
args[num_args++] = filename;
args[num_args] = NULL;
@@ -542,13 +648,33 @@ int main(int argc, const char **argv)
prepare_revision_walk(&rev);
process_commits(&rev, filename, &initial);
+ buf = blame_contents;
+ max_digits = 1 + log(num_blame_lines+1)/log(10);
for (i = 0; i < num_blame_lines; i++) {
struct commit *c = blame_lines[i];
if (!c)
c = initial;
- printf("%d %.8s\n", i, sha1_to_hex(c->object.sha1));
-// printf("%d %s\n", i, find_unique_abbrev(blame_lines[i]->object.sha1, 6));
+ get_commit_info(c, &ci);
+ fwrite(sha1_to_hex(c->object.sha1), sha1_len, 1, stdout);
+ if(compability)
+ printf("\t(%10s\t%10s\t%d)", ci.author,
+ format_time(ci.author_time, ci.author_tz), i+1);
+ else
+ printf(" (%-15.15s %10s %*d) ", ci.author,
+ format_time(ci.author_time, ci.author_tz),
+ max_digits, i+1);
+
+ if(i == num_blame_lines - 1) {
+ fwrite(buf, blame_len - (buf - blame_contents),
+ 1, stdout);
+ if(blame_contents[blame_len-1] != '\n')
+ putc('\n', stdout);
+ } else {
+ char* next_buf = index(buf, '\n') + 1;
+ fwrite(buf, next_buf - buf, 1, stdout);
+ buf = next_buf;
+ }
}
if (DEBUG) {
--
1.2.4.g4644-dirty
^ permalink raw reply related
* [PATCH] git-blame: Use the same tests for git-blame as for git-annotate
From: Fredrik Kuivinen @ 2006-03-05 11:13 UTC (permalink / raw)
To: git; +Cc: junkio
Signed-off-by: Fredrik Kuivinen <freku045@student.liu.se>
---
t/annotate-tests.sh | 86 +++++++++++++++++++++++++++++++++++++++++++++++++++
t/t8001-annotate.sh | 85 +-------------------------------------------------
t/t8002-blame.sh | 9 +++++
3 files changed, 97 insertions(+), 83 deletions(-)
create mode 100644 t/annotate-tests.sh
create mode 100755 t/t8002-blame.sh
06b0e500a5202899dcfd037cf78ee4a982da46b4
diff --git a/t/annotate-tests.sh b/t/annotate-tests.sh
new file mode 100644
index 0000000..54a4dfb
--- /dev/null
+++ b/t/annotate-tests.sh
@@ -0,0 +1,86 @@
+# This file isn't used as a test script directly, instead it is
+# sourced from t8001-annotate.sh and t8001-blame.sh.
+
+test_expect_success \
+ 'prepare reference tree' \
+ 'echo "1A quick brown fox jumps over the" >file &&
+ echo "lazy dog" >>file &&
+ git add file
+ GIT_AUTHOR_NAME="A" git commit -a -m "Initial."'
+
+test_expect_success \
+ 'check all lines blamed on A' \
+ '[ $(git annotate file | awk "{print \$3}" | grep -c "A") == 2 ]'
+
+test_expect_success \
+ 'Setup new lines blamed on B' \
+ 'echo "2A quick brown fox jumps over the" >>file &&
+ echo "lazy dog" >> file &&
+ GIT_AUTHOR_NAME="B" git commit -a -m "Second."'
+
+test_expect_success \
+ 'Two lines blamed on A' \
+ '[ $($PROG file | awk "{print \$3}" | grep -c "A") == 2 ]'
+
+test_expect_success \
+ 'Two lines blamed on B' \
+ '[ $($PROG file | awk "{print \$3}" | grep -c "B") == 2 ]'
+
+test_expect_success \
+ 'merge-setup part 1' \
+ 'git checkout -b branch1 master &&
+ echo "3A slow green fox jumps into the" >> file &&
+ echo "well." >> file &&
+ GIT_AUTHOR_NAME="B1" git commit -a -m "Branch1-1"'
+
+test_expect_success \
+ 'Two lines blamed on A' \
+ '[ $($PROG file | awk "{print \$3}" | grep -c "^A$") == 2 ]'
+
+test_expect_success \
+ 'Two lines blamed on B' \
+ '[ $($PROG file | awk "{print \$3}" | grep -c "^B$") == 2 ]'
+
+test_expect_success \
+ 'Two lines blamed on B1' \
+ '[ $($PROG file | awk "{print \$3}" | grep -c "^B1$") == 2 ]'
+
+test_expect_success \
+ 'merge-setup part 2' \
+ 'git checkout -b branch2 master &&
+ sed -e "s/2A quick brown/4A quick brown lazy dog/" < file > file.new &&
+ mv file.new file &&
+ GIT_AUTHOR_NAME="B2" git commit -a -m "Branch2-1"'
+
+test_expect_success \
+ 'Two lines blamed on A' \
+ '[ $($PROG file | awk "{print \$3}" | grep -c "^A$") == 2 ]'
+
+test_expect_success \
+ 'One line blamed on B' \
+ '[ $($PROG file | awk "{print \$3}" | grep -c "^B$") == 1 ]'
+
+test_expect_success \
+ 'One line blamed on B2' \
+ '[ $($PROG file | awk "{print \$3}" | grep -c "^B2$") == 1 ]'
+
+
+test_expect_success \
+ 'merge-setup part 3' \
+ 'git pull . branch1'
+
+test_expect_success \
+ 'Two lines blamed on A' \
+ '[ $($PROG file | awk "{print \$3}" | grep -c "^A$") == 2 ]'
+
+test_expect_success \
+ 'One line blamed on B' \
+ '[ $($PROG file | awk "{print \$3}" | grep -c "^B$") == 1 ]'
+
+test_expect_success \
+ 'Two lines blamed on B1' \
+ '[ $($PROG file | awk "{print \$3}" | grep -c "^B1$") == 2 ]'
+
+test_expect_success \
+ 'One line blamed on B2' \
+ '[ $($PROG file | awk "{print \$3}" | grep -c "^B2$") == 1 ]'
diff --git a/t/t8001-annotate.sh b/t/t8001-annotate.sh
index 172908a..9e5a04b 100755
--- a/t/t8001-annotate.sh
+++ b/t/t8001-annotate.sh
@@ -3,88 +3,7 @@
test_description='git-annotate'
. ./test-lib.sh
-test_expect_success \
- 'prepare reference tree' \
- 'echo "1A quick brown fox jumps over the" >file &&
- echo "lazy dog" >>file &&
- git add file
- GIT_AUTHOR_NAME="A" git commit -a -m "Initial."'
-
-test_expect_success \
- 'check all lines blamed on A' \
- '[ $(git annotate file | awk "{print \$3}" | grep -c "A") == 2 ]'
-
-test_expect_success \
- 'Setup new lines blamed on B' \
- 'echo "2A quick brown fox jumps over the" >>file &&
- echo "lazy dog" >> file &&
- GIT_AUTHOR_NAME="B" git commit -a -m "Second."'
-
-test_expect_success \
- 'Two lines blamed on A' \
- '[ $(git annotate file | awk "{print \$3}" | grep -c "A") == 2 ]'
-
-test_expect_success \
- 'Two lines blamed on B' \
- '[ $(git annotate file | awk "{print \$3}" | grep -c "B") == 2 ]'
-
-test_expect_success \
- 'merge-setup part 1' \
- 'git checkout -b branch1 master &&
- echo "3A slow green fox jumps into the" >> file &&
- echo "well." >> file &&
- GIT_AUTHOR_NAME="B1" git commit -a -m "Branch1-1"'
-
-test_expect_success \
- 'Two lines blamed on A' \
- '[ $(git annotate file | awk "{print \$3}" | grep -c "^A$") == 2 ]'
-
-test_expect_success \
- 'Two lines blamed on B' \
- '[ $(git annotate file | awk "{print \$3}" | grep -c "^B$") == 2 ]'
-
-test_expect_success \
- 'Two lines blamed on B1' \
- '[ $(git annotate file | awk "{print \$3}" | grep -c "^B1$") == 2 ]'
-
-test_expect_success \
- 'merge-setup part 2' \
- 'git checkout -b branch2 master &&
- sed -e "s/2A quick brown/4A quick brown lazy dog/" < file > file.new &&
- mv file.new file &&
- GIT_AUTHOR_NAME="B2" git commit -a -m "Branch2-1"'
-
-test_expect_success \
- 'Two lines blamed on A' \
- '[ $(git annotate file | awk "{print \$3}" | grep -c "^A$") == 2 ]'
-
-test_expect_success \
- 'One line blamed on B' \
- '[ $(git annotate file | awk "{print \$3}" | grep -c "^B$") == 1 ]'
-
-test_expect_success \
- 'One line blamed on B2' \
- '[ $(git annotate file | awk "{print \$3}" | grep -c "^B2$") == 1 ]'
-
-
-test_expect_success \
- 'merge-setup part 3' \
- 'git pull . branch1'
-
-test_expect_success \
- 'Two lines blamed on A' \
- '[ $(git annotate file | awk "{print \$3}" | grep -c "^A$") == 2 ]'
-
-test_expect_success \
- 'One line blamed on B' \
- '[ $(git annotate file | awk "{print \$3}" | grep -c "^B$") == 1 ]'
-
-test_expect_success \
- 'Two lines blamed on B1' \
- '[ $(git annotate file | awk "{print \$3}" | grep -c "^B1$") == 2 ]'
-
-test_expect_success \
- 'One line blamed on B2' \
- '[ $(git annotate file | awk "{print \$3}" | grep -c "^B2$") == 1 ]'
+PROG='git annotate'
+source ../annotate-tests.sh
test_done
diff --git a/t/t8002-blame.sh b/t/t8002-blame.sh
new file mode 100755
index 0000000..1036c54
--- /dev/null
+++ b/t/t8002-blame.sh
@@ -0,0 +1,9 @@
+#!/bin/sh
+
+test_description='git-blame'
+. ./test-lib.sh
+
+PROG='git blame -c'
+source ../annotate-tests.sh
+
+test_done
--
1.2.4.g4644-dirty
^ permalink raw reply related
* Re: What's in git.git
From: Alexandre Julliard @ 2006-03-05 10:47 UTC (permalink / raw)
To: Martin Langhoff; +Cc: Junio C Hamano, git
In-Reply-To: <46a038f90603050215v7afcbd4crc145e85a4da416a7@mail.gmail.com>
"Martin Langhoff" <martin.langhoff@gmail.com> writes:
> So I should use a combination of both? Hmmm. Worth exploring, can you
> give us a quick guide on getting started with it? (Or where should I
> read? I'm not that good with emacs)...
To get started with the VC backend, make sure vc-git.el is somewhere
on your emacs load-path, and add GIT to the vc-handled-backends
variable; the easiest is with customize, something like
`M-x customize-variable [RET] vc-handled-backends'.
Once you have done that, when you open a file that's under git
control, the vc-git mode should automatically be turned on, and you
should see a "GIT" indicator in the modeline. Then you can use the
standard VC backend commands (the ones that start with the C-x v
prefix). The Emacs VC mode is documented at:
http://www.gnu.org/software/emacs/manual/html_node/Version-Control.html
For the git-status mode, simply do a `M-x load-file [RET] git.el', and
then `M-x git-status'. This will prompt you for the directory to view,
and display a list of modified files. From there you can mark files
and perform actions on group of files, like diff, commit, revert, etc.
There isn't a lot of documentation at this point, but a `C-h m' will
show you the list of key bindings, so you can try them all and see
what happens ;-)
> Oh. Ah. Ok! I'll have to try this! So far, I've had good luck
> following this guide:
>
> http://wiki.gnuarch.org/Process_20_2a_2erej_20files
>
> which is targetted pretty much at dumb emacs users. Like me ;-)
smerge mode is a very simple mode to edit files that contain conflict
markers, in my experience it works pretty well. The nice thing is that
it works directly from the file buffer, so you don't need to jump back
and forth between file and diff.
--
Alexandre Julliard
julliard@winehq.org
^ permalink raw reply
* [PATCH] git-blame: Kill warning "print_map defined but not used"
From: Fredrik Kuivinen @ 2006-03-05 11:16 UTC (permalink / raw)
To: git; +Cc: junkio
Signed-off-by: Fredrik Kuivinen <freku045@student.liu.se>
---
blame.c | 2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
aebef8969d11b04634b9ab7a6ae85a0844b2e4c7
diff --git a/blame.c b/blame.c
index 6dccae5..0fb30ee 100644
--- a/blame.c
+++ b/blame.c
@@ -235,6 +235,7 @@ static void print_patch(struct patch *p)
}
/* For debugging only */
+#if DEBUG
static void print_map(struct commit *cmit, struct commit *other)
{
struct util_info *util = cmit->object.util;
@@ -267,6 +268,7 @@ static void print_map(struct commit *cmi
printf("\n");
}
}
+#endif
// p is a patch from commit to other.
static void fill_line_map(struct commit *commit, struct commit *other,
--
1.2.4.g4644-dirty
^ permalink raw reply related
* [PATCH] avoid asciidoc warning in git-cvsserver.txt
From: Francis Daly @ 2006-03-05 11:41 UTC (permalink / raw)
To: git
Manually renumber to keep asciidoc happy
---
Documentation/git-cvsserver.txt | 4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
9809de6594b8e11261ca5f18bb2eadb913fb33ae
diff --git a/Documentation/git-cvsserver.txt b/Documentation/git-cvsserver.txt
index 19c9c51..0c4948d 100644
--- a/Documentation/git-cvsserver.txt
+++ b/Documentation/git-cvsserver.txt
@@ -44,13 +44,13 @@ INSTALLATION
n.b. you need to ensure each user that is going to invoke server.pl has
write access to the log file.
-5. On each client machine you need to set the following variables.
+3. On each client machine you need to set the following variables.
CVSROOT should be set as per normal, but the directory should point at the
appropriate git repo.
CVS_SERVER should be set to the server.pl script that has been put on the
remote machine.
-6. Clients should now be able to check out modules (where modules are the names
+4. Clients should now be able to check out modules (where modules are the names
of branches in git).
$ cvs co -d mylocaldir master
--
1.2.GIT
--
Francis Daly francis@daoine.org
^ permalink raw reply related
* Re: [PATCH] git-blame: Make the output human readable
From: Junio C Hamano @ 2006-03-05 12:10 UTC (permalink / raw)
To: Fredrik Kuivinen; +Cc: git, Johannes Schindelin, Ryan Anderson
In-Reply-To: <20060305110351.GA23448@c165.ib.student.liu.se>
Fredrik Kuivinen <freku045@student.liu.se> writes:
> The default output mode is slightly different from git-annotate's.
> However, git-annotate's output mode can be obtained by using the
> '-c' flag.
It might be better to default to human readable and make the
script consumption format an option, if only to reduce typing.
> diff --git a/Makefile b/Makefile
> index b6d8804..eb1887d 100644
> --- a/Makefile
> +++ b/Makefile
> @@ -534,6 +534,10 @@ git-rev-list$X: rev-list.o $(LIB_FILE)
> $(CC) $(ALL_CFLAGS) -o $@ $(ALL_LDFLAGS) $(filter %.o,$^) \
> $(LIBS) $(OPENSSL_LIBSSL)
>
> +git-blame$X: blame.o $(LIB_FILE)
> + $(CC) $(ALL_CFLAGS) -o $@ $(ALL_LDFLAGS) $(filter %.o,$^) \
> + $(LIBS) -lm
> +
I wonder what it is about to link this binary different from others...
> +char* format_time(unsigned long time, const char* tz)
> +{
> + static char time_buf[128];
> + time_t t = time;
> +
> + strftime(time_buf, sizeof(time_buf), "%Y-%m-%d %H:%M:%S ", gmtime(&t));
> + strcat(time_buf, tz);
> + return time_buf;
> +}
I think this shows GMT with time offset, which is compatible
with the human readable time Johannes did to git-annotate. I do
not know what timezone CVS annotate shows its dates offhand (it
seems to only show dates). Johannes, is this an attempt to
match what CVS does?
I am wondering if we want to be in line with the date formatting
convention used for our commits and tags, that is, to show local
timestamp with timezone. The code to use would be show_date()
from date.c if we go that route.
^ permalink raw reply
* Re: [PATCH] avoid asciidoc warning in git-cvsserver.txt
From: Francis Daly @ 2006-03-05 12:11 UTC (permalink / raw)
To: git
Oops, I missed
Subject: [PATCH] cvsserver: updated documentation
which makes this one redundant.
Sorry,
f
--
Francis Daly francis@daoine.org
^ permalink raw reply
* [PATCH] gitignore: Ignore some more boring things.
From: Mark Wooding @ 2006-03-05 12:25 UTC (permalink / raw)
To: git
From: Mark Wooding <mdw@distorted.org.uk>
Signed-off-by: Mark Wooding <mdw@distorted.org.uk>
---
.gitignore | 1 +
t/.gitignore | 1 +
2 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/.gitignore b/.gitignore
index 5be239a..abbc509 100644
--- a/.gitignore
+++ b/.gitignore
@@ -130,3 +130,4 @@ libgit.a
*.o
*.py[co]
config.mak
+git-blame
diff --git a/t/.gitignore b/t/.gitignore
new file mode 100644
index 0000000..fad67c0
--- /dev/null
+++ b/t/.gitignore
@@ -0,0 +1 @@
+trash
^ permalink raw reply related
* Re: [PATCH] git-blame: Make the output human readable
From: Fredrik Kuivinen @ 2006-03-05 12:38 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Fredrik Kuivinen, git, Johannes Schindelin, Ryan Anderson
In-Reply-To: <7vbqwlgkhk.fsf@assigned-by-dhcp.cox.net>
On Sun, Mar 05, 2006 at 04:10:47AM -0800, Junio C Hamano wrote:
> Fredrik Kuivinen <freku045@student.liu.se> writes:
>
> > The default output mode is slightly different from git-annotate's.
> > However, git-annotate's output mode can be obtained by using the
> > '-c' flag.
>
> It might be better to default to human readable and make the
> script consumption format an option, if only to reduce typing.
>
The default output format is human readable, but it is different from
the output format used by git-annotate. By default, (when the patch is
applied) git-blame outputs lines with on the following form:
<eight first digits of commit SHA1> (<first 15 letters of committer's name> YYYY-MM-DD HH:MM:SS TZ <line number, right justified>) file contents
where as git-annotate uses
<eight first digits of commit SHA1>\t(<committer's name, right justified, padded to 10 characters> YYYY-MM-DD HH:MM:SS TZ\t<line number>)file contents
I find the first format easier to read since everything is aligned (we
always output 15 characters for the committer's name padded with
spaces if necessary and the line numbers are padded appropriately). It
also takes up less space on screen since it doesn't use tabs.
However, I wanted to use the tests for git-annotate to test git-blame
too and the tests do, of course, expect the output to be in
git-annotate's format. Hence, the '-c' switch.
We may want to add an output format suitable for scripts too, which
just lists the SHA1. But I don't think it is much more difficult to
parse the format above, at least not if you just want the SHA1s.
> > diff --git a/Makefile b/Makefile
> > index b6d8804..eb1887d 100644
> > --- a/Makefile
> > +++ b/Makefile
> > @@ -534,6 +534,10 @@ git-rev-list$X: rev-list.o $(LIB_FILE)
> > $(CC) $(ALL_CFLAGS) -o $@ $(ALL_LDFLAGS) $(filter %.o,$^) \
> > $(LIBS) $(OPENSSL_LIBSSL)
> >
> > +git-blame$X: blame.o $(LIB_FILE)
> > + $(CC) $(ALL_CFLAGS) -o $@ $(ALL_LDFLAGS) $(filter %.o,$^) \
> > + $(LIBS) -lm
> > +
>
> I wonder what it is about to link this binary different from others...
>
It uses log(3) to compute the number of digits needed to represent the
last line number. It is probably better to this some other way
though...
> > +char* format_time(unsigned long time, const char* tz)
> > +{
> > + static char time_buf[128];
> > + time_t t = time;
> > +
> > + strftime(time_buf, sizeof(time_buf), "%Y-%m-%d %H:%M:%S ", gmtime(&t));
> > + strcat(time_buf, tz);
> > + return time_buf;
> > +}
>
> I think this shows GMT with time offset, which is compatible
> with the human readable time Johannes did to git-annotate. I do
> not know what timezone CVS annotate shows its dates offhand (it
> seems to only show dates). Johannes, is this an attempt to
> match what CVS does?
>
> I am wondering if we want to be in line with the date formatting
> convention used for our commits and tags, that is, to show local
> timestamp with timezone. The code to use would be show_date()
> from date.c if we go that route.
>
I think it is a good idea. Consistency is good.
- Fredrik
^ permalink raw reply
* Re: [PATCH] git-blame: Make the output human readable
From: Johannes Schindelin @ 2006-03-05 14:11 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Fredrik Kuivinen, git, Ryan Anderson
In-Reply-To: <7vbqwlgkhk.fsf@assigned-by-dhcp.cox.net>
Hi,
On Sun, 5 Mar 2006, Junio C Hamano wrote:
> Fredrik Kuivinen <freku045@student.liu.se> writes:
>
> > +char* format_time(unsigned long time, const char* tz)
> > +{
> > + static char time_buf[128];
> > + time_t t = time;
> > +
> > + strftime(time_buf, sizeof(time_buf), "%Y-%m-%d %H:%M:%S ", gmtime(&t));
> > + strcat(time_buf, tz);
> > + return time_buf;
> > +}
>
> I think this shows GMT with time offset, which is compatible
> with the human readable time Johannes did to git-annotate. I do
> not know what timezone CVS annotate shows its dates offhand (it
> seems to only show dates). Johannes, is this an attempt to
> match what CVS does?
CVS only shows the date, something like
strftime("%Y-%b-%d", gmtime($timestamp));
> I am wondering if we want to be in line with the date formatting
> convention used for our commits and tags, that is, to show local
> timestamp with timezone. The code to use would be show_date()
> from date.c if we go that route.
I like that approach. Sometimes imitating CVS can be overdone.
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH] git-blame: Make the output human readable
From: Johannes Schindelin @ 2006-03-05 14:23 UTC (permalink / raw)
To: Fredrik Kuivinen; +Cc: Junio C Hamano, git
In-Reply-To: <20060305123800.GD23448@c165.ib.student.liu.se>
Hi,
On Sun, 5 Mar 2006, Fredrik Kuivinen wrote:
> On Sun, Mar 05, 2006 at 04:10:47AM -0800, Junio C Hamano wrote:
> > Fredrik Kuivinen <freku045@student.liu.se> writes:
> >
> > > +git-blame$X: blame.o $(LIB_FILE)
> > > + $(CC) $(ALL_CFLAGS) -o $@ $(ALL_LDFLAGS) $(filter %.o,$^) \
> > > + $(LIBS) -lm
> > > +
> >
> > I wonder what it is about to link this binary different from others...
> >
>
> It uses log(3) to compute the number of digits needed to represent the
> last line number. It is probably better to this some other way
> though...
How about this:
- max_digits = 1 + log(num_blame_lines+1)/log(10);
+ for (i = 10, max_digits = 1; i <= num_blame_lines + 1;
+ i *= 10, max_digits++);
(Totally untested)
Hth,
Dscho
^ permalink raw reply
* [PATCH] contrib/emacs/Makefile: Provide tool for byte-compiling files.
From: Mark Wooding @ 2006-03-05 16:14 UTC (permalink / raw)
To: git
From: Mark Wooding <mdw@distorted.org.uk>
Signed-off-by: Mark Wooding <mdw@distorted.org.uk>
---
contrib/emacs/.gitignore | 1 +
contrib/emacs/Makefile | 20 ++++++++++++++++++++
2 files changed, 21 insertions(+), 0 deletions(-)
diff --git a/contrib/emacs/.gitignore b/contrib/emacs/.gitignore
new file mode 100644
index 0000000..c531d98
--- /dev/null
+++ b/contrib/emacs/.gitignore
@@ -0,0 +1 @@
+*.elc
diff --git a/contrib/emacs/Makefile b/contrib/emacs/Makefile
new file mode 100644
index 0000000..d3619db
--- /dev/null
+++ b/contrib/emacs/Makefile
@@ -0,0 +1,20 @@
+## Build and install stuff
+
+EMACS = emacs
+
+ELC = git.elc vc-git.elc
+INSTALL = install
+INSTALL_ELC = $(INSTALL) -m 644
+prefix = $(HOME)
+emacsdir = $(prefix)/share/emacs/site-lisp
+
+all: $(ELC)
+
+install: all
+ $(INSTALL) -d $(emacsdir)
+ $(INSTALL_ELC) $(ELC) $(emacsdir)
+
+%.elc: %.el
+ $(EMACS) --batch --eval '(byte-compile-file "$<")'
+
+clean:; rm -f $(ELC)
^ permalink raw reply related
* [PATCH] gitk: Fix size saving for diff and file list panes
From: Sergey Vlasov @ 2006-03-05 17:09 UTC (permalink / raw)
To: Paul Mackerras; +Cc: git
Signed-off-by: Sergey Vlasov <vsu@altlinux.ru>
The splitter between diff and file list panes was moving to the left
after every restart of gitk.
---
This patch applies both to the stable and new gitk versions.
gitk | 4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
1e43530dc79f176507e5ad2fd57f4c9ba6cea46a
diff --git a/gitk b/gitk
index f4c6624..a5331f1 100755
--- a/gitk
+++ b/gitk
@@ -676,10 +676,10 @@ proc savestuff {w} {
puts $f "set geometry(canv2) [expr {[winfo width $canv2]-2}]"
puts $f "set geometry(canv3) [expr {[winfo width $canv3]-2}]"
puts $f "set geometry(canvh) [expr {[winfo height $canv]-2}]"
- set wid [expr {([winfo width $ctext] - 8) \
+ set wid [expr {([winfo width $ctext]) \
/ [font measure $textfont "0"]}]
puts $f "set geometry(ctextw) $wid"
- set wid [expr {([winfo width $cflist] - 11) \
+ set wid [expr {([winfo width $cflist]) \
/ [font measure [$cflist cget -font] "0"]}]
puts $f "set geometry(cflistw) $wid"
close $f
--
1.2.GIT
^ permalink raw reply related
* Re: What's in git.git
From: Linus Torvalds @ 2006-03-05 17:53 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vfylxigxc.fsf@assigned-by-dhcp.cox.net>
On Sat, 4 Mar 2006, Junio C Hamano wrote:
>
> At this point commit is revs->commits->item. It cannot be
> UNINTERESTING because you make it sure with !revs->limited and
> friends, but I wonder if it can be SHOWN already for some
> reason, in which case returning it is wrong.
>
> Unlike the earlier special case in rev-list, this special case
> kicks in for the last iteration of repeated calls to
> get_revision() (e.g. third iteration of "rev-list -3")...
Good point. Yes, it needs to check that it's not SHOWN. Might as well
check against interesting too. Maybe something like this instead?
Linus
---
diff --git a/revision.c b/revision.c
index a3df810..2a33637 100644
--- a/revision.c
+++ b/revision.c
@@ -684,13 +684,11 @@ static void rewrite_parents(struct commi
struct commit *get_revision(struct rev_info *revs)
{
struct commit_list *list = revs->commits;
- struct commit *commit;
if (!list)
return NULL;
/* Check the max_count ... */
- commit = list->item;
switch (revs->max_count) {
case -1:
break;
@@ -701,22 +699,28 @@ struct commit *get_revision(struct rev_i
}
do {
- commit = pop_most_recent_commit(&revs->commits, SEEN);
+ struct commit *commit = revs->commits->item;
+
if (commit->object.flags & (UNINTERESTING|SHOWN))
- continue;
+ goto next;
if (revs->min_age != -1 && (commit->date > revs->min_age))
- continue;
+ goto next;
if (revs->max_age != -1 && (commit->date < revs->max_age))
return NULL;
if (revs->no_merges && commit->parents && commit->parents->next)
- continue;
+ goto next;
if (revs->paths && revs->dense) {
if (!(commit->object.flags & TREECHANGE))
- continue;
+ goto next;
rewrite_parents(commit);
}
+ /* More to go? */
+ if (revs->max_count)
+ pop_most_recent_commit(&revs->commits, SEEN);
commit->object.flags |= SHOWN;
return commit;
+next:
+ pop_most_recent_commit(&revs->commits, SEEN);
} while (revs->commits);
return NULL;
}
^ permalink raw reply related
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