Re: gitk -m ?

[Uxío Prego]

Not sure what you are wanting to achieve, but please make sure neither `gitk
PATHSPEC` nor `gitk --all PATHSPEC` are presenting you enough information.

> On 3 Aug 2017, at 19:37, Burkhardt, Glenn B UTAS 
>  wrote:
> 
> I've been looking in 'gitk' for an option that does what 'git log -m' does.  
> Did I miss something?  In particular, I'd like to get information about a 
> file that's currently available with "git log -m --all --follow", but 
> presented in 'gitk'.  If it's not there, please consider this a feature 
> request.
> 
> Thanks.

[PATCH] stash: prevent warning about null bytes in input

[Kevin Daudt]

The no_changes function calls the untracked_files function through
command substitution. untracked_files will return null bytes because it
runs ls-files with the '-z' option.

Bash since version 4.4 warns about these null bytes. As they are not
required for the test that is being done, remove null bytes from the
input.

This warning is triggered when running git stash save -u resulting in
two warnings:

git-stash: line 43: warning: command substitution: ignored null byte
in input

Signed-off-by: Kevin Daudt 
---
 git-stash.sh | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/git-stash.sh b/git-stash.sh
index 9b6c2da7b..0dcca3cd6 100755
--- a/git-stash.sh
+++ b/git-stash.sh
@@ -39,7 +39,7 @@ fi
 no_changes () {
git diff-index --quiet --cached HEAD --ignore-submodules -- "$@" &&
git diff-files --quiet --ignore-submodules -- "$@" &&
-   (test -z "$untracked" || test -z "$(untracked_files)")
+   (test -z "$untracked" || test -z "$(untracked_files | tr -d '\0')")
 }
 
 untracked_files () {
-- 
2.14.0.rc1.33.g384a8b271c

Re: Bug when stashing previously-ignored file plus associated .gitignore change

[Kevin Daudt]

On Fri, Aug 11, 2017 at 04:55:38PM +0100, Sam Partington wrote:
> Hi there,
> 
> I'm running git 2.7.4 on Ubuntu 16.04.  I've found a couple of
> problems when "un-ignoring" files in tandem with git stash.
> 
> Here's how to reproduce:
> 
> Say you have a project using git, with a .gitignore file which
> contains the following line:
> 
> bin/*
> 
> You can then see the problems by doing this:
> 
> $ touch bin/mynewfile # this file will be ignored at this point > 
> and then updating .gitignore to look like this (adding that second line):
> 
> bin/*
> !bin/mynewfile
> 
> So far, so good; the new file is no longer ignored.
> 
> But now, try stashing the changes and including untracked files in the stash:
> 
> $ git stash save -u
> 
> Here's the first problem, bin/mynewfile is still there:
> 
> $ ls bin/mynewfile
> bin/mynewfile
> 
> But you'd expect it to not be there and be in the stash, I think.
> This is what would normally happen with the untracked-files option for
> git stash.
> 
> This leads to the second problem - you can't now pop the stash:
> 
> $ git stash pop
> bin/mynewfile already exists, no checkout
> Could not restore untracked files from stash
> 
> If you want to apply the stash, you have to remove the file:
> 
> $ rm bin/mynewfile
> $ git stash pop # this works, and re-creates bin/mynewfile
> 
> This is quite an unusual edge case, but I have hit it two or three
> times now and so thought it worth reporting, but I'll understand if
> it's deemed not worth fixing!
> 
> Do let me know if you need any more information from me here.
> 
> Thanks
> Sam
> 
> PS Sorry for the lack of formatting - I'm sending this as plain text
> as my original HTML emails was rejected as possible spam by your
> mailserver.
> 
> Sam Partington
> Senior Developer
> 

Hello Sam,

Is it the case that you did not commit the addition of '!bin/mynewfile'
yet? I suspect that by running git stash save -u, you also are stashing
this addition to the .gitigore file. Can you confirm this?

Kevin

Fast Loans

[Financial Services]

Do you need a loan to pay up bill or to start a business? Email Us

RE: TREAT URGENT !!

[Dr. Mallon Liam]

Hello.

I am Dr. Mallon Liam, an Engineer with ExxonMobil in United Kingdom 
http://www.exxonmobil.co.uk). I got your contact address from an associate 
working with the British Export Promotion Council. Before I continue, let me 
stress that I am NOT contacting you for financial assistance.

I am in search of a business partner to assist us in the transfer of 
(GBP35million) and subsequent investment in your country.

If you decide to participate in this business, 10% of the total amount of 
(GBP35million) will be for you for your participation and sincere assistance. I 
shall communicate further details as soon as i received your response.

I look forward to your partnership.

Best Regards,
Dr. Mallon Liam.
Fawley Refinery, Fawley, Southampton SO45 1TX, 
United Kingdom
Ph: +(44) 203 322 4197

Re: [PATCH 1/9] Convert pack-objects to size_t

[Junio C Hamano]

Ramsay Jones  writes:

> It should be, see commit b97e911643 ("Support for large files
> on 32bit systems.", 17-02-2007), where you can see that the
> _FILE_OFFSET_BITS macro is set to 64. This asks  et.al.,
> to use the "Large File System" API and a 64-bit off_t.

Correct.  Roughly speaking, we should view off_t as size of things
you can store in a file, and size_t as size of things you can have
in core.  When we allocate a region of memory, and then repeatedly
fill it with some data and hand that memory to a helper function
e.g. git_deflate(), each of these calls should expect to get data
whose size can be representable by size_t, and if that is shorter
than ulong which we currently use, we are artificially limiting our
potential by using a type that is narrower than necessary.  

The result from these helper functions that are repeatedly called
may be sent to a file as the output from the loop.  If that logic in
the outer loop wants to keep a tally of the total size of data they
processed, that number may not be fit in size_t and instead may
require off_t.

One interesting question is which of these two types we should use
for the size of objects Git uses.  

Most of the "interesting" operations done by Git require that the
thing is in core as a whole before we can do anything (e.g. compare
two such things to produce delta, have one in core and apply patch),
so it is tempting that we deal with size_t, but at the lowest level
to serve as a SCM, i.e. recording the state of a file at each
version, we actually should be able to exceed the in-core
limit---both "git add" of a huge file whose contents would not fit
in-core and "git checkout" of a huge blob whose inflated contents
would not fit in-core should (in theory, modulo bugs) be able to
exercise the streaming interface to handle such case without holding
everything in-core at once.  So from that point of view, even size_t
may not be the "correct" type to use.

Re: [PATCH 1/9] Convert pack-objects to size_t

[Ramsay Jones]

On 13/08/17 19:30, Martin Koegler wrote:
> On Sat, Aug 12, 2017 at 02:47:25PM +0100, Ramsay Jones wrote:
>> On 32-bit Linux, off_t is 64-bit and size_t is 32-bit.
> 
> --- t.c ---
> #include 
> #include 
> 
> int main()
> {
> printf("%d %d\n", sizeof(size_t), sizeof(off_t));
> }
> 
> $ gcc -m32 -o t t.c
> $ ./t.c
> 4 4
> 
> So is that really true?

It should be, see commit b97e911643 ("Support for large files
on 32bit systems.", 17-02-2007), where you can see that the
_FILE_OFFSET_BITS macro is set to 64. This asks  et.al.,
to use the "Large File System" API and a 64-bit off_t.

I can't boot my 32-bit installation at the moment, and it seems
that my 64-bit multilib system is not playing ball:

  $ gcc -m32 -D_FILE_OFFSET_BITS=64 -o t t.c
  In file included from /usr/include/stdio.h:27:0,
   from t.c:2:
  /usr/include/features.h:367:25: fatal error: sys/cdefs.h: No such file or 
directory
  compilation terminated.
  $ 

ATB,
Ramsay Jones

[RFC PATCH 0/7] Implement ref namespaces as a ref storage backend

[Richard Maw]

Forewarning: I don't consider this work complete
and am unlikely to find time to finish it any time soon.
I've mostly sent this because it may include valuable feedback
on how well the ref storage backends works
from trying to use it to change how git namespaces work.

Introduction


I work on a git server called Gitano,
and I'd like to add support for git namespaces to:

1.  Allow administrative content to be kept out of the default namespace.

Gitano keeps some repository configuration in a ref in the repository.
I'd like to be able to hide it in a namespace
to make fetching all the content easier, such as for mirroring.

2.  Implement repository forking backed by namespaces in the same repo.

I'd like to be able to add a logical vs physical repository separation
so that forking a repository just copies the refs into a namespace.

3.  Any other inventive uses users could think of.


It's possible with some hackery to do all this with the existing namespace code
but we like to integrate with a web frontend, and a web frontend needs to do
more than just let you push and pull the repository.

Unfortunately namespace handling was never implemented for any other part of git
and at least gitolite makes use of namespaces,
and will have to work around it not being implemented fully,
but implementing it more fully will break work-arounds.

Instead of continuing to do work-arounds I tried to add support into libgit,
since as well as making it less code in the web frontend to work around it,
it would become common code that other git servers may make use of.


This is not my first attempt to improve the git namespace handling in git.
I tried last year, but it took me so long that all the ref handling code changed
and I would have had to start from scratch.

Fortunately the pluggable ref backends work provided an easier starting point.

The included patches work for the use-cases I need to support in gitano,
but I don't want it to end up like GIT_NAMESPACE and not be fixable,
so I've tried to make it work such that everything in the git test suite works.

I was not successful with this due to time constraints
but it helped me find many issues and I've listed known issues.

Technical description
=

This patch series adds a new refs backend, stacking on top of the files backend,
based on whether `core.namespace` is set in git config.

Since config can be done on the command-line or in config files,
both per-repo or global, it's a reasonable approach.

This allows the default namespace of a repository to be changed
so that operations such as fetch only show refs of that namespace,
or a smarter git server to intercept the repository path
and redirect it to a different repository with a namespace set.

It also mostly works for local git operations,
but I've no real idea what they would be useful for
beyond what's needed for a git server's web frontend.

It may make sense in future to allow remotes to have namespaces
so you can push to a namespace on the server without it being namespace aware,
but that's not the goal of this series,
and may be possible to handle without modification by changing the refspecs.

The majority of what the namespaced refs backend does
is to prepend the namespace to requests before the files backend sees them
and strip namespaces off returned refs before the caller sees them.

Issues
==

Having core.namespace set in a repository namespaces the fetch results.
If the source repository is local then setting -c core.namespace
to fetch the content into a different namespace will break the source namespace
since the upload-pack also obeys the -c core.namespace on the command-line.

Supporting `clone --namespace` instead of `git -c` might resolve this,
but I can't think of an appropriate use-case for wanting to do so
which makes it hard to consider what API would be appropriate.

Bugs


Most boil down to how special refs like HEAD are handled.

1.  Logged messages display the namespaced path,
which a human may deal with but confuses the test suite.

2.  Reflogs for namespaced HEAD are not updated.

This is because resolving HEAD to split the transaction's updates
to add a log only update to HEAD works by transaction_prepare resolving HEAD
using its own ref store rather than the main one,
so the namespace translation isn't performed.
See split_head_update.

The fix for this may be to move the transaction mangling out of the backend,
unless it should be implied that every backend implementation
must be responsible for symbolic ref reflog updates implicitly.

3.  git init always says Reinitialized repository.

This is because create_default_files checks for whether HEAD already exists
directly via fs access rather than through the refs backend,
but then creates the symbolic ref using it.

Without a workaround this causes clones to fail because they don't recognise
that the repository is 

[PATCH 2/7] Add git_configset_add_standard

[Richard Maw]

This exposes implementation details of repo_read_config
so a configset can be populated with a repository's standard config,
without needing to create a full repository.

This allows config lookup to use the same codepath
whether the repository is ready or not,
which allows it to be used during git init.
---
 config.c | 7 ++-
 config.h | 1 +
 2 files changed, 7 insertions(+), 1 deletion(-)

diff --git a/config.c b/config.c
index 231f9a7..d0af812 100644
--- a/config.c
+++ b/config.c
@@ -1764,6 +1764,11 @@ int git_configset_add_file(struct config_set *cs, const 
char *filename)
return git_config_from_file(config_set_callback, filename, cs);
 }
 
+int git_configset_add_standard(struct config_set *cs, const struct 
config_options *opts)
+{
+   return config_with_options(config_set_callback, cs, NULL, opts);
+}
+
 int git_configset_get_value(struct config_set *cs, const char *key, const char 
**value)
 {
const struct string_list *values = NULL;
@@ -1879,7 +1884,7 @@ static void repo_read_config(struct repository *repo)
 
git_configset_init(repo->config);
 
-   if (config_with_options(config_set_callback, repo->config, NULL, ) 
< 0)
+   if (git_configset_add_standard(repo->config, ) < 0)
/*
 * config_with_options() normally returns only
 * zero, as most errors are fatal, and
diff --git a/config.h b/config.h
index 0352da1..0b7b8d2 100644
--- a/config.h
+++ b/config.h
@@ -151,6 +151,7 @@ struct config_set {
 
 extern void git_configset_init(struct config_set *cs);
 extern int git_configset_add_file(struct config_set *cs, const char *filename);
+extern int git_configset_add_standard(struct config_set *cs, const struct 
config_options *opts);
 extern int git_configset_get_value(struct config_set *cs, const char *key, 
const char **value);
 extern const struct string_list *git_configset_get_value_multi(struct 
config_set *cs, const char *key);
 extern void git_configset_clear(struct config_set *cs);
-- 
2.9.0

[PATCH 3/7] Add helper for skipping namespace prefixes

[Richard Maw]

Normally your own namespace is known and you only need to skip that prefix,
but when you need to classify the type of a ref
it helps to be able to consider what type of ref it would be
if it were outside of a namespace.
---
 git-compat-util.h | 19 +++
 1 file changed, 19 insertions(+)

diff --git a/git-compat-util.h b/git-compat-util.h
index db9c22d..c5e0a34 100644
--- a/git-compat-util.h
+++ b/git-compat-util.h
@@ -501,6 +501,25 @@ static inline int skip_prefix_mem(const char *buf, size_t 
len,
return 0;
 }
 
+static inline int skip_namespace(const char *refname, const char **out)
+{
+   const char *c = refname;
+
+   while (skip_prefix(c, "refs/namespaces/", )) {
+   c = strchr(c, '/');
+   if (!c)
+   return 0;
+
+   c++;
+   }
+
+   if (c == refname)
+   return 0;
+
+   *out = c;
+   return 1;
+}
+
 /*
  * If buf ends with suffix, return 1 and subtract the length of the suffix
  * from *len. Otherwise, return 0 and leave *len untouched.
-- 
2.9.0

[PATCH 4/7] Autocreate reflogs for namespaced refs

[Richard Maw]

Since refs are classified based on their prefix
but namespaces have their own prefix,
it's necessary to skip that prefix to classify their remaining prefix.
---
 refs.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/refs.c b/refs.c
index ba22f4a..2e8bace 100644
--- a/refs.c
+++ b/refs.c
@@ -699,6 +699,7 @@ int should_autocreate_reflog(const char *refname)
case LOG_REFS_ALWAYS:
return 1;
case LOG_REFS_NORMAL:
+   (void) skip_namespace(refname, );
return starts_with(refname, "refs/heads/") ||
starts_with(refname, "refs/remotes/") ||
starts_with(refname, "refs/notes/") ||
-- 
2.9.0

[PATCH 6/7] Add namespaced ref backend

[Richard Maw]

---
 Makefile  |   1 +
 refs/namespaced-backend.c | 619 ++
 refs/refs-internal.h  |   1 +
 3 files changed, 621 insertions(+)
 create mode 100644 refs/namespaced-backend.c

diff --git a/Makefile b/Makefile
index 461c845..0c417c3 100644
--- a/Makefile
+++ b/Makefile
@@ -842,6 +842,7 @@ LIB_OBJS += reflog-walk.o
 LIB_OBJS += refs.o
 LIB_OBJS += refs/files-backend.o
 LIB_OBJS += refs/iterator.o
+LIB_OBJS += refs/namespaced-backend.o
 LIB_OBJS += refs/ref-cache.o
 LIB_OBJS += ref-filter.o
 LIB_OBJS += remote.o
diff --git a/refs/namespaced-backend.c b/refs/namespaced-backend.c
new file mode 100644
index 000..bcea2ca
--- /dev/null
+++ b/refs/namespaced-backend.c
@@ -0,0 +1,619 @@
+
+#include "../cache.h"
+#include "../config.h"
+#include "../refs.h"
+#include "refs-internal.h"
+#include "../repository.h"
+#include "../iterator.h"
+
+/* Namespace backend intended to stack on top of existing ref store */
+
+extern struct ref_storage_be refs_be_namespaced;
+
+struct namespaced_ref_store {
+   struct ref_store base;
+   struct ref_store *lower;
+   char *prefix;
+};
+
+static struct namespaced_ref_store *namespaced_downcast(
+   struct ref_store *ref_store, const char *caller)
+{
+   struct namespaced_ref_store *refs;
+
+   if (ref_store->be != _be_namespaced)
+   die("BUG: ref_store is type \"%s\" not \"namespaced\" in %s",
+   ref_store->be->name, caller);
+
+   refs = (struct namespaced_ref_store *)ref_store;
+
+   return refs;
+}
+
+int namespaced_ref_store_create(const char *gitdir,
+struct ref_store **lower)
+{
+   struct namespaced_ref_store *refs = NULL;
+   struct ref_store *ref_store;
+   char *config = NULL, *prefix = NULL;
+   int ret;
+   struct config_options opts;
+   struct config_set cs;
+   struct strbuf sb = STRBUF_INIT;
+
+   ret = get_common_dir(, gitdir);
+   if (ret < 0) {
+   goto cleanup;
+   }
+
+   opts.respect_includes = 1;
+   opts.commondir =  sb.buf;
+   opts.git_dir = gitdir;
+   memset(, 0, sizeof(cs));
+   git_configset_init();
+
+   ret = git_configset_add_standard(, );
+   if (ret < 0) {
+   goto cleanup;
+   }
+
+   ret = git_configset_get_string(, "core.namespace", );
+   if (ret != 0) {
+   goto cleanup;
+   }
+
+   prefix = expand_namespace(config);
+   assert(prefix);
+
+   refs = xcalloc(1, sizeof(*refs));
+   ref_store = >base;
+   refs->prefix = prefix;
+   prefix = NULL;
+
+   base_ref_store_init(ref_store, _be_namespaced);
+
+   refs->lower = *lower;
+   *lower = ref_store;
+   refs = NULL;
+
+cleanup:
+   free(refs);
+   git_configset_clear();
+   free(prefix);
+   free(config);
+   strbuf_release();
+
+   return ret;
+}
+
+static void prepend_prefix(struct ref_transaction *transaction,
+   const char *prefix)
+{
+   struct strbuf sb = STRBUF_INIT;
+   size_t prefixlen;
+   int i;
+
+   strbuf_addstr(, prefix);
+   prefixlen = sb.len;
+
+   for (i = 0; i < transaction->nr; i++) {
+   struct ref_update *oldupdate, *newupdate;
+
+   oldupdate = transaction->updates[i];
+
+   if (ref_type(oldupdate->refname) == REF_TYPE_PSEUDOREF)
+   continue;
+
+   strbuf_addstr(, oldupdate->refname);
+   FLEX_ALLOC_STR(newupdate, refname, sb.buf);
+   memcpy(newupdate, oldupdate,
+  ((char*)>refname) - (char*)newupdate);
+   transaction->updates[i] = newupdate;
+   free(oldupdate);
+   strbuf_setlen(, prefixlen);
+   }
+   strbuf_release();
+}
+
+static char *add_namespace(
+   struct strbuf *sb, struct namespaced_ref_store *refs,
+   const char *refname)
+{
+   if (ref_type(refname) != REF_TYPE_PSEUDOREF)
+   strbuf_addstr(sb, refs->prefix);
+   if (refname)
+   strbuf_addstr(sb, refname);
+   return sb->buf;
+}
+
+static int namespaced_init_db(struct ref_store *ref_store, struct strbuf *err)
+{
+   struct namespaced_ref_store *refs = namespaced_downcast(
+   ref_store, "init_db");
+   int ret;
+   
+   ret = refs->lower->be->init_db(refs->lower, err);
+   if (ret != 0)
+   return ret;
+
+   /* TODO: Needs to add an un-namespaced HEAD symlink,
+is_git_directory assumes it's not a repo without it.
+Can't change is_git_directory to resolve ref via backend
+since it would need to make the backend and can't free it. */
+   ret = refs->lower->be->create_symref(
+   refs->lower, "HEAD", "refs/heads/master", NULL);
+   if (ret != 0)
+   return 

[PATCH 7/7] Plumb in namespaced ref store

[Richard Maw]

---
 refs.c | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/refs.c b/refs.c
index 9a3dcfb..e80244f 100644
--- a/refs.c
+++ b/refs.c
@@ -647,7 +647,6 @@ int refs_delete_ref(struct ref_store *refs, const char *msg,
struct strbuf err = STRBUF_INIT;
 
if (ref_type(refname) == REF_TYPE_PSEUDOREF) {
-   assert(refs == get_main_ref_store());
return delete_pseudoref(refname, old_sha1);
}
 
@@ -986,7 +985,6 @@ int refs_update_ref(struct ref_store *refs, const char *msg,
int ret = 0;
 
if (ref_type(refname) == REF_TYPE_PSEUDOREF) {
-   assert(refs == get_main_ref_store());
ret = write_pseudoref(refname, new_sha1, old_sha1, );
} else {
t = ref_store_transaction_begin(refs, );
@@ -1589,6 +1587,9 @@ static struct ref_store *ref_store_init(const char 
*gitdir,
die("BUG: reference backend %s is unknown", be_name);
 
refs = be->init(gitdir, flags);
+
+   namespaced_ref_store_create(gitdir, );
+
return refs;
 }
 
-- 
2.9.0

[PATCH 5/7] Treat namespaced HEAD and refs/bisect as per-worktree

[Richard Maw]

---
 refs.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/refs.c b/refs.c
index 2e8bace..9a3dcfb 100644
--- a/refs.c
+++ b/refs.c
@@ -536,6 +536,7 @@ int dwim_log(const char *str, int len, unsigned char *sha1, 
char **log)
 
 static int is_per_worktree_ref(const char *refname)
 {
+   (void) skip_namespace(refname, );
return !strcmp(refname, "HEAD") ||
starts_with(refname, "refs/bisect/");
 }
-- 
2.9.0

[PATCH 1/7] Expose expand_namespace API

[Richard Maw]

Namespaces will not only be settable with GIT_NAMESPACE,
so this previously internal helper needs to be made available to other code.
---
 cache.h   | 1 +
 environment.c | 2 +-
 2 files changed, 2 insertions(+), 1 deletion(-)

diff --git a/cache.h b/cache.h
index 71fe092..e01b8a2 100644
--- a/cache.h
+++ b/cache.h
@@ -485,6 +485,7 @@ extern char *get_graft_file(void);
 extern int set_git_dir(const char *path);
 extern int get_common_dir_noenv(struct strbuf *sb, const char *gitdir);
 extern int get_common_dir(struct strbuf *sb, const char *gitdir);
+extern char *expand_namespace(const char *raw_namespace);
 extern const char *get_git_namespace(void);
 extern const char *strip_namespace(const char *namespaced_ref);
 extern const char *get_super_prefix(void);
diff --git a/environment.c b/environment.c
index 3fd4b10..97dfa8c 100644
--- a/environment.c
+++ b/environment.c
@@ -123,7 +123,7 @@ const char * const local_repo_env[] = {
NULL
 };
 
-static char *expand_namespace(const char *raw_namespace)
+char *expand_namespace(const char *raw_namespace)
 {
struct strbuf buf = STRBUF_INIT;
struct strbuf **components, **c;
-- 
2.9.0

Re: [RFC] clang-format: outline the git project's coding style

[Ramsay Jones]

On 13/08/17 18:33, Junio C Hamano wrote:
> Ramsay Jones  writes:
>> Hmm, on reflection, it may be a bit too crude! :-D
> 
> As you already saw in the output from this, I think this is a good
> illustration that shows why we want an incremental tool that works
> on the changes, not on full file contents.  Contributors who want
> their changes accepted and want to help the review process by
> avoiding trivial coding style violations in their patches should not
> have to find _their_ piece from an output about the whole file
> contents, most of which is likely to have been inherited from the
> original.  They are not working on Git to produce unnecessary code
> churn whose only purpose is to make existing and otherwise dormant
> code conform to the style tool's liking.  That's not their focus.
> 
> IOW I was expecting something that works on the output from "git
> diff HEAD" or "git format-patch --stdout @{u}.."

Yes, I had already tried the following, which maybe more workable,
but it is only lightly tested. (we may want to create our own version
of checkpatch.pl, which is written specifically for the kernel ...)

$ git diff
diff --git a/Makefile b/Makefile
index 461c845d3..a25028e68 100644
--- a/Makefile
+++ b/Makefile
@@ -2440,6 +2440,15 @@ $(SP_OBJ): %.sp: %.c GIT-CFLAGS FORCE
 .PHONY: sparse $(SP_OBJ)
 sparse: $(SP_OBJ)
 
+STYLE_REVS = HEAD
+STYLE_IGNORES = NEW_TYPEDEFS,INLINE
+
+.PHONY: style
+style:
+   @git diff $(STYLE_REVS) -- '*.[ch]' | \
+   checkpatch.pl -q --no-tree --show-types \
+   --ignore=$(STYLE_IGNORES) --patch - 2>/dev/null || true
+
 check: common-cmds.h
@if sparse; \
then \
$ make style  # I don't have any changes to *.[ch] files!
$ make STYLE_REVS=HEAD~3 style
WARNING:LONG_LINE: line over 80 characters
#181: FILE: git.c:320:
+   if (use_pager == -1 && p->option & (RUN_SETUP | 
RUN_SETUP_GENTLY) &&

WARNING:LONG_LINE: line over 80 characters
#221: FILE: revision.c:2317:
+   if (revs->def && !revs->pending.nr && !revs->rev_input_given && 
!got_rev_arg) {

total: 0 errors, 2 warnings, 206 lines checked
$ 

I suspect this closer to what you had in mind. ;-)
(although the --ignore list may need adding to).

ATB,
Ramsay Jones

Re: [PATCH 0/5] make interpret-trailers useful for parsing

[Jacob Keller]

On Thu, Aug 10, 2017 at 11:42 AM, Junio C Hamano  wrote:
> Jeff King  writes:
>
>>> > The above example made me wonder if we also want a format specifier
>>> > to do the above without piping, but it turns out that we already
>>> > have "log --format=%(trailers)", so we are good ;-)
>>>
>>> I was going to say, I thought we had a way to get trailers for a
>>> commit via the pretty format, since that is what i used in the past.
>>
>> I do like that you could get the trailers for many commits in a single
>> invocation. That doesn't matter for my current use-case, but obviously
>> piping through O(n) interpret-trailers invocations is a bad idea.
>> But there are a few difficulties with using %(trailers) for this,...
>
> I think it is clear to you, but it may not be clear to others, that
> I did not mean to say "because 'log --format' already knows about
> it, this change to interpret-trailers is unnecessary".
>
>> For (1) I think many callers would prefer to see the original
>> formatting. Maybe we'd need a %(trailers:normalize) or something.
>
> Thanks; that is exactly the line of thought I had in the back of my
> head without even realizing when I brought up %(trailers) format
> element.

I'll add that I also think this patch series is good, it's useful to
have a separate command.

Thanks,
Jake

Re: [PATCH 1/9] Convert pack-objects to size_t

[Martin Koegler]

On Sat, Aug 12, 2017 at 02:47:25PM +0100, Ramsay Jones wrote:
> On 32-bit Linux, off_t is 64-bit and size_t is 32-bit.

--- t.c ---
#include 
#include 

int main()
{
printf("%d %d\n", sizeof(size_t), sizeof(off_t));
}

$ gcc -m32 -o t t.c
$ ./t.c
4 4

So is that really true?

Regards,
Martin 

Re: [PATCH 1/9] Convert pack-objects to size_t

[Martin Koegler]

On Sat, Aug 12, 2017 at 11:59:15AM +0200, Torsten Bögershausen wrote:
> Thanks for working on this - unfortunatly the patch does not apply on
> git.git/master.
> 
> Which baseline did you use ?

next - 98096fd7a85b93626db8757f944f2d8ffdf7e96a
It accumulated to 19 patches.

Regards,
Martin 

Re: [PATCH 3/9] Convert unpack-objects to size_t

[Martin Koegler]

On Sat, Aug 12, 2017 at 04:07:50PM +0200, Martin Ågren wrote:
> On 12 August 2017 at 10:47, Martin Koegler  wrote:
> "size" is handed over to a "git_zstream" and goes through zlib.c,
> eventually ending up in zlib, which is outside Git's control, and which
> seems to work with "uLong"s. How do these kind of changes interact with
> zlib? For example, I wonder about this line further down in get_data:
> 
> if (stream.total_out == size && ret == Z_STREAM_END)
> 
> If total_out isn't converted, I guess this would never hit if "size" is
> too large. And if total_out /is/ converted, I guess we'd risk truncation

I posted a patch changing git_zstream.

> in zlib_pre_call in zlib.c. Maybe that might cause Git and zlib to have
> different ideas about how much data is available and/or should be
> processed. Maybe we could then hit things like this in git.c:
> 
> if (s->z.total_out != s->total_out + bytes_produced)
> die("BUG: total_out mismatch");
> 
> I am not very familiar with zlib, so apologies if this is just noise...

You are right, if sizeof(size_t) != sizeof(unsigned long), there can be 
truncations.

Currently, an object size is read/passed as ulong including to the memory 
allocation functions.
(x)malloc & Co take a length - so the whole GIT code might assume a larger 
object size than the
memory allocation functions.
Migrating everything to size_t means, that we move the truncation locations to 
places, where values 
enter/leave GIT.

My patches are just a starting point to fix the size handling. They concentrate 
of fixing data types - 
not avoiding any possible overflow.  Merging them will already be a challenging 
task, because they 
touch many functions and will likely conflict with other changes (eg. moving 
functions).

Regards,
Martin

Re: [PATCH 5/9] Convert various things to size_t

[Martin Koegler]

On Sat, Aug 12, 2017 at 03:27:21PM +0200, Martin Ågren wrote:
> On 12 August 2017 at 10:47, Martin Koegler  wrote:
> > From: Martin Koegler 
> >
> > ---
> >  bisect.c| 2 +-
> >  blame.c | 2 +-
> >  builtin/fmt-merge-msg.c | 2 +-
> >  builtin/mktag.c | 2 +-
> >  dir.c   | 4 ++--
> >  dir.h   | 2 +-
> >  6 files changed, 7 insertions(+), 7 deletions(-)
> >
> > diff --git a/bisect.c b/bisect.c
> > index 2549eaf..0580c82 100644
> > --- a/bisect.c
> > +++ b/bisect.c
> > @@ -131,7 +131,7 @@ static void show_list(const char *debug, int counted, 
> > int nr,
> > struct commit *commit = p->item;
> > unsigned flags = commit->object.flags;
> > enum object_type type;
> > -   unsigned long size;
> > +   size_t size;
> > char *buf = read_sha1_file(commit->object.sha1, , 
> > );
> > const char *subject_start;
> > int subject_len;
> 
> Would this need to be done in a patch where read_sha1_file is converted?

I missed this first, because it is debug code requiring a code change to be 
enabled. 

It probably should be merged in my second patch. On the other hand that patch 
is already considered too large.

Regards,
Martin

Re: [RFC] clang-format: outline the git project's coding style

[Junio C Hamano]

Ramsay Jones  writes:

> As a start, how about something like this:
>
> -- >8 --
> $ git diff
> diff --git a/Makefile b/Makefile
> index 461c845d3..7555def45 100644
> --- a/Makefile
> +++ b/Makefile
> @@ -2440,6 +2440,18 @@ $(SP_OBJ): %.sp: %.c GIT-CFLAGS FORCE
>  .PHONY: sparse $(SP_OBJ)
>  sparse: $(SP_OBJ)
>  
> +ST_C = $(patsubst %.o,%.stc,$(C_OBJ))
> +ST_H = $(patsubst %.h,%.sth,$(LIB_H))
> +
> +$(ST_C): %.stc: %.c FORCE
> +   checkpatch.pl --no-tree --show-types --ignore=NEW_TYPEDEFS,INLINE -f 
> $<
> +
> +$(ST_H): %.sth: %.h FORCE
> +   checkpatch.pl --no-tree --show-types --ignore=NEW_TYPEDEFS,INLINE -f 
> $<
> +
> +.PHONY: style $(ST_C) $(ST_H)
> +style: $(ST_C) $(ST_H)
> +
>  check: common-cmds.h
> @if sparse; \
> then \
> $ 
> -- >8 --
> ...
> Hmm, on reflection, it may be a bit too crude! :-D

As you already saw in the output from this, I think this is a good
illustration that shows why we want an incremental tool that works
on the changes, not on full file contents.  Contributors who want
their changes accepted and want to help the review process by
avoiding trivial coding style violations in their patches should not
have to find _their_ piece from an output about the whole file
contents, most of which is likely to have been inherited from the
original.  They are not working on Git to produce unnecessary code
churn whose only purpose is to make existing and otherwise dormant
code conform to the style tool's liking.  That's not their focus.

IOW I was expecting something that works on the output from "git
diff HEAD" or "git format-patch --stdout @{u}.."

Unless you were somehow envisioning that having a baseline line
this, and then take another full dump after their patch and
comparing the two, would make a good foundation for that incremental
checker, that is.  I am not sure if that would be a workable
approach myself, though.

Thanks.

Re: [RFC] clang-format: outline the git project's coding style

[Ramsay Jones]

On 13/08/17 17:14, Ramsay Jones wrote:
> 
> 
> On 13/08/17 05:41, Jeff King wrote:
>> On Fri, Aug 11, 2017 at 09:39:11PM -0700, Junio C Hamano wrote:
>>
 Yeah, I just dug in the archive. The script I ran way back when was
 actually clang-format-diff.
>>>
>>> I am confident with the competence of people around here that we can
>>> come up with a reasonable checker for obvious style violations. In
>>> the worst case, we could customize and/or tweak checkpatch.pl and
>>> start from there.
>>
>> I am confident we _can_, too. My question is whether we will. :)
>>
>>> Assuming that we can have such a checker, I am more interested in
>>> the way how people envision such a checker fits in our workflow to
>>> help people.  Earlier Dscho floated an idea to integrate with the
>>> GitHub pull requests in a way similar to how Travis and SubmitGit
>>> are triggered, and I can sort of see how it may help, but I haven't
>>> seen ideas from others.
>>
>> Yeah, I agree. I assume most people already run "make test" locally. I'd
>> be happy enough if we started with a "make style" that offers style
>> suggestions for you to accept. From there we can grow into
>> "automatically apply suggestions" and integrating with things like
>> submitGit.
> 
> As a start, how about something like this:
> 
> -- >8 --
> $ git diff
> diff --git a/Makefile b/Makefile
> index 461c845d3..7555def45 100644
> --- a/Makefile
> +++ b/Makefile
> @@ -2440,6 +2440,18 @@ $(SP_OBJ): %.sp: %.c GIT-CFLAGS FORCE
>  .PHONY: sparse $(SP_OBJ)
>  sparse: $(SP_OBJ)
>  
> +ST_C = $(patsubst %.o,%.stc,$(C_OBJ))
> +ST_H = $(patsubst %.h,%.sth,$(LIB_H))
> +
> +$(ST_C): %.stc: %.c FORCE
> +   checkpatch.pl --no-tree --show-types --ignore=NEW_TYPEDEFS,INLINE -f 
> $<
> +
> +$(ST_H): %.sth: %.h FORCE
> +   checkpatch.pl --no-tree --show-types --ignore=NEW_TYPEDEFS,INLINE -f 
> $<
> +
> +.PHONY: style $(ST_C) $(ST_H)
> +style: $(ST_C) $(ST_H)
> +
>  check: common-cmds.h
> @if sparse; \
> then \
> $ 
> -- >8 --
> 
> To give it a try:
> 
> $ make git.stc# just run checkpatch over git.c
> $ make cache.sth  # just run checkpatch over cache.h
> $ make -k style >style.out 2>&1  # yep, large output!
> 
> A bit crude, but workable. ;-)
> 
> Just FYI, for me:
> 
> $ wc -l style.out
> 144076 style.out
> $ 
> $ grep '^WARNING' style.out | cut -d: -f1,2 | sort | uniq -c
>   2 WARNING:AVOID_EXTERNS
> 495 WARNING:BLOCK_COMMENT_STYLE
> 127 WARNING:BRACES
> 213 WARNING:CONSTANT_COMPARISON
>   12584 WARNING:CONST_STRUCT
>   5 WARNING:CVS_KEYWORD
>  26 WARNING:DEEP_INDENTATION
>   2 WARNING:DEFAULT_NO_BREAK
>  77 WARNING:EMBEDDED_FUNCTION_NAME
>   5 WARNING:ENOSYS
> 773 WARNING:FUNCTION_ARGUMENTS
>  39 WARNING:INDENTED_LABEL
>2610 WARNING:LEADING_SPACE
>   1 WARNING:LINE_CONTINUATIONS
>2680 WARNING:LINE_SPACING
>3975 WARNING:LONG_LINE
> 330 WARNING:LONG_LINE_COMMENT
> 380 WARNING:LONG_LINE_STRING
>   2 WARNING:MACRO_WITH_FLOW_CONTROL
>   1 WARNING:MISORDERED_TYPE
>  17 WARNING:MISSING_SPACE
>   1 WARNING:ONE_SEMICOLON
>  77 WARNING:PREFER_PRINTF
>   7 WARNING:QUOTED_WHITESPACE_BEFORE_NEWLINE
>  10 WARNING:RETURN_VOID
>   5 WARNING:SINGLE_STATEMENT_DO_WHILE_MACRO
>   6 WARNING:SIZEOF_PARENTHESIS
>  61 WARNING:SPACE_BEFORE_TAB
> 347 WARNING:SPACING
> 322 WARNING:SPLIT_STRING
>  87 WARNING:STATIC_CONST_CHAR_ARRAY
>   2 WARNING:STORAGE_CLASS
> 538 WARNING:SUSPECT_CODE_INDENT
>  29 WARNING:SYMBOLIC_PERMS
> 279 WARNING:TABSTOP
>   9 WARNING:TRAILING_SEMICOLON
>   3 WARNING:TYPECAST_INT_CONSTANT
>   2 WARNING:UNNECESSARY_BREAK
>  56 WARNING:UNNECESSARY_ELSE
> 568 WARNING:UNSPECIFIED_INT
>   4 WARNING:USE_NEGATIVE_ERRNO
>  26 WARNING:VOLATILE
> $ 

oops, I forgot this:

$ grep '^ERROR' style.out | cut -d: -f1,2 | sort | uniq -c
216 ERROR:ASSIGN_IN_IF
 46 ERROR:CODE_INDENT
 41 ERROR:COMPLEX_MACRO
317 ERROR:ELSE_AFTER_BRACE
  3 ERROR:FUNCTION_WITHOUT_ARGS
  1 ERROR:GLOBAL_INITIALISERS
 46 ERROR:INITIALISED_STATIC
  2 ERROR:INLINE_LOCATION
  5 ERROR:MULTISTATEMENT_MACRO_USE_DO_WHILE
305 ERROR:OPEN_BRACE
314 ERROR:POINTER_LOCATION
  5 ERROR:RETURN_PARENTHESES
   3464 ERROR:SPACING
  7 ERROR:SWITCH_CASE_INDENT_LEVEL
326 ERROR:TRAILING_STATEMENTS
 15 ERROR:TRAILING_WHITESPACE
$ 

> Hmm, on reflection, it may be a bit too crude! :-D
> 
> ATB,
> Ramsay Jones
> 
> 

Re: [RFC] clang-format: outline the git project's coding style

[Ramsay Jones]

On 13/08/17 05:41, Jeff King wrote:
> On Fri, Aug 11, 2017 at 09:39:11PM -0700, Junio C Hamano wrote:
> 
>>> Yeah, I just dug in the archive. The script I ran way back when was
>>> actually clang-format-diff.
>>
>> I am confident with the competence of people around here that we can
>> come up with a reasonable checker for obvious style violations. In
>> the worst case, we could customize and/or tweak checkpatch.pl and
>> start from there.
> 
> I am confident we _can_, too. My question is whether we will. :)
> 
>> Assuming that we can have such a checker, I am more interested in
>> the way how people envision such a checker fits in our workflow to
>> help people.  Earlier Dscho floated an idea to integrate with the
>> GitHub pull requests in a way similar to how Travis and SubmitGit
>> are triggered, and I can sort of see how it may help, but I haven't
>> seen ideas from others.
> 
> Yeah, I agree. I assume most people already run "make test" locally. I'd
> be happy enough if we started with a "make style" that offers style
> suggestions for you to accept. From there we can grow into
> "automatically apply suggestions" and integrating with things like
> submitGit.

As a start, how about something like this:

-- >8 --
$ git diff
diff --git a/Makefile b/Makefile
index 461c845d3..7555def45 100644
--- a/Makefile
+++ b/Makefile
@@ -2440,6 +2440,18 @@ $(SP_OBJ): %.sp: %.c GIT-CFLAGS FORCE
 .PHONY: sparse $(SP_OBJ)
 sparse: $(SP_OBJ)
 
+ST_C = $(patsubst %.o,%.stc,$(C_OBJ))
+ST_H = $(patsubst %.h,%.sth,$(LIB_H))
+
+$(ST_C): %.stc: %.c FORCE
+   checkpatch.pl --no-tree --show-types --ignore=NEW_TYPEDEFS,INLINE -f $<
+
+$(ST_H): %.sth: %.h FORCE
+   checkpatch.pl --no-tree --show-types --ignore=NEW_TYPEDEFS,INLINE -f $<
+
+.PHONY: style $(ST_C) $(ST_H)
+style: $(ST_C) $(ST_H)
+
 check: common-cmds.h
@if sparse; \
then \
$ 
-- >8 --

To give it a try:

$ make git.stc# just run checkpatch over git.c
$ make cache.sth  # just run checkpatch over cache.h
$ make -k style >style.out 2>&1  # yep, large output!

A bit crude, but workable. ;-)

Just FYI, for me:

$ wc -l style.out
144076 style.out
$ 
$ grep '^WARNING' style.out | cut -d: -f1,2 | sort | uniq -c
  2 WARNING:AVOID_EXTERNS
495 WARNING:BLOCK_COMMENT_STYLE
127 WARNING:BRACES
213 WARNING:CONSTANT_COMPARISON
  12584 WARNING:CONST_STRUCT
  5 WARNING:CVS_KEYWORD
 26 WARNING:DEEP_INDENTATION
  2 WARNING:DEFAULT_NO_BREAK
 77 WARNING:EMBEDDED_FUNCTION_NAME
  5 WARNING:ENOSYS
773 WARNING:FUNCTION_ARGUMENTS
 39 WARNING:INDENTED_LABEL
   2610 WARNING:LEADING_SPACE
  1 WARNING:LINE_CONTINUATIONS
   2680 WARNING:LINE_SPACING
   3975 WARNING:LONG_LINE
330 WARNING:LONG_LINE_COMMENT
380 WARNING:LONG_LINE_STRING
  2 WARNING:MACRO_WITH_FLOW_CONTROL
  1 WARNING:MISORDERED_TYPE
 17 WARNING:MISSING_SPACE
  1 WARNING:ONE_SEMICOLON
 77 WARNING:PREFER_PRINTF
  7 WARNING:QUOTED_WHITESPACE_BEFORE_NEWLINE
 10 WARNING:RETURN_VOID
  5 WARNING:SINGLE_STATEMENT_DO_WHILE_MACRO
  6 WARNING:SIZEOF_PARENTHESIS
 61 WARNING:SPACE_BEFORE_TAB
347 WARNING:SPACING
322 WARNING:SPLIT_STRING
 87 WARNING:STATIC_CONST_CHAR_ARRAY
  2 WARNING:STORAGE_CLASS
538 WARNING:SUSPECT_CODE_INDENT
 29 WARNING:SYMBOLIC_PERMS
279 WARNING:TABSTOP
  9 WARNING:TRAILING_SEMICOLON
  3 WARNING:TYPECAST_INT_CONSTANT
  2 WARNING:UNNECESSARY_BREAK
 56 WARNING:UNNECESSARY_ELSE
568 WARNING:UNSPECIFIED_INT
  4 WARNING:USE_NEGATIVE_ERRNO
 26 WARNING:VOLATILE
$ 

Hmm, on reflection, it may be a bit too crude! :-D

ATB,
Ramsay Jones

[PATCH] doc: clarify "config --bool" behaviour with empty values

[Andreas Heiduk]

`git config --bool xxx.yyy` returns `true` for `[xxx]yyy` but
`false` for `[xxx]yyy=` or `[xxx]yyy=""`.  This is tested in
t1300-repo-config.sh since 09bc098c2.

Signed-off-by: Andreas Heiduk 
---
 Documentation/config.txt | 3 ++-
 Documentation/git.txt| 3 ++-
 2 files changed, 4 insertions(+), 2 deletions(-)

diff --git a/Documentation/config.txt b/Documentation/config.txt
index d5c9c4cab..d3261006b 100644
--- a/Documentation/config.txt
+++ b/Documentation/config.txt
@@ -221,7 +221,8 @@ boolean::
is taken as true.
 
false;; Boolean false can be spelled as `no`, `off`,
-   `false`, or `0`.
+   `false`, `0`, no value (but still with `=`) or the
+   empty string.
 +
 When converting value to the canonical form using `--bool` type
 specifier; 'git config' will ensure that the output is "true" or
diff --git a/Documentation/git.txt b/Documentation/git.txt
index 7dd5e0328..6e3a6767e 100644
--- a/Documentation/git.txt
+++ b/Documentation/git.txt
@@ -75,7 +75,8 @@ example the following invocations are equivalent:
 Note that omitting the `=` in `git -c foo.bar ...` is allowed and sets
 `foo.bar` to the boolean true value (just like `[foo]bar` would in a
 config file). Including the equals but with an empty value (like `git -c
-foo.bar= ...`) sets `foo.bar` to the empty string.
+foo.bar= ...`) sets `foo.bar` to the empty string which ` git config
+--bool` will convert to `false`.
 
 --exec-path[=]::
Path to wherever your core Git programs are installed.
-- 
2.13.3

[PATCH/RFC 2/2] File commited with CRLF should roundtrip diff and apply

[tboegi]

From: Torsten Bögershausen 

When a file had been commited with CRLF and core.autocrlf is true,
the following does not roundtrip, `git apply` fails:

printf "Added line\r\n" >>file &&
git diff >patch &&
git checkout -- . &&
git apply patch

Before applying the patch, the file from working tree is converted into the
index format (clean filter, CRLF conversion, ...)
Here, when commited with CRLF, the line endings should not be converted.

Analyze the patch if there is any context line with CRLF,
or if any line with CRLF is to be removed.

If yes, the new flag has_crlf is set in "struct patch", and two things
will happen:
- read_old_data() will not convert CRLF into LF by calling
  convert_to_git(..., SAFE_CRLF_KEEP_CRLF);
- The WS_CR_AT_EOL bit is set in the "white space rule",
  CRLF are no longer treated as white space.

Thanks to Junio C Hamano, his input became the base for t4140.

Reported-by: Anthony Sottile 
Signed-off-by: Torsten Bögershausen 
---


The last version did not pass t4124, fix this.



apply.c  | 37 -
 apply.h  |  4 
 t/t4124-apply-ws-rule.sh |  3 +--
 t/t4140-apply-CRLF.sh| 46 ++
 4 files changed, 79 insertions(+), 11 deletions(-)
 create mode 100755 t/t4140-apply-CRLF.sh

diff --git a/apply.c b/apply.c
index f2d599141d..63455cd65f 100644
--- a/apply.c
+++ b/apply.c
@@ -220,6 +220,7 @@ struct patch {
unsigned int recount:1;
unsigned int conflicted_threeway:1;
unsigned int direct_to_threeway:1;
+   unsigned int has_crlf:1;
struct fragment *fragments;
char *result;
size_t resultsize;
@@ -1662,6 +1663,17 @@ static void check_whitespace(struct apply_state *state,
record_ws_error(state, result, line + 1, len - 2, state->linenr);
 }
 
+/* Check if the patch has context lines with CRLF or
+   the patch wants to remove lines with CRLF */
+static void check_old_for_crlf(struct patch *patch, const char *line, int len)
+{
+   if (len >= 2 && line[len-1] == '\n' && line[len-2] == '\r') {
+   patch->ws_rule |= WS_CR_AT_EOL;
+   patch->has_crlf = 1;
+   }
+}
+
+
 /*
  * Parse a unified diff. Note that this really needs to parse each
  * fragment separately, since the only way to know the difference
@@ -1712,11 +1724,13 @@ static int parse_fragment(struct apply_state *state,
if (!deleted && !added)
leading++;
trailing++;
+   check_old_for_crlf(patch, line, len);
if (!state->apply_in_reverse &&
state->ws_error_action == correct_ws_error)
check_whitespace(state, line, len, 
patch->ws_rule);
break;
case '-':
+   check_old_for_crlf(patch, line, len);
if (state->apply_in_reverse &&
state->ws_error_action != nowarn_ws_error)
check_whitespace(state, line, len, 
patch->ws_rule);
@@ -2268,8 +2282,10 @@ static void show_stats(struct apply_state *state, struct 
patch *patch)
add, pluses, del, minuses);
 }
 
-static int read_old_data(struct stat *st, const char *path, struct strbuf *buf)
+static int read_old_data(struct stat *st, const char *path, struct strbuf 
*buf, int flags)
 {
+   enum safe_crlf safe_crlf = flags & APPLY_FLAGS_CR_AT_EOL ?
+   SAFE_CRLF_KEEP_CRLF : SAFE_CRLF_FALSE;
switch (st->st_mode & S_IFMT) {
case S_IFLNK:
if (strbuf_readlink(buf, path, st->st_size) < 0)
@@ -2278,7 +2294,7 @@ static int read_old_data(struct stat *st, const char 
*path, struct strbuf *buf)
case S_IFREG:
if (strbuf_read_file(buf, path, st->st_size) != st->st_size)
return error(_("unable to open or read %s"), path);
-   convert_to_git(_index, path, buf->buf, buf->len, buf, 0);
+   convert_to_git(_index, path, buf->buf, buf->len, buf, 
safe_crlf);
return 0;
default:
return -1;
@@ -3385,7 +3401,8 @@ static int load_patch_target(struct apply_state *state,
 const struct cache_entry *ce,
 struct stat *st,
 const char *name,
-unsigned expected_mode)
+unsigned expected_mode,
+int flags)
 {
if (state->cached || state->check_index) {
if (read_file_or_gitlink(ce, buf))
@@ -3399,7 +3416,7 @@ static int load_patch_target(struct apply_state *state,
} else if (has_symlink_leading_path(name, strlen(name))) {
return error(_("reading from '%s' beyond a symbolic 

[PATCH/RFC 1/2] convert: Add SAFE_CRLF_KEEP_CRLF

[tboegi]

From: Torsten Bögershausen 

When convert_to_git() is called, the caller may want to keep CRLF
to be kept as CRLF (and not converted into LF).

This will be used in the next commit, when apply works with files that have
CRLF and patches are applied onto these files.

Add the new value "SAFE_CRLF_KEEP_CRLF" to safe_crlf.

Prepare convert_to_git() to be able to run the clean filter,
skip the CRLF conversion and run the ident filter.

Signed-off-by: Torsten Bögershausen 
---
convert.c | 10 ++
 convert.h |  3 ++-
 2 files changed, 8 insertions(+), 5 deletions(-)

diff --git a/convert.c b/convert.c
index deaf0ba7b3..040123b4fe 100644
--- a/convert.c
+++ b/convert.c
@@ -1104,10 +1104,12 @@ int convert_to_git(const struct index_state *istate,
src = dst->buf;
len = dst->len;
}
-   ret |= crlf_to_git(istate, path, src, len, dst, ca.crlf_action, 
checksafe);
-   if (ret && dst) {
-   src = dst->buf;
-   len = dst->len;
+   if (checksafe != SAFE_CRLF_KEEP_CRLF) {
+   ret |= crlf_to_git(istate, path, src, len, dst, ca.crlf_action, 
checksafe);
+   if (ret && dst) {
+   src = dst->buf;
+   len = dst->len;
+   }
}
return ret | ident_to_git(path, src, len, dst, ca.ident);
 }
diff --git a/convert.h b/convert.h
index cecf59d1aa..cabd5ed6dd 100644
--- a/convert.h
+++ b/convert.h
@@ -10,7 +10,8 @@ enum safe_crlf {
SAFE_CRLF_FALSE = 0,
SAFE_CRLF_FAIL = 1,
SAFE_CRLF_WARN = 2,
-   SAFE_CRLF_RENORMALIZE = 3
+   SAFE_CRLF_RENORMALIZE = 3,
+   SAFE_CRLF_KEEP_CRLF = 4
 };
 
 extern enum safe_crlf safe_crlf;
-- 
2.14.1.145.gb3622a4ee9

Re: git-describe --contains

[Davide Cavallari]

Thanks Andreas and Nicholas, I'll check it out.