Re: [PATCH v4 3/3] range-diff: make diff option behavior (e.g. --stat) consistent

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/

Re: [PATCH v3 1/2] range-diff doc: add a section about output stability

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

Re: [PATCH 2/2] mingw: fix getcwd when the parent directory cannot be queried

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

Re: How to handle patch series conflicts

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

Re: What's cooking in git.git (Sep 2018, #02; Tue, 11)

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 > >> > >> -

Re: What's cooking in git.git (Sep 2018, #02; Tue, 11)

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

Re: Mailsplit

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

Re: [PATCH v3 0/4] wt-status.c: commitable flag

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 one em

Re: Mailsplit

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

Mailsplit

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

Re: How to handle patch series conflicts

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

Re: How to handle patch series conflicts

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

How to handle patch series conflicts

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

Re: test files with same names?

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)

Re: What's cooking in git.git (Aug 2018, #06; Wed, 29)

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 >

Re: [PATCH v2 2/3] Add test for commit --dry-run --short.

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

Re: [PATCH 3/3] wt-status.c: Set the commitable flag in the collect phase.

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"

Re: [PATCH 2/3] Add test for commit --dry-run --short.

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

Re: Missing Tagger Entry

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

Missing Tagger Entry

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'

Re: [PATCH] wt-status.c: set commitable bit if there is a meaningful merge.

> > 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

References to old messages

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

Re: Allow "git shortlog" to group by committer information

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

Re: [PATCH] wt-status.c: set commitable bit if there is a meaningful merge.

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

Re: [PATCH] wt-status.c: set commitable bit if there is a meaningful merge.

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

Re: [PATCH] wt-status.c: set commitable bit if there is a meaningful merge.

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" <philipoak...@iee.org> writes: > > > > >>It appeared that the conditional for 'Reject a

Re: [PATCH] wt-status.c: set commitable bit if there is a meaningful merge.

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 >

Re: [PATCH] wt-status.c: set commitable bit if there is a meaningful merge.

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

Re: Bug report: 'git commit --dry-run' corner case: returns error ("nothing to commit") when all conflicts resolved to HEAD

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 > &

Re: Bug report: 'git commit --dry-run' corner case: returns error ("nothing to commit") when all conflicts resolved to HEAD

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

Re: Picking up old threads/patches

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

Picking up old threads/patches

> 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

Re: Picking up old threads/patches

> 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

Re: What's cooking in git.git (Jan 2016, #01; Mon, 4)

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

Re: What's cooking in git.git (Jan 2016, #01; Mon, 4)

On Monday, January 04, 2016 07:36:05 PM Junio C Hamano wrote: > Stephen & Linda Smith <isch...@cox.net> writes: > > > On Monday, January 04, 2016 03:44:33 PM Junio C Hamano wrote: > >> Becoming tired of waiting for a reroll. > >> ($gmane/271213

Re: [PATCH V2] user-manual: add addition gitweb information

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

Re: [PATCH V2] user-manual: add addition gitweb information

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

Re: [PATCH V5 2/2] user-manual: add section documenting shallow clones

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 >

Re: [PATCH] user-manual: remove temporary branch entry from todo list

On Monday, December 28, 2015 09:29:13 AM Junio C Hamano wrote: > Stephen & Linda Smith <isch...@cox.net> writes: > > > I think that this is a stale todo. > > > > The only place there is a mention of temporary branches (which is > > then parenthetical

Re: [PATCH V4 2/2] user-manual: add section documenting shallow clones

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 > >

Re: [PATCH] user-manual: remove temporary branch entry from todo list

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

Re: [PATCH V2 x/2] user-manual: add section documenting shallow clones

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

Re: [PATCH 2/2] Add a section to the users manual documenting shallow clones.

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 <

Re: Someplace to contribute: documentation

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 h

Someplace to contribute: documentation

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.

Signed tags and git repository

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

Re: Signed tags and git repository

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

Re: [PATCH] How to keep a project's canonical history correct.

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 monospace. -

Re: Beginner question on Pull is mostly evil

I'll create a patch. On Wednesday, May 07, 2014 01:51:04 PM Junio C Hamano wrote: Jim Garrison jim.garri...@nwea.org 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

Re: merging commit history

July 2013 09:43, Stephen Linda Smith isch...@cox.net 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. What I would like to to do is take the individal

merging commit history

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

Re: Version 1.8.1 does not compile on Cygwin 1.7.14

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, which

Version 1.8.1 does not compile on Cygwin 1.7.14

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