Karsten Blees karsten.bl...@gmail.com 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
complete reload instead of just changing
Thank-you all for replying,
It's just as Jason suggests - Genbank, FASTA EMBL are more or less
the defacto standards, I suspect FASTA will be phased out because (to
my knowledge) it does not support gene annotation, nevertheless, they
are all text based.
These formats usually insert linebreaks
-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:39
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:
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
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 hvo...@hvoigt.net
---
submodule.c | 142 +---
1 file changed, 97 insertions(+),
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.
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 hvo...@hvoigt.net
---
Am 28.06.2014 08:01, schrieb Matthieu Moy:
Karsten Blees karsten.bl...@gmail.com 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
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 l@web.de
---
sha1_file.c | 41 +++--
1 file changed,
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 l@web.de
---
The usage string for this option is:
git replace [-f] --graft commit [parent...]
First we create a new commit that is the same as commit
except that its parents are [parents...]
Then we create a replace ref that replace commit with
the commit we just created.
With this new option, it should be
Signed-off-by: Christian Couder chrisc...@tuxfamily.org
Signed-off-by: Junio C Hamano gits...@pobox.com
---
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
+++
Here is a small patch series to implement:
git replace [-f] --graft commit [parent...]
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
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
Signed-off-by: Christian Couder chrisc...@tuxfamily.org
Signed-off-by: Junio C Hamano gits...@pobox.com
---
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
---
Signed-off-by: Christian Couder chrisc...@tuxfamily.org
---
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 @@
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
Signed-off-by: Christian Couder chrisc...@tuxfamily.org
---
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
+++
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. Probably
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
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.
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
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
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. Probably
On Fri, Jun 27, 2014 at 5:02 AM, Junio C Hamano gits...@pobox.com 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
-
On Fri, Jun 27, 2014 at 1:09 AM, Junio C Hamano gits...@pobox.com wrote:
Nguyễn Thái Ngọc Duy pclo...@gmail.com 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,
On Sat, Jun 28, 2014 at 1:56 AM, Thomas Braun
thomas.br...@virtuell-zuhause.de 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
On Sat, Jun 28, 2014 at 9:47 PM, René Scharfe l@web.de 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 7:20 AM, David Turner dtur...@twopensource.com 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 dtur...@twitter.com
---
builtin/checkout.c| 4
cache-tree.c
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 pclo...@gmail.com
Signed-off-by: Rene Scharfe l@web.de
---
@Duy: Thanks for catching the missing
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 l@web.de
---
No
32 matches
Mail list logo
