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
> >
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
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, 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
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 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
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 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, 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
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
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
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(+
SZEDER Gábor writes:
> Speaking of sharp eyes... That Subject: line really needs a
> s/comment:/commit:/, doesn't it? :)
Surely it does.
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
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
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
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:
> ...
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
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}/".
>>
>>
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
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 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
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
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'
>
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
"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
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
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
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
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:
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
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
>>
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
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.
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
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
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
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
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 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
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 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
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
43 matches
Mail list logo