Re: [PATCH v3 2/6] path.c: new (identical) list for worktree v1

[Junio C Hamano]

Nguyễn Thái Ngọc Duy   writes:

> +static struct common_dir common_list_v1[] = {
> + ...
> +};
> +
> +static struct common_dir *get_common_list(void)
> +{
> + switch (repository_format_worktree_version) {
> + case 0: return common_list_v0;
> + case 1: return common_list_v1;

Why not an array whose elements are these common_list_v$N[]
instead of "switch"?  I.e.

static struct common_dir **common_list_version[] = {
common_list_v0,
common_list_v1,
};

static struct common_dir *get_common_list(void)
{
int i = repository_format_worktree_version;
if (i < ARRAY_SIZE(common_list_version))
return common_list_version[i];
die("I dunno about version %d", i);
}

--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Starting on a microproject for GSoC

[Moritz Neeb]

Hi git developers,

the next Google Summer of Code is not too far away. I expect git to
apply for it and hopefully have some student spots which in turn I plan
to apply. It was recommended elsewhere and on this list as well, that it
is beneficial to engage with the community early, that's why I am
writing to you already now, before all this formal stuff has begun.

Before I may introduce myself: I'm a Computer Science student in
Germany, coming towards the end of my Masters. I am an enthusiastic git
user that's why I'd like to give something back. This would be my first
time to actually contribute to a FOSS project and I am quite excited
(also a bit frightened ;)).

As the list of available microprojects 2016 is still to be created, I
might need your help in finding a project to work on. I started to dig
through the archives along items of the list of 2015 [0] and so far
found out the following:

The first task, to make "git -C '' cmd" not to barf seems to be solved.
I tried it with "git -C '' status" at least. I could not find the
related patch, maybe it did use other keywords. I would be interested.

The second task, to allow "-" as a short-hand for "@{-1}" in more places
seems to be still open for reset, although someone almost finished it
(cf. $gmane/265417). I suppose just fixing/revising this would be kind
of a too low hanging fruit? More interesting (also because I am a bit
earlier) might be to unify everything, as suggested by Junio in
$gmane/265260. Or implementing it for another branch command, e.g. rebase.

The other tasks I did not yet dig into.

If all of that is considered as not relevant, I might just go for a
newer idea, like converting strbuf_getline_lf() callers to
strbuf_getline(), as suggested in $gmane/284104.

Any thoughts?

A question regarding the process of "taking a task (or bug)" in general:
Is it solely organized through the mailing list? Suppose I start to work
on something, should I announce it to not risk work duplication? Does it
happen often that more people accidentally work on the same task?

Best,
Moritz

[0] http://git.github.io/SoC-2015-Microprojects.html
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Need support with git credential storage

[Jeff King]

On Wed, Jan 27, 2016 at 09:49:38PM +, Charles Bélanger wrote:

> Here's the git clone command launch by a .sh script file called from 
> ~/.profile:
> git clone https://myusern...@bitbucket.org/CompanyName/ProjectName.git 
> ~/Projects/SubFolderName/ProjectName
> 
> Here's the error from bash .profile:
> Fatal: unable to access 
> 'https://myusern...@bitbucket.org/CompanyName/ProjectName.git/':
> Could not resolve host: bitbucket.org

I don't think this is related to credentials. The credential code should
never do a network hostname lookup. It looks more like git-clone is
failing to contact the host in the first place.

Try "ping bitbucket.org", which would presumably yield the same error.
If so, you need to figure out why you cannot resolve the name, but
that's beyond the scope of this list.

> I followed the excellent Web page here:
> https://git-scm.com/book/be/v2/Git-Tools-Credential-Storage
> 
> Here's what I use as commands:
> git credential-store --file ~/git.store store
> protocol=https
> host=bitbucket.org/CompanyName/ProjectName.git
> username=MyUserName
> password=MyPassword
> (type enter on a blank line to exit)

This comes from the "under the hood" section, I think. In normal use,
you shouldn't need to run the credential-helper directly. Just configure
it, via:

  git config credential.helper "store --file ~/git.store"

The first time git needs a password, it will prompt you on the terminal,
and then store the result in that file.

If you do want to pre-seed the store, you can do so using a command like
the one above. But as you noted later, the "host" field should be _just_
the hostname, not the rest of the url path. That would go in the "path"
field if you want it, but typically git does not even bother to store
paths, and just keys on whole domains (see "credential.useHttpPath" in
"git help config" for more details).

You can also specify a URL using the special key "url", which is then
parsed into its components. So for example:

  $ git credential-store --file my-store store
  url=https://bitbucket.org/CompanyName/ProjectName.git
  username=foo
  password=bar
  [blank line to end]

  $ cat my-store
  https://foo:b...@bitbucket.org/CompanyName/ProjectName.git

  $ git credential-store --file my-store get
  url=https://bitbucket.org/

  [blank line ends our input, the rest is output]
  username=foo
  password=bar

> Here's what the ~/git.store file looks like:
> 
> https://MyUserName:mypassw...@bitbucket.org%2fCompanyName%2fProjectName.git
> 
> I tried changing the %2f by / inside the git.store file and also tried // but 
> it's still showing the same fatal error.
> Perhaps I don't use the host=  property correctly.

Right. It should be:

  https://MyUserName:mypassw...@bitbucket.org/CompanyName/ProjectName.git

Though as before, you can omit "CompanyName/ProjectName.git" completely,
to cover the whole domain.

-Peff
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: git archive should use vendor extension in pax header

[fuz]

Hallo René,

On Wed, Jan 27, 2016 at 09:31:15PM +0100, René Scharfe wrote:
> Hello Robert,
> 
> it's customary to discuss in the open by copying the list.  Unless
> there are secrets involved, but I don't see any below.  I kept it
> private anyway in case I missed any, but please cc:
> git@vger.kernel.org on your reply if possible.

I'm sorry for miss-sending the last mail, I sent it to the list again.

> >>This is only a problem if you don't know how a given tar files was
> >>created (or modified later).  How did you get into this situation?
> >>Or in other words: Please tell me more about your use case.
> >
> >My situation is that I'm interested in knowing if an archive was created
> >by git so I can find out where the corresponding repository is and find
> >out which commit this archive was created from.  Right now the only way
> >is to open a hex editor or as archiving software is instructed to ignore
> >the content of comment headers.  This is clearly a suboptimal situation.
> 
> There is git get-tar-commit-id, which prints the commit ID if it
> finds a comment entry which looks like a hexadecimal SHA-1 hash.
> It's better than a hex editor at least. :)

This is incredibly fuzzy and can get wrong for a pleothora of reasons.
I hope you agree though that the situation is suboptimal, git is doing
the equivalent of using a custom file format without an easily
recognizable magic number.

> But I'm still interested how you got a collection of tar files with
> unknown origin.  Just curious.

Easy: Just download the (source) distribution archives of a distribution
of choice and try to verify that the tarballs they use to compile their
packages actually come from the project's public git repositories.

There are other reasons why an easily detectable git hash might be
useful.  For example, file(1) could show that the archive comes from
git.  Other utilities could use this to work around git-specific bugs.
An unpacker could add corresponding meta-data when unpacking the file.

> >>>It would be much more useful if git created a
> >>>custom key. As per POSIX suggestions, something like this would be
> >>>appropriate:
> >>>
> >>> GIT.commit=57ca140635bf157354124e4e4b3c8e1bde2832f1
> >>
> >>This would be included in addition to the comment in order to avoid
> >>breaking existing users, I guess.
> >
> >Good point.  I'm not sure how many user use the comment header at all.
> 
> Apart from git get-tar-commit-id I don't know any program for
> extracting pax comments.  And I don't know how widely used that is,
> but I assume there is *someone* out there, extracting commit IDs
> with it.

Neither do I.  But remember, POSIX explicitly specifies that programs
that parse pax file must ignore pax comments so an unpacker that
interpretes the content of such a comment in any way is in violation of
the pax specification.

> >>If you have a random archive and want to know if it was generated by
> >>git then your next question might be which options and substitutions
> >>were used.  That reminds me of this thread regarding verifiable
> >>archives:
> >>
> >> http://article.gmane.org/gmane.comp.version-control.git/240244
> >
> >Good point.  Something like this should be enough to be enough to have
> >reproducable archives if archives with a tree ID were to have a time
> >stamp of 0 (1970-01-01) instead of the current date:
> >
> > comment=...(for compatibility)
> > GIT.commit=... (like comment)
> > GIT.umask=...  (tar.umask)
> > GIT.prefix=... (--prefix=)
> > GIT.path=...   (see below
> > GIT.export-subst=1 (in extended header instead of global header)
> >
> >A different key such as GIT.treeish might be appropriate.  The
> >GIT.export-subst key should be set only for those files where a
> >substitution has taken place.
> 
> What would GIT.export-subst contain? There can be multiple
> replacements in a file.

GIT.export-subst would only contain a 1 if substitution is turned on.
The goal is to have reproduceable archives, not the ability to turn an
archive back into a git repository.

> >Maybe there should also be an
> >GIT.original-name key.
> 
> What would it be used for?

In case an export substition changes the file name so the implementation
can verify that the original file could plausibly have been substituted
into the current name.  Also for the case where multiple files
substitute into the same name to tell which file git should check
equivalency with.

> >An option GIT.export-ignore is not required.  Instead it would be more
> >useful to have a special file type G (for git) with the convention that
> >the file name .gitattributes means “attributes that apply to this git
> >archive.”
> 
> That would be a non-standard extension.  Archivers would extract
> these as regular files.  Storing a list of excluded paths (in
> GIT.exclude or so) might be a better idea.

No, that's not a good idea as pax headers are interpreted as “attributes
pertaining to a file.”  A file doesn't have the attribute 

Re: [PATCH v3 1/6] worktree: new repo extension to manage worktree behaviors

[Junio C Hamano]

Nguyễn Thái Ngọc Duy   writes:

> Multiple worktree setup is still evolving and its behavior may be
> changed in future. But we do not want to break existing worktree

s/be changed/change/

> setups. A new set of extensions, worktree=X, is recognized to tell Git
> what multiple worktree "version" is being used so that Git can
> behavior accordingly.

s/behavior/behave/

> +WORKTREE VERSIONS AND MIGRATION
> +---
> +Multiple worktree is still an experimental feature and evolving. Every
> +time the behavior is changed, the "worktree version" is stepped
> +up. Worktree version is stored as a configuration variable
> +extensions.worktree.

s/stepped up/incremented/

More seriously, are we confident that the overall worktree support
is mature enough by now that once we add an experimental feature X
at version 1, we can promise to keep maintaining it forever at
version N for any positive integer N?  I hate to sound overly
negative, but I am getting an impression that we are not quite
there, and it is still not ready for production use.

It would be beneficial both for us and our users if we can keep our
hand untied for at least several more releases to allow us try
various random experimental features, fully intending to drop any of
them if the ideas do not pan out.

--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v3 0/6] Split .git/config in multiple worktree setup

[Junio C Hamano]

Nguyễn Thái Ngọc Duy   writes:

> For any worktree, the new file .git/common/config is read first, then
> either .git/config or .git/worktrees/xxx/config is read after. There's
> no special per-worktree var list any more. Which is great. You want to
> add per-worktree config vars, use "git config --local". You want to
> add per-repo config vars, use (new) "git config --repo". You put a
> variable in a wrong file, you're punished for it (and it's the same
> today, say if you put core.worktree to /etc/gitconfig).

I think this is saner than the one before.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v2 1/3] git: remove an early return from save_env_before_alias()

[Junio C Hamano]

Junio C Hamano  writes:

> Duy Nguyen  writes:
>
>> On Wed, Jan 27, 2016 at 1:49 PM, Junio C Hamano  wrote:
>>> Junio C Hamano  writes:
>>>
 I spoke too soon, I am afraid.
 ...
 I wonder if this would be better done as a multi-part series that
 goes like this:
 ...
>>>
>>> So here is the first of the three-patch series to replace it.
>>
>> This is much better (the whole series, not just the first patch). We
>> probably should add a test about help.autocorrect though, maybe in the
>> first patch, because it's not tested at all in the test suite.
>
> Patches welcome.  Thanks.

Here is an updated 1/3; this feature does not fit very well to any
category (it is certainly not basic, or command that is primarily
about objects or worktree; I just picked "Git tools" t9xxx as that
is the closest thing to "direct end user support").

-- >8 --
When help.autocorrect is in effect, an attempt to auto-execute an
uniquely corrected result of a misspelt alias will result in an
irrelevant error message.  The codepath that causes this calls
save_env_before_alias() and restore_env() in handle_alias(), and
that happens twice.  A global variable orig_cwd is allocated to hold
the return value of getcwd() in save_env_before_alias(), which is
then used in restore_env() to go back to that directory and finally
free(3)'d there.

However, save_env_before_alias() is not prepared to be called twice.
It returns early when it knows it has already been called, leaving
orig_cwd undefined, which is then checked in the second call to
restore_env(), and by that time, the memory that used to hold the
contents of orig_cwd is either freed or reused to hold something
else, and this is fed to chdir(2), causing it to fail.  Even if it
did not fail (i.e. reading of the already free'd piece of memory
yielded a directory path that we can chdir(2) to), it then gets
free(3)'d.

Fix this by making sure save_env() does do the saving when called.

While at it, add a minimal test for help.autocorrect facility.

Signed-off-by: Junio C Hamano 
---
 git.c   |  2 --
 t/t9003-help-autocorrect.sh | 52 +
 2 files changed, 52 insertions(+), 2 deletions(-)
 create mode 100755 t/t9003-help-autocorrect.sh

diff --git a/git.c b/git.c
index 98d4412..a57a4cb 100644
--- a/git.c
+++ b/git.c
@@ -30,8 +30,6 @@ static int saved_env_before_alias;
 static void save_env_before_alias(void)
 {
int i;
-   if (saved_env_before_alias)
-   return;
saved_env_before_alias = 1;
orig_cwd = xgetcwd();
for (i = 0; i < ARRAY_SIZE(env_names); i++) {
diff --git a/t/t9003-help-autocorrect.sh b/t/t9003-help-autocorrect.sh
new file mode 100755
index 000..dfe95c9
--- /dev/null
+++ b/t/t9003-help-autocorrect.sh
@@ -0,0 +1,52 @@
+#!/bin/sh
+
+test_description='help.autocorrect finding a match'
+. ./test-lib.sh
+
+test_expect_success 'setup' '
+   # An alias
+   git config alias.lgf "log --format=%s --first-parent" &&
+
+   # A random user-defined command
+   write_script git-distimdistim <<-EOF &&
+   echo distimdistim was called
+   EOF
+
+   PATH="$PATH:." &&
+   export PATH &&
+
+   git commit --allow-empty -m "a single log entry" &&
+
+   # Sanity check
+   git lgf >actual &&
+   echo "a single log entry" >expect &&
+   test_cmp expect actual &&
+
+   git distimdistim >actual &&
+   echo "distimdistim was called" >expect &&
+   test_cmp expect actual
+'
+
+test_expect_success 'autocorrect showing candidates' '
+   git config help.autocorrect 0 &&
+
+   test_must_fail git lfg 2>actual &&
+   sed -e "1,/^Did you mean this/d" actual | grep lgf &&
+
+   test_must_fail git distimdist 2>actual &&
+   sed -e "1,/^Did you mean this/d" actual | grep distimdistim
+'
+
+test_expect_success 'autocorrect running commands' '
+   git config help.autocorrect -1 &&
+
+   git lfg >actual &&
+   echo "a single log entry" >expect &&
+   test_cmp expect actual &&
+
+   git distimdist >actual &&
+   echo "distimdistim was called" >expect &&
+   test_cmp expect actual
+'
+
+test_done
-- 
2.7.0-368-gb6e04f9

--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: GPL v2 authoritative answer on stored code as a derived work

[Philip Oakley]

From: "Junio C Hamano" 

Jonathan Smith  writes:


It's pretty clear that code stored in a Git repository isn't
considered a derived work of Git, regardless of whether it is used
in a commercial context or otherwise.


I'm guessing here, but I suspect that while its 'pretty clear' to Jonathan, 
that he has met others who aren't so clear or trusting, and it's that 
distrustful community that would need convincing.




However, I'm unable to find this stated in any authoritative and
unambiguous manner.


The GPL2 FAQ's (search for 'data')
http://www.gnu.org/licenses/old-licenses/gpl-2.0-faq.en.html#TOCGPLOutput 
(should link to "Is there some way that I can GPL the output people get from 
use of my program? For example, if my program is used to develop hardware 
designs, can I require that these designs must be free?") and 
http://www.gnu.org/licenses/old-licenses/gpl-2.0-faq.en.html#IfInterpreterIsGPL 
both cover the fact that the repo (data) is not a derived work, and thus not 
subject to GPL2.




Is it reasonable to ask for such a statement?  I doubt it,
especially if "It's pretty clear".


(Rhet) If there were to be such a statement, where should it be placed, and 
who could issue it? It couldn't be part of the COPYING licence file (because 
it's not supposed to be modified).


It could be in the User Manual, but that wouldn't carry much weight with the 
already worried, or perhaps the git(1) man page [E.g. 'discusssion' section 
maybe], or even in the git-scm.com 'book', but really it would need Jonathan 
(and others with similar FUD issues) to suggest what they'd need.




Without such a statement, I think we have already seen that the
commercial adoption is already appealing.



Hopefully the links can help Jonathan if he is having any local 
difficulties.


--
Philip 


--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v3 4/6] worktree: new config file hierarchy

[Junio C Hamano]

Nguyễn Thái Ngọc Duy   writes:

> ($C stands for $GIT_COMMON_DIR for the rest of the message)
>
> In main worktree, we read these config files in this order:
>
> 1) system config
> 2) XDG config
> 3) user config
> 4) $GIT_DIR/config
>
> Currently linked worktrees share the same config file at step 4 with
> main worktree. The problem is, not all config variables can be
> shared. We need per-repo vars and per-worktree ones.
>
> With this patch, since worktree v1, the repo config file (or worktree
> config file in multi worktree context) is no longer shared. Main
> worktree reads $C/config.  Linked worktrees read $C/worktrees/xxx/config
> and a new file, $C/worktrees/config. Sharing is done via this new
> file. The read hierarchy for a worktree becomes
>
> 1) system config
> 2) XDG config
> 3) user config
> 4) $C/common/config
> 5) $C/worktrees/xxx/config (or $C/config for main worktree)
>
> Compare to an alternative scheme where $C/config contains both shared
> variables and main-worktree-only ones, this is a cleaner design.
>
> * We do not have to check every single variable name to see if it's
>   shared or per-worktree when reading config files.
>
> * We do not enforce any particular variable split. If a variable
>   is in $C/worktrees/config, it is shared. Putting core.worktree in
>   $C/worktrees/config is punished the same way the variable is put in
>   $HOME/.gitconfig, for example.
>
> * We will provide a new "git config --repo" to access this new config
>   file. In single-worktree context, or worktree v0, --repo is an alias
>   of --local.
>
> There is one problem though. We store worktree version in config file
> and expect that all worktrees must share the same version (i.e. read
> the same config file). But the share-ness of per-repo config files is
> changed based on worktree version. Where do we put extensions.worktree
> then?

I cannot see why it cannot live in $C/common/config, which would be
read as the fourth alternative in your earlier enumeration.  What I
am missing?
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v2 3/3] git: simplify environment save/restore logic

[Junio C Hamano]

The only code that cares about the value of the global variable
saved_env_before_alias after the previous fix is handle_builtin()
that turns into a glorified no-op when the variable is true, so the
logic could safely be lifted to its caller, i.e. the caller can
refrain from calling it when the variable is set.

This variable tells us if save_env_before_alias() was called (with
or without matching restore_env()), but the sole caller of the
function, handle_alias(), always calls it as the first thing, so we
can consider that the variable essentially keeps track of the fact
that handle_alias() has ever been called.

It turns out that handle_builtin() and handle_alias() are called
only from one function in a way that the value of the variable
matters, which is run_argv(), and it already keeps track of the
fact that it already called handle_alias().

So we can simplify the whole thing by:

- Change handle_builtin() to always make a direct call to the
  builtin implementation it finds, and make sure the caller
  refrains from calling it if handle_alias() has ever been
  called;

- Remove saved_env_before_alias variable, and instead use the
  local "done_alias" variable maintained inside run_argv() to
  make the same decision.

Signed-off-by: Junio C Hamano 
---

 * Patches 2 and 3 are with updated log messages; their patch text
   did not change.

 git.c | 29 ++---
 1 file changed, 14 insertions(+), 15 deletions(-)

diff --git a/git.c b/git.c
index e39b972..c8d7b56 100644
--- a/git.c
+++ b/git.c
@@ -25,13 +25,11 @@ static const char *env_names[] = {
GIT_PREFIX_ENVIRONMENT
 };
 static char *orig_env[4];
-static int saved_env_before_alias;
 static int save_restore_env_balance;
 
 static void save_env_before_alias(void)
 {
int i;
-   saved_env_before_alias = 1;
 
assert(save_restore_env_balance == 0);
save_restore_env_balance = 1;
@@ -533,16 +531,8 @@ static void handle_builtin(int argc, const char **argv)
}
 
builtin = get_builtin(cmd);
-   if (builtin) {
-   /*
-* XXX: if we can figure out cases where it is _safe_
-* to do, we can avoid spawning a new process when
-* saved_env_before_alias is true
-* (i.e. setup_git_dir* has been run once)
-*/
-   if (!saved_env_before_alias)
-   exit(run_builtin(builtin, argc, argv));
-   }
+   if (builtin)
+   exit(run_builtin(builtin, argc, argv));
 }
 
 static void execv_dashed_external(const char **argv)
@@ -586,8 +576,17 @@ static int run_argv(int *argcp, const char ***argv)
int done_alias = 0;
 
while (1) {
-   /* See if it's a builtin */
-   handle_builtin(*argcp, *argv);
+   /*
+* If we tried alias and futzed with our environment,
+* it no longer is safe to invoke builtins directly in
+* general.  We have to spawn them as dashed externals.
+*
+* NEEDSWORK: if we can figure out cases
+* where it is safe to do, we can avoid spawning a new
+* process.
+*/
+   if (!done_alias)
+   handle_builtin(*argcp, *argv);
 
/* .. then try the external ones */
execv_dashed_external(*argv);
@@ -598,9 +597,9 @@ static int run_argv(int *argcp, const char ***argv)
 */
if (done_alias)
break;
+   done_alias = 1;
if (!handle_alias(argcp, argv))
break;
-   done_alias = 1;
}
 
return done_alias;
-- 
2.7.0-368-gb6e04f9

--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v2 3/3] git: simplify environment save/restore logic

[Junio C Hamano]

Junio C Hamano  writes:

> @@ -598,9 +597,9 @@ static int run_argv(int *argcp, const char ***argv)
>*/
>   if (done_alias)
>   break;
> + done_alias = 1;
>   if (!handle_alias(argcp, argv))
>   break;
> - done_alias = 1;
>   }
>  
>   return done_alias;

This hunk shouldn't be there; it changes the return value from this
function and breaks the whole thing.

What I will push out as part of 'pu' will have this fixed.

--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Starting on a microproject for GSoC

[Stefan Beller]

On Wed, Jan 27, 2016 at 4:40 PM, Moritz Neeb  wrote:
> Hi git developers,
>
> the next Google Summer of Code is not too far away. I expect git to
> apply for it and hopefully have some student spots which in turn I plan
> to apply. It was recommended elsewhere and on this list as well, that it
> is beneficial to engage with the community early, that's why I am
> writing to you already now, before all this formal stuff has begun.
>
> Before I may introduce myself: I'm a Computer Science student in
> Germany, coming towards the end of my Masters. I am an enthusiastic git
> user that's why I'd like to give something back.

Giving back is a noble thing. To have most fun at it, you need to ask yourself:
What is the most obnoxious part of Git that you personally use? What was
the latest problem you had, which you'd want to fix? If you identified
that, is that the right size to fix it? (Usually it is way bigger than thought,
but you can ask around if there are approaches for solving that problem ;)

> This would be my first
> time to actually contribute to a FOSS project and I am quite excited
> (also a bit frightened ;)).

Each FLOSS project is run differently. So in case your fright
was the right instinct, go for some other project, it will be totally different.

>
> As the list of available microprojects 2016 is still to be created, I
> might need your help in finding a project to work on. I started to dig
> through the archives along items of the list of 2015 [0] and so far
> found out the following:

Some smaller starter projects may be found at
http://git-blame.blogspot.com/p/leftover-bits.html
The size and difficulty of these projects may vary
a bit more than the micro projects for GSoC though.

>
> The first task, to make "git -C '' cmd" not to barf seems to be solved.
> I tried it with "git -C '' status" at least. I could not find the
> related patch, maybe it did use other keywords. I would be interested.
>
> The second task, to allow "-" as a short-hand for "@{-1}" in more places
> seems to be still open for reset, although someone almost finished it
> (cf. $gmane/265417). I suppose just fixing/revising this would be kind
> of a too low hanging fruit? More interesting (also because I am a bit
> earlier) might be to unify everything, as suggested by Junio in
> $gmane/265260. Or implementing it for another branch command, e.g. rebase.
>
> The other tasks I did not yet dig into.
>
> If all of that is considered as not relevant, I might just go for a
> newer idea, like converting strbuf_getline_lf() callers to
> strbuf_getline(), as suggested in $gmane/284104.
>
> Any thoughts?
>
> A question regarding the process of "taking a task (or bug)" in general:
> Is it solely organized through the mailing list?

Yes, I'd say 95% of the discussion is done on the mailing list.
(The remaining 5% is done on conferences,
or privately for security related stuff I'd assume)

> Suppose I start to work
> on something, should I announce it to not risk work duplication?

[In the context of fighting procrastination,] I recently read that announcing
that you are going to work on $FOO is not necessarily helpful
for actually doing it. Chances are lower that you actually finish a
thing which you announced.

However feel free to announce what you work on. Usually people don't.

> Does it
> happen often that more people accidentally work on the same task?

It happens rarely for larger goals. For the GSoc micro projects however
some students did the same thing with slight differences. (2015 we only
had 2 spots to fill but a few more applicants (3-5?), but seeing
how students approached the same problem helped on deciding whom
to mentor. (Given different problems it would have been harder.)

>
> Best,
> Moritz
>
> [0] http://git.github.io/SoC-2015-Microprojects.html

I just realized there are some micro projects on the 2014 page
as well which haven't been solved yet. (maybe, they are not
striked through)

Thanks,
Stefan
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: eol round trip Was: [PATCH] travis-ci: run previously failed ....

[Torsten Bögershausen]

On 01/27/2016 08:05 PM, Junio C Hamano wrote:
(Changed the topic, 2 notes inside)

Clemens Buchacher  writes:


Coming back to "[PATCH] optionally disable gitattributes": The topics
are related, because they both deal with the situation where the work
tree has files which are not normalized according to gitattributes. But
my patch is more about saying: ok, I know I may have files which need to
be normalized, but I want to ignore this issue for now. Please disable
gitattributes for now, because I want to work with the files as they are
committed. Conversely, the discussion here is about how to reliably
detect and fix files which are not normalized.

git ls-files --eol can detect that (as Junio pointed out)


I primarily wanted to make sure that you understood the underlying
issue, so that I do not have to go back to the basics in the other
thread.  And it is clear that you obviously do, which is good.

Here, you seem to think that what t0025 wants to see happen is
sensible, judging by the fact that you call "rm .git/index && git
reset" a "fix".

My take on this is quite different.  After a "reset --hard HEAD", we
should be able to trust the cached stat information and have "diff
HEAD" say "no changes".  That is what you essentially want in the
other thread, if I understand you correctly, and in an ideal world
where the filesystem timestamp has infinite precision, that is what
would happen in t0025, always "breaking" its expectation.  The real
world has much coarser timestamp granularity than ideal, and that is
why the test appear to be "flaky", failing to give "correct" outcome
some of the time--but I'd say that it is expecting a wrong thing.

An index entry that has data that does not round-trip when it goes
through convert_to_working_tree() and then convert_to_git() "breaks"
this arrangement, and I'd view it as the user having an inconsistent
data.  It is like you are in a repository that still has an unmerged
paths--you cannot proceed before you resolve them.

This is actually bringing some light to me: the round-trip test.
There are this "well known but less well document" situations where we 
break that rule:

- files are checked in with CRLF into the repo.
- .gittatributes is set to "text" later.
2 different ways to handle it:
- keep the eol at checkout, normalize at checkin -> roundtrip broken
- keep the eol at checkout and checkin -> roundtrip OK

- files with mixed line endings in the repo:
Same here: 2 different ways to handle it:
- keep the eol at checkout, normalize at checkin -> roundtrip broken
- keep the eol at checkout and checkin -> roundtrip OK

- files with CRCRLF line endings in the repo:
Same here: 2 different ways to handle it:
- keep the eol at checkout, normalize at checkin -> roundtrip broken
- keep the eol at checkout and checkin -> roundtrip OK

My feeling is that we should simply say:
You user set attribute to "text" and by doing that, you promised to have 
files

with LF only in the index.
If you break that promise, Git does  not know, what you really want.
- It may be a situation where you write a shell script which for some 
reasons
  needs a '\015' at the end of a line, and Git may treat it wrong by 
assuming

  that this is a CRLF line ending (end converts it into LF)
- It may be that you want CRLF because you added a Windows .BAT file.
  It may be that you use git.git and another implementation of Git, 
which doesn't
  support attributes at all, so that a save way to do this is to just 
commit CRLF.

- It may be that this is a historical issue.
  Everybody using the project uses git that understands .gitattributes,
  so someone may fix it some day.

Can Git make this decision ?

When core.autocrlf is true (and no attributes are set), then the 
conversion of line ending is disabled.

On 01/27/2016 08:05 PM, Junio C Hamano wrote:
(Changed the topic, 2 notes inside)

Clemens Buchacher  writes:


Coming back to "[PATCH] optionally disable gitattributes": The topics
are related, because they both deal with the situation where the work
tree has files which are not normalized according to gitattributes. But
my patch is more about saying: ok, I know I may have files which need to
be normalized, but I want to ignore this issue for now. Please disable
gitattributes for now, because I want to work with the files as they are
committed. Conversely, the discussion here is about how to reliably
detect and fix files which are not normalized.

git ls-files --eol can detect that (as Junio pointed out)


I primarily wanted to make sure that you understood the underlying
issue, so that I do not have to go back to the basics in the other
thread.  And it is clear that you obviously do, which is good.

Here, you seem to think that what t0025 wants to see happen is
sensible, judging by the fact that you call "rm .git/index && git
reset" a "fix".

My take on this is quite different.  After a "reset --hard HEAD", we
should be able to trust the cached stat information 

Re: [PATCH] contrib/subtree: Split history with empty trees correctly

[Marcus Brinkmann]

On 01/28/2016 03:56 AM, David A. Greene wrote:

Marcus Brinkmann  writes:


With my patch, "git subtree split -P" produces the same result (for my
data set) as "git filter-branch --subdirectory-filter", which is much
faster, because it selects the revisions to rewrite before rewriting.
As I am not using any of the advanced features of "git subtree", I will
just use "git filter-branch" instead.


Heh.  :)

I hope to replace all that ugly split code with filter-branch as you
describe but there are some cases where it differs.  It may be that your
changes fix some of that.

Are you still able to do a re-roll on this?


I have to admit that my interest has declined steeply since discovering 
that subtree-split and filter-branch --subtree-filter give different 
results from "git svn" on the subdirectory.  The reason is that git-svn 
includes all commits for revisions that regular "svn log" gives on that 
directory, which includes commits that serve as branch points only or 
that are empty except for unhandled properties.


While empty commits for unhandled properties wouldn't be fatal, missing 
branch points make "git svn" really unhappy when asked to rebuild .git/svn.


As migration from SVN is my main motivation at this point to use a 
subtree filter at this point (git-svn is just very slow - about one week 
on our repository), I am somewhat stuck and back to using git-svn. 
Although hacking up something with filter-branch seems like a remote 
option, it's probably nothing that generalizes.


It didn't help that "make test" in contrib/subtree gives me 27 out of 29 
failed tests (with no indication how to figure out what exactly failed).


Oh well :)

Marcus
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] contrib/subtree: Split history with empty trees correctly

[David A. Greene]

[ Sorry it took a few days to reply.  I am absolutely slammed at work
  and will be for the next few weeks at least.  The good news is that
  it's resulting in some nice work on git-subtree!  :) ]

Marcus Brinkmann  writes:

> On 01/20/2016 05:05 AM, David A. Greene wrote:
>> Marcus Brinkmann  writes:
>> 
>>> 'git subtree split' will fail if the history of the subtree has empty
>>> tree commits (or trees that are considered empty, such as submodules).
>>> This fix keeps track of this condition and correctly follows the history
>>> over such commits.
>> 
>> Thanks for working on this!  Please add a test to t7900-subtree.sh.
>
> I couldn't get the tests to run and I couldn't find documentation on how
> to run it.  If you enlighten me I can add a test :)

Just run "make test" in contrib/subtree.  You have to build git first.

>> Can you explain the logic here?  The old code appears to be using the
>> lack of a tree to filter out "mainline" commits from the subtree history
>> when splitting.  If that test is only done before seeing a proper
>> subtree commit and never after, then any commit mainline commit
>> following the first subtree commit in the rev list will miss being
>> marked with set_notree and the cache will not have the identity entry
>> added.
>> 
>> Test #36 in t7900-subtree.sh has a mainline commit listed after the
>> first subtree commit in the rev list, I believe.
>> 
>> I'm not positive your change is wrong, I'd just like to understand it
>> better.  I'd also like a comment explaining why it works so future
>> developers don't get confused.  Overall, I am trying to better comment
>> the code as I make my own changes.
>
> It's possible the patch does not work for some cases.  For example, I
> don't know how the rejoin variant of splits work.

I'm not so much worried about catching all cases of the bug you
identified, though it would be good if the patch did.  I'm much more
concerned about not causing a regression in existing functionality.

> Some observations:
>
> 1) The notree list is never actually used except to identify which
> commits have been visited in check_parents.

It's really verifying that we visited parents before children in the
split code, I think.  That seems like a good check to keep.

Let me make sure I understand your fix too.  Are you essentially
skipping empty commits when splitting?  You original patch said that
split failed but didn't say how.  Did git-subtree spit out an error
message, or did the failure manifest in some other way?  If I knew the
failure mode it might help me understand your changes better.

I see you explain the proble below (thanks!) but I'd still like to know
how you discovered it.  It will help in constructing a test.

> 2) I have no idea what use case is covered by the "if [ -n "$newparents"
> ]; then cache_set $rev $rev; fi".  I left it in purely for traditional
> reasons.  So, clarifying that would go a long way in understanding the
> code, and if there is a test for that, I will figure it out.

As far as I understand things, $newparents being non-empty means that
the commits parents were split out and $newparents contains the hashes
of the split commits, so that when this commit is split it can set up
the proper parent links.

If the commit doesn't have a tree in the subdirectory, then I *think*
the split codesimply sets the identity entry in the cache so that any
future commit that has this (empty) one as a parent will see it in the
$newparents list.  Since copy_or_skip checks for parents with empty
trees and does not link split commits to them, I don't understand the
purpose of including these commits in $newparents.

So you may very well be right that it just doesn't matter if we skip
these altogether.

> 3a) The bug happens because on the first commit that deletes the subdir,
> newparents will not be empty, and the "cache_set $rev $rev" will kick in
> and subsequently (when the subdir is added again) the history will
> divert into the $rev commit which is not rewritten, but part of the
> unsplit tree.  This seems very wrong to me!  See 2).

Ah, so the problem isn't empty commits per se, it's the fact that a
subdirectory was deleted and re-added.  That makes sense.  I didn't
understand that from your original commit message though I now remember
you discussed it in the first e-mail you sent.  It would be good to
clarify this in the final commit.

I agree that the behavior you describe is wrong.  So the fix basically
relies on the fact that there is some tree in the subdirectory, which
later gets deleted, but since "found_first_commit" triggered, we'll just
skip those empty commits and never see them in the cache so that when a
tree appears again we won't link to mainline commits.  Have I got it
right?

Currently the split code is all-or-nothing.  You split the whole history
or none of it.  Eventually I want to make it flexible enough to allow
splitting ranges of commits or individual 

Re: [PATCH] contrib/subtree: Split history with empty trees correctly

[David A. Greene]

Marcus Brinkmann  writes:

> With my patch, "git subtree split -P" produces the same result (for my
> data set) as "git filter-branch --subdirectory-filter", which is much
> faster, because it selects the revisions to rewrite before rewriting.
> As I am not using any of the advanced features of "git subtree", I will
> just use "git filter-branch" instead.

Heh.  :)

I hope to replace all that ugly split code with filter-branch as you
describe but there are some cases where it differs.  It may be that your
changes fix some of that.

Are you still able to do a re-roll on this?

  -David
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

NEW ARRIVALS, CISCO,CPU's,Memory, LAPTOP AND AVAYA

[Laison Computech Inc]

Dear Sir/Madam,

Clean tested working pulls CPUs and QTYs in stock.

115  X   X5650
65  X   E5410
75  X   X5660
145  X   E5530
100  X   E5645
40  X   X5680
75  X   X5690

Brand new sealed  IP phones and QTYs in stock.

55 x CP-7937G
77 x CP-7942G
54 x CP-7945G
75 x CP-7962G
..
45 x Avaya 9630
65 x Avaya 9641
55 x Avaya 9640

All NIB.

Here is our current stock list.

 SSD drives and 750 gig 2.5" sata drives

We also have
250 x i5 dell
133 x HP
360 x Lenevo
all grade A

Here is the qty in stock for laptops
 
150 x E6500 Dell Latitude E6500 Core 2 Duo 2.80GHz T9600 4GB 160GB DVD+/-RW Win 
7
 60 x E6510 Dell Ltitude E6510. 15.6" Intel Core i5- M520 @ 2.40GHz. 4GB. 320GB 
DVD+/-RW Win 7
30 X 8530P HP EliteBook 8530p 15.4" Laptop 2.53GHz Core 2 Duo T9400, 4GB RAM, 
160GB HDD, Win
100 x  8740W  HP EliteBook 8740w 17" 2.4Ghz Core i5 6GB 250GB Win 7 Pr
45 x 8760W HP EliteBook 8760W 17.3" 2nd Gen Intel Core i7 2.70GHz 8GB 320GB 
Windows 7 Pro
50 x DELL 6520Dell latitude e6520 15.6" i5-2520M 2.5Ghz, 8GB Ram, 500GB HD Win 
7 @ $115
120 x DELL 6420 Laptop Dell Latitude E6420 14" Intel Core i5 2.4Ghz 4GB RAM 
250GB HDD DVD Win 7
150 x T410 Lenovo ThinkPad Laptop T410s 14.1" 2.40GHz Core i5 4GB RAM 160GB Win 
7
180 x 8440P HP EliteBook 8440p 14" M520 Core i5 2.4GHz 4GB 250GB Win 7


Let me know if you're interested. We are very open to offers and willing to 
work with you to make sure that we have a deal.

Thank You
Barbara Johnson
Laison Computech Inc
210 N Scoring Ave,
Rialto California, 92376
Tel: +1-657-232-7047
Fax: +1-347-214-047
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCHv4 1/2] submodule: port resolve_relative_url from shell to C

[Stefan Beller]

Later on we want to automatically call `git submodule init` from
other commands, such that the users don't have to initialize the
submodule themselves.  As these other commands are written in C
already, we'd need the init functionality in C, too.  The
`resolve_relative_url` function is a large part of that init
functionality, so start by porting this function to C.

To create the tests in t0060, the function `resolve_relative_url`
was temporarily enhanced to write all inputs and output to disk
when running the test suite. The added tests in this patch are
a small selection thereof.

Signed-off-by: Stefan Beller 
Signed-off-by: Junio C Hamano 
---
 builtin/submodule--helper.c | 208 +++-
 git-submodule.sh|  81 +
 t/t0060-path-utils.sh   |  42 +
 3 files changed, 253 insertions(+), 78 deletions(-)

diff --git a/builtin/submodule--helper.c b/builtin/submodule--helper.c
index 8002187..13583d9 100644
--- a/builtin/submodule--helper.c
+++ b/builtin/submodule--helper.c
@@ -9,6 +9,210 @@
 #include "submodule-config.h"
 #include "string-list.h"
 #include "run-command.h"
+#include "remote.h"
+#include "refs.h"
+#include "connect.h"
+
+static char *get_default_remote(void)
+{
+   char *dest = NULL, *ret;
+   unsigned char sha1[20];
+   int flag = 0;
+   struct strbuf sb = STRBUF_INIT;
+   const char *refname = resolve_ref_unsafe("HEAD", 0, sha1, );
+
+   if (!refname)
+   die("No such ref: HEAD");
+
+   /* detached HEAD */
+   if (!strcmp(refname, "HEAD"))
+   return xstrdup("origin");
+
+   if (!skip_prefix(refname, "refs/heads/", ))
+   die(_("Expecting a full ref name, got %s"), refname);
+
+   strbuf_addf(, "branch.%s.remote", refname);
+   if (git_config_get_string(sb.buf, ))
+   ret = xstrdup("origin");
+   else
+   ret = dest;
+
+   strbuf_release();
+   return ret;
+}
+
+static int starts_with_dot_slash(const char *str)
+{
+   return str[0] == '.' && is_dir_sep(str[1]);
+}
+
+static int starts_with_dot_dot_slash(const char *str)
+{
+   return str[0] == '.' && str[1] == '.' && is_dir_sep(str[2]);
+}
+
+/*
+ * Returns 1 if it was the last chop before ':'.
+ */
+static int chop_last_dir(char **remoteurl, int is_relative)
+{
+   char *rfind = find_last_dir_sep(*remoteurl);
+   if (rfind) {
+   *rfind = '\0';
+   return 0;
+   }
+
+   rfind = strrchr(*remoteurl, ':');
+   if (rfind) {
+   *rfind = '\0';
+   return 1;
+   }
+
+   if (is_relative || !strcmp(".", *remoteurl))
+   die(_("cannot strip one component off url '%s'"),
+   *remoteurl);
+
+   free(*remoteurl);
+   *remoteurl = xstrdup(".");
+   return 0;
+}
+
+/*
+ * The `url` argument is the URL that navigates to the submodule origin
+ * repo. When relative, this URL is relative to the superproject origin
+ * URL repo. The `up_path` argument, if specified, is the relative
+ * path that navigates from the submodule working tree to the superproject
+ * working tree. Returns the origin URL of the submodule.
+ *
+ * Return either an absolute URL or filesystem path (if the superproject
+ * origin URL is an absolute URL or filesystem path, respectively) or a
+ * relative file system path (if the superproject origin URL is a relative
+ * file system path).
+ *
+ * When the output is a relative file system path, the path is either
+ * relative to the submodule working tree, if up_path is specified, or to
+ * the superproject working tree otherwise.
+ *
+ * NEEDSWORK: This works incorrectly on the domain and protocol part.
+ * remote_url  url  outcome  correct
+ * http://a.com/b  ../c http://a.com/c   yes
+ * http://a.com/b  ../../c  http://c no (domain should be kept)
+ * http://a.com/b  ../../../c   http:/c  no
+ * http://a.com/b  ../../../../chttp:c   no
+ * http://a.com/b  ../../../../../c.:c   no
+ */
+static char *relative_url(const char *remote_url,
+   const char *url,
+   const char *up_path)
+{
+   int is_relative = 0;
+   int colonsep = 0;
+   char *out;
+   char *remoteurl = xstrdup(remote_url);
+   struct strbuf sb = STRBUF_INIT;
+   size_t len = strlen(remoteurl);
+
+   if (is_dir_sep(remoteurl[len]))
+   remoteurl[len] = '\0';
+
+   if (!url_is_local_not_ssh(remoteurl) || is_absolute_path(remoteurl))
+   is_relative = 0;
+   else {
+   is_relative = 1;
+   /*
+* Prepend a './' to ensure all relative
+* remoteurls start with './' or '../'
+*/
+   if (!starts_with_dot_slash(remoteurl) &&
+   

[PATCHv4 2/2] submodule: port init from shell to C

[Stefan Beller]

By having the `init` functionality in C, we can reference it easier
from other parts in the code.

Signed-off-by: Stefan Beller 
Signed-off-by: Junio C Hamano 
---
 builtin/submodule--helper.c | 119 ++--
 git-submodule.sh|  39 +--
 2 files changed, 115 insertions(+), 43 deletions(-)

diff --git a/builtin/submodule--helper.c b/builtin/submodule--helper.c
index 13583d9..689c354 100644
--- a/builtin/submodule--helper.c
+++ b/builtin/submodule--helper.c
@@ -214,6 +214,119 @@ static int resolve_relative_url_test(int argc, const char 
**argv, const char *pr
return 0;
 }
 
+static int git_submodule_config(const char *var, const char *value, void *cb)
+{
+   return parse_submodule_config_option(var, value);
+}
+
+static void init_submodule(const char *path, const char *prefix, int quiet)
+{
+   const struct submodule *sub;
+   struct strbuf sb = STRBUF_INIT;
+   char *url = NULL;
+   char *upd = NULL;
+   char *cwd = xgetcwd();
+   const char *displaypath = relative_path(cwd, prefix, );
+
+   /* Only loads from .gitmodules, no overlay with .git/config */
+   gitmodules_config();
+
+   sub = submodule_from_path(null_sha1, path);
+
+   /*
+* Copy url setting when it is not set yet.
+* To look up the url in .git/config, we must not fall back to
+* .gitmodules, so look it up directly.
+*/
+   strbuf_reset();
+   strbuf_addf(, "submodule.%s.url", sub->name);
+   if (git_config_get_string(sb.buf, )) {
+   url = xstrdup(sub->url);
+
+   if (!url)
+   die(_("No url found for submodule path '%s' in 
.gitmodules"),
+   displaypath);
+
+   /* Possibly a url relative to parent */
+   if (starts_with_dot_dot_slash(url) ||
+   starts_with_dot_slash(url)) {
+   char *remoteurl;
+   char *remote = get_default_remote();
+   struct strbuf remotesb = STRBUF_INIT;
+   strbuf_addf(, "remote.%s.url", remote);
+   free(remote);
+
+   if (git_config_get_string(remotesb.buf, ))
+   /*
+* The repository is its own
+* authoritative upstream
+*/
+   remoteurl = xgetcwd();
+   url = relative_url(remoteurl, url, NULL);
+   strbuf_release();
+   free(remoteurl);
+   }
+
+   if (git_config_set(sb.buf, url))
+   die(_("Failed to register url for submodule path '%s'"),
+   displaypath);
+   if (!quiet)
+   printf(_("Submodule '%s' (%s) registered for path 
'%s'\n"),
+   sub->name, url, displaypath);
+   }
+
+   /* Copy "update" setting when it is not set yet */
+   strbuf_reset();
+   strbuf_addf(, "submodule.%s.update", sub->name);
+   if (git_config_get_string(sb.buf, ) && sub->update) {
+   upd = xstrdup(sub->update);
+   if (strcmp(sub->update, "checkout") &&
+   strcmp(sub->update, "rebase") &&
+   strcmp(sub->update, "merge") &&
+   strcmp(sub->update, "none")) {
+   fprintf(stderr, _("warning: unknown update mode '%s' 
suggested for submodule '%s'\n"),
+   upd, sub->name);
+   upd = xstrdup("none");
+   }
+   if (git_config_set(sb.buf, upd))
+   die(_("Failed to register update mode for submodule 
path '%s'"), displaypath);
+   }
+   strbuf_release();
+   free(cwd);
+   free(upd);
+   free(url);
+}
+
+static int module_init(int argc, const char **argv, const char *prefix)
+{
+   int quiet = 0;
+   int i;
+
+   struct option module_init_options[] = {
+   OPT_STRING(0, "prefix", ,
+  N_("path"),
+  N_("alternative anchor for relative paths")),
+   OPT__QUIET(, "Suppress output for initialzing a 
submodule"),
+   OPT_END()
+   };
+
+   const char *const git_submodule_helper_usage[] = {
+   N_("git submodule--helper init []"),
+   NULL
+   };
+
+   argc = parse_options(argc, argv, prefix, module_init_options,
+git_submodule_helper_usage, 0);
+
+   if (argc == 0)
+   die(_("Pass at least one submodule"));
+
+   for (i = 0; i < argc; i++)
+   init_submodule(argv[i], prefix, quiet);
+
+   return 0;
+}
+
 struct module_list {
const struct cache_entry **entries;
   

Re: Starting on a microproject for GSoC

[Andrew Ardill]

On 28 January 2016 at 11:40, Moritz Neeb  wrote:
> I suppose just fixing/revising this would be kind
> of a too low hanging fruit?

I am in no way qualified to speak to the majority of your post, but I
can't imagine anyone refusing your work because it was 'too low
hanging fruit'.

Indeed, the general gist of getting people to start with a
microproject has always appeared to help potential applicants
understand what it takes to get a patch accepted in git. As long as
the low hanging fruit is useful (your example of polishing a patchset
to get it into master is definitely useful, assuming the patchset is
useful) then I'd say go for it.

In the worst case, if you feel your contribution was not 'meaty'
enough, there is nothing to stop you working on some other problem, or
extending the first further. That said, I do remember previous
applicants trying to do as many microprojects as possible, leaving few
for other people.

Regards,

Andrew Ardill
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: git archive should use vendor extension in pax header

[fuz]

On Tue, Jan 26, 2016 at 11:06:25PM +0100, René Scharfe wrote:
> Am 24.01.2016 um 16:59 schrieb f...@fuz.su:
> >Right now, git archive creates a pax global header of the form
> >
> > comment=57ca140635bf157354124e4e4b3c8e1bde2832f1
> >
> >in tar archives it creates. This is suboptimal as as comments are
> >specified to be ignored by extraction software. It is impossible to
> >find out in an automatic way (short of guessing) that this is supposed
> >to be a commit hash.
> 
> This is only a problem if you don't know how a given tar files was
> created (or modified later).  How did you get into this situation?
> Or in other words: Please tell me more about your use case.

My situation is that I'm interested in knowing if an archive was created
by git so I can find out where the corresponding repository is and find
out which commit this archive was created from.  Right now the only way
is to open a hex editor or as archiving software is instructed to ignore
the content of comment headers.  This is clearly a suboptimal situation.

> >It would be much more useful if git created a
> >custom key. As per POSIX suggestions, something like this would be
> >appropriate:
> >
> > GIT.commit=57ca140635bf157354124e4e4b3c8e1bde2832f1
> 
> This would be included in addition to the comment in order to avoid
> breaking existing users, I guess.

Good point.  I'm not sure how many user use the comment header at all.

> If you have a random archive and want to know if it was generated by
> git then your next question might be which options and substitutions
> were used.  That reminds me of this thread regarding verifiable
> archives:
> 
> http://article.gmane.org/gmane.comp.version-control.git/240244

Good point.  Something like this should be enough to be enough to have
reproducable archives if archives with a tree ID were to have a time
stamp of 0 (1970-01-01) instead of the current date:

comment=...(for compatibility)
GIT.commit=... (like comment)
GIT.umask=...  (tar.umask)
GIT.prefix=... (--prefix=)
GIT.path=...   (see below
GIT.export-subst=1 (in extended header instead of global header)

A different key such as GIT.treeish might be appropriate.  The
GIT.export-subst key should be set only for those files where a
substitution has taken place. Maybe there should also be an
GIT.original-name key.

An option GIT.export-ignore is not required.  Instead it would be more
useful to have a special file type G (for git) with the convention that
the file name .gitattributes means “attributes that apply to this git
archive.”

The GIT.path option holds the paths that are being archived. It is a bit
tricky to get right.  The intent of POSIX pax headers is that each key
is an attribute that applies to a series of files.  In the case of a
global header, each key applies until it is overridden with a new
header or with a local header.  A GIT.path key should only apply to the
files that correspond to this path operant to git archive.  Thus, a new
GIT.path should be written frequently.  There should always be at least
one GIT.path.

It might be a good idea to be able to control the kind of metadata git
adds to the archive as to be able to not leak any confidential
information with git archive.  If you are interested I can try to make a
specification for these headers.

Yours sincerely,
Robert Clausecker

-- 
()  ascii ribbon campaign - for an 8-bit clean world 
/\  - against html email  - against proprietary attachments
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v2 2/3] git: protect against unbalanced calls to {save,restore}_env()

[Junio C Hamano]

We made sure that save_env_before_alias() does not skip saving the
environment when asked to (which led to use-after-free of orig_cwd
in restore_env() in the buggy version) with the previous step.

Protect against future breakage where somebody adds new callers of
these functions in an unbalanced fashion.

Signed-off-by: Junio C Hamano 
---
 git.c | 7 +++
 1 file changed, 7 insertions(+)

diff --git a/git.c b/git.c
index a57a4cb..e39b972 100644
--- a/git.c
+++ b/git.c
@@ -26,11 +26,15 @@ static const char *env_names[] = {
 };
 static char *orig_env[4];
 static int saved_env_before_alias;
+static int save_restore_env_balance;
 
 static void save_env_before_alias(void)
 {
int i;
saved_env_before_alias = 1;
+
+   assert(save_restore_env_balance == 0);
+   save_restore_env_balance = 1;
orig_cwd = xgetcwd();
for (i = 0; i < ARRAY_SIZE(env_names); i++) {
orig_env[i] = getenv(env_names[i]);
@@ -42,6 +46,9 @@ static void save_env_before_alias(void)
 static void restore_env(int external_alias)
 {
int i;
+
+   assert(save_restore_env_balance == 1);
+   save_restore_env_balance = 0;
if (!external_alias && orig_cwd && chdir(orig_cwd))
die_errno("could not move to %s", orig_cwd);
free(orig_cwd);
-- 
2.7.0-368-gb6e04f9

--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [RFC] tag-ref and tag object binding

[Jeff King]

On Wed, Jan 27, 2016 at 08:53:08AM +0100, Michael J Gruber wrote:

> > Yeah, definitely. My thinking was that `verify-tag` could learn a series
> > of optional consistency checks, enabled by command line options, and
> > verifying programs (or humans) could turn them on to avoid having to
> > replicate them manually. So something like:
> > 
> >   git verify-tag \
> > --verify-tagger-matches-key \
> > --verify-tag-matches-ref \ # or --verify-tag-matches=v2.0.0
> > v2.0.0
> > 
> > or to implement more specific policy, maybe an option to check for a
> > _specific_ tagger, either by email (as provided by gpg) or even key-id.
> > 
> > Those are all things that are not _too_ hard to do if you're willing to
> > parse gpg or git output, but we could make life easier for our callers.
> > And hopefully by asking for specific, concrete checks, it doesn't
> > introduce a false sense of security. I.e., we're not making a foolproof
> > tool; we're making building blocks that one could use for a more
> > foolproof tool.
> 
> OK, let's make a tool that helps fooling as well as proofing :)
> 
> I'll look into the tag header check. Maybe "--check-tagname"? "check"
> seems to imply less than "verify".

Yeah, I think that is fine (I actually wrote --check originally; I'm not
quite sure why I decided to change it).

> As for the gpg related stuff: We provide the full diagnostic output from
> gpg on request. But I think a mismatch between the signing key's uid and
> the taggers' name/email is more common than not,

Is it? I'd think if you are using that name with a signed tag, you would
bother to issue (and get people to sign) the matching uid. Certainly it
is the case for git and linux signatures, but I admit that it a pretty
small sampling size.

The bigger issue is that gpg seems to give us only _one_ uid, when there
may be several. E.g., Junio's v2.7.0 is signed by 96AFE6CB, which is a
sub-key that has several uids associated with it. The one that "git
verify-tag --raw" shows from gpg is gits...@pobox.com, which is good,
but I think that's just because it happens to be the first uid. Or maybe
there is some gpg arcana going on that I don't know about.

> and on the other hand a
> signature by a key identified by its uid is meaningless unless you keep
> your keyring tidy... We could punt on that and let users identify the
> key by any means that gpg allows, of course, and check that the
> signature comes from whatever "gpg --list-key " gives as
> long as it's unique.

Right, I think it's an open question whether people actually participate
in the web of trust. I don't have a good signature path to Junio's key,
but I happen to know what it is based on past interaction.

But then, I also do not really verify tags. Why would I? I routinely
fetch and run "make" on the result, and there is no cryptographic
protection there at all. Verifying tag signatures after a release seems
all but pointless. :)

I think for any of this to be useful, it has to be part of some tool
that is very opinionated on policy. E.g., imagine a post-fetch hook that
validated that each incoming commit was signed, and that the signer was
part of a whitelisted group of keys that you "somehow" got hold of
out-of-band for your project. That is not that useful for an open-source
project, but I could see the appeal for a proprietary development
environment.

-Peff
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v3 01/20] mingw: let's use gettext with MSYS2

[Johannes Schindelin]

This solves two problems:

- we now have proper localisation even on Windows

- we sidestep the infamous "BUG: your vsnprintf is broken (returned -1)"
  message when running "git init" (which otherwise prevents the entire
  test suite from running) because libintl.h overrides vsnprintf() with
  libintl_vsnprintf() [*1*]

The latter issue is rather crucial, as *no* test passes in Git for
Windows without this fix.

Footnote *1*: gettext_git=http://git.savannah.gnu.org/cgit/gettext.git
$gettext_git/tree/gettext-runtime/intl/libgnuintl.in.h#n380

Signed-off-by: Johannes Schindelin 
---
 config.mak.uname | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/config.mak.uname b/config.mak.uname
index 4b2e1b8..6b25661 100644
--- a/config.mak.uname
+++ b/config.mak.uname
@@ -560,7 +560,7 @@ else
NO_R_TO_GCC_LINKER = YesPlease
INTERNAL_QSORT = YesPlease
HAVE_LIBCHARSET_H = YesPlease
-   NO_GETTEXT = YesPlease
+   NO_GETTEXT =
USE_LIBPCRE= YesPlease
NO_CURL =
USE_NED_ALLOCATOR = YesPlease
-- 
2.7.0.windows.1.7.g55a05c8


--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v3 04/20] mingw: factor out Windows specific environment setup

[Johannes Schindelin]

From: Karsten Blees 

We will add more environment-related code to that new function
in the next patch.

Signed-off-by: Karsten Blees 
Signed-off-by: Johannes Schindelin 
---
 compat/mingw.c | 30 +-
 1 file changed, 17 insertions(+), 13 deletions(-)

diff --git a/compat/mingw.c b/compat/mingw.c
index 77a51d3..8d52c73 100644
--- a/compat/mingw.c
+++ b/compat/mingw.c
@@ -2047,6 +2047,22 @@ int xwcstoutf(char *utf, const wchar_t *wcs, size_t 
utflen)
return -1;
 }
 
+static void setup_windows_environment()
+{
+   /* on Windows it is TMP and TEMP */
+   if (!getenv("TMPDIR")) {
+   const char *tmp = getenv("TMP");
+   if (!tmp)
+   tmp = getenv("TEMP");
+   if (tmp)
+   setenv("TMPDIR", tmp, 1);
+   }
+
+   /* simulate TERM to enable auto-color (see color.c) */
+   if (!getenv("TERM"))
+   setenv("TERM", "cygwin", 1);
+}
+
 /*
  * Disable MSVCRT command line wildcard expansion (__getmainargs called from
  * mingw startup code, see init.c in mingw runtime).
@@ -2125,19 +2141,7 @@ void mingw_startup()
qsort(environ, i, sizeof(char*), compareenv);
 
/* fix Windows specific environment settings */
-
-   /* on Windows it is TMP and TEMP */
-   if (!mingw_getenv("TMPDIR")) {
-   const char *tmp = mingw_getenv("TMP");
-   if (!tmp)
-   tmp = mingw_getenv("TEMP");
-   if (tmp)
-   setenv("TMPDIR", tmp, 1);
-   }
-
-   /* simulate TERM to enable auto-color (see color.c) */
-   if (!getenv("TERM"))
-   setenv("TERM", "cygwin", 1);
+   setup_windows_environment();
 
/* initialize critical section for waitpid pinfo_t list */
InitializeCriticalSection(_cs);
-- 
2.7.0.windows.1.7.g55a05c8


--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v3 13/20] mingw: fix t9700's assumption about directory separators

[Johannes Schindelin]

This test assumed that there is only one directory separator (the
forward slash), not two equivalent directory separators.
However, on Windows, the back slash and the forward slash *are*
equivalent.

Let's paper over this issue by converting the backward slashes to
forward ones in the test that fails with MSYS2 otherwise.

Signed-off-by: Johannes Schindelin 
---
 t/t9700/test.pl | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/t/t9700/test.pl b/t/t9700/test.pl
index 1140767..7e8c40b 100755
--- a/t/t9700/test.pl
+++ b/t/t9700/test.pl
@@ -33,7 +33,7 @@ is($r->config_int("test.int"), 2048, "config_int: integer");
 is($r->config_int("test.nonexistent"), undef, "config_int: nonexistent");
 ok($r->config_bool("test.booltrue"), "config_bool: true");
 ok(!$r->config_bool("test.boolfalse"), "config_bool: false");
-is($r->config_path("test.path"), $r->config("test.pathexpanded"),
+is($r->config_path("test.path") =~ s/\\/\//gr, $r->config("test.pathexpanded"),
"config_path: ~/foo expansion");
 is_deeply([$r->config_path("test.pathmulti")], ["foo", "bar"],
"config_path: multiple values");
-- 
2.7.0.windows.1.7.g55a05c8


--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v3 07/20] mingw: let lstat() fail with errno == ENOTDIR when appropriate

[Johannes Schindelin]

POSIX semantics requires lstat() to fail with ENOTDIR when "[a]
component of the path prefix names an existing file that is neither a
directory nor a symbolic link to a directory".

See http://pubs.opengroup.org/onlinepubs/9699919799/functions/lstat.html

This behavior is expected by t1404-update-ref-df-conflicts now.

Signed-off-by: Johannes Schindelin 
---
 compat/mingw.c | 39 +++
 1 file changed, 39 insertions(+)

diff --git a/compat/mingw.c b/compat/mingw.c
index f37f8d5..fbe69b8 100644
--- a/compat/mingw.c
+++ b/compat/mingw.c
@@ -454,6 +454,39 @@ static inline time_t filetime_to_time_t(const FILETIME *ft)
return (time_t)(filetime_to_hnsec(ft) / 1000);
 }
 
+/**
+ * Verifies that safe_create_leading_directories() would succeed.
+ */
+static int has_valid_directory_prefix(wchar_t *wfilename)
+{
+   int n = wcslen(wfilename);
+
+   while (n > 0) {
+   wchar_t c = wfilename[--n];
+   DWORD attributes;
+
+   if (!is_dir_sep(c))
+   continue;
+
+   wfilename[n] = L'\0';
+   attributes = GetFileAttributesW(wfilename);
+   wfilename[n] = c;
+   if (attributes == FILE_ATTRIBUTE_DIRECTORY ||
+   attributes == FILE_ATTRIBUTE_DEVICE)
+   return 1;
+   if (attributes == INVALID_FILE_ATTRIBUTES)
+   switch (GetLastError()) {
+   case ERROR_PATH_NOT_FOUND:
+   continue;
+   case ERROR_FILE_NOT_FOUND:
+   /* This implies parent directory exists. */
+   return 1;
+   }
+   return 0;
+   }
+   return 1;
+}
+
 /* We keep the do_lstat code in a separate function to avoid recursion.
  * When a path ends with a slash, the stat will fail with ENOENT. In
  * this case, we strip the trailing slashes and stat again.
@@ -514,6 +547,12 @@ static int do_lstat(int follow, const char *file_name, 
struct stat *buf)
case ERROR_NOT_ENOUGH_MEMORY:
errno = ENOMEM;
break;
+   case ERROR_PATH_NOT_FOUND:
+   if (!has_valid_directory_prefix(wfilename)) {
+   errno = ENOTDIR;
+   break;
+   }
+   /* fallthru */
default:
errno = ENOENT;
break;
-- 
2.7.0.windows.1.7.g55a05c8


--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v3 11/20] tests: turn off git-daemon tests if FIFOs are not available

[Johannes Schindelin]

The Git daemon tests create a FIFO first thing and will hang if said
FIFO is not available.

This is a problem with Git for Windows, where `mkfifo` is an MSYS2
program that leverages MSYS2's POSIX emulation layer, but
`git-daemon.exe` is a MINGW program that has not the first clue about
that POSIX emulation layer and therefore blinks twice when it sees
MSYS2's emulated FIFOs and then just stares into space.

This lets t5570-git-daemon.sh and t5811-proto-disable-git.sh pass.

Signed-off-by: Stepan Kasal 
Signed-off-by: Johannes Schindelin 
---
 t/lib-git-daemon.sh | 5 +
 1 file changed, 5 insertions(+)

diff --git a/t/lib-git-daemon.sh b/t/lib-git-daemon.sh
index bc4b341..9b1271c 100644
--- a/t/lib-git-daemon.sh
+++ b/t/lib-git-daemon.sh
@@ -23,6 +23,11 @@ then
test_done
 fi
 
+if ! test_have_prereq PIPE
+then
+   test_skip_or_die $GIT_TEST_GIT_DAEMON "file system does not support 
FIFOs"
+fi
+
 LIB_GIT_DAEMON_PORT=${LIB_GIT_DAEMON_PORT-${this_test#t}}
 
 GIT_DAEMON_PID=
-- 
2.7.0.windows.1.7.g55a05c8


--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v3 08/20] mingw: fix t5601-clone.sh

[Johannes Schindelin]

Since baaf233 (connect: improve check for plink to reduce false
positives, 2015-04-26), t5601 writes out a `plink.exe` for testing that
is actually a shell script. So the assumption that the `.exe` extension
implies that the file is *not* a shell script is now wrong.

Since there was no love for the idea of allowing `.exe` files to be
shell scripts on Windows, let's go the other way round: *make*
`plink.exe` a real `.exe`.

This fixes t5601-clone.sh in Git for Windows' SDK.

Signed-off-by: Johannes Schindelin 
---
 Makefile |  1 +
 t/t5601-clone.sh | 18 --
 test-fake-ssh.c  | 30 ++
 3 files changed, 39 insertions(+), 10 deletions(-)
 create mode 100644 test-fake-ssh.c

diff --git a/Makefile b/Makefile
index fc2f1ab..10566d6 100644
--- a/Makefile
+++ b/Makefile
@@ -583,6 +583,7 @@ TEST_PROGRAMS_NEED_X += test-delta
 TEST_PROGRAMS_NEED_X += test-dump-cache-tree
 TEST_PROGRAMS_NEED_X += test-dump-split-index
 TEST_PROGRAMS_NEED_X += test-dump-untracked-cache
+TEST_PROGRAMS_NEED_X += test-fake-ssh
 TEST_PROGRAMS_NEED_X += test-genrandom
 TEST_PROGRAMS_NEED_X += test-hashmap
 TEST_PROGRAMS_NEED_X += test-index-version
diff --git a/t/t5601-clone.sh b/t/t5601-clone.sh
index 669ec9b..c1efb8e 100755
--- a/t/t5601-clone.sh
+++ b/t/t5601-clone.sh
@@ -4,6 +4,9 @@ test_description=clone
 
 . ./test-lib.sh
 
+X=
+test_have_prereq !MINGW || X=.exe
+
 test_expect_success setup '
 
rm -fr .git &&
@@ -305,14 +308,9 @@ test_expect_success 'clone checking out a tag' '
 
 setup_ssh_wrapper () {
test_expect_success 'setup ssh wrapper' '
-   write_script "$TRASH_DIRECTORY/ssh-wrapper" <<-\EOF &&
-   echo >>"$TRASH_DIRECTORY/ssh-output" "ssh: $*" &&
-   # throw away all but the last argument, which should be the
-   # command
-   while test $# -gt 1; do shift; done
-   eval "$1"
-   EOF
-   GIT_SSH="$TRASH_DIRECTORY/ssh-wrapper" &&
+   cp "$GIT_BUILD_DIR/test-fake-ssh$X" \
+   "$TRASH_DIRECTORY/ssh-wrapper$X" &&
+   GIT_SSH="$TRASH_DIRECTORY/ssh-wrapper$X" &&
export GIT_SSH &&
export TRASH_DIRECTORY &&
>"$TRASH_DIRECTORY"/ssh-output
@@ -320,8 +318,8 @@ setup_ssh_wrapper () {
 }
 
 copy_ssh_wrapper_as () {
-   cp "$TRASH_DIRECTORY/ssh-wrapper" "$1" &&
-   GIT_SSH="$1" &&
+   cp "$TRASH_DIRECTORY/ssh-wrapper$X" "${1%$X}$X" &&
+   GIT_SSH="${1%$X}$X" &&
export GIT_SSH
 }
 
diff --git a/test-fake-ssh.c b/test-fake-ssh.c
new file mode 100644
index 000..980de21
--- /dev/null
+++ b/test-fake-ssh.c
@@ -0,0 +1,30 @@
+#include "git-compat-util.h"
+#include "run-command.h"
+#include "strbuf.h"
+
+int main(int argc, char **argv)
+{
+   const char *trash_directory = getenv("TRASH_DIRECTORY");
+   struct strbuf buf = STRBUF_INIT;
+   FILE *f;
+   int i;
+   const char *child_argv[] = { NULL, NULL };
+
+   /* First, print all parameters into $TRASH_DIRECTORY/ssh-output */
+   if (!trash_directory)
+   die("Need a TRASH_DIRECTORY!");
+   strbuf_addf(, "%s/ssh-output", trash_directory);
+   f = fopen(buf.buf, "w");
+   if (!f)
+   die("Could not write to %s", buf.buf);
+   for (i = 0; i < argc; i++)
+   fprintf(f, "%s%s", i > 0 ? " " : "", i > 0 ? argv[i] : "ssh:");
+   fprintf(f, "\n");
+   fclose(f);
+
+   /* Now, evaluate the *last* parameter */
+   if (argc < 2)
+   return 0;
+   child_argv[0] = argv[argc - 1];
+   return run_command_v_opt(child_argv, RUN_USING_SHELL);
+}
-- 
2.7.0.windows.1.7.g55a05c8


--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v3 14/20] mingw: work around pwd issues in the tests

[Johannes Schindelin]

In Git for Windows' SDK, the tests are run using a Bash that relies on
the POSIX emulation layer MSYS2 (itself a friendly fork of Cygwin). As
such, paths in tests can be POSIX paths. As soon as those paths are
passed to git.exe (which does *not* use the POSIX emulation layer),
those paths are converted into Windows paths, though. This happens
for command-line parameters, but not when reading, say, config variables.

To help with that, the `pwd` command is overridden to return the Windows
path of the current working directory when testing Git on Windows.

However, when talking to anything using the POSIX emulation layer, it is
really much better to use POSIX paths because Windows paths contain a
colon after the drive letter that will easily be mistaken for the common
separator in path lists.

So let's just use the $PWD variable when the POSIX path is needed.

This lets t7800-difftool.sh, t9400-git-cvsserver-server.sh,
t9402-git-cvsserver-refs.sh and t9401-git-cvsserver-crlf.sh pass in Git
for Windows' SDK.

Note: the cvsserver tests require not only the `cvs` package (install
it into Git for Windows' SDK via `pacman -S cvs`) but also the Perl
SQLite bindings (install them into Git for Windows' SDK via
`cpan DBD::SQLite`).

This patch is based on earlier work by 마누엘 and Karsten Blees.

Signed-off-by: Johannes Schindelin 
---
 t/t7800-difftool.sh | 14 +++---
 t/t9400-git-cvsserver-server.sh |  6 +++---
 t/t9401-git-cvsserver-crlf.sh   |  6 +++---
 t/t9402-git-cvsserver-refs.sh   |  6 +++---
 4 files changed, 16 insertions(+), 16 deletions(-)

diff --git a/t/t7800-difftool.sh b/t/t7800-difftool.sh
index ec8bc8c..4e713f7 100755
--- a/t/t7800-difftool.sh
+++ b/t/t7800-difftool.sh
@@ -430,11 +430,11 @@ EOF
 test_expect_success PERL,SYMLINKS 'difftool --dir-diff --symlink without 
unstaged changes' '
cat >expect <<-EOF &&
file
-   $(pwd)/file
+   $PWD/file
file2
-   $(pwd)/file2
+   $PWD/file2
sub/sub
-   $(pwd)/sub/sub
+   $PWD/sub/sub
EOF
git difftool --dir-diff --symlink \
--extcmd "./.git/CHECK_SYMLINKS" branch HEAD &&
@@ -448,14 +448,14 @@ EOF
 run_dir_diff_test 'difftool --dir-diff syncs worktree with unstaged change' '
test_when_finished git reset --hard &&
echo "orig content" >file &&
-   git difftool -d $symlinks --extcmd "$(pwd)/modify-right-file" branch &&
+   git difftool -d $symlinks --extcmd "$PWD/modify-right-file" branch &&
echo "new content" >expect &&
test_cmp expect file
 '
 
 run_dir_diff_test 'difftool --dir-diff syncs worktree without unstaged change' 
'
test_when_finished git reset --hard &&
-   git difftool -d $symlinks --extcmd "$(pwd)/modify-right-file" branch &&
+   git difftool -d $symlinks --extcmd "$PWD/modify-right-file" branch &&
echo "new content" >expect &&
test_cmp expect file
 '
@@ -466,7 +466,7 @@ EOF
 
 test_expect_success PERL 'difftool --no-symlinks does not overwrite working 
tree file ' '
echo "orig content" >file &&
-   git difftool --dir-diff --no-symlinks --extcmd "$(pwd)/modify-file" 
branch &&
+   git difftool --dir-diff --no-symlinks --extcmd "$PWD/modify-file" 
branch &&
echo "new content" >expect &&
test_cmp expect file
 '
@@ -482,7 +482,7 @@ test_expect_success PERL 'difftool --no-symlinks detects 
conflict ' '
TMPDIR=$TRASH_DIRECTORY &&
export TMPDIR &&
echo "orig content" >file &&
-   test_must_fail git difftool --dir-diff --no-symlinks --extcmd 
"$(pwd)/modify-both-files" branch &&
+   test_must_fail git difftool --dir-diff --no-symlinks --extcmd 
"$PWD/modify-both-files" branch &&
echo "wt content" >expect &&
test_cmp expect file &&
echo "tmp content" >expect &&
diff --git a/t/t9400-git-cvsserver-server.sh b/t/t9400-git-cvsserver-server.sh
index 6146c3f..d708cbf 100755
--- a/t/t9400-git-cvsserver-server.sh
+++ b/t/t9400-git-cvsserver-server.sh
@@ -25,11 +25,11 @@ perl -e 'use DBI; use DBD::SQLite' >/dev/null 2>&1 || {
 test_done
 }
 
-WORKDIR=$(pwd)
-SERVERDIR=$(pwd)/gitcvs.git
+WORKDIR=$PWD
+SERVERDIR=$PWD/gitcvs.git
 git_config="$SERVERDIR/config"
 CVSROOT=":fork:$SERVERDIR"
-CVSWORK="$(pwd)/cvswork"
+CVSWORK="$PWD/cvswork"
 CVS_SERVER=git-cvsserver
 export CVSROOT CVS_SERVER
 
diff --git a/t/t9401-git-cvsserver-crlf.sh b/t/t9401-git-cvsserver-crlf.sh
index 5a4ed28..f324b9f 100755
--- a/t/t9401-git-cvsserver-crlf.sh
+++ b/t/t9401-git-cvsserver-crlf.sh
@@ -74,11 +74,11 @@ perl -e 'use DBI; use DBD::SQLite' >/dev/null 2>&1 || {
 }
 
 unset GIT_DIR GIT_CONFIG
-WORKDIR=$(pwd)
-SERVERDIR=$(pwd)/gitcvs.git
+WORKDIR=$PWD
+SERVERDIR=$PWD/gitcvs.git
 git_config="$SERVERDIR/config"
 CVSROOT=":fork:$SERVERDIR"
-CVSWORK="$(pwd)/cvswork"
+CVSWORK="$PWD/cvswork"
 CVS_SERVER=git-cvsserver
 export CVSROOT CVS_SERVER

[PATCH v3 10/20] mingw: disable mkfifo-based tests

[Johannes Schindelin]

MSYS2 (the POSIX emulation layer used by Git for Windows' Bash) actually
has a working mkfifo. The only problem is that it is only emulating
named pipes through the MSYS2 runtime; The Win32 API has no idea about
named pipes, hence the Git executable cannot access those pipes either.

The symptom is that Git fails with a ': No such file or directory'
because MSYS2 emulates named pipes through special-crafted '.lnk' files.

The solution is to tell the test suite explicitly that we cannot use
named pipes when we want to test on Windows.

This lets t4056-diff-order.sh, t9010-svn-fe.sh and t9300-fast-import.sh
pass.

Signed-off-by: Johannes Schindelin 
---
 t/test-lib.sh | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/t/test-lib.sh b/t/test-lib.sh
index bd4b02e..1470c8d 100644
--- a/t/test-lib.sh
+++ b/t/test-lib.sh
@@ -998,7 +998,7 @@ test_i18ngrep () {
 test_lazy_prereq PIPE '
# test whether the filesystem supports FIFOs
case $(uname -s) in
-   CYGWIN*)
+   CYGWIN*|MINGW*)
false
;;
*)
-- 
2.7.0.windows.1.7.g55a05c8


--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v3 06/20] mingw: try to delete target directory before renaming

[Johannes Schindelin]

From: =?UTF-8?q?=EB=A7=88=EB=88=84=EC=97=98?= 

When the rename() function tries to move a directory it fails if the
target directory exists. It should check if it can delete the (possibly
empty) target directory and then try again to move the directory.

This partially fixes t9100-git-svn-basic.sh.

Signed-off-by: 마누엘 
Signed-off-by: Johannes Schindelin 
---
 compat/mingw.c | 7 ++-
 1 file changed, 6 insertions(+), 1 deletion(-)

diff --git a/compat/mingw.c b/compat/mingw.c
index ba5cb1c..f37f8d5 100644
--- a/compat/mingw.c
+++ b/compat/mingw.c
@@ -1603,7 +1603,12 @@ repeat:
if (gle == ERROR_ACCESS_DENIED &&
(attrs = GetFileAttributesW(wpnew)) != INVALID_FILE_ATTRIBUTES) {
if (attrs & FILE_ATTRIBUTE_DIRECTORY) {
-   errno = EISDIR;
+   DWORD attrsold = GetFileAttributesW(wpold);
+   if (attrsold == INVALID_FILE_ATTRIBUTES ||
+   !(attrsold & FILE_ATTRIBUTE_DIRECTORY))
+   errno = EISDIR;
+   else if (!_wrmdir(wpnew))
+   goto repeat;
return -1;
}
if ((attrs & FILE_ATTRIBUTE_READONLY) &&
-- 
2.7.0.windows.1.7.g55a05c8

[PATCH v3 15/20] Avoid absolute path in t0008

[Johannes Schindelin]

From: Pat Thoyts 

The colon is used by check-ignore to separate paths from other output
values. If we use an absolute path, however, on Windows it will be
converted into a Windows path that very much contains a colon.

It is actually not at all necessary to make the path of the global
excludes absolute, so let's just not even do that.

Based on suggestions by Karsten Blees and Junio Hamano.

Suggested-by: Karsten Blees 
Signed-off-by: Pat Thoyts 
Signed-off-by: Johannes Schindelin 
---
 t/t0008-ignores.sh | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/t/t0008-ignores.sh b/t/t0008-ignores.sh
index 4ef5ed4..89544dd 100755
--- a/t/t0008-ignores.sh
+++ b/t/t0008-ignores.sh
@@ -5,7 +5,7 @@ test_description=check-ignore
 . ./test-lib.sh
 
 init_vars () {
-   global_excludes="$(pwd)/global-excludes"
+   global_excludes="global-excludes"
 }
 
 enable_global_excludes () {
-- 
2.7.0.windows.1.7.g55a05c8


--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v3 12/20] mingw: skip test in t1508 that fails due to path conversion

[Johannes Schindelin]

In Git for Windows, the MSYS2 POSIX emulation layer used by the Bash
converts command-line arguments that looks like they refer to a POSIX
path containing a file list (i.e. @) into a Windows path
equivalent when calling non-MSYS2 executables, such as git.exe.

Let's just skip the test that uses the parameter `@/at-test` that
confuses the MSYS2 runtime.

Signed-off-by: Johannes Schindelin 
---
 t/t1508-at-combinations.sh | 6 +-
 1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/t/t1508-at-combinations.sh b/t/t1508-at-combinations.sh
index 078e119..4a9964e 100755
--- a/t/t1508-at-combinations.sh
+++ b/t/t1508-at-combinations.sh
@@ -35,7 +35,10 @@ test_expect_success 'setup' '
git checkout -b upstream-branch &&
test_commit upstream-one &&
test_commit upstream-two &&
-   git checkout -b @/at-test &&
+   if test_have_prereq !MINGW
+   then
+   git checkout -b @/at-test
+   fi &&
git checkout -b @@/at-test &&
git checkout -b @at-test &&
git checkout -b old-branch &&
@@ -64,6 +67,7 @@ check "@{-1}@{u}@{1}" commit master-one
 check "@" commit new-two
 check "@@{u}" ref refs/heads/upstream-branch
 check "@@/at-test" ref refs/heads/@@/at-test
+test_have_prereq MINGW ||
 check "@/at-test" ref refs/heads/@/at-test
 check "@at-test" ref refs/heads/@at-test
 nonsense "@{u}@{-1}"
-- 
2.7.0.windows.1.7.g55a05c8


--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v3 03/20] Git.pm: stop assuming that absolute paths start with a slash

[Johannes Schindelin]

On Windows, absolute paths never start with a slash, unless a POSIX
emulation layer is used. The latter is the case for MSYS2's Perl that
Git for Windows leverages. However, in the tests we also go through
plain `git.exe`, which does *not* leverage the POSIX emulation layer,
and therefore the paths we pass to Perl may actually be DOS-style paths
such as C:/Program Files/Git.

So let's just use Perl's own way to test whether a given path is
absolute or not instead of home-brewing our own.

This patch partially fixes t7800 and t9700 when running in Git for
Windows' SDK.

Signed-off-by: Johannes Schindelin 
---
 perl/Git.pm | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/perl/Git.pm b/perl/Git.pm
index 19ef081..49eb88a 100644
--- a/perl/Git.pm
+++ b/perl/Git.pm
@@ -188,7 +188,8 @@ sub repository {
};
 
if ($dir) {
-   $dir =~ m#^/# or $dir = $opts{Directory} . '/' . $dir;
+   _verify_require();
+   File::Spec->file_name_is_absolute($dir) or $dir = 
$opts{Directory} . '/' . $dir;
$opts{Repository} = abs_path($dir);
 
# If --git-dir went ok, this shouldn't die either.
-- 
2.7.0.windows.1.7.g55a05c8


--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v3 18/20] mingw: handle the missing POSIXPERM prereq in t9124

[Johannes Schindelin]

On Windows, the permission system works completely differently than
expected by some of the tests. So let's make sure that we do not test
POSIX functionality on Windows.

This lets t9124-git-svn-dcommit-auto-props.sh pass in Git for Windows'
SDK.

Signed-off-by: Johannes Schindelin 
---
 t/t9124-git-svn-dcommit-auto-props.sh | 16 ++--
 1 file changed, 10 insertions(+), 6 deletions(-)

diff --git a/t/t9124-git-svn-dcommit-auto-props.sh 
b/t/t9124-git-svn-dcommit-auto-props.sh
index aa841e1..9f7231d 100755
--- a/t/t9124-git-svn-dcommit-auto-props.sh
+++ b/t/t9124-git-svn-dcommit-auto-props.sh
@@ -34,8 +34,7 @@ test_expect_success 'enable auto-props config' '
 '
 
 test_expect_success 'add files matching auto-props' '
-   echo "#!$SHELL_PATH" >exec1.sh &&
-   chmod +x exec1.sh &&
+   write_script exec1.sh hello.txt &&
echo bar >bar &&
git add exec1.sh hello.txt bar &&
@@ -48,8 +47,7 @@ test_expect_success 'disable auto-props config' '
 '
 
 test_expect_success 'add files matching disabled auto-props' '
-   echo "#$SHELL_PATH" >exec2.sh &&
-   chmod +x exec2.sh &&
+   write_script exec2.sh world.txt &&
echo zot >zot &&
git add exec2.sh world.txt zot &&
@@ -65,7 +63,10 @@ test_expect_success 'check resulting svn repository' '
cd svnrepo &&
 
# Check properties from first commit.
-   test "x$(svn_cmd propget svn:executable exec1.sh)" = "x*" &&
+   if test_have_prereq POSIXPERM
+   then
+   test "x$(svn_cmd propget svn:executable exec1.sh)" = "x*"
+   fi &&
test "x$(svn_cmd propget svn:mime-type exec1.sh)" = \
 "xapplication/x-shellscript" &&
test "x$(svn_cmd propget svn:mime-type hello.txt)" = "xtext/plain" &&
@@ -73,7 +74,10 @@ test_expect_success 'check resulting svn repository' '
test "x$(svn_cmd propget svn:mime-type bar)" = "x" &&
 
# Check properties from second commit.
-   test "x$(svn_cmd propget svn:executable exec2.sh)" = "x*" &&
+   if test_have_prereq POSIXPERM
+   then
+   test "x$(svn_cmd propget svn:executable exec2.sh)" = "x*"
+   fi &&
test "x$(svn_cmd propget svn:mime-type exec2.sh)" = "x" &&
test "x$(svn_cmd propget svn:mime-type world.txt)" = "x" &&
test "x$(svn_cmd propget svn:eol-style world.txt)" = "x" &&
-- 
2.7.0.windows.1.7.g55a05c8


--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v3 17/20] mingw: avoid illegal filename in t9118

[Johannes Schindelin]

On Windows' file systems, file names with trailing dots are forbidden.
The POSIX emulation layer used by Git for Windows' Subversion emulates
those file names, therefore the test adding the file would actually
succeed, but when we would ask git.exe (which does not leverage the
POSIX emulation layer) to check out the tree, it would fail.

Let's just guard the test using a filename that is illegal on Windows
by the MINGW prereq.

This lets t9118-git-svn-funky-branch-names.sh pass in Git for Windows'
SDK.

Signed-off-by: Johannes Schindelin 
---
 t/t9118-git-svn-funky-branch-names.sh | 12 +---
 1 file changed, 9 insertions(+), 3 deletions(-)

diff --git a/t/t9118-git-svn-funky-branch-names.sh 
b/t/t9118-git-svn-funky-branch-names.sh
index a221915..ecb1fed 100755
--- a/t/t9118-git-svn-funky-branch-names.sh
+++ b/t/t9118-git-svn-funky-branch-names.sh
@@ -23,8 +23,11 @@ test_expect_success 'setup svnrepo' '
  "$svnrepo/pr ject/branches/$scary_uri" &&
svn_cmd cp -m "leading dot" "$svnrepo/pr ject/trunk" \
"$svnrepo/pr ject/branches/.leading_dot" &&
-   svn_cmd cp -m "trailing dot" "$svnrepo/pr ject/trunk" \
-   "$svnrepo/pr ject/branches/trailing_dot." &&
+   if test_have_prereq !MINGW
+   then
+   svn_cmd cp -m "trailing dot" "$svnrepo/pr ject/trunk" \
+   "$svnrepo/pr ject/branches/trailing_dot."
+   fi &&
svn_cmd cp -m "trailing .lock" "$svnrepo/pr ject/trunk" \
"$svnrepo/pr ject/branches/trailing_dotlock.lock" &&
svn_cmd cp -m "reflog" "$svnrepo/pr ject/trunk" \
@@ -45,7 +48,10 @@ test_expect_success 'test clone with funky branch names' '
git rev-parse "refs/remotes/origin/more%20fun%20plugin!" &&
git rev-parse "refs/remotes/origin/$scary_ref" &&
git rev-parse "refs/remotes/origin/%2Eleading_dot" &&
-   git rev-parse "refs/remotes/origin/trailing_dot%2E" &&
+   if test_have_prereq !MINGW
+   then
+   git rev-parse "refs/remotes/origin/trailing_dot%2E"
+   fi &&
git rev-parse "refs/remotes/origin/trailing_dotlock%2Elock" &&
git rev-parse "refs/remotes/origin/$non_reflog"
)
-- 
2.7.0.windows.1.7.g55a05c8


--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v3 19/20] mingw: skip a test in t9130 that cannot pass on Windows

[Johannes Schindelin]

On Windows, Git itself has no clue about POSIX paths, but its shell
scripts do. In this instance, we get mixed paths as a result, and when
comparing the path of the author file, we get a mismatch that is
entirely due to the POSIX path vs Windows path clash.

Let's just skip this test so that t9130-git-svn-authors-file.sh passes
in Git for Windows' SDK.

Signed-off-by: Johannes Schindelin 
---
 t/t9130-git-svn-authors-file.sh | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/t/t9130-git-svn-authors-file.sh b/t/t9130-git-svn-authors-file.sh
index d306b77..4126481 100755
--- a/t/t9130-git-svn-authors-file.sh
+++ b/t/t9130-git-svn-authors-file.sh
@@ -91,7 +91,7 @@ test_expect_success 'fetch continues after authors-file is 
fixed' '
)
'
 
-test_expect_success 'fresh clone with svn.authors-file in config' '
+test_expect_success !MINGW 'fresh clone with svn.authors-file in config' '
(
rm -r "$GIT_DIR" &&
test x = x"$(git config svn.authorsfile)" &&
-- 
2.7.0.windows.1.7.g55a05c8


--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v3 00/20] Let Git's tests pass on Windows

[Johannes Schindelin]

This is a big milestone. With these modifications, Git's source code
does not only build without warnings in Git for Windows' SDK, but
passes the entire regression test suite.

The patch series contains three different types of patches. First,
there are a couple of real fixes that were triggered by failures in
the regression tests. Then there are a couple of fixes to the
regression tests themselves. And finally, we have to disable a couple
of tests because we simply cannot make them work on Windows.

Relative to v2, this fixes stupid typos that made the tests fail on
Linux, a stupid copy-paste error pointed out by Eric Sunshine,
unnecessary 'printf ""' calls pointed out by Junio Hamano, and I now
use `test_have_prereq !MINGW` consistently, as pointed out by both Eric
and Junio. This time, I also send the patch series with the character
set set (sic!) to UTF-8. Oh, and this time, I also made sure that the
regression tests pass on Windows & Linux alike. Oh, and I also managed not
to forget the fix for t9130 this time.


Johannes Schindelin (17):
  mingw: let's use gettext with MSYS2
  mingw: do not trust MSYS2's MinGW gettext.sh
  Git.pm: stop assuming that absolute paths start with a slash
  mingw: prepare the TMPDIR environment variable for shell scripts
  mingw: let lstat() fail with errno == ENOTDIR when appropriate
  mingw: fix t5601-clone.sh
  mingw: accomodate t0060-path-utils for MSYS2
  mingw: disable mkfifo-based tests
  tests: turn off git-daemon tests if FIFOs are not available
  mingw: skip test in t1508 that fails due to path conversion
  mingw: fix t9700's assumption about directory separators
  mingw: work around pwd issues in the tests
  mingw: mark t9100's test cases with appropriate prereqs
  mingw: avoid illegal filename in t9118
  mingw: handle the missing POSIXPERM prereq in t9124
  mingw: skip a test in t9130 that cannot pass on Windows
  mingw: do not bother to test funny file names

Karsten Blees (1):
  mingw: factor out Windows specific environment setup

Pat Thoyts (1):
  Avoid absolute path in t0008

마누엘 (1):
  mingw: try to delete target directory before renaming

 Makefile  |  1 +
 compat/mingw.c| 91 +--
 config.mak.uname  |  3 +-
 perl/Git.pm   |  3 +-
 t/lib-git-daemon.sh   |  5 ++
 t/t0008-ignores.sh|  2 +-
 t/t0060-path-utils.sh |  9 
 t/t1508-at-combinations.sh|  6 ++-
 t/t3300-funny-names.sh|  1 +
 t/t3600-rm.sh |  2 +-
 t/t3703-add-magic-pathspec.sh |  2 +-
 t/t3902-quoted.sh |  1 +
 t/t4016-diff-quote.sh |  1 +
 t/t4135-apply-weird-filenames.sh  |  3 +-
 t/t5601-clone.sh  | 18 +++
 t/t7800-difftool.sh   | 14 +++---
 t/t9100-git-svn-basic.sh  | 18 +++
 t/t9118-git-svn-funky-branch-names.sh | 12 +++--
 t/t9124-git-svn-dcommit-auto-props.sh | 16 +++---
 t/t9130-git-svn-authors-file.sh   |  2 +-
 t/t9200-git-cvsexportcommit.sh|  2 +-
 t/t9400-git-cvsserver-server.sh   |  6 +--
 t/t9401-git-cvsserver-crlf.sh |  6 +--
 t/t9402-git-cvsserver-refs.sh |  6 +--
 t/t9700/test.pl   |  2 +-
 t/t9903-bash-prompt.sh|  2 +-
 t/test-lib.sh |  2 +-
 test-fake-ssh.c   | 30 
 28 files changed, 196 insertions(+), 70 deletions(-)
 create mode 100644 test-fake-ssh.c

Interdiff vs v2:

 diff --git a/t/t1508-at-combinations.sh b/t/t1508-at-combinations.sh
 index c59d554..4a9964e 100755
 --- a/t/t1508-at-combinations.sh
 +++ b/t/t1508-at-combinations.sh
 @@ -35,9 +35,9 @@ test_expect_success 'setup' '
git checkout -b upstream-branch &&
test_commit upstream-one &&
test_commit upstream-two &&
 -  if ! test_have_prereq MINGW
 +  if test_have_prereq !MINGW
then
 -  git checkout -b @/at-slash
 +  git checkout -b @/at-test
fi &&
git checkout -b @@/at-test &&
git checkout -b @at-test &&
 diff --git a/t/t3600-rm.sh b/t/t3600-rm.sh
 index 5232ee9..d046d98 100755
 --- a/t/t3600-rm.sh
 +++ b/t/t3600-rm.sh
 @@ -14,8 +14,7 @@ test_expect_success \
   git add -- foo bar baz 'space embedded' -q &&
   git commit -m 'add normal files'"
  
 -
 -if ! test_have_prereq MINGW && touch -- 'tab  embedded' 'newline
 +if test_have_prereq !MINGW && touch -- 'tab   embedded' 'newline
  embedded' 2>/dev/null
  then
test_set_prereq FUNNYNAMES
 diff --git a/t/t3703-add-magic-pathspec.sh b/t/t3703-add-magic-pathspec.sh
 index aaff784..3ef525a 100755
 --- a/t/t3703-add-magic-pathspec.sh
 +++ b/t/t3703-add-magic-pathspec.sh
 @@ -38,7 +38,7 @@ cat >expected /dev/null
  then
test_set_prereq COLON_DIR
  fi
 diff 

[PATCH v3 05/20] mingw: prepare the TMPDIR environment variable for shell scripts

[Johannes Schindelin]

When shell scripts access a $TMPDIR variable containing backslashes,
they will be mistaken for escape characters. Let's not let that happen
by converting them to forward slashes.

This partially fixes t7800 with MSYS2.

Signed-off-by: Johannes Schindelin 
---
 compat/mingw.c | 23 +++
 1 file changed, 19 insertions(+), 4 deletions(-)

diff --git a/compat/mingw.c b/compat/mingw.c
index 8d52c73..ba5cb1c 100644
--- a/compat/mingw.c
+++ b/compat/mingw.c
@@ -2049,13 +2049,28 @@ int xwcstoutf(char *utf, const wchar_t *wcs, size_t 
utflen)
 
 static void setup_windows_environment()
 {
+   char *tmp = getenv("TMPDIR");
+
/* on Windows it is TMP and TEMP */
-   if (!getenv("TMPDIR")) {
-   const char *tmp = getenv("TMP");
-   if (!tmp)
+   if (!tmp) {
+   if (!(tmp = getenv("TMP")))
tmp = getenv("TEMP");
-   if (tmp)
+   if (tmp) {
setenv("TMPDIR", tmp, 1);
+   tmp = getenv("TMPDIR");
+   }
+   }
+
+   if (tmp) {
+   /*
+* Convert all dir separators to forward slashes,
+* to help shell commands called from the Git
+* executable (by not mistaking the dir separators
+* for escape characters).
+*/
+   for (; *tmp; tmp++)
+   if (*tmp == '\\')
+   *tmp = '/';
}
 
/* simulate TERM to enable auto-color (see color.c) */
-- 
2.7.0.windows.1.7.g55a05c8


--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v3 02/20] mingw: do not trust MSYS2's MinGW gettext.sh

[Johannes Schindelin]

It does not quite work because it produces DOS line endings which the
shell does not like at all.

This lets t0200-gettext-basic.sh, t0204-gettext-reencode-sanity.sh,
t3406-rebase-message.sh, t3903-stash.sh, t7400-submodule-basic.sh,
t7401-submodule-summary.sh, t7406-submodule-update.sh and
t7407-submodule-foreach.sh pass in Git for Windows' SDK.

Signed-off-by: Johannes Schindelin 
---
 config.mak.uname | 1 +
 1 file changed, 1 insertion(+)

diff --git a/config.mak.uname b/config.mak.uname
index 6b25661..d6f7980 100644
--- a/config.mak.uname
+++ b/config.mak.uname
@@ -561,6 +561,7 @@ else
INTERNAL_QSORT = YesPlease
HAVE_LIBCHARSET_H = YesPlease
NO_GETTEXT =
+   USE_GETTEXT_SCHEME = fallthrough
USE_LIBPCRE= YesPlease
NO_CURL =
USE_NED_ALLOCATOR = YesPlease
-- 
2.7.0.windows.1.7.g55a05c8


--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v3 20/20] mingw: do not bother to test funny file names

[Johannes Schindelin]

MSYS2 actually allows to create files or directories whose names contain
tabs, newlines or colors, even if plain Win32 API cannot access them.
As we are using an MSYS2 bash to run the tests, such files or
directories are created successfully, but Git itself has no chance to
work with them because it is a regular Windows program, hence limited by
the Win32 API.

With this change, on Windows otherwise failing tests in
t3300-funny-names.sh, t3600-rm.sh, t3703-add-magic-pathspec.sh,
t3902-quoted.sh, t4016-diff-quote.sh, t4135-apply-weird-filenames.sh,
t9200-git-cvsexportcommit.sh, and t9903-bash-prompt.sh are skipped.

Signed-off-by: Johannes Schindelin 
---
 t/t3300-funny-names.sh   | 1 +
 t/t3600-rm.sh| 2 +-
 t/t3703-add-magic-pathspec.sh| 2 +-
 t/t3902-quoted.sh| 1 +
 t/t4016-diff-quote.sh| 1 +
 t/t4135-apply-weird-filenames.sh | 3 ++-
 t/t9200-git-cvsexportcommit.sh   | 2 +-
 t/t9903-bash-prompt.sh   | 2 +-
 8 files changed, 9 insertions(+), 5 deletions(-)

diff --git a/t/t3300-funny-names.sh b/t/t3300-funny-names.sh
index 9a146f1..04de03c 100755
--- a/t/t3300-funny-names.sh
+++ b/t/t3300-funny-names.sh
@@ -13,6 +13,7 @@ tree, index, and tree objects.
 
 HT='   '
 
+test_have_prereq MINGW ||
 echo 2>/dev/null > "Name with an${HT}HT"
 if ! test -f "Name with an${HT}HT"
 then
diff --git a/t/t3600-rm.sh b/t/t3600-rm.sh
index 2e47a2b..d046d98 100755
--- a/t/t3600-rm.sh
+++ b/t/t3600-rm.sh
@@ -14,7 +14,7 @@ test_expect_success \
  git add -- foo bar baz 'space embedded' -q &&
  git commit -m 'add normal files'"
 
-if touch -- 'tab   embedded' 'newline
+if test_have_prereq !MINGW && touch -- 'tabembedded' 'newline
 embedded' 2>/dev/null
 then
test_set_prereq FUNNYNAMES
diff --git a/t/t3703-add-magic-pathspec.sh b/t/t3703-add-magic-pathspec.sh
index 5115de7..3ef525a 100755
--- a/t/t3703-add-magic-pathspec.sh
+++ b/t/t3703-add-magic-pathspec.sh
@@ -38,7 +38,7 @@ cat >expected /dev/null
 then
test_set_prereq COLON_DIR
 fi
diff --git a/t/t3902-quoted.sh b/t/t3902-quoted.sh
index 892f567..f528008 100755
--- a/t/t3902-quoted.sh
+++ b/t/t3902-quoted.sh
@@ -12,6 +12,7 @@ GN='???'
 HT='   '
 DQ='"'
 
+test_have_prereq MINGW ||
 echo foo 2>/dev/null > "Name and an${HT}HT"
 if ! test -f "Name and an${HT}HT"
 then
diff --git a/t/t4016-diff-quote.sh b/t/t4016-diff-quote.sh
index cd543ec..9c48e5c 100755
--- a/t/t4016-diff-quote.sh
+++ b/t/t4016-diff-quote.sh
@@ -13,6 +13,7 @@ P1='pathname  with HT'
 P2='pathname with SP'
 P3='pathname
 with LF'
+test_have_prereq !MINGW &&
 echo 2>/dev/null >"$P1" && test -f "$P1" && rm -f "$P1" || {
skip_all='Your filesystem does not allow tabs in filenames'
test_done
diff --git a/t/t4135-apply-weird-filenames.sh b/t/t4135-apply-weird-filenames.sh
index bf5dc57..27cb000 100755
--- a/t/t4135-apply-weird-filenames.sh
+++ b/t/t4135-apply-weird-filenames.sh
@@ -19,7 +19,8 @@ test_expect_success 'setup' '
 
test_when_finished "rm -f \"tab embedded.txt\"" &&
test_when_finished "rm -f '\''\"quoteembedded\".txt'\''" &&
-   if touch -- "tabembedded.txt" '\''"quoteembedded".txt'\''
+   if test_have_prereq !MINGW &&
+   touch -- "tab   embedded.txt" '\''"quoteembedded".txt'\''
then
test_set_prereq FUNNYNAMES
fi
diff --git a/t/t9200-git-cvsexportcommit.sh b/t/t9200-git-cvsexportcommit.sh
index 812c9cd..5cfb9cf 100755
--- a/t/t9200-git-cvsexportcommit.sh
+++ b/t/t9200-git-cvsexportcommit.sh
@@ -197,7 +197,7 @@ if 
p="??/goo/a/b/c/d/e/f/g/h/i/j/k/l/m/n/o/p/q/r/s/t/u/v/w/x/y/z/??/??/??" &&
 then
 
 # This test contains UTF-8 characters
-test_expect_success \
+test_expect_success !MINGW \
  'File with non-ascii file name' \
  'mkdir -p 
??/goo/a/b/c/d/e/f/g/h/i/j/k/l/m/n/o/p/q/r/s/t/u/v/w/x/y/z/??/??/?? &&
   echo Foo 
>??/goo/a/b/c/d/e/f/g/h/i/j/k/l/m/n/o/p/q/r/s/t/u/v/w/x/y/z/??/??/??/g??rdets??g??rdet.txt
 &&
diff --git a/t/t9903-bash-prompt.sh b/t/t9903-bash-prompt.sh
index af82049..ffbfa0e 100755
--- a/t/t9903-bash-prompt.sh
+++ b/t/t9903-bash-prompt.sh
@@ -67,7 +67,7 @@ repo_with_newline='repo
 with
 newline'
 
-if mkdir "$repo_with_newline" 2>/dev/null
+if test_have_prereq !MINGW && mkdir "$repo_with_newline" 2>/dev/null
 then
test_set_prereq FUNNYNAMES
 else
-- 
2.7.0.windows.1.7.g55a05c8

[PATCH v3 16/20] mingw: mark t9100's test cases with appropriate prereqs

[Johannes Schindelin]

Many a test requires either POSIXPERM (to change the executable bit) or
SYMLINKS, and neither are available on Windows.

This lets t9100-git-svn-basic.sh pass in Git for Windows' SDK.

Signed-off-by: Johannes Schindelin 
---
 t/t9100-git-svn-basic.sh | 18 +-
 1 file changed, 9 insertions(+), 9 deletions(-)

diff --git a/t/t9100-git-svn-basic.sh b/t/t9100-git-svn-basic.sh
index 258d9b8..56acc1e 100755
--- a/t/t9100-git-svn-basic.sh
+++ b/t/t9100-git-svn-basic.sh
@@ -30,8 +30,7 @@ test_expect_success \
echo "deep dir" >dir/a/b/c/d/e/file &&
mkdir bar &&
echo "zzz" >bar/zzz &&
-   echo "#!/bin/sh" >exec.sh &&
-   chmod +x exec.sh &&
+   write_script exec.sh /dev/null
) &&
rm -rf import &&
@@ -117,7 +116,7 @@ test_expect_success "$name" '
 
 
 name='remove executable bit from a file'
-test_expect_success "$name" '
+test_expect_success POSIXPERM "$name" '
rm -f "$GIT_DIR"/index &&
git checkout -f -b mybranch5 ${remotes_git_svn} &&
chmod -x exec.sh &&
@@ -130,7 +129,7 @@ test_expect_success "$name" '
 
 
 name='add executable bit back file'
-test_expect_success "$name" '
+test_expect_success POSIXPERM "$name" '
chmod +x exec.sh &&
git update-index exec.sh &&
git commit -m "$name" &&
@@ -141,7 +140,7 @@ test_expect_success "$name" '
 
 
 name='executable file becomes a symlink to file'
-test_expect_success "$name" '
+test_expect_success SYMLINKS "$name" '
rm exec.sh &&
ln -s file exec.sh &&
git update-index exec.sh &&
@@ -153,7 +152,7 @@ test_expect_success "$name" '
 
 name='new symlink is added to a file that was also just made executable'
 
-test_expect_success "$name" '
+test_expect_success POSIXPERM,SYMLINKS "$name" '
chmod +x file &&
ln -s file exec-2.sh &&
git update-index --add file exec-2.sh &&
@@ -165,7 +164,7 @@ test_expect_success "$name" '
test -h "$SVN_TREE"/exec-2.sh'
 
 name='modify a symlink to become a file'
-test_expect_success "$name" '
+test_expect_success POSIXPERM,SYMLINKS "$name" '
echo git help >help &&
rm exec-2.sh &&
cp help exec-2.sh &&
@@ -181,7 +180,8 @@ test_expect_success "$name" '
 name="commit with UTF-8 message: locale: $GIT_SVN_LC_ALL"
 LC_ALL="$GIT_SVN_LC_ALL"
 export LC_ALL
-test_expect_success UTF8 "$name" "
+# This test relies on the previous test, hence requires POSIXPERM,SYMLINKS
+test_expect_success UTF8,POSIXPERM,SYMLINKS "$name" "
echo '# hello' >> exec-2.sh &&
git update-index exec-2.sh &&
git commit -m '???' &&
@@ -214,7 +214,7 @@ tree d667270a1f7b109f5eb3aaea21ede14b56bfdd6e
 tree 8f51f74cf0163afc9ad68a4b1537288c4558b5a4
 EOF
 
-test_expect_success "$name" "test_cmp a expected"
+test_expect_success POSIXPERM,SYMLINKS "$name" "test_cmp a expected"
 
 test_expect_success 'exit if remote refs are ambigious' "
 git config --add svn-remote.svn.fetch \
-- 
2.7.0.windows.1.7.g55a05c8

[PATCH v3 09/20] mingw: accomodate t0060-path-utils for MSYS2

[Johannes Schindelin]

On Windows, there are no POSIX paths, only Windows ones (an absolute
Windows path looks like "C:\Program Files\Git\ReleaseNotes.html", under
most circumstances, forward slashes are also allowed and synonymous to
backslashes).

So when a POSIX shell (such as MSYS2's Bash, which is used by Git for
Windows to execute all those shell scripts that are part of Git) passes
a POSIX path to test-path-utils.exe (which is not POSIX-aware), the path
is translated into a Windows path. For example, /etc/profile becomes
C:/Program Files/Git/etc/profile.

This path translation poses a problem when passing the root directory as
parameter to test-path-utils.exe, as it is not well defined whether the
translated root directory should end in a slash or not. MSys1 stripped
the trailing slash, but MSYS2 does not.

Originally, the Git for Windows project patched MSYS2's runtime to
accomodate Git's regression test, but we really should do it the other
way round.

To work with both of MSys1's and MSYS2's behaviors, we simply test what
the current system does in the beginning of t0060-path-utils.sh and then
adjust the expected longest ancestor length accordingly.

It looks quite a bit tricky what we actually do in this patch: first, we
adjust the expected length for the trailing slash we did not originally
expect (subtracting one). So far, so good.

But now comes the part where things work in a surprising way: when the
expected length was 0, the prefix to match is the root directory. If the
root directory is converted into a path with a trailing slash, however,
we know that the logic in longest_ancestor_length() cannot match: to
avoid partial matches of the last directory component, it verifies that
the character after the matching prefix is a slash (but because the
slash was part of the matching prefix, the next character cannot be a
slash). So the return value is -1. Alas, this is exactly what the
expected length is after subtracting the value of $rootslash! So we skip
adding the $rootoff value in that case (and only in that case).

Directories other than the root directory are handled fine (as they are
specified without a trailing slash, something not possible for the root
directory, and MSYS2 converts them into Windows paths that also lack
trailing slashes), therefore we do not need any more special handling.

Thanks to Ray Donnelly for his patient help with this issue.

Signed-off-by: Johannes Schindelin 
---
 t/t0060-path-utils.sh | 9 +
 1 file changed, 9 insertions(+)

diff --git a/t/t0060-path-utils.sh b/t/t0060-path-utils.sh
index f0152a7..8532a02 100755
--- a/t/t0060-path-utils.sh
+++ b/t/t0060-path-utils.sh
@@ -36,12 +36,21 @@ if test $rootoff = 2; then
rootoff=# we are on Unix
 else
rootoff=$(($rootoff-1))
+   # In MSYS2, the root directory "/" is translated into a Windows
+   # directory *with* trailing slash. Let's test for that and adjust
+   # our expected longest ancestor length accordingly.
+   case "$(test-path-utils print_path /)" in
+   */) rootslash=1;;
+   *) rootslash=0;;
+   esac
 fi
 
 ancestor() {
# We do some math with the expected ancestor length.
expected=$3
if test -n "$rootoff" && test "x$expected" != x-1; then
+   expected=$(($expected-$rootslash))
+   test $expected -lt 0 ||
expected=$(($expected+$rootoff))
fi
test_expect_success "longest ancestor: $1 $2 => $expected" \
-- 
2.7.0.windows.1.7.g55a05c8


--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: git for windows

[Johannes Schindelin]

Hi Andrey,

we never saw the two mails you were replying to, and please note that 1)
the preferred place to report bugs in Git for Windows is
https://github.com/git-for-windows/git/issues, as outlined in
https://git-for-windows.github.io/#contribute, and that 2) top-posting
will most likely result in less responses than you would want.

> > On 1/27/2016 2:32 PM, Andrey Chernyshov wrote:
> > >
> > > I'm using PHP storm with git for windows. Once I do a push to the github
> > > I get the following error
> > Problem signature:
> >   Problem Event Name:APPCRASH
> >   Application Name:git-remote-https.exe
> >   Application Version:2.7.0.0
> >   Application Timestamp:35316130
> >   Fault Module Name:libidn-11.dll
> >   Fault Module Version:0.0.0.0
> >   Fault Module Timestamp:00170158
> >   Exception Code:c005
> >   Exception Offset:46bc
> >   OS Version:6.3.9600.2.0.0.256.4
> >   Locale ID:1033
> >   Additional Information 1:a547
> >   Additional Information 2:a54764e1ee4f5613d3fc9395100a0ff4
> >   Additional Information 3:ac01
> >   Additional Information 4:ac010ce737711604ec050156caebd625
> >
> > Read our privacy statement online:
> > http://go.microsoft.com/fwlink/?linkid=280262
> >
> > If the online privacy statement is not available, please read our privacy
> > statement offline:
> >   C:\windows\system32\en-US\erofflps.txt
> >
> > > If I try to push with Git GUI, it's the same, so not a PHPStorm issue...

If you can come up with a minimal, complete & verifiable example (see
http://stackoverflow.com/help/mcve), it is much more likely that I can
help you than it is right now.

My only guess is that you might be able to work around the issue by
setting the environment variable `CHARSET` to something like `cp1252`
before pushing. But that's the extent of the help I have to offer unless
the time when I have a chance to reproduce this on my computer.

Ciao,
Johannes
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v2 16/19] mingw: mark t9100's test cases with appropriate prereqs

[Johannes Schindelin]

Hi Junio,

On Tue, 26 Jan 2016, Junio C Hamano wrote:

> Johannes Schindelin  writes:
> 
> > @@ -181,7 +180,8 @@ test_expect_success "$name" '
> >  name="commit with UTF-8 message: locale: $GIT_SVN_LC_ALL"
> >  LC_ALL="$GIT_SVN_LC_ALL"
> >  export LC_ALL
> > -test_expect_success UTF8 "$name" "
> > +# This test relies on the previous test, hence requires POSIXPERM,SYMLINKS
> > +test_expect_success UTF8,POSIXPERM,SYMLINKS "$name" "
> > echo '# hello' >> exec-2.sh &&
> > git update-index exec-2.sh &&
> > git commit -m '???' &&
> 
> Hmph.  "Content-Type: text/plain; charset=X-UNKNOWN" in the header
> gives a hint to me, too.

Bah. I recently upgraded to a newer Alpine and must have overlooked the
unknown charset option. Sorry for that, I think I fixed it now (let me
know if not).

Ciao,
Dscho
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] optionally disable gitattributes

[Clemens Buchacher]

On Wed, Jan 27, 2016 at 04:04:39PM +0100, Torsten Bögershausen wrote:
>
> It feels like a workaround for something that could be fixable, or is already 
> ongoing.
> Before going into more details,
> could you tell us which attributes you are typically using (when having this 
> problems) ?
> Is it
> * text=auto
> or
> *.sh text 
> or something else?

My concrete use case is the text attribute, as in your example: "*.sh
text". But I think of the patch as a more general solution for cases
where we want to work with the files as they are committed, without
having to deal with not normalized files or other conversions due to
gitattributes.

Please note that you may also want to read my reply to the other thread
that Junio mentioned: [PATCH] travis-ci: run previously failed tests
first, then slowest to fastest.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v3 16/20] mingw: mark t9100's test cases with appropriate prereqs

[Johannes Schindelin]

Hi Junio,

On Wed, 27 Jan 2016, Johannes Schindelin wrote:

> --8323329-1704809497-1453911609=:2964
> Content-Type: text/plain; charset=X-UNKNOWN

Oh well. I guess I am really too stupid to get this right... Will change
my script to call format-patch with the --add-header='Content-Type:
text/plain; charset=UTF-8' option to prevent more misery in the future.

Sorry,
Dscho
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v5 0/2] Let merge-file write out conflict markers with correct EOLs

[Johannes Schindelin]

The original patch was sent by Beat Bolli in
http://thread.gmane.org/gmane.comp.version-control.git/281600

My suggestion to extend it to respect gitattributes led to
changes that broke the original patch. And they were misguided
to begin with (see below).

Since there have been a couple of "What's cooking" mails
containing unheard calls for updates on this patch, I took it
on myself to fix things.

Junio's comment that we might look at blobs containing CR/LF
line endings made me rethink the entire approach, and I am now
convinced that we need to abandon the entire idea to make the
conflict markers depend on config settings or attributes:
after all, I introduced `git merge-file` as a replacement for
GNU merge that can be used *outside* of any repository, by design.

The crucial idea hit me yesterday when I took a step back: all
we need to do is to ensure that the end-of-line style is matched
when *all* input files are LF-only, or when they are all CR/LF.
In all other cases, we have mixed line endings anyway.

And to do that, it is sufficient to look at *one single line
ending* in the context. Technically, it does not even have to be
the context, but the first line endings of the first file would
be enough, however it is so much more pleasant if the conflict
marker's eol matches the one of the preceding line.

To prevent my future self from repeating mistakes, I added a
little bit of background to the first commit message.

Triggered by a comment by Junio, I realized that a second patch is
needed: we need to make sure that the conflicting sections are also
augmented by the appropriate line endings if they lack any.

The change relative to v4 is that I now test the correct conflict
markers: the merge-file call we add to t6023 actually produces four
conflict markers because a previous test switched the conflict style
to `diff3` mode. This is only a side effect, though, therefore I
really wanted to avoid testing for it. However, I managed to test
an *incorrect* subset of three, but this is now fixed. Thanks go
to Ramsay Jones for poking my nose onto that issue.


Johannes Schindelin (2):
  merge-file: let conflict markers match end-of-line style of the
context
  merge-file: ensure that conflict sections match eol style

 t/t6023-merge-file.sh | 13 +++
 xdiff/xmerge.c| 98 +--
 2 files changed, 93 insertions(+), 18 deletions(-)

Interdiff vs v4:

 diff --git a/t/t6023-merge-file.sh b/t/t6023-merge-file.sh
 index 1390548..20aee43 100755
 --- a/t/t6023-merge-file.sh
 +++ b/t/t6023-merge-file.sh
 @@ -352,11 +352,11 @@ test_expect_success 'conflict sections match existing 
line endings' '
printf "1\\r\\n2\\r\\n5" >crlf-diff2.txt &&
test_must_fail git -c core.eol=crlf merge-file -p \
crlf-diff1.txt crlf-orig.txt crlf-diff2.txt >crlf.txt &&
 -  test $(tr "\015" Q ].*Q$" | wc -l) = 3 &&
test $(tr "\015" Q nolf.txt &&
 -  test $(tr "\015" Q ].*Q$" | wc -l) = 0
  '
  
  test_done

-- 
2.7.0.windows.1.7.g55a05c8

--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v5 1/2] merge-file: let conflict markers match end-of-line style of the context

[Johannes Schindelin]

When merging files with CR/LF line endings, the conflict markers should
match those, lest the output file has mixed line endings.

This is particularly of interest on Windows, where some editors get
*really* confused by mixed line endings.

The original version of this patch by Beat Bolli respected core.eol, and
a subsequent improvement by this developer also respected gitattributes.
This approach was suboptimal, though: `git merge-file` was invented as a
drop-in replacement for GNU merge and as such has no problem operating
outside of any repository at all!

Another problem with the original approach was pointed out by Junio
Hamano: legacy repositories might have their text files committed using
CR/LF line endings (and core.eol and the gitattributes would give us a
false impression there). Therefore, the much superior approach is to
simply match the context's line endings, if any.

We actually do not have to look at the *entire* context at all: if the
files are all LF-only, or if they all have CR/LF line endings, it is
sufficient to look at just a *single* line to match that style. And if
the line endings are mixed anyway, it is *still* okay to imitate just a
single line's eol: we will just add to the pile of mixed line endings,
and there is nothing we can do about that.

So what we do is: we look at the line preceding the conflict, falling
back to the line preceding that in case it was the last line and had no
line ending, falling back to the first line, first in the first
post-image, then the second post-image, and finally the pre-image.
If we find consistent CR/LF (or undecided) end-of-line style, we match
that, otherwise we use LF-only line endings for the conflict markers.

Note that while it is true that there have to be at least two lines we
can look at (otherwise there would be no conflict), the same is not true
for line *endings*: the three files in question could all consist of a
single line without any line ending, each. In this case we fall back to
using LF-only.

Signed-off-by: Johannes Schindelin 
---
 t/t6023-merge-file.sh | 12 ++
 xdiff/xmerge.c| 61 +++
 2 files changed, 69 insertions(+), 4 deletions(-)

diff --git a/t/t6023-merge-file.sh b/t/t6023-merge-file.sh
index 190ee90..a082116 100755
--- a/t/t6023-merge-file.sh
+++ b/t/t6023-merge-file.sh
@@ -346,4 +346,16 @@ test_expect_success 'conflict at EOF without LF resolved 
by --union' \
 printf "line1\nline2\nline3x\nline3y" >expect.txt &&
 test_cmp expect.txt output.txt'
 
+test_expect_success 'conflict markers match existing line endings' '
+   printf "1\\r\\n2\\r\\n3" >crlf-orig.txt &&
+   printf "1\\r\\n2\\r\\n4" >crlf-diff1.txt &&
+   printf "1\\r\\n2\\r\\n5" >crlf-diff2.txt &&
+   test_must_fail git -c core.eol=crlf merge-file -p \
+   crlf-diff1.txt crlf-orig.txt crlf-diff2.txt >crlf.txt &&
+   test $(tr "\015" Q ].*Q$" | wc -l) = 3 &&
+   test_must_fail git -c core.eol=crlf merge-file -p \
+   nolf-diff1.txt nolf-orig.txt nolf-diff2.txt >nolf.txt &&
+   test $(tr "\015" Q ].*Q$" | wc -l) = 0
+'
+
 test_done
diff --git a/xdiff/xmerge.c b/xdiff/xmerge.c
index 625198e..7b21a6b 100644
--- a/xdiff/xmerge.c
+++ b/xdiff/xmerge.c
@@ -143,6 +143,50 @@ static int xdl_orig_copy(xdfenv_t *xe, int i, int count, 
int add_nl, char *dest)
return xdl_recs_copy_0(1, xe, i, count, add_nl, dest);
 }
 
+/*
+ * Returns 1 if the i'th line ends in CR/LF (if it is the last line and
+ * has no eol, the preceding line, if any), 0 if it ends in LF-only, and
+ * -1 if the line ending cannot be determined.
+ */
+static int is_eol_crlf(xdfile_t *file, int i)
+{
+   long size;
+
+   if (i < file->nrec - 1)
+   /* All lines before the last *must* end in LF */
+   return (size = file->recs[i]->size) > 1 &&
+   file->recs[i]->ptr[size - 2] == '\r';
+   if (!file->nrec)
+   /* Cannot determine eol style from empty file */
+   return -1;
+   if ((size = file->recs[i]->size) &&
+   file->recs[i]->ptr[size - 1] == '\n')
+   /* Last line; ends in LF; Is it CR/LF? */
+   return size > 1 &&
+   file->recs[i]->ptr[size - 2] == '\r';
+   if (!i)
+   /* The only line has no eol */
+   return -1;
+   /* Determine eol from second-to-last line */
+   return (size = file->recs[i - 1]->size) > 1 &&
+   file->recs[i - 1]->ptr[size - 2] == '\r';
+}
+
+static int is_cr_needed(xdfenv_t *xe1, xdfenv_t *xe2, xdmerge_t *m)
+{
+   int needs_cr;
+
+   /* Match post-images' preceding, or first, lines' end-of-line style */
+   needs_cr = is_eol_crlf(>xdf2, m->i1 ? m->i1 - 1 : 0);
+   if (needs_cr)
+   needs_cr = is_eol_crlf(>xdf2, m->i2 ? m->i2 - 1 : 0);
+   /* Look at pre-image's first line, unless 

[PATCH v5 2/2] merge-file: ensure that conflict sections match eol style

[Johannes Schindelin]

In the previous patch, we made sure that the conflict markers themselves
match the end-of-line style of the input files. However, this still left
out the conflicting text itself: if it lacks a trailing newline, we
add one, and should add a carriage return when appropriate, too.

Signed-off-by: Johannes Schindelin 
---
 t/t6023-merge-file.sh |  3 ++-
 xdiff/xmerge.c| 37 +++--
 2 files changed, 25 insertions(+), 15 deletions(-)

diff --git a/t/t6023-merge-file.sh b/t/t6023-merge-file.sh
index a082116..20aee43 100755
--- a/t/t6023-merge-file.sh
+++ b/t/t6023-merge-file.sh
@@ -346,13 +346,14 @@ test_expect_success 'conflict at EOF without LF resolved 
by --union' \
 printf "line1\nline2\nline3x\nline3y" >expect.txt &&
 test_cmp expect.txt output.txt'
 
-test_expect_success 'conflict markers match existing line endings' '
+test_expect_success 'conflict sections match existing line endings' '
printf "1\\r\\n2\\r\\n3" >crlf-orig.txt &&
printf "1\\r\\n2\\r\\n4" >crlf-diff1.txt &&
printf "1\\r\\n2\\r\\n5" >crlf-diff2.txt &&
test_must_fail git -c core.eol=crlf merge-file -p \
crlf-diff1.txt crlf-orig.txt crlf-diff2.txt >crlf.txt &&
test $(tr "\015" Q ].*Q$" | wc -l) = 3 &&
+   test $(tr "\015" Q nolf.txt &&
test $(tr "\015" Q ].*Q$" | wc -l) = 0
diff --git a/xdiff/xmerge.c b/xdiff/xmerge.c
index 7b21a6b..d98f430 100644
--- a/xdiff/xmerge.c
+++ b/xdiff/xmerge.c
@@ -109,7 +109,7 @@ static int xdl_merge_cmp_lines(xdfenv_t *xe1, int i1, 
xdfenv_t *xe2, int i2,
return 0;
 }
 
-static int xdl_recs_copy_0(int use_orig, xdfenv_t *xe, int i, int count, int 
add_nl, char *dest)
+static int xdl_recs_copy_0(int use_orig, xdfenv_t *xe, int i, int count, int 
needs_cr, int add_nl, char *dest)
 {
xrecord_t **recs;
int size = 0;
@@ -125,6 +125,12 @@ static int xdl_recs_copy_0(int use_orig, xdfenv_t *xe, int 
i, int count, int add
if (add_nl) {
i = recs[count - 1]->size;
if (i == 0 || recs[count - 1]->ptr[i - 1] != '\n') {
+   if (needs_cr) {
+   if (dest)
+   dest[size] = '\r';
+   size++;
+   }
+
if (dest)
dest[size] = '\n';
size++;
@@ -133,14 +139,14 @@ static int xdl_recs_copy_0(int use_orig, xdfenv_t *xe, 
int i, int count, int add
return size;
 }
 
-static int xdl_recs_copy(xdfenv_t *xe, int i, int count, int add_nl, char 
*dest)
+static int xdl_recs_copy(xdfenv_t *xe, int i, int count, int needs_cr, int 
add_nl, char *dest)
 {
-   return xdl_recs_copy_0(0, xe, i, count, add_nl, dest);
+   return xdl_recs_copy_0(0, xe, i, count, needs_cr, add_nl, dest);
 }
 
-static int xdl_orig_copy(xdfenv_t *xe, int i, int count, int add_nl, char 
*dest)
+static int xdl_orig_copy(xdfenv_t *xe, int i, int count, int needs_cr, int 
add_nl, char *dest)
 {
-   return xdl_recs_copy_0(1, xe, i, count, add_nl, dest);
+   return xdl_recs_copy_0(1, xe, i, count, needs_cr, add_nl, dest);
 }
 
 /*
@@ -202,7 +208,7 @@ static int fill_conflict_hunk(xdfenv_t *xe1, const char 
*name1,
marker_size = DEFAULT_CONFLICT_MARKER_SIZE;
 
/* Before conflicting part */
-   size += xdl_recs_copy(xe1, i, m->i1 - i, 0,
+   size += xdl_recs_copy(xe1, i, m->i1 - i, 0, 0,
  dest ? dest + size : NULL);
 
if (!dest) {
@@ -221,7 +227,7 @@ static int fill_conflict_hunk(xdfenv_t *xe1, const char 
*name1,
}
 
/* Postimage from side #1 */
-   size += xdl_recs_copy(xe1, m->i1, m->chg1, 1,
+   size += xdl_recs_copy(xe1, m->i1, m->chg1, needs_cr, 1,
  dest ? dest + size : NULL);
 
if (style == XDL_MERGE_DIFF3) {
@@ -240,7 +246,7 @@ static int fill_conflict_hunk(xdfenv_t *xe1, const char 
*name1,
dest[size++] = '\r';
dest[size++] = '\n';
}
-   size += xdl_orig_copy(xe1, m->i0, m->chg0, 1,
+   size += xdl_orig_copy(xe1, m->i0, m->chg0, needs_cr, 1,
  dest ? dest + size : NULL);
}
 
@@ -255,7 +261,7 @@ static int fill_conflict_hunk(xdfenv_t *xe1, const char 
*name1,
}
 
/* Postimage from side #2 */
-   size += xdl_recs_copy(xe2, m->i2, m->chg2, 1,
+   size += xdl_recs_copy(xe2, m->i2, m->chg2, needs_cr, 1,
  dest ? dest + size : NULL);
if (!dest) {
size += marker_size + 1 + needs_cr + marker2_size;
@@ -294,21 +300,24 @@ static int xdl_fill_merge_buffer(xdfenv_t *xe1, const 
char *name1,
  marker_size);
else if (m->mode & 3) {
   

Re: [PATCH v4 1/2] merge-file: let conflict markers match end-of-line style of the context

[Johannes Schindelin]

Hi Junio,

On Wed, 27 Jan 2016, Junio C Hamano wrote:

> Johannes Schindelin  writes:
> 
> [administrivia: I finally managed to correct e-mail address of peff@,
> which has been giving me bounces for all the previous messages in
> the thread]

Oops! I got those bounces myself, but wrote them off to Eric's account
without checking (because I consistently had problems sending emails to
him in the past). Sorry about that.

> > Your response is also an indicator to me that future myself will find the
> > same code just as confusing as you did, though.
> >
> > Maybe need_cr -> eol_is_crlf?
> 
> The crucial question is how well the variable conveys its meaning
> when it has -1 as its value.  "need_cr? -- I don't know yet" is as
> clear as "eol_is_crlf? -- I don't know yet", if not clearer.  I
> personally do not think "eol_is_crlf" is an improvement.

Okay, then. Let's keep the "needs_cr" name.

Ciao,
Dscho
> it unclear _whose_ eol the variable is talking about.  It can be
> misread as talking about one or more of the files that are being
> merged and mistaken as a statement of a fact (i.e. "we inspected
> and know the input file's eol is CRLF").
> 
> Compared to that, it is clear that "need_cr" is talking about what
> the EOL convention the resulting file should be.
> 
> I briefly wondered if the if/if (need_cr)/... cascade that inspects
> (conditionally up to) three variants might become cleaner if the
> polarity of that variable is flipped (we are allowed to use CRLF
> only when we know that among all of the three variants that we can
> determine the line termination convention used, all of them use
> CRLF), but I didn't think it through seriously.
> 
> 
> 
> 
> --
> To unsubscribe from this list: send the line "unsubscribe git" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v2 12/19] mingw: skip test in t1508 that fails due to path conversion

[Johannes Schindelin]

Hi Junio,

On Wed, 27 Jan 2016, Junio C Hamano wrote:

> Johannes Schindelin  writes:
> 
> > On Tue, 26 Jan 2016, Junio C Hamano wrote:
> >
> >> Johannes Schindelin  writes:
> >> 
> >> > -git checkout -b @/at-test &&
> >> > +if ! test_have_prereq MINGW
> >> > +then
> >> > +git checkout -b @/at-slash
> >> 
> >> I presume that this is meant to be "@/at-test", not "@/at-slash".
> >
> > Oh my. That's what you get for redoing patches from scratch. Sorry about
> > that!
> 
> Heh.  That is why it makes me feel uneasy, after asking you to fetch
> from me and fix it up, to hear that you will send in a new reroll.

I should have mentioned that I did rebase what your pu carries onto my
changes locally and found that the only differences were the consistency
tweaks (such as not adding the empty line pointed out by Eric, and such as
using !MINGW through-out).

Ciao,
Dscho
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] travis-ci: run previously failed tests first, then slowest to fastest

[Clemens Buchacher]

On Wed, Jan 27, 2016 at 12:49:31PM -0800, Junio C Hamano wrote:
> Junio C Hamano  writes:
> 
> > I wonder what would break if we ask this question instead:
> >
> > We do not know if the working tree file and the indexed data
> > match.  Let's see if "git checkout" of that path would leave the
> > same data as what currently is in the working tree file.

If we do this, then git diff should show the diff between
convert_to_worktree(index state) and the worktree state. That would be
nice, because the diff would actually show what we have in the worktree.
It keeps confusing me that with eol conversion enabled, git diff does
not actually show me the worktree state.

However, even if the file is clean in that direction, there could be a
mismatch between convert_to_git(worktree state) and the index state.
This will happen for example in t0025.4, where we have a CRLF file in
the index and the worktree, but convert_to_git converts it to a file
with LF line endings. Still, I do not see a problem if we also provide a
command like git add --fix-index, which will force normalization of all
files.

> > If we did this, "reset --hard HEAD" followed by "diff HEAD" will by
> > definition always report "is clean" as long as nobody changes files
> > in the working tree, even with the inconsistent data in the index.

Yes, this is a more elegant and a more complete solution to the problem
which prompted me to submit the GIT_ATTRIBUTES_DISABLED patch.

> > This still requires that convert_to_working_tree(), i.e. your smudge
> > filter, is deterministic, though, but I think that is a sensible
> > assumption for sane people, even for those with inconsistent data in
> > the index.

Deterministic, yes. But not unchanging. When a smudge filter is added,
or modified, or if the filter program changes, we still have to remove
the index before we can trust git diff again. The only way to avoid this
would be to somehow detect if the conversion itself changes. One could
hash the attributes, but changes to the filter configuration or the
filter itself are hard to detect. So I think we have to live with this.

> [...] Doing the other check will have to
> inflate the blob data and apply the convert_to_working_tree()
> processing, and also read the whole thing from the filesystem and
> compare, which is more work at runtime.

If we assume that the smudge filter is deterministic, then we could also
hash the output of convert_to_working_tree, and store the hash in the
index. With this optimization, the comparision would be less work,
because we do not have to apply a filter again, whereas currently we
have to apply convert_to_git.

> IOW, I am saying that the "add --fix-index" lunchbreak patch I sent
> earlier in the thread that has to hold the data in-core while
> processing is not a production quality patch ;-)

Ok. The existing implementation in renormalize_buffer (convert.c) works
for me, though.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [RFC] tag-ref and tag object binding

[Junio C Hamano]

Michael J Gruber  writes:

> Jeff King venit, vidit, dixit 27.01.2016 09:09:
>
>> The bigger issue is that gpg seems to give us only _one_ uid, when there
>> may be several. E.g., Junio's v2.7.0 is signed by 96AFE6CB, which is a
>> sub-key that has several uids associated with it. The one that "git
>> verify-tag --raw" shows from gpg is gits...@pobox.com, which is good,
>> but I think that's just because it happens to be the first uid. Or maybe
>> there is some gpg arcana going on that I don't know about.
>
> You do not sign with a uid, you sign with a (sub)key, and the tag is
> signed with Junio's primary key. His subkey is encryption only.

Hmm, actually I meant to sign my tags with signing subkey, not the
primary one, but I may have made a mistake.

> You do sign a uid.
>
> So, if you want to be sure that a tag is signed "with a specific uid" by
> relying on signatures from a set of signers, you would really need to
> check that the key that signed the tag has a signature on the correct
> uid. Having a signed key with the right uid in it doesn't mean much
> unlss the right uid is signed.
>
> E.g., I have a key with many signatures, and I could have Junio's uid on
> it in a minute without invalidating any of those signatures.

I have signatures on my primary key from others, and my signing key
is signed by my primary key and by no other keys.  Here is an
abbreviated output from running "gpg --list-sigs 96AFE6CB":

pub   4096R/713660A7 2011-10-01
uid  Junio C Hamano 
sig 3713660A7 2011-10-01  Junio C Hamano 
sig 3713660A7 2011-10-01  Junio C Hamano 
sig  F3119B9A 2011-10-01  Junio C Hamano 
sig  493BACE4 2011-10-04  H. Peter Anvin (hpa) 
sig  93674C40 2011-10-04  Theodore Y. Ts'o 
sig  00411886 2012-07-20  Linus Torvalds 
sig  C11804F0 2011-10-04  Theodore Ts'o 
sig  02A80207 2011-10-05  Andrew Morton (akpm) 

uid  Junio C Hamano 
sig 3713660A7 2011-10-01  Junio C Hamano 
sig  F3119B9A 2011-10-01  Junio C Hamano 
sig  493BACE4 2011-10-04  H. Peter Anvin (hpa) 
sig  00411886 2012-07-20  Linus Torvalds 
sig  C11804F0 2011-10-04  Theodore Ts'o 
uid  Junio C Hamano 
sig 3713660A7 2011-10-01  Junio C Hamano 
sig  F3119B9A 2011-10-01  Junio C Hamano 
sig  493BACE4 2011-10-04  H. Peter Anvin (hpa) 
sig  00411886 2012-07-20  Linus Torvalds 
sub   4096R/833262C4 2011-10-01
sig  713660A7 2011-10-01  Junio C Hamano 
sub   4096R/96AFE6CB 2011-10-03 [expires: 2017-09-20]
sig  713660A7 2015-09-21  Junio C Hamano 
sub   4096R/B3F7CAC9 2014-09-20 [expires: 2017-09-19]
sig  713660A7 2014-09-20  Junio C Hamano 

So I understand that the way you trust 96AFE6CB has to be indirect.
You may have somebody's key you know belongs to that somebody you
trust (say, Linus) in the list of signers of 713660A7 (my primary),
and you know 96AFE6CB is a key I use because it is signed by my
primary key.

You can add a subkey to your keyring a uid that says "Junio", but
the signature on that subkey would not have a signature by me you
can verify by following the web of trust.  You are correct to point
out that "this key claims to be by somebody, and it has some
signature" is not a sufficient reason for you to trust it.

> That one is easy already by setting "GNUPGHOME" to a special dir with a
> small keyring and tight trust settings (or having a dedicated account on
> the incoming side in the first place).

Yes, I understand that the above is how automated services per
project should be set up, with a dedicated verification keyring that
holds keys the project trusts.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: What's cooking in git.git (Jan 2016, #04; Wed, 20)

[Stefan Beller]

On Wed, Jan 27, 2016 at 12:46 AM, Lars Schneider
 wrote:
>
> On 26 Jan 2016, at 23:58, Junio C Hamano  wrote:
>
>> Lars Schneider  writes:
>>
>>> Hi Junio,
>>>
>>> Did you miss the topic "submodule: extend die message on failed
>>> checkout with depth argument" or do you not agree with it
>>> ($gmane/282779)? Stefan Beller reviewed the commits ($gmane/283666
>>> and $gmane/283851).
>>
>> No, these three are still in my inbox.
>>
>> Quite honestly, "test to demonstrate breakage" alone is not all that
>> interesting to me unless I get a firm impression that somebody is
>> (or will soon be) working on fixing the breakage--which would make
>> it worth keeping track of it in my tree, to allow the eventual fix
>> to be more easily verified and protected from getting broken again.
>> Also "these look good to me" without much explanation is not much of
>> a review, and such a comment on a "demonstrate breakage" did not add
>> to the sense of urgency to the issue, either.
>>
>> That was why it has been sitting near the bottom of the pile.
>
> OK, I get your point. I got the impression that Stefan is on to a fix 
> ($gmane/281260). Looks like he is not and I need to learn more about Git to 
> tackle fixes of this scope.

I was on it and I put it on hold as I wanted to prioritize
sb/submodule-parallel-update,
sb/submodule-init and the upcoming sb/submodule-groups (maybe that's called
sb/submodule-autoInit, its scope is still being bikehedded)

Coming back to $gmane/281260 with a fresh mind, I think
this is what we want on the client side:

 1) fetch as we always did. During this fetch we learn from the
servers capabilities list, if it supports fetching direct sha1s.
 2) if the needed sha1 has been fetched in step 1, stop.
 3) fetch the needed sha1 directly if the server supports it.
 4) if the server doesn't support it, display a message like:
"Please ask your Git server admin, to run at least Git 2.4.0
and enable uploadpack.allowReachableSHA1InWant to have
submodules working properly"

Currently we only perform step 1 and this yields the error when
fetching too shallow to have the needed sha1 included.

The server side should be ok as soon as uploadpack.allowReachableSHA1InWant
is enabled. I thought we would need to add another option, but it
looks like that
option is exactly what we need here.

If you want to give it a try, I'll be happy to review patches!
(with more than "these look good to me" ;)

Thanks,
Stefan

> Would it be an option for you to just drop patch 1/3 from this series and 
> look at the remaining ones? 2/3 fixes an "&& chain issue" ($gmane/282776) and 
> 3/3 prints a explanatory user warning instead of an incomprehensible error 
> ($gmane/282777).
>
> Thanks,
> Lars
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v4 1/2] merge-file: let conflict markers match end-of-line style of the context

[Junio C Hamano]

Johannes Schindelin  writes:

>> Just in case it was unclear, none of the comment above means I want
>> any part of the patch redone--I am happy with this patch as-is.
>
> Thanks for saying that... I was about to try to make things clearer, but I
> could not think of a better term than "needs_cr".

I don't, either ;-).

The primary reason I respond with the "I find this a bit confusing
but it probably is just me" (not just to this patch) is to give an
example of a review comment that demonstrates to the others that the
reviewer understood what is in the patch and the issues around the
change better than a mere unsubstantiated "These look OK to me.",
which does not tell us how carefully the proposed change was
reviewed by the reviewer--such a review does not allow me to "trust
the review that is already done by others" and apply the patches
with minimum cursory scanning and I end up having to carefully read
them myself.

--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v4 1/2] merge-file: let conflict markers match end-of-line style of the context

[Johannes Schindelin]

Hi Junio,

On Wed, 27 Jan 2016, Junio C Hamano wrote:

> Johannes Schindelin  writes:
> 
> >> Just in case it was unclear, none of the comment above means I want
> >> any part of the patch redone--I am happy with this patch as-is.
> >
> > Thanks for saying that... I was about to try to make things clearer, but I
> > could not think of a better term than "needs_cr".
> 
> I don't, either ;-).
> 
> The primary reason I respond with the "I find this a bit confusing
> but it probably is just me" (not just to this patch) is to give an
> example of a review comment that demonstrates to the others that the
> reviewer understood what is in the patch and the issues around the
> change better than a mere unsubstantiated "These look OK to me.",
> which does not tell us how carefully the proposed change was
> reviewed by the reviewer--such a review does not allow me to "trust
> the review that is already done by others" and apply the patches
> with minimum cursory scanning and I end up having to carefully read
> them myself.

Your response is also an indicator to me that future myself will find the
same code just as confusing as you did, though.

Maybe need_cr -> eol_is_crlf?

Ciao,
Dscho
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] travis-ci: run previously failed tests first, then slowest to fastest

[Junio C Hamano]

Clemens Buchacher  writes:

> Coming back to "[PATCH] optionally disable gitattributes": The topics
> are related, because they both deal with the situation where the work
> tree has files which are not normalized according to gitattributes. But
> my patch is more about saying: ok, I know I may have files which need to
> be normalized, but I want to ignore this issue for now. Please disable
> gitattributes for now, because I want to work with the files as they are
> committed. Conversely, the discussion here is about how to reliably
> detect and fix files which are not normalized.

I primarily wanted to make sure that you understood the underlying
issue, so that I do not have to go back to the basics in the other
thread.  And it is clear that you obviously do, which is good.

Here, you seem to think that what t0025 wants to see happen is
sensible, judging by the fact that you call "rm .git/index && git
reset" a "fix".

My take on this is quite different.  After a "reset --hard HEAD", we
should be able to trust the cached stat information and have "diff
HEAD" say "no changes".  That is what you essentially want in the
other thread, if I understand you correctly, and in an ideal world
where the filesystem timestamp has infinite precision, that is what
would happen in t0025, always "breaking" its expectation.  The real
world has much coarser timestamp granularity than ideal, and that is
why the test appear to be "flaky", failing to give "correct" outcome
some of the time--but I'd say that it is expecting a wrong thing.

An index entry that has data that does not round-trip when it goes
through convert_to_working_tree() and then convert_to_git() "breaks"
this arrangement, and I'd view it as the user having an inconsistent
data.  It is like you are in a repository that still has an unmerged
paths--you cannot proceed before you resolve them.

Anyway.

As to your patch in the other thread, here is what I think:

 (1) When you know (or perhaps your CI knows) that the working tree
 has never been modified since you did "reset --hard HEAD" (or
 its equivalent, like "git checkout $branch" from a clean
 state), these paths with inconsistent data would break the
 usual check to ask "is the working tree clean?"  That is a
 problem and we need a way to ensure that the working tree is
 always judged to be clean immediately after "reset --hard
 HEAD".  IOW, I agree with you that the issue you are trying to
 solve is worth solving.

 (2) Regardless of the "inconsistent data breaking the cleanliness
 check" issue, it may be handy to have a way to temporarily
 disable the attributes, i.e. allow us to ask "what happens if
 there is no attributes defined?"  IOW, I am saying that the
 change in the patch is not without merit.

In addition to (1), I further think that this sequence should not
report that the path F is modified:

 # Write F from HEAD to the working tree, after passing it
 # through convert_to_working_tree()
 $ git reset --hard HEAD

 # Force the re-reading, without changing the contents at all
 $ cp F F.new
 $ mv F.new F

 $ git diff HEAD

which is broken by paths with inconsistent data.  Your CI would want
a way to make that happen.

However, I do not think disabling attributes (i.e. (2)) is a
solution to the issue (i.e. (1)), which we just agreed to be an
issue that is worth solving, for at least two reasons.

 * Even without any attributes, core.autocrlf setting can get the
   data in your index (whose lines can be terminated with CRLF) into
   the same "inconsistent data" situation.  Disabling attribute
   handling would not have any effect on that codepath, I think.

 * The indexed data and the contents in the working tree file may
   match only because the clean/smudge transformation is done.  If
   you disable attributes, re-checking by passing the working tree
   contents through convert_to_git() and comparing the result with
   what is in the index would tell you that they are different, even
   if the clean/smudge filter pair implements round-trip operations
   correctly.

One way to solve (1) I can think of is to change the definition of
ce_compare_data(), which is called by the code that does not trust
the cached stat data (including but not limited to the Racy Git
codepath).  The current semantics of that function asks this
question:

We do not know if the working tree file and the indexed data
match.  Let's see if "git add" of that path would record the
data that is identical to what is in the index.

This definition was cast in stone by 29e4d363 (Racy GIT, 2005-12-20)
and has been with us since Git v1.0.0.  But that does not have to be
the only sensible definition of this check.  I wonder what would
break if we ask this question instead:

We do not know if the working tree file and the indexed data
match.  Let's see if "git checkout" of that path would leave the
same data as what 

Re: [PATCH v2 12/19] mingw: skip test in t1508 that fails due to path conversion

[Junio C Hamano]

Johannes Schindelin  writes:

> Hi Junio,
>
> On Tue, 26 Jan 2016, Junio C Hamano wrote:
>
>> Johannes Schindelin  writes:
>> 
>> > @@ -35,7 +35,10 @@ test_expect_success 'setup' '
>> >git checkout -b upstream-branch &&
>> >test_commit upstream-one &&
>> >test_commit upstream-two &&
>> > -  git checkout -b @/at-test &&
>> > +  if ! test_have_prereq MINGW
>> > +  then
>> > +  git checkout -b @/at-slash
>> 
>> I presume that this is meant to be "@/at-test", not "@/at-slash".
>
> Oh my. That's what you get for redoing patches from scratch. Sorry about
> that!

Heh.  That is why it makes me feel uneasy, after asking you to fetch
from me and fix it up, to hear that you will send in a new reroll.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v5 0/2] Let merge-file write out conflict markers with correct EOLs

[Junio C Hamano]

Thanks, will queue after looking at the interdiff since v4.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v4 1/2] merge-file: let conflict markers match end-of-line style of the context

[Junio C Hamano]

Johannes Schindelin  writes:

[administrivia: I finally managed to correct e-mail address of peff@,
which has been giving me bounces for all the previous messages in
the thread]

> Your response is also an indicator to me that future myself will find the
> same code just as confusing as you did, though.
>
> Maybe need_cr -> eol_is_crlf?

The crucial question is how well the variable conveys its meaning
when it has -1 as its value.  "need_cr? -- I don't know yet" is as
clear as "eol_is_crlf? -- I don't know yet", if not clearer.  I
personally do not think "eol_is_crlf" is an improvement.  It makes
it unclear _whose_ eol the variable is talking about.  It can be
misread as talking about one or more of the files that are being
merged and mistaken as a statement of a fact (i.e. "we inspected
and know the input file's eol is CRLF").

Compared to that, it is clear that "need_cr" is talking about what
the EOL convention the resulting file should be.

I briefly wondered if the if/if (need_cr)/... cascade that inspects
(conditionally up to) three variants might become cleaner if the
polarity of that variable is flipped (we are allowed to use CRLF
only when we know that among all of the three variants that we can
determine the line termination convention used, all of them use
CRLF), but I didn't think it through seriously.




--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [RFC] tag-ref and tag object binding

[Michael J Gruber]

Junio C Hamano venit, vidit, dixit 27.01.2016 19:10:
> Michael J Gruber  writes:
> 
>> Jeff King venit, vidit, dixit 27.01.2016 09:09:
>>
>>> The bigger issue is that gpg seems to give us only _one_ uid, when there
>>> may be several. E.g., Junio's v2.7.0 is signed by 96AFE6CB, which is a
>>> sub-key that has several uids associated with it. The one that "git
>>> verify-tag --raw" shows from gpg is gits...@pobox.com, which is good,
>>> but I think that's just because it happens to be the first uid. Or maybe
>>> there is some gpg arcana going on that I don't know about.
>>
>> You do not sign with a uid, you sign with a (sub)key, and the tag is
>> signed with Junio's primary key. His subkey is encryption only.
> 
> Hmm, actually I meant to sign my tags with signing subkey, not the
> primary one, but I may have made a mistake.

Oops, I needed to refresh my copy of your key, sorry. You did sign 2.7.0
with the subkey 0xB0B5E88696AFE6CB

>> You do sign a uid.
>>
>> So, if you want to be sure that a tag is signed "with a specific uid" by
>> relying on signatures from a set of signers, you would really need to
>> check that the key that signed the tag has a signature on the correct
>> uid. Having a signed key with the right uid in it doesn't mean much
>> unlss the right uid is signed.
>>
>> E.g., I have a key with many signatures, and I could have Junio's uid on
>> it in a minute without invalidating any of those signatures.
> 
> I have signatures on my primary key from others, and my signing key
> is signed by my primary key and by no other keys.  Here is an
> abbreviated output from running "gpg --list-sigs 96AFE6CB":
> 
> pub   4096R/713660A7 2011-10-01
> uid  Junio C Hamano 
> sig 3713660A7 2011-10-01  Junio C Hamano 
> sig 3713660A7 2011-10-01  Junio C Hamano 
> sig  F3119B9A 2011-10-01  Junio C Hamano 
> sig  493BACE4 2011-10-04  H. Peter Anvin (hpa) 
> sig  93674C40 2011-10-04  Theodore Y. Ts'o 
> sig  00411886 2012-07-20  Linus Torvalds 
> 
> sig  C11804F0 2011-10-04  Theodore Ts'o 
> sig  02A80207 2011-10-05  Andrew Morton (akpm) 
> 
> uid  Junio C Hamano 
> sig 3713660A7 2011-10-01  Junio C Hamano 
> sig  F3119B9A 2011-10-01  Junio C Hamano 
> sig  493BACE4 2011-10-04  H. Peter Anvin (hpa) 
> sig  00411886 2012-07-20  Linus Torvalds 
> 
> sig  C11804F0 2011-10-04  Theodore Ts'o 
> uid  Junio C Hamano 
> sig 3713660A7 2011-10-01  Junio C Hamano 
> sig  F3119B9A 2011-10-01  Junio C Hamano 
> sig  493BACE4 2011-10-04  H. Peter Anvin (hpa) 
> sig  00411886 2012-07-20  Linus Torvalds 
> 
> sub   4096R/833262C4 2011-10-01
> sig  713660A7 2011-10-01  Junio C Hamano 
> sub   4096R/96AFE6CB 2011-10-03 [expires: 2017-09-20]
> sig  713660A7 2015-09-21  Junio C Hamano 
> sub   4096R/B3F7CAC9 2014-09-20 [expires: 2017-09-19]
> sig  713660A7 2014-09-20  Junio C Hamano 
> 
> So I understand that the way you trust 96AFE6CB has to be indirect.
> You may have somebody's key you know belongs to that somebody you
> trust (say, Linus) in the list of signers of 713660A7 (my primary),
> and you know 96AFE6CB is a key I use because it is signed by my
> primary key.
> 
> You can add a subkey to your keyring a uid that says "Junio", but
> the signature on that subkey would not have a signature by me you
> can verify by following the web of trust.  You are correct to point
> out that "this key claims to be by somebody, and it has some
> signature" is not a sufficient reason for you to trust it.

"subkey" and "uid" are different things. You bind a subkey to your
primary key with that self-signature. subkeys don't carry any other
signatures.

A primary key "carries" the uids, and whenever someone "signs your key"
they in fact sign a specific uid - usually all, resulting in multiple
signatures, one for each uid of the (primary) key.

A key is usually considered trusted if it carries "a" signature from a
trusted key.

So, assuming my key carries a signature from a trusted key to at least
one uid, it would be trusted no matter what (fake) uids I add to it later.

>> That one is easy already by setting "GNUPGHOME" to a special dir with a
>> small keyring and tight trust settings (or having a dedicated account on
>> the incoming side in the first place).
> 
> Yes, I understand that the above is how automated services per
> project should be set up, with a 

Re: [RFC] tag-ref and tag object binding

[Jeff King]

On Wed, Jan 27, 2016 at 09:09:31PM +0100, Michael J Gruber wrote:

> "subkey" and "uid" are different things. You bind a subkey to your
> primary key with that self-signature. subkeys don't carry any other
> signatures.
> 
> A primary key "carries" the uids, and whenever someone "signs your key"
> they in fact sign a specific uid - usually all, resulting in multiple
> signatures, one for each uid of the (primary) key.
> 
> A key is usually considered trusted if it carries "a" signature from a
> trusted key.
> 
> So, assuming my key carries a signature from a trusted key to at least
> one uid, it would be trusted no matter what (fake) uids I add to it later.

Right. I think I didn't do a good job of explaining myself earlier, so
let me try to rephrase.

When we look at the v2.7 tag, GPG sees that we are signed by Junio's
subkey, 96AFE6CB. It then knows that belongs to the main public key
713660A7, because the main key signed the subkey. And then it sees that
there are several uids for that main key, each with their own signatures
by other people.

So of the three uids that I have for that key:

  pub   4096R/713660A7 2011-10-01
  uid  Junio C Hamano 
  uid  Junio C Hamano 
  uid  Junio C Hamano 

it reports back to git only one (the pobox.com), which we relay to the
user via --raw. If we wanted to check that the key matches the "tagger"
header, that works. But why did gpg return that first uid, and not any
of the others? We would ideally see all of them, and consider it OK if
it matches any uid (assuming that uid is sufficiently signed for gpg to
consider it valid).

Weirder, if you _don't_ use "--raw", the human-readable output gives us
all of the uids as "aka" lines:

  $ git verify-tag v2.7.0
  $ git verify-tag v2.7.0
  gpg: Signature made Mon 04 Jan 2016 05:08:12 PM EST using RSA key ID 96AFE6CB
  gpg: Good signature from "Junio C Hamano "
  gpg: aka "Junio C Hamano "
  gpg: aka "Junio C Hamano "

  $ git verify-tag --raw v2.7.0
  [GNUPG:] SIG_ID xFANmHj+QJ1gwIcoRuT5BF/y8H4 2016-01-04 1451945292
  [GNUPG:] GOODSIG B0B5E88696AFE6CB Junio C Hamano 
  [GNUPG:] VALIDSIG E1F036B1FEE7221FC778ECEFB0B5E88696AFE6CB 2016-01-04 
1451945292 0 4 0 1 2 00 96E07AF25771955980DAD10020D04E5A713660A7
  [GNUPG:] TRUST_FULLY

It seems like we should be able to get the raw-output to tell us all of
those uids. I guess it is not the end of the world to go back to gpg and
say "give me all of the valid uids that match this signing key", but it
seems silly to have to do so.

-Peff
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] git-svn: shorten glob error message

[Junio C Hamano]

Eric Wong  writes:

> Junio C Hamano  wrote:
>> I am not sure if it is a good idea to show */*/* as an example in
>> the message (that is an anti-example of 'one set of wildcard' by
>> having three stars, isn't it?), but that is not a new issue this
>> change introduces.
>
> Actually, going back to commit 570d35c26dfbc40757da6032cdc96afb58cc0037
> ("git-svn: Allow deep branch names by supporting multi-globs"),
> having equal '*' on both sides is all that is required.
>
> Not sure how to improve the wording, though...

I dunno, either, and that is why "not a new issue", iow, the patch
is good as-is.  The wording might be an area with possible future
improvement, but that does not have to block the improvement the
patch under discussion brings us.

Thanks.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v2 00/19] Let Git's tests pass on Windows

[Junio C Hamano]

Johannes Schindelin  writes:

> I made a couple of other adjustments anyway, so expect a new iteration
> shortly. This time cross-checked on Linux.

Thanks, will take a look.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] travis-ci: run previously failed tests first, then slowest to fastest

[Junio C Hamano]

Junio C Hamano  writes:

> One way to solve (1) I can think of is to change the definition of
> ce_compare_data(), which is called by the code that does not trust
> the cached stat data (including but not limited to the Racy Git
> codepath).  The current semantics of that function asks this
> question:
>
> We do not know if the working tree file and the indexed data
> match.  Let's see if "git add" of that path would record the
> data that is identical to what is in the index.
>
> This definition was cast in stone by 29e4d363 (Racy GIT, 2005-12-20)
> and has been with us since Git v1.0.0.  But that does not have to be
> the only sensible definition of this check.  I wonder what would
> break if we ask this question instead:
>
> We do not know if the working tree file and the indexed data
> match.  Let's see if "git checkout" of that path would leave the
> same data as what currently is in the working tree file.
>
> If we did this, "reset --hard HEAD" followed by "diff HEAD" will by
> definition always report "is clean" as long as nobody changes files
> in the working tree, even with the inconsistent data in the index.
>
> This still requires that convert_to_working_tree(), i.e. your smudge
> filter, is deterministic, though, but I think that is a sensible
> assumption for sane people, even for those with inconsistent data in
> the index.

Just a few additional comments.

The primary reason why I originally chose "does 'git add' of what is
in the working tree give us the same blob in the index?" as opposed
to "does 'git checkout' from the index again will give the same
result in the working tree?" is because it is a lot less resource
intensive and also is simpler.  Back then I do not think we had a
streaming interface to hash huge contents from a file in the working
tree, but it requires us to read the entire file from the filesystem
just once, apply the convert_to_git() processing and then hash the
result, whether we keep the whole thing in core at once or process
the data in streaming fashion.  Doing the other check will have to
inflate the blob data and apply the convert_to_working_tree()
processing, and also read the whole thing from the filesystem and
compare, which is more work at runtime.  And for a sane set-up where
the data in the index does not contradict with the clean/smudge
filter and EOL settings, both would yield the same result.

If we were to switch the semantics of ce_compare_data(), we would
want a new sibling interface next to stream_blob_to_fd() that takes
a file descriptor opened on the file in the working tree for reading
(fd), the object name (sha1), and the output filter, and works very
similarly to stream_blob_to_fd().  The difference would be that we
would be reading from the fd (i.e. the file in the working tree) as
we read from the istream (i.e. the contents of the blob in the
index, after passing the convert_to_working_tree() filter) and
comparing them in the main loop.  The filter parameter to the
function would be obtained by calling get_stream_filter() just like
how write_entry() uses it to prepare the filter parameter to call
streaming_write_entry() with.  That way, we can rely on future
improvement of the streaming interface to make sure we keep the data
we have to keep in core to the minimum.

IOW, I am saying that the "add --fix-index" lunchbreak patch I sent
earlier in the thread that has to hold the data in-core while
processing is not a production quality patch ;-)



--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Need support with git credential storage

[Charles Bélanger]

Hello Git Community,

I'm working at AddEnergie at Quebec city in Canada and I'm currently working on 
making a Build Server in a Virtual Machine running Ubuntu.
We are using git for our source code and I'm the first one here that need to 
use git store credentials for an Automated Build Server that would run 
overnight.

I'm wondering if you could provide me support about it because I'm having issue 
making it works.
The clue I have right now about my git store credential issue is when I'm doing 
a git clone of my project repo, I'm having following errors:

Here's the git clone command launch by a .sh script file called from ~/.profile:
git clone https://myusern...@bitbucket.org/CompanyName/ProjectName.git 
~/Projects/SubFolderName/ProjectName

Here's the error from bash .profile:
Fatal: unable to access 
'https://myusern...@bitbucket.org/CompanyName/ProjectName.git/':
Could not resolve host: bitbucket.org

I followed the excellent Web page here:
https://git-scm.com/book/be/v2/Git-Tools-Credential-Storage

Here's what I use as commands:
git credential-store --file ~/git.store store
protocol=https
host=bitbucket.org/CompanyName/ProjectName.git
username=MyUserName
password=MyPassword
(type enter on a blank line to exit)

git credential-store --file ~/git.store get
protocol=https
host=bitbucket.org/CompanyName/ProjectName.git
(type enter on a blank line to exit)


Here's what the ~/git.store file looks like:

https://MyUserName:mypassw...@bitbucket.org%2fCompanyName%2fProjectName.git

I tried changing the %2f by / inside the git.store file and also tried // but 
it's still showing the same fatal error.
Perhaps I don't use the host=  property correctly.

May I ask you helping me with this ?

Best Regards,

Charles Belanger
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCHv4 0/2] Port `git submodule init` from shell to C

[Stefan Beller]

Hi,

I looked at this patch series again and fixed all memory leaks as found by
coverity scan.

This applies on top of sb/submodule-parallel-update

Thanks,
Stefan

Interdiff to v3:
diff --git a/builtin/submodule--helper.c b/builtin/submodule--helper.c
index c9b0c05..dd8b2a5 100644
--- a/builtin/submodule--helper.c
+++ b/builtin/submodule--helper.c
@@ -35,7 +35,7 @@ static char *get_default_remote(void)
if (git_config_get_string(sb.buf, ))
ret = xstrdup("origin");
else
-   ret = xstrdup(dest);
+   ret = dest;
 
strbuf_release();
return ret;
@@ -188,6 +188,7 @@ static int resolve_relative_url(int argc, const char 
**argv, const char *prefix)
res = relative_url(remoteurl, url, up_path);
puts(res);
free(res);
+   free(remoteurl);
return 0;
 }
 
@@ -209,6 +210,7 @@ static int resolve_relative_url_test(int argc, const char 
**argv, const char *pr
res = relative_url(remoteurl, url, up_path);
puts(res);
free(res);
+   free(remoteurl);
return 0;
 }
 
@@ -222,8 +224,9 @@ static void init_submodule(const char *path, const char 
*prefix, int quiet)
const struct submodule *sub;
struct strbuf sb = STRBUF_INIT;
char *url = NULL;
-   const char *upd = NULL;
-   const char *displaypath = relative_path(xgetcwd(), prefix, );
+   char *upd = NULL;
+   char *cwd = xgetcwd();
+   const char *displaypath = relative_path(cwd, prefix, );
 
/* Only loads from .gitmodules, no overlay with .git/config */
gitmodules_config();
@@ -261,6 +264,7 @@ static void init_submodule(const char *path, const char 
*prefix, int quiet)
remoteurl = xgetcwd();
url = relative_url(remoteurl, url, NULL);
strbuf_release();
+   free(remoteurl);
}
 
if (git_config_set(sb.buf, url))
@@ -269,26 +273,27 @@ static void init_submodule(const char *path, const char 
*prefix, int quiet)
if (!quiet)
printf(_("Submodule '%s' (%s) registered for path 
'%s'\n"),
sub->name, url, displaypath);
-   free(url);
}
 
/* Copy "update" setting when it is not set yet */
strbuf_reset();
strbuf_addf(, "submodule.%s.update", sub->name);
-   if (git_config_get_string_const(sb.buf, ) && sub->update) {
-   upd = sub->update;
+   if (git_config_get_string(sb.buf, ) && sub->update) {
+   upd = xstrdup(sub->update);
if (strcmp(sub->update, "checkout") &&
strcmp(sub->update, "rebase") &&
strcmp(sub->update, "merge") &&
strcmp(sub->update, "none")) {
fprintf(stderr, _("warning: unknown update mode '%s' 
suggested for submodule '%s'\n"),
upd, sub->name);
-   upd = "none";
+   upd = xstrdup("none");
}
if (git_config_set(sb.buf, upd))
die(_("Failed to register update mode for submodule 
path '%s'"), displaypath);
}
strbuf_release();
+   free(cwd);
+   free(upd);
+   free(url);
 }
 
 static int module_init(int argc, const char **argv, const char *prefix)


Stefan Beller (2):
  submodule: port resolve_relative_url from shell to C
  submodule: port init from shell to C

 builtin/submodule--helper.c | 326 +++-
 git-submodule.sh| 118 +---
 t/t0060-path-utils.sh   |  42 ++
 3 files changed, 366 insertions(+), 120 deletions(-)

-- 
2.7.0.rc0.42.ge5f5e2d

--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] git.c: fix help.autocorrect after 57ea712 breaks it

[Junio C Hamano]

Duy Nguyen  writes:

> On Wed, Jan 27, 2016 at 1:49 PM, Junio C Hamano  wrote:
>> Junio C Hamano  writes:
>>
>>> I spoke too soon, I am afraid.
>>> ...
>>> I wonder if this would be better done as a multi-part series that
>>> goes like this:
>>> ...
>>
>> So here is the first of the three-patch series to replace it.
>
> This is much better (the whole series, not just the first patch). We
> probably should add a test about help.autocorrect though, maybe in the
> first patch, because it's not tested at all in the test suite.

Patches welcome.  Thanks.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] optionally disable gitattributes

[Junio C Hamano]

Clemens Buchacher  writes:

> If committed files are not normalized, adding gitattributes has the
> side effect that such files are shown as modified, even though they
> were not actually modified by the user, and the work tree matches
> the committed file. This is because with gitattributes, the file is
> modified on the fly when git reads it from disk, before it compares
> with the index contents.
>
> This is desirable in most situations, because it makes the user
> aware that files should be normalized. However, it can become an
> issue for automation. Since Git considers the work tree to be
> dirty, some operations such as git rebase or git cherry-pick refuse
> to operate. Those commands offer no flag to force overwrite work
> tree changes. The only options are to commit the changes, or to
> remove gitattributes, but that changes the repository state, which
> may be undesirable in a scripted context.
>
> Introduce an environment variable GIT_ATTRIBUTES_DISABLED, which if
> set makes Git ignore any gitattributes.
>
> Signed-off-by: Clemens Buchacher 
> ---

Is the problem you are trying to solve related to the issue we
discussed recently in a nearby thread?

That is, even after "reset --hard", if the result of converting the
contents in the index to the working tree representation and then
converting that result back to the normalized representation does
not match what is in the index, Git would sometimes say that the
working tree contents differ from the index?

I think the change in this patch has some uses, and I think the
issue we discussed recently in a nearby thread indeed is a problem,
but I do not think there is an impedance mismatch beween the two, so
I'd like to first make sure you are trying to solve the problem I
think you are trying to solve.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: What's cooking in git.git (Jan 2016, #04; Wed, 20)

[Lars Schneider]

On 26 Jan 2016, at 23:58, Junio C Hamano  wrote:

> Lars Schneider  writes:
> 
>> Hi Junio,
>> 
>> Did you miss the topic "submodule: extend die message on failed
>> checkout with depth argument" or do you not agree with it
>> ($gmane/282779)? Stefan Beller reviewed the commits ($gmane/283666
>> and $gmane/283851).
> 
> No, these three are still in my inbox.
> 
> Quite honestly, "test to demonstrate breakage" alone is not all that
> interesting to me unless I get a firm impression that somebody is
> (or will soon be) working on fixing the breakage--which would make
> it worth keeping track of it in my tree, to allow the eventual fix
> to be more easily verified and protected from getting broken again.
> Also "these look good to me" without much explanation is not much of
> a review, and such a comment on a "demonstrate breakage" did not add
> to the sense of urgency to the issue, either.
> 
> That was why it has been sitting near the bottom of the pile.

OK, I get your point. I got the impression that Stefan is on to a fix 
($gmane/281260). Looks like he is not and I need to learn more about Git to 
tackle fixes of this scope. Would it be an option for you to just drop patch 
1/3 from this series and look at the remaining ones? 2/3 fixes an "&& chain 
issue" ($gmane/282776) and 3/3 prints a explanatory user warning instead of an 
incomprehensible error ($gmane/282777).

Thanks,
Lars--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: git for windows

[Andrey Chernyshov]

On 1/27/2016 2:35 PM, Andrey Chernyshov wrote:


On 1/27/2016 2:32 PM, Andrey Chernyshov wrote:

Hi

I'm using PHP storm with git for windows. Once I do a push to the 
github I get the following error

Problem signature:
  Problem Event Name:APPCRASH
  Application Name:git-remote-https.exe
  Application Version:2.7.0.0
  Application Timestamp:35316130
  Fault Module Name:libidn-11.dll
  Fault Module Version:0.0.0.0
  Fault Module Timestamp:00170158
  Exception Code:c005
  Exception Offset:46bc
  OS Version:6.3.9600.2.0.0.256.4
  Locale ID:1033
  Additional Information 1:a547
  Additional Information 2:a54764e1ee4f5613d3fc9395100a0ff4
  Additional Information 3:ac01
  Additional Information 4:ac010ce737711604ec050156caebd625

Read our privacy statement online:
http://go.microsoft.com/fwlink/?linkid=280262

If the online privacy statement is not available, please read our 
privacy statement offline:

  C:\windows\system32\en-US\erofflps.txt


If I try to push with Git GUI, it's the same, so not a PHPStorm issue...

--
Thanks, Andrey.


--
Thanks, Andrey.


--
Thanks, Andrey.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v2 19/19] mingw: do not bother to test funny file names

[Johannes Schindelin]

Hi Eric,

On Tue, 26 Jan 2016, Eric Sunshine wrote:

> On Tue, Jan 26, 2016 at 9:35 AM, Johannes Schindelin
>  wrote:
> > MSYS2 actually allows to create files or directories whose names contain
> > tabs, newlines or colors, even if plain Win32 API cannot access them.
> > As we are using an MSYS2 bash to run the tests, such files or
> > directories are created successfully, but Git itself has no chance to
> > work with them because it is a regular Windows program, hence limited by
> > the Win32 API.
> > [...]
> > Signed-off-by: Johannes Schindelin 
> > ---
> > diff --git a/t/t3600-rm.sh b/t/t3600-rm.sh
> > @@ -14,7 +14,8 @@ test_expect_success \
> > -if touch -- 'tab   embedded' 'newline
> > +
> 
> Is this new blank line intentional?

Absolutely not! ;-) Fixed.

> > +if ! test_have_prereq MINGW && touch -- 'tab   embedded' 'newline
> > [...]
> > +test_have_prereq !MINGW &&
> 
> Where negation is concerned, is there a non-obvious reason that this
> patch sometimes says:
> 
> ! test_have_prereq MINGW
> 
> and sometimes:
> 
> test_have_prereq !MINGW
> 
> ? Is one form preferred over the other?

Hysterical raisins. I changed all of them to the latter form, as suggested
by Junio.

Ciao,
Dscho
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v2] t0027: Add tests for get_stream_filter()

[Torsten Bögershausen]

- This needs to go on top of  tb/ls-files-eol


With missing "separate commit", I am having a hard time to decide if
this is something I should pick up at this moment, or I should wait
until that separate commit materializes.  What is your intention?


I send a serious including this patch the next days.
If there are more review comments, they are welcome.

--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] git.c: fix help.autocorrect after 57ea712 breaks it

[Duy Nguyen]

On Wed, Jan 27, 2016 at 1:49 PM, Junio C Hamano  wrote:
> Junio C Hamano  writes:
>
>> I spoke too soon, I am afraid.
>> ...
>> I wonder if this would be better done as a multi-part series that
>> goes like this:
>> ...
>
> So here is the first of the three-patch series to replace it.

This is much better (the whole series, not just the first patch). We
probably should add a test about help.autocorrect though, maybe in the
first patch, because it's not tested at all in the test suite.
-- 
Duy
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] convert: legitimately disable clean/smudge filter with an empty override

[Lars Schneider]

On 24 Jan 2016, at 22:45, Jeff King  wrote:

> On Sun, Jan 24, 2016 at 01:22:50PM +0100, larsxschnei...@gmail.com wrote:
> 
>> From: Lars Schneider 
>> 
>> A clean/smudge filter can be disabled if set to an empty string. However,
>> Git will try to run the empty string as command which results in a error
>> message per processed file.
>> 
>> Teach Git to consider an empty clean/smudge filter as legitimately disabled
>> and do not print an error message.
> 
> That makes sense to me, as I do not think the empty filter name can
> possibly do anything useful. You omitted the real motivation here, but I
> know what it is from past discussions: you want to be able to
> temporarily disable a filter with "git -c filter.foo.clean= ...". Which
> I think makes it more immediately obvious that this is a useful thing to
> have, and not just user error.
> 
>> diff --git a/convert.c b/convert.c
>> index 814e814..58af965 100644
>> --- a/convert.c
>> +++ b/convert.c
>> @@ -786,7 +786,7 @@ int convert_to_git(const char *path, const char *src, 
>> size_t len,
>>  struct conv_attrs ca;
>> 
>>  convert_attrs(, path);
>> -if (ca.drv) {
>> +if (ca.drv && ca.drv->clean && strlen(ca.drv->clean)) {
>>  filter = ca.drv->clean;
>>  required = ca.drv->required;
>>  }
>> @@ -835,7 +835,7 @@ static int convert_to_working_tree_internal(const char 
>> *path, const char *src,
>>  struct conv_attrs ca;
>> 
>>  convert_attrs(, path);
>> -if (ca.drv) {
>> +if (ca.drv && ca.drv->smudge && strlen(ca.drv->smudge)) {
>>  filter = ca.drv->smudge;
>>  required = ca.drv->required;
>>  }
> 
> This catches two calls, but I think there are others. What about
> would_convert_to_git_filter_fd and convert_to_git_filter_fd?
> 
> Would it make more sense for apply_filter() to treat the empty string as
> a noop, just as it does for NULL?

Yes :-)

Thanks,
Lars

> 
> I.e.:
> 
> 
> diff --git a/convert.c b/convert.c
> index 814e814..02d5f1e 100644
> --- a/convert.c
> +++ b/convert.c
> @@ -395,7 +395,7 @@ static int apply_filter(const char *path, const char 
> *src, size_t len, int fd,
>   struct async async;
>   struct filter_params params;
> 
> - if (!cmd)
> + if (!cmd || !*cmd)
>   return 0;
> 
>   if (!dst)
> 
> which I think would cover all callers?
> 
> -Peff

--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] convert: legitimately disable clean/smudge filter with an empty override

[Lars Schneider]

On 24 Jan 2016, at 22:35, Eric Sunshine  wrote:

> On Sun, Jan 24, 2016 at 10:06 AM, Torsten Bögershausen  wrote:
>> On 24.01.16 13:22, larsxschnei...@gmail.com wrote:
>>> From: Lars Schneider 
>>> diff --git a/convert.c b/convert.c
>>> @@ -786,7 +786,7 @@ int convert_to_git(const char *path, const char *src, 
>>> size_t len,
>>>  struct conv_attrs ca;
>>> 
>>>  convert_attrs(, path);
>>> - if (ca.drv) {
>>> + if (ca.drv && ca.drv->clean && strlen(ca.drv->clean)) {
> 
> More idiomatic:
> 
>if (ca.drv && ca.drv->clean && *ca.drv->clean) {
Agreed! Although I will go with Jeff's suggestion to implement that
logic in apply_filter.


> 
>>>  filter = ca.drv->clean;
>>>  required = ca.drv->required;
>>>  }
>>> @@ -835,7 +835,7 @@ static int convert_to_working_tree_internal(const char 
>>> *path, const char *src,
>>>  struct conv_attrs ca;
>>> 
>>>  convert_attrs(, path);
>>> - if (ca.drv) {
>>> + if (ca.drv && ca.drv->smudge && strlen(ca.drv->smudge)) {
> 
> Ditto.
> 
>>>  filter = ca.drv->smudge;
>>>  required = ca.drv->required;
>>>  }
>>> diff --git a/t/t0021-conversion.sh b/t/t0021-conversion.sh
>>> @@ -252,4 +252,18 @@ test_expect_success "filter: smudge empty file" '
>>> +test_expect_success 'disable filter with empty override' '
>>> + git config filter.disable.smudge false &&
>>> + git config filter.disable.clean false &&
> 
> test_config perhaps?

I was wondering about that, too. Especially because I could also use 
test_config_global.
Why does no test in t0021 use these functions? Should that be fixed?


> 
>>> + echo "*.disable filter=disable" >.gitattributes &&
>>> +
>>> + echo test >test.disable &&
>>> + git -c filter.disable.clean= add test.disable 2>err &&
>>> + ! test -s err &&
>> How about
>> test_cmp /dev/null err
>> to make debugging easier ?
> 
> Even better:
> 
>test_must_be_empty err &&

True! I will use that.

Thanks,
Lars
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v2 12/19] mingw: skip test in t1508 that fails due to path conversion

[Johannes Schindelin]

Hi Junio,

On Tue, 26 Jan 2016, Junio C Hamano wrote:

> Johannes Schindelin  writes:
> 
> > @@ -35,7 +35,10 @@ test_expect_success 'setup' '
> > git checkout -b upstream-branch &&
> > test_commit upstream-one &&
> > test_commit upstream-two &&
> > -   git checkout -b @/at-test &&
> > +   if ! test_have_prereq MINGW
> > +   then
> > +   git checkout -b @/at-slash
> 
> I presume that this is meant to be "@/at-test", not "@/at-slash".

Oh my. That's what you get for redoing patches from scratch. Sorry about
that!

Ciao,
Dscho
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [RFC] tag-ref and tag object binding

[Michael J Gruber]

Jeff King venit, vidit, dixit 27.01.2016 09:09:
> On Wed, Jan 27, 2016 at 08:53:08AM +0100, Michael J Gruber wrote:
> 
>>> Yeah, definitely. My thinking was that `verify-tag` could learn a series
>>> of optional consistency checks, enabled by command line options, and
>>> verifying programs (or humans) could turn them on to avoid having to
>>> replicate them manually. So something like:
>>>
>>>   git verify-tag \
>>> --verify-tagger-matches-key \
>>> --verify-tag-matches-ref \ # or --verify-tag-matches=v2.0.0
>>> v2.0.0
>>>
>>> or to implement more specific policy, maybe an option to check for a
>>> _specific_ tagger, either by email (as provided by gpg) or even key-id.
>>>
>>> Those are all things that are not _too_ hard to do if you're willing to
>>> parse gpg or git output, but we could make life easier for our callers.
>>> And hopefully by asking for specific, concrete checks, it doesn't
>>> introduce a false sense of security. I.e., we're not making a foolproof
>>> tool; we're making building blocks that one could use for a more
>>> foolproof tool.
>>
>> OK, let's make a tool that helps fooling as well as proofing :)
>>
>> I'll look into the tag header check. Maybe "--check-tagname"? "check"
>> seems to imply less than "verify".
> 
> Yeah, I think that is fine (I actually wrote --check originally; I'm not
> quite sure why I decided to change it).
> 
>> As for the gpg related stuff: We provide the full diagnostic output from
>> gpg on request. But I think a mismatch between the signing key's uid and
>> the taggers' name/email is more common than not,
> 
> Is it? I'd think if you are using that name with a signed tag, you would
> bother to issue (and get people to sign) the matching uid. Certainly it
> is the case for git and linux signatures, but I admit that it a pretty
> small sampling size.
> 
> The bigger issue is that gpg seems to give us only _one_ uid, when there
> may be several. E.g., Junio's v2.7.0 is signed by 96AFE6CB, which is a
> sub-key that has several uids associated with it. The one that "git
> verify-tag --raw" shows from gpg is gits...@pobox.com, which is good,
> but I think that's just because it happens to be the first uid. Or maybe
> there is some gpg arcana going on that I don't know about.

You do not sign with a uid, you sign with a (sub)key, and the tag is
signed with Junio's primary key. His subkey is encryption only.

uids do not identify keys, you can add and delete them at will without
changing the primary key id. To help recognize ("identify") a key, gpg
displays the uid with the most recent self-signature, which is usually
the most "recent uid".

You do sign a uid.

So, if you want to be sure that a tag is signed "with a specific uid" by
relying on signatures from a set of signers, you would really need to
check that the key that signed the tag has a signature on the correct
uid. Having a signed key with the right uid in it doesn't mean much
unlss the right uid is signed.

E.g., I have a key with many signatures, and I could have Junio's uid on
it in a minute without invalidating any of those signatures.

>> and on the other hand a
>> signature by a key identified by its uid is meaningless unless you keep
>> your keyring tidy... We could punt on that and let users identify the
>> key by any means that gpg allows, of course, and check that the
>> signature comes from whatever "gpg --list-key " gives as
>> long as it's unique.
> 
> Right, I think it's an open question whether people actually participate
> in the web of trust. I don't have a good signature path to Junio's key,
> but I happen to know what it is based on past interaction.
> 
> But then, I also do not really verify tags. Why would I? I routinely
> fetch and run "make" on the result, and there is no cryptographic
> protection there at all. Verifying tag signatures after a release seems
> all but pointless. :)

No signature protects us from our own dogfood :)

> I think for any of this to be useful, it has to be part of some tool
> that is very opinionated on policy. E.g., imagine a post-fetch hook that
> validated that each incoming commit was signed, and that the signer was
> part of a whitelisted group of keys that you "somehow" got hold of
> out-of-band for your project. That is not that useful for an open-source
> project, but I could see the appeal for a proprietary development
> environment.

That one is easy already by setting "GNUPGHOME" to a special dir with a
small keyring and tight trust settings (or having a dedicated account on
the incoming side in the first place).

Michael
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] convert: legitimately disable clean/smudge filter with an empty override

[Lars Schneider]

On 24 Jan 2016, at 16:06, Torsten Bögershausen  wrote:

> On 24.01.16 13:22, larsxschnei...@gmail.com wrote:
>> From: Lars Schneider 
> Some minor nits inside: 
>> 
>> A clean/smudge filter can be disabled if set to an empty string. 
> "set to an empty string" refers to "git config" (in opposite to the
> filter as such, which is specified in .gitattributes.
> Does it make sense to write 
> "git config filter.XXX.smudge ''" or so ?

I am not sure I get what you want here. Would this work for you?

The clean/smudge filter commands (filter.XYZ.smudge and filter.XYZ.clean)
can be disabled if set to an empty string. However, Git will still consider the 
empty string as command which results in a error message per processed 
file.


> 
>> However,
>> Git will try to run the empty string as command which results in a error
>> message per processed file.
>> 
>> Teach Git to consider an empty clean/smudge filter as legitimately disabled
>> and do not print an error message.
>> 
>> Signed-off-by: Lars Schneider 
>> ---
>> convert.c |  4 ++--
>> t/t0021-conversion.sh | 14 ++
>> 2 files changed, 16 insertions(+), 2 deletions(-)
>> 
>> diff --git a/convert.c b/convert.c
>> index 814e814..58af965 100644
>> --- a/convert.c
>> +++ b/convert.c
>> @@ -786,7 +786,7 @@ int convert_to_git(const char *path, const char *src, 
>> size_t len,
>>  struct conv_attrs ca;
>> 
>>  convert_attrs(, path);
>> -if (ca.drv) {
>> +if (ca.drv && ca.drv->clean && strlen(ca.drv->clean)) {
>>  filter = ca.drv->clean;
>>  required = ca.drv->required;
>>  }
>> @@ -835,7 +835,7 @@ static int convert_to_working_tree_internal(const char 
>> *path, const char *src,
>>  struct conv_attrs ca;
>> 
>>  convert_attrs(, path);
>> -if (ca.drv) {
>> +if (ca.drv && ca.drv->smudge && strlen(ca.drv->smudge)) {
>>  filter = ca.drv->smudge;
>>  required = ca.drv->required;
>>  }
>> diff --git a/t/t0021-conversion.sh b/t/t0021-conversion.sh
>> index 718efa0..56e385c 100755
>> --- a/t/t0021-conversion.sh
>> +++ b/t/t0021-conversion.sh
>> @@ -252,4 +252,18 @@ test_expect_success "filter: smudge empty file" '
>>  test_cmp expected filtered-empty-in-repo
>> '
>> 
>> +test_expect_success 'disable filter with empty override' '
>> +git config filter.disable.smudge false &&
>> +git config filter.disable.clean false &&
>> +
>> +echo "*.disable filter=disable" >.gitattributes &&
>> +
>> +echo test >test.disable &&
>> +git -c filter.disable.clean= add test.disable 2>err &&
>> +! test -s err &&
> How about 
> test_cmp /dev/null err
> to make debugging easier ?
Right. Although I would probably go with Eric's suggestion and use 
"test_must_be_empty".

That being said, I copied "! test -s" from the "filter large file" test in this 
file (added with 0b6806b).
How does the list handle these cases? Should I add another commit to replace "! 
test -s" there, 
too?

Thanks,
Lars--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH] optionally disable gitattributes

[Clemens Buchacher]

If committed files are not normalized, adding gitattributes has the
side effect that such files are shown as modified, even though they
were not actually modified by the user, and the work tree matches
the committed file. This is because with gitattributes, the file is
modified on the fly when git reads it from disk, before it compares
with the index contents.

This is desirable in most situations, because it makes the user
aware that files should be normalized. However, it can become an
issue for automation. Since Git considers the work tree to be
dirty, some operations such as git rebase or git cherry-pick refuse
to operate. Those commands offer no flag to force overwrite work
tree changes. The only options are to commit the changes, or to
remove gitattributes, but that changes the repository state, which
may be undesirable in a scripted context.

Introduce an environment variable GIT_ATTRIBUTES_DISABLED, which if
set makes Git ignore any gitattributes.

Signed-off-by: Clemens Buchacher 
---
 Documentation/git.txt   |  4 
 Documentation/gitattributes.txt |  6 ++
 attr.c  |  3 +++
 t/t0003-attributes.sh   | 43 +
 4 files changed, 56 insertions(+)

diff --git a/Documentation/git.txt b/Documentation/git.txt
index bff6302..00f4e3b 100644
--- a/Documentation/git.txt
+++ b/Documentation/git.txt
@@ -1132,6 +1132,10 @@ of clones and fetches.
  - any external helpers are named by their protocol (e.g., use
`hg` to allow the `git-remote-hg` helper)
 
+'GIT_ATTRIBUTES_DISABLED'::
+   If set, attributes are disabled for all paths. See
+   linkgit:gitattributes[1] for more details on attributes.
+
 
 Discussion[[Discussion]]
 
diff --git a/Documentation/gitattributes.txt b/Documentation/gitattributes.txt
index e3b1de8..f6a2b1d 100644
--- a/Documentation/gitattributes.txt
+++ b/Documentation/gitattributes.txt
@@ -996,6 +996,12 @@ frotz  unspecified
 
 
 
+ENVIRONMENT
+---
+
+GIT_ATTRIBUTES_DISABLED::
+   If set, attributes are disabled for all paths.
+
 SEE ALSO
 
 linkgit:git-check-attr[1].
diff --git a/attr.c b/attr.c
index 086c08d..0fa2f1a 100644
--- a/attr.c
+++ b/attr.c
@@ -547,6 +547,9 @@ static void prepare_attr_stack(const char *path, int dirlen)
int len;
const char *cp;
 
+   if (getenv("GIT_ATTRIBUTES_DISABLED"))
+   return;
+
/*
 * At the bottom of the attribute stack is the built-in
 * set of attribute definitions, followed by the contents
diff --git a/t/t0003-attributes.sh b/t/t0003-attributes.sh
index f0fbb42..26e6766 100755
--- a/t/t0003-attributes.sh
+++ b/t/t0003-attributes.sh
@@ -13,6 +13,14 @@ attr_check () {
test_line_count = 0 err
 }
 
+attr_check_disabled () {
+   (
+   GIT_ATTRIBUTES_DISABLED=t
+   export GIT_ATTRIBUTES_DISABLED
+   attr_check "$@" unspecified
+   )
+}
+
 test_expect_success 'setup' '
mkdir -p a/b/d a/c b &&
(
@@ -84,6 +92,41 @@ test_expect_success 'attribute test' '
attr_check a/b/d/yes unspecified
 '
 
+test_expect_success 'gitattributes disabled' '
+   attr_check_disabled f &&
+   attr_check_disabled a/f &&
+   attr_check_disabled a/c/f &&
+   attr_check_disabled a/g &&
+   attr_check_disabled a/b/g &&
+   attr_check_disabled b/g &&
+   attr_check_disabled a/b/h &&
+   attr_check_disabled a/b/d/g &&
+   attr_check_disabled onoff &&
+   attr_check_disabled offon &&
+   attr_check_disabled no &&
+   attr_check_disabled a/b/d/no &&
+   attr_check_disabled a/b/d/yes
+'
+
+test_expect_success 'no changes if gitattributes disabled' '
+   mkdir clean &&
+   git init clean &&
+   (
+   cd clean &&
+   printf "foo\r\n" >dos.txt &&
+   git add dos.txt &&
+   test_tick &&
+   git commit -q -m dos.txt &&
+   echo "*.txt text eol=lf" >.gitattributes &&
+   git add .gitattributes &&
+   test_tick &&
+   git commit -q -m .gitattributes &&
+   rm -f .git/index &&
+   git reset &&
+   GIT_ATTRIBUTES_DISABLED=t git diff --exit-code
+   )
+'
+
 test_expect_success 'attribute matching is case sensitive when 
core.ignorecase=0' '
 
test_must_fail attr_check F f "-c core.ignorecase=0" &&
-- 
2.7.0

--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: What's cooking in git.git (Jan 2016, #05; Tue, 26)

[Johannes Schindelin]

Hi Junio,

On Tue, 26 Jan 2016, Junio C Hamano wrote:

> * js/mingw-tests (2016-01-26) 20 commits
>  - mingw: skip a test in t9130 that cannot pass on Windows
>  - mingw: do not bother to test funny file names
>  - mingw: handle the missing POSIXPERM prereq in t9124
>  - mingw: avoid illegal filename in t9118
>  - mingw: mark t9100's test cases with appropriate prereqs
>  - Avoid absolute path in t0008
>  - mingw: work around pwd issues in the tests
>  - mingw: fix t9700's assumption about directory separators
>  - mingw: skip test in t1508 that fails due to path conversion
>  - tests: turn off git-daemon tests if FIFOs are not available
>  - mingw: disable mkfifo-based tests
>  - mingw: accomodate t0060-path-utils for MSYS2
>  - mingw: fix t5601-clone.sh
>  - mingw: let lstat() fail with errno == ENOTDIR when appropriate
>  - mingw: try to delete target directory before renaming
>  - mingw: prepare the TMPDIR environment variable for shell scripts
>  - mingw: factor out Windows specific environment setup
>  - Git.pm: stop assuming that absolute paths start with a slash
>  - mingw: do not trust MSYS2's MinGW gettext.sh
>  - mingw: let's use gettext with MSYS2
>  (this branch uses js/msys2.)
> 
>  Updates test scripts to remove assumptions that are not portable
>  between Git for POSIX and Git for Windows, or to skip ones with
>  expectations that are not satisfiable on Git for Windows.
> 
>  Looks mostly done, but I had to tweak a few things, so
>  Waiting for re-test.

Will re-submit with additional tweaks.

> * js/xmerge-maker-eol (2016-01-26) 2 commits
>  - merge-file: ensure that conflict sections match eol style
>  - merge-file: let conflict markers match end-of-line style of the context
> 
>  The low-level merge machinery has been taught to use CRLF line
>  termination when inserting conflict markers to merged contents that
>  are themselves CRLF line-terminated.
> 
>  Will merge to 'next'.

There is one more tweak I introduced, and will resubmit: the test case did
not test the intended 3 out of the 4 conflict markers.

Ciao,
Dscho
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v2 00/19] Let Git's tests pass on Windows

[Johannes Schindelin]

Hi Junio,

On Tue, 26 Jan 2016, Junio C Hamano wrote:

> Johannes Schindelin  writes:
> 
> > This is a big milestone. With these modifications, Git's source code
> > does not only build without warnings in Git for Windows' SDK, but
> > passes the entire regression test suite.
> 
> Thanks.
> 
> Without a few fixups, the result of applying these patches made
> tests fail for me (so presumably for everybody !MINGW)

Drats! I got lazy and did not re-test everything on Linux after a while
(it really slwed me down and for a good while the tests all succeeded,
so those regressions were incurred from working on this very patch
series...)

> which I think I fixed all, but I may have broken things on MINGW while
> doing so.  Please re-fetch from my tree when I pushed the integration
> result out with this merged somewhere on the 'pu' branch, retest, and if
> I broke something please re-fix them ;-)

I made a couple of other adjustments anyway, so expect a new iteration
shortly. This time cross-checked on Linux.

Ciao,
Dscho
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v2 18/19] mingw: handle the missing POSIXPERM prereq in t9124

[Johannes Schindelin]

Hi Junio,

On Tue, 26 Jan 2016, Junio C Hamano wrote:

> Johannes Schindelin  writes:
> 
> > On Windows, the permission system works completely differently than
> > expected by some of the tests. So let's make sure that we do not test
> > POSIX functionality on Windows.
> >
> > This lets t9124-git-svn-dcommit-auto-props.sh pass in Git for Windows'
> > SDK.
> >
> > Signed-off-by: Johannes Schindelin 
> > ---
> >  t/t9124-git-svn-dcommit-auto-props.sh | 16 ++--
> >  1 file changed, 10 insertions(+), 6 deletions(-)
> >
> > diff --git a/t/t9124-git-svn-dcommit-auto-props.sh 
> > b/t/t9124-git-svn-dcommit-auto-props.sh
> > index aa841e1..2be0805 100755
> > --- a/t/t9124-git-svn-dcommit-auto-props.sh
> > +++ b/t/t9124-git-svn-dcommit-auto-props.sh
> > @@ -34,8 +34,7 @@ test_expect_success 'enable auto-props config' '
> >  '
> >  
> >  test_expect_success 'add files matching auto-props' '
> > -   echo "#!$SHELL_PATH" >exec1.sh &&
> > -   chmod +x exec1.sh &&
> > +   printf "" | write_script exec1.sh &&
> 
> That looks like a useless use of printf.  Why not
> 
>   write_script exec1.sh  > echo "hello" >hello.txt &&
> > echo bar >bar &&
> > git add exec1.sh hello.txt bar &&
> > @@ -48,8 +47,7 @@ test_expect_success 'disable auto-props config' '
> >  '
> >  
> >  test_expect_success 'add files matching disabled auto-props' '
> > -   echo "#$SHELL_PATH" >exec2.sh &&
> > -   chmod +x exec2.sh &&
> > +   printf "" | write_script exec2.sh &&
> > echo "world" >world.txt &&
> > echo zot >zot &&
> > git add exec2.sh world.txt zot &&
> > @@ -65,7 +63,10 @@ test_expect_success 'check resulting svn repository' '
> > cd svnrepo &&
> >  
> > # Check properties from first commit.
> > -   test "x$(svn_cmd propget svn:executable exec1.sh)" = "x*" &&
> > +   if test_have_prereq POSIXPERM
> > +   then
> > +   test -z "$(svn_cmd propget svn:executable exec1.sh)"
> 
> Why this change?
> 
>   test "x$(svn_cmd propget svn:executable exec1.sh)" = "x*" &&
> 
> means "propget command gives a literal string that consists of a
> single asterisk".

Oh wow... I blame it on lack of sleep. Would you believe that I totally
overlooked the asterisk, in both cases? Wow.

Sorry for the mess, cleaned it up locally and will resubmit as soon as the
tests passed on both Windows & Linux, and as soon as I figure out how to
change my charset to something else than unknown.

My apologies,
Dscho

P.S.: Would you believe that the reason the tests passed on Linux was that
I forgot to install Subversion? ;-)
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Dear Sir or Madam! - please help our site - пожалуйста, помогите нашему сайту - будь ласка, допоможіть нашому сайту http://petition.kiev.ua/

[admin]

Dear Sir or Madam! 
please at the top of any page of site click once on the advertising banner,
so that we could pay for hosting our site,
Thank you

ad...@petition.kiev.ua
http://petition.kiev.ua/

добрий день,
просимо на будь-якій сторінці вгорі один раз натиснути на рекламний банер,
щоб ми змогли оплатити хостинг нашого сайту,
Дякуємо

добрый день, 
просим на любой странице вверху один раз нажать на рекламный баннер,
чтобы мы смогли оплатить хостинг нашего сайта,
спасибо

Sorry if this letter has caused you inconvenience. Your address is taken from 
public sources.
To unsubscribe, please send us a a message to our email address.

ad...@petition.kiev.ua
http://petition.kiev.ua/
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: git for windows

[Andrey Chernyshov]

Additional note - when I use the command line git push doesn't display 
any errors but no updates on github...

git status says :

On branch master
Your branch is ahead of 'origin/master' by 3 commits.

On 1/27/2016 2:51 PM, Andrey Chernyshov wrote:



On 1/27/2016 2:35 PM, Andrey Chernyshov wrote:


On 1/27/2016 2:32 PM, Andrey Chernyshov wrote:

Hi

I'm using PHP storm with git for windows. Once I do a push to the 
github I get the following error

Problem signature:
  Problem Event Name:APPCRASH
  Application Name:git-remote-https.exe
  Application Version:2.7.0.0
  Application Timestamp:35316130
  Fault Module Name:libidn-11.dll
  Fault Module Version:0.0.0.0
  Fault Module Timestamp:00170158
  Exception Code:c005
  Exception Offset:46bc
  OS Version:6.3.9600.2.0.0.256.4
  Locale ID:1033
  Additional Information 1:a547
  Additional Information 2:a54764e1ee4f5613d3fc9395100a0ff4
  Additional Information 3:ac01
  Additional Information 4:ac010ce737711604ec050156caebd625

Read our privacy statement online:
http://go.microsoft.com/fwlink/?linkid=280262

If the online privacy statement is not available, please read our 
privacy statement offline:

  C:\windows\system32\en-US\erofflps.txt

If I try to push with Git GUI, it's the same, so not a PHPStorm 
issue...


--
Thanks, Andrey.


--
Thanks, Andrey.




--
Thanks, Andrey.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] optionally disable gitattributes

[Torsten Bögershausen]

On 27.01.16 12:59, Junio C Hamano wrote:
> Clemens Buchacher  writes:
> 
>> If committed files are not normalized, adding gitattributes has the
>> side effect that such files are shown as modified, even though they
>> were not actually modified by the user, and the work tree matches
>> the committed file. This is because with gitattributes, the file is
>> modified on the fly when git reads it from disk, before it compares
>> with the index contents.
>>
>> This is desirable in most situations, because it makes the user
>> aware that files should be normalized. However, it can become an
>> issue for automation. Since Git considers the work tree to be
>> dirty, some operations such as git rebase or git cherry-pick refuse
>> to operate. Those commands offer no flag to force overwrite work
>> tree changes. The only options are to commit the changes, or to
>> remove gitattributes, but that changes the repository state, which
>> may be undesirable in a scripted context.
It feels like a workaround for something that could be fixable, or is already 
ongoing.
Before going into more details,
could you tell us which attributes you are typically using (when having this 
problems) ?
Is it
* text=auto
or
*.sh text 
or something else?


>>
>> Introduce an environment variable GIT_ATTRIBUTES_DISABLED, which if
>> set makes Git ignore any gitattributes.
>>
>> Signed-off-by: Clemens Buchacher 
>> ---
> 
> Is the problem you are trying to solve related to the issue we
> discussed recently in a nearby thread?
It seems that I missed the thread ?
> 
> That is, even after "reset --hard", if the result of converting the
> contents in the index to the working tree representation and then
> converting that result back to the normalized representation does
> not match what is in the index, Git would sometimes say that the
> working tree contents differ from the index?
> 
> I think the change in this patch has some uses, and I think the
> issue we discussed recently in a nearby thread indeed is a problem,
> but I do not think there is an impedance mismatch beween the two, so
> I'd like to first make sure you are trying to solve the problem I
> think you are trying to solve.








--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[ANNOUNCE] Git-backup - Backup set of Git repositories & just files; efficiently

[Kirill Smelkov]

https://lab.nexedi.com/kirr/git-backup.git

This program backups files and set of bare Git repositories into one Git 
repository.
Files are copied to blobs and then added to tree under certain place, and for
Git repositories, all reachable objects are pulled in with maintaining index
which remembers reference -> sha1 for all pulled repositories.

This allows to leverage Git's good data deduplication ability, especially for
cases when there are many hosted repositories which are forks of each other,
and for backup to have history and be otherwise managed as a usual Git
repository.  In particular it is possible to use standard git pull/push to
synchronize backups in several places.

Backup workflow is:

1. create backup repository::

 $ mkdir backup
 $ cd backup
 $ git init # both bare and non-bare possible

2. pull files and Git repositories into backup repository::

 $ git-backup pull dir1:prefix1 dir2:prefix2 ...

   This will pull bare Git repositories & just files from `dir1` into backup
   under `prefix1`, from `dir2` into backup prefix `prefix2`, etc...

3. restore files and Git repositories from backup::

 $ git-backup restore  prefix1:dir1

   Restore Git repositories & just files from backup `prefix1` into `dir1`,
   from backup `prefix2` into `dir2`, etc...

   Backup state to restore is taken from  which is sha1 or
   ref pointing to backup repository state.

4. backup repository itself can be managed with Git. In particular it can be
   synchronized between several places with standard git pull/push, be
   repacked, etc::

 $ git push ...
 $ git pull ...


Technical overview of how it works
--

After objects from backuped Git repositories are pulled in, we create new
commit which references tree with changed backup index and files, and also has
all head objects from pulled-in repositories in its parents(*). This way backup
has history and all pulled objects become reachable from single head commit in
backup repository. In particular that means that the whole state of backup can
be described with only single sha1, and that backup repository itself could be
synchronized via standard git pull/push, be repacked, etc.

Restoration process is the opposite - from a particular backup state, files are
extracted at a proper place, and for Git repositories a pack with all objects
reachable from that repository heads is prepared and extracted from backup
repository object database.

Data for all backuped files and repositories can be accessed if one has access
to backup repository, so either they all should be in the same security domain,
or extra care has to be taken to protect access to backup repository.

File permissions are not managed with strict details due to inherent
nature of Git. This aspect can be improved with e.g. etckeeper-like
(http://etckeeper.branchable.com/) approach if needed.

NOTE the idea of pulling all refs together is similar to git-namespaces
 http://git-scm.com/docs/gitnamespaces

(*) Tag objects are handled specially - because in a lot of places Git insists 
and
assumes commit parents can only be commit objects. We encode tag objects in
specially-crafted commit object on pull, and decode back on backup restore.

We do likewise if a ref points to tree or blob, which is valid in Git.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v1 1/6] t0027: Add tests for get_stream_filter()

[tboegi]

From: Torsten Bögershausen 

When a filter is configured, a different code-path is used in convert.c
and entry.c via get_stream_filter(), but there are no test cases yet.

Add tests for the filter API by configuring the ident filter.
The result of the SHA1 conversion is not checked, this is already
done in other TC.

Add a parameter to checkout_files() in t0027.
While changing the signature, add another parameter for the eol= attribute.
This is currently unused, tests for e.g.
"* text=auto eol=lf" will be added in a separate commit.

Signed-off-by: Torsten Bögershausen 
---
 t/t0027-auto-crlf.sh | 262 ---
 1 file changed, 146 insertions(+), 116 deletions(-)

diff --git a/t/t0027-auto-crlf.sh b/t/t0027-auto-crlf.sh
index 504e5a0..08fe6a5 100755
--- a/t/t0027-auto-crlf.sh
+++ b/t/t0027-auto-crlf.sh
@@ -21,32 +21,45 @@ compare_ws_file () {
pfx=$1
exp=$2.expect
act=$pfx.actual.$3
-   tr '\015\000' QN <"$2" >"$exp" &&
-   tr '\015\000' QN <"$3" >"$act" &&
+   tr '\015\000abcdef01234567890' QN0 <"$2" >"$exp" &&
+   tr '\015\000abcdef01234567890' QN0 <"$3" >"$act" &&
test_cmp $exp $act &&
rm $exp $act
 }
 
 create_gitattributes () {
attr=$1
+   ident=$2
+   case "$2" in
+   "")
+   >.gitattributes
+   ;;
+   i)
+   echo "* ident" >.gitattributes
+   ;;
+   *)
+   echo >&2 invalid ident: $2
+   exit 1
+   esac
+
case "$attr" in
auto)
-   echo "*.txt text=auto" >.gitattributes
+   echo "*.txt text=auto" >>.gitattributes
;;
text)
-   echo "*.txt text" >.gitattributes
+   echo "*.txt text" >>.gitattributes
;;
-text)
-   echo "*.txt -text" >.gitattributes
+   echo "*.txt -text" >>.gitattributes
;;
crlf)
-   echo "*.txt eol=crlf" >.gitattributes
+   echo "*.txt eol=crlf" >>.gitattributes
;;
lf)
-   echo "*.txt eol=lf" >.gitattributes
+   echo "*.txt eol=lf" >>.gitattributes
;;
"")
-   echo >.gitattributes
+   #echo >.gitattributes
;;
*)
echo >&2 invalid attribute: $attr
@@ -90,7 +103,7 @@ commit_check_warn () {
lfmixcr=$6
crlfnul=$7
pfx=crlf_${crlf}_attr_${attr}
-   create_gitattributes "$attr" &&
+   create_gitattributes "$attr" "" &&
for f in LF CRLF LF_mix_CR CRLF_mix_LF LF_nul CRLF_nul
do
fname=${pfx}_$f.txt &&
@@ -115,7 +128,7 @@ commit_chk_wrnNNO () {
crlfnul=$7
pfx=NNO_${crlf}_attr_${attr}
#Commit files on top of existing file
-   create_gitattributes "$attr" &&
+   create_gitattributes "$attr" "" &&
for f in LF CRLF CRLF_mix_LF LF_mix_CR CRLF_nul
do
fname=${pfx}_$f.txt &&
@@ -208,28 +221,30 @@ check_in_repo_NNO () {
 }
 
 checkout_files () {
-   eol=$1
-   crlf=$2
-   attr=$3
-   lfname=$4
-   crlfname=$5
-   lfmixcrlf=$6
-   lfmixcr=$7
-   crlfnul=$8
-   create_gitattributes $attr &&
+   attr=$1 ; shift
+   ident=$1; shift
+   aeol=$1 ; shift
+   crlf=$1 ; shift
+   ceol=$1 ; shift
+   lfname=$1 ; shift
+   crlfname=$1 ; shift
+   lfmixcrlf=$1 ; shift
+   lfmixcr=$1 ; shift
+   crlfnul=$1 ; shift
+   create_gitattributes "$attr" "$ident" &&
git config core.autocrlf $crlf &&
-   pfx=eol_${eol}_crlf_${crlf}_attr_${attr}_ &&
+   pfx=eol_${ceol}_crlf_${crlf}_attr_${attr}_ &&
for f in LF CRLF LF_mix_CR CRLF_mix_LF LF_nul
do
rm crlf_false_attr__$f.txt &&
-   if test -z "$eol"; then
+   if test -z "$ceol"; then
git checkout crlf_false_attr__$f.txt
else
-   git -c core.eol=$eol checkout crlf_false_attr__$f.txt
+   git -c core.eol=$ceol checkout crlf_false_attr__$f.txt
fi
done
 
-   test_expect_success "ls-files --eol $lfname ${pfx}LF.txt" '
+   test_expect_success "ls-files --eol attr=$attr i=$ident $aeol 
core.autocrlf=$crlf core.eol=$ceol" '
test_when_finished "rm expect actual" &&
sort <<-EOF >expect &&
i/crlf w/$(stats_ascii $crlfname) crlf_false_attr__CRLF.txt
@@ -244,19 +259,19 @@ checkout_files () {
sort >actual &&
test_cmp expect actual
'
-   test_expect_success "checkout core.eol=$eol core.autocrlf=$crlf 

Re: [PATCH] travis-ci: run previously failed tests first, then slowest to fastest

[Clemens Buchacher]

I think Junio pointed me to this thread from "[PATCH] optionally disable
gitattributes". Since I am not sure I am following everything correctly
in this thread, allow me to recapitulate what I understood so far.

Firstly, I think the racy'ness of t0025 is understood. It is due to the
is_racy_timestamp check in read-cache.c's ie_match_stat. But for the
moment I would like to put this aside, because the issue can be
reproduced reliably with this change to t0025:

diff --git a/t/t0025-crlf-auto.sh b/t/t0025-crlf-auto.sh
index c164b46..e30e9b3 100755
--- a/t/t0025-crlf-auto.sh
+++ b/t/t0025-crlf-auto.sh
@@ -55,8 +55,11 @@ test_expect_success 'crlf=true causes a CRLF file to be 
normalized' '
 test_expect_success 'text=true causes a CRLF file to be normalized' '
 
rm -f .gitattributes tmp LFonly CRLFonly LFwithNUL &&
-   echo "CRLFonly text" > .gitattributes &&
git read-tree --reset -u HEAD &&
+   sleep 1 &&
+   rm .git/index &&
+   git reset &&
+   echo "CRLFonly text" > .gitattributes &&
 
# Note, "normalized" means that git will normalize it if added
has_cr CRLFonly &&

I intentionally wait for one second and then I remove and re-read the
index. Now the timestamps of CRLFonly and .git/index are different, so
we avoid the is_racy_timestamp check. From now on Git will not read the
contents of CRLFonly from disk again until either the index entry or the
mtime of CRLFonly changes (maybe we also check the size, I am not sure).

Now we add .gitattributes. This does not change the index entry, nor
does it change the mtime of CRLFonly. Therefore the subsequent git diff
turns out empty, and the test fails.

I believe this behavior is expected. In gitattributes(5) we therefore
recommend using rm .git/index and git reset to "force Git to rescan the
working directory." The test should be fixed accordingly, something
like:

diff --git a/t/t0025-crlf-auto.sh b/t/t0025-crlf-auto.sh
index c164b46..2917591 100755
--- a/t/t0025-crlf-auto.sh
+++ b/t/t0025-crlf-auto.sh
@@ -57,6 +57,8 @@ test_expect_success 'text=true causes a CRLF file to be 
normalized' '
rm -f .gitattributes tmp LFonly CRLFonly LFwithNUL &&
echo "CRLFonly text" > .gitattributes &&
git read-tree --reset -u HEAD &&
+   rm .git/index &&
+   git reset &&
 
# Note, "normalized" means that git will normalize it if added
has_cr CRLFonly &&



On Mon, Jan 25, 2016 at 01:52:18PM -0800, Junio C Hamano wrote:
> Junio C Hamano  writes:
> 
> > I do not think there is a canned command to help dealing with these
> > broken paths right now.

I think (rm .git/index && git reset) works well enough in most cases,
but not all:

> We could go even fancier and attempt the round-trip twice or more.
> It is possible that the in-index representation will not converge
> when you use a misconfigured pair of clean/smudge filters

This can also happen with eol conversion, for example if you have files
with CRCRLF line endings. The eol conversion will remove only one CR.
Two conversions would be needed to achieve a normalized format. But
iterating (rm .git/index && git reset) does not help. Since we do not
touch the file on disk, after the first round, we have CRCRLF on disk
and CRLF in the index. During the second round, Git reads CRCRLF from
disk again, converts it to CRLF, which matches the index. Even
git reset --hard will not checkout the CRLF version to the worktree.

A possible solution is to iterate (rm -r * && git checkout -- . && git
add -u) until the work tree is clean. Quite ugly.

A command like git add --fix-index would make this conversion less
painful.  It should be ok if the user has to run it several times in
corner cases like CRCRLF, but it would be nice to issue a warning if the
index is still not normalized after running git add --fix-index.

Regarding the name of the option, maybe git add --renormalize-index
would be more consistent, since we also have the related merge option
"renormalize", which is very similar. In fact possibly you can share
some code with it.

Your patch looks good to me otherwise.


Coming back to "[PATCH] optionally disable gitattributes": The topics
are related, because they both deal with the situation where the work
tree has files which are not normalized according to gitattributes. But
my patch is more about saying: ok, I know I may have files which need to
be normalized, but I want to ignore this issue for now. Please disable
gitattributes for now, because I want to work with the files as they are
committed. Conversely, the discussion here is about how to reliably
detect and fix files which are not normalized.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html