Re: Tabs in commit messages - de-tabify option in strbuf_stripspace()?

On Wed, Mar 16, 2016 at 7:27 AM, Marc Branchaud wrote: > > Could this also help with diff output, where the leading + or - mars the > indentation in a similar way? I don't think that's a good idea at least by default, since then it will break things like running diff in

Re: [PATCH 4/4] pretty-print: add --pretty=noexpand

On Thu, Mar 17, 2016 at 10:08 PM, Jeff King wrote: > > Hmm. Isn't "expand tabs" orthogonal to the rest of the pretty format? > That is, couldn't one want "--pretty=fuller, but with tabs expanded"? Yeah, you are right, one easily could. And in fact I end up doing "fuller" myself

Re: [PATCH] pretty-print: de-tabify indented logs to make things line up properly

On Wed, Mar 16, 2016 at 11:01 AM, Junio C Hamano wrote: > > (1) if turning your "preparation; do { ... } while()" into > "while () { }" would make the result a bit easier to read; So it's probably partly taste, but I will also disagree with your "easier to read", because

Re: [GIT PULL] GPIO bulk changes for kernel v4.6

On Thu, Mar 17, 2016 at 11:07 PM, Laxman Dewangan wrote: > > For creating the repo and branch, I just followed the instruction from wiki > https://help.github.com/articles/create-a-repo/ So you shouldn't have created a new repo at all, you should just have cloned an

Re: [PATCH] merge: refuse to create too cool a merge by default

lly wrote a new test for this. Feel free to ignore my patches, they have nothing really different from yours, just slightly different implementation. Linus From 0f3e4a9294eeda6799e3e50e28809133233126db Mon Sep 17 00:00:00 2001 From: Linus Torvalds <torva...@linux-foundatio

Re: [PATCH 4/4] pretty-print: add --pretty=noexpand

On Thu, Mar 17, 2016 at 4:16 PM, Junio C Hamano wrote: > It is reasonable for tweak the default output mode for "git log" to > untabify the commit log message, it sometimes may be necessary to > see the output without tab expansion. Thanks, these all look good to me. Sorry

Re: [PATCH] pretty-print: de-tabify indented logs to make things line up properly

On Wed, Mar 16, 2016 at 12:47 PM, Junio C Hamano wrote: > > Strangely running t4201 with your patch (without any squashing) > seems to show a breakage in shortlog. I won't be able to come back > to this topic for at least a few hours, so this is just a single bit > "breaks"

Re: [PATCH] pretty-print: de-tabify indented logs to make things line up properly

On Wed, Mar 16, 2016 at 2:37 PM, Junio C Hamano wrote: > > What surprised me was that this new expand logic triggered for > shortlog, actually. I somehow assumed the caller that called > de-tabify helper was only called for --pretty=medium. I guess that would be ok, since

Re: [GIT PULL] GPIO bulk changes for kernel v4.6

On Fri, Mar 18, 2016 at 7:32 AM, Johannes Schindelin <johannes.schinde...@gmx.de> wrote: > > On Fri, 18 Mar 2016, Linus Torvalds wrote: > >> I thought git didn't merge two branches that have no common base by >> default, but it seems it will happily do so. > > Wh

Re: [GIT PULL] GPIO bulk changes for kernel v4.6

On Fri, Mar 18, 2016 at 9:37 AM, Junio C Hamano wrote: > >> I don't think the original "resolve" did it, for example. You can't do >> a three-way merge without a base. > > Yes, and that continues to this day: Yeah, "octopus" also refuses it cleanly: common=$(git

[PATCH] pretty-print: de-tabify indented logs to make things line up properly

From: Linus Torvalds <torva...@linux-foundation.org> Date: Wed, 16 Mar 2016 09:15:53 -0700 Subject: [PATCH] pretty-print: de-tabify indented logs to make things line up properly This should all line up: Column 1 Column 2 A B ABCD

Re: Tabs in commit messages - de-tabify option in strbuf_stripspace()?

On Tue, Mar 15, 2016 at 9:46 PM, Junio C Hamano wrote: > > It also ignores that byte counts of non-HT bytes may not necessarily > match display columns. There is utf8_width() function exported from > utf8.c for that purpose. Hmm. I did that to now make it horribly slower.

Re: Tabs in commit messages - de-tabify option in strbuf_stripspace()?

On Tue, Mar 15, 2016 at 5:48 PM, Linus Torvalds <torva...@linux-foundation.org> wrote: > On Tue, Mar 15, 2016 at 5:45 PM, Junio C Hamano <gits...@pobox.com> wrote: >> >> Wouldn't it be nicer to do this kind of thing at the output side? A >> stupid way would be to

Re: Tabs in commit messages - de-tabify option in strbuf_stripspace()?

On Tue, Mar 15, 2016 at 5:45 PM, Junio C Hamano wrote: > > Wouldn't it be nicer to do this kind of thing at the output side? A > stupid way would be to have an option to indent the log text with a > tab instead of 4-spaces, but a more sensible way would be to keep > the visual

Re: Tabs in commit messages - de-tabify option in strbuf_stripspace()?

On Tue, Mar 15, 2016 at 5:23 PM, Stefan Beller wrote: > > Could you point at some example to better understand the problem? So in the kernel repo, I just randomly looked for tabs that show this problem, and take for example commit ff9a9b4c4334b53b52ee9279f30bd5dd92ea9bdd.

Tabs in commit messages - de-tabify option in strbuf_stripspace()?

So I end up doing this manually when I notice, but I was wondering ig maybe git could just have an option to "git am" and friends to de-tabify the commit message. It's particularly noticeable when people line things up using tabs (for the kernel, it's often things like "cpu1 does X, cpu2 does

Re: Clarification on the git+ssh and ssh+git schemes

On Fri, Feb 5, 2016 at 11:30 AM, Jeff King wrote: > > I suspect they were not really documented because nobody wanted to > encourage their use. I don't think it would be wrong to document that > they exist and are deprecated, though. They exist because some people seemed to think

Re: [PATCH v4] Add git-grep threads param

On Mon, Nov 9, 2015 at 10:32 AM, Victor Leschuk wrote: > On Mon, Nov 9, 2015 at 9:28 AM, Victor Leschuk >> num_threads = online_cpus() <= 1 ? 0 : GREP_NUM_THREADS_DEFAULT; > > Actually I have never said the nCPUs played main role in it. T The pseudo-code you sent

Re: [PATCH v4] Add git-grep threads param

On Mon, Nov 9, 2015 at 9:28 AM, Victor Leschuk wrote: > > Maybe use the simplest version (and keep num_numbers == 0 also as flag for > all other checks in code like if(num_flags) ): > > if (list.nr || cached ) > num_threads = 0; // do not use threads > else if

Re: [PATCH] am: match --signoff to the original scripted version

On Sat, Sep 5, 2015 at 9:56 PM, Junio C Hamano wrote: > > For > the upcoming release, stop using the append_signoff() in "git am" > and reimplement the looser definition used by the scripted version > to use only in "git am" to fix this regression in "am"

More builtin git-am issues..

ll) end up looking like this: Cc: <sta...@vger.kernel.org> [3.15+] Signed-off-by: Andrew Morton <a...@linux-foundation.org> Signed-off-by: Linus Torvalds <torva...@linux-foundation.org> note the extraneous whitespace line between Andrew's sign-off and mine. What'

Re: More builtin git-am issues..

On Fri, Sep 4, 2015 at 4:47 PM, Linus Torvalds <torva...@linux-foundation.org> wrote: > > I *think* it's this part: > > if (!(found_rfc2822 || > is_cherry_picked_from_line(buf + i, k - i - 1))) > return 0; >

Re: More builtin git-am issues..

On Fri, Sep 4, 2015 at 6:06 PM, Junio C Hamano wrote: > > that rule would still not think this is a signature block, but at > that point, do we really want to consider such a block of text a > signature block? So exactly why are you arguing for these rules that are known to

Re: More builtin git-am issues..

want to see in a case like this: > > Signed-off-by: Noam Camus <no...@ezchip.com> > Acked-by: Vineet Gupta <vgu...@synopsys.com> > [ Also removed pointless cast from "void *". - Linus] > Signed-off-by: Linus Torvalds <torva...@linux-founda

Re: More builtin git-am issues..

On Fri, Sep 4, 2015 at 5:07 PM, Jeff King wrote: > > Do we want to make Signed-off-by a special token here? What about "Cc:", > and other project-specific trailers? You wouldn't want to end up with: > > [some comment] > Cc: somebody > > Signed-off-by: somebody else > > It's

Re: More builtin git-am issues..

We have commetns from the sign-off people. Things like this: Signed-off-by: Noam Camus <no...@ezchip.com> Acked-by: Vineet Gupta <vgu...@synopsys.com> [ Also removed pointless cast from "void *". - Linus ] Signed-off-by: Linus Torvalds <torva...@lin

Re: [PATCH] am --abort: merge ORIG_HEAD tree into index

On Mon, Aug 17, 2015 at 2:48 AM, Paul Tan pyoka...@gmail.com wrote: It's true that we need to merge the ORIG_HEAD tree into the index instead of overwriting it. Patch below. Seems to work for me. Thanks, Linus -- To unsubscribe from this list: send the line unsubscribe

Re: git am --abort screwing up index?

On Sun, Aug 16, 2015 at 12:46 PM, Linus Torvalds torva...@linux-foundation.org wrote: Maybe it has always done this, and I just haven't noticed (I usually _just_ do the git reset --hard thing, don't ask me why I wanted to be doubly sure this time). But maybe it's an effect of the new built

git am --abort screwing up index?

So I just noticed while applying a patch with git am when I had a dirty tree, and I ended up getting a failure and starting over: [torvalds@i7 linux]$ git am --abort [torvalds@i7 linux]$ git reset --hard Checking out files: 100% (50794/50794), done.0794) HEAD is now at 1efdb5f0a924

Re: [PATCH] git_open_noatime: return with errno=0 on success

On Tue, Aug 4, 2015 at 11:03 PM, Junio C Hamano gits...@pobox.com wrote: I would agree it is a good idea to clear it after seeing the first open fail due to lack of O_NOATIME before trying open for the second time, iow, more like this? So I don't think this is _wrong_ per se, but I think the

Re: git log fails to show all changes for a file

On Wed, Jul 15, 2015 at 11:17 AM, Junio C Hamano gits...@pobox.com wrote: So this is a suggested change to -p -m behavior? Not really. This is a suggested behaviour for git log -p Oh, in that case I say NAK NAK NAK. That would be totally horrible, and completely unacceptable. I do git log

Re: git log fails to show all changes for a file

On Wed, Jul 15, 2015 at 9:29 AM, Junio C Hamano gits...@pobox.com wrote: I would think git log -p that implies --cc would be a good change, as long as there is an easy escape hatch to let us do what we have to do with a rather lengthy git log -p --first-parent -m (i.e. show the change

Re: git log fails to show all changes for a file

On Wed, Jul 15, 2015 at 10:58 AM, Junio C Hamano gits...@pobox.com wrote: * When '-p' is given, we show only diff with first-parent by default, regardless of the traversal (i.e. --first-parent option currently controls both traversal and patch display, but in the new world order, it

Re: git log fails to show all changes for a file

On Tue, Jul 14, 2015 at 12:59 AM, Olaf Hering o...@aepfle.de wrote: On Tue, Jul 14, John Keeping wrote: It was added in an evil merge (f9da455b93f6ba076935b4ef4589f61e529ae046), That's not an evil merge. That's just a regular merge. One side had changed the argument to const: - 1b9d48f2a579

Re: Why does git log -Gregex works with regexp-ignore-case but not with other regexp-related options?

On Mon, Apr 20, 2015 at 10:41 AM, Junio C Hamano gits...@pobox.com wrote: Ahh, OK. And not just -S and -G, the fields in headers may be something user may want to switch independently? So personally, I hate extra command line flags for this. I'd much rather see is use something in the regular

Re: Odd broken --date=now behavior in current git

On Wed, Apr 15, 2015 at 12:22 AM, Eric Sunshine sunsh...@sunshineco.com wrote: The fix seems to be simply: Yup, that seems to do it for me. I'm not sure how we get to match_digit() with the time string now, though. So your patch fixes things for me, but I think: - we should move the

Odd broken --date=now behavior in current git

commit is broken: [torvalds@i7 git]$ git show --pretty=fuller commit ec7733db5360966434e03eab1a849e6d4227231c (HEAD - master) Author: Linus Torvalds torva...@linux-foundation.org AuthorDate: Tue Apr 14 20:11:03 2015 -0800 Commit: Linus Torvalds torva...@linux

Re: Git very slow ?

On Sun, Mar 8, 2015 at 12:37 PM, David Kastrup d...@gnu.org wrote: Since git blame outputs everything once it is finished (the first screen is purely the pager's business), it needs to unpack the entire history of the file (unless no blameable lines remain at all) and look at it. 6 seconds

Re: Git very slow ?

On Sun, Mar 8, 2015 at 12:02 PM, Ken Moffat zarniwh...@ntlworld.com wrote: The comments on git bisect were for linus'skernel tree, on a local disk. 2.3GB of repo, just under 57000 files. Ugh. I hope you are talking about checked-out size. [torvalds@i7 linux]$ du -sh .git 850M .git

Re: [PATCH 0/3] request-pull: do something if $3 is passed

On Tue, Feb 17, 2015 at 12:34 PM, Paolo Bonzini bonz...@gnu.org wrote: I guess only Linus could answer that, since he wrote 024d34cb0 and he knows the intent better than anyone else. I don't even understand your problem. You said when $3 is not passed git will try to use HEAD as the

Re: [PATCH 0/3] request-pull: do something if $3 is passed

On Tue, Feb 17, 2015 at 12:53 PM, Paolo Bonzini bonz...@gnu.org wrote: Without $3, git tries to do things that make no sense like git show-ref --heads --tags HEAD; or that make little sense when requesting a pull, like looking for HEAD in the output of git ls-remote. But from the release

Re: [PATCH 0/3] request-pull: do something if $3 is passed

On Tue, Feb 17, 2015 at 1:03 PM, Junio C Hamano gits...@pobox.com wrote: HEAD should resolve as a tag is not sensible, but HEAD should locally DWIM to something sensible is still possible, no? I disagree. Why? Because what you have locally is *not* necessarily the same thing you have remotely.

Re: [PATCH 0/3] request-pull: do something if $3 is passed

On Tue, Feb 17, 2015 at 1:10 PM, Paolo Bonzini pbonz...@redhat.com wrote: Sure. But if I got a pull request saying please pull git://example.org/foo.git HEAD I would think that the sender messed up the pull request. So *in the context of git-request-pull* ${remote:-HEAD} makes little sense

Re: [PATCH] hex.c: reduce memory footprint of sha1_to_hex static buffers

On Fri, Feb 13, 2015 at 1:56 PM, Stefan Beller sbel...@google.com wrote: As I could not find any documentation on the magical 50 in the early days, I cc'd Linus in case there is something I did not think of yet. Nothing magical, it's just rounded up from 40 + NUL character.

Re: patch-2.7.3 no longer applies relative symbolic link patches

On Mon, Jan 26, 2015 at 1:35 PM, Junio C Hamano gits...@pobox.com wrote: What is your take on CVE-2015-1196, which brought this /regression/ to GNU patch? If git apply get /fixed/ for that same CVE, would that /break/ your fix? I _think_ we allow arbitrary symlinks to be created, but then we

Re: patch-2.7.3 no longer applies relative symbolic link patches

On Mon, Jan 26, 2015 at 1:07 PM, Josh Boyer jwbo...@fedoraproject.org wrote: Or did I miss a way that git-apply can take a git patch and apply it to a tree that isn't a git repo? Exactly. git apply works as a straight patch replacement outside of a git repository. It doesn't actually need a

Re: patch-2.7.3 no longer applies relative symbolic link patches

On Mon, Jan 26, 2015 at 8:32 AM, Josh Boyer jwbo...@fedoraproject.org wrote: I went to do the Fedora 3.19-rc6 build this morning and it failed in our buildsystem with: + '[' '!' -f /builddir/build/SOURCES/patch-3.19-rc6.xz ']' + case $patch in + unxz + patch -p1 -F1 -s symbolic link

Re: Sources for 3.18-rc1 not uploaded

On Tue, Oct 21, 2014 at 1:08 AM, Michael J Gruber g...@drmicha.warpmail.net wrote: Unfortunately, the git archive doc clearly says that the umask is applied to all archive entries. And that clearly wasn't the case (for extended metadata headers) before Brian's fix. Hey, it's time for another

Re: Sources for 3.18-rc1 not uploaded

:00:00 2001 From: Linus Torvalds torva...@linux-foundation.org Date: Mon, 20 Oct 2014 08:21:38 -0700 Subject: [PATCH] Don't use the default 'tar.umask' for pax headers That wasn't the original behavior, and doing so breaks the fact that tar-files are bit-for-bit compatible across git versions

Re: Sources for 3.18-rc1 not uploaded

On Mon, Oct 20, 2014 at 3:28 PM, brian m. carlson sand...@crustytoothpaste.net wrote: It doesn't appear that the stability of git archive --format=tar is documented anywhere. Given that, it doesn't seem reasonable to expect that any tar implementation produces bit-for-bit compatible output

Re: Tackling Git Limitations with Singular Large Line-seperated Plaintext files

On Fri, Jun 27, 2014 at 10:48 AM, Junio C Hamano gits...@pobox.com wrote: Even though the original question mentioned delta discovery, I think what was being asked is not delta in the Git sense (which your answer is about) but is can we diff two long sequences of text (that happens to consist

Re: Tackling Git Limitations with Singular Large Line-seperated Plaintext files

On Fri, Jun 27, 2014 at 12:38 PM, Linus Torvalds torva...@linux-foundation.org wrote: I think it might be possible to just specify a special diff algorithm (git already supports that, obviously), and just introduce a new use binary diffs with a textual representation model. Another model

Re: Tackling Git Limitations with Singular Large Line-seperated Plaintext files

On Fri, Jun 27, 2014 at 12:55 PM, Jason Pyeron jpye...@pdinc.us wrote: The issue will be, if we talk about changes other than same length substitutions (e.g. Down's Syndrome where it has an insertion of code) would require one code per line for the diffs to work nicely. Not my area of

Re: BUG: git request-pull broken for plain branches

On Wed, Jun 25, 2014 at 2:55 AM, Uwe Kleine-König u.kleine-koe...@pengutronix.de wrote: $ git rev-parse HEAD 9e065e4a5a58308f1a0da4bb80b830929dfa90b3 $ git ls-remote origin | grep 9e065e4a5a58308f1a0da4bb80b830929dfa90b3 9e065e4a5a58308f1a0da4bb80b830929dfa90b3

Re: 2.0.0 regression? request pull does not seem to find head

On Mon, Jun 2, 2014 at 2:01 PM, Michael S. Tsirkin m...@redhat.com wrote: [mst@robin linux]$ git request-pull net-next/master git://git.kernel.org/pub/scm/linux/kernel/git/mst/vhost.git net-next warn: No match for commit 2ae76693b8bcabf370b981cd00c36cd41d33fabc found at

Re: [ANNOUNCE] Git v2.0.0

On Mon, Jun 2, 2014 at 7:08 PM, NeilBrown ne...@suse.de wrote: git request-pull master git://neil.brown.name/md after tagging the current commit as md/3.15-fixes and pushing out the tag You should *tell* git request-pull what you're actually requesting to pull. The old let's guess based on

[RFC PATCH] git log: support auto decorations

From: Linus Torvalds torva...@linux-foundation.org Date: Thu, 29 May 2014 15:19:40 -0700 Subject: [RFC PATCH] git log: support auto decorations This works kind of like --color=auto - add decorations for interactive use, but do not change defaults when scripting or when piping the output

Re: [RFC PATCH] git log: support auto decorations

On Thu, May 29, 2014 at 6:58 PM, Jeff King p...@peff.net wrote: I will spare you the usual lecture on having these lines in the message body. ;) We do it for the kernel because they often get lost otherwise. Particularly the date/author. git doesn't tend to have the same kind of deep email

Odd git diff breakage

I hit this oddity when not remembering the right syntax for --color-words.. Try this (outside of a git repository): touch a b git diff -u --color=words a b and watch it scroll (infinitely) printing out error: option `color' expects always, auto, or never forever. I haven't tried to

Re: Odd git diff breakage

On Mon, Mar 31, 2014 at 11:30 AM, Junio C Hamano gits...@pobox.com wrote: Hmph, interesting. outside a repository is the key, it seems. Well, you can do it inside a repository too, but then you need to use the --no-index flag to get the diff two files behavior. It will result in the same

Re: [PATCH] diff-no-index: correctly diagnose error return from diff_opt_parse()

On Mon, Mar 31, 2014 at 11:47 AM, Junio C Hamano gits...@pobox.com wrote: Instead, make it act like so: $ git diff --no-index --color=words a b error: option `color' expects always, auto, or never fatal: invalid diff option/value: --color=words Thanks,

Re: Re* [RFC PATCH 2/1] Make request-pull able to take a refspec of form local:remote

On Wed, Jan 29, 2014 at 3:34 PM, Junio C Hamano gits...@pobox.com wrote: I am not yet doing the docs, but here is a minimal (and I think is the most sensible) fix to the If I asked a tag to be pulled, I used to get the message from the tag in the output---the updated code no longer does so

Re: [RFC PATCH 2/1] Make request-pull able to take a refspec of form local:remote

On Thu, Jan 23, 2014 at 11:43 AM, Junio C Hamano gits...@pobox.com wrote: I am not sure if it is a good idea to hand-craft resulting head is unique constraint here. We already have disambiguation rules (and warning mechanism) we use in other places---this part should use the same rule, I

Re: [RFC PATCH 2/1] Make request-pull able to take a refspec of form local:remote

On Thu, Jan 23, 2014 at 2:58 PM, Junio C Hamano gits...@pobox.com wrote: Will be fine, provided if they always use local:remote syntax, I'd agree. Why? No sane user should actually need to use the local:remote syntax. The normal situation should be that you create the correctly named branch

[RFC PATCH] Make 'git request-pull' more strict about matching local/remote branches

From: Linus Torvalds torva...@linux-foundation.org Date: Wed, 22 Jan 2014 12:32:30 -0800 Subject: [PATCH] Make 'git request-pull' more strict about matching local/remote branches The current 'request-pull' will try to find matching commit on the given remote, and rewrite the please pull line

Re: [RFC PATCH] Make 'git request-pull' more strict about matching local/remote branches

On Wed, Jan 22, 2014 at 1:46 PM, Junio C Hamano gits...@pobox.com wrote: The new find local ref code will also complain loudly if you give an ambiguous refname (eg you have both a tag and a branch with that same name, and you don't specify heads/name or tags/name). But this part might be a

Re: [RFC PATCH] Make 'git request-pull' more strict about matching local/remote branches

On Wed, Jan 22, 2014 at 2:03 PM, Linus Torvalds torva...@linux-foundation.org wrote: Any ideas? The hacky way is to do | head -1 to take the first show-ref output, and then check if you get a different result if you re-do it using show-ref --tags. But that sounds really excessively hacky

Re: [RFC PATCH] Make 'git request-pull' more strict about matching local/remote branches

On Wed, Jan 22, 2014 at 2:14 PM, Junio C Hamano gits...@pobox.com wrote: I looked at 5150.4 and found that what it attempts to do is halfway sensible. I agree that it is half-way sensible. The important bit being the HALF part. The half part is why we have the semantics we have. There's no

[RFC PATCH 2/1] Make request-pull able to take a refspec of form local:remote

From: Linus Torvalds torva...@linux-foundation.org Date: Wed, 22 Jan 2014 15:23:48 -0800 Subject: [PATCH] Make request-pull able to take a refspec of form local:remote This allows a user to say that a local branch has a different name on the remote server, using the same syntax that git push

Re: [PATCH] git-compat-util: Avoid strcasecmp() being inlined

On Wed, Sep 18, 2013 at 5:43 AM, Sebastian Schuberth sschube...@gmail.com wrote: My feeling is that Linus' reaction was more about that this work-around is even necessary (and MinGW is buggy) rather than applying it to git-compat-util.h and not elsewhere. So I think it's an annoying MinGW

Re: [PATCH] git-compat-util: Avoid strcasecmp() being inlined

On Fri, Sep 13, 2013 at 12:53 PM, Sebastian Schuberth sschube...@gmail.com wrote: +#ifdef __MINGW32__ +#ifdef __NO_INLINE__ Why do you want to push this insane workaround for a clear Mingw bug? Please have mingw just fix the nasty bug, and the git patch with the trivial wrapper looks much

Re: [PATCH/RFC] Developer's Certificate of Origin: default to COPYING

On Thu, Sep 12, 2013 at 3:30 PM, Junio C Hamano gits...@pobox.com wrote: Linus, this is not limited to us, so I am bothering you; sorry about that. My instinct tells me that some competent lawyers at linux-foundation helped you with the wording of DCO, and we amateurs shouldn't be mucking

Re: [PATCH/RFC] Developer's Certificate of Origin: default to COPYING

On Thu, Sep 12, 2013 at 4:15 PM, Richard Hansen rhan...@bbn.com wrote: Is it worthwhile to poke a lawyer about this as a precaution? (If so, who?) Or do we wait for a motivating event? I can poke the lawyer that was originally involved. If people know other lawyers, feel free to poke them

Re: [PATCH v4] compat: Fix read() of 2GB and more on Mac OS X

On Mon, Aug 19, 2013 at 8:41 AM, Steffen Prohaska proha...@zib.de wrote: The reason was that read() immediately returns with EINVAL if nbyte = 2GB. According to POSIX [1], if the value of nbyte passed to read() is greater than SSIZE_MAX, the result is implementation-defined. Yeah, the OS X

Re: [PATCH v4] compat: Fix read() of 2GB and more on Mac OS X

On Mon, Aug 19, 2013 at 10:16 AM, Junio C Hamano gits...@pobox.com wrote: Linus Torvalds torva...@linux-foundation.org writes: The same argument applies to xwrite(), but currently we explicitly catch EINTR and EAGAIN knowing that on sane systems these are the signs that we got interrupted

Re: [PATCH v4] compat: Fix read() of 2GB and more on Mac OS X

On Mon, Aug 19, 2013 at 2:56 PM, Kyle J. McKay mack...@gmail.com wrote: The fact that the entire file is read into memory when applying the filter does not seem like a good thing (see #7-#10 above). Yeah, that's horrible. Its likely bad for performance too, because even if you have enough

Re: New feature discussion: git rebase --status

On Tue, Jun 11, 2013 at 10:18 AM, Hilco Wijbenga hilco.wijbe...@gmail.com wrote: Having git status display (even more) context sensitive information during git rebase or git merge would be very welcome. Please, if at all possible, don't make that a separate command. I agree. The rebase state

Re: [PATCH] build: get rid of the notion of a git library

On Tue, Jun 11, 2013 at 11:06 AM, Felipe Contreras felipe.contre...@gmail.com wrote: Moreover, if you are going to argue that we shouldn't be closing the door [...] Felipe, you saying if you are going to argue ... to anybody else is kind of ironic. Why is it every thread I see you in, you're

Re: first parent, commit graph layout, and pull merge direction

On Thu, May 23, 2013 at 3:11 PM, Junio C Hamano gits...@pobox.com wrote: If the proposal were to make pull.rebase the default at a major version bump and force all integrators and other people who are happy with how pull = fetch + merge (not fetch + rebase) works to say pull.rebase = false in

Re: first parent, commit graph layout, and pull merge direction

On Thu, May 23, 2013 at 5:21 PM, Junio C Hamano gits...@pobox.com wrote: I would assume that no-ff above was meant to be --ff-only from the first part of the message. Yeah, I may need more coffee.. I also would assume that I can rephrase that setting pull.merge (which does not exist) as

Re: [PATCH] patch-ids.c: cache patch IDs in a notes tree

On Sat, May 11, 2013 at 12:54 PM, John Keeping j...@keeping.me.uk wrote: This adds a new configuration variable patchid.cacheRef which controls whether (and where) patch IDs will be cached in a notes tree. Patch ID's aren't stable wrt different diff options, so I think this is potentially a

Re: [PATCH] patch-ids.c: cache patch IDs in a notes tree

On Sat, May 11, 2013 at 2:49 PM, John Keeping j...@keeping.me.uk wrote: Hmm... I hadn't realised that. Looking a bit closer, it looks like init_patch_ids sets up its own diffopts so its not affected by the command line (except for pathspecs which would be easy to check for). Of course that

git grep parallelism question

Since I reboot fairly regularly to test new kernels, I don't *always* have the kernel source tree in my caches, so I still care about some cold-cache performance. And git grep tends to be the most noticeable one. Now, I have a SSD, and even the cold-cache case takes just five seconds or so, but

Re: git grep parallelism question

On Fri, Apr 26, 2013 at 11:47 AM, Junio C Hamano gits...@pobox.com wrote: The real issue may be that we do not have a good estimate of how many paths are involved in the request before starting these threads, though. Yes. Also, I'm not sure if the 15% possible improvement on my SSD case is

Re: git grep parallelism question

On Fri, Apr 26, 2013 at 12:19 PM, Junio C Hamano gits...@pobox.com wrote: OK, you have to recompile at least once for experiment, so perhaps building the test binary with this patch may help. So here's my experiment on my machine with this patch and the kernel tree. First I did the warm-cache

Re: [RFC/PATCH 0/7] Rework git core for native submodules

On Thu, Apr 4, 2013 at 1:04 PM, Ramkumar Ramachandra artag...@gmail.com wrote: Linus Torvalds wrote: Or you could also just edit and carry a dirty .gitmodules around for your personal use-case. I'm sorry, but a dirty worktree is unnecessarily painful to work with. Bzzt. Wrong. A dirty

Re: [RFC/PATCH 0/7] Rework git core for native submodules

On Thu, Apr 4, 2013 at 11:30 AM, Ramkumar Ramachandra artag...@gmail.com wrote: The purpose of this series is to convince you that we've made a lot of fundamental mistakes while designing submodules, and that we should fix them now. [1/7] argues for a new object type, and this is the core of

Re: [RFC/PATCH 0/7] Rework git core for native submodules

On Thu, Apr 4, 2013 at 11:52 AM, Ramkumar Ramachandra artag...@gmail.com wrote: 1. upstream_url: this records the upstream URL. No need to keep a .gitmodules. 2. checkout_rev: this records the ref to check out the submodule to. As opposed to a concrete SHA-1, this allows for more

Re: [RFC/PATCH 0/7] Rework git core for native submodules

On Thu, Apr 4, 2013 at 12:36 PM, Ramkumar Ramachandra artag...@gmail.com wrote: Let's compare the two alternatives: .gitmodules versus link object. If I want my fork of .gitmodules, I create a commit on top. Or you could also just edit and carry a dirty .gitmodules around for your personal

Re: git status takes 30 seconds on Windows 7. Why?

On Wed, Mar 27, 2013 at 12:04 PM, Jeff King p...@peff.net wrote: Yes, I think that's pretty much the case (though most of my Git-on-Windows experience is from cygwin long ago, where the stat performance was truly horrendous). Have you tried setting core.preloadindex, which should run the

Re: git status takes 30 seconds on Windows 7. Why?

On Wed, Mar 27, 2013 at 1:00 PM, Junio C Hamano gits...@pobox.com wrote: Given that we haven't tweaked the parallelism or thread-cost parameters since the inception of the mechanism in Nov 2008, I suspect that we would see praises from some and grievances from other corners of the user base

Re: linux-next: unneeded merge in the security tree

[ Added Junio and git to the recipients, and leaving a lot of stuff quoted due to that... ] On Mon, Mar 11, 2013 at 9:16 PM, Theodore Ts'o ty...@mit.edu wrote: On Tue, Mar 12, 2013 at 03:10:53PM +1100, James Morris wrote: On Tue, 12 Mar 2013, Stephen Rothwell wrote: The top commit in the

Re: linux-next: unneeded merge in the security tree

On Tue, Mar 12, 2013 at 2:20 PM, Theodore Ts'o ty...@mit.edu wrote: What if we added the ability to do something like this: [remote origin] url = git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git fetch = +refs/heads/master:refs/heads/master

Re: linux-next: unneeded merge in the security tree

On Tue, Mar 12, 2013 at 2:47 PM, Junio C Hamano gits...@pobox.com wrote: I agree that --ff-only thing is too strict and sometimes you would want to allow back-merges, but when you do allow such a back-merge, is there a reason you want it to be --no-signatures merge? When a subtree maintainer

Re: [PULL] Module fixes, and a virtio block fix.

On Sun, Jan 20, 2013 at 5:32 PM, Rusty Russell ru...@rustcorp.com.au wrote: Due to the delay on git.kernel.org, git request-pull fails. It *looks* like it succeeds, except the warning, but (as we learned last time I screwed up), it doesn't put the branchname because it can't know. I think

Re: [PULL] Module fixes, and a virtio block fix.

On Sun, Jan 20, 2013 at 6:00 PM, Junio C Hamano gits...@pobox.com wrote: What you mean by corrupt is not clear to me Some versions would just silently change the actual name you were using. So if you said for-linus, it might change it to linus, just because that branch happened to have the

Re: [PULL] Module fixes, and a virtio block fix.

On Sun, Jan 20, 2013 at 6:57 PM, Rusty Russell ru...@rustcorp.com.au wrote: I'm confused. The default argument is HEAD: what does it know about tag names? Ugh. I actually thought that if you give it the tag name directly (as the end) it will use that. But no. It figures it out with git

Re: [PATCH 2/2] fix clang -Wtautological-compare with unsigned enum

On Fri, Jan 18, 2013 at 9:15 AM, Phil Hord phil.h...@gmail.com wrote: Yes, I can tell by the wording of the error message that you are right and clang has a problem. But the git code it complained about does have a real problem, because the result of signed int a = ULONG_MAX is

Re: [PATCH 2/2] fix clang -Wtautological-compare with unsigned enum

On Thu, Jan 17, 2013 at 3:00 AM, John Keeping j...@keeping.me.uk wrote: There's also a warning that triggers with clang 3.2 but not clang trunk, which I think is a legitimate warning - perhaps someone who understands integer type promotion better than me can explain why the code is OK

Re: [PATCH nd/wildmatch] Correct Git's version of isprint and isspace

On Tue, Nov 13, 2012 at 11:15 AM, René Scharfe rene.scha...@lsrfire.ath.cx wrote: Linus, do you remember if you left them out on purpose? Umm, no. I have to wonder why you care? As far as I'm concerned, the only valid space is space, TAB and CR/LF. Anything else is *noise*, not space. What's

<    1   2   3   4   5   6   >