Re: bogus merges

On Mon, 5 Sep 2005, Wayne Scott wrote: A recent commit in linux-2.6 looks like this: It hopefully shouldn't happen any more with the improved and fixed git-merge-base. Author: Russell King [EMAIL PROTECTED] Date: Wed Aug 31 10:12:14 2005 +0100 I suspect rmk is using cogito-0.13, and

Re: Tool renames? was Re: First stab at glossary

On Mon, 5 Sep 2005, David Kågedal wrote: But to the users (like myself), there's no point in naming it by whether it's a script or a binary. So? There's no downside. To you, as a user, you never see the -script ending anyway. You'd never type it out, or you're already doing something

Re: Tool renames? was Re: First stab at glossary

On Tue, 6 Sep 2005, Martin Langhoff wrote: Grep knows how to ignore binary files. That wasn't the _point_. The point is, naming things as being scripts is useful. Grep is just an example. Naming things as being .pl or .sh is _not_ useful. So with grep you can use -I, but what about doing

Re: Tool renames? was Re: First stab at glossary

On Tue, 6 Sep 2005, Junio C Hamano wrote: Linus Torvalds [EMAIL PROTECTED] writes: The point is, naming things as being scripts is useful. Grep is just an example. Naming things as being .pl or .sh is _not_ useful. Sorry, but why not? What's the upside? I can point to one downside

Re: [PATCH 0/2] A new merge algorithm, take 3

On Thu, 8 Sep 2005, Junio C Hamano wrote: Yes, the reading of three trees upfront is probably the culprit in your case However, note that _most_ tree reading just reads one. Merges may take half a second, and yes, when I did it, the fact that we move things around in the array is by far

Re: [PATCH 0/2] A new merge algorithm, take 3

On Thu, 8 Sep 2005, Chuck Lever wrote: in my case the merges were taking significantly longer than a half second. making this change is certainly not worth it if merges are running fast... Note that in cold-cache cases, all the expense of read-tree is in actually reading the tree

Re: git applymbox is too anal

On Thu, 8 Sep 2005, Greg KH wrote: Or am I missing some option to 'git applymbox' that I can't seem to find? No. git-apply wants an exact bit-for-bit match. Partly because fuzz is hard, but mostly because I don't like it. I apply a _lot_ of patches, and if a unforgiving git-apply works

Re: [PATCH maint-1.6.5] block-sha1: avoid unaligned accesses on some big-endian systems

On Sat, Jul 14, 2012 at 12:59 AM, Jonathan Nieder jrnie...@gmail.com wrote: Unfortunately, on big-endian architectures, if p is a pointer to unsigned int then current gcc assumes it is properly aligned and converts this construct to a 32-bit load. This patch seems to entirely depend on the

Re: [PATCH maint-1.6.5] block-sha1: avoid unaligned accesses on some big-endian systems

On Sat, Jul 14, 2012 at 12:50 PM, Jonathan Nieder jrnie...@gmail.com wrote: After the patch, what reason does gcc have to expect that 'block' is 32-bit aligned except when it is? The code (including the code I didn't touch) never casts from char * to int * except in get/put_be32 on arches

Re: [PATCH maint-1.6.5 v2] block-sha1: avoid pointer conversion that violates alignment constraints

Looks good to me. I'd suggest doing the macro argument expansion in #define SHA_SRC(t) get_be32((unsigned char *) block + t*4) with parenthesis around 't', but that's a fairly independent thing. The old code didn't do that either. Linus -- To unsubscribe from this list: send the

Re: [PATCH v2] macos: lazily initialize iconv

On Tue, Jul 31, 2012 at 11:37 AM, Junio C Hamano gits...@pobox.com wrote: * This is not even compile tested, so it needs testing and benchmarking, as I do not even know how costly the calls to open/close are when we do not have to call iconv() itself. Ok, so it's easily compile-tested:

Re: [PATCH v2] macos: lazily initialize iconv

On Tue, Jul 31, 2012 at 1:16 PM, Junio C Hamano gits...@pobox.com wrote: Eek. Oh, I agree. Doing a full character set conversion both ways is quite a bit more work. Not just write_entry() codepath that creates the final paths on the filesystem, you would need to touch lstat() calls that

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

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

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

[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

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

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

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: [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"

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

RFC: dynamic "auto" date formats

This is a throw-away idea with a simple patch attached, which I don't think anybody should really take all that seriously per se, but I thought I'd throw it out and see if it generates any discussion. I almost never use anything but the default date format (DATE_NORMAL), but every once in a while

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

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

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

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: [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: [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: [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 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] 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: 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 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: [PATCH] merge: refuse to create too cool a merge by default

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

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

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

On Wed, Mar 16, 2016 at 9:29 AM, Linus Torvalds <torva...@linux-foundation.org> wrote: > > This should all line up: > > Column 1 Column 2 > > A B > ABCD EFGH > SPACESInstead of Tabs > >

Re: [PATCH v3 0/5] Expanding tabs in "git log" output

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

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: [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] 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: history damage in linux.git

On Thu, Apr 21, 2016 at 9:36 AM, Linus Torvalds <torva...@linux-foundation.org> 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 i

Re: history damage in linux.git

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

Re: history damage in linux.git

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

Re: history damage in linux.git

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 >

Re: history damage in linux.git

On Thu, Apr 21, 2016 at 10:43 AM, Linus Torvalds <torva...@linux-foundation.org> wrote: > > In other words, I'm trying to convince people that my patch not only > gives a good result, but that the "weight numbers" I use make some > kind of conceptual sense from a compl

Re: history damage in linux.git

On Thu, Apr 21, 2016 at 12:27 PM, Junio C Hamano <gits...@pobox.com> wrote: > Linus Torvalds <torva...@linux-foundation.org> writes: > >> But this patch is small and simple, and has some excuses for its >> behavior. What do people think? > > I like it that

Re: history damage in linux.git

On Thu, Apr 21, 2016 at 11:05 AM, Jeff King wrote: > > I actually think the best name for aed06b9 is probably: > > v3.13-rc1~65^2^2~42 Sounds likely. I don't know how to find that best match without a complete rewrite, though. My recent patch that got v3.13-rc2~32^2^2~47

Re: [PATCH] name-rev: include taggerdate in considering the best name

On Fri, Apr 22, 2016 at 11:11 AM, Jeff King wrote: > > I confirmed that it does find the "optimal" tag for the case we've been > discussing. Yes. I'm a bit more worried about the date behavior for projects that merge back stable branches into their development trees (is the

Small trivial annoyance with the nice new builtin "git am"

Ok, it's no longer *that* new, but I only now noticed.. So I noticed that when I applied the last patch-bomb series from Andrew, all the commit date-stamps are idential. Now, it would be lovely if the new builtin git-am really was *so* fast that it applies a 100+-patch series in under a second,

Re: Small trivial annoyance with the nice new builtin "git am"

On Thu, Jul 28, 2016 at 5:29 PM, Jeff King wrote: > > I guess we want something like: > > +void reset_ident_date(void) > +{ > + strbuf_reset(_default_date); > +} Looks sane. > and then to sprinkle calls liberally through builtin-ified programs when > they move from one unit

Re: Small trivial annoyance with the nice new builtin "git am"

On Thu, Jul 28, 2016 at 5:21 PM, Jeff King wrote: > > I do wonder if you would be happier giving each commit a "fake" > monotonically increasing time, so they are correctly ordered by commit > date. No, that would be nasty, partly for the corner case you mention, but partly

Re: Odd git overrflow bug?

On Sun, Jul 10, 2016 at 2:21 PM, Linus Torvalds <torva...@linux-foundation.org> wrote: > > I'm not sure why it doesn't happen in current git master, because that > function is the same, and the logic around expand_tabs_in_log looks > similar too. Ahh. Commit 43ec55091553 (&q

Re: Odd git overrflow bug?

On Sun, Jul 10, 2016 at 2:05 PM, Linus Torvalds <torva...@linux-foundation.org> wrote: > > I'm getting "extra" being -1 in strbuf_grow(). Let me dog deeper. "dog deeper"? My typing skills are deteriorating. Anyway, I dug deeper, and the reason is that "tabw

Odd git overrflow bug?

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

Re: Odd git overrflow bug?

On Sun, Jul 10, 2016 at 2:01 PM, Linus Torvalds <torva...@linux-foundation.org> wrote: > > I'll try to figure out why git-2.9.0 fails. I'm getting "extra" being -1 in strbuf_grow(). Let me dog deeper. Linus -- To unsubscribe from this list: send the line "u

Re: Odd git overrflow bug?

On Sun, Jul 10, 2016 at 11:41 AM, Andreas Schwab wrote: > > I've seen that too, but only at the end of bisection, when it tries to > display the bad commit. That's apparently what the kernel bug reporter sees too now. However, I cannot reproduce the problem with the

Re: [PATCH] reset cached ident date before creating objects

On Fri, Jul 29, 2016 at 11:05 AM, Jeff King wrote: > > Linus suggested resetting the timestamp after making the commit, to > clear the way for the next commit. But if we reset any cached value > _before_ making the commit, this has a few advantages: Looks fine to me. It should

Re: topological index field for commit objects

On Thu, Jun 30, 2016 at 3:30 AM, Jakub Narębski wrote: > > P.S. Having Git ensure that committerdate (as an epoch) is greater > than committerdates of its parents at the commit creation time (with > providing warning about time skew, perhaps not doing it if skew is > too large)

<    1   2   3   4   5   6   >