* [PATCH v15 0/7] bisect: Add support for --no-checkout option
From: Jon Seymour @ 2011-08-03 15:03 UTC (permalink / raw)
To: git; +Cc: chriscool, gitster, j6t, jnareb, Jon Seymour
Motivation
==========
For some bisection tasks, checking out the commit at each stage of the bisection process is unecessary or undesirable.
This series adds support for a --no-checkout option to git-bisect.
If specified on a start command, --no-checkout causes 'git bisect' to update BISECT_HEAD at each stage of the bisection process instead of checking out the commit at that point.
One application of the --no-checkout option is to find, within a partially damaged repository, a commit that has at least one parent whose graph is fully reachable in the sense of 'git pack-objects'.
For example:
git bisect start BISECT_HEAD <some-known-good-commit> <boundary-commits> --no-checkout
git bisect run eval '
rc=1;
if git rev-list --objects BISECT_HEAD >tmp.$$; then
git pack-objects --stdout >/dev/null < tmp.$$ && rc=0;
fi;
rm tmp.$$;
test $rc -eq 0;'
<some-known-good-commit> is a known good commit, for which the test passes.
<boundary-commits> are commits chosen to prevent the bisection visiting missing or corrupt commit objects.
Assuming this git bisect run completes successfully, bisect/bad will refer to a commit which has at least one parent that is fully reachable in the sense of 'git pack-objects'.
Patch Synopsis
==============
Remediation
-----------
Patch 1/7 changes existing behaviour in the case that an invalid revision argument is supplied to 'git bisect start'. In particular, in this case, bisection state is neither created or modified if argument validation fails. Previously, existing bisection state would be cleared even if the revision arguments were subsequently determined to be invalid.
Patch 2/7 remediates a potential flaw that might hide a failure in a chain of pasted statements.
Patch 3/7 adds a test which documents the existing behaviour of git bisect in the presence of tree damage.
New Function
------------
Patch 4/7 modifies the C code that supports bisection.
Patch 5/7 modifies porcelain to enable option exposed by 4/7.
Patch 6/7 adds some tests.
Patch 7/7 adds some documentation.
Revision History
----------------
v15:
Fixed reset behaviour in --no-checkout case. Added one test for same.
Simplified implementation so that no-checkout mode is inferred by presence of
$GIT_DIR/BISECT_HEAD eliminating the need for a separate BISECT_MODE control file.
Patch 8/8 from v13/14 was redistributed and squashed into earlier commits.
Style and documentation edits based on feedback from Christian Coulder.
v14:
Reverted --bisect-mode aspect of v13 change so C code matches v11.
v13:
Following suggestions from Junio:
* Replaced BISECT_NO_CHECKOUT control file with BISECT_MODE.
* Changed name of internal option on bisect--helper from --no-checkout to --bisect-mode=checkout|update-ref.
* Changed --no-checkout bisections to update BISECT_HEAD instead of HEAD.
v11:
Removed support for --update-ref=<ref>, per Junio's preference.
v10:
Changed the way deferred statements are connected. Reverted some whitespace minimization.
v8:
Further feedback from Christian Couder. Support --update-ref <ref>.
v6:
This series includes numerous improvements suggested by Christian Couder.
Reworks:
"bisect: allow git bisect to be used with repos containing damaged trees."
Replaced --ignore-checkout-failure with --no-checkout option suggested by Junio.
Todo
-----
* Implement full support for bisection in bare repositories.
Jon Seymour (7):
bisect: move argument parsing before state modification.
bisect: use && to connect statements that are deferred with eval.
bisect: add tests to document expected behaviour in presence of
broken trees.
bisect: introduce support for --no-checkout option.
bisect: introduce --no-checkout support into porcelain.
bisect: add tests for the --no-checkout option.
bisect: add documentation for --no-checkout option.
Documentation/git-bisect.txt | 32 +++++++++-
bisect.c | 33 +++++++---
bisect.h | 2 +-
builtin/bisect--helper.c | 7 ++-
git-bisect.sh | 110 +++++++++++++++++++-------------
t/t6030-bisect-porcelain.sh | 144 +++++++++++++++++++++++++++++++++++++++++-
6 files changed, 265 insertions(+), 63 deletions(-)
--
1.7.6.352.g5540e
^ permalink raw reply
* Re: [PATCH v13 5/8] bisect: introduce --no-checkout support into porcelain.
From: Christian Couder @ 2011-08-03 14:09 UTC (permalink / raw)
To: Jon Seymour; +Cc: Christian Couder, git, gitster, j6t, jnareb
In-Reply-To: <CAH3AnrpQZJprVtkNH1oeGXADzy1HA20xSTD8Cwpo3=ymOjgYhA@mail.gmail.com>
On Wed, Aug 3, 2011 at 3:24 PM, Jon Seymour <jon.seymour@gmail.com> wrote:
> On Wed, Aug 3, 2011 at 10:46 PM, Jon Seymour <jon.seymour@gmail.com> wrote:
>> On Wed, Aug 3, 2011 at 3:27 PM, Christian Couder
>> <chriscool@tuxfamily.org> wrote:
>>> On Tuesday 02 August 2011 16:41:13 Jon Seymour wrote:
>>>> On Tue, Aug 2, 2011 at 10:04 PM, Christian Couder
>>>>
>>>> If I was to do this, I'd prefer to change uses of $BISECT_MODE with a
>>>> call to a function bisect_mode() that does the same thing.
>>>
>>> Yeah, I think it would be a good idea to have a bisect_mode() function.
>>> I don't like very much to blindly call some code when we might not need it.
>>>
>>
> Mmmm.
>
> Actually, there is a neater way to do this.
>
> I'll such use the existence of BISECT_HEAD to inform the
> implementation of bisect_mode().
>
> This avoids the need for a separate .git/BISECT_MODE file.
Yeah, but then you have to be careful of the fact that BISECT_HEAD
might have not been properly deleted or might have been created by the
user for other purposes.
Thanks,
Christian.
^ permalink raw reply
* Re: [PATCH 3/5] setup_revisions: remember whether a ref was positive or not
From: Sverre Rabbelier @ 2011-08-03 13:52 UTC (permalink / raw)
To: Junio C Hamano, Johannes Schindelin
Cc: Jonathan Nieder, Jeff King, Git List, Daniel Barkalow,
Ramkumar Ramachandra, Dmitry Ivankov
In-Reply-To: <7vr55fs1z0.fsf@alter.siamese.dyndns.org>
Heya,
On Mon, Jul 25, 2011 at 01:17, Junio C Hamano <gitster@pobox.com> wrote:
> In other words, I am not opposed to an effort to give the callers to the
> "pending objects" machinery a better way to discover what the user told us
> from the command line, giving them more than just "at the end of the
> UNINTERESTING marking here are the objects listed on the command line and
> you can look at their flags". For example, some commands may want to tell
> "a..b" and "^a b" apart, and other commands may want to tell what "a" was
> when the user asked for exotic things like "a^@" or "a^!".
I agree that such might be useful, but since we currently do not need
something as advanced as that, I'm hesitant to implement something
(far) more advanced than what we need (YAGNI [0]). So I'm thinking
that perhaps there's a suitable middle ground where we stick with the
current flags approach until someone needs something more advanced so
as to make sure that it's implemented in a way that meets an actual
implementer need?
On Sun, Jul 24, 2011 at 21:23, Junio C Hamano <gitster@pobox.com> wrote:
> Sverre Rabbelier <srabbelier@gmail.com> writes:
>
>> void add_pending_object(struct rev_info *revs, struct object *obj, const char *name)
>> {
>> - add_pending_object_with_mode(revs, obj, name, S_IFINVALID);
>> + add_pending_object_with_mode(revs, obj, name, S_IFINVALID, 0);
>> }
>
> This seems utterly broken. For example, fmt-merge-msg.c adds "^HEAD" and
> of course the flags on the object is UNINTERESTING. Has all the callers of
> add_pending_object() been verified? Why is it passing an unconditional 0
> and not !!(obj->flags & UNINTERESTING) or something?
If I understand correctly (and it's not unlikely that I don't), the
'flags' field is used to store the actual flags (not just a boolean).
Would the following be appropriate?
+ add_pending_object_with_mode(revs, obj, name, S_IFINVALID, obj->flags);
Hopefully Dscho remembers enough of our hacking to be able to answer
that question.
If it is, do you still think it's "utterly broken" or would that be
something we can work with?
[0] http://c2.com/xp/YouArentGonnaNeedIt.html
--
Cheers,
Sverre Rabbelier
^ permalink raw reply
* [PATCH 2/2] gitattributes: Reword "attribute macro" to "macro attribute"
From: Michael Haggerty @ 2011-08-03 13:41 UTC (permalink / raw)
To: git; +Cc: gitster, peff, Michael Haggerty
In-Reply-To: <1312378890-31703-1-git-send-email-mhagger@alum.mit.edu>
The new wording makes it clearer that such a beast is an attribute in
addition to being a macro (as opposed to being only a macro that is
used for attributes).
Signed-off-by: Michael Haggerty <mhagger@alum.mit.edu>
---
Documentation/gitattributes.txt | 18 +++++++++---------
1 files changed, 9 insertions(+), 9 deletions(-)
diff --git a/Documentation/gitattributes.txt b/Documentation/gitattributes.txt
index ccb3f3f..2bbe76b 100644
--- a/Documentation/gitattributes.txt
+++ b/Documentation/gitattributes.txt
@@ -79,7 +79,7 @@ Attributes for all users on a system should be placed in the
`$(prefix)/etc/gitattributes` file.
Sometimes you would need to override an setting of an attribute
-for a path to `unspecified` state. This can be done by listing
+for a path to `Unspecified` state. This can be done by listing
the name of the attribute prefixed with an exclamation point `!`.
@@ -868,7 +868,7 @@ If this attribute is not set or has an invalid value, the value of the
(See linkgit:git-config[1]).
-USING ATTRIBUTE MACROS
+USING MACRO ATTRIBUTES
----------------------
You do not want any end-of-line conversions applied to, nor textual diffs
@@ -879,27 +879,27 @@ produced for, any binary file you track. You would need to specify e.g.
------------
but that may become cumbersome, when you have many attributes. Using
-attribute macros, you can define an attribute that, when set, also
+macro attributes, you can define an attribute that, when set, also
sets or unsets a number of other attributes at the same time. The
-system knows a built-in attribute macro, `binary`:
+system knows a built-in macro attribute, `binary`:
------------
*.jpg binary
------------
Setting the "binary" attribute also unsets the "text" and "diff"
-attributes as above. Note that attribute macros can only be "Set",
+attributes as above. Note that macro attributes can only be "Set",
though setting one might have the effect of setting or unsetting other
attributes or even returning other attributes to the "Unspecified"
state.
-DEFINING ATTRIBUTE MACROS
+DEFINING MACRO ATTRIBUTES
-------------------------
-Custom attribute macros can be defined only in the `.gitattributes` file
-at the toplevel (i.e. not in any subdirectory). The built-in attribute
-macro "binary" is equivalent to:
+Custom macro attributes can be defined only in the `.gitattributes`
+file at the toplevel (i.e. not in any subdirectory). The built-in
+macro attribute "binary" is equivalent to:
------------
[attr]binary -diff -text
--
1.7.6.8.gd2879
^ permalink raw reply related
* [PATCH 1/2] gitattributes: Clarify discussion of attribute macros
From: Michael Haggerty @ 2011-08-03 13:41 UTC (permalink / raw)
To: git; +Cc: gitster, peff, Michael Haggerty
In-Reply-To: <1312378890-31703-1-git-send-email-mhagger@alum.mit.edu>
In particular, make it clear that attribute macros are themselves
recorded as attributes in addition to setting other attributes.
Signed-off-by: Michael Haggerty <mhagger@alum.mit.edu>
---
Documentation/gitattributes.txt | 13 ++++++++-----
1 files changed, 8 insertions(+), 5 deletions(-)
diff --git a/Documentation/gitattributes.txt b/Documentation/gitattributes.txt
index 412c55b..ccb3f3f 100644
--- a/Documentation/gitattributes.txt
+++ b/Documentation/gitattributes.txt
@@ -879,16 +879,19 @@ produced for, any binary file you track. You would need to specify e.g.
------------
but that may become cumbersome, when you have many attributes. Using
-attribute macros, you can specify groups of attributes set or unset at
-the same time. The system knows a built-in attribute macro, `binary`:
+attribute macros, you can define an attribute that, when set, also
+sets or unsets a number of other attributes at the same time. The
+system knows a built-in attribute macro, `binary`:
------------
*.jpg binary
------------
-which is equivalent to the above. Note that the attribute macros can only
-be "Set" (see the above example that sets "binary" macro as if it were an
-ordinary attribute --- setting it in turn unsets "text" and "diff").
+Setting the "binary" attribute also unsets the "text" and "diff"
+attributes as above. Note that attribute macros can only be "Set",
+though setting one might have the effect of setting or unsetting other
+attributes or even returning other attributes to the "Unspecified"
+state.
DEFINING ATTRIBUTE MACROS
--
1.7.6.8.gd2879
^ permalink raw reply related
* [PATCH 0/2] Clarify semantics of git attribute macros
From: Michael Haggerty @ 2011-08-03 13:41 UTC (permalink / raw)
To: git; +Cc: gitster, peff, Michael Haggerty
Make it clearer that attribute macros do not only affect other
attributes, but are attributes themselves.
The second patch changes the nomenclature in gitattributes(5) from
"attribute macro" to "macro attribute", which I think makes the point
a tiny bit clearer. But it is definitely optional.
Michael Haggerty (2):
gitattributes: Clarify discussion of attribute macros
gitattributes: Reword "attribute macro" to "macro attribute"
Documentation/gitattributes.txt | 25 ++++++++++++++-----------
1 files changed, 14 insertions(+), 11 deletions(-)
--
1.7.6.8.gd2879
^ permalink raw reply
* Re: [PATCH] For Real - Fixed pluralization in diff reports
From: Jakub Narebski @ 2011-08-03 13:38 UTC (permalink / raw)
To: Jon Forrest
In-Reply-To: <4E36B8E4.5080900@gmail.com>
Jon Forrest <nobozo@gmail.com> writes:
> On 8/1/2011 2:58 AM, Sverre Rabbelier wrote:
>> On Mon, Aug 1, 2011 at 06:46, Jon Forrest<nobozo@gmail.com> wrote:
>>> fprintf(options->file, "%s", line_prefix);
>>> fprintf(options->file,
>>> - " %d files changed, %d insertions(+), %d deletions(-)\n",
>>> - total_files, adds, dels);
>>> + " %d file%s changed, %d insertion%s(+), %d deletion%s(-)\n",
>>> + total_files, total_files == 1 ? "" : "s", adds, adds == 1 ?
>>> "" : "s", dels,
>>> + dels == 1 ? "" : "s");
>>> }
>>
>> Also, this is rather detrimental to the i18n effort methinks?
Besides, as it was already said, this is an API.
> If the goal if the i18n effort is also to produce grammatically
> correct output in all the supported languages then the
> tests that my patch would break would have to be rewritten
> anyway.
That's not it.
The problem is that above code assumes that plural form can be formed
by adding suffix, and it assumes that is only one plural form... both
assumptions does not hold for non-English.
C.f. "Additional functions for plural forms" chapter in gettext info
page: http://www.gnu.org/s/hello/manual/gettext/Plural-forms.html
--
Jakub Narębski
^ permalink raw reply
* Re: [PATCH 17/18] revert: Introduce --continue to continue the operation
From: Jonathan Nieder @ 2011-08-03 13:34 UTC (permalink / raw)
To: Ramkumar Ramachandra
Cc: Christian Couder, Junio C Hamano, Git List, Daniel Barkalow,
Jeff King
In-Reply-To: <CALkWK0mrx+3jdCQD9xya3AWMsPpSiZzEz+Z9XVxZNzw3UdKMVw@mail.gmail.com>
Ramkumar Ramachandra wrote:
>> On Thursday 28 July 2011 18:52:30 Ramkumar Ramachandra wrote:
>>> + for (p = buf.buf; *p; p = strchr(p, '\n') + 1) {
[...]
> Yes, that was intentional. Every editor I know of inserts a '\n' at
> the end of the last line, and I've seen some applications warn/ break
> when the last line is not terminated with '\n'. I suppose another
> reason to not change this is consistency -- we don't have to handle
> the last line using a special case. So, I personally don't like it,
> but I'll add a special case if you insist.
What is the failure mode? If it is a baffling segfault, then I
insist.
^ permalink raw reply
* Re: [PATCH] git-am: ignore leading whitespace before patch
From: Sverre Rabbelier @ 2011-08-03 13:33 UTC (permalink / raw)
To: Tay Ray Chuan; +Cc: David Barr, Git Mailing List
In-Reply-To: <CALUzUxrubhFpLd00BomM5WwPYNwPbxCx6q7U2TG4PssaQODkZQ@mail.gmail.com>
Heya,
On Wed, Aug 3, 2011 at 15:31, Tay Ray Chuan <rctay89@gmail.com> wrote:
> On Wed, Aug 3, 2011 at 9:21 PM, Sverre Rabbelier <srabbelier@gmail.com> wrote:
>> So how do you get the patches out of gmail? Do you just copy/paste the
>> output of the "Show original" page?
>
> I Ctrl-S from the "Show original" page. Using Chrome, that yields a
> mail.txt file.
Ah, clever hack! Nice :)
--
Cheers,
Sverre Rabbelier
^ permalink raw reply
* Re: Strange O(N^3) behavior in "git filter-branch"
From: Michael Haggerty @ 2011-08-03 13:33 UTC (permalink / raw)
To: git; +Cc: Junio C Hamano, Jeff King, Drew Northup, Jakub Narebski
In-Reply-To: <4E200611.9010005@alum.mit.edu>
On 07/15/2011 11:19 AM, Michael Haggerty wrote:
> On 07/14/2011 11:24 AM, Michael Haggerty wrote:
>> On 07/14/2011 09:16 AM, Michael Haggerty wrote:
>>> I have noticed that "git filter-branch" gets pathologically slow when it
>>> operates on a repository that has many references in a complicated
>>> directory hierarchy. The time seems to go like O(N^3), where N is the
>>> number of references being rewritten.
> [...]
> A many possible improvements come to mind, in increasing order of
> intrusiveness and generality:
> [...]
> 5. Organize the loose refs cache in memory as a tree, and only populate
> the parts of it that are accessed. This should also speed up iteration
> through a subtree by avoiding a linear search through all loose references.
FYI: I am working on (5), namely storing a linked list of loose refs for
each directory and only populating those directories that are accessed.
The directories themselves will be held in a tree/trie (AFAICT the
distinction is primarily whether each node holds its whole key or only
the part of the key relative to its parent, which is an implementation
detail). As a bonus, the caches for submodules will be handled
correctly (they are currently never used).
It might be another week or so before I have patches ready.
Michael
--
Michael Haggerty
mhagger@alum.mit.edu
http://softwareswirl.blogspot.com/
^ permalink raw reply
* Re: Fwd: [PATCH 0/6] rebase: command "ref" and options --rewrite-{refs,heads,tags}
From: Sverre Rabbelier @ 2011-08-03 13:32 UTC (permalink / raw)
To: Greg Price; +Cc: Junio C Hamano, git
In-Reply-To: <20110628104758.GS5771@dr-wily.mit.edu>
Heya,
On Tue, Jun 28, 2011 at 12:47, Greg Price <price@mit.edu> wrote:
> I would also like to support that use case. In my personal
> experience, the case where the part$N are ancestors of the topic has
> actually been the more common case; typically it's that part1 is some
> topic, and then part2 is a further topic that depends on the changes
> in part1, so naturally it goes directly on top of it. So I'd be
> pleased to get the functionality of the present series in, even before
> supporting the more general case.
FWIW, I'm having the exact same need while working on the remote-hg
series (which depends on my remote-helper follow-up series, which
depends on fast-export-fixes, which depends on my original
remote-helper series, which depends on peffs initial patches; luckily
the latter two have been merged to next :P). I'd really like having
this available, especially the rebase -i support.
--
Cheers,
Sverre Rabbelier
^ permalink raw reply
* Re: [PATCH] git-am: ignore leading whitespace before patch
From: Tay Ray Chuan @ 2011-08-03 13:31 UTC (permalink / raw)
To: Sverre Rabbelier; +Cc: David Barr, Git Mailing List
In-Reply-To: <CAGdFq_it-QAA5uSme6S715dRzHs-s-Uj=MWKzBK2MOaaSdiXtg@mail.gmail.com>
On Wed, Aug 3, 2011 at 9:21 PM, Sverre Rabbelier <srabbelier@gmail.com> wrote:
> So how do you get the patches out of gmail? Do you just copy/paste the
> output of the "Show original" page?
I Ctrl-S from the "Show original" page. Using Chrome, that yields a
mail.txt file.
Without this patch, I used to manually remove the first line (all
empty whitespace).
--
Cheers,
Ray Chuan
^ permalink raw reply
* Re: [PATCH v13 5/8] bisect: introduce --no-checkout support into porcelain.
From: Jon Seymour @ 2011-08-03 13:24 UTC (permalink / raw)
To: Christian Couder; +Cc: Christian Couder, git, gitster, j6t, jnareb
In-Reply-To: <CAH3Anroaq+fH3T3_G1HsS3ecdNdpReaKLC5v=x37rDqSmtghww@mail.gmail.com>
On Wed, Aug 3, 2011 at 10:46 PM, Jon Seymour <jon.seymour@gmail.com> wrote:
> On Wed, Aug 3, 2011 at 3:27 PM, Christian Couder
> <chriscool@tuxfamily.org> wrote:
>> On Tuesday 02 August 2011 16:41:13 Jon Seymour wrote:
>>> On Tue, Aug 2, 2011 at 10:04 PM, Christian Couder
>>>
>>> If I was to do this, I'd prefer to change uses of $BISECT_MODE with a
>>> call to a function bisect_mode() that does the same thing.
>>
>> Yeah, I think it would be a good idea to have a bisect_mode() function.
>> I don't like very much to blindly call some code when we might not need it.
>>
>
Mmmm.
Actually, there is a neater way to do this.
I'll such use the existence of BISECT_HEAD to inform the
implementation of bisect_mode().
This avoids the need for a separate .git/BISECT_MODE file.
jon.
^ permalink raw reply
* Re: [PATCH] git-am: ignore leading whitespace before patch
From: Sverre Rabbelier @ 2011-08-03 13:21 UTC (permalink / raw)
To: David Barr, Tay Ray Chuan; +Cc: Git Mailing List
In-Reply-To: <CALUzUxpn-vCWpTQyB7z9dsu8a+UBL9MPjEycOfTmyws5ndz5kA@mail.gmail.com>
Heya,
On Wed, Aug 3, 2011 at 14:28, Tay Ray Chuan <rctay89@gmail.com> wrote:
> On Wed, Aug 3, 2011 at 6:20 AM, David Barr <davidbarr@google.com> wrote:
>> Some web-based email clients prepend whitespace to raw message
>> transcripts to workaround content-sniffing in some browsers.
>> Adjust the patch format detection logic to ignore leading
>> whitespace.
>>
>> Signed-off-by: David Barr <davidbarr@google.com>
>
> Finally, patches from GMail that play nice with git-am!
So how do you get the patches out of gmail? Do you just copy/paste the
output of the "Show original" page?
--
Cheers,
Sverre Rabbelier
^ permalink raw reply
* Re: "git check-attr" lists macros as being "set" -- feature or bug?
From: Michael Haggerty @ 2011-08-03 13:19 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Jeff King, git
In-Reply-To: <7vvcuoq13i.fsf@alter.siamese.dyndns.org>
On 07/26/2011 09:43 PM, Junio C Hamano wrote:
> Jeff King <peff@peff.net> writes:
>> I don't know the original rationale, but it seems like the only sane
>> behavior to me.
I agree that the behavior is sane (and also convenient).
> When we say "check-attr tells you if the named attribute is set", do we
> say "but macros cannot be examined this way" in the documentation? If
> not, I do not think we need any cluttering update.
I was confused by the following things:
* The word "macro" in other contexts (e.g., C macros) typically refers
to something that is fully replaced by its substitution text, leaving no
trace of the original macro or its name.
* In gitattributes(5), the following misleading text:
> ------------
> *.jpg -text -diff
> ------------
>
> but that may become cumbersome, when you have many attributes. Using
> attribute macros, you can specify groups of attributes set or unset at
> the same time. The system knows a built-in attribute macro, `binary`:
>
> ------------
> *.jpg binary
> ------------
>
> which is equivalent to the above.
It is *not* equivalent to the above, rather it is equivalent to
*.jpg binary -text -diff
(neglecting, of course, the recursive expansion of "binary").
I will soon send a documentation patch.
> It is a separate issue if macros should also be listed as the new feature
> that lists all attributes given to a path. I tend to think the macro
> attributes as well as the other attributes they set should all be shown.
I agree.
Michael
--
Michael Haggerty
mhagger@alum.mit.edu
http://softwareswirl.blogspot.com/
^ permalink raw reply
* Re: [PATCH v14 5/8] bisect: introduce --no-checkout support into porcelain.
From: Jon Seymour @ 2011-08-03 13:16 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, chriscool, j6t, jnareb
In-Reply-To: <7vk4avcsk9.fsf@alter.siamese.dyndns.org>
On Wed, Aug 3, 2011 at 9:16 AM, Junio C Hamano <gitster@pobox.com> wrote:
> Junio C Hamano <gitster@pobox.com> writes:
>
>> Jon Seymour <jon.seymour@gmail.com> writes:
>> ...
>>> + if test "$BISECT_MODE" = "--no-checkout"; then
>>> + git update-ref --no-deref HEAD "$start_head"
>>> + else
>>> + git checkout "$start_head" --
>>> + fi
>>
>> Just a minor worry but I would not be surprised if somebody's "test"
>> implementation barfs upon:
>>
>> test "--no-checkout" = "--no-checkout"
>>
>> mistaking the string with a dash at the beginning as an option unknown to
>> it. That is why we often have "z$variable" in our comparison, like so:
>>
>> if test "z$BISECT_MODE" = "z--no-checkout"
>> then
>> git update-ref --no-deref BISECT_HEAD "$start_head"
>> else
>> git checkout "$start_head" --
>> fi
>>
>>> - git rev-parse --sq-quote "$@" >"$GIT_DIR/BISECT_NAMES" &&
>>> + git rev-parse --sq-quote "$@" >"$GIT_DIR/BISECT_NAMES"
>>> + echo "$BISECT_MODE" > "$GIT_DIR/BISECT_MODE" &&
>>
>> &&?
>
> Having said that, other than these minor nits, I think this round is
> almost ready. I didn't check how it behaves upon "bisect reset",
> though. It shouldn't touch the index, HEAD nor the working tree (it
> probably is just the matter of "update-ref -d BISECT_HEAD" and nothing
> else, but I haven't thought things through thoroughly).
That seems reasonable. In fact, none of these series properly cleaned
up the reset state properly, so I'll fix that and a test for it.
>
> Further polishing we may want to do while it is still in pu/next I can
> think of off the top of my head are:
>
> - In this mode, I can bisect the history even inside a bare repository,
> as the whole point of --no-checkout is that the mode does not require a
> working tree. I however suspect "git bisect" requires working tree. Is
> this something we want to fix?
>
I agree, that would be useful. Haven't tried it yet but I'll see what
happens.I may issue changes for this as separate commit that can be
squashed later, if required, once it has been reviewed.
BTW: I'll squash v14 8/8 into the other commits, per Christian's suggestion.
> - Further, perhaps should we default to this mode inside a bare
> repository?
Seems reasonable.
jon.
^ permalink raw reply
* Re: [PATCH v13 5/8] bisect: introduce --no-checkout support into porcelain.
From: Jon Seymour @ 2011-08-03 12:46 UTC (permalink / raw)
To: Christian Couder; +Cc: Christian Couder, git, gitster, j6t, jnareb
In-Reply-To: <201108030727.04246.chriscool@tuxfamily.org>
On Wed, Aug 3, 2011 at 3:27 PM, Christian Couder
<chriscool@tuxfamily.org> wrote:
> On Tuesday 02 August 2011 16:41:13 Jon Seymour wrote:
>> On Tue, Aug 2, 2011 at 10:04 PM, Christian Couder
>>
>> If I was to do this, I'd prefer to change uses of $BISECT_MODE with a
>> call to a function bisect_mode() that does the same thing.
>
> Yeah, I think it would be a good idea to have a bisect_mode() function.
> I don't like very much to blindly call some code when we might not need it.
>
Ok, I'll do that, though it does mean that during a bisect run
invocation, for example, the file BISECT_MODE file will be read log(N)
times instead of just once. Obviously, in the grand scheme of things
this is not a huge cost.
I could use a variable to avoid hitting the file each time, but if I
do that I am going to have to ensure it is blank to start with which
means I will need at least an assignment in the place where that
statement is now.
jon.
^ permalink raw reply
* Re: [PATCH] git-am: ignore leading whitespace before patch
From: Tay Ray Chuan @ 2011-08-03 12:28 UTC (permalink / raw)
To: David Barr; +Cc: Git Mailing List
In-Reply-To: <1312323646-93427-1-git-send-email-davidbarr@google.com>
On Wed, Aug 3, 2011 at 6:20 AM, David Barr <davidbarr@google.com> wrote:
> Some web-based email clients prepend whitespace to raw message
> transcripts to workaround content-sniffing in some browsers.
> Adjust the patch format detection logic to ignore leading
> whitespace.
>
> Signed-off-by: David Barr <davidbarr@google.com>
Finally, patches from GMail that play nice with git-am!
Acked-by: Tay Ray Chuan <rctay89@gmail.com>
--
Cheers,
Ray Chuan
^ permalink raw reply
* Re: tracking submodules out of main directory.
From: henri GEIST @ 2011-08-03 12:26 UTC (permalink / raw)
To: Heiko Voigt
Cc: Jens Lehmann, Alexei Sholik, Junio C Hamano, git,
Sverre Rabbelier
In-Reply-To: <20110803062536.GB33203@book.hvoigt.net>
Le mercredi 03 août 2011 à 08:25 +0200, Heiko Voigt a écrit :
> Hi Henri,
>
> On Tue, Aug 02, 2011 at 08:42:24PM +0200, Jens Lehmann wrote:
> > Am 02.08.2011 14:19, schrieb henri GEIST:
> > > Le lundi 01 ao??t 2011 ?? 21:39 +0200, Jens Lehmann a ??crit :
> > >> Am 30.07.2011 23:55, schrieb henri GEIST:
> > >>> I can not see the difference with a gitlink.
> > >>
> > >> Then you can just use a config file for that, no? ;-)
> > >
> > > Off corse, I immediately start to work on it.
> >
> > I'm looking forward to that!
>
> Before hacking away please share some design information about this.
>
Ok this is what I intend to do.
I plan to use a config file containing lines like
"path_to_poited_repo SHA1_of_intended_commit URL_of_origin"
the URL part will not be required.
this file will be a list of pointer to other project.
I have plane to name the file ".gitdependencies" and put it at the root
of the current repository.
Then I will :
1) Adding to git-status the ability to scan this file and report :
- if the repository pointed by the path does not exist
- if the SHA1 of the current checkout of this repository mismatch.
- if this repository content differ from its checkout.
2) Adding to git status the ability to say if the current checkout has
the expected one in its ancestors.
3) Adding to git-add the ability to:
- create/update this file when trying to add an external repository
- giving up if it is not an external repository.
- automatically add the dependency file as well.
4) Adding to git-rm the ability to:
- remove lines in this file.
- add the result to index.
- maybe removing the complete file if it is empty.
5) Adding to git-reset the ability to:
- reset those lines one by one.
- adding the the file to the index.
I think I will do those steps as separate commits because they can works
independently. it just need you to do the unimplemented step manually
until it is done.
That is a first proposal, all your comment will be appreciate.
> Another thing:
>
> It sounds like the workflow you want to achieve is similar to the one
> the android developers are using. They have a lot of submodules which
> need automatic updating.
>
> The last time I checked they used repo (similar tool to submodules)
> together with gerrit.
>
> AFAIR they wanted to switch to submodules and have gerrit automatically
> make the superproject commits for single submodule changes. Additionally
> if a change involves multiple submodules the developer should be able to
> tie them together using a superproject commit.
>
> Have a look over there whether that workflow might help you?
I just add a quick look on the android web site and I did not understand
what exactly repo do.
All there documentation only say how to install it and checkout android
but it dose not explain anything about repo itself.
I will search more info about it.
Henri GEIST
^ permalink raw reply
* Re: [PATCH rc/histogram-diff] Make test number unique
From: Tay Ray Chuan @ 2011-08-03 12:20 UTC (permalink / raw)
To: Johannes Sixt; +Cc: Junio C Hamano, Git Mailing List
In-Reply-To: <4E38F7EB.3040400@viscovery.net>
On Wed, Aug 3, 2011 at 3:25 PM, Johannes Sixt <j.sixt@viscovery.net> wrote:
> From: Johannes Sixt <j6t@kdbg.org>
>
> Signed-off-by: Johannes Sixt <j6t@kdbg.org>
> ---
> ...9-diff-histogram.sh => t4050-diff-histogram.sh} | 0
> 1 files changed, 0 insertions(+), 0 deletions(-)
> rename t/{t4049-diff-histogram.sh => t4050-diff-histogram.sh} (100%)
Thanks for catching this.
--
Cheers,
Ray Chuan
^ permalink raw reply
* [PATCH] Makefile: some changes for http-related flag documentation
From: Tay Ray Chuan @ 2011-08-03 12:07 UTC (permalink / raw)
To: Git Mailing List; +Cc: Junio C Hamano
Rename git-http-pull to git-http-fetch. This was passed over in 215a7ad
(Big tool rename, Wed Sep 7 17:26:23 2005 -0700).
Also, distinguish between dumb and smart in flag docs, as the "warnings"
in NO_CURL and NO_EXPACT are no longer accurate given the introduction
of smart http(s).
Signed-off-by: Tay Ray Chuan <rctay89@gmail.com>
---
Makefile | 6 +++---
1 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/Makefile b/Makefile
index 4ed7996..9c7c3d0 100644
--- a/Makefile
+++ b/Makefile
@@ -30,15 +30,15 @@ all::
# Define LIBPCREDIR=/foo/bar if your libpcre header and library files are in
# /foo/bar/include and /foo/bar/lib directories.
#
-# Define NO_CURL if you do not have libcurl installed. git-http-pull and
+# Define NO_CURL if you do not have libcurl installed. git-http-fetch and
# git-http-push are not built, and you cannot use http:// and https://
-# transports.
+# transports (neither smart nor dumb).
#
# Define CURLDIR=/foo/bar if your curl header and library files are in
# /foo/bar/include and /foo/bar/lib directories.
#
# Define NO_EXPAT if you do not have expat installed. git-http-push is
-# not built, and you cannot push using http:// and https:// transports.
+# not built, and you cannot push using http:// and https:// transports (dumb).
#
# Define EXPATDIR=/foo/bar if your expat header and library files are in
# /foo/bar/include and /foo/bar/lib directories.
--
1.7.6.11.g49037.dirty
^ permalink raw reply related
* [PATCH] http.c: fix an invalid free()
From: Tay Ray Chuan @ 2011-08-03 11:54 UTC (permalink / raw)
To: Git Mailing List; +Cc: Junio C Hamano, avarab, Jeff King
In-Reply-To: <20110802033344.GA17494@sigill.intra.peff.net>
Remove a free() on the static buffer returned by sha1_file_name().
While we're at it, replace xmalloc() calls on the structs
http_(object|pack)_request with xcalloc() so that pointers in the
structs get initialized to NULL. That way, free()'s are safe - for
example, a free() on the url string member when aborting.
This fixes an invalid free().
Reported-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com>
Helped-by: Jeff King peff@peff.net
Signed-off-by: Tay Ray Chuan <rctay89@gmail.com>
---
http.c | 8 ++------
1 files changed, 2 insertions(+), 6 deletions(-)
diff --git a/http.c b/http.c
index a1ea3db..a59cac4 100644
--- a/http.c
+++ b/http.c
@@ -1121,9 +1121,8 @@ struct http_pack_request *new_http_pack_request(
struct strbuf buf = STRBUF_INIT;
struct http_pack_request *preq;
- preq = xmalloc(sizeof(*preq));
+ preq = xcalloc(1, sizeof(*preq));
preq->target = target;
- preq->range_header = NULL;
end_url_with_slash(&buf, base_url);
strbuf_addf(&buf, "objects/pack/pack-%s.pack",
@@ -1215,7 +1214,7 @@ struct http_object_request *new_http_object_request(const char *base_url,
struct curl_slist *range_header = NULL;
struct http_object_request *freq;
- freq = xmalloc(sizeof(*freq));
+ freq = xcalloc(1, sizeof(*freq));
hashcpy(freq->sha1, sha1);
freq->localfile = -1;
@@ -1253,8 +1252,6 @@ struct http_object_request *new_http_object_request(const char *base_url,
goto abort;
}
- memset(&freq->stream, 0, sizeof(freq->stream));
-
git_inflate_init(&freq->stream);
git_SHA1_Init(&freq->c);
@@ -1329,7 +1326,6 @@ struct http_object_request *new_http_object_request(const char *base_url,
return freq;
abort:
- free(filename);
free(freq->url);
free(freq);
return NULL;
--
1.7.6.11.g49037.dirty
^ permalink raw reply related
* Re: [RFC] Questions for "Git User's Survey 2011"
From: Jakub Narebski @ 2011-08-03 11:27 UTC (permalink / raw)
To: Jens Lehmann; +Cc: git
In-Reply-To: <4E384789.1000909@web.de>
On Tue, 2 Aug 2011, Jens Lehmann wrote:
> Am 25.07.2011 22:33, schrieb Jakub Narebski:
> > I am planning doing annual Git User's Survey, and I'd like to ask for
> > feedback.
>
> I'd appreciate to get some user feedback on submodules. What about this:
>
> === xx. What do you use submodules for? ===
> (multiple choice, with other)
>
> + I don't use submodules at all
>
> + to import repositories maintained by others
> + for your own (or your organization's) code shared between different projects
> + to separate large and/or many files for performance reasons
> + to separate data which you don't want (or aren't allowed) to disclose
>
> + Other, please specify
Thanks for your feedback. I'll add it, either in the above form, or
slightly extended as
=== xx. What do you use submodules (or similar) for? ===
(multiple choice, with other)
+ I don't use submodules at all
+ I use submodules
+ I use repo
+ I use git-subtree
+ I use gitslave
+ to import repositories maintained by others
+ for your own (or your organization's) code shared between different projects
+ to separate large and/or many files for performance reasons
+ to separate data which you don't want (or aren't allowed) to disclose
+ Other, please specify
--
Jakub Narebski
Poland
^ permalink raw reply
* Re: [ANNOUNCE/RFC] cj-git-patchtool: a "rebase -i" with more interaction
From: Jakub Narebski @ 2011-08-03 10:55 UTC (permalink / raw)
To: Christian Jaeger; +Cc: git
In-Reply-To: <CAEjYwfUY9tF_9frkaS7Aw26CPJA02Cr3HDN5Qpkup1rfHYacXw@mail.gmail.com>
Christian Jaeger <chrjae@gmail.com> writes:
> So I've written a set of tools[1] that separates the acts of editing
> and applying history changes.
[...]
>
> For more information see the README on Github.[1]
[...]
I have added cj-git-patchtool to "Patch-management Interface layers"
section of "Interfaces, frontends and tools" page on Git Wiki:
https://git.wiki.kernel.org/index.php/Interfaces,_frontends,_and_tools#cj-git-patchtool
Please check if it is correct, and improve project description if
needed.
> I don't know whether there are other tools offering the same now.
> Also, I have written this "just for myself", and for this reason made
> use of a set of never-before released Perl libraries of mine. If
> there's general interest in this tool, I'll be glad to help get rid of
> the dependency on these libraries (or clean them up and publish them
> properly, too).
I use one of patch management interfaces for that, namely StGit. It
operates on stack of patches, which you can apply and unapply, going
back and forth and correcting them.
--
Jakub Narębski
^ permalink raw reply
* Re: [PATCH] Skip archive --remote tests on Windows
From: Johannes Sixt @ 2011-08-03 10:40 UTC (permalink / raw)
To: Jakub Narebski
Cc: Junio C Hamano, Jeff King, Git Mailing List, Erik Faye-Lund
In-Reply-To: <m3hb5yrhfw.fsf@localhost.localdomain>
Am 8/3/2011 11:09, schrieb Jakub Narebski:
> Johannes Sixt <j.sixt@viscovery.net> writes:
>> -test_expect_success 'archive --list shows only enabled remote filters' '
>> +test_expect_success NOT_MINGW 'archive --list shows only enabled remote filters' '
>
> Shouldn't the prerequisite be called FORK rather than NON_MINGW?
Yes, it should. But we already have one instance of NOT_MINGW in
connection with archive --remote in this file before this patch, and with
Erik's efforts, these particular prerequisites should go away anyway RSN.
-- Hannes
^ 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