* Re: [PATCH] git-gui: suggest gc only when counting at least 2 objects
From: Clemens Buchacher @ 2009-09-13 18:41 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, msysgit, Shawn O. Pearce
In-Reply-To: <7vr5uasp4a.fsf@alter.siamese.dyndns.org>
On Sun, Sep 13, 2009 at 10:58:45AM -0700, Junio C Hamano wrote:
> Somebody cares to explain why this threashold number has to be different
> per platform in the first place?
I really don't know. I vaguely remember someone claim that performance on
Windows suffered from many loose objects more than on other platforms. I
can't find any discussion of it though.
^ permalink raw reply
* Re: [PATCH 1/2] git-archive: add '-o' as a alias for '--output'
From: Junio C Hamano @ 2009-09-13 18:34 UTC (permalink / raw)
To: Dmitry Potapov; +Cc: git, John Tapsell
In-Reply-To: <1252863407-2598-1-git-send-email-dpotapov@gmail.com>
Dmitry Potapov <dpotapov@gmail.com> writes:
> The '-o' option is commonly used in many tools to specify the output file.
> Typing '--output' every time is a bit too long to be a practical alternative
> to redirecting output. But specifying the output name has the advantage of
> making possible to guess the desired output format by filename extension.
>
> Signed-off-by: Dmitry Potapov <dpotapov@gmail.com>
> ---
> ...
> diff --git a/Documentation/git-archive.txt b/Documentation/git-archive.txt
> index 92444dd..f7a3b95 100644
> --- a/Documentation/git-archive.txt
> +++ b/Documentation/git-archive.txt
> @@ -48,6 +48,7 @@ OPTIONS
> --prefix=<prefix>/::
> Prepend <prefix>/ to each filename in the archive.
>
> +-o::
> --output=<file>::
> Write the archive to <file> instead of stdout.
I think this patch is very reasonable, except for this hunk, which would
want to say "-o <file>::" instead. I'll see if there are comments from
others and if there is none, apply this patch with that minor tweak.
Thanks.
^ permalink raw reply
* Re: [PATCH] completion: Replace config --list with --get-regexp
From: Todd Zullinger @ 2009-09-13 18:29 UTC (permalink / raw)
To: Bert Wesarg; +Cc: Shawn O. Pearce, Jeff King, james bardin, git, Junio C Hamano
In-Reply-To: <36ca99e90909130351m7ad5a641t8adb3ade3d2ec5ca@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 806 bytes --]
Bert Wesarg wrote:
> I have not looked into this, but what about pushurl?
Is it reasonable to expect someone to have remote.<name>.pushurl and
not have remote.<name>.url set? If not, then we should be fine, as
all the old code and this new code do is extract <name>.
OTOH, if there are some cases where setting pushurl and not url make
sense, extending the regex to catch pushurl as well is a simple matter
of changing 'remote\..*\.url' to 'remote\..*\.(push)?url' and, I
believe, using 'echo "${i/.*url*/}"' to strip off everything after the
remote <name>.
--
Todd OpenPGP -> KeyID: 0xBEAF0CE3 | URL: www.pobox.com/~tmz/pgp
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Fleas can be taught nearly anything that a Congressman can.
-- Mark Twain
[-- Attachment #2: Type: application/pgp-signature, Size: 542 bytes --]
^ permalink raw reply
* Re: rename tracking and file-name swapping
From: Junio C Hamano @ 2009-09-13 18:14 UTC (permalink / raw)
To: Yuri D'Elia; +Cc: git
In-Reply-To: <wavexx-2ECE7F.13171313092009@ger.gmane.org>
Yuri D'Elia <wavexx@users.sf.net> writes:
> Hi everyone. Does rename tracking recognize two file names being swapped?
>
> % ls -l
> total 24
> -rw-rw-r-- 1 wavexx wavexx 5952 Sep 13 13:09 file1.txt
> -rw-rw-r-- 1 wavexx wavexx 3330 Sep 13 13:09 file2.txt
> % mv file1.txt file3.txt
> % mv file2.txt file1.txt
> % mv file3.txt file2.txt
> % git add file1.txt file2.txt
> % git diff -M --stat --cached
> file1.txt | 150 +++++++++++++++++++++++-------------------------------------
> file2.txt | 150 +++++++++++++++++++++++++++++++++++++-----------------------
> 2 files changed, 150 insertions(+), 150 deletions(-)
By default, if the pathname that was present in the old version still
appears in the new version, that path is not considered as a candiate
for rename detection. Only "X used to be there but is gone" and "Y did
not exist but appeared" are paired up and checked if they are similar.
Give the command -B option, too, to break the filepair that does not
disappear.
^ permalink raw reply
* Re: [PATCH] git-gui: suggest gc only when counting at least 2 objects
From: Junio C Hamano @ 2009-09-13 17:58 UTC (permalink / raw)
To: Clemens Buchacher; +Cc: git, msysgit, Shawn O. Pearce
In-Reply-To: <20090913160637.GA15256@localhost>
Clemens Buchacher <drizzd@aon.at> writes:
> On Windows, git-gui suggests running the garbage collector if it finds
> 1 or more files in .git/objects/42 (as opposed to 8 files on other
> platforms).
Somebody cares to explain why this threashold number has to be different
per platform in the first place? Instead of bumping up to 2 like your
patch did, what bad things would happen if you increased it to 8 on
Windows? Doesn't the same badness happen on non-Windows because they have
the threashold set to 8 already?
^ permalink raw reply
* [PATCH 2/2] teach git-archive to auto detect the output format
From: Dmitry Potapov @ 2009-09-13 17:36 UTC (permalink / raw)
To: Junio C Hamano, git; +Cc: John Tapsell, Dmitry Potapov
In-Reply-To: <1252863407-2598-1-git-send-email-dpotapov@gmail.com>
When I type something like this:
git archive -o my-v2.0.zip v2.0
it is almost certainly that I want to create a zip archive, and not
a tar file.
This patch teaches git-archive to auto detect the output format from the
file name. Currently, only '.zip' is supported. If the auto detect failed,
the tar format is used as default. The auto detect is not used when the
output format is specified explicitly.
Signed-off-by: Dmitry Potapov <dpotapov@gmail.com>
---
On Sat, Sep 12, 2009 at 07:47:21PM -0700, Junio C Hamano wrote:
> John Tapsell <johnflux@gmail.com> writes:
>_
> > Why not have --format=tgz then or something? Or better yet, give
> > the filename on the command line and detect the format from the file
> > extension.
>_
> That is an interesting enhancement and sounds like a useful feature.
Here is my first attempt to implement that. I have not added 'tgz' yet,
but only auto detect the format from the output file name.
PS I resend this patch because I forgot to include the git mailing list when
I sent it before. Sorry for inconvinience...
Documentation/git-archive.txt | 10 +++++++++-
builtin-archive.c | 25 +++++++++++++++++++++++++
2 files changed, 34 insertions(+), 1 deletions(-)
diff --git a/Documentation/git-archive.txt b/Documentation/git-archive.txt
index f7a3b95..c6fb21c 100644
--- a/Documentation/git-archive.txt
+++ b/Documentation/git-archive.txt
@@ -35,7 +35,9 @@ OPTIONS
--format=<fmt>::
Format of the resulting archive: 'tar' or 'zip'. The default
- is 'tar'.
+ is 'tar', unless the output file is specified, and it has a known
+ extension (such as '.zip') then the default for the output format
+ will be determined by this extension.
-l::
--list::
@@ -130,6 +132,12 @@ git archive --format=zip --prefix=git-docs/ HEAD:Documentation/ > git-1.4.0-docs
Put everything in the current head's Documentation/ directory
into 'git-1.4.0-docs.zip', with the prefix 'git-docs/'.
+git archive -o latest.zip HEAD::
+
+ Create a Zip archive that contains the contents of the latest
+ commit on the current branch. Note that the output format is
+ specified implicitly by the extension of the output file.
+
SEE ALSO
--------
diff --git a/builtin-archive.c b/builtin-archive.c
index 565314b..878c6b2 100644
--- a/builtin-archive.c
+++ b/builtin-archive.c
@@ -60,6 +60,17 @@ static int run_remote_archiver(int argc, const char **argv,
return !!rv;
}
+static const char* format_from_name(const char *filename)
+{
+ const char *ext = strrchr(filename, '.');
+ if (!ext)
+ return NULL;
+ ext++;
+ if (!strcasecmp(ext, "zip"))
+ return "zip";
+ return NULL;
+}
+
#define PARSE_OPT_KEEP_ALL ( PARSE_OPT_KEEP_DASHDASH | \
PARSE_OPT_KEEP_ARGV0 | \
PARSE_OPT_KEEP_UNKNOWN | \
@@ -70,6 +81,7 @@ int cmd_archive(int argc, const char **argv, const char *prefix)
const char *exec = "git-upload-archive";
const char *output = NULL;
const char *remote = NULL;
+ const char *format = NULL;
struct option local_opts[] = {
OPT_STRING('o', "output", &output, "file",
"write the archive to this file"),
@@ -77,14 +89,27 @@ int cmd_archive(int argc, const char **argv, const char *prefix)
"retrieve the archive from remote repository <repo>"),
OPT_STRING(0, "exec", &exec, "cmd",
"path to the remote git-upload-archive command"),
+ OPT_STRING(0, "format", &format, "fmt", "archive format"),
OPT_END()
};
+ char fmt_opt[32];
argc = parse_options(argc, argv, prefix, local_opts, NULL,
PARSE_OPT_KEEP_ALL);
if (output)
+ {
create_output_file(output);
+ if (!format)
+ format = format_from_name(output);
+ }
+
+ if (format)
+ {
+ sprintf(fmt_opt, "--format=%s", format);
+ argv[argc++] = fmt_opt;
+ argv[argc] = NULL;
+ }
if (remote)
return run_remote_archiver(argc, argv, remote, exec);
--
1.6.4
^ permalink raw reply related
* [PATCH 1/2] git-archive: add '-o' as a alias for '--output'
From: Dmitry Potapov @ 2009-09-13 17:36 UTC (permalink / raw)
To: Junio C Hamano, git; +Cc: John Tapsell, Dmitry Potapov
In-Reply-To: <7v3a6r5znq.fsf@alter.siamese.dyndns.org>
The '-o' option is commonly used in many tools to specify the output file.
Typing '--output' every time is a bit too long to be a practical alternative
to redirecting output. But specifying the output name has the advantage of
making possible to guess the desired output format by filename extension.
Signed-off-by: Dmitry Potapov <dpotapov@gmail.com>
---
PS I resend this patch because I forgot to include the git mailing list when
I sent it before. Sorry for inconvinience...
Documentation/git-archive.txt | 3 ++-
archive.c | 2 +-
builtin-archive.c | 2 +-
3 files changed, 4 insertions(+), 3 deletions(-)
diff --git a/Documentation/git-archive.txt b/Documentation/git-archive.txt
index 92444dd..f7a3b95 100644
--- a/Documentation/git-archive.txt
+++ b/Documentation/git-archive.txt
@@ -10,7 +10,7 @@ SYNOPSIS
--------
[verse]
'git archive' [--format=<fmt>] [--list] [--prefix=<prefix>/] [<extra>]
- [--output=<file>] [--worktree-attributes]
+ [-o | --output=<file>] [--worktree-attributes]
[--remote=<repo> [--exec=<git-upload-archive>]] <tree-ish>
[path...]
@@ -48,6 +48,7 @@ OPTIONS
--prefix=<prefix>/::
Prepend <prefix>/ to each filename in the archive.
+-o::
--output=<file>::
Write the archive to <file> instead of stdout.
diff --git a/archive.c b/archive.c
index 0bca9ca..73b8e8a 100644
--- a/archive.c
+++ b/archive.c
@@ -283,7 +283,7 @@ static int parse_archive_args(int argc, const char **argv,
OPT_STRING(0, "format", &format, "fmt", "archive format"),
OPT_STRING(0, "prefix", &base, "prefix",
"prepend prefix to each pathname in the archive"),
- OPT_STRING(0, "output", &output, "file",
+ OPT_STRING('o', "output", &output, "file",
"write the archive to this file"),
OPT_BOOLEAN(0, "worktree-attributes", &worktree_attributes,
"read .gitattributes in working directory"),
diff --git a/builtin-archive.c b/builtin-archive.c
index f9a4bea..565314b 100644
--- a/builtin-archive.c
+++ b/builtin-archive.c
@@ -71,7 +71,7 @@ int cmd_archive(int argc, const char **argv, const char *prefix)
const char *output = NULL;
const char *remote = NULL;
struct option local_opts[] = {
- OPT_STRING(0, "output", &output, "file",
+ OPT_STRING('o', "output", &output, "file",
"write the archive to this file"),
OPT_STRING(0, "remote", &remote, "repo",
"retrieve the archive from remote repository <repo>"),
--
1.6.4
^ permalink raw reply related
* [PATCH] reflog: Usage documentation cleanup
From: Nelson Elhage @ 2009-09-13 17:23 UTC (permalink / raw)
To: git; +Cc: Nelson Elhage
* Make git-reflog.txt and the builtin usage text consistent.
* Make 'git reflog expire' not claim that 'show' takes the same
arguments as 'expire'.
* Document -n as an alias for --dry-run for the expire and delete
subcommands.
---
Documentation/git-reflog.txt | 5 +++--
builtin-reflog.c | 4 ++--
2 files changed, 5 insertions(+), 4 deletions(-)
Thanks to Jeff King and Erik Faye-Lund for both pointing out that 'git
reflog expire' is probably wrong to be documenting the 'show' command
in the first place, which makes this cleanup much saner.
diff --git a/Documentation/git-reflog.txt b/Documentation/git-reflog.txt
index 7f7a544..2c90c2c 100644
--- a/Documentation/git-reflog.txt
+++ b/Documentation/git-reflog.txt
@@ -16,10 +16,11 @@ The command takes various subcommands, and different options
depending on the subcommand:
[verse]
-'git reflog expire' [--dry-run] [--stale-fix] [--verbose]
+'git reflog expire' [-n | --dry-run] [--stale-fix] [--verbose]
[--expire=<time>] [--expire-unreachable=<time>] [--all] <refs>...
+
-'git reflog delete' ref@\{specifier\}...
+'git reflog delete [--verbose] [-n | --dry-run] [--rewrite]
+ [--updateref] ref@\{specifier}\...'
+
'git reflog' ['show'] [log-options] [<ref>]
diff --git a/builtin-reflog.c b/builtin-reflog.c
index 95198c5..4da5c6b 100644
--- a/builtin-reflog.c
+++ b/builtin-reflog.c
@@ -13,9 +13,9 @@
*/
static const char reflog_expire_usage[] =
-"git reflog (show|expire) [--verbose] [--dry-run] [--stale-fix] [--expire=<time>] [--expire-unreachable=<time>] [--all] <refs>...";
+"git reflog expire [--verbose] [-n | --dry-run] [--stale-fix] [--expire=<time>] [--expire-unreachable=<time>] [--all] <refs>...";
static const char reflog_delete_usage[] =
-"git reflog delete [--verbose] [--dry-run] [--rewrite] [--updateref] <refs>...";
+"git reflog delete [--verbose] [-n | --dry-run] [--rewrite] [--updateref] ref@{specifier}...";
static unsigned long default_reflog_expire;
static unsigned long default_reflog_expire_unreachable;
--
1.6.3.1.499.ge7b8da
^ permalink raw reply related
* Re: [PATCH] git-push: Accept -n as a synonym for --dry-run.
From: Nelson Elhage @ 2009-09-13 17:07 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vd45v2za4.fsf@alter.siamese.dyndns.org>
On Sat, Sep 12, 2009 at 10:23:47PM -0700, Junio C Hamano wrote:
> Nelson Elhage <nelhage@MIT.EDU> writes:
>
> > ... I think my
> > general argument still stands for commands where that is not the case.
>
> Cool down.
>
> It is a mere subset of what I already said, so you are not arguing against
> me at all.
My apologies for continuing an argument where there was none. I've
sent a patch with an improved commit message, and we can continue
discussing on that thread if necessary.
- Nelson
^ permalink raw reply
* [PATCH v2] git-push: Accept -n as a synonym for --dry-run.
From: Nelson Elhage @ 2009-09-13 16:56 UTC (permalink / raw)
To: git; +Cc: Nelson Elhage
git-push is not currently using -n for anything else, and it seems
unlikely we will want to use it to mean anything else in the future,
so add it as an alias for convenience.
Signed-off-by: Nelson Elhage <nelhage@mit.edu>
---
Documentation/git-push.txt | 3 ++-
builtin-push.c | 4 ++--
2 files changed, 4 insertions(+), 3 deletions(-)
diff --git a/Documentation/git-push.txt b/Documentation/git-push.txt
index 58d2bd5..ba6a8a2 100644
--- a/Documentation/git-push.txt
+++ b/Documentation/git-push.txt
@@ -9,7 +9,7 @@ git-push - Update remote refs along with associated objects
SYNOPSIS
--------
[verse]
-'git push' [--all | --mirror | --tags] [--dry-run] [--receive-pack=<git-receive-pack>]
+'git push' [--all | --mirror | --tags] [-n | --dry-run] [--receive-pack=<git-receive-pack>]
[--repo=<repository>] [-f | --force] [-v | --verbose]
[<repository> <refspec>...]
@@ -82,6 +82,7 @@ nor in any Push line of the corresponding remotes file---see below).
if the configuration option `remote.<remote>.mirror` is
set.
+-n::
--dry-run::
Do everything except actually send the updates.
diff --git a/builtin-push.c b/builtin-push.c
index 787011f..5e5f3ad 100644
--- a/builtin-push.c
+++ b/builtin-push.c
@@ -10,7 +10,7 @@
#include "parse-options.h"
static const char * const push_usage[] = {
- "git push [--all | --mirror] [--dry-run] [--porcelain] [--tags] [--receive-pack=<git-receive-pack>] [--repo=<repository>] [-f | --force] [-v] [<repository> <refspec>...]",
+ "git push [--all | --mirror] [-n | --dry-run] [--porcelain] [--tags] [--receive-pack=<git-receive-pack>] [--repo=<repository>] [-f | --force] [-v] [<repository> <refspec>...]",
NULL,
};
@@ -182,7 +182,7 @@ int cmd_push(int argc, const char **argv, const char *prefix)
OPT_BIT( 0 , "mirror", &flags, "mirror all refs",
(TRANSPORT_PUSH_MIRROR|TRANSPORT_PUSH_FORCE)),
OPT_BOOLEAN( 0 , "tags", &tags, "push tags"),
- OPT_BIT( 0 , "dry-run", &flags, "dry run", TRANSPORT_PUSH_DRY_RUN),
+ OPT_BIT('n' , "dry-run", &flags, "dry run", TRANSPORT_PUSH_DRY_RUN),
OPT_BIT( 0, "porcelain", &flags, "machine-readable output", TRANSPORT_PUSH_PORCELAIN),
OPT_BIT('f', "force", &flags, "force updates", TRANSPORT_PUSH_FORCE),
OPT_BOOLEAN( 0 , "thin", &thin, "use thin pack"),
--
1.6.3.1.499.ge7b8da
^ permalink raw reply related
* Re: git push --confirm ?
From: Uri Okrent @ 2009-09-13 16:59 UTC (permalink / raw)
To: Jeff King; +Cc: Junio C Hamano, Owen Taylor, git, Colin Walters
In-Reply-To: <20090913105247.GA21750@coredump.intra.peff.net>
Jeff King wrote:
[snip]
> Besides being a lot more annoying to implement, there is one big
> downside: in many cases the single TCP connection is a _feature_. If you
> are pushing via ssh and providing a password manually, it is a
> significant usability regression to have to input it twice.
>
> Also, given that ssh is going to be by far the biggest transport for
> pushing via the git protocol, I suspect any timeouts are set for
> _before_ the authentication phase (i.e., SSH times you out if you don't
> actually log in). So in that sense it may not be worth worrying about
> how long we take during the push itself.
That doesn't seem like a huge hurdle to overcome. Most ssh clients support some
sort of ServerAliveInterval parameter for just this reason. Sending a keep alive
packet every 60 seconds or so while waiting for user confirmation doesn't seem
all that egregious.
--
Uri
Please consider the environment before printing this message.
http://www.panda.org/how_you_can_help/
^ permalink raw reply
* [PATCH] git-gui: suggest gc only when counting at least 2 objects
From: Clemens Buchacher @ 2009-09-13 16:06 UTC (permalink / raw)
To: git; +Cc: msysgit, Junio C Hamano, Shawn O. Pearce
In-Reply-To: <20090909195158.GA12968@localhost>
On Windows, git-gui suggests running the garbage collector if it finds
1 or more files in .git/objects/42 (as opposed to 8 files on other
platforms). The probability of that happening if the repo contains
only about 100 loose objects is 32%. The probability for the same to happen
with at least 2 files is only 6%, which is bit more reasonable.
The following octave script shows the probability for m or more
objects to be in .git/objects/42 for a total of n objects.
m = [1 2 8];
n = 100:100:3000;
P = zeros(length(n), length(m));
for k = 1:length(n)
P(k, :) = 1-binocdf(m-1, n(k), 1/255);
end
plot(n, P);
n \ m 1 2 8
100 32% 6% 0%
500 86% 58% 0%
1000 98% 90% 5%
2000 100% 100% 55%
Signed-off-by: Clemens Buchacher <drizzd@aon.at>
---
So here is the patch for my other complaint. Note that I fixed a bug in the
octave script above, in case someone wants to check the numbers.
I even tested it on a windows VM (as if it wasn't slow enough already).
Clemens
git-gui/lib/database.tcl | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/git-gui/lib/database.tcl b/git-gui/lib/database.tcl
index a18ac8b..44099e5 100644
--- a/git-gui/lib/database.tcl
+++ b/git-gui/lib/database.tcl
@@ -91,7 +91,7 @@ proc do_fsck_objects {} {
proc hint_gc {} {
set object_limit 8
if {[is_Windows]} {
- set object_limit 1
+ set object_limit 2
}
set objects_current [llength [glob \
--
1.6.5.rc0.164.g5f6b0
^ permalink raw reply related
* [ANNOUNCE] Stacked Git 0.15-rc3
From: Catalin Marinas @ 2009-09-13 16:01 UTC (permalink / raw)
To: Git Mailing List; +Cc: Karl Wiberg
The third release candidate for StGit 0.15 is available from the
git://repo.or.cz/stgit.git or http://download.gna.org/stgit/. Bugs can
be reported on the Git mailing list or via the project bugs page
(https://gna.org/bugs/?group=stgit).
StGit is a Python application providing similar functionality to Quilt
(i.e. pushing/popping patches to/from a stack) on top of Git. These
operations are performed using Git commands and the patches are stored
as Git commit objects, allowing easy merging of the StGit patches into
other repositories using standard Git functionality.
Unless there are major issues, the aim is for this to be the last
release candidate before 0.15.
The main changes since release 0.15-rc2:
- 'stg import' command fixes to allow the importing of 'git show' output
and also support the -pN option for stripping leading slashes from
diff paths. The author date when importing e-mails is also preserved
- Generate binary diffs by default when exporting patches
- Other bug-fixes
Acknowledgements:
Catalin Marinas (7):
Add stg-build, stg-dbg and RELEASENOTES to the MANIFEST.in file
Merge commit 'kha/safe'
Import git show output easily
Merge commit 'kha/safe'
Add import -p option
Preserve the given author date during import
Generate binary diffs by default
David Kågedal (1):
Escape patch name when creating regexp
Karl Wiberg (2):
When reading a config value, pick the last value, not the first
squash: Make commit message editing more convenient
--
Catalin
^ permalink raw reply
* Re: [PATCH] transport-helper.c: don't leak fdopen'd stream buffers
From: Johannes Sixt @ 2009-09-13 15:20 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Jim Meyering, git list, Daniel Barkalow
In-Reply-To: <7vtyz760lm.fsf@alter.siamese.dyndns.org>
On Sonntag, 13. September 2009, Junio C Hamano wrote:
> Jim Meyering <jim@meyering.net> writes:
> > diff --git a/transport-helper.c b/transport-helper.c
> > index f57e84c..0bbd014 100644
> > --- a/transport-helper.c
> > +++ b/transport-helper.c
> > @@ -49,6 +49,7 @@ static struct child_process *get_helper(struct
> > transport *transport) if (!strcmp(buf.buf, "fetch"))
> > data->fetch = 1;
> > }
> > + fclose (file);
> > return data->helper;
> > }
> >
> > @@ -88,6 +89,7 @@ static int fetch_with_fetch(struct transport
> > *transport, if (strbuf_getline(&buf, file, '\n') == EOF)
> > exit(128); /* child died, message supplied already */
> > }
> > + fclose (file);
> > return 0;
> > }
>
> The callchain of fetch_with_fetch() looks like:
>
> fetch_with_fetch()
> helper = get_helper();
> --> get_helper()
> - start helper with start_command();
> - read from helper->out until it sees an empty line;
> - break out of the loop;
> <-- return helper
> - file = xfdopen(helper->out) to get another FILE on the fd
> - read the rest of the output from helper->out via file
>
> It seems to me that the fclose() in get_helper() will close the underlying
> fd and would break the caller, no?
>
> I think "struct helper_data" should get a new FILE* field and once
> somebody creates a FILE* out of its helper->out, that FILE* can be passed
> around without a new xfdopen().
>
> Or something like that.
>
> Who is responsible for closing the underlying helper->out fd in the
> start_command() API, by the way?
A pipe was requested by setting helper->out = -1 before the call to
start_command(), and in such a case the caller must close the fd.
-- Hannes
^ permalink raw reply
* Re: [RFC/PATCH v4 1/2] gitweb: check given hash before trying to create snapshot
From: Jakub Narebski @ 2009-09-13 15:03 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Mark Rada, git
In-Reply-To: <7vy6oj1jug.fsf@alter.siamese.dyndns.org>
On Sun, 13 Sep 2009, Junio C Hamano wrote:
> Mark Rada <marada@uwaterloo.ca> writes:
>> On 09-09-12 11:30 PM, Junio C Hamano wrote:
>>>> @@ -5196,8 +5202,9 @@ sub git_snapshot {
>>>> die_error(403, "Unsupported snapshot format");
>>>> }
>>>>
>>>> - if (!defined $hash) {
>>>> - $hash = git_get_head_hash($project);
>>>> + my $full_hash = git_get_full_hash($project, $hash);
>>>> + if (!$full_hash) {
>>>> + die_error(404, 'Hash id was not valid');
>>>> }
>>>
>>> This is in the context of "snapshot", so obviously you care more about
>>> just "such an object exists", don't you? You also want it to be a
>>> tree-ish. Try giving it $hash = 'junio-gpg-pub' and see how it breaks.
>>
>> You have confused me. How is using 'junio-gpg-pub' different from the
>> second test case that tries to use 'frizzumFrazzum'?
>
> junio-gpg-pub tag exists in git.git but it tags a blob not a tree.
>
> $ git rev-parse junio-gpg-pub
> 6019c27d966fe3ce8adcc0e9f12078eef96ca6ef
> $ git archive junio-gpg-pub
> fatal: not a tree object
So the proper solution with respect to snapshot parameters validation
would be to use
my $type = git_get_type("$hash^{}");
and check it:
* if $type is empty or undef (if it is false-ish) then requested object
does not exist and we return '404 - No such object' (or something like
that)
* if $type is 'blob' then we return '400 - Object is not a tree-ish'
(or something like that)
* otherwise $type is 'commit' or 'tree'
--
Jakub Narebski
Poland
^ permalink raw reply
* Re: What's cooking in git.git (Sep 2009, #03; Sun, 13)
From: Sverre Rabbelier @ 2009-09-13 14:54 UTC (permalink / raw)
To: Johan Herland; +Cc: Junio C Hamano, git, Shawn O. Pearce
In-Reply-To: <200909131653.12743.johan@herland.net>
Heya,
On Sun, Sep 13, 2009 at 16:53, Johan Herland <johan@herland.net> wrote:
> The next iteration of this topic will use sr/gfi-options, however, I'm
> holding off on submitting the re-roll until Shawn's comments on sr/gfi-
> options have been adressed by Sverre.
I might have some time to do that today, but I'm not sure how Shawn
wants me to do the options part (drop it out and replace it with
specific features, or keep it in).
--
Cheers,
Sverre Rabbelier
^ permalink raw reply
* Re: What's cooking in git.git (Sep 2009, #03; Sun, 13)
From: Johan Herland @ 2009-09-13 14:53 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Shawn O. Pearce, Sverre Rabbelier
In-Reply-To: <7v63bnw3wy.fsf@alter.siamese.dyndns.org>
On Sunday 13 September 2009, Junio C Hamano wrote:
> --------------------------------------------------
> [Stalled]
>
> * jh/cvs-helper (2009-08-18) 8 commits
> - More fixes to the git-remote-cvs installation procedure
> - Fix the Makefile-generated path to the git_remote_cvs package in
> git-remote-cvs - Add simple selftests of git-remote-cvs functionality
> - git-remote-cvs: Remote helper program for CVS repositories
> - 2/2: Add Python support library for CVS remote helper
> - 1/2: Add Python support library for CVS remote helper
> - Basic build infrastructure for Python scripts
> - Allow helpers to request marks for fast-import
> (this branch uses db/vcs-helper-rest.)
>
> Builds on db/vcs-helper. There is a re-roll planned.
The next iteration of this topic will use sr/gfi-options, however, I'm
holding off on submitting the re-roll until Shawn's comments on sr/gfi-
options have been adressed by Sverre.
> --------------------------------------------------
> [Cooking]
>
> * jh/notes (2009-09-12) 13 commits
> - Selftests verifying semantics when loading notes trees with various
> fanouts - Teach the notes lookup code to parse notes trees with various
> fanout schemes - notes.[ch] fixup: avoid old-style declaration
> - Teach notes code to free its internal data structures on request.
> - Add '%N'-format for pretty-printing commit notes
> - Add flags to get_commit_notes() to control the format of the note
> string - t3302-notes-index-expensive: Speed up create_repo()
> - fast-import: Add support for importing commit notes
> - Teach "-m <msg>" and "-F <file>" to "git notes edit"
> - Add an expensive test for git-notes
> - Speed up git notes lookup
> - Add a script to edit/inspect notes
> - Introduce commit notes
> (this branch uses sr/gfi-options.)
This topic does not use sr/gfi-options.
...Johan
--
Johan Herland, <johan@herland.net>
www.herland.net
^ permalink raw reply
* Re: GIT 1.6.5-rc1
From: Johan Herland @ 2009-09-13 14:43 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vws43up6z.fsf@alter.siamese.dyndns.org>
On Sunday 13 September 2009, Junio C Hamano wrote:
> Updates since v1.6.4
> --------------------
[snip]
> * various subcommands to "git submodule" learned --recursive option.
'git clone' also learned the --recursive option.
...Johan
--
Johan Herland, <johan@herland.net>
www.herland.net
^ permalink raw reply
* Re: Effectively tracing project contributions with git
From: Joseph Wakeling @ 2009-09-13 14:30 UTC (permalink / raw)
To: Theodore Tso; +Cc: Sverre Rabbelier, Jeff King, git
In-Reply-To: <20090913022843.GB26588@mit.edu>
Theodore Tso wrote:
> This will display all of the diffs on file (pathname) XXX by contributor YYY:
>
> git log -p --author=YYY XXX
>
> You might also find the diffstats useful:
>
> git log --stat --author=YYY XXX
>
> Or if you want *only* the diffstats for the file in question, you might try:
>
> git log --stat --pretty=format: --author=YYY XXX | grep XXX
That's absolutely brilliant -- using these commands makes my task much
easier.
As for reasons -- there are several. For the FOSS project, here is a
potential relicensing issue (guarding against future problems rather
than addressing present ones) and indeed I'm going about it the way you
suggest -- getting consent from as many contributors as possible.
Despite that, it seems useful to have up-to-date file-by-file credits
and copyright notices.
Personally, there's also a degree of curiosity and wanting to learn some
of the more complex and advanced possibilities of git -- and also
basically wanting to see to what extent this task is possible. How
fine-grained a degree of credit/blame can I extract for a given piece of
code? And how far back in history? etc.
Finally, there's an aspect which has nothing to do with code but could
still be very interesting for some people in the git community. I've
long been fascinated by DVCS as a collaborative tool and over the last
year have been part of the Liquid Publications project:
http://project.liquidpub.org/
... that is trying to develop new models for scientific collaboration
and publishing/sharing of results and ideas. One of my interests is to
see whether DVCS can be harnessed to enable better and more open
collaboration and micro-credit for scientific contributions.
We've already set up a project on Launchpad to try to turn one of our
project reports into a review paper via open collaboration:
https://code.launchpad.net/~webdrake/liquidpub/peer-review
... and I'll shortly be setting up a GitHub branch for another,
from-scratch article directly on DVCS and their potential applications
(the use of different VCS is deliberate: one thing I'll be doing is
testing different VCS and their different features). This is something
I'd very much like to have git (and bzr, and hg) community members
involved in.
I was going to write to the git community about this at a later date
once I'd got more stuff prepared, but since the present discussion could
generate useful material for that it seems only fair to be open.
The FOSS project stuff has nothing to do with that, but I certainly see
it as a good experience to feed the LiquidPub research.
Thanks for the useful advice and best wishes,
-- Joe
^ permalink raw reply
* Re: [PATCH] Improve --patch option documentation in git-add
From: Jari Aalto @ 2009-09-13 14:09 UTC (permalink / raw)
To: Mikael Magnusson; +Cc: git
In-Reply-To: <237967ef0909130648l36b592aft9c50ccff5d03d1b1@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 593 bytes --]
Mikael Magnusson <mikachu@gmail.com> writes:
>> + Interactively choose hunks of patch between the index and the
> diff probably makes more sense than patch here
>
>> + work tree and add them to the index. This gives a change to
> a chance
>
>> + review the difference before adding modified contents to the
> differences? Not sure which I prefer on this one.
>
>> + index.
>> +
>> + This effectively runs ``add --interactive``, but bypass the
> bypasses
>
>> + initial command menu and directly jump to `patch` subcommand.
> jumps
An update. Thanks,
Jari
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: 0001-Improve-patch-option-documentation-in-git-add.patch --]
[-- Type: text/x-diff, Size: 1200 bytes --]
>From beca0d3dcd668e1b578588378149320cd3aed9d9 Mon Sep 17 00:00:00 2001
From: Jari Aalto <jari.aalto@cante.net>
Date: Sun, 13 Sep 2009 17:08:51 +0300
Subject: [PATCH] Improve --patch option documentation in git-add
Signed-off-by: Jari Aalto <jari.aalto@cante.net>
---
Documentation/git-add.txt | 11 ++++++++---
1 files changed, 8 insertions(+), 3 deletions(-)
diff --git a/Documentation/git-add.txt b/Documentation/git-add.txt
index e67b7e8..0b2a2a6 100644
--- a/Documentation/git-add.txt
+++ b/Documentation/git-add.txt
@@ -72,9 +72,14 @@ OPTIONS
-p::
--patch::
- Similar to Interactive mode but the initial command loop is
- bypassed and the 'patch' subcommand is invoked using each of
- the specified filepatterns before exiting.
+ Interactively choose hunks of diff between the index and the
+ work tree and add them to the index. This gives a change to
+ review the differences before adding modified contents to the
+ index.
+
+ This effectively runs ``add --interactive``, but bypass the
+ initial command menu and directly jumps to `patch` subcommand.
+ See ``Interactive mode'' for details.
-e, \--edit::
Open the diff vs. the index in an editor and let the user
--
1.6.3.3
^ permalink raw reply related
* Re: [PATCH] Improve --patch option documentation in git-add
From: Mikael Magnusson @ 2009-09-13 13:48 UTC (permalink / raw)
To: Jari Aalto; +Cc: git
In-Reply-To: <87ab0zny27.fsf_-_@jondo.cante.net>
2009/9/13 Jari Aalto <jari.aalto@cante.net>:
> Junio C Hamano <gitster@pobox.com> writes:
>
>> Jari Aalto <jari.aalto@cante.net> writes:
>>
>>> --patch:
>>> -p::
>>> In a modified work tree, choose interactively which patch hunks to
>>> add. This gives a change to review the difference between the
>>> index and the work before adding modified contents to the index.
>>
>> Sounds sensible. You may want to be even more direct and succinct, e.g.
>>
>> Interactively choose hunks of patch between the index and the work
>> tree and add them to the index.
>
> Thanks, see below,
> Jari
>
> From 63aa94e7782d6340ead0446ea80ed6223d7ac5c1 Mon Sep 17 00:00:00 2001
> From: Jari Aalto <jari.aalto@cante.net>
> Date: Sun, 13 Sep 2009 09:43:10 +0300
> Subject: [PATCH] Improve --patch option documentation in git-add
>
> Signed-off-by: Jari Aalto <jari.aalto@cante.net>
> ---
> Documentation/git-add.txt | 11 ++++++++---
> 1 files changed, 8 insertions(+), 3 deletions(-)
>
> diff --git a/Documentation/git-add.txt b/Documentation/git-add.txt
> index e67b7e8..b94fbec 100644
> --- a/Documentation/git-add.txt
> +++ b/Documentation/git-add.txt
> @@ -72,9 +72,14 @@ OPTIONS
>
> -p::
> --patch::
> - Similar to Interactive mode but the initial command loop is
> - bypassed and the 'patch' subcommand is invoked using each of
> - the specified filepatterns before exiting.
> + Interactively choose hunks of patch between the index and the
diff probably makes more sense than patch here
> + work tree and add them to the index. This gives a change to
a chance
> + review the difference before adding modified contents to the
differences? Not sure which I prefer on this one.
> + index.
> +
> + This effectively runs ``add --interactive``, but bypass the
bypasses
> + initial command menu and directly jump to `patch` subcommand.
jumps
> + See ``Interactive mode'' for details.
>
> -e, \--edit::
> Open the diff vs. the index in an editor and let the user
> --
> 1.6.3.3
--
Mikael Magnusson
^ permalink raw reply
* [PATCH] git-commit: Only describe --dry-run once
From: Johannes Gilger @ 2009-09-13 13:35 UTC (permalink / raw)
To: Git Mailing List; +Cc: Johannes Gilger
Junio described the option in 3a5d13a and then again in 60c2993.
Also fix a small typo in the documentation for git-clone.
Signed-off-by: Johannes Gilger <heipei@hackvalue.de>
---
Documentation/git-clone.txt | 2 +-
Documentation/git-commit.txt | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/Documentation/git-clone.txt b/Documentation/git-clone.txt
index f23100e..aacf4fd 100644
--- a/Documentation/git-clone.txt
+++ b/Documentation/git-clone.txt
@@ -130,7 +130,7 @@ objects from the source repository into a pack in the cloned repository.
--branch <name>::
-b <name>::
Instead of pointing the newly created HEAD to the branch pointed
- to by the cloned repositoroy's HEAD, point to <name> branch
+ to by the cloned repository's HEAD, point to <name> branch
instead. In a non-bare repository, this is the branch that will
be checked out.
diff --git a/Documentation/git-commit.txt b/Documentation/git-commit.txt
index 64f94cf..b2817b4 100644
--- a/Documentation/git-commit.txt
+++ b/Documentation/git-commit.txt
@@ -8,7 +8,7 @@ git-commit - Record changes to the repository
SYNOPSIS
--------
[verse]
-'git commit' [-a | --interactive] [-s] [-v] [-u<mode>] [--amend] [--dry-run]
+'git commit' [-a | --interactive] [-s] [-v] [-u<mode>] [--amend]
[(-c | -C) <commit>] [-F <file> | -m <msg>] [--dry-run]
[--allow-empty] [--no-verify] [-e] [--author=<author>]
[--cleanup=<mode>] [--] [[-i | -o ]<file>...]
--
1.6.5.rc1
^ permalink raw reply related
* Re: [PATCH] reflog documentation: -n is an alias for --dry-run
From: Jeff King @ 2009-09-13 13:26 UTC (permalink / raw)
To: Nelson Elhage; +Cc: git
In-Reply-To: <20090913125313.GQ4275@mit.edu>
On Sun, Sep 13, 2009 at 08:53:13AM -0400, Nelson Elhage wrote:
> Patch withdrawn -- I'd send one documenting that -n works for delete
> and expire, but it'd probably just complicate the documentation more
> than clarify anything.
I think it would be fine to just split the (show|expire) line into two
separate lines:
> > > -"git reflog (show|expire) [--verbose] [--dry-run] [--stale-fix] [--expire=<time>] [--expire-unreachable=<time>] [--all] <refs>...";
> > > +"git reflog (show|expire) [--verbose] [-n | --dry-run] [--stale-fix] [--expire=<time>] [--expire-unreachable=<time>] [--all] <refs>...";
-Peff
^ permalink raw reply
* Re: [PATCH v7 4/6] fast-import: test the new feature command
From: Miklos Vajna @ 2009-09-13 13:20 UTC (permalink / raw)
To: Sverre Rabbelier
Cc: Shawn O. Pearce, Junio C Hamano, Johannes Schindelin, Git List,
Ian Clatworthy, Matt McClure, Julian Phillips,
vcs-fast-import-devs
In-Reply-To: <fabb9a1e0909121231l7586bb5cn90f3153e22988f42@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 234 bytes --]
On Sat, Sep 12, 2009 at 09:31:46PM +0200, Sverre Rabbelier <srabbelier@gmail.com> wrote:
> Is that still possible since the series is in next now? Also, with the
> series being in next, should I send incremental patches?
I think so.
[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Re: [PATCH] reflog documentation: -n is an alias for --dry-run
From: Erik Faye-Lund @ 2009-09-13 13:05 UTC (permalink / raw)
To: Jeff King; +Cc: Nelson Elhage, git
In-Reply-To: <20090913094032.GC14438@coredump.intra.peff.net>
On Sun, Sep 13, 2009 at 11:40 AM, Jeff King <peff@peff.net> wrote:
>> static const char reflog_expire_usage[] =
>> -"git reflog (show|expire) [--verbose] [--dry-run] [--stale-fix] [--expire=<time>] [--expire-unreachable=<time>] [--all] <refs>...";
>> +"git reflog (show|expire) [--verbose] [-n | --dry-run] [--stale-fix] [--expire=<time>] [--expire-unreachable=<time>] [--all] <refs>...";
>
> Really? I think "git reflog show -n" is not about dry-run at all...
Indeed. However, the reflog expire uses -n as an alias for --dry-run,
according to lines 548-549 of my builtin-reflog.c (ddfdf5a):
if (!strcmp(arg, "--dry-run") || !strcmp(arg, "-n"))
cb.dry_run = 1;
...and this usage-string is only output from cmd_reflog_expire, so the
correct solution would IMO be to simply remove show from the
usage-string:
-"git reflog (show|expire) [--verbose] [-n | --dry-run] [--stale-fix]
[--expire=<time>] [--expire-unreachable=<time>] [--all] <refs>...";
+"git reflog expire [--verbose] [-n | --dry-run] [--stale-fix]
[--expire=<time>] [--expire-unreachable=<time>] [--all] <refs>...";
This issue ("reflog expire" incorrectly documenting "reflog show") was
present before this patch, though. At least the option "--stale-fix"
appears not to be valid for "reflog show".
--
Erik "kusma" Faye-Lund
kusmabite@gmail.com
(+47) 986 59 656
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox