Re: [PATCH v5 6/6] RFC blame: use a fingerprint heuristic to match ignored lines

u segfault with the patch and don't segfault with the patch, there is not much of a point in declaring this "somebody else's problem", is there? It has to be fixed anyway in order to make the patch get in. Or am I fundamentally misunderstanding something here? -- David Kastrup

Re: [PATCH] blame.c: don't drop origin blobs as eagerly

there are a number of separate layers that are doing rather similar work with rather similar data, but intermingling the layers' work is not going to be good for maintainability. Caching at the various layers can keep their separation while still reducing some of the redundancy costs. -- David Kastrup

Re: [PATCH] blame.c: don't drop origin blobs as eagerly

Junio C Hamano writes: > David Kastrup writes: > >> When a parent blob already has chunks queued up for blaming, dropping >> the blob at the end of one blame step will cause it to get reloaded >> right away, doubling the amount of I/O and unpacking when proces

[PATCH] blame.c: don't drop origin blobs as eagerly

that should incur additional memory pressure mostly when processing the merges from old branches. Signed-off-by: David Kastrup --- blame.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/blame.c b/blame.c index 5c07dec190..c11c516921 100644 --- a/blame.c +++ b/blame.c

Re: Make the git codebase thread-safe

Duy Nguyen writes: > On Tue, Apr 2, 2019 at 5:30 PM David Kastrup wrote: >> >> Duy Nguyen writes: >> >> > On Tue, Apr 2, 2019 at 7:52 AM Matheus Tavares >> > wrote: >> >> I downloaded chromium to give it a try and got (on a m

Re: Make the git codebase thread-safe

#x27;ve proposed a trivial change in 2014 that could have cut down typical blame times significantly but nobody was interested in testing and committing it, and it is conceivable that in limited-memory situations it might warrant some accounting/mitigation for weird histories (not that ther

Re: [PATCH] blame.c: don't drop origin blobs as eagerly

Johannes Schindelin writes: > Hi David, > > On Sat, 28 May 2016, David Kastrup wrote: > >> > The short version of your answer is that you will leave this patch in >> > its current form and address none of my concerns because you moved on, >> > correct? If

[PATCH v2] Require 0 context lines in git-blame algorithm

org/gmane.comp.version-control.git/255289/>. <http://permalink.gmane.org/gmane.comp.version-control.git/295795> sheds some more light on the history of the previous choice. Signed-off-by: David Kastrup --- builtin/blame.c | 7 +++ 1 file changed, 3 insertions(+), 4 deletions(-)

Re: [PATCH] blame.c: don't drop origin blobs as eagerly

Johannes Schindelin writes: > On Fri, 27 May 2016, David Kastrup wrote: > >> Johannes Schindelin writes: >> >> > On Fri, 27 May 2016, David Kastrup wrote: >> > >> >> pressure particularly when the history contains lots of merges from

Re: [PATCH] blame.c: don't drop origin blobs as eagerly

Johannes Schindelin writes: > On Fri, 27 May 2016, David Kastrup wrote: > >> pressure particularly when the history contains lots of merges from >> long-diverged branches. In practice, this optimization appears to >> behave quite benignly, > > Why not just stop he

[PATCH] Require 0 context lines in git-blame algorithm

Previously, the core part of git blame -M required 1 context line. There is no rationale to be found in the code (one guess would be that the old blame algorithm was unable to deal with immediately adjacent regions), and it causes artifacts like discussed in the thread http://thread.gmane.org/gmane

[PATCH] blame.c: don't drop origin blobs as eagerly

When a parent blob already has chunks queued up for blaming, dropping the blob at the end of one blame step will cause it to get reloaded right away, doubling the amount of I/O and unpacking when processing a linear history. Keeping such parent blobs in memory seems like a reasonable optimization.

Re: Draft of Git Rev News edition 1

Thomas Ferris Nicolaisen writes: > On Sun, Mar 22, 2015 at 12:21 PM, David Kastrup wrote: >> David Kastrup (dak at gnu.org) previously reimplemented significant >> parts of "git blame" for a vast gain in performance with complex >> histories and

Re: Draft of Git Rev News edition 1

d sending a pull request, or by commenting on > this GitHub issue: > > https://github.com/git/git.github.io/issues/17 > > You can also reply to this email. I've seen David Kastrup (dak at gnu.org) previously reimplemented significant parts of "git blame" for a v

Re: Promoting Git developers

is about news? > >> If I may humbly offer the suggestion that "Git Blame" would be a far more >> appropriate pun as a name :) > > You don't want me to steal Junio's blog title: > > http://git-blame.blogspot.fr/ > > don't you? "Git Annotate"? -- David Kastrup -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html

Re: git-scm.com website

kes it a bit harder to say "not my field of responsibility". -- David Kastrup -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html

Re: git-scm.com website

David Kastrup writes: > Scott Chacon writes: > >> On Mon, Mar 9, 2015 at 9:06 AM, David Kastrup wrote: >>> Personally, I consider the recent migration of the Emacs repository to >>> Git a bigger endorsement but then that's me. >> >> I would lo

Re: git-scm.com website

Scott Chacon writes: > On Mon, Mar 9, 2015 at 9:06 AM, David Kastrup wrote: >> Personally, I consider the recent migration of the Emacs repository to >> Git a bigger endorsement but then that's me. > > I would love to have Emacs on that page, actually. If you guys

Re: git-scm.com website

Shawn Pearce writes: > On Mon, Mar 9, 2015 at 9:06 AM, David Kastrup wrote: >> Shawn Pearce writes: >> >>> On Mon, Mar 9, 2015 at 6:57 AM, Michael J Gruber >>> wrote: >>>> >>>> Since we're talking business: git-scm.com still look

Re: git-scm.com website

embarrassing list of companies to advertise for. Personally, I consider the recent migration of the Emacs repository to Git a bigger endorsement but then that's me. It might make sense to reduce this list just to "Projects" since those are actually more tangible and verifiable. Or scrap it

Re: Promoting Git developers

Michael J Gruber writes: > Christian Couder venit, vidit, dixit 07.03.2015 08:18: >> Hi, >> >> On Fri, Mar 6, 2015 at 6:41 PM, David Kastrup wrote: >> >>> At some point of time I think it may be worth reevaluating the toxic >>> atmosphere against

Re: Git very slow ?

Ken Moffat writes: > On Sun, Mar 08, 2015 at 05:21:22PM +0100, David Kastrup wrote: > >> Particularly not git-blame in 2.1. I should be quite surprised to see >> any git-blame call running noticeably slower in 2.1 than in any >> preceding version. >> >>

Re: Git very slow ?

acked aggressively and thus any access to older revisions got slower. However, that change would be mostly tied to the repository rather than the version of Git you access it with. -- David Kastrup -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html

Re: Bashing freelancers

Junio C Hamano writes: > David Kastrup writes: > >> Junio C Hamano writes: >> >>> David Kastrup writes: >>> >>>> Good work is worth good money. Suggesting that people who are not able >>>> to work for free are morally infe

Re: Bashing freelancers

Junio C Hamano writes: > David Kastrup writes: > >> Junio C Hamano writes: >> >>> David Kastrup writes: >>> >>>> Good work is worth good money. Suggesting that people who are not able >>>> to work for free are morally infe

Re: Bashing freelancers

Junio C Hamano writes: > David Kastrup writes: > >> Good work is worth good money. Suggesting that people who are not able >> to work for free are morally inferior is not conducive for a cooperative >> work atmosphere. > > Yes, but I do not think anybody did any

Bashing freelancers (was: [ANNOUNCE] Git Merge Contributors Summit, April 8th, Paris)

d after I pointed out that not even my name was correct, removed altogether. All that in connection with public shaming that I wanted to point out to end users that this work required financing if it were to continue. -- David Kastrup -- To unsubscribe from this list: send the line "unsubscrib

Re: weird behaviour in git

could not be interpreted exactly like the commit info interpreted it. It's nonsensical and should in my opinion rather be stated as # Changes to be committed: # removed:a # new file: Makefile # new file: b But that's not the fault of Git mv. -- David Kastrup -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html

Possible GSoC project?

get kind of release for a number of platforms. -- David Kastrup -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html

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

kernel > source tree is one that points to a different directory using ".." > format. And while I could imagine that "patch" ends up counting the > dot-dot entries and checking that it's all inside the same tree it is > patching, I could also easily see patch *not

Re: git-svn metadata commands performance issue

ing about something like 64kB of total available memory here), that tended to work reasonably well. -- David Kastrup -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html

Re: reject "backwards" merges

ay to figure out which kind of branch a merge will land on. Most "reversed merges" probably come into being by having a fast-forward in a series of zig-zagged merges. Naturally the history before the fast-forward can only be "the right way round" for one of the two branches. -

Re: Antw: Re: Enhancement Request: "locale" git option

ionieren" describes the concept of tracking >> better than "beobachten", IMO. I'll send a patch for that. > > Isolated from usage, "versionieren" and "tracking" have no common translation; > what about "verfolgen" (~follow) for

Re: [BUG] Documentation: git log: --exit-code undocumented?

Junio C Hamano writes: > David Kastrup writes: > >> I disagree that --exit-code does nothing: it indicates whether the >> listed log is empty. So for example >> >> git log -1 --exit-code a..b > /dev/null >> >> can be used to figure out whet

Re: [BUG] Documentation: git log: --exit-code undocumented?

7;t. That is why it is not listed. I disagree that --exit-code does nothing: it indicates whether the listed log is empty. So for example git log -1 --exit-code a..b > /dev/null can be used to figure out whether "a" is a proper ancestor of "b" or not. -- David Kastrup -

Re: Sources for 3.18-rc1 not uploaded

Linus Torvalds writes: > 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 tim

Re: git branch --merged and git branch --verbose do not combine

Junio C Hamano writes: > David Kastrup writes: > >> dak@lola:/usr/local/tmp/lilypond$ ../git/git branch --merged --verbose >> fatal: malformed object name --verbose > > Only at the very end of the command line if you omit something that > is required, Git helps by de

git branch --merged and git branch --verbose do not combine

ne gets an incomplete list (basically ignoring --merged) or an error message. Since both behavior and naming of the --verbose option is more or less orthogonal to other listing options, it would make sense to allow it to combine with them. -- David Kastrup -- To unsubscribe from this list: sen

Re: AW: Understanding behavior of git blame -M

iscern that you find the current behavior > correct. I don't say any such thing and don't imply it. -- David Kastrup -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html

Re: Understanding behavior of git blame -M

uzzle from genius to genius. Good luck figuring it out. I have not touched this when rewriting git-blame recently, and I am not interested in touching it. I stand absolutely nothing to gain from working on Git. -- David Kastrup -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html

Re: [PATCH/RFH 0/3] stable priority-queue

ferent way, but at least will correspond to the order the commits have been discovered/generated, so they should still exhibit a more topological relation than what prio_queue does without further help. -- David Kastrup -- To unsubscribe from this list: send the line "unsubscribe git"

Re: Git reset --hard with staged changes

always remove untracked files then? Because it never removes them? Git only removes files once it tracks them. This includes the operation of removing _and_ untracking them, like with git reset --hard. The only command which explicitly messes with untracked files is git-clean. -- Dav

Re: Git reset --hard with staged changes

a borderline, but I consider it better that once a file _is_ tracked, git reset --hard will first physically remove it before untracking it. -- David Kastrup -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html

Re: What's cooking in git.git (Jun 2014, #02; Fri, 6)

ble of getting the name right. At any rate, as promised I'll post a list of remaining low-hanging fruit in the next days for somebody else to get praised for, and then I'm out. -- David Kastrup -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a me

Re: [PATCH] t9001: avoid not portable '\n' with sed

\n' shall match a embedded in the > pattern space. > > so it may be better to be a bit more explicit in the log message to > say whose implementation has this issue to warn people. "shall match" talks about the match expression, not the replacement. -- David Kastr

Re: [PATCH] pack-objects: use free()+xcalloc() instead of xrealloc()+memset()

te packfile > with missing delta base., 2006-02-19). Not that it matters, but I was > just surprised since the code you are changing did not seem familiar to > me. I guess there was just too much refactoring during the code movement > for git-blame to pass along the blame in this case.

Re: [ANNOUNCE] Git v2.0.0

Jeff King writes: > On Sat, May 31, 2014 at 11:52:24AM +0200, David Kastrup wrote: > >> Some mailing list filters and/or spam filters flag mails with too many >> recipients so that they need to pass through moderation first. The >> typical threads on this list are short

Re: [ANNOUNCE] Git v2.0.0

not and a glance at it shows nothing but insults, wild accusations, threats and so on for the umpteenth time, I'd consider twice clicking "Accept". Whether or not I ultimately did so, this would likely contribute to the delay. -- David Kastrup -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html

Re: [ANNOUNCE] Git v2.0.0

sender on silent moderation, where postings will only appear once he has acknowledged them. However, that is a manual and burdensome process and requires an up-front decision to do so. Once a message made it to the list, the various archives will pick it up. -- David Kastrup -- To unsubscribe from this

Re: [PATCH 1/5] progress.c: replace signal() with sigaction()

Erik Faye-Lund writes: > On Wed, May 28, 2014 at 10:19 AM, David Kastrup wrote: >> Chris Packham writes: >> >>> On 28/05/14 18:14, Jeremiah Mahler wrote: >>>> static void clear_progress_signal(void) >>>> { >>>>

Re: [PATCH 1/5] progress.c: replace signal() with sigaction()

sa)); >> +sa.sa_handler = SIG_IGN; > > A C99 initialiser here would save the call to memset. Unfortunately > Documentation/CodingGuidelines is fairly clear on not using C99 > initialisers, given the fact we're now at git 2.0 maybe it's time to > revisit this policy? If I

Re: [PATCH v3 2/5] commit test: Change $PWD to $(pwd)

This can cause confusion if one shell instance maintains 'PWD' but a subsidiary and different shell does not know about 'PWD' and executes 'cd'; in this case 'PWD' points to the wrong directory. Use '`pwd`' rather than '$PWD'. Ok, probably Git relies on Posix 1003.1-2001 in other respects so it's likely not much of an actual issue. -- David Kastrup -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html

Re: [PATCH] Get rid of the non portable shell export VAR=VALUE costruct

Johannes Sixt writes: > Am 5/22/2014 15:19, schrieb David Kastrup: >> Torsten Bögershausen writes: >> >>> On 2014-05-22 14.48, Elia Pinto wrote: >>>> Found by check-non-portable-shell.pl >>> >>> Thanks for picking this up >>>> -

Re: [PATCH] Get rid of the non portable shell export VAR=VALUE costruct

(1+1 != 2) { fputs("Warning: your CPU may be broken", stderr); } variety. If you have to check for that, you have bigger problems... -- David Kastrup -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html

Re: [ANNOUNCE] Git v2.0.0-rc4

"synchronization crash regression" while refusing to give further specifics, so this would unfortunately be the safest option for the upcoming release. Signed-off-by: Junio C Hamano -- David Kastrup -- To unsubscribe from this list: send the line "unsubscribe git&quo

Re: Fwd: [Bug] - Processing commit message after amend

mend --no-edit Ah, so you got your solution. It's not like you could add that sort of commit message interactively to start with, so it's not all that surprising that you won't be able to amend it interactively. -- David Kastrup -- To unsubscribe from this list: send the line "u

Re: [PATCH 0/4] remote-hg: more improvements

Felipe Contreras writes: > David Kastrup wrote: >> Shouting "your God is an imaginary shithead" every time you see Mark > > There's no point in discussing with an unconstructive person as you. So go to a constructive person you call your friend and show him one o

Re: [PATCH 0/4] remote-hg: more improvements

Junio C Hamano writes: > David Kastrup writes: > >> Philippe Vaucher writes: >> >>> Thanks for the explanation. I think it underlines well the A) >>> technical issues (quality commits) and the B) social issues (ability >>> to communicate in a fri

Re: [PATCH 0/4] remote-hg: more improvements

Felipe Contreras writes: > David Kastrup wrote: >> Felipe Contreras writes: >> >> > Philippe Vaucher wrote: >> >> [...] >> >> >> > Do you feel Felipe is in control of what you label bad behavior? Do you >> >> > feel yo

Re: [PATCH 0/4] remote-hg: more improvements

quot;. What effect your behavior has on others is not dependent on what you think about it. If you convinced yourself to be standing perfectly balanced and find yourself falling, there is no point in not catching yourself before smashing your head open just because you _know_ you have been sta

Re: [PATCH 0/4] remote-hg: more improvements

hat one want to have to rely on permanently but it may be worth thinking about ways to make consequences from difficulties less "inevitable" and/or grave. -- David Kastrup -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html

Re: [PATCH 0/4] remote-hg: more improvements

scratching their own itch, but once their contributions become significant, it's almost always the itches of others they are scratching, and continue to scratch, feeling responsible for them due to the skills they have been not as much blessed or cursed but entrusted with. And programming

Re: [PATCH 0/4] remote-hg: more improvements

a manner "if a seedy stranger gave me that code on a street corner, I would have no problem checking it in". In practice, the shortcuts offering themselves through civil behavior and mutual trust get a lot more work done. But they _are_ a vector for "social engineering". You have to

Re: [PATCH 0/4] remote-hg: more improvements

sion fees, only benefit me... -- David Kastrup -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html

Re: Should git-remote-hg/bzr be part of the core?

basic understanding of people. So all you can really aim for is understanding: presenting your best case. Forget about "rhetorics" and the like: you suck at them, and a technical audience is easily annoyed by them even when they are employed well. And if a calm presentation does not l

Re: Should git-remote-hg/bzr be part of the core?

bout a lack of effort here. It is just not spent conducively. -- David Kastrup -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html

Re: What's cooking in git.git (May 2014, #02; Fri, 9)

ne making the decisions is unilateral. The salient questions rather are whether the decision is sensible, takes into account all available input and is communicated in a reasonable manner. -- David Kastrup -- To unsubscribe from this list: send the line "unsubscribe git" in the body

Re: Output from "git blame A..B -- path" for the bottom commit is misleading

Junio C Hamano writes: > Jeff King writes: > >> On Fri, May 09, 2014 at 07:04:05AM +0200, David Kastrup wrote: >> >>> Arguably if the user explicitly limited the range, he knows what he's >>> looking at. Admittedly, I don't know offhand wh

Re: [PATCH v1 23/25] contrib: remove 'hooks/multimail'

argumentativeness, and arrogance for some > reason don't win the hearts and minds of other contributors. Oh come on. Junio is not _that_ bad. -- David Kastrup -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html

Re: [PATCH v1 04/25] contrib: remove 'buildsystems'

Felipe Contreras writes: > David Kastrup wrote: >> Felipe Contreras writes: >> >> > David Kastrup wrote: >> > >> >> The idea of removing software from distribution is to get rid of >> >> stuff without a user base rather than punishin

Re: [PATCH v1 04/25] contrib: remove 'buildsystems'

Felipe Contreras writes: > David Kastrup wrote: > >> The idea of removing software from distribution is to get rid of >> stuff without a user base rather than punishing lazy developers. > > No. So we have you on record that you would want to get rid of stuff _with_ a us

Re: [PATCH v1 04/25] contrib: remove 'buildsystems'

oftware from distribution is to get rid of stuff without a user base rather than punishing lazy developers. If it were the latter, then you could argue that anybody not willing to host his own repository should get thrown off Git's. That would solve the whole contrib "probl

Re: Output from "git blame A..B -- path" for the bottom commit is misleading

what he's looking at. Admittedly, I don't know offhand which options _will_ produce boundary commit indications: there may be some without explicit range limitation, and we might also be talking about limiting through shallow repos (git blame on a shallow repo is probably a bad idea in

Re: Output from "git blame A..B -- path" for the bottom commit is misleading

to > me (when I do use them, I just mentally assume that the information in > the boundary line is useless; this is just making that more apparent). It is unclear to me what "this one makes the most sense to me" is referring to, in particular whether it encompasses the "and not ove

Re: Output from "git blame A..B -- path" for the bottom commit is misleading

> which does away with the misleading information altogether. That would make more sense for -b but hardly for the default. > I myself is leaning towards the latter between the two, and not > overriding "-b" but introducing another "cleanse the output of > useless bottom inform

Re: Is there any efficient way to track history of a piece of code?

it blame -w might help with a number of "coding style fixes". -- David Kastrup -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html

Re: Beginner question on "Pull is mostly evil"

;s basically unavoidable. Two opposing directions are actually part of the same workflow usually handled by "git pull": "Codeveloper X sends a pull request to Y who maintains the mainline. Y executes git pull to merge X' sidebranch into the mainline." "Codeveloper X execu

Re: [PATCH v2] pager: remove 'S' from $LESS by default

ed much worse than the metadata: otherwise it would make much more sense to display the content _first_ in line. The metadata is useless without the content anyway. -- David Kastrup -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html

Re: [PATCH 1/9] Define a structure for object IDs.

Andreas Schwab writes: > David Kastrup writes: > >> Your premise is _not_ assumed in my statement. My premise was "a >> pointer to something of the same type of [the struct's] first member". >> That does quite explicitly _not_ state that an object of str

Re: [PATCH] Bump core.deltaBaseCacheLimit to 96m

Duy Nguyen writes: > On Mon, May 5, 2014 at 12:13 AM, David Kastrup wrote: >> The default of 16m causes serious thrashing for large delta chains >> combined with large files. >> >> Here are some benchmarks (pu variant of git blame): >> >> t

Re: [PATCH 1/9] Define a structure for object IDs.

Andreas Schwab writes: > David Kastrup writes: > >> It does not as far as I can see guarantee that a pointer to something >> of the same type of its first member can be converted to a pointer to >> a struct even if the struct only contains a member of such type. > &

Re: [PATCH 1/9] Define a structure for object IDs.

of the same type of its first member can be converted to a pointer to a struct even if the struct only contains a member of such type. -- David Kastrup -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html

Re: [PATCH 1/9] Define a structure for object IDs.

Andreas Schwab writes: > David Kastrup writes: > >> Andreas Schwab writes: >> >>> "brian m. carlson" writes: >>> >>>> I don't even plan to write the code assuming that offsetof(struct >>>> object_id, oid) is 0

[PATCH] Bump core.deltaBaseCacheLimit to 96m

sys 0m23.964s 96m: real2m5.668s user1m50.784s sys 0m14.288s 128m: real2m4.337s user1m50.764s sys 0m12.832s 192m: real2m3.567s user1m49.508s sys 0m13.312s Signed-off-by: David Kastrup --- Documentation/config.txt | 2 +- environment.c| 2 +-

Re: [PATCH 1/9] Define a structure for object IDs.

Andreas Schwab writes: > "brian m. carlson" writes: > >> I don't even plan to write the code assuming that offsetof(struct >> object_id, oid) is 0. > > This is guaranteed by the C standard, though. Any reference? -- David Kastrup -- To unsubscribe fro

Re: Pull is Mostly Evil

. According to whose summary? https://www.youtube.com/watch?v=2eMkth8FWno> -- David Kastrup -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html

Re: [PATCH 1/9] Define a structure for object IDs.

as I know that anything but element dereference is a valid means of converting access to a struct to access to a sole element. -- David Kastrup -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html

Re: Pull is Mostly Evil

thers. You can't tell if someone else's argument is > good, because it runs against yours, and yours must be > right because you hold it. If he considered others capable of independent thought, would he call out their imperviousness to rhetorics as a deficiency? -- David Kastrup --

Re: Pull is Mostly Evil

y are around, they are worth getting plastered with your frustration. > It's the others that focus on the carisma and credentials of the > people in the discussion, rather than the arguments. I think you are confusing inertia with resistance. -- David Kastrup -- To un

Re: Pull is Mostly Evil

Felipe Contreras writes: > David Kastrup wrote: >> Richard Hansen writes: >> >> > These three usage patterns are at odds; it's hard to change the >> > default behavior of 'git pull' to favor one usage case without >> > harming a

Re: Pull is Mostly Evil

hould do. Should a screwdriver be turning clockwise or counterclockwise by default? There are valid arguments for either. -- David Kastrup -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html

Re: Pull is Evil

Andreas Krey writes: > On Fri, 02 May 2014 10:46:09 +0000, David Kastrup wrote: > ... >> What the gibbins? I don't even use git pull. > > I do, but I watch for the fast-forward message > and undo as appropriate. > >> I use git fetch, and then, depending on

Re: Pull is Mostly Evil

rder. > > I realize this has veered off into talking about an "update" command, > and not necessarily "pull", but since there a lot of proposals floating > around, I wanted to make one point: if we are going to do such a switch, > let's please make it something th

Re: Pull is Mostly Evil

David Lang writes: > On Fri, 2 May 2014, David Kastrup wrote: > >> It's just when the merge-left/merge-right/rebase-left/rebase-right >> decision kicks in that prescribing one git-pull behavior looks like a >> recipe for trouble. > > confusion at least. It'

Re: [PATCH 1/8] CodingGuidelines: typofix

>> > >> > which seems to say that with 'e' is more common. >> >> Grammar by democracy. ;) > > Languages are a democracy. There's no authority that decides if > "unibrow" should become part of the English language. We all do. Well, a

Re: Pull is Evil

vincing them (for every pull) to set the appropriate ff flag. >> >> It wouldn't matter if by the default non-fast-forward merges are >> rejected. > > It would matter if you didn't want them making non-fast-forward merges > (e.g. for explicitly-merged topic branches). s/didn't want/only wanted/ -- David Kastrup -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html

Re: Pull is Mostly Evil

is uncontentious, and I _think_ that fast-forwards are pretty uncontentious as well. It's just when the merge-left/merge-right/rebase-left/rebase-right decision kicks in that prescribing one git-pull behavior looks like a recipe for trouble. -- David Kastrup -- To unsubscribe from this lis

Re: Pull is Evil

or merge. git pull is not part of my workflow exactly because it does non-connected things not translating unambiguously to a particular identifiable workflow. It might sometimes, more by accident than design, do what I would have done anyway. But I prefer making that choice on my own, depending on

Re: [PATCH 6/8] CodingGuidelines: call the conditional statement "if ()", not "if()"

Junio C Hamano writes: > David Kastrup writes: > >>> - - We try to avoid assignments inside if(). >>> + - We try to avoid assignments inside "if ()" condition. >> >> That's not grammatical. > > OK, > > ... inside the condi

Re: [PATCH 4/8] CodingGuidelines: give an example for control statements

and "for". > > + (incorrect) > + if test -f hello; then > + do this > + fi > + > + (correct) > + if test -f hello > + then > + do this > + fi > + > - We prefer "test" over "[ ... ]"

  1   2   3   4   >