Jeff King wrote:
> I collected the message-ids from my archive. Interestingly, I had a
> dozen or so that did not have message-ids at all. I think most of them
> are from patches that put the "From " line in the body, like this one:
>
> http://public-inbox.org/git/20070311033833.gb10...@spearce
John Keeping writes:
> At the moment difftool's "trust exit code" logic always suppresses the
> exit status of the diff utility we invoke. This is useful because we
> don't want to exit just because diff returned "1" because the files
> differ, but it's confusing if the shell returns an error be
On Sat, Aug 13, 2016 at 1:49 AM, Duy Nguyen wrote:
> On Tue, Aug 9, 2016 at 12:27 AM, Stefan Beller wrote:
>> is what you want. Maybe we want to see a patch that adds the reverse
>> functionality as well, i.e. git-am will store the the cover letter as the
>> branch description and git-merge will
The '>' character is not a legal part of filenames on Windows. So let's
just not use it in Git's source code. This poses a challenge in the test
script t4013 which distills command-lines into file names (so that the
expected outcome can be stored in files with said names).
We have to take particul
On Sat, Aug 13, 2016 at 8:59 AM, Junio C Hamano wrote:
> Jeff King writes:
>
>> So assuming everything I just said isn't complete bollocks, I think we
>> can move to a future where nobody uses the compaction heuristic. And
>> there are three ways to deal with that:
>>
>> 1. The knob and feature
On Wed, Jul 27, 2016 at 11:14:28AM +0100, Luis Gutierrez wrote:
> Hi,
>
> Attached is a potential patch for reversing the order on which
> git-mergetool presents the files to merge.
>
> Currently, when running git-mergetool, it performs a sort of the files
> to merge by alphabetical ordering. Whe
Eric Wong wrote:
> Thanks, should all be imported.
Oops, missed one which was missing X-Mailing-List (causing
it to not get imported) and had "X-No-Archive: yes" set;
which meant I couldn't get it from gmane this year.
Hmm... XNAY defeats the point of public-inbox (and probably the
point of publ
On Sat, Aug 13, 2016 at 12:30:28PM +0100, John Keeping wrote:
> At the moment difftool's "trust exit code" logic always suppresses the
> exit status of the diff utility we invoke. This is useful because we
> don't want to exit just because diff returned "1" because the files
> differ, but it's con
On Sat, Aug 13, 2016 at 05:38:56PM +0200, René Scharfe wrote:
> Use the macro FLEX_ALLOC_MEM instead of open-coding it. This shortens
> and simplifies the code a bit.
Thanks, looks good (I obviously missed a few opportunities for
conversion during the initial introduction of FLEX_ALLOC simply by
On Sat, Aug 13, 2016 at 07:26:02PM +0200, René Scharfe wrote:
> > I suppose it could assert(sizeof((x)->flexname) == FLEX_ALLOC) or
> > something, but I'm not sure if it is worth worrying about.
>
> You can't use sizeof with an actual flexible array. It only works if
> FLEX_ARRAY is defined as 1
On Sat, Aug 13, 2016 at 08:42:21PM -0700, David Aguilar wrote:
> This use case makes me wonder whether the sorting we do here is
> something that should be opened up a bit so that the it's not
> quite so set in stone.
>
> For example, an extension to the approach taken by this patch
> would be to
From: Torsten Bögershausen
When a non-reversible CRLF conversion is done in "git add",
a warning is printed on stderr (or Git dies, depending on checksafe)
The function commit_chk_wrnNNO() in t0027 was written to test this,
but did the wrong thing: Instead of looking at the warning
from "git add
On 08/04/2016 09:06 AM, Jeff King wrote:
> On Thu, Aug 04, 2016 at 12:00:29AM +0200, Michael Haggerty wrote:
>
>> * ix -> i
>> * ixo -> io
>> * ixs -> start
>> * grpsiz -> groupsize
>
> After your change, I immediately understand three of them. But what is
> "io"?
The (pre-existing) convention i
On Sat, Aug 13, 2016 at 06:50:19PM +0200, Johannes Sixt wrote:
> Am 12.08.2016 um 18:51 schrieb tbo...@web.de:
> >From: Torsten Bögershausen
> >
> >When a non-reversible CRLF conversion is done in "git add",
> >a warning is printed on stderr (or Git dies, depending on checksafe)
> >
> >The functio
Hi Stephen,
On Wed, Aug 10, 2016 at 9:21 PM, Stephen Morton
wrote:
>
> Formatting on previous email was terrible, plus the diff wasn't performed
> against origin. Re-sending.
Thanks for working on this...
> (Finally getting back to this.)
>
> Something like the diff below, then Johannes?
...bu
Signed-off-by: Ramsay Jones
---
Hi Stefan,
If you need to re-roll your 'sb/submodule-clone-rr' branch, could
you please squash this into the relevant patch (commit 7bcd1d17,
"clone: recursive and reference option triggers submodule alternates",
11-08-2016).
Thanks!
[What, deja vu? :-D]
ATB,
From: Torsten Bögershausen
Change since v1:
- The changes done in 1/2 in t0027 needed to be reverted in 2/2.
Put both changes for convert.c and t0027 into a single commit
Thanks to Johannes Sixt.
Torsten Bögershausen (1):
convert: Correct NNO tests and missing `LF will be replaced by CRLF`
On Sun, Aug 14, 2016 at 01:27:06AM +, Eric Wong wrote:
> What's also interesting about the thread you highlighed is the
> extra '<>' when you started that thread; and I have a bug where
> I strip off an extra '>' which needs to be fixed...
Oh, that's interesting. It's not in the message that
On Sun, Aug 14, 2016 at 02:12:34AM +, Eric Wong wrote:
> Eric Wong wrote:
> > Thanks, should all be imported.
>
> Oops, missed one which was missing X-Mailing-List (causing
> it to not get imported) and had "X-No-Archive: yes" set;
> which meant I couldn't get it from gmane this year.
>
> H
On Sat, Aug 13, 2016 at 09:38:33PM +0200, Michael Haggerty wrote:
> On 08/04/2016 09:06 AM, Jeff King wrote:
> > On Thu, Aug 04, 2016 at 12:00:29AM +0200, Michael Haggerty wrote:
> >
> >> * ix -> i
> >> * ixo -> io
> >> * ixs -> start
> >> * grpsiz -> groupsize
> >
> > After your change, I immed
On Wed, Aug 10, 2016 at 11:23:56PM -0400, Jonas Fonseca wrote:
> It's crazy to think that Tig has happily browsed Git repos for more than 10
> years! Thanks to everybody who contributed and made that possible. Looking
> forward to the next 10 years ...
Thanks for all your work on tig. I have trie
I am learning how to use git. I would like to know how:
Given a branch's designation, such as "master~4", how can I see the message I
furnished when I created the branch using "git commit"?
Conversely, given the message I furnished to "git commit", when I created a
branch, how can I see the branc
From: "Eric Wong"
Yes, I was somewhat careful to check for proper mboxes from gmane;
I just missed entire ranges :x
There were a number of messages that were listed by gmane as being in the
various Git for Windows lists such as msysgit, especially when the messages
went to both lists (as t
when looking for pre-rebase and post-rewrite hooks, git-rebase
only looks for hooks dir using `git rev-parse --git-path hooks`,
which didn't consider the path overridden by core.hooksPath.
Signed-off-by: ryenus
---
git-rebase--interactive.sh | 14 +-
git-rebase--merge.sh | 4 +
Patch attached.
It seems gmail ruined the white spaces.
Not sure how to stop gmail from doing that.
Sorry for me, and for Gmail.
0001-make-rebase-respect-core.hooksPath-if-set.patch
Description: Binary data
Hi,
A draft of a new Git Rev News edition is available here:
https://github.com/git/git.github.io/blob/master/rev_news/drafts/edition-18.md
Everyone is welcome to contribute in any section either by editing the
above page on GitHub and sending a pull request, or by commenting on
this GitHub is
From:
I am learning how to use git. I would like to know how:
Given a branch's designation, such as "master~4", how can I see the
message I
furnished when I created the branch using "git commit"?
Conversely, given the message I furnished to "git commit", when I created
a
branch, how can I
On Sun, Aug 14, 2016 at 12:29 PM, ryenus wrote:
> Patch attached.
>
> It seems gmail ruined the white spaces.
> Not sure how to stop gmail from doing that.
> Sorry for me, and for Gmail.
Did you use git-send-email? I don't think that the gmail ui works.
If you have 2-factor authentication, there
Torsten Bögershausen writes:
> Looking at t0027, it turns out that the changes in the test matrix done in 1/2
> are reverted in 2/2.
> This is not a good thing.
> Either (a) they should be marked as test_expect_failure in 1/2 and
> corrected in 2/2,
> or (b) 1/2 and 2/2 are squashed together and
Christian Couder writes:
> You can also reply to this email.
I am not sure that is to be recommended, as that ends up going to
the list, but anyway, these
- Michael's "finding better -/+ assignment in diff using indent
heuristic"
- Philip Oakley's updates to revision range notation docume
Johannes Schindelin writes:
> - test=$(echo "$cmd" | sed -e 's|[/ ][/ ]*|_|g')
> + test=$(echo "$cmd" | sed -e 's|[/ ][/ ]*|_|g' -e 'y/>/_/')
The existing sed scriptlet says "we cannot have slash and do not
want to have space in filename, so we squash runs of them to a
single underscore"
From: "Christian Couder"
Hi,
A draft of a new Git Rev News edition is available here:
https://github.com/git/git.github.io/blob/master/rev_news/drafts/edition-18.md
Everyone is welcome to contribute in any section either by editing the
above page on GitHub and sending a pull request, or by c
Jacob Keller writes:
> On Fri, Aug 12, 2016 at 2:58 PM, Junio C Hamano wrote:
>> On Fri, Aug 12, 2016 at 2:43 PM, Jacob Keller wrote:
>>> Ok so the big problem here is that unlike with diff which has support
>>> for line-prefixes already due to needing it for graph mode, I can't
>>> figure out
With the review of the list's workflow, and failings in my personal
workflow, I asked a couple of questions about fixup and discovered
that my reading of the man pages hadn't provided the illumination
they hope to give.
Here's three little documenation patches, and some queries to go
with them.
Be clearer that the --fixup/--squash options can take any of the
gitrevisions methods of specifying a commit, not just a 'hash'.
Signed-off-by: Philip Oakley
---
v1
It's not immediately obvious what different forms the
option can take. Spell out, and refer to the git revisions guide,
that any of
22c5b13 (rebase -i: handle fixup! fixup! in --autosquash, 2013-06-27)
Signed-off-by: Philip Oakley
---
v1
the historical discussion about this is here
https://public-inbox.org/git/20130611180530.GA18488%40oinkpad.pimlott.net/
I certainly misunderstood what this meant. It sounded like only one fi
Since 68d5d03 (rebase: teach --autosquash to match on sha1 in addition
to message, 2010-11-04) the commit subject can refer directly to the
destination object hash as a single word.)...
Signed-off-by: Philip Oakley
---
v1
This is about the actual commit subject line, rather than the --fixup
optio
Philip Oakley writes:
> Be clearer that the --fixup/--squash options can take any of the
> gitrevisions methods of specifying a commit, not just a 'hash'.
>
> Signed-off-by: Philip Oakley
> ---
> ...
> @@ -81,15 +81,15 @@ OPTIONS
> --fixup=::
> Construct a commit message for use with `reba
Philip Oakley writes:
> Since 68d5d03 (rebase: teach --autosquash to match on sha1 in addition
> to message, 2010-11-04) the commit subject can refer directly to the
> destination object hash as a single word.)...
That's not an object hash but an object name (see glossary); you got
it right in t
Philip Oakley writes:
> 22c5b13 (rebase -i: handle fixup! fixup! in --autosquash, 2013-06-27)
That's a noun that names a commit object. What about it?
> I certainly misunderstood what this meant. It sounded like only one fixup! was
> allowed per commit (i.e. one mistake) - fixing two mistakes
From: "Junio C Hamano"
Philip Oakley writes:
Be clearer that the --fixup/--squash options can take any of the
gitrevisions methods of specifying a commit, not just a 'hash'.
Signed-off-by: Philip Oakley
---
...
@@ -81,15 +81,15 @@ OPTIONS
--fixup=::
Construct a commit message for use with
Here are the topics that have been cooking. Commits prefixed with
'-' are only in 'pu' (proposed updates) while commits prefixed with
'+' are in 'next'. The ones marked with '.' do not appear in any of
the integration branches, but I am still holding onto them.
The preview for the upcoming 2.10
An early preview release Git v2.10.0-rc0 is now available for
testing at the usual places. It is comprised of 589 non-merge
commits since v2.9.0, contributed by 67 people, 20 of which are
new faces.
The tarballs are found at:
https://www.kernel.org/pub/software/scm/git/testing/
The followin
Philip Oakley wrote:
> From: "Eric Wong"
> >
> >Yes, I was somewhat careful to check for proper mboxes from gmane;
> >I just missed entire ranges :x
> >
>
> There were a number of messages that were listed by gmane as being in the
> various Git for Windows lists such as msysgit, especially when
"Philip Oakley" writes:
>> I think the
>> use of "commit" in an angle-bracket-pair in the label for the
>> section, i.e. "--fixup=", has been considered to be clear
>> enough to tell that you can use usual extended SHA-1 syntax to
>> specify the commit you want to talk about,
>
> I certainly hadn
From: "Junio C Hamano"
Philip Oakley writes:
Since 68d5d03 (rebase: teach --autosquash to match on sha1 in addition
to message, 2010-11-04) the commit subject can refer directly to the
destination object hash as a single word.)...
That's not an object hash but an object name (see glossary);
"Philip Oakley" writes:
> the 'standalone' is that it must be a single (standalone) word on the
> subject line immediately after the "fixup! "(s).
>
> communicationg that one cannot have any extra textual notes after that
> word was the issue that 'standalone' tried to address.
Perhaps I am slow
Philip Oakley wrote:
> From: "Christian Couder"
> >You can also reply to this email.
>
> I see you mention in passing (weel in the small headings near the bottom)
> that gmane web interface has gone away. It may be worth noting a few of the
> alternatives, and in particular Eric's newly updated
From: "Junio C Hamano"
Philip Oakley writes:
22c5b13 (rebase -i: handle fixup! fixup! in --autosquash, 2013-06-27)
That's a noun that names a commit object. What about it?
It's the commit that introduced the original change that's being clarified.
Is a paragraph needed or simply "Ref co
From: "Junio C Hamano"
"Philip Oakley" writes:
I think the
use of "commit" in an angle-bracket-pair in the label for the
section, i.e. "--fixup=", has been considered to be clear
enough to tell that you can use usual extended SHA-1 syntax to
specify the commit you want to talk about,
I cert
From: "Junio C Hamano"
"Philip Oakley" writes:
the 'standalone' is that it must be a single (standalone) word on the
subject line immediately after the "fixup! "(s).
communicationg that one cannot have any extra textual notes after that
word was the issue that 'standalone' tried to address.
From: "Eric Wong"
Philip Oakley wrote:
From: "Christian Couder"
>You can also reply to this email.
I see you mention in passing (weel in the small headings near the bottom)
that gmane web interface has gone away. It may be worth noting a few of
the
alternatives, and in particular Eric's ne
The test added in 71abeb753fa8 (reflog: continue walking the reflog
past root commits, 2016-06-03) contains an unnecessary 'git reflog'
execution, which was part of my debug/tracing instrumentation that I
somehow didn't manage to remove before submitting.
Signed-off-by: SZEDER Gábor
---
t/t1410-
Philip Oakley wrote:
> From: "Eric Wong"
> >Philip Oakley wrote:
> >>From: "Christian Couder"
> >>>You can also reply to this email.
> >>
> >>I see you mention in passing (weel in the small headings near the bottom)
> >>that gmane web interface has gone away. It may be worth noting a few of
> >
Looks like there's a problem with setting a config with an empty
section, making it create a new section. The result is:
$ git --version
git version 2.9.2
$ git init
Initialized empty Git repository in /home/eli/t/.git/
$ t() { git config x.y x; git config --unset x.y; }
$
On Sun, Aug 14, 2016 at 2:21 PM, Junio C Hamano wrote:
> Jacob Keller writes:
>
>> On Fri, Aug 12, 2016 at 2:58 PM, Junio C Hamano wrote:
>>> On Fri, Aug 12, 2016 at 2:43 PM, Jacob Keller
>>> wrote:
Ok so the big problem here is that unlike with diff which has support
for line-prefix
If option --help is passed to a Git command, we try to open
the man page of that command. However, we do it even for commands
we don't know. Make sure the command is known to Git before try
to open the man page. If we don't know the command, give the
usual advice.
Signed-off-by: Ralf Thielow
--
On Mon, Aug 15, 2016 at 1:10 AM, Eric Wong wrote:
> Philip Oakley wrote:
>> From: "Christian Couder"
>> >You can also reply to this email.
>>
>> I see you mention in passing (weel in the small headings near the bottom)
>> that gmane web interface has gone away. It may be worth noting a few of th
On Sun, Aug 14, 2016 at 10:58 PM, Junio C Hamano wrote:
> Christian Couder writes:
>
>> You can also reply to this email.
>
> I am not sure that is to be recommended, as that ends up going to
> the list, but anyway, these
>
> - Michael's "finding better -/+ assignment in diff using indent
>h
On Sun, Aug 14, 2016 at 12:15 AM, Jacob Keller wrote:
> On Sat, Aug 13, 2016 at 1:49 AM, Duy Nguyen wrote:
>> On Tue, Aug 9, 2016 at 12:27 AM, Stefan Beller wrote:
>>> is what you want. Maybe we want to see a patch that adds the reverse
>>> functionality as well, i.e. git-am will store the the c
> Is there a case where the compaction heuristic produces a better result
> than this indent heuristic? AFAICT, you have not found one, and I'd be
> surprised if there is one, because this _seems_ like a superset
> generally. I suppose there is always the possibility that the empirical
> knobs beha
On Sun, Aug 14, 2016 at 11:28 PM, Stefan Beller wrote:
> I would imagine this is similar to the pull requests on the linux
> mailing list, i.e.
> how it is with merges. Back in the time we did not open the editor for you to
> talk about the merge you just did, and then we started doing that.
>
> S
On Sun, Aug 14, 2016 at 11:38 PM, Jacob Keller wrote:
> On Sun, Aug 14, 2016 at 11:28 PM, Stefan Beller wrote:
>> I would imagine this is similar to the pull requests on the linux
>> mailing list, i.e.
>> how it is with merges. Back in the time we did not open the editor for you to
>> talk about
On Sun, Aug 14, 2016 at 11:49 PM, Stefan Beller wrote:
> On Sun, Aug 14, 2016 at 11:38 PM, Jacob Keller wrote:
>> On Sun, Aug 14, 2016 at 11:28 PM, Stefan Beller wrote:
>>> I would imagine this is similar to the pull requests on the linux
>>> mailing list, i.e.
>>> how it is with merges. Back in
64 matches
Mail list logo