Re: [PATCH] Do not record unstaged deleted file upon recursive merge if file was moved outside of working tree with enabled sparse-checkout.

It's a very unexpected behaviour when a user sees a deleted file after a merge with enabled sparse-checkout. Moreover, when the user resolves merge conflicts and commits the changes with the command "git commit -am xxx", a repository can be broken because all the moved files will be deleted.

Diff impromements: keep block whole

Does it be more meaning full which change was done when diff will be displayed as: @@ -1278,6 +1311,16 @@ sub process { if( ref $result eq 'HASH' ) { $code = $result->{ code }; @args = DB::eval( $result->{ expr } );

Re: Diff impromements: keep block whole

On Mon, Sep 12, 2016 at 12:36:26PM +0300, KES wrote: > Does it be more meaning full which change was done when diff will be > displayed as: > @@ -1278,6 +1311,16 @@ sub process { > if( ref $result eq 'HASH' ) { > $code = $result->{ code }; >

Re: [PATCH v2 21/25] sequencer: refactor write_message()

Am 11.09.2016 um 12:55 schrieb Johannes Schindelin: -static int write_message(struct strbuf *msgbuf, const char *filename) +static int write_with_lock_file(const char *filename, + const void *buf, size_t len, int append_eol) { static struct lock_file

Re: [PATCH] git-gui: respect commit.gpgsign again

Hi Junio, On Sun, 11 Sep 2016, Junio C Hamano wrote: > Johannes Schindelin writes: > > > Thanks. There are a couple more git-gui patches waiting for quite a long > > time. So you prefer them still as patches to git-gui.git? > > I prefer not to have to worry about

Re: Bug: git-add .* errors out

Hey Thomas, On Mon, Sep 12, 2016 at 1:09 AM, Thomas Gummerer wrote: > Hi, > > On 09/12, Pranit Bauva wrote: >> Hey everyone, >> >> One of my friend was trying to add files using the command `git add >> .*` and got an error that "fatal: ..: '..' is outside repository" >>

Re: [PATCH v2 20/25] sequencer: left-trim lines read from the script

Hi Junio, On Sun, 11 Sep 2016, Junio C Hamano wrote: > Johannes Schindelin writes: > > > Interactive rebase's scripts may be indented; we need to handle this > > case, too, now that we prepare the sequencer to process interactive > > rebases. > > Hmph, have we ever

[PATCH] Do not record unstaged deleted file upon recursive merge if file was moved outside of working tree with enabled sparse-checkout.

It's a very unexpected behaviour when a user sees a deleted file after a merge with enabled sparse-checkout. Moreover, when the user resolves merge conflicts and commits the changes with the command "git commit -am xxx", a repository can be broken because all the moved files will be deleted.

Re: [PATCH v2 12/14] i18n: show-branch: mark error messages for translation

Le 12/09/2016 à 13:30, Vasco Almeida a écrit : > if (MAX_REVS < reflog) > - die("Only %d entries can be shown at one time.", > + die("only %d entries can be shown at one time.", > MAX_REVS); Wouldn't you i18n this one

[PATCH v2 07/14] i18n: merge-recursive: mark error messages for translation

Lowercase first word of such error messages following the usual style. Signed-off-by: Vasco Almeida --- builtin/merge-recursive.c | 14 +++--- 1 file changed, 7 insertions(+), 7 deletions(-) diff --git a/builtin/merge-recursive.c b/builtin/merge-recursive.c index

[PATCH v2 05/14] i18n: branch: mark option description 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 7df0543..d5d93a8 100644 --- a/builtin/branch.c +++ b/builtin/branch.c @@ -657,7 +657,7 @@ int cmd_branch(int

[PATCH v2 02/14] i18n: apply: mark error messages for translation

Mark error messages for translation passed to error() and die() functions. Signed-off-by: Vasco Almeida --- builtin/apply.c | 46 +++--- 1 file changed, 23 insertions(+), 23 deletions(-) diff --git a/builtin/apply.c

Re: [PATCH v2 07/14] i18n: merge-recursive: mark error messages for translation

Hi, Le 12/09/2016 à 13:29, Vasco Almeida a écrit : > - warning("Cannot handle more than %d bases. " > - "Ignoring %s.", > + warning(_("cannot handle more than %d bases. " > + "Ignoring %s."), >

[PATCH v2 12/14] i18n: show-branch: mark error messages for translation

Lowercase some messages first word to match style of the others. Signed-off-by: Vasco Almeida --- builtin/show-branch.c | 18 +- 1 file changed, 9 insertions(+), 9 deletions(-) diff --git a/builtin/show-branch.c b/builtin/show-branch.c index

[PATCH v2 13/14] i18n: update-index: mark warnings for translation

Signed-off-by: Vasco Almeida --- builtin/update-index.c | 12 ++-- 1 file changed, 6 insertions(+), 6 deletions(-) diff --git a/builtin/update-index.c b/builtin/update-index.c index ba04b19..7a17ce1 100644 --- a/builtin/update-index.c +++ b/builtin/update-index.c

[PATCH v2 11/14] i18n: receive-pack: mark messages for translation

Mark messages refuse_unconfigured_deny_msg and refuse_unconfigured_deny_delete_current_msg for translation. Signed-off-by: Vasco Almeida --- builtin/receive-pack.c | 58 ++ 1 file changed, 25 insertions(+), 33 deletions(-)

[PATCH v2 14/14] i18n: show-branch: mark plural strings for translation

Mark plural string for translation using Q_(). Although we already know that the plural sentence is always used in the English source, other languages have complex plural rules they must comply according to the value of MAX_REVS. Signed-off-by: Vasco Almeida ---

[PATCH v2 08/14] i18n: merge-recursive: mark verbose message for translation

Signed-off-by: Vasco Almeida --- builtin/merge-recursive.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/builtin/merge-recursive.c b/builtin/merge-recursive.c index 0bc88a7..1c21802 100644 --- a/builtin/merge-recursive.c +++

[PATCH v2 03/14] i18n: apply: mark info messages for translation

Mark messages for translation printed to stderr. Signed-off-by: Vasco Almeida --- builtin/apply.c | 8 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/builtin/apply.c b/builtin/apply.c index ef2c084..43ab7c5 100644 --- a/builtin/apply.c +++

[PATCH v2 01/14] i18n: apply: mark plural string for translation

Mark plural string for translation using Q_(). Signed-off-by: Vasco Almeida --- builtin/apply.c | 10 ++ 1 file changed, 6 insertions(+), 4 deletions(-) diff --git a/builtin/apply.c b/builtin/apply.c index 1a488f9..ef03c74 100644 --- a/builtin/apply.c +++

[PATCH v2 09/14] i18n: notes: mark error messages for translation

Signed-off-by: Vasco Almeida --- builtin/notes.c | 18 +- 1 file changed, 9 insertions(+), 9 deletions(-) diff --git a/builtin/notes.c b/builtin/notes.c index f848b89..abacae2 100644 --- a/builtin/notes.c +++ b/builtin/notes.c @@ -340,7 +340,7 @@ static

[PATCH v2 04/14] i18n: blame: mark error messages for translation

Mark error messages for translation passed to die() function. Change "Cannot" to lowercase following the usual style. Reflect changes to test by using test_i18ngrep. Signed-off-by: Vasco Almeida --- builtin/blame.c | 18 ++

Re: [PATCH v7 10/10] convert: add filter..process option

> On 10 Sep 2016, at 08:29, Torsten Bögershausen wrote: > > On Thu, Sep 08, 2016 at 08:21:32PM +0200, larsxschnei...@gmail.com wrote: > [] >> +packet: git> git-filter-client >> +packet: git> version=2 >> +packet: git> version=42 >> +packet:

Re: [PATCH v7 03/10] pkt-line: add packet_write_fmt_gently()

> On 11 Sep 2016, at 18:01, Stefan Beller wrote: > > On Sun, Sep 11, 2016 at 4:36 AM, Lars Schneider > wrote: > >>> >>> call check_pipe from write_or_die here instead of >>> reproducing that function? >> [...] > >> Maybe it would be more

Re: [PATCH] Do not record unstaged deleted file upon recursive merge if file was moved outside of working tree with enabled sparse-checkout.

>> +test_expect_success 'move file/sparse-checkout/merge should not delete >> moved file' ' >> + git rm -rf . && >> + git clean -fdqx && >> + rm -rf .git && >> + git init && > > Yuck. This is inherited from existing tests but I think they need > to be cleaned up. It is not your fault, and it

[PATCH v2 06/14] i18n: config: mark error message for translation

Signed-off-by: Vasco Almeida --- builtin/config.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/builtin/config.c b/builtin/config.c index 6cbf733..05843a0 100644 --- a/builtin/config.c +++ b/builtin/config.c @@ -622,8 +622,8 @@ int cmd_config(int

[PATCH v2 10/14] notes: lowercase first word of error messages

Follow the usual case style. Update one test to reflect these changes. Signed-off-by: Vasco Almeida --- builtin/notes.c | 64 t/t3320-notes-merge-worktrees.sh | 2 +- 2 files changed, 33 insertions(+), 33

Re: [PATCH v2 09/14] i18n: notes: mark error messages for translation

Le 12/09/2016 à 13:29, Vasco Almeida a écrit : > Signed-off-by: Vasco Almeida > --- > builtin/notes.c | 18 +- > 1 file changed, 9 insertions(+), 9 deletions(-) > > diff --git a/builtin/notes.c b/builtin/notes.c > index f848b89..abacae2 100644 > ---

Re: Git Miniconference at Plumbers

So, like, Jeff King said: > On Tue, Sep 06, 2016 at 12:42:04PM -0500, Jon Loeliger wrote: > > > I have recently been enlisted by folks at the Linux Foundation to > > help run a Miniconference on Git at the Plumbers Conference [*] > > this fall. > > I see the conference runs for 4 days; I assume

Re: [PATCH] gpg-interface: reflect stderr to stderr

Junio C Hamano venit, vidit, dixit 08.09.2016 23:36: > Jeff King writes: > >>> Even though this patch is fixing only one of the two issues, I am >>> tempted to say that we should queue it for now, as it does so >>> without breaking a bigger gain made by the original, i.e. we learn

Gitattributes file is not respected when switching between branches

Good day I faced following issue with gitattributes file (at least eol setting) when was trying to force `lf` mode on windows. We have 2 branches: master & dev. With master set as HEAD in repository I've added `.gitattributes` with following content to `dev` branch ``` * text eol=lf ``` Now

Re: What's cooking in git.git (Sep 2016, #03; Fri, 9)

On Fri, Sep 09, 2016 at 03:47:35PM -0700, Junio C Hamano wrote: > * jk/delta-base-cache (2016-08-23) 7 commits > (merged to 'next' on 2016-08-25 at f1c141a) > + t/perf: add basic perf tests for delta base cache > + delta_base_cache: use hashmap.h > + delta_base_cache: drop special treatment

Re: [PATCH v2 3/5] Make the require_clean_work_tree() function truly reusable

Johannes Schindelin writes: > It is remarkable that libgit.a did not sport this function yet... Let's > move it into a more prominent (and into an actually reusable) spot: > wt-status.[ch]. > > Signed-off-by: Johannes Schindelin > --- I

Re: [PATCH] t/perf/run: Don't forget to copy config.mak.autogen & friends to build area

Kirill Smelkov writes: > Otherwise for people who use autotools-based configure in main worktree, > the performance testing results will be inconsistent as work and build > trees could be using e.g. different optimization levels. > > See e.g. > > >

Re: Gitattributes file is not respected when switching between branches

On 12.09.16 21:35, Torsten Bögershausen wrote: > On 12.09.16 14:55, Виталий Ищенко wrote: >> Good day >> >> I faced following issue with gitattributes file (at least eol setting) >> when was trying to force `lf` mode on windows. >> >> We have 2 branches: master & dev. With master set as HEAD in

Re: [PATCH v2 04/25] sequencer: future-proof remove_sequencer_state()

Johannes Schindelin writes: > +static const char *get_dir(const struct replay_opts *opts) > +{ > + return git_path_seq_dir(); > +} Presumably this is what "In a couple of commits" meant, i.e. opts will be used soonish. > -static void remove_sequencer_state(void)

[ANNOUNCE] Git User's Survey 2016

Hello all, We would like to ask you a few questions about your use of the Git version control system. This survey is mainly to understand who is using Git, how and why. The results will be published to the Git wiki on the GitSurvey2016 page (https://git.wiki.kernel.org/index.php/GitSurvey2016)

Re: [PATCH v2 02/25] sequencer: use memoized sequencer directory path

Johannes Schindelin writes: > Signed-off-by: Johannes Schindelin > --- > builtin/commit.c | 2 +- > sequencer.c | 11 ++- > sequencer.h | 5 + > 3 files changed, 8 insertions(+), 10 deletions(-) OK. It's nice to

Re: [PATCH v2 07/14] i18n: merge-recursive: mark error messages for translation

Jean-Noël Avila writes: > Le 12/09/2016 à 13:29, Vasco Almeida a écrit : >> -warning("Cannot handle more than %d bases. " >> -"Ignoring %s.", >> +warning(_("cannot handle more than %d bases. " >> +

Re: [PATCH v2 12/14] i18n: show-branch: mark error messages for translation

Jean-Noël Avila writes: > Le 12/09/2016 à 13:30, Vasco Almeida a écrit : >> if (MAX_REVS < reflog) >> -die("Only %d entries can be shown at one time.", >> +die("only %d entries can be shown at one time.", >>

Re: [PATCH v2 12/14] i18n: show-branch: mark error messages for translation

On lundi 12 septembre 2016 10:02:54 CEST Junio C Hamano wrote: > Jean-Noël Avila writes: > > Le 12/09/2016 à 13:30, Vasco Almeida a écrit : > >>if (MAX_REVS < reflog) > >> > >> - die("Only %d entries can be shown at one time.", > >> +

Re: [PATCH v3 0/2] patch-id for merges

Jeff King writes: > That looks like the patch below (as a replacement for patch 2), which is > even less invasive. It also performs a little better on my example case, > because we avoid adding merges to the hashmap entirely. After reading it, I did not find [v3 2/2] is too bad

Re: [PATCH 1/2 v5] pack-objects: respect --local/--honor-pack-keep/--incremental when bitmap is in use

Kirill Smelkov writes: > On Thu, Aug 18, 2016 at 01:52:22PM -0400, Jeff King wrote: > > > > Good to know there is no regression. It is curious that there is a > > slight _improvement_ across the board. Do we have an explanation for > > that? It seems odd that noise would be so

Re: [PATCH v2 2/5] pull: make code more similar to the shell script again

Johannes Schindelin writes: > When converting the pull command to a builtin, the > require_clean_work_tree() function was renamed and the pull-specific > parts hard-coded. > > This makes it impossible to reuse the code, so let's modify the code to > make it more

Re: [PATCH 2/2 v7] pack-objects: use reachability bitmap index when generating non-stdout pack

Kirill Smelkov writes: >> This is v7, but as I understand your numbering, it goes with v5 of patch >> 1/2 that I just reviewed (usually we just increment the version number >> on the whole series and treat it as a unit, even if some patches didn't >> change from version to

Re: [PATCH v2 2/4] update-index: use the same structure for chmod as add

On 09/11, Junio C Hamano wrote: > Thomas Gummerer writes: > > > @@ -955,10 +941,8 @@ int cmd_update_index(int argc, const char **argv, > > const char *prefix) > > PARSE_OPT_NOARG | /* disallow --cacheinfo= form */ > > PARSE_OPT_NONEG

Re: [PATCH v2 05/25] sequencer: allow the sequencer to take custody of malloc()ed data

Johannes Schindelin writes: > The sequencer is our attempt to lib-ify cherry-pick. Yet it behaves > like a one-shot command when it reads its configuration: memory is > allocated and released only when the command exits. > > This is kind of okay for git-cherry-pick,

Re: [PATCH v2 01/25] sequencer: use static initializers for replay_opts

Johannes Schindelin writes: > This change is not completely faithful: instead of initializing all fields > to 0, we choose to initialize command and subcommand to -1 (instead of > defaulting to REPLAY_REVERT and REPLAY_NONE, respectively). Practically, > it makes no

Re: What's cooking in git.git (Sep 2016, #03; Fri, 9)

Jeff King writes: > I happened to notice today that this topic needs a minor tweak: > > -- >8 -- > Subject: [PATCH] add_delta_base_cache: use list_for_each_safe > > We may remove elements from the list while we are iterating, > which requires using a second temporary pointer.

Re: Gitattributes file is not respected when switching between branches

On 12.09.16 14:55, Виталий Ищенко wrote: > Good day > > I faced following issue with gitattributes file (at least eol setting) > when was trying to force `lf` mode on windows. > > We have 2 branches: master & dev. With master set as HEAD in repository > > I've added `.gitattributes` with following

Re: [PATCH v2 0/5] Pull out require_clean_work_tree() functionality from builtin/pull.c

Johannes Schindelin writes: > Johannes Schindelin (5): > pull: drop confusing prefix parameter of die_on_unclean_work_tree() > pull: make code more similar to the shell script again > Make the require_clean_work_tree() function truly reusable > Export also the

Re: [PATCH v2 03/25] sequencer: avoid unnecessary indirection

Johannes Schindelin writes: > -static int read_populate_opts(struct replay_opts **opts) > +static int read_populate_opts(struct replay_opts *opts) > { > if (!file_exists(git_path_opts_file())) > return 0; > @@ -823,7 +823,7 @@ static int

RE: [PATCH v2] checkout: eliminate unnecessary merge for trivial checkout

> -Original Message- > From: Junio C Hamano [mailto:gits...@pobox.com] > Sent: Friday, September 9, 2016 5:55 PM > To: Ben Peart > Cc: git@vger.kernel.org; pclo...@gmail.com; Ben Peart > > Subject: Re: [PATCH v2] checkout: eliminate

Re: [RFC/PATCH] ls-files: adding support for submodules

Thanks for all the comments. What it sounds like is that using ls-files as a means to power a recursive git-grep may not be like the best approach (I assumed that would be the case but thought it a decent place to start). I agree that not all operating modes would be useful for a recursive

Re: [PATCH v3 0/2] patch-id for merges

On Mon, Sep 12, 2016 at 10:18:33AM -0700, Junio C Hamano wrote: > > +static int patch_id_defined(struct commit *commit) > > +{ > > + /* must be 0 or 1 parents */ > > + return !commit->parents || !commit->parents->next; > > +} > > If we make the first hunk begin like so: > > > + if

RE: Git Miniconference at Plumbers

Hi, The subject matter of the conference looks really interesting but I am unlikely to be able to attend, unfortunately. The subjects being covered like the current State of Git and the Future of Git, for example, deserve much wider exposure, and I would certainly appreciate hearing the

Re: Git Miniconference at Plumbers

So, like, David Bainbridge said: > Hi, > > The subject matter of the conference looks really interesting but I am > unlikely to be able to attend, unfortunately. > > The subjects being covered like the current State of Git and the > Future of Git, for example, deserve much wider exposure, and I

Re: [PATCH v2 12/14] i18n: show-branch: mark error messages for translation

Jean-Noël AVILA writes: > ..., and > plural forms can be quite different depending on its value. AHHhhh, of course you are right.

Re: build issues on AIX - aka non-GNU environment, no gnu grep, no gcc

Michael Felt writes: > I had a couple of issues when packaging git for AIX > a) option -Wall by default - works fine with gcc I am sure, but not so > well when gcc is not your compiler That is expected. As you said, it is merely "by default" and there are mechanisms like

Re: [PATCH v2 18/25] sequencer: support cleaning up commit messages

Johannes Schindelin writes: > @@ -788,7 +792,7 @@ static int do_pick_commit(enum todo_command command, > struct commit *commit, > } > if (!opts->no_commit) > res = sequencer_commit(opts->edit ? NULL : git_path_merge_msg(), > -

[PATCH] [git-p4.py] Add --checkpoint-period option to sync/clone

Importing a long history from Perforce into git using the git-p4 tool can be especially challenging. The `git p4 clone` operation is based on an all-or-nothing transactionality guarantee. Under real-world conditions like network unreliability or a busy Perforce server, `git p4 clone` and `git p4

[PATCH] [git-p4.py] Add --checkpoint-period option to sync/clone

Importing a long history from Perforce into git using the git-p4 tool can be especially challenging. The `git p4 clone` operation is based on an all-or-nothing transactionality guarantee. Under real-world conditions like network unreliability or a busy Perforce server, `git p4 clone` and `git p4

Re: [PATCH v2] checkout: eliminate unnecessary merge for trivial checkout

"Ben Peart" writes: > I completely agree that optimizing within merge_working_tree would provide > more opportunities for optimization. I can certainly move the test into > that function as a first step. Note that "optimizing more" was not the primary point of my response.

[PATCH v3 0/4] git add --chmod: always change the file

Thanks to Junio on setting me straight on the change of behaviour in the previous round. This round includes a similar change, which does however not change the behaviour of update-index with repeated arguments. I still think the unification of the way git add and git update-index handle chmod

[PATCH v3 1/4] add: document the chmod option

The git add --chmod option was introduced in 4e55ed3 ("add: add --chmod=+x / --chmod=-x options", 2016-05-31), but was never documented. Document the feature. Signed-off-by: Thomas Gummerer --- Documentation/git-add.txt | 7 ++- 1 file changed, 6 insertions(+), 1

[PATCH v3 4/4] add: modify already added files when --chmod is given

When the chmod option was added to git add, it was hooked up to the diff machinery, meaning that it only works when the version in the index differs from the version on disk. As the option was supposed to mirror the chmod option in update-index, which always changes the mode in the index,

[PATCH v3 2/4] update-index: use the same structure for chmod as add

While the chmod options for update-index and the add have the same functionality, they are using different ways to parse and handle the option internally. Unify these modes in order to make further refactoring simpler. Signed-off-by: Thomas Gummerer ---

[PATCH v3 3/4] read-cache: introduce chmod_index_entry

As there are chmod options for both add and update-index, introduce a new chmod_index_entry function to do the work. Use it in update-index, while it will be used in add in the next patch. Signed-off-by: Thomas Gummerer --- builtin/update-index.c | 8 +--- cache.h

Re: git commit -p with file arguments

W dniu 12.09.2016 o 03:57, Junio C Hamano pisze: > Jacob Keller writes: > >> Yes, I'm actually confused by "git commit " *not* usinng what's >> in the index already, so I think that isn't intuitive as is. > > You are excused ;-) > > In ancient days, "git commit " was to

Re: Git Miniconference at Plumbers

W dniu 12.09.2016 o 20:09, Jon Loeliger napisał: > So, like, David Bainbridge said: >> Does anyone know whether the sessions will be recorded in any way? > > I am uncertain about outright recording (digital video/audio), > but there will be at least summarizing notes taken and posted. > Anyone

Re: [PATCH v2 19/25] sequencer: remember do_recursive_merge()'s return value

Johannes Schindelin writes: > The return value of do_recursive_merge() may be positive (indicating merge > conflicts), so let's OR later error conditions so as not to overwrite them > with 0. Are the untold assumptions as follows? - The caller wants to act on

Re: [PATCH v2 17/25] sequencer: support amending commits

Johannes Schindelin writes: > This teaches the sequencer_commit() function to take an argument that > will allow us to implement "todo" commands that need to amend the commit > messages ("fixup", "squash" and "reword"). > > Signed-off-by: Johannes Schindelin

Re: [PATCH v3 0/2] patch-id for merges

Jeff King writes: > On Mon, Sep 12, 2016 at 10:18:33AM -0700, Junio C Hamano wrote: > >> > +static int patch_id_defined(struct commit *commit) >> > +{ >> > + /* must be 0 or 1 parents */ >> > + return !commit->parents || !commit->parents->next; >> > +} >> >> If we make the

Re: What's cooking in git.git (Sep 2016, #03; Fri, 9)

On Mon, Sep 12, 2016 at 12:10:13PM -0700, Junio C Hamano wrote: > Jeff King writes: > > > I happened to notice today that this topic needs a minor tweak: > > > > -- >8 -- > > Subject: [PATCH] add_delta_base_cache: use list_for_each_safe > > > > We may remove elements from the

Re: [PATCH v3 2/4] update-index: use the same structure for chmod as add

Thomas Gummerer writes: > + char flip = force_mode == 0777 ? '+' : '-'; > > pos = cache_name_pos(path, strlen(path)); > if (pos < 0) > @@ -432,17 +433,11 @@ static void chmod_path(int flip, const char *path) > mode = ce->ce_mode; > if

[PATCH 15/16] init: expand comments explaining config trickery

git-init may copy "config" from the templates directory and then re-read it. There are some comments explaining what's going on here, but they are not grouped very well with the matching code. Let's rearrange and expand them. Signed-off-by: Jeff King --- builtin/init-db.c | 11

[PATCH 14/16] config: only read .git/config from configured repos

When git_config() runs, it looks in the system, user-wide, and repo-level config files. It gets the latter by calling git_pathdup(), which in turn calls get_git_dir(). If we haven't set up the git repository yet, this may simply return ".git", and we will look at ".git/config". This seems like it

[PATCH 16/16] init: reset cached config when entering new repo

After we copy the templates into place, we re-read the config in case we copied in a default config file. But since git_config() is backed by a cache these days, it's possible that the call will not actually touch the filesystem at all; we need to tell it that something has changed behind the

[PATCH 10/16] pager: use callbacks instead of configset

While the cached configset interface is more pleasant to use, it is not appropriate for "early" config like pager setup, which must sometimes do tricky things like reading from ".git/config" even when we have not set up the repository. As a preparatory step to handling these cases better, let's

[PATCH 11/16] pager: handle early config

The pager code is often run early in the git.c startup, before we have actually found the repository. When we ask git_config() to look for values like core.pager, it doesn't know where to find the repo-level config, and will blindly examine ".git/config" if it exists. That's why t7006 shows that

[PATCH 12/16] t1302: use "git -C"

This is shorter, and saves a subshell. Signed-off-by: Jeff King --- t/t1302-repo-version.sh | 30 ++ 1 file changed, 6 insertions(+), 24 deletions(-) diff --git a/t/t1302-repo-version.sh b/t/t1302-repo-version.sh index 9bcd349..f859809 100755 ---

[PATCH 13/16] test-config: setup git directory

The t1308 test script uses our test-config helper to read repository-level config, but never actually sets up the repository. This works because git_config() blindly reads ".git/config" even if we have not configured a repository. This means that test-config won't work from a subdirectory, though

Re: [PATCH v2] ls-files: adding support for submodules

> static void write_name(const char *name) > { > /* > +* NEEDSWORK: To make this thread-safe, full_name would have to be > owned > +* by the caller. > +* > +* full_name get reused across output lines to minimize the allocation > +* churn. > +

[PATCH 0/16] fix config-reading in non-repos

The motivation for this series is to fix the regression in v2.9 where core.logallrefupdates is sometimes not set properly in a newly initialized repository, as described in this thread: http://public-inbox.org/git/c46d36ef-3c2e-374f-0f2e-ffe31104e...@gmx.de/T/#u The root of the problem is that

[PATCH 09/16] pager: make pager_program a file-local static

This variable is only ever used by the routines in pager.c, and other parts of the code should always use those routines (like git_pager()) to make decisions about which pager to use. Let's reduce its scope to prevent accidents. Signed-off-by: Jeff King --- cache.h | 1 -

[PATCH 06/16] diff: always try to set up the repository

If we see an explicit "--no-index", we do not bother calling setup_git_directory_gently() at all. This means that we may miss out on reading repo-specific config. It's arguable whether this is correct or not. If we were designing from scratch, making "git diff --no-index" completely ignore the

[PATCH 08/16] pager: stop loading git_default_config()

In git_pager(), we really only care about getting the value of core.pager. But to do so, we use the git_default_config() callback, which loads many other values. Ordinarily it isn't a big deal to load this config an extra time, as it simply overwrites the values from the previous run. But it's a

[PATCH 03/16] patch-id: use RUN_SETUP_GENTLY

Patch-id does not require a repository because it is just processing the incoming diff on stdin, but it may look at git config for keys like patchid.stable. Even though we do not setup_git_directory(), this works from the top-level of a repository because we blindly look at ".git/config" in this

[PATCH 04/16] diff: skip implicit no-index check when given --no-index

We can invoke no-index mode in two ways: by an explicit request from the user, or implicitly by noticing that we have two paths, and at least one is outside the repository. If the user already told us --no-index, there is no need for us to do the implicit test at all. However, we currently do,

[PATCH 07/16] pager: remove obsolete comment

The comment at the top of pager.c claims that we've split the code out so that Windows can do something different. This dates back to f67b45f (Introduce trivial new pager.c helper infrastructure, 2006-02-28), because the original implementation used fork(). Later, we ended up sticking the Windows

[PATCH 05/16] diff: handle --no-index prefixes consistently

If we see an explicit "git diff --no-index ../foo ../bar", then we do not set up the git repository at all (we already know we are in --no-index mode, so do not have to check "are we in a repository?"), and hence have no "prefix" within the repository. A patch generated by this command will have

[PATCH 02/16] hash-object: always try to set up the git repository

When "hash-object" is run without "-w", we don't need to be in a git repository at all; we can just hash the object and write its sha1 to stdout. However, if we _are_ in a git repository, we would want to know that so we can follow the normal rules for respecting config, .gitattributes, etc. This

[PATCH 01/16] t1007: factor out repeated setup

We have a series of 3 CRLF tests that do exactly the same (long) setup sequence. Let's pull it out into a common setup test, which is shorter, more efficient, and will make it easier to add new tests. Note that we don't have to worry about cleaning up any of the setup which was previously

[PATCH v2] ls-files: adding support for submodules

Allow ls-files to recognize submodules in order to retrieve a list of files from a repository's submodules. This is done by forking off a process to recursively call ls-files on all submodules. Also added an output-path-prefix command in order to prepend paths to child processes. Signed-off-by:

Re: Potential Same Name Bug

Hi Kevin, On 13 September 2016 at 09:29, Kevin Smith wrote: > So when I move from master to develop that status would come up. If I > ran "git reset --hard" I would no longer have that message. I also > saw that when I do a git clone and specify to clone the develop branch >

Re: [PATCH] t/perf/run: Don't forget to copy config.mak.autogen & friends to build area

Junio C Hamano writes: >> build_git_rev () { >> rev=$1 >> -cp ../../config.mak build/$rev/config.mak >> +cp -t build/$rev ../../{config.mak,config.mak.autogen,config.status} > > That unfortunately is a GNUism -t with a bash-ism {a,b,c}; just keep > it simple and

Re: Git Miniconference at Plumbers

Jon Loeliger writes: > So, like, David Bainbridge said: >> Hi, >> >> The subject matter of the conference looks really interesting but I am >> unlikely to be able to attend, unfortunately. >> >> The subjects being covered like the current State of Git and the >> Future of Git,

Re: [PATCH 07/10] diff.c: convert fn_out_consume to use emit_line_*

On Mon, Sep 12, 2016 at 5:25 PM, Junio C Hamano wrote: > Stefan Beller writes: > >> diff --git a/diff.c b/diff.c >> index 2aefd0f..7dcef73 100644 >> --- a/diff.c >> +++ b/diff.c >> @@ -493,6 +493,19 @@ static void emit_line(struct diff_options *o, const

Re: [PATCH v3 4/4] add: modify already added files when --chmod is given

Thomas Gummerer writes: > When the chmod option was added to git add, it was hooked up to the diff > machinery, meaning that it only works when the version in the index > differs from the version on disk. > > As the option was supposed to mirror the chmod option in

Re: [PATCH 02/10] diff: emit_{add, del, context}_line to increase {pre,post}image line count

Stefan Beller writes: > From: Stefan Beller > > At all call sites of emit_{add, del, context}_line we increment the line > count, so move it into the respective functions to make the code at the > calling site a bit clearer. > > Signed-off-by: Stefan

  1   2   >