On Monday, January 21, 2019 8:04:29 AM MST SZEDER Gábor wrote:
> Note that the relative time output is translated, see all the Q_()
> calls in show_date_relative(). Consequently, these tests fail in
> GETTEXT_POISON builds. Please use 'test_i18ncmp' instead.
>
> Furthermore, I think it would hel
On Friday, January 18, 2019 11:35:22 AM MST Junio C Hamano wrote:
> "Stephen P. Smith" writes:
> I think doing two things in this step (i.e. reverting Linus's "auto"
> support from 1/5, and adding "auto" that is similar to color's auto)
> is OK, but then the title should list both. It sounded lik
On Tuesday, January 8, 2019 11:58:29 PM MST Johannes Sixt wrote:
> But notice that the value of $TODAY_REGEX contains blanks.
>
> In this line
>
> check_human_date "$(($(date +%s)-18000)) +0200" $TODAY_REGEX
>
> the value of $TODAY_REGEX is substituted and then the value is split
> into fields a
On Thursday, January 3, 2019 12:44:22 AM MST Jeff King wrote:
> We already have $TEST_DATE_NOW, which "test-tool date" will respect for
> various commands to pretend that it's currently a particular time. I
> think you'd need to add a sub-command similar to "relative" (which
> directly calls show_d
On Wednesday, January 2, 2019 11:15:02 AM MST Junio C Hamano wrote:
> 'date +%s' is used everywhere in this patch but has never been used
> in our test suite before. It is not portable.
So I don't make this mistake again, Is there a reference somewhere for that is
and is not portable?
>
> We pe
On Friday, November 9, 2018 3:18:03 AM MST Ævar Arnfjörð Bjarmason wrote:
>
> But we should behave consistently with "diff" in anticipation of such
> output being useful in the future, because it would make for confusing
> UI if two "diff" and "range-diff" behaved differently when it came to
's/
On Wednesday, November 7, 2018 5:22:01 AM MST Ævar Arnfjörð Bjarmason wrote:
> +OUTPUT STABILITY
> +
> +
> +The output of the `range-diff` command is subject to change. It is
> +intended to be human-readable porcelain output, not something that can
> +be used across versions of Git
On Tuesday, October 23, 2018 3:52:49 AM MST you wrote:
> From: Anton Serbulov
>
> `GetLongPathName()` function may fail when it is unable to query
> the parent directory of a path component to determine the long name
> for that component. It happens, because of it uses `FindFirstFile()`
s/of it/i
On Wednesday, September 5, 2018 2:16:06 PM MST Junio C Hamano wrote:
> Stephen & Linda Smith writes:
> > Junio -
> >
> > On Tuesday, September 4, 2018 10:27:26 AM MST Junio C Hamano wrote:
> >> > t7500-commit.sh
> >> > t7501-commit
On Wednesday, September 12, 2018 12:13:23 AM MST Junio C Hamano wrote:
> Stephen & Linda Smith writes:
> > On Tuesday, September 11, 2018 3:20:19 PM MST Junio C Hamano wrote:
> >> * jc/wt-status-state-cleanup (2018-09-07) 1 commit
> >>
> >> - WIP:
On Tuesday, September 11, 2018 3:20:19 PM MST Junio C Hamano wrote:
>
> * jc/wt-status-state-cleanup (2018-09-07) 1 commit
> - WIP: roll wt_status_state into wt_status and populate in the collect
> phase (this branch uses ss/wt-status-committable.)
>
> * ss/wt-status-committable (2018-09-07) 4 c
On Friday, September 7, 2018 8:15:43 AM MST Kevin Daudt wrote:
> On Wed, Sep 05, 2018 at 09:17:29PM -0700, Stephen & Linda Smith wrote:
>
> This is the mailsplit command, and should be executed when running `git
> mailsplit`. What does git --exec-dir return?
>
The other ni
On Thursday, September 6, 2018 12:38:55 AM MST Ævar Arnfjörð Bjarmason wrote:
> On Thu, Sep 06 2018, Stephen P. Smith wrote:
> Sometimes you send mail from this address as "Stephen & Linda Smith
> ", do we also need Linda Smith's Signed-Off-By? :)
My wife and I share o
On Wednesday, September 5, 2018 9:17:29 PM MST Stephen & Linda Smith wrote:
> So two questions:
> 1) why would git version 2.18.0 not appear to continue applying the
> patches.
>
> 2) where do I find the command "git mailsplit". The onlything in my
> ins
I thought I would use "git mailsplit" to split a mbox file (which downloaded
from public inbox) so that I could attemp to resurrect a patch series for from
a year ago.
The motivation is that I downloaded the series [1] and applied to a tag from
about the time period that the patch was sent ou
On Wednesday, September 5, 2018 2:16:06 PM MST Junio C Hamano wrote:
> I think that one that is not even in 'pu' hasn't been looked at for
> a long time; it is probably a good idea to discard and replace, if
> you have something working.
I submitted [1] over the weekend. I will add a spelling err
On Wednesday, September 5, 2018 2:16:06 PM MST Junio C Hamano wrote:
> I think that one that is not even in 'pu' hasn't been looked at for
> a long time; it is probably a good idea to discard and replace, if
> you have something working.
I submitted [1] over the weekend. I will add a spelling err
Junio -
On Tuesday, September 4, 2018 10:27:26 AM MST Junio C Hamano wrote:
> > t7500-commit.sh
> > t7501-commit.sh
> > t7502-commit.sh
> > t7509-commit.sh
>
> These seem to have organically grown and it is very likely that ones
> later introduced were added more from laziness.
How does the proj
I don't mind doing this.
On Tuesday, September 4, 2018 10:27:26 AM MST Junio C Hamano wrote:
> Duy Nguyen writes:
> > t2000-checkout-cache-clash.sh
> > t2001-checkout-cache-clash.sh
>
> These date back to 368f99d5 ("[PATCH 2/2] The core GIT tests: recent
> additions and fixes.", 2005-05-13) whic
On Wednesday, August 29, 2018 3:35:57 PM MST Junio C Hamano wrote:
>
> * mk/use-size-t-in-zlib (2017-08-10) 1 commit
> . zlib.c: use size_t for size
>
> The wrapper to call into zlib followed our long tradition to use
> "unsigned long" for sizes of regions in memory, which have been
> updated
On Saturday, September 1, 2018 7:18:34 PM MST Eric Sunshine wrote:
> > diff --git a/t/t7501-commit.sh b/t/t7501-commit.sh
> > @@ -682,4 +682,12 @@ test_expect_success '--dry-run with conflicts fixed
> > from a merge' ' +test_expect_failure '--dry-run --short' '
> > + # setup two branches with
On Friday, August 31, 2018 9:54:50 AM MST Junio C Hamano wrote:
> Ævar Arnfjörð Bjarmason writes:
> >> Leave the setting of the commitable flag in show_merge_in_progress. If
> >> a check for merged commits is moved to the collect phase then other
> >> --dry-run tests fail.
>
> "Some tests fail" i
On Friday, August 31, 2018 9:26:02 AM MST Junio C Hamano wrote:
> Ævar Arnfjörð Bjarmason writes:
> >
> > Ditto my comment on 1/3 on this. I.e. this changes the failing tests in
> > this series from 2 to 3.
>
> Correct. Thanks for helping Stephen on this topic.
I wasn't sure how this situation
On Wednesday, August 29, 2018 7:43:05 PM MST Ramsay Jones wrote:
>
> Hope this helps.
>
> ATB,
> Ramsay Jones
I was working on the patch for wt-status.c and thought I screwed up my git
database. So I ran fsck and ran into the tag issue.
Thanks
sps
I am getting the following warning when runing a git fsck command against tag
v0.99.
$ git --version
git version 2.18.0
$ git fsck
checking object directories: 100% (256/256), done.
warning in tag d6602ec5194c87b0fc87103ca4d67251c76f233a: missingTaggerEntry:
invalid format - expected 'tagger' l
> > On Tuesday, February 16, 2016 8:33:54 PM MST Junio C Hamano wrote:
> Wow, that's quite an old discussion ;-)
It wasn't intended to be so
> After these:
> tells me that "--short" still does not notice that there _is_
> something to be committed, either with an ancient version like
> v2.10.5 or
I want to pick up work on a patch that I was working on previously.
I had been told to reference (i.e. footnote) a gmane URL. With that service
no longer being being online, what is the preferred method footnoting?
sps
On Thursday, December 15, 2016 5:39:53 PM MST Linus Torvalds wrote:
> On Thu, Dec 15, 2016 at 4:19 PM, Junio C Hamano wrote:
>
> Sorry, I'll just re-send it without the attachment. I prefer inline
> myself, but I thought you didn't care (and gmail makes it
> unnecessarily hard).
>
>
On Tuesday, February 16, 2016 07:33:54 PM Junio C Hamano wrote:
> > ---
>
> I think I mislead you into a slightly wrong direction. While the
> single liner does improve the situation, I think this is merely a
> band-aid upon closer inspection. For example, if you changed your
> "commit --dry-run
On Tuesday, February 16, 2016 07:33:54 PM Junio C Hamano wrote:
> "Stephen P. Smith" writes:
>
> > The 'commit --dry-run' and commit return values differed if a
> > conflicted merge had been resolved and the commit would be the same as
> > the parent.
> >
> > Update show_merge_in_progress to set
On Tuesday, February 16, 2016 04:26:38 PM Stephen & Linda Smith wrote:
> On Tuesday, February 16, 2016 01:54:48 PM Junio C Hamano wrote:
> > "Philip Oakley" writes:
> >
> > >>It appeared that the conditional for 'Reject an attempt to rec
On Tuesday, February 16, 2016 08:20:43 AM Philip Oakley wrote:
> From: "Stephen P. Smith"
> > The 'commit --dry-run' and commit return values differed if a
>
> Should this have quotes around the second 'commit' as they both refer to the
> command, rather than the action?
OK
>
> > conflicted me
On Tuesday, February 16, 2016 01:54:48 PM Junio C Hamano wrote:
> "Philip Oakley" writes:
>
> >>It appeared that the conditional for 'Reject an attempt to record a
> >>non-merge empty commit without * explicit --allow-empty.' could be
> >>simplified after adding this patch.
> >>
> >>
On Monday, February 08, 2016 06:55:17 PM Stephen & Linda Smith wrote:
> > #!/bin/bash
> > mkdir test-repository || exit 1
> > cd test-repository
> > git init
> > echo "Initial contents, unimportant" > test-file
> > git add test-file
> &
Ovidiu Gheorghioiu wrote:
> Hi git guys,
>
> The bug is fairly simple: if we have a conflicted merge, AND all the
> conflicts have been resolved to the version in HEAD, the commit
> --dry-run error code says nothing to commit. As expected, git commit
> goes through.
>
> The commit message IS cor
On Thursday, January 07, 2016 03:03:50 AM Jeff King wrote:
> If it's an ancient thread, it's not a big deal to just start a new
> thread (especially if you reference the old one in the text so people
> can dig it up if they really care).
>
> But for reference, you can add `/raw` to the end of a gm
> If Will isn't interested in finishing these two patches I will pick them
> up [ ($gmane/271213), ($gmane/272180) ]
>
> After that I will check look at some of the others for which you've
> asked for help.
I started work on both of these rerolls this evening. Since I do not have the
origin
> If Will isn't interested in finishing these two patches I will pick them
> up [ ($gmane/271213), ($gmane/272180) ]
>
> After that I will check look at some of the others for which you've
> asked for help.
I started work on both of this this evening. Since I do not have the
original emails
On Monday, January 04, 2016 07:36:05 PM Junio C Hamano wrote:
> Stephen & Linda Smith writes:
>
> > On Monday, January 04, 2016 03:44:33 PM Junio C Hamano wrote:
> >> Becoming tired of waiting for a reroll.
> >> ($gmane/271213).
> >> Anybody wa
On Monday, January 04, 2016 03:44:33 PM Junio C Hamano wrote:
> Becoming tired of waiting for a reroll.
> ($gmane/271213).
> Anybody wants to help rerolling this? Otherwise will discard.
> Becoming tired of waiting for a reroll.
> Anybody wants to help rerolling this? Otherwise will discar
On Wednesday, December 30, 2015 03:29:09 PM Junio C Hamano wrote:
> "Stephen P. Smith" writes:
>
> > The gitweb cgi script provides users an easy way to browse your
> > -project's files and history without having to install Git; see the file
> > -gitweb/INSTALL in the Git source tree for in
On Wednesday, December 30, 2015 03:29:09 PM Junio C Hamano wrote:
> "Stephen P. Smith" writes:
>
> > The gitweb cgi script provides users an easy way to browse your
> > -project's files and history without having to install Git; see the file
> > -gitweb/INSTALL in the Git source tree for instruc
On Tuesday, December 29, 2015 11:24:00 AM Junio C Hamano wrote:
> "Stephen P. Smith" writes:
>
> > Rather than merely pointing readers at the 1.5 release notes to
> > learn about shallow clones, document them formally.
> >
> > Signed-off-by: Stephen P. Smith
> > ---
>
> Thanks. I do not think
On Monday, December 28, 2015 02:57:47 PM Junio C Hamano wrote:
> "Stephen P. Smith" writes:
>
> > Rather than merely pointing readers at the 1.5 release notes to
> > learn about shallow clones, document them formally.
> >
> > Signed-off-by: Stephen P. Smith
> > ---
> >
> > I replaced the paragr
On Monday, December 28, 2015 09:29:13 AM Junio C Hamano wrote:
> Stephen & Linda Smith writes:
>
> > I think that this is a stale todo.
> >
> > The only place there is a mention of temporary branches (which is
> > then parenthetically called a topic bran
On Sunday, December 27, 2015 06:41:09 PM Junio C Hamano wrote:
> "Stephen P. Smith" writes:
>
> > Remove the suggestion for using a detached HEAD instead of a
> > temporary branch.
>
> That is something we can read from the patch text. Please explain
> why it is a good idea to remove it.
>
> I
I just realized that the two patches I sent earlier were missing the Signed by
lines. I will be resending them.
sps
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-in
On Monday, December 21, 2015 10:47:16 PM Eric Sunshine wrote:
> On Mon, Dec 21, 2015 at 9:09 PM, Stephen P. Smith wrote:
> > [[repositories-and-branches]]
> > Repositories and Branches
> > =
> > @@ -72,6 +71,25 @@ called the <>, together
> > with a special
> > top-leve
On Sunday, December 20, 2015 06:27:56 PM Stephen & Linda Smith wrote:
> I've been looking over the git source tree to see if there is some place
> where I can
> contribute. It appears that there are some suggestions at the bottom of
> the userguide. Does anyone have o
I've been looking over the git source tree to see if there is some place where
I can
contribute. It appears that there are some suggestions at the bottom of
the userguide. Does anyone have other places that they would like
worked on first? If not I will start with one of the suggestions.
On Thursday, November 26, 2015 04:56:00 AM Johannes Löthberg wrote:
> You don't even need the Web of Trust though, you can just verify the
> signature and then check that the key used to make the signature is the
> correct one,
Ok, but if I don't have a link to the Web or Trust, how do I know
I've been following commits to the linux and git repostitories for some time.
I used signed tags for
projects that I'm working on.
I know that the linux and git repositories have signed tags, but I'm not able
to verify
them because my key isn't signed by anyone that leads back to one of th
On Friday, May 09, 2014 02:05:44 PM Junio C Hamano wrote:
> I needed a few tweaks on top while queuing. You will find the
> result on 'pu' after I push it out.
>
> In addition to one typofix ("because" lacking "c"), here are what I
> did:
>
> - Typeset concrete command e.g. `git pull` in monosp
I'll create a patch.
On Wednesday, May 07, 2014 01:51:04 PM Junio C Hamano wrote:
> Jim Garrison writes:
>
> >> -Original Message-
> >> From: Junio C Hamano
> >> Sent: Wednesday, May 07, 2014 1:16 PM
> >> Subject: Re: Beginner question on "Pull is mostly evil"
> >>
> >> No. This is mos
> On 12 July 2013 09:43, Stephen & Linda Smith wrote:
> > I'm working on a project that used to use a proprietary CM system (aka
> > oldCM). At a point in time, the state of the code was frozen and used as
> > the basis for commits in SVN.
> >
> > W
I'm working on a project that used to use a proprietary CM system (aka oldCM).
At a point in time, the state of the code was frozen and used as the basis for
commits in SVN.
What I would like to to do is take the individal commits from the oldCM and
place them into git knowing that the time/d
On Sunday, January 06, 2013 04:09:17 AM Jonathan Nieder wrote:
> Mark Levedahl wrote:
> > However, the
> > newer
> >
> > win32api is provided only for the current cygwin release series
> Was it the commit before
> 9fca6cffc05321445b59c91e8f8d308f41588b53 that compiles or was
> it 9fca6cffc05321445b59c91e8f8d308f41588b53 that compiled? I
> am doing a cygwin update presently to look at it.
Since the email earlier today, I had blown away the directory. I just now
did the foll
Commit 9fca6cffc05321445b59c91e8f8d308f41588b53 message states that
the macro was being renamed for clarity. The patch also changes a define.
This change causes the code to not compile on cygwin 1.7.14.
I narrowed the problem to this patch by bisecting commits between v1.8.0 and
1.8.1
Here i
59 matches
Mail list logo
