Re: [PATCH 2/6] t1414: document some reflog-walk oddities

On Thu, Jul 06, 2017 at 08:42:45AM -0700, Junio C Hamano wrote: > >> I somehow feel that the "showing all entries from HEAD and then > >> showing all from side" is simply a buggy behaviour. I do not think > >> our users would terribly mind if we changed it later. But I may be > >> missing the

Honorable Barrister Paul Williams.

Attn: Sir/Madam I am Honorable Barrister Paul Williams the personal resident Attorney here in Burkina Faso to Late Mr. Muammar Muhammad Abu Minyar AL-Gaddafi of Libya c. 1942 – 20 October 2011. Late Mr. Muammar Muhammad Abu Minyar al-Gaddafi c. 1942 – 20 October 2011, commonly known as Colonel

Re: [PATCH 6/6] reflog-walk: stop using fake parents

On Thu, Jul 06, 2017 at 11:02:24PM -0400, Jeff King wrote: > On Fri, Jul 07, 2017 at 12:32:39AM +, Eric Wong wrote: > > > I'm not sure why, but this is causing t1414.8 failures on 32-bit > > x86 with the latest pu with Debian jessie (oldstable). > > > > Reverting this

Re: [PATCH 6/6] reflog-walk: stop using fake parents

On Fri, Jul 07, 2017 at 12:32:39AM +, Eric Wong wrote: > I'm not sure why, but this is causing t1414.8 failures on 32-bit > x86 with the latest pu with Debian jessie (oldstable). > > Reverting this (beafb2c62947a6d4a97b9c3baf99fe62ec8e830f) in pu > seems to fix the test for me. > > +Cc:

Re: [RFC/WIP PATCH] object store classification

Stefan Beller writes: > Subject: Re: [RFC/WIP PATCH] object store classification I thought you are writing different object-store backends and classifying them into many categories (e.g. local, networked, telepathic, etc.) It is a logical next step to put per-repository

Re: What's cooking in git.git (Jul 2017, #01; Wed, 5)

Stefan Beller writes: > Speaking of submodules, It's not just features, but I also send bug fixes. ;) > https://public-inbox.org/git/20170630003851.17288-1-sbel...@google.com/ > (That patch is not related to this series, except for working in the submodule > area, but I

[RFPR] please ping me with materials for upcoming 2.14

As I want to start the pre-release stabilization period for the upcoming Git 2.14 sometime next week, please throw me a pull request soonish if you have updates meant for it. Thanks.

Re: [PATCH 6/6] reflog-walk: stop using fake parents

I'm not sure why, but this is causing t1414.8 failures on 32-bit x86 with the latest pu with Debian jessie (oldstable). Reverting this (beafb2c62947a6d4a97b9c3baf99fe62ec8e830f) in pu seems to fix the test for me. +Cc: Ramsay since he also had a 32-bit environment. --8<-- ok 7 - --parents shows

Re: [PATCH] push: disable lazy --force-with-lease by default

On Thu, Jul 6, 2017 at 3:39 PM, Junio C Hamano wrote: >>> @@ -91,6 +91,7 @@ test_expect_success 'push to update (allowed)' ' >>> ( >>> cd dst && >>> test_commit D && >>> + git config push.allowLazyForceWithLease false && >>

Re: [PATCH] push: disable lazy --force-with-lease by default

Stefan Beller writes: >> diff --git a/Documentation/git-push.txt b/Documentation/git-push.txt >> index 0a639664fd..1fa01210a2 100644 >> --- a/Documentation/git-push.txt >> +++ b/Documentation/git-push.txt >> @@ -212,8 +212,9 @@ must not already exist. >> + >> Note that all

Re: Should "head" also work for "HEAD" on case-insensitive FS?

Junio C Hamano writes: > Once Michael's packed-refs backend stabilizes, we may have a nice > calm period in the refs subsystem and I expect that this will become > a good medium-sized project for a contributor who does not have to > be so experienced (but not a complete

[RFC/WIP PATCH] object store classification

This continues the efforts of bw/repo-object, making our code base more object oriented by adding the object store to the the repository struct. Long term goal of the series that would evolve from this discussion: * Easier to implement submodule features as it can be in the same process. Short

Re: [PATCH] push: disable lazy --force-with-lease by default

On Thu, Jul 6, 2017 at 11:56 AM, Junio C Hamano wrote: > "git push --force-with-lease=:" makes sure that > there is no unexpected changes to the branch at the remote while you > prepare a rewrite based on the old state of the branch. This > feature came with an experimental

Re: [PATCH] push: add config option to --force-with-lease by default.

Francesco Mazzoli writes: > Moreover, it seems to me that the problem `--force-with-lease` is > just one of marketing. `--force-with-lease` is strictly more "safe" > than `--force` in the sense that it'll reject some pushes that `--force` > will let through. By that logic, a

[PATCH] push: disable lazy --force-with-lease by default

"git push --force-with-lease=:" makes sure that there is no unexpected changes to the branch at the remote while you prepare a rewrite based on the old state of the branch. This feature came with an experimental option that allows : part to be omitted by using the tip of remote-tracking branch

Re: name-rev: anchor pattern without --exclude?

Bryan Turner writes: [...] > If you don't need the ancestor traversals "git name-rev" provides, > "git for-each-ref --count 1 --format "%(refname:short)" --points-at > refs/heads/" might work. That only goes back to Git 2.7.0, > though; still quite a ways off your 1.9

Re: bug report: dates on diff

Junio C Hamano writes: > Imagine this scenario: > > - Contributor A writes a change on 2017-07-01 and send it in to me > - Contributor B writes a change on 2017-07-03 and send it in to me > - I apply change from B on 2017-07-04 on 'master' > - I apply change from A on

Re: bug report: dates on diff

Todd Lewis writes: > Trying not to sound snide, but, what's the point of "--date=" on commits if > you > can't use it later? Granted, things always seem harder until you understand > how > the work. Thanks again. You do not sound snide at all, at least to me ;-) Imagine

Re: name-rev: anchor pattern without --exclude?

On Thu, Jul 6, 2017 at 10:23 AM, Kyle Meyer wrote: > Junio C Hamano writes: >> Kyle Meyer writes: > >> What is the answer desired by your application when two or more >> branches point at the same commit you are interested in? Pick one at >>

Re: [RFC/PATCH v4 00/49] Add initial experimental external ODB support

On 7/1/2017 3:41 PM, Christian Couder wrote: On Fri, Jun 23, 2017 at 8:24 PM, Ben Peart wrote: On 6/20/2017 3:54 AM, Christian Couder wrote: To be able to better handle some kind of objects, for example big blobs, it would be nice if Git could store its objects in

Re: bug report: dates on diff

On 07/06/2017 12:22 PM, Junio C Hamano wrote: > If you didn't create this repository back in 2012, then the syntax > "master@{01-01-2012}" that asks "Back at the beginning of 2012, what > object did the master branch point at?" does not have a sensible > answer. That can be seen in the warning

Re: name-rev: anchor pattern without --exclude?

Junio C Hamano writes: > Kyle Meyer writes: > >> [*] A bit more information on why I'm trying to do this: In Magit, we >> have a work-in-progress feature that takes "snapshots" of changes >> before they are committed. These snapshots are stored as >>

Re: name-rev: anchor pattern without --exclude?

Kyle Meyer writes: > [*] A bit more information on why I'm trying to do this: In Magit, we > have a work-in-progress feature that takes "snapshots" of changes > before they are committed. These snapshots are stored as > "refs/wip/{wtree,index}/". > > We want to

Re: Flurries of 'git reflog expire'

I'm one of the Bitbucket Server developers. My apologies; I just noticed this thread or I would have jumped in sooner! On Thu, Jul 6, 2017 at 6:31 AM, Andreas Krey wrote: > On Wed, 05 Jul 2017 04:20:27 +, Jeff King wrote: >> On Tue, Jul 04, 2017 at 09:57:58AM +0200, Andreas

name-rev: anchor pattern without --exclude?

Hello, I'm trying to restrict name-rev's output to a ref whose name begins with the supplied pattern [*]. Looking at "man git-name-rev", builtin/name-rev.c, and wildmatch.c, I don't see a way to accomplish this with "--refs=". Say, for example, that I want to limit name-rev's output to a ref in

Re: [PATCH] t5534: fix misleading grep invocation

Michael J Gruber writes: > Junio C Hamano venit, vidit, dixit 05.07.2017 18:26: > >> The invocation this fixes is not just misleading but simply wrong. >> Nicely spotted. > > In addition, the patch makes sure to catch any rev-parse failures which > the original invocation shove

Re: bug report: dates on diff

Todd Lewis writes: > [utoddl@tarna gitbug]$ git diff master@{01-01-2012} charter.txt > warning: Log for 'master' only goes back to Thu, 6 Jul 2017 08:19:45 -0400. What you observed is how @{} syntax is designed to work, and is not limited to "git diff". Any Git command

Re: [PATCH] comment: fix a typo in the comment

SZEDER Gábor writes: > Speaking of sharp eyes... That Subject: line really needs a > s/comment:/commit:/, doesn't it? :) Surely it does.

[PATCH] reflog-walk: mark a file-local symbol as static

Signed-off-by: Ramsay Jones --- Hi Jeff, When you re-roll your 'jk/reflog-walk' branch, could you please squash this into the relevant patch (commit beafb2c629, "reflog-walk: stop using fake parents", 05-07-2017). Thanks! ATB, Ramsay Jones reflog-walk.c | 2 +-

Re: [PATCH 2/6] t1414: document some reflog-walk oddities

Jeff King writes: > On Wed, Jul 05, 2017 at 03:45:03PM -0700, Junio C Hamano wrote: > >> > I did make the ordering intentional. We process each reflog sequentially >> > in turn. I don't think it would be wrong to interleave them by date, but >> > I actually think it's useful for

Charity

Hi, My name is Peggy Altman the personal assistant of Ms. Doris Buffett, She is a philanthropist and the founder of one of the largest private foundation in the world. She is on a mission to give it all away as she strongly believes in ‘giving while living.’ She always had the idea that never

Re: [PATCH] comment: fix a typo in the comment

> On Wed, 2017-07-05 at 11:18 -0700, Junio C Hamano wrote: > > Kaartic Sivaraam writes: > > > > > --- > > > �Though very trivial, I wanted to correct this as I didn't > > > �want to ignore it after seeing it. > > > > Thanks for sharp eyes.��Sign-off?��(or

Re: [PATCH] hooks: add signature using "interpret-trailers"

On Wed, 2017-07-05 at 21:14 +0100, Ramsay Jones wrote: > > On 05/07/17 18:35, Kaartic Sivaraam wrote: > > The sample hook to prepare the commit message before > > a commit allows users to opt-in to add the signature > > to the commit message. The signature is added at a place > > that isn't

Re: Flurries of 'git reflog expire'

On Wed, 05 Jul 2017 04:20:27 +, Jeff King wrote: > On Tue, Jul 04, 2017 at 09:57:58AM +0200, Andreas Krey wrote: ... > I seem to recall that using --stale-fix is also extremely expensive, > too. What do the command line arguments for the slow commands look like? The problem isn't that the

Re: Flurries of 'git reflog expire'

On Tue, 04 Jul 2017 11:43:33 +, Ævar Arnfjörð Bjarmason wrote: ... > You can set gc.auto=0 in the repo to disable auto-gc, and play with > e.g. the reflog expire values, see the git-gc manpage. > > But then you need to run your own gc, which is not a bad idea anyway > with a dedicated git

bug report: dates on diff

I've run into what I think is a bug wrt date handling in "git diff". I have some historical data with which I'm attempting to populate a new git repo with back-dated commits. That appears to work. But referencing those commits by date with "git diff" does not. (I have no idea if the problem is

Re: [PATCH] merge-message: change meaning of "empty merge message"

On Thu, 2017-07-06 at 06:46 +0200, Kevin Daudt wrote: > > The function is called "rest_is_empty". > Thanks for correcting that! > But isn't it better that commit and merge use the same code, instead > of > duplicating it again? Otherwise one may be updated, and the other > forgotten, getting

Re: [PATCH] t5534: fix misleading grep invocation

Junio C Hamano venit, vidit, dixit 05.07.2017 18:26: > Johannes Schindelin writes: > >> It seems to be a little-known feature of `grep` (and it certainly came >> as a surprise to this here developer who believed to know the Unix tools >> pretty well) that multiple

Re: [PATCH 2/6] t1414: document some reflog-walk oddities

On Thu, Jul 06, 2017 at 03:16:06AM -0400, Jeff King wrote: > If we think it's buggy, we can fix it now. But I'm not convinced that > sequential iteration is that bad. It's at least _simple_ and easy to > explain. The only other thing that would make sense to me is sorting the > entries by date

Re: [PATCH 2/6] t1414: document some reflog-walk oddities

On Wed, Jul 05, 2017 at 03:45:03PM -0700, Junio C Hamano wrote: > > I did make the ordering intentional. We process each reflog sequentially > > in turn. I don't think it would be wrong to interleave them by date, but > > I actually think it's useful for somebody who switches that behavior to > >