Re: [PATCH 5/8] rebase: introduce the --recreate-merges option

Johannes Sixt writes: > Am 09.02.2018 um 07:11 schrieb Sergey Organov: >> Johannes Schindelin writes: >>> Let me explain the scenario which comes up plenty of times in my work with >>> Git for Windows. We have a thicket of some 70 branches on top of

Re: [PATCH 5/8] rebase: introduce the --recreate-merges option

Hi Johannes, Johannes Schindelin writes: > Hi Sergey, > > On Fri, 9 Feb 2018, Sergey Organov wrote: > >> Johannes Schindelin writes: >> >> [...] >> >> > With this patch, the goodness of the Git garden shears comes to `git >> > rebase -i`

Re: [PATCH 5/8] rebase: introduce the --recreate-merges option

Hi Johannes, Thanks for explanations, and could you please answer this one: [...] >> I also have trouble making sense of "Recreate merge commits instead of >> flattening the history by replaying merges." Is it "> commits by replaying merges> instead of " or is it >> rather " instead of >

Re: [PATCH v1] worktree: set worktree environment in post-checkout hook

On Fri, Feb 9, 2018 at 8:01 PM, wrote: > In ade546be47 (worktree: invoke post-checkout hook (unless > --no-checkout), 2017-12-07) we taught Git to run the post-checkout hook > in worktrees. Unfortunately, the environment of the hook was not made > aware of the

[PATCH 0/2] worktree: change to new worktree dir before running hook(s)

This patch series replaces "worktree: set worktree environment in post-checkout hook"[1] from Lars, which is a proposed bug fix for ade546be47 (worktree: invoke post-checkout hook, 2017-12-07). The problem that patch addresses is that "git worktree add" does not provide proper context to the

[PATCH 1/2] run-command: teach 'run_hook' about alternate worktrees

Git commands which run hooks do so at the top level of the worktree in which the command itself was invoked. However, the 'git worktree' command may need to run hooks within some other directory. For instance, when "git worktree add" runs the 'post-checkout' hook, the hook must be run within the

[PATCH 2/2] worktree: add: change to new worktree directory before running hook

Although "git worktree add" learned to run the 'post-checkout' hook in ade546be47 (worktree: invoke post-checkout hook, 2017-12-07), it neglects to change to the directory of the newly-created worktree before running the hook. Instead, the hook is run within the directory from which the "git

Re: [PATCH v3 42/42] git-completion.bash: add GIT_COMPLETION_OPTIONS=all config

On Sun, Feb 11, 2018 at 8:59 AM, Eric Sunshine wrote: > On Fri, Feb 9, 2018 at 6:02 AM, Nguyễn Thái Ngọc Duy > wrote: >> By default, some option names (mostly --force, scripting related or for >> internal use) are not completable for various reasons.

[PATCH 2/2] Makefile: suppress a sparse warning for pack-revindex.c

Sparse has, for a long time, been issuing the following warning against the pack-revindex.c file: SP pack-revindex.c pack-revindex.c:64:23: warning: memset with byte count of 262144 This results from a unconditional check, with a hard-coded limit, which is really only appropriate for

[PATCH 1/2] config.mak.uname: remove SPARSE_FLAGS setting for cygwin

Since commit f66450ae9 ("cygwin: Remove the Win32 l/stat() implementation", 2013-06-22), the cygwin build has not used the WIN32 API/header files. This means that the '-isystem /usr/include/w32api' option to sparse is no longer necessary (to allow sparse to find the WIN32 header files). In

[PATCH 0/2] misc sparse updates

These patches are based on v2.16, but a test merge to master, next and pu are all clean. Ramsay Jones (2): config.mak.uname: remove SPARSE_FLAGS setting for cygwin Makefile: suppress a sparse warning for pack-revindex.c Makefile | 2 ++ config.mak.uname | 1 - 2 files changed, 2

[PATCH 2/2] t5556: replace test_i18ngrep with a simple grep

Attempting to grep the output of test_i18ngrep will not work under a poison build, since the output is (almost) guaranteed not to have the string you are looking for. In this case, the output of test_i18ngrep is further filtered by a simple piplined grep to exclude an '... remote end hung up

[PATCH 1/2] t4151: consolidate multiple calls to test_i18ngrep

Attempting to grep the output of test_i18ngrep will not work under a poison build, since the output is (almost) guaranteed not to have the string you are looking for. In this case, we have a test_i18ngrep call which attempts to filter the contents of a file, which was itself the result of a call

[PATCH 0/2] test_i18ngrep

These patches resulted from an experiment of yours [1], I wrote these up last year, then promptly forgot about them! ;-) These patches were built on top of v2.16, and the second patch has a simple conflict with commit 93b4b0313c ("t5536: let 'test_i18ngrep' read the file without redirection",

REQUEST NEW TRANSLATION (INDONESIAN/id_ID)

Hello git-l10n Team I want to join to this project as a translator for Indonesian language (ID) I have read the README file located in the https://github.com/git-l10n/git-po/blob/master/po/README directory I also have a fork repository master (git-l10n) to my repository (anaufalm), and also

[PATCH 2/3] config: respect `pager.config` in list/get-mode only

Similar to de121ffe5 (tag: respect `pager.tag` in list-mode only, 2017-08-02), use the DELAY_PAGER_CONFIG-mechanism to only respect `pager.config` when we are listing or "get"ing config. Some getters give at most one line of output, but it is much easier to document and understand that we page

[PATCH 3/3] config: change default of `pager.config` to "on"

This is similar to ff1e72483 (tag: change default of `pager.tag` to "on", 2017-08-02) and is safe now that we do not consider `pager.config` at all when we are not listing or getting configuration. This change will help with listing large configurations, but will not hurt users of `git config

[PATCH 1/3] t7006: add tests for how git config paginates

The next couple of commits will change how `git config` handles `pager.config`, similar to how de121ffe5 (tag: respect `pager.tag` in list-mode only, 2017-08-02) and ff1e72483 (tag: change default of `pager.tag` to "on", 2017-08-02) changed `git tag`. Similar work has also been done to `git

Re: [PATCH v3 42/42] git-completion.bash: add GIT_COMPLETION_OPTIONS=all config

On Sat, Feb 10 2018, Duy Nguyen jotted: > On Fri, Feb 09, 2018 at 03:19:57PM +0100, Ævar Arnfjörð Bjarmason wrote: >> >> On Fri, Feb 09 2018, Nguyễn Thái Ngọc Duy jotted: >> >> > By default, some option names (mostly --force, scripting related or for >> > internal use) are not completable for

Re: What's cooking in git.git (Jan 2018, #04; Wed, 31)

On Sat, Feb 10 2018, Duy Nguyen jotted: > On Sat, Feb 10, 2018 at 1:37 AM, Ævar Arnfjörð Bjarmason > wrote: >> >> On Thu, Feb 01 2018, Junio C. Hamano jotted: >> >>> * nd/fix-untracked-cache-invalidation (2018-01-24) 5 commits >>> - dir.c: stop ignoring opendir() error in

Re: [PATCH 5/8] rebase: introduce the --recreate-merges option

On Thu, Feb 8, 2018 at 11:13 PM, Johannes Sixt wrote: > Am 09.02.2018 um 07:11 schrieb Sergey Organov: >> >> Johannes Schindelin writes: >>> >>> Let me explain the scenario which comes up plenty of times in my work >>> with >>> Git for Windows. We have

[PATCH v3 0/3] Add "git rebase --show-current-patch"

Compared to v2: - the potential loss of errno before it's printed out in builtin/am.c is fixed. - keep update_ref() in sequencer.c non-fatal like this rest - rename ORIG_COMMIT to REBASE_HEAD Interdiff: diff --git a/Documentation/git-rebase.txt b/Documentation/git-rebase.txt index

[PATCH v3 1/3] am: add --show-current-patch

Pointing the user to $GIT_DIR/rebase-apply may encourage them to mess around in there, which is not a good thing. With this, the user does not have to keep the path around somewhere (because after a couple of commands, the path may be out of scrollback buffer) when they need to look at the patch.

[PATCH v3 3/3] rebase: introduce and use pseudo-ref REBASE_HEAD

The new command `git rebase --show-current-patch` is useful for seeing the commit related to the current rebase state. Some however may find the "git show" command behind it too limiting. You may want to increase context lines, do a diff that ignores whitespaces... For these advanced use cases,

[PATCH v3 2/3] rebase: add --show-current-patch

It is useful to see the full patch while resolving conflicts in a rebase. The only way to do it now is less .git/rebase-*/patch which could turn out to be a lot longer to type if you are in a linked worktree, or not at top-dir. On top of that, an ordinary user should not need to peek into