On Thu, Apr 21, 2016 at 10:23 AM, Junio C Hamano wrote:
>
> I think avoiding side branches to describe with the weight is a
> right thing to do, i.e. if you have this history:
>
> X---o---o---o---o---v4.6
> \ /
> o---o
>
> you do not want to explain X as "v4.6~^2
On Thu, Apr 21, 2016 at 10:08 AM, Jeff King wrote:
>
> Right, because it makes the names longer. We give the second-parent
> traversal a heuristic cost. If we drop that cost to "1", like:
So I dropped it to 500 (removed the two last digits), and it gave a
reasonable answer. With 1000, it gave the
On Thu, Apr 21, 2016 at 9:36 AM, Linus Torvalds
wrote:
>
> This seems to be a git bug.
>
> That commit aed06b9 can also be described as
>
> v3.13-rc7~9^2~14^2~42
>
> so describing it as 'v4.6-rc1~9^2~792' is clearly not closer in any way.
Hmm. I think
On Thu, Apr 21, 2016 at 6:24 AM, Andreas Schwab wrote:
>
> 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
On Wed, Apr 6, 2016 at 11:36 AM, Junio C Hamano wrote:
>
> I was reviewing the topics to merge to 'master', and a thought
> crossed my mind. Both of our series only refuse to create a merge
> that does not have any common ancestor, but shouldn't the right
> solution refuse to add a new root?
So
On Wed, Mar 23, 2016 at 4:23 PM, Junio C Hamano wrote:
> So here is the third try (previous round is found at $gmane/289166
> and the very first one is at $gmane/288987).
>
> The first three patches are essentially the same as v2. The last
> two updates how the tab-expansion is internally control
On Wed, Mar 16, 2016 at 9:29 AM, Linus Torvalds
wrote:
>
> This should all line up:
>
> Column 1 Column 2
>
> A B
> ABCD EFGH
> SPACESInstead of Tabs
>
> Even with multi-byte UTF8 characters
On Wed, Mar 16, 2016 at 12:32 PM, Junio C Hamano wrote:
>
> may give us a better structure if we are going to give users a knob
> to disable this tab expansion, i.e. move the addition of 4 spaces to
> the caller, name the body of such a function strbuf_expand_add(),
> and then make the caller do s
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 emacs capture mode.
So ev
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 occasionally, beca
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 of the way the code
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 existing one (that gets you a
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
Date: Fri, 18 Mar 2016 12:46:06 -0700
Subje
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 for not following up,
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" report, without "how a
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 shortlog by definition
On Fri, Mar 18, 2016 at 7:32 AM, Johannes Schindelin
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.
>
> What happened to "The c
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 merge-base --all $SHA1 $M
From: Linus Torvalds
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 EFGH
SPACESInstead of Tabs
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. Doing the
per-character
On Tue, Mar 15, 2016 at 5:48 PM, Linus Torvalds
wrote:
> 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
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 4-space-indent and
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.
You can see how the ori
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 Y"),
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 that people shou
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 disagrees. Not that "online_cpu
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 (num_threads == 0)
> num_th
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" while
> avoiding new
in a case like this:
>
> Signed-off-by: Noam Camus
> Acked-by: Vineet Gupta
> [ Also removed pointless cast from "void *". - Linus]
> Signed-off-by: Linus Torvalds
> [ Ahh, we have to tell at least these people
>
> - stakeholder class
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 break
in real life, th
mmetns from the sign-off people.
Things like this:
Signed-off-by: Noam Camus
Acked-by: Vineet Gupta
[ Also removed pointless cast from "void *". - Linus ]
Signed-off-by: Linus Torvalds
or
Signed-off-by: Andi Kleen
[ Updated comments and changelog a bit. ]
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 not a problem for
On Fri, Sep 4, 2015 at 4:47 PM, Linus Torvalds
wrote:
>
> I *think* it's this part:
>
> if (!(found_rfc2822 ||
> is_cherry_picked_from_line(buf + i, k - i - 1)))
> return 0;
>
> which basically returns 0
not all) end up looking like this:
Cc: [3.15+]
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds
note the extraneous whitespace line between Andrew's sign-off and mine.
What's odd is that the emails I'm applying literally don't have that
extra empty lin
On Mon, Aug 17, 2015 at 2:48 AM, Paul Tan 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 git" in
the body
On Sun, Aug 16, 2015 at 12:46 PM, Linus Torvalds
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
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 M
On Tue, Aug 4, 2015 at 11:03 PM, Junio C Hamano 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 deeper issue
i
On Wed, Jul 15, 2015 at 11:17 AM, Junio C Hamano 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 -p" all
On Wed, Jul 15, 2015 at 10:58 AM, Junio C Hamano 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 reverts back
On Wed, Jul 15, 2015 at 9:29 AM, Junio C Hamano 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 relative to it
On Tue, Jul 14, 2015 at 12:59 AM, Olaf Hering 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 ("hyper-v
On Mon, Apr 20, 2015 at 10:41 AM, Junio C Hamano 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 expression i
On Wed, Apr 15, 2015 at 12:22 AM, Eric Sunshine 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 "tm.tm_isdst = -1;" up a b
lting commit is broken:
[torvalds@i7 git]$ git show --pretty=fuller
commit ec7733db5360966434e03eab1a849e6d4227231c (HEAD -> master)
Author: Linus Torvalds
AuthorDate: Tue Apr 14 20:11:03 2015 -0800
Commit: Linus Torvalds
CommitDate: Tue Apr 14 21:11:03 20
On Sun, Mar 8, 2015 at 12:37 PM, David Kastrup 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 tends n
On Sun, Mar 8, 2015 at 12:02 PM, Ken Moffat 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
because otherwise it so
On Tue, Feb 17, 2015 at 1:10 PM, Paolo Bonzini 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 to me.
Umm.
On Tue, Feb 17, 2015 at 1:03 PM, Junio C Hamano 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.
And that'
On Tue, Feb 17, 2015 at 12:53 PM, Paolo Bonzini 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 notes of 2
On Tue, Feb 17, 2015 at 12:34 PM, Paolo Bonzini 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 default but
it c
On Fri, Feb 13, 2015 at 1:56 PM, Stefan Beller 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".
Linus
On Mon, Jan 26, 2015 at 1:35 PM, Junio C Hamano 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
should be ca
On Mon, Jan 26, 2015 at 1:07 PM, Josh Boyer 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 git tree to work.
(O
On Mon, Jan 26, 2015 at 8:32 AM, Josh Boyer 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 target '../../../../
On Tue, Oct 21, 2014 at 1:08 AM, Michael J Gruber
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 round of the world-fam
On Mon, Oct 20, 2014 at 3:28 PM, brian m. carlson
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
> between versions.
The ke
Linus
From d5ca7ae0a34e31c48397f59b03ecabda7c5c40b2 Mon Sep 17 00:00:00 2001
From: Linus Torvalds
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
On Fri, Jun 27, 2014 at 12:55 PM, Jason Pyeron 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 expertise, but
On Fri, Jun 27, 2014 at 12:38 PM, Linus Torvalds
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 w
On Fri, Jun 27, 2014 at 10:48 AM, Junio C Hamano 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 of only
On Wed, Jun 25, 2014 at 2:55 AM, Uwe Kleine-König
wrote:
>
> $ git rev-parse HEAD
> 9e065e4a5a58308f1a0da4bb80b830929dfa90b3
> $ git ls-remote origin | grep 9e065e4a5a58308f1a0da4bb80b830929dfa90b3
> 9e065e4a5a58308f1a0da4bb80b830929dfa90b3
> refs/heads/ukl/
On Mon, Jun 2, 2014 at 7:08 PM, NeilBrown 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 the
On Mon, Jun 2, 2014 at 2:01 PM, Michael S. Tsirkin 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
> git://git.kernel.org/pub/scm/l
On Thu, May 29, 2014 at 6:58 PM, Jeff King 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 forwarding
mo
From: Linus Torvalds
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
to anything
I just got a comment saying that
git commit --amend --date=now
doesn't work. I replied that you can use
--date="$(date)"
but I do wonder if we should accept the approxidate format - we do in
other equivalent places. Hmm?
The code uses fmt_ident(), which uses parse_date(), which in turn
On Mon, Mar 31, 2014 at 11:47 AM, Junio C Hamano 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,
Linus
--
On Mon, Mar 31, 2014 at 11:30 AM, Junio C Hamano 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 infinite error
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 trie
On Wed, Jan 29, 2014 at 3:34 PM, Junio C Hamano 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" problem.
Tha
On Thu, Jan 23, 2014 at 2:58 PM, Junio C Hamano 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 or tag locally,
On Thu, Jan 23, 2014 at 11:43 AM, Junio C Hamano 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 think.
If you
From: Linus Torvalds
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" uses to create
that
On Wed, Jan 22, 2014 at 2:14 PM, Junio C Hamano 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
question about
On Wed, Jan 22, 2014 at 2:03 PM, Linus Torvalds
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
On Wed, Jan 22, 2014 at 1:46 PM, Junio C Hamano 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 bit
From: Linus Torvalds
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"
On Wed, Sep 18, 2013 at 5:43 AM, Sebastian Schuberth
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 bug, but the reason
On Fri, Sep 13, 2013 at 12:53 PM, Sebastian Schuberth
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 simpler than just say
On Thu, Sep 12, 2013 at 4:15 PM, Richard Hansen 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 too. Just ask t
On Thu, Sep 12, 2013 at 3:30 PM, Junio C Hamano 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 with the text
On Mon, Aug 19, 2013 at 2:56 PM, Kyle J. McKay 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 memory, it blows ev
On Mon, Aug 19, 2013 at 10:16 AM, Junio C Hamano wrote:
> Linus Torvalds 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.
>
> Do we catch EINV
On Mon, Aug 19, 2013 at 8:41 AM, Steffen Prohaska 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 filesystem l
On Tue, Jun 11, 2013 at 11:06 AM, Felipe Contreras
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 being a dick and argui
On Tue, Jun 11, 2013 at 10:18 AM, Hilco Wijbenga
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 etc is someth
On Thu, May 23, 2013 at 5:21 PM, Junio C Hamano 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 setting pull
On Thu, May 23, 2013 at 3:11 PM, Junio C Hamano 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 their
On Sat, May 11, 2013 at 2:49 PM, John Keeping 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 still means it
On Sat, May 11, 2013 at 12:54 PM, John Keeping 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 very bad idea.
On Fri, Apr 26, 2013 at 12:19 PM, Junio C Hamano 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 case:
for i
On Fri, Apr 26, 2013 at 11:47 AM, Junio C Hamano 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 even worth it fo
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
On Thu, Apr 4, 2013 at 1:04 PM, Ramkumar Ramachandra 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
On Thu, Apr 4, 2013 at 12:36 PM, Ramkumar Ramachandra
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 use-case.
I don't
On Thu, Apr 4, 2013 at 11:52 AM, Ramkumar Ramachandra
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 flexibility; you
> can
On Thu, Apr 4, 2013 at 11:30 AM, Ramkumar Ramachandra
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 the idea.
I
On Wed, Mar 27, 2013 at 1:00 PM, Junio C Hamano 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 for a while un
On Wed, Mar 27, 2013 at 12:04 PM, Jeff King 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 stats in para
201 - 300 of 779 matches
Mail list logo
