* Re: [PATCH 3/5] check-ref-format: Abolish leak of collapsed refname
From: Michael Haggerty @ 2016-12-19 11:09 UTC (permalink / raw)
To: Ian Jackson, git
In-Reply-To: <20161104191358.28812-4-ijackson@chiark.greenend.org.uk>
On 11/04/2016 08:13 PM, Ian Jackson wrote:
> collapse_slashes always returns a value from xmallocz.
>
> Right now this leak is not very interesting, since we only call
> check_one_ref_format once.
>
> Signed-off-by: Ian Jackson <ijackson@chiark.greenend.org.uk>
> ---
> builtin/check-ref-format.c | 4 +++-
> 1 file changed, 3 insertions(+), 1 deletion(-)
>
> diff --git a/builtin/check-ref-format.c b/builtin/check-ref-format.c
> index f12c19c..020ebe8 100644
> --- a/builtin/check-ref-format.c
> +++ b/builtin/check-ref-format.c
> @@ -63,8 +63,10 @@ static int check_one_ref_format(const char *refname)
> : check_refname_format(refname, flags);
> if (got)
> return 1;
If the function returns via the line above, then the memory will still
be leaked.
> - if (normalize)
> + if (normalize) {
> printf("%s\n", refname);
> + free((void*)refname);
> + }
> }
>
> int cmd_check_ref_format(int argc, const char **argv, const char *prefix)
>
Michael
^ permalink raw reply
* Re: [PATCH 2/5] check-ref-format: Refactor to make --branch code more common
From: Michael Haggerty @ 2016-12-19 11:07 UTC (permalink / raw)
To: Ian Jackson, git
In-Reply-To: <20161104191358.28812-3-ijackson@chiark.greenend.org.uk>
On 11/04/2016 08:13 PM, Ian Jackson wrote:
> We are going to want to permit other options with --branch.
>
> So, replace the special case with just an entry for --branch in the
> parser for ordinary options, and check for option compatibility at the
> end.
>
> No overall functional change.
>
> Signed-off-by: Ian Jackson <ijackson@chiark.greenend.org.uk>
> ---
> builtin/check-ref-format.c | 17 +++++++++++++----
> 1 file changed, 13 insertions(+), 4 deletions(-)
>
> diff --git a/builtin/check-ref-format.c b/builtin/check-ref-format.c
> index 4d56caa..f12c19c 100644
> --- a/builtin/check-ref-format.c
> +++ b/builtin/check-ref-format.c
> @@ -49,13 +49,19 @@ static int check_ref_format_branch(const char *arg)
> }
>
> static int normalize = 0;
> +static int check_branch = 0;
> static int flags = 0;
>
> static int check_one_ref_format(const char *refname)
> {
> + int got;
`got` is an unusual name for this variable, and I don't really
understand what the word means in this context. Is there a reason not to
use the more usual `err`?
> +
> if (normalize)
> refname = collapse_slashes(refname);
> - if (check_refname_format(refname, flags))
> + got = check_branch
> + ? check_ref_format_branch(refname)
> + : check_refname_format(refname, flags);
> + if (got)
> return 1;
> if (normalize)
> printf("%s\n", refname);
> @@ -68,9 +74,6 @@ int cmd_check_ref_format(int argc, const char **argv, const char *prefix)
> if (argc == 2 && !strcmp(argv[1], "-h"))
> usage(builtin_check_ref_format_usage);
>
> - if (argc == 3 && !strcmp(argv[1], "--branch"))
> - return check_ref_format_branch(argv[2]);
> -
> for (i = 1; i < argc && argv[i][0] == '-'; i++) {
> if (!strcmp(argv[i], "--normalize") || !strcmp(argv[i], "--print"))
> normalize = 1;
> @@ -80,9 +83,15 @@ int cmd_check_ref_format(int argc, const char **argv, const char *prefix)
> flags &= ~REFNAME_ALLOW_ONELEVEL;
> else if (!strcmp(argv[i], "--refspec-pattern"))
> flags |= REFNAME_REFSPEC_PATTERN;
> + else if (!strcmp(argv[i], "--branch"))
> + check_branch = 1;
> else
> usage(builtin_check_ref_format_usage);
> }
> +
> + if (check_branch && (flags || normalize))
Is there a reason not to allow `--normalize` with `--branch`?
(Currently, `git check-ref-format --branch` *does* allow input like
`refs/heads/foo`.)
But note that simply allowing `--branch --normalize` without changing
`check_one_ref_format()` would mean generating *two* lines of output per
reference, so something else would have to change, too.
> + usage(builtin_check_ref_format_usage);
> +
> if (! (i == argc - 1))
> usage(builtin_check_ref_format_usage);
>
>
Michael
^ permalink raw reply
* [PATCH] config.c: handle error case for fstat() calls
From: Nguyễn Thái Ngọc Duy @ 2016-12-19 9:21 UTC (permalink / raw)
To: git; +Cc: Junio C Hamano, josharian, Nguyễn Thái Ngọc Duy
In-Reply-To: <CAFAcib_cY8FeLFkW1=MfR+P7xoupGK9DFegNY5boExHSRppAmg@mail.gmail.com>
Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com>
---
Will this fix the problem I'm replying to? I don't know. I found this
while checking the code and it should be fixed regardless.
config.c | 12 ++++++++++--
1 file changed, 10 insertions(+), 2 deletions(-)
diff --git a/config.c b/config.c
index 83fdecb..4973256 100644
--- a/config.c
+++ b/config.c
@@ -2194,7 +2194,12 @@ int git_config_set_multivar_in_file_gently(const char *config_filename,
goto out_free;
}
- fstat(in_fd, &st);
+ if (fstat(in_fd, &st) == -1) {
+ error_errno(_("fstat on %s failed"), config_filename);
+ ret = CONFIG_INVALID_FILE;
+ goto out_free;
+ }
+
contents_sz = xsize_t(st.st_size);
contents = xmmap_gently(NULL, contents_sz, PROT_READ,
MAP_PRIVATE, in_fd, 0);
@@ -2414,7 +2419,10 @@ int git_config_rename_section_in_file(const char *config_filename,
goto unlock_and_out;
}
- fstat(fileno(config_file), &st);
+ if (fstat(fileno(config_file), &st) == -1) {
+ ret = error_errno(_("fstat on %s failed"), config_filename);
+ goto out;
+ }
if (chmod(get_lock_file_path(lock), st.st_mode & 07777) < 0) {
ret = error_errno("chmod on %s failed",
--
2.8.2.524.g6ff3d78
^ permalink raw reply related
* Re: [PATCH 1/5] check-ref-format: Refactor out check_one_ref_format
From: Michael Haggerty @ 2016-12-19 8:27 UTC (permalink / raw)
To: Ian Jackson, git
In-Reply-To: <20161104191358.28812-2-ijackson@chiark.greenend.org.uk>
On 11/04/2016 08:13 PM, Ian Jackson wrote:
> We are going to want to reuse this. No functional change right now.
>
> It currently has a hidden memory leak if --normalize is used.
>
> Signed-off-by: Ian Jackson <ijackson@chiark.greenend.org.uk>
> ---
> builtin/check-ref-format.c | 26 ++++++++++++++------------
> 1 file changed, 14 insertions(+), 12 deletions(-)
>
> diff --git a/builtin/check-ref-format.c b/builtin/check-ref-format.c
> index eac4994..4d56caa 100644
> --- a/builtin/check-ref-format.c
> +++ b/builtin/check-ref-format.c
> @@ -48,12 +48,22 @@ static int check_ref_format_branch(const char *arg)
> return 0;
> }
>
> +static int normalize = 0;
> +static int flags = 0;
> +
> +static int check_one_ref_format(const char *refname)
> +{
> + if (normalize)
> + refname = collapse_slashes(refname);
> + if (check_refname_format(refname, flags))
> + return 1;
> + if (normalize)
> + printf("%s\n", refname);
This function needs to `return 0` if it gets to the end.
> +}
> +
> int cmd_check_ref_format(int argc, const char **argv, const char *prefix)
> {
> int i;
> - int normalize = 0;
> - int flags = 0;
> - const char *refname;
>
> if (argc == 2 && !strcmp(argv[1], "-h"))
> usage(builtin_check_ref_format_usage);
> @@ -76,13 +86,5 @@ int cmd_check_ref_format(int argc, const char **argv, const char *prefix)
> if (! (i == argc - 1))
> usage(builtin_check_ref_format_usage);
>
> - refname = argv[i];
> - if (normalize)
> - refname = collapse_slashes(refname);
> - if (check_refname_format(refname, flags))
> - return 1;
> - if (normalize)
> - printf("%s\n", refname);
> -
> - return 0;
> + return check_one_ref_format(argv[i]);
> }
>
Michael
^ permalink raw reply
* Re: [PATCHv8 6/6] submodule: add absorb-git-dir function
From: Duy Nguyen @ 2016-12-19 5:35 UTC (permalink / raw)
To: Stefan Beller; +Cc: gitster, git, bmwill
In-Reply-To: <20161212190435.10358-7-sbeller@google.com>
On Mon, Dec 12, 2016 at 11:04:35AM -0800, Stefan Beller wrote:
> diff --git a/dir.c b/dir.c
> index e0efd3c2c3..d872cc1570 100644
> --- a/dir.c
> +++ b/dir.c
> @@ -2773,3 +2773,15 @@ void connect_work_tree_and_git_dir(const char *work_tree_, const char *git_dir_)
> free(work_tree);
> free(git_dir);
> }
> +
> +/*
> + * Migrate the git directory of the given path from old_git_dir to new_git_dir.
> + */
> +void relocate_gitdir(const char *path, const char *old_git_dir, const char *new_git_dir)
> +{
> + if (rename(old_git_dir, new_git_dir) < 0)
> + die_errno(_("could not migrate git directory from '%s' to '%s'"),
> + old_git_dir, new_git_dir);
> +
> + connect_work_tree_and_git_dir(path, new_git_dir);
Should we worry about recovering (e.g. maybe move new_git_dir back to
old_git_dir) if this connect_work_tree_and_git_dir() fails?
Both write_file() and git_config_set_.. in this function may die(). In
such a case the repo is in broken state and the user needs pretty good
submodule understanding to recover from it, I think.
Recovering is not easy (nor entirely safe) either, though I suppose if
we keep original copies for modified files, then we could restore them
after moving the directory back and pray the UNIX gods that all
operations succeed.
--
Duy
^ permalink raw reply
* [PATCH] fast-import: properly fanout notes when tree is imported
From: Mike Hommey @ 2016-12-19 2:12 UTC (permalink / raw)
To: git; +Cc: johan, gitster
In typical uses of fast-import, trees are inherited from a parent
commit. In that case, the tree_entry for the branch looks like:
.versions[1].sha1 = $some_sha1
.tree = <tree structure loaded from $some_sha1>
However, when trees are imported, rather than inherited, that is not the
case. One can import a tree with a filemodify command, replacing the
root tree object.
e.g.
"M 040000 $some_sha1 \n"
In this case, the tree_entry for the branch looks like:
.versions[1].sha1 = $some_sha1
.tree = NULL
When adding new notes with the notemodify command, do_change_note_fanout
is called to get a notes count, and to do so, it loops over the
tree_entry->tree, but doesn't do anything when the tree is NULL.
In the latter case above, it means do_change_note_fanout thinks the tree
contains no note, and new notes are added with no fanout.
Interestingly, do_change_note_fanout does check whether subdirectories
have a NULL .tree, in which case it uses load_tree(). Which means the
right behaviour happens when using the filemodify command to import
subdirectories.
This change makes do_change_note_fanount call load_tree() whenever the
tree_entry it is given has no tree loaded, making all cases handled
equally.
Signed-off-by: Mike Hommey <mh@glandium.org>
---
This is something I should have submitted a patch for a long time ago, back
when this was discussed in the thread starting from
https://www.spinics.net/lists/git/msg242426.html. The message most relevant to
this patch in the thread is https://www.spinics.net/lists/git/msg242448.html.
fast-import.c | 8 +++++---
t/t9301-fast-import-notes.sh | 41 +++++++++++++++++++++++++++++++++++++++++
2 files changed, 46 insertions(+), 3 deletions(-)
diff --git a/fast-import.c b/fast-import.c
index cb545d7df5..5e528b1999 100644
--- a/fast-import.c
+++ b/fast-import.c
@@ -2220,13 +2220,17 @@ static uintmax_t do_change_note_fanout(
char *fullpath, unsigned int fullpath_len,
unsigned char fanout)
{
- struct tree_content *t = root->tree;
+ struct tree_content *t;
struct tree_entry *e, leaf;
unsigned int i, tmp_hex_sha1_len, tmp_fullpath_len;
uintmax_t num_notes = 0;
unsigned char sha1[20];
char realpath[60];
+ if (!root->tree)
+ load_tree(root);
+ t = root->tree;
+
for (i = 0; t && i < t->entry_count; i++) {
e = t->entries[i];
tmp_hex_sha1_len = hex_sha1_len + e->name->str_len;
@@ -2278,8 +2282,6 @@ static uintmax_t do_change_note_fanout(
leaf.tree);
} else if (S_ISDIR(e->versions[1].mode)) {
/* This is a subdir that may contain note entries */
- if (!e->tree)
- load_tree(e);
num_notes += do_change_note_fanout(orig_root, e,
hex_sha1, tmp_hex_sha1_len,
fullpath, tmp_fullpath_len, fanout);
diff --git a/t/t9301-fast-import-notes.sh b/t/t9301-fast-import-notes.sh
index 83acf68bc3..b408b2b32d 100755
--- a/t/t9301-fast-import-notes.sh
+++ b/t/t9301-fast-import-notes.sh
@@ -483,6 +483,47 @@ test_expect_success 'verify that lots of notes trigger a fanout scheme' '
'
+# Create another notes tree from the one above
+cat >>input <<INPUT_END
+commit refs/heads/other_commits
+committer $GIT_COMMITTER_NAME <$GIT_COMMITTER_EMAIL> $GIT_COMMITTER_DATE
+data <<COMMIT
+commit #$(($num_commit + 1))
+COMMIT
+
+from refs/heads/many_commits
+M 644 inline file
+data <<EOF
+file contents in commit #$(($num_commit + 1))
+EOF
+
+commit refs/notes/other_notes
+committer $GIT_COMMITTER_NAME <$GIT_COMMITTER_EMAIL> $GIT_COMMITTER_DATE
+data <<COMMIT
+committing one more note on a tree imported from a previous notes tree
+COMMIT
+
+M 040000 $(git log --no-walk --format=%T refs/notes/many_notes)
+N inline :$(($num_commit + 1))
+data <<EOF
+note for commit #$(($num_commit + 1))
+EOF
+INPUT_END
+
+test_expect_success 'verify that importing a notes tree respects the fanout scheme' '
+ git fast-import <input &&
+
+ # None of the entries in the top-level notes tree should be a full SHA1
+ git ls-tree --name-only refs/notes/other_notes |
+ while read path
+ do
+ if test $(expr length "$path") -ge 40
+ then
+ return 1
+ fi
+ done
+'
+
cat >>expect_non-note1 << EOF
This is not a note, but rather a regular file residing in a notes tree
EOF
--
2.11.0.dirty
^ permalink raw reply related
* Re: [PATCH] winansi_isatty(): fix when Git is used from CMD
From: Junio C Hamano @ 2016-12-19 1:12 UTC (permalink / raw)
To: Johannes Sixt; +Cc: Johannes Schindelin, git, Pranit Bauva
In-Reply-To: <ffc6a7a0-4ae4-b755-0b09-5bcd7114a2e6@kdbg.org>
Johannes Sixt <j6t@kdbg.org> writes:
> ..
> The new isatty() override implemented by cbb3f3c9b197 (mingw: intercept
> isatty() to handle /dev/null as Git expects it, 2016-12-11) does not
> take into account that _get_osfhandle() returns the handle visible by
> the C code, which is the pipe. But it actually wants to investigate the
> properties of the handle that is actually connected to the outside
> world. Fortunately, there is already winansi_get_osfhandle(), which
> returns exactly this handle. Use it.
>
> Signed-off-by: Johannes Sixt <j6t@kdbg.org>
> ---
> I was able to test the idea earlier than anticipated and it does work
> for me.
I'll queue this in 'pu' so that I won't forget, but this time I'll
make sure I won't act on it until I see you two agree on the right
way forward.
Thanks.
^ permalink raw reply
* Re: Suggestion for the "Did you mean this?" feature
From: Chris Packham @ 2016-12-19 0:48 UTC (permalink / raw)
To: Kaartic Sivaraam; +Cc: GIT
In-Reply-To: <1482063500.10858.1.camel@gmail.com>
On Mon, Dec 19, 2016 at 1:18 AM, Kaartic Sivaraam
<kaarticsivaraam91196@gmail.com> wrote:
> Hello all,
>
> I have found the "Did you mean this?" feature of git as a very good
> feature. I thought it would be even better if it took a step toward by
> asking for a prompt when there was only one alternative to the command
> that was entered.
>
> E.g.
>
>> unique@unique-pc:~$ git hepl
>> git: 'hepl' is not a git command. See 'git --help'.
>>
>> Did you mean this?
>> help
>> [yes/No] : y
>> usage: git [--version] [--help] [-C <path>] [-c name=value]
>> [--exec-path[=<path>]] [--html-path] [--man-path] [--info-
>> path]
>> ....
>
> This would make it even better for the user as it would avoid having to
> correct the mistake long commands that had only a single error
> (considering history feature is enabled).
>
> Is this is a good idea ?
This feature already exists (although it's not interactive). See
help.autoCorrect in the git-config man page. "git config
help.autoCorrect -1" should to the trick.
^ permalink raw reply
* Re: Bug report: $program_name in error message
From: Josh Bleecher Snyder @ 2016-12-18 21:44 UTC (permalink / raw)
To: Stefan Beller; +Cc: git@vger.kernel.org
In-Reply-To: <CAGZ79kZ=QK5s0_94+4GNs3M5oo49GLm-KkT5K=yZktxX8C4UCw@mail.gmail.com>
>> To reproduce, run 'git submodule' from within a bare repo. Result:
>>
>> $ git submodule
>> fatal: $program_name cannot be used without a working tree.
>>
>> Looks like the intent was for $program_name to be interpolated.
>
> Which version of git do you use?
$ git version
git version 2.11.0
>> As an aside, I sent a message a few days ago about a segfault when
>> working with a filesystem with direct_io on, but it appears not to
>> have made it to the archives on marc.info. Am I perhaps still
>> greylisted?
>
> Both emails show up in my mailbox (subscribed to the mailing list),
> so I think that just nobody answered your first email as the answer
> may be non trivial.
Thanks for the confirmation.
-josh
^ permalink raw reply
* Re: Bug report: $program_name in error message
From: Stefan Beller @ 2016-12-18 21:34 UTC (permalink / raw)
To: Josh Bleecher Snyder; +Cc: git@vger.kernel.org
In-Reply-To: <CAFAcib8yauNRB6UbO8qS2_Ff4fDt-7mMsmgop8d1V0j=RoTBSA@mail.gmail.com>
On Sun, Dec 18, 2016 at 12:36 PM, Josh Bleecher Snyder
<josharian@gmail.com> wrote:
> To reproduce, run 'git submodule' from within a bare repo. Result:
>
> $ git submodule
> fatal: $program_name cannot be used without a working tree.
>
> Looks like the intent was for $program_name to be interpolated.
Which version of git do you use?
>
>
> As an aside, I sent a message a few days ago about a segfault when
> working with a filesystem with direct_io on, but it appears not to
> have made it to the archives on marc.info. Am I perhaps still
> greylisted?
Both emails show up in my mailbox (subscribed to the mailing list),
so I think that just nobody answered your first email as the answer
may be non trivial.
>
> Thanks,
> Josh
^ permalink raw reply
* Bug report: $program_name in error message
From: Josh Bleecher Snyder @ 2016-12-18 20:36 UTC (permalink / raw)
To: git
To reproduce, run 'git submodule' from within a bare repo. Result:
$ git submodule
fatal: $program_name cannot be used without a working tree.
Looks like the intent was for $program_name to be interpolated.
As an aside, I sent a message a few days ago about a segfault when
working with a filesystem with direct_io on, but it appears not to
have made it to the archives on marc.info. Am I perhaps still
greylisted?
Thanks,
Josh
^ permalink raw reply
* [PATCH v1] git-p4: add diff/merge properties to .gitattributes for GitLFS files
From: larsxschneider @ 2016-12-18 19:01 UTC (permalink / raw)
To: git; +Cc: luke, gitster, Lars Schneider
From: Lars Schneider <larsxschneider@gmail.com>
The `git lfs track` command generates a .gitattributes file with diff
and merge properties [1]. Set the same .gitattributes format for files
tracked with GitLFS in git-p4.
[1] https://github.com/git-lfs/git-lfs/blob/v1.5.3/commands/command_track.go#L121
Signed-off-by: Lars Schneider <larsxschneider@gmail.com>
---
Notes:
Base Commit: d1271bddd4 (v2.11.0)
Diff on Web: https://github.com/git/git/compare/d1271bddd4...larsxschneider:e045b3d5c8
Checkout: git fetch https://github.com/larsxschneider/git git-p4/fix-lfs-attributes-v1 && git checkout e045b3d5c8
git-p4.py | 4 ++--
t/t9824-git-p4-git-lfs.sh | 24 ++++++++++++------------
2 files changed, 14 insertions(+), 14 deletions(-)
diff --git a/git-p4.py b/git-p4.py
index fd5ca52462..87b6932c81 100755
--- a/git-p4.py
+++ b/git-p4.py
@@ -1098,10 +1098,10 @@ class GitLFS(LargeFileSystem):
'# Git LFS (see https://git-lfs.github.com/)\n',
'#\n',
] +
- ['*.' + f.replace(' ', '[[:space:]]') + ' filter=lfs -text\n'
+ ['*.' + f.replace(' ', '[[:space:]]') + ' filter=lfs diff=lfs merge=lfs -text\n'
for f in sorted(gitConfigList('git-p4.largeFileExtensions'))
] +
- ['/' + f.replace(' ', '[[:space:]]') + ' filter=lfs -text\n'
+ ['/' + f.replace(' ', '[[:space:]]') + ' filter=lfs diff=lfs merge=lfs -text\n'
for f in sorted(self.largeFiles) if not self.hasLargeFileExtension(f)
]
)
diff --git a/t/t9824-git-p4-git-lfs.sh b/t/t9824-git-p4-git-lfs.sh
index 110a7e7924..1379db6357 100755
--- a/t/t9824-git-p4-git-lfs.sh
+++ b/t/t9824-git-p4-git-lfs.sh
@@ -81,9 +81,9 @@ test_expect_success 'Store files in LFS based on size (>24 bytes)' '
#
# Git LFS (see https://git-lfs.github.com/)
#
- /file2.dat filter=lfs -text
- /file4.bin filter=lfs -text
- /path[[:space:]]with[[:space:]]spaces/file3.bin filter=lfs -text
+ /file2.dat filter=lfs diff=lfs merge=lfs -text
+ /file4.bin filter=lfs diff=lfs merge=lfs -text
+ /path[[:space:]]with[[:space:]]spaces/file3.bin filter=lfs diff=lfs merge=lfs -text
EOF
test_path_is_file .gitattributes &&
test_cmp expect .gitattributes
@@ -109,7 +109,7 @@ test_expect_success 'Store files in LFS based on size (>25 bytes)' '
#
# Git LFS (see https://git-lfs.github.com/)
#
- /file4.bin filter=lfs -text
+ /file4.bin filter=lfs diff=lfs merge=lfs -text
EOF
test_path_is_file .gitattributes &&
test_cmp expect .gitattributes
@@ -135,7 +135,7 @@ test_expect_success 'Store files in LFS based on extension (dat)' '
#
# Git LFS (see https://git-lfs.github.com/)
#
- *.dat filter=lfs -text
+ *.dat filter=lfs diff=lfs merge=lfs -text
EOF
test_path_is_file .gitattributes &&
test_cmp expect .gitattributes
@@ -163,8 +163,8 @@ test_expect_success 'Store files in LFS based on size (>25 bytes) and extension
#
# Git LFS (see https://git-lfs.github.com/)
#
- *.dat filter=lfs -text
- /file4.bin filter=lfs -text
+ *.dat filter=lfs diff=lfs merge=lfs -text
+ /file4.bin filter=lfs diff=lfs merge=lfs -text
EOF
test_path_is_file .gitattributes &&
test_cmp expect .gitattributes
@@ -199,8 +199,8 @@ test_expect_success 'Remove file from repo and store files in LFS based on size
#
# Git LFS (see https://git-lfs.github.com/)
#
- /file2.dat filter=lfs -text
- /path[[:space:]]with[[:space:]]spaces/file3.bin filter=lfs -text
+ /file2.dat filter=lfs diff=lfs merge=lfs -text
+ /path[[:space:]]with[[:space:]]spaces/file3.bin filter=lfs diff=lfs merge=lfs -text
EOF
test_path_is_file .gitattributes &&
test_cmp expect .gitattributes
@@ -237,8 +237,8 @@ test_expect_success 'Add .gitattributes and store files in LFS based on size (>2
#
# Git LFS (see https://git-lfs.github.com/)
#
- /file2.dat filter=lfs -text
- /path[[:space:]]with[[:space:]]spaces/file3.bin filter=lfs -text
+ /file2.dat filter=lfs diff=lfs merge=lfs -text
+ /path[[:space:]]with[[:space:]]spaces/file3.bin filter=lfs diff=lfs merge=lfs -text
EOF
test_path_is_file .gitattributes &&
test_cmp expect .gitattributes
@@ -278,7 +278,7 @@ test_expect_success 'Add big files to repo and store files in LFS based on compr
#
# Git LFS (see https://git-lfs.github.com/)
#
- /file6.bin filter=lfs -text
+ /file6.bin filter=lfs diff=lfs merge=lfs -text
EOF
test_path_is_file .gitattributes &&
test_cmp expect .gitattributes
--
2.11.0
^ permalink raw reply related
* [PATCH v1] git-p4: fix git-p4.pathEncoding for removed files
From: larsxschneider @ 2016-12-18 17:51 UTC (permalink / raw)
To: git; +Cc: luke, gitster, Lars Schneider
From: Lars Schneider <larsxschneider@gmail.com>
In a9e38359e3 we taught git-p4 a way to re-encode path names from what
was used in Perforce to UTF-8. This path re-encoding worked properly for
"added" paths. "Removed" paths were not re-encoded and therefore
different from the "added" paths. Consequently, these files were not
removed in a git-p4 cloned Git repository because the path names did not
match.
Fix this by moving the re-encoding to a place that affects "added" and
"removed" paths. Add a test to demonstrate the issue.
Signed-off-by: Lars Schneider <larsxschneider@gmail.com>
---
Notes:
Base Commit: d1271bddd4 (v2.11.0)
Diff on Web: https://github.com/git/git/compare/d1271bddd4...larsxschneider:05a82caa69
Checkout: git fetch https://github.com/larsxschneider/git git-p4/fix-path-encoding-v1 && git checkout 05a82caa69
git-p4.py | 19 +++++++++----------
t/t9822-git-p4-path-encoding.sh | 16 ++++++++++++++++
2 files changed, 25 insertions(+), 10 deletions(-)
diff --git a/git-p4.py b/git-p4.py
index fd5ca52462..8f311cb4e8 100755
--- a/git-p4.py
+++ b/git-p4.py
@@ -2366,6 +2366,15 @@ class P4Sync(Command, P4UserMap):
break
path = wildcard_decode(path)
+ try:
+ path.decode('ascii')
+ except:
+ encoding = 'utf8'
+ if gitConfig('git-p4.pathEncoding'):
+ encoding = gitConfig('git-p4.pathEncoding')
+ path = path.decode(encoding, 'replace').encode('utf8', 'replace')
+ if self.verbose:
+ print 'Path with non-ASCII characters detected. Used %s to encode: %s ' % (encoding, path)
return path
def splitFilesIntoBranches(self, commit):
@@ -2495,16 +2504,6 @@ class P4Sync(Command, P4UserMap):
text = regexp.sub(r'$\1$', text)
contents = [ text ]
- try:
- relPath.decode('ascii')
- except:
- encoding = 'utf8'
- if gitConfig('git-p4.pathEncoding'):
- encoding = gitConfig('git-p4.pathEncoding')
- relPath = relPath.decode(encoding, 'replace').encode('utf8', 'replace')
- if self.verbose:
- print 'Path with non-ASCII characters detected. Used %s to encode: %s ' % (encoding, relPath)
-
if self.largeFileSystem:
(git_mode, contents) = self.largeFileSystem.processContent(git_mode, relPath, contents)
diff --git a/t/t9822-git-p4-path-encoding.sh b/t/t9822-git-p4-path-encoding.sh
index 7b83e696a9..c78477c19b 100755
--- a/t/t9822-git-p4-path-encoding.sh
+++ b/t/t9822-git-p4-path-encoding.sh
@@ -51,6 +51,22 @@ test_expect_success 'Clone repo containing iso8859-1 encoded paths with git-p4.p
)
'
+test_expect_success 'Delete iso8859-1 encoded paths and clone' '
+ (
+ cd "$cli" &&
+ ISO8859="$(printf "$ISO8859_ESCAPED")" &&
+ p4 delete "$ISO8859" &&
+ p4 submit -d "remove file"
+ ) &&
+ git p4 clone --destination="$git" //depot@all &&
+ test_when_finished cleanup_git &&
+ (
+ cd "$git" &&
+ git -c core.quotepath=false ls-files >actual &&
+ test_must_be_empty actual
+ )
+'
+
test_expect_success 'kill p4d' '
kill_p4d
'
--
2.11.0
^ permalink raw reply related
* Re: [PATCH] winansi_isatty(): fix when Git is used from CMD
From: Johannes Sixt @ 2016-12-18 15:37 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Junio C Hamano, git, Pranit Bauva
In-Reply-To: <ffc6a7a0-4ae4-b755-0b09-5bcd7114a2e6@kdbg.org>
Am 18.12.2016 um 16:26 schrieb Johannes Sixt:
> The new isatty() override implemented by cbb3f3c9b197 (mingw: intercept
> isatty() to handle /dev/null as Git expects it, 2016-12-11) does not
> take into account that _get_osfhandle() returns the handle visible by
> the C code, which is the pipe. But it actually wants to investigate the
> properties of the handle that is actually connected to the outside
> world. Fortunately, there is already winansi_get_osfhandle(), which
> returns exactly this handle. Use it.
But quite frankly, I find the implementation of winansi_isatty()
very unsatisfactory.
I understand that you wanted to be defensive and to override the
decision made by MSVCRT only when necessary.
However!
winansi.c is all about overriding MSVCRT's console handling. If we are
connected to a console, then by the time isatty() is called (from
outside the emulation layer), all handling of file descriptors 1 and 2
is already outside MSVCRT's control. In particular, we have determined
unambiguously whether a terminal is connected (see is_console()). I
suggest to have the implementation below (on top of the patch I'm
responding to).
What do you think?
diff --git a/compat/winansi.c b/compat/winansi.c
index ba360be69b..1748d17777 100644
--- a/compat/winansi.c
+++ b/compat/winansi.c
@@ -575,9 +575,8 @@ static void detect_msys_tty(int fd)
int winansi_isatty(int fd)
{
- int res = isatty(fd);
-
- if (res) {
+ switch (fd) {
+ case 0:
/*
* Make sure that /dev/null is not fooling Git into believing
* that we are connected to a terminal, as "_isatty() returns a
@@ -586,21 +585,19 @@ int winansi_isatty(int fd)
*
* https://msdn.microsoft.com/en-us/library/f4s0ddew.aspx
*/
- HANDLE handle = winansi_get_osfhandle(fd);
- if (fd == STDIN_FILENO) {
+ {
+ HANDLE handle = (HANDLE)_get_osfhandle(fd);
DWORD dummy;
- if (!GetConsoleMode(handle, &dummy))
- res = 0;
- } else if (fd == STDOUT_FILENO || fd == STDERR_FILENO) {
- CONSOLE_SCREEN_BUFFER_INFO dummy;
-
- if (!GetConsoleScreenBufferInfo(handle, &dummy))
- res = 0;
+ return !!GetConsoleMode(handle, &dummy);
}
+ case 1:
+ return !!hconsole1;
+ case 2:
+ return !!hconsole2;
}
- return res;
+ return isatty(fd);
}
void winansi_init(void)
--
2.11.0.79.gf6b77ca
^ permalink raw reply related
* [PATCH] winansi_isatty(): fix when Git is used from CMD
From: Johannes Sixt @ 2016-12-18 15:26 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Junio C Hamano, git, Pranit Bauva
In-Reply-To: <5977e71d-da58-7cb0-bc69-343bb3a1341d@kdbg.org>
The code in winansi.c emulates ANSI escape sequences when Git is
connected to the "real" windows console, CMD.exe. The details are
outline in eac14f8909d9 (Win32: Thread-safe windows console output,
2012-01-14). Essentially, it plugs a pipe between C code and the actual
console output handle.
This commit also added an override for isatty(), but it was made
unnecessary by fcd428f4a952 (Win32: fix broken pipe detection,
2012-03-01).
The new isatty() override implemented by cbb3f3c9b197 (mingw: intercept
isatty() to handle /dev/null as Git expects it, 2016-12-11) does not
take into account that _get_osfhandle() returns the handle visible by
the C code, which is the pipe. But it actually wants to investigate the
properties of the handle that is actually connected to the outside
world. Fortunately, there is already winansi_get_osfhandle(), which
returns exactly this handle. Use it.
Signed-off-by: Johannes Sixt <j6t@kdbg.org>
---
I was able to test the idea earlier than anticipated and it does work
for me.
compat/winansi.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/compat/winansi.c b/compat/winansi.c
index cb725fb02f..ba360be69b 100644
--- a/compat/winansi.c
+++ b/compat/winansi.c
@@ -586,7 +586,7 @@ int winansi_isatty(int fd)
*
* https://msdn.microsoft.com/en-us/library/f4s0ddew.aspx
*/
- HANDLE handle = (HANDLE)_get_osfhandle(fd);
+ HANDLE handle = winansi_get_osfhandle(fd);
if (fd == STDIN_FILENO) {
DWORD dummy;
--
2.11.0.79.gf6b77ca
^ permalink raw reply related
* Re: Suggestion for the "Did you mean this?" feature
From: Alexei Lozovsky @ 2016-12-18 15:16 UTC (permalink / raw)
To: Kaartic Sivaraam; +Cc: git
In-Reply-To: <1482063500.10858.1.camel@gmail.com>
On 18 December 2016 at 14:18, Kaartic Sivaraam wrote:
> Hello all,
>
> I have found the "Did you mean this?" feature of git as a very good
> feature. I thought it would be even better if it took a step toward by
> asking for a prompt when there was only one alternative to the command
> that was entered.
>
> E.g.
>
>> unique@unique-pc:~$ git hepl
>> git: 'hepl' is not a git command. See 'git --help'.
>>
>> Did you mean this?
>> help
>> [yes/No] : y
>> usage: git [--version] [--help] [-C <path>] [-c name=value]
>> [--exec-path[=<path>]] [--html-path] [--man-path] [--info-
>> path]
>> ....
>
> This would make it even better for the user as it would avoid having to
> correct the mistake long commands that had only a single error
> (considering history feature is enabled).
>
> Is this is a good idea ?
It's definitely a good thing for human users. For example, I am annoyed
from time to time when I type in some long spell, mistype one minor thing,
and the whole command fails. Then I need to press <up>, correct the
obvious typo, and run the command again.
Though, there is one aspect which may be the reason why git does not have
this feature: it requires interactive input. For example, it won't work
if some script tries to run an invalid git command. And git cannot really
tell whether it is running interactively or in a batch mode. If it is
running in batch mode then the whole script may hang indefinitely waiting
for nonexistent input. This also may apply to using git with pipes.
Maybe a configuration option or some GIT_NO_PROMPT environment variable
may be used to force disable this, but it still will be a hassle for the
scripts.
^ permalink raw reply
* Re: Suggestion for the "Did you mean this?" feature
From: Kaartic Sivaraam @ 2016-12-18 13:26 UTC (permalink / raw)
To: Stephan Beyer, git
In-Reply-To: <5e1a3c4b-43b9-29f2-68fe-8149d9940123@gmx.net>
On Sun, 2016-12-18 at 14:16 +0100, Stephan Beyer wrote:
> I cannot tell if this is a good idea (or why it would be a bad idea)
> but
> why do you restrict your suggestion to the case when there is only
> one
> alternative?
>
> Why not also something like:
>
> ---
> $ git sta
> git: 'sta' is not a git command. See 'git --help'.
>
> Did you mean one of these?
> [1] status
> [2] stage
> [3] stash
> You can choose or quit [1,2,3,q]:
That would be fine too. Just thought it would be a good start to start
with a simple case. Also, I wasn't sure if there were any drawback's
that I was missing. I guess if it was implemented it wouldn't be
difficult to extend it further.
--
Regards,
Kaartic
^ permalink raw reply
* Re: Suggestion for the "Did you mean this?" feature
From: Stephan Beyer @ 2016-12-18 13:16 UTC (permalink / raw)
To: Kaartic Sivaraam, git
In-Reply-To: <1482063500.10858.1.camel@gmail.com>
Hi,
On 12/18/2016 01:18 PM, Kaartic Sivaraam wrote:
> I have found the "Did you mean this?" feature of git as a very good
> feature. I thought it would be even better if it took a step toward by
> asking for a prompt when there was only one alternative to the command
> that was entered.
>
> E.g.
>
>> unique@unique-pc:~$ git hepl
>> git: 'hepl' is not a git command. See 'git --help'.
>>
>> Did you mean this?
>> help
>> [yes/No] : y
>> usage: git [--version] [--help] [-C <path>] [-c name=value]
>> [--exec-path[=<path>]] [--html-path] [--man-path] [--info-
>> path]
>> ....
>
> This would make it even better for the user as it would avoid having to
> correct the mistake long commands that had only a single error
> (considering history feature is enabled).
>
> Is this is a good idea ?
I cannot tell if this is a good idea (or why it would be a bad idea) but
why do you restrict your suggestion to the case when there is only one
alternative?
Why not also something like:
---
$ git sta
git: 'sta' is not a git command. See 'git --help'.
Did you mean one of these?
[1] status
[2] stage
[3] stash
You can choose or quit [1,2,3,q]:
---
Best
Stephan
^ permalink raw reply
* Re: [RFC/PATCH v3 00/16] Add initial experimental external ODB support
From: Lars Schneider @ 2016-12-18 13:13 UTC (permalink / raw)
To: Christian Couder
Cc: git, Junio C Hamano, Jeff King, Nguyen Thai Ngoc Duy, Mike Hommey,
Eric Wong, Christian Couder
In-Reply-To: <CAP8UFD2uyq3Uf1co_BUKJX_eogdCDJ30KJZmQ1BQXNQ1dw=w3A@mail.gmail.com>
> On 13 Dec 2016, at 18:20, Christian Couder <christian.couder@gmail.com> wrote:
>
> On Sat, Dec 3, 2016 at 7:47 PM, Lars Schneider <larsxschneider@gmail.com> wrote:
>>
>>> On 30 Nov 2016, at 22:04, Christian Couder <christian.couder@gmail.com> wrote:
>>>
>>> Goal
>>> ~~~~
>>>
>>> Git can store its objects only in the form of loose objects in
>>> separate files or packed objects in a pack file.
>>>
>>> To be able to better handle some kind of objects, for example big
>>> blobs, it would be nice if Git could store its objects in other object
>>> databases (ODB).
>> ...
>>
>> Minor nit: I feel the term "other" could be more expressive. Plus
>> "database" might confuse people. What do you think about
>> "External Object Storage" or something?
>
> In the current Git code, "DB" is already used a lot. For example in
> cache.h there is:
> ...
I am not worried about Git core developers as I don't think they would
be confused by the term "DB". I wonder if it would make sense to have
a clearer "external name" for the average Git user (== non Git devs)
or if this would create just more confusion.
>>> * Transfer
>>>
>>> To tranfer information about the blobs stored in external ODB, some
>>> special refs, called "odb ref", similar as replace refs, are used.
>>>
>>> For now there should be one odb ref per blob. Each ref name should be
>>> refs/odbs/<odbname>/<sha1> where <sha1> is the sha1 of the blob stored
>>> in the external odb named <odbname>.
>>>
>>> These odb refs should all point to a blob that should be stored in the
>>> Git repository and contain information about the blob stored in the
>>> external odb. This information can be specific to the external odb.
>>> The repos can then share this information using commands like:
>>>
>>> `git fetch origin "refs/odbs/<odbname>/*:refs/odbs/<odbname>/*"`
>>
>> The "odbref" would point to a blob and the blob could contain anything,
>> right? E.g. it could contain an existing GitLFS pointer, right?
>>
>> version https://git-lfs.github.com/spec/v1
>> oid sha256:4d7a214614ab2935c943f9e0ff69d22eadbb8f32b1258daaa5e2ca24d17e2393
>> size 12345
>
> Yes, but I think that the sha1 should be added. So yes, it could
> easily be made compatible with git LFS.
What do you mean with "the sha1 should be added"? Do you suggest to add
sha1 to GitLFS?
>>> Future work
>>> ~~~~~~~~~~~
>>>
>>> I think that the odb refs don't prevent a regular fetch or push from
>>> wanting to send the objects that are managed by an external odb. So I
>>> am interested in suggestions about this problem. I will take a look at
>>> previous discussions and how other mechanisms (shallow clone, bundle
>>> v3, ...) handle this.
>>
>> If the ODB configuration is stored in the Git repo similar to
>> .gitmodules then every client that clones ODB references would be able
>> to resolve them, right?
>
> Yeah, but I am not sure that being able to resolve the odb refs will
> prevent the big blobs from being sent.
> With Git LFS, git doesn't know about the big blobs, only about the
> substituted files, but that is not the case in what I am doing.
I think the biggest problem in Git are huge blobs that are not in the
head revision. In the great majority of cases you don't need these blobs
but you always have to transfer them during clone. That's what GitLFS
is solving today and what I hope your protocol could solve better in
the future!
Cheers,
Lars
^ permalink raw reply
* [PATCH v1] t0021: fix flaky test
From: larsxschneider @ 2016-12-18 12:37 UTC (permalink / raw)
To: git; +Cc: ramsay, peff, gitster, Lars Schneider
In-Reply-To: <B3D96792-047D-4C91-8DCC-60C800B2861B@gmail.com>
From: Lars Schneider <larsxschneider@gmail.com>
t0021.15 creates files, adds them to the index, and commits them. All
this usually happens in a test run within the same second and Git cannot
know if the files have been changed between `add` and `commit`. Thus,
Git has to run the clean filter in both operations. Sometimes these
invocations spread over two different seconds and Git can infer that the
files were not changed between `add` and `commit` based on their
modification timestamp. The test would fail as it expects the filter
invocation. Remove this expectation to make the test stable.
Signed-off-by: Lars Schneider <larsxschneider@gmail.com>
---
Notes:
Base Commit: f8bf8f2a7b (next)
Diff on Web: https://github.com/git/git/compare/f8bf8f2a7b...larsxschneider:9d88b66e03
Checkout: git fetch https://github.com/larsxschneider/git filter-process/fix-flaky-test-v1 && git checkout 9d88b66e03
t/t0021-conversion.sh | 17 +----------------
1 file changed, 1 insertion(+), 16 deletions(-)
diff --git a/t/t0021-conversion.sh b/t/t0021-conversion.sh
index 6f16983d3e..161f560446 100755
--- a/t/t0021-conversion.sh
+++ b/t/t0021-conversion.sh
@@ -377,22 +377,7 @@ test_expect_success PERL 'required process filter should filter data' '
EOF
test_cmp_count expected.log rot13-filter.log &&
- filter_git commit -m "test commit 2" &&
- cat >expected.log <<-EOF &&
- START
- init handshake complete
- IN: clean test.r $S [OK] -- OUT: $S . [OK]
- IN: clean test2.r $S2 [OK] -- OUT: $S2 . [OK]
- IN: clean test4-empty.r 0 [OK] -- OUT: 0 [OK]
- IN: clean testsubdir/test3 '\''sq'\'',\$x=.r $S3 [OK] -- OUT: $S3 . [OK]
- IN: clean test.r $S [OK] -- OUT: $S . [OK]
- IN: clean test2.r $S2 [OK] -- OUT: $S2 . [OK]
- IN: clean test4-empty.r 0 [OK] -- OUT: 0 [OK]
- IN: clean testsubdir/test3 '\''sq'\'',\$x=.r $S3 [OK] -- OUT: $S3 . [OK]
- STOP
- EOF
- test_cmp_count expected.log rot13-filter.log &&
-
+ git commit -m "test commit 2" &&
rm -f test2.r "testsubdir/test3 '\''sq'\'',\$x=.r" &&
filter_git checkout --quiet --no-progress . &&
--
2.11.0
^ permalink raw reply related
* Re: [PATCH v2 1/5] doc: add documentation for OPT_STRING_LIST
From: Jacob Keller @ 2016-12-18 12:19 UTC (permalink / raw)
To: Philip Oakley, Jacob Keller, git; +Cc: Junio C Hamano
In-Reply-To: <67572777448E4DCE967BA079110A3487@PhilipOakley>
On December 17, 2016 3:56:19 AM PST, Philip Oakley <philipoakley@iee.org> wrote:
>From: "Jacob Keller" <jacob.e.keller@intel.com>
>> From: Jacob Keller <jacob.keller@gmail.com>
>>
>> Commit c8ba16391655 ("parse-options: add OPT_STRING_LIST helper",
>> 2011-06-09) added the OPT_STRING_LIST as a way to accumulate a
>repeated
>> list of strings. However, this was not documented in the
>> api-parse-options documentation. Add documentation now so that future
>> developers may learn of its existence.
>>
>> Signed-off-by: Jacob Keller <jacob.keller@gmail.com>
>> ---
>> Documentation/technical/api-parse-options.txt | 5 +++++
>> 1 file changed, 5 insertions(+)
>>
>> diff --git a/Documentation/technical/api-parse-options.txt
>> b/Documentation/technical/api-parse-options.txt
>> index 27bd701c0d68..92791740aa64 100644
>> --- a/Documentation/technical/api-parse-options.txt
>> +++ b/Documentation/technical/api-parse-options.txt
>> @@ -168,6 +168,11 @@ There are some macros to easily define options:
>> Introduce an option with string argument.
>> The string argument is put into `str_var`.
>>
>> +`OPT_STRING_LIST(short long, &list, arg_str, description)`::
>
>should there be an extra comma between 'short long' in a similar manner
>to
>the OPT_INTEGER argument list below?
>
>
You are indeed correct sir. I will fix this up.
Thanks,
Jake
^ permalink raw reply
* Suggestion for the "Did you mean this?" feature
From: Kaartic Sivaraam @ 2016-12-18 12:18 UTC (permalink / raw)
To: git
Hello all,
I have found the "Did you mean this?" feature of git as a very good
feature. I thought it would be even better if it took a step toward by
asking for a prompt when there was only one alternative to the command
that was entered.
E.g.
> unique@unique-pc:~$ git hepl
> git: 'hepl' is not a git command. See 'git --help'.
>
> Did you mean this?
> help
> [yes/No] : y
> usage: git [--version] [--help] [-C <path>] [-c name=value]
> [--exec-path[=<path>]] [--html-path] [--man-path] [--info-
> path]
> ....
This would make it even better for the user as it would avoid having to
correct the mistake long commands that had only a single error
(considering history feature is enabled).
Is this is a good idea ?
--
Regards,
Kaartic
^ permalink raw reply
* [PATCH v2] git-p4: Fix multi-path changelist empty commits
From: George Vanburgh @ 2016-12-17 22:11 UTC (permalink / raw)
To: git
In-Reply-To: <01020159037a8995-2d1da9d4-4a27-4b98-818b-432fc0ad8a52-000000@eu-west-1.amazonses.com>
From: George Vanburgh <gvanburgh@bloomberg.net>
When importing from multiple perforce paths - we may attempt to import
a changelist that contains files from two (or more) of these depot
paths. Currently, this results in multiple git commits - one
containing the changes, and the other(s) as empty commit(s). This
behavior was introduced in commit 1f90a64
("git-p4: reduce number of server queries for fetches", 2015-12-19).
Reproduction Steps:
1. Have a git repo cloned from a perforce repo using multiple depot
paths (e.g. //depot/foo and //depot/bar).
2. Submit a single change to the perforce repo that makes changes in
both //depot/foo and //depot/bar.
3. Run "git p4 sync" to sync the change from #2.
Change is synced as multiple commits, one for each depot path that was
affected.
Using a set, instead of a list inside p4ChangesForPaths() ensures that
each changelist is unique to the returned list, and therefore only a
single commit is generated for each changelist.
Reported-by: James Farwell <jfarwell@vmware.com>
Signed-off-by: George Vanburgh <gvanburgh@bloomberg.net>
---
git-p4.py | 4 ++--
t/t9800-git-p4-basic.sh | 22 +++++++++++++++++++++-
2 files changed, 23 insertions(+), 3 deletions(-)
diff --git a/git-p4.py b/git-p4.py
index fd5ca52..6307bc8 100755
--- a/git-p4.py
+++ b/git-p4.py
@@ -822,7 +822,7 @@ def p4ChangesForPaths(depotPaths, changeRange, requestedBlockSize):
die("cannot use --changes-block-size with non-numeric revisions")
block_size = None
- changes = []
+ changes = set()
# Retrieve changes a block at a time, to prevent running
# into a MaxResults/MaxScanRows error from the server.
@@ -841,7 +841,7 @@ def p4ChangesForPaths(depotPaths, changeRange, requestedBlockSize):
# Insert changes in chronological order
for line in reversed(p4_read_pipe_lines(cmd)):
- changes.append(int(line.split(" ")[1]))
+ changes.add(int(line.split(" ")[1]))
if not block_size:
break
diff --git a/t/t9800-git-p4-basic.sh b/t/t9800-git-p4-basic.sh
index 0730f18..4d93522 100755
--- a/t/t9800-git-p4-basic.sh
+++ b/t/t9800-git-p4-basic.sh
@@ -131,6 +131,26 @@ test_expect_success 'clone two dirs, @all, conflicting files' '
)
'
+test_expect_success 'clone two dirs, each edited by submit, single git commit' '
+ (
+ cd "$cli" &&
+ echo sub1/f4 >sub1/f4 &&
+ p4 add sub1/f4 &&
+ echo sub2/f4 >sub2/f4 &&
+ p4 add sub2/f4 &&
+ p4 submit -d "sub1/f4 and sub2/f4"
+ ) &&
+ git p4 clone --dest="$git" //depot/sub1@all //depot/sub2@all &&
+ test_when_finished cleanup_git &&
+ (
+ cd "$git" &&
+ git ls-files >lines &&
+ test_line_count = 4 lines &&
+ git log --oneline p4/master >lines &&
+ test_line_count = 5 lines
+ )
+'
+
revision_ranges="2000/01/01,#head \
1,2080/01/01 \
2000/01/01,2080/01/01 \
@@ -147,7 +167,7 @@ test_expect_success 'clone using non-numeric revision ranges' '
(
cd "$git" &&
git ls-files >lines &&
- test_line_count = 6 lines
+ test_line_count = 8 lines
)
done
'
--
https://github.com/git/git/pull/311
^ permalink raw reply related
* Re: [PATCH v2 01/34] sequencer: support a new action: 'interactive rebase'
From: Stephan Beyer @ 2016-12-17 20:23 UTC (permalink / raw)
To: Junio C Hamano, Johannes Schindelin; +Cc: git, Kevin Daudt, Dennis Kaarsemaker
In-Reply-To: <xmqqy3ziwbpk.fsf@gitster.mtv.corp.google.com>
Hi,
On 12/14/2016 08:29 PM, Junio C Hamano wrote:
> Johannes Schindelin <johannes.schindelin@gmx.de> writes:
>> -/* We will introduce the 'interactive rebase' mode later */
>> static inline int is_rebase_i(const struct replay_opts *opts)
>> {
>> - return 0;
>> + return opts->action == REPLAY_INTERACTIVE_REBASE;
>> }
>>
>> static const char *get_dir(const struct replay_opts *opts)
>> {
>> + if (is_rebase_i(opts))
>> + return rebase_path();
>> return git_path_seq_dir();
>> }
>
> This obviously makes the assumption made by 39784cd362 ("sequencer:
> remove useless get_dir() function", 2016-12-07) invalid, where the
> "remove useless" thought that the callers of this function wants a
> single answer that does not depend on opts.
>
> I'll revert that commit from the sb/sequencer-abort-safety topic (as
> the topic is in 'next' already) to keep this one. Please holler if
> that is a mistaken decision.
It seems to be the right decision if one wants to keep the internal-path
backwards-compatibility of "git rebase -i" (and it seems that Dscho
wants to keep it).
However, maintaining more than one directory (like "sequencer" for
sequencer state and "rebase-merge" for rebase todo and log) can cause
the necessity to be even more careful when hacking on sequencer... For
example, the cleanup code must delete both of them, not only one of them.
Hence, I think that it's a wiser choice to keep one directory for
sequencer state *and* additional files.
If we (a) save everything in "sequencer", we break the internal-path
backwards-compatbility but we can get rid of get_dir()...
If we (b) save everything in "rebase-merge" when using rebase -i and
save everything in "sequencer" for pick/revert, we are 100%
backwards-compatible, but we have to change every occurrence of
git_path_seq_dir() to get_dir() and the GIT_PATH_FUNC definitions of
git_path_{todo,opts,head}_file must be replaced by definitions using
get_dir().
Best
Stephan
^ permalink raw reply
* Re: [PATCH v15 08/27] bisect--helper: `is_expected_rev` & `check_expected_revs` shell function in C
From: Stephan Beyer @ 2016-12-17 19:55 UTC (permalink / raw)
To: Pranit Bauva; +Cc: Git List
In-Reply-To: <CAFZEwPMwviof5jNvQnxFZYdw324XpbLSQ9mzEQjrCW-K4A+GCA@mail.gmail.com>
Hi Pranit,
On 12/16/2016 08:35 PM, Pranit Bauva wrote:
> On Thu, Nov 17, 2016 at 5:17 AM, Stephan Beyer <s-beyer@gmx.net> wrote:
>> On 10/14/2016 04:14 PM, Pranit Bauva wrote:
>>> diff --git a/builtin/bisect--helper.c b/builtin/bisect--helper.c
>>> index d84ba86..c542e8b 100644
>>> --- a/builtin/bisect--helper.c
>>> +++ b/builtin/bisect--helper.c
>>> @@ -123,13 +123,40 @@ static int bisect_reset(const char *commit)
>>> return bisect_clean_state();
>>> }
>>>
>>> +static int is_expected_rev(const char *expected_hex)
>>> +{
>>> + struct strbuf actual_hex = STRBUF_INIT;
>>> + int res = 0;
>>> + if (strbuf_read_file(&actual_hex, git_path_bisect_expected_rev(), 0) >= 40) {
>>> + strbuf_trim(&actual_hex);
>>> + res = !strcmp(actual_hex.buf, expected_hex);
>>> + }
>>> + strbuf_release(&actual_hex);
>>> + return res;
>>> +}
>>
>> I am not sure it does what it should.
>>
>> I would expect the following behavior from this function:
>> - file does not exist (or is "broken") => return 0
>> - actual_hex != expected_hex => return 0
>> - otherwise return 1
>>
>> If I am not wrong, the code does the following instead:
>> - file does not exist (or is "broken") => return 0
>> - actual_hex != expected_hex => return 1
>> - otherwise => return 0
>
> It seems that I didn't carefully see what the shell code is (or
> apparently did a mistake in understanding it ;)). I think the C
> version does exactly what the shell version does. Can you confirm it
> once again, please?
I check again...
The shell code does the following:
- file does not exist or is not a regular file => return false
- actual_hex != expected_hex => return false
- otherwise => return true
(false means a value != 0, true means 0)
Your code does the following:
- file cannot be read or is broken => return 0
- actual_hex != expected_hex => return 0
- otherwise => return 1
So you are very right, it seems I had a weird thinko (I probably missed
the "!" in front of strcmp or something) :)
Sorry for bothering,
Stephan
^ 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