Junio C Hamano writes:
> Mahmoud Al-Qudsi writes:
>
>> The default git behavior when attempting to `git checkout xxx` for
>> some value of "xxx" that cannot be resolved to a single, unique
>> file/path/branch/tag/commit/etc is to display the following:
> ...
> So a possible implementation approa
Kaartic Sivaraam writes:
> On Wed, 2017-08-16 at 12:09 -0700, Junio C Hamano wrote:
>> You said that "checkout" does not do a necessary check that is done
>> in "branch", so presumably "branch" already has a code to do so that
>> is not called by the current "checkout", right? Then you would add
On Sun, Sep 10, 2017 at 9:39 AM, 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 w
Jeff King writes:
> On Mon, Aug 07, 2017 at 04:04:05PM +0200, Nicolas Morey-Chaisemartin wrote:
>
>> Signed-off-by: Nicolas Morey-Chaisemartin
>
> Thanks for moving forward with this.
>
> Can you please flesh out your commit messages with some of the reasoning
> and related discussion? I know fr
On Tue, Sep 12, 2017 at 11:28:00AM +0900, Junio C Hamano wrote:
> Kevin Daudt writes:
>
> > The synopsis and description inconsistently add a '=' between the
> > argument name and it's value. Make this consistent.
> >
> > Signed-off-by: Kevin Daudt
> > ---
> > Documentation/git-for-each-ref.txt
Johannes Schindelin writes:
>> Stepping back a bit, I am not sure if it is sane or even valid for the
>> end-user to modify paths outside sparse-checkout area, but that is
>> probably a separate tangent.
>
> That is not at all the scenario that Kevin fixed.
I know, but in this tangent I was reac
Kevin Daudt writes:
> The synopsis and description inconsistently add a '=' between the
> argument name and it's value. Make this consistent.
>
> Signed-off-by: Kevin Daudt
> ---
> Documentation/git-for-each-ref.txt | 15 ---
> 1 file changed, 8 insertions(+), 7 deletions(-)
Good i
Thomas Gummerer writes:
> On 09/11, Kevin Willford wrote:
>> >
>> > * kw/write-index-reduce-alloc (2017-09-08) 2 commits
>> > - read-cache: fix index corruption with index v4
>> > - Add t/helper/test-write-cache to .gitignore
>> >
>> > Expecting a reroll.
>> > cf. > > q...@mail.gmail.com>
>
--
Hi friend
I am a banker in ADB BANK. I want to transfer an abandoned sum of
USD15.6Million to your Bank account. 40/percent will be your share.
No risk involved but keeps it as secret. Contact me for more details.
Please reply me through my alternative email id only (salif.musa...@gmail.com)
On 11/09/17 11:31, Adam Dinwoodie wrote:
> On Sat, Sep 09, 2017 at 02:13:32PM +0100, 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.
>
From: "Pavel Kretov"
Hi all,
Excuse me if the topic I'm going to raise here has been already discussed
on the mailing list, forums, or IRC, but I couldn't find anything related.
The problem:
Git, being "a stupid content tracker", doesn't try to keep an eye on
operations which happens to indi
Am 10.09.2017 um 19:38 schrieb Jeff King:
> On Sun, Sep 10, 2017 at 12:37:06PM +0200, René Scharfe wrote:
>
>>> And in fact, being called from a signal handler means we should
>>> generally avoid touching malloc or free (which could be holding locks).
>>> That would mean preferring a leak to strbu
Hi Pavel,
On 11/09/2017 09:11, Pavel Kretov wrote:
> Hi all,
>
> Excuse me if the topic I'm going to raise here has been already discussed
> on the mailing list, forums, or IRC, but I couldn't find anything related.
>
>
> The problem:
>
> Git, being "a stupid content tracker", doesn't try to k
On 09/11, Kevin Willford wrote:
> >
> > * kw/write-index-reduce-alloc (2017-09-08) 2 commits
> > - read-cache: fix index corruption with index v4
> > - Add t/helper/test-write-cache to .gitignore
> >
> > Expecting a reroll.
> > cf. > q...@mail.gmail.com>
> >
> I didn't submit these patches
For count, sort and format, only the argument names were listed under
OPTIONS, not the option names.
Add the option names to make it clear the options exist
Signed-off-by: Kevin Daudt
---
Documentation/git-for-each-ref.txt | 18 +-
1 file changed, 9 insertions(+), 9 deletions(-)
The synopsis and description inconsistently add a '=' between the
argument name and it's value. Make this consistent.
Signed-off-by: Kevin Daudt
---
Documentation/git-for-each-ref.txt | 15 ---
1 file changed, 8 insertions(+), 7 deletions(-)
diff --git a/Documentation/git-for-each-r
>
> * kw/write-index-reduce-alloc (2017-09-08) 2 commits
> - read-cache: fix index corruption with index v4
> - Add t/helper/test-write-cache to .gitignore
>
> Expecting a reroll.
> cf. q...@mail.gmail.com>
>
I didn't submit these patches so what would you like
me to do?
The reroll for rea
On 09/08, Junio C Hamano wrote:
> Junio C Hamano writes:
>
> > One thing I still do not know how I feel about after re-reading the
> > thread, and I didn't find the above doc, is Linus's suggestion to
> > use the objects themselves as NewHash-to-SHA-1 mapper [*1*].
> > ...
> > [Reference]
> >
>
On Mon, Sep 11, 2017 at 11:32 AM, Allen Li wrote:
> $ git --version
> git version 2.14.1.581
>
> This does not work:
>
> $ git --git-dir ~/foo/.git --work-tree ~/foo stash create
> fatal: /usr/lib/git-core/git-stash cannot be used without a working tree.
>
> This does:
>
> $ git --git-dir ~/foo/.g
On Mon, Sep 11, 2017 at 11:11 AM, Stefan Beller wrote:
> On Mon, Sep 11, 2017 at 12:11 AM, Pavel Kretov wrote:
>> Hi all,
>>
>> Excuse me if the topic I'm going to raise here has been already discussed
>> on the mailing list, forums, or IRC, but I couldn't find anything related.
>>
>>
>> The prob
On Mon, Sep 11, 2017 at 10:11:31AM +0300, Pavel Kretov wrote:
> Unfortunately, the heuristic can only deal with simple file renames with
> no substantial content changes; it's helpless when you:
>
> - rename file and change it's content significantly;
> - split single file into several files;
>
$ git --version
git version 2.14.1.581
This does not work:
$ git --git-dir ~/foo/.git --work-tree ~/foo stash create
fatal: /usr/lib/git-core/git-stash cannot be used without a working tree.
This does:
$ git --git-dir ~/foo/.git --work-tree ~/foo -C ~/foo stash create
I found a description of
On Mon, Sep 11, 2017 at 12:11 AM, Pavel Kretov wrote:
> Hi all,
>
> Excuse me if the topic I'm going to raise here has been already discussed
> on the mailing list, forums, or IRC, but I couldn't find anything related.
>
>
> The problem:
>
> Git, being "a stupid content tracker", doesn't try to ke
On Fri, Sep 08, 2017 at 02:33:35PM +0200, Michael J Gruber wrote:
> Looking at it more closely, the solution in cbc60b6720 ("git tag
> --contains: avoid stack overflow", 2014-04-24) seems to be a bit "ad
> hoc" to me:
>
> First of all, there is more than "tag --contains" that may exceed the
> sta
On Sun, Sep 10, 2017 at 02:27:47PM +0200, Michael J Gruber wrote:
> This apparantly expects "ulimit -s" to fail on platforms that don't
> support it, so set the prereq accordingly. I moved the following to
> t/test-lib.sh:
>
> run_with_limited_stack () {
> (ulimit -s 128 && "$@")
> }
>
>
On Mon, Sep 11, 2017 at 7:34 AM, Joseph Dunne wrote:
> When I merge ... however my commit-msg hook does not run. (The
> commit-msg hook works fine in all other commits / merges.)
When using git-commit, but not git-merge?
See the discussion of patches at
https://public-inbox.org/git/20170907220
On Thu, Sep 7, 2017 at 6:13 PM, Junio C Hamano wrote:
> Stefan Beller writes:
>
>> The --no-verify option however is not remembered across invocations
>> of git-merge. Originally the author assumed an alternative in which the
>> 'git merge --continue' command accepts the --no-verify flag, bu
> 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?
> then Travis CI would run the build twice. This wastes resources and
Nit: s/run the build/build and test the same tree/, to further
Hi,
I am Andrew McCabe the United States FBI director charge, am hereby announcing
to you that your ATM Card fund from Benin Republic government authorities, and
Mrs. Jane Frederick, came forward and claimed that they are having problem in
the process of your Card.
This is to bring to your not
I’ve globally configured git master branch to use the –no-ff option in
my .gitconfig file:
[branch "master"]
mergeoptions = “-–no-ff”
When I merge a branch into master that would normally be a fast
forward merge, the merge happens fine and follows the option –no-ff,
creating a new
On 9/10/2017 11:27 PM, 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 warning() and preten
Hi Junio,
On Mon, 11 Sep 2017, Junio C Hamano wrote:
> Stepping back a bit, I am not sure if it is sane or even valid for the
> end-user to modify paths outside sparse-checkout area, but that is
> probably a separate tangent.
That is not at all the scenario that Kevin fixed. Just have a quick lo
On Sat, Sep 09, 2017 at 02:13:32PM +0100, 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.
Confirmed, I also see this unexpected pass.
> Th
You attempted to send a message that contained an executable file. Our company
policy prohibits the sending of executable files via email. The message was
not delivered.
On 2017-09-02 02:04, Jonathan Nieder wrote:
>> Anyway, this should really more explicitly say *what* you need to know
>> about, that is, reordering commits does not work.
>
> It tries to explain that, even with an example. If you have ideas for
> improving the wording, that would be welcome.
As
Hi all,
Excuse me if the topic I'm going to raise here has been already discussed
on the mailing list, forums, or IRC, but I couldn't find anything related.
The problem:
Git, being "a stupid content tracker", doesn't try to keep an eye on
operations which happens to individual files; things lik
36 matches
Mail list logo