Re: [PATCH v2 0/3] rebase: give precise error message

Kaartic Sivaraam writes: >> I do not think the above is a good change in the first place for at >> least two reasons. By saying , the updated text says "not just >> branches but you can also give tags and remote-tracking branches". > > I used as you could actually

Re: [PATCH v6 2/2] t5560-http-backend-noserver.sh: add CONTENT_LENGTH cases

On Tue, Nov 28, 2017 at 10:26:33PM -0500, Jeff King wrote: > On Mon, Nov 27, 2017 at 12:40:51AM +0200, Max Kirillov wrote: > That said, we already have some precedent in "git version > --build-options" to report sizes there. Can we do something like the > patch below instead of adding a new test

Re: [PATCH v6 0/2] http-backend: respect CONTENT_LENGTH as specified by rfc3875

On Mon, Nov 27, 2017 at 01:02:10PM +0900, Junio C Hamano wrote: > To recap (other than the typofix in the proposed log message), here > is what I would have as SQUASH??? on top of (or interspersed with) > v6. Thank you. I'll update it a bit later. May/should I add "Signed-off-by:" from you?

Re: git-p4: cloning with a change number does not import all files

Hi, On Mon, Nov 27, 2017 at 7:52 AM, Lars Schneider wrote: > > what is your goal here? Do you want to convert the repo to Git or do you > want to use Git to interact with a P4 repo? I want to use git to interact with a P4 repo. I am used to git tools and I prefer them

[PATCH v4 4/4] builtin/branch: strip refs/heads/ using skip_prefix

Instead of hard-coding the offset strlen("refs/heads/") to skip the prefix "refs/heads/" use the skip_prefix() function which is more communicative and verifies that the string actually starts with that prefix. Signed-off-by: Kaartic Sivaraam --- v2 and v3 of this

Re: [PATCH v6 2/2] t5560-http-backend-noserver.sh: add CONTENT_LENGTH cases

On Mon, Nov 27, 2017 at 12:40:51AM +0200, Max Kirillov wrote: > > Rather than introducing a new 'test' program, would it be possible to > > get by with just using 'printf' from the shell? > > > > % printf "%zu\n" -20 > > 18446744073709551596 > > I thought about it, of course. But, I am

Re: [PATCH v6 1/2] http-backend: respect CONTENT_LENGTH as specified by rfc3875

On Sun, Nov 26, 2017 at 09:38:12PM +0200, Max Kirillov wrote: > From: Florian Manschwetus > Date: Wed, 30 Mar 2016 10:54:21 +0200 > > http-backend reads whole input until EOF. However, the RFC 3875 specifies > that a script must read only as many bytes as

Re: [PATCH v2 0/3] rebase: give precise error message

On Wed, 2017-11-29 at 09:10 +0900, Junio C Hamano wrote: > Kaartic Sivaraam writes: > > > If is the correct substitute , I could try to send a > > patch that fixes this. > > I do not think the above is a good change in the first place for at > least two reasons. By

Re: Question regarding "next" merge

Dan Jacques writes: > I read the "what's cooking in Git" notes and saw that you were intending to > introduce this patch set into "next". Johannes pointed out some quoting errors > that break Windows builds, and I have incorporated fixes in my working copy. > > I was going to

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

Hi Johannes, On 27/11/17 06:04 PM, Johannes Schindelin wrote: > Hi Liam, > > On Sun, 26 Nov 2017, Liam Beguin wrote: > >> diff --git a/Documentation/rebase-config.txt >> b/Documentation/rebase-config.txt >> index 30ae08cb5a4b..0820b60f6e12 100644 >> --- a/Documentation/rebase-config.txt >> +++

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

Hi Peff, Thanks for taking the time to test this, I'll squash that patch in v2. On 27/11/17 06:11 PM, Jeff King wrote: > On Tue, Nov 28, 2017 at 12:04:45AM +0100, Johannes Schindelin wrote: > >>> +rebase.abbreviateCommands:: >>> + If set to true, `git rebase` will use abbreviated command

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

Hi Junio, On 27/11/17 12:19 AM, Junio C Hamano wrote: > Liam Beguin writes: > >> if (command == MAKE_SCRIPT && argc > 1) >> -return !!sequencer_make_script(keep_empty, stdout, argc, argv); >> +return !!sequencer_make_script(keep_empty,

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

Hi Johannes, Thanks for taking the time to review this. On 27/11/17 05:42 PM, Johannes Schindelin wrote: > Hi Liam, > > could I ask for a favor? I'd like the oneline to start with > > rebase -i -x: ... > > (this would help future me to realize what this commit touches already > from the

Re: [PATCH v3] launch_editor(): indicate that Git waits for user input

On Mon, Nov 27, 2017 at 06:05:20PM -0500, Jeff King wrote: > On Mon, Nov 27, 2017 at 08:09:32PM +, brian m. carlson wrote: > > > > Show a message in the original terminal and get rid of it when the > > > editor returns. > > [...] > > > > Sorry for coming to the topic so late, but it occurred

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

Hi Junio, On 27/11/17 12:14 AM, Junio C Hamano wrote: > Liam Beguin writes: > >> diff --git a/sequencer.c b/sequencer.c >> index fa94ed652d2c..810b7850748e 100644 >> --- a/sequencer.c >> +++ b/sequencer.c >> @@ -2492,6 +2492,52 @@ int sequencer_make_script(int keep_empty,

Re: [PATCH 0/5] rebase -i: add config to abbreviate command names

Hi Junio, On 27/11/17 12:23 AM, Junio C Hamano wrote: > Liam Beguin writes: > >> Liam Beguin (5): >> Documentation: move rebase.* configs to new file >> Documentation: use preferred name for the 'todo list' script >> rebase -i: add exec commands via the

[PATCH] strbuf: Remove unused stripspace function alias

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 branches had time to switch over. They have had time, so remove the old alias.

[PATCH v4 29/34] merge-recursive: avoid clobbering untracked files with directory renames

Signed-off-by: Elijah Newren --- merge-recursive.c | 42 +++-- t/t6043-merge-rename-directories.sh | 6 +++--- 2 files changed, 43 insertions(+), 5 deletions(-) diff --git a/merge-recursive.c b/merge-recursive.c index

[PATCH v4 08/34] directory rename detection: files/directories in the way of some renames

Signed-off-by: Elijah Newren --- t/t6043-merge-rename-directories.sh | 320 1 file changed, 320 insertions(+) diff --git a/t/t6043-merge-rename-directories.sh b/t/t6043-merge-rename-directories.sh index 1dcf010aa6..29b2af7f19 100755 ---

[PATCH v4 07/34] directory rename detection: partially renamed directory testcase/discussion

Signed-off-by: Elijah Newren --- t/t6043-merge-rename-directories.sh | 104 1 file changed, 104 insertions(+) diff --git a/t/t6043-merge-rename-directories.sh b/t/t6043-merge-rename-directories.sh index 0ccabed4a2..1dcf010aa6 100755 ---

[PATCH v4 01/34] Tighten and correct a few testcases for merging and cherry-picking

t3501 had a testcase originally added in 05f2dfb965 (cherry-pick: demonstrate a segmentation fault, 2016-11-26) to ensure cherry-pick wouldn't segfault when working with a dirty file involved in a rename. While the segfault was fixed, there was another problem this test demonstrated: namely, that

[PATCH v4 34/34] merge-recursive: ensure we write updates for directory-renamed file

When a file is present in HEAD before the merge and the other side of the merge does not modify that file, we try to avoid re-writing the file and making it stat-dirty. However, when a file is present in HEAD before the merge and was in a directory that was renamed by the other side of the merge,

[PATCH v4 09/34] directory rename detection: testcases checking which side did the rename

Signed-off-by: Elijah Newren --- t/t6043-merge-rename-directories.sh | 321 1 file changed, 321 insertions(+) diff --git a/t/t6043-merge-rename-directories.sh b/t/t6043-merge-rename-directories.sh index 29b2af7f19..5db2986de8 100755 ---

[PATCH v4 20/34] merge-recursive: add a new hashmap for storing directory renames

This just adds dir_rename_entry and the associated functions; code using these will be added in subsequent commits. Signed-off-by: Elijah Newren --- merge-recursive.c | 35 +++ merge-recursive.h | 8 2 files changed, 43 insertions(+)

[PATCH v4 30/34] merge-recursive: fix overwriting dirty files involved in renames

This fixes an issue that existed before my directory rename detection patches that affects both normal renames and renames implied by directory rename detection. Additional codepaths that only affect overwriting of directy files that are involved in directory rename detection will be added in a

[PATCH v4 27/34] merge-recursive: when comparing files, don't include trees

get_renames() would look up stage data that already existed (populated in get_unmerged(), taken from whatever unpack_trees() created), and if it didn't exist, would call insert_stage_data() to create the necessary entry for the given file. The insert_stage_data() fallback becomes much more

[PATCH v4 32/34] directory rename detection: new testcases showcasing a pair of bugs

Add a testcase showing spurious rename/rename(1to2) conflicts occurring due to directory rename detection. Also add a pair of testcases dealing with moving directory hierarchies around that were suggested by Stefan Beller as "food for thought" during his review of an earlier patch series, but

[PATCH v4 21/34] merge-recursive: make a helper function for cleanup for handle_renames

In anticipation of more involved cleanup to come, make a helper function for doing the cleanup at the end of handle_renames. Rename the already existing cleanup_rename[s]() to final_cleanup_rename[s](), name the new helper initial_cleanup_rename(), and leave the big comment in the code about why

[PATCH v4 10/34] directory rename detection: more involved edge/corner testcases

Signed-off-by: Elijah Newren --- t/t6043-merge-rename-directories.sh | 381 1 file changed, 381 insertions(+) diff --git a/t/t6043-merge-rename-directories.sh b/t/t6043-merge-rename-directories.sh index 5db2986de8..2c57a02c6d 100755 ---

[PATCH v4 16/34] merge-recursive: introduce new functions to handle rename logic

The amount of logic in merge_trees() relative to renames was just a few lines, but split it out into new handle_renames() and cleanup_renames() functions to prepare for additional logic to be added to each. No code or logic changes, just a new place to put stuff for when the rename detection

[PATCH v4 33/34] merge-recursive: avoid spurious rename/rename conflict from dir renames

If a file on one side of history was renamed, and merely modified on the other side, then applying a directory rename to the modified side gives us a rename/rename(1to2) conflict. We should only apply directory renames to pairs representing either adds or renames. Making this change means that a

[PATCH v4 14/34] directory rename detection: tests for handling overwriting dirty files

Signed-off-by: Elijah Newren --- t/t6043-merge-rename-directories.sh | 436 1 file changed, 436 insertions(+) diff --git a/t/t6043-merge-rename-directories.sh b/t/t6043-merge-rename-directories.sh index 00b0ee7f08..0644b95ec5 100755 ---

[PATCH v4 04/34] directory rename detection: basic testcases

Signed-off-by: Elijah Newren --- t/t6043-merge-rename-directories.sh | 430 1 file changed, 430 insertions(+) create mode 100755 t/t6043-merge-rename-directories.sh diff --git a/t/t6043-merge-rename-directories.sh

[PATCH v4 06/34] directory rename detection: testcases to avoid taking detection too far

Signed-off-by: Elijah Newren --- t/t6043-merge-rename-directories.sh | 150 1 file changed, 150 insertions(+) diff --git a/t/t6043-merge-rename-directories.sh b/t/t6043-merge-rename-directories.sh index 335aa1c145..0ccabed4a2 100755 ---

[PATCH v4 26/34] merge-recursive: check for file level conflicts then get new name

Before trying to apply directory renames to paths within the given directories, we want to make sure that there aren't conflicts at the file level either. If there aren't any, then get the new name from any directory renames. Signed-off-by: Elijah Newren --- merge-recursive.c

[PATCH v4 11/34] directory rename detection: testcases exploring possibly suboptimal merges

Signed-off-by: Elijah Newren --- t/t6043-merge-rename-directories.sh | 394 1 file changed, 394 insertions(+) diff --git a/t/t6043-merge-rename-directories.sh b/t/t6043-merge-rename-directories.sh index 2c57a02c6d..fc9b13c37d 100755 ---

[PATCH v4 02/34] merge-recursive: fix logic ordering issue

merge_trees() did a variety of work, including: * Calling get_unmerged() to get unmerged entries * Calling record_df_conflict_files() with all unmerged entries to do some work to ensure we could handle D/F conflicts correctly * Calling get_renames() to check for renames. An easily

[PATCH v4 25/34] merge-recursive: add computation of collisions due to dir rename & merging

directory renaming and merging can cause one or more files to be moved to where an existing file is, or to cause several files to all be moved to the same (otherwise vacant) location. Add checking and reporting for such cases, falling back to no-directory-rename handling for such paths.

[PATCH v4 05/34] directory rename detection: directory splitting testcases

Signed-off-by: Elijah Newren --- t/t6043-merge-rename-directories.sh | 137 1 file changed, 137 insertions(+) diff --git a/t/t6043-merge-rename-directories.sh b/t/t6043-merge-rename-directories.sh index d8ead7c56b..335aa1c145 100755 ---

[PATCH v4 31/34] merge-recursive: fix remaining directory rename + dirty overwrite cases

Signed-off-by: Elijah Newren --- merge-recursive.c | 26 +++--- t/t6043-merge-rename-directories.sh | 8 2 files changed, 27 insertions(+), 7 deletions(-) diff --git a/merge-recursive.c b/merge-recursive.c index

[PATCH v4 17/34] merge-recursive: fix leaks of allocated renames and diff_filepairs

get_renames() has always zero'ed out diff_queued_diff.nr while only manually free'ing diff_filepairs that did not correspond to renames. Further, it allocated struct renames that were tucked away in the return string_list. Make sure all of these are deallocated when we are done with them.

[PATCH v4 23/34] merge-recursive: check for directory level conflicts

Before trying to apply directory renames to paths within the given directories, we want to make sure that there aren't conflicts at the directory level. There will be additional checks at the individual file level too, which will be added later. Signed-off-by: Elijah Newren

[PATCH v4 00/34] Add directory rename detection to git

This patchset introduces directory rename detection to merge-recursive. See https://public-inbox.org/git/20171110190550.27059-1-new...@gmail.com/ for the first series (including design considerations, etc.), and follow-up series can be found at

[PATCH v4 28/34] merge-recursive: apply necessary modifications for directory renames

This commit hooks together all the directory rename logic by making the necessary changes to the rename struct, it's dst_entry, and the diff_filepair under consideration. Signed-off-by: Elijah Newren --- merge-recursive.c | 187

[PATCH v4 12/34] directory rename detection: miscellaneous testcases to complete coverage

I came up with the testcases in the first eight sections before coding up the implementation. The testcases in this section were mostly ones I thought of while coding/debugging, and which I was too lazy to insert into the previous sections because I didn't want to re-label with all the testcase

[PATCH v4 13/34] directory rename detection: tests for handling overwriting untracked files

Signed-off-by: Elijah Newren --- t/t6043-merge-rename-directories.sh | 337 1 file changed, 337 insertions(+) diff --git a/t/t6043-merge-rename-directories.sh b/t/t6043-merge-rename-directories.sh index 42228a60aa..00b0ee7f08 100755 ---

[PATCH v4 18/34] merge-recursive: make !o->detect_rename codepath more obvious

Previously, if !o->detect_rename then get_renames() would return an empty string_list, and then process_renames() would have nothing to iterate over. It seems more straightforward to simply avoid calling either function in that case. Signed-off-by: Elijah Newren ---

[PATCH v4 03/34] merge-recursive: add explanation for src_entry and dst_entry

If I have to walk through the debugger and inspect the values found in here in order to figure out their meaning, despite having known these things inside and out some years back, then they probably need a comment for the casual reader to explain their purpose. Signed-off-by: Elijah Newren

[PATCH v4 22/34] merge-recursive: add get_directory_renames()

This populates a list of directory renames for us. The list of directory renames is not yet used, but will be in subsequent commits. Signed-off-by: Elijah Newren --- merge-recursive.c | 155 -- 1 file changed, 152

[PATCH v4 19/34] merge-recursive: split out code for determining diff_filepairs

Create a new function, get_diffpairs() to compute the diff_filepairs between two trees. While these are currently only used in get_renames(), I want them to be available to some new functions. No actual logic changes yet. Signed-off-by: Elijah Newren --- merge-recursive.c |

[PATCH v4 15/34] merge-recursive: move the get_renames() function

I want to re-use some other functions in the file without moving those other functions or dealing with a handful of annoying split function declarations and definitions. Signed-off-by: Elijah Newren --- merge-recursive.c | 139

[PATCH v4 24/34] merge-recursive: add a new hashmap for storing file collisions

Directory renames with the ability to merge directories opens up the possibility of add/add/add/.../add conflicts, if each of the N directories being merged into one target directory all had a file with the same name. We need a way to check for and report on such collisions; this hashmap will be

Question regarding "next" merge

Junio, I read the "what's cooking in Git" notes and saw that you were intending to introduce this patch set into "next". Johannes pointed out some quoting errors that break Windows builds, and I have incorporated fixes in my working copy. I was going to hold off on publishing v4 in case some of

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

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 modifying the initializer of the 'the_repo' >

What's cooking in git.git (Nov 2017, #08; Tue, 28)

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. Git 2.15.1 has been tagged, with

A note from the maintainer

Welcome to the Git development community. This message is written by the maintainer and talks about how Git project is managed, and how you can work with it. * Mailing list and the community The development is primarily done on the Git mailing list. Help requests, feature proposals, bug reports

[ANNOUNCE] Git v2.15.1

The latest maintenance release Git v2.15.1 is now available at the usual places. The tarballs are found at: https://www.kernel.org/pub/software/scm/git/ The following public repositories all have a copy of the 'v2.15.1' tag and the 'maint' branch that the tag points at: url =

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 in addition

[PATCH] pretty: fix buffer over-read with %> and %

A buffer over-read of the format string would occur with unterminated formats of the form '%>(#' and '%<(#', where '#' represents a number. This error can be witnessed by running git log under valgrind like so: valgrind git log -n1 --format='%<(42' This was due to the fact that the "not

Re: [PATCH v2 0/3] rebase: give precise error message

Kaartic Sivaraam writes: > Something like the following diff with additional changes to other > places that refer to , > > diff --git a/Documentation/git-rebase.txt b/Documentation/git-rebase.txt > index 67d48e688..ba4a545bf 100644 > --- a/Documentation/git-rebase.txt

Re: [PATCH] travis-ci: avoid new tcl/tk build requirement

Todd Zullinger writes: > I pulled the travis docker image used in clang/gcc builds[1] and can > see it has both tcl and tk packages installed. The linux32 builds use > a docker image[2] which does not contain tcl or tk. > > [1] travisci/ci-garnet:packer-1503972846 > [2]

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

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 literal matching up to the first wildcard and then punting to the

Re: Bug in pathspec handling (in conjunction with submodules)

On 11/26, Johannes Schindelin wrote: > Hi Duy & Brandon, > > in 74ed43711fd (grep: enable recurse-submodules to work on objects, > 2016-12-16), the do_match() function in tree-walk.c was changed so that it > can recurse across submodule boundaries. > > However, there is a bug, and I *think*

[add-default-config] add --default option to git config.

From: Soukaina NAIT HMID Signed-off-by: Soukaina NAIT HMID --- Documentation/git-config.txt | 4 ++ builtin/config.c | 34 - config.c | 10 +++ config.h | 1 +

[PATCH 2/4] sha1dc_git.h: re-arrange an ifdef chain for a subsequent change

A subsequent change will change the semantics of DC_SHA1_SUBMODULE in a way that would require moving these checks around, so start by moving them around without any functional changes. Signed-off-by: Ævar Arnfjörð Bjarmason --- sha1dc_git.h | 6 +++--- 1 file changed, 3

[PATCH 0/4] SHA1DC fixes & fully moving to a git.git submodule

We've now had a couple of Git releases where we've used sha1collisiondetection/ if it's checked out, but have gracefully fallen back on sha1dc/ if it's not there. This series makes it a hard requirement, without 4/4 you'll still be able to do NO_DC_SHA1_SUBMODULE=UnfortunatelyYes, but with it

[PATCH 1/4] Makefile: don't error out under DC_SHA1_EXTERNAL if DC_SHA1_SUBMODULE=auto

Fix a logic error in the initial introduction of DC_SHA1_EXTERNAL. If git.git has a sha1collisiondetection submodule checked out the logic to set DC_SHA1_SUBMODULE=auto would interact badly with the check for whether DC_SHA1_SUBMODULE was set. It would error out, meaning that there's no way to

[PATCH 3/4] Makefile: use the sha1collisiondetection submodule by default

Change the build process so that instead of needing to supply DC_SHA1_SUBMODULE=YesPlease to use the sha1collisiondetection submodule instead of the copy of the same code shipped in the sha1dc directory, it uses the submodule by default unless NO_DC_SHA1_SUBMODULE=UnfortunatelyYes is supplied.

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

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 over the beginning of the prompt like )ser@pc MINGW64

git-prompt: fix reading files with windows line endings

I noticed today that my git prompt using msys-git on Windows got a bit broken. After investigating I found that the git-prompt doesn't handle the case when __git_eread reads Windows line endings \r\n. It will only strip \n, leaving the \r. I noticed this when I created a repository with msys-git,

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

Teach diff a new algorithm, one that attempts to prevent user-specified lines from appearing as a deletion or addition in the end result. The end user can use this by specifying "--anchored=" one or more times when using Git commands like "diff" and "show". Signed-off-by: Jonathan Tan

Re: Feature request: Reduce amount of diff in patch

On Tue, 2017-11-28 at 18:09 +0200, KES wrote: > Hi. > > I get often patches which can be minimized: > I guess the one below can't be (see below). > @@ -60,11 +64,8 @@ sub _get_filter { > address=> { -like => \[ '?', "%$search%" ] }, > company=> { -like => \[ '?',

Re: [PATCH v2 3/3] rebase: rebasing can also be done when HEAD is detached

On Tue, 2017-11-28 at 11:31 +0900, Junio C Hamano wrote: > Kaartic Sivaraam writes: > > > + if test "$branch_or_commit" = "HEAD" && > > +!(git symbolic-ref -q HEAD) > > Did you need a subshell here? No. That's a consequence of me not

Re: [RFC PATCH v2] builtin/worktree: enhance worktree removal

On Tuesday 28 November 2017 09:34 AM, Junio C Hamano wrote: Eric Sunshine writes: With this approach, validate_worktree() will print an error message saying that the worktree directory is missing before the control info is actually removed. Kaartic's original patch

[PATCH v3 2/2] Doc/check-ref-format: clarify information about @{-N} syntax

When the N-th previous thing checked out syntax (@{-N}) is used with '--branch' option of check-ref-format the result might not always be a valid branch name (see NOTE below). This is because @{-N} is used to refer to the N-th last checked out "thing" which might be any commit (sometimes a

Feature request: Reduce amount of diff in patch

Hi. I get often patches which can be minimized: @@ -60,11 +64,8 @@ sub _get_filter { address=> { -like => \[ '?', "%$search%" ] }, company=> { -like => \[ '?', "%$search%" ] }, country_code => { '=' => \[ 'UPPER(?)' => $search ] }, -]); -$users =

Re: [PATCH] travis-ci: avoid new tcl/tk build requirement

Christian Couder wrote: Junio C Hamano wrote: It seems that TravisCI objects ;-) https://travis-ci.org/git/git/jobs/307745929 Interesting that the main builds passed. I don't know what the default 64-bit linuxinstall looks like in travis, so I presume it includes tcl/tk or something.

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). > > When done

GET BACK TO ME FOR YOUR ATM CARD

3 Whitehall Court London SW1A 2EL United Kingdom Attention:Beneficairy. NOTE: If you received this message in your SPAM/BULK folder, it is because of the restrictions imposed by your Mail/Internet Service Provider, we urge you to treat it genuinely. How are you today? Hope all is well with you

Re: [PATCH] travis-ci: avoid new tcl/tk build requirement

On Tue, Nov 28, 2017 at 3:37 PM, Todd Zullinger wrote: > A build requirement on tcl/tk was added in 01c54284f1 (Makefile: check > that tcl/tk is installed, 2017-11-20). For building and running the > tests, we don't need tcl/tk installed. Bypass the requirement. > >

DIRECTOR IN CHARGE: DR.PATRICE TEME

UN Visitor Centre Department of Public Information United Nations Headquarters Room DHL-1B-154 New York, NY 10017 E-mail:un...@teewars.org United Nations Compensation Unit, In Affiliation with World Bank Our Ref: UN/WBO/042UK/2015. Congratulations Beneficiary, How are you today Hope all is

DIRECTOR IN CHARGE: DR.PATRICE TEME

UN Visitor Centre Department of Public Information United Nations Headquarters Room DHL-1B-154 New York, NY 10017 E-mail:un...@teewars.org United Nations Compensation Unit, In Affiliation with World Bank Our Ref: UN/WBO/042UK/2015. Congratulations Beneficiary, How are you today Hope all is

Re: [PATCH v2 2/2] Doc/check-ref-format: clarify information about @{-N} syntax

On Tue, 2017-11-28 at 11:40 +0900, Junio C Hamano wrote: > Kaartic Sivaraam writes: > > > When the N-th previous thing checked out sytax is used with > > '--branch' option of check-ref-format the results might not > > always be a valid branch name > > I wonder if you

[PATCH] travis-ci: avoid new tcl/tk build requirement

A build requirement on tcl/tk was added in 01c54284f1 (Makefile: check that tcl/tk is installed, 2017-11-20). For building and running the tests, we don't need tcl/tk installed. Bypass the requirement. Signed-off-by: Todd Zullinger --- Junio C Hamano wrote: > It seems that

Re: [PATCH] git-gui: Prevent double UTF-8 conversion

Hi Łukasz, On Tue, 28 Nov 2017, Łukasz Stelmach wrote: > Set encoding to utf-8 for file descriptors used to receive data from git > commands. The patch only changes it for the `cat-file` command used to read the latest commit message for amending. Maybe the commit message should be adjusted to

bug deleting "unmerged" branch (2.12.3)

Hi! 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). When done rebasing, I attached a new name to the new (rebased) branch,

DIRECTOR IN CHARGE: DR.PATRICE TEME

UN Visitor Centre Department of Public Information United Nations Headquarters Room DHL-1B-154 New York, NY 10017 E-mail:un...@teewars.org United Nations Compensation Unit, In Affiliation with World Bank Our Ref: UN/WBO/042UK/2015. Congratulations Beneficiary, How are you today Hope all is

DIRECTOR IN CHARGE: DR.PATRICE TEME

UN Visitor Centre Department of Public Information United Nations Headquarters Room DHL-1B-154 New York, NY 10017 E-mail:un...@teewars.org United Nations Compensation Unit, In Affiliation with World Bank Our Ref: UN/WBO/042UK/2015. Congratulations Beneficiary, How are you today Hope all is

DIRECTOR IN CHARGE: DR.PATRICE TEME

UN Visitor Centre Department of Public Information United Nations Headquarters Room DHL-1B-154 New York, NY 10017 E-mail:un...@teewars.org United Nations Compensation Unit, In Affiliation with World Bank Our Ref: UN/WBO/042UK/2015. Congratulations Beneficiary, How are you today Hope all is

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

Hi Dan, and (based on the timezone recorded in your mail:) good morning! On Mon, 27 Nov 2017, Dan Jacques wrote: > > In Git for Windows, we have an almost identical patch: > > > > https://github.com/git-for-windows/git/commit/bdd739bb2b0b > > > > We just guard the call to system_path() behind a

DIRECTOR IN CHARGE: DR.PATRICE TEME

UN Visitor Centre Department of Public Information United Nations Headquarters Room DHL-1B-154 New York, NY 10017 E-mail:un...@teewars.org United Nations Compensation Unit, In Affiliation with World Bank Our Ref: UN/WBO/042UK/2015. Congratulations Beneficiary, How are you today Hope all is

Re: [PATCH v2 0/3] rebase: give precise error message

On Tue, 2017-11-28 at 11:25 +0900, Junio C Hamano wrote: > Kaartic Sivaraam writes: > > > 1. "git rebase " does nothing > > Not limited to "rebase", you do not muck with remote-tracking branch > in your local repository, so it would be a bug if the above updated >

Re: [PATCH v3] launch_editor(): indicate that Git waits for user input

> On 28 Nov 2017, at 00:18, Junio C Hamano wrote: > > lars.schnei...@autodesk.com writes: > >> diff to v2: >>- shortened and localized the "waiting" message >>- detect "emacsclient" and suppress "waiting" message > > Thanks for moving this forward. > > >> +

Re: [PATCH v3] launch_editor(): indicate that Git waits for user input

> On 28 Nov 2017, at 00:05, Jeff King wrote: > > On Mon, Nov 27, 2017 at 08:09:32PM +, brian m. carlson wrote: > >>> Show a message in the original terminal and get rid of it when the >>> editor returns. >> [...] >> >> Sorry for coming to the topic so late, but it occurred

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

Hi Junio, On Tue, 28 Nov 2017, Junio C Hamano wrote: > Dan Jacques writes: > > >> In Git for Windows, we have an almost identical patch: > >> > >> https://github.com/git-for-windows/git/commit/bdd739bb2b0b > >> > >> We just guard the call to system_path() behind a test whether

Re: [PATCH] Use OBJECT_INFO_QUICK to speedup git fetch-pack

Hi, Thank you for merging! Takuto 2017-11-28 20:27 GMT+09:00 Johannes Schindelin : > Hi, > > On Tue, 28 Nov 2017, Takuto Ikuta wrote: > >> As long as this PR is included in next Git for Windows release, I >> won't suffer from slow git fetch. >>

Re: [PATCH] Use OBJECT_INFO_QUICK to speedup git fetch-pack

Hi, On Tue, 28 Nov 2017, Takuto Ikuta wrote: > As long as this PR is included in next Git for Windows release, I > won't suffer from slow git fetch. > https://github.com/git-for-windows/git/pull/1372 > > But I sent you 2 PRs to follow right way. >

[PATCH] git-gui: Prevent double UTF-8 conversion

Set encoding to utf-8 for file descriptors used to receive data from git commands. With encoding on the file descriptor set to "binary" Tcl (8.6 in my case) does double conversion which breaks e.g. author name in amended commits. For example "\305\201ukasz" (as written by git cat-file) becomes