* Re: How to make "git push/pull" work in non-clone repo?
From: Hong-Ming Su @ 2011-11-03 16:10 UTC (permalink / raw)
To: Kirill Likhodedov; +Cc: git
In-Reply-To: <F802D297-95A0-4B1E-894D-9681E0EEF3AD@jetbrains.com>
Thank for your hints. I get "git push" work. The "git pull" need argument.
/d/workspace/git
$ ls
depot work1 work2
/d/workspace/git
$ git clone --bare work1 depot
Cloning into bare repository depot...
done.
/d/workspace/git/work1 (master)
$ git push
fatal: No destination configured to push to.
/d/workspace/git/work1 (master)
$ git pull
fatal: No remote repository specified. Please, specify either a URL or a
remote name from which new revisions should be fetched.
/d/workspace/git/work1 (master)
$ git remote add origin ../depot
/d/workspace/git/work1 (master)
$ git push
Everything up-to-date
/d/workspace/git/work1 (master)
$ git pull
From ../depot
* [new branch] master -> origin/master
You asked me to pull without telling me which branch you
want to merge with, and 'branch.master.merge' in
your configuration file does not tell me, either. Please
specify which branch you want to use on the command line and
try again (e.g. 'git pull <repository> <refspec>').
See git-pull(1) for details.
If you often merge with the same branch, you may want to
use something like the following in your configuration file:
[branch "master"]
remote = <nickname>
merge = <remote-ref>
[remote "<nickname>"]
url = <url>
fetch = <refspec>
/d/workspace/git/work1 (master)
$ git pull origin master:master
Already up-to-date.
2011/11/4 Kirill Likhodedov <Kirill.Likhodedov@jetbrains.com>:
>
>
> 03.11.2011, в 17:59, Hong-Ming Su:
>
>> I create a repo X with git init. After several commit in X, I clone a
>> bare repo Y from X.
>> I try to continue work in X, and push to/pull from Y. The command git
>> push and git pull fails. I see the error message but I do not know
>> which git command can fix that problem.
>> Then I clone Z from Y. git push/pull works in Z.
>> How to make "git push/pull" the same in X as in Z?
>>
>
>
> By cloning Y from X you made X to be a parent of Y while you need vice versa.
> To fix this add Y as a remote to X and set up tracking for you master branch.
>
> By the way, in such cases you'd better write commands you've executed, and the error report you've got.
> " I see the error message but I do not know which git command can fix that problem" - this is zero of useful information.
>
> ----------------------------------
> Kirill Likhodedov
> JetBrains, Inc
> http://www.jetbrains.com
> "Develop with pleasure!"
>
>
^ permalink raw reply
* Re: Repository data loss in fast-export with a merge of a deleted submodule
From: Joshua Jensen @ 2011-11-03 16:05 UTC (permalink / raw)
To: git@vger.kernel.org
In-Reply-To: <4EA9B0B5.6060005@workspacewhiz.com>
----- Original Message -----
From: Joshua Jensen
Date: 10/27/2011 1:27 PM
> We had a submodule that we deleted and then added back into the
> repository at the same location as the former submodule. When running
> fast-export, the newly 'added' files for the merge commit are listed
> and then are followed with a:
>
> M ... path/to/submodule/file
> D path/to/submodule
>
> On fast-import, the resultant repository becomes corrupt due to the
> Delete instruction above occurring AFTER the file adds/modifications.
> The new repository does not match the old repository where the
> fast-export was performed.
>
> I am not familiar with the fast-export code. Can anyone help out?
Okay, I looked into this further, and I came up with a patch that works
for me. Nevertheless, I do not understand exactly what is going on
here, so I would like to defer to someone else's patch to fix the issue.
-Josh
---
builtin/fast-export.c | 8 ++++++++
1 files changed, 8 insertions(+), 0 deletions(-)
diff --git a/builtin/fast-export.c b/builtin/fast-export.c
index 9836e6b..1abc470 100644
--- a/builtin/fast-export.c
+++ b/builtin/fast-export.c
@@ -161,6 +161,14 @@ static int depth_first(const void *a_, const void *b_)
name_a = a->one ? a->one->path : a->two->path;
name_b = b->one ? b->one->path : b->two->path;
+ /*
+ * Move 'D'elete entries first.
+ */
+ if (a->status == 'D')
+ return -1;
+ else if (b->status == 'D')
+ return 1;
+
len_a = strlen(name_a);
len_b = strlen(name_b);
len = (len_a < len_b) ? len_a : len_b;
--
^ permalink raw reply related
* Re: How to find a commit that introduces (not removes) a string?
From: Neal Kreitzinger @ 2011-11-03 15:56 UTC (permalink / raw)
To: Sebastian Schuberth; +Cc: git
In-Reply-To: <j8to8h$vqd$1@dough.gmane.org>
On 11/3/2011 4:50 AM, Sebastian Schuberth wrote:
> Hi all,
>
> I know about git log's -S / -G, but I'm unable to make these search through *introduced* strings only. Is there a way to do so?
>
> Thanks!
>
> PS: I also read [1], but although the author claims to be interested in introduced strings only, he seems to be satisfied with -G, which slightly puzzles me.
>
> [1] http://stackoverflow.com/questions/5816134/git-finding-a-commit-that-introduced-a-string
>
If you are using linux, here is git diff command I use to find leftover
debug statements. I imagine the -S option will work the same in git
log. I pipe the results into grep to filter the results to show only
the additions. (I'm using git 1.7.1)
$ git diff --unified=0 -S"DEBUG" <commit> <commit> -- <path> | grep -e
"diff --" -e "+" | grep -v -e "@@" -e "+++"
maybe you will find this helpful.
v/r,
neal
^ permalink raw reply
* Re: git svn dcommit COMMIT silently checks in everything if COMMIT is not a complete revision
From: Frans Klaver @ 2011-11-03 15:56 UTC (permalink / raw)
To: Reuben Thomas; +Cc: git
In-Reply-To: <CAOnWdoj1eUipRd8M=jsAPdDTNcgEbT7adWR78iU5Oac9DvODkQ@mail.gmail.com>
Hi,
On Thu, Nov 3, 2011 at 4:12 PM, Reuben Thomas <rrt@sc3d.org> wrote:
> If I run
>
> git svn dcommit COMMIT
>
> with COMMIT being an unambiguous, but partial revision string, it
> behaves like git svn dcommit, i.e. commits everything. (If I remember
> to copy and paste the whole nine yards of the revision string, it
> works as expected, i.e. commits just that revision.)
>
> I'd expect it to work like other git commands, and understand partial
> revision strings, or at least bail out saying it was an invalid
> revision.
Sounds like git-svn skips the rev-parse, or doesn't verify. Which
version of git is this?
Workaround would probably be something like
dcommit.sh:
#!/bin/sh
COMMIT=$1
THINGY=$(git rev-parse --verify $COMMIT) || exit $?
git svn dcommit THINGY
$ dcommit.sh COMMIT
Meh. Better fix git-svn.
Cheers,
Frans
^ permalink raw reply
* git svn dcommit COMMIT silently checks in everything if COMMIT is not a complete revision
From: Reuben Thomas @ 2011-11-03 15:12 UTC (permalink / raw)
To: git
If I run
git svn dcommit COMMIT
with COMMIT being an unambiguous, but partial revision string, it
behaves like git svn dcommit, i.e. commits everything. (If I remember
to copy and paste the whole nine yards of the revision string, it
works as expected, i.e. commits just that revision.)
I'd expect it to work like other git commands, and understand partial
revision strings, or at least bail out saying it was an invalid
revision.
--
http://rrt.sc3d.org
^ permalink raw reply
* Re: How to make "git push/pull" work in non-clone repo?
From: Kirill Likhodedov @ 2011-11-03 16:09 UTC (permalink / raw)
To: Hong-Ming Su; +Cc: git
In-Reply-To: <CANiMyiFfiLnK8-q7vTZ9VAtkW8ip2NQfpR4iaU2oSnnonVDuUA@mail.gmail.com>
03.11.2011, в 17:59, Hong-Ming Su:
> I create a repo X with git init. After several commit in X, I clone a
> bare repo Y from X.
> I try to continue work in X, and push to/pull from Y. The command git
> push and git pull fails. I see the error message but I do not know
> which git command can fix that problem.
> Then I clone Z from Y. git push/pull works in Z.
> How to make "git push/pull" the same in X as in Z?
>
By cloning Y from X you made X to be a parent of Y while you need vice versa.
To fix this add Y as a remote to X and set up tracking for you master branch.
By the way, in such cases you'd better write commands you've executed, and the error report you've got.
" I see the error message but I do not know which git command can fix that problem" - this is zero of useful information.
----------------------------------
Kirill Likhodedov
JetBrains, Inc
http://www.jetbrains.com
"Develop with pleasure!"
^ permalink raw reply
* Re: How to make "git push/pull" work in non-clone repo?
From: Frans Klaver @ 2011-11-03 15:07 UTC (permalink / raw)
To: Hong-Ming Su; +Cc: git
In-Reply-To: <CANiMyiFfiLnK8-q7vTZ9VAtkW8ip2NQfpR4iaU2oSnnonVDuUA@mail.gmail.com>
Hi,
On Thu, Nov 3, 2011 at 3:59 PM, Hong-Ming Su <halleyinvent@gmail.com> wrote:
> I create a repo X with git init. After several commit in X, I clone a
> bare repo Y from X.
> I try to continue work in X, and push to/pull from Y. The command git
> push and git pull fails. I see the error message but I do not know
> which git command can fix that problem.
Care to tell us which commands you use and which errors you get? It
will give clues about how to help.
> Then I clone Z from Y. git push/pull works in Z.
> How to make "git push/pull" the same in X as in Z?
Same here.
Cheers,
Frans
^ permalink raw reply
* How to make "git push/pull" work in non-clone repo?
From: Hong-Ming Su @ 2011-11-03 14:59 UTC (permalink / raw)
To: git
Hi,
I create a repo X with git init. After several commit in X, I clone a
bare repo Y from X.
I try to continue work in X, and push to/pull from Y. The command git
push and git pull fails. I see the error message but I do not know
which git command can fix that problem.
Then I clone Z from Y. git push/pull works in Z.
How to make "git push/pull" the same in X as in Z?
Thanks,
Hong-Ming
^ permalink raw reply
* Re: git rev-parse --since=1970-01-01 does not work reliably
From: Nguyen Thai Ngoc Duy @ 2011-11-03 12:36 UTC (permalink / raw)
To: Dmitry V. Levin; +Cc: git
In-Reply-To: <20111101124434.GB22229@altlinux.org>
2011/11/1 Dmitry V. Levin <ldv@altlinux.org>:
> BTW, the timezone specifier (UTC) in "git rev-parse --since='1970-01-01 UTC'"
> seems to be completely ignored by date string parser.
It takes this "00:00 1970-01-01 UTC"
--
Duy
^ permalink raw reply
* [PATCH] log: allow to specify diff pathspec in addition to prune pathspec
From: Nguyễn Thái Ngọc Duy @ 2011-11-03 12:15 UTC (permalink / raw)
To: git; +Cc: Nguyễn Thái Ngọc Duy
In-Reply-To: <1320314474-19536-1-git-send-email-pclouds@gmail.com>
Pathspec in "git log -p <pathspec>" is used for both commit pruning
and diff generation. If --full-diff is given, then diff pathspec is
reset to generate complete diff.
This patch gives more control to diff generation. The first pathspec
in "git log -p -- <pathspec> -- <pathspec>" is used as commit pruning
as usual. The second one is used for diff generation. So --full-diff
now is essentially "git log -p -- <pathspec> --".
This form requires specifying "--" twice. If a file name happens to be
"--", it may be misunderstood as the second "--" marker. This is an
unfortunate consequence for this syntax. Users can still use "./--" or
similar to workaround this.
Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com>
---
Version 2. Now it looks more acceptable.
Documentation/git-log.txt | 9 +++++++--
revision.c | 28 +++++++++++++++++++++++++---
2 files changed, 32 insertions(+), 5 deletions(-)
diff --git a/Documentation/git-log.txt b/Documentation/git-log.txt
index 249fc87..8e00dbc 100644
--- a/Documentation/git-log.txt
+++ b/Documentation/git-log.txt
@@ -9,7 +9,7 @@ git-log - Show commit logs
SYNOPSIS
--------
[verse]
-'git log' [<options>] [<since>..<until>] [[\--] <path>...]
+'git log' [<options>] [<since>..<until>] [[\--] <path>... [\-- <path>...]]
DESCRIPTION
-----------
@@ -52,11 +52,12 @@ OPTIONS
commit was reached.
--full-diff::
- Without this flag, "git log -p <path>..." shows commits that
+ Without this flag, `git log -p <path>...` shows commits that
touch the specified paths, and diffs about the same specified
paths. With this, the full diff is shown for commits that touch
the specified paths; this means that "<path>..." limits only
commits, and doesn't limit diff for those commits.
+ It is equivalent to `git log -p \-- <path>... \--`.
+
Note that this affects all diff-based output types, e.g. those
produced by --stat etc.
@@ -76,6 +77,10 @@ produced by --stat etc.
+
To prevent confusion with options and branch names, paths may need to
be prefixed with "\-- " to separate them from options or refnames.
++
+If the second "\--" is found, the following pathspec is used to limit
+diff generation. Note that this affects all diff-based output types,
+e.g. those produced by --stat etc.
include::rev-list-options.txt[]
diff --git a/revision.c b/revision.c
index 8764dde..f560647 100644
--- a/revision.c
+++ b/revision.c
@@ -1682,20 +1682,37 @@ static int handle_revision_pseudo_opt(const char *submodule,
*/
int setup_revisions(int argc, const char **argv, struct rev_info *revs, struct setup_revision_opt *opt)
{
- int i, flags, left, seen_dashdash, read_from_stdin, got_rev_arg = 0;
+ int i, flags, left, read_from_stdin, got_rev_arg = 0;
+ int seen_dashdash, seen_second_dashdash;
struct cmdline_pathspec prune_data;
+ struct cmdline_pathspec diff_data;
const char *submodule = NULL;
memset(&prune_data, 0, sizeof(prune_data));
+ memset(&diff_data, 0, sizeof(diff_data));
if (opt)
submodule = opt->submodule;
/* First, search for "--" */
- seen_dashdash = 0;
+ seen_dashdash = seen_second_dashdash = 0;
for (i = 1; i < argc; i++) {
+ int i2;
const char *arg = argv[i];
if (strcmp(arg, "--"))
continue;
+
+ /* Search for second "--" */
+ for (i2 = i + 1; i2 < argc; i2++) {
+ const char *arg = argv[i2];
+ if (strcmp(arg, "--"))
+ continue;
+ argv[i2] = NULL;
+ if (argv[i2 + 1])
+ append_prune_data(&diff_data, argv + i2 + 1);
+ seen_second_dashdash = 1;
+ break;
+ }
+
argv[i] = NULL;
argc = i;
if (argv[i + 1])
@@ -1817,7 +1834,12 @@ int setup_revisions(int argc, const char **argv, struct rev_info *revs, struct s
/* Can't prune commits with rename following: the paths change.. */
if (!DIFF_OPT_TST(&revs->diffopt, FOLLOW_RENAMES))
revs->prune = 1;
- if (!revs->full_diff)
+ if (seen_second_dashdash) {
+ ALLOC_GROW(diff_data.path, diff_data.nr+1, diff_data.alloc);
+ diff_data.path[diff_data.nr++] = NULL;
+ diff_tree_setup_paths(diff_data.path, &revs->diffopt);
+ }
+ else if (!revs->full_diff)
diff_tree_setup_paths(revs->prune_data.raw, &revs->diffopt);
}
if (revs->combine_merges)
--
1.7.4.74.g639db
^ permalink raw reply related
* Re: error from 'git push' on v1.7.8-rc0
From: Stefan Näwe @ 2011-11-03 11:49 UTC (permalink / raw)
To: gitlist, Junio C Hamano
In-Reply-To: <CAJzBP5Q1_zX+H0jeBZNB81KLYAbtJWhUuHA3rf8CuW-_OSFXbg@mail.gmail.com>
On Thu, Nov 3, 2011 at 12:43 PM, Stefan Näwe <stefan.naewe@gmail.com> wrote:
> I get errors from git push when trying to delete a (remote) branch:
>
> $ ./bin-wrappers/git versiongit version 1.7.8.rc0
> $ ./bin-wrappers/git push -q . :refs/heads/nogofatal: bad object
$ ./bin-wrappers/git push -q . :refs/heads/nogo
(re-wrapped)
$ ./bin-wrappers/git push -q . :refs/heads/nogo
fatal: bad object 0000000000000000000000000000000000000000
fatal: bad object 0000000000000000000000000000000000000000
remote: warning: Allowing deletion of corrupt ref.
Stefan
--
----------------------------------------------------------------
python -c "print '73746566616e2e6e6165776540676d61696c2e636f6d'.decode('hex')"
^ permalink raw reply
* error from 'git push' on v1.7.8-rc0
From: Stefan Näwe @ 2011-11-03 11:43 UTC (permalink / raw)
To: gitlist, Junio C Hamano
I get errors from git push when trying to delete a (remote) branch:
$ ./bin-wrappers/git versiongit version 1.7.8.rc0
$ ./bin-wrappers/git push -q . :refs/heads/nogofatal: bad object
0000000000000000000000000000000000000000fatal: bad object
0000000000000000000000000000000000000000remote: warning: Allowing
deletion of corrupt ref.
I bisected this to: 52fed6e receive-pack: check connectivity before
concluding "git push"
$ git describe 52fed6e~1
v1.7.5.3-492-gf96400c
$ ./bin-wrappers/git version
git version 1.7.5.3.492.gf9640
$ ./bin-wrappers/git push -q . :refs/heads/nogo
remote: warning: Allowing deletion of corrupt ref.
It makes no difference if the branch to be deleted exists, or not.
Regards,
Stefan
--
----------------------------------------------------------------
python -c "print '73746566616e2e6e6165776540676d61696c2e636f6d'.decode('hex')"
^ permalink raw reply
* Re: [PATCH 1/2] git-gui: make config gui.warndetachedcommit a boolean
From: Bert Wesarg @ 2011-11-03 11:27 UTC (permalink / raw)
To: Pat Thoyts; +Cc: Heiko Voigt, git, Bert Wesarg
In-Reply-To: <0f4995b5df707782c73ec83171fb2f512ae887ef.1319312280.git.bert.wesarg@googlemail.com>
On Sat, Oct 22, 2011 at 21:39, Bert Wesarg <bert.wesarg@googlemail.com> wrote:
> Signed-off-by: Bert Wesarg <bert.wesarg@googlemail.com>
> ---
> lib/commit.tcl | 2 +-
> lib/option.tcl | 1 +
> 2 files changed, 2 insertions(+), 1 deletions(-)
>
> diff --git a/lib/commit.tcl b/lib/commit.tcl
> index 372bed9..e27e148 100644
> --- a/lib/commit.tcl
> +++ b/lib/commit.tcl
> @@ -263,7 +263,7 @@ proc commit_commitmsg {curHEAD msg_p} {
> global is_detached repo_config
> global pch_error
>
> - if {$is_detached && $repo_config(gui.warndetachedcommit)} {
> + if {$is_detached && [is_config_true gui.warndetachedcommit]} {
> set msg [mc "You are about to commit on a detached head.\
> This is a potentially dangerous thing to do because if you switch\
> to another branch you will loose your changes and it can be difficult\
> diff --git a/lib/option.tcl b/lib/option.tcl
> index 719103a..f7f866b 100644
> --- a/lib/option.tcl
> +++ b/lib/option.tcl
> @@ -156,6 +156,7 @@ proc do_options {} {
> {i-0..99 gui.commitmsgwidth {mc "Commit Message Text Width"}}
> {t gui.newbranchtemplate {mc "New Branch Name Template"}}
> {c gui.encoding {mc "Default File Contents Encoding"}}
> + {b gui.warndetachedcommit {mc "Warn before commiting to a detached head"}}
> {s gui.stageuntracked {mc "Staging of untracked files"} {list "yes" "no" "ask"}}
> } {
> set type [lindex $option 0]
Pat,
if you're interessted in this patch, please fix the typo in the second
hunk, mentioning 'commiting'.
Also shouldn't this variable be called gui.warndetachedhead?
Thanks.
Bert
> --
> 1.7.7.908.g383b5
>
>
^ permalink raw reply
* Re: git-p4: problem with commit 97a21ca50ef8
From: Vitor Antunes @ 2011-11-03 11:04 UTC (permalink / raw)
To: Michael Wookey; +Cc: Pete Wyckoff, Git Mailing List, Luke Diamand
In-Reply-To: <CAOk9v+_xaS_Y1m17TROOSjgiscT+QEJWbpZbAZFmh8_tAviF6Q@mail.gmail.com>
Hi Michael,
On Wed, Nov 2, 2011 at 10:42 PM, Michael Wookey <michaelwookey@gmail.com> wrote:
> I tried your suggested version of git-p4 (at rev 630fb678c46c) and
> unfortunately, the perforce repository fails to import. Firstly, there
> was a problem with importing UTF-16 encoded files, secondly the
> "apple" filetype files are still skipped.
I had no intention of directing you to try that version. Sorry for
misleading you on this.
I just found it interesting that P4's KB contains an article that
directs users to another version which isn't this one.
--
Vitor Antunes
^ permalink raw reply
* Re: [PATCH v3 2/7] invalidate_ref_cache(): take the submodule as parameter
From: Michael Haggerty @ 2011-11-03 10:23 UTC (permalink / raw)
To: Junio C Hamano
Cc: git, Jeff King, Drew Northup, Jakub Narebski, Heiko Voigt,
Johan Herland, Julian Phillips
In-Reply-To: <7vmxczmrb0.fsf@alter.siamese.dyndns.org>
On 10/17/2011 08:00 PM, Junio C Hamano wrote:
> Michael Haggerty <mhagger@alum.mit.edu> writes:
>> On 10/12/2011 09:19 PM, Junio C Hamano wrote:
>>> Michael Haggerty <mhagger@alum.mit.edu> writes:
>>> ...
>>> Probably that is what all the existing callers want, but I would have
>>> expected that an existing feature would be kept, perhaps like this
>>> instead:
>>>
>>> if (!submodule) {
>>> struct ref_cache *c;
>>> for (c = ref_cache; c; c = c->next)
>>> clear_ref_cache(c);
>>> } else {
>>> clear_ref_cache(get_ref_cache(submodule);
>>> }
>> ...
>> Your specific suggestion would not work because currently
>> submodule==NULL signifies the main module. However, it would be easy to
>> add the few-line function when/if it is needed.
>
> I think "submodule==NULL" is probably a mistake; "" would make more sense
> given that you are storing the string in name[FLEX_ARRAY] field.
Sorry I didn't respond to this earlier.
The public API convention (which predates my changes) is that "char
*submodule" arguments either point at the relative path to the submodule
or are NULL to denote the main module. But since these are stored
internally in a name[FLEX_ARRAY] field, I have been using "" internally
to denote the main module. I believe that everything is done correctly,
but I admit that the use of different conventions internally and
externally is a potential source of programming errors.
If this is viewed as something that needs changing, the easiest thing
would probably be to add a "const char *submodule" in the ref_cache data
structure that either contains NULL or points at the name field, and to
consistently use the convention that the main module must always be
denoted by NULL. The space overhead would be negligible because the
number of ref_cache objects is limited to the number of submodules plus 1.
Michael
--
Michael Haggerty
mhagger@alum.mit.edu
http://softwareswirl.blogspot.com/
^ permalink raw reply
* [PATCH] log: support --full-diff=<pathspec>
From: Nguyễn Thái Ngọc Duy @ 2011-11-03 10:01 UTC (permalink / raw)
To: git; +Cc: Nguyễn Thái Ngọc Duy
I wanted to check if any patches that update builtin/fsck.c also
update 't' directory and git seemed not support this case
(true?). With this I can do
git log --patch --full-diff="'builtin/fsck.c' 't'" -- builtin/fsck.c
I guess this may be something people find useful.
This patch is a bit inconvenient though because <pathspec> is parsed
with sq_dequote_to_argv() and all arguments must be wrapped by ''.
Also "full-diff" name does not make much sense when it comes with
pathspec.
Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com>
---
revision.c | 19 +++++++++++++++++++
revision.h | 1 +
2 files changed, 20 insertions(+), 0 deletions(-)
diff --git a/revision.c b/revision.c
index 8764dde..f508953 100644
--- a/revision.c
+++ b/revision.c
@@ -13,6 +13,7 @@
#include "decorate.h"
#include "log-tree.h"
#include "string-list.h"
+#include "quote.h"
volatile show_early_output_fn_t show_early_output;
@@ -1531,6 +1532,10 @@ static int handle_revision_opt(struct rev_info *revs, int argc, const char **arg
} else if (!strcmp(arg, "--full-diff")) {
revs->diff = 1;
revs->full_diff = 1;
+ } else if (!prefixcmp(arg, "--full-diff=")) {
+ revs->diff = 1;
+ revs->full_diff = 1;
+ revs->full_diff_opt = arg + strlen("--full-diff=");
} else if (!strcmp(arg, "--full-history")) {
revs->simplify_history = 0;
} else if (!strcmp(arg, "--relative-date")) {
@@ -1819,6 +1824,20 @@ int setup_revisions(int argc, const char **argv, struct rev_info *revs, struct s
revs->prune = 1;
if (!revs->full_diff)
diff_tree_setup_paths(revs->prune_data.raw, &revs->diffopt);
+ else if (revs->full_diff_opt) {
+ const char **argv = NULL;
+ int alloc = 0, nr = 0;
+ char *arg;
+
+ arg = xstrdup(revs->full_diff_opt);
+ sq_dequote_to_argv(arg, &argv, &nr, &alloc);
+
+ ALLOC_GROW(argv, nr + 1, alloc);
+ argv[nr] = NULL;
+ argv = get_pathspec(revs->prefix, argv);
+
+ diff_tree_setup_paths(argv, &revs->diffopt);
+ }
}
if (revs->combine_merges)
revs->ignore_merges = 0;
diff --git a/revision.h b/revision.h
index 6aa53d1..baa709c 100644
--- a/revision.h
+++ b/revision.h
@@ -137,6 +137,7 @@ struct rev_info {
const char *subject_prefix;
int no_inline;
int show_log_size;
+ const char *full_diff_opt;
/* Filter by commit log message */
struct grep_opt grep_filter;
--
1.7.3.1.256.g2539c.dirty
^ permalink raw reply related
* How to find a commit that introduces (not removes) a string?
From: Sebastian Schuberth @ 2011-11-03 9:50 UTC (permalink / raw)
To: git
Hi all,
I know about git log's -S / -G, but I'm unable to make these search through *introduced* strings only. Is there a way to do so?
Thanks!
PS: I also read [1], but although the author claims to be interested in introduced strings only, he seems to be satisfied with -G, which slightly puzzles me.
[1] http://stackoverflow.com/questions/5816134/git-finding-a-commit-that-introduced-a-string
--
Sebastian Schuberth
^ permalink raw reply
* [PATCH] fsck: print progress
From: Nguyễn Thái Ngọc Duy @ 2011-11-03 8:50 UTC (permalink / raw)
To: git; +Cc: Jeff King, Nguyễn Thái Ngọc Duy
In-Reply-To: <20111103033325.GA10230@sigill.intra.peff.net>
fsck is usually a long process and it would be nice if it prints
progress from time to time.
Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com>
---
2011/11/3 Jeff King <peff@peff.net>:
> We're actually leaking some memory here, since stop_progress will also
> free() the progress object and any associated resources. It's not a lot,
> but it's kind of ugly.
Fixed by always calling stop_progress_msg() but make sure no newline
is printed (actually "done\n" is not)
Also fixed "progress" initialization in fsck_object_dir()
> Or perhaps we could even come up with a total object count
> before starting. I guess it would involve mapping each pack index
> simultaneously, though by my reading of the code, I think we do that
> anyway (the opened index is cached in the pack object).
I think this way is better because we can count two numbers at a
time, nr. packs and nr. objects of current pack. Total object
(I assume you mean of all packs) may be less informative.
Documentation/git-fsck.txt | 12 +++++++++-
builtin/fsck.c | 52 +++++++++++++++++++++++++++++++++++++++++--
pack-check.c | 11 ++++++--
pack.h | 4 ++-
progress.c | 2 +-
5 files changed, 72 insertions(+), 9 deletions(-)
diff --git a/Documentation/git-fsck.txt b/Documentation/git-fsck.txt
index a2a508d..5245101 100644
--- a/Documentation/git-fsck.txt
+++ b/Documentation/git-fsck.txt
@@ -10,7 +10,8 @@ SYNOPSIS
--------
[verse]
'git fsck' [--tags] [--root] [--unreachable] [--cache] [--no-reflogs]
- [--[no-]full] [--strict] [--verbose] [--lost-found] [<object>*]
+ [--[no-]full] [--strict] [--verbose] [--lost-found]
+ [--[no-]progress] [<object>*]
DESCRIPTION
-----------
@@ -72,6 +73,15 @@ index file, all SHA1 references in .git/refs/*, and all reflogs (unless
a blob, the contents are written into the file, rather than
its object name.
+--progress::
+--no-progress::
+ When fsck is run in a terminal, it will show the progress.
+ These options can force progress to be shown or not
+ regardless terminal check.
++
+Progress is not shown when --verbose is used. --progress is ignored
+in this case.
+
It tests SHA1 and general object sanity, and it does full tracking of
the resulting reachability and everything else. It prints out any
corruption it finds (missing or bad objects), and if you use the
diff --git a/builtin/fsck.c b/builtin/fsck.c
index df1a88b..e19b78c 100644
--- a/builtin/fsck.c
+++ b/builtin/fsck.c
@@ -11,6 +11,7 @@
#include "fsck.h"
#include "parse-options.h"
#include "dir.h"
+#include "progress.h"
#define REACHABLE 0x0001
#define SEEN 0x0002
@@ -27,6 +28,8 @@ static const char *head_points_at;
static int errors_found;
static int write_lost_and_found;
static int verbose;
+static int show_progress = -1;
+
#define ERROR_OBJECT 01
#define ERROR_REACHABLE 02
@@ -512,15 +515,20 @@ static void get_default_heads(void)
static void fsck_object_dir(const char *path)
{
int i;
+ struct progress *progress = NULL;
if (verbose)
fprintf(stderr, "Checking object directory\n");
+ if (show_progress)
+ progress = start_progress("Checking object directories", 256);
for (i = 0; i < 256; i++) {
static char dir[4096];
sprintf(dir, "%s/%02x", path, i);
fsck_dir(i, dir);
+ display_progress(progress, i+1);
}
+ stop_progress(&progress);
fsck_sha1_list();
}
@@ -591,6 +599,7 @@ static struct option fsck_opts[] = {
OPT_BOOLEAN(0, "strict", &check_strict, "enable more strict checking"),
OPT_BOOLEAN(0, "lost-found", &write_lost_and_found,
"write dangling objects in .git/lost-found"),
+ OPT_BOOL (0, "progress", &show_progress, "show progress"),
OPT_END(),
};
@@ -603,6 +612,12 @@ int cmd_fsck(int argc, const char **argv, const char *prefix)
read_replace_refs = 0;
argc = parse_options(argc, argv, prefix, fsck_opts, fsck_usage, 0);
+
+ if (show_progress == -1)
+ show_progress = isatty(2);
+ if (verbose)
+ show_progress = 0;
+
if (write_lost_and_found) {
check_full = 1;
include_reflogs = 0;
@@ -622,20 +637,51 @@ int cmd_fsck(int argc, const char **argv, const char *prefix)
if (check_full) {
struct packed_git *p;
+ int i, nr_packs = 0;
+ struct progress *progress = NULL;
prepare_packed_git();
+
for (p = packed_git; p; p = p->next)
+ nr_packs++;
+
+ for (i = 1, p = packed_git; p; p = p->next, i++) {
+ if (show_progress) {
+ char buf[32];
+ snprintf(buf, sizeof(buf), "Verifying pack %d/%d",
+ i, nr_packs);
+ if (open_pack_index(p))
+ continue;
+ progress = start_progress(buf, p->num_objects);
+ }
/* verify gives error messages itself */
- verify_pack(p);
+ verify_pack(p, progress);
- for (p = packed_git; p; p = p->next) {
+ if (p->next)
+ stop_progress_msg(&progress, NULL);
+ }
+ stop_progress(&progress);
+
+ for (i = 1, p = packed_git; p; p = p->next, i++) {
+ char buf[64];
uint32_t j, num;
if (open_pack_index(p))
continue;
num = p->num_objects;
- for (j = 0; j < num; j++)
+
+ snprintf(buf, sizeof(buf), "Checking objects on pack %d/%d",
+ i, nr_packs);
+ if (show_progress)
+ progress = start_progress(buf, num);
+ for (j = 0; j < num; j++) {
fsck_sha1(nth_packed_object_sha1(p, j));
+ display_progress(progress, j+1);
+ }
+
+ if (p->next)
+ stop_progress_msg(&progress, NULL);
}
+ stop_progress(&progress);
}
heads = 0;
diff --git a/pack-check.c b/pack-check.c
index 0c19b6e..e30c18c 100644
--- a/pack-check.c
+++ b/pack-check.c
@@ -1,6 +1,7 @@
#include "cache.h"
#include "pack.h"
#include "pack-revindex.h"
+#include "progress.h"
struct idx_entry {
off_t offset;
@@ -42,7 +43,8 @@ int check_pack_crc(struct packed_git *p, struct pack_window **w_curs,
}
static int verify_packfile(struct packed_git *p,
- struct pack_window **w_curs)
+ struct pack_window **w_curs,
+ struct progress *progress)
{
off_t index_size = p->index_size;
const unsigned char *index_base = p->index_data;
@@ -126,7 +128,10 @@ static int verify_packfile(struct packed_git *p,
break;
}
free(data);
+ if ((i & 1023) == 0)
+ display_progress(progress, i);
}
+ display_progress(progress, i);
free(entries);
return err;
@@ -155,7 +160,7 @@ int verify_pack_index(struct packed_git *p)
return err;
}
-int verify_pack(struct packed_git *p)
+int verify_pack(struct packed_git *p, struct progress *progress)
{
int err = 0;
struct pack_window *w_curs = NULL;
@@ -164,7 +169,7 @@ int verify_pack(struct packed_git *p)
if (!p->index_data)
return -1;
- err |= verify_packfile(p, &w_curs);
+ err |= verify_packfile(p, &w_curs, progress);
unuse_pack(&w_curs);
return err;
diff --git a/pack.h b/pack.h
index 722a54e..572794f 100644
--- a/pack.h
+++ b/pack.h
@@ -70,10 +70,12 @@ struct pack_idx_entry {
off_t offset;
};
+struct progress;
+
extern const char *write_idx_file(const char *index_name, struct pack_idx_entry **objects, int nr_objects, const struct pack_idx_option *, unsigned char *sha1);
extern int check_pack_crc(struct packed_git *p, struct pack_window **w_curs, off_t offset, off_t len, unsigned int nr);
extern int verify_pack_index(struct packed_git *);
-extern int verify_pack(struct packed_git *);
+extern int verify_pack(struct packed_git *, struct progress *);
extern void fixup_pack_header_footer(int, unsigned char *, const char *, uint32_t, unsigned char *, off_t);
extern char *index_pack_lockfile(int fd);
extern int encode_in_pack_object_header(enum object_type, uintmax_t, unsigned char *);
diff --git a/progress.c b/progress.c
index 3971f49..fc96a5f 100644
--- a/progress.c
+++ b/progress.c
@@ -245,7 +245,7 @@ void stop_progress_msg(struct progress **p_progress, const char *msg)
if (!progress)
return;
*p_progress = NULL;
- if (progress->last_value != -1) {
+ if (progress->last_value != -1 && msg) {
/* Force the last update */
char buf[128], *bufp;
size_t len = strlen(msg) + 5;
--
1.7.3.1.256.g2539c.dirty
^ permalink raw reply related
* Re: Folder level Acces in git
From: Magnus Bäck @ 2011-11-03 7:17 UTC (permalink / raw)
To: redhat1981; +Cc: git
In-Reply-To: <1320300655224-6958047.post@n2.nabble.com>
On Thursday, November 03, 2011 at 07:10 CET,
redhat1981 <redhat1981@gmail.com> wrote:
> I am using Gitosis, Adding the gitosis conf file
>
> [group testabc]
> writable = testabc
> members = shrii Abhijeet premkumar
> add cgit = yes
> gitweb = yes
>
>
> [group testabc-readonly]
> readonly = testabc
> members = Ganesh Shweta
> add cgit = yes
> gitweb = yes
>
> Inside the repository, testabc let us say there are folders folder1,
> folder 2 etc, I want some users to have read/write, read or no access
> to the folder1 or folder2, Is this possible in Git, I have done it in
> SVN, Please help!!
Given Git's nature, you can't have read access restrictions on a sub-git
level (i.e. file/directory level). For basically the same reason, you
can never prevent users from making (local) commits that modify certain
paths (but you can encourage people to have local hooks to enforce such
policies). What you *can* do is install a server-side update hook that
rejects attempts to push commits that modify certain paths. If you're
willing to trade Gitosis for Gitolite, you get that feature for free.
http://book.git-scm.com/5_git_hooks.html
http://progit.org/book/ch4-8.html
--
Magnus Bäck Opinions are my own and do not necessarily
SW Configuration Manager represent the ones of my employer, etc.
Sony Ericsson
^ permalink raw reply
* Re: [PATCH] Add options to specify snapshot file name, prefix
From: Thomas Guyot-Sionnest @ 2011-11-03 6:28 UTC (permalink / raw)
To: Thomas Guyot-Sionnest; +Cc: git
In-Reply-To: <1320298641-11149-1-git-send-email-dermoth@aei.ca>
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Please disregard; i've actually managed to break the patch while playing
with it.
I will resubmit.
- --
Thomas
On 11-11-03 01:37 AM, Thomas Guyot-Sionnest wrote:
> commit b629275 implemented "smart" snapshot names and prefixes. I have
> scripts that used to rely on the old behaviour which allowed in some
> cases to have fixed prefix, and would require modifications to work with
> newer Gitweb.
>
> This patch adds two parameters for overriding the snapshot name and
> prefix, sn and sp respectively. For example, to get a snapshot
> named "myproject.[suffix]" with no prefix one can add this query string:
> ?sn=myproject;sp=
>
> Signed-off-by: Thomas Guyot-Sionnest <dermoth@aei.ca>
> ---
> gitweb/gitweb.perl | 8 ++++++++
> 1 files changed, 8 insertions(+), 0 deletions(-)
>
> diff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl
> index 4f0c3bd..4820ef7 100755
> --- a/gitweb/gitweb.perl
> +++ b/gitweb/gitweb.perl
> @@ -756,6 +756,8 @@ our @cgi_param_mapping = (
> searchtext => "s",
> searchtype => "st",
> snapshot_format => "sf",
> + snapshot_name => "sn",
> + snapshot_prefix => "sp",
> extra_options => "opt",
> search_use_regexp => "sr",
> ctag => "by_tag",
> @@ -6684,6 +6686,12 @@ sub git_snapshot {
> }
>
> my ($name, $prefix) = snapshot_name($project, $hash);
> + if (defined($input_params{'snapshot_name'})) {
> + $name = $input_params{'snapshot_name'};
> + }
> + if (defined($input_params{'snapshot_prefix'})) {
> + $prefix = $input_params{'snapshot_prefix'};
> + }
> my $filename = "$name$known_snapshot_formats{$format}{'suffix'}";
> my $cmd = quote_command(
> git_cmd(), 'archive',
- --
Thomas
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAk6yNJcACgkQ6dZ+Kt5BchZkCgCgvJ9kAF636HYCAwQ7LoWu8ckG
8+8Anj5ocii3c7vKQ2/eVjcAvDJxsvhQ
=jGwr
-----END PGP SIGNATURE-----
^ permalink raw reply
* Folder level Acces in git
From: redhat1981 @ 2011-11-03 6:10 UTC (permalink / raw)
To: git
Hi,
I am using Gitosis, Adding the gitosis conf file
[group testabc]
writable = testabc
members = shrii Abhijeet premkumar
add cgit = yes
gitweb = yes
[group testabc-readonly]
readonly = testabc
members = Ganesh Shweta
add cgit = yes
gitweb = yes
Inside the repository, testabc let us say there are folders folder1, folder
2 etc, I want some users to have read/write, read or no access to the
folder1 or folder2, Is this possible in Git, I have done it in SVN, Please
help!!
redhat1981@gmail.com
--
View this message in context: http://git.661346.n2.nabble.com/Folder-level-Acces-in-git-tp6958047p6958047.html
Sent from the git mailing list archive at Nabble.com.
^ permalink raw reply
* Re: New Feature wanted: Is it possible to let git clone continue last break point?
From: Shawn Pearce @ 2011-11-03 4:19 UTC (permalink / raw)
To: Jeff King
Cc: Junio C Hamano, Jonathan Nieder, netroby, Git Mail List,
Tomas Carnecky
In-Reply-To: <20111103024248.GA9492@sigill.intra.peff.net>
On Wed, Nov 2, 2011 at 19:42, Jeff King <peff@peff.net> wrote:
> On Wed, Nov 02, 2011 at 05:06:53PM -0700, Shawn O. Pearce wrote:
>
> I thought of doing something like that, but I wanted to be able to make
> cross-domain links. The "302 to a CDN" thing is a clever hack, but it
> requires more control of the webserver than some users might have. And
> of course it doesn't work for the "redirect to git:// on a different
> server" trick. Or redirect from "git://".
I agree. Later I said I regret this being a bundle file. I also regret
it being this $URL/clone.bundle thing. Its a reasonable quick hack in
Python for repo. Its cheap for my servers to respond 404 Not Found or
302 Found, and cheap to use the CDN. But it isn't the right solution
for git-core.
It has given us some useful information already in the context of
android.googlesource.com. It appears to work quite well for
distributing the large Android operating system. So the notion of
making packs available from another URL than the main repository, and
doing it as primarily a pack and not the native Git protocol, with a
follow-up incremental fetch to bring the client current seems to work.
:-)
> My thought of having it in "refs/mirrors" is only slightly less hacky,
> but I think covers all of those cases. :)
Right, but this would have been a bit more work for me to code in Python. :-)
Long term this may be a better approach, because it does allow the
user to control the redirect without having full control over their
HTTP server. It also supports redirections across protocols like you
noted above. So its probably the direction we will see git-core take.
>> Actually, I really think the bundle thing is wasteful.... sendfile() capability.
>
> I didn't quite parse this. You say it is wasteful, but then indicate
> that it can use sendfile(), which is a good thing.
Apparently I was babbling. Based on what else you say, we agree. That
is good enough for me.
> However, I do agree with this:
>
>> Its also expensive for kernel.org to create each Git repository twice
>> on disk. The disk is cheap. Its the kernel buffer cache that is damned
>> expensive.
>
> Doubling the disk cache required is evil and ugly. I was hoping it
> wouldn't matter because the bundle would be hosted on some far-away CDN
> server anyway, though. But that is highly dependent on your setup. And
> it's really just glossing over the fact that you have twice as many
> servers. ;)
Right. :-)
In my opinion this is the important part. We shouldn't double the disk
usage required to support this. Most users can't afford the extra disk
cache or the extra server required to make this work well. But they
can use sendfile() on the server they have and get a lot of
improvement in clone speed due to lower system load, plus resumable
clone for the relatively stable history part.
> Another issue with packs is that they generally aren't supposed to be
> --thin on disk, whereas bundles can be. So I could point you to a
> succession of bundles. Which is maybe a feature, or maybe just makes
> things insanely complex[1].
Actually we can store --thin on disk safely. Don't laugh until you
finish reading it through.
To build an incremental pack we modify pack-objects to construct a
completed thin pack on disk. Build up the list of objects that you
want in the thin pack, as though it were thin. Use REF_DELTA format to
reference objects that are not in this set but are delta bases. Copy
the necessary delta bases from the base pack over to the thin pack, at
the end just like it would be if received over the wire. The pack is
now self-contained like its supposed to be, but the tail of it is
redundant information.
If you cache alongside of the pack the "thin" object count, the cut
offset of the thin vs. completed bases, and the SHA-1 of the "thin"
pack, you can serve the "thin" pack by copying the header, then the
region of the file up to the cut point, and the final SHA-1. And there
are no pack file format changes involved.
:-)
Obviously this has some downside. Using REF_DELTA instead of OFS_DELTA
for the relatively small number of references from the "thin" part to
the completed part at the tail isn't a big disk space overhead. The
big overhead is storing the boundary data that served as delta bases
at the tail of this incremental pack. But we already do that when you
transfer this section of data over the network and it was more than
100 objects.
So I think we can get away with doing this. The serving repository is
in no worse state than if the owner had just pushed all of that
incremental stuff into the serving repository and it completed as a
thin pack. With only 2 packs in the serving repository (e.g. the
historical stuff that is stable, and the incremental current thin pack
+ completed bases), git gc --auto wouldn't even kick in to GC this
thing for a while *anyway*. So we already probably have a ton of
repositories in the wild that exhibit this disk layout and space
usage, and nobody has complained about it.
For a server admin or repository owner who cares about his user's
resumable clone support, carrying around a historical pack and a
single new incremental pack for say 2-3 months before repacking the
entire thing down to 1 new historical pack... the disk space and
additional completed base data is an acceptable cost. We already do
it.
Clients can figure out whether or not they should use an incremental
pack download vs the native Git protocol if the incremental pack does
like a bundle does and stores the base information alongside of it.
Actually you don't want the base (the ^ lines in a bundle), but the
immediate child of those. If the client has any of those children,
there is some chance the client has other objects in the pack and
should favor native protocol. But if the client has none of those base
children, but does have the base, it may be more efficient to download
the entire pack to bring the client current.
The problem with incremental pack updates is balancing the number of
round-trip requests against the update rate of the repository against
the polling frequency of the client. Its not an easy thing to solve.
However, we may be able to do better if the server can do a reasonably
fast concat of these thin pack slices together by writing a new object
header and computing the SHA-1 trailer as it goes. Instead of
computing actual graph connectivity, just concat packs together
between the base children and the requested tips. This probably
requires that the client ask for every branch (e.g. the typical
refs/heads/*:refs/remotes/origin/* refspec) and that branches didn't
rewind. But I think this is so common its perhaps worthwhile to look
into optimizing. But note we can do this in the native protocol at the
server side without telling the client anything, or changing the
protocol. It just isn't resumable without a bit more glue to have a
state marker available to the client. Nor does it work on a CDN
without giving the client more information. :-)
> So the sendfile() stuff would always happen over http.
I'm OK with that. I was just saying we may be able to also support
sendfile() over git:// if the repository owner / git-daemon owner
wants us to. Or if not sendfile(), a simple read-write loop that
doesn't have to look at the data, since the client will validate it
all.
> Yeah, I'm liking that idea. In reference to my [1] above, what I've
> started with is making:
>
> git fetch http://host/foo.bundle
This should work, whether or not we use it for resumable clone. Its
just nice to have that tiny bit of extra glue to make it easy to pull
a bundle. So I'd like this too. :-)
> Pulling down a non-thin packfile makes the problem go away. We can spool
> it right into objects/pack, index it on the fly, and if all is well,
> move it into its final filename. If the transfer is interrupted, you
> drop what's been indexed so far, finish the transfer, and then re-start
> the indexing from scratch (actually, the "on the fly" would probably
> involve teaching index-pack to be clever about incrementally reading a
> partially written file, but it should be possible).
I wonder if we can teach index-pack to work with a thin pack on disk
and complete that by appending to the file, in addition to the
streaming from stdin it supports. Seems like that should be possible.
So then you could save a thin pack to a temp file on disk, and thus
could split a bundle header from its pack content, saving them into
two different temp files, allowing index-pack to avoid copying the
pack portion if its non-thin, or if its a huge thin pack.
I did think about doing this in "repo" and decided it was complex, and
not worth the effort. So we spool. 2G+ bundles. Its not the most
pleasant user experience. If I had more time, I would have tried to
split the bundle header from the pack and written the pack directly
off for index-pack to read from disk.
^ permalink raw reply
* Re: [git patches] libata updates, GPG signed (but see admin notes)
From: Linus Torvalds @ 2011-11-03 4:13 UTC (permalink / raw)
To: Jochen Striepe
Cc: Shawn Pearce, Junio C Hamano, git, James Bottomley, Jeff Garzik,
Andrew Morton, linux-ide, LKML
In-Reply-To: <20111103032205.GA25888@pompeji.miese-zwerge.org>
On Wed, Nov 2, 2011 at 8:22 PM, Jochen Striepe <jochen@tolot.escape.de> wrote:
>
> It seems quite useless and leading to false conclusions in several cases
> where the merger's gpg output differs from someone's checking later on,
> e.g. when
>
> - the signing key has been revoked in the mean time (for whatever
> reasons)
> - the signing key has expired
> - the public part of the signing key is not available for the general
> public.
So I don't think those are *big* issues. Sure, you'd want the public
key to be public for it to make any real sense to save, but on the
other hand, they *are* generally public. Yes, yes, you might have keys
that are only used - and only made public - within some particular
organization, but in that case the source code that gets signed with
those keys would tend to be private to that organization too, so..
And yes, keys get revoked or they expire, but that's still a pretty
rare event, so it doesn't really invalidate the argument that making
the original signed content available can quite often be useful - even
if it's not guaranteed to *always* be useful.
No, my main objection to saving the data is that it's ugly and it's
redundant. Sure, in practice you can check the signatures later fine
(with the rare exceptions you mention), but even when you can do it,
what's the big upside?
And there are much bigger real downsides, imho.
For example, let's say that we do eventually end up switching from
SHA1 to SHA256 in git, and we do a full re-import of the tree. Guess
what? All those signatures are now just so much garbage. Sure, you can
recreate them (create some trusted script that you agree does a 1:1
transform, and re-sign everything), but in practice you can't ever
really do that - because all those things are tied to the tree, so you
need to have *everybodys* private keys in one place to do so. And the
people who signed things initially would have to be insane to allow
that.
So I'm actually of the opinion that "internal signatures" are bad
design at a rather fundamental level.
In contrast, the "external signed tags" are fine: it's not just that
there are much fewer of them, it's that they are *independent*. So you
can easily re-generate the signed tags, because each signer can
*individually* decide to validate the newly converted tree, and sign
off on the fact that the conversion was done identically using new
external tags with signatures.
This was one of the reasons I made the signed tags work the way they
do. And it wasn't because I was extremely far-sighted and thought of
all the problems that internal signatures have - it's because monotone
had their internal signatures, and every other email on the monotone
list was about all the problems it caused.
> AFAIK gpg just gives you an error code and a message like e.g. "Key has
> expired" without stating if the key was valid _when signing the commit_.
>
> How do you plan to handle this when keeping the signature in the
> repository? Or am I overlooking something?
So see above - I just wouldn't worry about it. The possible few cases
where it would occur are dwarfed by the cases where it *doesn't*
occur, and those are the ones I'd concentrate on. They are the ones
that need to be important enough that it's even worth carrying the
random noise around.
Are they?
So I do think that there are real upsides at the *process* level where
you can use the signatures to verify that what is pulled is pulled
from the person you thought it was. I don't think anybody disputes
those advantages. But outside of that I think it gets very gray, and
there real disadvantages.
That said, I don't care *that* much. I don't mind polluting the merge
commits with information that I don't think is really worth it. So I'd
be willing to carry the signature information around, although I'd
hope to minimize it and have some sane way to hide it.
Linus
^ permalink raw reply
* Re: [PATCH] fsck: print progress
From: Jeff King @ 2011-11-03 3:33 UTC (permalink / raw)
To: Nguyễn Thái Ngọc Duy; +Cc: git
In-Reply-To: <1320290513-8878-1-git-send-email-pclouds@gmail.com>
On Thu, Nov 03, 2011 at 10:21:53AM +0700, Nguyen Thai Ngoc Duy wrote:
> fsck is usually a long process and it would be nice if it prints
> progress from time to time.
The output looks good to me. Code looks sane overall, with one comment:
> + for (i = 1, p = packed_git; p; p = p->next, i++) {
> + if (show_progress) {
> + char buf[32];
> + snprintf(buf, sizeof(buf), "Verifying pack %d/%d",
> + i, nr_packs);
> + if (open_pack_index(p))
> + continue;
> + progress = start_progress(buf, p->num_objects);
> + }
> /* verify gives error messages itself */
> - verify_pack(p);
> + verify_pack(p, progress);
> +
> + /*
> + * we do not stop progress here, let the next
> + * progress line overwrite the current one for
> + * the next pack.
> + */
> + }
> + stop_progress(&progress);
We're actually leaking some memory here, since stop_progress will also
free() the progress object and any associated resources. It's not a lot,
but it's kind of ugly.
Perhaps there should be a special version of stop_progress that handles
this better? Or perhaps we could even come up with a total object count
before starting. I guess it would involve mapping each pack index
simultaneously, though by my reading of the code, I think we do that
anyway (the opened index is cached in the pack object).
-Peff
^ permalink raw reply
* Re: [git patches] libata updates, GPG signed (but see admin notes)
From: Jochen Striepe @ 2011-11-03 3:22 UTC (permalink / raw)
To: Linus Torvalds
Cc: Shawn Pearce, Junio C Hamano, git, James Bottomley, Jeff Garzik,
Andrew Morton, linux-ide, LKML
In-Reply-To: <CA+55aFyXg32mko8TOGCfGHpr3jHBEgcKiK7HdVwq0Wez0fAs9A@mail.gmail.com>
Hi,
On Wed, Nov 02, 2011 at 07:25:17PM -0700, Linus Torvalds wrote:
> To me, the point of the tag is so that the person doing the merge can
> verify that he merges something trusted.
>
> However, everybody else seems to disagree, and wants that stupid
> signature to live along in the repository.
It seems quite useless and leading to false conclusions in several cases
where the merger's gpg output differs from someone's checking later on,
e.g. when
- the signing key has been revoked in the mean time (for whatever
reasons)
- the signing key has expired
- the public part of the signing key is not available for the general
public.
AFAIK gpg just gives you an error code and a message like e.g. "Key has
expired" without stating if the key was valid _when signing the commit_.
How do you plan to handle this when keeping the signature in the
repository? Or am I overlooking something?
Thanks,
Jochen.
^ 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