* Re: Untracked working tree files
From: Junio C Hamano @ 2008-10-15 22:06 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Andrew Morton, david, Git Mailing List
In-Reply-To: <alpine.LFD.2.00.0810151311210.3288@nehalem.linux-foundation.org>
Linus Torvalds <torvalds@linux-foundation.org> writes:
> On Wed, 15 Oct 2008, Linus Torvalds wrote:
>>
> It's quite possible that we should remove unmerged entries. Except that's
> not how our internal 'read_cache_unmerged()' function works. It really
> just ignores them, and throws them on the floor. We _could_ try to just
> turn them into a (since) stage-0 entry.
>
> Junio?
I'd agree that dropping unmerged entries to stage-0 when we can would make
sense. An conflicted existing path would get an stage-0 entry in the
index, which is compared with the switched-to HEAD (which could be the
same as the current one when "git reset --hard" is run without a rev), we
notice that they are different and the index entry and the work tree path
is overwritten by the version from the switched-to HEAD. For a new path
that a failed merge tried to bring in, we notice that the switched-to HEAD
does not have that path and happily remove it from the index and from the
work tree. All will go a lot smoother than the current code.
I am not sure what should happen when we can't drop the unmerged entry
down to stage-0 due to D/F conflicts, though. IIRC, read-tree proper
would not touch the work tree in such a case, but merge-recursive creates
our and their versions with funny suffixes, which will not be known to the
index and will be left in the working tree.
^ permalink raw reply
* [PATCH] parse-opt: migrate builtin-checkout-index.
From: Miklos Vajna @ 2008-10-15 22:55 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
Signed-off-by: Miklos Vajna <vmiklos@frugalware.org>
---
NOTE: I introduced the force/quiet/not_new helper variables because they
are originally bitfields, so passing their address is not possible. One
could say that introducing helper functions for those as well would be
nicer, but I think that would just make the code even longer with no
good reason.
builtin-checkout-index.c | 151 +++++++++++++++++++++++++---------------------
1 files changed, 82 insertions(+), 69 deletions(-)
diff --git a/builtin-checkout-index.c b/builtin-checkout-index.c
index 4ba2702..e241cd1 100644
--- a/builtin-checkout-index.c
+++ b/builtin-checkout-index.c
@@ -40,6 +40,7 @@
#include "cache.h"
#include "quote.h"
#include "cache-tree.h"
+#include "parse-options.h"
#define CHECKOUT_ALL 4
static int line_termination = '\n';
@@ -153,11 +154,55 @@ static void checkout_all(const char *prefix, int prefix_length)
exit(128);
}
-static const char checkout_cache_usage[] =
-"git checkout-index [-u] [-q] [-a] [-f] [-n] [--stage=[123]|all] [--prefix=<string>] [--temp] [--] <file>...";
+static const char * const builtin_checkout_index_usage[] = {
+ "git checkout-index [-u] [-q] [-a] [-f] [-n] [--stage=[123]|all] [--prefix=<string>] [--temp] [--] <file>...",
+ NULL
+};
static struct lock_file lock_file;
+static int option_parse_u(const struct option *opt,
+ const char *arg, int unset)
+{
+ int *newfd = opt->value;
+
+ state.refresh_cache = 1;
+ if (*newfd < 0)
+ *newfd = hold_locked_index(&lock_file, 1);
+ return 0;
+}
+
+static int option_parse_z(const struct option *opt,
+ const char *arg, int unset)
+{
+ line_termination = unset;
+ return 0;
+}
+
+static int option_parse_prefix(const struct option *opt,
+ const char *arg, int unset)
+{
+ state.base_dir = arg;
+ state.base_dir_len = strlen(arg);
+ return 0;
+}
+
+static int option_parse_stage(const struct option *opt,
+ const char *arg, int unset)
+{
+ if (!strcmp(arg, "all")) {
+ to_tempfile = 1;
+ checkout_stage = CHECKOUT_ALL;
+ } else {
+ int ch = arg[0];
+ if ('1' <= ch && ch <= '3')
+ checkout_stage = arg[0] - '0';
+ else
+ die("stage should be between 1 and 3 or all");
+ }
+ return 0;
+}
+
int cmd_checkout_index(int argc, const char **argv, const char *prefix)
{
int i;
@@ -165,6 +210,33 @@ int cmd_checkout_index(int argc, const char **argv, const char *prefix)
int all = 0;
int read_from_stdin = 0;
int prefix_length;
+ int force = 0, quiet = 0, not_new = 0;
+ struct option builtin_checkout_index_options[] = {
+ OPT_BOOLEAN('a', "all", &all,
+ "checks out all files in the index"),
+ OPT_BOOLEAN('f', "force", &force,
+ "forces overwrite of existing files"),
+ OPT__QUIET(&quiet),
+ OPT_BOOLEAN('n', "no-create", ¬_new,
+ "don't checkout new files"),
+ { OPTION_CALLBACK, 'u', "index", &newfd, NULL,
+ "update stat information in the index file",
+ PARSE_OPT_NOARG, option_parse_u },
+ { OPTION_CALLBACK, 'z', NULL, NULL, NULL,
+ "paths are separated with NUL character",
+ PARSE_OPT_NOARG, option_parse_z },
+ OPT_BOOLEAN(0, "stdin", &read_from_stdin,
+ "read list of paths from the standard input"),
+ OPT_BOOLEAN(0, "temp", &to_tempfile,
+ "write the content to temporary files"),
+ OPT_CALLBACK(0, "prefix", NULL, "string",
+ "when creating files, prepend <string>",
+ option_parse_prefix),
+ OPT_CALLBACK(0, "stage", NULL, NULL,
+ "copy out the files from named stage",
+ option_parse_stage),
+ OPT_END()
+ };
git_config(git_default_config, NULL);
state.base_dir = "";
@@ -174,72 +246,13 @@ int cmd_checkout_index(int argc, const char **argv, const char *prefix)
die("invalid cache");
}
- for (i = 1; i < argc; i++) {
- const char *arg = argv[i];
-
- if (!strcmp(arg, "--")) {
- i++;
- break;
- }
- if (!strcmp(arg, "-a") || !strcmp(arg, "--all")) {
- all = 1;
- continue;
- }
- if (!strcmp(arg, "-f") || !strcmp(arg, "--force")) {
- state.force = 1;
- continue;
- }
- if (!strcmp(arg, "-q") || !strcmp(arg, "--quiet")) {
- state.quiet = 1;
- continue;
- }
- if (!strcmp(arg, "-n") || !strcmp(arg, "--no-create")) {
- state.not_new = 1;
- continue;
- }
- if (!strcmp(arg, "-u") || !strcmp(arg, "--index")) {
- state.refresh_cache = 1;
- if (newfd < 0)
- newfd = hold_locked_index(&lock_file, 1);
- continue;
- }
- if (!strcmp(arg, "-z")) {
- line_termination = 0;
- continue;
- }
- if (!strcmp(arg, "--stdin")) {
- if (i != argc - 1)
- die("--stdin must be at the end");
- read_from_stdin = 1;
- i++; /* do not consider arg as a file name */
- break;
- }
- if (!strcmp(arg, "--temp")) {
- to_tempfile = 1;
- continue;
- }
- if (!prefixcmp(arg, "--prefix=")) {
- state.base_dir = arg+9;
- state.base_dir_len = strlen(state.base_dir);
- continue;
- }
- if (!prefixcmp(arg, "--stage=")) {
- if (!strcmp(arg + 8, "all")) {
- to_tempfile = 1;
- checkout_stage = CHECKOUT_ALL;
- } else {
- int ch = arg[8];
- if ('1' <= ch && ch <= '3')
- checkout_stage = arg[8] - '0';
- else
- die("stage should be between 1 and 3 or all");
- }
- continue;
- }
- if (arg[0] == '-')
- usage(checkout_cache_usage);
- break;
- }
+ argc = parse_options(argc, argv, builtin_checkout_index_options,
+ builtin_checkout_index_usage, 0);
+ state.force = force;
+ state.quiet = quiet;
+ state.not_new = not_new;
+ if (argc && read_from_stdin)
+ die("--stdin must be at the end");
if (state.base_dir_len || to_tempfile) {
/* when --prefix is specified we do not
@@ -253,7 +266,7 @@ int cmd_checkout_index(int argc, const char **argv, const char *prefix)
}
/* Check out named files first */
- for ( ; i < argc; i++) {
+ for (i = 0; i < argc; i++) {
const char *arg = argv[i];
const char *p;
--
1.6.0.2
^ permalink raw reply related
* [PATCH] reset --hard/read-tree --reset -u: remove unmerged new paths
From: Junio C Hamano @ 2008-10-15 23:00 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Andrew Morton, david, Git Mailing List
In-Reply-To: <7v3aixqzrn.fsf@gitster.siamese.dyndns.org>
When aborting a failed merge that has brought in a new path using "git
reset --hard" or "git read-tree --reset -u", we used to first forget about
the new path (via read_cache_unmerged) and then matched the working tree
to what is recorded in the index, thus ending up leaving the new path in
the work tree.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
---
Junio C Hamano <gitster@pobox.com> writes:
> Linus Torvalds <torvalds@linux-foundation.org> writes:
>
>> On Wed, 15 Oct 2008, Linus Torvalds wrote:
>>>
>> It's quite possible that we should remove unmerged entries. Except that's
>> not how our internal 'read_cache_unmerged()' function works. It really
>> just ignores them, and throws them on the floor. We _could_ try to just
>> turn them into a (since) stage-0 entry.
>>
>> Junio?
>
> I am not sure what should happen when we can't drop the unmerged entry
> down to stage-0 due to D/F conflicts, though. IIRC, read-tree proper
> would not touch the work tree in such a case, but merge-recursive creates
> our and their versions with funny suffixes, which will not be known to the
> index and will be left in the working tree.
I am still unsure what we should do when we hit D/F conflicts; this one
simply replaces but it may be safer to drop ADD_CACHE_OK_TO_REPLACE from
the options to trigger an error in such a case. I dunno.
read-cache.c | 32 +++++++++++++++++++-------------
t/t1005-read-tree-reset.sh | 30 ++++++++++++++++++++++++++++++
2 files changed, 49 insertions(+), 13 deletions(-)
diff --git a/read-cache.c b/read-cache.c
index c229fd4..efbab6a 100644
--- a/read-cache.c
+++ b/read-cache.c
@@ -1489,25 +1489,31 @@ int write_index(const struct index_state *istate, int newfd)
int read_index_unmerged(struct index_state *istate)
{
int i;
- struct cache_entry **dst;
- struct cache_entry *last = NULL;
+ int unmerged = 0;
read_index(istate);
- dst = istate->cache;
for (i = 0; i < istate->cache_nr; i++) {
struct cache_entry *ce = istate->cache[i];
- if (ce_stage(ce)) {
- remove_name_hash(ce);
- if (last && !strcmp(ce->name, last->name))
- continue;
- cache_tree_invalidate_path(istate->cache_tree, ce->name);
- last = ce;
+ struct cache_entry *new_ce;
+ int size, len, option;
+
+ if (!ce_stage(ce))
continue;
- }
- *dst++ = ce;
+ unmerged = 1;
+ len = strlen(ce->name);
+ size = cache_entry_size(len);
+ new_ce = xcalloc(1, size);
+ hashcpy(new_ce->sha1, ce->sha1);
+ memcpy(new_ce->name, ce->name, len);
+ new_ce->ce_flags = create_ce_flags(len, 0);
+ new_ce->ce_mode = ce->ce_mode;
+ option = ADD_CACHE_OK_TO_ADD|ADD_CACHE_OK_TO_REPLACE;
+ if (add_index_entry(istate, new_ce, option))
+ return error("%s: cannot drop to stage #0",
+ ce->name);
+ i = index_name_pos(istate, new_ce->name, len);
}
- istate->cache_nr = dst - istate->cache;
- return !!last;
+ return unmerged;
}
struct update_callback_data
diff --git a/t/t1005-read-tree-reset.sh b/t/t1005-read-tree-reset.sh
index b0d31f5..0cd519c 100755
--- a/t/t1005-read-tree-reset.sh
+++ b/t/t1005-read-tree-reset.sh
@@ -27,4 +27,34 @@ test_expect_success 'reset should work' '
test_cmp expect actual
'
+test_expect_success 'reset should remove remnants from a failed merge' '
+ git read-tree --reset -u HEAD &&
+ git ls-files -s >expect &&
+ sha1=$(git rev-parse :new) &&
+ (
+ echo "100644 $sha1 1 old"
+ echo "100644 $sha1 3 old"
+ ) | git update-index --index-info &&
+ >old &&
+ git ls-files -s &&
+ git read-tree --reset -u HEAD &&
+ git ls-files -s >actual &&
+ ! test -f old
+'
+
+test_expect_success 'Porcelain reset should remove remnants too' '
+ git read-tree --reset -u HEAD &&
+ git ls-files -s >expect &&
+ sha1=$(git rev-parse :new) &&
+ (
+ echo "100644 $sha1 1 old"
+ echo "100644 $sha1 3 old"
+ ) | git update-index --index-info &&
+ >old &&
+ git ls-files -s &&
+ git reset --hard &&
+ git ls-files -s >actual &&
+ ! test -f old
+'
+
test_done
--
1.6.0.2.717.gc6f0a
^ permalink raw reply related
* Re: builtin conversion between tabs and spaces
From: Stefan Karpinski @ 2008-10-15 23:02 UTC (permalink / raw)
To: Jonathan del Strother; +Cc: Alex Riesen, Git Mailing List, Johannes Sixt
In-Reply-To: <d4bc1a2a0810151418r3bf21ddaj498017e8e178f579@mail.gmail.com>
Any further comments? I'm more than willing to implement this, but I
won't bother if there's no chance of getting it accepted as a patch.
Does no one else feel like at least having the option to enforce
whitespace consistency in git is a good thing? If not, I guess I'll
just muddle along without this feature instead of implementing it.
On Wed, Oct 15, 2008 at 2:18 PM, Stefan Karpinski
<stefan.karpinski@gmail.com> wrote:
> That's not what I would call a "crazy" mix of tabs and spaces, but
> rather a *sane* mix of tabs and spaces. That can consistently be
> reproduced, and is in fact what the spaces_to_tabs function included
> above produces. The sane consistent formats as I see it are:
>
> 1) use spaces for everything
> 2) use tabs for indentation, spaces for everything else
> 3) use tabs for indentation and alignment
>
> If you know the tab size, you can reproduce any of these from the
> others, except that #3 is a little tricky since there's places where
> the tab/space issue can be ambiguous. I actually think that keeping
> the repo version with tab-based indentation is a very sane thing to
> do. However, I'd still like to be able to edit the files using soft
> tabs, largely because any program that doesn't know what my tab size
> should be applies its own interpretation and makes the code look
> terrible (think terminal output for diff, cat, less, etc.)
>
> On the other hand, a *crazy* mix of tabs and spaces is where some
> indentation is done with spaces while other indentation is done with
> tabs. Even crazier is a single line where the indentation is a mixture
> of tabs and spaces. I think that just about everyone can agree that
> this is not only crazy, but evil and is the kind of thing one really
> wants to avoid in a code base. Unfortunately, when developers disagree
> on their standard settings, it's very, very hard to avoid precisely
> this kind of mess. My idea is to enable git to prevent this sort of
> insanity if configured to do so.
^ permalink raw reply
* Re: [PATCH] reset --hard/read-tree --reset -u: remove unmerged new paths
From: Linus Torvalds @ 2008-10-15 23:16 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Andrew Morton, david, Git Mailing List
In-Reply-To: <7vy70ppiq1.fsf_-_@gitster.siamese.dyndns.org>
On Wed, 15 Oct 2008, Junio C Hamano wrote:
>
> When aborting a failed merge that has brought in a new path using "git
> reset --hard" or "git read-tree --reset -u", we used to first forget about
> the new path (via read_cache_unmerged) and then matched the working tree
> to what is recorded in the index, thus ending up leaving the new path in
> the work tree.
Looks good to me. And from my tests, I think "git checkout -f" didn't have
this problem at all, because it ends up using not got read-tree, but doing
its own "reset_tree()" that uses unpack_trees().
I do wonder if "git reset" should perhaps be written in those terms,
instead of just being a wrapper around git read-tree. But the patch looks
fine.
Linus
^ permalink raw reply
* Re: [PATCH] gitk: bind Key-Return to create on new branch dialog
From: Paul Mackerras @ 2008-10-15 23:11 UTC (permalink / raw)
To: Richard Quirk; +Cc: git
In-Reply-To: <1224017605-13893-1-git-send-email-richard.quirk@gmail.com>
Richard Quirk writes:
> The Return key can now be used as well as pressing the Create button
> from the dialog box that is shown when selecting "Create new branch".
Thanks, applied.
Paul.
^ permalink raw reply
* Re: builtin conversion between tabs and spaces
From: A Large Angry SCM @ 2008-10-15 23:34 UTC (permalink / raw)
To: Stefan Karpinski
Cc: Jonathan del Strother, Alex Riesen, Git Mailing List,
Johannes Sixt
In-Reply-To: <d4bc1a2a0810151602j56550c3di2f59f92039fa8243@mail.gmail.com>
Stefan Karpinski wrote:
> Any further comments? I'm more than willing to implement this, but I
> won't bother if there's no chance of getting it accepted as a patch.
> Does no one else feel like at least having the option to enforce
> whitespace consistency in git is a good thing? If not, I guess I'll
> just muddle along without this feature instead of implementing it.
I'm against including this in except as a sample smudge/clean script.
Git is a content tracker; not the enforcement mechanism for individual
project policies.
^ permalink raw reply
* [PATCH maint 2/2] t4018-diff-funcname: demonstrate end of line funcname matching flaw
From: drafnel @ 2008-10-16 0:58 UTC (permalink / raw)
To: gitster; +Cc: git, Brandon Casey
In-Reply-To: <1224118730-24711-1-git-send-email-drafnel@gmail.com>
Since the newline is not removed from lines before pattern matching, a
pattern cannot match to the end of the line using the '$' operator without
using an additional operator which will indirectly match the '\n' character.
Introduce a test which should pass, but which does not due to this flaw.
Signed-off-by: Brandon Casey <drafnel@gmail.com>
---
t/t4018-diff-funcname.sh | 6 ++++++
1 files changed, 6 insertions(+), 0 deletions(-)
diff --git a/t/t4018-diff-funcname.sh b/t/t4018-diff-funcname.sh
index 72076ec..40a805a 100755
--- a/t/t4018-diff-funcname.sh
+++ b/t/t4018-diff-funcname.sh
@@ -69,6 +69,12 @@ test_expect_success 'last regexp must not be negated' '
grep "fatal: Last expression must not be negated:"
'
+test_expect_failure 'pattern which matches to end of line' '
+ git config diff.java.funcname "Beer$" &&
+ git diff --no-index Beer.java Beer-correct.java |
+ grep "^@@.*@@ Beer"
+'
+
test_expect_success 'alternation in pattern' '
git config diff.java.xfuncname "^[ ]*((public|static).*)$" &&
git diff --no-index Beer.java Beer-correct.java |
--
1.6.0.2.101.gb844
^ permalink raw reply related
* [PATCH maint 1/2] t4018-diff-funcname: rework negated last expression test
From: drafnel @ 2008-10-16 0:58 UTC (permalink / raw)
To: gitster; +Cc: git, Brandon Casey
In-Reply-To: <7vljwpr6lr.fsf@gitster.siamese.dyndns.org>
This test used the non-zero exit status of 'git diff' to indicate that a
negated funcname pattern, when placed last, was correctly rejected.
The problem with this is that 'git diff' always returns non-zero if it
finds differences in the files it is comparing, and the files must
contain differences in order to trigger the funcname pattern codepath.
Instead of checking for non-zero exit status, make sure the expected
error message is printed.
Signed-off-by: Brandon Casey <drafnel@gmail.com>
---
This is not really a series, but I expect you'll apply both, so this
seems easier for both of us.
-brandon
t/t4018-diff-funcname.sh | 3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/t/t4018-diff-funcname.sh b/t/t4018-diff-funcname.sh
index 99fff97..72076ec 100755
--- a/t/t4018-diff-funcname.sh
+++ b/t/t4018-diff-funcname.sh
@@ -65,7 +65,8 @@ test_expect_success 'custom pattern' '
test_expect_success 'last regexp must not be negated' '
git config diff.java.funcname "!static" &&
- test_must_fail git diff --no-index Beer.java Beer-correct.java
+ git diff --no-index Beer.java Beer-correct.java 2>&1 |
+ grep "fatal: Last expression must not be negated:"
'
test_expect_success 'alternation in pattern' '
--
1.6.0.2.101.gb844
^ permalink raw reply related
* Re: builtin conversion between tabs and spaces
From: Stefan Karpinski @ 2008-10-16 2:00 UTC (permalink / raw)
To: gitzilla
Cc: Jonathan del Strother, Alex Riesen, Git Mailing List,
Johannes Sixt
In-Reply-To: <48F67E09.90202@gmail.com>
>> Any further comments? I'm more than willing to implement this, but I
>> won't bother if there's no chance of getting it accepted as a patch.
>> Does no one else feel like at least having the option to enforce
>> whitespace consistency in git is a good thing? If not, I guess I'll
>> just muddle along without this feature instead of implementing it.
>
> I'm against including this in except as a sample smudge/clean script. Git is
> a content tracker; not the enforcement mechanism for individual project
> policies.
Alright. Fair enough.
^ permalink raw reply
* Re: [PATCH try 2] t1301-shared-repo.sh: don't let a default ACL interfere with the test
From: Junio C Hamano @ 2008-10-16 5:23 UTC (permalink / raw)
To: Johannes Sixt; +Cc: Matt McCutchen, git
In-Reply-To: <48F5A590.3050905@viscovery.net>
Johannes Sixt <j.sixt@viscovery.net> writes:
> Junio C Hamano schrieb:
>
>> If that is the case what difference does your suggestion of not putting it
>> in test-lib.sh make? We discourage users from playing ACL games, and we
>> protect ourselves from such by making sure the trash directory used for
>> running tests are not contaminated with ACL. Wouldn't it make more sense
>> to do so for all the tests, so that future test writers do not have to
>> worry about it?
>
> We have to decide case by case. In the case of shared directories it makes
> sense to suggest "do not play ACL games". In other cases, however, this
> suggestion could not work out that well, and a workaround in the code is
> the better solutions. But we do not know what those other cases are, and
> the test suite may be a tool to uncover them.
Although I am not particularly interested in hypothetical case that does
not have concrete examples, I do not care deeply enough either. So let's
take this patch (with updated/corrected log message) that minimally covers
the parts that can be broken by ACL games.
^ permalink raw reply
* Re: [PATCH] Teach/Fix git-pull/git-merge --quiet and --verbose
From: Tuncer Ayaz @ 2008-10-16 5:54 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vprm1pfmd.fsf@gitster.siamese.dyndns.org>
On Thu, Oct 16, 2008 at 2:07 AM, Junio C Hamano <gitster@pobox.com> wrote:
> "Tuncer Ayaz" <tuncer.ayaz@gmail.com> writes:
>
>> On Wed, Oct 15, 2008 at 9:06 PM, Junio C Hamano <gitster@pobox.com> wrote:
>>> "Tuncer Ayaz" <tuncer.ayaz@gmail.com> writes:
>>>
>>>> Junio, what's the status here? Do you want me to rework it
>>>> all with a new verbose/quiet log infrastructure or
>>>
>>> Not really.
>>
>> OK, when do you expect to cut 1.6.0.3? It's so simple
>> that I'd like to have it included in that revision.
>
> Hmm, I did not think this was a breakage that needs to be fixed on the
> maintenance track. git-pull does not know -q nor -v and teaching these
> new options to the command would be a feature enhancement, which by
> definition won't be in 1.6.0.3.
It's no breakage as the options did not exist before :-), yes.
>>> Using two variables to keep track of what is conceptually a tristate
>>> (quiet, normal and verbose) is insane, and I'd like to see that insanity
>>> fixed first in the patch, regardless of an elaborate "log infrastructure"
>>> you mentioned.
>>
>> I see what you mean. What about all other modules
>> with quiet/verbose doing it with two variables?
>
> Are they broken? If not, let's not touch them. On the other hand, let's
> avoid adding more.
Not really. After I fixed -q in clone/fetch Miklos Vajna came up
with --verbose for clone. I just thought if we come up with a
new way to handle this we should fix it everywhere -v and
-q are available and make it consistent.
>> I guess doing it with a single variable in pull first
>> as an example is what you're after, right?
>
> I did not actually mind the ones in 'git-pull' that much, as eventually
> the script will be rewritten in C by somebody anyway. The patch to
> builtin-fetch.c/builtin-merge.c is different, as the repetition of
> (verbose || !quiet) was quite noticeable.
I've added -v as it was added to clone in "[PATCH] Implement
git clone -v" and I wanted to be fair to the IDE developers.
Would you prefer to leave -v out?
> Why have we gone off-list, by the way?
I was not sure this is of interest to everybody.
We are now on-list again :-).
^ permalink raw reply
* Re: [PATCH] Teach/Fix git-pull/git-merge --quiet and --verbose
From: Junio C Hamano @ 2008-10-16 6:15 UTC (permalink / raw)
To: Tuncer Ayaz; +Cc: git
In-Reply-To: <4ac8254d0810152254i615bca9dye0aedd8689c946e7@mail.gmail.com>
"Tuncer Ayaz" <tuncer.ayaz@gmail.com> writes:
> On Thu, Oct 16, 2008 at 2:07 AM, Junio C Hamano <gitster@pobox.com> wrote:
>> "Tuncer Ayaz" <tuncer.ayaz@gmail.com> writes:
>>
>>> On Wed, Oct 15, 2008 at 9:06 PM, Junio C Hamano <gitster@pobox.com> wrote:
>>>> "Tuncer Ayaz" <tuncer.ayaz@gmail.com> writes:
>>>>
> Would you prefer to leave -v out?
Not at all.
Perhaps there is a deeper misunderstanding.
It makes perfect sense _at the end user interface level_ to have -v and -q
as two separate options, perhaps with "later one wins" semantics. Another
possible semantics is "-q and -v are mutually incompatible", but I think
"later one wins" makes it much more usable from the end user's point of view.
The only thing I was objecting to was your repeated (verbose || !quiet)
expression in the _implementation_, which would have been much easier to
read and maintain, if it were expressed as a single variable "verbosity"
that can have one of three values.
IOW,
static enum { QUIET, NORMAL, VERBOSE } verbosity = NORMAL;
...
if (!strcmp("--quiet", arg))
verbosity = QUIET;
else if (!strcmp("--verbose", arg))
verbosity = VERBOSE;
else ...
...
if (verbosity > QUIET)
print informational message;
if (verbosity > NORMAL)
print verbose message;
See?
^ permalink raw reply
* Re: [PATCH] Fix mkpath abuse in dwim_ref/sha1_name.c
From: Alex Riesen @ 2008-10-16 6:21 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Git Mailing List, Shawn O. Pearce
In-Reply-To: <7vabd5r1ss.fsf@gitster.siamese.dyndns.org>
2008/10/15 Junio C Hamano <gitster@pobox.com>:
> Alex Riesen <raa.lkml@gmail.com> writes:
>
>> Junio C Hamano, Wed, Oct 15, 2008 01:17:52 +0200:
>>> "Alex Riesen" <raa.lkml@gmail.com> writes:
>>> >
>>> > Otherwise the function sometimes fail to resolve obviously correct refnames,
>>> > because the string data pointed to by "ref" argument were reused.
>>> >
>>> But your patch instead rewrites the computation of str2 by bypassing the
>>> call to "another_function_that_uses_get_pathname()" and duplicating its
>>> logic, which I do not think is a viable approach in the longer term.
>>
>> There is not enough logic to bypass there. It's just a dumb sprintf!
>
> But didn't you lose call to cleanup_path()?
>
In this case?
^ permalink raw reply
* Re: [PATCH] reset --hard/read-tree --reset -u: remove unmerged new paths
From: Junio C Hamano @ 2008-10-16 6:27 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Andrew Morton, david, Git Mailing List
In-Reply-To: <alpine.LFD.2.00.0810151615550.3288@nehalem.linux-foundation.org>
Linus Torvalds <torvalds@linux-foundation.org> writes:
> On Wed, 15 Oct 2008, Junio C Hamano wrote:
>>
>> When aborting a failed merge that has brought in a new path using "git
>> reset --hard" or "git read-tree --reset -u", we used to first forget about
>> the new path (via read_cache_unmerged) and then matched the working tree
>> to what is recorded in the index, thus ending up leaving the new path in
>> the work tree.
>
> Looks good to me. And from my tests, I think "git checkout -f" didn't have
> this problem at all, because it ends up using not got read-tree, but doing
> its own "reset_tree()" that uses unpack_trees().
>
> I do wonder if "git reset" should perhaps be written in those terms,
> instead of just being a wrapper around git read-tree. But the patch looks
> fine.
Let's do this for 'maint' and I'll let others think about possible
improvements, then ;-).
^ permalink raw reply
* Re: git-svnimport.perl bug when copy source path has a revision
From: Pete Harlan @ 2008-10-16 6:43 UTC (permalink / raw)
To: Karl Chen; +Cc: Git mailing list
In-Reply-To: <quack.20081015T1211.lth8wsp65dk@roar.cs.berkeley.edu>
Karl Chen wrote:
> This looks like a bug in git-svnimport.perl. If a tag (or
> branch?) is created retroactively, git-svnimport doesn't respect
> the copy source revision.
>
> To reproduce:
>
> svnadmin create somerepo; export R=file://$PWD/somerepo
>
> svn co $R wc && cd wc
>
> mkdir trunk tags && svn add trunk tags && svn commit -m "" # rev 1
>
> cd trunk
> echo a > a
> echo b > b
> echo c > c
>
> svn add a && svn commit -m "commit a" # rev 2
> svn add b && svn commit -m "commit b" # rev 3
> # Copy from revision 2 instead of HEAD:
> svn cp -m "tag rev 2" $R/trunk@2 $R/tags/mytag # rev 4
> svn add c && svn commit -m "commit c" # rev 5
>
> svn ls $R/tags/mytag
> # Lists only 'a'
>
> mkdir /tmp/gitrepo && cd /tmp/gitrepo
> perl /usr/share/doc/git-core/contrib/examples/git-svnimport.perl $R
>
> git log mytag
> # 'mytag' includes "commit b"; it was created as if it were tagged
> # at r3; the "@2" was ignored.
If you replace this:
> perl /usr/share/doc/git-core/contrib/examples/git-svnimport.perl $R
with:
git svn init -T trunk -t tags $R
git svn fetch
git log tags/mytag
you get a log that doesn't include "commit b". (And it does include the
tag commit, as svn does.) tags/mytag is a branch, visibile via "git
branch -r", instead of a tag. I'm not fluent enough in git svn to know
if this is a bug or a feature.
According to git logs (8cb070a4, fee9832a), git-svnimport.perl hasn't
been maintained in a while, presumably because git svn provides a
superset of its functionality.
HTH,
--Pete
^ permalink raw reply
* Re: [PATCH] reset --hard/read-tree --reset -u: remove unmerged new paths
From: Ingo Molnar @ 2008-10-16 7:20 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Linus Torvalds, Andrew Morton, david, Git Mailing List
In-Reply-To: <7vy70ppiq1.fsf_-_@gitster.siamese.dyndns.org>
* Junio C Hamano <gitster@pobox.com> wrote:
> When aborting a failed merge that has brought in a new path using "git
> reset --hard" or "git read-tree --reset -u", we used to first forget
> about the new path (via read_cache_unmerged) and then matched the
> working tree to what is recorded in the index, thus ending up leaving
> the new path in the work tree.
i've met this problem in various variants in the past few months, and i
always assumed that it's "as designed" - as Git's policy is to never
lose information unless forced to do so. (which i find very nice in
general, and which saved modification from getting lost a couple of
times in the past)
the situations where i end up with a messed up working tree [using
git-c427559 right now]:
- doing a conflicted Octopus merge will leave the tree in some weird
half-merged state, with lots of untracked working tree files that not
even a hard reset will recover from. The routine thing i do to clean
up is:
git reset --hard HEAD
git checkout HEAD .
git ls-files --others | xargs rm # DANGEROUS
doing git checkout -f alone is not enough, as there might be various
dangling files left around.
- git auto-gc thinking that it needs to do another pass in the middle
of a random git operation, but i dont have 10 minutes to wait so i
decide to Ctrl-C it.
- doing the wrong "git checkout" and then Ctlr-C-ing it can leave the
working tree in limbo as well, needing fixups. If i'm stuck between
two branches that rename/remove files it might need the full fixup
sequence above.
- if a testbox has a corrupted system clock, its git repo and the
kernel build can get confused. This is to be expected i think - but
the full sequence above will recover the corrupted tree. Not much Git
can do about this i guess.
Does your fix mean that all i have to do in the future is a hard reset
back to HEAD, and that dangling files are not supposed to stay around?
Ingo
^ permalink raw reply
* Re: [PATCH] parse-opt: migrate builtin-checkout-index.
From: Pierre Habouzit @ 2008-10-16 8:23 UTC (permalink / raw)
To: Miklos Vajna; +Cc: Junio C Hamano, git
In-Reply-To: <1224111343-17433-1-git-send-email-vmiklos@frugalware.org>
[-- Attachment #1: Type: text/plain, Size: 1919 bytes --]
On Wed, Oct 15, 2008 at 10:55:43PM +0000, Miklos Vajna wrote:
> Signed-off-by: Miklos Vajna <vmiklos@frugalware.org>
> ---
>
> NOTE: I introduced the force/quiet/not_new helper variables because they
> are originally bitfields, so passing their address is not possible. One
> could say that introducing helper functions for those as well would be
> nicer, but I think that would just make the code even longer with no
> good reason.
Well the alternative is to replace the bitfields with an enum, but it's
not always that nice as a result. C bit-fields sucks when it comes to
address them, it's silly not to be able to have the same as offsetof in
"bits" for a structure, but oh well.
> diff --git a/builtin-checkout-index.c b/builtin-checkout-index.c
> index 4ba2702..e241cd1 100644
> --- a/builtin-checkout-index.c
> +++ b/builtin-checkout-index.c
> @@ -40,6 +40,7 @@
> #include "cache.h"
> #include "quote.h"
> #include "cache-tree.h"
> +#include "parse-options.h"
>
> #define CHECKOUT_ALL 4
> static int line_termination = '\n';
> @@ -153,11 +154,55 @@ static void checkout_all(const char *prefix, int prefix_length)
> exit(128);
> }
>
> -static const char checkout_cache_usage[] =
> -"git checkout-index [-u] [-q] [-a] [-f] [-n] [--stage=[123]|all] [--prefix=<string>] [--temp] [--] <file>...";
> +static const char * const builtin_checkout_index_usage[] = {
> + "git checkout-index [-u] [-q] [-a] [-f] [-n] [--stage=[123]|all] [--prefix=<string>] [--temp] [--] <file>...",
> + NULL
> +};
Since git checkout-index -h will show you all the options, I usually
prefer to use "[options] [--] <file>...", it's 10x as readable, and the
user will have the [options] detail just below.
--
·O· Pierre Habouzit
··O madcoder@debian.org
OOO http://www.madism.org
[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Re: Untracked working tree files
From: Paolo Ciarrocchi @ 2008-10-16 8:42 UTC (permalink / raw)
To: Andrew Morton; +Cc: Linus Torvalds, david, git
In-Reply-To: <20081015132309.76d3cc28.akpm@linux-foundation.org>
On Wed, Oct 15, 2008 at 10:23 PM, Andrew Morton
<akpm@linux-foundation.org> wrote:
> On Wed, 15 Oct 2008 13:08:36 -0700 (PDT)
> Linus Torvalds <torvalds@linux-foundation.org> wrote:
>> On Wed, 15 Oct 2008, Andrew Morton wrote:
[...]
>> Is "git checkout -f" part of the scripting? Or "git reset --hard"?
>
> well, this script has been hacked on so many times I'm not sure what
> it does any more.
>
> Presently the main generate-a-diff function is
>
Hi Andrew,
I was wondering whether you could share the scripts you built on top of git,
you might get some useful suggestions from this list and they could be
inspiration for further improvement in GIT (it just happened with this
thread ;-)
Thanks.
Ciao,
--
Paolo
http://paolo.ciarrocchi.googlepages.com/
^ permalink raw reply
* git-svn and svnsync
From: Andriy Gapon @ 2008-10-16 8:07 UTC (permalink / raw)
To: git
I did the following:
1. mirror svn repository using svnsync
2. clone the mirror with git-svn --use-svnsync-props and some tweaking[*]
3. run git svn info in the clone
4. get error "Unable to determine upstream SVN information from working
tree history"
git svn log and git svn rebase do not work either.
git log does work.
I have git version 1.6.0.2 (from FreeBSD ports).
[*] About the tweaking - I manually massaged config file to get the
branches I was interested in, so .git/config is this:
[core]
repositoryformatversion = 0
filemode = true
bare = false
logallrefupdates = true
[svn-remote "svn"]
useSvnsyncProps = 1
url = file:///system/devel/svn/base
fetch = head:refs/remotes/trunk
fetch = stable/6:refs/remotes/stable_6
fetch = stable/7:refs/remotes/stable_7
fetch = releng/6.3:refs/remotes/releng_6_3
fetch = releng/6.4:refs/remotes/releng_6_4
fetch = releng/7.0:refs/remotes/releng_7_0
fetch = release/6.3.0:refs/remotes/release_6_3_0
fetch = release/7.0.0:refs/remotes/release_7_0_0
This is .git/svn/.metadata:
; This file is used internally by git-svn
; You should not have to edit it
[svn-remote "svn"]
reposRoot = file:///system/devel/svn/base
uuid = ccf9f872-aa2e-dd11-9fc8-001c23d0bc1f
svnsync-uuid = ccf9f872-aa2e-dd11-9fc8-001c23d0bc1f
svnsync-url = svn://svn.freebsd.org/base
So you can see the original svn repository URL.
git log reports svn info like the following:
git-svn-id: svn://svn.freebsd.org/base/stable/7@183898
ccf9f872-aa2e-dd11-9fc8-001c23d0bc1f
It seems that the problem is that the code in find_by_url() and/or
read_all_remotes() subroutines (in git-svn.perl) are not aware of
svnsync and do not realize an URL in logs and URL in svn-remote are
different.
BTW, I see that there is some special svm logic in read_all_remotes.
Thank you very much for any help in advance.
--
Andriy Gapon
^ permalink raw reply
* Re: Untracked working tree files
From: Andrew Morton @ 2008-10-16 9:32 UTC (permalink / raw)
To: Paolo Ciarrocchi; +Cc: Linus Torvalds, david, git
In-Reply-To: <4d8e3fd30810160142x36860354ka30375e3d21438ae@mail.gmail.com>
On Thu, 16 Oct 2008 10:42:13 +0200 "Paolo Ciarrocchi" <paolo.ciarrocchi@gmail.com> wrote:
> On Wed, Oct 15, 2008 at 10:23 PM, Andrew Morton
> <akpm@linux-foundation.org> wrote:
> > On Wed, 15 Oct 2008 13:08:36 -0700 (PDT)
> > Linus Torvalds <torvalds@linux-foundation.org> wrote:
> >> On Wed, 15 Oct 2008, Andrew Morton wrote:
> [...]
> >> Is "git checkout -f" part of the scripting? Or "git reset --hard"?
> >
> > well, this script has been hacked on so many times I'm not sure what
> > it does any more.
> >
> > Presently the main generate-a-diff function is
> >
>
> Hi Andrew,
> I was wondering whether you could share the scripts you built on top of git,
> you might get some useful suggestions from this list and they could be
> inspiration for further improvement in GIT (it just happened with this
> thread ;-)
oh gee, you don't want to look. It should all be in
http://userweb.kernel.org/~akpm/stuff/patch-scripts.tar.gz
But really it's just the one script, pull-git-patches, below. That
thing's been hacked around so much that I daren't breathe on it.
Fortunately as long as Stephen Rothwell is producing linux-next I don't
have much need for it any more.
#!/bin/sh
GIT_TREE=/usr/src/git26
PULL=/usr/src/pull
git_header()
{
tree="$1"
echo GIT $(cat .git/refs/heads/$tree) $(cat .git/branches/$tree)
echo
}
# maybe use git clean -dqfx
doit()
{
tree=$1
upstream=$2
cd $GIT_TREE
git checkout -f "$upstream"
git reset --hard "$upstream"
git fetch "$tree" || exit 1
git merge --no-commit 'test merge' HEAD FETCH_HEAD > /dev/null
{
git_header "$tree"
git log --no-merges ORIG_HEAD..FETCH_HEAD
git diff --patch-with-stat ORIG_HEAD
} >$PULL/$tree.patch
{
echo DESC
echo $tree.patch
echo EDESC
git_header "$tree"
git log --no-merges ORIG_HEAD..FETCH_HEAD
} >$PULL/$tree.txt
git reset --hard "$upstream"
}
do_one()
{
tree=$1
upstream=$2
if [ ! -e $PULL/$tree.patch ]
then
echo "*** doing $tree, based on $upstream"
git branch -D $tree
doit $tree $upstream
else
echo skipping $tree
fi
}
mkdir -p $PULL
if [ $1"x" = "-x" ]
then
exit
fi
cd $GIT_TREE
git checkout -f master
cd /usr/src
if [ $# == 0 ]
then
trees=/usr/src/git-trees
else
trees="$1"
fi
if [ $# == 2 ]
then
do_one $1 $2
else
while read x
do
if echo $x | grep '^#.*' > /dev/null
then
true
else
do_one $x
fi
done < $trees
fi
^ permalink raw reply
* Re: [BUG] git status doesn't handle submodules properly on OSX
From: Pedro Melo @ 2008-10-16 9:43 UTC (permalink / raw)
To: Lars Hoss; +Cc: git
In-Reply-To: <c60a85c1297be6446ad92a3e7723ddc8.squirrel@webmail.highteq.net>
Hi,
On Oct 15, 2008, at 1:07 PM, Lars Hoss wrote:
> Greetings all,
>
> two days ago I posted about an issue:
> http://thread.gmane.org/gmane.comp.version-control.git/98171
>
> After more testing I can confirm it is indeed a bug.
>
> 1.6.0.2 on OSX Leopard doesn't work. After adding a submodule
> the folder of the submodule will always get listed under
> "Untracked files" when calling git status.
I'm using 1.6.0.2.526.g5c283 on Leopard with lots of submodules
without any problems at all.
I was going to reply to your original message but it slipped my mind
(commuting et al).
Can you provide a sequence of commands that demonstrate the problem so
that I can try?
Best regards,
--
Pedro Melo
Blog: http://www.simplicidade.org/notes/
XMPP ID: melo@simplicidade.org
Use XMPP!
^ permalink raw reply
* Re: git-scm.com
From: Nanako Shiraishi @ 2008-10-16 9:42 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Petr Baudis, Scott Chacon, Wincent Colaiuta, git
In-Reply-To: <20081015172543.GX10544@machine.or.cz>
Quoting Petr Baudis <pasky@suse.cz>:
> On Wed, Oct 15, 2008 at 09:21:50AM -0700, Scott Chacon wrote:
>> I do wish that there wasn't this 'us vs them' mentality on this list,
>> though. I think GitHub is doing some good things for the community,
>> and I also think that 'the community' is bigger than this list.
>
> I think this last sentence is where we differ - for (most of?) us the
> Git developers, 'the community' pretty much _is_ this list (with the IRC
> channel as its casual extension).
Curiously, whenever somebody says "git-scm.com is the official git homepage", you are not involved in the discussion. Could you share your position on this issue with the rest of the "community"?
--
Nanako Shiraishi
http://ivory.ap.teacup.com/nanako3/
^ permalink raw reply
* Re: [BUG] git status doesn't handle submodules properly on OSX
From: Pedro Melo @ 2008-10-16 9:48 UTC (permalink / raw)
To: Lars Hoss; +Cc: Pieter de Bie, Jeff King, Git Mailinglist
In-Reply-To: <6ca24750ca8d7bd9e995d023e78e0d71.squirrel@webmail.highteq.net>
On Oct 15, 2008, at 3:51 PM, Lars Hoss wrote:
>> Works for me on Leopard
>>
>> Vienna:a pieter$ git submodule add ~/projects/GitX/ gitx
>> Initialized empty Git repository in /Users/pieter/a/gitx/.git/
>> Vienna:a pieter$ git st
>> # On branch master
>> # Changes to be committed:
>> # (use "git reset HEAD <file>..." to unstage)
>> #
>> # new file: .gitmodules
>> # new file: gitx
>> #
>> Vienna:a pieter$ git --version
>> git version 1.6.0.2.415.gf9137
>
> My git version "1.6.0.2" says:
>
> # On branch master
> # Changes to be committed:
> # (use "git reset HEAD <file>..." to unstage)
> #
> # new file: .gitmodules
> # new file: lib
> #
> # Untracked files:
> # (use "git add <file>..." to include in what will be committed)
> #
> # lib/
> git --version
> git version 1.6.0.2
>
> Git was build from macports.
hmms.. Really, I know about fink and Macports and all others, but I'm
using Mac OS X since version 10.1 (when compiling OSS software was
near impossible due to Apple decisions) and I've always had better
results with compiling my own than using any of those OSS repositories.
I understand the appeal, it seems easier, but I would recommend that
you compile yourself the software packages you depend on.
Regarding git, I saw a git-build.sh script floating around. If you
cannot find it, you might want to try my own recipe (http://tinyurl.com/4ayze6
). I compile git master every day (cron) and thats the one I use on my
main machine.
Best regards,
--
Pedro Melo
Blog: http://www.simplicidade.org/notes/
XMPP ID: melo@simplicidade.org
Use XMPP!
^ permalink raw reply
* Re: [BUG] git status doesn't handle submodules properly on OSX
From: Pedro Melo @ 2008-10-16 9:49 UTC (permalink / raw)
To: Lars Hoss; +Cc: Richard Bubel, Pieter de Bie, Jeff King, Git Mailinglist
In-Reply-To: <c84d2f2498509bfb916c060317892998.squirrel@webmail.highteq.net>
Hi,
On Oct 15, 2008, at 4:21 PM, Lars Hoss wrote:
> Ok, this might be the difference. I am pretty sure my
> filesystem is not case-sensitive (default?).
> At least "mkdir Foo" fails when "foo" exists.
My filesystem is Mac OS Extended (Journaled) case-insensitive like
yours, and submodules work.
Best regards,
>
>
> Yours,
> Lars
>
>> Hi,
>>
>> On Oct 15, 2008, at 16:51 , Lars Hoss wrote:
>>
>>>> Works for me on Leopard
>>>> [...]
>>>> Vienna:a pieter$ git --version
>>>> git version 1.6.0.2.415.gf9137
>>>
>>> My git version "1.6.0.2" says:
>>>
>>> # On branch master
>>> [...]
>>> git --version
>>> git version 1.6.0.2
>>>
>>> Git was build from macports.
>>
>>
>> works for me too on OS X 10.5.5 with git 1.6.0.2 from MacPorts. As it
>> deviates from the default, it might be worth mentioning that the
>> filesystem in use here is the case-sensitive version of HFS+.
>>
>> Best Regards,
>> Richard
>>
>
>
> --
> To unsubscribe from this list: send the line "unsubscribe git" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
--
Pedro Melo
Blog: http://www.simplicidade.org/notes/
XMPP ID: melo@simplicidade.org
Use XMPP!
^ 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