On Thu, Jul 06, 2017 at 11:00:13PM -0700, Junio C Hamano wrote:
> Jeff King writes:
>
> > I suspect that "--since 3.days" is still quite buggy (even with a single
> > reflog) because it checks commit timestamps and stops traversing when we
> > go too bar back. But in a reflog, the commits may be
On 6 July 2017 at 21:13, Junio C Hamano wrote:
> By that logic, a hypothetical update to `--force` that makes 1/3 of
> the attempted forced push randomly would make it safer than the
> current `--force`, wouldn't it?
It would. However, this additional safety is not really meaningful to any
workfl
Jeff King writes:
> I suspect that "--since 3.days" is still quite buggy (even with a single
> reflog) because it checks commit timestamps and stops traversing when we
> go too bar back. But in a reflog, the commits may be totally out of
> order. I'm not sure what it should do. Either:
>
> 1. D
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 re
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 Ga
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 (beafb2c62947a6d4a97b9c
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: Rams
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 things into
the_reposito
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 consider that patch more i
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.
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
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 &&
>>
>> Here I thought
>>
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 forms other than `--f
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 newbie).
>
> It needs to:
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 te
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 option that allows : p
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 hypothetical update
"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 tha
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 target. ("git branch
> --p
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 2017-07-05 on 'master'
>
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 this scenario:
- Con
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
>> random? An error saying it cannot decide where to pl
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 other object
databases
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 y
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
>> "refs/wip/{wtree,index}/".
>>
>>
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 use name-rev to ma
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 Krey wrote:
> ...
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
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 under the rug.
Ye
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 e.g. "git
rev-parse maste
SZEDER Gábor writes:
> Speaking of sharp eyes... That Subject: line really needs a
> s/comment:/commit:/, doesn't it? :)
Surely it does.
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 +-
1 file changed, 1 insertion(+
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 somebody who swit
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
> 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 Sign-of? ;-))
> >
> I should also thank
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 consis
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 expi
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 serv
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 limi
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 dif
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 patterns can be passed in the sa
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
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
> >
43 matches
Mail list logo