* Re: [PATCH 1/2] git-svn: teach dcommit about svn auto-props
From: Eric Wong @ 2008-07-25 6:00 UTC (permalink / raw)
To: Brad King; +Cc: git
In-Reply-To: <4885024A.3050200@kitware.com>
Brad King <brad.king@kitware.com> wrote:
>
> Subversion repositories often require files to have properties such as
> svn:mime-type and svn:eol-style set when they are added. Users
> typically set these properties automatically using the SVN auto-props
> feature with 'svn add'. This commit teaches dcommit to look at the user
> SVN configuration and apply matching auto-props entries for files added
> by a diff as it is applied to the SVN remote. A later commit will make
> this feature optional.
>
> Signed-off-by: Brad King <brad.king@kitware.com>
Hi Brad,
I like this patch. Can we get an automated test of this functionality?
We can (and probably should) set $HOME for the test and ignore the
existing ~/.subversion/config of the user.
Also, some minor nitpicks on whitespace/formatting inline below.
Not sure if writing a new unit test will trigger that bug below for you.
It really shouldn't...
> ---
> This change honors the user's enable-auto-props svn config setting.
> The next patch will configure this at the git level and add the
> corresponding documentation.
>
> I've tested this by hand on an real SVN repo that checks for mime type.
> Unfortunately I'm unable to run the git-svn test suite because I get
> the error reported here:
>
> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=486527
>
> (even without my changes).
I haven't had the chance to look at this. Can anybody else shed more
light on that bug? It's really strange that the tests won't run because
of it. Are you unable to run some git-svn tests or all of them?
<snip>
> +sub apply_autoprops {
> + my ($self, $file, $fbat) = @_;
> + my $conf_t = ${$self->{config}}{'config'};
> + no warnings 'once';
> + # Check [miscellany]/enable-auto-props in svn configuration.
> + if (SVN::_Core::svn_config_get_bool($conf_t,
> + $SVN::_Core::SVN_CONFIG_SECTION_MISCELLANY,
> + $SVN::_Core::SVN_CONFIG_OPTION_ENABLE_AUTO_PROPS,
Long lines here and below. I'd rather just align to the left (tabs are
assumed to be 8 characters wide on screen).
> + 0)) {
> + # Auto-props are enabled. Enumerate them to look for matches.
> + my $callback = sub {
> + $self->check_autoprop($_[0], $_[1], $file, $fbat);
> + };
> + SVN::_Core::svn_config_enumerate($conf_t,
> + $SVN::_Core::SVN_CONFIG_SECTION_AUTO_PROPS,
> + $callback);
> + }
> +}
> +
> sub A {
> my ($self, $m) = @_;
> my ($dir, $file) = split_path($m->{file_b});
> @@ -3535,6 +3581,7 @@ sub A {
> my $fbat = $self->add_file($self->repo_path($m->{file_b}), $pbat,
> undef, -1);
> print "\tA\t$m->{file_b}\n" unless $::_q;
> + $self->apply_autoprops($file, $fbat);
Hard tabs are used for indentation.
Thanks!
--
Eric Wong
^ permalink raw reply
* Re: [PATCH] Teach fsck and prune about the new location of temporary objects
From: Junio C Hamano @ 2008-07-25 6:07 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Brandon Casey, Git Mailing List
In-Reply-To: <alpine.DEB.1.00.0807250233031.4140@eeepc-johanness>
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> On Thu, 24 Jul 2008, Brandon Casey wrote:
>
>> Since 5723fe7e, temporary objects are now created in their final destination
>> directories, rather than in .git/objects/. Teach fsck to recognize and
>> ignore the temporary objects it encounters,
>
> It somehow feels wrong for fsck to ignore anything that could be used.
Back when we created temporaries in .git/objects/, these tmp_obj files
were not even checked nor looked at, because fsck_object_dir() checked
only those 256 fan-out directories, so this is nothing new.
And these tmp_obj files are something we _expect_ to be in the object
directory. The user can ^C out object creation codepath anytime, and we
do not reference the final destination objects from refs nor the index to
preserve the integrity of the repository when that happens. In other
words, they are crufts, but they are not something unusual nor get alarmed
about.
And it also is the right thing to do to remove them in prune.
^ permalink raw reply
* Re: [PATCH] Document disabling core.whitespace values trailing-space and space-before-tab
From: Peter Valdemar Mørch @ 2008-07-25 6:11 UTC (permalink / raw)
To: git
In-Reply-To: <7vbq0m608w.fsf@gitster.siamese.dyndns.org>
> So I think Peter's patch is going in the right direction.
Thus encouraged, I've created a file with two more patches like I
described in my previous mail: one that fixes up .gitattributes and one
that fixes up t/* to conform to documented syntax of core.whitespace.
(For the future: Is it better to have one file with tree patches like I
have created with git format-patch -M -s --stdout, 3 individual numbered
files, or one single patch created with git-merge --squash?)
Peter
--
Peter Valdemar Mørch
http://www.morch.com
^ permalink raw reply
* Re: [PATCH] Document disabling core.whitespace values trailing-space and space-before-tab
From: "Peter Valdemar Mørch (Lists)" @ 2008-07-25 6:13 UTC (permalink / raw)
To: git
In-Reply-To: <7vbq0m608w.fsf@gitster.siamese.dyndns.org>
[-- Attachment #1: Type: text/plain, Size: 532 bytes --]
> So I think Peter's patch is going in the right direction.
Thus encouraged, I've created a file with two more patches like I
described in my previous mail: one that fixes up .gitattributes and one
that fixes up t/* to conform to documented syntax of core.whitespace.
(For the future: Is it better to have one file with tree patches like I
have created with "git format-patch -M -s --stdout", 3 individual
numbered files, or one single patch created with git-merge --squash?)
Peter
--
Peter Valdemar Mørch
http://www.morch.com
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: core.whitespace.patch --]
[-- Type: text/x-patch; name="core.whitespace.patch", Size: 5595 bytes --]
>From 900455ce5a4e8bf771aea2e3dbdbab38e440cdf4 Mon Sep 17 00:00:00 2001
From: =?utf-8?q?Peter=20Valdemar=20M=C3=B8rch?= <peter@morch.com>
Date: Thu, 24 Jul 2008 07:18:48 +0200
Subject: [PATCH] Document disabling core.whitespace values trailing-space and space-before-tab
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 8bit
Signed-off-by: Peter Valdemar Mørch <peter@morch.com>
---
Documentation/config.txt | 6 ++++--
1 files changed, 4 insertions(+), 2 deletions(-)
diff --git a/Documentation/config.txt b/Documentation/config.txt
index e784805..a198b3c 100644
--- a/Documentation/config.txt
+++ b/Documentation/config.txt
@@ -361,10 +361,12 @@ core.whitespace::
consider them as errors:
+
* `trailing-space` treats trailing whitespaces at the end of the line
- as an error (enabled by default).
+ as an error (enabled by default - disable with 'git config core.whitespace
+ "-trailing-space"').
* `space-before-tab` treats a space character that appears immediately
before a tab character in the initial indent part of the line as an
- error (enabled by default).
+ error (enabled by default - disable with 'git config core.whitespace
+ "-space-before-tab"').
* `indent-with-non-tab` treats a line that is indented with 8 or more
space characters as an error (not enabled by default).
* `cr-at-eol` treats a carriage-return at the end of line as
--
1.5.6
>From c73dd588bef2a56fc44af2ce10cedef1b779a510 Mon Sep 17 00:00:00 2001
From: =?utf-8?q?Peter=20Valdemar=20M=C3=B8rch?= <peter@morch.com>
Date: Fri, 25 Jul 2008 07:33:07 +0200
Subject: [PATCH] Fixed up .gitattributes to allign with git-config.1
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 8bit
Signed-off-by: Peter Valdemar Mørch <peter@morch.com>
---
.gitattributes | 4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/.gitattributes b/.gitattributes
index 6b9c715..1a903b6 100644
--- a/.gitattributes
+++ b/.gitattributes
@@ -1,2 +1,2 @@
-* whitespace=!indent,trail,space
-*.[ch] whitespace
+* whitespace=-indent-with-non-tab,trailing-space,space-before-tab
+*.[ch] !whitespace
--
1.5.6
>From 45889568fec2b952e10aef2fac78ba6dfda9f46d Mon Sep 17 00:00:00 2001
From: =?utf-8?q?Peter=20Valdemar=20M=C3=B8rch?= <peter@morch.com>
Date: Fri, 25 Jul 2008 07:59:24 +0200
Subject: [PATCH] tests now use git-config's core.whitespace only with documented values
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 8bit
Signed-off-by: Peter Valdemar Mørch <peter@morch.com>
---
t/t4019-diff-wserror.sh | 14 +++++++-------
t/t4124-apply-ws-rule.sh | 4 ++--
2 files changed, 9 insertions(+), 9 deletions(-)
diff --git a/t/t4019-diff-wserror.sh b/t/t4019-diff-wserror.sh
index 0d9cbb6..ecff30d 100755
--- a/t/t4019-diff-wserror.sh
+++ b/t/t4019-diff-wserror.sh
@@ -33,9 +33,9 @@ test_expect_success default '
'
-test_expect_success 'without -trail' '
+test_expect_success 'without -trailing-space' '
- git config core.whitespace -trail
+ git config core.whitespace -trailing-space
git diff --color >output
grep "$blue_grep" output >error
grep -v "$blue_grep" output >normal
@@ -48,10 +48,10 @@ test_expect_success 'without -trail' '
'
-test_expect_success 'without -trail (attribute)' '
+test_expect_success 'without -trailing-space (attribute)' '
git config --unset core.whitespace
- echo "F whitespace=-trail" >.gitattributes
+ echo "F whitespace=-trailing-space" >.gitattributes
git diff --color >output
grep "$blue_grep" output >error
grep -v "$blue_grep" output >normal
@@ -99,7 +99,7 @@ test_expect_success 'without -space (attribute)' '
test_expect_success 'with indent-non-tab only' '
rm -f .gitattributes
- git config core.whitespace indent,-trailing,-space
+ git config core.whitespace indent-with-non-tab,-trailing-space,-space-before-tab
git diff --color >output
grep "$blue_grep" output >error
grep -v "$blue_grep" output >normal
@@ -115,7 +115,7 @@ test_expect_success 'with indent-non-tab only' '
test_expect_success 'with indent-non-tab only (attribute)' '
git config --unset core.whitespace
- echo "F whitespace=indent,-trailing,-space" >.gitattributes
+ echo "F whitespace=indent-with-non-tab,-trailing-space,-space-before-tab" >.gitattributes
git diff --color >output
grep "$blue_grep" output >error
grep -v "$blue_grep" output >normal
@@ -147,7 +147,7 @@ test_expect_success 'with cr-at-eol' '
test_expect_success 'with cr-at-eol (attribute)' '
git config --unset core.whitespace
- echo "F whitespace=trailing,cr-at-eol" >.gitattributes
+ echo "F whitespace=trailing-space,cr-at-eol" >.gitattributes
git diff --color >output
grep "$blue_grep" output >error
grep -v "$blue_grep" output >normal
diff --git a/t/t4124-apply-ws-rule.sh b/t/t4124-apply-ws-rule.sh
index 85f3da2..644aadc 100755
--- a/t/t4124-apply-ws-rule.sh
+++ b/t/t4124-apply-ws-rule.sh
@@ -106,7 +106,7 @@ test_expect_success 'whitespace=error-all, default rule' '
test_expect_success 'whitespace=error-all, no rule' '
- git config core.whitespace -trailing,-space-before,-indent &&
+ git config core.whitespace -trailing-space,-space-before-tab,-indent-with-non-tab &&
apply_patch --whitespace=error-all &&
diff file target
@@ -130,7 +130,7 @@ do
for i in - ''
do
case "$i" in '') ti='#' ;; *) ti= ;; esac
- rule=${t}trailing,${s}space,${i}indent
+ rule=${t}trailing-space,${s}space-before-tab,${i}indent-with-non-tab
rm -f .gitattributes
test_expect_success "rule=$rule" '
--
1.5.6
^ permalink raw reply related
* Re: Stitching together two split segments from svn
From: Jakub Narebski @ 2008-07-25 7:21 UTC (permalink / raw)
To: Liam Healy; +Cc: git
In-Reply-To: <654935030807241941p620201a2q21bb4513cd21225d@mail.gmail.com>
On Fri, 25 Jul 2008, Liam Healy wrote:
>
> Thanks for the advice -- this did exactly what I wanted.
>
> For anyone else wanting to do this: one thing that threw me for a
> while was that .git/info/grafts does not accept an abbreviated SHA,
> the full 40 hex digits is needed. I would see "bad graft data" from
> gitk with no other explanation. There is very little documentation
> that I could find on the grafts file; the best I could find was in the
> man page for git-filter branch:
>
> http://www.kernel.org/pub/software/scm/git/docs/git-filter-branch.html.
You can find definition of grafts in `gitglossary', and where you can
find them together with description of grafts file format in
`gitrepository-layout'
--
Jakub Narebski
Poland
^ permalink raw reply
* Re: [PATCH] Document disabling core.whitespace values trailing-space and space-before-tab
From: Junio C Hamano @ 2008-07-25 7:28 UTC (permalink / raw)
To: Peter Valdemar Mørch (Lists); +Cc: git
In-Reply-To: <4888144E.8090300@sneakemail.com>
"Peter Valdemar Mørch (Lists)" <4ux6as402@sneakemail.com> writes:
> This is a multi-part message in MIME format.
> --------------080005060106030305090009
> Content-Type: text/plain; charset=ISO-8859-1; format=flowed
> Content-Transfer-Encoding: 8bit
> ...
> --------------080005060106030305090009
> Content-Type: text/x-patch;
> name="0001-Document-disabling-core.whitespace-values-trailing-s.patch"
> Content-Transfer-Encoding: 8bit
Please do not send patch as attachment. It is very cumbersome to handle.
^ permalink raw reply
* Re: gitweb tags feed, Re: New version announcements?
From: Pedro Melo @ 2008-07-25 7:37 UTC (permalink / raw)
To: Julian Phillips; +Cc: Petr Baudis, Jordi Bunster, git, gitster
In-Reply-To: <Pine.LNX.4.64.0807241818520.7970@reaper.quantumfyre.co.uk>
Hi,
On Jul 24, 2008, at 6:25 PM, Julian Phillips wrote:
> On Thu, 24 Jul 2008, Pedro Melo wrote:
>> On Jul 24, 2008, at 4:04 PM, Julian Phillips wrote:
>>> > On Thu, Jul 24, 2008 at 10:38:24AM -0400, Jordi Bunster wrote:
>>> > > > > Any way that a git-announce list could be created for
>>> security fixes > > and
>>> > > new releases? Or maybe an RSS feed on the website?
>>> An RSS feed already exists, have a look at http://gitrss.q42.co.uk/.
>>
>> You might want to look at the script that generates the announces
>> feed. It missed the 1.5.6.4 announcement.
>>
>> http://article.gmane.org/gmane.comp.version-control.git/89148/
>> match=1.5.6.4
>
> Should be there now. Thanks. :)
It's there, fixed.
Best regards,
--
Pedro Melo
Blog: http://www.simplicidade.org/notes/
XMPP ID: melo@simplicidade.org
Use XMPP!
^ permalink raw reply
* [PATCH 6/9 - v2] builtin-init-db.c: use parse_options()
From: Michele Ballabio @ 2008-07-25 8:15 UTC (permalink / raw)
To: Olivier Marin; +Cc: git, gitster
In-Reply-To: <200807242207.02195.barra_cuda@katamail.com>
Signed-off-by: Michele Ballabio <barra_cuda@katamail.com>
---
On Thursday 24 July 2008, Michele Ballabio wrote:
> +static int parse_opt_shared_cb(const struct option *opt, const char *arg,
> + int unset)
> +{
> + *(int *)(opt->value) = unset ? PERM_UMASK : git_config_perm("arg", arg);
> + return 0;
> +}
>
Did it this way (and changed help strings).
builtin-init-db.c | 57 +++++++++++++++++++++++++++++++++-------------------
1 files changed, 36 insertions(+), 21 deletions(-)
diff --git a/builtin-init-db.c b/builtin-init-db.c
index 38b4fcb..42c2e20 100644
--- a/builtin-init-db.c
+++ b/builtin-init-db.c
@@ -6,6 +6,7 @@
#include "cache.h"
#include "builtin.h"
#include "exec_cmd.h"
+#include "parse-options.h"
#ifndef DEFAULT_GIT_TEMPLATE_DIR
#define DEFAULT_GIT_TEMPLATE_DIR "/usr/share/git-core/templates"
@@ -353,8 +354,18 @@ static int guess_repository_type(const char *git_dir)
return 1;
}
-static const char init_db_usage[] =
-"git init [-q | --quiet] [--bare] [--template=<template-directory>] [--shared[=<permissions>]]";
+static const char * const init_db_usage[] = {
+ "git init [-q | --quiet] [--bare] [--template=<dir>] [--shared[=<type>]]",
+ NULL
+};
+
+static int parse_opt_shared_cb(const struct option *opt, const char *arg,
+ int unset)
+{
+ *(int *)(opt->value) = unset ? PERM_UMASK :
+ git_config_perm("arg", arg);
+ return 0;
+}
/*
* If you want to, you can share the DB area with any number of branches.
@@ -367,25 +378,29 @@ int cmd_init_db(int argc, const char **argv, const char *prefix)
const char *git_dir;
const char *template_dir = NULL;
unsigned int flags = 0;
- int i;
-
- for (i = 1; i < argc; i++, argv++) {
- const char *arg = argv[1];
- if (!prefixcmp(arg, "--template="))
- template_dir = arg+11;
- else if (!strcmp(arg, "--bare")) {
- static char git_dir[PATH_MAX+1];
- is_bare_repository_cfg = 1;
- setenv(GIT_DIR_ENVIRONMENT, getcwd(git_dir,
- sizeof(git_dir)), 0);
- } else if (!strcmp(arg, "--shared"))
- shared_repository = PERM_GROUP;
- else if (!prefixcmp(arg, "--shared="))
- shared_repository = git_config_perm("arg", arg+9);
- else if (!strcmp(arg, "-q") || !strcmp(arg, "--quiet"))
- flags |= INIT_DB_QUIET;
- else
- usage(init_db_usage);
+ int bare = 0;
+
+ const struct option options[] = {
+ OPT_STRING(0, "template", &template_dir, "path",
+ "path to the template directory"),
+ OPT_BOOLEAN(0, "bare", &bare, "set up a bare repository"),
+ { OPTION_CALLBACK, 0, "shared", &shared_repository,
+ "permissions", "set up a shared repository",
+ PARSE_OPT_OPTARG, parse_opt_shared_cb, PERM_GROUP },
+ OPT_BIT('q', "quiet", &flags, "be quiet", INIT_DB_QUIET),
+ OPT_END()
+ };
+
+ argc = parse_options(argc, argv, options, init_db_usage, 0);
+
+ if (argc > 0)
+ usage_with_options(init_db_usage, options);
+
+ if (bare) {
+ static char git_dir[PATH_MAX+1];
+ is_bare_repository_cfg = 1;
+ setenv(GIT_DIR_ENVIRONMENT, getcwd(git_dir,
+ sizeof(git_dir)), 0);
}
/*
--
1.5.6.3
^ permalink raw reply related
* Re: sparse fetch, was Re: [PATCH 08/12] git-clone: support --path to do sparse clone
From: Sverre Rabbelier @ 2008-07-25 8:14 UTC (permalink / raw)
To: Johannes Schindelin
Cc: Petr Baudis, Jeff King, Nguy?n Thái Ng?c Duy, git
In-Reply-To: <alpine.DEB.1.00.0807250210090.4140@eeepc-johanness>
On Fri, Jul 25, 2008 at 02:12, Johannes Schindelin
<Johannes.Schindelin@gmx.de> wrote:
> On Thu, 24 Jul 2008, Sverre Rabbelier wrote:
>> Wouldn't that be as simple as passing a pathspec to git-rev-list? Not a
>> lot of overhead there I reckon.
>
> So the server would _not_ have to deflate the objects to inspect them? I
> thought you knew more about Git's object database.
Nope, I did not know this. I thought that the server already had to do
all that to decide what to send, since not every request asks for the
same pack (someone might not have updated in 2 month, or someone might
might be up to date, or anything in between).
>> Just keep them?
>
> You'd still have to inspect the objects, which is way more work than the
> current code has to do. Remember: in the optimal case, upload-pack does
> not more than just serve the existing deltas/base objects.
Ah, I can see how that would produce overhead then.
--
Cheers,
Sverre Rabbelier
^ permalink raw reply
* Re: [PATCH 5/9 v2] Allow the built-in exec path to be relative to the command invocation path
From: Johannes Sixt @ 2008-07-25 8:32 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7v3aly5zz3.fsf@gitster.siamese.dyndns.org>
Zitat von Junio C Hamano <gitster@pobox.com>:
> However, I have to wonder if it is the right thing to do, like your patch
> does, for "git --exec-path" to return "../libexec/git-core/" in a relative
> form, without saying what it is relative to. Shouldn't we be showing the
> full path after resolving that relative path to git executable?
Does it? "git --exec-path" calls git_exec_path(), and that now returns
system_path(GIT_EXEC_PATH), and that is an absolute path, although it's
not normalized.
Oh, I see: You tested it on Linux, right? This patch series does not work
correctly on Linux (Unix? bash?), as Dscho has pointed out, since argv[0]
does not have a directory part if "git" is in $PATH. In this case, system_path()
just returns its argument, which is the relative path. :-/
-- Hannes
^ permalink raw reply
* Re: [PATCH] editor.c: Libify launch_editor()
From: Junio C Hamano @ 2008-07-25 8:36 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Stephan Beyer, git
In-Reply-To: <alpine.DEB.1.00.0807181405510.3932@eeepc-johanness>
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> Hi,
>
> On Fri, 18 Jul 2008, Stephan Beyer wrote:
>
>> This patch removes exit()/die() calls and builtin-specific messages from
>> launch_editor(), so that it can be used as a general libgit.a function
>> to launch an editor.
>
> Thanks. Now we have to convince Junio that it is a good idea :-)
Eh, excuse me.
>> diff --git a/editor.c b/editor.c
>> index 483b62d..5d7f5f9 100644
>> --- a/editor.c
>> +++ b/editor.c
>> @@ -17,9 +17,8 @@ void launch_editor(const char *path, struct strbuf *buffer, const char *const *e
> ...
> Why not "return error()"?
>
> Rest looks obviously correct to me!
This is a patch to an existing file editor.c???
^ permalink raw reply
* Re: [PATCH 5/9 v2] Allow the built-in exec path to be relative to the command invocation path
From: Johannes Sixt @ 2008-07-25 8:38 UTC (permalink / raw)
To: Johannes Sixt; +Cc: Junio C Hamano, git
In-Reply-To: <1216974722.48898f82e80d6@webmail.eunet.at>
Johannes Sixt schrieb:
> Oh, I see: You tested it on Linux, right? This patch series does not work
> correctly on Linux (Unix? bash?), as Dscho has pointed out, since argv[0]
does not work correctly on Linux... *iff gitexecdir is relative*
> does not have a directory part if "git" is in $PATH. In this case, system_path()
> just returns its argument, which is the relative path. :-/
-- Hannes
^ permalink raw reply
* Re: [PATCH] rebase -i: only automatically amend commit if HEAD did not change
From: Junio C Hamano @ 2008-07-25 8:44 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git
In-Reply-To: <alpine.DEB.1.00.0807241311450.8986@racer>
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
>> At what point in what valid workflow sequence does HEAD become different
>> from dotest/amend?
>
> $ rebase -i HEAD~5
>
> <mark one commit as edit>
>
> <Whoa! While editing, I realize that this contains an unrelated
> bugfix>
>
> $ git reset HEAD^
> $ git add -p
> $ git commit
>
> <Edit a bit here, a bit there>
>
> $ git rebase --continue
>
> Sure it is a pilot error. It hit this pilot, too.
> ...
> In the way that the user certainly did not mean to amend _this_ HEAD.
> Another HEAD was marked with "edit".
Ok; after this "refraining from incorrectly squashing them", how would the
user edit the one the user originally intended to edit (I am not
complaining, but asking for information)?
So in your workflow example, when there is no pilot error, is this the
"ideal" sequence?
$ git rebase -i HEAD~5
.. mark one as edit
.. ah, the one I wanted to just "edit" actually need to be
.. split into two because it has some other thing I need to change
$ git reset HEAD^
$ git add -p
$ git stash --keep-index
.. test to verify the initial part
$ git commit ;# first part of split commit
$ git stash pop
.. test test
$ git add -p
$ git rebase --continue ;# gives you the editor to edit
I wonder if we can make the transcript of the "pilot error" case look like
this:
$ git rebase -i HEAD~5
...
$ git reset HEAD^
.. same as above up to...
.. test to verify the initial part
$ git rebase --continue ;# oops
.. gives you the editor to edit the message.
.. makes a commit, and says:
committed initial part of the change, stopping.
.. ah, the command noticed it and did not escape, thanks!
$ git stash pop
.. test test
$ git add -p
$ git rebase --continue ;# gives you the editor to edit
.. and goes on this time.
^ permalink raw reply
* Re: q: faster way to integrate/merge lots of topic branches?
From: Junio C Hamano @ 2008-07-25 8:46 UTC (permalink / raw)
To: Ingo Molnar; +Cc: SZEDER Gábor, git
In-Reply-To: <20080724152742.GA23585@elte.hu>
Ingo Molnar <mingo@elte.hu> writes:
> perhaps you need to run tip-create-local-branches.sh to create all the
> local branches? You can find it in:
>
> tip/tip .tip/bin/tip-create-local-branches.sh
>
> (does/should the presence of local branches matter?)
My refs/remotes/mingo/ hierarchy has as many branches as you do in your
repository as local branches, and I presume you do not have these tracking
branches as I do because you are the upstream of this repository, so
overall we have about the same number of refs. In the experiment, I did
"branch -a --no-merged" (notice -a), so I do not think the difference
should have mattered.
^ permalink raw reply
* Re: sparse fetch, was Re: [PATCH 08/12] git-clone: support --path to do sparse clone
From: Junio C Hamano @ 2008-07-25 8:47 UTC (permalink / raw)
To: Jeff King; +Cc: Johannes Schindelin, Nguyễn Thái Ngọc Duy, git
In-Reply-To: <20080724182813.GA21186@sigill.intra.peff.net>
Jeff King <peff@peff.net> writes:
> On Thu, Jul 24, 2008 at 06:41:03PM +0100, Johannes Schindelin wrote:
>
>> > As a user, I would expect "sparse clone" to also be sparse on the
>> > fetching. That is, to not even bother fetching tree objects that we are
>> > not going to check out. But that is a whole other can of worms from
>> > local sparseness, so I think it is worth saving for a different series.
>>
>> I think this is not even worth of a series. Sure, it would have benefits
>> for those who want sparse checkouts. But it comes for a high price on
>> everyone else:
>
> I agree there are a lot of issues. I am just thinking of the person who
> said they had a >100G repository. But I am also not volunteering to do
> it, so I will let somebody who really cares about it try to defend the
> idea.
I think sparse fetch is a lot worse than grafts and shallow clones which
are already bad. These are all ways to introduce local inconsistency at
the object level and pretend everything is Ok, but the latter two do so
only at commit boundary and it is somewhat more manageable (but we still
do not handle it very well). With sparse fetch, you cannot even guarantee
the integrity of individual commits with subtrees here and there missing.
I do think shallow checkout that says "I'll have the whole tree in the
index but the work tree will have only these paths checked out" makes
sense. You do not need a fully populated work tree to create commits or
merges -- the only absolute minimum you need is a fully populated index.
In that sense, I think "protect index entries outside of these paths" (I
remember that the first round of this series was done around that notion)
is a wrong mentality to handle this. We should think of this as more like
"you still populate the index with the whole tree, and you are free to
update them in any way you want, but we do not touch work tree outside
these areas".
This has a few ramifications:
- If the user can somehow check out a path outside the "sparse" area, it
is perfectly fine for the user to edit and "git add" it. Such a method
to check out a path outside the "sparse" area is a way to widen the
"sparse" area the user originally set up;
- When the user runs "merge", and it needs to present the user a working
tree file because of conflicts at the file level, the user has to agree
to widen the "sparse" area before being able to do so. One way to do
this is to refuse and fail the merge (and then the user needs to do
that "unspecified way" of widening the "sparse" area first). Another
way would be to automatically widen the "sparse" area to include such
conflicting paths.
- And you would want to narrow it down after you do such a widening.
For many projects that has src/ and doc/ (git.git being one of them), it
is perfectly valid for a code person and a doc person to work in tandem.
In such a project, after the code person makes changes in her sparsely
checked out repository and making changes only to the src/ area and pushes
the results out, the doc person would run "git pull && git log -p
ORIG_HEAD" and updates the documentation in his sparsely checked out
repository that has only doc/ area. The two parts are tied together and
they advance more or less in sync. I think sparse checkout would be a
useful feature to help such a configuration.
Having said that, I however think that this can easily be misused as a CVS
style "one CVSROOT houses millions of totally unrelated projects" layout.
In CVS, the layout is perfectly fine because the system does not track
changes at anything higher than the level of individual files, but when
you naïvely map the layout to a system with tree-wide atomic commits, such
as git, it will defeat the whole point of using such a system. The pace
these millions of unrelated projects advance do not have any relationship
with each other, but by tying them together in the same top-level tree,
the layout is introducing an unnecessary ordering between their commits.
^ permalink raw reply
* Re: [PATCH] Document disabling core.whitespace values trailing-space and space-before-tab
From: Junio C Hamano @ 2008-07-25 8:49 UTC (permalink / raw)
To: Nanako Shiraishi; +Cc: Peter Valdemar Mørch (Lists), git
In-Reply-To: <7vbq0m608w.fsf@gitster.siamese.dyndns.org>
Junio C Hamano <gitster@pobox.com> writes:
> Various "values" given to the whitespace attribute actually act as if they
> are sub-variables and obey the similar "[-]name" rule, but (1) that is
> left unsaid, and (2) in that context '!' does not make sense so only '-'
> has any meaning.
Actually I take it back. "!name to revert to unspecified and -name to unset"
really is about name; values to whitespace do not work like "sub-variables"
at all.
> So I think Peter's patch is going in the right direction.
I've committed a much more simplified version.
-- >8 --
[PATCH] Documentation: clarify how to diable elements in core.whitespace
Noticed by Peter Valdemar Mørch.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
diff --git a/Documentation/config.txt b/Documentation/config.txt
index e784805..798b551 100644
--- a/Documentation/config.txt
+++ b/Documentation/config.txt
@@ -358,7 +358,8 @@ core.whitespace::
A comma separated list of common whitespace problems to
notice. 'git-diff' will use `color.diff.whitespace` to
highlight them, and 'git-apply --whitespace=error' will
- consider them as errors:
+ consider them as errors. You can prefix `-` to disable
+ any of them (e.g. `-trailing-space`):
+
* `trailing-space` treats trailing whitespaces at the end of the line
as an error (enabled by default).
^ permalink raw reply related
* Re: sparse fetch, was Re: [PATCH 08/12] git-clone: support --path to do sparse clone
From: Sverre Rabbelier @ 2008-07-25 8:54 UTC (permalink / raw)
To: Junio C Hamano
Cc: Jeff King, Johannes Schindelin,
Nguyễn Thái Ngọc Duy, git
In-Reply-To: <7v7ibauz94.fsf@gitster.siamese.dyndns.org>
On Fri, Jul 25, 2008 at 10:47, Junio C Hamano <gitster@pobox.com> wrote:
> For many projects that has src/ and doc/ (git.git being one of them), it
We are? That's great, that'd mean I can actually do a 'ls' in the
git.git root! Oh wait...
$ ls | wc -l
693
--
Cheers,
Sverre Rabbelier
^ permalink raw reply
* Re: [PATCH 7/9] builtin-checkout-index.c: use parse_options()
From: René Scharfe @ 2008-07-25 9:01 UTC (permalink / raw)
To: sverre; +Cc: Michele Ballabio, Johannes Schindelin, git, gitster
In-Reply-To: <bd6139dc0807241335i3ab5280aq6a46325428ccc70f@mail.gmail.com>
Sverre Rabbelier schrieb:
> On Thu, Jul 24, 2008 at 10:08 PM, Michele Ballabio
> <barra_cuda@katamail.com> wrote:
>> On Thursday 24 July 2008, Johannes Schindelin wrote:
>>> On Wed, 23 Jul 2008, Michele Ballabio wrote:
>>>
>>>> + { OPTION_CALLBACK, 'f', "force", &state, NULL,
>>>> + "force overwrite of existing files",
>>>> + PARSE_OPT_NOARG, parse_state_force_cb, 0 },
>>> I wonder if this could not be written as
>>>
>>> OPT_BOOLEAN('f', "force", &state.force,
>>> "force overwrite of existing files"),
>> I did it that way because 'force' is a bitfield.
>
> I thought there is an OPT_BIT?
OPT_BIT is for flags and bitmasks, not for bitfields.
Since you can't get the address of a bitfield member, a function that
wants to change its value needs to know its name. Switching to bitmasks
would make the option parsing code look cleaner, but you'd have to
change all those bitfield accesses to explicit bitmask operations, e.g.:
if (state.force)
state.force = 0;
vs.
if (state.flags & CHECKOUT_FORCE)
state.flags &= ~CHECKOUT_FORCE;
In the case of struct checkout, though, we could simply make the
bitfield members full ints, because there are only a few instances of
this structure in memory at any given time. Wasting a few bytes of RAM
in order to gain much simpler code is OK in this case, I think.
OPT_BOOLEAN looks a lot nicer than a callback.
René
^ permalink raw reply
* Re: [PATCH] Preserve cwd in setup_git_directory()
From: Geoff Russell @ 2008-07-25 9:48 UTC (permalink / raw)
To: Nguyen Thai Ngoc Duy; +Cc: Johannes Schindelin, git
In-Reply-To: <fcaeb9bf0807241137h65292d7egad8cc5f797114607@mail.gmail.com>
Hi,
On 7/25/08, Nguyen Thai Ngoc Duy <pclouds@gmail.com> wrote:
> On 7/24/08, Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
> > Hi,
> >
> > On Thu, 24 Jul 2008, Nguyen Thai Ngoc Duy wrote:
> >
> > > On 7/24/08, Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
> > >
> >
> > > > On Thu, 24 Jul 2008, Nguyen Thai Ngoc Duy wrote:
> > > >
> > > > > When GIT_DIR is not set, cwd is used to determine where .git is. If
> > > > > core.worktree is set, setup_git_directory() needs to jump back to
> > > > > the original cwd in order to calculate worktree, this leads to
> > > > > incorrect .git location later in setup_work_tree().
> > > >
> > > > I do not understand. core.worktree is either absolute, in which case
> > > > there is no problem. Or it is relative to where the config lives, no?
> > >
> > > The problem is GIT_DIR is not absolute in this case. So cwd must stay
> > > where git dir is until it is absolute-ized by setup_work_tree().
> >
> >
> > I do not see GIT_DIR being set in your test case at all.
> >
> > I do not see how get_git_work_tree() ro get_relative_cwd() should ever be
> > allowed to chdir().
> >
> > _If_ they were (which I strongly doubt), they should chdir() back
> > themselves.
> >
> > I now wasted easily 30 minutes just trying to make sense of your patch and
> > your response. And I am still puzzled.
> >
> > Your commit message was of no help.
>
>
> Alright, let's look at the code.
>
> 1. cwd is moved to toplevel working directory by setup_git_directory_gently()
> 2. setup_git_env() by default will set git_dir variable as ".git" as
> part of check_repository_format_gently()
> 3. now in setup_git_directory() finds out core.worktree, it chdir()
> to get relative prefix
> 4. setup_work_tree() sees that git_dir is not absolute path, it makes
> git_dir absolute
>
> If in step 3, it does not chdir(), step 4 will be right. In this case,
> step 3 does chdir() and not going back, access to git repository will
> fail as Geoff Russell discovered.
> --
>
> Duy
>
There seem to be plenty of things happening here which I know nothing
about, which
is really why I hit the problem in the first place. I was pretty
surprised to find that
my command line switch (--work-tree) was being stored in the config file, which
ended up causing the problem. Duy thinks he can fix this, which is
fine, but as a matter of principle, I'm not keen on command line switches
being magically saved for me when I didn't ask for this to happen.
The reason for
using a command line switch is because I want to override default
behaviour on this execution, if I wanted to change the default behaviour, then
I'd set values in the config file.
Whatever you decide, I reckon its pretty magical to have a software
problem, send
an email to a list and get the solution in 45 minutes. I've never got that
service from any other piece of software (or hardware)!
Cheers,
Geoff Russell
^ permalink raw reply
* [PATCH] bash completion: Add long options for 'git describe'
From: Thomas Rast @ 2008-07-25 10:02 UTC (permalink / raw)
To: git; +Cc: gitster, Shawn O. Pearce
---
It seemed so tedious to type --always so I wrote this instead ;-)
contrib/completion/git-completion.bash | 11 +++++++++++
1 files changed, 11 insertions(+), 0 deletions(-)
diff --git a/contrib/completion/git-completion.bash b/contrib/completion/git-completion.bash
index 3b04934..421431c 100755
--- a/contrib/completion/git-completion.bash
+++ b/contrib/completion/git-completion.bash
@@ -665,6 +665,17 @@ _git_commit ()
_git_describe ()
{
+ __git_has_doubledash && return
+
+ local cur="${COMP_WORDS[COMP_CWORD]}"
+ case "$cur" in
+ --*)
+ __gitcomp "
+ --all --tags --contains --abbrev= --candidates=
+ --exact-match --debug --long --match --always
+ "
+ return
+ esac
__gitcomp "$(__git_refs)"
}
--
1.6.0.rc0.48.g3fa0a
^ permalink raw reply related
* Re: [PATCH] Preserve cwd in setup_git_directory()
From: Johannes Schindelin @ 2008-07-25 10:04 UTC (permalink / raw)
To: Geoff Russell; +Cc: Nguyen Thai Ngoc Duy, git
In-Reply-To: <93c3eada0807250248l60c81090sd1953df24cca1421@mail.gmail.com>
Hi,
On Fri, 25 Jul 2008, Geoff Russell wrote:
> I was pretty surprised to find that my command line switch (--work-tree)
> was being stored in the config file, which ended up causing the problem.
> Duy thinks he can fix this, which is fine, but as a matter of principle,
> I'm not keen on command line switches being magically saved for me when
> I didn't ask for this to happen.
You were initializing a repository. How on earth could you be surprised
when _important_ things like work-tree git-dir or if it is bare are stored
inside the freshly initialized repository?
> The reason for using a command line switch is because I want to override
> default behaviour on this execution, if I wanted to change the default
> behaviour, then I'd set values in the config file.
No, you would not. Because there is no config file yet.
Htrh,
Dscho
^ permalink raw reply
* Re: [PATCH] index-pack: correctly initialize appended objects
From: Johannes Schindelin @ 2008-07-25 10:24 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Nicolas Pitre, spearce, git
In-Reply-To: <7vy73q4jzp.fsf@gitster.siamese.dyndns.org>
Hi,
On Thu, 24 Jul 2008, Junio C Hamano wrote:
> The function does not seem to use type (which the patch is also setting)
> nor real_type (which the patch does not set).
>
> However, the code checks objects[nth].real_type all over the place in
> the code. Doesn't the lack of real_type assignment in
> append_obj_to_pack() affect them in any way?
>From staring at the code, I thought that real_type was set in
resolve_delta(), but I may be wrong.
The safer thing would be to set it, but I am not quite sure if we can use
"type" directly, or if type can be "delta" for an object that is used to
complete the pack, and therefore stored as a non-delta.
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH] editor.c: Libify launch_editor()
From: Johannes Schindelin @ 2008-07-25 10:28 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Stephan Beyer, git
In-Reply-To: <7vvdyuuzq2.fsf@gitster.siamese.dyndns.org>
Hi,
On Fri, 25 Jul 2008, Junio C Hamano wrote:
> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
>
> > On Fri, 18 Jul 2008, Stephan Beyer wrote:
> >
> >> diff --git a/editor.c b/editor.c
> >> index 483b62d..5d7f5f9 100644
> >> --- a/editor.c
> >> +++ b/editor.c
> >> @@ -17,9 +17,8 @@ void launch_editor(const char *path, struct strbuf *buffer, const char *const *e
> > ...
> > Why not "return error()"?
> >
> > Rest looks obviously correct to me!
>
> This is a patch to an existing file editor.c???
Yes, Stephan sent the two patches unrelatedly, even if they should have
been marked "1/2" and "2/2". I hope he does so now.
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH] rebase -i: only automatically amend commit if HEAD did not change
From: Johannes Schindelin @ 2008-07-25 10:35 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vod4muzck.fsf@gitster.siamese.dyndns.org>
Hi,
On Fri, 25 Jul 2008, Junio C Hamano wrote:
> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
>
> >> At what point in what valid workflow sequence does HEAD become
> >> different from dotest/amend?
> >
> > $ rebase -i HEAD~5
> >
> > <mark one commit as edit>
> >
> > <Whoa! While editing, I realize that this contains an unrelated
> > bugfix>
> >
> > $ git reset HEAD^
> > $ git add -p
> > $ git commit
> >
> > <Edit a bit here, a bit there>
> >
> > $ git rebase --continue
> >
> > Sure it is a pilot error. It hit this pilot, too.
> > ...
> > In the way that the user certainly did not mean to amend _this_ HEAD.
> > Another HEAD was marked with "edit".
>
> Ok; after this "refraining from incorrectly squashing them", how would the
> user edit the one the user originally intended to edit (I am not
> complaining, but asking for information)?
In this case, the two commits are two commits, the editor popped up with
rebase --continue contains the original commit message, and all is fine.
> So in your workflow example, when there is no pilot error, is this the
> "ideal" sequence?
>
> $ git rebase -i HEAD~5
> .. mark one as edit
> .. ah, the one I wanted to just "edit" actually need to be
> .. split into two because it has some other thing I need to change
> $ git reset HEAD^
> $ git add -p
> $ git stash --keep-index
> .. test to verify the initial part
> $ git commit ;# first part of split commit
> $ git stash pop
> .. test test
> $ git add -p
Without pilot error, here has to come a "git commit -c HEAD@{1}".
> $ git rebase --continue ;# gives you the editor to edit
>
> I wonder if we can make the transcript of the "pilot error" case look like
> this:
>
> $ git rebase -i HEAD~5
> ...
> $ git reset HEAD^
> .. same as above up to...
> .. test to verify the initial part
> $ git rebase --continue ;# oops
> .. gives you the editor to edit the message.
> .. makes a commit, and says:
> committed initial part of the change, stopping.
> .. ah, the command noticed it and did not escape, thanks!
> $ git stash pop
> .. test test
> $ git add -p
> $ git rebase --continue ;# gives you the editor to edit
> .. and goes on this time.
Possible.
The first hunk (IIRC) of my patch would stay the same, but the second hunk
would not fall through to the interactive commit, instead testing if amend
exists, _and_ is different from HEAD, and if both are the case, say
something helpful and exit.
Ciao,
Dscho
^ permalink raw reply
* [PATCH 1/6] archive: add write_archive()
From: Rene Scharfe @ 2008-07-25 10:41 UTC (permalink / raw)
To: git; +Cc: Junio C Hamano
Both archive and upload-archive have to parse command line arguments and
then call the archiver specific write function. Move the duplicate code
to a new function, write_archive().
Signed-off-by: Rene Scharfe <rene.scharfe@lsrfire.ath.cx>
---
archive.c | 18 ++++++++++++++++++
archive.h | 1 +
builtin-archive.c | 13 +------------
builtin-upload-archive.c | 10 +---------
4 files changed, 21 insertions(+), 21 deletions(-)
diff --git a/archive.c b/archive.c
index b8b45ba..75eb257 100644
--- a/archive.c
+++ b/archive.c
@@ -155,3 +155,21 @@ int write_archive_entries(struct archiver_args *args,
err = 0;
return err;
}
+
+int write_archive(int argc, const char **argv, const char *prefix,
+ int setup_prefix)
+{
+ const struct archiver *ar = NULL;
+ struct archiver_args args;
+ int tree_idx;
+
+ tree_idx = parse_archive_args(argc, argv, &ar, &args);
+ if (setup_prefix && prefix == NULL)
+ prefix = setup_git_directory();
+
+ argv += tree_idx;
+ parse_treeish_arg(argv, &args, prefix);
+ parse_pathspec_arg(argv + 1, &args);
+
+ return ar->write_archive(&args);
+}
diff --git a/archive.h b/archive.h
index 4a02371..6b5fe5a 100644
--- a/archive.h
+++ b/archive.h
@@ -41,5 +41,6 @@ extern int write_tar_archive(struct archiver_args *);
extern int write_zip_archive(struct archiver_args *);
extern int write_archive_entries(struct archiver_args *args, write_archive_entry_fn_t write_entry);
+extern int write_archive(int argc, const char **argv, const char *prefix, int setup_prefix);
#endif /* ARCHIVE_H */
diff --git a/builtin-archive.c b/builtin-archive.c
index df97724..502b339 100644
--- a/builtin-archive.c
+++ b/builtin-archive.c
@@ -232,9 +232,6 @@ static const char *extract_remote_arg(int *ac, const char **av)
int cmd_archive(int argc, const char **argv, const char *prefix)
{
- const struct archiver *ar = NULL;
- struct archiver_args args;
- int tree_idx;
const char *remote = NULL;
remote = extract_remote_arg(&argc, argv);
@@ -243,13 +240,5 @@ int cmd_archive(int argc, const char **argv, const char *prefix)
setvbuf(stderr, NULL, _IOLBF, BUFSIZ);
- tree_idx = parse_archive_args(argc, argv, &ar, &args);
- if (prefix == NULL)
- prefix = setup_git_directory();
-
- argv += tree_idx;
- parse_treeish_arg(argv, &args, prefix);
- parse_pathspec_arg(argv + 1, &args);
-
- return ar->write_archive(&args);
+ return write_archive(argc, argv, prefix, 1);
}
diff --git a/builtin-upload-archive.c b/builtin-upload-archive.c
index 13a6c62..cc37b36 100644
--- a/builtin-upload-archive.c
+++ b/builtin-upload-archive.c
@@ -19,12 +19,9 @@ static const char lostchild[] =
static int run_upload_archive(int argc, const char **argv, const char *prefix)
{
- const struct archiver *ar;
- struct archiver_args args;
const char *sent_argv[MAX_ARGS];
const char *arg_cmd = "argument ";
char *p, buf[4096];
- int treeish_idx;
int sent_argc;
int len;
@@ -66,12 +63,7 @@ static int run_upload_archive(int argc, const char **argv, const char *prefix)
sent_argv[sent_argc] = NULL;
/* parse all options sent by the client */
- treeish_idx = parse_archive_args(sent_argc, sent_argv, &ar, &args);
-
- parse_treeish_arg(sent_argv + treeish_idx, &args, prefix);
- parse_pathspec_arg(sent_argv + treeish_idx + 1, &args);
-
- return ar->write_archive(&args);
+ return write_archive(sent_argc, sent_argv, prefix, 0);
}
static void error_clnt(const char *fmt, ...)
--
1.6.0.rc0.42.g186458
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox