* Re: [PATCH 1/3] log_ref_write() -- do not chomp reflog message at the first LF
From: Junio C Hamano @ 2007-07-29 18:47 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Sean, Benoit SIGOURE, git
In-Reply-To: <Pine.LNX.4.64.0707291248560.14781@racer.site>
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> It is not like the reflog messages have to be very verbose; they only have
> to give a hint what the commit was about, and the commit name is the
> important information.
I've considered it, but decided against it because:
(1) I did not like the information lossage;
(2) this is solely to help log messages coming from outside the
recommended convention, and having excess will not hurt the
normal usage;
(3) it is not known if messages from outside the recommended
convention have enough information on its first line of the
first paragraph; the result of s/\n.*/.../ may not be
sufficient "hint";
(4) log output are by default piped to "less -S" so extra
output gives the user chance to inspect more if he chosses
to, without hurting the end user display; and
(5) the code was simpler and less error prone to go wrong.
^ permalink raw reply
* [PATCH] add option to find zlib in custom path
From: Robert Schiele @ 2007-07-29 18:35 UTC (permalink / raw)
To: git; +Cc: Junio C Hamano
Some systems do not provide zlib development headers and libraries in
default search path of the compiler. For these systems we should allow
specifying the location by --with-zlib=PATH or by setting ZLIB_PATH in
the makefile.
Signed-off-by: Robert Schiele <rschiele@gmail.com>
---
You can also fetch this patch as d669d5f17feb3b406862fd83b42998b2353da44f from
git://schiele.dyndns.org/git
Makefile | 8 +++++++-
configure.ac | 3 +++
2 files changed, 10 insertions(+), 1 deletions(-)
diff --git a/Makefile b/Makefile
index 73b487f..21bf5c7 100644
--- a/Makefile
+++ b/Makefile
@@ -372,7 +372,7 @@ BUILTIN_OBJS = \
builtin-pack-refs.o
GITLIBS = $(LIB_FILE) $(XDIFF_LIB)
-EXTLIBS = -lz
+EXTLIBS =
#
# Platform specific tweaks
@@ -517,6 +517,12 @@ ifndef NO_CURL
endif
endif
+ifdef ZLIB_PATH
+ BASIC_CFLAGS += -I$(ZLIB_PATH)/include
+ EXTLIBS += -L$(ZLIB_PATH)/lib $(CC_LD_DYNPATH)$(ZLIB_PATH)/lib
+endif
+EXTLIBS += -lz
+
ifndef NO_OPENSSL
OPENSSL_LIBSSL = -lssl
ifdef OPENSSLDIR
diff --git a/configure.ac b/configure.ac
index 50d2b85..b2f1965 100644
--- a/configure.ac
+++ b/configure.ac
@@ -75,6 +75,9 @@ GIT_ARG_SET_PATH(shell)
# Define PERL_PATH to provide path to Perl.
GIT_ARG_SET_PATH(perl)
#
+# Define ZLIB_PATH to provide path to zlib.
+GIT_ARG_SET_PATH(zlib)
+#
# Declare the with-tcltk/without-tcltk options.
AC_ARG_WITH(tcltk,
AS_HELP_STRING([--with-tcltk],[use Tcl/Tk GUI (default is YES)])
--
1.5.2.3
^ permalink raw reply related
* [git gui] Update to it.po pushed to the mob branch
From: Paolo Ciarrocchi @ 2007-07-29 18:26 UTC (permalink / raw)
To: Git Mailing List
I've just updated the Italian translation of git-gui
and pushed it into mob branch.
There is still some work to be done but thanks to the doc written by
Junio the workflow I'm now using is making me a lot more productive.
Ciao,
--
Paolo
^ permalink raw reply
* [PATCH] Add editor.c grouping functions for editing text files.
From: Carlos Rica @ 2007-07-29 18:21 UTC (permalink / raw)
To: git, Junio C Hamano, Kristian Høgsberg, Johannes Schindelin
The new file is grouping the previous function stripspace
from "builtin-stripspace.c", the previous launch_editor
from "builtin-tag.c", and a new function read_file, designed
to be also shared with the upcoming "builtin-commit.c".
Signed-off-by: Carlos Rica <jasampler@gmail.com>
---
This change is committed on top of the current "next".
It is the first proposal for the file editor.c with
some functions intended to be shared at least between the
recent "builtin-tag.c" and the upcoming "builtin-commit.c"
which Kristian is working on.
read_file is a reimplementation of the function read_path
which was helping to Kristian in his builtin-commit.c:
http://article.gmane.org/gmane.comp.version-control.git/52892
launch_editor now is just the same that "builtin-tag.c" was using,
but since it is currently different than the launch_editor from
"builtin-commit.c", it will need more changes which should be
discussed here. Every suggestion will be appreciated.
Makefile | 5 +-
builtin-stripspace.c | 71 ---------------------
builtin-tag.c | 47 +--------------
builtin.h | 1 -
editor.c | 165 ++++++++++++++++++++++++++++++++++++++++++++++++++
editor.h | 10 +++
6 files changed, 179 insertions(+), 120 deletions(-)
create mode 100644 editor.c
create mode 100644 editor.h
diff --git a/Makefile b/Makefile
index 98670bb..7417d95 100644
--- a/Makefile
+++ b/Makefile
@@ -284,7 +284,7 @@ LIB_H = \
run-command.h strbuf.h tag.h tree.h git-compat-util.h revision.h \
tree-walk.h log-tree.h dir.h path-list.h unpack-trees.h builtin.h \
utf8.h reflog-walk.h patch-ids.h attr.h decorate.h progress.h \
- mailmap.h remote.h
+ mailmap.h remote.h editor.h
DIFF_OBJS = \
diff.o diff-lib.o diffcore-break.o diffcore-order.o \
@@ -306,7 +306,8 @@ LIB_OBJS = \
write_or_die.o trace.o list-objects.o grep.o match-trees.o \
alloc.o merge-file.o path-list.o help.o unpack-trees.o $(DIFF_OBJS) \
color.o wt-status.o archive-zip.o archive-tar.o shallow.o utf8.o \
- convert.o attr.o decorate.o progress.o mailmap.o symlinks.o remote.o
+ convert.o attr.o decorate.o progress.o mailmap.o symlinks.o remote.o \
+ editor.o
BUILTIN_OBJS = \
builtin-add.o \
diff --git a/builtin-stripspace.c b/builtin-stripspace.c
index 916355c..7cb538a 100644
--- a/builtin-stripspace.c
+++ b/builtin-stripspace.c
@@ -1,77 +1,6 @@
#include "builtin.h"
#include "cache.h"
-/*
- * Returns the length of a line, without trailing spaces.
- *
- * If the line ends with newline, it will be removed too.
- */
-static size_t cleanup(char *line, size_t len)
-{
- if (len) {
- if (line[len - 1] == '\n')
- len--;
-
- while (len) {
- unsigned char c = line[len - 1];
- if (!isspace(c))
- break;
- len--;
- }
- }
- return len;
-}
-
-/*
- * Remove empty lines from the beginning and end
- * and also trailing spaces from every line.
- *
- * Note that the buffer will not be NUL-terminated.
- *
- * Turn multiple consecutive empty lines between paragraphs
- * into just one empty line.
- *
- * If the input has only empty lines and spaces,
- * no output will be produced.
- *
- * If last line has a newline at the end, it will be removed.
- *
- * Enable skip_comments to skip every line starting with "#".
- */
-size_t stripspace(char *buffer, size_t length, int skip_comments)
-{
- int empties = -1;
- size_t i, j, len, newlen;
- char *eol;
-
- for (i = j = 0; i < length; i += len, j += newlen) {
- eol = memchr(buffer + i, '\n', length - i);
- len = eol ? eol - (buffer + i) + 1 : length - i;
-
- if (skip_comments && len && buffer[i] == '#') {
- newlen = 0;
- continue;
- }
- newlen = cleanup(buffer + i, len);
-
- /* Not just an empty line? */
- if (newlen) {
- if (empties != -1)
- buffer[j++] = '\n';
- if (empties > 0)
- buffer[j++] = '\n';
- empties = 0;
- memmove(buffer + j, buffer + i, newlen);
- continue;
- }
- if (empties < 0)
- continue;
- empties++;
- }
-
- return j;
-}
-
int cmd_stripspace(int argc, const char **argv, const char *prefix)
{
char *buffer;
diff --git a/builtin-tag.c b/builtin-tag.c
index d6d38ad..4957d56 100644
--- a/builtin-tag.c
+++ b/builtin-tag.c
@@ -11,58 +11,13 @@
#include "refs.h"
#include "tag.h"
#include "run-command.h"
+#include "editor.h"
static const char builtin_tag_usage[] =
"git-tag [-n [<num>]] -l [<pattern>] | [-a | -s | -u <key-id>] [-f | -d | -v] [-m <msg> | -F <file>] <tagname> [<head>]";
static char signingkey[1000];
-static void launch_editor(const char *path, char **buffer, unsigned long *len)
-{
- const char *editor, *terminal;
- struct child_process child;
- const char *args[3];
- int fd;
-
- editor = getenv("GIT_EDITOR");
- if (!editor && editor_program)
- editor = editor_program;
- if (!editor)
- editor = getenv("VISUAL");
- if (!editor)
- editor = getenv("EDITOR");
-
- terminal = getenv("TERM");
- if (!editor && (!terminal || !strcmp(terminal, "dumb"))) {
- fprintf(stderr,
- "Terminal is dumb but no VISUAL nor EDITOR defined.\n"
- "Please supply the message using either -m or -F option.\n");
- exit(1);
- }
-
- if (!editor)
- editor = "vi";
-
- memset(&child, 0, sizeof(child));
- child.argv = args;
- args[0] = editor;
- args[1] = path;
- args[2] = NULL;
-
- if (run_command(&child))
- die("There was a problem with the editor %s.", editor);
-
- fd = open(path, O_RDONLY);
- if (fd < 0)
- die("could not open '%s': %s", path, strerror(errno));
- if (read_fd(fd, buffer, len)) {
- free(*buffer);
- die("could not read message file '%s': %s",
- path, strerror(errno));
- }
- close(fd);
-}
-
struct tag_filter {
const char *pattern;
int lines;
diff --git a/builtin.h b/builtin.h
index bb72000..91bc595 100644
--- a/builtin.h
+++ b/builtin.h
@@ -7,7 +7,6 @@ extern const char git_version_string[];
extern const char git_usage_string[];
extern void help_unknown_cmd(const char *cmd);
-extern size_t stripspace(char *buffer, size_t length, int skip_comments);
extern int write_tree(unsigned char *sha1, int missing_ok, const char *prefix);
extern void prune_packed_objects(int);
diff --git a/editor.c b/editor.c
new file mode 100644
index 0000000..f0c3dc6
--- /dev/null
+++ b/editor.c
@@ -0,0 +1,165 @@
+/*
+ * Utility functions for reading and editing text files.
+ *
+ * Copyright (c) 2007 Carlos Rica <jasampler@gmail.com>
+ */
+
+#include "cache.h"
+#include "run-command.h"
+#include "editor.h"
+
+void launch_editor(const char *path, char **buffer, unsigned long *len)
+{
+ const char *editor, *terminal;
+ struct child_process child;
+ const char *args[3];
+ int fd;
+
+ editor = getenv("GIT_EDITOR");
+ if (!editor && editor_program)
+ editor = editor_program;
+ if (!editor)
+ editor = getenv("VISUAL");
+ if (!editor)
+ editor = getenv("EDITOR");
+
+ terminal = getenv("TERM");
+ if (!editor && (!terminal || !strcmp(terminal, "dumb"))) {
+ fprintf(stderr,
+ "Terminal is dumb but no VISUAL nor EDITOR defined.\n"
+ "Please supply the message using either -m or -F option.\n");
+ exit(1);
+ }
+
+ if (!editor)
+ editor = "vi";
+
+ memset(&child, 0, sizeof(child));
+ child.argv = args;
+ args[0] = editor;
+ args[1] = path;
+ args[2] = NULL;
+
+ if (run_command(&child))
+ die("There was a problem with the editor %s.", editor);
+
+ fd = open(path, O_RDONLY);
+ if (fd < 0)
+ die("could not open '%s': %s", path, strerror(errno));
+ if (read_fd(fd, buffer, len)) {
+ free(*buffer);
+ die("could not read message file '%s': %s",
+ path, strerror(errno));
+ }
+ close(fd);
+}
+
+/*
+ * reads a file into memory, allocating a buffer to hold it and then
+ * returning it in *return_buf and setting also *return_size to save
+ * the size of its contents. Note that both variables are overwritten.
+ *
+ * If the path is "-" and the flag ALLOW_STDIN is enabled,
+ * then standard input is used to read the data.
+ * Currently, no other flags are defined.
+ *
+ * In case of failure, when -1 is returned, the allocated buffer is freed,
+ * otherwise the buffer must be freed by the caller.
+ */
+int read_file(const char *path, int flags,
+ char** return_buf, unsigned long* return_size)
+{
+ int fd;
+
+ if (flags & ALLOW_STDIN && path[0] == '-' && path[1] == '\0')
+ fd = 0;
+ else {
+ fd = open(path, O_RDONLY);
+ if (fd < 0)
+ return -1;
+ }
+
+ *return_size = 4096;
+ *return_buf = xmalloc(*return_size);
+ if (read_fd(fd, return_buf, return_size)) {
+ free(*return_buf);
+ if (fd)
+ close(fd);
+ return -1;
+ }
+ if (fd)
+ close(fd);
+
+ return 0;
+}
+
+/*
+ * Returns the length of a line, without trailing spaces.
+ *
+ * If the line ends with newline, it will be removed too.
+ */
+static size_t cleanup(char *line, size_t len)
+{
+ if (len) {
+ if (line[len - 1] == '\n')
+ len--;
+
+ while (len) {
+ unsigned char c = line[len - 1];
+ if (!isspace(c))
+ break;
+ len--;
+ }
+ }
+ return len;
+}
+
+/*
+ * Remove empty lines from the beginning and end
+ * and also trailing spaces from every line.
+ *
+ * Note that the buffer will not be NUL-terminated.
+ *
+ * Turn multiple consecutive empty lines between paragraphs
+ * into just one empty line.
+ *
+ * If the input has only empty lines and spaces,
+ * no output will be produced.
+ *
+ * If last line has a newline at the end, it will be removed.
+ *
+ * Enable skip_comments to skip every line starting with "#".
+ */
+size_t stripspace(char *buffer, size_t length, int skip_comments)
+{
+ int empties = -1;
+ size_t i, j, len, newlen;
+ char *eol;
+
+ for (i = j = 0; i < length; i += len, j += newlen) {
+ eol = memchr(buffer + i, '\n', length - i);
+ len = eol ? eol - (buffer + i) + 1 : length - i;
+
+ if (skip_comments && len && buffer[i] == '#') {
+ newlen = 0;
+ continue;
+ }
+ newlen = cleanup(buffer + i, len);
+
+ /* Not just an empty line? */
+ if (newlen) {
+ if (empties != -1)
+ buffer[j++] = '\n';
+ if (empties > 0)
+ buffer[j++] = '\n';
+ empties = 0;
+ memmove(buffer + j, buffer + i, newlen);
+ continue;
+ }
+ if (empties < 0)
+ continue;
+ empties++;
+ }
+
+ return j;
+}
diff --git a/editor.h b/editor.h
new file mode 100644
index 0000000..1d3e771
--- /dev/null
+++ b/editor.h
@@ -0,0 +1,10 @@
+#ifndef EDITOR_H
+#define EDITOR_H
+
+void launch_editor(const char *path, char **buffer, unsigned long *len);
+#define ALLOW_STDIN 0x01
+int read_file(const char *path, int flags,
+ char** return_buf, unsigned long* return_size);
+size_t stripspace(char *buffer, size_t length, int skip_comments);
+
+#endif
--
1.5.0
^ permalink raw reply related
* merge time
From: Matthew L Foster @ 2007-07-29 17:33 UTC (permalink / raw)
To: git; +Cc: mfoster167
Sorry to bring up the time issue again [that I am perhaps still confused about] but I have been
playing around with git more and I think I can phrase my question/observation better.
>From viewing gitweb.cgi I have observed a situation where Linus creates a tag, say rc1, and then
he later merges changes but some subset of those changes/commits show up in the list in time order
as taking place _before_ the rc1 tag was made even though they were merged after. Do I describe a
real or possible phenomenon? And does this happen because the developer that made the subset of
changes in question commit them to his/her local repository in time order before the rc1 tag was
made? So an external repository had the change before the rc1 tag was made but Linus' repository
didn't? But internally git on Linus' machine knows that the gitweb.cgi displayed time order is
wrong as far as the state is concerned because each repository's index file keeps local track of
the true local state [just time isn't reconcilable], or am I missing something(s)?
Is it possible for gitweb.cgi to have a new view mode that sorts/displays the list based on merge
time for commits (the time merged into Linus' or whatever repository) so the above situation
doesn't happen? The actual time of a local commit should be the time it was merged locally not the
time it was created externally/originally, right? Where can I find the gitweb.cgi source/package?
I could maybe hack gitweb.cgi myself.
Please CC me on any replies since I am not subscribed to the list.
-Matt
____________________________________________________________________________________
Get the Yahoo! toolbar and be alerted to new email wherever you're surfing.
http://new.toolbar.yahoo.com/toolbar/features/mail/index.php
^ permalink raw reply
* Re: Submit/Workflow question
From: Jason Sewall @ 2007-07-29 17:21 UTC (permalink / raw)
To: David Kastrup; +Cc: git, bfields
In-Reply-To: <85abtfw6d5.fsf@lola.goethe.zz>
On 7/29/07, David Kastrup <dak@gnu.org> wrote:
>
> Suppose that I have created a half-baked patch A suiting my personal
> needs and went on from there, having something like
>
> ...->A->B->...
>
> Now at some point of time I decide that really A should be made fit
> for submission.
What I do in this sort of situation varies on how good I was about
keeping A and B "independent"; first of all, let's assume you're not
on 'master', you're on 'some-feature' (and if you weren't, it's easy
to make it a branch, tho you might have to rebase the branch to the
point on master where the patch is meaningful to others, and
optionally rewind master to keep it clean)
some-feature: A->B->...
/
master: ->W->X->Y->Z
If I really want to edit *just* A and not use any of B at all, then
the excellent rebase -i would do the job - you may want to rebase to
Z, or if A weren't the first commit exclusive to your branch, you
could rebase to whatever that is...
The point is that rebase -i will let you say "edit just A, just apply
B afterwards" and it will rewrite history for you after you fix A, and
then it will try to apply B on top of A, and so on until you're done.
Sometimes, rebase -i doesn't cut it for me, (because I didn't make my
commits cleanly separated, or perhaps because I haven't totally
explored rebase) - then I do it the "old-fashioned way" which it the
way this was usually done before rebase -i. I make a temporary branch
off of master called (apply-some-feature) and I start generating diffs
between this new branch and some-feature. A apply them, sometimes
reaching across commits and so forth, and commit the changes in nice,
clean format. When I'm done, *I* usually merge these onto master (if
its my own project) but if you were going to make it into a patch, I
would probably just replace some-feature with apply-some-feature.
It's probably pretty self-evident, but (git) diff (and some sort of
visual patch-applier) is pretty powerful and you can generate very
"narrow" diffs to look at just the parts you want to for a given step
in this process. And of course, you can use to to make sure that at
the end, apply-some-feature and some-feature's HEADS have the same
tree (or not, if you chose to omit some debugging stuff as I often
do).
By the way, the way Bruce suggested was fine too, I just though I'd
share what I do in this sort of situation (and I do it often because I
always forget to make my commits clean the first time)
Jason
^ permalink raw reply
* Re: [RFC] Git User's Survey 2007
From: Paolo Ciarrocchi @ 2007-07-29 17:05 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git
In-Reply-To: <4d8e3fd30707290950lce19ef4g103cbb7ad1abbe23@mail.gmail.com>
On 7/29/07, Paolo Ciarrocchi <paolo.ciarrocchi@gmail.com> wrote:
[...]
> > 1. How did you hear about GIT?
> > 2. Did you find GIT easy to learn?
> > - very easy/easy/reasonably/hard/very hard
A comment that applies to a lot of the suggested answers that I've got
from private email when I was working on the first survey:
I used to do phone surveys. It often helps for people to qualify how
much they like something..
eg. on a scale of 0 to 10 where 1 use bad and 10 is excellent
or.. I dont mind, I like. I prefer. etc.
or on a scale of 1 to 5 etc. prefer not an number dividable by 2.
I think that was a really good suggestion.
Regards,
Paolo
^ permalink raw reply
* Re: [PATCH] Documentation/git-diff: remove -r from --name-status example
From: Linus Torvalds @ 2007-07-29 16:51 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Jeff King, git, Jakub Narebski, Jon Smirl
In-Reply-To: <7vbqdvolww.fsf@assigned-by-dhcp.cox.net>
On Sat, 28 Jul 2007, Junio C Hamano wrote:
>
> However, I think Jeff's patch always makes it recursive even
> when the user asks for --raw, which makes it inappropriate for
> inclusion whether before or after 1.5.3.
Well, that was kind of the point. Yes, it makrs it recursive even for
--raw, but the fact is, "git diff" is _always_ recursive (even for --raw)
for most common usage: anything that involves the index.
So "git diff" is fundamentally different from "git log" and "git show" and
friends. "git diff" can work on the files and index, which "git log" and
"git show" never do.
Linus
^ permalink raw reply
* Re: [RFC] Git User's Survey 2007
From: Paolo Ciarrocchi @ 2007-07-29 16:50 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git
In-Reply-To: <200707271320.06313.jnareb@gmail.com>
On 7/27/07, Jakub Narebski <jnareb@gmail.com> wrote:
> It's been more than a year since last Git User's Survey. It would be
> interesting to find what changed since then. Therefore the idea to
> have another survey.
Hi Jakub,
sorry for the late answer, I've been away from my PC having fun on a
beach for a few days.
I'm now back home, I have my Menabrea beer with me so I can try to
provide some useful comments :-)
> First there is a question about the form of survey. Should we use web
> based survey, as the survey before (http://www.survey.net.nz), sending
> emails with link to this survey, or perhaps do email based survey,
> with email Reply-To: address put for this survey alone?
I vote for the survey.net.nz approach. I think that from a user
prospective that's the right thing to do, we can have "multiple choice
questions" and avoid some of the more common mistakes.
> Second, what questions should be put in the survey, and in the case of
> single choice and ultiple choice questions what possible answers
> should be? Below are slightly extended questions from the last
> survey. Please comment on it.
>
> Third, where to send survey to? I was thinking about git mailing list,
> LKML, and mailing list for git projects found on GitProjects page on
> GIT wiki. Do you want to add some address? Or should info about GIT
> User's Survey 2007 be sent also to one of on-line magazines like
> LinuxToday, or asked to put on some blog?
I think that one of the mistakes I did when I sent out the first
survey was to not contact any magazines and blog.
> References:
> http://marc.info/?l=git&m=115116592330648&w=2
> http://marc.info/?l=git&m=115364303813936&w=2
> http://git.or.cz/gitwiki/GitSurvey
>
> ----
> About you
>
> 1. What country are you in?
I know that lot of people will disagree with me but from a pure
statistical prospective I'd like to add a couple of questions about
gender and age.
I understand very well that these questions will not be useful for
making git any better but it will be interesting to have a better
picture abut the git customer base.
> 2. What is your preferred non-programming language?
> 3. Which programming languages you are proficient with?
> (zero or more: multiple choice)
> - C, shell, Perl, Python, Tcl/Tk
>
> Getting started with GIT
>
> 1. How did you hear about GIT?
> 2. Did you find GIT easy to learn?
> - very easy/easy/reasonably/hard/very hard
> 3. What helped you most in learning to use it?
> 4. What did you find hardest?
> 5. When did you start using git? From which version?
>
> How you use GIT
>
> 1. Do you use GIT for work, unpaid projects, or both?
> work/unpaid projects/work
> 2. How do you obtain GIT? Source tarball, binary package, or
> pull the main repository?
> - binary package/source tarball/pull from main repository
> 3. What hardware platforms do you use GIT on?
> * examples: i386, x86_64, ARM, PowerPC, Alpha, g5, ...
> 4. What OS (please include the version) do you use GIT on?
> * examples: Linux, MS Windows (Cygwin/MinGW/gitbox),
> IRIX, HP-UX, Solaris, FreeBSD, ...
> (please give kernel version and distribution for Linux)
> 5. How many people do you collaborate with using GIT?
> 6. How big are the repositories that you work on? (e.g. how many
> files, how much disk space, how deep is the history?)
> * number of files in repository: "git ls-tree -r HEAD | wc -l"
> * pack size of freshly cloned fully packed repository
> * number of commits in straight line, number of commits in branch
> ("git rev-list --first-parent HEAD | wc -l",
> "git rev-list HEAD | wc -l")
> 7. How many different projects do you manage using GIT?
> 8. Which porcelains do you use?
> (zero or more: multiple choice)
> - core-git, cogito, StGIT, pg, guilt, other
git-gui ?
> 9. Which git GUI do you use
> (zero or more: multiple choice)
> - gitk, git-gui, qgit, gitview, giggle, other
> 10. Which git web interface do you use for your projects?
> - gitweb/cgit/wit (Ruby)/git-php/other
> 11. How do you publish/propagate your changes?
> (zero or more: multiple choice)
> - push, pull request, format-patch + email, bundle, other
> 12. Does git.git repository include code produced by you?
> - yes/no
>
> Internationalization
> 1. Is translating GIT required for wider adoption?
> - yes/no/somewhat
> 2. What do you need translated?
> (zero or more: multiple choice)
> - GUI (git-gui, gitk, qgit, ...), git-core messages,
> manpages, other documentation
> 3. For what language do you need translation for?
>
> What you think of GIT
>
> 1. Overall, how happy are you with GIT?
> - unhappy/not so happy/happy/very happy/completely extatic
> 2. How does GIT compare to other SCM tools you have used?
> - worse/equal (or comparable)/better
> 3. What do you like about using GIT?
> 4. What would you most like to see improved about GIT?
> (features, bugs, plugins, documentation, ...)
> 5. If you want to see GIT more widely used, what do you
> think we could do to make this happen?
>
> Documentation
>
> 1. Do you use the GIT wiki?
> - yes/no
> 2. Do you find GIT wiki useful?
> - yes/no/somewhat
> 3. Do you contribute to GIT wiki?
> - yes/no/only corrections or spam removal
> 4. Do you find GIT's online help (homepage, documentation) useful?
> - yes/no/somewhat
> 5. Do you find help distributed with GIT useful
> (manpages, manual, tutorial, HOWTO, release notes)?
> - yes/no/somewhat
> 6. Do you contribute to GIT documentation?
> - yes/no
> 7. What is your favourite user documentation for any software
> projects or products you have used?
> 8. What could be improved on the GIT homepage?
>
> Getting help, staying in touch
>
> 1. Have you tried to get GIT help from other people?
> - yes/no
> 2. If yes, did you get these problems resolved quickly
> and to your liking?
> - yes/no
> 3. Do you subscribe to the mailing list?
> - yes/no
> 4. Do you read the mailing list? What method do you use?
> - subscribed/news interface/RSS interface/archives/
> /post + reply-to request/digests/I don't read it
> 5. If yes, do you find it useful?
> - yes/no (optional)
> 6. Do you find traffic levels on GIT mailing list OK.
> - yes/no? (optional)
> 7. Do you use the IRC channel (#git on irc.freenode.net)?
> - yes/no
> 8. If yes, do you find IRC channel useful?
> - yes/no (optional)
>
> Open forum
>
> 1. What other comments or suggestions do you have that are not
> covered by the questions above?
How about adding a question about whether the user migrated from a
different SCM?
If so, from which SCM and why?
Regards,
--
Paolo
^ permalink raw reply
* Re: What's in git.git (stable)
From: Theodore Tso @ 2007-07-29 16:40 UTC (permalink / raw)
To: David Kastrup; +Cc: git
In-Reply-To: <85ir83zijd.fsf@lola.goethe.zz>
On Sun, Jul 29, 2007 at 11:05:42AM +0200, David Kastrup wrote:
> Theodore Tso <tytso@mit.edu> writes:
>
> > So I really am beginning to think the right answer is to give up on
> > using git-mergetool to support anything other than basic emacs users
> > (who just use emacs as an editor, what a concept),
>
> In contrast, you are trying to support only people by using Emacs
> _not_ as an editor, but as a mergetool under the control of git.
> That's a mistake.
The whole *point* of git-mergetool is to automatically call merge
tools so you can do three-way merges under the control of git.
If you just want an *editor* then you can just edit the files that are
listed as being in conflict after a failed merge or after running "git
status". You can do that today without using git-mergetool at all!
> Sorry, but you are way off here. The normal, standard use of Emacs is
> to start it once and do everything in it. Its startup time is such
> that other uses are not feasible.
Huh? The startup time of running emacs for me is well under a second
(and I have a 20k ~/.emacs.el file that loads a number of other
files). I'm sure if you put enough *crap* into your .emacs.el file,
you can make it take a huge amount of time, but I suspect your idea of
what is "normal" for emacs is more than a little skewed.
> So git's mergetool philosophy is currently _straight_ set against the
> way Emacs is designed to work.
So don't use git-mergetool. Like I said, I suspect the right answer
is contrib/git-mergetool.el, and do everything inside emacs. If you
are as extreme as someone who pulls in gazillions of emacs packages,
and you are using emacs as a desktop, a shell, and a window manager,
then you can probably do much better using a pure emacs lisp merge
system.
Git mergetool is fundamentally designed to work with tools like meld,
kdiff3, xxdiff, tkdiff, etc. These are all merge tools, and they work
a certain way. They expect, and need, to be driven a certain way. If
you insist on following a fundamentally different paradigm, then past
a certain point git-mergetool is not going to make you happy no matter
what I can do. The point is, git-mergetool does *need* to do know
when you are done doing a merge, and it needs to know if you've
decided to abandon a merge. Right now ediff doesn't fit well into
that paradigm. And that's fundamentally ediff's fault; we can do some
kludgery on the git-mergetool side, but the end result will always be
unsatisfactory, and will require that the person using it to *know*
that it is done.
I, personally, don't feel like trying to twist git-mergetool into
doing the right thing depending on whether you have emacs21, emacs22,
emacs23-snapshot, whether or not the desktop package is in use,
whether or not the user is using emacsclient or not, yadda, yadda,
yaddda. If you want to take a crack at doing *all* of that mess, and
provide a complete solution, send me patches and I'll look at them.
I think it will add a huge amount of *crap* into git-mergetool in
order to support all possible use cases (I'm not interesting in
putting in hackery just for your favorite use case, if it causes other
users to scratch their heads in befuddlement and confusion), but feel
free to prove me wrong.
As someone who has used emacs for over two decades, and have written
very sophisticated emacs lisp code during nearly all of those 21 years
(1986--2007; my first use of emacs was on a Vax 750 running BSD 4.3
--- if you want to talk about emacs taking a long time to start up, I
remember what it was like 20 years ago), I'm pretty well aware of what
you can and can not do in emacs, and I think I can say with fairly
good authority that for the amount of effort it would take to try to
get git-mergetool to hack around all of these different cases, writing
git-mergetool.el will probably be easier, and result in a cleaner,
better integration with people who like to live their entire lives in
a single emacs session.
- Ted
^ permalink raw reply
* Re: Gitweb and submodules
From: Sven Verdoolaege @ 2007-07-29 16:37 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git
In-Reply-To: <200707282239.29340.jnareb@gmail.com>
On Sat, Jul 28, 2007 at 10:39:28PM +0200, Jakub Narebski wrote:
> On Sat, 28 July 2007, Sven Verdoolaege wrote:
> > On Sat, Jul 28, 2007 at 12:29:16PM +0200, Jakub Narebski wrote:
> >> It has to be configuration variable because the
> >> location of repository which has submodule objects doesn't change when
> >> checking out (or rewinding) to different commit in supermodule.
> >
> > Let's hope Pasky provides a way to set this information...
>
> Why Pasky?
I was thinking about projects on repo.or.cz.
We'd want to have a way to specify the locations of submodules.
> I am thinking about the following sequence to search for submodule
> objects:
>
> From $GIT_DIR/config:
> submodule.$name.objects (absolute or relative to gitdir of superproject)
> submodule.$name.gitdir (absolute or relative to gitdir of superproject)
Do we really need both of these?
> submodule.$name.url (to find GIT_DIR, if it is local filesystem URL)
>
> If there is working directory, from .gitmodules file in top level
> of working directory:
> submodule.$name.path/.git (relative to toplevel of working directory)
Having a relative path for the URL in .gitmodules in a public repo
doesn't seem very useful to me. I know it's only meant as a default
value, but if it is a relative path, then it won't work for
anyone cloning the superproject.
skimo
^ permalink raw reply
* Re: Submit/Workflow question
From: David Kastrup @ 2007-07-29 16:06 UTC (permalink / raw)
To: J. Bruce Fields; +Cc: git
In-Reply-To: <20070729160347.GA26637@fieldses.org>
"J. Bruce Fields" <bfields@fieldses.org> writes:
> On Sun, Jul 29, 2007 at 05:56:54PM +0200, David Kastrup wrote:
>>
>> Suppose that I have created a half-baked patch A suiting my personal
>> needs and went on from there, having something like
>
> I'm not completely sure I follow that sequence, but something like that
> should work. A similar approach:
>
> http://www.kernel.org/pub/software/scm/git/docs/user-manual.html#modifying-one-commit
>
> I do something pretty close to what's described there, except I
> generally just cut and paste SHA1's instead of making the temporary tag.
Thanks.
--
David Kastrup, Kriemhildstr. 15, 44793 Bochum
^ permalink raw reply
* Re: Submit/Workflow question
From: David Kastrup @ 2007-07-29 16:03 UTC (permalink / raw)
To: git
In-Reply-To: <85abtfw6d5.fsf@lola.goethe.zz>
David Kastrup <dak@gnu.org> writes:
> Suppose that I have created a half-baked patch A suiting my personal
> needs and went on from there, having something like
>
> ...->A->B->...
>
> Now at some point of time I decide that really A should be made fit
> for submission. Basically, I'd want to do
> git-reset --hard A
> [edit some]
> git-commit --amend -a
> git-format-patch HEAD~1
>
> in order to arrive at a nice submittable patch. However, I don't want
> to lose B and the following stuff, and the resulting HEAD should
> include the improved of A (it is fine if that needs additional steps,
> and it is fine if it is just HEAD that gets the fixed version, not B).
>
> So how to do this? Branch at A^, rebase on A, fix the stuff, commit
> with --amend -a, rebase on master, rename the temporary branch to
> master (killing the old master), format and submit the patch?
>
> Or is there some bad thinko in there? Or is this too complicated?
Uh, too many rebases.
I mean:
Branch at A^, merge A, fix the stuff, commit with --amend -a, merge
master, rename the temporary branch to master (killing the old
master), format and submit the patch?
--
David Kastrup, Kriemhildstr. 15, 44793 Bochum
^ permalink raw reply
* Re: Submit/Workflow question
From: J. Bruce Fields @ 2007-07-29 16:03 UTC (permalink / raw)
To: David Kastrup; +Cc: git
In-Reply-To: <85abtfw6d5.fsf@lola.goethe.zz>
On Sun, Jul 29, 2007 at 05:56:54PM +0200, David Kastrup wrote:
>
> Suppose that I have created a half-baked patch A suiting my personal
> needs and went on from there, having something like
>
> ...->A->B->...
>
> Now at some point of time I decide that really A should be made fit
> for submission. Basically, I'd want to do
> git-reset --hard A
> [edit some]
> git-commit --amend -a
> git-format-patch HEAD~1
>
> in order to arrive at a nice submittable patch. However, I don't want
> to lose B and the following stuff, and the resulting HEAD should
> include the improved of A (it is fine if that needs additional steps,
> and it is fine if it is just HEAD that gets the fixed version, not B).
>
> So how to do this? Branch at A^, rebase on A,
Just branch on A. Or actually I just check out A at this point (leaving
me not on any branch).
> fix the stuff, commit
> with --amend -a, rebase on master, rename the temporary branch to
> master (killing the old master), format and submit the patch?
I'm not completely sure I follow that sequence, but something like that
should work. A similar approach:
http://www.kernel.org/pub/software/scm/git/docs/user-manual.html#modifying-one-commit
I do something pretty close to what's described there, except I
generally just cut and paste SHA1's instead of making the temporary tag.
--b.
^ permalink raw reply
* Submit/Workflow question
From: David Kastrup @ 2007-07-29 15:56 UTC (permalink / raw)
To: git
Suppose that I have created a half-baked patch A suiting my personal
needs and went on from there, having something like
...->A->B->...
Now at some point of time I decide that really A should be made fit
for submission. Basically, I'd want to do
git-reset --hard A
[edit some]
git-commit --amend -a
git-format-patch HEAD~1
in order to arrive at a nice submittable patch. However, I don't want
to lose B and the following stuff, and the resulting HEAD should
include the improved of A (it is fine if that needs additional steps,
and it is fine if it is just HEAD that gets the fixed version, not B).
So how to do this? Branch at A^, rebase on A, fix the stuff, commit
with --amend -a, rebase on master, rename the temporary branch to
master (killing the old master), format and submit the patch?
Or is there some bad thinko in there? Or is this too complicated?
--
David Kastrup, Kriemhildstr. 15, 44793 Bochum
^ permalink raw reply
* Re: [PATCH 3/8] Clean up work-tree handling
From: Johannes Schindelin @ 2007-07-29 15:53 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, matled
In-Reply-To: <7vlkd1umwf.fsf@assigned-by-dhcp.cox.net>
Hi,
I still have a problem with what should happen if both "core.bare == true"
and "core.worktree = /some/where/over/the/rainbow". Should it be bare, or
should it have a working tree?
So here is what I plan to support so far:
--work-tree= overrides GIT_WORK_TREE, which overrides core.worktree, which
overrides core.bare, which overrides GIT_DIR/.. when GIT_DIR ends in
/.git, which overrides the directory in which .git/ was found.
Does that look okay?
Ciao,
Dscho
^ permalink raw reply
* [Untested! proposal] git-mergetool.sh: introduce ediff option
From: David Kastrup @ 2007-07-29 13:51 UTC (permalink / raw)
To: git; +Cc: Theodore Tso
In-Reply-To: <Pine.LNX.4.64.0707291224460.14781@racer.site>
This is not yet tested (still have to do that): it's a base for
discussion and something which I think reasonable. It does not touch
the old behavior of "emerge" apart from calling Emacs with option -q
foregoing user-specific initializations, and preselects "ediff" only
where EDITOR/VISUAL suggest Emacs being used as a normal editor.
Here goes:
Most actual Emacs users prefer ediff to emerge concerning the
consolidation of versions. In general, people habitually using Emacs
will have this preference reflected in the EDITOR/VISUAL environment
variables.
If such a preference can be found there, ediff will be used/offered in
preference of emerge (which retains its previous behavior).
In ediff mode, success or failure of the merge will be discerned by
Emacs either having written or not written the merge buffer; no
attempt of interpreting the exit code is made.
This is much closer to the working habits of Emacs users than the
emerge behavior which uses Emacs as a one-shot session editor.
In order to bypass things like desktop files being loaded, emerge mode
now passes the "-q" option to Emacs. This will make it work in more
situations likely to occur, at the price of excluding possibly
harmless user customizations with the rest.
---
git-mergetool.sh | 50 ++++++++++++++++++++++++++++++++++++--------------
1 files changed, 36 insertions(+), 14 deletions(-)
diff --git a/git-mergetool.sh b/git-mergetool.sh
index 47a8055..8ed3ed4 100755
--- a/git-mergetool.sh
+++ b/git-mergetool.sh
@@ -251,13 +251,27 @@ merge_file () {
;;
emerge)
if base_present ; then
- emacs -f emerge-files-with-ancestor-command "$LOCAL" "$REMOTE" "$BASE" "$path"
+ emacs -q -f emerge-files-with-ancestor-command "$LOCAL" "$REMOTE" "$BASE" "$path"
else
- emacs -f emerge-files-command "$LOCAL" "$REMOTE" "$path"
+ emacs -q -f emerge-files-command "$LOCAL" "$REMOTE" "$path"
fi
status=$?
save_backup
;;
+ ediff)
+ case "${EDITOR:-${VISUAL:-emacs}}" in
+ */emacs*|*/gnuclient*|*/xemacs*)
+ emacs_candidate="${EDITOR:-${VISUAL:-emacs}}";;
+ *)
+ emacs_candidate=emacs;;
+ esac
+ if base_present ; then
+ ${emacs_candidate} --eval "(ediff-merge-files-with-ancestor (pop command-line-args-left) (pop command-line-args-left) (pop command-line-args-left) nil (pop-command-line-args-left))" "$LOCAL" "$REMOTE" "$BASE" "$path"
+ else
+ ${emacs_candidate} --eval "(ediff-merge-files (pop command-line-args-left) (pop command-line-args-left) nil (pop-command-line-args-left))" "$LOCAL" "$REMOTE" "$path"
+ fi
+ check_unchanged
+ save_backup
esac
if test "$status" -ne 0; then
echo "merge of $path failed" 1>&2
@@ -299,7 +313,7 @@ done
if test -z "$merge_tool"; then
merge_tool=`git config merge.tool`
case "$merge_tool" in
- kdiff3 | tkdiff | xxdiff | meld | opendiff | emerge | vimdiff | gvimdiff | "")
+ kdiff3 | tkdiff | xxdiff | meld | opendiff | emerge | ediff | vimdiff | gvimdiff | "")
;; # happy
*)
echo >&2 "git config option merge.tool set to unknown tool: $merge_tool"
@@ -319,23 +333,26 @@ if test -z "$merge_tool" ; then
merge_tool_candidates="kdiff3 $merge_tool_candidates"
fi
fi
- if echo "${VISUAL:-$EDITOR}" | grep 'emacs' > /dev/null 2>&1; then
- merge_tool_candidates="$merge_tool_candidates emerge"
- fi
+ case "${EDITOR:-${VISUAL}}" in
+ */emacs*|*/gnuclient*|*/xemacs*)
+ merge_tool_candidates="$merge_tool_candidates ediff"
+ esac
if echo "${VISUAL:-$EDITOR}" | grep 'vim' > /dev/null 2>&1; then
merge_tool_candidates="$merge_tool_candidates vimdiff"
fi
merge_tool_candidates="$merge_tool_candidates opendiff emerge vimdiff"
echo "merge tool candidates: $merge_tool_candidates"
for i in $merge_tool_candidates; do
- if test $i = emerge ; then
- cmd=emacs
- else
- cmd=$i
- fi
- if type $cmd > /dev/null 2>&1; then
- merge_tool=$i
- break
+ case $i in emerge)
+ cmd=emacs;;
+ ediff)
+ merge_tool=$i
+ break;;
+ *) cmd=$i
+ esac
+ if type $cmd > /dev/null 2>&1; then
+ merge_tool=$i
+ break
fi
done
if test -z "$merge_tool" ; then
@@ -357,6 +374,11 @@ case "$merge_tool" in
exit 1
fi
;;
+ ediff)
+ if ! (set ${EDITOR:-${VISUAL:-emacs}}; type "$1" > /dev/null 2>&1); then
+ echo "${EDITOR:-${VISUAL:-emacs}} is not available"
+ exit 1
+ fi
*)
echo "Unknown merge tool: $merge_tool"
exit 1
--
1.5.2.3
^ permalink raw reply related
* [StGIT PATCH] Include contrib scripts in the release tarball.
From: Yann Dirson @ 2007-07-29 13:32 UTC (permalink / raw)
To: Catalin Marinas; +Cc: git
Signed-off-by: Yann Dirson <ydirson@altern.org>
---
This patch is targeted at the stable branch.
MANIFEST.in | 6 +++---
1 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/MANIFEST.in b/MANIFEST.in
index 6b634e0..583a5e8 100644
--- a/MANIFEST.in
+++ b/MANIFEST.in
@@ -3,9 +3,9 @@ include stg-prof
include templates/*.tmpl
include examples/*.tmpl
include examples/gitconfig
-include contrib/diffcol.sh
-include contrib/stgbashprompt.sh
-include contrib/stgit-completion.bash
+include contrib/*.sh
+include contrib/*.bash
+include contrib/stg-*
include t/t*.sh t/t*/* t/Makefile t/README
include Documentation/*.txt Documentation/Makefile Documentation/*.conf
include Documentation/build-docdep.perl Documentation/callouts.xsl
^ permalink raw reply related
* Re: [PATCH] Documentation/git-diff: remove -r from --name-status example
From: Jeff King @ 2007-07-29 12:26 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Junio C Hamano, git
In-Reply-To: <Pine.LNX.4.64.0707291323150.14781@racer.site>
On Sun, Jul 29, 2007 at 01:24:20PM +0100, Johannes Schindelin wrote:
> No. Just think about "git diff -p -w --quiet". In some cases it _has_ to
> recurse.
OK, I'm convinced. It should be as you originally suggested.
-Peff
^ permalink raw reply
* Re: [PATCH] Documentation/git-diff: remove -r from --name-status example
From: Johannes Schindelin @ 2007-07-29 12:24 UTC (permalink / raw)
To: Jeff King; +Cc: Junio C Hamano, git
In-Reply-To: <20070729121948.GA21983@coredump.intra.peff.net>
Hi,
On Sun, 29 Jul 2007, Jeff King wrote:
> On Sun, Jul 29, 2007 at 01:04:13PM +0100, Johannes Schindelin wrote:
>
> > The idea is this: when "--quiet" was given, we do not output anything, and
> > therefore do not have to recurse into the directories, because we already
> > know that there are differences when a _tree_ is different. I do not
> > remember all details of the "--quiet" implementation, but I think that it
> >
> > - exits early (as you said)
> >
> > - does not turn on "recursive" to avoid unnecessary work.
>
> OK, looking through the code, this works _sometimes_. If I say "git-diff
> --quiet" then it will not recurse. If I say "git-diff -p --quiet" then
> it will (even though we never show the -p output).
That is expected behaviour. If you ask for it, it should be done (however
silly it might be).
> Since --quiet supersedes all output formats, I think it probably should
> just clear the recursive option entirely. In which case rather than
> special-casing quiet to avoid recursion in git-diff, we can simply turn
> on recursion before parsing options (and it will get turned off
> correctly by any diff options that need to do so).
No. Just think about "git diff -p -w --quiet". In some cases it _has_ to
recurse.
Ciao,
Dscho
^ permalink raw reply
* conversion from svn with renames
From: Ricardo SIGNES @ 2007-07-29 12:23 UTC (permalink / raw)
To: git
I'd like to convert svn.codesimply.com/projects' contents to git.
Right now, the content is like this:
/projects/$PROJECTNAME/{trunk,tags,branches}
git-svnimport does well if I specify projects/$PROJECTNAME/trunk as the trunk
directory and that/tags as the tags directory. (I am not interested in
bothering with branches.) The problem is this:
For many of the projects, $PROJECTNAME was once "foo" and is now "bar."
git-svnimport only imports the history from the current name.
I tried to import foo, then bar, into one git repostiory, but the histories
didn't seem to get connected. Sam V. suggested git-filter-branch, but I didn't
quite see how to make it do what I wanted.
I would greatly appreciate any advice or help on this conversion.
--
rjbs
^ permalink raw reply
* Re: [PATCH] Documentation/git-diff: remove -r from --name-status example
From: Jeff King @ 2007-07-29 12:19 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Junio C Hamano, git
In-Reply-To: <Pine.LNX.4.64.0707291258410.14781@racer.site>
On Sun, Jul 29, 2007 at 01:04:13PM +0100, Johannes Schindelin wrote:
> The idea is this: when "--quiet" was given, we do not output anything, and
> therefore do not have to recurse into the directories, because we already
> know that there are differences when a _tree_ is different. I do not
> remember all details of the "--quiet" implementation, but I think that it
>
> - exits early (as you said)
>
> - does not turn on "recursive" to avoid unnecessary work.
OK, looking through the code, this works _sometimes_. If I say "git-diff
--quiet" then it will not recurse. If I say "git-diff -p --quiet" then
it will (even though we never show the -p output).
Since --quiet supersedes all output formats, I think it probably should
just clear the recursive option entirely. In which case rather than
special-casing quiet to avoid recursion in git-diff, we can simply turn
on recursion before parsing options (and it will get turned off
correctly by any diff options that need to do so).
Something like:
diff --git a/builtin-diff.c b/builtin-diff.c
index 7f367b6..e6d10bd 100644
--- a/builtin-diff.c
+++ b/builtin-diff.c
@@ -229,6 +229,7 @@ int cmd_diff(int argc, const char **argv, const char *prefix)
argc = setup_revisions(argc, argv, &rev, NULL);
if (!rev.diffopt.output_format) {
rev.diffopt.output_format = DIFF_FORMAT_PATCH;
+ rev.diffopt.recursive = 1;
if (diff_setup_done(&rev.diffopt) < 0)
die("diff_setup_done failed");
}
diff --git a/diff.c b/diff.c
index a5fc56b..aeae1a3 100644
--- a/diff.c
+++ b/diff.c
@@ -2182,6 +2182,7 @@ int diff_setup_done(struct diff_options *options)
if (options->quiet) {
options->output_format = DIFF_FORMAT_NO_OUTPUT;
options->exit_with_status = 1;
+ options->recursive = 0;
}
/*
But maybe that doesn't work because some of the options need recursion
turned on, even if --quiet is specified. I have to admit, there are a
lot of code paths here and I'm not sure how all of them interact with
the recursive option. So perhaps it is better to just special case
options->quiet as you suggested.
-Peff
^ permalink raw reply related
* [PATCH v3] Add to gitk an --argscmd flag to get the list of refs to draw at refresh time.
From: Yann Dirson @ 2007-07-29 12:17 UTC (permalink / raw)
To: paulus; +Cc: git
This allows to display a set of refs, when the refs in the set may
themselves change between two refresh operations (eg. the set of
patches in a patch stack), and is expected to be called from other
porcelain suites.
The command is expected to generate a list of commits, which will be
appended to the commits litterally passed on the command-line. That
command is handled similarly to the litteral refs, and has its own
field in the saved view, and an edit field in the view editor.
Signed-off-by: Yann Dirson <ydirson@altern.org>
---
This is a rebase to current git master. It happens that I had to
revert 2 code simplifications you did under "Improve handling of --
and ambiguous arguments", which my patch happens to rely on in its
current form.
Documentation/gitk.txt | 7 +++++
gitk | 65 ++++++++++++++++++++++++++++++++++++++----------
2 files changed, 59 insertions(+), 13 deletions(-)
diff --git a/Documentation/gitk.txt b/Documentation/gitk.txt
index e9f82b9..71ed8ba 100644
--- a/Documentation/gitk.txt
+++ b/Documentation/gitk.txt
@@ -41,6 +41,13 @@ frequently used options.
Show all branches.
+--argscmd=<command>::
+ Command to be run each time gitk has to determine the list of
+ <revs> to show. The command is expected to print on its
+ standard output a list of additional revs to be shown. Use
+ this instead of explicitely specifying <revs> if the set of
+ commits to show may vary between refreshs.
+
<revs>::
Limit the revisions to show. This can be either a single revision
diff --git a/gitk b/gitk
index f74ce51..264500f 100755
--- a/gitk
+++ b/gitk
@@ -82,18 +82,29 @@ proc dorunq {} {
proc start_rev_list {view} {
global startmsecs
global commfd leftover tclencoding datemode
- global viewargs viewfiles commitidx
+ global viewargs viewargscmd viewfiles commitidx
global lookingforhead showlocalchanges
set startmsecs [clock clicks -milliseconds]
set commitidx($view) 0
+ set args $viewargs($view)
+ if {$viewargscmd($view) ne "None"} {
+ if {[catch {
+ set fd [open [concat | $viewargscmd($view)] r]
+ } err]} {
+ puts stderr "Error executing --argscmd command: $err"
+ exit 1
+ }
+ set args [concat $args [read $fd 500000]]
+ close $fd
+ }
set order "--topo-order"
if {$datemode} {
set order "--date-order"
}
if {[catch {
set fd [open [concat | git log -z --pretty=raw $order --parents \
- --boundary $viewargs($view) "--" $viewfiles($view)] r]
+ --boundary $args "--" $viewfiles($view)] r]
} err]} {
error_popup "Error executing git rev-list: $err"
exit 1
@@ -966,7 +977,7 @@ proc savestuff {w} {
global canv canv2 canv3 ctext cflist mainfont textfont uifont tabstop
global stuffsaved findmergefiles maxgraphpct
global maxwidth showneartags showlocalchanges
- global viewname viewfiles viewargs viewperm nextviewnum
+ global viewname viewfiles viewargs viewargscmd viewperm nextviewnum
global cmitmode wrapcomment
global colors bgcolor fgcolor diffcolors selectbgcolor
@@ -1002,7 +1013,7 @@ proc savestuff {w} {
puts -nonewline $f "set permviews {"
for {set v 0} {$v < $nextviewnum} {incr v} {
if {$viewperm($v)} {
- puts $f "{[list $viewname($v) $viewfiles($v) $viewargs($v)]}"
+ puts $f "{[list $viewname($v) $viewfiles($v) $viewargs($v) $viewargscmd($v)]}"
}
}
puts $f "}"
@@ -1597,7 +1608,7 @@ proc shellsplit {str} {
proc newview {ishighlight} {
global nextviewnum newviewname newviewperm uifont newishighlight
- global newviewargs revtreeargs
+ global newviewargs revtreeargs viewargscmd newviewargscmd curview
set newishighlight $ishighlight
set top .gitkview
@@ -1608,13 +1619,14 @@ proc newview {ishighlight} {
set newviewname($nextviewnum) "View $nextviewnum"
set newviewperm($nextviewnum) 0
set newviewargs($nextviewnum) [shellarglist $revtreeargs]
+ set newviewargscmd($nextviewnum) [shellarglist $viewargscmd($curview)]
vieweditor $top $nextviewnum "Gitk view definition"
}
proc editview {} {
global curview
global viewname viewperm newviewname newviewperm
- global viewargs newviewargs
+ global viewargs newviewargs viewargscmd newviewargscmd
set top .gitkvedit-$curview
if {[winfo exists $top]} {
@@ -1624,6 +1636,7 @@ proc editview {} {
set newviewname($curview) $viewname($curview)
set newviewperm($curview) $viewperm($curview)
set newviewargs($curview) [shellarglist $viewargs($curview)]
+ set newviewargscmd($curview) [shellarglist $viewargscmd($curview)]
vieweditor $top $curview "Gitk: edit view $viewname($curview)"
}
@@ -1644,7 +1657,15 @@ proc vieweditor {top n title} {
grid $top.al - -sticky w -pady 5
entry $top.args -width 50 -textvariable newviewargs($n) \
-background white -font $uifont
+
grid $top.args - -sticky ew -padx 5
+ message $top.ac -aspect 1000 -font $uifont \
+ -text "Command to generate more commits to include:"
+ grid $top.ac - -sticky w -pady 5
+ entry $top.argscmd -width 50 -textvariable newviewargscmd($n) \
+ -background white -font $uifont
+
+ grid $top.argscmd - -sticky ew -padx 5
message $top.l -aspect 1000 -font $uifont \
-text "Enter files and directories to include, one per line:"
grid $top.l - -sticky w
@@ -1690,7 +1711,7 @@ proc allviewmenus {n op args} {
proc newviewok {top n} {
global nextviewnum newviewperm newviewname newishighlight
global viewname viewfiles viewperm selectedview curview
- global viewargs newviewargs viewhlmenu
+ global viewargs newviewargs viewargscmd newviewargscmd viewhlmenu
if {[catch {
set newargs [shellsplit $newviewargs($n)]
@@ -1700,6 +1721,14 @@ proc newviewok {top n} {
focus $top
return
}
+ if {[catch {
+ set newargscmd [shellsplit $newviewargscmd($n)]
+ } err]} {
+ error_popup "Error in commit selection command: $err"
+ wm raise $top
+ focus $top
+ return
+ }
set files {}
foreach f [split [$top.t get 0.0 end] "\n"] {
set ft [string trim $f]
@@ -1714,6 +1743,7 @@ proc newviewok {top n} {
set viewperm($n) $newviewperm($n)
set viewfiles($n) $files
set viewargs($n) $newargs
+ set viewargscmd($n) $newargscmd
addviewmenu $n
if {!$newishighlight} {
run showview $n
@@ -1730,9 +1760,11 @@ proc newviewok {top n} {
doviewmenu $viewhlmenu 1 [list addvhighlight $n] \
entryconf [list -label $viewname($n) -value $viewname($n)]
}
- if {$files ne $viewfiles($n) || $newargs ne $viewargs($n)} {
+ if {$files ne $viewfiles($n) || $newargs ne $viewargs($n) || \
+ $newargscmd ne $viewargscmd($n)} {
set viewfiles($n) $files
set viewargs($n) $newargs
+ set viewargscmd($n) $newargscmd
if {$curview == $n} {
run updatecommits
}
@@ -7584,14 +7616,18 @@ if {![file isdirectory $gitdir]} {
set revtreeargs {}
set cmdline_files {}
set i 0
+set revtreeargscmd None
foreach arg $argv {
- switch -- $arg {
- "" { }
- "-d" { set datemode 1 }
- "--" {
+ switch -regexp -- $arg {
+ "^$" { }
+ "^-d" { set datemode 1 }
+ "^--$" {
set cmdline_files [lrange $argv [expr {$i + 1}] end]
break
}
+ "^--argscmd=" {
+ regexp {^--argscmd=(.*)} $arg match revtreeargscmd
+ }
default {
lappend revtreeargs $arg
}
@@ -7653,6 +7689,7 @@ set selectedhlview None
set viewfiles(0) {}
set viewperm(0) 0
set viewargs(0) {}
+set viewargscmd(0) None
set cmdlineok 0
set stopped 0
@@ -7669,7 +7706,7 @@ tkwait visibility .
wm title . "[file tail $argv0]: [file tail [pwd]]"
readrefs
-if {$cmdline_files ne {} || $revtreeargs ne {}} {
+if {$cmdline_files ne {} || $revtreeargs ne {} || $revtreeargscmd ne {}} {
# create a view for the files/dirs specified on the command line
set curview 1
set selectedview 1
@@ -7677,6 +7714,7 @@ if {$cmdline_files ne {} || $revtreeargs ne {}} {
set viewname(1) "Command line"
set viewfiles(1) $cmdline_files
set viewargs(1) $revtreeargs
+ set viewargscmd(1) $revtreeargscmd
set viewperm(1) 0
addviewmenu 1
.bar.view entryconf Edit* -state normal
@@ -7690,6 +7728,7 @@ if {[info exists permviews]} {
set viewname($n) [lindex $v 0]
set viewfiles($n) [lindex $v 1]
set viewargs($n) [lindex $v 2]
+ set viewargscmd($n) [lindex $v 3]
set viewperm($n) 1
addviewmenu $n
}
^ permalink raw reply related
* Re: [PATCH] Documentation/git-diff: remove -r from --name-status example
From: Johannes Schindelin @ 2007-07-29 12:04 UTC (permalink / raw)
To: Jeff King; +Cc: Junio C Hamano, git
In-Reply-To: <20070729113850.GA17796@coredump.intra.peff.net>
Hi,
On Sun, 29 Jul 2007, Jeff King wrote:
> On Sun, Jul 29, 2007 at 12:14:49PM +0100, Johannes Schindelin wrote:
>
> > How about
> >
> > if (!rev.diffopt.quiet)
> > rev.diffopt.recursive = 1;
> >
> > instead?
>
> Can you explain?
The idea is this: when "--quiet" was given, we do not output anything, and
therefore do not have to recurse into the directories, because we already
know that there are differences when a _tree_ is different. I do not
remember all details of the "--quiet" implementation, but I think that it
- exits early (as you said)
- does not turn on "recursive" to avoid unnecessary work.
Imagine something like this: tree "a" and "b" contain 100,000 elements
each, which are identical except for the last entry. "--quiet" does not
need to check the 99,999 elements before that one, since the tree hashes
are already different.
Of course, this reasoning breaks down fatally when you specify something
like "--ignore-whitespace", but those cases should turn on recursive
explicitely, so that the performance penalty of "recursive = 1" does not
percolate back to the (much more common) trivial cases.
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH 1/3] log_ref_write() -- do not chomp reflog message at the first LF
From: Johannes Schindelin @ 2007-07-29 11:57 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Sean, Benoit SIGOURE, git
In-Reply-To: <7vvec4nhfk.fsf_-_@assigned-by-dhcp.cox.net>
Hi,
On Sat, 28 Jul 2007, Junio C Hamano wrote:
> A reflog file is organized as one-line-per-entry records, and we
> enforced the file format integrity by chomping the given message
> at the first LF. This changes it to convert them to SP, which
> is more in line with the --pretty=oneline format.
Would it not be better to chop off before the first "\n", and just append
"..."? IOW something like
-- snip --
refs.c | 13 +++++++++----
1 files changed, 9 insertions(+), 4 deletions(-)
diff --git a/refs.c b/refs.c
index 2694e70..554436b 100644
--- a/refs.c
+++ b/refs.c
@@ -1043,7 +1043,7 @@ static int log_ref_write(const char *ref_name, const unsigned char *old_sha1,
unsigned maxlen, len;
int msglen;
char *log_file, *logrec;
- const char *committer;
+ const char *committer, *postmsg;
if (log_all_ref_updates < 0)
log_all_ref_updates = !is_bare_repository();
@@ -1088,15 +1088,16 @@ static int log_ref_write(const char *ref_name, const unsigned char *old_sha1,
break;
if (*msg) {
const char *ep = strchr(msg, '\n');
- if (ep)
+ if (ep) {
msglen = ep - msg;
- else
+ postmsg = (ep[1] && !isspace(ep[1])) ? "..." : NULL;
+ } else
msglen = strlen(msg);
}
}
committer = git_committer_info(-1);
- maxlen = strlen(committer) + msglen + 100;
+ maxlen = strlen(committer) + msglen + 100 + 3;
logrec = xmalloc(maxlen);
len = sprintf(logrec, "%s %s %s\n",
sha1_to_hex(old_sha1),
@@ -1104,6 +1105,10 @@ static int log_ref_write(const char *ref_name, const unsigned char *old_sha1,
committer);
if (msglen)
len += sprintf(logrec + len - 1, "\t%.*s\n", msglen, msg) - 1;
+ if (postmsg) {
+ len += strlen(postmsg);
+ strcat(logrec + len - 1, postmsg);
+ }
written = len <= maxlen ? write_in_full(logfd, logrec, len) : -1;
free(logrec);
if (close(logfd) != 0 || written != len)
-- snap --
It is not like the reflog messages have to be very verbose; they only have
to give a hint what the commit was about, and the commit name is the
important information.
What do you think?
Ciao,
Dscho
^ 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