* Re: How best to handle multiple-authorship commits in GIT?
From: Valerie Aurora @ 2012-02-02 18:00 UTC (permalink / raw)
To: David Howells; +Cc: git@vger.kernel.org, dhowells@redhat.com
In-Reply-To: <21056.1328185509@redhat.com>
On Feb 2, 2012, at 4:25, David Howells <dhowells@redhat.com> wrote:
>
> Hi,
>
> I've been assigned a stack of patches to maintain and try and get upstream by
> my employer. Most of the patches currently have the authorship set to Val,
> but since I'll be maintaining them if they go in upstream and I've changed
> them a lot, I feel I should reassign the author field to myself so people
> pester me rather than Val with questions about them. However, I don't want to
> deny Val or any other contributor credit for their work on the patches.
>
> I can see a number of ways of doing this, and am wondering which will be best:
>
> (1) Ascribe multiple authorship directly in the commit. I suspect this would
> require a change to GIT and its associated tools. That way I could put my
> name in the priority pestering spot, but doing a search on authorship
> would still credit Val and others.
>
> (2) Add an extra tag 'Originally-authored-by' (or maybe 'Coauthored-by' as I
> saw someone recommend) in amongst the 'Signed-off-by' list. But that
> doesn't give them credit in a gitweb search without changing gitweb.
>
> (3) Don't actually modify Val's commits to bring them up to date, but rather
> create a historical GIT tree with Val's commits committed as-are and then
> add my changes to the top in a number of large merge commits (there have
> been multiple major breakages due to different merge windows).
>
> I dislike this approach because it doesn't produce a nice set of patches I
> can give to someone to review (which is a must). Plus, for the most part,
> it's actually easier to port Val's patches individually.
>
> Can GIT be modified to do (1)? Gitweb's display need only show one of the
> authors in the single-row-per-patch list mode, but should find a patch by any
> of the authors in an author search and should display all the authors in the
> commit display.
>
> David
Thanks, David! I had the same trouble with my set: while I entirely rewrote some patches, I still felt Jan Blunck deserved primary credit. I don't recall my solution, but I'm fine with mentioning my name in the commit message (and I think Jan should get credit too).
In general, this is a big problem for motivating contributors in other cases. Some maintainers have a habit of trivially rewriting patches so that, technically, no line is the same, then taking authorship and giving the actual author an ambiguous Signed-off-by. David hasn't done this here, of course - these are major rewrites - but when someone does all the hard work of finding and fixing a problem, the credit shouldn't go to the person who prettied it up. There is a line in the kernel doc saying how this should be handled, suggested by Rusty, but it's not being followed.
First class support for multiple authorship would be a big way to motivate contributors.
-VAL
^ permalink raw reply
* Re: [PATCH v2] Use correct grammar in diffstat summary line
From: Junio C Hamano @ 2012-02-02 18:24 UTC (permalink / raw)
To: Nguyen Thai Ngoc Duy
Cc: git, Jonathan Nieder, Ævar Arnfjörð,
Frederik Schwarzer, Brandon Casey
In-Reply-To: <20120202142255.GA25871@do>
Nguyen Thai Ngoc Duy <pclouds@gmail.com> writes:
> On Wed, Feb 01, 2012 at 01:26:43PM -0800, Junio C Hamano wrote:
>> Nice. Will queue
>
> Please also squash this in (resend looks ugly and it's hard to point
> out changes). It makes the code look less ugly, use Q_() for gettext
> poisoning and revert am input text back as Jonathan suggested.
>
> I take it --summary is un-i18n-able,...
... because?
^ permalink raw reply
* Re: [PATCH 6/9] grep: cache userdiff_driver in grep_source
From: Junio C Hamano @ 2012-02-02 18:34 UTC (permalink / raw)
To: Jeff King
Cc: Thomas Rast, Conrad Irwin, git, Nguyen Thai Ngoc Duy,
Dov Grobgeld
In-Reply-To: <20120202082043.GF6786@sigill.intra.peff.net>
Jeff King <peff@peff.net> writes:
> - grep_attr_lock();
> - drv = userdiff_find_by_path(gs->name);
> - grep_attr_unlock();
> - if (drv && drv->funcname.pattern) {
> - const struct userdiff_funcname *pe = &drv->funcname;
> + grep_source_load_driver(gs);
> + if (gs->driver->funcname.pattern) {
> + const struct userdiff_funcname *pe = &gs->driver->funcname;
When we load driver, gs->driver gets at least "default" driver, so we no
longer need to check for drv != NULL as we used to? Is that the reason
for the slight difference here?
> @@ -1237,6 +1234,7 @@ void grep_source_init(struct grep_source *gs, enum grep_source_type type,
> gs->name = name ? xstrdup(name) : NULL;
> gs->buf = NULL;
> gs->size = 0;
> + gs->driver = NULL;
>
> switch (type) {
> case GREP_SOURCE_FILE:
^ permalink raw reply
* Re: How best to handle multiple-authorship commits in GIT?
From: David Howells @ 2012-02-02 18:36 UTC (permalink / raw)
To: Valerie Aurora; +Cc: dhowells, git@vger.kernel.org
In-Reply-To: <9B990DDC-858D-43BA-BF9E-E0C3435354AF@gmail.com>
Valerie Aurora <valerie.aurora@gmail.com> wrote:
> There is a line in the kernel doc saying how this should be handled,
> suggested by Rusty, but it's not being followed.
Do you know where?
David
^ permalink raw reply
* Re: [PATCH] vcs-svn: Fix some compiler warnings
From: Ramsay Jones @ 2012-02-02 18:24 UTC (permalink / raw)
To: Jonathan Nieder; +Cc: David Barr, Junio C Hamano, GIT Mailing-list
In-Reply-To: <20120131192053.GC12443@burratino>
Jonathan Nieder wrote:
> Ramsay Jones wrote:
>
>> In particular, some versions of gcc complains as follows:
>>
>> CC vcs-svn/sliding_window.o
>> vcs-svn/sliding_window.c: In function `check_overflow':
>> vcs-svn/sliding_window.c:36: warning: comparison is always false \
>> due to limited range of data type
>
> Yuck. Suppressing this warning would presumably also suppress the
> optimization that notices the comparison is always false.
I didn't check, but I would assume so. I would prefer not to loose any
chance at optimizing the code, but in this case, given that we are talking
about a fatal error path, I don't think it is much of a loss.
> The -Wtype-limits warning also triggers in some other perfectly
> reasonable situations: see <http://gcc.gnu.org/PR51712>.
[...]
>> Note that the "some versions of gcc" which complain includes 3.4.4 and
>> 4.1.2, whereas gcc version 4.4.0 compiles the code without complaint.
>
> Thanks for tracking this down. Interesting. -Wtype-limits was split
> out from the default set of warnings (!) in gcc 4.3 to address
> <http://gcc.gnu.org/PR12963>, among other bugs (r124875, 2007-05-20).
Thanks for the above references, and for taking the time to track them
down.
> Is there some less ugly way to write the condition "if this value is
> not representable in this type"?
>
> I guess I could live with something like the following (please don't
> take the names too seriously):
>
> static inline off_t off_t_or_die(uintmax_t val, const char *msg_if_bad)
> {
> if (val > maximum_signed_value_of_type(off_t))
> die("%s", msg_if_bad);
> return (off_t) val;
> }
>
> ...
>
> off_t delta_len = off_t_or_die(len, "enormous delta");
> postimage_len = apply_delta(delta_len, input, ...);
>
> What do you think?
An static inline function was actually my first thought (although I had
something more like Junio's suggestion [elsewhere in this thread] in mind),
but I didn't want to place it in git-compat-util.h and could not find a
suitable place in the vcs-svn directory.
Hmm, I will send a v2 patch along these lines ...
ATB,
Ramsay Jones
^ permalink raw reply
* Re: [PATCH] Fix an "variable might be used uninitialized" gcc warning
From: Ramsay Jones @ 2012-02-02 18:25 UTC (permalink / raw)
To: Jonathan Nieder; +Cc: Junio C Hamano, GIT Mailing-list
In-Reply-To: <20120131194302.GD12443@burratino>
Jonathan Nieder wrote:
> Sure, when the control flow grows too complicated, that's probably worth
> fixing anyway, for the sake of humans especially.
>
> Sometimes gcc is the only crazy one, though. ;-)
Indeed. :-D
ATB,
Ramsay Jones
^ permalink raw reply
* [PATCH v2] vcs-svn: Fix some compiler warnings
From: Ramsay Jones @ 2012-02-02 18:36 UTC (permalink / raw)
To: Jonathan Nieder; +Cc: Junio C Hamano, GIT Mailing-list
In particular, some versions of gcc complains as follows:
CC vcs-svn/sliding_window.o
vcs-svn/sliding_window.c: In function `check_overflow':
vcs-svn/sliding_window.c:36: warning: comparison is always false \
due to limited range of data type
CC vcs-svn/fast_export.o
vcs-svn/fast_export.c: In function `fast_export_blob_delta':
vcs-svn/fast_export.c:303: warning: comparison is always false due \
to limited range of data type
Simply casting the (limited range unsigned) variable in the comparison
to an uintmax_t does not suppress the warning, however, since gcc is
"smart" enough to know that the cast does not change anything regarding
the value of the casted expression. In order to suppress the warning, we
introduce a static inline function to hide the (implicit) cast of the
original variable to an uintmax_t type prior to using it in the overflow
check comparison expression.
Note that the "some versions of gcc" which complain includes 3.4.4 and
4.1.2, whereas gcc version 4.4.0 compiles the code without complaint.
Signed-off-by: Ramsay Jones <ramsay@ramsay1.demon.co.uk>
---
Hi Jonathan,
Any suggestions for a better name than "value_too_large_for_off_t" will
be greatly accepted! :)
Also, I suppose you could make a similar change to the other two sites
in vcs-svn with similar range checks (fast_export.c:174 and svndiff.c:150).
ATB,
Ramsay Jones
git-compat-util.h | 5 +++++
vcs-svn/fast_export.c | 2 +-
vcs-svn/sliding_window.c | 2 +-
3 files changed, 7 insertions(+), 2 deletions(-)
diff --git a/git-compat-util.h b/git-compat-util.h
index 8f3972c..6a6a25a 100644
--- a/git-compat-util.h
+++ b/git-compat-util.h
@@ -450,6 +450,11 @@ static inline size_t xsize_t(off_t len)
return (size_t)len;
}
+static inline int value_too_large_for_off_t(uintmax_t val)
+{
+ return val > maximum_signed_value_of_type(off_t);
+}
+
static inline int has_extension(const char *filename, const char *ext)
{
size_t len = strlen(filename);
diff --git a/vcs-svn/fast_export.c b/vcs-svn/fast_export.c
index 19d7c34..2e0dcb0 100644
--- a/vcs-svn/fast_export.c
+++ b/vcs-svn/fast_export.c
@@ -300,7 +300,7 @@ void fast_export_blob_delta(uint32_t mode,
uint32_t len, struct line_buffer *input)
{
long postimage_len;
- if (len > maximum_signed_value_of_type(off_t))
+ if (value_too_large_for_off_t(len))
die("enormous delta");
postimage_len = apply_delta((off_t) len, input, old_data, old_mode);
if (mode == REPO_MODE_LNK) {
diff --git a/vcs-svn/sliding_window.c b/vcs-svn/sliding_window.c
index 1bac7a4..0d38482 100644
--- a/vcs-svn/sliding_window.c
+++ b/vcs-svn/sliding_window.c
@@ -33,7 +33,7 @@ static int read_to_fill_or_whine(struct line_buffer *file,
static int check_overflow(off_t a, size_t b)
{
- if (b > maximum_signed_value_of_type(off_t))
+ if (value_too_large_for_off_t(b))
return error("unrepresentable length in delta: "
"%"PRIuMAX" > OFF_MAX", (uintmax_t) b);
if (signed_add_overflows(a, (off_t) b))
--
1.7.9
^ permalink raw reply related
* Re: [PATCH 0/9] respect binary attribute in grep
From: Junio C Hamano @ 2012-02-02 18:39 UTC (permalink / raw)
To: Jeff King
Cc: Thomas Rast, Conrad Irwin, git, Nguyen Thai Ngoc Duy,
Dov Grobgeld
In-Reply-To: <20120202081747.GA10271@sigill.intra.peff.net>
Jeff King <peff@peff.net> writes:
> ... The result turned out much easier to read
> (and explain in the commit messages, as it was simple to break into
> smaller commits)....
Indeed the series is very nicely done ;-)
Thanks.
^ permalink raw reply
* Re: [PATCH] i18n: po for zh_cn
From: Junio C Hamano @ 2012-02-02 18:49 UTC (permalink / raw)
To: Nguyen Thai Ngoc Duy
Cc: Jiang Xin, Git List, Ævar Arnfjörð Bjarmason
In-Reply-To: <CACsJy8BPTuS+u8Grx0ojhdX-5+Vn6=DuojSWO0or7fJE1dbAEQ@mail.gmail.com>
Nguyen Thai Ngoc Duy <pclouds@gmail.com> writes:
> On Thu, Feb 2, 2012 at 6:45 AM, Junio C Hamano <gitster@pobox.com> wrote:
>> Jiang Xin <worldhello.net@gmail.com> writes:
>>
>>> Git can speak Chinese now.
>>>
>>> Signed-off-by: Jiang Xin <worldhello.net@gmail.com>
>>> ---
>>> po/zh_cn.po | 3568 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
>>> 1 个文件被修改, 3568 处添加(+), 0 处删除(-)
>>> create mode 100644 po/zh_cn.po
>>
>> I do not mind Chinese in the patch text (i.e. below), but I would have
>> preferred the above not to be in Chinese, which I do not read---I can
>> guess what 文件, 添加 and 删除 are, and I can also guess that 个 and 处
>> are units of counting, but nevertheless...
>
> Such a stat line would be wonderful in an all-Chinese environment
> though.
Yes, but the git mailing list is not all-Chinese environment. I was merely
asking that the future submissions will be prepared with something like a
one-shot "LC_ALL=C git format-patch ..."; it wasn't a suggestion not to i18n
the summary bit.
^ permalink raw reply
* Re: [PATCH] vcs-svn: Fix some compiler warnings
From: Jonathan Nieder @ 2012-02-02 18:53 UTC (permalink / raw)
To: Ramsay Jones; +Cc: David Barr, Junio C Hamano, GIT Mailing-list, Dmitry Ivankov
In-Reply-To: <4F2AD4CF.7020303@ramsay1.demon.co.uk>
Ramsay Jones wrote:
> An static inline function was actually my first thought (although I had
> something more like Junio's suggestion [elsewhere in this thread] in mind),
> but I didn't want to place it in git-compat-util.h and could not find a
> suitable place in the vcs-svn directory.
>
> Hmm, I will send a v2 patch along these lines ...
Well, your v2 patch looks good to me. The three-patch series I
sent[1] also look good to me. I guess I could queue your v2 and put
the rest on top --- what say you?
[1] http://thread.gmane.org/gmane.comp.version-control.git/189618
http://repo.or.cz/w/git/jrn.git/log/refs/topics/rj/svn-fe-type-limits
^ permalink raw reply
* Re: [PATCH 1/3] vcs-svn: rename check_overflow arguments for clarity
From: Junio C Hamano @ 2012-02-02 18:56 UTC (permalink / raw)
To: Jonathan Nieder
Cc: David Barr, Dmitry Ivankov, Junio C Hamano, Ramsay Jones,
GIT Mailing-list
In-Reply-To: <20120202112732.GA15537@burratino>
Ok, I've tentatively queued this.
-- >8 --
From: Ramsay Jones <ramsay@ramsay1.demon.co.uk>
Code using the argument names a and b just doesn't look right (not
sure why!). Use more explicit names "offset" and "len" to make their
type and meaning clearer.
Also rename check_overflow() to check_offset_overflow() to clarify
that we are making sure that "len" bytes beyond "offset" still fits
the type to represent an offset.
Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
---
vcs-svn/sliding_window.c | 14 +++++++-------
1 files changed, 7 insertions(+), 7 deletions(-)
diff --git a/vcs-svn/sliding_window.c b/vcs-svn/sliding_window.c
index 1bac7a4..c6c2eff 100644
--- a/vcs-svn/sliding_window.c
+++ b/vcs-svn/sliding_window.c
@@ -31,15 +31,15 @@ static int read_to_fill_or_whine(struct line_buffer *file,
return 0;
}
-static int check_overflow(off_t a, size_t b)
+static int check_offset_overflow(off_t offset, size_t len)
{
- if (b > maximum_signed_value_of_type(off_t))
+ if (len > maximum_signed_value_of_type(off_t))
return error("unrepresentable length in delta: "
- "%"PRIuMAX" > OFF_MAX", (uintmax_t) b);
- if (signed_add_overflows(a, (off_t) b))
+ "%"PRIuMAX" > OFF_MAX", (uintmax_t) len);
+ if (signed_add_overflows(offset, (off_t) len))
return error("unrepresentable offset in delta: "
"%"PRIuMAX" + %"PRIuMAX" > OFF_MAX",
- (uintmax_t) a, (uintmax_t) b);
+ (uintmax_t) offset, (uintmax_t) len);
return 0;
}
@@ -48,9 +48,9 @@ int move_window(struct sliding_view *view, off_t off, size_t width)
off_t file_offset;
assert(view);
assert(view->width <= view->buf.len);
- assert(!check_overflow(view->off, view->buf.len));
+ assert(!check_offset_overflow(view->off, view->buf.len));
- if (check_overflow(off, width))
+ if (check_offset_overflow(off, width))
return -1;
if (off < view->off || off + width < view->off + view->width)
return error("invalid delta: window slides left");
--
1.7.9.172.ge26ae
^ permalink raw reply related
* Re: [msysGit] Breakage in master?
From: Johannes Schindelin @ 2012-02-02 18:57 UTC (permalink / raw)
To: Erik Faye-Lund
Cc: Git Mailing List, msysGit, Ævar Arnfjörð Bjarmason
In-Reply-To: <CABPQNSbWu0r_gKGvCHk567pUtQiyDOCO8vFfrzPMFW1eUaj1nw@mail.gmail.com>
Hi Erik,
On Thu, 2 Feb 2012, Erik Faye-Lund wrote:
> Something strange is going on in Junio's current 'master' branch
> (f3fb075). "git show" has started to error out on Windows with a
> complaint about our vsnprintf:
> ---8<---
>
> $ git show
> commit f3fb07509c2e0b21b12a598fcd0a19a92fc38a9d
> Author: Junio C Hamano <gitster@pobox.com>
> Date: Tue Jan 31 22:31:35 2012 -0800
>
> Update draft release notes to 1.7.10
>
> Signed-off-by: Junio C Hamano <gitster@pobox.com>
>
> fatal: BUG: your vsnprintf is broken (returned -1)
> ---8<---
>
> [...]
>
> I'm at a loss here. Does anyone have a hunch about what's going on?
It very much reminds me of 6ef404095bc1162031fc3cb43430b512e975bc6a...
Is it possible that NO_GETTEXT is either not set, or ignored?
Ciao,
Dscho
^ permalink raw reply
* Re: git-svn branches with revision id's in name
From: Jehan Bing @ 2012-02-02 19:03 UTC (permalink / raw)
To: git; +Cc: Stephen Duncan Jr
In-Reply-To: <4F2A807B.9050206@T-Online.de>
On 2012-02-02 04:24, Carsten Fuchs wrote:
> Hi all,
>
> Am 2012-01-30 20:42, schrieb Stephen Duncan Jr:
>> [...]
>> $ git branch -a
>> * master
>> remotes/develop
>> remotes/develop@29271
>> remotes/develop@32463
>> remotes/develop@34103
>> remotes/feature/xyz
>> remotes/feature/xyz@26438
>> remotes/feature/xyz@27542
>> remotes/feature/xyz@35233
>>
>> Why have these remote branches been created? What impact does this
>> have on my checkout? Can I remove safely remove them? How? I was
>> unable to figure out how to reference this behavior in order to search
>> for information on it.
>
> Same questions here.
> (I know how to remove them, but I'd love to learn and understand why
> they have been created.)
Those are branches that have been deleted and then recreated later.
In svn, you can always get a deleted branch back by checking out an old
revision. But in git, branches are not part of the history, so when you
delete a branch, it's completely gone, as if it never existed, taking
with it any commit that has not been merged elsewhere.
To prevent that loss, git-svn doesn't delete branches. But if the branch
was re-created later in svn, you would get a conflict in git. So
instead, git-svn rename the old branch by adding the revision number
where the branch last existed, i.e. the revision before it was deleted.
So in the OP case, the branch "develop" was deleted at least 3 times, at
r34104, r32464 and r29272. The last one may also have been deleted too
but then it was not re-created so git-svn didn't rename yet.
^ permalink raw reply
* [PATCH, RFC] Fix build problems related to profile-directed optimization
From: Theodore Ts'o @ 2012-02-02 19:03 UTC (permalink / raw)
To: git; +Cc: Theodore Ts'o, Andi Kleen
There was a number of problems I ran into when trying the
profile-directed optimizations added by Andi Kleen in git commit
7ddc2710b9. (This was using gcc 4.4 found on many enterprise
distros.)
1) The -fprofile-generate and -fprofile-use commands are incompatible
with ccache; the code ends up looking in the wrong place for the gcda
files based on the ccache object names.
2) If the makefile notices that CFLAGS are different, it will rebuild
all of the binaries. Hence the recipe originally specified by the
INSTALL file ("make profile-all" followed by "make install") doesn't
work. It will appear to work, but the binaries will end up getting
built with no optimization.
This patch fixes this by using an explicit set of options passed via
PROFILE_GEN and PROFILE_USE and then using these to directly
manipulate CFLAGS and EXTLIBS.
Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
Cc: Andi Kleen <ak@linux.intel.com>
---
INSTALL | 4 ++--
Makefile | 31 +++++++++++++++++++++++--------
2 files changed, 25 insertions(+), 10 deletions(-)
diff --git a/INSTALL b/INSTALL
index 6fa83fe..978ed09 100644
--- a/INSTALL
+++ b/INSTALL
@@ -28,8 +28,8 @@ set up install paths (via config.mak.autogen), so you can write instead
If you're willing to trade off (much) longer build time for a later
faster git you can also do a profile feedback build with
- $ make profile-all
- # make prefix=... install
+ $ make prefix=... profile-all
+ # make prefix=... PROFILE_USE=t install
This will run the complete test suite as training workload and then
rebuild git with the generated profile feedback. This results in a git
diff --git a/Makefile b/Makefile
index c457c34..15d1df4 100644
--- a/Makefile
+++ b/Makefile
@@ -1772,6 +1772,24 @@ ifdef ASCIIDOC7
export ASCIIDOC7
endif
+### profile feedback build
+#
+
+# Can adjust this to be a global directory if you want to do extended
+# data gathering
+PROFILE_DIR := $(CURDIR)
+
+ifdef PROFILE_GEN
+ CFLAGS += -fprofile-generate=$(PROFILE_DIR) -DNO_NORETURN=1
+ EXTLIBS += -lgcov
+ export CCACHE_DISABLE=t
+endif
+
+ifdef PROFILE_USE
+ CFLAGS += -fprofile-use=$(PROFILE_DIR) -fprofile-correction -DNO_NORETURN=1
+ export CCACHE_DISABLE=t
+endif
+
# Shell quote (do not use $(call) to accommodate ancient setups);
SHA1_HEADER_SQ = $(subst ','\'',$(SHA1_HEADER))
@@ -2701,14 +2719,11 @@ cover_db_html: cover_db
#
.PHONY: profile-all profile-clean
-PROFILE_GEN_CFLAGS := $(CFLAGS) -fprofile-generate -DNO_NORETURN=1
-PROFILE_USE_CFLAGS := $(CFLAGS) -fprofile-use -fprofile-correction -DNO_NORETURN=1
-
profile-clean:
- $(RM) $(addsuffix *.gcda,$(object_dirs))
- $(RM) $(addsuffix *.gcno,$(object_dirs))
+ $(RM) $(addsuffix *.gcda,$(addprefix $(PROFILE_DIR)/, $(object_dirs)))
+ $(RM) $(addsuffix *.gcno,$(addprefix $(PROFILE_DIR)/, $(object_dirs)))
profile-all: profile-clean
- $(MAKE) CFLAGS="$(PROFILE_GEN_CFLAGS)" all
- $(MAKE) CFLAGS="$(PROFILE_GEN_CFLAGS)" -j1 test
- $(MAKE) CFLAGS="$(PROFILE_USE_CFLAGS)" all
+ $(MAKE) PROFILE_GEN=t all
+ $(MAKE) PROFILE_GEN=t -j1 test
+ $(MAKE) PROFILE_USE=t all
--
1.7.8.11.gefc1f.dirty
^ permalink raw reply related
* Re: how to tell when git release changes porcelain stdout/stderr
From: Jonathan Nieder @ 2012-02-02 19:11 UTC (permalink / raw)
To: Neal Kreitzinger; +Cc: git
In-Reply-To: <jgeert$qeg$1@dough.gmane.org>
Hi Neal,
Neal Kreitzinger wrote:
> What is the best way for me (a git user) to tell when a new git release
> changes the stdout/stderr formatting of a porcelain command?
They almost always do. Maybe that will be happening less often as
messages get translated, but if you really need reproducible output,
your life will be much easier if you just use plumbing instead (and
please report problems when they arise).
^ permalink raw reply
* Re: Finding all commits which modify a file
From: Junio C Hamano @ 2012-02-02 19:13 UTC (permalink / raw)
To: Neal Groothuis; +Cc: git
In-Reply-To: <5456.38.96.167.131.1328194547.squirrel@mail.lo-cal.org>
"Neal Groothuis" <ngroot@lo-cal.org> writes:
>> "Neal Groothuis" <ngroot@lo-cal.org> writes:
>>
>>> Is there a situation where checking for TREESAMEness before
>>> simplification
>>> is desirable and checking after would not be?
>>
>> When you do not want to see a side branch that does not contribute to
> the end result at all, obviously ;-). Outside that situation, before or
> after should not make a difference, I would think.
>
> In that case, you wouldn't be using the --full-history flag at all, yeah?
Yes. In case my tongue-in-cheek comment was too obscure, I was saying that
I do not think the change to TREESAME-ness check you were alluding to would
break any use case I would think of off the top of my head.
We of course might discover undesired consequences in unexpected corners
after we try your change, but I do not think we can discuss such corner
cases further without seeing a patch.
^ permalink raw reply
* Re: [PATCH] i18n: po for zh_cn
From: Junio C Hamano @ 2012-02-02 19:20 UTC (permalink / raw)
To: Frederik Schwarzer; +Cc: git
In-Reply-To: <201202021104.50534.schwarzerf@gmail.com>
Frederik Schwarzer <schwarzerf@gmail.com> writes:
> Translations of the former group are in many cases suboptimal. But the
> latter group will not follow this mailing list.
Well, I would have to caution that translations by people who are not
familiar with Git would also be in many cases suboptimal, too. Have you
seen translations of technical books by nontechnical people?
> ... In practice I guess interested Translators (who are not
> interested in every code detail) will unsubscribe after a few days and
> then miss all the fun.
Ever heard of mail filtering by say Subject: or even From: ? ;)
> A git-i18n mailing list could coordinate that. It would not be a list
> for l10n teams to do their internal coordination, but for the i18n
> coordinator to notify l10n teams about updated POT files (he might
> even merge PO files) and for l10n teams to ask about strings they are
> unsure about. These questions would then be digested by the i18n
> coordinator and brought to the attention of the developers if needed.
>
> How does that sound?
That is entirely up to the l10n coordinator. Are you volunteering?
^ permalink raw reply
* Re: how to determine oldest supported version of git
From: Jonathan Nieder @ 2012-02-02 19:23 UTC (permalink / raw)
To: Neal Kreitzinger; +Cc: git
In-Reply-To: <jgeekn$of2$1@dough.gmane.org>
Hi Neal,
Neal Kreitzinger wrote:
> What is the best way for me (a git user) to determine what is currently the
> oldest supported version of git (the oldest version still getting bugfixes)?
> IOW, when can I tell that my version of git is no longer supported?
It depends what supported means. Even very old git releases might get
point updates to fix major problems such as security bugs.
If you want to see which branches Junio is actively maintaining,
looking at the last commit date from the maint-* branches on [1] is
one way.
However, in my experience people interested in product lifetimes more
often mean "versions the vendor will respond to bug reports about"
rather than "versions getting updates". If you have discovered a bug
in an old version of git, even if it is only a couple of major
releases ago, a good debugging strategy is almost always to try with
the newest release and see if it still exhibits the bug. If you don't
try that, people on this list might just try it themselves. If it
doesn't affect recent releases, I would not be surprised if people on
this list do not necessarily care much. One can more easily interest
me at least by pointing out which regression is making it hard to
upgrade instead.
Thanks,
Jonathan
[1] git://github.com/gitster/git.git
^ permalink raw reply
* Re: [PATCH v3 1/4] completion: be nicer with zsh
From: Junio C Hamano @ 2012-02-02 19:27 UTC (permalink / raw)
To: Jonathan Nieder; +Cc: Felipe Contreras, git, SZEDER Gábor
In-Reply-To: <20120202084859.GC3823@burratino>
Jonathan Nieder <jrnieder@gmail.com> writes:
> Felipe Contreras wrote:
>
>> Felipe Contreras (4):
>> completion: be nicer with zsh
>
> Since I can't find this patch in the mail archive, I'll reply here.
> Luckily the most important bit is above already.
Thanks for playing a mail-relay. Except for the much more readable log
message you have here, the result matches what I have at 06357ef (modulo
test vs '['). I'll replace what I queued.
> I think I mentioned before that this subject line is what will appear
> in the shortlog and the shortlog is all that some people will see of
> the changelog, so it should include a self-contained description of
> the impact of the patch.
>
> However, clearly I did not say it clearly enough. :) I guess it's
> better to take a cue from storytellers and show rather than tell.
Very big thanks for this ;-)
^ permalink raw reply
* [PATCH] t0300-credentials: Word around a solaris /bin/sh bug
From: Ben Walton @ 2012-02-02 19:32 UTC (permalink / raw)
To: git, gitster; +Cc: Ben Walton
Solaris' /bin/sh was making the IFS setting permanent instead of
temporary when using it to slurp in credentials in the generated
'dump' script of the 'setup helper scripts' test in t0300-credentials.
The stderr file that was being compared to expected-stderr contained the
following stray line from the credential helper run:
warning: invalid credential line: username foo
To avoid this bug, capture the original IFS and force it to be reset
after its use is no longer required. For now, this is lighter weight
than altering which shell these scripts use as their shebang.
Signed-off-by: Ben Walton <bwalton@artsci.utoronto.ca>
---
t/t0300-credentials.sh | 2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/t/t0300-credentials.sh b/t/t0300-credentials.sh
index 885af8f..1be3fe2 100755
--- a/t/t0300-credentials.sh
+++ b/t/t0300-credentials.sh
@@ -8,10 +8,12 @@ test_expect_success 'setup helper scripts' '
cat >dump <<-\EOF &&
whoami=`echo $0 | sed s/.*git-credential-//`
echo >&2 "$whoami: $*"
+ OIFS=$IFS
while IFS== read key value; do
echo >&2 "$whoami: $key=$value"
eval "$key=$value"
done
+ IFS=$OIFS
EOF
cat >git-credential-useless <<-\EOF &&
--
1.7.8.3
^ permalink raw reply related
* Re: [PATCH 6/9] grep: cache userdiff_driver in grep_source
From: Jeff King @ 2012-02-02 19:37 UTC (permalink / raw)
To: Junio C Hamano
Cc: Thomas Rast, Conrad Irwin, git, Nguyen Thai Ngoc Duy,
Dov Grobgeld
In-Reply-To: <7v4nv9xexs.fsf@alter.siamese.dyndns.org>
On Thu, Feb 02, 2012 at 10:34:07AM -0800, Junio C Hamano wrote:
> Jeff King <peff@peff.net> writes:
>
> > - grep_attr_lock();
> > - drv = userdiff_find_by_path(gs->name);
> > - grep_attr_unlock();
> > - if (drv && drv->funcname.pattern) {
> > - const struct userdiff_funcname *pe = &drv->funcname;
> > + grep_source_load_driver(gs);
> > + if (gs->driver->funcname.pattern) {
> > + const struct userdiff_funcname *pe = &gs->driver->funcname;
>
> When we load driver, gs->driver gets at least "default" driver, so we no
> longer need to check for drv != NULL as we used to? Is that the reason
> for the slight difference here?
Yes, exactly.
We could just leave gs->driver NULL instead of looking up "default", and
then use NULL to signal to the calling code that defaults should be
used. But NULL is interpreted by grep_source_load_driver as "we did not
look up the driver yet", so the common case of "no driver" would mean we
accidentally do the lookup multiple times. The diff_filespec code uses
the same convention to solve the same problem.
Speaking of which, there was some notion in my mind that a "grep_source"
and a "diff_filespec" were very similar objects, and that we could
possibly unify the implementations. I decided against that route with
this series, as it would have involved pretty heavy refactoring of the
diff code to prevent a fairly small amount of code duplication.
-Peff
^ permalink raw reply
* Re: [PATCH] t0300-credentials: Word around a solaris /bin/sh bug
From: Frans Klaver @ 2012-02-02 19:44 UTC (permalink / raw)
To: git, gitster, Ben Walton
In-Reply-To: <1328211135-25217-1-git-send-email-bwalton@artsci.utoronto.ca>
Wor_k_ around ...
On Thu, 02 Feb 2012 20:32:15 +0100, Ben Walton
<bwalton@artsci.utoronto.ca> wrote:
> Solaris' /bin/sh was making the IFS setting permanent instead of
> temporary when using it to slurp in credentials in the generated
> 'dump' script of the 'setup helper scripts' test in t0300-credentials.
>
> The stderr file that was being compared to expected-stderr contained the
> following stray line from the credential helper run:
>
> warning: invalid credential line: username foo
>
> To avoid this bug, capture the original IFS and force it to be reset
> after its use is no longer required. For now, this is lighter weight
> than altering which shell these scripts use as their shebang.
>
> Signed-off-by: Ben Walton <bwalton@artsci.utoronto.ca>
> ---
> t/t0300-credentials.sh | 2 ++
> 1 files changed, 2 insertions(+), 0 deletions(-)
>
> diff --git a/t/t0300-credentials.sh b/t/t0300-credentials.sh
> index 885af8f..1be3fe2 100755
> --- a/t/t0300-credentials.sh
> +++ b/t/t0300-credentials.sh
> @@ -8,10 +8,12 @@ test_expect_success 'setup helper scripts' '
> cat >dump <<-\EOF &&
> whoami=`echo $0 | sed s/.*git-credential-//`
> echo >&2 "$whoami: $*"
> + OIFS=$IFS
> while IFS== read key value; do
> echo >&2 "$whoami: $key=$value"
> eval "$key=$value"
> done
> + IFS=$OIFS
> EOF
> cat >git-credential-useless <<-\EOF &&
--
Using Opera's revolutionary e-mail client: http://www.opera.com/mail/
^ permalink raw reply
* Re: [PATCH v3 0/4] completion: couple of cleanups
From: Junio C Hamano @ 2012-02-02 19:48 UTC (permalink / raw)
To: Felipe Contreras; +Cc: git, SZEDER Gábor, Jonathan Nieder
In-Reply-To: <1328145320-14071-1-git-send-email-felipe.contreras@gmail.com>
Felipe Contreras <felipe.contreras@gmail.com> writes:
> Felipe Contreras (4):
> completion: be nicer with zsh
> completion: simplify __git_remotes
> completion: remove unused code
> completion: simplify __gitcomp*
My understanding is that the two patches relayed by Jonathan cover the
first three entries, so here is my attempt to reconstruct the last one
without seeing a single bit from the v3 series ;-)
-- >8 --
From: Felipe Contreras <felipe.contreras@gmail.com>
Subject: [PATCH] completion: simplify __gitcomp and __gitcomp_nl implementations
These shell functions are written in an unnecessarily verbose way;
simplify their "conditionally use $<number> after checking $# against
<number>" logic by using shell's built-in conditional substitution
facilities.
Also remove the first of the two assignments to IFS in __gitcomp_nl
that does not have any effect.
Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
---
contrib/completion/git-completion.bash | 19 +++----------------
1 files changed, 3 insertions(+), 16 deletions(-)
diff --git a/contrib/completion/git-completion.bash b/contrib/completion/git-completion.bash
index 8dd4e44..1ce1d6e 100755
--- a/contrib/completion/git-completion.bash
+++ b/contrib/completion/git-completion.bash
@@ -495,11 +495,8 @@ fi
# 4: A suffix to be appended to each possible completion word (optional).
__gitcomp ()
{
- local cur_="$cur"
+ local cur_="${3-$cur}"
- if [ $# -gt 2 ]; then
- cur_="$3"
- fi
case "$cur_" in
--*=)
COMPREPLY=()
@@ -524,18 +521,8 @@ __gitcomp ()
# appended.
__gitcomp_nl ()
{
- local s=$'\n' IFS=' '$'\t'$'\n'
- local cur_="$cur" suffix=" "
-
- if [ $# -gt 2 ]; then
- cur_="$3"
- if [ $# -gt 3 ]; then
- suffix="$4"
- fi
- fi
-
- IFS=$s
- COMPREPLY=($(compgen -P "${2-}" -S "$suffix" -W "$1" -- "$cur_"))
+ local IFS=$'\n'
+ COMPREPLY=($(compgen -P "${2-}" -S "${4- }" -W "$1" -- "${3-$cur}"))
}
__git_heads ()
--
1.7.9.172.ge26ae
^ permalink raw reply related
* Re: [PATCH] t0300-credentials: Word around a solaris /bin/sh bug
From: Ben Walton @ 2012-02-02 19:48 UTC (permalink / raw)
To: Frans Klaver, gitster; +Cc: git
In-Reply-To: <op.v82g3ura0aolir@keputer>
Excerpts from Frans Klaver's message of Thu Feb 02 14:44:08 -0500 2012:
> Wor_k_ around ...
*face*palm*
Thanks for catching that.
Junio, can you make that tweak if the patch is ok or would you prefer
a new mail?
Thanks
-Ben
--
Ben Walton
Systems Programmer - CHASS
University of Toronto
C:416.407.5610 | W:416.978.4302
^ permalink raw reply
* Re: how to determine oldest supported version of git
From: Jeff King @ 2012-02-02 19:49 UTC (permalink / raw)
To: Jonathan Nieder; +Cc: Neal Kreitzinger, git
In-Reply-To: <20120202192124.GA19873@burratino>
On Thu, Feb 02, 2012 at 01:23:40PM -0600, Jonathan Nieder wrote:
> However, in my experience people interested in product lifetimes more
> often mean "versions the vendor will respond to bug reports about"
> rather than "versions getting updates". If you have discovered a bug
> in an old version of git, even if it is only a couple of major
> releases ago, a good debugging strategy is almost always to try with
> the newest release and see if it still exhibits the bug. If you don't
> try that, people on this list might just try it themselves. If it
> doesn't affect recent releases, I would not be surprised if people on
> this list do not necessarily care much. One can more easily interest
> me at least by pointing out which regression is making it hard to
> upgrade instead.
Agreed. It is very annoying to have somebody report a bug, I (or another
dev) spends time trying to reproduce, and then we find out that it was
actually fixed a year ago.
However, I am much happier if a submitter does that leg-work themselves,
and posts to the list something like:
I am using version a.b.c. It has bug $FOO, which was fixed by $COMMIT
and released in d.e.f [or even "I tried d.e.f and it does not exhibit
the bug"]. This bug fix should get cherry-picked back to a.b.c,
because {it is more important than usual for reason X, upgrading past
a.b.c is not feasible for reason Y, etc}.
Nobody wastes time tracking down the already-fixed bug, and it's
relatively easy to decide whether the cherry-pick is worth the effort
based on the reasoning given.
I know not everybody is capable of complex bisection or writing a
succinct test case. But they can at least try to reproduce with the
latest version and convert "there's a bug in git" to "there's a bug in
this old version of git".
-Peff
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox