The following printout gives a warning:
(trace.c, arounf line 105)
strbuf_addf(buf, "%02d:%02d:%02d.%06ld ", tm.tm_hour, tm.tm_min,
tm.tm_sec, tv.tv_usec);
trace.c:105: warning: format ‘%06ld’ expects type ‘long int’, but argument 6
has type ‘__darwin_suseconds_t’
A
Historically there are 3 different parameters controlling how line endings
are handled by Git:
- core.autocrlf
- core.eol
- the "text" attribute in .gitattributes
There are different types of content:
- (1) Files with only LF
- (2) Files with only CRLF
- (3) Files with mixed LF and CRLF
- (4) File
On Sun, Jun 8, 2014 at 10:18 AM, Junio C Hamano wrote:
>
> On Sat, Jun 7, 2014 at 11:49 PM, Christian Couder
> wrote:
>>
>> On Fri, Jun 6, 2014 at 5:44 PM, Christian Couder
>> wrote:
>> >
>> > /* find existing parents */
>> > strbuf_addstr(&buf, commit->buffer);
>>
>> Unfortunate
The current test files are named one, two and three.
Make it clearer what the tests do and rename them into
LFonly, CRLFonly and LFwithNUL.
After the renaming we can see easier that we may want more test cases
for 2 types of files:
- files which have mixed LF and CRLF line endings,
- files which h
Avoid overrunning the existing pack name (p->pack_name, a C string) in
the case that the new path is longer by using strncmp instead of memcmp
for comparing. While at it, replace the magic constant 4 with a
strlen call to document its meaning.
Signed-off-by: Rene Scharfe
---
No changes from inti
Instead of using strbuf to create a message string in case a path is
too long for our fixed-size buffer, replace that buffer with a strbuf
and thus get rid of the limitation.
Helped-by: Duy Nguyen
Signed-off-by: Rene Scharfe
---
@Duy: Thanks for catching the missing strbuf_release in the opendir
On Sat, Jun 28, 2014 at 7:20 AM, David Turner wrote:
> When git checkout checks out a branch, create or update the
> cache-tree so that subsequent operations are faster.
>
> Signed-off-by: David Turner
> ---
> builtin/checkout.c| 4
> cache-tree.c | 22 --
>
On Sat, Jun 28, 2014 at 9:47 PM, René Scharfe wrote:
> - sprintf(path, "%s/pack", objdir);
> - len = strlen(path);
> - dir = opendir(path);
> + strbuf_addstr(&path, objdir);
> + strbuf_addstr(&path, "/pack");
> + dir = opendir(path.buf);
> if (!dir) {
>
On Sat, Jun 28, 2014 at 1:56 AM, Thomas Braun
wrote:
>> The name is misleading and forced me to read it twice before I
>> realized that this is "populating the is-binary bit". It might make
>> it a bit better if you renamed it to DIFF_POPULATE_IS_BINARY_BIT or
>> perhaps DIFF_POPULATE_CHECK_BINAR
On Fri, Jun 27, 2014 at 1:09 AM, Junio C Hamano wrote:
> Nguyễn Thái Ngọc Duy writes:
>
>> fsck is a tool that error() is more preferred than die(), but many
>
> "more preferred" without justifying why it is "more preferred" is
> not quite a justification, is it? Also, an object failing to load
On Fri, Jun 27, 2014 at 5:02 AM, Junio C Hamano wrote:
> * nd/split-index (2014-06-13) 32 commits
> - t1700: new tests for split-index mode
> - t2104: make sure split index mode is off for the version test
> - read-cache: force split index mode with GIT_TEST_SPLIT_INDEX
> - read-tree: note abo
Tests "merge without conflict (missing LF at EOF" and "merge result
added missing LF" are meaningless - the first one is identical to
"merge without conflict" and the second compares results of those
identical tests, which are always same.
This has been so since their addition in ba1f5f3537. Proba
If 'current-file' does not contain LF at EOF, and change between
'base-file' and 'other-file' does not change any line close to EOF, the
3-way merge should not add LF to EOF. This is what 'diff3 -m' does, and
seems to be a reasonable expectation.
The change which introduced the behavior is cd1d61
I realized the case when the newline adding can be needed.
The version 2 have this case (union-merge of changes at EOF without LF)
fixed, with adding corresponding tests.
Max Kirillov (2):
t6023-merge-file.sh: fix and mark as broken invalid tests
git-merge-file: do not add LF at EOF while app
Tests "merge without conflict (missing LF at EOF" and "merge result
added missing LF" are meaningless - the first one is identical to
"merge without conflict" and the second compares results of those
identical tests, which are always same.
This has been so since their addition in ba1f5f3537. Proba
If 'current-file' does not contain LF at EOF, and change between
'base-file' and 'other-file' does not change any line close to EOF, the
3-way merge should not add LF to EOF. This is what 'diff3 -m' does, and
seems to be a reasonable expectation.
The change which introduced the behavior is cd1d61
Hi.
I have noticed that cherry-pick adds trailing newlines when it is not
expected to - the change does not contain its addition. Here is the fix
for it.
The fix is quite debugging-driven, without detailed analysis of how
exactly this "add_nl" parameter works in all cases. But it passes all
tests
Signed-off-by: Christian Couder
---
builtin/replace.c | 42 +-
1 file changed, 25 insertions(+), 17 deletions(-)
diff --git a/builtin/replace.c b/builtin/replace.c
index 3515979..ad47237 100644
--- a/builtin/replace.c
+++ b/builtin/replace.c
@@ -295,27 +29
Signed-off-by: Christian Couder
Signed-off-by: Junio C Hamano
---
Documentation/git-replace.txt | 8
1 file changed, 8 insertions(+)
diff --git a/Documentation/git-replace.txt b/Documentation/git-replace.txt
index 61461b9..491875e 100644
--- a/Documentation/git-replace.txt
+++ b/Docume
Signed-off-by: Christian Couder
---
t/t6050-replace.sh | 22 ++
1 file changed, 22 insertions(+)
diff --git a/t/t6050-replace.sh b/t/t6050-replace.sh
index ca45a84..80b85e3 100755
--- a/t/t6050-replace.sh
+++ b/t/t6050-replace.sh
@@ -7,6 +7,7 @@ test_description='Tests replac
This patch adds into contrib/ an example script to convert
grafts from an existing grafts file into replace refs using
the new --graft option of "git replace".
While at it let's mention this new script in the
"git replace" documentation for the --graft option.
Signed-off-by: Christian Couder
Sig
It could be misleading to keep a signature in a
replacement commit, so let's remove it.
Note that there should probably be a way to sign
the replacement commit created when using --graft,
but this can be dealt with in another commit or
patch series.
Signed-off-by: Christian Couder
---
builtin/r
The usage string for this option is:
git replace [-f] --graft [...]
First we create a new commit that is the same as
except that its parents are [...]
Then we create a replace ref that replace with
the commit we just created.
With this new option, it should be straightforward to
convert graf
Signed-off-by: Christian Couder
Signed-off-by: Junio C Hamano
---
t/t6050-replace.sh | 12
1 file changed, 12 insertions(+)
diff --git a/t/t6050-replace.sh b/t/t6050-replace.sh
index 68b3cb2..ca45a84 100755
--- a/t/t6050-replace.sh
+++ b/t/t6050-replace.sh
@@ -351,4 +351,16 @@ test
Here is a small patch series to implement:
git replace [-f] --graft [...]
This patch series goes on top of the patch series that
implements --edit.
The changes since v4, thanks to Junio and Peff, are:
- The series has been rebased on top of Peff's series
to store the commit buffer le
Avoid overrunning the existing pack name (p->pack_name, a C string) in
the case that the new path is longer by using strncmp instead of memcmp
for comparing. While at it, replace the magic constant 4 with a
strlen call to document its meaning.
Signed-off-by: Rene Scharfe
---
sha1_file.c | 3 ++-
Instead of using strbuf to create a message string in case a path is
too long for our fixed-size buffer, replace that buffer with a strbuf
and thus get rid of the limitation.
Signed-off-by: Rene Scharfe
---
sha1_file.c | 41 +++--
1 file changed, 15 insertions
Am 28.06.2014 08:01, schrieb Matthieu Moy:
> Karsten Blees writes:
>
>> I still don't like that the invalidation is done in git_config_set, though,
>> as
>> this is also used to write completely unrelated files.
>
> I don't get it. It is used to write the config files. Yes, we trigger a
> compl
We should not die when reading the submodule config cache since the user
might not be able to get out of that situation when the configuration is
part of the history.
We should handle this condition later when the value is about to be
used.
Signed-off-by: Heiko Voigt
---
builtin/fetch.c
We remove the extracted functions and directly parse into and read out
of the cache. This allows us to have one unified way of accessing
submodule configuration values specific to single submodules. Regardless
whether we need to access a configuration from history or from the
worktree.
Signed-off-
This is one step towards using the new configuration API. We just
extract these functions to make replacing the actual code easier.
Signed-off-by: Heiko Voigt
---
submodule.c | 142 +---
1 file changed, 97 insertions(+), 45 deletions(-)
di
This submodule configuration cache allows us to lazily read .gitmodules
configurations by commit into a runtime cache which can then be used to
easily lookup values from it. Currently only the values for path or name
are stored but it can be extended for any value needed.
It is expected that .gitm
Here another iteration with all the comments incorporated:
* Dropped the hashmap enum parameter patch
* Renamed the test to t7411
* Compilation fixes and style
Gmane seems offline for me, so I can not check but this should be the last
iteration:
http://mid.gmane.org/20140605060425.GA23874@
> -Original Message-
> From: Jason Pyeron
> Sent: Friday, June 27, 2014 20:42
> To: 'git'
> Cc: 'Phil Hord'
> Subject: RE: Trouble merging renamed but identical files -
> CONFLICT (rename/rename)
>
> > -Original Message-
> > From: Jason Pyeron
> > Sent: Friday, June 27, 2014 18:3
34 matches
Mail list logo
