Re: [PATCHv8 6/6] submodule: add absorb-git-dir function

[Duy Nguyen]

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

[PATCH] fast-import: properly fanout notes when tree is imported

[Mike Hommey]

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 = 

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 04 $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 
---

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 < $GIT_COMMITTER_DATE
+data < $GIT_COMMITTER_DATE
+data <>expect_non-note1 << EOF
 This is not a note, but rather a regular file residing in a notes tree
 EOF
-- 
2.11.0.dirty

Re: [PATCH] winansi_isatty(): fix when Git is used from CMD

[Junio C Hamano]

Johannes Sixt  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 
> ---
> 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.  

Re: Suggestion for the "Did you mean this?" feature

[Chris Packham]

On Mon, Dec 19, 2016 at 1:18 AM, 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 ] [-c name=value]
>>[--exec-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.

Re: Bug report: $program_name in error message

[Josh Bleecher Snyder]

>> 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

Re: Bug report: $program_name in error message

[Stefan Beller]

On Sun, Dec 18, 2016 at 12:36 PM, Josh Bleecher Snyder
 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

Bug report: $program_name in error message

[Josh Bleecher Snyder]

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

[PATCH v1] git-p4: add diff/merge properties to .gitattributes for GitLFS files

[larsxschneider]

From: Lars Schneider 

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 
---

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

[PATCH v1] git-p4: fix git-p4.pathEncoding for removed files

[larsxschneider]

From: Lars Schneider 

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 
---

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

Re: [PATCH] winansi_isatty(): fix when Git is used from CMD

[Johannes Sixt]

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..1748d1 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, ))
-   res = 0;
-   } else if (fd == STDOUT_FILENO || fd == STDERR_FILENO) {
-   CONSOLE_SCREEN_BUFFER_INFO dummy;
-
-   if (!GetConsoleScreenBufferInfo(handle, ))
-   res = 0;
+   return !!GetConsoleMode(handle, );
}
+   case 1:
+   return !!hconsole1;
+   case 2:
+   return !!hconsole2;
}
 
-   return res;
+   return isatty(fd);
 }
 
 void winansi_init(void)
-- 
2.11.0.79.gf6b77ca

[PATCH] winansi_isatty(): fix when Git is used from CMD

[Johannes Sixt]

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 
---
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

Re: Suggestion for the "Did you mean this?" feature

[Alexei Lozovsky]

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 ] [-c name=value]
>>[--exec-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 , 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.

Re: Suggestion for the "Did you mean this?" feature

[Kaartic Sivaraam]

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

Re: Suggestion for the "Did you mean this?" feature

[Stephan Beyer]

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 ] [-c name=value]
>>[--exec-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

Re: [RFC/PATCH v3 00/16] Add initial experimental external ODB support

[Lars Schneider]

> On 13 Dec 2016, at 18:20, Christian Couder  wrote:
> 
> On Sat, Dec 3, 2016 at 7:47 PM, Lars Schneider  
> wrote:
>> 
>>> On 30 Nov 2016, at 22:04, Christian Couder  
>>> 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// where  is the sha1 of the blob stored
>>> in the external odb named .
>>> 
>>> 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//*:refs/odbs//*"`
>> 
>> 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

[PATCH v1] t0021: fix flaky test

[larsxschneider]

From: Lars Schneider 

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 
---

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

Re: [PATCH v2 1/5] doc: add documentation for OPT_STRING_LIST

[Jacob Keller]

On December 17, 2016 3:56:19 AM PST, Philip Oakley  wrote:
>From: "Jacob Keller" 
>> From: Jacob Keller 
>>
>> 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 
>> ---
>> 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, , 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

Suggestion for the "Did you mean this?" feature

[Kaartic Sivaraam]

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 ] [-c name=value]
>    [--exec-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