Re: bug report

git version 2.6.4 (Apple Git-63) system version: OS X EI Capitan 10.11.4 below is the steps: $ mkdir test_repo $ cd test_repo $ git init $ echo "hello" > README.md $ git commit -a -m 'Add README.md' $ git checkout -b A $ echo "world" > README.md $ git commit -a -m 'Add one line' $ git checkout

Re: [PATCH 4/4] pathspec: record labels

On Thu, May 12, 2016 at 10:26 PM, Junio C Hamano wrote: > Stefan Beller writes: > >> + >> +label:;; >> + Labels can be assigned to pathspecs in the .gitattributes file. >> + By specifying a list of labels the pattern will match only >> + files

Re: [PATCH 4/4] pathspec: record labels

On Thu, May 12, 2016 at 9:32 PM, Junio C Hamano wrote: > Stefan Beller writes: > >> diff --git a/Documentation/glossary-content.txt >> b/Documentation/glossary-content.txt >> index 8ad29e6..a1fc9e0 100644 >> --- a/Documentation/glossary-content.txt >> +++

Re: [PATCH 4/4] pathspec: record labels

Stefan Beller writes: > + > +label:;; > + Labels can be assigned to pathspecs in the .gitattributes file. > + By specifying a list of labels the pattern will match only > + files which have all of the listed labels. > + Attributes are given to paths, not

Re: bug report

Please mention the version no of git you are using and your system. I am answering according to git 2.8.1 Lubuntu 15.04 On Fri, May 13, 2016 at 10:34 AM, 李本超 wrote: > Hi all, > > Yestoday when I worked using Git, I found a bug. It's about > rebase. Or I don't know if

bug report

Hi all, Yestoday when I worked using Git, I found a bug. It's about rebase. Or I don't know if it is a bug, maybe that is Git. Below is my problem: There is a master branch, and we develop in our own branch. Let's simplify this: there are two branches created at the same commit point

Re: [PATCH 3/4] pathspec: move prefix check out of the inner loop

Stefan Beller writes: > The prefix check is not related the check of pathspec magic; also there > is no code that is relevant after we'd break the loop on a match for > "prefix:". So move the check before the loop and shortcircuit the outer > loop. > > Signed-off-by: Stefan

Re: [PATCH 4/4] pathspec: record labels

Stefan Beller writes: > diff --git a/Documentation/glossary-content.txt > b/Documentation/glossary-content.txt > index 8ad29e6..a1fc9e0 100644 > --- a/Documentation/glossary-content.txt > +++ b/Documentation/glossary-content.txt > @@ -362,6 +362,11 @@ glob;; > For

[PATCH] Documentation: fix a typo

Signed-off-by: Stefan Beller --- Documentation/gitattributes.txt | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/Documentation/gitattributes.txt b/Documentation/gitattributes.txt index e3b1de8..af2c682 100644 --- a/Documentation/gitattributes.txt +++

[RFC PATCH 0/4] pathspec labels [WAS: submodule groups]

After some fruitful discussion[1] in which Junio suggested trying a very different route[2] that is more general and not submodule related, I considered doing a mock for this. This lets you label arbitrary pathspecs, e.g. in git.git we may want to have: t/t[0-9]*.sh label=tests such

[PATCH 4/4] pathspec: record labels

Labels were originally designed to manage large amount of submodules, the discussion steered this in a more general direction, such that other files can be labeled as well. Labels are meant to describe arbitrary set of files, which is not described via the tree layout. Signed-off-by: Stefan

[PATCH 1/4] Documentation: correct typo in example for querying attributes

The introductory text of the example has a typo in the specification which makes it harder to follow that example. Signed-off-by: Stefan Beller --- Documentation/technical/api-gitattributes.txt | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git

[PATCH 3/4] pathspec: move prefix check out of the inner loop

The prefix check is not related the check of pathspec magic; also there is no code that is relevant after we'd break the loop on a match for "prefix:". So move the check before the loop and shortcircuit the outer loop. Signed-off-by: Stefan Beller --- pathspec.c | 19

[PATCH 2/4] pathspec: move long magic parsing out of prefix_pathspec

`prefix_pathspec` is quite a lengthy function and we plan on adding more. Split it up for better readability. As we want to add code into the inner loop of the long magic parsing, we also benefit from lower indentation. Signed-off-by: Stefan Beller --- pathspec.c | 84

Re: [PATCH] i18n: unpack-trees: avoid substituting only a verb in sentences

Junio C Hamano writes: > Thanks. I think we should squash the following in, as all these > messages are now i18ned and without being marked with test_i18ncmp, > GETTEXT_POISON build would fail to pass these tests. ... this was not a request for you to re-send your patch with

Re: [PATCH] i18n: unpack-trees: avoid substituting only a verb in sentences

Vasco Almeida writes: > Instead of reusing the same set of message templates for checkout > and other actions and substituting the verb with "%s", prepare > separate message templates for each known action. That would make > it easier for translation into languages where

[PATCH] i18n: unpack-trees: avoid substituting only a verb in sentences

Instead of reusing the same set of message templates for checkout and other actions and substituting the verb with "%s", prepare separate message templates for each known action. That would make it easier for translation into languages where the same verb may conjugate differently depending on the

Re: [PATCH v10 11/20] index-helper: use watchman to avoid refreshing index with lstat()

On 12/05/16 21:20, David Turner wrote: > From: Nguyễn Thái Ngọc Duy [snip] > > +/* in ms */ > +#define WATCHMAN_TIMEOUT 1000 > + > +static int poke_and_wait_for_reply(int fd) > +{ > + struct strbuf buf = STRBUF_INIT; > + int ret = -1; > + struct pollfd pollfd;

Re: [PATCH v4 2/7] i18n: unpack-trees: mark strings for translation

I think this patch is better than what is already in 'next', so let me see if I can make it into an incremental update. We'd need your sign-off, of course. -- >8 -- Subject: i18n: unpack-trees: avoid substituting only a verb in sentences Instead of reusing the same set of message templates for

Re: [PATCH v6 2/3] bisect: rewrite `check_term_format` shell function in C

Pranit Bauva writes: > + /* > + * In theory, nothing prevents swapping completely good and bad, > + * but this situation could be confusing and hasn't been tested > + * enough. Forbid it for now. > + */ > + > + if ((strcmp(orig_term, "bad") &&

Re: [Bug?] log -p -W showing the whole file for a patch that adds to the end?

Am 11.05.2016 um 00:51 schrieb Junio C Hamano: The helper function get_func_line() however gets confused when a hunk adds a new function at the very end, and returns -1 to signal that it did not find a suitable "function header line", i.e. the beginning of previous function. The caller then

Re: [PATCH] Documentation: correct typo in example

Stefan Beller writes: > The example want's to explain how 'To see how attributes "crlf" and > "indent" are set for different paths.' > > Spell the selected attribute correctly. > > Signed-off-by: Stefan Beller > --- >

git svn clone cannot go beyond a specific rev on codeplex

I tried bin-wrappers/ from current git HEAD. $ git describe v2.8.2-396-g5fe494c bin-wrappers/git svn clone https://ironpython.svn.codeplex.com/svn ironpython-old-codeplex always fails at this rev: M Src/Tests/test_re.py r7605 = e581bc66eda2b86bf46681191034844c4ba7d7a5

[PATCH] Documentation: correct typo in example

The example want's to explain how 'To see how attributes "crlf" and "indent" are set for different paths.' Spell the selected attribute correctly. Signed-off-by: Stefan Beller --- Documentation/technical/api-gitattributes.txt | 2 +- 1 file changed, 1 insertion(+), 1

Re: [PATCH v2 22/94] builtin/apply: move 'threeway' global into 'struct apply_state'

Christian Couder writes: > Ok, I will try to group knobs like that, but the comments tend to > break the groups. By keeping the comment on a single field short, and reserve comment occupying its own line(s) to comment on group, you can do /* These control

Re: proposal for extending smudge/clean filters with raw file access

Junio C Hamano wrote: > > Secondly, and harder to get around, the filename passed to the clean > > filter is not necessarily a path to the actual existing file that is > > being cleaned. > > Either one of us is confused. I was talking about updating the > current "clean" implementation without

Re: [PATCH v10 03/20] pkt-line: add gentle version of packet_write

David Turner writes: > packet_write calls write_or_die, which dies with a sigpipe even if > calling code has explicitly blocked that signal. > > Add packet_write_gently and packet_flush_gently, which don't. Soon, > we will use this for communication with git

Re: [PATCH v4 0/7] i18n miscellaneous updates

Vasco Almeida writes: > This re-roll upadates patch > i18n: unpack-trees: mark strings for translation Sorry, unfortunately you cannot take them back anymore. These from the previous round are already in 'next'. daf9f64 i18n: builtin/pull.c: split strings marked

Re: [PATCH v4 6/7] i18n: builtin/rm.c: remove a comma ',' from string

Vasco Almeida writes: > Remove a comma from string marked for translation. Make the string match the > one in builtin/mv.c. Now translators have do handle this string only once. > > Signed-off-by: Vasco Almeida > --- Looks good. BTW, I think you

Re: proposal for extending smudge/clean filters with raw file access

Junio C Hamano wrote: > The smudge happens to be the last to run, so it is quite true that > it can say "Hey Git, I've written it out already". > > I didn't check all codepaths to ensure that we won't need the > smudged result in core at all, but I am guessing you did so before > making this

Re: proposal for extending smudge/clean filters with raw file access

Joey Hess writes: > Junio C Hamano wrote: >> This side, I do not think we even need a new variant. We can just >> update the code to interact with "clean" so that it the writer to >> the pipe ignores SIGPIPE, detects EPIPE on write(2), says "ah, the >> other end does not need

Re: proposal for extending smudge/clean filters with raw file access

Junio C Hamano wrote: > This side, I do not think we even need a new variant. We can just > update the code to interact with "clean" so that it the writer to > the pipe ignores SIGPIPE, detects EPIPE on write(2), says "ah, the > other end does not need the full input to produce its output". The

Re: [PATCH v2 48/94] builtin/apply: rename 'prefix_' parameter to 'prefix'

Junio C Hamano writes: > Up to this point, the conversion looks quite sensible, even though I > think the organization of fields in apply_state do not look logical. I'd stop here for now, as everything before this step looks uncontroversial. Anybody whose tasked to move the

[PATCH v10 16/20] index-helper: don't run if already running

Signed-off-by: David Turner --- index-helper.c | 7 +++ t/t7900-index-helper.sh | 9 + 2 files changed, 16 insertions(+) diff --git a/index-helper.c b/index-helper.c index a1b33e4..7b893a0 100644 --- a/index-helper.c +++ b/index-helper.c @@ -435,6

[PATCH v10 04/20] index-helper: new daemon for caching index and related stuff

From: Nguyễn Thái Ngọc Duy Instead of reading the index from disk and worrying about disk corruption, the index is cached in memory (memory bit-flips happen too, but hopefully less often). The result is faster read. Read time is reduced by 70%. The biggest gain is not having

[PATCH v10 12/20] update-index: enable/disable watchman support

From: Nguyễn Thái Ngọc Duy Signed-off-by: Nguyễn Thái Ngọc Duy Signed-off-by: David Turner --- Documentation/git-index-helper.txt | 3 +++ Documentation/git-update-index.txt | 6 ++ builtin/update-index.c | 16

[PATCH v10 01/20] read-cache.c: fix constness of verify_hdr()

From: Nguyễn Thái Ngọc Duy Signed-off-by: Nguyễn Thái Ngọc Duy Signed-off-by: David Turner --- read-cache.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/read-cache.c b/read-cache.c index d9fb78b..16cc487

[PATCH v10 08/20] index-helper: log warnings

Instead of writing warnings to stderr, write them to a log. Later, we'll probably be daemonized, so writing to stderr will be pointless. Signed-off-by: David Turner --- Documentation/git-index-helper.txt | 3 +++ index-helper.c | 12 +++-

[PATCH v10 00/20] index-helper/watchman

packet_write was causing the sigpipes (by calling write_or_die, which intentionally overrides the caller's preferences about signal handling). This version fixes that. I didn't test on a virtual machine, but I did test by adding a sleep(). David Turner (9): pkt-line: add gentle version of

[PATCH v10 17/20] index-helper: autorun mode

Soon, we'll want to automatically start index-helper, so we need a mode that silently exits if it can't start up (either because it's not in a git dir, or because another one is already running). Signed-off-by: David Turner --- Documentation/git-index-helper.txt | 4

[PATCH v10 13/20] unpack-trees: preserve index extensions

Make git checkout (and other unpack_tree operations) preserve the untracked cache and watchman status. This is valuable for two reasons: 1. Often, an unpack_tree operation will not touch large parts of the working tree, and thus most of the untracked cache will continue to be valid. 2. Even if

[PATCH v10 19/20] trace: measure where the time is spent in the index-heavy operations

From: Nguyễn Thái Ngọc Duy All the known heavy code blocks are measured (except object database access). This should help identify if an optimization is effective or not. An unoptimized git-status would give something like below (92% of time is accounted). To sum up the effort

[PATCH v10 14/20] watchman: add a config option to enable the extension

For installations that have centrally-managed configuration, it's easier to set a config once than to run update-index on every repository. Signed-off-by: David Turner --- .gitignore| 1 + Documentation/config.txt | 4 Makefile

[PATCH v10 06/20] daemonize(): set a flag before exiting the main process

From: Nguyễn Thái Ngọc Duy This allows signal handlers and atexit functions to realize this situation and not clean up. Signed-off-by: Nguyễn Thái Ngọc Duy Signed-off-by: David Turner --- builtin/gc.c | 2 +- cache.h | 2 +-

[PATCH v10 07/20] index-helper: add --detach

From: Nguyễn Thái Ngọc Duy We detach after creating and opening the socket, because otherwise we might return control to the shell before index-helper is ready to accept commands. This might lead to flaky tests. Signed-off-by: Nguyễn Thái Ngọc Duy

[PATCH v10 20/20] untracked-cache: config option

Add a config option to populate the untracked cache. For installations that have centrally-managed configuration, it's easier to set a config once than to run update-index on every repository. Signed-off-by: David Turner --- Documentation/config.txt | 4

[PATCH v10 05/20] index-helper: add --strict

From: Nguyễn Thái Ngọc Duy There are "holes" in the index-helper approach because the shared memory is not verified again by git. If $USER is compromised, shared memory could be modified. But anyone who could do this could already modify $GIT_DIR/index. A more realistic risk

[PATCH v10 18/20] index-helper: optionally automatically run

Introduce a new config option, indexhelper.autorun, to automatically run git index-helper before starting up a builtin git command. This enables users to keep index-helper running without manual intervention. Signed-off-by: David Turner --- Documentation/config.txt |

[PATCH v10 11/20] index-helper: use watchman to avoid refreshing index with lstat()

From: Nguyễn Thái Ngọc Duy Watchman is hidden behind index-helper. Before git tries to read the index from shm, it notifies index-helper through the socket and waits for index-helper to prepare a file for sharing memory (with MAP_SHARED). index-helper then contacts watchman,

[PATCH v10 03/20] pkt-line: add gentle version of packet_write

packet_write calls write_or_die, which dies with a sigpipe even if calling code has explicitly blocked that signal. Add packet_write_gently and packet_flush_gently, which don't. Soon, we will use this for communication with git index-helper, which, being merely an optimization, should be

[PATCH v10 15/20] index-helper: kill mode

Add a new command (and command-line arg) to allow index-helpers to exit cleanly. This is mainly useful for tests. Signed-off-by: David Turner --- Documentation/git-index-helper.txt | 3 +++ index-helper.c | 31 ++-

[PATCH v10 10/20] watchman: support watchman to reduce index refresh cost

From: Nguyễn Thái Ngọc Duy The previous patch has the logic to clear bits in 'WAMA' bitmap. This patch has logic to set bits as told by watchman. The missing bit, _using_ these bits, are not here yet. A lot of this code is written by David Turner originally, mostly from [1].

[PATCH v10 09/20] read-cache: add watchman 'WAMA' extension

From: Nguyễn Thái Ngọc Duy The extension contains a bitmap, one bit for each entry in the index. If the n-th bit is zero, the n-th entry is considered unchanged, we can ce_mark_uptodate() it without refreshing. If the bit is non-zero and we found out the corresponding file is

[PATCH v10 02/20] read-cache: allow to keep mmap'd memory after reading

From: Nguyễn Thái Ngọc Duy Later, we will introduce git index-helper to share this memory with other git processes. We only unmap it when we discard the index (although the kernel may of course choose to page it out). Signed-off-by: Nguyễn Thái Ngọc Duy

Re: [PATCH v2 22/94] builtin/apply: move 'threeway' global into 'struct apply_state'

On Thu, May 12, 2016 at 9:41 PM, Junio C Hamano wrote: > Christian Couder writes: > >> To libify the apply functionality the 'threeway' variable should >> not be static and global to the file. Let's move it into >> 'struct apply_state'. >> >>

Re: [PATCH v2 10/94] builtin/apply: move 'unidiff_zero' global into 'struct apply_state'

On Thu, May 12, 2016 at 9:28 PM, Junio C Hamano wrote: > Christian Couder writes: > >> To libify the apply functionality the 'unidiff_zero' variable should >> not be static and global to the file. Let's move it into >> 'struct apply_state'. >> >>

Re: proposal for extending smudge/clean filters with raw file access

Joey Hess writes: > The clean filter has to consume the whole file content on stdin; > not reading it all will make git think the clean filter failed. > But, git-annex often doesn't need to read the whole content of a > work-tree file in order to clean it. This side, I do not

Re: [PATCH v2 00/94] libify apply and use lib in am

On Thu, May 12, 2016 at 9:04 PM, Junio C Hamano wrote: > > As Christian said in 00/94, this probably needs to go in steps, as I > do not think anybody wants to review fouteen rounds of 90+ patch > series. I thought the early 40+ patches in the series were at least > cursory

[PATCH v4 6/7] i18n: builtin/rm.c: remove a comma ',' from string

Remove a comma from string marked for translation. Make the string match the one in builtin/mv.c. Now translators have do handle this string only once. Signed-off-by: Vasco Almeida --- builtin/rm.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git

[PATCH v4 4/7] i18n: builtin/pull.c: mark placeholders for translation

Some translations might also translate "" and "". Signed-off-by: Vasco Almeida --- builtin/pull.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/builtin/pull.c b/builtin/pull.c index 596b92f..96b98ea 100644 --- a/builtin/pull.c +++

[PATCH v4 5/7] i18n: builtin/pull.c: split strings marked for translation

Split string "If you wish to set tracking information for this branch you can do so with:\n" to match occurring string in git-parse-remote.sh. In this case, the translator handles it only once. On the other hand, the translations of the string that were already made are mark as fuzzy and the

[PATCH v4 7/7] i18n: builtin/branch.c: mark option for translation

Mark description and parameter for option "set-upstream-to" for translation. Signed-off-by: Vasco Almeida --- builtin/branch.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/builtin/branch.c b/builtin/branch.c index 0adba62..b7d906d 100644 ---

[PATCH v4 1/7] i18n: index-pack: use plural string instead of normal one

Git could output "completed with 1 local objects", but in this case using "object" instead of "objects" is the correct form. Use Q_() instead of _(). Signed-off-by: Vasco Almeida --- builtin/index-pack.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git

[PATCH v4 2/7] i18n: unpack-trees: mark strings for translation

Mark strings seen by the user inside setup_unpack_trees_porcelain() and display_error_msgs() functions for translation. Signed-off-by: Vasco Almeida --- unpack-trees.c | 74 ++ 1 file changed, 54 insertions(+), 20

[PATCH v4 3/7] i18n: git-parse-remote.sh: mark strings for translation

Change Makefile to include git-parse-remote.sh in LOCALIZED_SH. TODO: remove 3rd argument of error_on_missing_default_upstream function that is no longer required. Signed-off-by: Vasco Almeida --- Makefile| 2 +- git-parse-remote.sh | 46

[PATCH v4 0/7] i18n miscellaneous updates

This re-roll upadates patch i18n: unpack-trees: mark strings for translation I have decoupled/untangled some strings to mark entire sentences instead of assemble them using placeholders "%s". This makes the translation work easier and more reliable. Vasco Almeida (7): i18n: index-pack: use

Re: [PATCH v2 48/94] builtin/apply: rename 'prefix_' parameter to 'prefix'

Christian Couder writes: > This is just a small cleanup. ... which may have been better happened at 09/94. Up to this point, the conversion looks quite sensible, even though I think the organization of fields in apply_state do not look logical. -- To unsubscribe

Re: [PATCH v2 40/94] builtin/apply: move 'ws_error_action' into 'struct apply_state'

Christian Couder writes: > struct apply_state { > const char *prefix; > int prefix_length; > @@ -71,6 +78,8 @@ struct apply_state { > int whitespace_error; > int squelch_whitespace_errors; > int applied_after_fixing_ws; > + > + enum

Re: [PATCH v2 33/94] builtin/apply: move 'p_value_known' global into 'struct apply_state'

Christian Couder writes: > To libify the apply functionality the 'p_value_known' variable should > not be static and global to the file. Let's move it into > 'struct apply_state'. This and p_value belong together, I would think, so this can be squashed with 32/94 if

Re: [PATCH v2 22/94] builtin/apply: move 'threeway' global into 'struct apply_state'

Christian Couder writes: > To libify the apply functionality the 'threeway' variable should > not be static and global to the file. Let's move it into > 'struct apply_state'. > > Reviewed-by: Stefan Beller > Signed-off-by: Christian Couder

Re: [PATCH v2 18/94] builtin/apply: move 'cached' global into 'struct apply_state'

Christian Couder writes: > To libify the apply functionality the 'cached' variable should > not be static and global to the file. Let's move it into > 'struct apply_state'. > > Reviewed-by: Stefan Beller > Signed-off-by: Christian Couder

Re: [PATCH v2 10/94] builtin/apply: move 'unidiff_zero' global into 'struct apply_state'

Christian Couder writes: > To libify the apply functionality the 'unidiff_zero' variable should > not be static and global to the file. Let's move it into > 'struct apply_state'. > > Reviewed-by: Stefan Beller > Signed-off-by: Christian Couder

Re: [PATCH v2 16/94] builtin/apply: move 'update_index' global into 'struct apply_state'

Christian Couder writes: > To libify the apply functionality the 'update_index' variable should > not be static and global to the file. Let's move it into > 'struct apply_state'. > > Reviewed-by: Stefan Beller > Signed-off-by: Christian Couder

Re: [PATCH v2 09/94] builtin/apply: move 'state' init into init_apply_state()

Christian Couder writes: > When the apply functionality will be libified, the 'struct apply_state' > will be used by different pieces of code. > > To properly initialize a 'struct apply_state', let's provide a nice > and easy to use init_apply_state() function. This

Re: [PATCH v2 05/94] builtin/apply: extract line_by_line_fuzzy_match() from match_fragment()

Christian Couder writes: > The match_fragment() function is very big and contains a big special case > algorithm that does line by line fuzzy matching. So let's extract this > algorithm in a separate line_by_line_fuzzy_match() function. > > Reviewed-by: Stefan Beller

Re: [PATCH v2 03/94] builtin/apply: avoid parameter shadowing 'linenr' global

Christian Couder writes: > Let's just rename the global 'state_linenr' as it will become > 'state->linenr' in a following patch. > > This also avoid errors when compiling with -Wshadow and makes > it safer to later move global variables into a "state" struct. Looks

Re: [PATCH v2 02/94] builtin/apply: avoid parameter shadowing 'p_value' global

Christian Couder writes: > Let's just rename the global 'state_p_value' as it will become > 'state->p_value' in a following patch. > > This also avoid errors when compiling with -Wshadow and makes > it safer to later move global variables into a "state" struct. Looks

Re: [PATCH v2 01/94] builtin/apply: make gitdiff_verify_name() return void

Christian Couder writes: > As the value returned by gitdiff_verify_name() is put into the > same variable that is passed as a parameter to this function, > it is simpler to pass the address of the variable and have > gitdiff_verify_name() change the variable itself. >

Re: [PATCH v2 00/94] libify apply and use lib in am

Johannes Sixt writes: > I'll also use it in production for a while, although I am not a git-am > consumer nor do I use git-rebase without -i, hence, my tests will > probably only show that there is no bad fall-out. It will probably only show that you do not use the part that was

Re: proposal for extending smudge/clean filters with raw file access

Joey Hess writes: > I'm using smudge/clean filters in git-annex now, and it's not been an > entirely smooth fit between the interface and what git-annex wants > to do. > > The clean filter has to consume the whole file content on stdin; > not reading it all will make git think

proposal for extending smudge/clean filters with raw file access

I'm using smudge/clean filters in git-annex now, and it's not been an entirely smooth fit between the interface and what git-annex wants to do. The clean filter has to consume the whole file content on stdin; not reading it all will make git think the clean filter failed. But, git-annex often

Re: t0008 test fails with ksh

On Thu, May 12, 2016 at 07:53:28PM +0200, Armin Kunaschik wrote: > The reason seems that the snippet > cat <<-EOF >expected-all > .gitignore:1:one../one > :: ../not-ignored > .gitignore:1:oneone > :: not-ignored >

Re: [PATCH v2 00/94] libify apply and use lib in am

On Thu, May 12, 2016 at 7:06 PM, Johannes Sixt wrote: > Am 11.05.2016 um 15:16 schrieb Christian Couder: >> >> This is a patch series about libifying `git apply` functionality, and >> using this libified functionality in `git am`, so that no 'git apply' >> process is spawn anymore.

t0008 test fails with ksh

Hello, in t0008 I see tests fails with not ok 374 - --stdin -v # # expect_from_stdin expected-all .gitignore:1:one../one :: ../not-ignored .gitignore:1:oneone :: not-ignored a/b/.gitignore:8:!on* b/on

Re: [PATCH] Documentation: clarify signature verification v2

On Thu, May 12, 2016 at 10:08 PM, Junio C Hamano wrote: > Pranit Bauva writes: > >> Seems like Junio was waiting for someone to point this out[2]. > > Thanks. I think you covered most of them correctly; I only have one > thing to add. > >> * Comments

Re: [PATCH v2 00/94] libify apply and use lib in am

Am 11.05.2016 um 15:16 schrieb Christian Couder: This is a patch series about libifying `git apply` functionality, and using this libified functionality in `git am`, so that no 'git apply' process is spawn anymore. This makes `git am` significantly faster, so `git rebase`, when it uses the am

Re: [PATCH 0/7] submodule groups

Stefan Beller writes: > We can still keep the submodule.defaultGroup. (In the WIP I renamed > it to updateGroup as its only feature is to have it set during clone > and remebered for `git submodule update`) Yes, my idle speculation between "[submodule"x"] label=A" stored in

Re: [PATCH] Documentation: clarify signature verification v2

Pranit Bauva writes: > Seems like Junio was waiting for someone to point this out[2]. Thanks. I think you covered most of them correctly; I only have one thing to add. > * Comments are put after ---. So your paragraph > "Clarify which commits need to be signed. >

Re: [PATCH 0/7] submodule groups

On Thu, May 12, 2016 at 8:58 AM, Junio C Hamano wrote: > Junio C Hamano writes: > >> The reason why I suspect that this may not work well with submodule >> labels is because submodule labels (or any attribute we give via >> .gitmodules to a submodule) are

Re: [PATCH v2 0/2] Work on t3404 in preparation for rebase--helper

I took these separately already, and plan to fast-track them as they are both "trivially correct"; I double checked that what I have match these two, too. Thanks. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More

Re: [PATCH v2 00/33] Yet more preparation for reference backends

Jeff King writes: > My trick for checking the before/after of a patch is: > > 1. Compile git without the patch. > > 2. Apply the patch, then run the test (via ./t1234-*, which does not > want to re-build git), confirm that it fails. > > 3. Re-compile and re-run the

Re: [PATCH 2/2] am: plug FILE * leak in split_mail_conv()

Jeff King writes: > Presumably `fclose` doesn't ever overwrite errno in practice, but I > guess it could in theory. Yeah, these two patches share the same issue. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to

[PATCH v2 2/2] test-lib: set BASH_XTRACEFD automatically

From: Jeff King Passing "-x" to a test script enables the shell's "set -x" tracing, which can help with tracking down the command that is causing a failure. Unfortunately, it can also _cause_ failures in some tests that redirect the stderr of a shell function. Inside the function

[PATCH v2 0/2] Work on t3404 in preparation for rebase--helper

This is the first patch series in preparation for a faster interactive rebase. It actually only prepares the test script that I mainly used to develop the rebase--helper, and the resilience against running with -x proved to be invaluable in keeping my sanity. Jeff King (1): test-lib: set

[PATCH v2 1/2] t3404: fix typo

Signed-off-by: Johannes Schindelin --- t/t3404-rebase-interactive.sh | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/t/t3404-rebase-interactive.sh b/t/t3404-rebase-interactive.sh index d96d0e4..66348f1 100755 --- a/t/t3404-rebase-interactive.sh +++

Re: [PATCH 0/7] submodule groups

Junio C Hamano writes: > The reason why I suspect that this may not work well with submodule > labels is because submodule labels (or any attribute we give via > .gitmodules to a submodule) are keyed by a submodule name, which is > the primary unchanging key (so that people

Re: [PATCH v2] test-lib: set BASH_XTRACEFD automatically

Hi Peff, On Wed, 11 May 2016, Jeff King wrote: > Subject: test-lib: set BASH_XTRACEFD automatically I confirm that this simple weird trick obsoletes my painstakingly developed patch ;-) To make it easy for everybody involved, I'll just go ahead and send out the next iteration with your patch.

Re: [PATCH] diff: run arguments through precompose_argv

Alexander Rinass writes: > I will create a v2 patch until the weekend and send it to the mailing list. 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

Re: [PATCH 0/7] submodule groups

On Wed, May 11, 2016 at 10:50 PM, Junio C Hamano wrote: > > git cmd -- \*.perl \*.pl \*.pm > > I've often wondered if it would be a good idea to let attributes > file to specify "these paths form the group Perl" with something > like: > > *.pmgroup=perl >

URGENT RESPONSE NEEDED, PLEASE REPLY....

Dear Friend, Pardon me for not having the pleasure of knowing your mindset before making you this offer and it is utterly confidential and genuine by virtue of its nature I write to solicit your assistance in a funds transfer deal involving £15.2M.This fund has been stashed out of the excess

  1   2   >