On Fri, Apr 26 2019, Junio C Hamano wrote:
> Ævar Arnfjörð Bjarmason writes:
>
>> On Wed, Apr 24 2019, Derrick Stolee via GitGitGadget wrote:
>>
>>> NOTE: this series was rebased onto ab/commit-graph-fixes, as the conflicts
>>> were significant and subtle.
>>
>> Sorry, hopefully it helped more
On Thu, Apr 25, 2019 at 9:36 PM Jonathan Nieder wrote:
>
> Hi,
>
> Ævar Arnfjörð Bjarmason wrote:
>
> > Because we don't have some general config facility for this it keeps
> > coming up, and various existing/proposed options have their own little
> > custom hacks for doing it, e.g. this for Barre
From: Phillip Wood
When `rebase -r` finishes it removes any refs under refs/rewritten
that it has created. However if the rebase is aborted these refs are
not removed. This can cause problems for future rebases. For example I
recently wanted to merge a updated version of a topic branch into an
in
From: Phillip Wood
If a merge can be fast-forwarded then make sure that we still edit the
commit message if the user specifies -c. The implementation follows the
same pattern that is used for ordinary rewords that are fast-forwarded.
Signed-off-by: Phillip Wood
---
sequencer.c |
Hi Eric,
On Thu, Apr 25, 2019 at 1:37 PM Eric Sunshine wrote:
>
> On Thu, Apr 25, 2019 at 11:51 AM Elijah Newren wrote:
> > Since git supports commit messages with an encoding other than utf-8,
> > allow fast-import to import such commits. This may be useful for folks
> > who do not want to ree
From: Derrick Stolee
The error messages when reading a commit-graph have a few problems:
1. Some values are output in hexadecimal, but that is not made
clear by the message. Prepend "0x" to these values.
2. The version number does not need to be hexadecimal, and also
should mention a "max
Here is a small patch that revises the error messages from
ab/commit-graph-fixes, as recommended by Ævar. Hopefully, it can be merged
faster than the commit-graph v2 stuff, and I can update that series to
include this change if we agree it is a good one.
Thanks, -Stolee
Cc: ava...@gmail.com
In-R
On 4/26/2019 4:33 AM, Ævar Arnfjörð Bjarmason wrote:
>
> On Fri, Apr 26 2019, Junio C Hamano wrote:
>>
>> Thanks always for your careful review and thoughtful comments, by
>> the way.
I agree that these comments are extremely helpful.
>>> Now as noted in my series we now on 'master' downgrade th
On Fri, Apr 26 2019, Derrick Stolee via GitGitGadget wrote:
> The error messages when reading a commit-graph have a few problems:
>
> 1. Some values are output in hexadecimal, but that is not made
>clear by the message. Prepend "0x" to these values.
>
> 2. The version number does not need to
We wish to inform you of your abandoned fund which has been approved and is
ready for payout.
Please respond to enable the payout department (E.F.C.C) to contact you with
more details.
Mr John Ron E-mail: johnronconsult...@aliyun.com
Sincerely,
Mr. Ibrahim Mustafa Magu
CHAIRMAN ECONOMIC & FINA
On Fri, Apr 26 2019, Derrick Stolee wrote:
> On 4/26/2019 4:33 AM, Ævar Arnfjörð Bjarmason wrote:
>>
>> On Fri, Apr 26 2019, Junio C Hamano wrote:
>>>
>>> Thanks always for your careful review and thoughtful comments, by
>>> the way.
>
> I agree that these comments are extremely helpful.
>
Hi Peff,
On Fri, 12 Apr 2019, Jeff King wrote:
> On Fri, Apr 12, 2019 at 04:04:39PM -0700, Rohit Ashiwal via GitGitGadget
> wrote:
>
> > From: Rohit Ashiwal
> >
> > MinGit for Windows comes without `gzip` bundled inside, git-archive uses
> > `gzip -cn` to compress tar files but for this to work
Hi Junio,
On Sat, 13 Apr 2019, Junio C Hamano wrote:
> Jeff King writes:
>
> >> +/* writes out the whole block, or dies if fails */
> >> +static void write_block_or_die(const char *block) {
> >> + if (gzip) {
> >> + if (gzwrite(gzip, block, (unsigned) BLOCKSIZE) != BLOCKSIZE)
> >> +
Jeff Schwartz writes:
> Using interactive rebase has one flaw IMHO and that is the way it
> handles dating its commit. Can you add an option to interactive rebase
> that would make it use the date from the commit that is most recent
> and not the date from the commit that is the oldest?
I am not
---
Documentation/gitignore.txt | 37 -
1 file changed, 24 insertions(+), 13 deletions(-)
diff --git a/Documentation/gitignore.txt b/Documentation/gitignore.txt
index b5bc9dbff0..3a6fb9117c 100644
--- a/Documentation/gitignore.txt
+++ b/Documentation/gitignore.
Hi Peff,
On Fri, 12 Apr 2019, Jeff King wrote:
> On Fri, Apr 12, 2019 at 04:04:40PM -0700, Rohit Ashiwal via GitGitGadget
> wrote:
>
> > From: Rohit Ashiwal
> >
> > As we already link to the zlib library, we can perform the compression
> > without even requiring gzip on the host machine.
>
> Ve
Hi Peff,
On Mon, 15 Apr 2019, Jeff King wrote:
> On Sun, Apr 14, 2019 at 12:01:10AM +0200, René Scharfe wrote:
>
> > >> As we already link to the zlib library, we can perform the compression
> > >> without even requiring gzip on the host machine.
> > >
> > > Very cool. It's nice to drop a depende
Hi brian,
On Sat, 13 Apr 2019, brian m. carlson wrote:
> On Fri, Apr 12, 2019 at 09:51:02PM -0400, Jeff King wrote:
> > I wondered how you were going to kick this in, since users can define
> > arbitrary filters. I think it's kind of neat to automagically convert
> > "gzip -cn" (which also happen
On Thu, Apr 25 2019, Ævar Arnfjörð Bjarmason wrote:
> On Thu, Apr 25 2019, Duy Nguyen wrote:
>
>> On Thu, Apr 25, 2019 at 5:08 PM Ævar Arnfjörð Bjarmason
>> wrote:
>>> >> Solving (1) without (2) feels like a bit of a missed opportunity to
>>> >> me. Ideally, what I would like is
>>> >>
>>> >>
Hi Junio,
On 26 April 2019 11:11:38 GMT+05:30, Junio C Hamano wrote:
>
>Unfortunately, I do not know how to ask GitHub web UI to give us a
>simple "log --oneline" equivalent of list like gitweb did (sadly
>cgit is not much better wrt this), but I think clicking on the
>parent link starting from
Given that 'ls-remote' can be sorted, it would be useful to be able to ask for
a subset of the total number of result records.
For example, if I want to retrieve only the tag with the highest version, I
would do so by adding this new option (-n1 in my example):
$ git ls-remote -n1 --tag
With Due Respect,
I know that this mail will come to you as a surprise as we have never met
before, but need not to worry as I am contacting you independently of my
investigation and no one is informed of this communication. I need your urgent
assistance in transferring the sum of $11.3million
Thanks for your comments, Eric and Junio.
Eric, I've combined the `test_when_finished` calls together so that the
statements within appear in a more "logical" order.
Junio, I've taken your suggestion and moved the change into
`create_branch`. Initially, I didn't want to do this because I didn't
w
In git-checkout.txt, it states
As a special case, you may use `"A...B"` as a shortcut for the
merge base of `A` and `B` if there is exactly one merge base. You can
leave out at most one of `A` and `B`, in which case it defaults to
`HEAD`.
However, there exists a bug where
Before, in t2018, if do_checkout failed to create `branch2`, the next
test-case would run `git branch -D branch2` but then fail because it was
expecting `branch2` to exist, even though it doesn't. As a result, an
early failure could cause a cascading failure of tests.
Make test-case responsible fo
When we ran something like
$ git checkout -b test master...
it would fail with the message
fatal: Not a valid object name: 'master...'.
This was caused by the call to `create_branch` where `start_name` is
expected to be a valid rev. However, git-checkout allows the branch to
be a valid
On Fri, Apr 26, 2019 at 11:57 AM David Carson
wrote:
>
> Given that 'ls-remote' can be sorted, it would be useful to be able to ask
> for a subset of the total number of result records.
>
> For example, if I want to retrieve only the tag with the highest version, I
> would do so by adding this n
Hi everyone,
The 50th edition of Git Rev News is now published:
https://git.github.io/rev_news/2019/04/26/edition-50/
Thanks a lot to Luca Milanesio who contributed again this month!
Enjoy,
Christian, Jakub, Markus and Gabriel.
Am 22.04.19 um 08:12 schrieb Denton Liu:
> In revisions.txt, the '^' form is mentioned but the '~' form
> is missing. Although both forms are essentially equivalent (they each
> get the first parent of the specified revision), we should mention the
> latter for completeness. Make this change.
>
>
On Thu, Apr 25, 2019 at 09:40:34PM +0200, Johannes Sixt wrote:
> Am 25.04.19 um 02:55 schrieb Junio C Hamano:
> > Johannes Sixt writes:
> >
> >> Furthermore, basing a decision on whether a file is executable won't
> >> work on Windows as intended. So, it is better to aim for an existence
> >> ch
On Fri, Apr 26, 2019 at 10:55:35PM +0200, Andreas Heiduk wrote:
> Am 22.04.19 um 08:12 schrieb Denton Liu:
> > In revisions.txt, the '^' form is mentioned but the '~' form
> > is missing. Although both forms are essentially equivalent (they each
> > get the first parent of the specified revision),
From: Vishal Verma
Convert option_commit to tristate, representing the states of
'default/untouched', 'enabled-by-cli', 'disabled-by-cli'. With this in
place, check whether option_commit was enabled by cli when squashing a
merge. If so, error out, as this is not supported.
Add a note to the --sq
On Thu, Apr 25, 2019 at 09:55:11AM -0600, Elijah Newren wrote:
> On Thu, Apr 25, 2019 at 9:51 AM Elijah Newren wrote:
> >
> > While stress testing `git filter-repo`, I noticed an issue with
> > encoding; further digging led to the fixes and features in this series.
> > See the individual commit me
Am 26.04.19 um 22:58 schrieb brian m. carlson:
> On Thu, Apr 25, 2019 at 09:40:34PM +0200, Johannes Sixt wrote:
> I would like to point out that we still have to perform an executability
> check before we run the hook or we'll get errors printed to the user.
That's fine. On Windows, when a hook is
Denton Liu writes:
> Thanks for your comments, Eric and Junio.
>
> Eric, I've combined the `test_when_finished` calls together so that the
> statements within appear in a more "logical" order.
>
> Junio, I've taken your suggestion and moved the change into
> `create_branch`. Initially, I didn't w
Christian Couder writes:
> Hi everyone,
>
> The 50th edition of Git Rev News is now published:
>
> https://git.github.io/rev_news/2019/04/26/edition-50/
>
> Thanks a lot to Luca Milanesio who contributed again this month!
>
> Enjoy,
> Christian, Jakub, Markus and Gabriel.
Rev News team, congra
On Sat, Apr 27, 2019 at 08:07:34AM +0900, Junio C Hamano wrote:
> Denton Liu writes:
>
> > Thanks for your comments, Eric and Junio.
> >
> > Eric, I've combined the `test_when_finished` calls together so that the
> > statements within appear in a more "logical" order.
> >
> > Junio, I've taken yo
Johannes Schindelin writes:
>> >> +/* writes out the whole block, or dies if fails */
>> >> +static void write_block_or_die(const char *block) {
>> >> + if (gzip) {
>> >> + if (gzwrite(gzip, block, (unsigned) BLOCKSIZE) != BLOCKSIZE)
>> >> + die(_("gzwrite failed"));
>> >>
We weren't flushing the context each time we processed a hunk in the
patch-id generation code in diff.c, but we were doing that when we
generated "stable" patch-ids with the 'patch-id' tool. Let's port that
similar logic over from patch-id.c into diff.c so we can get the same
hash when we're genera
I tried out 'git format-patch --base' with a set of commits that
modifies more than one file. It turns out that the way this command is
implemented it actually uses the unstable version of patch-id instead of
the stable version that's documented. When I tried to modify the
existing test to use 'git
On Fri, Apr 26, 2019 at 04:40:24PM -0700, Denton Liu wrote:
[snip]
> I'm going send a reroll to update the documentation to mention "..." in
> and, while I'm at it, I'll do the squash.
Actually, I have a quick question for you:
Out of respect for your time as the maintainer (since you have a l
Denton Liu writes:
> Out of respect for your time as the maintainer (since you have a lot of
> topics to deal with), how do you prefer small fixups be submitted?
>
> * A complete reroll of the whole series
> * A replacement for one patch in the series
> * A follow-up email with an "oops, please c
2019年4月27日(土) 2:58 Kaartic Sivaraam :
>
> May be you are searching for the following view which lists (similar to git
> log --one-line) the commits starting from 97dd512 which is the last in the
> tb/unexpected series?
>
> https://github.com/git/git/commits/97dd512af7ce4afb4f638ef73b4770921c8ca3
Hi Junio,
On 27 April 2019 10:36:55 GMT+05:30, Junio C Hamano wrote:
>2019年4月27日(土) 2:58 Kaartic Sivaraam :
>>
>
>I can click it and reach https://github.com/git/git/commit/c49927fca0d
>but then
>that is more like "git show c49927fca". I can even go to its second
>parent with
>one click, but th
44 matches
Mail list logo
