* Re: [PATCH] Make git-clean a builtin
From: Frank Lichtenheld @ 2007-10-06 21:52 UTC (permalink / raw)
To: Shawn Bohrer; +Cc: git, gitster
In-Reply-To: <11917040461528-git-send-email-shawn.bohrer@gmail.com>
On Sat, Oct 06, 2007 at 03:54:06PM -0500, Shawn Bohrer wrote:
> +static int remove_directory(const char *path)
> +{
> + DIR *d;
> + struct dirent *dir;
> + d = opendir(path);
> + if (d) {
> + chdir(path);
> + while ((dir = readdir(d)) != NULL) {
> + if(strcmp( dir->d_name, ".") == 0 ||
> + strcmp( dir->d_name, ".." ) == 0 )
> + continue;
> + if (dir->d_type == DT_DIR)
> + remove_directory(dir->d_name);
> + else
> + unlink(dir->d_name);
> + }
> + }
> + closedir(d);
> + chdir("..");
> + return rmdir(path);
> +}
The unconditional chdir(..) after the conditional chdir(path) seems like
asking for trouble to me...
> + while (fgets(path, sizeof(path), cmd_fout) != NULL) {
> + struct stat st;
> + char *p;
> + p = strrchr(path, '\n');
> + if ( p != NULL )
> + *p = '\0';
What happens in case p == NULL? It simply tries to remove the partial
path?
> + fclose(cmd_fout);
> + finish_command(&cmd);
> + if (!ignored && !access(git_path("info/exclude"), F_OK))
> + free(buf);
There is a race condition here of the value of access() changes between
the two calls. Not one likely to trigger but it should be easy to avoid
alltogether.
> + free(argv_ls_files);
> + return 0;
> +}
Gruesse,
--
Frank Lichtenheld <frank@lichtenheld.de>
www: http://www.djpig.de/
^ permalink raw reply
* [PATCH] hg-to-git speedup through selectable repack intervals
From: Michael Gebetsroither @ 2007-10-06 21:16 UTC (permalink / raw)
To: git; +Cc: Michael Gebetsroither
---
contrib/hg-to-git/hg-to-git.py | 14 +++++++++++---
1 files changed, 11 insertions(+), 3 deletions(-)
diff --git a/contrib/hg-to-git/hg-to-git.py b/contrib/hg-to-git/hg-to-git.py
index 37337ff..7a1c3e4 100755
--- a/contrib/hg-to-git/hg-to-git.py
+++ b/contrib/hg-to-git/hg-to-git.py
@@ -29,6 +29,8 @@ hgvers = {}
hgchildren = {}
# Current branch for each hg revision
hgbranch = {}
+# Number of new changesets converted from hg
+hgnewcsets = 0
#------------------------------------------------------------------------------
@@ -40,6 +42,8 @@ def usage():
options:
-s, --gitstate=FILE: name of the state to be saved/read
for incrementals
+ -n, --nrepack=INT: number of changesets that will trigger
+ a repack (default=0, -1 to deactivate)
required:
hgprj: name of the HG project to import (directory)
@@ -68,14 +72,16 @@ def getgitenv(user, date):
#------------------------------------------------------------------------------
state = ''
+opt_nrepack = 0
try:
- opts, args = getopt.getopt(sys.argv[1:], 's:t:', ['gitstate=', 'tempdir='])
+ opts, args = getopt.getopt(sys.argv[1:], 's:t:n:', ['gitstate=', 'tempdir=', 'nrepack='])
for o, a in opts:
if o in ('-s', '--gitstate'):
state = a
state = os.path.abspath(state)
-
+ if o in ('-n', '--nrepack'):
+ opt_nrepack = int(a)
if len(args) != 1:
raise('params')
except:
@@ -138,6 +144,7 @@ for cset in range(int(tip) + 1):
# incremental, already seen
if hgvers.has_key(str(cset)):
continue
+ hgnewcsets += 1
# get info
prnts = os.popen('hg log -r %d | grep ^parent: | cut -f 2 -d :' % cset).readlines()
@@ -222,7 +229,8 @@ for cset in range(int(tip) + 1):
print 'record', cset, '->', vvv
hgvers[str(cset)] = vvv
-os.system('git-repack -a -d')
+if hgnewcsets >= opt_nrepack and opt_nrepack != -1:
+ os.system('git-repack -a -d')
# write the state for incrementals
if state:
--
1.5.3.4
^ permalink raw reply related
* [PATCH] Make git-clean a builtin
From: Shawn Bohrer @ 2007-10-06 20:54 UTC (permalink / raw)
To: git; +Cc: gitster, Shawn Bohrer
This replaces git-clean.sh with builtin-clean.c, and moves git-clean.sh to the
examples.
Signed-off-by: Shawn Bohrer <shawn.bohrer@gmail.com>
---
Makefile | 3 +-
builtin-clean.c | 177 +++++++++++++++++++++++++
builtin.h | 1 +
git-clean.sh => contrib/examples/git-clean.sh | 0
git.c | 1 +
5 files changed, 181 insertions(+), 1 deletions(-)
create mode 100644 builtin-clean.c
rename git-clean.sh => contrib/examples/git-clean.sh (100%)
diff --git a/Makefile b/Makefile
index 8db4dbe..2b3b8fb 100644
--- a/Makefile
+++ b/Makefile
@@ -206,7 +206,7 @@ BASIC_LDFLAGS =
SCRIPT_SH = \
git-bisect.sh git-checkout.sh \
- git-clean.sh git-clone.sh git-commit.sh \
+ git-clone.sh git-commit.sh \
git-fetch.sh \
git-ls-remote.sh \
git-merge-one-file.sh git-mergetool.sh git-parse-remote.sh \
@@ -327,6 +327,7 @@ BUILTIN_OBJS = \
builtin-check-attr.o \
builtin-checkout-index.o \
builtin-check-ref-format.o \
+ builtin-clean.o \
builtin-commit-tree.o \
builtin-count-objects.o \
builtin-describe.o \
diff --git a/builtin-clean.c b/builtin-clean.c
new file mode 100644
index 0000000..534707f
--- /dev/null
+++ b/builtin-clean.c
@@ -0,0 +1,177 @@
+/*
+ * "git clean" builtin command
+ *
+ * Copyright (C) 2007 Shawn Bohrer
+ *
+ * Based on git-clean.sh by Pavel Roskin
+ */
+
+#include "builtin.h"
+#include "cache.h"
+#include "run-command.h"
+
+static int disabled = 0;
+static int show_only = 0;
+static int remove_directories = 0;
+static int quiet = 0;
+static int ignored = 0;
+static int ignored_only = 0;
+
+static const char builtin_clean_usage[] =
+"git-clean [-d] [-f] [-n] [-q] [-x | -X] [--] <paths>...";
+
+static int git_clean_config(const char *var, const char *value)
+{
+ if (!strcmp(var, "clean.requireforce")) {
+ disabled = git_config_bool(var, value);
+ }
+ return 0;
+}
+
+static int remove_directory(const char *path)
+{
+ DIR *d;
+ struct dirent *dir;
+ d = opendir(path);
+ if (d) {
+ chdir(path);
+ while ((dir = readdir(d)) != NULL) {
+ if(strcmp( dir->d_name, ".") == 0 ||
+ strcmp( dir->d_name, ".." ) == 0 )
+ continue;
+ if (dir->d_type == DT_DIR)
+ remove_directory(dir->d_name);
+ else
+ unlink(dir->d_name);
+ }
+ }
+ closedir(d);
+ chdir("..");
+ return rmdir(path);
+}
+
+int cmd_clean(int argc, const char **argv, const char *prefix)
+{
+ int i;
+ int j;
+ struct child_process cmd;
+ const char **argv_ls_files;
+ char *buf;
+ char path[1024];
+ FILE *cmd_fout;
+
+ git_config(git_clean_config);
+
+ for (i = 1; i < argc; i++) {
+ const char *arg = argv[i];
+
+ if (arg[0] != '-')
+ break;
+ if (!strcmp(arg, "--")) {
+ i++;
+ break;
+ }
+ if (!strcmp(arg, "-n")) {
+ show_only = 1;
+ disabled = 0;
+ continue;
+ }
+ if (!strcmp(arg, "-f")) {
+ disabled = 0;
+ continue;
+ }
+ if (!strcmp(arg, "-d")) {
+ remove_directories = 1;
+ continue;
+ }
+ if (!strcmp(arg, "-q")) {
+ quiet = 1;
+ continue;
+ }
+ if (!strcmp(arg, "-x")) {
+ ignored = 1;
+ continue;
+ }
+ if (!strcmp(arg, "-X")) {
+ ignored_only = 1;
+ continue;
+ }
+ usage(builtin_clean_usage);
+ }
+
+ if (ignored && ignored_only)
+ usage(builtin_clean_usage);
+
+ if (disabled) {
+ die("clean.requireForce set and -n or -f not given; refusing to clean");
+ }
+
+ /* Paths (argc - i) + 8 (Possible arguments)*/
+ argv_ls_files = xmalloc((argc - i + 8) * sizeof(const char *));
+ argv_ls_files[0] = "ls-files";
+ argv_ls_files[1] = "--others";
+ argv_ls_files[2] = "--directory";
+ j = 3;
+ if (!ignored) {
+ argv_ls_files[j++] = "--exclude-per-directory=.gitignore";
+ if (ignored_only)
+ argv_ls_files[j++] = "--ignored";
+ if (!access(git_path("info/exclude"), F_OK)) {
+ char *exclude_path = git_path("info/exclude");
+ int len = strlen(exclude_path);
+ buf = (char*)malloc(len+16);
+ sprintf(buf, "--exclude-from=%s", exclude_path);
+ argv_ls_files[j++] = buf;
+ }
+ }
+ argv_ls_files[j++] = "--";
+ /* Add remaining paths passed in as arguments */
+ if (argc - i)
+ memcpy(argv_ls_files + j++, argv + i, (argc - i) * sizeof(const char *));
+ argv_ls_files[j + argc - i] = NULL;
+
+ memset(&cmd, 0, sizeof(cmd));
+ cmd.argv = argv_ls_files;
+ cmd.git_cmd = 1;
+ cmd.out = -1;
+ if (start_command(&cmd))
+ die("Could not run sub-command: git ls-files");
+
+ cmd_fout = fdopen(cmd.out, "r");
+ while (fgets(path, sizeof(path), cmd_fout) != NULL) {
+ struct stat st;
+ char *p;
+ p = strrchr(path, '\n');
+ if ( p != NULL )
+ *p = '\0';
+ if (!lstat(path, &st) && (S_ISDIR(st.st_mode))) {
+ if (show_only && remove_directories) {
+ printf("Would remove %s\n", path);
+ } else if (quiet && remove_directories) {
+ remove_directory(path);
+ } else if (remove_directories) {
+ printf("Removing %s\n", path);
+ remove_directory(path);
+ } else if (show_only) {
+ printf("Would not remove %s\n", path);
+ } else {
+ printf("Not removing %s\n", path);
+ }
+ } else {
+ if (show_only) {
+ printf("Would remove %s\n", path);
+ continue;
+ } else if (!quiet) {
+ printf("Removing %s\n", path);
+ }
+ unlink(path);
+ }
+ }
+
+ fclose(cmd_fout);
+ finish_command(&cmd);
+ if (!ignored && !access(git_path("info/exclude"), F_OK))
+ free(buf);
+ free(argv_ls_files);
+ return 0;
+}
diff --git a/builtin.h b/builtin.h
index d6f2c76..8c112f3 100644
--- a/builtin.h
+++ b/builtin.h
@@ -23,6 +23,7 @@ extern int cmd_check_attr(int argc, const char **argv, const char *prefix);
extern int cmd_check_ref_format(int argc, const char **argv, const char *prefix);
extern int cmd_cherry(int argc, const char **argv, const char *prefix);
extern int cmd_cherry_pick(int argc, const char **argv, const char *prefix);
+extern int cmd_clean(int argc, const char **argv, const char *prefix);
extern int cmd_commit_tree(int argc, const char **argv, const char *prefix);
extern int cmd_count_objects(int argc, const char **argv, const char *prefix);
extern int cmd_describe(int argc, const char **argv, const char *prefix);
diff --git a/git-clean.sh b/contrib/examples/git-clean.sh
similarity index 100%
rename from git-clean.sh
rename to contrib/examples/git-clean.sh
diff --git a/git.c b/git.c
index 9eaca1d..cda6344 100644
--- a/git.c
+++ b/git.c
@@ -320,6 +320,7 @@ static void handle_internal_command(int argc, const char **argv)
{ "check-attr", cmd_check_attr, RUN_SETUP | NEED_WORK_TREE },
{ "cherry", cmd_cherry, RUN_SETUP },
{ "cherry-pick", cmd_cherry_pick, RUN_SETUP | NEED_WORK_TREE },
+ { "clean", cmd_clean, RUN_SETUP },
{ "commit-tree", cmd_commit_tree, RUN_SETUP },
{ "config", cmd_config },
{ "count-objects", cmd_count_objects, RUN_SETUP },
--
1.5.3.GIT
^ permalink raw reply related
* Re: A message from the human patch-queue
From: Lars Hjemli @ 2007-10-06 20:17 UTC (permalink / raw)
To: Frank Lichtenheld; +Cc: git@vger.kernel.org
In-Reply-To: <20071006200416.GU31659@planck.djpig.de>
On 10/6/07, Frank Lichtenheld <frank@lichtenheld.de> wrote:
> On Sat, Oct 06, 2007 at 07:18:34PM +0200, Lars Hjemli wrote:
> > Please let me know if I've your patches are missing, and I'll swiftly add them.
>
> You can remove my q/fl/t9400-checkout and q/fl/cvsserver-packed-refs. I
> will resubmit them in altered form.
Ok, thanks
--
larsh
^ permalink raw reply
* Re: A message from the human patch-queue
From: Frank Lichtenheld @ 2007-10-06 20:04 UTC (permalink / raw)
To: Lars Hjemli; +Cc: git@vger.kernel.org
In-Reply-To: <8c5c35580710061018m43f8ceaag9341ee95d39500f5@mail.gmail.com>
On Sat, Oct 06, 2007 at 07:18:34PM +0200, Lars Hjemli wrote:
> Please let me know if I've your patches are missing, and I'll swiftly add them.
You can remove my q/fl/t9400-checkout and q/fl/cvsserver-packed-refs. I
will resubmit them in altered form.
(My current cvsserver queue can be found at
http://source.djpig.de/git/?p=git-cvsserver.git;a=shortlog;h=cvsserver)
Gruesse,
--
Frank Lichtenheld <frank@lichtenheld.de>
www: http://www.djpig.de/
^ permalink raw reply
* git fetch -- double fetch
From: Andy Whitcroft @ 2007-10-06 18:57 UTC (permalink / raw)
To: git
I have recently been seeing repeated fetching of some branches. I feel
this has happened in at least three of my repos on three distinct
projects:
apw@pinky$ git fetch origin
remote: Generating pack...
remote: Done counting 5 objects.
remote: Deltifying 5 objects...
remote: 100% (5/5) done
Unpacking 5 objects...
remote: Total 5 (delta 0), reused 0 (delta 0)
100% (5/5) done
* refs/remotes/origin/master: fast forward to branch 'master' of ssh://git@abat-dev/var/www/git/abat
old..new: ce046f0..41c9dde
* refs/remotes/origin/master: fast forward to branch 'master' of ssh://git@abat-dev/var/www/git/abat
old..new: ce046f0..41c9dde
error: Ref refs/remotes/origin/master is at 41c9dde2e63f35cd7c64b0a52c3650f246999ffd but expected ce046f04172a2a216092936302ab2cb4da64b69e
apw@pinky$
This is with a 'next' a couple of days old:
apw@pinky$ git --version
git version 1.5.3.3.1145.g46930-dirty
apw@pinky$
Will be upgrading to the latest next, will let you know if I see it again.
-apw
^ permalink raw reply
* [PATCH] git-svn: respect Subversion's [auth] section configuration values
From: Eygene Ryabinkin @ 2007-10-06 18:57 UTC (permalink / raw)
To: git; +Cc: Eric Wong
Parameters 'store-passwords' and 'store-auth-creds' from Subversion's
configuration (~/.subversion/config) were not respected. This was
fixed: the default values for these parameters are set to 'yes' to
follow Subversion behaviour.
Signed-off-by: Eygene Ryabinkin <rea-git@codelabs.ru>
---
git-svn.perl | 23 +++++++++++++++++++++++
1 files changed, 23 insertions(+), 0 deletions(-)
diff --git a/git-svn.perl b/git-svn.perl
index 484b057..f7ef421 100755
--- a/git-svn.perl
+++ b/git-svn.perl
@@ -3051,6 +3051,29 @@ sub new {
]);
my $config = SVN::Core::config_get_config($config_dir);
$RA = undef;
+ my $dont_store_passwords = 1;
+ my $conf_t = ${$config}{'config'};
+ {
+ # The usage of $SVN::_Core::SVN_CONFIG_* variables
+ # produces warnings that variables are used only once.
+ # I had not found the better way to shut them up, so
+ # warnings are disabled in this block.
+ no warnings;
+ if (SVN::_Core::svn_config_get_bool($conf_t,
+ $SVN::_Core::SVN_CONFIG_SECTION_AUTH,
+ $SVN::_Core::SVN_CONFIG_OPTION_STORE_PASSWORDS,
+ 1) == 0) {
+ SVN::_Core::svn_auth_set_parameter($baton,
+ $SVN::_Core::SVN_AUTH_PARAM_DONT_STORE_PASSWORDS,
+ bless (\$dont_store_passwords, "_p_void"));
+ }
+ if (SVN::_Core::svn_config_get_bool($conf_t,
+ $SVN::_Core::SVN_CONFIG_SECTION_AUTH,
+ $SVN::_Core::SVN_CONFIG_OPTION_STORE_AUTH_CREDS,
+ 1) == 0) {
+ $Git::SVN::Prompt::_no_auth_cache = 1;
+ }
+ }
my $self = SVN::Ra->new(url => $url, auth => $baton,
config => $config,
pool => SVN::Pool->new,
--
1.5.3.2
--
Eygene
^ permalink raw reply related
* [PATCH 2/2] instaweb: support for Ruby's WEBrick server
From: mike @ 2007-10-06 17:29 UTC (permalink / raw)
To: normalperson, gitster; +Cc: git, Mike Dalessio
In-Reply-To: <55e906d58f15c79c61d83ad4c52ef085de8ad736.1191687881.git.mike@csa.net>
running the webrick server with git requires Ruby and Ruby's YAML and
Webrick libraries (both of which come standard with Ruby). nice for
single-user standalone invocations.
the --httpd=webrick option generates a ruby script on the fly to read
httpd.conf options and invoke the web server via library call. this
script is placed in the .git/gitweb directory. it also generates a
shell script in a feeble attempt to invoke ruby in a portable manner,
which assumes that 'ruby' is in the user's $PATH.
Signed-off-by: Mike Dalessio <mike@csa.net>
---
Documentation/git-instaweb.txt | 2 +-
git-instaweb.sh | 40 ++++++++++++++++++++++++++++++++++++++++
2 files changed, 41 insertions(+), 1 deletions(-)
diff --git a/Documentation/git-instaweb.txt b/Documentation/git-instaweb.txt
index cec60ee..735008c 100644
--- a/Documentation/git-instaweb.txt
+++ b/Documentation/git-instaweb.txt
@@ -27,7 +27,7 @@ OPTIONS
The HTTP daemon command-line that will be executed.
Command-line options may be specified here, and the
configuration file will be added at the end of the command-line.
- Currently, lighttpd and apache2 are the only supported servers.
+ Currently lighttpd, apache2 and webrick are supported.
(Default: lighttpd)
-m|--module-path::
diff --git a/git-instaweb.sh b/git-instaweb.sh
index 42d9c34..859be4a 100755
--- a/git-instaweb.sh
+++ b/git-instaweb.sh
@@ -139,6 +139,43 @@ GIT_DIR="$fqgitdir"
export GIT_EXEC_PATH GIT_DIR
+webrick_conf () {
+ # generate a standalone server script in $fqgitdir/gitweb.
+ cat >"$fqgitdir/gitweb/$httpd.rb" <<EOF
+require 'webrick'
+require 'yaml'
+options = YAML::load_file(ARGV[0])
+options[:StartCallback] = proc do
+ File.open(options[:PidFile],"w") do |f|
+ f.puts Process.pid
+ end
+end
+options[:ServerType] = WEBrick::Daemon
+server = WEBrick::HTTPServer.new(options)
+['INT', 'TERM'].each do |signal|
+ trap(signal) {server.shutdown}
+end
+server.start
+EOF
+ # generate a shell script to invoke the above ruby script,
+ # which assumes _ruby_ is in the user's $PATH. that's _one_
+ # portable way to run ruby, which could be installed anywhere,
+ # really.
+ cat >"$fqgitdir/gitweb/$httpd" <<EOF
+#!/bin/sh
+exec ruby "$fqgitdir/gitweb/$httpd.rb" \$*
+EOF
+ chmod +x "$fqgitdir/gitweb/$httpd"
+
+ cat >"$conf" <<EOF
+:Port: $port
+:DocumentRoot: "$fqgitdir/gitweb"
+:DirectoryIndex: ["gitweb.cgi"]
+:PidFile: "$fqgitdir/pid"
+EOF
+ test "$local" = true && echo ':BindAddress: "127.0.0.1"' >> "$conf"
+}
+
lighttpd_conf () {
cat > "$conf" <<EOF
server.document-root = "$fqgitdir/gitweb"
@@ -239,6 +276,9 @@ case "$httpd" in
*apache2*)
apache2_conf
;;
+webrick)
+ webrick_conf
+ ;;
*)
echo "Unknown httpd specified: $httpd"
exit 1
--
1.5.2.5
^ permalink raw reply related
* [PATCH 1/2] instaweb: allow for use of auto-generated scripts
From: mike @ 2007-10-06 17:29 UTC (permalink / raw)
To: normalperson, gitster; +Cc: git, Mike Dalessio
In-Reply-To: <7vodfztviv.fsf@gitster.siamese.dyndns.org>
this patch allows scripts that reside in $fqgitdir/gitweb to be used
for firing up an instaweb server. this lays the groundwork for
extending instaweb support to non-standard web servers, which may
require a script for proper invocation.
Signed-off-by: Mike Dalessio <mike@csa.net>
---
git-instaweb.sh | 4 +++-
1 files changed, 3 insertions(+), 1 deletions(-)
diff --git a/git-instaweb.sh b/git-instaweb.sh
index b79c6b6..42d9c34 100755
--- a/git-instaweb.sh
+++ b/git-instaweb.sh
@@ -37,7 +37,9 @@ start_httpd () {
else
# many httpds are installed in /usr/sbin or /usr/local/sbin
# these days and those are not in most users $PATHs
- for i in /usr/local/sbin /usr/sbin
+ # in addition, we may have generated a server script
+ # in $fqgitdir/gitweb.
+ for i in /usr/local/sbin /usr/sbin "$fqgitdir/gitweb"
do
if test -x "$i/$httpd_only"
then
--
1.5.2.5
^ permalink raw reply related
* A message from the human patch-queue
From: Lars Hjemli @ 2007-10-06 17:18 UTC (permalink / raw)
To: git@vger.kernel.org; +Cc: Junio C Hamano
Hi
I've been collecting patches from the list for the last couple of days
and published them as topic-branches on http://hjemli.net/git/git (see
http://article.gmane.org/gmane.comp.version-control.git/60023 if you
wonder _why_ I've done this ;-)
All topic-branches are prefixed with 'q/' and the authors initials,
they're all based on current master
(58ba4f6ac828606fc206cfd5cec412a6974c91a1), and I've run 'make test'
successfully on all topics with code changes. There is also a list of
topics with links to the relevant postings at
http://hjemli.net/git/git/tree/branches?h=q/meta
Please let me know if I've your patches are missing, and I'll swiftly add them.
--
larsh
^ permalink raw reply
* Re: Question about "git commit -a"
From: Linus Torvalds @ 2007-10-06 16:13 UTC (permalink / raw)
To: Andy Parkins
Cc: git, Marko Macek, Kristian H?gsberg, Andreas Ericsson,
Paolo Ciarrocchi, Johannes Schindelin, Nguyen Thai Ngoc Duy,
Wincent Colaiuta
In-Reply-To: <200710060843.38567.andyparkins@gmail.com>
On Sat, 6 Oct 2007, Andy Parkins wrote:
>
> Who cares? Commits that build isn't the only reason for small commits.
More importantly, while it's true that you should always test all your
changes, quite often they really *are* obviously separate.
I've mentioned this as an example lots of times, but I often tend to have
multiple independent things in my tree at the same time. One of the
"clearly independent" ones is the fact that I historically tended to
update my Makefile for the next version number several days before I do
the actual release, just to remind me (I used to forget to bump the
version number, so..).
So I often have a dirty main makefile, but that doesn't mean that I'm
going to commit it until I'm ready. I want to (no - *need* to) be able to
pull and apply patches from other people despite the fact that I have some
dirty state.
[ It's not just the makefile: almost all of what I do these days is pull
and apply patches, but I also send out suggestions to other developers
by email, and I often end up keeping my suggestion around in my tree as
dirty state. I could use a topic branch, but the thing is, I don't
actually want to save it - but not only do I actually like seeing the
"couldn't merge due to dirty state" because that tells me I got the fix
back, but I like just eatign my dogfood and compiling the kernel with
the suggestions I sent out ]
So it's quite ok to have multiple independent changes going on it the
tree, and there's absolutely *zero* reason to think you should commit them
together (quite the reverse). Maybe this isn't all that common for a
*small* thing, but I pretty much guarantee that large projects always end
up doing somethng like this.
And making the *default* workflow do something bad - namely commit
everything blindly - is not a good idea. I'd rather have the normal
workflow basically try to encourage many small commits, because while it's
true that they may not have been tested individually, 99% of the time any
linkages are pretty obvious.
(Side note: the *most* common failure to check stuff in completely tends
to be one that other SCM's also have, for all the same reasons: forgetting
to *add* a new file. I suspect the git model of "add all new changes"
whether new files or old, actually _helps_ avoid that error, but quite
frankly, I don't think we'll ever get away from it. It's just too easy a
mistake to do).
Linus
^ permalink raw reply
* git-push [--all] and tags
From: martin f krafft @ 2007-10-06 16:05 UTC (permalink / raw)
To: git discussion list
[-- Attachment #1: Type: text/plain, Size: 1037 bytes --]
Hello people,
`git-push --all --tags` does not work because git-push ends up
calling git-send-pack --all refs/tags/*, which the latter does not
deal with.
Looking at the code, it seems that previously, --all would push
everything, not just refs/heads/*. What's the reason that this was
changed? Why aren't tags considered part of --all?
If I wanted to fix this, so that --all pushes heads and --all --tags
pushes heads and tags, I could do so in two ways:
1. instead of --all, pass refs/heads/* to git-send-pack
2. add --tags to git-send-pack
which of these two would you prefer and why?
Thanks,
--
martin; (greetings from the heart of the sun.)
\____ echo mailto: !#^."<*>"|tr "<*> mailto:" net@madduck
"imagine if every thursday your shoes exploded if you
tied them the usual way. this happens to us all the time
with computers, and nobody thinks of complaining."
-- jeff raskin
spamtraps: madduck.bogus@madduck.net
[-- Attachment #2: Digital signature (see http://martin-krafft.net/gpg/) --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: [PATCH] makefile: Add a cscope target
From: Kristof Provost @ 2007-10-06 14:24 UTC (permalink / raw)
To: Frank Lichtenheld; +Cc: git, Alex Riesen
In-Reply-To: <20071006010437.GS31659@planck.djpig.de>
[-- Attachment #1: Type: text/plain, Size: 1934 bytes --]
On 2007-10-06 03:04:37 (+0200), Frank Lichtenheld <frank@lichtenheld.de> wrote:
> On Sat, Oct 06, 2007 at 12:33:36AM +0200, Kristof Provost wrote:
> > +cscope:
> > + $(RM) cscope*
> > + $(FIND) . -name '*.hcS]' -print | xargs cscope -b
>
>
> missing [
Well, that will teach me to post patches after midnight.
Here's a fixed version. I've also added cscope* to the .gitignore file.
For some reason tags and TAGS weren't in there either so I've added them
too.
Signed-off-by: Kristof Provost <Kristof@provost-engineering.be>
---
diff --git a/.gitignore b/.gitignore
index e0b91be..62afef2 100644
--- a/.gitignore
+++ b/.gitignore
@@ -171,3 +171,6 @@ config.status
config.mak.autogen
config.mak.append
configure
+tags
+TAGS
+cscope*
diff --git a/Makefile b/Makefile
index 8db4dbe..e2790c8 100644
--- a/Makefile
+++ b/Makefile
@@ -947,6 +947,10 @@ tags:
$(RM) tags
$(FIND) . -name '*.[hcS]' -print | xargs ctags -a
+cscope:
+ $(RM) cscope*
+ $(FIND) . -name '*.[hcS]' -print | xargs cscope -b
+
### Detect prefix changes
TRACK_CFLAGS = $(subst ','\'',$(ALL_CFLAGS)):\
$(bindir_SQ):$(gitexecdir_SQ):$(template_dir_SQ):$(prefix_SQ)
@@ -1093,7 +1097,7 @@ clean:
$(LIB_FILE) $(XDIFF_LIB)
$(RM) $(ALL_PROGRAMS) $(BUILT_INS) git$X
$(RM) $(TEST_PROGRAMS)
- $(RM) *.spec *.pyc *.pyo */*.pyc */*.pyo common-cmds.h TAGS tags
+ $(RM) *.spec *.pyc *.pyo */*.pyc */*.pyo common-cmds.h TAGS tags cscope*
$(RM) -r autom4te.cache
$(RM) configure config.log config.mak.autogen config.mak.append config.status config.cache
$(RM) -r $(GIT_TARNAME) .doc-tmp-dir
@@ -1111,7 +1115,7 @@ endif
$(RM) GIT-VERSION-FILE GIT-CFLAGS GIT-GUI-VARS
.PHONY: all install clean strip
-.PHONY: .FORCE-GIT-VERSION-FILE TAGS tags .FORCE-GIT-CFLAGS
+.PHONY: .FORCE-GIT-VERSION-FILE TAGS tags cscope .FORCE-GIT-CFLAGS
### Check documentation
#
--
Kristof
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply related
* [PATCH] git-gui: accept versions containing text annotations, like 1.5.3.mingw.1
From: Steffen Prohaska @ 2007-10-06 13:27 UTC (permalink / raw)
To: git, Shawn O. Pearce; +Cc: Steffen Prohaska
This commit teaches git-gui to accept versions with annotations
that start with text and optionally end with a dot followed by
a number.
This is needed by the current versioning scheme of msysgit,
which uses versions like 1.5.3.mingw.1. However, the changes
is not limited to this use case. Any version of the form
<numeric version>.<anytext>.<number> would be parsed and only
the starting <numeric version> used for validation.
Signed-off-by: Steffen Prohaska <prohaska@zib.de>
---
git-gui/git-gui.sh | 1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/git-gui/git-gui.sh b/git-gui/git-gui.sh
index bb1e7f3..f671eea 100755
--- a/git-gui/git-gui.sh
+++ b/git-gui/git-gui.sh
@@ -666,6 +666,7 @@ regsub -- {-dirty$} $_git_version {} _git_version
regsub {\.[0-9]+\.g[0-9a-f]+$} $_git_version {} _git_version
regsub {\.rc[0-9]+$} $_git_version {} _git_version
regsub {\.GIT$} $_git_version {} _git_version
+regsub {\.[a-zA-Z]+(\.[0-9]+)$} $_git_version {} _git_version
if {![regexp {^[1-9]+(\.[0-9]+)+$} $_git_version]} {
catch {wm withdraw .}
--
1.5.3.mingw.1.106.g1610f-dirty
^ permalink raw reply related
* [PATCH] git-gui: try to locate git in same directory as git-gui (on Windows)
From: Steffen Prohaska @ 2007-10-06 9:36 UTC (permalink / raw)
To: git; +Cc: Steffen Prohaska
This commit adds another guess where git might be located.
After searching PATH the last fallback is the directory
in which git-gui is installed. This is a good guess for
a sane installation.
Even if git is not included in PATH, git-gui is now able
to locate it. Hence git-gui can be passed to wish
as an absolute path without caring about the environment.
PATH is searched first and the location of git-gui only
as a last resort. Maybe the order should be reversed?
Signed-off-by: Steffen Prohaska <prohaska@zib.de>
---
git-gui/git-gui.sh | 1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/git-gui/git-gui.sh b/git-gui/git-gui.sh
index 3f5927f..bb1e7f3 100755
--- a/git-gui/git-gui.sh
+++ b/git-gui/git-gui.sh
@@ -344,6 +344,7 @@ proc _which {what} {
set _search_exe .exe
} elseif {[is_Windows]} {
set _search_path [split $env(PATH) {;}]
+ lappend _search_path [file dirname [info script]]
set _search_exe .exe
} else {
set _search_path [split $env(PATH) :]
--
1.5.3.mingw.1.105.ga0fd0
^ permalink raw reply related
* Re: [PATCH 1/2] Have a filter_start/filter_end API.
From: Alex Riesen @ 2007-10-06 9:06 UTC (permalink / raw)
To: Pierre Habouzit; +Cc: Linus Torvalds, Junio C Hamano, git
In-Reply-To: <1191615571-15946-2-git-send-email-madcoder@debian.org>
Pierre Habouzit, Fri, Oct 05, 2007 22:19:30 +0200:
> Those are helpers to build functions that transform a buffer into a
> strbuf, allowing the "buffer" to be taken from the destination buffer.
They are horrible. And very specialized for these "filter" routines.
To the point where I would move them into the file where they are used
(convert.c only, isn't it?)
If you continue to insist the code is generic enough to justify its
residence in strbuf.c, continue reading.
First off, what was wrong with dumb
void strbuf_make_room(struct strbuf *, size_t newsize);
again?
> +void *strbuf_start_filter(struct strbuf *sb, const char *src, ssize_t hint)
> +{
> + if (src < sb->buf || src >= sb->buf + sb->alloc) {
> + if (hint > 0 && (size_t)hint >= sb->alloc)
> + strbuf_grow(sb, hint - sb->len);
> + return NULL;
> + }
> +
> + if (hint < 0)
> + return strbuf_detach(sb, NULL);
what is that for? Why can't the caller just use strbuf_detach? (He
already has to pass negative hint somehow, which should be a concious
action).
> +
trailing space (two HTs)
> + if ((size_t)hint >= sb->alloc) {
> + void *tmp = strbuf_detach(sb, NULL);
> + strbuf_grow(sb, hint);
> + return tmp;
> + }
> +
> + return NULL;
> +}
How can one know when it sb is safe to use after strbuf_end_filter?
It is for the first "if", for example. free() wont free the buf in sb.
Oh, right, one can check if returned pointer !NULL. Which just adds
more code to handle your API.
What actually happens to sb? Is it detached? Is it reallocated?
When it is detached and when it is reallocated?
Why is the returned pointer useful only for giving it to
strbuf_end_filter?
Take for example your change in crlf_to_git:
@@ -85,6 +85,7 @@ static int crlf_to_git(const char *path, const char *src, size_t len,
{
struct text_stat stats;
char *dst;
+ void *tmp;
if ((action == CRLF_BINARY) || !auto_crlf || !len)
return 0;
@@ -110,9 +111,7 @@ static int crlf_to_git(const char *path, const char *src, size_t len,
return 0;
}
- /* only grow if not in place */
- if (strbuf_avail(buf) + buf->len < len)
- strbuf_grow(buf, len - buf->len);
+ tmp = strbuf_start_filter(buf, src, len);
dst = buf->buf;
if (action == CRLF_GUESS) {
/*
@@ -133,13 +132,14 @@ static int crlf_to_git(const char *path, const char *src, size_t len,
} while (--len);
}
strbuf_setlen(buf, dst - buf->buf);
+ strbuf_end_filter(tmp);
return 1;
}
And try to rewrite it with the strbuf_make_room:
@@ -110,9 +111,7 @@ static int crlf_to_git(const char *path, const char *src, size_t len,
return 0;
}
- /* only grow if not in place */
- if (strbuf_avail(buf) + buf->len < len)
- strbuf_grow(buf, len - buf->len);
+ strbuf_make_room(buf, len);
dst = buf->buf;
if (action == CRLF_GUESS) {
/*
The change looks rather simple
> +/*----- filter API -----*/
> +extern void *strbuf_start_filter(struct strbuf *, const char *, ssize_t);
> +extern void strbuf_end_filter(void *p);
I find the naming very confusing: what filtering takes place where?
If strbuf_end_filter is just free, why is it needed at all? For the
sake of wrapping free()?
^ permalink raw reply
* Re: Many gits are offline this week
From: Lars Hjemli @ 2007-10-06 9:05 UTC (permalink / raw)
To: Shawn O. Pearce, Junio C Hamano; +Cc: git
In-Reply-To: <20071005010448.GQ2137@spearce.org>
On 10/5/07, Shawn O. Pearce <spearce@spearce.org> wrote:
> With three gits offline for at least the next few days perhaps
> someone would be willing to step up and collect patches so that Junio
> has a reasonable place to pick up from when he can get back online?
I'll collect patches from the list for a few days and put them into
topic-branches on git://hjemli.net/pub/git/git.
--
larsh
^ permalink raw reply
* Re: [ALTERNATE PATCH] Add a simple option parser.
From: Sven Verdoolaege @ 2007-10-06 8:46 UTC (permalink / raw)
To: Pierre Habouzit; +Cc: David Kastrup, git
In-Reply-To: <20071005163846.GE20305@artemis.corp>
On Fri, Oct 05, 2007 at 06:38:46PM +0200, Pierre Habouzit wrote:
> The real issue is dependency and bloat. getopt_long would need the GNU
> implementation, That I believe depends upon gettext, and argp is just
> bloated, and I'm not even sure it's distributed outside from the glibc
> anyways.
It's part of gnulib (http://savannah.gnu.org/git/?group=gnulib).
Including argp (and all its dependencies) is as easy as running some
gnulib command.
It does have some bloat, but for my project it was definitely more
convenient to include it than to write my own parser and the bloat
is still acceptable I suppose...
bash-3.00$ du lib m4
572 lib
208 m4
bash-3.00$ du -s .
20348 .
(In a source tree without the git repo.)
skimo
^ permalink raw reply
* Re: [PATCH] makefile: Add a cscope target
From: Alex Riesen @ 2007-10-06 8:23 UTC (permalink / raw)
To: Kristof Provost; +Cc: git
In-Reply-To: <20071005223336.GA4556@luggage>
Kristof Provost, Sat, Oct 06, 2007 00:33:36 +0200:
> +cscope:
> + $(RM) cscope*
You may want to add the cscope* to .gitignore
^ permalink raw reply
* Re: [PATCH 2/2] Run garbage collection with loose object pruning after svn dcommit
From: Peter Baumann @ 2007-10-06 8:15 UTC (permalink / raw)
To: Steven Grimm; +Cc: Eric Wong, git
In-Reply-To: <470678ED.8050407@midwinter.com>
On Fri, Oct 05, 2007 at 10:48:29AM -0700, Steven Grimm wrote:
> Peter Baumann wrote:
>> That's new to me. Glancing over git-commit.sh, I could only find a
>> 'git-gc --auto', but no prune. I am not against doing a 'git gc --auto',
>> but I am against the --prune, because this could make shared
>> repositories unfunctional.
>>
>
> Does anyone run "git svn dcommit" from a shared repository? That is the
> only command that will trigger this code path.
>
> Given that you lose all the svn metadata if you do "git clone" (or "git
> clone -s") on a git-svn-managed repository, it's not clear to me that
> anyone would ever be bitten by this. Counterexamples welcome, of course.
>
> How would you feel about a separate config option to specifically enable
> auto-pruning, and having "git svn clone" set that option by default?
> Presumably anyone who is setting up a shared git-svn repository will be up
> to the task of disabling the option.
>
Sorry, I looked at 'git commit' (as you said in your mail) and not
'git-svn dcommit'. Looking now at git-svn, I could see the there is only
done a git-repack if the user *explicitly* asked for it on the cmdline
specifying --repack. For this repack run, the default parameter includes
-d and no --prune, so I do not think that we are doing a --prune run if
we where not _explicitly_ asked for it. As I said, I am totaly fine with
doing a 'git-gc --auto', but I am a little worried about the --prune.
We advertise everywhere that GIT adds only new content/objects/data to the
repository and *never* deletes anything itself in the repo and now you
want to do a --prune, wich obviously *does* delete data behind the users
back in a dcommit/fetch operation, which no one would think of that these
commands do have anything in common with deleting data. And this worries me.
-Peter
^ permalink raw reply
* Re: Question about "git commit -a"
From: Andy Parkins @ 2007-10-06 7:43 UTC (permalink / raw)
To: git
Cc: Marko Macek, Kristian Høgsberg, Andreas Ericsson,
Paolo Ciarrocchi, Johannes Schindelin, Nguyen Thai Ngoc Duy,
Wincent Colaiuta
In-Reply-To: <47067F68.2080709@gmx.net>
On Friday 2007, October 05, Marko Macek wrote:
> In CVS and subversion (which has nicer working-copy command line
> interface IMHO), I simply make a copy of the working copy, revert the
> non-commitable parts, build, commit the minor changes, and then update
> the first copy. For larger projects, where this can be slow, I use
> diff/revert/patch.
>
> Small checkins are nice for git-bisect, but if they don't build...
Who cares? Commits that build isn't the only reason for small commits.
git-bisect is nice and small buildable commits is something to aim for.
However, there is more to software history that buildable commits.
I hardly ever git-bisect, and I hardly ever checkout old revisions, however
I read the log _all the time_. The smaller the commit and the better the
log message the more quickly I'll understand what was going on. In the end
even if the commit doesn't build as long as the log message is a good
description of what the commit does and that thing is an isolated change
then the revision has achieved its goal for me.
Andy
--
Dr Andy Parkins, M Eng (hons), MIET
andyparkins@gmail.com
^ permalink raw reply
* Re: [PATCH] makefile: Add a cscope target
From: Frank Lichtenheld @ 2007-10-06 1:04 UTC (permalink / raw)
To: Kristof Provost; +Cc: git
In-Reply-To: <20071005223336.GA4556@luggage>
On Sat, Oct 06, 2007 at 12:33:36AM +0200, Kristof Provost wrote:
> +cscope:
> + $(RM) cscope*
> + $(FIND) . -name '*.hcS]' -print | xargs cscope -b
missing [
Gruesse,
--
Frank Lichtenheld <frank@lichtenheld.de>
www: http://www.djpig.de/
^ permalink raw reply
* Re: [PATCH 2/2] Run garbage collection with loose object pruning after svn dcommit
From: Eric Wong @ 2007-10-05 23:54 UTC (permalink / raw)
To: Steven Grimm; +Cc: git
In-Reply-To: <20071005001528.GA13029@midwinter.com>
Steven Grimm <koreth@midwinter.com> wrote:
> git-svn dcommit, by virtue of rewriting history to insert svn revision IDs,
> leaves old commits dangling. Since dcommit is already unsafe to run
> concurrently with other git commands, no additional risk is introduced
> by making it prune those old objects as needed.
>
> Signed-off-by: Steven Grimm <koreth@midwinter.com>
> ---
>
> This is in response to a colleague who complained that, after I
> installed the latest git release, he was getting lots of "too many
> unreachable loose objects" errors from the new "git gc --auto" run.
> Those objects turned out to be dangling commits from a year's worth of
> git-svn usage, since every git-svn commit will abandon at least one
> existing commit in order to rewrite it with the svn version data.
I'm not a fan of automatic gc in general, but I understand it can
help new users. So as long as clueful users can easily disable it,
then it's fine by me...
> git-svn.perl | 6 ++++++
> 1 files changed, 6 insertions(+), 0 deletions(-)
>
> diff --git a/git-svn.perl b/git-svn.perl
> index 777e436..be62ee1 100755
> --- a/git-svn.perl
> +++ b/git-svn.perl
> @@ -441,6 +441,12 @@ sub cmd_dcommit {
> }
> command_noisy(@finish, $gs->refname);
> $last_rev = $cmt_rev;
> +
> + # rebase will have made the just-committed revisions
> + # unreachable; over time that can build up lots of
> + # loose objects in the repo. prune is unsafe to run
> + # concurrently but so is dcommit.
> + command_noisy(qw/gc --auto --prune/);
> }
> }
> }
This is better called outside of this loop. We now do a rebase after
every revision committed (which gets us even more dangling commits);
but we only want to call git-gc after everything is committed.
It'll be faster since git-gc is only invoked once, and if git-gc takes a
very long time to repack, we won't have to worry about timing out a SVN
network connection. It'll also reduce the window for somebody else to
commit a conflicting change that'll cause dcommit to fail midway
through.
As far as Peter's concerns for shared repositories go, I'm not sure...
I've never been comfortable with shared repositories myself (even in a
pure git environment without git-svn) and always just preferred using
full clones or copies[1] myself so I could rm -r any working directory
and not worry about any other repositories relying on it.
[1] - I usually go about using cp -al + libflcow :)
--
Eric Wong
^ permalink raw reply
* Re: git-svn, svn:externals, git-submodules?
From: Eric Wong @ 2007-10-05 23:14 UTC (permalink / raw)
To: Benoit SIGOURE; +Cc: git list
In-Reply-To: <DEC49034-D594-4F4E-89E6-B98A3D4A8825@lrde.epita.fr>
Benoit SIGOURE <tsuna@lrde.epita.fr> wrote:
> Hello,
> is there any plan to support svn:externals in git-svn with git-
> submodules? If yes, where can we see the on-going work? If no, is
> anyone already planning to implement this? If no, has anyone
> anything to say about the idea? I could give it a try as I really
> need this feature to properly interoperate with SVN repositories.
> Many of my friends and co-workers also need it.
I hope to support it at some point, but some point could be anywhere
from days to months away depending on other things I'm working on...
I've barely looked at git-submodules myself. To my knowledge there's no
on-going work for it.
--
Eric Wong
^ permalink raw reply
* [PATCH] makefile: Add a cscope target
From: Kristof Provost @ 2007-10-05 22:33 UTC (permalink / raw)
To: git
[-- Attachment #1: Type: text/plain, Size: 1362 bytes --]
The current makefile supports ctags but not cscope. Some people prefer
cscope (I do), so this patch adds a cscope target.
Signed-off-by: Kristof Provost <Kristof@provost-engineering.be>
---
diff --git a/Makefile b/Makefile
index 8db4dbe..42c9e94 100644
--- a/Makefile
+++ b/Makefile
@@ -947,6 +947,10 @@ tags:
$(RM) tags
$(FIND) . -name '*.[hcS]' -print | xargs ctags -a
+cscope:
+ $(RM) cscope*
+ $(FIND) . -name '*.hcS]' -print | xargs cscope -b
+
### Detect prefix changes
TRACK_CFLAGS = $(subst ','\'',$(ALL_CFLAGS)):\
$(bindir_SQ):$(gitexecdir_SQ):$(template_dir_SQ):$(prefix_SQ)
@@ -1093,7 +1097,7 @@ clean:
$(LIB_FILE) $(XDIFF_LIB)
$(RM) $(ALL_PROGRAMS) $(BUILT_INS) git$X
$(RM) $(TEST_PROGRAMS)
- $(RM) *.spec *.pyc *.pyo */*.pyc */*.pyo common-cmds.h TAGS tags
+ $(RM) *.spec *.pyc *.pyo */*.pyc */*.pyo common-cmds.h TAGS tags cscope*
$(RM) -r autom4te.cache
$(RM) configure config.log config.mak.autogen config.mak.append config.status config.cache
$(RM) -r $(GIT_TARNAME) .doc-tmp-dir
@@ -1111,7 +1115,7 @@ endif
$(RM) GIT-VERSION-FILE GIT-CFLAGS GIT-GUI-VARS
.PHONY: all install clean strip
-.PHONY: .FORCE-GIT-VERSION-FILE TAGS tags .FORCE-GIT-CFLAGS
+.PHONY: .FORCE-GIT-VERSION-FILE TAGS tags cscope .FORCE-GIT-CFLAGS
### Check documentation
#
--
Kristof
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ 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