* [PATCH] restore fetching with thin-pack capability
From: Nicolas Pitre @ 2007-11-07 22:20 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
Broken since commit fa74052922cf39e5a39ad7178d1b13c2da9b4519.
Signed-off-by: Nicolas Pitre <nico@cam.org>
---
diff --git a/builtin-fetch-pack.c b/builtin-fetch-pack.c
index 862652b..bb1742f 100644
--- a/builtin-fetch-pack.c
+++ b/builtin-fetch-pack.c
@@ -32,7 +32,7 @@ static const char fetch_pack_usage[] =
#define MAX_IN_VAIN 256
static struct commit_list *rev_list;
-static int non_common_revs, multi_ack, use_thin_pack, use_sideband;
+static int non_common_revs, multi_ack, use_sideband;
static void rev_list_push(struct commit *commit, int mark)
{
@@ -178,7 +178,7 @@ static int find_common(int fd[2], unsigned char *result_sha1,
(multi_ack ? " multi_ack" : ""),
(use_sideband == 2 ? " side-band-64k" : ""),
(use_sideband == 1 ? " side-band" : ""),
- (use_thin_pack ? " thin-pack" : ""),
+ (args.use_thin_pack ? " thin-pack" : ""),
(args.no_progress ? " no-progress" : ""),
" ofs-delta");
else
^ permalink raw reply related
* [PATCH v3] Fix mistakes in the documentation of git-add --interactive.
From: Benoit Sigoure @ 2007-11-07 22:31 UTC (permalink / raw)
To: git; +Cc: gitster, Benoit Sigoure
In-Reply-To: <Pine.LNX.4.64.0711072224200.4362@racer.site>
This patch fixes a couple of language issues in the documentation
of the `patch' sub-command of git-add --interactive.
Signed-off-by: Benoit Sigoure <tsuna@lrde.epita.fr>
---
Use better wording proposed by Dscho.
Documentation/git-add.txt | 10 +++++-----
1 files changed, 5 insertions(+), 5 deletions(-)
diff --git a/Documentation/git-add.txt b/Documentation/git-add.txt
index 963e1ab..3117798 100644
--- a/Documentation/git-add.txt
+++ b/Documentation/git-add.txt
@@ -201,9 +201,9 @@ patch::
the change of each hunk. You can say:
y - add the change from that hunk to index
- n - do not add the change from that hunk to index
- a - add the change from that hunk and all the rest to index
- d - do not the change from that hunk nor any of the rest to index
+ n - skip this hunk
+ a - add the change from that hunk and all the remaining ones
+ d - skip this hunk, as well as the remaining ones
j - do not decide on this hunk now, and view the next
undecided hunk
J - do not decide on this hunk now, and view the next hunk
@@ -211,8 +211,8 @@ patch::
undecided hunk
K - do not decide on this hunk now, and view the previous hunk
+
-After deciding the fate for all hunks, if there is any hunk
-that was chosen, the index is updated with the selected hunks.
+After deciding the fate of each hunk, the index is updated with the selected
+ones.
diff::
--
1.5.3.4.398.g859b
^ permalink raw reply related
* Re: [PATCH] Fix mistakes in the documentation of git-add --interactive.
From: Benoit Sigoure @ 2007-11-07 22:28 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git, gitster
In-Reply-To: <Pine.LNX.4.64.0711072224200.4362@racer.site>
[-- Attachment #1: Type: text/plain, Size: 638 bytes --]
On Nov 7, 2007, at 11:25 PM, Johannes Schindelin wrote:
> Hi,
>
> On Wed, 7 Nov 2007, Benoit Sigoure wrote:
>
>> - a - add the change from that hunk and all the rest to index
>> - d - do not the change from that hunk nor any of the rest
>> to index
>> + a - add the change from that hunk and all the remaining ones
>> + d - do not the add change from that hunk and skip the
>> remaining ones
>
> This still sounds funny. How about
>
> d - skip this hunk, as well as the remaining ones
Yup, that's better, indeed. I'll post a v3 (:
--
Benoit Sigoure aka Tsuna
EPITA Research and Development Laboratory
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 186 bytes --]
^ permalink raw reply
* Re: [PATCH v2] user-manual: add advanced topic "bisecting merges"
From: J. Bruce Fields @ 2007-11-07 22:26 UTC (permalink / raw)
To: Benoit Sigoure; +Cc: Steffen Prohaska, gitster, Ralf.Wildenhues, git
In-Reply-To: <F783880C-A0F9-45D9-A23A-075600B31CEE@lrde.epita.fr>
On Wed, Nov 07, 2007 at 11:16:06PM +0100, Benoit Sigoure wrote:
> Hi Steffen,
>
> On Nov 7, 2007, at 10:50 PM, Steffen Prohaska wrote:
>
>> This commits adds a discussion of the challenge of bisecting
>> merge commits to the user manual. The text is slightly
>> adapted from a mail by Junio C Hamano <gitster@pobox.com>
>> to the mailing list
>> <http://marc.info/?l=git&m=119403257315527&w=2>.
>>
>> The discussion is added to "Exploring git history" in a
>> sub-section titled "Advanced topics". The discussion requires
>> detailed knowledge about git. It is assumed that the reader will
>> skip advanced topics on first reading. At least the text suggest
>> to do so.
>>
>> Signed-off-by: Steffen Prohaska <prohaska@zib.de>
>> ---
>> Documentation/user-manual.txt | 89
>> +++++++++++++++++++++++++++++++++++++++++
>> 1 files changed, 89 insertions(+), 0 deletions(-)
>>
>> Some minor errors were fixed. Thanks to <Ralf.Wildenhues@gmx.de>.
>>
>> I kept the naming of the commits. Benoit Sigoure suggested to choose
>> a different naming which he claims would be easier to remember.
>> I'm not convinced. The current naming starts with X, Y, Z on the left
>> and names the remaining commits on the right with A, B, C, D. This
>> is simple and give sufficient orientation.
>
> I still disagree but... fair enough ;)
> You end up comparing [ABCD] with [XYZ] which (to me) is hard to follow
> because it's like you were comparing two different kind of entities. I
> tend to think more in term of branch (e.g. what's happened to the upper
> branch and what's happened to the lower branch, rather than think in terms
> of "before a point in time" and "after that point in time"). Because of
> that, I constantly need to look back at the scheme to find out what is `A',
> what is `Z' etc.
>
> Some more comments below. Sorry for not spotting these earlier.
>
>>
>> diff --git a/Documentation/user-manual.txt b/Documentation/user-manual.txt
>> index d99adc6..d0e738e 100644
>> --- a/Documentation/user-manual.txt
>> +++ b/Documentation/user-manual.txt
>> @@ -934,6 +934,95 @@ Figuring out why this works is left as an exercise to
>> the (advanced)
>> student. The gitlink:git-log[1], gitlink:git-diff-tree[1], and
>> gitlink:git-hash-object[1] man pages may prove helpful.
>>
>> +[[history-advanced-topics]]
>> +Advanced topics
>> +---------------
>> +This section covers advanced topics that typically require more
>> +knowledge about git than the manual presented to this point.
>> +
>> +You may want to skip the section at first reading, and come back
>
> I think the correct wording here is "on first reading". If a native
> English speaker could confirm this...
Confirmed....
--b.
^ permalink raw reply
* Re: [PATCH] Fix mistakes in the documentation of git-add --interactive.
From: Johannes Schindelin @ 2007-11-07 22:25 UTC (permalink / raw)
To: Benoit Sigoure; +Cc: git, gitster
In-Reply-To: <1194472947-8601-1-git-send-email-tsuna@lrde.epita.fr>
Hi,
On Wed, 7 Nov 2007, Benoit Sigoure wrote:
> - a - add the change from that hunk and all the rest to index
> - d - do not the change from that hunk nor any of the rest to index
> + a - add the change from that hunk and all the remaining ones
> + d - do not the add change from that hunk and skip the remaining ones
This still sounds funny. How about
d - skip this hunk, as well as the remaining ones
Hmm?
Ciao,
Dscho
^ permalink raw reply
* git rebase --skip
From: Mike Hommey @ 2007-11-07 22:21 UTC (permalink / raw)
To: git
Hi,
I use git-rebase quite regularly, and I haven't used git-rebase --skip
after a failed merge without first resetting the working tree. I was
wondering if it wouldn't make sense to automatically do the reset when
running git-rebase --skip.
Mike
^ permalink raw reply
* Re: [PATCH v2] user-manual: add advanced topic "bisecting merges"
From: Benoit Sigoure @ 2007-11-07 22:16 UTC (permalink / raw)
To: Steffen Prohaska; +Cc: gitster, Ralf.Wildenhues, git
In-Reply-To: <11944722214046-git-send-email-prohaska@zib.de>
[-- Attachment #1: Type: text/plain, Size: 6860 bytes --]
Hi Steffen,
On Nov 7, 2007, at 10:50 PM, Steffen Prohaska wrote:
> This commits adds a discussion of the challenge of bisecting
> merge commits to the user manual. The text is slightly
> adapted from a mail by Junio C Hamano <gitster@pobox.com>
> to the mailing list
> <http://marc.info/?l=git&m=119403257315527&w=2>.
>
> The discussion is added to "Exploring git history" in a
> sub-section titled "Advanced topics". The discussion requires
> detailed knowledge about git. It is assumed that the reader will
> skip advanced topics on first reading. At least the text suggest
> to do so.
>
> Signed-off-by: Steffen Prohaska <prohaska@zib.de>
> ---
> Documentation/user-manual.txt | 89 ++++++++++++++++++++++++++++++
> +++++++++++
> 1 files changed, 89 insertions(+), 0 deletions(-)
>
> Some minor errors were fixed. Thanks to <Ralf.Wildenhues@gmx.de>.
>
> I kept the naming of the commits. Benoit Sigoure suggested to choose
> a different naming which he claims would be easier to remember.
> I'm not convinced. The current naming starts with X, Y, Z on the left
> and names the remaining commits on the right with A, B, C, D. This
> is simple and give sufficient orientation.
I still disagree but... fair enough ;)
You end up comparing [ABCD] with [XYZ] which (to me) is hard to
follow because it's like you were comparing two different kind of
entities. I tend to think more in term of branch (e.g. what's
happened to the upper branch and what's happened to the lower branch,
rather than think in terms of "before a point in time" and "after
that point in time"). Because of that, I constantly need to look
back at the scheme to find out what is `A', what is `Z' etc.
Some more comments below. Sorry for not spotting these earlier.
>
> diff --git a/Documentation/user-manual.txt b/Documentation/user-
> manual.txt
> index d99adc6..d0e738e 100644
> --- a/Documentation/user-manual.txt
> +++ b/Documentation/user-manual.txt
> @@ -934,6 +934,95 @@ Figuring out why this works is left as an
> exercise to the (advanced)
> student. The gitlink:git-log[1], gitlink:git-diff-tree[1], and
> gitlink:git-hash-object[1] man pages may prove helpful.
>
> +[[history-advanced-topics]]
> +Advanced topics
> +---------------
> +This section covers advanced topics that typically require more
> +knowledge about git than the manual presented to this point.
> +
> +You may want to skip the section at first reading, and come back
I think the correct wording here is "on first reading". If a native
English speaker could confirm this...
> +later when you have a better understanding of git.
> +
> +[[bisect-merges]]
> +Why bisecting merge commits can be harder than bisecting linear
> history
> +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> ~~
> +The following text is based upon an email by Junio C. Hamano to
> +the git mailing list
> +(link:http://marc.info/?l=git&m=119403257315527&w=2[link:http://
> marc.info/?l=git&m=119403257315527&w=2]).
> +It was slightly adapted for this manual.
> +
> +Bisecting merges can be challenging due to the complexity of
> +changes introduced at a merge. Bisecting through merges is not a
s/at a merge/& point/ ?
> +technical problem. The real problem is what to do when the
> +culprit turns out to be a merge commit. How to spot what really
> +is wrong, and figure out how to fix. The problem is not for the
> +tool but for the human, and it is real.
> +
> +Imagine this history.
> +
> +................................................
> + ---Z---o---X---...---o---A---C---D
> + \ /
> + o---o---Y---...---o---B
> +................................................
> +
> +Suppose that on the upper development line, the meaning of one
> +of the functions that existed at Z was changed at commit X. The
> +commits from Z leading to A change both the function's
> +implementation and all calling sites that existed at Z, as well
> +as new calling sites they add, to be consistent. There is no
> +bug at A.
> +
> +Suppose in the meantime the lower development line somebody
s/Suppose/& that/
> +added a new calling site for that function at commit Y. The
> +commits from Z leading to B all assume the old semantics of that
> +function and the callers and the callee are consistent with each
> +other. There is no bug at B, either.
> +
> +You merge to create C. There is no textual conflict with this
> +three way merge, and the result merges cleanly. You bisect
> +this, because you found D is bad and you know Z was good. Your
> +bisect will find that C (merge) is broken. Understandably so,
> +as at C, the new calling site of the function added by the lower
> +branch is not converted to the new semantics, while all the
> +other calling sites that already existed at Z would have been
> +converted by the merge. The new calling site has semantic
> +adjustment needed, but you do not know that yet. You need to
s/adjustment/&s/
> +find out that that is the cause of the breakage by looking at the
> +merge commit C and the history leading to it.
> +
> +How would you do that?
> +
> +Both "git diff A C" and "git diff B C" would be an enormous patch.
> +Each of them essentially shows the whole change on each branch
> +since they diverged. The developers may have well behaved to
> +create good commits that follow the "commit small, commit often,
> +commit well contained units" mantra, and each individual commit
> +leading from Z to A and from Z to B may be easy to review and
> +understand, but looking at these small and easily reviewable
> +steps alone would not let you spot the breakage. You need to
> +have a global picture of what the upper branch did (and
> +among many, one of them is to change the semantics of that
> +particular function) and look first at the huge "diff A C"
> +(which shows the change the lower branch introduces), and see if
> +that huge change is consistent with what have been done between
> +Z and A.
> +
> +If you linearize the history by rebasing the lower branch on
> +top of the upper, instead of merging, the bug becomes much easier to
> +find and understand. Your history would instead be:
> +
> +................................................................
> + ---Z---o---X--...---o---A---o---o---Y*--...---o---B*--D*
> +................................................................
> +
> +and there is a single commit Y* between A and B* that introduced
> +the new calling site that still uses the old semantics of the
> +function, even though that was already modified at X. "git show
> +Y*" will be a much smaller patch than "git diff A C" and it is
> +much easier to deal with.
> +
> +
> [[Developing-with-git]]
> Developing with git
> ===================
Thank you!
--
Benoit Sigoure aka Tsuna
EPITA Research and Development Laboratory
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 186 bytes --]
^ permalink raw reply
* Inconsistencies with git log
From: Jon Smirl @ 2007-11-07 22:15 UTC (permalink / raw)
To: Git Mailing List
In project root:
git log arch/powerpc/platforms/52xx
works as expected
cd arch/powerpc/platforms/52xx
git log arch/powerpc/platforms/52xx
fatal: ambiguous argument 'arch/powerpc/platforms/52xx': unknown
revision or path not in the working tree.
Use '--' to separate paths from revisions
still in arch/powerpc/platforms/52xx
git log
get log for the whole project
Shouldn't git log give the the log for the tree under the current directory?
jonsmirl@terra:~/mpc5200b/arch/powerpc/platforms/52xx$ git --version
git version 1.5.3.4.1458.g3e72e
--
Jon Smirl
jonsmirl@gmail.com
^ permalink raw reply
* Re: [PATCH] git-stash: Fix listing stashes
From: Junio C Hamano @ 2007-11-07 22:03 UTC (permalink / raw)
To: Emil Medve; +Cc: nanako3, git
In-Reply-To: <1194469827-17037-1-git-send-email-Emilian.Medve@Freescale.com>
Oops, indeed. Thanks.
^ permalink raw reply
* [PATCH] Fix mistakes in the documentation of git-add --interactive.
From: Benoit Sigoure @ 2007-11-07 22:02 UTC (permalink / raw)
To: git; +Cc: gitster, Benoit Sigoure
In-Reply-To: <200711072150.18751.barra_cuda@katamail.com>
This patch fixes a couple of language issues in the documentation
of the `patch' sub-command of git-add --interactive.
Signed-off-by: Benoit Sigoure <tsuna@lrde.epita.fr>
---
Documentation/git-add.txt | 8 ++++----
1 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/Documentation/git-add.txt b/Documentation/git-add.txt
index 963e1ab..f7c02ff 100644
--- a/Documentation/git-add.txt
+++ b/Documentation/git-add.txt
@@ -202,8 +202,8 @@ patch::
y - add the change from that hunk to index
n - do not add the change from that hunk to index
- a - add the change from that hunk and all the rest to index
- d - do not the change from that hunk nor any of the rest to index
+ a - add the change from that hunk and all the remaining ones
+ d - do not the add change from that hunk and skip the remaining ones
j - do not decide on this hunk now, and view the next
undecided hunk
J - do not decide on this hunk now, and view the next hunk
@@ -211,8 +211,8 @@ patch::
undecided hunk
K - do not decide on this hunk now, and view the previous hunk
+
-After deciding the fate for all hunks, if there is any hunk
-that was chosen, the index is updated with the selected hunks.
+After deciding the fate of each hunk, the index is updated with the selected
+ones.
diff::
--
1.5.3.4.398.g859b
^ permalink raw reply related
* Re: [PATCH] Fix mistakes in the documentation of git-add --interactive.
From: Benoit Sigoure @ 2007-11-07 21:59 UTC (permalink / raw)
To: Michele Ballabio; +Cc: git list
In-Reply-To: <200711072150.18751.barra_cuda@katamail.com>
[-- Attachment #1: Type: text/plain, Size: 362 bytes --]
On Nov 7, 2007, at 9:50 PM, Michele Ballabio wrote:
> On Wednesday 07 November 2007, Benoit Sigoure wrote:
>> + d - do not the add change from that hunk and skip the
>> remaining ones
> add the
> ^^^^^^^
> Swap these :)
Ouch, indeed ;o
--
Benoit Sigoure aka Tsuna
EPITA Research and Development Laboratory
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 186 bytes --]
^ permalink raw reply
* Re: [PATCH 2/2] Small code readability improvement in show_reference() in builtin-tag.c
From: Mike Hommey @ 2007-11-07 21:51 UTC (permalink / raw)
To: git; +Cc: Junio C Hamano
In-Reply-To: <1194095285-18651-2-git-send-email-mh@glandium.org>
I think this patch got lost with my bad behaviour of sending another
series of patch not including this one.
Cheers,
Mike
On Sat, Nov 03, 2007 at 02:08:05PM +0100, Mike Hommey wrote:
>
> Signed-off-by: Mike Hommey <mh@glandium.org>
> ---
> builtin-tag.c | 9 ++++-----
> 1 files changed, 4 insertions(+), 5 deletions(-)
>
> diff --git a/builtin-tag.c b/builtin-tag.c
> index e57f57f..3ed5759 100644
> --- a/builtin-tag.c
> +++ b/builtin-tag.c
> @@ -84,14 +84,13 @@ static int show_reference(const char *refname, const unsigned char *sha1,
> sp = buf = read_sha1_file(sha1, &type, &size);
> if (!buf)
> return 0;
> - if (!size) {
> + /* skip header */
> + sp = strstr(buf, "\n\n");
> +
> + if (!sp || !size) {
> free(buf);
> return 0;
> }
> - /* skip header */
> - while (sp + 1 < buf + size &&
> - !(sp[0] == '\n' && sp[1] == '\n'))
> - sp++;
> /* only take up to "lines" lines, and strip the signature */
> for (i = 0, sp += 2;
> i < filter->lines && sp < buf + size &&
> --
> 1.5.3.5
>
> -
> To unsubscribe from this list: send the line "unsubscribe git" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* [PATCH v2] user-manual: add advanced topic "bisecting merges"
From: Steffen Prohaska @ 2007-11-07 21:50 UTC (permalink / raw)
To: gitster; +Cc: Ralf.Wildenhues, tsuna, git, Steffen Prohaska
In-Reply-To: <20071104112302.GA2119@ins.uni-bonn.de>
This commits adds a discussion of the challenge of bisecting
merge commits to the user manual. The text is slightly
adapted from a mail by Junio C Hamano <gitster@pobox.com>
to the mailing list
<http://marc.info/?l=git&m=119403257315527&w=2>.
The discussion is added to "Exploring git history" in a
sub-section titled "Advanced topics". The discussion requires
detailed knowledge about git. It is assumed that the reader will
skip advanced topics on first reading. At least the text suggest
to do so.
Signed-off-by: Steffen Prohaska <prohaska@zib.de>
---
Documentation/user-manual.txt | 89 +++++++++++++++++++++++++++++++++++++++++
1 files changed, 89 insertions(+), 0 deletions(-)
Some minor errors were fixed. Thanks to <Ralf.Wildenhues@gmx.de>.
I kept the naming of the commits. Benoit Sigoure suggested to choose
a different naming which he claims would be easier to remember.
I'm not convinced. The current naming starts with X, Y, Z on the left
and names the remaining commits on the right with A, B, C, D. This
is simple and give sufficient orientation.
Steffen
diff --git a/Documentation/user-manual.txt b/Documentation/user-manual.txt
index d99adc6..d0e738e 100644
--- a/Documentation/user-manual.txt
+++ b/Documentation/user-manual.txt
@@ -934,6 +934,95 @@ Figuring out why this works is left as an exercise to the (advanced)
student. The gitlink:git-log[1], gitlink:git-diff-tree[1], and
gitlink:git-hash-object[1] man pages may prove helpful.
+[[history-advanced-topics]]
+Advanced topics
+---------------
+This section covers advanced topics that typically require more
+knowledge about git than the manual presented to this point.
+
+You may want to skip the section at first reading, and come back
+later when you have a better understanding of git.
+
+[[bisect-merges]]
+Why bisecting merge commits can be harder than bisecting linear history
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+The following text is based upon an email by Junio C. Hamano to
+the git mailing list
+(link:http://marc.info/?l=git&m=119403257315527&w=2[link:http://marc.info/?l=git&m=119403257315527&w=2]).
+It was slightly adapted for this manual.
+
+Bisecting merges can be challenging due to the complexity of
+changes introduced at a merge. Bisecting through merges is not a
+technical problem. The real problem is what to do when the
+culprit turns out to be a merge commit. How to spot what really
+is wrong, and figure out how to fix. The problem is not for the
+tool but for the human, and it is real.
+
+Imagine this history.
+
+................................................
+ ---Z---o---X---...---o---A---C---D
+ \ /
+ o---o---Y---...---o---B
+................................................
+
+Suppose that on the upper development line, the meaning of one
+of the functions that existed at Z was changed at commit X. The
+commits from Z leading to A change both the function's
+implementation and all calling sites that existed at Z, as well
+as new calling sites they add, to be consistent. There is no
+bug at A.
+
+Suppose in the meantime the lower development line somebody
+added a new calling site for that function at commit Y. The
+commits from Z leading to B all assume the old semantics of that
+function and the callers and the callee are consistent with each
+other. There is no bug at B, either.
+
+You merge to create C. There is no textual conflict with this
+three way merge, and the result merges cleanly. You bisect
+this, because you found D is bad and you know Z was good. Your
+bisect will find that C (merge) is broken. Understandably so,
+as at C, the new calling site of the function added by the lower
+branch is not converted to the new semantics, while all the
+other calling sites that already existed at Z would have been
+converted by the merge. The new calling site has semantic
+adjustment needed, but you do not know that yet. You need to
+find out that that is the cause of the breakage by looking at the
+merge commit C and the history leading to it.
+
+How would you do that?
+
+Both "git diff A C" and "git diff B C" would be an enormous patch.
+Each of them essentially shows the whole change on each branch
+since they diverged. The developers may have well behaved to
+create good commits that follow the "commit small, commit often,
+commit well contained units" mantra, and each individual commit
+leading from Z to A and from Z to B may be easy to review and
+understand, but looking at these small and easily reviewable
+steps alone would not let you spot the breakage. You need to
+have a global picture of what the upper branch did (and
+among many, one of them is to change the semantics of that
+particular function) and look first at the huge "diff A C"
+(which shows the change the lower branch introduces), and see if
+that huge change is consistent with what have been done between
+Z and A.
+
+If you linearize the history by rebasing the lower branch on
+top of the upper, instead of merging, the bug becomes much easier to
+find and understand. Your history would instead be:
+
+................................................................
+ ---Z---o---X--...---o---A---o---o---Y*--...---o---B*--D*
+................................................................
+
+and there is a single commit Y* between A and B* that introduced
+the new calling site that still uses the old semantics of the
+function, even though that was already modified at X. "git show
+Y*" will be a much smaller patch than "git diff A C" and it is
+much easier to deal with.
+
+
[[Developing-with-git]]
Developing with git
===================
--
1.5.3.5.578.g886d
^ permalink raw reply related
* Re: [PATCH] Make git-clean a builtin
From: Junio C Hamano @ 2007-11-07 21:49 UTC (permalink / raw)
To: Brian Downing; +Cc: Johannes Schindelin, Shawn Bohrer, gitster, git
In-Reply-To: <20071107205101.GE6212@lavos.net>
bdowning@lavos.net (Brian Downing) writes:
> This makes sense (to me), as at most you're only adding one extra line
> for the final closing brace, and it makes the whole conditional look more
> "balanced", IMHO.
>
> But regardless, whatever the actual style for Git should be followed.
> Life's too short for arguments about coding style (even if divergence
> from K&R brace style is just plain wrong. :)
Ok. We do not have any particularly strong technical reason to
deviate from the kernel style. Let's follow that.
^ permalink raw reply
* Re: [PATCH 1/9] gitk i18n implementation: Add Makefile with rules for po file creation and installation.
From: Christian Stimming @ 2007-11-07 22:18 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Paul Mackerras, git
In-Reply-To: <7vbqa5ag7s.fsf@gitster.siamese.dyndns.org>
Am Mittwoch, 7. November 2007 22:38 schrieb Junio C Hamano:
> Christian Stimming <stimming@tuhh.de> writes:
> > The compiled .msg files will be installed into $(sharedir)/gitk/lib/msgs
> > according to Junio's mailing list proposal on 2007-07-28.
> > ---
> > These patches are against master of gitk.git at git.kernel.org.
> >
>
> There is a slight issue of merging this into git.git, as the
> initial "coolest merge ever" was done with the understanding
> that gitk will remain a single file project.
>
> The simplest way without using submodule (because it would
> require everybody who follow git.git to update to 1.5.3 or
> later, which I'd rather not to do at this point yet) would be to
> merge gitk.git with the subtree strategy to a subdirectory,
> which I think will be what I'll end up doing.
Yes, merging with subtree strategy to a subdirectory was exactly what you
proposed here http://marc.info/?l=git&m=118559853016496&w=2 and Paul agreed
upon here http://marc.info/?l=git&m=118560371427209&w=2 .
Regards,
Christian
^ permalink raw reply
* Re: [PATCH v2] Add Documentation/CodingStyle
From: Robin Rosenberg @ 2007-11-07 21:43 UTC (permalink / raw)
To: Johannes Schindelin
Cc: Andreas Ericsson, Junio C Hamano, Ralf Wildenhues, git
In-Reply-To: <Pine.LNX.4.64.0711071456440.4362@racer.site>
onsdag 07 november 2007 skrev Johannes Schindelin:
> diff --git a/Documentation/CodingStyle b/Documentation/CodingStyle
> new file mode 100644
> index 0000000..38a3d9f
> --- /dev/null
> +++ b/Documentation/CodingStyle
> @@ -0,0 +1,103 @@
> +As a popular project, we also have some guidelines to keep to the
> +code. For git in general, two rough rules are:
> +
> + - Most importantly, we never say "It's in POSIX; we'll happily
> + screw your system that does not conform." We live in the
> + real world.
Can we use less offensive wording in documentation than we do on the list or IRC?
I'm not hurt by it but it doesn't look serious.
> + - Try to keep to 80 characters per line
less than?
> +
> + - When declaring pointers, the star sides with the variable name, i.e.
> + "char *string", not "char* string" or "char * string". This makes
> + it easier to understand "char *string, c;"
Rationale: The C syntax is defined the way it is. C programmers should
understand it.
I'd amend: Don't mix different types in declarations.
Write:
char *string;
char c;
Rather than:
char *string,c;
> + - Do not use curly brackets unnecessarily. I.e.
> +
> + if (bla) {
> + x = 1;
> + }
> +
> + is frowned upon. A gray area is when the statement extends over a
> + few lines, and/or you have a lengthy comment atop of it.
Avoid unnecessary curly brackets but use them if unsure. (This is less
strict than "do not". There are cases where we do want "unnecessary"
brackets.
-- robin
^ permalink raw reply
* Re: [PATCH 1/9] gitk i18n implementation: Add Makefile with rules for po file creation and installation.
From: Junio C Hamano @ 2007-11-07 21:38 UTC (permalink / raw)
To: Christian Stimming; +Cc: Paul Mackerras, git
In-Reply-To: <200711071839.08570.stimming@tuhh.de>
Christian Stimming <stimming@tuhh.de> writes:
> The compiled .msg files will be installed into $(sharedir)/gitk/lib/msgs
> according to Junio's mailing list proposal on 2007-07-28.
> ---
> These patches are against master of gitk.git at git.kernel.org.
>
> Just in case any of the mailers might mess up whitespaces, I've also
> attached all 9 patches in the attached tarball.
>
> Makefile | 45 +++++++++++++++++++++++++++++++++++++++++++++
> 1 files changed, 45 insertions(+), 0 deletions(-)
> create mode 100644 Makefile
There is a slight issue of merging this into git.git, as the
initial "coolest merge ever" was done with the understanding
that gitk will remain a single file project.
The simplest way without using submodule (because it would
require everybody who follow git.git to update to 1.5.3 or
later, which I'd rather not to do at this point yet) would be to
merge gitk.git with the subtree strategy to a subdirectory,
which I think will be what I'll end up doing.
^ permalink raw reply
* Re: git pull opinion
From: Aghiles @ 2007-11-07 21:25 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Bill Lear, Junio C Hamano, git
In-Reply-To: <alpine.LFD.0.999.0711060812170.15101@woody.linux-foundation.org>
On 11/6/07, Linus Torvalds <torvalds@linux-foundation.org> wrote:
> Git does merge with a dirty directory too, but refuses to merge if it
> needs to *change* any individual dirty *files*.
Understood.
> [...]
> Now, I do think that we could relax the rule so that "files that are
> modified must be clean in the working tree" could instead become "files
> that actually don't merge _trivially_ must be clean in the working tree".
> But basically, if it's not a trivial merge, then since it's done in the
> working tree, the working tree has to be clean (or the merge would
> overwrite it).
>[...]
I really think this is a good idea. It seems to me that the first "bad"
surprise a svn/cvs/bk user will have is the result of a "git pull" command
on a dirty tree. With the proposed change, and if I understand correctly:
- users that are used to commit often and fetch into clean trees
will never be bothered by this change.
- users that are used to "update" often are expecting to resolve
conflicts in their working copy anyway.
In both cases git does not get in your way and everyone is happy.
- Aghiles
^ permalink raw reply
* [PATCH] git-stash: Fix listing stashes
From: Emil Medve @ 2007-11-07 21:10 UTC (permalink / raw)
To: gitster, nanako3, git; +Cc: Emil Medve
Commit bc9e7399af3790918140c30a5b2c85bf9a8f1ad3 "reverted" commit
f12e925ac23ad6169e046cfe05b8438a1611ad58
Signed-off-by: Emil Medve <Emilian.Medve@Freescale.com>
---
git-stash.sh | 6 +++++-
1 files changed, 5 insertions(+), 1 deletions(-)
diff --git a/git-stash.sh b/git-stash.sh
index e556f42..534eb16 100755
--- a/git-stash.sh
+++ b/git-stash.sh
@@ -22,7 +22,7 @@ no_changes () {
clear_stash () {
if current=$(git rev-parse --verify $ref_stash 2>/dev/null)
then
- git update-ref -d refs/stash $current
+ git update-ref -d $ref_stash $current
fi
}
@@ -93,6 +93,10 @@ save_stash () {
clear_stash || die "Cannot initialize stash"
create_stash "$stash_msg"
+
+ # Make sure the reflog for stash is kept.
+ : >>"$GIT_DIR/logs/$ref_stash"
+
git update-ref -m "$stash_msg" $ref_stash $w_commit ||
die "Cannot save the current status"
printf >&2 'Saved "%s"\n' "$stash_msg"
--
1.5.3.GIT
^ permalink raw reply related
* Re: [PATCH] Add missing inside_work_tree setting in setup_git_directory_gently
From: Johannes Schindelin @ 2007-11-07 20:54 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Nguyen Thai Ngoc Duy, git
In-Reply-To: <7vve8daisu.fsf@gitster.siamese.dyndns.org>
Hi,
On Wed, 7 Nov 2007, Junio C Hamano wrote:
> Nguyen Thai Ngoc Duy <pclouds@gmail.com> writes:
>
> > On Sat, Nov 03, 2007 at 09:33:40PM -0700, Junio C Hamano wrote:
> >>
> >> Please add automated test script for this, thanks.
> >
> > Thank you for reminding. I tried to put a test in
> > t1501-worktree.sh and found out core.worktree can override
> > inside_work_tree previously set by setup_git_directory_gently(),
> > activating the worktree code in setup_git_directory() again.
> >
> > This made me think setup_git_directory_gently() should use
> > get_git_work_tree() instead. But then git_work_tree_cfg may not be
> > initialized when get_git_work_tree() is called (starting from
> > setup_git_directory(), git_work_tree_cfg is initialized in
> > check_repository_format_version(), which is called _after_
> > setup_git_directory_gently()).
> >
> > The interaction between these variables and functions is really beyond
> > my knowledge. Johannes, can you have a look at this? In theory the
> > following test should pass:
> >
> > diff --git a/t/t1501-worktree.sh b/t/t1501-worktree.sh
> > index 7ee3820..bdb7720 100755
> > --- a/t/t1501-worktree.sh
> > +++ b/t/t1501-worktree.sh
> > @@ -103,6 +103,11 @@ test_expect_success 'repo finds its work tree from work tree, too' '
> > test sub/dir/tracked = "$(git ls-files)")
> > '
> >
> > +test_expect_success 'Try a command from subdir in worktree' '
> > + (cd repo.git/work/sub &&
> > + GIT_DIR=../.. GIT_WORK_TREE=.. git blame dir/tracked)
> > +'
> > +
> > test_expect_success '_gently() groks relative GIT_DIR & GIT_WORK_TREE' '
> > cd repo.git/work/sub/dir &&
> > GIT_DIR=../../.. GIT_WORK_TREE=../.. GIT_PAGER= \
>
> I am wondering what happened to this thread...
It is still in my inbox, waiting for a time where I can actually
concentrate.
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH] Make git-clean a builtin
From: Brian Downing @ 2007-11-07 20:51 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Shawn Bohrer, gitster, git
In-Reply-To: <Pine.LNX.4.64.0711071501270.4362@racer.site>
On Wed, Nov 07, 2007 at 03:04:52PM +0000, Johannes Schindelin wrote:
> I do count them. Personally, I find it highly distracting and ugly.
> Besides, we have the convention of putting the "}" not into the same line
> as "else". (See keyword "uncuddling" in the list archives.)
I was under the impression that Git followed the kernel coding standards,
which seem to want "cuddled" else statements:
136 Note that the closing brace is empty on a line of its own, _except_ in
137 the cases where it is followed by a continuation of the same statement,
138 ie a "while" in a do-statement or an "else" in an if-statement, like
139 this:
140
141 do {
142 body of do-loop
143 } while (condition);
144
145 and
146
147 if (x == y) {
148 ..
149 } else if (x > y) {
150 ...
151 } else {
152 ....
153 }
154
155 Rationale: K&R.
Searching the MARC list archives for "uncuddling" only yields the message
I am replying to.
In addition, the kernel style seems to want braces for all branches of
a conditional if any branch needs it:
163 Do not unnecessarily use braces where a single statement will do.
164
165 if (condition)
166 action();
167
168 This does not apply if one branch of a conditional statement is a single
169 statement. Use braces in both branches.
170
171 if (condition) {
172 do_this();
173 do_that();
174 } else {
175 otherwise();
176 }
This makes sense (to me), as at most you're only adding one extra line
for the final closing brace, and it makes the whole conditional look more
"balanced", IMHO.
But regardless, whatever the actual style for Git should be followed.
Life's too short for arguments about coding style (even if divergence
from K&R brace style is just plain wrong. :)
-bcd
^ permalink raw reply
* Re: [PATCH] Fix mistakes in the documentation of git-add --interactive.
From: Michele Ballabio @ 2007-11-07 20:50 UTC (permalink / raw)
To: git; +Cc: Benoit Sigoure, gitster
In-Reply-To: <1194459603-7988-1-git-send-email-tsuna@lrde.epita.fr>
On Wednesday 07 November 2007, Benoit Sigoure wrote:
> + d - do not the add change from that hunk and skip the remaining ones
add the
^^^^^^^
Swap these :)
^ permalink raw reply
* Re: [PATCH 3/3] pretty=format: Avoid some expensive calculations when not needed
From: Junio C Hamano @ 2007-11-07 20:43 UTC (permalink / raw)
To: René Scharfe; +Cc: Johannes Schindelin, git
In-Reply-To: <4730F5FA.3030705@lsrfire.ath.cx>
René Scharfe <rene.scharfe@lsrfire.ath.cx> writes:
> I haven't seen any comments on strbuf_expand. Is it too far out?
> Here it is again, adjusted for current master and with the changes
> to strbuf.[ch] coming first:
Numbers talk ;-).
In your previous round, you alluded that the strbuf_expand()
interface could allow caching of the return value of fn(), but I
do not think strbuf_expand() in this patch has anything to
directly support that notion.
Nor I would expect to --- fn() could keep the really expensive
information cached, keyed with context value, if it wanted to,
but in practice for the purpose of format_commit_item() I do not
offhand see anything cacheable and reusable, unless the user did
stupid things (e.g. use more than one %h in the format string).
I added a few paragraphs to describe the API in the commit log
message, and rewrote "# master" to "(master)" etc.
-- >8 --
pretty=format: Avoid some expensive calculations when not needed
This rewrites the custom format prettyprinter for commit objects
by introducing a new strbuf API function "strbuf_expand()".
The function takes a format string, list of placeholder strings,
a user supplied function 'fn', and an opaque pointer 'context'
to tell 'fn' what thingy to operate on.
The function 'fn' is expected to accept a strbuf, a parsed
placeholder string and the 'context' pointer, and append the
interpolated value for the 'context' thingy, according to the
format specified by the placeholder.
Here my measurements of most of Paul's test cases (best of
three runs):
(master)
$ time git log --pretty=oneline >/dev/null
...
^ permalink raw reply
* Re: [PATCH] send-email: apply --suppress-from to S-o-b and cc-cmd
From: Junio C Hamano @ 2007-11-07 20:43 UTC (permalink / raw)
To: Uwe Kleine-König; +Cc: git, Uwe Kleine-König, Ryan Anderson
In-Reply-To: <1194420852-15822-1-git-send-email-ukleinek@informatik.uni-freiburg.de>
Uwe Kleine-König <ukleinek@informatik.uni-freiburg.de> writes:
> From: Uwe Kleine-König <Uwe.Kleine-Koenig@digi.com>
>
> Signed-off-by: Uwe Kleine-König <Uwe.Kleine-Koenig@digi.com>
> Cc: Ryan Anderson <ryan@michonline.com>
> ---
> Hello,
>
> I don't see the sense in adding the sender to Cc: from Signed-off-by
> lines but not from From:. If someone is convinced it makes sense, I'm
> willing to send a new patch that uses a different option.
I _think_ --suppress-from just means "I know what I'll be
sending out, so do not bother my mailbox with a copy of this
message", so what the patch tries to do makes perfect sense to
me.
> @@ -730,6 +729,7 @@ foreach my $t (@files) {
> if (/^(Signed-off-by|Cc): (.*)$/i && $signed_off_cc) {
> my $c = $2;
> chomp $c;
> + next if ($c eq $sender and $suppress_from);
> push @cc, $c;
> printf("(sob) Adding cc: %s from line '%s'\n",
> $c, $_) unless $quiet;
> @@ -745,6 +745,7 @@ foreach my $t (@files) {
> my $c = $_;
> $c =~ s/^\s*//g;
> $c =~ s/\n$//g;
> + next if ($c eq $sender and $suppress_from);
> push @cc, $c;
> printf("(cc-cmd) Adding cc: %s from: '%s'\n",
> $c, $cc_cmd) unless $quiet;
By the way, I noticed that in the header part we pick CC: and
From: address, which are rfc2047 quoted, and unquote it to
compare with the sender. If they are different, we push the
address, still rfc2047 quoted, to @cc, like this:
} elsif (/^(Cc|From):\s+(.*)$/) {
if (unquote_rfc2047($2) eq $sender) {
next if ($suppress_from);
}
elsif ($1 eq 'From') {
$author = unquote_rfc2047($2);
}
printf("(mbox) Adding cc: %s from line '%s'\n",
$2, $_) unless $quiet;
push @cc, $2;
}
However, in the body part, when we see S-o-b: and CC: address,
which are _not_ rfc2047 quoted, do not unquote to compare with
$sender and we push it direct to @cc (the original text in the
first hunk of your patch). We do the same for output from
$cc_cmd if specified (the second hunk).
This means that @cc list would be a mixed bag. Some are rfc2047
quoted, and some are not. This inconsistency of course is taken
care of by the call to sanitize_address over @cc at the very
beginning of send_message(), but it somehow feels dirty.
^ permalink raw reply
* Re: [PATCH] Add missing inside_work_tree setting in setup_git_directory_gently
From: Junio C Hamano @ 2007-11-07 20:42 UTC (permalink / raw)
To: Nguyen Thai Ngoc Duy; +Cc: Johannes Schindelin, git
In-Reply-To: <20071104070307.GA26071@laptop>
Nguyen Thai Ngoc Duy <pclouds@gmail.com> writes:
> On Sat, Nov 03, 2007 at 09:33:40PM -0700, Junio C Hamano wrote:
>>
>> Please add automated test script for this, thanks.
>
> Thank you for reminding. I tried to put a test in
> t1501-worktree.sh and found out core.worktree can override
> inside_work_tree previously set by setup_git_directory_gently(),
> activating the worktree code in setup_git_directory() again.
>
> This made me think setup_git_directory_gently() should use
> get_git_work_tree() instead. But then git_work_tree_cfg may not be
> initialized when get_git_work_tree() is called (starting from
> setup_git_directory(), git_work_tree_cfg is initialized in
> check_repository_format_version(), which is called _after_
> setup_git_directory_gently()).
>
> The interaction between these variables and functions is really beyond
> my knowledge. Johannes, can you have a look at this? In theory the
> following test should pass:
>
> diff --git a/t/t1501-worktree.sh b/t/t1501-worktree.sh
> index 7ee3820..bdb7720 100755
> --- a/t/t1501-worktree.sh
> +++ b/t/t1501-worktree.sh
> @@ -103,6 +103,11 @@ test_expect_success 'repo finds its work tree from work tree, too' '
> test sub/dir/tracked = "$(git ls-files)")
> '
>
> +test_expect_success 'Try a command from subdir in worktree' '
> + (cd repo.git/work/sub &&
> + GIT_DIR=../.. GIT_WORK_TREE=.. git blame dir/tracked)
> +'
> +
> test_expect_success '_gently() groks relative GIT_DIR & GIT_WORK_TREE' '
> cd repo.git/work/sub/dir &&
> GIT_DIR=../../.. GIT_WORK_TREE=../.. GIT_PAGER= \
I am wondering what happened to this thread...
^ 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