Re: [PATCH v5 6/6] RFC blame: use a fingerprint heuristic to match ignored lines
mich...@platin.gs writes:
> From: Michael Platings
>
> Hi Barret,
> This is the updated fuzzy matching algorithm, sorry for the delay. It does
> highlight a bug in the calculation for the number of lines ("int
> nr_parent_lines
> = e->num_lines - delta;") - if you apply the patch, build it, then try to
> ./git blame --ignore-rev blame.c then you'll get a
> segfault
> because nr_parent_lines is a negative number. I haven't had time to
> investigate further
> but I have confirmed that the bug is not due to my patch.
If you 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
Jeff King writes: > On Wed, Apr 03, 2019 at 07:06:02PM +0700, Duy Nguyen wrote: > >> On Wed, Apr 3, 2019 at 6:36 PM Jeff King wrote: >> > I suspect we could do even better by storing and reusing not just the >> > original blob between diffs, but the intermediate diff state (i.e., the >> > hashes produced by xdl_prepare(), which should be usable between >> > multiple diffs). That's quite a bit more complex, though, and I imagine >> > would require some surgery to xdiff. >> >> Amazing. xdl_prepare_ctx and xdl_hash_record (called inside >> xdl_prepare_ctx) account for 36% according to 'perf report'. Please >> tell me you just did not get this on your first guess. > > Sorry, it was a guess. ;) > > But an educated one, based on previous experiments with speeding up "log > -p". Remember XDL_FAST_HASH, which produced speedups there (but > unfortunately had some pathological slowdowns, because it produced too > many collisions). I've also played around with using other hashes like > murmur or siphash, but was never able to get anything remarkably faster > than what we have now. > >> I tracked and dumped all the hashes that are sent to xdl_prepare() and >> it looks like the amount of duplicates is quite high. There are only >> about 1000 one-time hashes out of 7000 (didn't really draw a histogram >> to examine closer). So yeah this looks really promising, assuming >> somebody is going to do something about it. > > I don't think counting the unique hash outputs tells you much about what > can be sped up. After all, two related blobs are likely to overlap quite > a bit in their hashes (i.e., all of their non-unique lines). The trick > is finding in each blob those ones that _are_ unique. :) > > But if we spend 36% of our time in hashing the blobs, then that implies > that we could gain back 18% by caching and reusing the work from a > previous diff (as David notes, a simple keep-the-last-parent cache only > yields 100% cache hits in a linear history, but it's probably good > enough for our purposes). Of course, if you really want to get tricky, you'll not even compare stuff that is expanded from the same delta-chain location. Basically, 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 processing a
>> linear history.
>>
>> Keeping such parent blobs in memory seems like a reasonable optimization
>> that should incur additional memory pressure mostly when processing the
>> merges from old branches.
>
> Thanks for finding an age-old one that dates back to 7c3c7962
> ("blame: drop blob data after passing blame to the parent",
> 2007-12-11).
>
> Interestingly, the said commit claims:
>
> When passing blame from a parent to its parent (i.e. the
> grandparent), the blob data for the parent may need to be read
> again, but it should be relatively cheap, thanks to delta-base
> cache.
>
> but perhaps you found a case where the delta-base cache is not all
> that effective in the benchmark?
The most relevant contribution is in a linear history where the diff
between commit and parent is followed by the diff between parent and
grandparent. It seems wasteful to recreate the blobs in this case. Of
course this is also the case where any close cache layers are more
likely to still be warm, so the savings may be less apparent. They are
likely more for deep delta chains in long histories where the
delta-chain cache is more thoroughly exercised.
--
David Kastrup
[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
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
@@ -1562,7 +1562,8 @@ static void pass_blame(struct blame_scoreboard *sb,
struct blame_origin *origin,
}
for (i = 0; i < num_sg; i++) {
if (sg_origin[i]) {
- drop_origin_blob(sg_origin[i]);
+ if (!sg_origin[i]->suspects)
+ drop_origin_blob(sg_origin[i]);
blame_origin_decref(sg_origin[i]);
}
}
--
2.20.1
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 machine with i7 and >> >> SSD, running Manjaro Linux): >> >> >> >> - 17s on blame for a file with long history[2] >> >> - 2m on blame for a huge file[3] >> >> - 15s on log for both [2] and [3] >> >> - 1s for git status >> >> >> >> It seems quite a lot, especially with SSD, IMO. >> > >> > There have been a couple of optimizations that are probably still not >> > enabled by default because they only benefit large repos. >> >> I'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 there isn't other code like that). > > I didn't really read the patch (I don't know much about blame.c to > really contribute anything there). But a quick "git blame --show-stats > unpack-trees.c" shows this > > Without the patch: > > num read blob: 767 > num get patch: 425 > num commits: 343 > > With the patch: > > num read blob: 419 > num get patch: 425 > num commits: 343 > > That's a nice reduction of blob reading. On a typical small file, the > actual time saving might be not much. But it could really help when > you blame a large file. > > Perhaps you could resubmit it again for inclusion? (at least a > sign-off-by is missing then) I don't expect it to go anywhere but will do. Feel free to herd it. -- David Kastrup
Re: Make the git codebase thread-safe
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 machine with i7 and
>> SSD, running Manjaro Linux):
>>
>> - 17s on blame for a file with long history[2]
>> - 2m on blame for a huge file[3]
>> - 15s on log for both [2] and [3]
>> - 1s for git status
>>
>> It seems quite a lot, especially with SSD, IMO.
>
> There have been a couple of optimizations that are probably still not
> enabled by default because they only benefit large repos.
I'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 there isn't other code like that).
Rebased/appended.
--
David Kastrup
>From a076daf13d144cb74ae5fd7250445bbfb4669a05 Mon Sep 17 00:00:00 2001
From: David Kastrup
Date: Sun, 2 Feb 2014 18:33:35 +0100
Subject: [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
that should incur additional memory pressure mostly when processing the
merges from old branches.
---
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
@@ -1562,7 +1562,8 @@ static void pass_blame(struct blame_scoreboard *sb, struct blame_origin *origin,
}
for (i = 0; i < num_sg; i++) {
if (sg_origin[i]) {
- drop_origin_blob(sg_origin[i]);
+ if (!sg_origin[i]->suspects)
+drop_origin_blob(sg_origin[i]);
blame_origin_decref(sg_origin[i]);
}
}
--
2.20.1
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 so, that's totally okay, it just needs to be spelled out. >> >> Yes, that's it. You'll notice that the code change itself is both >> minuscule as well purely functional, so it contains nothing >> copyrightable. > > That is unfortunately an interpretation of the law that would need to > come from a professional lawyer. A professional lawyer would laugh at "Signed-off-by:" being of more legal significance than a written record of intent but of course you know that. This is mere bluster. > As it is, the patch was clearly authored by you, and anybody else who > would claim authorship would most likely be breaking the law. The _diff_ is not "clearly authored" by me but just the simplest expression of the intent. The commit message is clearly authored by me but is not acceptable anyway. Whoever gets to write an acceptable commit message is up for all copyrightable credit in my book. Feel free to keep the authorship if you really want to, but when replacing the commit message it is not a particularly accurate attribution. > So I won't touch it. Signed-off-by: David Kastrup You don't get more than that for other patches either and it's a few bytes compared to a mail conversation. Here is a PGP signature on top. As I said: I am not going to put more work into it anyway and if it's an occasion for theatralics, it has at least accomplished something. -- David Kastrup signature.asc Description: PGP signature
[PATCH v2] 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.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(-)
diff --git a/builtin/blame.c b/builtin/blame.c
index 21f42b0..a3f6874 100644
--- a/builtin/blame.c
+++ b/builtin/blame.c
@@ -134,7 +134,7 @@ struct progress_info {
int blamed_lines;
};
-static int diff_hunks(mmfile_t *file_a, mmfile_t *file_b, long ctxlen,
+static int diff_hunks(mmfile_t *file_a, mmfile_t *file_b,
xdl_emit_hunk_consume_func_t hunk_func, void *cb_data)
{
xpparam_t xpp = {0};
@@ -142,7 +142,6 @@ static int diff_hunks(mmfile_t *file_a, mmfile_t *file_b,
long ctxlen,
xdemitcb_t ecb = {NULL};
xpp.flags = xdl_opts;
- xecfg.ctxlen = ctxlen;
xecfg.hunk_func = hunk_func;
ecb.priv = cb_data;
return xdi_diff(file_a, file_b, &xpp, &xecfg, &ecb);
@@ -980,7 +979,7 @@ static void pass_blame_to_parent(struct scoreboard *sb,
fill_origin_blob(&sb->revs->diffopt, target, &file_o);
num_get_patch++;
- if (diff_hunks(&file_p, &file_o, 0, blame_chunk_cb, &d))
+ if (diff_hunks(&file_p, &file_o, blame_chunk_cb, &d))
die("unable to generate diff (%s -> %s)",
oid_to_hex(&parent->commit->object.oid),
oid_to_hex(&target->commit->object.oid));
@@ -1129,7 +1128,7 @@ static void find_copy_in_blob(struct scoreboard *sb,
* file_p partially may match that image.
*/
memset(split, 0, sizeof(struct blame_entry [3]));
- if (diff_hunks(file_p, &file_o, 1, handle_split_cb, &d))
+ if (diff_hunks(file_p, &file_o, handle_split_cb, &d))
die("unable to generate diff (%s)",
oid_to_hex(&parent->commit->object.oid));
/* remainder, if any, all match the preimage */
--
2.7.4
--
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] 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 >> >> long-diverged branches. In practice, this optimization appears to >> >> behave quite benignly, >> > >> > Why not just stop here? >> >> Because there is a caveat. >> >> > I say that because... >> > >> >> and a viable strategy for limiting the total amount of cached blobs in a >> >> useful manner seems rather hard to implement. >> > >> > ... this sounds awfully handwaving. >> >> Because it is. > > Hrm. Are you really happy with this, on public record? Shrug. git-blame has limits for its memory usage which it generally heeds, throwing away potentially useful data to do so. git-blame -C has a store of data retained outside of those limits because nobody bothered reining them in, and this patch similarly retains data outside of those limits, though strictly limited to the pending priority queue size which controls the descent in reverse commit time order. In actual measurements on actual heavy-duty repositories I could not discern a difference in memory usage after the patch. The difference is likely only noticeable when you have lots of old long branches which is not a typical development model. The current data structures don't make harder constraints on memory pressure feasible, and enforcing such constraints would incur a lot of swapping (not by the operating system which does it more efficiently particularly since it does not need to decompress every time, but by the application constantly rereading and recompressing data). git-blame -C cares jack-shit about that (and it's used by git-gui's second pass if I remember correctly) and nobody raised concerns about its memory usage ever. I've taken out a lot of hand-waving of the "eh, good enough" kind from git-blame. If one wanted to have the memory limits enforced more stringently than they currently are, one would need a whole new layer of FIFO and accounting. This is not done in the current code base for existing functionality. And nobody bothered implementing it in decades or complaining about it in spite of it affecting git-blame -C (and consequently git-gui blame). Yes, this patch is another hand waving beside an already waving crowd. I am not going to lie about it but I am also not going to invest the time to fix yet another part of git-blame that has in decades not shown to be a problem anybody considered worth reporting let alone fixing. The limits for git-blame are set quite conservative: on actual developer systems, exceeding them by a factor of 10 will not exhaust the available memory. And I could not even measure a difference in memory usage in a small sample set of large examples. That's good enough for me (and better than the shape most of git-blame was in before I started on it and also after I finished), but it's still hand-waving. And it's not like it doesn't have a lot of company. >> > Since we already have reference counting, it sounds fishy to claim >> > that simply piggybacking a global counter on top of it would be >> > "rather hard". >> >> You'll see that the patch is from 2014. > > No I do not. There was no indication of that. I thought that git-send-email/git-am retained most patch metadata as opposed to git-patch, but you are entirely correct that the author date is nowhere to be found. Sorry for the presumption. >> When I actively worked on it, I found no convincing/feasible way to >> enforce a reasonable hard limit. I am not picking up work on this >> again but am merely flushing my queue so that the patch going to >> waste is not on my conscience. > > Hmm. Speaking from my point of view as a maintainer, this raises a > yellow alert. Sure, I do not maintain git.git, but if I were, I would > want my confidence in the quality of this patch, and in the patch > author being around when things go south with it, strengthened. This > paragraph achieves the opposite. It's completely reasonable to apply the same standards here as with an author having terminal cancer. I am not going to be around when things go South with git-blame but I should be very much surprised if this patch were significantly involved. >> > Besides, -C is *supposed* to look harder. >> >> We are not talking about "looking harder" but "taking more memory >> than the set limit". > > I meant to say: *of course* it uses more memory, it has a much harder > job. Still a non-sequitur. If you apply memory limits
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 here?
Because there is a caveat.
> I say that because...
>
>> and a viable strategy for limiting the total amount of cached blobs in a
>> useful manner seems rather hard to implement.
>
> ... this sounds awfully handwaving.
Because it is.
> Since we already have reference counting, it sounds fishy to claim
> that simply piggybacking a global counter on top of it would be
> "rather hard".
You'll see that the patch is from 2014. When I actively worked on it,
I found no convincing/feasible way to enforce a reasonable hard limit.
I am not picking up work on this again but am merely flushing my queue
so that the patch going to waste is not on my conscience.
>> In addition, calling git-blame with -C leads to similar memory retention
>> patterns.
>
> This is a red herring. Just delete it. I, for one, being a heavy user of
> `git blame`, could count the number of times I used blame's -C option
> without any remaining hands. Zero times.
>
> Besides, -C is *supposed* to look harder.
We are not talking about "looking harder" but "taking more memory than
the set limit".
> Also: is there an easy way to reproduce your claims of better I/O
> characteristics? Something like a command-line, ideally with a file in
> git.git's own history, that demonstrates the I/O before and after the
> patch, would be an excellent addition to the commit message.
I've used it on the wortliste repository and system time goes down from
about 70 seconds to 50 seconds (this is a flash drive). User time from
about 4:20 to 4:00. It is a rather degenerate repository (predominantly
small changes in one humongous text file) so savings for more typical
cases might end up less than that. But then it is degenerate
repositories that are most costly to blame.
> Further: I would have at least expected some rudimentary discussion
> why this patch -- which seems to at least partially contradict 7c3c796
> (blame: drop blob data after passing blame to the parent, 2007-12-11)
> -- is not regressing on the intent of said commit.
It is regressing on the intent of said commit by _retaining_ blob data
that it is _sure_ to look at again because of already having this data
asked for again in the priority queue. That's the point. It only drops
the blob data for which it has no request queued yet. But there is no
handle on when the request is going to pop up until it actually leaves
the priority queue: the priority queue is a heap IIRC and thus only
provides partial orderings.
>> diff --git a/builtin/blame.c b/builtin/blame.c
>> index 21f42b0..2596fbc 100644
>> --- a/builtin/blame.c
>> +++ b/builtin/blame.c
>> @@ -1556,7 +1556,8 @@ finish:
>> }
>> for (i = 0; i < num_sg; i++) {
>> if (sg_origin[i]) {
>> -drop_origin_blob(sg_origin[i]);
>> +if (!sg_origin[i]->suspects)
>> +drop_origin_blob(sg_origin[i]);
>> origin_decref(sg_origin[i]);
>> }
>
> It would be good to mention in the commit message that this patch does not
> change anything for blobs with only one remaining reference (the current
> one) because origin_decref() would do the same job as drop_origin_blob
> when decrementing the reference counter to 0.
A sizable number of references but not blobs are retained and needed for
producing the information in the final printed output (at least when
using the default sequential output instead of --incremental or
--porcelaine or similar).
> In fact, I suspect that simply removing the drop_origin_blob() call
> might result in the exact same I/O pattern.
It's been years since I actually worked on the code but I'm still pretty
sure you are wrong.
--
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
[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.comp.version-control.git/255289/>
---
builtin/blame.c | 7 +++
1 file changed, 3 insertions(+), 4 deletions(-)
diff --git a/builtin/blame.c b/builtin/blame.c
index 21f42b0..a3f6874 100644
--- a/builtin/blame.c
+++ b/builtin/blame.c
@@ -134,7 +134,7 @@ struct progress_info {
int blamed_lines;
};
-static int diff_hunks(mmfile_t *file_a, mmfile_t *file_b, long ctxlen,
+static int diff_hunks(mmfile_t *file_a, mmfile_t *file_b,
xdl_emit_hunk_consume_func_t hunk_func, void *cb_data)
{
xpparam_t xpp = {0};
@@ -142,7 +142,6 @@ static int diff_hunks(mmfile_t *file_a, mmfile_t *file_b,
long ctxlen,
xdemitcb_t ecb = {NULL};
xpp.flags = xdl_opts;
- xecfg.ctxlen = ctxlen;
xecfg.hunk_func = hunk_func;
ecb.priv = cb_data;
return xdi_diff(file_a, file_b, &xpp, &xecfg, &ecb);
@@ -980,7 +979,7 @@ static void pass_blame_to_parent(struct scoreboard *sb,
fill_origin_blob(&sb->revs->diffopt, target, &file_o);
num_get_patch++;
- if (diff_hunks(&file_p, &file_o, 0, blame_chunk_cb, &d))
+ if (diff_hunks(&file_p, &file_o, blame_chunk_cb, &d))
die("unable to generate diff (%s -> %s)",
oid_to_hex(&parent->commit->object.oid),
oid_to_hex(&target->commit->object.oid));
@@ -1129,7 +1128,7 @@ static void find_copy_in_blob(struct scoreboard *sb,
* file_p partially may match that image.
*/
memset(split, 0, sizeof(struct blame_entry [3]));
- if (diff_hunks(file_p, &file_o, 1, handle_split_cb, &d))
+ if (diff_hunks(file_p, &file_o, handle_split_cb, &d))
die("unable to generate diff (%s)",
oid_to_hex(&parent->commit->object.oid));
/* remainder, if any, all match the preimage */
--
2.7.4
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] 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. It's conceivable that this may incur additional memory
pressure particularly when the history contains lots of merges from
long-diverged branches. In practice, this optimization appears to
behave quite benignly, and a viable strategy for limiting the total
amount of cached blobs in a useful manner seems rather hard to
implement. In addition, calling git-blame with -C leads to similar
memory retention patterns.
---
builtin/blame.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/builtin/blame.c b/builtin/blame.c
index 21f42b0..2596fbc 100644
--- a/builtin/blame.c
+++ b/builtin/blame.c
@@ -1556,7 +1556,8 @@ finish:
}
for (i = 0; i < num_sg; i++) {
if (sg_origin[i]) {
- drop_origin_blob(sg_origin[i]);
+ if (!sg_origin[i]->suspects)
+ drop_origin_blob(sg_origin[i]);
origin_decref(sg_origin[i]);
}
}
--
2.7.4
--
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: 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 large files. As working on free software is his sole >> source of income, please consider contributing to his remuneration >> if you find this kind of improvements useful. >> >> Thank you very much for this heads-up. > > Do you have a link to where people can go to donate/contribute? I > searched around a bit but couldn't find anything. My Email address is linked at PayPal. However, it's the more affordable option in the Euro zone (which most definitely does not include GB) to ask me for my bank account data: SEPA-region transfers are by EU law required not to differentiate between in-country or cross-country payments. I don't maintain a personal home page or a blog or similar, so there is really not much to point people to than my Email address. -- 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: Draft of Git Rev News edition 1
Christian Couder writes: > Hi, > > A draft of Git Rev News edition 1 is available here: > > https://github.com/git/git.github.io/blob/master/rev_news/draft/edition-1.md > > Everyone is welcome to contribute in any section either by editing the > above page on GitHub and 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 vast gain in performance with complex histories and large files. As working on free software is his sole source of income, please consider contributing to his remuneration if you find this kind of improvements useful. Thank you very much for this heads-up. However, I'd replace "previously" with "as of version 2.1.0". That's where the big difference is, so if people actually are impacted they'll know whether and what to benchmark and/or upgrade. -- 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: Promoting Git developers
Christian Couder writes: > On Sun, Mar 15, 2015 at 11:43 PM, Randall S. Becker > wrote: >>> On March 15, 2015 6:19 PM Christian Couder wrote: >> >>> Just one suggestion on the name and half a comment. >>> >>> How would "Git Review" (or "Git Monthly Review", or replace your favourite >>> "how-often-per-period-ly" in its name) sound? I meant it to sound similar >> to >>> academic journals that summarize and review contemporary works in the >> field >>> and keeps your original "pun" about our culture around "patch reviews". > > I would be ok for that but there is already this Gerrit related command: > > http://www.mediawiki.org/wiki/Gerrit/git-review > > Maybe I can just use "Git Rev", but it doesn't tell that it 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
Jeff King writes: > If people don't like git-scm.com and want to have an alternate site, I think that's the basic problem here. As long as people want to _have_ an alternate site rather than want to _write_ and _maintain_ an alternate site, any site will only be as representative of the Git community as the person(s) working on the site feel they are representative of the Git community. Scott says that he tried his best to create a neutral site, and that's what the site is. When a guardian votes instead of his ward in an election, he might vote different from his own vote in order to better reflect the interest of his ward. It may still well be different from who the ward would have voted for. For me, the Git-scm site has the air of a third-party site, and that's what it is essentially. I don't see that Scott could do any better here when basically left on his own and it seems pointless to complain to him about that. That is one case where the "central repository" approach has at least some psychological advantage over the "one personal repository is what is considered canonical" approach used by the Linux kernel, Git, the Git-scm site and possibly by most of the GitHub hosted projects: with a central repository, there is somewhat less of a feeling that one person "owns" the project (even admin rights come into play only for exceptional circumstances rather than everyday work). Possibly that makes 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 love to have Emacs on that page, actually. If you guys want me >> to add that, I'm happy to. I didn't know they moved over, I thought >> they were still a bzr shop. > > I don't know who "you guys" is, but it would be my guess that > Stallman/FSF would not be enthused to see the Emacs logo added to that > particular list. > > Emacs used Bzr particularly to promote an alternative to Git more open > to the free software philosophy promoted by the FSF. Once Bzr > development became non-responsive and Canonical turned it more into a > Canonical-owned rather than a community project, it became sort of > pointless to stick with a technically less popular choice. > > So Emacs fairly recently switched to Git. I might add that the abysmal performance of git-blame on Emacs' src/xdisp.c was given as one fairly important argument against switching to Git, and in consequence I promised to take a look at it. Git runs about a factor of 4 faster on src/xdisp.c now, but I can safely say that I consider letting myself get involved here a rather expensive mistake. Live and learn. -- 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
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 want me > to add that, I'm happy to. I didn't know they moved over, I thought > they were still a bzr shop. I don't know who "you guys" is, but it would be my guess that Stallman/FSF would not be enthused to see the Emacs logo added to that particular list. Emacs used Bzr particularly to promote an alternative to Git more open to the free software philosophy promoted by the FSF. Once Bzr development became non-responsive and Canonical turned it more into a Canonical-owned rather than a community project, it became sort of pointless to stick with a technically less popular choice. So Emacs fairly recently switched to Git. So it's sort of a screaming and kicking endorsement. Some people would claim that those are the best, but it does not really fit well with the spirit of this front page. >> It might make sense to reduce this list just to "Projects" since >> those are actually more tangible and verifiable. Or scrap it >> altogether. > > Sorry, I disagree with this. I think it's helpful for people to see > some important corporations that are using it, Where is the point if they don't see how or in what scale? > since many people coming to the page are doing research to figure out > if they want to switch to it in their companies. It also demonstrates > that these large companies are participating in the open source > community Uh no, it doesn't. "Uses $x" does not constitute participation. -- 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
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 looks a bit like a >>>> ProGit/Github promotion site. I don't have anything against either, and >>>> git-scm.com provides a lot of the information that users are looking >>>> for, and that are hard to find anywhere else; it's a landing page. It >>>> just does not look like a "project home". >>> >>> Yes, git-scm.com is a place to point people. >> >> It features "Companies & Projects Using Git" at the bottom. Not >> "supporting" but "using". >> >> Linux is point 10 on that list. The first 6 items are Google, facebook, >> Microsoft, Twitter, LinkedIn, and Netflix. >> >> Even for an OpenSource project that does not buy into the Free Software >> philosophy, that is a mostly 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 altogether. > > At the bottom of the git-scm.com page there is this blurb: > > This open sourced site is hosted on GitHub. > Patches, suggestions and comments are welcome > > And that text contains a link to the GitHub repository[1] where anyone > can propose modifications to the page. Unfortunately I don't know of > anyone paying out contribution stipends for content changes made to > git-scm.com. Yeah, thanks for the cheap shot. I already understood that category B is subject to contempt. Congrats on being category A or C. > [1] https://github.com/git/git-scm.com/blob/master/README.md#contributing Turns out that "anyone" is actually "anyone accepting the conditions for a GitHub account": If you wish to contribute to this website, please fork it on GitHub, push your change to a named branch, then send a pull request. I've read the rather longish Terms&Conditions of GitHub and found myself unwilling to agree to them. Which does not mean that changing the ways of contributing to the Git website to accommodate me would make any sense since obviously I don't have a clue what a member of the "Git community" should be proud of and ashamed of and thus would be unable to make a meaningful proposal anyway even if I were into website programming. -- 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
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 looks a bit like a >> ProGit/Github promotion site. I don't have anything against either, and >> git-scm.com provides a lot of the information that users are looking >> for, and that are hard to find anywhere else; it's a landing page. It >> just does not look like a "project home". > > Yes, git-scm.com is a place to point people. It features "Companies & Projects Using Git" at the bottom. Not "supporting" but "using". Linux is point 10 on that list. The first 6 items are Google, facebook, Microsoft, Twitter, LinkedIn, and Netflix. Even for an OpenSource project that does not buy into the Free Software philosophy, that is a mostly 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 altogether. -- 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: 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 freelancers doing Git development. >> >> My opinion on this is that the Git community has not been good >> especially lately at promoting its own developers. >> > > I guess we have at least 3 kinds of people here: > > A) Paid to do Git development, at least as part of their job. > B) Freelancers who don't get paid directly for "doing git" but hope to > profit from their git efforts directly or indirectly. > C) Doing it in their freetime (or as minor, inofficial part of their > non-programming job). > > I'm in camp C and honestly wasn't aware of camp B until now. My guess is that camp B is dead and intentionally so. For the rationale, see for example http://article.gmane.org/gmane.comp.version-control.git/247165/>. It is considered tasteless to even mention camp B. -- 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 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.
>>
>> What may have happened is that the repository recently got repacked
>> 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.
>>
> That is possible - well, not recently-recently, but I might have
> repacked my repo of buildscripts some time last year. Running
> ls -al .git
> in that repository gives me:
> drwxr-xr-x 8 ken 100 4096 Mar 8 16:08 .
> drwxr-xr-x 48 ken 100 4096 Mar 8 03:05 ..
> -rw-r--r-- 1 ken 100220 May 12 2014 BRANCH_DESCRIPTION
> drwxr-xr-x 2 ken 100 4096 Apr 13 2010 branches
> -rw-r--r-- 1 ken 100470 Mar 8 16:08 COMMIT_EDITMSG
> -rw-r--r-- 1 ken 100566 May 17 2014 config
> -rw-r--r-- 1 ken 100 73 May 1 2010 description
> -rw-r--r-- 1 ken 100 196439 Sep 17 21:56 gitk.cache
> -rw-rw-rw- 1 ken 100 29 Feb 8 22:19 HEAD
> drwxr-xr-x 2 ken 100 4096 May 1 2010 hooks
> -rw-r--r-- 1 ken 100 218255 Mar 8 16:07 index
> drwxr-xr-x 2 ken 100 4096 Sep 16 2013 info
> drwxr-xr-x 3 ken 100 4096 Sep 16 2013 logs
> drwxr-xr-x 260 ken 100 4096 Nov 12 2013 objects
> -rw-r--r-- 1 ken 100 41 Nov 11 06:05 ORIG_HEAD
> -rw-r--r-- 1 ken 100 1879 Sep 16 2013 packed-refs
> drwxr-xr-x 5 ken 100 4096 May 20 2014 refs
> -rw-r--r-- 1 ken 100 41 Dec 7 2010 RENAMED-REF
>
> Running git blame on a script which dates back to when the repo was
> created takes between 5 and 6 seconds to show the first screen,
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 not to be all that excessive for extracting more
than 5 years of a file's history.
--
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 very slow ?
Kevin D writes: > On Sat, Mar 07, 2015 at 01:30:07AM +, Ken Moffat wrote: >> Hi, please CC me if that is not your usual fashion, because I am not >> subscribed. >> >> I use git for my build scripts - those are accessed over nfs. Since >> I started using 2.1 and later (I don't think I used 2.0) commands >> such as 'commit' take a long time before anything happens. I >> assumed that the newer version meant this would take longer. >> >> But today^Wyesterday I was bisecting the kernel on a local >> filesystem - even when the number of revisions left to test was in >> the single digits, git bisect took a long time to decide which >> revision should be the next one to test. The filesystems are ext4. >> Is this sort of delay normal now? >> >> What really prompted me to ask is that I ran git blame on a script, >> to see when I made a particular change so that I could add that >> information to a ticket, and almost gave up waiting because it felt >> as if it was taking for ever. >> > > What kind of repository are we talking about? How many files, how big? > Git should not have become significantly slower recently. 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. What may have happened is that the repository recently got repacked 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 inferior is not conducive for a cooperative >>>> work atmosphere. >>> >>> Yes, but I do not think anybody did any such thing. >> >> "Of course, I am hoping that all the mentors are doing GSoC not for >> money but out of love of our software and our community," >> >> Huh. > > I did not intend any moral judgement in that statement, but after > re-reading it, I would say that "not for money" would have been > better phrased as "not only for money". Shrug. "love of our software and our community" was not sufficient in the thread started at <http://permalink.gmane.org/gmane.comp.version-control.git/255385> to make anybody do a one-character change spelled out explicitly even after the user, presumably a "community" member, begged again. Presumably a case of "Somebody else's problem". The reality is that developers work mostly for their own motivations, what Linus Torvalds describes as "scratching your own itch". And not everybody is in the situation where he is able to scratch his own itch. Sometimes there are good scratchers whose main itch is that everybody is of the opinion they are so excellent at scratching people's itches that they have the moral obligation to not do anything else. Like eating. Or sleeping. Or having a life. The non-glorious part of maintaining a flea circus where you can say "jump" and marvel at inhuman feats of strength is feeding time. You can't just hope to shake down some passing dog whenever it is performance time: even if that works, some of your actors may be too starved to perform well. Well, a flea circus is probably a bad analogy when talking about scratching one's own itches. But it's easy to state that one wants people to work for love when oneself is getting paid for 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: 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 inferior is not conducive for a cooperative >>>> work atmosphere. >>> >>> Yes, but I do not think anybody did any such thing. >> >> "Of course, I am hoping that all the mentors are doing GSoC not for >> money but out of love of our software and our community," >> >> Huh. > > I did not intend any moral judgement in that statement, but after > re-reading it, I would say that "not for money" would have been > better phrased as "not only for money". > > Let me clarify. > > There _could_ be a mentor who hates Git the software and Git the > community, who wants to mentor students only for the mentorship > stipend. Uh, mentors don't rise from beneath the Earth. They are project members. Do you want to suggest that you suspect those contributors to have worked on Git, which they hate with a vengeance, only so that they could cash in on GSoC? You know the kind of sum we are talking about here, right? Pocketing that makes sense only if you feel _indifferent_ about anything but money and are not planning on investing significant amount of work. It's too little to do something you actually hate. > I do not want to see such mentors. I would imagine that such a person > surely can find something else that is more enjoyable and do the > mentoring there for money, if competent enough to mentor others. And > that would be good for everybody. I think Google would prefer a mentor who takes the money and does the job to someone who hands the money on to some more generic Git account out of love for the project and community and does not find the time for actually mentoring his student, but feels sort of ok about it because he did not in the end take the money. Someone who hates Git will at least have a solid idea about where Git is most in need of improvement... No, I'm not volunteering. I am merely sick of the income-bashing and consider it not doing a useful job for Git or other free software. Particularly not in connection with a program like Google Summer of Code which is _designed_ to let money make a difference. -- 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: > >> 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 such thing. "Of course, I am hoping that all the mentors are doing GSoC not for money but out of love of our software and our community," Huh. -- 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
Bashing freelancers (was: [ANNOUNCE] Git Merge Contributors Summit, April 8th, Paris)
Junio C Hamano writes: > Of course, I am hoping that all the mentors are doing GSoC not for > money but out of love of our software and our community, At some point of time I think it may be worth reevaluating the toxic atmosphere against freelancers doing Git development. There is nothing wrong with not having a fixed employment paying the rent. And there is nothing to be gained by going out of one's way vilifying those who cannot afford to work for free. 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. I still have patches sitting in my repository that I could not bring myself to finish for contribution after the shameful treatment of my months of git-blame work where I was credited in passing with a wrong name in one "What's cooking", and 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 "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: weird behaviour in git
Thomas Klausner writes: > I've played around with git and found that 'git mv' does not honor > what I tell it to do: > > wiz@yt:~> mkdir a > wiz@yt:~> cd a > wiz@yt:~/a> git init . > Initialized empty Git repository in /home/wiz/a/.git/ > wiz@yt:~/a> touch a > wiz@yt:~/a> git add a > wiz@yt:~/a> git commit -m 'add a' > [master (root-commit) 99d0ee7] add a > 1 file changed, 0 insertions(+), 0 deletions(-) > create mode 100644 a > wiz@yt:~/a> git mv a b > wiz@yt:~/a> touch Makefile > wiz@yt:~/a> git add Makefile > wiz@yt:~/a> git commit > > > # Please enter the commit message for your changes. Lines starting > # with '#' will be ignored, and an empty message aborts the commit. > # On branch master > # Changes to be committed: > # renamed:a -> Makefile > # new file: b > # git mv was tasked with removing file a and creating file b with the same content and permissions. It did so successfully. "Changes to be committed" states an interpretation consistent with that. Now it is entirely silly in my book to describe files as "renamed" that are actually empty and thus do not contain a single common byte. I would call that change description a bug or at least a "misfeature". git mv, however, did exactly what it was tasked to do and could not possibly do anything better since Git does, by design, not ever track file operations. > This is reproducible for me with "git version 2.3.0" on > NetBSD-7.99.5/amd64. > > I guess this happens because the checksums of the files are the same > and 'Makefile' is earlier when sorting, but since I explicitly told > "git mv" old and new name, I think that's a bug nevertheless. No. Git mv is just a convenience command for deleting one file and creating another one with the same contents. Git has no concept of file renames in its repository, so git mv cannot record anything there that 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?
Maybe it would be worthwhile to explore GUB http://www.lilypond.org/gub> for rolling the Windows (and possibly Cygwin as well, but then they tend to do their own) release/installer for Git? LilyPond has a similar mixture of scripting engines and target-dependent bits-of-GNU that it packages into its installers (for GNU/Linux, FreeBSD, MacOSX on PowerPC as well as x86, Windows) using GUB, and as far as developers are concerned, the synchronized releases happen without any extra work and involvement just by letting the standard release scripts roll. Looking at http://lilypond.org/gub/applications>, there appears to be a Git recipe already, but it will likely not be an installed bundle including the necessary scripting engines (what's it? Tk, Perl, Bash/Dash, and similar?). So it might be worth figuring out what is needed for setting this up in order to have a run-and-forget 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
Linus Torvalds writes: > 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 '../../../../../include/dt-bindings' is invalid >> error: Bad exit status from /var/tmp/rpm-tmp.mWE3ZL (%prep) > > Ugh. I don't see anything we can do about this on the git side, and I > do kind of understand why 'patch' would be worried about '..' files. > In a perfect world, patch would parse the filename and see that it > stays within the directory structure of the project, but that is a > rather harder thing to do than just say "no dot-dot files". > > The short-term fix is likely to just use "git apply" instead of "patch". > > The long-term fix? I dunno. I don't see us not using symlinks, and a > quick check says that every *single* symlink we have in the 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* doing that. I consider it rather hard and error-prone and/or an attack vector to choose a course of action for ../ in connection with the -p option. -- 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-svn metadata commands performance issue
Eric Wong writes: > How big is the parent process which forks the git commands? On Linux at > least, fork() performance is negatively impacted by parent process > memory size. Huh. I thought with the advent of demand-paging, at the very least with copy-on-write, this was supposed to be sort of a non-issue. The old original UNIX version, in contrast, consisted of swapping out the current process without removing the in-memory copy. But since the in-memory copy then did the exec call and since usually the exec call was happy about every page of free memory (we _are_ talking 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
Patrick Donnelly writes: > Is there a way to reject pushes that change the history of > first-parents, caused by a "backwards" merge? To clarify by example > (using branches instead of separate repositories): > > Here the desired first parent (HEAD^) would be commit > 9cb303e2578af305d688abf62570ef31f3f113da. Unfortunately, the incorrect > merge reversed the line of parents. Is there a way to prevent this > from happening (via git-config) other than fixing the human? You'd have to do this in a push hook. Before pushing, Git does not really have a way 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. -- 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: Antw: Re: Enhancement Request: "locale" git option
"Ulrich Windl" writes: >>>> Ralf Thielow schrieb am 06.12.2014 um 20:28 in > Nachricht > : >> 2014-12-05 16:45 GMT+01:00 Torsten Bögershausen : >>> >>> I do not know who was first, and who came later, but >>> >> > <http://git-scm.com/book/de/v1/Git-Grundlagen-%C3%84nderungen-am-Repository-na > >> chverfolgen> >>> >>> uses "versioniert" as "tracked" >>> >>> >>> LANG=de_DE.UTF-8 git status >>> gives: >>> nichts zum Commit vorgemerkt, aber es gibt unbeobachtete Dateien (benutzen > >> Sie "git add" zum Beobachten) >>> >>> >>> Does it make sense to replace "beobachten" with "versionieren" ? >>> >> >> I think it makes sense. "versionieren" 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 "tracking"? What about "bekannt", "unbekannt" and "bekanntmachen"? "unregistriert", "registriert", "anmelden"? Or "ungemeldet", "angemeldet", "anmelden"? -- 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: [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 whether "a" is a proper ancestor of "b" or >> not. > > Hmph. > > $ git log --exit-code master..maint >/dev/null; echo $? > 0 > $ git log --exit-code maint..master >/dev/null; echo $? > 1 > > That is a strange way to use --exit-code. I suspect that if you did > this, you will get 0 from the log between HEAD~..HEAD > > $ git checkout master^0 > $ git commit --allow-empty -m empty > $ git log --exit-code HEAD~..HEAD > > even though HEAD~ is a proper ancestor of HEAD, so it is not giving > us anything useful. Isn't it a mere artifact that "log" happens to > share the underlying machinery with "diff" that --exit-code shows a > non-zero exit when there is any single commit in the range that has > any change? Possibly: I haven't checked the underlying code for the details. At any rate, it is an option git log accepts for whatever reason. -- 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: [BUG] Documentation: git log: --exit-code undocumented?
Junio C Hamano writes: > Sergey Organov writes: > >> Hello, >> >> $ git help log | grep exit-code >>problems are found. Not compatible with --exit-code. >> $ >> >> What --exit-code does in "git log"? > > It doesn'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 -- 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: 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 time for another round of the world-famous "Captain Obvious > Quiz Game"! Yay! > > The questions these week are: > > (1) "If reality and documentation do not match, where is the bug?" > (a) Documentation is buggy > (b) Reality is buggy > > (2) "Where would you put the horse in relationship to a horse-drawn > carriage?" > (a) in front > (b) in the carriage You are aware that a buggy _is_ a horse-drawn carriage? -- Captain Facepalm -- 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 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 defaulting the missing rev to HEAD. You > can be a bit more explicit in the middle, i.e. instead of asking > "Which are branches that already has been merged in --verbose?", you > can ask "branch --merged HEAD --verbose", meaning "What are branhes > that already has been merged in HEAD, please give me a verbose > answer?" perhaps? This gives the same result as git branch --verbose --merged namely _only_ listing the current branch verbosely. Use of --verbose kills any effect of --merged: instead of branches merged to the named branch (or to the default of HEAD), _only_ the named branch (or the default of HEAD) gets listed. So no. -- 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
git branch --merged and git branch --verbose do not combine
dak@lola:/usr/local/tmp/lilypond$ ../git/git branch --merged --verbose fatal: malformed object name --verbose dak@lola:/usr/local/tmp/lilypond$ ../git/git branch --verbose --merged * (detached from 5b2267a) 1c23f39 Merge branch 'issue4097' into HEAD issue3468cf033e Issue 346: monochord issues dak@lola:/usr/local/tmp/lilypond$ ../git/git branch --merged * (detached from 5b2267a) issue346 issue3855 issue4030 issue4083 issue4092 issue4096 issue4097 removelyr test-master test-staging So depending on the order of --verbose and --merged, one 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: 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: AW: Understanding behavior of git blame -M
"Sokolov, Konstantin (ext)" writes: > Hi David, > > thank you very much for the exhaustive answer. The keyword "hunk" made > me try a little bit more. So I realized that -M works as expected when > at least three lines are moved. > > From your answer I discern 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
"Sokolov, Konstantin (ext)" writes: > Hi Folks, > > I'm trying to understand the behavior of git blame -M and find that > the actual results differ from what I understood from the > documentation. I've already asked longer time ago on stackoverflow and > on the user mailing list without any satisfactory results. So here is > the example: > > Initial content of file.txt (2cd9f7f) > > A > B > 2 > D > E > G > F > > Move line B to the middle (d4bbd97e): > > A > 2 > D > B > E > G > F > >>git blame -s -n -f -w -M20 file.txt > ^2cd9f7f 1 1) A > ^2cd9f7f 3 2) 2 > ^2cd9f7f 4 3) D > d4bbd97e 4 4) B > ^2cd9f7f 5 5) E > ^2cd9f7f 6 6) G > ^2cd9f7f 7 7) F > > I wonder, why line B is not recognized as moved. According to the > documentation, I would expect git blame to report that it originates > from line 2 in revision 2cd9f7f. Can anybody explain the behavior? Someone had reasons. diff_hunks in builtin/blame.c is once called with 0 as third argument, once with 1. Change the latter call to using 0 as well and you get your expected result: dak@lola:/tmp/test$ /usr/local/tmp/git/git blame -s -n -f -w -M20 file.txt ^2cab496 file.txt 1 1) A ^2cab496 file.txt 3 2) 2 ^2cab496 file.txt 4 3) D ^2cab496 file.txt 2 4) B ^2cab496 file.txt 5 5) E ^2cab496 file.txt 6 6) G ^2cab496 file.txt 7 7) F The function diff_hunks is a wrapper for the diff engine. Putting the context length explicitly into this wrapper (rather than not passing an argument and just setting the context length to zero anyway in the function) clearly indicates that somebody _wanted_ it called with different values. There is no documentation or rationale in the file _why_ as far as I remember. Maybe it can crash or end up in an infinite loop. Maybe it could do so at one point of time but no longer does. Maybe Git is just a puzzle 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
Jeff King writes: > As Junio and I discussed earlier in [1], this series makes the > prio_queue struct stable with respect to object insertion (which in turn > means we can use it to replace commit_list in more places). I don't think that this makes sense in general since it assumes the appropriate fallback behavior to be FIFO. Depending on the use case, it might be the other way round, or something else (like topology-based) entirely. commit_list may be unsuitable as such for intermingled addition of unsorted and extraction of sorted elements (the general use case for priority queues). I see that struct commit already contains an integer field called "index", assigned sequentially, which might conceivably be used for tie-breaking independent from the actual prio_queue use at no extra cost. The resulting order will of course be somewhat arbitrary in a different 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" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Git reset --hard with staged changes
Pierre-François CLEMENT writes: > 2014-06-10 1:28 GMT+02:00 Junio C Hamano : >> Pierre-François CLEMENT writes: >> >>> Hm, I didn't think of "git apply --index"... Makes sense for this >>> special use, but I'm not sure about the other use cases. >> >> Try merging another branch that tracks a file your current branch >> does not know about and ending up with conflicts during that merge. >> Resetting the half-done result away must remove that new path from >> your working tree and the index. > > Hm I see. Even though the documentation doesn't make it very clear > about what happens to such files, it turns out the scenario we > stumbled upon seems to be the special use case after all. Thanks for > shedding some light on this :) I wonder why does git-reset's hard mode > not 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. -- 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 reset --hard with staged changes
Pierre-François CLEMENT writes: > Hi all, > > Someone pointed out on the "Git for human beings" Google group > (https://groups.google.com/d/topic/git-users/27_FxIV_100/discussion) > that using git-reset's hard mode when having staged untracked files > simply deletes them from the working dir. > > Since git-reset specifically doesn't touch untracked files, one could > expect having staged untracked files reset to their previous > "untracked" state rather than being deleted. > > Could this be a bug or a missing feature? Or if it isn't, can someone > explain what we got wrong? git reset --keep maybe? In a work dir and index without modifications, I expect git apply --index ... git reset --hard to remove any files that git apply created. It would not do so using your proposal. I agree that it seems a bit of 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)
Junio C Hamano writes: > "git blame" has been optimized greatly by reorganising the data > structure that is used to keep track of the work to be done, thanks > to David Karstrup . I guess that "reorganising the data structure" for months is not worth the trouble 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 message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] t9001: avoid not portable '\n' with sed
Junio C Hamano writes: > Torsten Bögershausen writes: > >> t9001 used a '\n' in a sed expression to split one line into two lines. >> Some versions of sed simply ignore the '\' before the 'n', treating >> '\n' as 'n'. >> >> As the test already requires perl as a prerequisite, use perl instead of sed. >> >> Signed-off-by: Torsten Bögershausen >> --- > > Hmph. I read this in > pubs.opengroup.org/onlinepubs/9699919799/utilities/sed.html > > The escape sequence '\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 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] pack-objects: use free()+xcalloc() instead of xrealloc()+memset()
Jeff King writes: > On Sun, Jun 01, 2014 at 01:07:21PM +0200, René Scharfe wrote: > >> Whenever the hash table becomes too small then its size is increased, >> the original part (and the added space) is zerod out using memset(), >> and the table is rebuilt from scratch. >> >> Simplify this proceess by returning the old memory using free() and >> allocating the new buffer using xcalloc(), which already clears the >> buffer for us. That way we avoid copying the old hash table contents >> needlessly inside xrealloc(). >> >> While at it, use the first array member with sizeof instead of a >> specific type. The old code used uint32_t and int, while index is >> actually an array of int32_t. Their sizes are the same basically >> everywhere, so it's not actually a problem, but the new code is >> cleaner and doesn't have to be touched should the type be changed. >> >> Signed-off-by: Rene Scharfe > > Looks good to me. > > BTW, the code does git-blame to Vicent's 2834bc2 (which I also worked > on), but actually originated in 7a979d9 (Thin pack - create 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. Without -M, "too much refactoring" for git-blame may just be moving a function to a different place in the same file. -- 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
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 and have few recipients while >> longer threads, due to the list policy of adding every participants to >> the Cc, will tend to have more recipients. > > AFAIK, vger does not do anything like this. They block HTML, messages > lacking a message-id, messages over 100K, and certain taboo phrases: > > http://vger.kernel.org/majordomo-info.html#taboo > > And anyway, I do not think vger is responsible here. The messages were > delivered through the list, and other archives have them. This looks > like a gmane problem. I am reading more than one list through Gmane/nntp, and in the last years it was not infrequent that delivery paused for even days and/or spurious old messages from the last day or even more were getting redelivered. > According to gmane.org, their admins will look manually at messages > flagged as spam, but I find it unlikely that they flagged several days > worth of git traffic (and when they do, I think they cross-post them > to a spam group in NNTP, and the messages do not seem to be marked as > such). So I think this really is just a bug. Quite so. In particular when other mirrors got the messages timely. -- 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
Felipe Contreras writes: > Jeff King wrote: >> On Wed, May 28, 2014 at 06:17:25PM -0500, Felipe Contreras wrote: >> >> > This is the last mail I sent to you, because you ignore them anyway, and >> > remove them from the mailing list. >> > [...] >> > [2], a mail you conveniently removed from the tracked record. >> > [...] >> > You also conveniently removed this mail from the archives. >> >> I see you already noticed the changes in v2.0, but I wanted to address >> these points, because I consider silent censorship to be a serious >> accusation. > > Yes, I also think silent censorship is a very seriours matter, and I was > very dissapointed that this mailing list would engage in that. > >> I've reported the bug to gmane.discuss (no link yet, as I'm waiting >> for the message to go through, but it is not a high traffic group, so >> it should be easy to find the thread once it is there). > > Thanks. At first I thought that was the reason, but then I noticed it > was always my mails that seemed to get this "bug", so I decided it was > too much of a coincidence. 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 and have few recipients while longer threads, due to the list policy of adding every participants to the Cc, will tend to have more recipients. So there may a bias against long-running threads with multiple participants with regard to timely delivery. And frankly, if I were a list moderator and software asked me through this sort of coincidence whether a mail should be delivered or 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
Jeff King writes: > On Wed, May 28, 2014 at 06:17:25PM -0500, Felipe Contreras wrote: > >> This is the last mail I sent to you, because you ignore them anyway, and >> remove them from the mailing list. >> [...] >> [2], a mail you conveniently removed from the tracked record. >> [...] >> You also conveniently removed this mail from the archives. > > I see you already noticed the changes in v2.0, but I wanted to address > these points, because I consider silent censorship to be a serious > accusation. > > I do not think Junio or anyone else has the technical ability to remove > messages from the archive. You can post self-destructing messages by adding X-no-archive: yes if I am not mistaken. But that only concerns stuff you post yourself. > There is not one archive, but rather several that get messages > straight from vger.kernel.org and keep their own database (e.g., > gmane, marc, spinics, nabble). Frankly, I find it weird that vger.kernel.org does not have an archive of its own. But yes, that makes it unlikely that silent censorship is much of a thing. A list moderator may put a particular 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 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/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)
>>>> {
>>>> struct itimerval v = {{0,},};
>>>> +struct sigaction sa;
>>>> +
>>>> +memset(&sa, 0, sizeof(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 look at the initialization of v in the context immediately above
>> the new code, it would appear that somebody already revisited this
>> policy.
>
> Huh, the initialization of v doesn't use C99-features...?
Well, for me anything post-K&R apparently is C99.
Cf
http://computer-programming-forum.com/47-c-language/859a1b6693a0ddc5.htm>
I have to admit that gcc -c -ansi -std=c89 -pedantic does not complain,
so that makes it quite probable that I was erring somewhat on the side
of the ancient ones and zeros.
--
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/5] progress.c: replace signal() with sigaction()
Chris Packham writes:
> On 28/05/14 18:14, Jeremiah Mahler wrote:
>> From signal(2)
>>
>> The behavior of signal() varies across UNIX versions, and has also var‐
>> ied historically across different versions of Linux. Avoid its use:
>> use sigaction(2) instead. See Portability below.
>
> Minor nit. The last sentence applies to the man page you're quoting and
> doesn't really make sense when viewed in the context of this commit
> message. Same applies to other patches in this series.
>
>>
>> Replaced signal() with sigaction() in progress.c
>>
>> Signed-off-by: Jeremiah Mahler
>> ---
>> progress.c | 6 +-
>> 1 file changed, 5 insertions(+), 1 deletion(-)
>>
>> diff --git a/progress.c b/progress.c
>> index 261314e..24df263 100644
>> --- a/progress.c
>> +++ b/progress.c
>> @@ -66,8 +66,12 @@ static void set_progress_signal(void)
>> static void clear_progress_signal(void)
>> {
>> struct itimerval v = {{0,},};
>> +struct sigaction sa;
>> +
>> +memset(&sa, 0, sizeof(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 look at the initialization of v in the context immediately above
the new code, it would appear that somebody already revisited this
policy.
--
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 v3 2/5] commit test: Change $PWD to $(pwd)
Johannes Sixt writes:
> That said, it is not wrong to use $(pwd) with test_set_editor, it's just
> unnecessarily slow.
Any shell that knows $(...) is pretty sure to have pwd as a built-in.
I don't think Git will run on those kind of ancient shells reverting to
/bin/pwd here.
The autoconf manual (info "(autoconf) Limitations of Builtins") states
'pwd'
With modern shells, plain 'pwd' outputs a "logical" directory name,
some of whose components may be symbolic links. These directory
names are in contrast to "physical" directory names, whose
components are all directories.
Posix 1003.1-2001 requires that 'pwd' must support the '-L'
("logical") and '-P' ("physical") options, with '-L' being the
default. However, traditional shells do not support these options,
and their 'pwd' command has the '-P' behavior.
Portable scripts should assume neither option is supported, and
should assume neither behavior is the default. Also, on many hosts
'/bin/pwd' is equivalent to 'pwd -P', but Posix does not require
this behavior and portable scripts should not rely on it.
Typically it's best to use plain 'pwd'. On modern hosts this
outputs logical directory names, which have the following
advantages:
* Logical names are what the user specified.
* Physical names may not be portable from one installation host
to another due to network file system gymnastics.
* On modern hosts 'pwd -P' may fail due to lack of permissions
to some parent directory, but plain 'pwd' cannot fail for this
reason.
Also please see the discussion of the 'cd' command.
So $PWD is pretty much guaranteed to be the same as $(pwd) and pretty
much guaranteed to _not_ be "unnecessarily slow" when not run in an
inner loop.
However, looking at (info "(autoconf) Special Shell Variables") I see
'PWD'
Posix 1003.1-2001 requires that 'cd' and 'pwd' must update the
'PWD' environment variable to point to the logical name of the
current directory, but traditional shells do not support this.
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 >>>> -export TEST_DIRECTORY=$(pwd)/../../../t >>>> +TEST_DIRECTORY=$(pwd)/../../../t && export TEST_DIRECTORY >>> Minor remark: >>> Both commands should go on their own line, like this: >>> >>> TEST_DIRECTORY=$(pwd)/../../../t && >>> export TEST_DIRECTORY >>> >>> >>> And, unrelated to this patch, >>> there seem to be a lot of && missing in git-remote-testgit.sh. >> >> I have a hard time taking the above && seriously. pwd is a shell >> builtin (when we are not talking about Version 3 UNIX or something) that >> can hardly fail. And when your shell does not support assignment to a >> shell variable, you'll have a hard time getting the shell script to run. > > The && after an assignment makes a big difference when the assignment is > part of an && chain. This is *very* common in our test suite, as you know. > > People tend to copy-and-paste. And then it is better to provide a more > universally applicable precedent. Copy-and-paste will not magically add the second && that would be required for that usage, and the one in the line above might mislead you into thinking that the problem "has been dealt with already". So I'm not convinced that using && outside of a preexisting && chain makes any sense in this context. -- 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
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
>> -export TEST_DIRECTORY=$(pwd)/../../../t
>> +TEST_DIRECTORY=$(pwd)/../../../t && export TEST_DIRECTORY
> Minor remark:
> Both commands should go on their own line, like this:
>
> TEST_DIRECTORY=$(pwd)/../../../t &&
> export TEST_DIRECTORY
>
>
> And, unrelated to this patch,
> there seem to be a lot of && missing in git-remote-testgit.sh.
I have a hard time taking the above && seriously. pwd is a shell
builtin (when we are not talking about Version 3 UNIX or something) that
can hardly fail. And when your shell does not support assignment to a
shell variable, you'll have a hard time getting the shell script to run.
That's stuff of the
if (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
Felipe Contreras writes: > Junio C Hamano wrote: > >> * The remote-helper interface to fast-import/fast-export via the >>transport-helper has been tightened to avoid leaving the import >>marks file from a failed/crashed run, as such a file that is out-of- >>sync with reality confuses a later invocation of itself. > > Really? Where are the patches for that? The following seems related: commit 10e1feebb454d99eb6644cc53b94255f40e6fe9c Author: Junio C Hamano Date: Wed May 14 12:06:35 2014 -0700 Revert "Merge branch 'fc/transport-helper-sync-error-fix'" This reverts commit d508e4a8e2391ae2596403b6478d01cf3d5f928f, reversing changes made to e42552135a2a396f37053a89f44952ea907870b2. The author of the original topic says he broke the upcoming 2.0 release with something that relates to "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" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Fwd: [Bug] - Processing commit message after amend
Michal Stasa writes: > I have stumbled on a weird bug. At work, we use redmine as an issue > tracker and its task are marked by a number starting with #. When I > commit some work and write #1234 in the message, it works. However, > later on when I remember that I forgot to add some files and amend the > commit, vim appears and I cannot perform the commit because the > message starts with # which is a comment in vim and thus I get an > error that my commit message is empty. > > Steps to reproduce: > 1) commit a file > git commit File1.txt -m "#1234 documentation added" > > 2) amend previous commit > git commit File2.txt -- amend > > 3) go for :wq right away git commit --amend -C HEAD File2.txt should do the trick without starting the editor. > However, if you use amend and no edit option, it works > git commit --amend --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 "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
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 of your calm rational mails and ask him for his opinion. Did you do so? Why not? Are you so infallible in communication that a second opinion from someone you trust would be irrelevant? Or is there nobody you trust? > I've made my point, you are just talking nonsense. > > Every rational person on this list knows that if I wanted to, I could > be much more offsensive and insulting. It would not appear that there any rational persons on this list apart from you. Not that it matters. I think that all the other irrational people on this list are rather more interested in your potential of being less offensive and insulting. Once the cure is worse than the ailment, namely you cause fewer work to be done on Git by your presence than you can do yourself, because of you distracting others and/or making them leave, it does not matter whether it could be even worse. -- 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
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 friendly way & respond constructively), which we >>> discovered are both *essential* for contributing to git. >> >> I'm not entirely convinced of that: there is something akin to drop-dead >> gorgeous code: code that is so well done that it would not matter with >> regard to its maintenance whether or not its author dropped dead because >> it's both done well as well as documented in a manner where the original >> author could not offer significant additional help. > > I would have to say that you are living in a fantasy land. During > the entire life of Git, I do not think I ever saw such a code that > is perfect from the get-go and did not require any maintenance to > adjust to the changing time. You are attacking a straw man. "where the original author could not offer significant _additional_ help" does not at all equate "does not require any maintenance". -- 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
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 you are in control over how you react to his behavior? >> >> >> >> I feel that Felipe cannot control this (or decided not to), >> > >> > I am pretty much in control of my behavior. Those who know me >> > personally know that I *never* get angry. >> >> You are missing the point. The point is not what effect your behavior >> has on you but what it has on others. > > If me saying "I do not believe in God" has a negative effect on Mark, > your answer seems to be "do not tell Mark the truth". Shouting "your God is an imaginary shithead" every time you see Mark and asking everybody in the room "Isn't it right that Mark's God is an imaginary shithead? Can anybody here testify having seen him?" whenever anybody is there, and occasionally calling him and others on the phone when you have nothing else to do and tell him that you consider his God an imaginary shithead and him a gullible fool to believe otherwise... Do you really think that's the way you are going to earn people's respect? By prouding yourself on having seen through Mark's purported stupidity and pointing it out to everybody? > But if Mark was a member of an open source project, I do have an > option and I'd rather tell it like it is. And everybody else, of course, is wrong about it. And only you are right. All you need to do is to be as obnoxious as you can manage, and you'll win everyone over to your side. Don't kid yourself: you are doing this entire sad spectacle only to satisfy your own self-righteousness, just to be able to tell yourself "all those people working on Git with the exception of myself are pitiable fools and/or bad persons letting Junio pull the wool over their eyes". You've made your point. People don't agree with it. Repeating your point over and over will not change that. > If Mark has a problem with that, I can always avoid Mark, or just > leave the project (say if Mark was the maintainer). > > In both cases Mark is wrong. I do understand that most people would > rather comprimise their beliefs in order to win penguing points. I'm > not that way. No, you rather compromise your standing in order to win your beliefs. Take them. They are yours. Nobody else wants them. Even if there would have been merit in them originally, after revomiting them a dozen times on people's laps they just want the stench to go away. > If I can't speak my mind in an open source project where I'm > contributing my time *for free*, I do not want to be part of that > project. It's the project that's wrong, not me, and it's the project > that looses, not me. Well, you are a sore winner for sure. -- 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
Felipe Contreras writes: > Philippe Vaucher wrote: [...] >> > Do you feel Felipe is in control of what you label bad behavior? Do you >> > feel you are in control over how you react to his behavior? >> >> I feel that Felipe cannot control this (or decided not to), > > I am pretty much in control of my behavior. Those who know me > personally know that I *never* get angry. You are missing the point. The point is not what effect your behavior has on you but what it has on others. As you are unable to attribute feelings to others (like you appear unable to attribute reason to them), you are unable to control it. It's like repairing clockwork when your hands are numb and have never been otherwise. "When something does not work, apply extra force" does not work with clockwork. It does not work with people, either. > The problem is that what you label as "bad behavior" I do not. It does not matter what you or others want to label it. The effects are there anyway. > So if somebody convinced me that my behavior is indeed bad, I would > certainly change it, but I do not think it's "bad". 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 standing perfectly upright. -- 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
Philippe Vaucher writes: > I'm sorry that my words aren't clear enough for you to infer the point > I'm trying to make. Let's try something simpler: what I was saying is > that bad behavior will get you into trouble when contributing (and > thus it's important to behave nicely), where Felipe usualy says bad > behavior is irrelevant because only truth/quality is important. Do you feel Felipe is in control of what you label bad behavior? Do you feel you are in control over how you react to his behavior? > Yes it's unfortunate. The amount of talent in our societies that is > wasted because of communication problems is probably quite high. I > didn't find a way around "being social" in any human based community > yet, but if you have an idea please share. "being social" as an isolated feat is self-contradictory. The question is how to function in a particular social context. Stock answers apply to stock behaviors and are obviously most efficient to apply. Yesterday my girl friend bought back a mare she had sold two years ago because its owner did not manage to get along with it. It's a temperamental animal that learns and performs amazingly well for its comparatively compact build. But it's highest in rank "or else", and so in the end it got locked up in its stable box most of the time in order to avoid injuries to other horses. Now it's back here at the riding school, and there is little question that there will be some injuries before things settle down again even though most of the horses here know it already. > The only way I can see working is that for someone to act as a > mediator between the grumpy contributor and the community, but the > role of this person is not very pleasant. That or maybe have merges > done by some kind of robot with some AI about patch quality, but I > doubt it is technically feasible yet. Well, humans are more complex. There are no sure-fire recipes even for working with horses: some of them here have their separate paddocks because things would not settle down, some of them have standard conflicts, there are occasional injuries. The most important "standard recipe" is to make sure that the areas accessible to multiple horses do not have dead ends small enough for one horse to be able to corner another. That's not really fabulous but still pretty essential. Also enough room all around, obviously. Now humans are often held in conditions that are not species-appropriate and lead to a buildup of tension. Try finding an undisturbed spot in a typical city suitable for devouring a bread roll you hunted down without getting other predators eyeing your prey. Almost impossible. It may be that distributed version control systems offer more possibilities for organizing cooperation in a manner leaving graceful escape paths when things don't work out. It's not what 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
Philippe Vaucher writes: >> Basically you have to write in 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. > > My point was more that it's very hard to produce high quality commits > without social interaction with others explaining what you missed, > stuffs you overlooked, etc. You are overgeneralizing. You are assuming that it's easier for everybody to interact with humans rather than the Tao of Computing. > And there B issues quickly isolate you. Unless you were isolated to start with. > Anyway, I think we are speaking about different things. All I'm saying > is that humans are social creatures and that thinking you can > contribute to projects ran by humans without according a high > importance to social behaviors (like Felipe thinks) is not possible. You are assuming that "according a high importance to social behaviors" is all that it takes for anybody. Do you tell the beggar on the next street corner that "according a high importance to earning millions" would be all that would be necessary for him to afford anything to drink that he'd like? > Threads like this are proof that while technical quality might be > important for the short term, social behaviors is impossible to ignore > in the long term. Not really. > Both are very important to be an appreciated contributor, or to > contribute at all in the long term. The one thing where social behavior comes in is noticing who tends to be running free software projects. There is the mythical "scratching one's itch" theory, but it does not fit the bill. Those people who invest enough time into a project's progress to make a fundamental difference tend to do it at the cost of not having any worthwhile amount of time left actually _using_ the product. People mainly working on music software create very little music themselves, people mainly working on text processing software do not write many texts themselves, people writing high-performance operating systems have very little use for high-performance operating systems themselves. All of this might have started at one time as 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 and social skills tend to be packaged separately. So not everybody is gifted with being able to contribute _gracefully_. -- 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
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 friendly way & respond constructively), which we >>> discovered are both *essential* for contributing to git. >> >> I'm not entirely convinced of that: there is something akin to drop-dead >> gorgeous code: code that is so well done that it would not matter with >> regard to its maintenance whether or not its author dropped dead because >> it's both done well as well as documented in a manner where the original >> author could not offer significant additional help. > > I think this only means that you can get away with B issues if A's > quality is very very very high, which doens't happen very often. I would not exactly say "get away with B issues". It's like saying you can get away with looking like a sleazebag if you plan the time for a complete border search whenever traveling abroad. Of course that means that traveling into countries where "complete border search" might entail depriving you of your civic rights and locking you up for decades in a torture camp without due process is plainly not an option. But if you are honest: everybody has to be prepared for that. It's just less likely to occur in practice. Basically you have to write in 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 admit that it seems pretty unlikely by now that Felipe is trying to sneak in some NSA-written code without arousing people's suspicions. -- 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
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 friendly way & respond constructively), which we > discovered are both *essential* for contributing to git. I'm not entirely convinced of that: there is something akin to drop-dead gorgeous code: code that is so well done that it would not matter with regard to its maintenance whether or not its author dropped dead because it's both done well as well as documented in a manner where the original author could not offer significant additional help. Of course I am a major proponent of this view because of being myself somewhat differently endowed in the respective classes A and B, and so having at least some sort of exchange rate between the two can, however large the conversion 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?
Felipe Contreras writes: > Michael Haggerty wrote: >> On 05/12/2014 12:37 PM, Felipe Contreras wrote: >> > Michael Haggerty wrote: >> >> On 05/12/2014 01:34 AM, Felipe Contreras wrote: >> >>> Recently Junio said he was willing to hear the opinion of other people >> >>> regarding the move from contrib to the core[1]. This move is already >> >>> under way, but suddenly Junio changed his mind. >> >> >> >> I agree with Junio. There are good technical arguments for and against >> >> moving git-remote-hg out of contrib. >> > >> > Saying you agree with Junio is content-free. You have to say *why* you >> > agree. >> >> Actually, I don't have to, > > Then there's no point in reading what else you have to say. Whatever > reasons you might have to agree with Junio are known only to you, thus > your "agreement" is opaque and meaningless. Let me spell it out for you. Michael states "I agree with Junio. There are good technical arguments for and against moving git-remote-hg out of contrib." Since there are arguments for both sides, the decision boils down to a judgment call. Michael states that he condones the choice Junio made, based on the reasoning he gave. Does that mean that he examined the choice with equal detail and remembers every detail? No. In such a decision, both technical expertise as well as trust based on a past record factor in. >> > The quality of the subjproject has not been called into question, >> > stop taiting the discussion with red herrings. >> >> On the contrary. I just called the quality of the subproject into >> question, and I stated exactly which aspects of its quality I find to >> be inadequate in the text that you omitted from your response: > > I'll wait until somebody else calls into question the quality. > Preferably somebody who backs up his claims with evidence. The evidence for the toxicity of dealing with subprojects maintained by you is all over the mailing list. You are obviously blind to it yourself. Feel free to print out a few salient threads where you argue in favor of your points and ask someone you trust about his impression about how you come across. >> > Let's see how sincere you are in your sentiment. I'll reply to you >> > personally about the points that I consider to be red herrings and >> > ad hominem attacks so we don't taint the dicussion. If you don't >> > reply I'll know you were not being sincere. >> >> Jumping at your every demand is not a prerequisite for being sincere. > > I spent a lot of time writing that mail. Not sincere it is then. That kind of exchange is what you should show some of your personal friends and ask them whether it will likely lead to the desired understanding and ultimately reaction in the reader. Because that is what communication is about. Of course, one can try bypassing understanding and directly aim for a particular reaction: that is being manipulative. You are hardly in danger of being manipulative: that would require a 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 lead others to the same conclusion that you would draw, deal with the consequences. Throwing tantrums will only bias people against you when you have the next case to present. -- 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?
Michael Haggerty writes: > This email is written in sorrow, not in anger. Felipe, you seem to > have so much potential. If you would put as much effort in conducting > social interactions as you do in coding, [...] I think that's where you are mistaken. We are not talking about 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)
Junio C Hamano writes: > Is making that decision as the maintainer unilateral? Without addressing anything else, this point is vacuous. The whole point of begin "maintainer" is that you are the one making the decisions. Of course making a decision from the position of the one 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 of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
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 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 the >>> first place, but anyway). >> >> Yes, I was thinking mostly of "X..Y" types of ranges, which are probably >> the most common. I hadn't considered shallow repositories, and you can >> also hit the root commit as a boundary if you do not specify --root. >> >> I guess the question still in my mind is: what use does the identity of >> the boundary commit have? That is, whether you know ahead of time where >> the boundary is or not, is there ever a case where knowing its author >> and/or commit sha1 is a useful piece of information, as opposed to >> knowing that we hit a boundary at all? >> >> I could not think of one, but I may simply lack imagination. > > Well, the original message was triggered by the same "I could not > think of one" from me ;-). If it's the root commit, omitting all info may surprisingly make "who should I yell at" hard. I also am not sure about the implications in connection with --reverse. In connection with explicit -b however, I think it is nonsensical to blank out only the commit id. -- 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 23/25] contrib: remove 'hooks/multimail'
Michael Haggerty writes: > On 05/09/2014 02:58 AM, Felipe Contreras wrote: >> No tests. No chance of ever graduating. >> >> Already out-of-tree. >> >> Cc: Michael Haggerty >> Signed-off-by: Felipe Contreras > > Thank you for your input. > > git-multimail is maintained outside of the Git project and is only > distributed along with Git as a convenience to Git users. It does in > fact have a test suite, along with some other bits and bobs that are not > needed to use it, in the upstream repository at > > https://github.com/mhagger/git-multimail > > What's more, it has a maintainer who doesn't routinely insult other > people on the mailing list, conduct endless and pointless flame wars, > think that he is superior to everybody in sight, and throw temper > tantrums when his rudeness, 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 punishing lazy developers. >> > >> > No. >> >> So we have you on record that you would want to get rid of stuff >> _with_ a user base > > That's what Junio wants. Let's hear it from himself. Your track record summarizing other people's opinions to their satisfaction would suggest that he might have something to add to that. -- 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: > >> 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 user base and/or to punish lazy developers. That's not inconsistent with your other replies, but you probably did not express it as bluntly elsewhere. -- 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: > Erik Faye-Lund wrote: >> On Fri, May 9, 2014 at 10:14 AM, Felipe Contreras >> wrote: >> > If you want this script to remain in contrib, please: >> > >> > a) Write at least a few tests >> > b) Write some documentation >> > c) Explain why it cannot live outside the git.git repository like other >> > tools. [1][2][3] >> >> (Adding Marius, the original author to the CC-list) >> >> Uh, why is such a burden required all of a sudden? contrib/README >> mentions no such requirements, and the scripts have been accepted (and >> maintained) since. > > contrib/README mentions clearly the expectation that these scripts > eventually move to the core once they mature. This is never going to > happen for these. > > It also mentions that inactive ones would be proposed for removal, and > this one is clearly inactive. It has 9 commits (if you count the one > that changes the execution bit). > >> Besides, you say "No activity since 2010" - this is not the case, >> bc380fc is from November 2013. > > You think changing the execution bit of a file is considered "activity"? For an indication of "this software has actual users", it definitely would count as such, yes. Why would someone change the executable bit if it did not impact his usage of the software? The idea of removing software 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 "problem" in one fell swoop. -- 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: Output from "git blame A..B -- path" for the bottom commit is misleading
Jeff King writes: > I'd actually be inclined to say the opposite of what Junio is saying > there: that "-b" should blank the author field as well as the commit > sha1. I'd even go so far as to say that "-b" should probably be the > default when boundary commits are in use. I cannot think of a time when > I have found the boundary information useful, and the IMHO the output > above is less confusing than what we produce now. But I admit I haven't > thought very hard on it. Arguably if the user explicitly limited the range, he knows 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 the first place, but 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: Output from "git blame A..B -- path" for the bottom commit is misleading
Jeff King writes: > On Thu, May 08, 2014 at 01:52:38PM -0700, Junio C Hamano wrote: > >> ( 103) >> 7bbc458b (Kyle J. McKay 2014-04-22 04:16:22 -0700 104) test_expect_... >> ( 105) test... >> 7bbc458b (Kyle J. McKay 2014-04-22 04:16:22 -0700 106) git ... >> ( 107) test... >> >> which does away with the misleading information altogether. >> >> I myself is leaning towards the latter between the two, and not >> overriding "-b" but introducing another "cleanse the output of >> useless bottom information even more" option. > > Though I rarely use boundary commits, this one makes the most sense 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 overriding" part of the paragraph. -- 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: Output from "git blame A..B -- path" for the bottom commit is misleading
Junio C Hamano writes: > If you run > > $ git blame -L103,107 v2.0.0-rc0..v2.0.0-rc2 t/t9117-git-svn-init-clone.sh > > you will see something like this: > > ^cc29195 (Junio C Hamano 2014-04-18 11:21:43 -0700 103) > 7bbc458b (Kyle J. McKay 2014-04-22 04:16:22 -0700 104) test_expect_... > ^cc29195 (Junio C Hamano 2014-04-18 11:21:43 -0700 105) test... > 7bbc458b (Kyle J. McKay 2014-04-22 04:16:22 -0700 106) git ... > ^cc29195 (Junio C Hamano 2014-04-18 11:21:43 -0700 107) test... > > It is correct to attribute these lines that have not changed since > the bottom of the range (i.e. v2.0.0-rc0) to that commit, They are not attributed to that commit in particular. They are traced all the way up to that commit, so they are either from this commit or from an earlier one. > But I find it really misleading, as this is the true picture if we > dug to the bottom of the history: > > $ git blame -L103,107 v2.0.0-rc2 t/t9117-git-svn-init-clone.sh > f849bb6b (Johan Herland 2013-10-11 14:57:06 +0200 103) > 7bbc458b (Kyle J. McKay 2014-04-22 04:16:22 -0700 104) test_expect_... > f849bb6b (Johan Herland 2013-10-11 14:57:06 +0200 105) test ! -d p... > 7bbc458b (Kyle J. McKay 2014-04-22 04:16:22 -0700 106) git svn ini... > f849bb6b (Johan Herland 2013-10-11 14:57:06 +0200 107) test_must_f... So indeed, an earlier one. > I do not expect Johan's name to appear in the output for the first > one, because that would require us to dig deeper than the commit we > were told to stop at, but I am wondering if we can do better than the > existing "-b" option to reduce the confusion from the output. Do you mean "better than" or rather "better in the case where -b is given"? > The "-b" option blanks the commit object name, but still shows the > name and timestamp for the bottom commit: > > (Junio C Hamano 2014-04-18 11:21:43 -0700 103) > 7bbc458b (Kyle J. McKay 2014-04-22 04:16:22 -0700 104) test_expect_... > (Junio C Hamano 2014-04-18 11:21:43 -0700 105) test... > 7bbc458b (Kyle J. McKay 2014-04-22 04:16:22 -0700 106) git ... > (Junio C Hamano 2014-04-18 11:21:43 -0700 107) test... > > I am tempted to say "blame that is run without the --porcelain > option is a end-user facing Porcelain, and people should not be > reading its output in their scripts" and change the behaviour of the > "-b" option to instead show something like this instead: > > ^cc29195 (Unknown2014-04-18 11:21:43 -0700 103) > 7bbc458b (Kyle J. McKay 2014-04-22 04:16:22 -0700 104) test_expect_... > ^cc29195 (Unknown2014-04-18 11:21:43 -0700 105) test... > 7bbc458b (Kyle J. McKay 2014-04-22 04:16:22 -0700 106) git ... > ^cc29195 (Unknown2014-04-18 11:21:43 -0700 107) test... > > which shows the commit object name, its bottom-ness and the > timestamp, or even > > ( 103) > 7bbc458b (Kyle J. McKay 2014-04-22 04:16:22 -0700 104) test_expect_... > ( 105) test... > 7bbc458b (Kyle J. McKay 2014-04-22 04:16:22 -0700 106) git ... > ( 107) test... > > 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 information even more" option. One could use -b -b but frankly, where is the point? Name and date deliver no useful information when the commit is absent. -- 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: Is there any efficient way to track history of a piece of code?
Jianyu Zhan writes: > Usually, a trivial change(like coding style fix) may bury a > original change of the code, and thus git blame is of less > help. And to address this situation, I have to do like this: > >git blame -s REF^ > temp > > to dig into the history recursively by hand, to find out > the original change. > > Here, REF is commit-id that git blame reports. > > git log -L is a good alternative option, but sometimes it seems > too cubersome, as I care only one line of code. > > Is there any current solution or suggestion? git 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"
Jim Garrison writes: > During my initial self-education I came across the maxim "don't pull, > fetch+merge instead" and have been doing that. I think I followed > most of the "pull is (mostly) evil" discussion but one facet still > puzzles me: the idea that pull will do a merge "in the wrong > direction" sometimes. > > Do I understand correctly that this occurs only in the presence of > multiple remotes? > Can someone provide a simple example of a situation where pull would > do the "wrong" thing? That'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 executes git pull in order to merge the mainline from Y back into his private sidebranch." -- 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 v2] pager: remove 'S' from $LESS by default
Junio C Hamano writes: > I still find the output from "git blame" disturbing, though. The > first thing I do in "git blame" output is to scroll to the right in > order to identify the the area I am interested in, and this first > step is not negatively affected, because the right scrolled output > automatically wraps long lines. > > But my second step is to scroll back to the left edge to find the > commit object name and at that point, the new default output without > "S" gets somewhat annoying, because most of the output lines from > "git blame" are longer than my window width. git blame sucks in anything but fullscreen either way. It would help to display _only_ the source code and have the other info as mouse-over, but that's not something a pager can do. It is a pity that the content can be columnized 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 struct type is >> in existence. > > So you are not taking about struct object_id, and it's irrelevant to > this thread. > > This thread is about objects of type struct object_id, and their address > is always the same as the address of its first member. Nothing else is > relevant. Have it your way. I am too old for selective quotation games. -- 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] 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): >> >> time git blame -C src/xdisp.c >/dev/null > > ... > >> diff --git a/Documentation/config.txt b/Documentation/config.txt >> index 1932e9b..21a3c86 100644 >> --- a/Documentation/config.txt >> +++ b/Documentation/config.txt >> @@ -489,7 +489,7 @@ core.deltaBaseCacheLimit:: >> to avoid unpacking and decompressing frequently used base >> objects multiple times. >> + >> -Default is 16 MiB on all platforms. This should be reasonable >> +Default is 96 MiB on all platforms. This should be reasonable >> for all users/operating systems, except on the largest projects. >> You probably do not need to adjust this value. > > So emacs.git falls exactly into the "except on the largest projects" > part. git gc --aggressive has been used/recommended for _all_ projects regularly, leading to delta chains with a length of 250. So this delta chain size is not exceptional but will eventually occur in any archive that has been created and maintained according to the recommendations of Git's documentation (which recommends gc --aggressive every few hundreds of revisions). I was illustrating the effect on a file of size 1MB. That's not an egregiously large file either. 96MB is the point of diminuishing returns for this case which is _6_ times larger than the current default and _small_ in comparison with the memory installed on developer machines nowadays. Similar slowdowns occur with other examples. Git will with the current defaults accept files of 512Mb size into its compression scheme (and thus its core memory) before punting. The current delteBaseCacheLimit of 16Mb is rather ridiculous in particular with the pre-2.0 settings for gc --aggressive and causes serious performance degration. It was actually ridiculous even 10 years ago. > Would it make more sense to advise git devs to set this per repo > instead? The majority of (open source) repositories out there are > small if I'm not mistaken. Of those few big repos, we could have a > section listing all the tips and tricks to tune git. This is one of > them. Index v4 and sparse checkout are some other. In future, maybe > watchman support, split index and untracked cache as well. Shrug. The last version of the patch was refused because of wanting more evidence. I added the evidence. And I have it on record in the mailing list and can point to it when people ask me why Git is so slow for "git blame" in comparison to other version control systems in spite of my purporting to having improved it. I'm definitely not going to jump through any more hoops here. I don't see a point in this kind of spectacle. -- 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: > >> 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. > > This sentence doesn't make any sense. I disagree. > If you have an object of struct type 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 struct type is in existence. > then any pointer to the first member of the object can only be a > pointer to the one and same object. The case we are talking about is basically passing a pointer to some actual bonafide toplevel unsigned char [20] object to a routine that expects a pointer to a struct _only_ containing one such unsigned char [20] element. This is the situation we have to deal with if a caller has not been converted to using such a struct, but the called function does. More seriously, this is the situation we have to deal with when our SHA1 is actually embedded in some header or whatever else that is actually available only inside of a larger byte buffer. In that case, the standard does not permit us converting the address where that SHA1 is into a pointer to struct. It may well be that this will fall under the "let's ignore the standard and write for "sensible" compilers/architectures" dictum, but if it doesn't, it might be necessary to first copy the data to a struct before passing it to routines expecting a pointer to struct. -- 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: > Johannes Sixt writes: > >> Isn't internal padding only allowed between members to achieve correct >> alignment of later members, and at the end only sufficient padding so >> that members are aligned correctly when the struct is part of an array? > > The standard allows arbitrary internal padding, it doesn't have to be > minimal. What the standard does guarantee is that a pointer to a struct can be cast to a pointer to its first member and vice versa. 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. -- 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. >>> >>> This is guaranteed by the C standard, though. >> >> Any reference? > > §6.7.2.1#15 More like #13. I am pretty sure, however, that this has not always been the case. -- 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
[PATCH] Bump core.deltaBaseCacheLimit to 96m
The default of 16m causes serious thrashing for large delta chains combined with large files. Here are some benchmarks (pu variant of git blame): time git blame -C src/xdisp.c >/dev/null for a repository of Emacs repacked with git gc --aggressive (v1.9, resulting in a window size of 250) located on an SSD drive. The file in question has about 3 lines, 1Mb of size, and a history with about 2500 commits. 16m (previous default): real3m33.936s user2m15.396s sys 1m17.352s 32m: real3m1.319s user2m8.660s sys 0m51.904s 64m: real2m20.636s user1m55.780s 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 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/Documentation/config.txt b/Documentation/config.txt index 1932e9b..21a3c86 100644 --- a/Documentation/config.txt +++ b/Documentation/config.txt @@ -489,7 +489,7 @@ core.deltaBaseCacheLimit:: to avoid unpacking and decompressing frequently used base objects multiple times. + -Default is 16 MiB on all platforms. This should be reasonable +Default is 96 MiB on all platforms. This should be reasonable for all users/operating systems, except on the largest projects. You probably do not need to adjust this value. + diff --git a/environment.c b/environment.c index 5c4815d..37354c8 100644 --- a/environment.c +++ b/environment.c @@ -37,7 +37,7 @@ int core_compression_seen; int fsync_object_files; size_t packed_git_window_size = DEFAULT_PACKED_GIT_WINDOW_SIZE; size_t packed_git_limit = DEFAULT_PACKED_GIT_LIMIT; -size_t delta_base_cache_limit = 16 * 1024 * 1024; +size_t delta_base_cache_limit = 96 * 1024 * 1024; unsigned long big_file_threshold = 512 * 1024 * 1024; const char *pager_program; int pager_use_color = 1; -- 1.9.1 -- 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: > "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 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
James Denholm writes: > On 4 May 2014 19:51:09 GMT+10:00, Felipe Contreras > wrote: > >>But I'm not going to bother any more with you, you are just spreading >>lies and tainting the discussion. > > Well, maybe we'll see what other folks think. 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.
Johannes Sixt writes: > Am 04.05.2014 08:07, schrieb Michael Haggerty: >> On 05/03/2014 10:12 PM, brian m. carlson wrote: >>> Introduce a structure for object IDs. This allows us to obtain the benefits >>> of compile-time checking for misuse. The structure is expected to remain >>> the same size and have the same alignment requirements on all known >>> platforms, compared to the array of unsigned char. >> >> Please clarify whether you plan to rely on all platforms having "the >> same size and alignment constraints" for correctness, or whether that >> observation of the status quo is only meant to reassure us that this >> change won't cause memory to be wasted on padding. > > I think that a compiler that has different size and alignment > requirements for the proposed struct object_id and an unsigned > char[20] would, strictly speaking, not be a "C" compiler. Huh? How so? There is no warranty as far as I know that a structure with only a single member has the same size and alignment requirements as the single member would have. There is also no guarantee as far 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
James Denholm writes: > Felipe Contreras wrote: >>David Lang wrote: >>> the vast majority of people here do not take that attitude. >> >>It's actually the exact opposite. I don't care what is the track record >>of the people in the discussion. > > Ah, yes, like that discussion we once had where you totally > didn't run `git log | grep James Denholm` at one point to demonstrate > that I had not yet made any > contributions,instead of actually engaging in discussion. Oh, > wait. It's called an "ad hominem attack", and it's a very common and very effective rhetorical device. Cf http://thread.gmane.org/gmane.comp.version-control.git/246598/focus=247002> > The problem, though, is that time and time again you've > shown that you value your own arguments to the exclusion > of all others. 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 -- 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
Felipe Contreras writes: > David Lang wrote: >> note that this is one person taking the "I don't see any commits from >> you so your opinion doesn't count" attitude. > > Wrong. I said it doesn't count "for the project". There are a number of commits from me that actually count. A few old core performance ones might have actually have affected my carbon footprint noticeably. The one currently in pu will probably not be called often enough for that but will at least have practical consequences. > Do you honestly believe Junio cares about what some random guy on the > list thinks about default aliases? No. Putting aside my code contributions: Git is a comparatively small project, so if the main project you are working on with Git is Git, your experience is limited. So yes, input from people who are _not_ heavy Git developers is important, since the heavy Git developers do not get to see the heavy Git use cases a lot. > It's actually the exact opposite. I don't care what is the track > record of the people in the discussion. If their argument is good, > their argument is good. More like if they 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 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
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 another. Perhaps this is why there's so much disagreement >> > about what 'git pull' should do. >> >> Should a screwdriver be turning clockwise or counterclockwise by >> default? There are valid arguments for either. > > If you don't have anything to contribute don't disturb the people that > actually care and are trying to improve Git. Thanks. No need to expand on the welcoming atmosphere here. My heinous plot to subvert the quality of Git has already been thwarted by making sure that its "meritocracy" continues relying only on input from those with an independent income. I'm just sticking around until my current contributions move into master so that I can summarize the resulting low-hanging fruit that the meritorious can then pick at great fanfare. The sooner my work moves from pu into master, the sooner y'all be rid of 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: Pull is Mostly Evil
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 > another. Perhaps this is why there's so much disagreement about what > 'git pull' should 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 my needs, I rebase or merge. > > I wouldn't mind that, but I have a century of newbies who are used > to having other people's changes appear in their workspace without > any interaction. Teaching them the mainline thing (aka first-parent) > and the commands to properly merge&push is...tricky. > > And that goes for every user base, so some improvement would be > greatly appreciated. I've seen the proposals for "git update" and whatever. It's sort of like having an assembly line where there are separate automatic screw drivers for screwing and unscrewing. The latter are hard to find in the rare case you need them, with quite different handling and looks. This is modeled after the successful fastening model for nails, where hammer and pliers look and behave quite differently, so people are used to handle and arrange hammer and pliers on different racks and have different numbers for them. Since this model works well for nails, let's employ it for screws as well and call right-turning screwdrivers "hammers" and left-turning screwdrivers "pliers" and sort them accordingly in order to avoid confusion for beginners and help them learn to deal with screws properly and deftly. -- 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
Jeff King writes: > On Fri, May 02, 2014 at 02:11:05PM -0500, Felipe Contreras wrote: > >> Junio C Hamano wrote: >> > If we step back a bit, because we are forcing him to differentiate >> > these two pulls in his mental model anyway, perhaps it may help >> > people (both new and old) if we had a new command to make the >> > distinction stand out more. What if the command sequence were like >> > this instead? >> > >> > $ git checkout maint >> > $ git update [ origin maint ] >> > >> > $ git pull [--no-ff] developer-remote topic-branch >> > $ git push [ origin maint ] >> > >> > where the new command 'update' enforces the '--ff-only' update. And >> > then we would stop telling "'git pull' first" when a push does not >> > fast-forward. >> >> In addition to barf when it's not a fast-forward, such command can >> switch the parents, so it appears 'maint' was merged to 'origin/maint'. >> Many people have complained about this order. > > 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 the user explicitly turns on. A safety catch defaulting to a factory position of "off" is not going to stop inexperienced people from shooting themselves in the foot. -- 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
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's not fatal confusion, people have been using > it for years after all. It's one of the most frequent causes for educating newcomers what they have been doing wrong in the LilyPond project. Including the occasional blunder from experienced people who did not notice that they got a non-ff merge as a mergeday present. It's one of the main things putting new contributors on edge and causing anxiety about messing up again. -- 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/8] CodingGuidelines: typofix
Felipe Contreras writes: > Jeff King wrote: >> On Fri, May 02, 2014 at 11:31:10AM -0700, Junio C Hamano wrote: >> >> > But let's follow this one: >> > >> > http://www.google.com/trends/explore#q=judgement%20call%2C%20judgment%20call&cmpt=q >> > >> > 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, and the U.S. justice system rather supports the hyphenation judge- mental. -- 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
"W. Trevor King" writes: > On Fri, May 02, 2014 at 01:55:36PM -0500, Felipe Contreras wrote: >> W. Trevor King wrote: >> > On Thu, May 01, 2014 at 08:14:29PM -0500, Felipe Contreras wrote: >> > > W. Trevor King wrote: >> > > > My proposed --prompt behavior is for folks who think “I often run >> > > > this command without thinking it through all the way. I'm also >> > > > not used to reading Git's output and using 'reset --hard' with the >> > > > reflog to reverse changes. Instead of trusting me to only say >> > > > what I mean or leaving me to recover from mistakes, please tell me >> > > > what's about to change and let me opt out if I've changed my >> > > > mind.” >> > > >> > > Unfortunately those folks by definition wouldn't know about the >> > > --prompt option. >> > >> > But once such folks are identified, you just have to convince them >> > (once) to set the pull.prompt config. That's a lot easier than >> > convincing 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
Marc Branchaud writes: > To that end, I suggest that pull's default behaviour should be to do > *nothing*. It should just print out a message to the effect that it > hasn't been configured, and that the user should run "git help pull" > for guidance. Fetching 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 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 Wed, 30 Apr 2014 13:01:49 +, Junio C Hamano wrote: > ... >> I didn't mean "replace 'pull' with 'update' everywhere". I meant >> "Introduce 'update' that lets integrate your history into that from >> the remote, which is to integrate in a direction opposite from how >> 'pull' does". > > That still doesn't quite solve my problem. If I'm tracking origin/master > in a local master branch, I can just use 'git pull' to get my 'feature' > branch (which is named master) updated to the current state of the origin. > This amounts to 'integrating' origin/master into my master. This discussion makes as much sense to me as debating whether "git fiddle" should, in case a simple "git hammer" does not apply, should translate to an implied "git screwdriver", and when it does, whether more people's workflows involve turning a screw left rather than right by default. What the gibbins? I don't even use git pull. I use git fetch, and then, depending on my needs, I rebase 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 the particular circumstances. -- 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 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 condition part of an "if ()" statement. > > then? ... in the condition of an "if" statement is what I would write. "if ()" statement is mixing name and shorthand for the statement. -- 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 4/8] CodingGuidelines: give an example for control statements
Junio C Hamano writes: > Signed-off-by: Junio C Hamano > --- > Documentation/CodingGuidelines | 11 +++ > 1 file changed, 11 insertions(+) > > diff --git a/Documentation/CodingGuidelines b/Documentation/CodingGuidelines > index 1e0c4cf..d72e912 100644 > --- a/Documentation/CodingGuidelines > +++ b/Documentation/CodingGuidelines > @@ -97,6 +97,17 @@ For shell scripts specifically (not exhaustive): > "then" should be on the next line for if statements, and "do" > should be on the next line for "while" and "for". > > + (incorrect) > + if test -f hello; then > + do this > + fi > + > + (correct) > + if test -f hello > + then > + do this > + fi > + > - We prefer "test" over "[ ... ]". > > - We do not write the noiseword "function" in front of shell s/noiseword/bashism/ -- 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
