Antw: Re: bug deleting "unmerged" branch (2.12.3)

> Hi Ulrich, > > On Tue, 28 Nov 2017, Ulrich Windl wrote: > >> During a rebase that turned out to be heavier than expected 8-( I >> decided to keep the old branch by creating a temporary branch name to >> the commit of the branch to rebase (which was still the old commit ID at >> that time).

Antw: Re: bug deleting "unmerged" branch (2.12.3)

> "Ulrich Windl" writes: > >> I think if more than one branches are pointing to the same commit, >> one should be allowed to delete all but the last one without >> warning. Do you agree? > > That comes from a viewpoint that the only purpose "branch -d" exists

Re: [PATCH] strbuf: Remove unused stripspace function alias

On 2017-11-29 at 02:45:59 +0100, Elijah Newren wrote: > In commit 63af4a8446 ("strbuf: make stripspace() part of strbuf", > 2015-10-16), stripspace() was moved to strbuf and renamed to > strbuf_stripspace(). A "temporary" alias was added for the old name until > all topic

Reply

I have something very confidential and private to discuss with you

git blame --reverse doesn't find line in HEAD

I have a repo that reproduces a behavior with `git blame --reverse` that surprises me. https://github.com/nicksnyder/git-blame-bug The readme explains the observed behavior and what I expected to happen. I will inline the readme at the bottom of this message for convenience. Am I

Re: [PATCH] git-prompt: fix reading files with windows line endings

Hi Robert, On Tue, 28 Nov 2017, Robert Abel wrote: > If any of the files read by __git_eread have \r\n line endings, read > will only strip \n, leaving \r. This results in an ugly prompt, where > instead of > > user@pc MINGW64 /path/to/repo (BARE:master) > > the last parenthesis is printed

Re: Antw: Re: bug deleting "unmerged" branch (2.12.3)

Hi Ulrich, On Wed, 29 Nov 2017, Ulrich Windl wrote: > > On Tue, 28 Nov 2017, Ulrich Windl wrote: > > > >> During a rebase that turned out to be heavier than expected 8-( I > >> decided to keep the old branch by creating a temporary branch name to > >> the commit of the branch to rebase (which

[ANNOUNCE] Git for Windows 2.15.1

Dear Git users, It is my pleasure to announce that Git for Windows 2.15.1 is available from: https://git-for-windows.github.io/ Changes since Git for Windows v2.15.0 (October 30th 2017) New Features * Comes with Git v2.15.1. * Operations in massively-sparse worktrees are now much

[PATCH v4 4/4] exec_cmd: RUNTIME_PREFIX on some POSIX systems

Enable Git to resolve its own binary location using a variety of OS-specific and generic methods, including: - procfs via "/proc/self/exe" (Linux) - _NSGetExecutablePath (Darwin) - KERN_PROC_PATHNAME sysctl on BSDs. - argv0, if absolute (all, including Windows). This is used to enable

[PATCH v4 3/4] Makefile: add Perl runtime prefix support

Add a new Makefile flag, RUNTIME_PREFIX_PERL, which, when enabled, configures Perl scripts to locate the Git installation's Perl support libraries by resolving against the script's path, rather than hard-coding that path at build-time. Enabling RUNTIME_PREFIX_PERL overrides the system-specific

[PATCH v4 0/4] RUNTIME_PREFIX relocatable Git

Previous threads: v1: https://public-inbox.org/git/20171116170523.28696-1-...@google.com/ v2: https://public-inbox.org/git/20171119173141.4896-1-...@google.com/ v3: https://public-inbox.org/git/20171127164055.93283-1-...@google.com/ This is a small update to incorporate some Windows fixes from

[PATCH v4 1/4] Makefile: generate Perl header from template file

Currently, the generated Perl script headers are emitted by commands in the Makefile. This mechanism restricts options to introduce alternative header content, needed by Perl runtime prefix support, and obscures the origin of the Perl script header. Change the Makefile to generate a header by

[PATCH v4 2/4] Makefile: add support for "perllibdir"

Add the "perllibdir" Makefile variable, which allows the customization of the Perl library installation path. The Perl library installation path is currently left entirely to the Perl Makefile implementation, either MakeMaker (default) or a fixed path when NO_PERL_MAKEMAKER is enabled. This patch

Re: [PATCH v5 5/6] rev-list: add list-objects filtering support

On 11/22/2017 3:08 PM, Jonathan Nieder wrote: Hi, Jeff Hostetler wrote: Teach rev-list to use the filtering provided by the traverse_commit_list_filtered() interface to omit unwanted objects from the result. Object filtering is only allowed when one of the "--objects*" options are used.

[RFC/PATCH] Makefile: replace the overly complex perl build system with something simple

As the history of perl/Makefile.PL reveals the reason we have it in the first place is because during its initial development the perl bindings would link to libgit, building such a module with any sanity requires ExtUtils::MakeMaker and Devel::PPPort. However, since then this grew into a much

[PATCH v4 1/2] refactor "dumb" terminal determination

From: Lars Schneider Move the code to detect "dumb" terminals into a single location. This avoids duplicating the terminal detection code yet again in a subsequent commit. Signed-off-by: Lars Schneider --- cache.h| 1 + color.c| 3

[PATCH v4 2/2] launch_editor(): indicate that Git waits for user input

From: Lars Schneider When a graphical GIT_EDITOR is spawned by a Git command that opens and waits for user input (e.g. "git rebase -i"), then the editor window might be obscured by other windows. The user may be left staring at the original Git terminal window without

[PATCH v4 0/2] launch_editor(): indicate that Git waits for user input

From: Lars Schneider Hi, I simplified the code and enabled the "Git is waiting for editor input" message only for "intelligent" terminals. The rational is, that today's novice Git users are likely to have an "intelligent" terminal. People working with "dumb" terminals

Re: [PATCH] repository: fix a sparse 'using integer as NULL pointer' warning

On 29/11/17 01:35, brian m. carlson wrote: > On Tue, Nov 28, 2017 at 03:01:19AM +, Ramsay Jones wrote: >> >> Commit 78a6766802 ("Integrate hash algorithm support with repo setup", >> 2017-11-12) added a 'const struct git_hash_algo *hash_algo' field to the >> repository structure, without

Git filter clean not working when staging files

Hello, I've got a question or maybe bug about Git clean filter. According to documentation[1] clean should be run when staging files. When I'm staging file I see my script was run (I'm logging execution into /tmp), but file content is unmodified. My script is reading stdin and writing to stdout.

imap-send with gmail: curl_easy_perform() failed: URL using bad/illegal format or missing URL

Hi, I'm trying to send a patch with the command `git imap-send`, I used the examples in the manual page as the main reference for my configuration: ``` [imap] folder = "[Gmail]/Drafts" host = imaps://imap.gmail.com user = doron.be...@gmail.com port = 993

Re: [SCRIPT/RFC 0/3] git-commit --onto-parent (three-way merge, no working tree file changes)

Am 28.11.2017 um 02:15 schrieb Igor Djordjevic: On 27/11/2017 22:54, Johannes Sixt wrote: I my opinion, putting the focus on integration merge commits and the desire to automate the re-merge step brings in a LOT of complexity in the implementation for a very specific use-case that does not

Re: [PATCH v4 0/4] RUNTIME_PREFIX relocatable Git

> In general this whole thing structurally looks good to me with the > caveats noted in other review E-Mails. > > I haven't done anything but skim the details of the "where's my > executable" C code though, just looked at what it's doing structurally. > > I think it makes sense for this to land

Re: [PATCH v4 3/4] Makefile: add Perl runtime prefix support

On Wed, Nov 29 2017, Dan Jacques jotted: > Add a new Makefile flag, RUNTIME_PREFIX_PERL, which, when enabled, > configures Perl scripts to locate the Git installation's Perl support > libraries by resolving against the script's path, rather than > hard-coding that path at build-time. > [...] >

Re: [PATCH 3/5] rebase -i: add exec commands via the rebase--helper

Hi Liam, On Tue, 28 Nov 2017, liam Beguin wrote: > I just realized we could maybe add exec instructions only after pick > commands if we do add-exec-commands before rearrange-squash. That won't work, because the squash/fixup commands are pick commands before rearrange-squash. So you'd add one

Re: [PATCH v4 0/4] RUNTIME_PREFIX relocatable Git

On Wed, Nov 29 2017, Dan Jacques jotted: > This is a small update to incorporate some Windows fixes from Johannes. > At this point, it passes the full test suite on Linux, Mac, and FreeBSD, > as well as the Travis.ci test suites, with and without > RUNTIME_PREFIX/RUNTIME_PREFIX_PERL flags. > >

Re: [PATCH] pathspec: only match across submodule boundaries when requested

Hi Brandon, On Tue, 28 Nov 2017, Brandon Williams wrote: > Commit 74ed43711fd (grep: enable recurse-submodules to work on > objects, 2016-12-16) taught 'tree_entry_interesting()' to be able to > match across submodule boundaries in the presence of wildcards. This is > done by performing

Re: [PATCH] git-prompt: fix reading files with windows line endings

Hi Johannes, On 29 Nov 2017 15:27, Johannes Schindelin wrote: >> diff --git a/contrib/completion/git-prompt.sh >> b/contrib/completion/git-prompt.sh >> index c6cbef38c2..71a64e7959 100644 >> --- a/contrib/completion/git-prompt.sh >> +++ b/contrib/completion/git-prompt.sh >> @@ -282,7 +282,7 @@

Re: [PATCH v4 3/4] Makefile: add Perl runtime prefix support

On Wed, Nov 29 2017, Dan Jacques jotted: > + use lib split /@@PATHSEP@@/, > + ( > + $ENV{GITPERLLIB} > + || > + do { > + require FindBin; > + require File::Spec; > + my $gitexecdir_relative =

From Mrs. Serita Miner

My name is Mrs. Serita Miner is 53years old, I wish to make a donation of 3.5million dollars to you. As my doctor just confirmed to me that I have limited days to live due to the cancer problems I am suffering from. I have asked the lord to forgive me all my sins and I believe he has, because He

Re: [PATCH 4/5] rebase -i: learn to abbreviate command names

Hi Liam, On Tue, 28 Nov 2017, liam Beguin wrote: > On 27/11/17 06:04 PM, Johannes Schindelin wrote: > > > > On Sun, 26 Nov 2017, Liam Beguin wrote: > > > >> @@ -2483,7 +2491,9 @@ int sequencer_make_script(int keep_empty, FILE *out, > >>strbuf_reset(); > >>if

Re: [PATCH v3] diff: support anchoring line(s)

Hi Jonathan, On Tue, 28 Nov 2017, Jonathan Tan wrote: > @@ -4607,7 +4627,14 @@ int diff_opt_parse(struct diff_options *options, > DIFF_XDL_CLR(options, NEED_MINIMAL); > options->xdl_opts &= ~XDF_DIFF_ALGORITHM_MASK; > options->xdl_opts |= value; > +

Re: [PATCH] git-prompt: fix reading files with windows line endings

Hi Robert, On Wed, 29 Nov 2017, Robert Abel wrote: > On 29 Nov 2017 15:27, Johannes Schindelin wrote: > > > Or maybe keep with the Bash construct, but guarded behind a test that we > > area actually running in Bash? Something like > > > > test -z "$BASH" || IFS=$' \t\r\n' > > Actually,

Att! Att!! Att!!! Att!!!!

Good Day, I'm Wong Shiu a staff of Wing Hang Bank here in Hong Kong. Can i TRUST you in transferring- $13,991,674 USD? If yes do get back to me with my private email: wong.shiu...@accountant.com Best Regards

Re: [ANNOUNCE] Git for Windows 2.15.1

Hi Johannes, On 29/11/2017 14:57, Johannes Schindelin wrote: > > * It is now possible to configure nano or Notepad++ as Git's > default editor instead of vim. This seems as a really nice option, as it could\should greatly help Windows people in lowering friction in first encounter with

Re: imap-send with gmail: curl_easy_perform() failed: URL using bad/illegal format or missing URL

On Wed, Nov 29, 2017 at 10:28:32PM -0500, Jeff King wrote: > 2. Setting GIT_TRACE_CURL=1 may dump more verbose information. But one > caveat: if you get as far as authenticating, then the trace will > contain your password. We redact HTTP auth from the trace output, > but not imap

Re: [PATCH] git-prompt: fix reading files with windows line endings

> > diff --git a/contrib/completion/git-prompt.sh > > b/contrib/completion/git-prompt.sh > > index c6cbef38c2..71a64e7959 100644 > > --- a/contrib/completion/git-prompt.sh > > +++ b/contrib/completion/git-prompt.sh > > @@ -282,7 +282,7 @@ __git_eread () > > { > > local f="$1" > > shift >

[ANNOUNCE] Git for Windows 2.15.1(2), was Re:Git for Windows 2.15.1

Hi all, unfortunately, a last-minute bug slipped in: MSYS2 updated vim (including its defaults.vim, in a way that interacted badly with Git for Windows' configuration). The result was that an ugly warning is shown every time a user opens vim (which is still the default editor of Git for Windows,

Re: [ANNOUNCE] Git for Windows 2.15.1

Hi Buga, On Thu, 30 Nov 2017, Igor Djordjevic wrote: > On 29/11/2017 14:57, Johannes Schindelin wrote: > > > > * It is now possible to configure nano or Notepad++ as Git's > > default editor instead of vim. > > This seems as a really nice option, as it could\should greatly help >

Re: [PATCH] hashmap: adjust documentation to reflect reality

On Thu, Nov 30, 2017 at 12:51:41AM +0100, Johannes Schindelin wrote: > The hashmap API is just complicated enough that even at least one > long-time Git contributor has to look up how to use it every time he > finds a new use case. When that happens, it is really useful if the > provided example

Re: imap-send with gmail: curl_easy_perform() failed: URL using bad/illegal format or missing URL

On Wed, Nov 29, 2017 at 06:04:45PM -0800, Jonathan Nieder wrote: > > Password for 'imaps://doron.be...@gmail.com@imap.gmail.com': > > sending 3 messages > > curl_easy_perform() failed: URL using bad/illegal format or missing URL > > ``` > > Thanks for reporting this. I suspect this is related

Git stash (or git rev-parse) doesn't inherit the '--work-tree' parameter

Hello guys, I don't know if this is a normal behavior, so I'll just explain it here. * Behavior: from a directory OUTSIDE my git repo, I can run this command successfully: $ git --git-dir=/my/repo/path/.git --work-tree=/my/repo/path pull origin master But this one: $ git

Re: [PATCH] git-prompt: fix reading files with windows line endings

Hi Johannes, On 30 Nov 2017 01:21, Johannes Schindelin wrote: > On Wed, 29 Nov 2017, Robert Abel wrote: >> This means that it should be okay to just do >> >>> test -r "$f" && IFS=" \t\r\n" read "$@" < "$f" > > I am afraid that this won't work: when I call I managed to trick myself with that

Re: [SCRIPT/RFC 0/3] git-commit --onto-parent (three-way merge, no working tree file changes)

Hi Hannes, On 29/11/2017 20:11, Johannes Sixt wrote: > > Ok, then please explain, how this process should work in my workflow > and with the `commit --onto-parent` feature that you have in mind. I > have an integration branch (which is a throw-away type, so you can > mangle it in any way you

[PATCH] hashmap: adjust documentation to reflect reality

The hashmap API is just complicated enough that even at least one long-time Git contributor has to look up how to use it every time he finds a new use case. When that happens, it is really useful if the provided example code is correct... While at it, "fix a memory leak", avoid statements before

Re: [PATCH] hashmap: adjust documentation to reflect reality

Johannes Schindelin wrote: > The hashmap API is just complicated enough that even at least one > long-time Git contributor has to look up how to use it every time he > finds a new use case. When that happens, it is really useful if the > provided example code is correct... > > While at it, "fix a

Re: imap-send with gmail: curl_easy_perform() failed: URL using bad/illegal format or missing URL

(+cc: Nicolas) Hi, Doron Behar wrote: > I'm trying to send a patch with the command `git imap-send`, I used the > examples in the manual page as the main reference for my configuration: > > ``` > [imap] > folder = "[Gmail]/Drafts" > host = imaps://imap.gmail.com > user =

Re: [PATCH] Makefile: replace perl/Makefile.PL with simple make rules

Hi, Ævar Arnfjörð Bjarmason wrote: > Replace the perl/Makefile.PL and the fallback perl/Makefile used under > NO_PERL_MAKEMAKER=NoThanks with a much simpler implementation heavily > inspired by how the i18n infrastructure's build process works[1]. Yay! This looks exciting. One quick comment:

How hard would it be to implement sparse fetching/pulling?

Hi guys, I'm looking for ways to improve fetch/pull/clone time for large git (mono)repositories with unrelated source trees (that span across multiple services). I've found sparse checkout approach appealing and helpful for most of client-side operations (e.g. status, reset, commit, etc.) The

Re: [PATCH] git-prompt: fix reading files with windows line endings

Hi Gábor, On Thu, 30 Nov 2017, SZEDER Gábor wrote: > > > diff --git a/contrib/completion/git-prompt.sh > > > b/contrib/completion/git-prompt.sh > > > index c6cbef38c2..71a64e7959 100644 > > > --- a/contrib/completion/git-prompt.sh > > > +++ b/contrib/completion/git-prompt.sh > > > @@ -282,7

[PATCH v6 0/6] make git worktree add dwim more

The previous rounds were at https://public-inbox.org/git/20171112134305.3949-1-t.gumme...@gmail.com/, https://public-inbox.org/git/20171118181103.28354-1-t.gumme...@gmail.com/, https://public-inbox.org/git/20171118224706.13810-1-t.gumme...@gmail.com/,

[PATCH v6 5/6] worktree: add --guess-remote flag to add subcommand

Currently 'git worktree add ' creates a new branch named after the basename of the , that matches the HEAD of whichever worktree we were on when calling "git worktree add ". It's sometimes useful to have 'git worktree add behave more like the dwim machinery in 'git checkout ', i.e. check if the

[PATCH v6 6/6] add worktree.guessRemote config option

Some users might want to have the --guess-remote option introduced in the previous commit on by default, so they don't have to type it out every time they create a new worktree. Add a config option worktree.guessRemote that allows users to configure the default behaviour for themselves.

[PATCH v6 4/6] worktree: make add dwim

Currently 'git worktree add ', errors out when 'branch' is not a local branch. It has no additional dwim'ing features that one might expect. Make it behave more like 'git checkout ' when the branch doesn't exist locally, but a remote tracking branch uniquely matches the desired branch name,

[PATCH v6 3/6] worktree: add --[no-]track option to the add subcommand

Currently 'git worktree add' sets up tracking branches if '' is a remote tracking branch, and doesn't set them up otherwise, as is the default for 'git branch'. This may or may not be what the user wants. Allow overriding this behaviour with a --[no-]track flag that gets passed through to 'git

Re: [PATCH v4 2/4] Makefile: add support for "perllibdir"

On Wed, Nov 29 2017, Dan Jacques jotted: > Add the "perllibdir" Makefile variable, which allows the customization > of the Perl library installation path. > > The Perl library installation path is currently left entirely to the > Perl Makefile implementation, either MakeMaker (default) or a

Re: [PATCH on en/rename-progress] diffcore-rename: make diff-tree -l0 mean -l

Elijah Newren wrote: > On Wed, Nov 29, 2017 at 10:32 AM, Jonathan Tan > wrote: >> In the documentation of diff-tree, it is stated that the -l option >> "prevents rename/copy detection from running if the number of >> rename/copy targets exceeds the specified number".

[PATCH v6 2/6] worktree: add can be created from any commit-ish

Currently 'git worktree add' is documented to take an optional argument, which is checked out in the new worktree. However it is more generally possible to use a commit-ish as the optional argument, and check that out into the new worktree. Document that this is a possibility, as new users of

Re: [PATCH on en/rename-progress v2] diffcore-rename: make diff-tree -l0 mean -l

Jonathan Tan wrote: > In the documentation of diff-tree, it is stated that the -l option > "prevents rename/copy detection from running if the number of > rename/copy targets exceeds the specified number". The documentation > does not mention any special handling for the number 0, but the >

[PATCH] Makefile: replace perl/Makefile.PL with simple make rules

Replace the perl/Makefile.PL and the fallback perl/Makefile used under NO_PERL_MAKEMAKER=NoThanks with a much simpler implementation heavily inspired by how the i18n infrastructure's build process works[1]. The reason for having the Makefile.PL in the first place is that it was initially[2]

[PATCH v6 1/6] checkout: factor out functions to new lib file

Factor the functions out, so they can be re-used from other places. In particular these functions will be re-used in builtin/worktree.c to make git worktree add dwim more. While there add some docs to the function. Signed-off-by: Thomas Gummerer --- Makefile |

[PATCH on en/rename-progress v2] diffcore-rename: make diff-tree -l0 mean -l

In the documentation of diff-tree, it is stated that the -l option "prevents rename/copy detection from running if the number of rename/copy targets exceeds the specified number". The documentation does not mention any special handling for the number 0, but the implementation before commit

[PATCH on en/rename-progress] diffcore-rename: make diff-tree -l0 mean -l

In the documentation of diff-tree, it is stated that the -l option "prevents rename/copy detection from running if the number of rename/copy targets exceeds the specified number". The documentation does not mention any special handling for the number 0, but the implementation before commit b520abf

Re: [PATCH v4 0/2] launch_editor(): indicate that Git waits for user input

On Wed, Nov 29, 2017 at 03:37:50PM +0100, lars.schnei...@autodesk.com wrote: > + if (print_waiting_for_editor) { > + fprintf(stderr, _("hint: Waiting for your editor > input...")); > fflush(stderr); Just FYI, stderr is typically unbuffered on

Re: [PATCH on en/rename-progress] diffcore-rename: make diff-tree -l0 mean -l

On Wed, Nov 29, 2017 at 10:32 AM, Jonathan Tan wrote: > In the documentation of diff-tree, it is stated that the -l option > "prevents rename/copy detection from running if the number of > rename/copy targets exceeds the specified number". The documentation > does not

Re: [PATCH on en/rename-progress] diffcore-rename: make diff-tree -l0 mean -l

On Wed, 29 Nov 2017 10:51:20 -0800 Elijah Newren wrote: > Thanks for testing that version and sending along the fix. > > I suspect the commit referenced twice in the commit message should > have been 9f7e4bfa3b ("diff: remove silent clamp of renameLimit", > 2017-11-13) rather