Re: in case you want a use-case with lots of submodules

On Mon, Jun 19, 2017 at 1:20 PM, Yaroslav Halchenko wrote: > > On Mon, 19 Jun 2017, Stefan Beller wrote: > >> On Mon, Jun 19, 2017 at 8:59 AM, Yaroslav Halchenko >> wrote: >> > Hi All, > >> > On a recent trip I've listened to the git minutes podcast

[PATCH/RFC] Cleanup Documentation

Make following changes to the git-submodule documentation: * Remove redundancy * Remove unclear back reference * Use more appropriate word * Quote important word Suggestions-by: Stefan Beller Signed-off-by: Kaartic Sivaraam --- Currently

[PATCH 3/3] Add tests for the contextual initial status message

Also, fixed minor spacing issue Helped-by: Ævar Arnfjörð Bjarmason Helped-by: Junio C Hamano Signed-off-by: Kaartic Sivaraam --- t/t7508-status.sh | 32 +++- 1 file changed, 31 insertions(+), 1

[PATCH 2/3] Update test(s) that used old status message

The tests that checked for old status message have been updated to check for the new status message Signed-off-by: Kaartic Sivaraam --- t/t7501-commit.sh | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/t/t7501-commit.sh b/t/t7501-commit.sh

[PATCH 1/3] Contextually notify user about an initial commit

"git status" indicated "Initial commit" when HEAD points at an unborn branch. This message is shared with the commit log template "git commit" prepares for the user when creating a commit (i.e. "You are about to create the initial commit"), and is OK as long as the reader is aware of the nature

Re: [showing-off RFC/PATCH 26/26] diff.c: have a "machine parseable" move coloring

+ Ævar, who was not part of the email where I copied all recipients from for this series. On Mon, Jun 19, 2017 at 7:48 PM, Stefan Beller wrote: > Ævar asked for it, this is how you would do it. > (plus documentation, tests, CLI knobs, options) > > Signed-off-by: Stefan Beller

[PATCH 23/26] diff.c: color moved lines differently, plain mode

Add the 'plain' mode for move detection of code. This omits the checking for adjacent blocks, so it is not as useful. If you have a lot of the same blocks moved in the same patch, the 'Zebra' would end up slow as it is O(n^2) (n is number of same blocks). So this may be useful there and is

[PATCH 22/26] diff.c: color moved lines differently

When a patch consists mostly of moving blocks of code around, it can be quite tedious to ensure that the blocks are moved verbatim, and not undesirably modified in the move. To that end, color blocks that are moved within the same patch differently. For example (OM, del, add, and NM are different

[PATCH 13/26] diff.c: emit_diff_symbol learns about DIFF_SYMBOL_BINARY_FILES

Signed-off-by: Stefan Beller --- diff.c | 21 - 1 file changed, 16 insertions(+), 5 deletions(-) diff --git a/diff.c b/diff.c index 95f11ea86f..e56962b844 100644 --- a/diff.c +++ b/diff.c @@ -572,6 +572,7 @@ enum diff_symbol { DIFF_SYMBOL_WORDS,

[PATCH 01/26] diff.c: readability fix

We already have dereferenced 'p->two' into a local variable 'two'. Use that. Signed-off-by: Stefan Beller Signed-off-by: Junio C Hamano --- diff.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/diff.c b/diff.c index

[PATCH 16/26] diff.c: convert emit_binary_diff_body to use emit_diff_symbol

Signed-off-by: Stefan Beller --- diff.c | 66 +- 1 file changed, 49 insertions(+), 17 deletions(-) diff --git a/diff.c b/diff.c index 42a9020d95..e6ade5fde0 100644 --- a/diff.c +++ b/diff.c @@ -573,6 +573,11 @@

[PATCH 10/26] diff.c: emit_diff_symbol learns DIFF_SYMBOL_CONTEXT_INCOMPLETE

Signed-off-by: Stefan Beller --- diff.c | 10 -- 1 file changed, 8 insertions(+), 2 deletions(-) diff --git a/diff.c b/diff.c index 7096457c8a..e6029e8213 100644 --- a/diff.c +++ b/diff.c @@ -565,6 +565,7 @@ enum diff_symbol { DIFF_SYMBOL_CONTEXT_FRAGINFO,

[PATCH 09/26] diff.c: emit_diff_symbol learns DIFF_SYMBOL_WORDS{_PORCELAIN}

Signed-off-by: Stefan Beller --- diff.c | 42 ++ 1 file changed, 26 insertions(+), 16 deletions(-) diff --git a/diff.c b/diff.c index 42c9f48dc2..7096457c8a 100644 --- a/diff.c +++ b/diff.c @@ -567,6 +567,8 @@ enum diff_symbol {

[showing-off RFC/PATCH 26/26] diff.c: have a "machine parseable" move coloring

Ævar asked for it, this is how you would do it. (plus documentation, tests, CLI knobs, options) Signed-off-by: Stefan Beller --- diff.c | 15 +++ diff.h | 2 ++ 2 files changed, 13 insertions(+), 4 deletions(-) diff --git a/diff.c b/diff.c index

[PATCH 21/26] diff.c: buffer all output if asked to

Introduce a new option 'emitted_symbols' in the struct diff_options which controls whether all output is buffered up until all output is available. It is set internally in diff.c when necessary. We'll have a new struct 'emitted_string' in diff.c which will be used to buffer each line. The

[PATCH 05/26] diff.c: emit_diff_symbol learns DIFF_SYMBOL_CONTEXT_MARKER

Signed-off-by: Stefan Beller --- diff.c | 10 +- 1 file changed, 9 insertions(+), 1 deletion(-) diff --git a/diff.c b/diff.c index 89466018e5..3af07fa659 100644 --- a/diff.c +++ b/diff.c @@ -561,17 +561,24 @@ static void emit_line(struct diff_options *o, const char

[PATCH 20/26] diff.c: emit_diff_symbol learns about DIFF_SYMBOL_SUMMARY

Signed-off-by: Stefan Beller --- diff.c | 73 +++--- 1 file changed, 43 insertions(+), 30 deletions(-) diff --git a/diff.c b/diff.c index 18bfc4720b..f2f7a4da79 100644 --- a/diff.c +++ b/diff.c @@ -592,6 +592,7 @@

[PATCH 24/26] diff.c: add dimming to moved line detection

Any lines inside a moved block of code are not interesting. Boundaries of blocks are only interesting if they are next to another block of moved code. Signed-off-by: Stefan Beller --- color.h| 2 + diff.c | 139

[PATCH 03/26] diff.c: factor out diff_flush_patch_all_file_pairs

In a later patch we want to do more things before and after all filepairs are flushed. So factor flushing out all file pairs into its own function that the new code can be plugged in easily. Signed-off-by: Stefan Beller Signed-off-by: Junio C Hamano ---

[PATCH 11/26] diff.c: emit_diff_symbol learns DIFF_SYMBOL_FILEPAIR

Signed-off-by: Stefan Beller --- diff.c | 42 +- 1 file changed, 21 insertions(+), 21 deletions(-) diff --git a/diff.c b/diff.c index e6029e8213..7c56150b56 100644 --- a/diff.c +++ b/diff.c @@ -570,6 +570,7 @@ enum diff_symbol {

[PATCH 00/26] reroll of sb/diff-color-moved

This is a complete rewrite of the series. Highlights: * instead of buffering partial lines, we'll pretend all diff output follows a well defined grammar, and we emit symbols thereof. (The difference is mostly mental, though by this trick we reduce the memory footprint for storing one of

[PATCH 15/26] submodule.c: migrate diff output to use emit_diff_symbol

As the submodule process is no longer attached to the same stdout as the superprojects process, we need to pass coloring explicitly. Remove the colors from the function signatures, as all the coloring decisions will be made either inside the child process or the final emit_diff_symbol.

[PATCH 18/26] diff.c: convert word diffing to use emit_diff_symbol

The word diffing is not line oriented and would need some serious effort to be transformed into a line oriented approach, so just go with a symbol DIFF_SYMBOL_WORD_DIFF that is a partial line. Signed-off-by: Stefan Beller --- diff.c | 79

[PATCH 02/26] diff.c: move line ending check into emit_hunk_header

The emit_hunk_header() function is responsible for assembling a hunk header and calling emit_line() to send the hunk header to the output file. Its only caller fn_out_consume() needs to prepare for a case where the function emits an incomplete line and add the terminating LF. Instead make sure

[PATCH 17/26] diff.c: convert show_stats to use emit_diff_symbol

We call print_stat_summary from builtin/apply, so we still need the version with a file pointer, so introduce print_stat_summary_0 that uses emit_string machinery and keep print_stat_summary with the same arguments around. Signed-off-by: Stefan Beller --- diff.c | 118

[PATCH 25/26] diff: document the new --color-moved setting

Signed-off-by: Stefan Beller --- Documentation/config.txt | 12 ++-- Documentation/diff-options.txt | 27 +++ 2 files changed, 37 insertions(+), 2 deletions(-) diff --git a/Documentation/config.txt b/Documentation/config.txt index

[PATCH 04/26] diff.c: introduce emit_diff_symbol

Signed-off-by: Stefan Beller --- diff.c | 22 +++--- 1 file changed, 19 insertions(+), 3 deletions(-) diff --git a/diff.c b/diff.c index 2f9722b382..89466018e5 100644 --- a/diff.c +++ b/diff.c @@ -559,6 +559,24 @@ static void emit_line(struct diff_options *o,

[PATCH 14/26] diff.c: emit_diff_symbol learns DIFF_SYMBOL_REWRITE_DIFF

Signed-off-by: Stefan Beller --- diff.c | 35 +-- 1 file changed, 21 insertions(+), 14 deletions(-) diff --git a/diff.c b/diff.c index e56962b844..96ce53c5cf 100644 --- a/diff.c +++ b/diff.c @@ -573,6 +573,7 @@ enum diff_symbol {

[PATCH 12/26] diff.c: emit_diff_symbol learns DIFF_SYMBOL_HEADER

Signed-off-by: Stefan Beller --- diff.c | 28 1 file changed, 20 insertions(+), 8 deletions(-) diff --git a/diff.c b/diff.c index 7c56150b56..95f11ea86f 100644 --- a/diff.c +++ b/diff.c @@ -571,6 +571,7 @@ enum diff_symbol {

[PATCH 07/26] diff.c: emit_diff_symbol learns DIFF_SYMBOL_NO_LF_EOF

Signed-off-by: Stefan Beller --- diff.c | 19 +++ 1 file changed, 11 insertions(+), 8 deletions(-) diff --git a/diff.c b/diff.c index a1804a7785..28be3226c2 100644 --- a/diff.c +++ b/diff.c @@ -563,11 +563,13 @@ enum diff_symbol {

[PATCH 06/26] diff.c: emit_diff_symbol learns DIFF_SYMBOL_CONTEXT_FRAGINFO

Signed-off-by: Stefan Beller --- diff.c | 8 ++-- 1 file changed, 6 insertions(+), 2 deletions(-) diff --git a/diff.c b/diff.c index 3af07fa659..a1804a7785 100644 --- a/diff.c +++ b/diff.c @@ -562,6 +562,7 @@ static void emit_line(struct diff_options *o, const char

[PATCH 08/26] diff.c: migrate emit_line_checked to use emit_diff_symbol

Add a new flags field to emit_diff_symbol, that will be used by context lines for: * white space rules that are applicable (The first 12 bits) * how the rules are evaluated (actually this double encodes the sign of the line, but the code is easier to keep this way, bits 13,14,15) * if the line a

[PATCH 19/26] diff.c: emit_diff_symbol learns about DIFF_SYMBOL_STAT_SEP

Signed-off-by: Stefan Beller --- diff.c | 10 +++--- 1 file changed, 7 insertions(+), 3 deletions(-) diff --git a/diff.c b/diff.c index 5b46baa12a..18bfc4720b 100644 --- a/diff.c +++ b/diff.c @@ -591,6 +591,7 @@ enum diff_symbol {

Re: [PATCH v4 5/5] stash: implement builtin stash

On Sun, Jun 11, 2017 at 2:27 PM, Thomas Gummerer wrote: >> + >> +int cmd_stash(int argc, const char **argv, const char *prefix) >> +{ >> + int result = 0; >> + pid_t pid = getpid(); >> + >> + struct option options[] = { >> + OPT_END() >> + }; >> +

Re: [PATCH v5 08/10] rebase -i: skip unnecessary picks using the rebase--helper

On 19/06/17 05:45 AM, Johannes Schindelin wrote: > Hi Liam, > > On Sat, 17 Jun 2017, Liam Beguin wrote: > >> On 16/06/17 09:56 AM, Johannes Schindelin wrote: >> >>> On Thu, 15 Jun 2017, Liam Beguin wrote: >>> On 14/06/17 09:08 AM, Johannes Schindelin wrote: > diff --git a/sequencer.c

Re: [PATCH v4 5/5] stash: implement builtin stash

On Fri, Jun 16, 2017 at 3:47 PM, Junio C Hamano wrote: > Joel Teichroeb writes: >> +/* >> + * Untracked files are stored by themselves in a parentless commit, for >> + * ease of unpacking later. >> + */ >> +static int save_untracked(struct stash_info *info,

[PATCH v4 8/8] sha1_file: refactor has_sha1_file_with_flags

has_sha1_file_with_flags() implements many mechanisms in common with sha1_object_info_extended(). Make has_sha1_file_with_flags() a convenience function for sha1_object_info_extended() instead. Signed-off-by: Jonathan Tan --- builtin/fetch.c | 10 ++

[PATCH v4 6/8] sha1_file: improve sha1_object_info_extended

Improve sha1_object_info_extended() by supporting additional flags. This allows has_sha1_file_with_flags() to be modified to use sha1_object_info_extended() in a subsequent patch. Signed-off-by: Jonathan Tan --- cache.h | 4 sha1_file.c | 43

[PATCH v4 7/8] sha1_file: do not access pack if unneeded

Add an option to struct object_info to suppress population of additional information about a packed object if unneeded. This allows an optimization in which sha1_object_info_extended() does not even need to access the pack if no information besides provenance is requested. A subsequent patch will

[PATCH v4 4/8] sha1_file: move delta base cache code up

In a subsequent patch, packed_object_info() will be modified to use the delta base cache, so move the relevant code to before packed_object_info(). Signed-off-by: Jonathan Tan --- sha1_file.c | 220 ++-- 1 file

[PATCH v4 5/8] sha1_file: refactor read_object

read_object() and sha1_object_info_extended() both implement mechanisms such as object replacement, retrying the packed store after failing to find the object in the packed store then the loose store, and being able to mark a packed object as bad and then retrying the whole process. Consolidating

[PATCH v4 0/8] Improvements to sha1_file

Thanks, Peff and Junio for your comments. Here's an updated version and some replies to comments. > I also found this quite subtle. However, I don't think that > has_sha1_file() actually freshens. It's a bit confusing because > has_loose_object() reuses the check_and_freshen() function to do the

[PATCH v4 1/8] sha1_file: teach packed_object_info about typename

In commit 46f0344 ("sha1_file: support reading from a loose object of unknown type", 2015-05-06), "struct object_info" gained a "typename" field that could represent a type name from a loose object file, whether valid or invalid, as opposed to the existing "typep" which could only represent valid

[PATCH v4 2/8] sha1_file: rename LOOKUP_UNKNOWN_OBJECT

The LOOKUP_UNKNOWN_OBJECT flag was introduced in commit 46f0344 ("sha1_file: support reading from a loose object of unknown type", 2015-05-03) in order to support a feature in cat-file subsequently introduced in commit 39e4ae3 ("cat-file: teach cat-file a '--allow-unknown-type' option",

[PATCH v4 3/8] sha1_file: rename LOOKUP_REPLACE_OBJECT

The LOOKUP_REPLACE_OBJECT flag controls whether the lookup_replace_object() function is invoked by sha1_object_info_extended(), read_sha1_file_extended(), and lookup_replace_object_extended(), but it is not immediately clear which functions accept that flag. Therefore restrict this flag to only

Re: [GSoC] Update: Week 5

On 06/20, Andrew Ardill wrote: > On 20 June 2017 at 07:41, Prathamesh Chavan wrote: > > >But as communicating between child_process is still an issue > >and so there was no simple was to current carry out the > >porting. And hence, a hack was used instead. But

Re: [GSoC] Update: Week 5

On 20 June 2017 at 07:41, Prathamesh Chavan wrote: >But as communicating between child_process is still an issue >and so there was no simple was to current carry out the >porting. And hence, a hack was used instead. But after >discussing it, instead using the

Re: [PATCH] die routine: change recursion limit from 1 to 1024

On Mon, Jun 19, 2017 at 3:32 PM, Ævar Arnfjörð Bjarmason wrote: > > On Mon, Jun 19 2017, Stefan Beller jotted: > >>> Now, git-grep could make use of the pluggable error facility added in >>> commit c19a490e37 ("usage: allow pluggable die-recursion checks", >>> 2013-04-16). >> >>

Re: [PATCH] die routine: change recursion limit from 1 to 1024

On Mon, Jun 19 2017, Stefan Beller jotted: >> Now, git-grep could make use of the pluggable error facility added in >> commit c19a490e37 ("usage: allow pluggable die-recursion checks", >> 2013-04-16). > > I think we should do that instead (though I have not looked at the downsides > of this),

Re: Behavior of 'git fetch' for commit hashes

On Mon, 19 Jun 2017 10:49:36 -0700 Jonathan Tan wrote: > On Mon, 19 Jun 2017 12:09:28 + > wrote: > > > For version 2.13.3 Firstly, exactly which version of Git doesn't work? I'm assuming 2.13.1 (as written elsewhere in your e-mail),

Re: Git Strange behaviour with remote deleted branch

On Mon, 2017-06-19 at 23:33 +0200, Reda Lyazidi wrote: > with git I noticed when I removed a remote branch with git push origin > --delete > in my clone when I used git branch -a I don't the deleted branch > but my colleagues still see it. > > I tried with two clones in my PC, with the first

Re: [PATCH] die routine: change recursion limit from 1 to 1024

> Now, git-grep could make use of the pluggable error facility added in > commit c19a490e37 ("usage: allow pluggable die-recursion checks", > 2013-04-16). I think we should do that instead (though I have not looked at the downsides of this), because... > > So let's just set the recursion limit to

[PATCH] grep: fix erroneously copy/pasted variable in check/assert pattern

Fix an erroneously copy/pasted check for the pcre2_jit_stack variable to check pcre2_match_context instead. The former was already checked in the preceding "if" statement. This is a trivial and obvious error introduced in my commit 94da9193a6 ("grep: add support for PCRE v2", 2017-06-01). In

[PATCH] die routine: change recursion limit from 1 to 1024

Change the recursion limit for the default die routine from a *very* low 1 to 1024. This ensures that infinite recursions are broken, but doesn't lose error messages. The intent of the existing code, as explained in commit cd163d4b4e ("usage.c: detect recursion in die routines and bail out

[GSoC][PATCH 6/6] submodule: port submodule subcommand 'deinit' from shell to C

The same mechanism is used even for porting this submodule subcommand, as used in the ported subcommands till now. The function cmd_deinit in split up after porting into three functions: module_deinit, for_each_submodule_list and deinit_submodule. Mentored-by: Christian Couder

[GSoC][PATCH 2/6] submodule--helper: introduce get_submodule_displaypath and for_each_submodule_list

Functions get_submodule_displaypath and for_each_submodule_list for using them in the later patches, related to porting submodule subcommands from shell to C. These new functions are also used in ported submodule subcommand init Mentored-by: Christian Couder

[GSoC][PATCH 5/6] submodule: port submodule subcommand sync from shell to C

The mechanism used for porting the submodule subcommand 'sync' is similar to that of 'foreach', where we split the function cmd_sync from shell into three functions in C, module_sync, for_each_submodule_list and sync_submodule. print_default_remote is introduced as a submodule--helper subcommand

[GSoC][PATCH 4/6] submodule: port submodule subcommand status

The mechanism used for porting submodule subcommand 'status' is similar to that used for subcommand 'foreach'. The function cmd_status from git-submodule is ported to three functions in the builtin submodule--helper namely: module_status, for_each_submodule_list and status_submodule. print_status

[GSoC][PATCH 3/6] submodule: port set_name_rev from shell to C

Since later on we want to port submodule subcommand status, and since set_name_rev is part of cmd_status, hence this function is ported. It has been ported to function print_name_rev in C, which calls get_name_rev to get the revname, and after formatting it, print_name_rev prints it. And hence in

[GSoC][PATCH 1/6] dir: create function count_slashes

Similar functions exist in apply.c and builtin/show-branch.c for counting the number of slashes in a string. Also in the later patches, we introduce a third caller for the same. Hence, we unify it now by cleaning the existing functions and declaring a common function count_slashes in dir.h and

[GSoC] Update: Week 5

SUMMARY OF MY PROJECT: Git submodule subcommands are currently implemented by using shell script 'git-submodule.sh'. There are several reasons why we'll prefer not to use the shell script. My project intends to convert the subcommands into C code, thus making them builtins. This will increase

Git Strange behaviour with remote deleted branch

Hello, with git I noticed when I removed a remote branch with git push origin --delete in my clone when I used git branch -a I don't the deleted branch but my colleagues still see it. I tried with two clones in my PC, with the first one delete branch and the other still sees it despite git

Re: What's cooking in git.git (Jun 2017, #05; Mon, 19)

> > * sb/submodule-doc (2017-06-13) 1 commit > - submodules: overhaul documentation > > Doc update. > > Waiting for discussion to settle. Please hold back, this definitely needs another version. > * sb/diff-color-move (2017-06-01) 17 commits > - diff.c: color moved lines differently > ... >

Re: Better usability of stash refs

On Mon, Jun 19, 2017 at 03:32:54PM -0500, Robert Dailey wrote: > To drop a stash, I have to do this (example): > > $ git stash drop stash@{3} > > Using the full "stash@{N}" seems superfluous since the documentation > states it must be a stash in the first place. It would make more sense > (and

Re: Better usability of stash refs

Robert Dailey writes: > To drop a stash, I have to do this (example): > > $ git stash drop stash@{3} > > Using the full "stash@{N}" seems superfluous since the documentation > states it must be a stash in the first place. It would make more sense > (and be quicker to

Better usability of stash refs

To drop a stash, I have to do this (example): $ git stash drop stash@{3} Using the full "stash@{N}" seems superfluous since the documentation states it must be a stash in the first place. It would make more sense (and be quicker to type) to do: $ git stash drop 3 Is there a trick I can use to

Re: in case you want a use-case with lots of submodules

On Mon, 19 Jun 2017, Stefan Beller wrote: > On Mon, Jun 19, 2017 at 8:59 AM, Yaroslav Halchenko > wrote: > > Hi All, > > On a recent trip I've listened to the git minutes podcast episode and > > got excited to hear Stefan Beller (CCed just in case) describing > > ongoing

AW: Restoring detached HEADs after Git operations

Hello Stefan, I never have tapped into the DLL Hell trap. That's maybe I never did C++ development or I started with VB .NET / C# as .NET solved major parts of the DLL Hell :). That doesn't mean my new beloved language Python doesn't have a similar problem ... Thinking about DLL Hell is a

What's cooking in git.git (Jun 2017, #05; Mon, 19)

Here are the topics that have been cooking. Commits prefixed with '-' are only in 'pu' (proposed updates) while commits prefixed with '+' are in 'next'. The ones marked with '.' do not appear in any of the integration branches, but I am still holding onto them. You can find the changes

Re: [RFC/PATCH 0/5] remote: eliminate remote->{fetch,push}_refspec and lazy parsing of refspecs

Jeff King writes: > If we forget the "storing it twice" argument, would it make sense to > convert the parallel arrays of items into a single array-of-struct? > I.e.: > > struct configured_refspec { > const char *string; > struct refspec refspec; > unsigned

Re: [PATCH v2 0/3] Add regression tests for rectent rebase -i fixes

Johannes Sixt writes: > Am 16.06.2017 um 20:43 schrieb Johannes Sixt: >> Am 16.06.2017 um 15:49 schrieb Johannes Schindelin: >>> On Thu, 15 Jun 2017, Junio C Hamano wrote: diff --git a/t/t3420-rebase-autostash.sh b/t/t3420-rebase-autostash.sh index 325ec75353..801bce25da

Re: [PATCH 00/28] Create a reference backend for packed refs

On Mon, Jun 19, 2017 at 03:43:15PM -0400, Jeff King wrote: > > > Is the iterator over packed-refs correctly skipping over what are > > > covered by loose refs? The entries in the packed-refs file that are > > > superseded by loose refs should be allowed to point at an already > > > expired

Re: [PATCH v2 0/3] Add regression tests for rectent rebase -i fixes

Am 16.06.2017 um 20:43 schrieb Johannes Sixt: Am 16.06.2017 um 15:49 schrieb Johannes Schindelin: On Thu, 15 Jun 2017, Junio C Hamano wrote: diff --git a/t/t3420-rebase-autostash.sh b/t/t3420-rebase-autostash.sh index 325ec75353..801bce25da 100755 --- a/t/t3420-rebase-autostash.sh +++

Re: [PATCH 2/2] Add test for the new status message

On Mon, 2017-06-19 at 14:04 -0400, Jeff King wrote: > On Mon, Jun 19, 2017 at 11:29:49PM +0530, Kaartic Sivaraam wrote: > > > Is there a way to test for the "Initial commit" message in the > > commit > > template? > > You can do "git commit --dry-run", which produces the template on > stdout.

Re: [PATCH 00/28] Create a reference backend for packed refs

On Mon, Jun 19, 2017 at 12:25:07PM -0700, Junio C Hamano wrote: > Junio C Hamano writes: > > > Is the iterator over packed-refs correctly skipping over what are > > covered by loose refs? The entries in the packed-refs file that are > > superseded by loose refs should be

Re: in case you want a use-case with lots of submodules

On Mon, Jun 19, 2017 at 8:59 AM, Yaroslav Halchenko wrote: > Hi All, > > On a recent trip I've listened to the git minutes podcast episode and > got excited to hear Stefan Beller (CCed just in case) describing > ongoing work on submodules mechanism. I got excited, since

Re: [PATCH 00/28] Create a reference backend for packed refs

Junio C Hamano writes: > Is the iterator over packed-refs correctly skipping over what are > covered by loose refs? The entries in the packed-refs file that are > superseded by loose refs should be allowed to point at an already > expired object. Here it is in a test form

Re: Restoring detached HEADs after Git operations

On Mon, Jun 19, 2017 at 11:09 AM, Patrick Lehmann wrote: > Hello Stefan, > > the use case is as follows: > > The projects consists of circa 18 IP cores. Each IP core is represented by a > Git repository. Think of an IP core as of a lonestanding DLL or SO file > project.

Re: Restoring detached HEADs after Git operations

On Mon, Jun 19, 2017 at 10:55 AM, Junio C Hamano wrote: > Stefan Beller writes: > >> On Mon, Jun 19, 2017 at 2:52 AM, Patrick Lehmann >> wrote: >>> Hello Lars, >>> >>> for your questions: If there are multiple branches with

Re: [PATCH 00/28] Create a reference backend for packed refs

Michael Haggerty writes: > I've developed these patches on top of master plus the following > patches, which are followups to mh/packed-refs-store-prep: > > * lock_packed_refs(): fix cache validity check > * for_each_bisect_ref(): don't trim refnames > > The patches can

Re: [RFC/PATCH] submodules: overhaul documentation

On 06/13, Stefan Beller wrote: > Adding two native speakers as we start word smithing. > > On Tue, Jun 13, 2017 at 12:29 PM, Junio C Hamano wrote: > > >> + > >> +A submodule is another Git repository tracked in a subdirectory of your > >> +repository. The tracked repository

AW: Restoring detached HEADs after Git operations

Hello Stefan, the use case is as follows: The projects consists of circa 18 IP cores. Each IP core is represented by a Git repository. Think of an IP core as of a lonestanding DLL or SO file project. Each IP core references 2 submodules, which bring the verification environments for testing

Re: [PATCH 2/2] Add test for the new status message

On Mon, Jun 19, 2017 at 11:29:49PM +0530, Kaartic Sivaraam wrote: > Is there a way to test for the "Initial commit" message in the commit > template? You can do "git commit --dry-run", which produces the template on stdout. That should be good enough for our purposes here, as it's the same code

Re: [PATCH 2/2] Add test for the new status message

On Sun, 2017-06-18 at 21:32 -0700, Junio C Hamano wrote: > Kaartic Sivaraam writes: > > > +test_expect_success 'No commits yet should be noted in status > > output' ' > > +   git init initial && > > +   cd initial && > > +   git status >output && > > + 

Re: How to git push mirror local refs only?

Robert Dailey writes: > On Fri, Jun 9, 2017 at 8:53 PM, Junio C Hamano wrote: >> Robert Dailey writes: >> >>> So I want to update my remote fork with all my local branches. >>> Normally I'd do this: >>> >>> $ git push

[PATCH v3 4/4] rebase: Add more regression tests for console output

From: Phillip Wood Check the console output when using --autostash and the stash does not apply is what we expect. The test is quite strict but should catch any changes to the console output from the various rebase flavors. Thanks-to: Johannes Schindelin

[PATCH v3 2/4] rebase -i: Add test for reflog message

From: Phillip Wood Check that the reflog message written to the branch reflog when the rebase is completed is correct Signed-off-by: Phillip Wood --- t/t3404-rebase-interactive.sh | 7 +++ 1 file changed, 7 insertions(+) diff --git

[PATCH v3 3/4] rebase: Add regression tests for console output

From: Phillip Wood Check the console output when using --autostash and the stash applies cleanly is what we expect. The test is quite strict but should catch any changes to the console output from the various rebase flavors. Thanks-to: Johannes Schindelin

[PATCH v3 1/4] sequencer: print autostash messages to stderr

From: Johannes Schindelin The rebase messages are printed to stderr traditionally. However due to a bug introduced in 587947750bd (rebase: implement --[no-]autostash and rebase.autostash, 2013-05-12) which was faithfully copied when reimplementing parts of the

Re: Restoring detached HEADs after Git operations

On Mon, Jun 19 2017, Patrick Lehmann jotted: > Hello, > > I wrote a Bash script to recover branch names after Git operations have > create detached HEADs in a Git repository containing lots of Git submodules. > The script works recursively. > > I would like to see: > a) that script or

[PATCH v3 0/4] Add regression tests for recent rebase -i fixes

From: Phillip Wood I've updated the second two tests to be portable using q_to_cr() as Johannes suggested and added his patch to fix the autostash messages going to stdout rather than stderr. The reflog message test is unchanged. Thanks to Johannes for his help and to

Re: [PATCH/RFC] Cleanup Documentation

On Mon, Jun 19, 2017 at 10:33 AM, Kaartic Sivaraam wrote: > >> Please markup the '.gitmodules' either via single quotes or `. >> (or even link to 'gitmodules(5)' ) >> > Marked it up using `. Help needed to link to 'gitmodules(5)', as I'm > not sure how to provide

Re: Restoring detached HEADs after Git operations

Stefan Beller writes: > On Mon, Jun 19, 2017 at 2:52 AM, Patrick Lehmann > wrote: >> Hello Lars, >> >> for your questions: >>> If there are multiple branches with the same hash then your script would >>> pick the first one. Can you imagine a

Re: Behavior of 'git fetch' for commit hashes

On Mon, 19 Jun 2017 12:09:28 + wrote: > For version 2.7.4 > = > Git exits with exit code 1. > > However, if I first do 'git fetch ', then 'git fetch will > also work > > * branch-> FETCH_HEAD I suspect that what is happening is that 'git

Re: Restoring detached HEADs after Git operations

On Mon, Jun 19, 2017 at 10:34 AM, Patrick Lehmann wrote: > Hello, > > I'm just an advanced Git user, not a Git developer. So I might find some time > to improve the suggested script, which I provided with the hints given on the > mailing list, but I have no time to do a

Re: [PATCH v5 4/5] convert: move multiple file filter error handling to separate function

> On 19 Jun 2017, at 19:18, Torsten Bögershausen wrote: > > On 2017-06-18 13:47, Lars Schneider wrote: >> >>> On 18 Jun 2017, at 09:20, Torsten Bögershausen wrote: >>> >>> >>> On 2017-06-01 10:22, Lars Schneider wrote: This is useful for the subsequent

Re: [PATCH v5 08/10] rebase -i: skip unnecessary picks using the rebase--helper

Jeff King writes: > On Mon, Jun 19, 2017 at 11:45:50AM +0200, Johannes Schindelin wrote: > >> The reason for this suggestion is that one of the revision machinery's >> implementation details is an ugly little semi-secret: the pretty-printing >> machinery uses a global state, and

Re: [PATCH/RFC] Cleanup Documentation

On Sun, 2017-06-18 at 22:50 -0700, Stefan Beller wrote: > > > diff --git a/Documentation/git-submodule.txt b/Documentation/git- > > > submodule.txt > > > index 74bc6200d..9812b0655 100644 > > > --- a/Documentation/git-submodule.txt > > > +++ b/Documentation/git-submodule.txt > > > @@ -63,13 +63,7

AW: Restoring detached HEADs after Git operations

Hello, I'm just an advanced Git user, not a Git developer. So I might find some time to improve the suggested script, which I provided with the hints given on the mailing list, but I have no time to do a complete feature release in your patch based Git flow. I'm currently involved in 8 other

Re: [PATCH v5 4/5] convert: move multiple file filter error handling to separate function

On 2017-06-18 13:47, Lars Schneider wrote: > >> On 18 Jun 2017, at 09:20, Torsten Bögershausen wrote: >> >> >> On 2017-06-01 10:22, Lars Schneider wrote: >>> This is useful for the subsequent patch 'convert: add "status=delayed" to >>> filter process protocol'. >> >> May be >>

  1   2   >