On Tuesday 12 September 2017 08:59 PM, Jeff King wrote:
Like all good writing rules, I think it's important to know when to
break them. :)
That's right. "Have guidelines but 'Be bold' enough to break them when
they seem to be inducing counter productivity."
Writing in the imperative is _most_
Just reminding people that this issue would seem to still exist in
current master..
It's trivial to show:
[torvalds@i7 git]$ git bisect start
[torvalds@i7 git]$ git bisect bad master
[torvalds@i7 git]$ git bisect good master~5
Bisecting: 23 revisions left to test after this (roughly 5
On Tue, Sep 12, 2017 at 4:30 PM, Kevin Willford wrote:
>
> Sorry. It was not in the sparse-checkout file.
> $ git config core.sparsecheckout true
> $ echo /i > .git/info/sparse-checkout
> $ git checkout -f
> was ran in the modified file case as well and "i" was the only file in the
> working dire
On Tue, Sep 12, 2017 at 10:33:37AM -0700, Stefan Beller wrote:
> On Sun, Sep 10, 2017 at 9:27 PM, Sam Bobroff wrote:
>
> > (If only there were a way to set the coverletter text automatically as
> > well...)
> >
>
> Checkout branch..description
AH! I had seen this section of the format-patch man
> From: Jacob Keller [mailto:jacob.kel...@gmail.com]
> Sent: Tuesday, September 12, 2017 4:29 PM
>
> On Tue, Sep 12, 2017 at 1:20 PM, Kevin Willford wrote:
> >
> > I think this is where I need to do a better job of explaining so here is a
> > simple example.
> >
> > I have a file "a" that was add
Following are several fixes for duplicated words ("of of") and one
case where an extra article ("a") slipped in.
Signed-off-by: Evan Zacks
---
Documentation/git-cat-file.txt | 2 +-
Documentation/git-checkout.txt | 2 +-
Documentation/git-notes.txt| 2 +-
Documentation/git-update
Callers are only allowed to pass certain flags into
ref_transaction_update, other flags are internal to it. To prevent
mistakes from the callers, strip the internal only flags out before
continuing.
This was noticed because of a compiler warning gcc 7.1.1 issued about
passing a NULL parameter as
Am 20.08.2017 um 11:06 schrieb Jeff King:
> I actually think it would be reasonable to omit the empty directory in
> t5004. The main thing we care about there is that we produce an archive
> with no files rather than barfing. Checking that the empty directory is
> actually there was mostly "this is
On Tue, Sep 12, 2017 at 1:20 PM, Kevin Willford wrote:
>> From: Junio C Hamano [mailto:gits...@pobox.com]
>> Sent: Monday, September 11, 2017 9:57 PM
>>
>> Let's imagine a path P that is outside the sparse checkout area.
>> And we check out a commit that has P. P would still be recorded in
>> the
> From: Junio C Hamano [mailto:gits...@pobox.com]
> Sent: Monday, September 11, 2017 9:57 PM
>
> Let's imagine a path P that is outside the sparse checkout area.
> And we check out a commit that has P. P would still be recorded in
> the index but it would not materialize in the working tree. "gi
"My name is Gerard Sanchez , a real estate agent presently based in UAE. I have
been diagnosed with Oesophageal cancer. I have been on medical treatment after
which it was confirmed by my doctor that I have cancer in 2012. The sad part
now is that it has also been confirmed that i may not live t
<>
Sorry I don't understand your question. The commit-msg hook runs
properly in all cases except when I perform a merge with the --no-ff
option enabled.
On Mon, Sep 11, 2017 at 12:25 PM, Stefan Beller wrote:
> On Mon, Sep 11, 2017 at 7:34 AM, Joseph Dunne wrote:
>
>> When I merge ... however my co
On Tue, Sep 12, 2017 at 06:18:32PM +0200, Lars Schneider wrote:
> we are seeing this now in Git 2.14.1:
>
> ...
> error: inflate: data stream error (unknown compression method)
> error: unable to unpack 7b513f98a66ef9488e516e7abbc246438597c6d5 header
> error: inflate: data stream error (unknown c
On Sun, Sep 10, 2017 at 9:27 PM, Sam Bobroff wrote:
> (If only there were a way to set the coverletter text automatically as
> well...)
>
Checkout branch..description
From: Stefan Beller
The first argument of a ref_store_init_fn is documented to represent
the $GIT_DIR, not the path to the packed-refs file. This brings the
packed-refs store more in line with the usual ref store interface.
Signed-off-by: Jonathan Nieder
Signed-off-by: Stefan Beller
---
That's
From: Stefan Beller
Pass DO_FOR_EACH_INCLUDE_BROKEN when iterating over replacement refs
so that the iteration does not require opening the named objects from
the object store. This avoids a dependency cycle between object access
and replace ref iteration.
Moreover the ref subsystem has not been
From: Stefan Beller
The check_has_commit helper uses resolves a submodule entry to a
commit, when validating its existence. As a side effect this means
tolerates a submodule entry pointing to a tag, which is not a valid
submodule entry that git commands would know how to cope with.
Tighten the c
The MRU cache that keeps track of recently used packs is represented
using two global variables:
struct mru packed_git_mru_storage;
struct mru *packed_git_mru = &packed_git_mru_storage;
Callers never assign to the packed_git_mru pointer, though, so we can
simplify by eliminating i
Hi,
This is a continuation of the series at [1]. That was part 1 ---
you can think of this as part 0, since it contains the simplest and
least controversial part of the series --- each patch in this series
is a bugfix in its own right.
Patch 1 should be familiar if you reviewed the series [1].
> On 31 Mar 2017, at 19:45, Jeff King wrote:
>
> On Fri, Mar 31, 2017 at 10:35:06AM -0700, Junio C Hamano wrote:
>
>> Lars Schneider writes:
>>
>>> Hi,
>>>
>>> I just got a report with the following output after a "git fetch" operation
>>> using Git 2.11.0.windows.3 [1]:
>>>
>>> remote: Cou
On Tue, Sep 12, 2017 at 06:17:29PM +0530, Kaartic Sivaraam wrote:
> I noted a little issue with the interaction to a remote git repository.
> The issue occurs when the network used for remote communication is a
> bit sluggish. The main issue is illustrated by the following shell
> interaction,
>
On Tue, Sep 12, 2017 at 07:11:38PM +0530, Kaartic Sivaraam wrote:
> On Tue, 2017-09-05 at 09:05 -0400, Jeff King wrote:
> > This patch introduces an UNLEAK() macro that lets us do so.
> > To understand its design, let's first look at some of the
> > alternatives.
> >
>
> > This patch adds the UN
On Tue, Sep 12, 2017 at 08:04:52PM +0530, Kaartic Sivaraam wrote:
> > On Tue, 2017-09-05 at 15:05 -0700, Stefan Beller wrote:
> >
> > After having a sneak peak at the implementation
> > it is O(1) in runtime for each added element, and the
> > space complexity is O(well).
> >
>
> Incidentally I
> On Tue, 2017-09-05 at 15:05 -0700, Stefan Beller wrote:
>
> After having a sneak peak at the implementation
> it is O(1) in runtime for each added element, and the
> space complexity is O(well).
>
Incidentally I was reading about "complexity of algorithms" and there
was the following paragraph
On Tue, 2017-09-05 at 09:05 -0400, Jeff King wrote:
> This patch introduces an UNLEAK() macro that lets us do so.
> To understand its design, let's first look at some of the
> alternatives.
>
> This patch adds the UNLEAK() macro and enables it
> automatically when Git is compiled with SANITIZE=le
Hi Ramsay,
On Sat, 9 Sep 2017, Ramsay Jones wrote:
> I ran the test-suite on the 'pu' branch last night (simply because that
> was what I had built at the time!), which resulted in a PASS, but t6120
> was showing a 'TODO passed' for #52.
>
> This is a test introduced by Michael's 'mg/name-rev-te
Hello all,
I noted a little issue with the interaction to a remote git repository.
The issue occurs when the network used for remote communication is a
bit sluggish. The main issue is illustrated by the following shell
interaction,
$ git push -u fork
sivaraamUsername for 'https://git
> On 11 Sep 2017, at 05:27, Junio C Hamano wrote:
>
> Junio C Hamano writes:
>
>> I still think we would want to turn warning() to die(), but it
>> probably is better to do so in a separate follow-up patch. That
>> will give us a good place to record the reason why the current "just
>> call a
> On 10 Sep 2017, at 09:39, Jeff King wrote:
>
> On Sun, Sep 10, 2017 at 06:45:08AM +0200, Michael Haggerty wrote:
>
>>> So nothing to see here, but since I spent 20 minutes scratching my head
>>> (and I know others look at Coverity output and may scratch their heads
>>> too), I thought it was
> On 11 Sep 2017, at 16:52, SZEDER Gábor wrote:
>
>> If we push a branch and a tag pointing to the HEAD of this branch,
>
> s/the HEAD of//, perhaps?
> There is no such thing as "HEAD" (all capital!) of a branch, is it?
Agreed, maybe:
"If we push a branch and a tag pointing to the tip of this
Hi Junio,
On Mon, 11 Sep 2017, Junio C Hamano wrote:
> * js/rebase-i-final (2017-07-27) 10 commits
> - rebase -i: rearrange fixup/squash lines using the rebase--helper
> - t3415: test fixup with wrapped oneline
> - rebase -i: skip unnecessary picks using the rebase--helper
> - rebase -i: chec
When the user tries to use '--help' option on an aliased command
information about the alias is printed as sshown below,
$ git co --help
`git co' is aliased to `checkout'
This doesn't seem correct as the user has aliased only 'co' and not
'git co'. This might even be incorrect in cases in
It's not possible to 'touch' the cut-line that is shown when the
user requests a patch in his commit template.
So, make the sentence more intuitive.
Signed-off-by: Kaartic Sivaraam
---
Just a small tweak. May or may not be worth the patch.
wt-status.c | 2 +-
1 file changed, 1 insertion(+), 1
Allowing a branch with a name 'HEAD' could trigger ambiguity. We could
avoid this by checking for it manually. Moreover this has been done
partially in 8efb8899c ("branch: segfault fixes and validation", 2013-02-23)
There was still a way to create a branch with name 'HEAD' by using
$ git check
>From The Regional Manager!,
best regards!,
How are you doing including your family, hope all is well?
My purpose of contacting you is to crave your indulgence to assist me in
securing some funds abroad. (US$7,500,000.00 ) I am writing you this proposal
in good faith, believing that I can tru
Le 12/09/2017 à 09:02, Junio C Hamano a écrit :
> Junio C Hamano writes:
>
>> I was sweeping my mailbox to collect loose ends that haven't been
>> tied down, and noticed that this topic does not seem to have reached
>> a conclusion. Do we want to reboot the effort? Or should we just
>> throw i
Junio C Hamano writes:
> I was sweeping my mailbox to collect loose ends that haven't been
> tied down, and noticed that this topic does not seem to have reached
> a conclusion. Do we want to reboot the effort? Or should we just
> throw it in the #leftoverbits bin for now?
Ahh, I failed to fin
On Tue, 2017-09-12 at 15:49 +0900, Junio C Hamano wrote:
> Kaartic Sivaraam writes:
>
> > Thanks. Now I get it. What about doing that check in
> > branch.c::create_branch or branch.c::validate_new_branchname? I guess
> > creating a branch named HEAD isn't that good an idea in any case. Doing
> >
39 matches
Mail list logo
