[PATCH] name-rev: change a "long" variable to timestamp_t

Earlier dddbad72 ("timestamp_t: a new data type for timestamps", 2017-04-26) updated all in-core variables, fields and function return values that are used to store "seconds since epoch" to a new type timestamp_t. Unfortunately one variable "cutoff", which is used to keep track of the oldest

Re: [PATCH v3 3/4] name-rev: provide debug output

Michael J Gruber writes: > I think I should change 3/4 to display exactly those bits that name-rev > actually uses for weighing different possible descriptions; they are > differents from the "describe-bits". So please withhold 3/4 and 4/4. OK, I think 1&2/4 from this series can

Re: [PATCHv2 12/20] submodule.c: convert show_submodule_summary to use emit_line_fmt

Stefan Beller writes: > That could be added in ws.c:ws_check_emit, as these certain words > are similar to coloring whitespace. I actually was envisioning of highlighting a part of a line, like -Very poor SCM +Very nice SCM which would be done by finding

Re: Git log.decorate can't be overridden in global config (v2.13.0)

Todd Zullinger writes: > I believe a patch for this is on the ah/log-decorate-default-to-auto > branch, courtesy of Brian Carlson (Cc:d): > >https://github.com/gitster/git/commit/c74271aae7 > > The relevant list thread is here: > > >

Re: Git log.decorate can't be overridden in global config (v2.13.0)

Hi Caleb, Caleb Evans wrote: I recently updated to Git v2.13.0 (macOS Sierra via Homebrew), and I noticed that the default --decorate option for `git log` has changed from --decorate=no to --decorate=auto. I'd prefer to keep decoration disabled to minimize clutter in the logs, so I try

Git log.decorate can't be overridden in global config (v2.13.0)

Hi, I recently updated to Git v2.13.0 (macOS Sierra via Homebrew), and I noticed that the default --decorate option for `git log` has changed from --decorate=no to --decorate=auto. I'd prefer to keep decoration disabled to minimize clutter in the logs, so I try disabling it in my global

Re: [Bug] git branch -v has problems with carriage returns

No problem, thanks for taking the time to help me. I managed to create a minimal repository that shows the bug. (I was able to deploy gitlab-ce-v8.15.8-ce.0 from docker locally and create the repo, create the merge request and merge it) I created a github repository so everybody interested can

Re: persistent-https, url insteadof, and `git submodule`

On Fri, 2017-05-19 at 23:43 +0200, Dennis Kaarsemaker wrote: > On Fri, 2017-05-19 at 14:57 -0500, Elliott Cable wrote: > > Set up `persistent-https` as described in the [README][]; including the > > ‘rewrite https urls’ feature in `.gitconfig`: > > > > [url "persistent-https"] > >

Re: [Bug] git branch -v has problems with carriage returns

Sorry for the noise with previous response... I have tried to repro this issue but git goes out of its way to store the commit messages using unix end-of-line format. I think that git itself cannot create a repo exhibiting this problem. Most helpful would be if you could create a mini repo using

Re: Delivery Status Notification (Failure)

Hi, I have tried to repro this issue but git goes out of its way to store the commit messages using unix end-of-line format. I think that git itself cannot create a repo exhibiting this problem. Most helpful would be if you could create a mini repo using gitlab. All it would need is one file,

Re: persistent-https, url insteadof, and `git submodule`

On Fri, 2017-05-19 at 14:57 -0500, Elliott Cable wrote: > Set up `persistent-https` as described in the [README][]; including the > ‘rewrite https urls’ feature in `.gitconfig`: > > [url "persistent-https"] > insteadof = https > [url "persistent-http"] > insteadof = http >

Re: [PATCH v2] send-email: Net::SMTP::SSL is obsolete, use only when necessary

Second ping. This problem is not going away, so if this solution is not acceptable, I'd like to know what needs to be improved. On Thu, 2017-05-04 at 09:01 +0200, Dennis Kaarsemaker wrote: > Ping. It's a little over a month since I sent this, but I haven't seen > any comments. Is this commit good

persistent-https, url insteadof, and `git submodule`

Set up `persistent-https` as described in the [README][]; including the ‘rewrite https urls’ feature in `.gitconfig`: [url "persistent-https"] insteadof = https [url "persistent-http"] insteadof = http Unfortunately, this breaks `git submodule add`: > git submodule

Re: [PATCHv3 20/20] diff.c: color moved lines differently

On Fri, May 19, 2017 at 11:40 AM, Stefan Beller wrote: >>> +static unsigned get_line_hash(struct buffered_patch_line *line, unsigned >>> ignore_ws) >>> +{ >>> + static struct strbuf sb = STRBUF_INIT; >>> + >>> + if (ignore_ws) { >>> + strbuf_reset(); >>> +

Re: [PATCHv3 20/20] diff.c: color moved lines differently

On Fri, May 19, 2017 at 11:23 AM, Jonathan Tan wrote: > On Thu, 18 May 2017 12:37:46 -0700 > Stefan Beller wrote: > > [snip] > >> Instead this provides a dynamic programming greedy algorithm that > > Not sure if this is called "dynamic programming".

Re: [WIP/RFC 00/23] repository object

Glad to see you tackling this. This is definitely a step in the right direction. I realize that it will take a lot of work and that intermediate steps may just be pushing it the global state one level higher but eventually it would be great to see an entire code path global state free! I'm

Re: git merges of tags

On Thu, May 18, 2017 at 4:23 PM, Stephen Rothwell wrote: > > Just a reminder that if you are merging Linus' tree (or any tree > really) via a tag, git was changed some time ago so that merging a tag > will not do a fast forward (there is a good reason for this - I just >

Re: [PATCHv3 20/20] diff.c: color moved lines differently

On Thu, 18 May 2017 12:37:46 -0700 Stefan Beller wrote: [snip] > Instead this provides a dynamic programming greedy algorithm that Not sure if this is called "dynamic programming". > finds the largest moved hunk and then switches color to the > alternative color for the

die("bad object.. for duplicate tagged tag in remote

Bear with me here, I hit this in a real repo. If you have an annotated tag of an annotated tag, and `remote update` elects not to fetch this tag (perhaps because it has a name collision locally), then the repo ends up corrupt: you can't gc it, but fsck doesn't notice. Two repos, named "bad" and

How are you doing

Greetings It’s my pleasure to write you today, I am Awawu Issa, am a Personal Assistant to Late Mr. Lorna Laboso the former Assistant Minister of Home Affairs in Kenya. Mr.Lorna Laboso and the former Kenyan Road minister Dr. Kipkalya Kones has been on board the Cessna 210, which was headed to

Re: [PATCH v2 3/6] fsmonitor: teach git to optionally utilize a file system monitor to speed up detecting new or changed files.

After sending this, I noticed that using a different compiler generated a couple of warnings I should fix. I'm assuming I'll need another re-roll but if not, here are the changes that will be squashed in. Ben diff --git a/dir.c b/dir.c index da428489e2..37f1c580a5 100644 --- a/dir.c +++

Re: [PATCH] doc: explain default option for rev-parse --short

Hey Jeff, I'll take a look at improving the text and the other commands. Thanks for the response. I'll get back to you soonish. André 2017-05-18 12:59 GMT-03:00 Jeff King : > On Thu, May 18, 2017 at 11:03:00AM -0300, André Werlang wrote: > >> Git 2.11 introduced a computation to

Re: reversion in GIT_COMMON_DIR refs path

Joey Hess wrote: > Bisecting this test suite failure > https://git-annex.branchable.com/git-annex_in_nixpkgs_fails_with_git-2.13.0/ > I landed on commit f57f37e2e1bf11ab4cdfd221ad47e961ba9353a0 to git. > > It seems that changed resolving refs paths when GIT_DIR and GIT_COMMON_DIR > are both set.

Re: [PATCH] rebase -i: Add missing newline to end of message

On 19/05/17 12:24, Ævar Arnfjörð Bjarmason wrote: On Fri, May 19, 2017 at 12:13 PM, Phillip Wood wrote: On 18/05/17 22:21, Johannes Schindelin wrote: Hi Phillip, On Thu, 18 May 2017, Phillip Wood wrote: From: Phillip Wood The message

[PATCH v2] rebase -i: Add missing newline to end of message

From: Phillip Wood The message that's printed when auto-stashed changes are successfully restored was missing '\n' at the end. Signed-off-by: Phillip Wood Acked-by: Johannes Schindelin --- I've added

[PATCH 14/15] diff: use pending "path" if it is available

There's a subtle distinction between "name" and "path" for a blob that we resolve: the name is what the user told us on the command line, and the path is what we traversed when finding the blob within a tree (if we did so). When we diff blobs directly, we use "name", but "path" is more likely to

[PATCH 15/15] diff: use blob path for blob/file diffs

When we diff a blob against a working tree file like: git diff HEAD:Makefile Makefile we always use the working tree filename for both sides of the diff. In most cases that's fine, as the two would be the same anyway, as above. And until recently, we used the "name" for the blob, not the path,

[PATCH 12/15] diff: pass whole pending entry in blobinfo

When diffing blobs directly, git-diff picks the blobs out of the rev_info's pending array and copies the relevant bits to a custom "struct blobinfo". But the pending array entry already has all of this information (and more, which we'll use in future patches). Let's just pass the original entry

[PATCH 10/15] handle_revision_arg: record modes for "a..b" endpoints

The "a..b" revision syntax was designed to handle commits, so it doesn't bother to record any mode we find while traversing a "tree:path" endpoint. These days "git diff" can diff blobs using either "a:path..b:path" (with dots) or "a:path b:path" (without), but the two behave inconsistently, as the

[PATCH 08/15] get_sha1_with_context: dynamically allocate oc->path

When a sha1 lookup returns the tree path via "struct object_context", it just copies it into a fixed-size buffer. This means the result can be truncated, and it means our "struct object_context" consumes a lot of stack space. Instead, let's allocate a string on the heap. Because most callers

[PATCH 11/15] handle_revision_arg: record paths for pending objects

If the revision parser sees an argument like tree:path, we parse it down to the correct blob (or tree), but throw away the "path" portion. Let's ask get_sha1_with_context() to record it, and pass it along in the pending array. This will let programs like git-diff which rely on the revision-parser

[PATCH 09/15] t4063: add tests of direct blob diffs

The git-diff command can directly compare two blobs (or a blob and a file), but we don't test this at all. Let's add some basic tests that reveal a few problems. There are basically four interesting inputs: 1. sha1 against sha1 (where diff has no information beyond the contents) 2.

[PATCH 07/15] get_sha1_with_context: always initialize oc->symlink_path

The get_sha1_with_context() function zeroes out the oc->symlink_path strbuf, but doesn't use strbuf_init() to set up the usual invariants (like pointing to the slopbuf). We don't actually write to the oc->symlink_path strbuf unless we call get_tree_entry_follow_symlinks(), and that function does

[PATCH 06/15] sha1_name: consistently refer to object_context as "oc"

An early version of the patch to add object_context used the name object_resolve_context. This was later shortened to just object_context, but the "orc" variable name stuck in a few places. Let's use "oc", which is used elsewhere in the code. Signed-off-by: Jeff King --- cache.h

[PATCH 05/15] handle_revision_arg: add handle_dotdot() helper

The handle_revision_arg function is rather long, and a big chunk of it is handling the range operators. Let's pull that out to a separate helper. While we're doing so, we can clean up a few of the rough edges that made the flow hard to follow: - instead of manually restoring *dotdot (that we

[PATCH 04/15] handle_revision_arg: hoist ".." check out of range parsing

Since 003c84f6d (specifying ranges: we did not mean to make ".." an empty set, 2011-05-02), we treat the argument ".." specially. We detect it by noticing that both sides of the range are empty, and that this is a non-symmetric two-dot range. While correct, this makes the code overly complicated.

[PATCH 03/15] handle_revision_arg: stop using "dotdot" as a generic pointer

The handle_revision_arg() function has a "dotdot" variable that it uses to find a ".." or "..." in the argument. If we don't find one, we look for other marks, like "^!". But we just keep re-using the "dotdot" variable, which is confusing. Let's introduce a separate "mark" variable that can be

[PATCH 01/15] handle_revision_arg: reset "dotdot" consistently

When we are parsing a range like "a..b", we write a temporary NUL over the first ".", so that we can access the names "a" and "b" as C strings. But our restoration of the original "." is done at inconsistent times, which can lead to confusing results. For most calls, we restore the "." after we

[PATCH 02/15] handle_revision_arg: simplify commit reference lookups

The "dotdot" range parser avoids calling lookup_commit_reference() if we are directly fed two commits. But its casts are unnecessarily complex; that function will just return a commit we pass into it. Just calling the function all the time is much simpler, and doesn't do any significant extra

[PATCH 0/15] retain blob info for git diff HEAD:foo HEAD:bar

On Tue, May 16, 2017 at 10:05:35PM -0400, Jeff King wrote: > On Wed, May 17, 2017 at 10:38:36AM +0900, Junio C Hamano wrote: > > > > - add_pending_object(revs, a_obj, this); > > > - add_pending_object(revs, b_obj, next); > > > +

Re: [WIP/RFC 00/23] repository object

On 5/18/2017 7:21 PM, Brandon Williams wrote: When I first started working on the git project I found it very difficult to understand parts of the code base because of the inherently global nature of our code. It also made working on submodules very difficult. Since we can only open up a

your response is highly appreciated

Hello , I am specifically contacting you in respect of a business proposal that I have for you as you appear very relevant in the proposal. Please kindly reply back to me for further details. Waiting to hear from you. Regards, Mr. Adams Salem Private E-mail: mradamssa...@outlook.my

Re: [PATCH] rebase -i: Add missing newline to end of message

On Fri, May 19, 2017 at 12:13 PM, Phillip Wood wrote: > On 18/05/17 22:21, Johannes Schindelin wrote: >> Hi Phillip, >> >> On Thu, 18 May 2017, Phillip Wood wrote: >> >>> From: Phillip Wood >>> >>> The message that's printed when

Re: [PATCH] rebase -i: Add missing newline to end of message

On 18/05/17 22:21, Johannes Schindelin wrote: > Hi Phillip, > > On Thu, 18 May 2017, Phillip Wood wrote: > >> From: Phillip Wood >> >> The message that's printed when auto-stashed changes are successfully >> restored was missing '\n' at the end. >> --- > > Please

Re: [PATCH 22/23] ref-filter: limit traversal to prefix

On 05/17/2017 03:38 PM, Jeff King wrote: > On Wed, May 17, 2017 at 02:05:45PM +0200, Michael Haggerty wrote: > >> From: Jeff King > > This patch did originate with me, but I know you had to fix several > things to integrate it in your series. So I'll review it anyway, and > give

Re: [PATCH 12/23] ref_transaction_commit(): break into multiple functions

On 05/17/2017 07:44 PM, Stefan Beller wrote: > On Wed, May 17, 2017 at 5:05 AM, Michael Haggerty > wrote: >> Break the function `ref_transaction_commit()` into two functions, >> `ref_transaction_prepare()` and `ref_transaction_finish()`, with a >> third function,

[PATCH] ref-filter: resolve HEAD when parsing %(HEAD) atom

If the user asks to display (or sort by) the %(HEAD) atom, ref-filter has to compare each refname to the value of HEAD. We do so by resolving HEAD fresh when calling populate_value() on each ref. If there are a large number of refs, this can have a measurable impact on runtime. Instead, let's