Re: Any way to make git-log to enumerate commits?
On Dez 05 2018, Elijah Newren wrote: > Or, just use name-rev so it works with non-linear histories too: > > git log | git name-rev --refs=$(git symbolic-ref HEAD) --stdin | less That wouldn't work for a detached HEAD, though, and you need to use --no-abbrev. Andreas. -- Andreas Schwab, sch...@linux-m68k.org GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510 2552 DF73 E780 A9DA AEC1 "And now for something completely different."
Re: git broken for AIX somewhere between 2.13.2 and 2.13.3
On Jul 29 2018, Ævar Arnfjörð Bjarmason wrote: > Also, to you and anyone else with access to AIX: I'd be happy to figure > these issues out pro-actively if you give me a login to an AIX > machine. I promise not to do anything except compile/debug/test git on > it. The GCC compile farm <http://gcc.gnu.org/wiki/CompileFarm> has a machine running AIX, and is free to use for anyone working on free software. Andreas. -- Andreas Schwab, sch...@linux-m68k.org GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510 2552 DF73 E780 A9DA AEC1 "And now for something completely different."
Re: Git Bash Completion Not Working In Emacs
On Apr 16 2018, Marko Vasic <va...@utexas.edu> wrote: > Git bash completion script works perfectly under the terminal, > however, it does not work in Emacs (neither shell nor gui mode). Did > anyone encounter this issues and how can it be solved? Depend on how you run the command in Emacs. If you use M-x shell then Emacs handles special keys like TAB itself (and the started shell usually disables its own command line editing). If you use M-x term then Emacs emulates a terminal and lets the running process handle all special keys. Andreas. -- Andreas Schwab, sch...@linux-m68k.org GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510 2552 DF73 E780 A9DA AEC1 "And now for something completely different."
Re: man page for "git remote set-url" seems confusing/contradictory
On Apr 16 2018, "Robert P. J. Day" <rpj...@crashcourse.ca> wrote: > i don't understand how you can clearly set the fetch and push URLs of > a remote independently, while the man page nonetheless insists that > "even though they can be set differently, must still refer to the same > place". how can they be set differently yet still must refer to the > same place? They could be using different transport methods. For example, for fetching the unauthenticated git: method could be used, but for pushing an authenticated method like ssh: is usually needed. Andreas. -- Andreas Schwab, sch...@linux-m68k.org GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510 2552 DF73 E780 A9DA AEC1 "And now for something completely different."
Re: .gitattributes lookup doesn't respect GIT_WORK_TREE
On Apr 16 2018, Junio C Hamano <gits...@pobox.com> wrote: > I may be mistaken (I do not have the code in front of me right now) > but IIRC after the setup.c code runs (which happens quite early in > the sequence that starts from git.c::cmd_main()), the Git process > moves to the top level of the working tree, git log/show don't appear to do that. Andreas. -- Andreas Schwab, sch...@linux-m68k.org GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510 2552 DF73 E780 A9DA AEC1 "And now for something completely different."
.gitattributes lookup doesn't respect GIT_WORK_TREE
The functions in attr.c do not look at $GIT_WORK_TREE when trying to find the .gitattributes file. Thus if you are not inside the work tree, but have GIT_WORK_TREE set attribute lookup will be wrong. Password Store <http://www.passwordstore.org/> is using this feature when the password store is a git repository. It sets up a diff attribute that decrypts the contents, but that works only if the command is issued while inside the repository. Andreas. -- Andreas Schwab, sch...@linux-m68k.org GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510 2552 DF73 E780 A9DA AEC1 "And now for something completely different."
Re: git: CVE-2018-1000021: client prints server sent ANSI escape codes to the terminal, allowing for unverified messages to potentially execute arbitrary commands
On Feb 06 2018, "Randall S. Becker" <rsbec...@nexbridge.com> wrote: > What I don't know - and it's not explicitly in the CVE - is just how many > other terminal types with similar vulnerabilities are out there, but I'm > suspecting it's larger than one would guess - mostly, it seems like this > particular sequence is intended to be used for writing status line output > (line 25?) instead of sticking it in a prompt. This can be used prettifies a > lengthy bash prompt to display the current branch and repository at the > bottom of the screen instead of in the inline prompt, but that's the user's > choice and not something git has to deal with. There were some green-screen > terminals with other weird ESC sequences back in the day that could really > get into trouble with this, including loading/executing programs in terminal > memory via output - really. I'm sure it seemed like a good idea at the time, > but I can see how it could have been used for evil. Do you also want to block "+++AT"? :-) Andreas. -- Andreas Schwab, sch...@linux-m68k.org GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 "And now for something completely different."
Re: contrib/completion/git-completion.bash: declare -g is not portable
On Feb 03 2018, Torsten Bögershausen <tbo...@web.de> wrote: > What is "declare -g" good for ? -gcreate global variables when used in a shell function; otherwise ignored When used in a function, `declare' makes NAMEs local, as with the `local' command. The `-g' option suppresses this behavior. Andreas. -- Andreas Schwab, sch...@linux-m68k.org GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 "And now for something completely different."
Re: [PATCH 05/14] packed-graph: implement construct_graph()
On Jan 26 2018, Junio C Hamano <gits...@pobox.com> wrote: > Also, would >>32 be a problem if commit.date is an uint32 (and > shifting all its bits out to the right)? It would be undefined. Andreas. -- Andreas Schwab, sch...@linux-m68k.org GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 "And now for something completely different."
Re: [PATCH] enable core.fsyncObjectFiles by default
On Jan 17 2018, Christoph Hellwig <h...@lst.de> wrote: > I've lost data on development machines with various times countless > times due to the lack of this option, and now lost trees on a Too many times. :-) Andreas. -- Andreas Schwab, sch...@linux-m68k.org GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 "And now for something completely different."
Re: [BUG] git remote prune removes local tags, depending on fetch config
On Jan 15 2018, Michael Giuffrida <michae...@chromium.org> wrote: > It doesn't seem like a useful feature -- you wouldn't expect `git > fetch --prune` to remove your local branches that you were developing > on, right? Don't mix local and remote refs. There is a reason why remote tracking branches are put in a separate name space. If you fetch the remote tags into a separate name space (eg. refs/remote/tags/*:refs/tags/*) then there is no conflict. Andreas. -- Andreas Schwab, sch...@linux-m68k.org GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 "And now for something completely different."
Re: [PATCH v4 1/4] Makefile: generate Perl header from template file
On Dez 01 2017, Dan Jacques <d...@google.com> wrote: > I am not a `sed` wizard, but perhaps the tool is ignoring the semicolon > because > it's in the middle of the "s" expression? The shell may similarly be ignoring > it > because it's nested in between single-quotes? As far as POSIX is concerned, semicolons are not special, but can be used to separate commands instead of newlines. Andreas. -- Andreas Schwab, sch...@linux-m68k.org GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 "And now for something completely different."
Re: [PATCH v4 0/2] launch_editor(): indicate that Git waits for user input
On Nov 30 2017, Thomas Adam <tho...@xteddy.org> wrote:
> On Thu, Nov 30, 2017 at 02:55:35PM +0100, Lars Schneider wrote:
>>
>> > On 29 Nov 2017, at 19:35, Thomas Adam <tho...@xteddy.org> wrote:
>> >
>> > On Wed, Nov 29, 2017 at 03:37:50PM +0100, lars.schnei...@autodesk.com
>> > wrote:
>> >> + if (print_waiting_for_editor) {
>> >> + fprintf(stderr, _("hint: Waiting for your editor
>> >> input..."));
>> >> fflush(stderr);
>> >
>> > Just FYI, stderr is typically unbuffered on most systems I've used, and
>> > although the call to fflush() is harmless, I suspect it's not having any
>> > effect. That said, there's plenty of other places in Git which seems to
>> > think
>> > fflush()ing stderr actually does something.
>>
>> I agree with the "unbuffered" statement. I am surprised that you expect
>> fflush()
>> to do nothing in that situation... but I am no expert in that area. Can you
>> point me to some documentation?
>
> Because stderr is unbuffered, it will get printed immediately.
POSIX only requires stderr to be "not fully buffered". If it is line
buffered, the message may not appear immediately.
Andreas.
--
Andreas Schwab, sch...@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5
"And now for something completely different."
Re: [PATCHv2 6/7] builtin/describe.c: describe a blob
On Nov 01 2017, Johannes Schindelin <johannes.schinde...@gmx.de> wrote: > Sure, but it is still a tricky thing. Imagine > > - A1 - B1 - A2 - B2 - B3 > > where all the B* commits have the blob. Do you really want to report B1 > rather than B2 as the commit introducing the blob? (I would prefer B2...) What if B3 renames or copies the blob? Andreas. -- Andreas Schwab, sch...@linux-m68k.org GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 "And now for something completely different."
Re: Why does fetch-pack not works over http?
On Okt 27 2017, Alvaro del Castillo <a...@bitergia.com> wrote: > We're wondering why "fetch-pack" (when is running from the command > line) doesn't handle "https://; protocol. It only works with "git://". > > For instance, this doesn't work: > > $ git fetch-pack https://github.com/git/git refs/heads/master > fatal: I don't handle protocol 'https' > > while this does: > > $ git fetch-pack git://github.com/git/git refs/heads/master > > The funny thing is that under the hood, "fetch" calls "fetch-pack" > using "https" procotol. Example of a trace below: > > 12:03:07.512558 git.c:344 trace: built-in: git 'fetch- > pack' '--stateless-rpc' '--stdin' '--lock-pack' '--thin' 'https://githu > b.com/git/git/' With --stateless-rpc, fetch-pack doesn't do the connect itself, but expects the caller having set up a pipe to it. The URL is then actually ignored. Andreas. -- Andreas Schwab, sch...@linux-m68k.org GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 "And now for something completely different."
Re: Minor man page weirdness?
On Okt 17 2017, Jeff King <p...@peff.net> wrote: > One other thing to try: > > rm git-branch.1 > make NO_MAN_BOLD_LITERAL=1 git-branch.1 That doesn't help: Reset to if exists already\&. Without \-f\fIgit branch\fR refuses to change an existing branch\&. In combination with Andreas. -- Andreas Schwab, sch...@linux-m68k.org GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 "And now for something completely different."
Re: Minor man page weirdness?
On Okt 16 2017, Jeff King <p...@peff.net> wrote: > We do have some hacks/workarounds for broken versions of the toolchain. > You can try tweaking various knobs you find in Documentation/Makefile). > DOCBOOK_SUPPRESS_SP sounds promising, but I think it actually does the > opposite (removes extra spaces). An easy workaround would be to add a comma between `-f` and 'git branch'. Andreas. -- Andreas Schwab, sch...@linux-m68k.org GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 "And now for something completely different."
Re: Minor man page weirdness?
On Okt 17 2017, Jeff King <p...@peff.net> wrote: > On Tue, Oct 17, 2017 at 07:25:28PM +0200, Andreas Schwab wrote: > >> >> I see this in git-branch.1: >> >> >> >> Reset to if exists already\&. >> >> Without >> >> \fB\-f\fR\fIgit branch\fR >> >> refuses to change an existing branch\&. In combination with >> >> >> >> This is with asciidoc 8.6.9. >> > >> > Thanks, that seems a likely culprit, then. What's in your git-branch.xml >> > after you build the documentation? >> >> Same as yours, with the space. I'd guess it's rather xmlto (version >> 0.0.25) that's the culprit here. > > Yes, it's in that step, but xmlto is just driving the xslt > transformation done by docbook. So the interesting version is probably > docbook. I have docbook-xsl 1.79.1+dfsg-2 (from Debian unstable). docbook-xsl-stylesheets-1.78.1+svn9743 Andreas. -- Andreas Schwab, sch...@linux-m68k.org GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 "And now for something completely different."
Re: Minor man page weirdness?
On Okt 17 2017, Jeff King <p...@peff.net> wrote: > On Tue, Oct 17, 2017 at 06:29:59PM +0200, Andreas Schwab wrote: > >> On Okt 16 2017, Jeff King <p...@peff.net> wrote: >> >> > I get: >> > >> > Reset to if exists already\&. >> > Without >> > \fB\-f\fR >> > \fIgit branch\fR >> > refuses to change an existing branch\&. In combination with >> >> I see this in git-branch.1: >> >> Reset to if exists already\&. >> Without >> \fB\-f\fR\fIgit branch\fR >> refuses to change an existing branch\&. In combination with >> >> This is with asciidoc 8.6.9. > > Thanks, that seems a likely culprit, then. What's in your git-branch.xml > after you build the documentation? Same as yours, with the space. I'd guess it's rather xmlto (version 0.0.25) that's the culprit here. Andreas. -- Andreas Schwab, sch...@linux-m68k.org GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 "And now for something completely different."
Re: Minor man page weirdness?
On Okt 16 2017, Jeff King <p...@peff.net> wrote: > I get: > > Reset to if exists already\&. Without > \fB\-f\fR > \fIgit branch\fR > refuses to change an existing branch\&. In combination with I see this in git-branch.1: Reset to if exists already\&. Without \fB\-f\fR\fIgit branch\fR refuses to change an existing branch\&. In combination with This is with asciidoc 8.6.9. Andreas. -- Andreas Schwab, sch...@linux-m68k.org GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 "And now for something completely different."
Re: Consider escaping special characters like 'less' does
On Okt 16 2017, Jeff King <p...@peff.net> wrote: > I can't help but feel this is the tip of a larger iceberg, though. E.g., > what about characters outside of the terminal's correct encoding? Or > broken UTF-8 characters? Or correctly encoded UTF-8 characters that look confusing? Or blobs with embedded escape sequences? Andreas. -- Andreas Schwab, sch...@linux-m68k.org GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 "And now for something completely different."
Re: Consider escaping special characters like 'less' does
On Okt 15 2017, "Jason Pyeron" <jpye...@pdinc.us> wrote: >> -Original Message- >> From: Joris Valette >> Sent: Sunday, October 15, 2017 9:34 AM >> To: git@vger.kernel.org >> Subject: Consider escaping special characters like 'less' does >> >> The pager 'less' escapes some characters when calling 'git diff'. This >> is what I might get: >> >> $ git diff --cached >> diff --git a/some_file b/some_file >> new file mode 100644 >> index 000..357323f >> --- /dev/null >> +++ b/some_file >> @@ -0,0 +1 @@ >> +<U+FEFF>Hello >> \ No newline at end of file >> >> This example is a simple file encoded in UTF-8 *with BOM*. >> On the other hand, the built-in git output shows this: >> >> $ git --no-pager diff --cached >> diff --git a/some_file b/some_file >> new file mode 100644 >> index 000..357323f >> --- /dev/null >> +++ b/some_file >> @@ -0,0 +1 @@ >> +?Hello >> \ No newline at end of file > > It is your terminal, not git's fault that you get a ? rendered. It's your MUA's fault that you get a ?, the mail didn't contain any. Andreas. -- Andreas Schwab, sch...@linux-m68k.org GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 "And now for something completely different."
Re: [PATCH v2] for_each_string_list_item: avoid undefined behavior for empty list
On Sep 21 2017, Junio C Hamano <gits...@pobox.com> wrote: > Now you make me curious. How would that variant be different from > option C. in Jonathan's message? Only in the parity of the condition. Andreas. -- Andreas Schwab, sch...@linux-m68k.org GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 "And now for something completely different."
Re: [PATCH v2] for_each_string_list_item: avoid undefined behavior for empty list
On Sep 20 2017, Jonathan Nieder <jrnie...@gmail.com> wrote: > Andreas Schwab wrote: >> On Sep 19 2017, Jonathan Nieder <jrnie...@gmail.com> wrote: > >>> B. #define for_each_string_list_item(item, list) \ >>> if (list->items) \ >>> for (item = ...; ...; ... ) >>> >>>This breaks a caller like >>> if (foo) >>> for_each_string_list_item(item, list) >>> ... >>> else >>> ... >>> >>>making it a non-starter. >> >> That can be fixed with a dangling else. > > I believe the fix you're referring to is option C, from the same email > you are replying to. If not, please correct me. A variant thereof, yes. Andreas. -- Andreas Schwab, sch...@linux-m68k.org GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 "And now for something completely different."
Re: [PATCH v2] for_each_string_list_item: avoid undefined behavior for empty list
On Sep 19 2017, Jonathan Nieder <jrnie...@gmail.com> wrote: > B. #define for_each_string_list_item(item, list) \ > if (list->items) \ > for (item = ...; ...; ... ) > >This breaks a caller like > if (foo) > for_each_string_list_item(item, list) > ... > else > ... > >making it a non-starter. That can be fixed with a dangling else. Andreas. -- Andreas Schwab, sch...@linux-m68k.org GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 "And now for something completely different."
Re: git-describe --contains
On Aug 11 2017, Davide Cavallari <davide.cavall...@gmail.com> wrote: > Please help me understand how this command works. There is one case in the > linux kernel repository that puzzles me. Let's consider patch "drm/i915/ > execlists: Reset RING registers upon resume" [1]. This patch was committed 641 > commits after version 4.8-rc2: > > ~$ git describe bafb2f7d4755bf1571bd5e9a03b97f3fc4fe69ae > v4.8-rc2-641-gbafb2f7d4755 > > So I would expect to find it in version 4.8-rc3 and later versions. > > However, if I search for the tag that follows (and hence contains) that > commit, I do not find version 4.8-rc3, nor version 4.8, nor version 4.9, but > 4.10-rc1: > > ~$ git describe --contains bafb2f7d4755bf1571bd5e9a03b97f3fc4fe69ae > v4.10-rc1~154^2~44^2~178 > > Why? Why not v4.8-rc3? This means that the patch has been included neither in > v4.8 nor in v4.9, but only in version 4.10-rc1, right? Why so much time was > needed, considering it was the 621st commit on top ov v4.8-rc2? You have to ask that the maintainers of the drm subsystem. If you look at commit 5481e27f6fd06b7cb902072e81d6b083db8155eb you see that the branch containing the above commit was merged into a branch that follows v4.9-rc2, which eventually was merged into v4.10-rc1. > BTW, what are the numbers 154^2~44^2~178 that follow the tag name? See git-rev-parse(1). '~N' means to go back N parents, ^N means to pick parent N of a merge commit. Andreas. -- Andreas Schwab, sch...@linux-m68k.org GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 "And now for something completely different."
Re: [PATCH] tests: don't give unportable ">" to "test" built-in, use -gt
On Aug 06 2017, Ævar Arnfjörð Bjarmason <ava...@gmail.com> wrote: > diff --git a/t/t7004-tag.sh b/t/t7004-tag.sh > index 0ef7b94394..0e2e57aa3d 100755 > --- a/t/t7004-tag.sh > +++ b/t/t7004-tag.sh > @@ -1887,7 +1887,7 @@ EOF" > run_with_limited_stack git tag --contains HEAD >actual && > test_cmp expect actual && > run_with_limited_stack git tag --no-contains HEAD >actual && > - test_line_count ">" 10 actual > + test_line_count "-gt" 10 actual Maybe also remove the quotes, they are no longer needed. Andreas. -- Andreas Schwab, sch...@linux-m68k.org GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 "And now for something completely different."
Re: [RFC] imap-send: escape backslash in password
On Aug 04 2017, Junio C Hamano <gits...@pobox.com> wrote: > Is the quoting rules documented somewhere? If so, please also give > a reference to it here. RFC3501 "6.2.3 LOGIN Command" does not say > much (other parts of the RFC may specify the rules that apply to > arguments in general, but I didn't look for them). Without such > reference, it is hard to judge if this change is sufficient or even > correct (in an extreme case, the IMAP server you are talking with > that prompted you to make this change might be in violation). > > For example, FRC3501 "9. Formal Syntax" says that both "password" > and "userid" are "astring"; it looks strange that the code with this > patch only touches cred.password while sending cred.username as-is. astring = ... / string string = quoted / ... quoted = DQUOTE *QUOTED-CHAR DQUOTE QUOTED-CHAR = / "\" quoted-specials quoted-specials = DQUOTE / "\" Thus the quoting applies to any element that is a string (and a double quote needs to be quoted as well). Andreas. -- Andreas Schwab, sch...@linux-m68k.org GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 "And now for something completely different."
Re: Git on macOS shows committed files as untracked
On Jul 14 2017, Torsten Bögershausen <tbo...@web.de> wrote: > (Please no top-posting) > On 14/07/17 11:45, Elliot Chandler wrote: >> For what it's worth, the file looks normal in Gentoo GNU/Linux (name >> appears "ḋἲ╓εﮯ○╓Ӳ" and it seems to work like any other directory). >> > Thanks for testing - > Normal and Normal ;-) > For me the 6th code point does look strange > The "box" with 04142F: This is actually 1244f (CUNEIFORM NUMERIC SIGN ONE BAN2). Andreas. -- Andreas Schwab, sch...@linux-m68k.org GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 "And now for something completely different."
Re: [PATCH] strbuf: use designated initializers in STRBUF_INIT
On Jul 10 2017, Jeff King <p...@peff.net> wrote: > If this patch can survive a few releases without complaint, > then we can feel more confident that designated initializers > are widely supported by our user base. It also is an > indication that other C99 features may be supported, but not > a guarantee (e.g., gcc had designated initializers before > C99 existed). Note that the GNU C designated initializers initially used a different syntax than the one C99 adopted. Andreas. -- Andreas Schwab, sch...@linux-m68k.org GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 "And now for something completely different."
Re: [PATCH] apply: use strcmp(3) for comparing strings in gitdiff_verify_name()
On Jul 09 2017, René Scharfe <l@web.de> wrote: > [2] http://pubs.opengroup.org/onlinepubs/009695399/functions/memchr.html You are using an old revision. Andreas. -- Andreas Schwab, sch...@linux-m68k.org GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 "And now for something completely different."
Re: [PATCH] apply: use strcmp(3) for comparing strings in gitdiff_verify_name()
On Jul 08 2017, René Scharfe <l@web.de> wrote: > Am 08.07.2017 um 13:08 schrieb Andreas Schwab: >> On Jul 08 2017, René Scharfe <l@web.de> wrote: >> >>> Avoid running over the end of another -- a C string whose length we >>> don't know -- by using strcmp(3) instead of memcmp(3) for comparing it >>> with another C string. >> >> That's not a good justification for the change, since memcmp never reads >> past the differing characters. > > Interesting. Where does that guarantee come from? Sorry, I misremembered. It's only memchr that has this restriction. Andreas. -- Andreas Schwab, sch...@linux-m68k.org GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 "And now for something completely different."
Re: [PATCH] apply: use strcmp(3) for comparing strings in gitdiff_verify_name()
On Jul 08 2017, René Scharfe <l@web.de> wrote: > Avoid running over the end of another -- a C string whose length we > don't know -- by using strcmp(3) instead of memcmp(3) for comparing it > with another C string. That's not a good justification for the change, since memcmp never reads past the differing characters. Andreas. -- Andreas Schwab, sch...@linux-m68k.org GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 "And now for something completely different."
Re: Migration from CVS to Git looses merges
On Jun 25 2017, Urs Thuermann <u...@isnogud.escape.de> wrote: > In both cases, the branch "a-branch" is in the git repository but is > not merged with the master branch, i.e. rev 1.4 has only parent 1.3 > but not 1.2.2.2. I also tried cvsimport with several regexes passed > using -M to match "Merge branch a-branch", but still the same result. Merges are recognized purely by matching the commit message, and the regexp must capture the branch name in the first subexpr. The -m option enables some default regexps but won't match your example. You can use -M 'Merge branch ([-\w]+)' to match it. Andreas. -- Andreas Schwab, sch...@linux-m68k.org GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 "And now for something completely different."
Re: [PATCH v2 1/2] git-compat-util: add a FREEZ() wrapper around free(ptr); ptr = NULL
On Jun 09 2017, Jonathan Nieder <jrnie...@gmail.com> wrote: > That way side-effectful callers like FREEZ(func() ? a : b) would > work. Except that you cannot take the address of a non-lvalue. Andreas. -- Andreas Schwab, sch...@linux-m68k.org GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 "And now for something completely different."
Re: Unaligned accesses in sha1dc
On Jun 01 2017, Junio C Hamano <gits...@pobox.com> wrote: > Depending on the model of "ARM" (or "SPARC") emulated with QEMU, and > depending on the OS that runs on such an "ARM" or "SPARC", we may > not see this---if the emulated OS has the "software unaligned-access > emulation" our userland may not see a SIGBUS. Even if the architecture implements unaligned accesses in hardware, it is still undefined behaviour, and the compiler will (eventually) take advantage of it. Andreas. -- Andreas Schwab, SUSE Labs, sch...@suse.de GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE 1748 E4D4 88E3 0EEA B9D7 "And now for something completely different."
Re: Unaligned accesses in sha1dc
On Jun 01 2017, "brian m. carlson" <sand...@crustytoothpaste.net> wrote: > On Thu, Jun 01, 2017 at 10:28:52AM +0200, Andreas Schwab wrote: >> The sh1dc implementation is making unaligned accesses, which will crash >> on some architectures, others have to emulate them in software. >> >> Breakpoint 4, sha1_compression_states (ihv=0x600e7010, >> m=, W=0x600e70a8, states=0x600e7328) >> at sha1dc/sha1.c:398 >> 398 SHA1COMPRESS_FULL_ROUND2_STEP(e, a, b, c, d, W, 21, temp); >> (gdb) n >> 403 SHA1COMPRESS_FULL_ROUND2_STEP(d, e, a, b, c, W, 22, temp); >> (gdb) >> 408 SHA1COMPRESS_FULL_ROUND2_STEP(c, d, e, a, b, W, 23, temp); >> (gdb) >> 413 SHA1COMPRESS_FULL_ROUND2_STEP(b, c, d, e, a, W, 24, temp); >> (gdb) >> 418 SHA1COMPRESS_FULL_ROUND2_STEP(a, b, c, d, e, W, 25, temp); >> (gdb) >> 291 SHA1COMPRESS_FULL_ROUND1_STEP_LOAD(a, b, c, d, e, m, W, 0, >> temp); >> (gdb) >> git(21728): unaligned access to 0x6009f8d5, ip=0x403336d0 >> 423 SHA1COMPRESS_FULL_ROUND2_STEP(e, a, b, c, d, W, 26, temp); > > What architecture are you seeing this on? It doesn't matter. Andreas. -- Andreas Schwab, SUSE Labs, sch...@suse.de GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE 1748 E4D4 88E3 0EEA B9D7 "And now for something completely different."
Re: Unaligned accesses in sha1dc
This is git 2.13.0. Andreas. -- Andreas Schwab, SUSE Labs, sch...@suse.de GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE 1748 E4D4 88E3 0EEA B9D7 "And now for something completely different."
Re: Unaligned accesses in sha1dc
SHA1DCUpdate calls sha1_process with buf being unaligned. Andreas. -- Andreas Schwab, SUSE Labs, sch...@suse.de GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE 1748 E4D4 88E3 0EEA B9D7 "And now for something completely different."
Unaligned accesses in sha1dc
The sh1dc implementation is making unaligned accesses, which will crash on some architectures, others have to emulate them in software. Breakpoint 4, sha1_compression_states (ihv=0x600e7010, m=, W=0x600e70a8, states=0x600e7328) at sha1dc/sha1.c:398 398 SHA1COMPRESS_FULL_ROUND2_STEP(e, a, b, c, d, W, 21, temp); (gdb) n 403 SHA1COMPRESS_FULL_ROUND2_STEP(d, e, a, b, c, W, 22, temp); (gdb) 408 SHA1COMPRESS_FULL_ROUND2_STEP(c, d, e, a, b, W, 23, temp); (gdb) 413 SHA1COMPRESS_FULL_ROUND2_STEP(b, c, d, e, a, W, 24, temp); (gdb) 418 SHA1COMPRESS_FULL_ROUND2_STEP(a, b, c, d, e, W, 25, temp); (gdb) 291 SHA1COMPRESS_FULL_ROUND1_STEP_LOAD(a, b, c, d, e, m, W, 0, temp); (gdb) git(21728): unaligned access to 0x6009f8d5, ip=0x403336d0 423 SHA1COMPRESS_FULL_ROUND2_STEP(e, a, b, c, d, W, 26, temp); Andreas. -- Andreas Schwab, SUSE Labs, sch...@suse.de GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE 1748 E4D4 88E3 0EEA B9D7 "And now for something completely different."
Re: Bug: wrong documentation for git-fast-import's option command
On Apr 30 2017, Tomi Belan <tomi.be...@gmail.com> wrote:
> The man page of git-fast-import says the syntax is "'option' SP
> LF". But this is wrong, and commands like that will be
> silently ignored.
Unless starts with 'git', as you have seen. Other importers
may recognize other options, eg 'option hg ...'.
> The correct syntax is e.g. "option git stats" or "option git
> big-file-threshold=123". The docs should say "'option' SP 'git' SP
> LF" or maybe even "'option' SP 'git' SP ('='
> )? LF" (similarly to the docs for feature), and explain this
> is meant to allow other consumers of the fast import format.
>
> Looks like this bug existed since the option command was added in
> 9c8398f in 2009. Am I the first one who tried to use it? ;-)
>
> Cheers,
>
> Tomi
>
Andreas.
--
Andreas Schwab, sch...@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5
"And now for something completely different."
Re: [PATCH v2] rebase -i: add config to abbreviate command-names
On Apr 25 2017, Liam Beguin <liambeg...@gmail.com> wrote: > Add the 'rebase.abbrevCmd' boolean config option to allow `git rebase -i` > to abbreviate the command-names in the instruction list. > > This means that `git rebase -i` would print: > p deadbee The oneline of this commit > ... > > instead of: > pick deadbee The oneline of this commit > ... > > Using a single character command-name allows the lines to remain > aligned, making the whole set more readable. Perhaps there should rather be an option to tell rebase to align the columns? Andreas. -- Andreas Schwab, sch...@linux-m68k.org GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 "And now for something completely different."
Re: [PATCH v2] rebase -i: add config to abbreviate command-names
On Apr 25 2017, Liam Beguin <liambeg...@gmail.com> wrote: > diff --git a/Documentation/config.txt b/Documentation/config.txt > index 475e874d5155..8b1877f2df91 100644 > --- a/Documentation/config.txt > +++ b/Documentation/config.txt > @@ -2614,6 +2614,25 @@ rebase.instructionFormat:: > the instruction list during an interactive rebase. The format will > automatically > have the long commit hash prepended to the format. > > +rebase.abbrevCmd:: > + If set to true, `git rebase -i` will abbreviate the command-names in the > + instruction list. This means that instead of looking like this, > + > +--- > + pick deadbee The oneline of this commit > + pick fa1afe1 The oneline of the next commit > + ... > +--- > + > + the list would use the short version of the command resulting in > + something like this. > + > +--- > + p deadbee The oneline of this commit > + p fa1afe1 The oneline of the next commit > + ... > +----------- That doesn't explain the point of the option. Andreas. -- Andreas Schwab, sch...@linux-m68k.org GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 "And now for something completely different."
Re: BUG: Renaming a branch checked out in a different work tree
On Mär 29 2017, Eyal Lotem <eyal.lo...@gmail.com> wrote: > git version: 2.7.4 > installed from Ubuntu repos: > Ubuntu Version: 1:2.7.4-0ubuntu1 > > When renaming a branch checked out in a different work tree, that work > tree's state is corrupted. Git status in that work tree then reports > itself being on the "initial commit" with all files being in the > staging area. Fixed since 2.8.3. Andreas. -- Andreas Schwab, sch...@linux-m68k.org GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 "And now for something completely different."
Re: Confusing git messages when disk is full.
On Feb 15 2017, Jeff King <p...@peff.net> wrote:
> On Wed, Feb 15, 2017 at 02:50:19PM -0800, Junio C Hamano wrote:
>
>> > That works, but the fact that we need a comment is a good sign that it's
>> > kind of gross. It's too bad stdio does not specify the return of fclose
>> > to report an error in the close _or_ any previous error. I guess we
>> > could wrap it with our own function.
>>
>> Sure. I am happy to add something like this:
>>
>> /*
>> * closes a FILE *, returns 0 if closing and all the
>> * previous stdio operations on fp were successful,
>> * otherwise non-zero.
>> */
>> int xfclose(FILE *fp)
>> {
>> return ferror(fp) | fclose(fp);
>> }
>
> Yes, that's exactly what I had in mind (might be worth calling out the
> bitwise-OR, though, just to make it clear it's not a typo).
Since the order of evaluation is unspecified, it would be better to
force sequencing ferror before fclose.
Andreas.
--
Andreas Schwab, sch...@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5
"And now for something completely different."
Re: Test failures when Git is built with libpcre and grep is built without it
On Jan 09 2017, "A. Wilcox" <awil...@adelielinux.org> wrote:
> Interestingly enough, you seem to be right. The failure is very
> bizarre and has nothing to do with system /bin/grep:
>
> test_must_fail: command succeeded: git grep -G -F -P -E a\x{2b}b\x{2a}c ab
> not ok 142 - grep -G -F -P -E pattern
> #
> # >empty &&
> # test_must_fail git grep -G -F -P -E "a\x{2b}b\x{2a}c"
> ab >actual &&
> # test_cmp empty actual
> #
>
> However:
>
> elaine trash directory.t7810-grep # git grep -G -F -P -E
> a\x{2b}b\x{2a}c ab >actual
You need to quote the regexp argument, see the line starting with
"test_must_fail" above.
Andreas.
--
Andreas Schwab, sch...@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5
"And now for something completely different."
Re: [PATCH v3] am: add am.signoff add config variable
On Dez 28 2016, Eduardo Habkost <ehabk...@redhat.com> wrote: > @@ -32,10 +32,12 @@ OPTIONS > If you supply directories, they will be treated as Maildirs. > > -s:: > ---signoff:: > +--[no-]-signoff:: That's one dash too much. Andreas. -- Andreas Schwab, sch...@linux-m68k.org GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 "And now for something completely different."
Re: [PATCH v2] am: add am.signoff add config variable
On Dez 28 2016, Eduardo Habkost <ehabk...@redhat.com> wrote: > diff --git a/Documentation/git-am.txt b/Documentation/git-am.txt > index 12879e402..f22f10d40 100644 > --- a/Documentation/git-am.txt > +++ b/Documentation/git-am.txt > @@ -9,7 +9,7 @@ git-am - Apply a series of patches from a mailbox > SYNOPSIS > > [verse] > -'git am' [--signoff] [--keep] [--[no-]keep-cr] [--[no-]utf8] > +'git am' [--[no-]signoff] [--keep] [--[no-]keep-cr] [--[no-]utf8] >[--[no-]3way] [--interactive] [--committer-date-is-author-date] >[--ignore-date] [--ignore-space-change | --ignore-whitespace] >[--whitespace=] [-C] [-p] [--directory=] > @@ -32,10 +32,12 @@ OPTIONS > If you supply directories, they will be treated as Maildirs. > > -s:: > ---signoff:: > +--[no]-signoff:: That should be --[no-]signoff, as in the synopsis. Andreas. -- Andreas Schwab, sch...@linux-m68k.org GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 "And now for something completely different."
[PATCH v2] t6026-merge-attr: don't fail if sleep exits early
Commit 5babb5bdb3 ("t6026-merge-attr: clean up background process at end
of test case") added a kill command to clean up after the test, but this
can fail if the sleep command exits before the cleanup is executed.
Ignore the error from the kill command.
Explicitly check for the existence of the pid file to test that the merge
driver was actually called.
Signed-off-by: Andreas Schwab <sch...@suse.de>
---
t/t6026-merge-attr.sh | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/t/t6026-merge-attr.sh b/t/t6026-merge-attr.sh
index 7a6e33e673..03d13d00b5 100755
--- a/t/t6026-merge-attr.sh
+++ b/t/t6026-merge-attr.sh
@@ -187,13 +187,14 @@ test_expect_success 'custom merge does not lock index' '
sleep 1 &
echo $! >sleep.pid
EOF
- test_when_finished "kill \$(cat sleep.pid)" &&
+ test_when_finished "kill \$(cat sleep.pid) || :" &&
test_write_lines >.gitattributes \
"* merge=ours" "text merge=sleep-one-second" &&
test_config merge.ours.driver true &&
test_config merge.sleep-one-second.driver ./sleep-one-second.sh &&
- git merge master
+ git merge master &&
+ test -f sleep.pid
'
test_done
--
2.10.2
--
Andreas Schwab, SUSE Labs, sch...@suse.de
GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE 1748 E4D4 88E3 0EEA B9D7
"And now for something completely different."
Re: [PATCH] t6026-merge-attr: don't fail if sleep exits early
On Nov 09 2016, Johannes Schindelin <johannes.schinde...@gmx.de> wrote: > The reason why we do not ignore kill errors is that we want to make sure > that the script *actually ran*. Otherwise, the thing we need to test here > does not necessarily get tested. That can be tested by looking for the pid file. Andreas. -- Andreas Schwab, SUSE Labs, sch...@suse.de GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE 1748 E4D4 88E3 0EEA B9D7 "And now for something completely different."
[PATCH] t6026-merge-attr: don't fail if sleep exits early
Commit 5babb5bdb3 ("t6026-merge-attr: clean up background process at end
of test case") added a kill command to clean up after the test, but this
can fail if the sleep command exits before the cleanup is executed.
Ignore the error from the kill command.
Signed-off-by: Andreas Schwab <sch...@suse.de>
---
The failure can be simulated by adding a sleep after the last command to
delay the cleanup.
---
t/t6026-merge-attr.sh | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/t/t6026-merge-attr.sh b/t/t6026-merge-attr.sh
index 7a6e33e673..2672b15aa3 100755
--- a/t/t6026-merge-attr.sh
+++ b/t/t6026-merge-attr.sh
@@ -187,7 +187,7 @@ test_expect_success 'custom merge does not lock index' '
sleep 1 &
echo $! >sleep.pid
EOF
- test_when_finished "kill \$(cat sleep.pid)" &&
+ test_when_finished "kill \$(cat sleep.pid) || :" &&
test_write_lines >.gitattributes \
"* merge=ours" "text merge=sleep-one-second" &&
--
2.10.2
--
Andreas Schwab, SUSE Labs, sch...@suse.de
GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE 1748 E4D4 88E3 0EEA B9D7
"And now for something completely different."
Re: [PATCH] reset: --unmerge
On Okt 25 2016, Junio C Hamano <gits...@pobox.com> wrote: > Somebody with a bright idea decided that vc-git-resolve-conflicts > variable should be on by default in Emacs 25.1 X-< This is consistent with the behaviour of the other VC backends, where it isn't even customizable. Andreas. -- Andreas Schwab, sch...@linux-m68k.org GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 "And now for something completely different."
Re: git clone --bare --origin incompatible?
On Okt 23 2016, Roman Neuhauser <neuhau...@sigpipe.cz> wrote: > what is the reason clone --bare prohibits --origin? > > % git clone --bare -o fubar anything anywhere > fatal: --bare and --origin fubar options are incompatible. Since a bare clone maps remote branches directly to local branches, without any remote-tracking branches, --origin doesn't make sense. Andreas. -- Andreas Schwab, sch...@linux-m68k.org GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 "And now for something completely different."
Re: Bug: git-add .* errors out
On Sep 12 2016, Pranit Bauva <pranit.ba...@gmail.com> wrote: > One of my friend was trying to add files using the command `git add > .*` and got an error that "fatal: ..: '..' is outside repository" > which did seem a little obvious to me. But then I tried to reproduce > it in my machine with `git add ".*"` and it didn't error out. Probably you were running it in a subdirectory. Andreas. -- Andreas Schwab, sch...@linux-m68k.org GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 "And now for something completely different."
Re: Most recent revision that contains a string
On Aug 20 2016, Josh Triplett <j...@joshtriplett.org> wrote: > If you want to find a change that introduces or removes a particular > string, you could use "git log -S". That doesn't allow regexes, It does, actually, see --pickaxe-regex. Andreas. -- Andreas Schwab, sch...@linux-m68k.org GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 "And now for something completely different." -- 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-info.html
Re: git format-patch --break-rewrites broken in 2.9.3
On Aug 19 2016, "Philip Oakley" <philipoak...@iee.org> wrote: > On Thu, Aug 18, 2016 at 04:44:21PM +0200, Olaf Hering wrote: > >> This command used to create a diff which can be consumed by patch. But >> at least with 2.9.3 it just gives a rename output: >> >> git format-patch \ >> --no-signature \ >> --stdout \ >> --break-rewrites \ >> --keep-subject \ >> >> 95fa0405c5991726e06c08ffcd8ff872f7fb4f2d^..95fa0405c5991726e06c08ffcd8ff872f7fb4f2d >> >> >> What must be done now to get a usable patch? > > As an aside, the range can be shortened to > > 95fa0405c5991726e06c08ffcd8ff872f7fb4f2d^! In the context of format-patch you can also use -1 to select the topmost commit from the list. Andreas. -- Andreas Schwab, sch...@linux-m68k.org GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 "And now for something completely different." -- 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-info.html
Re: Minor bug: git config ignores empty sections
On Aug 15 2016, Junio C Hamano <gits...@pobox.com> wrote: > If we were to remove the section header at this point, we should > be removing the comment two out of three cases. > > - if it is about section.key, it should go when section.key goes. > - if it is about section, it should go when section goes. > - if it is a more generic comment about this configuration file, >it should stay. The comment may not be related to the surrounding keys, but just a commented-out config key that you want to keep around for reference. Andreas. -- Andreas Schwab, sch...@linux-m68k.org GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 "And now for something completely different." -- 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-info.html
Re: Minor bug: git config ignores empty sections
On Aug 15 2016, Jeff King <p...@peff.net> wrote: > And implicit in your test is the other bug, which is that deleting the > last key in a section leaves the empty header. I think it's related to > the same issue. Indiscriminately removing empty section headers may break comments that have been put there on purpose. Andreas. -- Andreas Schwab, sch...@linux-m68k.org GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 "And now for something completely different." -- 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-info.html
Re: [PATCH 1/2] mailinfo: extract is_from_line from mailsplit
Johannes Schindelin <johannes.schinde...@gmx.de> writes:
> Hi Andreas,
>
> On Sun, 24 Jul 2016, Andreas Schwab wrote:
>
>> Eric Wong <e...@80x24.org> writes:
>>
>> > diff --git a/mailinfo.c b/mailinfo.c
>> > index 9f19ca1..0ebd953 100644
>> > --- a/mailinfo.c
>> > +++ b/mailinfo.c
>> > @@ -1035,3 +1035,34 @@ void clear_mailinfo(struct mailinfo *mi)
>> >
>> >strbuf_release(>log_message);
>> > }
>> > +
>> > +int is_from_line(const char *line, int len)
>> > +{
>> > + const char *colon;
>> > +
>> > + if (len < 20 || memcmp("From ", line, 5))
>> > + return 0;
>> > +
>> > + colon = line + len - 2;
>> > + line += 5;
>> > + for (;;) {
>> > + if (colon < line)
>> > + return 0;
>> > + if (*--colon == ':')
>> > + break;
>> > + }
>> > +
>> > + if (!isdigit(colon[-4]) ||
>> > + !isdigit(colon[-2]) ||
>> > + !isdigit(colon[-1]) ||
>> > + !isdigit(colon[ 1]) ||
>> > + !isdigit(colon[ 2]))
>> > + return 0;
>> > +
>> > + /* year */
>> > + if (strtol(colon+3, NULL, 10) <= 90)
>> > + return 0;
>> > +
>> > + /* Ok, close enough */
>> > + return 1;
>> > +}
>>
>> Should this be made more strict, like by checking for a space before the
>> year?
>
> This patch only moves the function, so it would be inappropriate to change
> it.
>
> If you want to make it stricter, you will have to submit a separate patch.
You didn't answer my question.
Andreas.
--
Andreas Schwab, sch...@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5
"And now for something completely different."
--
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-info.html
Re: [PATCH 1/2] mailinfo: extract is_from_line from mailsplit
Eric Wong <e...@80x24.org> writes:
> diff --git a/mailinfo.c b/mailinfo.c
> index 9f19ca1..0ebd953 100644
> --- a/mailinfo.c
> +++ b/mailinfo.c
> @@ -1035,3 +1035,34 @@ void clear_mailinfo(struct mailinfo *mi)
>
> strbuf_release(>log_message);
> }
> +
> +int is_from_line(const char *line, int len)
> +{
> + const char *colon;
> +
> + if (len < 20 || memcmp("From ", line, 5))
> + return 0;
> +
> + colon = line + len - 2;
> + line += 5;
> + for (;;) {
> + if (colon < line)
> + return 0;
> + if (*--colon == ':')
> + break;
> + }
> +
> + if (!isdigit(colon[-4]) ||
> + !isdigit(colon[-2]) ||
> + !isdigit(colon[-1]) ||
> + !isdigit(colon[ 1]) ||
> + !isdigit(colon[ 2]))
> + return 0;
> +
> + /* year */
> + if (strtol(colon+3, NULL, 10) <= 90)
> + return 0;
> +
> + /* Ok, close enough */
> + return 1;
> +}
Should this be made more strict, like by checking for a space before the
year?
Andreas.
--
Andreas Schwab, sch...@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5
"And now for something completely different."
--
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-info.html
Re: [ANNOUNCE] Git v2.9.1
Johannes Schindelin <johannes.schinde...@gmx.de> writes: > So I got curious and looked at the man page. It says indeed that strtoul() > returns ULONG_MAX, which happens to translate into a date in the year > 2038. 4294967295 would rather be 2106. $ date -d @$((0x)) So 7. Feb 07:28:15 CET 2106 Andreas. -- Andreas Schwab, sch...@linux-m68k.org GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 "And now for something completely different." -- 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-info.html
Re: [ANNOUNCE] Git v2.9.1
Jeff King <p...@peff.net> writes: > In case it wasn't clear, I was mostly guessing there. So I dug a bit > further, and indeed, I am wrong. Linux never bumped to a 64-bit time_t > on i386 because of the ABI headaches. This is being worked on. Andreas. -- Andreas Schwab, sch...@linux-m68k.org GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 "And now for something completely different." -- 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-info.html
Re: [ANNOUNCE] Git v2.9.1
Johannes Schindelin <johannes.schinde...@gmx.de> writes: > Hi Andreas, > > On Tue, 12 Jul 2016, Andreas Schwab wrote: > >> Johannes Schindelin <schinde...@wisc.edu> writes: >> >> >> PRIuMAX isn't compatible with time_t. >> > >> > That statement is wrong. >> >> No, it isn't. PRIuMAX is for uintmax_t, and time_t is not uintmax_t >> (even if they happen to have the same representation). > > Sigh. > > So if it is wrong, what is right? The right thing is to add a cast, of course. Andreas. -- Andreas Schwab, sch...@linux-m68k.org GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 "And now for something completely different." -- 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-info.html
Re: [ANNOUNCE] Git v2.9.1
Johannes Schindelin <schinde...@wisc.edu> writes: >> PRIuMAX isn't compatible with time_t. > > That statement is wrong. No, it isn't. PRIuMAX is for uintmax_t, and time_t is not uintmax_t (even if they happen to have the same representation). Andreas. -- Andreas Schwab, sch...@linux-m68k.org GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 "And now for something completely different." -- 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-info.html
Re: [ANNOUNCE] Git v2.9.1
Johannes Schindelin <johannes.schinde...@gmx.de> writes:
> @@ -88,11 +88,11 @@ static int local_tzoffset(unsigned long time)
> return offset * eastwest;
> }
>
> -void show_date_relative(unsigned long time, int tz,
> +void show_date_relative(time_t time, int tz,
> const struct timeval *now,
> struct strbuf *timebuf)
> {
> - unsigned long diff;
> + time_t diff;
> if (now->tv_sec < time) {
> strbuf_addstr(timebuf, _("in the future"));
> return;
> @@ -100,65 +100,65 @@ void show_date_relative(unsigned long time, int tz,
> diff = now->tv_sec - time;
> if (diff < 90) {
> strbuf_addf(timebuf,
> - Q_("%lu second ago", "%lu seconds ago", diff), diff);
> + Q_("%" PRIuMAX " second ago", "%" PRIuMAX " seconds
> ago", diff), diff);
PRIuMAX isn't compatible with time_t.
Andreas.
--
Andreas Schwab, sch...@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5
"And now for something completely different."
--
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-info.html
Re: [ANNOUNCE] Git v2.9.1
Junio C Hamano <gits...@pobox.com> writes: > local_tzoffset: detect errors from tm_to_time_t not ok 19 - show date (iso:5758122296 -0400) # # echo "$time -> $expect" >expect && # test-date show:$format "$time" >actual && # test_cmp expect actual # not ok 20 - show date (iso-local:5758122296 -0400) # # echo "$time -> $expect" >expect && # test-date show:$format "$time" >actual && # test_cmp expect actual This is outside the range of 32bit time_t. Andreas. -- Andreas Schwab, sch...@linux-m68k.org GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 "And now for something completely different." -- 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-info.html
Re: Odd git overrflow bug?
Linus Torvalds <torva...@linux-foundation.org> writes: > We have an odd bug report in the kernel, where somebody had trouble > bisecting all the way due to > > "git is failing with "you are trying to use to much memory"(?!)" > > which can't be an exact error message quote, but the closest I can > find smells like the "unsigned_add_overflows()" check in the strbuf > code. Very odd. I've seen that too, but only at the end of bisection, when it tries to display the bad commit. For example, when running git bisect on git://gcc.gnu.org/git/gcc: $ git bisect start de4fa746271d39d490b59bdfbbdd2cf5b54c0521 dd58bf212e9a250300e64d78748418b01d0035cd Bisecting: 0 revisions left to test after this (roughly 0 steps) [f529d395184700e2404f4a293a2198355ab7ded5] Daily bump. $ git bisect good de4fa746271d39d490b59bdfbbdd2cf5b54c0521 is the first bad commit commit de4fa746271d39d490b59bdfbbdd2cf5b54c0521 fatal: you want to use way too much memory Andreas. -- Andreas Schwab, sch...@linux-m68k.org GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 "And now for something completely different." -- 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-info.html
Re: Fwd: git rm
Peter <peter...@gmail.com> writes: > Ah, ok, I see now. But are there any other situations where the "-f" > switch is not needed? When the file is unmodified and matches the index. Andreas. -- Andreas Schwab, sch...@linux-m68k.org GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 "And now for something completely different." -- 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-info.html
Re: Fwd: git rm
Peter <peter...@gmail.com> writes: > So if I do: > > touch abc > git add abc > > > And after that I do: > > git rm abc error: the following file has changes staged in the index: abc (use --cached to keep the file, or -f to force removal) Andreas. -- Andreas Schwab, sch...@linux-m68k.org GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 "And now for something completely different." -- 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-info.html
Re: Fwd: git rm
Peter <peter...@gmail.com> writes: > I am a lightweigt git user so by all means not a reference, but I was > wondering why exactly does "git rm" also delete the file (remove it > from the working tree). I see it as an unintended behaviour as git is > written in a way that it preserves the most data. The data is still preserved. You can restore it with "git checkout HEAD ". Andreas. -- Andreas Schwab, sch...@linux-m68k.org GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 "And now for something completely different." -- 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-info.html
Re: split directories into branches
shawn wilson <ag4ve...@gmail.com> writes: > $ git filter-branch --tree-filter "shopt -s extglob && mkdir -p > cookbooks/base_sys && mv !(cookbooks) cookbooks/base_sys" extglob changes the parser, you need to set that on a separate line. Andreas. -- Andreas Schwab, sch...@linux-m68k.org GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 "And now for something completely different." -- 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-info.html
Re: unable to pull from remote if commit date is in the future
Norbert Kiesel <nkie...@gmail.com> writes: > For the record: the faulty commit is > https://github.com/seandepagnier/weather_routing_pi/commit/23c07cc5d2be7ce68349f4b3719b6fa6fe90e0bf That commit is part of master. Are you sure you don't have it already? Andreas. -- Andreas Schwab, sch...@linux-m68k.org GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 "And now for something completely different." -- 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-info.html
Re: [PATCH] prune: keep files created after process start
Eric Wong <e...@80x24.org> writes:
> @@ -21,7 +22,7 @@ static int prune_tmp_file(const char *fullpath)
> struct stat st;
> if (lstat(fullpath, ))
> return error("Could not stat '%s'", fullpath);
> - if (st.st_mtime > expire)
> + if (st.st_mtime > expire || st.st_ctime >= start)
That will also mean objects created (or their inode changed) up to a
second before the start of prune will not be removed. For example,
objects ejected out of a pack by a previous repack may be affected.
Andreas.
--
Andreas Schwab, sch...@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5
"And now for something completely different."
--
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-info.html
Re: t6044 broken on pu
Torsten Bögershausen <tbo...@web.de> writes: > The "seq" is not understood by all shells, > using printf fixes this, > > index 20a3ffe..48d964e 100755 > --- a/t/t6044-merge-unrelated-index-changes.sh > +++ b/t/t6044-merge-unrelated-index-changes.sh > @@ -20,7 +20,7 @@ test_description="merges with unrelated index changes" > # Commit E: renames a->subdir/a, adds subdir/e > > test_expect_success 'setup trivial merges' ' > - seq 1 10 >a && > + printf 1 2 3 4 5 7 8 9 10 >a && $ printf 1 2 3 4 5 7 8 9 10 1 Andreas. -- Andreas Schwab, sch...@linux-m68k.org GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 "And now for something completely different." -- 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-info.html
Re: [PATCH] git-prompt: make colors available in custom prompts
Simon Oosthoek <s.oosth...@xs4all.nl> writes: > Hi Andrew > > sorry, I only noticed your request this morning... > > On 22/04/16 07:00, Andrew Schwartzmeyer wrote: >> diff --git a/contrib/completion/git-prompt.sh >> b/contrib/completion/git-prompt.sh >> index f18aedc73..ffe79168c 100644 >> --- a/contrib/completion/git-prompt.sh >> +++ b/contrib/completion/git-prompt.sh >> @@ -12,8 +12,8 @@ >> #source ~/.git-prompt.sh >> #3a) Change your PS1 to call __git_ps1 as >> #command-substitution: >> -#Bash: PS1='[\u@\h \W$(__git_ps1 " (%s)")]\$ ' >> -#ZSH: setopt PROMPT_SUBST ; PS1='[%n@%m %c$(__git_ps1 " (%s)")]\$ ' >> +#Bash: PS1="[\u@\h \W$(__git_ps1 ' (%s)')]\$ " >> +#ZSH: setopt PROMPT_SUBST ; PS1="[%n@%m %c$(__git_ps1 ' (%s)')]\$ " > > I haven't tested this at all, but when using double quotes, you need to at > least check all the escapings, like \$ should probably be: \\\$ when used > in double quotes. By using double quotes the command subsititution is expanded when PS1 is set, which makes it pretty useless. > The original reason for not using colors in command substitution mode was > that the prompt string length was not calculated correctly by bash and it > messed up the commandline with very long commands (relative to the > terminal width), when browsing the command history. If you want to include control characters in the prompt that don't contribute to the length you have to enclose them in \[ \]. The problem is that \[ \] are processed before embedded command substitutions are expanded, thus they cannot produce such control characters. Andreas. -- Andreas Schwab, sch...@linux-m68k.org GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 "And now for something completely different." -- 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-info.html
Re: history damage in linux.git
Olaf Hering <o...@aepfle.de> writes: > How can I find out whats going on? Is my git(1) 2.8.1 broken, or did > Linus just pull some junk tree (and does he continue to do so)? The branches recently pulled by Linus contain commits with rather old author dates, eg 8cad489261c564d4ee1db4de4ac365af56807d8a or 281baf7a702693deaa45c98ef0c5161006b48257. That will probably cause git describe --contains to take a different path through the history. Andreas. -- Andreas Schwab, sch...@linux-m68k.org GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 "And now for something completely different." -- 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-info.html
Re: git rebase -i without altering the committer date
Shaun Jackman <sjack...@gmail.com> writes: > I'd like to insert a commit between two commits without changing the > committer date or author date of that commit or the subsequent commits. I'd > planned on using `git rebase -i` to insert the commit. I believe it retains > the author date, but changes the committer date to the current time. I've > seen the options `--committer-date-is-author-date` and `--ignore-date`, but I > don't believe either of those options does what I want. If no such option > currently exists to leave the committer and author date unchanged, is there > any chance that this functionality could please be implemented? The easiest way to implement that is to add a graft to redirect the parent of the second commit to the inserted commit, then use git filter-branch to make the graft permanent. Andreas. -- Andreas Schwab, sch...@linux-m68k.org GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 "And now for something completely different." -- 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-info.html
Re: [BUG] git rev-parse :/ "regex" syntax not really regex?
Andreas Mohr <a...@lisas.de> writes: > Unless I happened to misunderstand git's regex flavour, or something else... > (hmm, perhaps it's a try-match-single-line vs. multi-line content issue, > which perhaps does not work by specifying the trailing $) This is exactly the difference. git log --grep matches individual lines (like grep), whereas :/ matches against the whole commit message including embedded (and trailing) newlines, and $ doesn't match an embedded newline. Thus to address the second commit in your example you have to use $':/^My commit\n' (using bash's ANSI-C quoting feature). Andreas. -- Andreas Schwab, sch...@linux-m68k.org GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 "And now for something completely different." -- 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-info.html
Re: Timestamp of zero in reflog considered invalid
Junio C Hamano <gits...@pobox.com> writes: > Checking the value against ULONG_MAX and errno==ERANGE would be an > improvement. It may be debatable if we should silently ignore an > entry with an invalid timestamp, but that is a separate issue. > > refs.c | 3 ++- > 1 file changed, 2 insertions(+), 1 deletion(-) > > diff --git a/refs.c b/refs.c > index 4e15f60..ff24184 100644 > --- a/refs.c > +++ b/refs.c > @@ -3701,7 +3701,8 @@ static int show_one_reflog_ent(struct strbuf *sb, > each_reflog_ent_fn fn, void *c > get_sha1_hex(sb->buf + 41, nsha1) || sb->buf[81] != ' ' || > !(email_end = strchr(sb->buf + 82, '>')) || > email_end[1] != ' ' || > - !(timestamp = strtoul(email_end + 2, , 10)) || > + ((timestamp = strtoul(email_end + 2, , 10)) == ULONG_MAX && > + errno == ERANGE) || You need to set errno = 0 before calling strtoul, to distinguish the valid return of ULONG_MAX (which would keep errno intact) and a real overflow. Andreas. -- Andreas Schwab, sch...@linux-m68k.org GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 "And now for something completely different." -- 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-info.html
Re: git show -m with a parent number
Anatoly Borodin <anatoly.boro...@gmail.com> writes:
> It's not like `git diff X^2 X` is a big problem, but too much of a
> copypaste.
Brace expansion helps a bit: git diff X{^2,}
Andreas.
--
Andreas Schwab, sch...@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5
"And now for something completely different."
--
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-info.html
Re: Git clone sends first an empty authorization header
Guilherme <guibuf...@gmail.com> writes: > When doing basic authentication using git clone by passing the > username and password in the url git clone will first send a GET > request without the authorization header set. > > Am i seeing this right? Yes, that is the correct way to implement HTTP authentication. The client won't know which authentication method to use until the server tells it. Andreas. -- Andreas Schwab, sch...@linux-m68k.org GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 "And now for something completely different." -- 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-info.html
Re: [PATCH v4 05/12] ref-filter: introduce parsing functions for each valid atom
Karthik Nayak <karthik@gmail.com> writes: > + if ((( arg && len == arg - sp) || > +(!arg && len == ep - sp )) && len == (arg ? arg : ep) - sp && Andreas. -- Andreas Schwab, sch...@linux-m68k.org GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 "And now for something completely different." -- 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-info.html
Re: fast-import fails in read-only tree
Jeff King <p...@peff.net> writes:
> If you're really going to do a lot of interactive back-and-forth access
> of objects, though, I think you want to set up pipes to cat-file. It's a
> little tedious to allocate fifos, but something like:
With bash's coproc it's a bit less tedious:
> mkfifo in out
> (exec git cat-file --batch out) &
> exec 8>in
> exec 9 echo $sha >&8
> read mode type size <&9
coproc CAT_FILE git cat-file --batch
echo $sha >&${CAT_FILE[1]}
read mode type size <&${CAT_FILE[0]}
Andreas.
--
Andreas Schwab, sch...@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5
"And now for something completely different."
--
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-info.html
Re: git bisect with temporary commits
Florian Bruhin <m...@the-compiler.org> writes: > I see - but wouldn't it make more sense for a "git bisect good" (or > bad, respectively) without arguments to assume I mean the commit > bisect checked out for me, not HEAD? The problem is that there is nothing that marks the originally checked out commit except by being pointed to by HEAD. Also, testing a different commit as the one suggested by git can be useful when skipping over commits that are known to fail for unrelated reasons (see "Avoiding testing a commit" in git-bisect(1)). Andreas. -- Andreas Schwab, sch...@linux-m68k.org GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 "And now for something completely different." -- 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-info.html
Re: git bisect with temporary commits
Florian Bruhin <m...@the-compiler.org> writes: > Now when trying to say it's good (and forgetting to remove the > temporary commits), I get this: > > $ git bisect good > Bisecting: a merge base must be tested > [981e1093dae24b37189bcba2dd848b0c3388080c] still good and does not compile > > Is this intended behaviour? Shouldn't git either do a reset to the > commit we're currently bisecting, or warn the user as it was probably > unintended to add new commits? You should instead tell git that HEAD^ is good, since that is what git asked you to test. Andreas. -- Andreas Schwab, sch...@linux-m68k.org GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 "And now for something completely different." -- 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-info.html
Re: Show total commit count of two authors or more authors into first author
Jagan Teki <jagannadh.t...@gmail.com> writes: > Out of which below three names are with same author which changed > while submitted patches. > 149 Jagan Teki > 122 Jagannadha Teki > 116 Jagannadha Sutradharudu Teki > > I need a command to show to add all commits and show first one as >387 Jagan Teki > > Can anyone help to do this? See the "MAPPING AUTHORS" section of git-shortlog(1). The .mailmap feature is used to coalesce together commits by the same person in the shortlog, where their name and/or email address was spelled differently. If the file .mailmap exists at the toplevel of the repository, or at the location pointed to by the mailmap.file or mailmap.blob configuration options, it is used to map author and committer names and email addresses to canonical real names and email addresses. Andreas. -- Andreas Schwab, sch...@linux-m68k.org GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 "And now for something completely different." -- 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-info.html
Re: Three dot notion used inconsitent?
Lars Schneider <larsxschnei...@gmail.com> writes: > git diff branchA...branchB > --> gives me the diff between (the common ancestor of A and B) and B. That > means I never see changes on branchA. > > git log branchA...branchB > --> gives me the commits reachable from A and B. That includes changes from > branchA. > > Is this because of a design decision that I do not (yet) understand or is > this inconsistent for historical reasons? git diff operates on two revisions. That is inherently incompatible with the usual meaning of A...B and A..B, which are set operations on the revision history. That git diff accepts this syntax is only for convenience. Andreas. -- Andreas Schwab, sch...@linux-m68k.org GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 "And now for something completely different." -- 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-info.html
Re: [PATCH] http: fix some printf format warnings on 32-bit builds
Torsten Bögershausen <tbo...@web.de> writes: > So whenever a long long is printed, I can warmly recommend to use > > PRId64 PRId64 is not suitable for long long, only for int64_t. Andreas. -- Andreas Schwab, sch...@linux-m68k.org GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 "And now for something completely different." -- 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-info.html
Re: git log --author=me
Harry Jeffery <ha...@exec64.co.uk> writes: > The purpose being to make finding your own commits quicker and easier: > git log --author=me Since --author does a regexp search, this would most likely break someone's searches. Better add a new option for that functionality. Andreas. -- Andreas Schwab, sch...@linux-m68k.org GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 "And now for something completely different." -- 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-info.html
Re: [PATCH v3] http.c: use CURLOPT_RANGE for range requests
Jeff King <p...@peff.net> writes: > 4. Fix all of the callers. I suspect this would involve calling > fstat(fileno(fh)) to get a real off_t. You can also use ftello which returns off_t. Andreas. -- Andreas Schwab, sch...@linux-m68k.org GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 "And now for something completely different." -- 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-info.html
Re: [Savannah-users] Anonymous commit (empty Author and Committer)
Kaz Kylheku <k...@kylheku.com> writes: > Nope. They will have a git in which that commit looks like their own > local work. *Someone* will inadvertently do a "git push" to blast out > their changes based on that deleted commit, thereby causing it to > reappear. Not if another one pushes something different in the mean time. Andreas. -- Andreas Schwab, sch...@linux-m68k.org GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 "And now for something completely different." -- 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-info.html
Re: Exclude a file from a pull request
Rudy YAYON <rudy.yayon@boursorama.fr> writes: > My concern is that one important file (Puppetfile) needs to be pushed to my > remote repository so I can check the changes I commited. > To do that, I need to commit changes (included to the Puppetfile) then I > need to push it to the remote repository. > > Once I want to merge these changes from a specific branch to the master > branch, I do NOT want to include this file. In other words, I want to merge > all files except the Puppetfile file. > > What is the best way for you to do that? Create a branch that does not include the file. Andreas. -- Andreas Schwab, sch...@linux-m68k.org GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 "And now for something completely different." -- 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-info.html
git rev-list --all --reflog does not include worktree references
When running git rev-list --all --reflog in the main worktree it doesn't
include commits only referenced by the worktrees, neither HEAD nor its
reflog.
$ git init test
$ cd test
# add some commits
$ touch 1; git add 1; git commit -m 1
$ touch 2; git add 2; git commit -m 2
# add new worktree
$ git worktree add ../test2 master^{}
$ cd ../test2
# add more commits
$ touch 3; git add 3; git commit -m 3
$ touch 4; git add 4; git commit -m 4
# create an unreferenced commit
$ git checkout @^
# both commands should give the same number of commits
$ git rev-list --reflog | wc -l
4
$ git -C ../test rev-list --all --reflog | wc -l
2
IIUC this will cause git gc to prune references from worktrees too
early.
Andreas.
--
Andreas Schwab, sch...@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5
"And now for something completely different."
--
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-info.html
Re: Single brackets matching in .gitignore rules
Andrey Loskutov <losku...@gmx.de> writes: > Next, the surprising table for ']': > -- > rule | file | match? > -- > ] ] true > ]* ] true > *] ] true > *] a]true > -- > > Here Git does not give up on parsing, treats unmatched ']' character > literally, and doesn't dislike that it is an "unmatched" end of a broken > character group. > Why? ] by itself is not special in a glob. Andreas. -- Andreas Schwab, sch...@linux-m68k.org GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 "And now for something completely different." -- 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-info.html
[PATCH] Documentation/config: fix formatting for branch.*.rebase and pull.rebase
Don't format the second paragraph as a literal block.
Signed-off-by: Andreas Schwab <sch...@linux-m68k.org>
---
Documentation/config.txt | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/Documentation/config.txt b/Documentation/config.txt
index 0c351b9..e0bd703 100644
--- a/Documentation/config.txt
+++ b/Documentation/config.txt
@@ -865,7 +865,7 @@ branch..rebase::
instead of merging the default branch from the default remote when
"git pull" is run. See "pull.rebase" for doing this in a non
branch-specific manner.
-+
+ +
When preserve, also pass `--preserve-merges` along to 'git rebase'
so that locally committed merge commits will not be flattened
by running 'git pull'.
@@ -2137,7 +2137,7 @@ pull.rebase::
of merging the default branch from the default remote when "git
pull" is run. See "branch..rebase" for setting this on a
per-branch basis.
-+
+ +
When preserve, also pass `--preserve-merges` along to 'git rebase'
so that locally committed merge commits will not be flattened
by running 'git pull'.
--
2.5.2
--
Andreas Schwab, sch...@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5
"And now for something completely different."
--
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-info.html
Re: [ANNOUNCE] Git v2.6.0-rc1
Junio C Hamano <gits...@pobox.com> writes: > * After "git am" without "-3" stops, running "git am -" pays attention Is this a typo for ---> "git am -3"? Andreas. -- Andreas Schwab, sch...@linux-m68k.org GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 "And now for something completely different." -- 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-info.html
Re: glibc mutex deadlock in signal handler
See <http://pubs.opengroup.org/onlinepubs/9699919799/functions/V2_chap02.html#tag_15_04_03> for the complete list of functions you may safely call from a signal handler. Andreas. -- Andreas Schwab, sch...@linux-m68k.org GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 "And now for something completely different." -- 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-info.html
Re: Git's inconsistent command line options
Jacob Keller jacob.kel...@gmail.com writes: if you really mean to create a tag named create, use git tag -- create master In all other uses of -- refs must be put on the *left* side. Andreas. -- Andreas Schwab, sch...@linux-m68k.org GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 And now for something completely different. -- 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-info.html
[PATCH] Documentation/config: fix inconsistent label
Change ref to pattern in the description of gc.*.reflogExpireUnreachable, since that is what the text refers to. Signed-off-by: Andreas Schwab sch...@linux-m68k.org --- Documentation/config.txt | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/Documentation/config.txt b/Documentation/config.txt index 75ec02e..b4f7c46 100644 --- a/Documentation/config.txt +++ b/Documentation/config.txt @@ -1329,7 +1329,7 @@ gc.pattern.reflogExpire:: the refs that match the pattern. gc.reflogExpireUnreachable:: -gc.ref.reflogExpireUnreachable:: +gc.pattern.reflogExpireUnreachable:: 'git reflog expire' removes reflog entries older than this time and are not reachable from the current tip; defaults to 30 days. The value now expires all entries -- 2.5.0 -- Andreas Schwab, sch...@linux-m68k.org GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 And now for something completely different. -- 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-info.html
Re: [PATCH v11 05/13] ref-filter: implement an `align` atom
Karthik Nayak karthik@gmail.com writes: I think we need to squash this in diff --git a/Documentation/git-for-each-ref.txt b/Documentation/git-for-each-ref.txt index 3099631..17bd15e 100644 --- a/Documentation/git-for-each-ref.txt +++ b/Documentation/git-for-each-ref.txt @@ -129,7 +129,7 @@ color:: align:: left-, middle-, or right-align the content between %(align:..) - and %(end). Followed by `:position,width`, where the + and %(end). Followed by `:width,position`, where the s/// Andreas. -- Andreas Schwab, sch...@linux-m68k.org GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 And now for something completely different. -- 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-info.html
