* [PATCH 1/2] cache-tree: update API to take abitrary flags
From: Nguyễn Thái Ngọc Duy @ 2012-01-11 9:59 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Nguyễn Thái Ngọc Duy
In-Reply-To: <1326261707-11484-1-git-send-email-pclouds@gmail.com>
---
builtin/commit.c | 4 ++--
cache-tree.c | 27 ++++++++++++---------------
cache-tree.h | 4 +++-
merge-recursive.c | 2 +-
test-dump-cache-tree.c | 2 +-
5 files changed, 19 insertions(+), 20 deletions(-)
diff --git a/builtin/commit.c b/builtin/commit.c
index eba1377..bf42bb3 100644
--- a/builtin/commit.c
+++ b/builtin/commit.c
@@ -400,7 +400,7 @@ static char *prepare_index(int argc, const char **argv, const char *prefix,
fd = hold_locked_index(&index_lock, 1);
add_files_to_cache(also ? prefix : NULL, pathspec, 0);
refresh_cache_or_die(refresh_flags);
- update_main_cache_tree(1);
+ update_main_cache_tree(WRITE_TREE_SILENT);
if (write_cache(fd, active_cache, active_nr) ||
close_lock_file(&index_lock))
die(_("unable to write new_index file"));
@@ -421,7 +421,7 @@ static char *prepare_index(int argc, const char **argv, const char *prefix,
fd = hold_locked_index(&index_lock, 1);
refresh_cache_or_die(refresh_flags);
if (active_cache_changed) {
- update_main_cache_tree(1);
+ update_main_cache_tree(WRITE_TREE_SILENT);
if (write_cache(fd, active_cache, active_nr) ||
commit_locked_index(&index_lock))
die(_("unable to write new_index file"));
diff --git a/cache-tree.c b/cache-tree.c
index 8de3959..16355d6 100644
--- a/cache-tree.c
+++ b/cache-tree.c
@@ -150,9 +150,10 @@ void cache_tree_invalidate_path(struct cache_tree *it, const char *path)
}
static int verify_cache(struct cache_entry **cache,
- int entries, int silent)
+ int entries, int flags)
{
int i, funny;
+ int silent = flags & WRITE_TREE_SILENT;
/* Verify that the tree is merged */
funny = 0;
@@ -241,10 +242,11 @@ static int update_one(struct cache_tree *it,
int entries,
const char *base,
int baselen,
- int missing_ok,
- int dryrun)
+ int flags)
{
struct strbuf buffer;
+ int missing_ok = flags & WRITE_TREE_MISSING_OK;
+ int dryrun = flags & WRITE_TREE_DRY_RUN;
int i;
if (0 <= it->entry_count && has_sha1_file(it->sha1))
@@ -288,8 +290,7 @@ static int update_one(struct cache_tree *it,
cache + i, entries - i,
path,
baselen + sublen + 1,
- missing_ok,
- dryrun);
+ flags);
if (subcnt < 0)
return subcnt;
i += subcnt - 1;
@@ -371,15 +372,13 @@ static int update_one(struct cache_tree *it,
int cache_tree_update(struct cache_tree *it,
struct cache_entry **cache,
int entries,
- int missing_ok,
- int dryrun,
- int silent)
+ int flags)
{
int i;
- i = verify_cache(cache, entries, silent);
+ i = verify_cache(cache, entries, flags);
if (i)
return i;
- i = update_one(it, cache, entries, "", 0, missing_ok, dryrun);
+ i = update_one(it, cache, entries, "", 0, flags);
if (i < 0)
return i;
return 0;
@@ -572,11 +571,9 @@ int write_cache_as_tree(unsigned char *sha1, int flags, const char *prefix)
was_valid = cache_tree_fully_valid(active_cache_tree);
if (!was_valid) {
- int missing_ok = flags & WRITE_TREE_MISSING_OK;
-
if (cache_tree_update(active_cache_tree,
active_cache, active_nr,
- missing_ok, 0, 0) < 0)
+ flags) < 0)
return WRITE_TREE_UNMERGED_INDEX;
if (0 <= newfd) {
if (!write_cache(newfd, active_cache, active_nr) &&
@@ -672,10 +669,10 @@ int cache_tree_matches_traversal(struct cache_tree *root,
return 0;
}
-int update_main_cache_tree (int silent)
+int update_main_cache_tree (int flags)
{
if (!the_index.cache_tree)
the_index.cache_tree = cache_tree();
return cache_tree_update(the_index.cache_tree,
- the_index.cache, the_index.cache_nr, 0, 0, silent);
+ the_index.cache, the_index.cache_nr, flags);
}
diff --git a/cache-tree.h b/cache-tree.h
index 0ec0b2a..d8cb2e9 100644
--- a/cache-tree.h
+++ b/cache-tree.h
@@ -29,13 +29,15 @@ void cache_tree_write(struct strbuf *, struct cache_tree *root);
struct cache_tree *cache_tree_read(const char *buffer, unsigned long size);
int cache_tree_fully_valid(struct cache_tree *);
-int cache_tree_update(struct cache_tree *, struct cache_entry **, int, int, int, int);
+int cache_tree_update(struct cache_tree *, struct cache_entry **, int, int);
int update_main_cache_tree(int);
/* bitmasks to write_cache_as_tree flags */
#define WRITE_TREE_MISSING_OK 1
#define WRITE_TREE_IGNORE_CACHE_TREE 2
+#define WRITE_TREE_DRY_RUN 4
+#define WRITE_TREE_SILENT 8
/* error return codes */
#define WRITE_TREE_UNREADABLE_INDEX (-1)
diff --git a/merge-recursive.c b/merge-recursive.c
index d83cd6c..6479a60 100644
--- a/merge-recursive.c
+++ b/merge-recursive.c
@@ -264,7 +264,7 @@ struct tree *write_tree_from_memory(struct merge_options *o)
if (!cache_tree_fully_valid(active_cache_tree) &&
cache_tree_update(active_cache_tree,
- active_cache, active_nr, 0, 0, 0) < 0)
+ active_cache, active_nr, 0) < 0)
die("error building trees");
result = lookup_tree(active_cache_tree->sha1);
diff --git a/test-dump-cache-tree.c b/test-dump-cache-tree.c
index e6c2923..a6ffdf3 100644
--- a/test-dump-cache-tree.c
+++ b/test-dump-cache-tree.c
@@ -59,6 +59,6 @@ int main(int ac, char **av)
struct cache_tree *another = cache_tree();
if (read_cache() < 0)
die("unable to read index file");
- cache_tree_update(another, active_cache, active_nr, 0, 1, 0);
+ cache_tree_update(another, active_cache, active_nr, WRITE_TREE_DRY_RUN);
return dump_cache_tree(active_cache_tree, another, "");
}
--
1.7.3.1.256.g2539c.dirty
^ permalink raw reply related
* [PATCH 2/2] commit: add --skip-intent-to-add to allow commit with i-t-a entries in index
From: Nguyễn Thái Ngọc Duy @ 2012-01-11 9:59 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Nguyễn Thái Ngọc Duy
In-Reply-To: <1326261707-11484-1-git-send-email-pclouds@gmail.com>
---
builtin/commit.c | 10 +++++++---
cache-tree.c | 8 +++++---
cache-tree.h | 1 +
t/t2203-add-intent.sh | 17 +++++++++++++++++
4 files changed, 30 insertions(+), 6 deletions(-)
diff --git a/builtin/commit.c b/builtin/commit.c
index bf42bb3..021206e 100644
--- a/builtin/commit.c
+++ b/builtin/commit.c
@@ -86,6 +86,7 @@ static int all, also, interactive, patch_interactive, only, amend, signoff;
static int edit_flag = -1; /* unspecified */
static int quiet, verbose, no_verify, allow_empty, dry_run, renew_authorship;
static int no_post_rewrite, allow_empty_message;
+static int cache_tree_flags, skip_intent_to_add;
static char *untracked_files_arg, *force_date, *ignore_submodule_arg;
static char *sign_commit;
@@ -170,6 +171,7 @@ static struct option builtin_commit_options[] = {
OPT_BOOLEAN(0, "amend", &amend, "amend previous commit"),
OPT_BOOLEAN(0, "no-post-rewrite", &no_post_rewrite, "bypass post-rewrite hook"),
{ OPTION_STRING, 'u', "untracked-files", &untracked_files_arg, "mode", "show untracked files, optional modes: all, normal, no. (Default: all)", PARSE_OPT_OPTARG, NULL, (intptr_t)"all" },
+ OPT_BOOL(0, "skip-intent-to-add", &skip_intent_to_add, "allow intent-to-add entries in index"),
/* end commit contents options */
{ OPTION_BOOLEAN, 0, "allow-empty", &allow_empty, NULL,
@@ -400,7 +402,7 @@ static char *prepare_index(int argc, const char **argv, const char *prefix,
fd = hold_locked_index(&index_lock, 1);
add_files_to_cache(also ? prefix : NULL, pathspec, 0);
refresh_cache_or_die(refresh_flags);
- update_main_cache_tree(WRITE_TREE_SILENT);
+ update_main_cache_tree(cache_tree_flags | WRITE_TREE_SILENT);
if (write_cache(fd, active_cache, active_nr) ||
close_lock_file(&index_lock))
die(_("unable to write new_index file"));
@@ -421,7 +423,7 @@ static char *prepare_index(int argc, const char **argv, const char *prefix,
fd = hold_locked_index(&index_lock, 1);
refresh_cache_or_die(refresh_flags);
if (active_cache_changed) {
- update_main_cache_tree(WRITE_TREE_SILENT);
+ update_main_cache_tree(cache_tree_flags | WRITE_TREE_SILENT);
if (write_cache(fd, active_cache, active_nr) ||
commit_locked_index(&index_lock))
die(_("unable to write new_index file"));
@@ -870,7 +872,7 @@ static int prepare_to_commit(const char *index_file, const char *prefix,
*/
discard_cache();
read_cache_from(index_file);
- if (update_main_cache_tree(0)) {
+ if (update_main_cache_tree(cache_tree_flags)) {
error(_("Error building trees"));
return 0;
}
@@ -1088,6 +1090,8 @@ static int parse_and_validate_options(int argc, const char *argv[],
cleanup_mode = CLEANUP_ALL;
else
die(_("Invalid cleanup mode %s"), cleanup_arg);
+ if (skip_intent_to_add)
+ cache_tree_flags = WRITE_TREE_INTENT_TO_ADD_OK;
handle_untracked_files_arg(s);
diff --git a/cache-tree.c b/cache-tree.c
index 16355d6..b8593e0 100644
--- a/cache-tree.c
+++ b/cache-tree.c
@@ -159,7 +159,9 @@ static int verify_cache(struct cache_entry **cache,
funny = 0;
for (i = 0; i < entries; i++) {
struct cache_entry *ce = cache[i];
- if (ce_stage(ce) || (ce->ce_flags & CE_INTENT_TO_ADD)) {
+ if (ce_stage(ce) ||
+ ((flags & WRITE_TREE_INTENT_TO_ADD_OK) == 0 &&
+ (ce->ce_flags & CE_INTENT_TO_ADD))) {
if (silent)
return -1;
if (10 < ++funny) {
@@ -339,8 +341,8 @@ static int update_one(struct cache_tree *it,
mode, sha1_to_hex(sha1), entlen+baselen, path);
}
- if (ce->ce_flags & CE_REMOVE)
- continue; /* entry being removed */
+ if (ce->ce_flags & (CE_REMOVE | CE_INTENT_TO_ADD))
+ continue; /* entry being removed or placeholder */
strbuf_grow(&buffer, entlen + 100);
strbuf_addf(&buffer, "%o %.*s%c", mode, entlen, path + baselen, '\0');
diff --git a/cache-tree.h b/cache-tree.h
index d8cb2e9..865733c 100644
--- a/cache-tree.h
+++ b/cache-tree.h
@@ -38,6 +38,7 @@ int update_main_cache_tree(int);
#define WRITE_TREE_IGNORE_CACHE_TREE 2
#define WRITE_TREE_DRY_RUN 4
#define WRITE_TREE_SILENT 8
+#define WRITE_TREE_INTENT_TO_ADD_OK 16
/* error return codes */
#define WRITE_TREE_UNREADABLE_INDEX (-1)
diff --git a/t/t2203-add-intent.sh b/t/t2203-add-intent.sh
index 2543529..990c765 100755
--- a/t/t2203-add-intent.sh
+++ b/t/t2203-add-intent.sh
@@ -44,6 +44,23 @@ test_expect_success 'cannot commit with i-t-a entry' '
test_must_fail git commit -m initial
'
+test_expect_success 'can commit with i-t-a entry' '
+ git reset --hard &&
+ echo xyzzy >rezrov &&
+ echo frotz >nitfol &&
+ git add rezrov &&
+ git add -N nitfol &&
+ git commit --skip-intent-to-add -m initial &&
+ git ls-tree -r HEAD >actual &&
+ cat >expected <<EOF &&
+100644 blob ce013625030ba8dba906f756967f9e9ca394464a elif
+100644 blob ce013625030ba8dba906f756967f9e9ca394464a file
+100644 blob cf7711b63209d0dbc2d030f7fe3513745a9880e4 rezrov
+EOF
+ test_cmp expected actual &&
+ git reset HEAD^
+'
+
test_expect_success 'can commit with an unrelated i-t-a entry in index' '
git reset --hard &&
echo xyzzy >rezrov &&
--
1.7.3.1.256.g2539c.dirty
^ permalink raw reply related
* Re: [PATCH 2/8] revert: decouple sequencer actions from builtin commands
From: Ramkumar Ramachandra @ 2012-01-11 10:11 UTC (permalink / raw)
To: Jonathan Nieder; +Cc: Git List, Junio C Hamano
In-Reply-To: <20120111095236.GB31670@burratino>
Jonathan Nieder wrote:
> Perhaps cherry-pick and revert should be different values for
> replay_subcommand, to avoid conflating the mechanics and the command
> name? Resulting in something like this:
>
> enum replay_subcommand {
> REPLAY_PICK_REVISIONS,
> REPLAY_REVERT_REVISIONS,
> REPLAY_EDIT_SEQUENCE,
> REPLAY_REMOVE_STATE,
> REPLAY_CONTINUE,
> REPLAY_SKIP,
> REPLAY_ROLLBACK
> };
We'd be prematurely locking ourselves into a design where we can't
tell which top-level command issued the continue/ abort -- this means
that there's no way to deny a 'git rebase --continue' from running
after a 'git cherry-pick' conflicts (assuming that rebase is
implemented in terms of the sequencer ofcourse). Even if that
specific objection isn't to your taste, I'm not comfortable about
painting ourselves into such a tight corner so early on. My sincere
suggestion is to procrastinate the problem until we have a tighter
usecase (a new top-level command or action added, for instance). I
don't think we have to worry about preserving backward compatibility
in the sequencer API?
-- Ram
^ permalink raw reply
* Re: [PATCH RFC] commit: allow to commit even if there are intent-to-add entries
From: Jonathan Nieder @ 2012-01-11 11:02 UTC (permalink / raw)
To: Junio C Hamano
Cc: Nguyễn Thái Ngọc Duy, git, Jeff King,
Will Palmer
In-Reply-To: <7vr4z67jbb.fsf@alter.siamese.dyndns.org>
Hi,
Junio C Hamano wrote:
> I have a mild suspicion that in earlier incarnation of the patch we used
> to let empty blobs committed, and then we used to instead not commit
> anything at all for such a path, and the real users were bitten by either
> of these approaches, forgetting to add the contents to the final commit.
I remember the empty blob era. :) I don't think I ever saw something
like this patch, though, and a quick search finds that the first
iteration of the bugfix to stop commiting empty blobs was the one that
was used:
http://thread.gmane.org/gmane.comp.version-control.git/101881/focus=101894
I suspect that at the time, introducing an intent-to-add flag (which
was always the right thing to do) provided enough momentum to avoid
any worries about smaller details like whether to error out or skip
those entries on commit, which could always be changed later (today).
> So I am not sure if this is such a good idea.
My first reaction was the same, but on reflection, I think this is a
good idea as long as the "git status" output in the editor says
something appropriate.
The response Duy mentioned[1] to a report about the unenlightening
message "error building trees" was also memorable:
> When running "commit" and "status" with files marked with "intent to add",
> I think there are three possible interpretations of what the user
> wants to do.
[ (1) thanks for stopping me, I had forgotten about that file;
(2) I changed my mind, please leave that file out; or (3) please
dwim and add the file ]
I think (3) was a trick --- no one that does not use the "-a" option
would want that. :)
At the time, I did not understand what (2) meant. Now I see why ---
in interpretation (2), the user did not change her mind at all. She
said "I will be adding this file at some point, so please keep track
of it along with the others for the sake of commands like 'git diff'
and 'git add -u', but that does not mean "I will be adding this file
at some point _before the next commit_".
So at the time I thought (1) was the only sensible behavior but kept
my mouth shut; and now I see that (1) and (2) both fit into reasonable
workflows.
However. A person using "git diff" to review remaining changes and
"git add" to mark files once they have reached their final form would
benefit even more from a switch for "git commit" to error out if _any_
files in the worktree do not match the index. So if we are to take
this workflow seriously, treating "git add -N" as a special case is
not helping. What we currently provide for this workflow is a
reminder in the status area of changes that were not marked with "git
add".
I suspect no longer erroring out might feel eerie for a period for
people that were relying on "git add -N" as a reminder but that as
long as the "git status" output is sensible enough, Duy's proposed
behavior would end up seeming just as natural.
(2) makes intent-to-add entries just like any other tracked index
entry with some un-added content. It is conceptually pleasant and
fits well in all workflows I can imagine[2].
Hope that helps, and sorry for the ramble,
Jonathan
[1] http://thread.gmane.org/gmane.comp.version-control.git/170651/focus=170658
[2] Ok, that is a small lie. In "git stash", a commit is used to save
the state of the index, so the user would want the presence of the
intent-to-add entry to be stored somehow in the commit, and none of
(1), (2), or (3) will make her happy. Using "git commit" this way is
not going to work when there are unmerged entries, for example,
either, so I think it is okay to ignore that problem here.
^ permalink raw reply
* git diff <file> HEAD^:<file> error message
From: Carlos Martín Nieto @ 2012-01-11 11:18 UTC (permalink / raw)
To: git
[-- Attachment #1: Type: text/plain, Size: 1434 bytes --]
Hello,
I was trying to figure out why running
git diff HEAD^:RelNotes RelNotes
gives the expected output (on maint it tells me that the stable
version changed from 1.7.8.3 to 1.7.8.4) but swapping the arguments
doesn't.
git diff RelNotes HEAD^:RelNotes
doesn't show the opposite patch but tells me that RelNotes doesn't
exist in HEAD^ which is clearly a lie (it sounds like it's a
misunderstanding on git's part, but it's certainly not the truth). In
both cases, verify_filename gets called and tries to stat both
HEAD^:RelNotes and RelNotes. In the "bad" (latter) case, after it
fails to find a file named "HEAD^:RelNotes" it ends up calling
diagnose_invalid_sha1_path which is not correct according to the
command just before the function
/* Must be called only when object_name:filename doesn't exist. */
It looks like get_sha1_with_context_1 gets confused because we pass it
a filename which looks like object_name:filename even though we
earlier parsed it simply as a filename which happens to have a colon
inside it.
Another issue is that I'm not sure that the error message should even
get shown. The documentation tells me that I should be able to compare
two random blobs, though this mode doesn't seem to work if the first
argument is a file. I realise that a file isn't a blob, but since
specifying the arguments the other way around (blob, file) does work,
it looks to me like it should as well.
cmn
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 490 bytes --]
^ permalink raw reply
* Re: [msysGit] [PATCH 2/2] git-cvsexportcommit: Fix calling Perl's rel2abs() on MSYS
From: Pat Thoyts @ 2012-01-11 11:29 UTC (permalink / raw)
To: Sebastian Schuberth; +Cc: msysgit, git
In-Reply-To: <4F0D5486.7020707@gmail.com>
On 11 January 2012 09:21, Sebastian Schuberth <sschuberth@gmail.com> wrote:
> Due to MSYS path mangling GIT_DIR contains a Windows-style path when
> checked inside a Perl script even if GIT_DIR was previously set to an
> MSYS-style path in a shell script. So explicitly convert to an MSYS-style
> path before calling Perl's rel2abs() to make it work.
>
> This fix was inspired by a very similar patch in WebKit:
>
> http://trac.webkit.org/changeset/76255/trunk/Tools/Scripts/commit-log-editor
>
> Signed-off-by: Sebastian Schuberth <sschuberth@gmail.com>
> ---
> git-cvsexportcommit.perl | 7 +++++++
> 1 files changed, 7 insertions(+), 0 deletions(-)
>
> diff --git a/git-cvsexportcommit.perl b/git-cvsexportcommit.perl
> index 39a426e..e6bf252 100755
> --- a/git-cvsexportcommit.perl
> +++ b/git-cvsexportcommit.perl
> @@ -30,6 +30,13 @@ if ($opt_w || $opt_W) {
> chomp($gd);
> $ENV{GIT_DIR} = $gd;
> }
> +
> + # On MSYS, convert a Windows-style path to an MSYS-style path
> + # so that rel2abs() below works correctly.
> + if ($^O eq 'msys') {
> + $ENV{GIT_DIR} =~ s#^([[:alpha:]]):/#/$1/#;
> + }
> +
> # Make sure GIT_DIR is absolute
> $ENV{GIT_DIR} = File::Spec->rel2abs($ENV{GIT_DIR});
> }
> --
> 1.7.9.rc0.5096.g30a61
>
Cool - works for me. I just assumed we didn't support cvsexport.
Tested-by: Pat Thoyts <patthoyts@users.sourceforge.net>
^ permalink raw reply
* [PATCH] archive: re-allow HEAD:Documentation on a remote invocation
From: Carlos Martín Nieto @ 2012-01-11 12:12 UTC (permalink / raw)
To: Jeff King; +Cc: git, Albert Astals Cid
In-Reply-To: <20120110232132.GA29245@sigill.intra.peff.net>
The tightening done in (ee27ca4a: archive: don't let remote clients
get unreachable commits, 2011-11-17) went too far and disallowed
HEAD:Documentation as it would try to find "HEAD:Documentation" as a
ref.
Only DWIM the "HEAD" part to see if it exists as a ref. Once we're
sure that we've been given a valid ref, we follow the normal code
path. This still disallows attempts to access commits which are not
branch tips.
Signed-off-by: Carlos Martín Nieto <cmn@elego.de>
---
AFAICT this should still be safe. Using HEAD^:Documentation or
<sha1>:Documentation still complains that HEAD^ and <sha1> aren't
refs.
archive.c | 19 +++++++++++++------
1 files changed, 13 insertions(+), 6 deletions(-)
diff --git a/archive.c b/archive.c
index 164bbd0..4735bfb 100644
--- a/archive.c
+++ b/archive.c
@@ -260,14 +260,21 @@ static void parse_treeish_arg(const char **argv,
/* Remotes are only allowed to fetch actual refs */
if (remote) {
char *ref = NULL;
- if (!dwim_ref(name, strlen(name), sha1, &ref))
- die("no such ref: %s", name);
+ const char *refname, *colon = NULL;
+
+ colon = strchr(name, ':');
+ if (colon)
+ refname = xstrndup(name, colon - name);
+ else
+ refname = name;
+
+ if (!dwim_ref(refname, strlen(refname), sha1, &ref))
+ die("no such ref: %s", refname);
free(ref);
}
- else {
- if (get_sha1(name, sha1))
- die("Not a valid object name");
- }
+
+ if (get_sha1(name, sha1))
+ die("Not a valid object name");
commit = lookup_commit_reference_gently(sha1, 1);
if (commit) {
--
1.7.8.352.g876a6f
^ permalink raw reply related
* Re: [PATCH 3/3] diff-index: pass pathspec down to unpack-trees machinery
From: Nguyen Thai Ngoc Duy @ 2012-01-11 12:33 UTC (permalink / raw)
To: Jonathan Nieder; +Cc: Junio C Hamano, git, Linus Torvalds
In-Reply-To: <20120111063104.GA3153@burratino>
On Wed, Jan 11, 2012 at 1:31 PM, Jonathan Nieder <jrnieder@gmail.com> wrote:
> Check this out:
>
> mkdir -p test-repo/subdir
> cd test-repo
> git init
> echo hi >subdir/hello.h
> git add subdir/hello.h
> git commit -m 'say hi'
> git diff-index --abbrev HEAD -- '*.h'
This seems to fix this.
diff --git a/unpack-trees.c b/unpack-trees.c
index 7c9ecf6..5cf58b6 100644
--- a/unpack-trees.c
+++ b/unpack-trees.c
@@ -1042,6 +1042,7 @@ int unpack_trees(unsigned len, struct tree_desc
*t, struct unpack_trees_options
info.data = o;
info.show_all_errors = o->show_all_errors;
info.pathspec = o->pathspec;
+ info.pathspec->recursive = 1;
if (o->prefix) {
/*
Still scratching my head why this flag is zero by default, which would
affect all other places.. Or perhaps the right fix would be this
instead
diff --git a/tree-walk.c b/tree-walk.c
index f82dba6..0345938 100644
--- a/tree-walk.c
+++ b/tree-walk.c
@@ -634,7 +634,7 @@ enum interesting tree_entry_interesting(const
struct name_entry *entry,
* Match all directories. We'll try to
* match files later on.
*/
- if (ps->recursive && S_ISDIR(entry->mode))
+ if (S_ISDIR(entry->mode))
return entry_interesting;
}
@@ -662,7 +662,7 @@ match_wildcards:
* Match all directories. We'll try to match files
* later on.
*/
- if (ps->recursive && S_ISDIR(entry->mode))
+ if (S_ISDIR(entry->mode))
return entry_interesting;
}
return never_interesting; /* No matches */
--
Duy
^ permalink raw reply related
* Re: [PATCH 4/8] revert: separate out parse errors logically
From: Ramkumar Ramachandra @ 2012-01-11 12:38 UTC (permalink / raw)
To: Jonathan Nieder; +Cc: Git List, Junio C Hamano
In-Reply-To: <20120110190311.GD22184@burratino>
New commit message.
revert: simplify insn parsing logic
Our instruction sheet parser first looks for a valid action by
checking that the buffer starts with either "pick" or "revert". Then,
it looks for either spaces or tabs before looking for the object name,
erroring out if it doesn't find any. Simplify this logic without
making any functional changes by looking for ("pick " or "pick\t") or
("revert " or "revert\t") in the first place.
-- Ram
^ permalink raw reply
* Re: [PATCH 5/8] revert: report fine-grained errors from insn parser
From: Jonathan Nieder @ 2012-01-11 12:44 UTC (permalink / raw)
To: Ramkumar Ramachandra; +Cc: Git List, Junio C Hamano
In-Reply-To: <1326212039-13806-6-git-send-email-artagnon@gmail.com>
Ramkumar Ramachandra wrote:
> --- a/builtin/revert.c
> +++ b/builtin/revert.c
> @@ -732,7 +732,22 @@ static int format_todo(struct strbuf *buf, struct replay_insn_list *todo_list)
> return 0;
> }
>
> -static int parse_insn_line(char *bol, char *eol, struct replay_insn_list *item)
> +static int parse_error(const char *message, const char *file,
> + int lineno, char *error_line)
> +{
> + const char *suffix = "";
> + int error_len = strcspn(error_line, " \t\n");
> +
> + if (error_len > 20) {
> + error_len = 20;
> + suffix = "...";
> + }
> + return error(_("%s:%d: %s: %.*s%s"), file, lineno, message,
> + error_len, error_line, suffix);
Since the snippet used in an error message is a single word,
why is it called error_line? (And why is the signature written
in a way that implies we might modify it, by the way?)
Missing /* TRANSLATORS: ... */ comment.
[...]
> @@ -757,11 +773,13 @@ static int parse_insn_line(char *bol, char *eol, struct replay_insn_list *item)
> *end_of_object_name = saved;
>
> if (status < 0)
> - return -1;
> + return parse_error(_("malformed object name"),
> + git_path(SEQ_TODO_FILE), lineno, bol);
This is the message I'll get if I misspell "master" as "mister" or try
to cherry-pick HEAD~100000 when the history is not that deep. When I
read "malformed object name", I'll look for syntax errors and be
confused. (They are valid syntax denoting commits that just happen
not to exist.)
^ permalink raw reply
* Re: [PATCH 3/3] diff-index: pass pathspec down to unpack-trees machinery
From: Nguyen Thai Ngoc Duy @ 2012-01-11 12:47 UTC (permalink / raw)
To: Jonathan Nieder; +Cc: Junio C Hamano, git, Linus Torvalds
In-Reply-To: <CACsJy8D7EnOebAxBYF8ua7htu-81nKY=ghUMgg=JOe4Fc1uigQ@mail.gmail.com>
On Wed, Jan 11, 2012 at 7:33 PM, Nguyen Thai Ngoc Duy <pclouds@gmail.com> wrote:
> Still scratching my head why this flag is zero by default, which would
> affect all other places.. Or perhaps the right fix would be this
> instead
Yep, it seems the right one. recursive flag is introduced to
enable/disable max_depth feature, which is only used by grep, so we
want this feature to be off by default. max_depth == 0 has special
meaning, and we do not want another any other kind of initialization
but memset(), so "recursive" functions as the feature switch.
The code portions below deal with the case where we have tried and
failed prefix matching. Because this is wildcard, we don't know if
anything in the given directory may match or not, so we match all
directories, then filter unmatched files out at the end. This has
nothing to do with "recursive" flag as the max_depth switch.
Will think about it and test some more tomorrow when my mind is in better state.
> diff --git a/tree-walk.c b/tree-walk.c
> index f82dba6..0345938 100644
> --- a/tree-walk.c
> +++ b/tree-walk.c
> @@ -634,7 +634,7 @@ enum interesting tree_entry_interesting(const
> struct name_entry *entry,
> * Match all directories. We'll try to
> * match files later on.
> */
> - if (ps->recursive && S_ISDIR(entry->mode))
> + if (S_ISDIR(entry->mode))
> return entry_interesting;
> }
>
> @@ -662,7 +662,7 @@ match_wildcards:
> * Match all directories. We'll try to match files
> * later on.
> */
> - if (ps->recursive && S_ISDIR(entry->mode))
> + if (S_ISDIR(entry->mode))
> return entry_interesting;
> }
> return never_interesting; /* No matches */
--
Duy
^ permalink raw reply
* Re: [BUG] git archive broken in 1.7.8.1
From: Carlos Martín Nieto @ 2012-01-11 12:51 UTC (permalink / raw)
To: git
In-Reply-To: <20120110230122.GA24020@vent.lifeintegrity.localnet>
[-- Attachment #1: Type: text/plain, Size: 937 bytes --]
On Tue, Jan 10, 2012 at 06:01:22PM -0500, Allan Wind wrote:
> On 2012-01-10 23:05:45, Albert Astals Cid wrote:
> > Unfortunately this producess a tarball with a different layout, e.g.
> >
> > git archive --remote=git://anongit.kde.org/kgraphviewer.git HEAD:doc/en_US
> > gives me a tarball with the doc/en_US files in the root
>
> Meaning the files you have stored in git under doc/en_US are
> dumped in the root directory of the tar? That does not sound
> like desired behavior for the feature.
Which feature do you mean? Using HEAD:doc/en_US should be equivalent
to running `tar cf - .` from inside the doc/en_US, as what you're
passing is that tree.
Using HEAD -- doc/en_US however means that you want to pack HEAD, but
limit it to files that match doc/en_US, so it's working as
designed. If you mean that 'HEAD -- doc/en_US' shouldn't give you a
tar with those files at the root, then we agree.
cmn
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 490 bytes --]
^ permalink raw reply
* Re: git svn can't handle giant commit
From: Carlos Martín Nieto @ 2012-01-11 13:07 UTC (permalink / raw)
To: fREW Schmidt; +Cc: Git List
In-Reply-To: <CADVrmKRySXFAAi5WgpgSrephbsY7JLBECF+c9ZX=_KnRxn3Lzg@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 729 bytes --]
On Mon, Dec 19, 2011 at 09:28:04AM -0600, fREW Schmidt wrote:
> Hey guys,
>
> I'm working on an import of some repos and I discovered that I can't
> import a certain commit due to it's size. This is the commit:
>
> http://perlcritic.tigris.org/source/browse/perlcritic?view=rev&revision=2676
>
> Clearly it's large :-)
>
> Anyway, here's the error message I get:
>
> Svndiff data contains invalid instruction: Invalid diff stream:
> [new] insn 4 overflows the new data section at
> /opt/libexec/git-core/git-svn line 5653
What version of git are you using? I can't find any of those error
messages in the git repo, and it looks like it's the svn library that
is creating the error message.
cmn
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 490 bytes --]
^ permalink raw reply
* Re: [PATCH 2/8] revert: decouple sequencer actions from builtin commands
From: Jonathan Nieder @ 2012-01-11 13:18 UTC (permalink / raw)
To: Ramkumar Ramachandra; +Cc: Git List, Junio C Hamano
In-Reply-To: <CALkWK0kJpEXvBMV=D7h91sz7U2sLvXdW1UzomW0kG2bbM+byYA@mail.gmail.com>
Ramkumar Ramachandra wrote:
> Once the
> painful move to sequencer.c is completed, we can think about all these
> things.
Honestly, moving code verbatim between files is very easy. Repeatedly
rebasing a patch that carries out such a move would presumably be
hard, though. But this pain is unnecessary!
Just like I haven't been reviewing the code movement, I'd be perfectly
happy to read a "patch" that says
"And then we move the functions from the following list to
sequencer.c. I'll send a patch doing so once work has settled
down in patches earlier in this series."
Now you are telling me that in the super-final future my worries are
valid, but I should forget about them today, because later in this
series there is some code movement. That we need to get this painful
part over with. I would be much more comforted if you said that in
the future my worries were _not_ valid, that the current design is a
good one, and that these patches are not making the program worse;
otherwise, wouldn't it be better to skip whichever are the
questionable patches and just carry out the code movement, which
doesn't depend on them?
^ permalink raw reply
* Re: rsync a *bunch* of git repos
From: Sergio @ 2012-01-11 13:22 UTC (permalink / raw)
To: git
In-Reply-To: <7v39bn9onl.fsf@alter.siamese.dyndns.org>
Junio C Hamano <gitster <at> pobox.com> writes:
>
> "Philip Oakley" <philipoakley <at> iee.org> writes:
>
> > I think there is an exception for certain git submodule setups with
> > local repos, where the gitdir link is hard coded to the absolute
> > machine path. There has been some discussion on the list recently
> > about trying to cover this case.
>
> But if you read the original post carefully, all repositories involved are
> under /home before the transition, and they will move to the exact same
> place under /home anyway, so I do not think the discussion you have in
> mind would apply to this case.
>
> The only thing that is needed after the move would be to run
>
> git update-index --refresh
>
> in all of the repositories, I think.
>
>
I keep a desktop and a laptop in sync with unison (which uses rsync) and I
confirm that git is entirely happy about that.
the git update-index --refresh is necessary, otherwise git status will
incorrectly report dirty trees.
I wonder if it would not make sense to incorporate the update-index --refresh in
the git status command.
As an aside: git works fine when repos are transferred with rsync, but git packs
are not rsync friendly nor friendly with backup strategies using binary deltas.
^ permalink raw reply
* Re: [PATCH 2/8] revert: decouple sequencer actions from builtin commands
From: Jonathan Nieder @ 2012-01-11 13:40 UTC (permalink / raw)
To: Ramkumar Ramachandra; +Cc: Git List, Junio C Hamano
In-Reply-To: <CALkWK0mv2jzmDA==pJg5R4jH0yxo=OopYM_WzAWusiffnb+4HQ@mail.gmail.com>
Ramkumar Ramachandra wrote:
> We'd be prematurely locking ourselves into a design where we can't
> tell which top-level command issued the continue/ abort
The .git/sequencer/todo file already doesn't record which top-level
command initiated the sequence and doesn't seem to operate under a
model in which that is a useful question. Honestly, that's my only
objection to the "git revert --continue during git cherry-pick" check.
I think it is not premature to think about whether that matters. I've
already said a little about related cases where it seemed to matter
but there was instead something else at play. Can you offer some
examples of how people might use the "git cherry-pick" / "git revert"
commands and get stuck or run into trouble, and how git can help them?
[...]
> My sincere
> suggestion is to procrastinate the problem until we have a tighter
> usecase (a new top-level command or action added, for instance).
Thinking carefully about sequencer use cases also seems like a good
idea. Is it intended that "git am" and "git rebase" should be
reimplemented on top of the sequencer? Do you have goals in mind for
commands like "git sequence --step" that could be used to examine,
influence, and carry out git's idea of what should happen next?
If we have no use case, then there's no reason to change the code. It
already works[*] for cherry-pick and revert. I think we shouldn't be
moving this code to sequencer.c or cleaning up the API to suit other
commands (e.g., introducing two ways to sane "am I picking or
reverting") without having one in mind.
[*] Modulo bugs and some missing features such as --skip.
^ permalink raw reply
* Re: git svn dcommit sends to wrong branch
From: Victor Engmark @ 2012-01-11 14:05 UTC (permalink / raw)
To: git
In-Reply-To: <20120110161843.GC8196@victor>
This message was never delivered and no error message ever came back; is
there some weird filtering going on?
On Tue, Jan 10, 2012 at 05:18:43PM +0100, Victor Engmark wrote:
> Commands:
>
> git svn clone -s -r 1:HEAD http://svn/repo
> cd repo
> git commit [thrice, in master only]
> git rebase --interactive HEAD~20 [i.e., started rebase in commits before
> the clone]
> [Merged two commits I had made *after* the clone]
> git commit ...
> git dcommit
>
> This created commits on
> <http://svn/repo/branches/branch_name>! Why? Is it because HEAD~20's
> git-svn-id <http://svn/repo/branches/branch_name@22481> is on that
> branch?
>
> And more importantly, how do I "replay" my commits on trunk?
Cheers,
V
--
terreActive AG
Kasinostrasse 30
CH-5001 Aarau
Tel: +41 62 834 00 55
Fax: +41 62 823 93 56
www.terreactive.ch
Wir sichern Ihren Erfolg - seit 15 Jahren
^ permalink raw reply
* Re: git svn dcommit sends to wrong branch
From: Thomas Rast @ 2012-01-11 15:31 UTC (permalink / raw)
To: git; +Cc: Victor Engmark
In-Reply-To: <20120111140513.GA12633@victor>
Victor Engmark <victor.engmark@terreactive.ch> writes:
> This message was never delivered and no error message ever came back; is
> there some weird filtering going on?
It was delivered, see e.g.
http://thread.gmane.org/gmane.comp.version-control.git/188265
However, my reply ended up not having a Cc to you because your
Mail-Followup-To header fooled Gnus into believing you didn't want that
to happen. Please do not set this header; we Cc everyone involved in
discussions so far, and MFT makes it that much less convenient to
achieve that.
Since you are apparently not subscribed (otherwise you should have
received my reply), please find a cut&paste of the original reply below.
---- 8< ----
Victor Engmark <victor.engmark@terreactive.ch> writes:
> Commands:
>
> git svn clone -s -r 1:HEAD http://svn/repo
> cd repo
> git commit [thrice, in master only]
Which git version is this? Before 1.6.5 (b186a261 to be precise)
git-svn pointed master at the branch where the last commit in SVN
happened, which is not necessarily trunk. After that it tries to point
it at trunk instead. You can find out, e.g., by saying 'git show' on
the fresh clone and looking at the git-svn-id line.
> git rebase --interactive HEAD~20 [i.e., started rebase in commits before
> the clone]
> [Merged two commits I had made *after* the clone]
> git commit ...
> git dcommit
>
> This created commits on
> <http://svn/repo/branches/branch_name>! Why? Is it because HEAD~20's
> git-svn-id <http://svn/repo/branches/branch_name@22481> is on that
> branch?
The rule is that the commits go to the branch named in the git-svn-id
line of the most recent first-parent ancestor of HEAD.
You can find the "base" commit in question with
git log -1 --first-parent --grep=^git-svn-id:
> And more importantly, how do I "replay" my commits on trunk?
You need to rebase the commits on trunk, and (very important) strip the
git-svn-id lines from their messages. If you only had a handful of
commits, your best bet is to use something like
git checkout -b newbranch
git rebase -i --onto svn/trunk svn/branch_name # or whatever git-svn named the remote branches
# edit all the 'pick' into 'reword'
# in every commit message editor that pops up, remove the git-svn-id line
gitk # make sure that you like the resulting history!
git svn dcommit
(If you have many commits, git-filter-branch can do the removal
automatically, but it's a bit of a loaded gun pointed at your foot.)
If your git-rebase is too old for 'reword', you can use 'edit' instead
and then, every time that git-rebase drops you into a command line, say
git commit --amend # and edit the commit message
git rebase --continue
--
Thomas Rast
trast@{inf,student}.ethz.ch
^ permalink raw reply
* Re: Re* Regulator updates for 3.3
From: Phil Hord @ 2012-01-11 16:14 UTC (permalink / raw)
To: Junio C Hamano
Cc: Linus Torvalds, Mark Brown, Liam Girdwood, Git Mailing List
In-Reply-To: <7vzkdu7miv.fsf@alter.siamese.dyndns.org>
On Wed, Jan 11, 2012 at 1:59 AM, Junio C Hamano <gitster@pobox.com> wrote:
[...]
>
> With that caveat, the patch should look like this.
>
> -- >8 --
> Subject: [PATCH] merge: use editor by default in interactive sessions
>
> Traditionally, a cleanly resolved merge was committed by "git merge" using
> the auto-generated merge commit log message with invoking the editor.
>
> After 5 years of use in the field, it turns out that many people perform
> too many unjustified backmerges of the upstream history into their topic
> branches. These merges are not just useless, but they are more often than
> not explained and making the end result unreadable when it gets time for
> merging their history back to their upstream.
Typo, I think. I believe you meant "they are more often than not not
explained", but as this is unclear, maybe you can use "they are
usually not explained" or "they more often than not go in without
explanation".
P
^ permalink raw reply
* Re: Re* Regulator updates for 3.3
From: Linus Torvalds @ 2012-01-11 16:23 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Mark Brown, Liam Girdwood, linux-kernel, Git Mailing List
In-Reply-To: <7vzkdu7miv.fsf@alter.siamese.dyndns.org>
On Tue, Jan 10, 2012 at 10:59 PM, Junio C Hamano <gitster@pobox.com> wrote:
>
> What makes me uneasy about the idea of running the editor by default is
> that many people still use Git as a better CVS/SVN. Their workflow is to
> build randomly on their 'master', attempt to push and get rejected, pull
> only so that they can push out, and then push the merge result out.
Sure. And I don't think we can do much about it. They'll either set
the legacy flag, or they'll just exit the editor without adding
anything useful (if you come from a CVS background in particular, you
probably never learnt to do good commit logs anyway).
So it will be a bit more work for the bad workflow, I agree - although
if it really irritates people, they can just set that GIT_MERGE_LEGACY
in their .bashrc files or something. But we can *hope* that even those
people might sometimes actually talk about what/why they are doing
things, or maybe even learn about that whole "distributed" thing.
I agree that is unlikely to ever happen, though. It's more likely that
they will change their aliases so that their "update" command just
adds the --no-edit flag. Regardless, it doesn't sound *too* onerous to
work around.
Patch looks good to me. I would personally have compared "st_mode"
instead of (or in addition to) "st_rdev", but I don't think it matters
all that much.
Linus
^ permalink raw reply
* Re: [PATCH 2/8] revert: decouple sequencer actions from builtin commands
From: Ramkumar Ramachandra @ 2012-01-11 16:39 UTC (permalink / raw)
To: Jonathan Nieder; +Cc: Git List, Junio C Hamano
In-Reply-To: <20120111131854.GG32173@burratino>
Jonathan Nieder wrote:
> Honestly, moving code verbatim between files is very easy. Repeatedly
> rebasing a patch that carries out such a move would presumably be
> hard, though. But this pain is unnecessary!
>
> Just like I haven't been reviewing the code movement, I'd be perfectly
> happy to read a "patch" that says
>
> "And then we move the functions from the following list to
> sequencer.c. I'll send a patch doing so once work has settled
> down in patches earlier in this series."
More than the pain of rebasing the patch everytime, I guess what I'm
asking is: is it worth stretching my foresight like this? Once the
code is in sequencer.c, it just becomes so much easier for me to write
scratch code to help me wrap my head around the generalization. If
the answer to the question is yes, I suppose it makes sense to submit
the good parts now and work on the other parts over an extended period
of time.
-- Ram
^ permalink raw reply
* Re: [PATCH 2/8] revert: decouple sequencer actions from builtin commands
From: Jonathan Nieder @ 2012-01-11 16:47 UTC (permalink / raw)
To: Ramkumar Ramachandra; +Cc: Git List, Junio C Hamano
In-Reply-To: <CALkWK0=gvsvqk7Th7YY_eRzb+Ri52AZbOVokC98i9BXVAJOZEw@mail.gmail.com>
Ramkumar Ramachandra wrote:
> More than the pain of rebasing the patch everytime, I guess what I'm
> asking is: is it worth stretching my foresight like this? Once the
> code is in sequencer.c, it just becomes so much easier for me to write
> scratch code to help me wrap my head around the generalization.
In that case, why not just a patch to move the code to sequencer.c,
with whatever is the minimum of related fixes (just namespace stuff,
I'd imagine) before it?
^ permalink raw reply
* Re: rsync a *bunch* of git repos
From: Neal Kreitzinger @ 2012-01-11 16:52 UTC (permalink / raw)
To: Sergio; +Cc: git
In-Reply-To: <loom.20120111T141805-791@post.gmane.org>
On 1/11/2012 7:22 AM, Sergio wrote:
>
> As an aside: git works fine when repos are transferred with rsync, but git packs
> are not rsync friendly nor friendly with backup strategies using binary deltas.
>
All these answers are assuming that your source git repos are quiet
during the rsync. If they are not quiet during the rsync then you are
going to need a more tailored rsync to do things in a certain order.
See this thread for details:
http://thread.gmane.org/gmane.comp.version-control.git/168699
v/r,
neal
^ permalink raw reply
* Re: [PATCH 2/8] revert: decouple sequencer actions from builtin commands
From: Ramkumar Ramachandra @ 2012-01-11 16:52 UTC (permalink / raw)
To: Jonathan Nieder; +Cc: Git List, Junio C Hamano
In-Reply-To: <20120111164758.GD1891@burratino>
Jonathan Nieder wrote:
> In that case, why not just a patch to move the code to sequencer.c,
> with whatever is the minimum of related fixes (just namespace stuff,
> I'd imagine) before it?
Cool, I'll do that then. I thought what I'd originally posted was an
acceptable minimum to show the motivation for the move.
-- Ram
^ permalink raw reply
* why git-svn dcommit recreates master branch?
From: Pawel Sikora @ 2012-01-11 16:27 UTC (permalink / raw)
To: git
[-- Attachment #1: Type: text/plain, Size: 1218 bytes --]
Hi,
i'm wondering why the git-svn-dcommit recreates a master branch in my repo.
is it a bug or feature and master is required to cooperate with subversion?
please look at attached test.sh:
$ ./test.sh
Checked out revision 0.
A file.txt
Adding file.txt
Transmitting file data .
Committed revision 1.
Initialized empty Git repository in /home/users/pawels/bugs/git-svn-master-issue/repo.git/.git/
A file.txt
r1 = 464dbae76d675c8c4bdc715e34ebe46691b8bfa2 (refs/remotes/git-svn)
Checked out HEAD:
file:///home/users/pawels/bugs/git-svn-master-issue/repo.svn r1
branches before dcommit:
* bridge
remotes/git-svn
[bridge ffffc26] bar
1 files changed, 1 insertions(+), 0 deletions(-)
Committing to file:///home/users/pawels/bugs/git-svn-master-issue/repo.svn ...
M file.txt
Committed r2
M file.txt
r2 = d98723bccdcf673790b55d47a4f345c694a68ced (refs/remotes/git-svn)
No changes between current HEAD and refs/remotes/git-svn
Resetting to the latest refs/remotes/git-svn
branches after dcommit:
* bridge
master
remotes/git-svn
could some one put some light on this?
BR,
Paweł.
please CC me on reply.
[-- Attachment #2: test.sh --]
[-- Type: application/x-shellscript, Size: 489 bytes --]
^ 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