* git rm --cached
From: Jing Xue @ 2007-11-02 2:17 UTC (permalink / raw)
To: git
In the following scenario, why do I have to run 'git reset' following
'git rm --cached 1.txt' to revert to exactly where I was before 'git add
1.txt'? Shouldn't 'git rm --cached' have done that already?
jingxue@fawkes:~/workspace/t1.git$ git status
# On branch master
# Changed but not updated:
# (use "git add <file>..." to update what will be committed)
#
# modified: 1.txt
#
no changes added to commit (use "git add" and/or "git commit -a")
jingxue@fawkes:~/workspace/t1.git$ git add 1.txt
jingxue@fawkes:~/workspace/t1.git$ git status
# On branch master
# Changes to be committed:
# (use "git reset HEAD <file>..." to unstage)
#
# modified: 1.txt
#
jingxue@fawkes:~/workspace/t1.git$ git rm --cached 1.txt
rm '1.txt'
jingxue@fawkes:~/workspace/t1.git$ git status
# On branch master
# Changes to be committed:
# (use "git reset HEAD <file>..." to unstage)
#
# deleted: 1.txt
#
# Untracked files:
# (use "git add <file>..." to include in what will be committed)
#
# 1.txt
jingxue@fawkes:~/workspace/t1.git$ git reset
1.txt: needs update
jingxue@fawkes:~/workspace/t1.git$ git status
# On branch master
# Changed but not updated:
# (use "git add <file>..." to update what will be committed)
#
# modified: 1.txt
#
no changes added to commit (use "git add" and/or "git commit -a")
Thanks.
--
Jing Xue
^ permalink raw reply
* [PATCH] gc: use parse_options
From: James Bowes @ 2007-11-02 1:02 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vhck579pm.fsf@gitster.siamese.dyndns.org>
Signed-off-by: James Bowes <jbowes@dangerouslyinc.com>
---
Junio C Hamano <gitster@pobox.com> writes:
> Now, what makes the command report error when the user says:
>
> $ git gc unwanted parameter
Ah yes. I forgot about that :)
This version of the patch errors out with extra args, and calls them
'unreferenced loose objects' rather than unused.
-James
builtin-gc.c | 44 ++++++++++++++++++++++----------------------
1 files changed, 22 insertions(+), 22 deletions(-)
diff --git a/builtin-gc.c b/builtin-gc.c
index 3a2ca4f..c5bce89 100644
--- a/builtin-gc.c
+++ b/builtin-gc.c
@@ -12,11 +12,15 @@
#include "builtin.h"
#include "cache.h"
+#include "parse-options.h"
#include "run-command.h"
#define FAILED_RUN "failed to run %s"
-static const char builtin_gc_usage[] = "git-gc [--prune] [--aggressive]";
+static const char * const builtin_gc_usage[] = {
+ "git-gc [options]",
+ NULL
+};
static int pack_refs = 1;
static int aggressive_window = -1;
@@ -165,38 +169,34 @@ static int need_to_gc(void)
int cmd_gc(int argc, const char **argv, const char *prefix)
{
- int i;
int prune = 0;
+ int aggressive = 0;
int auto_gc = 0;
char buf[80];
+ struct option builtin_gc_options[] = {
+ OPT_BOOLEAN(0, "prune", &prune, "prune unreferenced loose objects"),
+ OPT_BOOLEAN(0, "aggressive", &aggressive, "be more thorough (increased runtime)"),
+ OPT_BOOLEAN(0, "auto", &auto_gc, "enable auto-gc mode"),
+ OPT_END()
+ };
+
git_config(gc_config);
if (pack_refs < 0)
pack_refs = !is_bare_repository();
- for (i = 1; i < argc; i++) {
- const char *arg = argv[i];
- if (!strcmp(arg, "--prune")) {
- prune = 1;
- continue;
- }
- if (!strcmp(arg, "--aggressive")) {
- append_option(argv_repack, "-f", MAX_ADD);
- if (aggressive_window > 0) {
- sprintf(buf, "--window=%d", aggressive_window);
- append_option(argv_repack, buf, MAX_ADD);
- }
- continue;
- }
- if (!strcmp(arg, "--auto")) {
- auto_gc = 1;
- continue;
+ argc = parse_options(argc, argv, builtin_gc_options, builtin_gc_usage, 0);
+ if (argc > 0)
+ usage_with_options(builtin_gc_usage, builtin_gc_options);
+
+ if (aggressive) {
+ append_option(argv_repack, "-f", MAX_ADD);
+ if (aggressive_window > 0) {
+ sprintf(buf, "--window=%d", aggressive_window);
+ append_option(argv_repack, buf, MAX_ADD);
}
- break;
}
- if (i != argc)
- usage(builtin_gc_usage);
if (auto_gc) {
/*
--
1.5.3.4.1481.g854da
^ permalink raw reply related
* Re: [PATCH] post-update hook: update working copy
From: Junio C Hamano @ 2007-11-02 1:02 UTC (permalink / raw)
To: Sam Vilain; +Cc: git
In-Reply-To: <1193964304-10847-1-git-send-email-sam.vilain@catalyst.net.nz>
Sam Vilain <sam.vilain@catalyst.net.nz> writes:
> Now that git-stash is available, it is not so unsafe to push to a
> non-bare repository, but care needs to be taken to preserve any dirty
> working copy or index state. This hook script does that, using
> git-stash.
Honestly, I am reluctant to do things that _encourages_ pushing
into a live tree.
- Who guarantees that the reflog is enabled for the HEAD?
- Who guarantees that a human user is not actively editing the
work tree files without saving? You would not see "dirty
state", the editor would notice "the file was modified since
you started editing it" and tell so to the user, but the user
cannot recover from the situation without knowing to do the
three-way merge between HEAD@{1}, HEAD and the index _anyway_.
> +update_wc() {
> + ref=$1
> + echo "Push to checked out branch $ref" >&2
> + if (cd $GIT_WORK_TREE; git-diff-files -q --exit-code >/dev/null)
> + then
> + wc_dirty=0
> + else
> + echo "W:unstaged changes found in working copy" >&2
> + wc_dirty=1
> + desc="working copy"
> + fi
> + if git diff-index HEAD@{1} >/dev/null
Are you missing "--cached" here?
> + if [ "$wc_dirty" -ne 0 -o "$index_dirty" -ne 0 ]
> + then
> + new=$(git rev-parse HEAD)
> + git-update-ref --no-deref HEAD HEAD@{1}
> + echo "W:stashing dirty $desc - see git-stash(1)" >&2
> + (cd $GIT_WORK_TREE
> + git stash save "dirty $desc before update to $new")
> + git-symbolic-ref HEAD "$ref"
This part feels somewhat dangerous. What happens if we are
interrupted in the middle of these commands?
> + fi
> +
> + # eye candy - show the WC updates :)
> + echo "Updating working copy" >&2
> + (cd $GIT_WORK_TREE
> + git-diff-index -R --name-status HEAD >&2
> + git-reset --hard HEAD)
> +}
And I would have expected you would unstash the dirty state here.
Are there any reason not to?
^ permalink raw reply
* Re: [PATCH] gc: use parse_options
From: Junio C Hamano @ 2007-11-02 0:49 UTC (permalink / raw)
To: James Bowes; +Cc: git, gitster
In-Reply-To: <20071102002856.GB3282@crux.yyz.redhat.com>
James Bowes <jbowes@dangerouslyinc.com> writes:
> + struct option builtin_gc_options[] = {
> + OPT_BOOLEAN(0, "prune", &prune, "prune unused objects"),
I would write "unreferenced loose" instead of "unused" here...
> + OPT_BOOLEAN(0, "aggressive", &aggressive, "be more thorough (increased runtime)"),
> + OPT_BOOLEAN(0, "auto", &auto_gc, "enable auto-gc mode"),
> + OPT_END()
> + };
> +
> git_config(gc_config);
>
> if (pack_refs < 0)
> pack_refs = !is_bare_repository();
>
> + parse_options(argc, argv, builtin_gc_options, builtin_gc_usage, 0);
> +
> + if (aggressive) {
> + append_option(argv_repack, "-f", MAX_ADD);
> + if (aggressive_window > 0) {
> + sprintf(buf, "--window=%d", aggressive_window);
> + append_option(argv_repack, buf, MAX_ADD);
> }
> }
> - if (i != argc)
> - usage(builtin_gc_usage);
Now, what makes the command report error when the user says:
$ git gc unwanted parameter
Other than that, this is a good thing to have, I think.
^ permalink raw reply
* [PATCH] post-update hook: update working copy
From: Sam Vilain @ 2007-11-02 0:45 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Sam Vilain
Now that git-stash is available, it is not so unsafe to push to a
non-bare repository, but care needs to be taken to preserve any dirty
working copy or index state. This hook script does that, using
git-stash.
Signed-off-by: Sam Vilain <sam.vilain@catalyst.net.nz>
---
templates/hooks--post-update | 76 ++++++++++++++++++++++++++++++++++++++++--
1 files changed, 73 insertions(+), 3 deletions(-)
mode change 100644 => 100755 templates/hooks--post-update
diff --git a/templates/hooks--post-update b/templates/hooks--post-update
old mode 100644
new mode 100755
index bcba893..352a432
--- a/templates/hooks--post-update
+++ b/templates/hooks--post-update
@@ -1,8 +1,78 @@
#!/bin/sh
#
-# An example hook script to prepare a packed repository for use over
-# dumb transports.
+# This hook does two things:
+#
+# 1. update the "info" files that allow the list of references to be
+# queries over dumb transports such as http
+#
+# 2. if this repository looks like it is a non-bare repository, and
+# the checked-out branch is pushed to, then update the working copy.
+# This makes "push" function somewhat similarly to darcs and bzr.
#
# To enable this hook, make this file executable by "chmod +x post-update".
-exec git-update-server-info
+git-update-server-info
+
+is_bare=$(git-config --get --bool core.bare)
+
+if [ -z "$is_bare" ]
+then
+ # for compatibility's sake, guess
+ git_dir_full=$(cd $GIT_DIR; pwd)
+ case $git_dir_full in */.git) is_bare=false;; *) is_bare=true;; esac
+fi
+
+update_wc() {
+ ref=$1
+ echo "Push to checked out branch $ref" >&2
+ if (cd $GIT_WORK_TREE; git-diff-files -q --exit-code >/dev/null)
+ then
+ wc_dirty=0
+ else
+ echo "W:unstaged changes found in working copy" >&2
+ wc_dirty=1
+ desc="working copy"
+ fi
+ if git diff-index HEAD@{1} >/dev/null
+ then
+ index_dirty=0
+ else
+ echo "W:uncommitted, staged changes found" >&2
+ index_dirty=1
+ if [ -n "$desc" ]
+ then
+ desc="$desc and index"
+ else
+ desc="index"
+ fi
+ fi
+ if [ "$wc_dirty" -ne 0 -o "$index_dirty" -ne 0 ]
+ then
+ new=$(git rev-parse HEAD)
+ git-update-ref --no-deref HEAD HEAD@{1}
+ echo "W:stashing dirty $desc - see git-stash(1)" >&2
+ (cd $GIT_WORK_TREE
+ git stash save "dirty $desc before update to $new")
+ git-symbolic-ref HEAD "$ref"
+ fi
+
+ # eye candy - show the WC updates :)
+ echo "Updating working copy" >&2
+ (cd $GIT_WORK_TREE
+ git-diff-index -R --name-status HEAD >&2
+ git-reset --hard HEAD)
+}
+
+if [ "$is_bare" = "false" ]
+then
+ active_branch=`git-symbolic-ref HEAD`
+ export GIT_DIR=$(cd $GIT_DIR; pwd)
+ GIT_WORK_TREE=${GIT_WORK_TREE-..}
+ for ref
+ do
+ if [ "$ref" = "$active_branch" ]
+ then
+ update_wc $ref
+ fi
+ done
+fi
--
1.5.3.2.3.g2f2dcc-dirty
^ permalink raw reply related
* Re: What's cooking in git.git (topics)
From: Junio C Hamano @ 2007-11-02 0:32 UTC (permalink / raw)
To: Mike Hommey; +Cc: Geert Bosch, Linus Torvalds, git
In-Reply-To: <7vhck5acj4.fsf@gitster.siamese.dyndns.org>
Junio C Hamano <gitster@pobox.com> writes:
> I am personally very much in favor of removing "git clean", but
> having many people on the list saying loudly that it is a bad
> command is not good enough justification, as people who are
> content with the status quo tend to be silent.
>
> The steps I think is sensible to transition to that goal would
> be:
>
> - Change clean.requireForce to default to 'true' in the next
> (or one after) version of git, to make 'clean' even safer.
> See if anybody complains (I do not expect any).
>
> - Implement the same functionarity as a new option to "git rm",
> which is already in C.
>
> - Do "git clean" in C, but sharing the code with "git rm"
> implementation above.
>
> - Discuss deprecation and removal of redundant commands. Ship
> a version of git with deprecation and future removal notice.
> Outline how to achieve the same thing as the deprecated
> command used to do (or give convincing argument why what the
> deprecated command used to do was a bad thing and do not
> offer an alternative).
>
> - Wait for a while (6 months to 1 year) and then remove them.
And this is the first step.
---
Documentation/config.txt | 4 ++--
git-clean.sh | 6 +++++-
2 files changed, 7 insertions(+), 3 deletions(-)
diff --git a/Documentation/config.txt b/Documentation/config.txt
index edf50cd..2144855 100644
--- a/Documentation/config.txt
+++ b/Documentation/config.txt
@@ -345,8 +345,8 @@ branch.<name>.mergeoptions::
supported.
clean.requireForce::
- A boolean to make git-clean do nothing unless given -f or -n. Defaults
- to false.
+ A boolean to make git-clean do nothing unless given -f
+ or -n. Defaults to true.
color.branch::
A boolean to enable/disable color in the output of
diff --git a/git-clean.sh b/git-clean.sh
index 4491738..f4965b8 100755
--- a/git-clean.sh
+++ b/git-clean.sh
@@ -20,12 +20,16 @@ require_work_tree
ignored=
ignoredonly=
cleandir=
-disabled="`git config --bool clean.requireForce`"
rmf="rm -f --"
rmrf="rm -rf --"
rm_refuse="echo Not removing"
echo1="echo"
+# requireForce used to default to false but now it defaults to true.
+# IOW, lack of explicit "clean.requireForce = false" is taken as
+# "clean.requireForce = true".
+disabled=$(git config --bool clean.requireForce || echo true)
+
while test $# != 0
do
case "$1" in
^ permalink raw reply related
* [PATCH] gc: use parse_options
From: James Bowes @ 2007-11-02 0:28 UTC (permalink / raw)
To: git, gitster
Signed-off-by: James Bowes <jbowes@dangerouslyinc.com>
---
builtin-gc.c | 42 ++++++++++++++++++++----------------------
1 files changed, 20 insertions(+), 22 deletions(-)
diff --git a/builtin-gc.c b/builtin-gc.c
index 3a2ca4f..7bb873c 100644
--- a/builtin-gc.c
+++ b/builtin-gc.c
@@ -12,11 +12,15 @@
#include "builtin.h"
#include "cache.h"
+#include "parse-options.h"
#include "run-command.h"
#define FAILED_RUN "failed to run %s"
-static const char builtin_gc_usage[] = "git-gc [--prune] [--aggressive]";
+static const char * const builtin_gc_usage[] = {
+ "git-gc [options]",
+ NULL
+};
static int pack_refs = 1;
static int aggressive_window = -1;
@@ -165,38 +169,32 @@ static int need_to_gc(void)
int cmd_gc(int argc, const char **argv, const char *prefix)
{
- int i;
int prune = 0;
+ int aggressive = 0;
int auto_gc = 0;
char buf[80];
+ struct option builtin_gc_options[] = {
+ OPT_BOOLEAN(0, "prune", &prune, "prune unused objects"),
+ OPT_BOOLEAN(0, "aggressive", &aggressive, "be more thorough (increased runtime)"),
+ OPT_BOOLEAN(0, "auto", &auto_gc, "enable auto-gc mode"),
+ OPT_END()
+ };
+
git_config(gc_config);
if (pack_refs < 0)
pack_refs = !is_bare_repository();
- for (i = 1; i < argc; i++) {
- const char *arg = argv[i];
- if (!strcmp(arg, "--prune")) {
- prune = 1;
- continue;
- }
- if (!strcmp(arg, "--aggressive")) {
- append_option(argv_repack, "-f", MAX_ADD);
- if (aggressive_window > 0) {
- sprintf(buf, "--window=%d", aggressive_window);
- append_option(argv_repack, buf, MAX_ADD);
- }
- continue;
- }
- if (!strcmp(arg, "--auto")) {
- auto_gc = 1;
- continue;
+ parse_options(argc, argv, builtin_gc_options, builtin_gc_usage, 0);
+
+ if (aggressive) {
+ append_option(argv_repack, "-f", MAX_ADD);
+ if (aggressive_window > 0) {
+ sprintf(buf, "--window=%d", aggressive_window);
+ append_option(argv_repack, buf, MAX_ADD);
}
- break;
}
- if (i != argc)
- usage(builtin_gc_usage);
if (auto_gc) {
/*
--
1.5.3.4.1481.g854da
^ permalink raw reply related
* Re: Debugging corrupt object generation
From: Julian Phillips @ 2007-11-02 0:26 UTC (permalink / raw)
To: Nicolas Pitre; +Cc: git
In-Reply-To: <alpine.LFD.0.9999.0711011947220.21255@xanadu.home>
On Thu, 1 Nov 2007, Nicolas Pitre wrote:
> On Thu, 1 Nov 2007, Julian Phillips wrote:
>
>> After a certain commit, and attempt to use that commit generates a "fatal:
>> unable to apply delta". This appears to be coming from unpack_delta_entry
>> in sha1_file.c.
>
> I suppose you mean "fatal: failed to apply delta", because "unable to
> apply delta" doesn't appear anywhere in the current source tree.
I did indeed. Read 'n' type never seems to be as reliable as copy 'n'
paste ...
>> Can anyone give me any hints as to how I find out what is causing the
>> problem? I'm not even sure what it is that isn't working ... and all
>> attempts to replicate the problem with my test repository have failed.
>
> Well, something is screwed for sure. Some object you're requesting is
> made of a delta, and that delta is bad, therefore patch_delta() returns
> NULL (you could instrument it to determine exactly why).
Ah, ok - that sounds like it might be useful. I guess that looking at the
opposite side where fast-import is creating the data might also prove
fruitful.
> Maybe fast-import hasn't flushed the needed data to the pack yet?
Well, fast-import completes quite happily and outputs the normal summary
status. I can look at logs and trees etc provided that I don't try and
look at one particular part of the tree on one particular commit. I
think the problem is that I've managed to do something inside fast-import
that corrupts one particular tree object (though I've no idea what that
might be).
I shall have to start instrumenting and try again.
Thanks.
--
Julian
---
Many changes of mind and mood; do not hesitate too long.
^ permalink raw reply
* Re: [PATCH 0/3] gitweb: Simplify some gitweb URLs generation
From: Jakub Narebski @ 2007-11-02 0:18 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7v1wb98twi.fsf@gitster.siamese.dyndns.org>
Junio C Hamano wrote:
> Jakub Narebski <jnareb@gmail.com> writes:
>
>> This series of patches simplifies some gitweb URLs generation by
>> providing -replay option to href() subroutine, and then using this
>> feature in gitweb code.
>>
>> Shortlog:
>> gitweb: Easier adding/changing parameters to current URL
>> gitweb: Use href(-replay=>1, page=>...) to generate pagination links
>> gitweb: Use href(-replay=>1, action=>...) to generate alternate views
>>
>> Diffstat:
>> gitweb/gitweb.perl | 82 ++++++++++++++++++++++-----------------------------
>> 1 files changed, 35 insertions(+), 47 deletions(-)
>
> If this "-replay" is used carelessly, it could add parameters
> that were passed to the page that the original code stripped
> away from passing on purpose. Have you checked if the
> conversion done with 2/3 and 3/3 are correct (I haven't)?
First, I guess that I should have marked this series of patches as
an RFC, but not for the reason you mentioned. This series changes
somewhat gitweb behaviour (patches 2/3 and 3/3 to be more exact) in
a way that before gitweb passed 'expanded' hashes to page / alternate
view links. For example before this series link to second page for
shortlog view starting from 'HEAD' passed literal sha1 for 'h' parameter,
ans second page started where first page ended. After this patch, if
refs have changed between viewing first page and clicking on the link
to second page, the resulting view would be second page of _new_ 'HEAD',
not of old (shown) 'HEAD'.
Second, you do not need to worry about adding parameters, because in 2/3
and 3/3 -replay is used to change view to the one which differs from
current by one parameter. Please take into account that some parameters
are just not important.
--
Jakub Narebski
Poland
^ permalink raw reply
* Re: What's cooking in git.git (topics)
From: Jakub Narebski @ 2007-11-02 0:04 UTC (permalink / raw)
To: git
In-Reply-To: <alpine.LFD.0.999.0711011129460.3342@woody.linux-foundation.org>
Linus Torvalds wrote:
> On Wed, 31 Oct 2007, Junio C Hamano wrote:
>>
>> * ph/parseopt (Tue Oct 30 14:15:21 2007 -0500) 23 commits
>> + ...
>>
>> It appears 1.5.4 will be, to a certain extent, a "Let's clean up
>> the internal implementation" release. This series should become
>> part of it. Hopefully will merge to 'master' soon, but I
>> haven't looked this series very closely yet.
>
> I certainly think this should go in, but it does make one deficiency
> painfully clear: the remaining shell scripts end up having all the old
> flags behaviour.
Is 'getopts' bash-ism, or is it in POSIX?
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
^ permalink raw reply
* Re: What's cooking in git.git (topics)
From: Jonas Fonseca @ 2007-11-02 0:00 UTC (permalink / raw)
To: Geert Bosch; +Cc: Junio C Hamano, Linus Torvalds, git
In-Reply-To: <DB2DC59C-8580-4AFE-860F-6E7C4A47499E@adacore.com>
On Nov 1, 2007 10:17 PM, Geert Bosch <bosch@adacore.com> wrote:
> On Nov 1, 2007, at 16:27, Junio C Hamano wrote:
> > I think what you are trying to do is to deprecate or remove "git
> > clean".
>
> Yes, and in the meantime I'd like to discourage people
> from spending time and effort to upgrade it to first
> class built-in status.
If you search the archive you will find that a builtin-clean.c has already
been offered.
--
Jonas Fonseca
^ permalink raw reply
* Re: Debugging corrupt object generation
From: Nicolas Pitre @ 2007-11-01 23:57 UTC (permalink / raw)
To: Julian Phillips; +Cc: git
In-Reply-To: <Pine.LNX.4.64.0711012256080.17812@beast.quantumfyre.co.uk>
On Thu, 1 Nov 2007, Julian Phillips wrote:
> I have been trying to import a repository using fast-import, and as part of
> this I have extended fast-import to support copying a path from any arbitrary
> commit. This works fine on my small test repository.
>
> However, when I run against my (vastly more complicated) real work repository
> things don't go so well. I get a few thousand commits in, and then it breaks.
> It appears that I have somehow managed to create a corrupt object or
> something.
>
> After a certain commit, and attempt to use that commit generates a "fatal:
> unable to apply delta". This appears to be coming from unpack_delta_entry
> in sha1_file.c.
I suppose you mean "fatal: failed to apply delta", because "unable to
apply delta" doesn't appear anywhere in the current source tree.
> Can anyone give me any hints as to how I find out what is causing the
> problem? I'm not even sure what it is that isn't working ... and all
> attempts to replicate the problem with my test repository have failed.
Well, something is screwed for sure. Some object you're requesting is
made of a delta, and that delta is bad, therefore patch_delta() returns
NULL (you could instrument it to determine exactly why).
Maybe fast-import hasn't flushed the needed data to the pack yet?
Nicolas
^ permalink raw reply
* Re: [PATCH] Implement git commit as a builtin command.
From: Junio C Hamano @ 2007-11-01 23:51 UTC (permalink / raw)
To: Kristian Høgsberg; +Cc: git
In-Reply-To: <1193944163-22892-1-git-send-email-krh@redhat.com>
Kristian Høgsberg <krh@redhat.com> writes:
> @@ -364,7 +365,6 @@ BUILTIN_OBJS = \
> builtin-rev-parse.o \
> builtin-revert.o \
> builtin-rm.o \
> - builtin-runstatus.o \
> builtin-shortlog.o \
> builtin-show-branch.o \
> builtin-stripspace.o \
I did not read in the commit log that runstatus is gone...
> diff --git a/builtin-commit.c b/builtin-commit.c
> new file mode 100644
> index 0000000..56c7427
> --- /dev/null
> +++ b/builtin-commit.c
> @@ -0,0 +1,608 @@
> +/*
> + * Builtin "git commit"
> + *
> + * Copyright (c) 2007 Kristian Høgsberg <krh@redhat.com>
> + * Based on git-commit.sh by Junio C Hamano and Linus Torvalds
> + */
> +
> +#include <sys/types.h>
> +#include <sys/stat.h>
> +#include <unistd.h>
> +
> +#include "cache.h"
The system header files on some systems have a nasty habit of
changing the behaviour depending on the order they are included.
Since 85023577a8f4b540aa64aa37f6f44578c0c305a3 (simplify
inclusion of system header files) in late 2006, we have a few
rules for system-header inclusion to avoid the portability
issues:
(1) sources under compat/, platform sha-1 implementations, and
xdelta code are exempt from the following rules;
(2) the first #include must be "git-compat-util.h" or one of
our own header file that includes it first (e.g. config.h,
builtin.h, pkt-line.h);
(3) system headers that are included in "git-compat-util.h"
need not be included in individual C source files.
(4) "git-compat-util.h" does not have to include subsystem
specific header files (e.g. expat.h).
> +static void determine_author_info(struct strbuf *sb)
> +{
> + char *p, *eol;
> + char *name = NULL, *email = NULL;
> +
> + if (use_message) {
> + p = strstr(use_message_buffer, "\nauthor");
> + if (!p)
> + die("invalid commit: %s\n", use_message);
> + p++;
> + eol = strchr(p, '\n');
> + if (!eol)
> + die("invalid commit: %s\n", use_message);
> +
> + strbuf_add(sb, p, eol + 1 - p);
> + } else if (force_author) {
> + const char *eoname = strstr(force_author, " <");
> + const char *eomail = strchr(force_author, '>');
Doesn't this break:
$ git commit --amend --author='A U Thor <author@example.com>'
to fix a misattribution?
> +static int parse_and_validate_options(int argc, const char *argv[])
> +{
> ...
> + if (use_message) {
> + unsigned char sha1[20];
> + static char utf8[] = "UTF-8";
> + const char *out_enc;
> + char *enc, *end;
> + struct commit *commit;
> +
> + if (get_sha1(use_message, sha1))
> + die("could not lookup commit %s", use_message);
> + commit = lookup_commit(sha1);
> + if (!commit || parse_commit(commit))
> + die("could not parse commit %s", use_message);
> +
> + enc = strstr(commit->buffer, "\nencoding");
> + if (enc) {
> + end = strchr(enc + 10, '\n');
> + enc = xstrndup(enc + 10, end - (enc + 10));
> + } else {
> + enc = utf8;
> + }
> + out_enc = git_commit_encoding ? git_commit_encoding : utf8;
> +
> + use_message_buffer =
> + reencode_string(commit->buffer, out_enc, enc);
> + if (enc != utf8)
> + free(enc);
A few issues.
* When use_message is set because of --amend that wanted to
amend a commit message that was recorded in a corrupt
encoding, and iconv() in reencode_string() fails, saying "I
cannot convert that completely", most of the message can
still be salvageable. This part should allow looser
reencoding if the message will be eyeballed and edited by the
user.
* We would want to avoid reencoding when !strcmp(out_enc, enc).
Both builtin-mailinfo.c and commit.c skip the call to the
function at the calling site, but it might make sense to
teach reencode_string() about such an optimization.
^ permalink raw reply
* Re: [PATCH 1/2] gitweb: Always set 'from_file' and 'to_file' in parse_difftree_raw_line
From: Jakub Narebski @ 2007-11-01 23:46 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7v7il18twn.fsf@gitster.siamese.dyndns.org>
Junio C Hamano wrote:
> Jakub Narebski <jnareb@gmail.com> writes:
>
>> Always set 'from_file' and 'to_file' keys when parsing raw diff output
>> format line, even if filename didn't change (file was not renamed).
>> This allows for simpler code (and no problems with file named '0').
>>
>> Use
>> $diffinfo->{'from_file'}
>> instead of
>> $diffinfo->{'from_file'} || $diffinfo->{'file'}
>> from now on.
>
> Isn't this description the other way around?
Description is in good direction, although I agree that it is
a bit awkward. Perhaps it should read:
Instead of
$diffinfo->{'from_file'} || $diffinfo->{'file'}
it is now enough to use
$diffinfo->{'from_file'}
(because $diffinfo->{'from_file'} is now _always_ set, not only for
renames and copies, when from_name and to_name differ).
--
Jakub Narebski
Poland
^ permalink raw reply
* Re: [PATCH] gitweb: Remove CGI::Carp::set_programname() call from t9500 gitweb test
From: Jakub Narebski @ 2007-11-01 23:36 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vve8l8va0.fsf@gitster.siamese.dyndns.org>
Junio C Hamano wrote:
> Jakub Narebski <jnareb@gmail.com> writes:
>
>> It does appear to do nothing; gitweb is run as standalone program
>> and not as CGI script in this test. This call caused problems later.
>
> Care to describe "later problems" a bit more?
Sorry about that. The problems were while creating yet-to-be send
patch
"gitweb: Add tests for overriding gitweb config with repo config"
Perhaps not in the current version. I forgot details.
Perhaps last sentence "This call caused problems later." should be
simply removed from commit message.
--
Jakub Narebski
Poland
^ permalink raw reply
* [PATCH] Make git-mailsplit strip whitespace from the start of the mailbox file.
From: Simon Sasburg @ 2007-11-01 22:57 UTC (permalink / raw)
To: gitster; +Cc: git, Simon Sasburg
In-Reply-To: <7vr6j98uw5.fsf@gitster.siamese.dyndns.org>
Signed-off-by: Simon Sasburg <Simon.Sasburg@gmail.com>
---
Ah, i see.
Well, this patch also fixes the problem in my case.
builtin-mailsplit.c | 6 ++++++
1 files changed, 6 insertions(+), 0 deletions(-)
diff --git a/builtin-mailsplit.c b/builtin-mailsplit.c
index 43fc373..3fdeb23 100644
--- a/builtin-mailsplit.c
+++ b/builtin-mailsplit.c
@@ -164,6 +164,7 @@ static int split_mbox(const char *file, const char *dir, int allow_bare,
{
char name[PATH_MAX];
int ret = -1;
+ int peek;
FILE *f = !strcmp(file, "-") ? stdin : fopen(file, "r");
int file_done = 0;
@@ -173,6 +174,11 @@ static int split_mbox(const char *file, const char *dir, int allow_bare,
goto out;
}
+ do {
+ peek = fgetc(f);
+ } while (peek == ' ' || peek == '\r' || peek == '\n');
+ ungetc(peek, f);
+
if (fgets(buf, sizeof(buf), f) == NULL) {
/* empty stdin is OK */
if (f != stdin) {
--
1.5.3.4.504.gdf75-dirty
^ permalink raw reply related
* Debugging corrupt object generation
From: Julian Phillips @ 2007-11-01 22:57 UTC (permalink / raw)
To: git
I have been trying to import a repository using fast-import, and as part
of this I have extended fast-import to support copying a path from any
arbitrary commit. This works fine on my small test repository.
However, when I run against my (vastly more complicated) real work
repository things don't go so well. I get a few thousand commits in, and
then it breaks. It appears that I have somehow managed to create a
corrupt object or something.
After a certain commit, and attempt to use that commit generates a "fatal:
unable to apply delta". This appears to be coming from unpack_delta_entry
in sha1_file.c.
Can anyone give me any hints as to how I find out what is causing the
problem? I'm not even sure what it is that isn't working ... and all
attempts to replicate the problem with my test repository have failed.
--
Julian
---
...the prevailing Catholic odor - incense, wax, centuries of mild bleating
from the lips of the flock.
-- Thomas Pynchon, _Gravity's Rainbow_
^ permalink raw reply
* Re: What's cooking in git.git (topics)
From: Junio C Hamano @ 2007-11-01 22:50 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Johan Herland, git, Geert Bosch
In-Reply-To: <alpine.LFD.0.999.0711011459490.3342@woody.linux-foundation.org>
Linus Torvalds <torvalds@linux-foundation.org> writes:
> But yeah, I guess we could make the "clean.Imagirlyman" option (or however
> the "please-don't-hurt-me-by-default" option is spelled) the default. That
> way I'd just feel *extra* manly for immediately disabling it, and laughing
> at you wimps.
That makes me a girly man, I would guess, as I just suggested
making clean.requireForce default to true in the next (or one
after) version of git ;-).
^ permalink raw reply
* Re: [PATCH 0/3] gitweb: Simplify some gitweb URLs generation
From: Junio C Hamano @ 2007-11-01 22:47 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git
In-Reply-To: <1193918789-16421-1-git-send-email-jnareb@gmail.com>
Jakub Narebski <jnareb@gmail.com> writes:
> This series of patches simplifies some gitweb URLs generation by
> providing -replay option to href() subroutine, and then using this
> feature in gitweb code.
>
> Shortlog:
> gitweb: Easier adding/changing parameters to current URL
> gitweb: Use href(-replay=>1, page=>...) to generate pagination links
> gitweb: Use href(-replay=>1, action=>...) to generate alternate views
>
> Diffstat:
> gitweb/gitweb.perl | 82 ++++++++++++++++++++++-----------------------------
> 1 files changed, 35 insertions(+), 47 deletions(-)
If this "-replay" is used carelessly, it could add parameters
that were passed to the page that the original code stripped
away from passing on purpose. Have you checked if the
conversion done with 2/3 and 3/3 are correct (I haven't)?
^ permalink raw reply
* Re: [PATCH 1/2] gitweb: Always set 'from_file' and 'to_file' in parse_difftree_raw_line
From: Junio C Hamano @ 2007-11-01 22:47 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git
In-Reply-To: <1193917089-15920-2-git-send-email-jnareb@gmail.com>
Jakub Narebski <jnareb@gmail.com> writes:
> Always set 'from_file' and 'to_file' keys when parsing raw diff output
> format line, even if filename didn't change (file was not renamed).
> This allows for simpler code (and no problems with file named '0').
>
> Use
> $diffinfo->{'from_file'}
> instead of
> $diffinfo->{'from_file'} || $diffinfo->{'file'}
> from now on.
Isn't this description the other way around?
^ permalink raw reply
* Re: [PATCH] Do no colorify test output if stdout is not a terminal
From: Junio C Hamano @ 2007-11-01 22:47 UTC (permalink / raw)
To: Alex Riesen; +Cc: git
In-Reply-To: <20071101140158.GA14475@steel.home>
Good catch. Thanks.
^ permalink raw reply
* Re: Importing svn branch
From: LCID Fire @ 2007-11-01 22:39 UTC (permalink / raw)
To: Sean; +Cc: git
In-Reply-To: <BAYC1-PASMTP1474D8094F6C5F2CCF2B6CAE8C0@CEZ.ICE>
Sean wrote:
> git-svnimport should probably be officially deprecated; you're not the
> first person to struggle with it. Fortunately there's another option
> provided with Git which will likely give you what you're looking for:
>
> git svn clone http://svn.gnome.org/svn/banshee/branches/banshee/stable
Okay, I tried git-svn after I was stuck with svnimport. Although I still
couldn't figure out how to clone a single branch (due to some confusing
complaints) I just cloned the whole repro, which was working fine.
Thanks.
^ permalink raw reply
* Re: [PATCH 1/3] Introduce --dirty option to git-rebase, allowing you to start from a dirty state.
From: Junio C Hamano @ 2007-11-01 22:36 UTC (permalink / raw)
To: Simon Sasburg; +Cc: gitster, git
In-Reply-To: <7vmytx8upi.fsf@gitster.siamese.dyndns.org>
Junio C Hamano <gitster@pobox.com> writes:
> Doesn't this have the exact same problem with the one in 'next'
> that uses "git-stash create", which Shawn said he was upset
> about, and I said I will revert?
Sorry, --dirty is not the default, which changes everything.
Forget what I said, sorry for the noise.
^ permalink raw reply
* Re: [PATCH 1/3] Introduce --dirty option to git-rebase, allowing you to start from a dirty state.
From: Junio C Hamano @ 2007-11-01 22:30 UTC (permalink / raw)
To: Simon Sasburg; +Cc: gitster, git
In-Reply-To: <1193952624-608-2-git-send-email-Simon.Sasburg@gmail.com>
Doesn't this have the exact same problem with the one in 'next'
that uses "git-stash create", which Shawn said he was upset
about, and I said I will revert?
FYI, this is what I wrote in the log for the revert.
commit 0f49327c9755b6575b447f79b540749d231cb26d
Author: Junio C Hamano <gitster@pobox.com>
Date: Thu Nov 1 13:46:20 2007 -0700
Revert "rebase: allow starting from a dirty tree."
This reverts commit 6c9ad166dbbf9e5a0c09450b892151dbec49b8dc.
Allowing rebase to start in a dirty tree might have been a worthy
goal, but it is not necessarily always wanted (some people prefer
to be reminded that the state is dirty, and think about the next
action that may not be to stash and proceed). Furthermore, depending
on the nature of local changes, unstashing the dirty state on top of
the rebased result is not always desirable.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
^ permalink raw reply
* Re: What's cooking in git.git (topics)
From: Bill Lear @ 2007-11-01 22:26 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Junio C Hamano, Johan Herland, git, Geert Bosch
In-Reply-To: <alpine.LFD.0.999.0711011459490.3342@woody.linux-foundation.org>
On Thursday, November 1, 2007 at 15:05:44 (-0700) Linus Torvalds writes:
>...
>But yeah, I guess we could make the "clean.Imagirlyman" option (or however
>the "please-don't-hurt-me-by-default" option is spelled) the default. That
>way I'd just feel *extra* manly for immediately disabling it, and laughing
>at you wimps.
Precisely my sentiments.
Bill
^ 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