Speed of git branch --contains

Hi everybody, I'm just looking at some scripts that do a 'git branch --contains $id --remote' for each new commit in a repo, and unfortunately each invokation already takes four minutes. It feels like git branch does the reachability detection separately for each branch potentially listed. The

Problem with git and proxy server with authentication

Hi. (sory for my english - it's not native for me) I use proxy-server with authentication. I have two instances of PortableGit: version 2.10.0.windows.1 and 2.16.1.windows.1 I added proxy settings in ~/.gitconfig. If I try to pull my repository with version 2.16.1.windows.1 , I get error

Re: [PATCH v6] mru: Replace mru.[ch] with list.h implementation

On Tue, Jan 23, 2018 at 06:46:51PM -0500, Gargi Sharma wrote: > Replace the custom calls to mru.[ch] with calls to list.h. This patch is > the final step in removing the mru API completely and inlining the logic. > This patch leads to significant code reduction and the mru API hence, is > not a

Re: [PATCH] mailinfo: avoid segfault when can't open files

On Tue, Jan 23, 2018 at 11:54:17PM -0300, Juan F. Codagnone wrote: > If or files can't be opened, clear_mailinfo crash as > it follows NULL pointers. > > Can be reproduced using `git mailinfo . .` Thanks for finding this. Looking at the offending code and your solution, it looks like: 1.

[PATCH] mailinfo: avoid segfault when can't open files

If or files can't be opened, clear_mailinfo crash as it follows NULL pointers. Can be reproduced using `git mailinfo . .` Signed-off-by: Juan F. Codagnone --- mailinfo.c | 10 ++ 1 file changed, 6 insertions(+), 4 deletions(-) diff --git a/mailinfo.c

Your long awaited part payment of $2.5.000.00Usd

Attention: Beneficiary, Your long awaited part payment of $2.5.000.00Usd (TWO MILLION FIVE Hundred Thousand United State Dollars) is ready for immediate release to you, and it was electronically credited into an ATM Visa Card for easy delivery. Your new Payment Reference No.- 6363836, Password

Re: [PATCH 5/5] travis-ci: don't fail if user already exists on 32 bit Linux build job

On Tue, Jan 23, 2018 at 11:46 PM, Jeff King wrote: >> The build job on Travis CI always starts with a fresh Docker >> container, so this change doesn't make a difference there. > > I wonder if that is fixable. Installing dependencies into the container > takes quite a lot of time,

[PATCH v6] mru: Replace mru.[ch] with list.h implementation

Replace the custom calls to mru.[ch] with calls to list.h. This patch is the final step in removing the mru API completely and inlining the logic. This patch leads to significant code reduction and the mru API hence, is not a useful abstraction anymore. Signed-off-by: Gargi Sharma

What's cooking in git.git (Jan 2018, #03; Tue, 23)

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. Many topics in 'next' have been

[PATCH v3 04/11] fetch tests: re-arrange arguments for future readability

Re-arrange the arguments to the test_configured_prune() function used in this test to pass the arguments to --fetch last. A subsequent change will test for more elaborate fetch arguments, including long refspecs. It'll be more readable to be able to wrap those on a new line of their own.

[PATCH v3 08/11] git remote doc: correct dangerous lies about what prune does

The "git remote prune " command uses the same machinery as "git fetch --prune", and shares all the same caveats, but its documentation has suggested that it'll just "delete stale remote-tracking branches under ". This isn't true, and hasn't been true since at least v1.8.5.6 (the oldest version I

[PATCH v3 00/11] document & test fetch pruning & add fetch.pruneTags

Addresses Junio's comments on v2 + more fixes. The Ævar Arnfjörð Bjarmason (11): fetch: don't redundantly NULL something calloc() gave us fetch: stop accessing "remote" variable indirectly Moved these patches to the beginning. No changes except a note to the commit message saying how these

[PATCH v3 01/11] fetch: don't redundantly NULL something calloc() gave us

Stop redundantly NULL-ing the last element of the refs structure, which was retrieved via calloc(), and is thus guaranteed to be pre-NULL'd. This code dates back to b888d61c83 ("Make fetch a builtin", 2007-09-10), where wasn't any reason to do this back then either, it's just something left over

[PATCH v3 06/11] fetch tests: test --prune and refspec interaction

Add a test for the interaction between explicitly provided refspecs and fetch.prune. There's no point in adding this boilerplate to every combination of unset/false/true, it's instructive and sufficient to show that no matter if the variable is unset, false or true the refspec on the command-line

[PATCH v3 11/11] fetch: add a --fetch-prune option and fetch.pruneTags config

Add a --fetch-prune option to git-fetch, along with fetch.pruneTags config option. This allows for doing any of: git fetch -p -P git fetch --prune --prune-tags git fetch -p -P origin git fetch --prune --prune-tags origin Or simply: git config fetch.prune true && git

[PATCH v3 10/11] fetch tests: add scaffolding for the new fetch.pruneTags

The fetch.pruneTags configuration doesn't exist yet, but will be added in a subsequent commit. Since testing for it requires adding new parameters to the test_configured_prune function it's easier to review this patch first to assert that no functional changes are introduced yet. Signed-off-by:

[PATCH v3 09/11] git-fetch & config doc: link to the new PRUNING section

Amend the documentation for fetch.prune, fetch..prune and --prune to link to the recently added PRUNING section. I'd have liked to link directly to it with "<>" from fetch-options.txt, since it's included in git-fetch.txt (git-pull.txt also includes it, but doesn't include that option). However

[PATCH v3 05/11] fetch tests: add a tag to be deleted to the pruning tests

Add a tag to be deleted to the fetch --prune tests. The tag is always kept for now, which is the expected behavior, but now I can add a test for tag pruning in a later commit. Signed-off-by: Ævar Arnfjörð Bjarmason --- t/t5510-fetch.sh | 93

[PATCH v3 07/11] git fetch doc: add a new section to explain the ins & outs of pruning

Add a new section to canonically explain how remote reference pruning works, and how users should be careful about using it in conjunction with tag refspecs in particular. A subsequent commit will update the git-remote documentation to refer to this section, and details the motivation for writing

[PATCH v3 02/11] fetch: stop accessing "remote" variable indirectly

Access the "remote" variable passed to the fetch_one() directly rather than through the gtransport wrapper struct constructed in this function for other purposes. This makes the code more readable, as it's now obvious that the remote struct doesn't somehow get munged by the prepare_transport()

[PATCH v3 03/11] fetch tests: refactor in preparation for testing tag pruning

In a subsequent commit this function will learn to test for tag pruning, prepare for that by making space for more variables, and making it clear that "expected" here refers to branches. Signed-off-by: Ævar Arnfjörð Bjarmason --- t/t5510-fetch.sh | 9 ++--- 1 file changed,

Re: [PATCH] daemon: add --no-syslog to undo implicit --syslog

Thanks for your responses! On 23.01.2018 01:00, Ævar Arnfjörð Bjarmason wrote: > This patch looks good, but I wonder if with the rise of systemd > there's a good reason to flip the default around to not having other > stuff imply --syslog, and have users specify this implictly, then we > won't

HELLO

-- Hello Dear Friend, Greetings and how are you doing? I want to know if you are keen to be my partner in claiming the fortune $12.8 Million USD left by a late client. If you're interested revert for more details. Awaiting your reply Hamza Kabore

Re: [PATCH v4 5/6] convert: add 'working-tree-encoding' attribute

Jeff King writes: > But with Coccinelle, it's a lot easier to apply the change tree-wide, and > to convert topics in flight as they get merged. The maintainer still > gets conflicts with topics-in-flight that touch converted areas, though. > So I'd be curious to hear if Junio's

Re: [PATCH v4 0/6] convert: add support for different encodings

Torsten Bögershausen writes: > On Sat, Jan 20, 2018 at 04:24:12PM +0100, lars.schnei...@autodesk.com wrote: >> From: Lars Schneider >> >> Hi, >> >> Patches 1-4 and 6 are preparation and helper functions. >> Patch 5 is the actual change. > > I (still)

RE: [PATCH v2 0/6] Force pipes to flush immediately on NonStop platform

On January 23, 2018 1:13 PM, Junio C Hamano wrote: > "Randall S. Becker" writes: > > >> IOW, I do not see it explained clearly why this change is needed on > >> any single platform---so "that issue may be shared by others, too" > >> is a bit premature thing for me to

Re: [PATCH 0/8] rebase -i: offer to recreate merge commits

Johannes Schindelin writes: > My original attempt was --preserve-merges, but that design was so > limited that I did not even enable it in interactive mode. > ... > There are more patches in the pipeline, based on this patch series, but > left for later in the

Re: [PATCH 6/8] sequencer: handle autosquash and post-rewrite for merge commands

Jacob Keller writes: >> static int is_per_worktree_ref(const char *refname) >> { >> return !strcmp(refname, "HEAD") || >> - starts_with(refname, "refs/bisect/"); >> + starts_with(refname, "refs/bisect/") || >> +

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

Johannes Schindelin writes: > diff --git a/Documentation/git-rebase.txt b/Documentation/git-rebase.txt > index 8a861c1e0d6..1d061373288 100644 > --- a/Documentation/git-rebase.txt > +++ b/Documentation/git-rebase.txt > @@ -368,6 +368,11 @@ The commit list format can

Re: [PATCH v4 0/6] convert: add support for different encodings

On Sat, Jan 20, 2018 at 04:24:12PM +0100, lars.schnei...@autodesk.com wrote: > From: Lars Schneider > > Hi, > > Patches 1-4 and 6 are preparation and helper functions. > Patch 5 is the actual change. I (still) have 2 remarks on convert.c - to make live easier, I will

Re: [PATCH 4/8] rebase-helper --make-script: introduce a flag to recreate merges

Eric Sunshine writes: >> + is_octopus = to_merge && to_merge->next; >> + >> + if (is_octopus) >> + BUG("Octopus merges not yet supported"); > > Is this a situation which the end-user can trigger by specifying a > merge

Re: [PATCH 4/8] rebase-helper --make-script: introduce a flag to recreate merges

Johannes Schindelin writes: > The sequencer just learned a new commands intended to recreate branch s/a //; > structure (similar in spirit to --preserve-merges, but with a > substantially less-broken design). > ... > @@ -2785,6 +2787,335 @@ void

Re: [PATCH 3/8] sequencer: fast-forward merge commits, if possible

Phillip Wood writes: > On 18/01/18 15:35, Johannes Schindelin wrote: >> >> Just like with regular `pick` commands, if we are trying to recreate a >> merge commit, we now test whether the parents of said commit match HEAD >> and the commits to be merged, and

Re: [PATCH 3/8] sequencer: fast-forward merge commits, if possible

Johannes Schindelin writes: > + /* > + * If HEAD is not identical to the parent of the original merge commit, > + * we cannot fast-forward. > + */ > + can_fast_forward = commit && commit->parents && > +

Re: [PATCH v2 1/2] t7505: Add tests for cherry-pick and rebase -i/-p

Phillip Wood writes: > + export GIT_SEQUENCE_EDITOR GIT_EDITOR && > + test_must_fail git rebase $mode b && > + echo x>a && "echo x >a"

Re: [PATCH v2 1/2] t7505: Add tests for cherry-pick and rebase -i/-p

Phillip Wood writes: > @@ -31,17 +63,40 @@ mkdir -p "$HOOKDIR" > echo "#!$SHELL_PATH" > "$HOOK" > cat >> "$HOOK" <<'EOF' > > +GIT_DIR=$(git rev-parse --git-dir) > +if test -d "$GIT_DIR/rebase-merge" > +then > + rebasing=1 > +else > + rebasing=0 > +fi > + >

Re: The original file that was split in 2 other files, is there a way in git to see what went where?

Jeff King writes: > On Mon, Jan 22, 2018 at 10:22:21PM -0500, Aleksey Bykov wrote: > >> I am a code reviewer, I have a situation in GIT: >> >> - before: a.txt >> >> Then a developer decided to split the content of a.txt into 2 files >> and add a few changes all in one commit: >>

Re: [PATCH] Fixes compile warning with -Wimplicit-fallthrough CFLAGS

On Tue, Jan 23, 2018 at 10:33:57AM -0800, Junio C Hamano wrote: > Jeff King writes: > > >> diff --git a/apply.c b/apply.c > >> index 321a9fa68..a22fb2881 100644 > >> --- a/apply.c > >> +++ b/apply.c > >> @@ -1450,7 +1450,7 @@ static void recount_diff(const char *line, int size,

Re: [PATCH] Fixes compile warning with -Wimplicit-fallthrough CFLAGS

Jeff King writes: >> diff --git a/apply.c b/apply.c >> index 321a9fa68..a22fb2881 100644 >> --- a/apply.c >> +++ b/apply.c >> @@ -1450,7 +1450,7 @@ static void recount_diff(const char *line, int size, >> struct fragment *fragment) >> switch (*line) { >>

Re: [PATCH] daemon: add --no-syslog to undo implicit --syslog

Ævar Arnfjörð Bjarmason writes: > On Mon, Jan 22 2018, Lucas Werkmeister jotted: > >> Several options imply --syslog, without there being a way to disable it >> again. This commit adds that option. > > Just two options imply --syslog, --detach & --inetd, unless I've missed >

Re: [PATCH] sequencer: mark a file local symbol as static

Ramsay Jones writes: > Signed-off-by: Ramsay Jones > --- > > Hi Phillip, > > If you need to re-roll your 'pw/sequencer-in-process-commit' branch, could > you please squash this into the relevant patch (commit da96adcf5a, > "sequencer:

Re: [PATCH] fsck: fix leak when traversing trees

Eric Wong writes: > While fsck_walk/fsck_walk_tree/parse_tree populates "struct tree" > idempotently, it is still up to the fsck_walk caller to call > free_tree_buffer. > > Fixes: ad2db4030e42890e ("fsck: remove redundant parse_tree() invocation") Yup, we can see that that

Re: [PATCH v2 0/6] Force pipes to flush immediately on NonStop platform

"Randall S. Becker" writes: >> IOW, I do not see it explained clearly why this change is needed on any >> single >> platform---so "that issue may be shared by others, too" >> is a bit premature thing for me to listen to and understand, as "that issue" >> is >> quite

Re: The original file that was split in 2 other files, is there a way in git to see what went where?

On Mon, Jan 22, 2018 at 10:22:21PM -0500, Aleksey Bykov wrote: > I am a code reviewer, I have a situation in GIT: > > - before: a.txt > > Then a developer decided to split the content of a.txt into 2 files > and add a few changes all in one commit: > > - after: b.txt + few changes and c.txt +

Re: [PATCH 5/5] travis-ci: don't fail if user already exists on 32 bit Linux build job

On Mon, Jan 22, 2018 at 02:32:20PM +0100, SZEDER Gábor wrote: > The 32 bit Linux build job runs in a Docker container, which lends > itself to running and debugging locally, too. Especially during > debugging one usually doesn't want to start with a fresh container > every time, to save time

Re: [PATCH 4/5] travis-ci: don't run the test suite as root in the 32 bit Linux build

On Mon, Jan 22, 2018 at 02:32:19PM +0100, SZEDER Gábor wrote: > Travis CI runs the 32 bit Linux build job in a Docker container, where > all commands are executed as root by default. Therefore, ever since > we added this build job in 88dedd5e7 (Travis: also test on 32-bit > Linux, 2017-03-05),

Re: The original file that was split in 2 other files, is there a way in git to see what went where?

On Mon, Jan 22, 2018 at 7:22 PM, Aleksey Bykov wrote: > Is there an easy way to see: > > 1. what came to b from a? > 2 .what came to c from a? > 3. all extra changes apart from just moving stuff? One way to do this is to use "--color-moved" - it will tell you what in

Re: [PATCH 2/5] travis-ci: use 'set -e' in the 32 bit Linux build job

On Tue, Jan 23, 2018 at 11:26:33AM -0500, Jeff King wrote: > > +HOST_UID=$1 > > +CI_USER=$USER > > +test -z $HOST_UID || (CI_USER="ci" && useradd -u $HOST_UID $CI_USER) > > If this "useradd" step fails, we wouldn't abort the script, because it's > part of a conditional. You'd need a manual "||

Re: [PATCH 3/5] travis-ci: don't repeat the path of the cache directory

On Mon, Jan 22, 2018 at 02:32:18PM +0100, SZEDER Gábor wrote: > Some of our 'ci/*' scripts repeat the name or full path of the Travis > CI cache directory, and the following patches will add new places > using that path. > > Use a variable to refer to the path of the cache directory instead, so

Re: [PATCH 2/5] travis-ci: use 'set -e' in the 32 bit Linux build job

On Mon, Jan 22, 2018 at 02:32:17PM +0100, SZEDER Gábor wrote: > All 'ci/*' scripts use 'set -e' to break the build job if a command > fails, except 'ci/run-linux32-build.sh' which relies on the && chain > to do the same. This inconsistency among the 'ci/*' scripts is asking > for trouble: I

Re: [PATCH v4 5/6] convert: add 'working-tree-encoding' attribute

On Tue, Jan 23, 2018 at 11:25:58AM +0100, Simon Ruderich wrote: > On Mon, Jan 22, 2018 at 07:54:01PM -0500, Jeff King wrote: > > But anyway, that was a bit of a tangent. Certainly the smaller change is > > just standardizing on sizeof(*foo), which I think most people agree on > > at this point.

Re: [PATCH] enable core.fsyncObjectFiles by default

On Tue, Jan 23, 2018 at 12:45:53AM -0500, Theodore Ts'o wrote: > What I was thinking about instead is that in cases where we know we > are likely to be creating a large number of loose objects (whether > they referenced or not), in a world where we will be calling fsync(2) > after every single

Charity Funds

my name is Mrs. Alice Walton, a business woman an America Citizen and the heiress to the fortune of Walmart stores, born October 7, 1949. I have a mission for you worth $100,000,000.00(Hundred Million United State Dollars) which I intend using for CHARITY

Re: git merge-tree: bug report and some feature requests

On Tue, Jan 23, 2018 at 7:08 AM, Josh Bleecher Snyder wrote: > Looking over your list above, at a minimum, libgit2 might not have a > particularly good way to represent submodule/file or > submodule/directory conflicts, because is-a-submodule is defined > external to a

Re: [PATCH v4 5/6] convert: add 'working-tree-encoding' attribute

On Mon, Jan 22, 2018 at 07:54:01PM -0500, Jeff King wrote: > But anyway, that was a bit of a tangent. Certainly the smaller change is > just standardizing on sizeof(*foo), which I think most people agree on > at this point. It might be worth putting in CodingGuidelines. Personally I prefer

[PATCH v2 2/2] sequencer: run 'prepare-commit-msg' hook

From: Phillip Wood Commit 356ee4659b ("sequencer: try to commit without forking 'git commit'", 2017-11-24) forgot to run the 'prepare-commit-msg' hook when creating the commit. Fix this by writing the commit message to a different file and running the hook. Using a

[PATCH v2 0/2] sequencer: run 'prepare-commit-msg' hook​

From: Phillip Wood I've updated the patches in response to comments, there are just a couple of small changes. Thanks to Ramsay and Eric for their reviews. Best Wishes Phillip Original cover letter: These two patches add some tests and fix the sequencer to run the

[PATCH v2 1/2] t7505: Add tests for cherry-pick and rebase -i/-p

From: Phillip Wood Check that cherry-pick and rebase call the 'prepare-commit-msg' hook correctly. The expected values for the hook arguments are taken to match the current master branch. I think there is scope for improving the arguments passed so they make a bit

[PATCH v2] SQUASH convert: add tracing for 'working-tree-encoding' attribute

From: Lars Schneider Hi Junio, I overlooked a typo pointed out in Simon's review. Here is a new patch for squashing. Sorry for the trouble! @Eric: Thanks for spotting this! Cheers, Lars convert.c| 8 ++--

Re: [PATCH/RFC 0/2] Automate updating git-completion.bash a bit

On Mon, Jan 22, 2018 at 07:03:24PM +0100, SZEDER Gábor wrote: > On Wed, Jan 17, 2018 at 10:34 AM, Duy Nguyen wrote: > > Actually I forgot another option. What if we automate updating the > > script at "compile" time instead of calling git at run time? E.g. with > > something

Re: [PATCH v4 5/6] convert: add 'working-tree-encoding' attribute

On Mon, Jan 22, 2018 at 01:35:25PM +0100, Lars Schneider wrote: >>> + enc->name = xstrdup_toupper(value); /* aways use upper case names! */ >> >> "aways" -> "always" and I think the comment should say why >> uppercase is important. > > Would that be better? > > /* Aways use upper case