* Re: [PATCH JGIT] Add "compare with Git Index" action.
From: Yann Simon @ 2009-03-13 10:28 UTC (permalink / raw)
To: Robin Rosenberg; +Cc: Shawn O. Pearce, git
In-Reply-To: <200903110022.53854.robin.rosenberg.lists@dewire.com>
2009/3/11 Robin Rosenberg <robin.rosenberg.lists@dewire.com>:
> Saving works, but the diff regions aren't updated on save.
Sorry, I do not understand. Can you explain me more?
> When there is a diff
> this would give us the partial staging similar to git gui, if only (not your fault) the
> commit dialog would allow us to make a distinction between changes in the
> workdir and the index.
Yes, I know that this patch is not very usefull for the moment.
I was more looking for a review as an inclusion.
And you found one bug. Thank you for that!
--
yann
^ permalink raw reply
* Re: git doc build failure on OS X 10.5.6 (Leopard) during xmlto phase
From: Michael J Gruber @ 2009-03-13 10:29 UTC (permalink / raw)
To: Todd Zullinger; +Cc: Alejandro Riveira, git, Jay Soffian, Tom Holaday
In-Reply-To: <20090312170931.GB19175@inocybe.teonanacatl.org>
Todd Zullinger venit, vidit, dixit 12.03.2009 18:09:
> Michael J Gruber wrote:
>> Following up on this:
>> On Fedora 10, I have asciidoc 8.2.5 and docbook 1.7.4 xsl's. For
>> proper man and html doc, I have to set DOCBOOK_XSL_172=Yes but leave
>> ASCIIDOC8 unset! I always forget, though (just like the packagers).
>
> Check the fedora git packages in rawhide, we don't set ASCIIDOC8. :)
I was unclear, but I meant forgetting to set DOCB... But:
> I experimented with that and found it did not improve things. We are
> only setting DOCBOOK_XSL_172. Without that, we get the '.ft C'
> droppings. With it, we get non-ascii characters in various places
> (where bold should be used to make the (1) notations stand out, for
> example). This was filed as:
>
> https://bugzilla.redhat.com/show_bug.cgi?id=485161
I hadn't noticed that yet (neither the effect nor the report). So, you
kept it unset intentionally and for a good reason. Please accept my apology!
>
> I didn't add DOCBOOK_XSL_172 to the F-10 packages yet, because I know
> that it fixes one problem and causes another. Either way, we'd be
> shipping packages with known brokeness. I chose to stick with keeping
> the currently broken '.ft C' behavior. Pick your poison. ;)
>
> One of the fedora/red hat folks that works on the xmlto and docbook
> packages was going to take a look, as I very much don't understand the
> documentation stack. :/
>
> Anyone who does is very welcome to help find the culprit(s) and help
> get fixes to the proper places.
So the easy solution is out again, quite a pitty. The problem occurs on
F10 as well as F11/rawhide, right?
On a related issue: Does anybody know which asciidoc versions need
asciidoc7compatible to be set? 8.2.5 and above certainly don't, so we
should not advise using it. asciidoc's hg repo doesn't go back much more
(the initial revision does not need it either), and I haven't dug for
their earlier history yet.
Michael J Gruber
^ permalink raw reply
* Re: Transparently encrypt repository contents with GPG
From: Michael J Gruber @ 2009-03-13 10:46 UTC (permalink / raw)
To: Sverre Rabbelier; +Cc: Matthias Nothhaft, git
In-Reply-To: <fabb9a1e0903121434u4a3d71bdi6277071f54557a7e@mail.gmail.com>
Sverre Rabbelier venit, vidit, dixit 12.03.2009 22:34:
> Heya,
>
> On Thu, Mar 12, 2009 at 22:19, Matthias Nothhaft
> <matthias.nothhaft@googlemail.com> > What I need is a way to
> automatically modify each file
>>
>> a) before it is written in the repository
>> b) after it is read from the repository
>
> Have a look at smudging, you might not need to touch the git source
> code at all ;).
>
And people asked me not to be cryptic... even though the OP explicitely
asked for encryption, of course ;)
"git help attributes" may help: look for filter and set attributes and
config (filter.$name.{clean,smudge}) accordingly. smudge should probably
decrypt, clean should encrypt.
BTW: Why not use an encrypted file system? That way your work tree would
be encrypted also.
Cheers,
Michael
^ permalink raw reply
* Re: Not pushing all branches?
From: Johannes Schindelin @ 2009-03-13 10:49 UTC (permalink / raw)
To: Peter Krefting; +Cc: Imran M Yousuf, git
In-Reply-To: <alpine.DEB.2.00.0903131043510.17450@perkele.intern.softwolves.pp.se>
Hi,
On Fri, 13 Mar 2009, Peter Krefting wrote:
> Imran M Yousuf:
>
> > Just try -
> > git push remote branch :)
>
> That is what I do. Unfortunately, the times I forged to name the branch,
> it pushes my master branch, which is different from the remote's, and I
> have to go to the other repository and reset it manually...
You can set
$ git config remote.<remote>.push invalid-branch-name
so that
$ git push <remote>
will give you an error.
Ciao,
Dscho
^ permalink raw reply
* Re: Not pushing all branches?
From: Johannes Schindelin @ 2009-03-13 10:51 UTC (permalink / raw)
To: John Tapsell; +Cc: Peter Krefting, git
In-Reply-To: <43d8ce650903130125m6335d189obbcdb86ec9036083@mail.gmail.com>
Hi,
On Fri, 13 Mar 2009, John Tapsell wrote:
> 2009/3/13 Peter Krefting <peter@softwolves.pp.se>:
>
> > Doing "git push remote" pushes all my local branches by default. Is
> > there a way to set it to *not* do that, and (for this particular
> > remote repository) just push the current branch?
>
> > Or failing that, not allow me to run "git push" without specifying a
> > branch?
>
> I've been pushing for this behaviour, and there was a patch a few days
> ago to do this. I'm not sure if it is/will be committed.
As Junio is a careful maintainer, he will not change anything radical
which would piss of a lot of people _without_ a proper, long-term plan
that gives users a chance.
I know, I once tried to push for something like that, and I am glad that
Junio is too wise as to make Git unstable for existing users.
Ciao,
Dscho
^ permalink raw reply
* Re: Generalised bisection
From: Johannes Schindelin @ 2009-03-13 10:55 UTC (permalink / raw)
To: Ealdwulf Wuffinga; +Cc: John Tapsell, Christian Couder, Git List, Ingo Molnar
In-Reply-To: <efe2b6d70903130258t2594b027m5812e9a5895f477e@mail.gmail.com>
Hi,
On Fri, 13 Mar 2009, Ealdwulf Wuffinga wrote:
> It is BayesianSearch_Debugging.pdf.
Now I'll only need a bayesian-search-for-original-url-in-mails.py.
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH][v2] http authentication via prompts (with correct line lengths)
From: Mike Ralphson @ 2009-03-13 10:53 UTC (permalink / raw)
To: Junio C Hamano, Daniel Stenberg; +Cc: Mike Gaffney, git
In-Reply-To: <7vsklihsti.fsf@gitster.siamese.dyndns.org>
2009/3/13 Junio C Hamano <gitster@pobox.com>:
> Yeah, I did this as "How about doing it this way without adding a band-aid
> configuration options" demonstration, and meant to clean it up (rather,
> meant to wait for the original submitter to clean-up) before moving it
> forward, but I forgot. Sorry about that.
>
> How does this look?
This patch fixes the build breakage for me, thanks. If I can find a
combination of AIX + working gcc + correct 32bit / non-broken 64bit
libraries + necessary Gnu tools + ancient curl + Apache2 in this maze
of twisty turny servers (all different) I'll give the http server
tests a whirl too.
2009/3/13 Daniel Stenberg <daniel@haxx.se>:
>Driven by use cases such as this, I also recently produced the
>"symbols-in-versions" document in the libcurl tree which should
> help apps to know what should works when:
> http://cool.haxx.se/cvs.cgi/curl/docs/libcurl/symbols-in-versions?rev=HEAD&content-type=text/vnd.viewcvs-markup
Very helpful, thanks.
Junio, if I check all the unprotected CURL* options against this list,
would that give us our absolute minimum supported version? If so,
would it then be ok to remove any unnecessary ifdefs for lower
versions if they exist?
Mike
^ permalink raw reply
* Re: Transparently encrypt repository contents with GPG
From: Sverre Rabbelier @ 2009-03-13 10:51 UTC (permalink / raw)
To: Michael J Gruber; +Cc: Matthias Nothhaft, git
In-Reply-To: <49BA39A1.9090203@drmicha.warpmail.net>
Heya,
On Fri, Mar 13, 2009 at 11:46, Michael J Gruber
<git@drmicha.warpmail.net> wrote:
> And people asked me not to be cryptic... even though the OP explicitely
> asked for encryption, of course ;)
I wasn't being cryptic, I just don't remember the details of smudge,
just that it exists, and that it allows you to perform operations on a
file on checkout and on add.
--
Cheers,
Sverre Rabbelier
^ permalink raw reply
* Re: Transparently encrypt repository contents with GPG
From: Thomas Rast @ 2009-03-13 11:15 UTC (permalink / raw)
To: Michael J Gruber; +Cc: Sverre Rabbelier, Matthias Nothhaft, git
In-Reply-To: <49BA39A1.9090203@drmicha.warpmail.net>
[-- Attachment #1: Type: text/plain, Size: 668 bytes --]
Michael J Gruber wrote:
> "git help attributes" may help: look for filter and set attributes and
> config (filter.$name.{clean,smudge}) accordingly. smudge should probably
> decrypt, clean should encrypt.
Wouldn't this trip over the randomness included in all encryption [to
avoid generating the same cyphertext for two separate identical
messages, which gives away some information], which would let git
think the file has been changed as soon as its stat info has changed
(or is just racy)?
Not to mention that this makes most source-oriented features such as
diff, blame, merge, etc., rather useless.
--
Thomas Rast
trast@{inf,student}.ethz.ch
[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Re: Transparently encrypt repository contents with GPG
From: Sverre Rabbelier @ 2009-03-13 11:17 UTC (permalink / raw)
To: Thomas Rast; +Cc: Michael J Gruber, Matthias Nothhaft, git
In-Reply-To: <200903131215.49336.trast@student.ethz.ch>
Heya,
On Fri, Mar 13, 2009 at 12:15, Thomas Rast <trast@student.ethz.ch> wrote:
> Not to mention that this makes most source-oriented features such as
> diff, blame, merge, etc., rather useless.
I would assume that smudge takes care of this somehow, it'd seem like
a rather useless feature otherwise :).
--
Cheers,
Sverre Rabbelier
^ permalink raw reply
* Re: Not pushing all branches?
From: Finn Arne Gangstad @ 2009-03-13 11:38 UTC (permalink / raw)
To: Peter Krefting; +Cc: Imran M Yousuf, git
In-Reply-To: <alpine.DEB.2.00.0903131043510.17450@perkele.intern.softwolves.pp.se>
On Fri, Mar 13, 2009 at 10:44:49AM +0100, Peter Krefting wrote:
> Imran M Yousuf:
>
>> Just try -
>> git push remote branch :)
>
> That is what I do. Unfortunately, the times I forged to name the branch,
> it pushes my master branch, which is different from the remote's, and I
> have to go to the other repository and reset it manually...
I sent a patch series a few days ago to fix this in various ways,
adding a configuration variable push.default, and also indicating that
pushing nothing rather than pushing all matching branches is a safer
(and saner) default.
As you have also discovered, it is very easy to accidentally push
master to the wrong remote with the current default behavior.
- Finn Arne
^ permalink raw reply
* [PATCH] test-suite: Make test script numbers unique
From: Johannes Sixt @ 2009-03-13 12:23 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Johannes Sixt
In order to selectively skip tests, the environment variable GIT_SKIP_TESTS
can be set like this:
$ GIT_SKIP_TESTS='t1301 t4150.18' make test
That is, its value can contain only the test script numbers, but not the
full script name. Therefore, it is important that the test scripts are
uniquely numbered. This makes it so.
Signed-off-by: Johannes Sixt <j6t@kdbg.org>
---
This applies to master. Today's next and pu do not have any new
duplicated numbers.
-- Hannes
t/{t3409-rebase-hook.sh => t3413-rebase-hook.sh} | 0
t/{t4017-quiet.sh => t4035-diff-quiet.sh} | 0
...r-mime.sh => t4036-format-patch-signer-mime.sh} | 0
t/{t4203-patch-id.sh => t4204-patch-id.sh} | 0
t/{t5521-pull-symlink.sh => t5522-pull-symlink.sh} | 0
...me-nocruft.sh => t6034-merge-rename-nocruft.sh} | 0
t/{t7502-status.sh => t7508-status.sh} | 0
...n-multi-glob.sh => t9109-git-svn-multi-glob.sh} | 0
....sh => t9137-git-svn-dcommit-clobber-series.sh} | 0
9 files changed, 0 insertions(+), 0 deletions(-)
rename t/{t3409-rebase-hook.sh => t3413-rebase-hook.sh} (100%)
rename t/{t4017-quiet.sh => t4035-diff-quiet.sh} (100%)
rename t/{t4021-format-patch-signer-mime.sh => t4036-format-patch-signer-mime.sh} (100%)
rename t/{t4203-patch-id.sh => t4204-patch-id.sh} (100%)
rename t/{t5521-pull-symlink.sh => t5522-pull-symlink.sh} (100%)
rename t/{t6023-merge-rename-nocruft.sh => t6034-merge-rename-nocruft.sh} (100%)
rename t/{t7502-status.sh => t7508-status.sh} (100%)
rename t/{t9108-git-svn-multi-glob.sh => t9109-git-svn-multi-glob.sh} (100%)
rename t/{t9106-git-svn-dcommit-clobber-series.sh => t9137-git-svn-dcommit-clobber-series.sh} (100%)
diff --git a/t/t3409-rebase-hook.sh b/t/t3413-rebase-hook.sh
similarity index 100%
rename from t/t3409-rebase-hook.sh
rename to t/t3413-rebase-hook.sh
diff --git a/t/t4017-quiet.sh b/t/t4035-diff-quiet.sh
similarity index 100%
rename from t/t4017-quiet.sh
rename to t/t4035-diff-quiet.sh
diff --git a/t/t4021-format-patch-signer-mime.sh b/t/t4036-format-patch-signer-mime.sh
similarity index 100%
rename from t/t4021-format-patch-signer-mime.sh
rename to t/t4036-format-patch-signer-mime.sh
diff --git a/t/t4203-patch-id.sh b/t/t4204-patch-id.sh
similarity index 100%
rename from t/t4203-patch-id.sh
rename to t/t4204-patch-id.sh
diff --git a/t/t5521-pull-symlink.sh b/t/t5522-pull-symlink.sh
similarity index 100%
rename from t/t5521-pull-symlink.sh
rename to t/t5522-pull-symlink.sh
diff --git a/t/t6023-merge-rename-nocruft.sh b/t/t6034-merge-rename-nocruft.sh
similarity index 100%
rename from t/t6023-merge-rename-nocruft.sh
rename to t/t6034-merge-rename-nocruft.sh
diff --git a/t/t7502-status.sh b/t/t7508-status.sh
similarity index 100%
rename from t/t7502-status.sh
rename to t/t7508-status.sh
diff --git a/t/t9108-git-svn-multi-glob.sh b/t/t9109-git-svn-multi-glob.sh
similarity index 100%
rename from t/t9108-git-svn-multi-glob.sh
rename to t/t9109-git-svn-multi-glob.sh
diff --git a/t/t9106-git-svn-dcommit-clobber-series.sh b/t/t9137-git-svn-dcommit-clobber-series.sh
similarity index 100%
rename from t/t9106-git-svn-dcommit-clobber-series.sh
rename to t/t9137-git-svn-dcommit-clobber-series.sh
--
1.6.2.127.g9cd69
^ permalink raw reply
* Re: Not pushing all branches?
From: John Tapsell @ 2009-03-13 12:37 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Peter Krefting, git
In-Reply-To: <alpine.DEB.1.00.0903131149200.10279@pacific.mpi-cbg.de>
2009/3/13 Johannes Schindelin <Johannes.Schindelin@gmx.de>:
> Hi,
>
> On Fri, 13 Mar 2009, John Tapsell wrote:
>
>> 2009/3/13 Peter Krefting <peter@softwolves.pp.se>:
>>
>> > Doing "git push remote" pushes all my local branches by default. Is
>> > there a way to set it to *not* do that, and (for this particular
>> > remote repository) just push the current branch?
>>
>> > Or failing that, not allow me to run "git push" without specifying a
>> > branch?
>>
>> I've been pushing for this behaviour, and there was a patch a few days
>> ago to do this. I'm not sure if it is/will be committed.
>
> As Junio is a careful maintainer, he will not change anything radical
> which would piss of a lot of people _without_ a proper, long-term plan
> that gives users a chance.
>
> I know, I once tried to push for something like that, and I am glad that
> Junio is too wise as to make Git unstable for existing users.
Understandable. There were 6 patches, only the last one changes the
default. Hopefully the first 5 will be applied and the 6 will
debated, then grudgingly applied :-)
John
^ permalink raw reply
* Re: Generalised bisection
From: John Tapsell @ 2009-03-13 12:42 UTC (permalink / raw)
To: Johannes Schindelin
Cc: Ealdwulf Wuffinga, Christian Couder, Git List, Ingo Molnar
In-Reply-To: <alpine.DEB.1.00.0903131154190.10279@pacific.mpi-cbg.de>
2009/3/13 Johannes Schindelin <Johannes.Schindelin@gmx.de>:
> Hi,
>
> On Fri, 13 Mar 2009, Ealdwulf Wuffinga wrote:
>
>> It is BayesianSearch_Debugging.pdf.
>
> Now I'll only need a bayesian-search-for-original-url-in-mails.py.
I managed to work it out:
http://github.com/Ealdwulf/bbchop.git/BBChop/doc/BayesianSearch_Debugging.pdf
John
^ permalink raw reply
* Re: [PATCH][v2] http authentication via prompts (with correct line lengths)
From: Mike Gaffney @ 2009-03-13 12:47 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Mike Ralphson, git
In-Reply-To: <7vsklihsti.fsf@gitster.siamese.dyndns.org>
I was going to try and clean this up this weekend or early next week. I'm also
trying to encourage open source submissions at work and was using this
as an example patch to get people going (we need the fix to use git). So
I do plan finishing this, just have to do it when I have time.
Daniel, thanks for the link, I had been wondering what was introduced when in curl.
-Mike
Junio C Hamano wrote:
> Mike Ralphson <mike.ralphson@gmail.com> writes:
>
>> Elsewhere we seem to protect use of CURL_NETRC_OPTIONAL by checking
>> for LIBCURL_VERSION_NUM >= 0x070907. I have an ancient curl here
>> (curl-7.9.3-2ssl) which doesn't seem to have this option, so building
>> next is broken on AIX for me from this morning (c33976cb).
>
> Yeah, I did this as "How about doing it this way without adding a band-aid
> configuration options" demonstration, and meant to clean it up (rather,
> meant to wait for the original submitter to clean-up) before moving it
> forward, but I forgot. Sorry about that.
>
> How does this look?
>
> http://curl.haxx.se/libcurl/c/curl_easy_setopt.html seems to say "added in
> 7.X.Y" for some options but does say when CURLOPT_USERPWD was added, so I
> am assuming it was available even in very early versions...
>
> -- >8 --
> From 750d9305009a0f3fd14c0b5c5e62ae1eb2b18fda Mon Sep 17 00:00:00 2001
> From: Junio C Hamano <gitster@pobox.com>
> Date: Thu, 12 Mar 2009 22:34:43 -0700
> Subject: [PATCH] http.c: CURLOPT_NETRC_OPTIONAL is not available in ancient versions of cURL
>
> Besides, we have already called easy_setopt with the option before coming
> to this function if it was available, so there is no need to repeat it
> here.
>
> Signed-off-by: Junio C Hamano <gitster@pobox.com>
> ---
> http.c | 4 +---
> 1 files changed, 1 insertions(+), 3 deletions(-)
>
> diff --git a/http.c b/http.c
> index b8f947e..2fc55d6 100644
> --- a/http.c
> +++ b/http.c
> @@ -138,9 +138,7 @@ static int http_options(const char *var, const char *value, void *cb)
>
> static void init_curl_http_auth(CURL *result)
> {
> - if (!user_name)
> - curl_easy_setopt(result, CURLOPT_NETRC, CURL_NETRC_OPTIONAL);
> - else {
> + if (user_name) {
> struct strbuf up = STRBUF_INIT;
> if (!user_pass)
> user_pass = xstrdup(getpass("Password: "));
--
-Mike Gaffney (http://rdocul.us)
^ permalink raw reply
* Re: Generalised bisection
From: Ealdwulf Wuffinga @ 2009-03-13 12:49 UTC (permalink / raw)
To: Steven Tweed
Cc: Johannes Schindelin, John Tapsell, Christian Couder, Git List
In-Reply-To: <d9c1caea0903121102y5452603fua0e7a1b82e121b01@mail.gmail.com>
On Thu, Mar 12, 2009 at 6:02 PM, Steven Tweed <orthochronous@gmail.com> wrote:
> I haven't even looked at the source code so a description of the
> mathematical algorithm would help, but I'll just point out that
> underflow (in the case of working with probabilities) and overflow
> (when working with their negated logarithms) is inherent in most
> multi-step Bayesian algorithms. The only solution is to rescale things
> as you go so that things stay in a "computable" range. (You're almost
> never interested in absolute probabilities anyway but rather relative
> probabilities or, in extreme cases, just the biggest probability, so
> rescaling isn't losing any useful information.)
Are you sure you aren't thinking of when you are using fixed point? I
was under the impression
that Bayesian algorithms usually worked okay in floating point.
One issue in BBChop which should be easy to fix, is that I use a dumb
way of calculating Beta functions. These
are ratios of factorials, so the subexpressions get stupidly big very
quickly. But I don't think that is the only problem.
Ealdwulf
^ permalink raw reply
* [PATCH] Remove unused assignments
From: Benjamin Kramer @ 2009-03-13 12:51 UTC (permalink / raw)
To: gitster; +Cc: git
These variables were always overwritten or the assigned
value was unused:
builtin-diff-tree.c::cmd_diff_tree(): nr_sha1
builtin-for-each-ref.c::opt_parse_sort(): sort_tail
builtin-mailinfo.c::decode_header_bq(): in
builtin-shortlog.c::insert_one_record(): len
connect.c::git_connect(): path
imap-send.c::v_issue_imap_cmd(): n
pretty.c::pp_user_info(): filler
remote::parse_refspec_internal(): llen
Signed-off-by: Benjamin Kramer <benny.kra@googlemail.com>
---
builtin-diff-tree.c | 1 -
builtin-for-each-ref.c | 1 -
builtin-mailinfo.c | 1 -
builtin-shortlog.c | 1 -
connect.c | 2 +-
imap-send.c | 2 +-
pretty.c | 1 -
remote.c | 2 +-
8 files changed, 3 insertions(+), 8 deletions(-)
diff --git a/builtin-diff-tree.c b/builtin-diff-tree.c
index 8ecefd4..79cedb7 100644
--- a/builtin-diff-tree.c
+++ b/builtin-diff-tree.c
@@ -102,7 +102,6 @@ int cmd_diff_tree(int argc, const char **argv, const char *prefix)
init_revisions(opt, prefix);
git_config(git_diff_basic_config, NULL); /* no "diff" UI options */
- nr_sha1 = 0;
opt->abbrev = 0;
opt->diff = 1;
argc = setup_revisions(argc, argv, opt, NULL);
diff --git a/builtin-for-each-ref.c b/builtin-for-each-ref.c
index e46b7ad..5cbb4b0 100644
--- a/builtin-for-each-ref.c
+++ b/builtin-for-each-ref.c
@@ -943,7 +943,6 @@ static int opt_parse_sort(const struct option *opt, const char *arg, int unset)
return -1;
*sort_tail = s = xcalloc(1, sizeof(*s));
- sort_tail = &s->next;
if (*arg == '-') {
s->reverse = 1;
diff --git a/builtin-mailinfo.c b/builtin-mailinfo.c
index 2789ccd..1eeeb4d 100644
--- a/builtin-mailinfo.c
+++ b/builtin-mailinfo.c
@@ -537,7 +537,6 @@ static int decode_header_bq(struct strbuf *it)
*/
strbuf_add(&outbuf, in, ep - in);
}
- in = ep;
}
/* E.g.
* ep : "=?iso-2022-jp?B?GyR...?= foo"
diff --git a/builtin-shortlog.c b/builtin-shortlog.c
index badd912..b28091b 100644
--- a/builtin-shortlog.c
+++ b/builtin-shortlog.c
@@ -101,7 +101,6 @@ static void insert_one_record(struct shortlog *log,
}
while (*oneline && isspace(*oneline) && *oneline != '\n')
oneline++;
- len = eol - oneline;
format_subject(&subject, oneline, " ");
buffer = strbuf_detach(&subject, NULL);
diff --git a/connect.c b/connect.c
index 0a35cc1..7636bf9 100644
--- a/connect.c
+++ b/connect.c
@@ -504,7 +504,7 @@ struct child_process *git_connect(int fd[2], const char *url_orig,
const char *prog, int flags)
{
char *url = xstrdup(url_orig);
- char *host, *path = url;
+ char *host, *path;
char *end;
int c;
struct child_process *conn;
diff --git a/imap-send.c b/imap-send.c
index cb518eb..8154cb2 100644
--- a/imap-send.c
+++ b/imap-send.c
@@ -579,7 +579,7 @@ static struct imap_cmd *v_issue_imap_cmd(struct imap_store *ctx,
n = socket_write(&imap->buf.sock, cmd->cb.data, cmd->cb.dlen);
free(cmd->cb.data);
if (n != cmd->cb.dlen ||
- (n = socket_write(&imap->buf.sock, "\r\n", 2)) != 2) {
+ socket_write(&imap->buf.sock, "\r\n", 2) != 2) {
free(cmd->cmd);
free(cmd);
return NULL;
diff --git a/pretty.c b/pretty.c
index c018408..3a24cd5 100644
--- a/pretty.c
+++ b/pretty.c
@@ -154,7 +154,6 @@ void pp_user_info(const char *what, enum cmit_fmt fmt, struct strbuf *sb,
while (line < name_tail && isspace(name_tail[-1]))
name_tail--;
display_name_length = name_tail - line;
- filler = "";
strbuf_addstr(sb, "From: ");
add_rfc2047(sb, line, display_name_length, encoding);
strbuf_add(sb, name_tail, namelen - display_name_length);
diff --git a/remote.c b/remote.c
index d7079c6..7efaa02 100644
--- a/remote.c
+++ b/remote.c
@@ -495,7 +495,7 @@ static struct refspec *parse_refspec_internal(int nr_refspec, const char **refsp
int is_glob;
const char *lhs, *rhs;
- llen = is_glob = 0;
+ is_glob = 0;
lhs = refspec[i];
if (*lhs == '+') {
--
1.6.2.169.g92418
^ permalink raw reply related
* Re: Honoring a checked out gitattributes file
From: Kristian Amlie @ 2009-03-13 13:24 UTC (permalink / raw)
To: git
In-Reply-To: <49B8DD1D.3060908@viscovery.net>
Ok, here's another round. I fixed the test case to expect failure, as
pointed out by Matthieu, and I also added code to make sure that
.gitattributes gets checked out first.
I also added a test case and some code to support the case where
.gitattributes is removed in a commit, but this doesn't work properly
yet (see commit message). I'm not sure how to solve this without
resolving to ugly hacks like passing the new index_state* all the way
down to where git_checkattr gets called. If anybody has any
suggestions, do share.
The main usecase where .gitattributes is modified, is anyway covered
by this patch.
--
Kristian
^ permalink raw reply
* [PATCH 1/2] Add a test for checking whether gitattributes is honored by checkout.
From: Kristian Amlie @ 2009-03-13 13:24 UTC (permalink / raw)
To: git; +Cc: Kristian Amlie
In-Reply-To: <1236950656-1967-1-git-send-email-kristian.amlie@nokia.com>
The original bug will not honor new entries in gitattributes if they
are changed in the same checkout as the files they affect.
It will also keep using .gitattributes, even if it is deleted in the
same commit as the files it affects.
---
t/t2013-checkout-crlf.sh | 41 +++++++++++++++++++++++++++++++++++++++++
1 files changed, 41 insertions(+), 0 deletions(-)
create mode 100755 t/t2013-checkout-crlf.sh
diff --git a/t/t2013-checkout-crlf.sh b/t/t2013-checkout-crlf.sh
new file mode 100755
index 0000000..d9d6465
--- /dev/null
+++ b/t/t2013-checkout-crlf.sh
@@ -0,0 +1,41 @@
+#!/bin/sh
+
+test_description='checkout should honor .gitattributes'
+
+. ./test-lib.sh
+
+test_expect_success 'setup' '
+
+ git config core.autocrlf true &&
+ printf ".file2 -crlf\r\n" > .gitattributes &&
+ git add .gitattributes &&
+ git commit -m initial &&
+ printf ".file -crlf\n" >> .gitattributes &&
+ printf "contents\n" > .file &&
+ git add .gitattributes .file &&
+ git commit -m second &&
+ git rm .gitattributes &&
+ printf "contents\r\n" > .file2 &&
+ git add .file2 &&
+ git commit -m third
+
+'
+
+test_expect_failure 'checkout with existing .gitattributes' '
+
+ git checkout master~2 &&
+ git checkout master~1 &&
+ test "$(git diff-files --raw)" = ""
+
+'
+
+test_expect_failure 'checkout when deleting .gitattributes' '
+
+ git checkout master~1 &&
+ git checkout master &&
+ test "$(stat -c %s .file2)" = "10"
+
+'
+
+test_done
+
--
1.6.1.1
^ permalink raw reply related
* [PATCH 2/2] Make Git respect changes to .gitattributes during checkout.
From: Kristian Amlie @ 2009-03-13 13:24 UTC (permalink / raw)
To: git; +Cc: Kristian Amlie
In-Reply-To: <1236950656-1967-2-git-send-email-kristian.amlie@nokia.com>
The fix is twofold:
First, we force .gitattributes files to always be the first ones
checked out. This is the part in check_updates().
Second, we make sure that the checked out attributes get honored by
popping off elements on the attribute stack, until we reach the level
where a new .gitattributes was checked out. The next time someone
calls git_checkattr(), it will reconstruct the attributes from that
point.
Note that in unlink_entry() there is code to support the case where
.gitattributes is removed (test case #3 in t2013-checkout-crlf.sh),
but this doesn't work properly because Git tries to read new
attributes from the index, but the old index (where .gitattributes
still exists) is still active.
---
attr.c | 86 +++++++++++++++++++++++++++++++++++++++------
attr.h | 1 +
entry.c | 19 ++++++++++
t/t2013-checkout-crlf.sh | 2 +-
unpack-trees.c | 77 +++++++++++++++++++++++++++++++----------
5 files changed, 154 insertions(+), 31 deletions(-)
diff --git a/attr.c b/attr.c
index 17f6a4d..2bc0847 100644
--- a/attr.c
+++ b/attr.c
@@ -455,6 +455,23 @@ static void bootstrap_attr_stack(void)
}
}
+static void pop_attr_stack(const char *path, int dirlen)
+{
+ struct attr_stack *elem;
+ while (attr_stack && attr_stack->origin) {
+ int namelen = strlen(attr_stack->origin);
+
+ elem = attr_stack;
+ if (namelen <= dirlen &&
+ !strncmp(elem->origin, path, namelen))
+ break;
+
+ debug_pop(elem);
+ attr_stack = elem->prev;
+ free_attr_elem(elem);
+ }
+}
+
static void prepare_attr_stack(const char *path, int dirlen)
{
struct attr_stack *elem, *info;
@@ -489,18 +506,7 @@ static void prepare_attr_stack(const char *path, int dirlen)
* Pop the ones from directories that are not the prefix of
* the path we are checking.
*/
- while (attr_stack && attr_stack->origin) {
- int namelen = strlen(attr_stack->origin);
-
- elem = attr_stack;
- if (namelen <= dirlen &&
- !strncmp(elem->origin, path, namelen))
- break;
-
- debug_pop(elem);
- attr_stack = elem->prev;
- free_attr_elem(elem);
- }
+ pop_attr_stack(path, dirlen);
/*
* Read from parent directories and push them down
@@ -642,3 +648,59 @@ int git_checkattr(const char *path, int num, struct git_attr_check *check)
return 0;
}
+
+void git_attr_invalidate_path(const char *path)
+{
+ int dirlen;
+ const char *cp;
+ struct attr_stack *info, *elem;
+
+ bootstrap_attr_stack();
+
+ /*
+ * Pop the "info" one that is always at the top of the stack.
+ */
+ info = attr_stack;
+ attr_stack = info->prev;
+
+ cp = strrchr(path, '/');
+ dirlen = cp ? cp - path : 0;
+ /* Pop everything up to, and including, path. */
+ pop_attr_stack(path, dirlen);
+
+ if (!strcmp(path, "") && attr_stack->origin && !strcmp(attr_stack->origin, "")) {
+ /*
+ * Special handling when the root attributes must be invalidated.
+ * Note that we cannot reread the attributes here. The reason is that
+ * when unlinking the root .gitattributes file, the index entry is
+ * removed after unlinking. If we reread the attributes here, we
+ * would get the same attributes as before because .gitattributes
+ * is still in the index. Thus we must wait until the next call to
+ * read_attr, when the index has been updated.
+ */
+ /* $GIT_DIR/info/attributes */
+ elem = info;
+ debug_pop(elem);
+ free_attr_elem(elem);
+
+ /* $GIT_WORK_TREE/.gitattributes */
+ elem = attr_stack;
+ debug_pop(elem);
+ attr_stack = elem->prev;
+ free_attr_elem(elem);
+
+ /* builtins */
+ elem = attr_stack;
+ debug_pop(elem);
+ attr_stack = elem->prev;
+ free_attr_elem(elem);
+
+ assert(!attr_stack);
+ } else {
+ /*
+ * Finally push the "info" one at the top of the stack.
+ */
+ info->prev = attr_stack;
+ attr_stack = info;
+ }
+}
diff --git a/attr.h b/attr.h
index f1c2038..8f4135b 100644
--- a/attr.h
+++ b/attr.h
@@ -30,5 +30,6 @@ struct git_attr_check {
};
int git_checkattr(const char *path, int, struct git_attr_check *);
+void git_attr_invalidate_path(const char *path);
#endif /* ATTR_H */
diff --git a/entry.c b/entry.c
index 05aa58d..7fb27fd 100644
--- a/entry.c
+++ b/entry.c
@@ -1,6 +1,7 @@
#include "cache.h"
#include "blob.h"
#include "dir.h"
+#include "attr.h"
static void create_directories(const char *path, const struct checkout *state)
{
@@ -91,6 +92,9 @@ static int write_entry(struct cache_entry *ce, char *path, const struct checkout
{
int fd;
long wrote;
+ int gitattrlen;
+ int pathlen;
+ char *cp;
switch (ce->ce_mode & S_IFMT) {
char *new;
@@ -171,6 +175,21 @@ static int write_entry(struct cache_entry *ce, char *path, const struct checkout
return error("git checkout-index: unknown file mode for %s", path);
}
+ gitattrlen = strlen(GITATTRIBUTES_FILE);
+ pathlen = strlen(path);
+ if (pathlen >= gitattrlen && !strncmp(path + pathlen - gitattrlen,
+ GITATTRIBUTES_FILE, gitattrlen)) {
+ /* Invalidate attributes if a new .gitattributes file was checked out. */
+ cp = strrchr(path, '/');
+ if (!cp) {
+ git_attr_invalidate_path("");
+ } else {
+ *cp = '\0';
+ git_attr_invalidate_path(path);
+ *cp = '/';
+ }
+ }
+
if (state->refresh_cache) {
struct stat st;
lstat(ce->name, &st);
diff --git a/t/t2013-checkout-crlf.sh b/t/t2013-checkout-crlf.sh
index d9d6465..e704c93 100755
--- a/t/t2013-checkout-crlf.sh
+++ b/t/t2013-checkout-crlf.sh
@@ -21,7 +21,7 @@ test_expect_success 'setup' '
'
-test_expect_failure 'checkout with existing .gitattributes' '
+test_expect_success 'checkout with existing .gitattributes' '
git checkout master~2 &&
git checkout master~1 &&
diff --git a/unpack-trees.c b/unpack-trees.c
index e547282..63a41f8 100644
--- a/unpack-trees.c
+++ b/unpack-trees.c
@@ -7,6 +7,7 @@
#include "unpack-trees.h"
#include "progress.h"
#include "refs.h"
+#include "attr.h"
/*
* Error messages expected by scripts out of plumbing commands such as
@@ -60,6 +61,7 @@ static void unlink_entry(struct cache_entry *ce)
{
char *cp, *prev;
char *name = ce->name;
+ int namelen, gitattrlen;
if (has_symlink_or_noent_leading_path(ce_namelen(ce), ce->name))
return;
@@ -82,6 +84,21 @@ static void unlink_entry(struct cache_entry *ce)
}
prev = cp;
}
+
+ if (!prev) {
+ gitattrlen = strlen(GITATTRIBUTES_FILE);
+ namelen = strlen(name);
+ if (namelen >= gitattrlen && !strncmp(name + namelen - gitattrlen,
+ GITATTRIBUTES_FILE, gitattrlen)) {
+ if (cp) {
+ *cp = '\0';
+ git_attr_invalidate_path(name);
+ *cp = '/';
+ } else {
+ git_attr_invalidate_path("");
+ }
+ }
+ }
}
static struct checkout state;
@@ -92,6 +109,9 @@ static int check_updates(struct unpack_trees_options *o)
struct index_state *index = &o->result;
int i;
int errs = 0;
+ int attr;
+ int gitattrlen;
+ int namelen;
if (o->update && o->verbose_update) {
for (total = cnt = 0; cnt < index->cache_nr; cnt++) {
@@ -105,27 +125,48 @@ static int check_updates(struct unpack_trees_options *o)
cnt = 0;
}
- for (i = 0; i < index->cache_nr; i++) {
- struct cache_entry *ce = index->cache[i];
+ gitattrlen = strlen(GITATTRIBUTES_FILE);
- if (ce->ce_flags & CE_REMOVE) {
- display_progress(progress, ++cnt);
- if (o->update)
- unlink_entry(ce);
- remove_index_entry_at(&o->result, i);
- i--;
- continue;
+ /*
+ * We want to checkout .gitattributes before everything else. So:
+ * attr == 0 -> .gitattributes
+ * attr == 1 -> everything else
+ */
+ for (attr = 0; attr < 2; attr++) {
+ for (i = 0; i < index->cache_nr; i++) {
+ struct cache_entry *ce = index->cache[i];
+
+ namelen = strlen(ce->name);
+ if ((attr == 0) != (namelen >= gitattrlen && strncmp(
+ ce->name + namelen - gitattrlen,
+ GITATTRIBUTES_FILE, gitattrlen) == 0))
+ continue;
+ if (ce->ce_flags & CE_REMOVE) {
+ display_progress(progress, ++cnt);
+ if (o->update)
+ unlink_entry(ce);
+ remove_index_entry_at(&o->result, i);
+ i--;
+ continue;
+ }
}
}
- for (i = 0; i < index->cache_nr; i++) {
- struct cache_entry *ce = index->cache[i];
+ for (attr = 0; attr < 2; attr++) {
+ for (i = 0; i < index->cache_nr; i++) {
+ struct cache_entry *ce = index->cache[i];
- if (ce->ce_flags & CE_UPDATE) {
- display_progress(progress, ++cnt);
- ce->ce_flags &= ~CE_UPDATE;
- if (o->update) {
- errs |= checkout_entry(ce, &state, NULL);
+ namelen = strlen(ce->name);
+ if ((attr == 0) != (namelen >= gitattrlen && strncmp(
+ ce->name + namelen - gitattrlen,
+ GITATTRIBUTES_FILE, gitattrlen) == 0))
+ continue;
+ if (ce->ce_flags & CE_UPDATE) {
+ display_progress(progress, ++cnt);
+ ce->ce_flags &= ~CE_UPDATE;
+ if (o->update) {
+ errs |= checkout_entry(ce, &state, NULL);
+ }
}
}
}
--
1.6.1.1
^ permalink raw reply related
* RE: newb: Given a commit id, find which branches have it as an ancestor
From: Kelly F. Hickel @ 2009-03-13 13:30 UTC (permalink / raw)
To: Johannes Sixt; +Cc: git
In-Reply-To: <49BA07E5.2080701@viscovery.net>
> -----Original Message-----
> From: Johannes Sixt [mailto:j.sixt@viscovery.net]
> Sent: Friday, March 13, 2009 2:15 AM
> To: Kelly F. Hickel
> Cc: git@vger.kernel.org
> Subject: Re: newb: Given a commit id, find which branches have it as
an
> ancestor
>
> Kelly F. Hickel schrieb:
> >> From: git-owner@vger.kernel.org [mailto:git-owner@vger.kernel.org]
> On
> >> Behalf Of Johannes Sixt
> >> Sent: Thursday, March 12, 2009 10:38 AM
> >> To: Kelly F. Hickel
> >
> >> $ git branch -a --contains the-sha1
> >>
> >> -- Hannes
> >>
> >
> > Thanks, that looks like a really useful command.
> >
> > Unfortunately, in this case it didn't print anything out (neither
did
> > "git branch -r -a sha1").
> >
> > What I'm beginning to suspect is that all the commits that should
> have
> > gone to master went to some unnamed branch.
> > Is that reasonable/possible/likely? This commit has a full
ancestry,
> > but doesn't appear to be on any branch.
> >
> > In the above question there's an assumption that if a branch exists
> > without a name, then git branch -a --contains wouldn't print
anything
> > out, is that correct?
>
> Correct.
>
> Your best bet is perhaps that you create a branch at the commit
>
> $ git branch tmp-branch your_sha1
>
> so that the commits are not lost, then you cherry-pick them to master.
>
> -- Hannes
Thanks, in the end it turned out that I just hadn't properly understood
the
Comment about doing your own merge in the git-cvsimport doc. For
whatever
reason, when doing cvsimport in a workspace on master, after the import
I
have to do "git merge origin/master" and it fast forwards it and all is
well.
I *don't* have to do that for any of the other branches that get
affected by
the cvsimport, so that threw me for awhile.
Thanks for the help,
Kelly
^ permalink raw reply
* RE: newb: Given a commit id, find which branches have it as an ancestor
From: Kelly F. Hickel @ 2009-03-13 13:31 UTC (permalink / raw)
To: Junio C Hamano, Johannes Sixt; +Cc: git
In-Reply-To: <7v3adhj2ku.fsf@gitster.siamese.dyndns.org>
> -----Original Message-----
> From: Junio C Hamano [mailto:gitster@pobox.com]
> Sent: Friday, March 13, 2009 2:37 AM
> To: Johannes Sixt
> Cc: Kelly F. Hickel; git@vger.kernel.org
> Subject: Re: newb: Given a commit id, find which branches have it as
an
> ancestor
>
> Johannes Sixt <j.sixt@viscovery.net> writes:
>
> > Your best bet is perhaps that you create a branch at the commit
> >
> > $ git branch tmp-branch your_sha1
> >
> > so that the commits are not lost, then you cherry-pick them to
> master.
>
> It could be that there are more commits that are built on top of the
> one
> you are aware of. Finding unreachable commits from "git fsck --full"
> might help you find them.
Thanks, turned out to be my misunderstanding of how to do incremental
imports
(see my response to Johannes).
Thanks for the help,
-Kelly
^ permalink raw reply
* Re: Not pushing all branches?
From: Johannes Schindelin @ 2009-03-13 13:53 UTC (permalink / raw)
To: John Tapsell; +Cc: Peter Krefting, git
In-Reply-To: <43d8ce650903130537r2459e1d2pef8fffc1c9b3fa5e@mail.gmail.com>
Hi,
On Fri, 13 Mar 2009, John Tapsell wrote:
> Hopefully the first 5 will be applied and the 6 will debated, then
> grudgingly applied :-)
No. If it has to be applied grudgingly, it is most likely wrong.
Ciao,
Dscho
^ permalink raw reply
* Re: Generalised bisection
From: Johannes Schindelin @ 2009-03-13 13:56 UTC (permalink / raw)
To: John Tapsell; +Cc: Ealdwulf Wuffinga, Christian Couder, Git List, Ingo Molnar
In-Reply-To: <43d8ce650903130542o4125fef3rdddea4a31c23aa30@mail.gmail.com>
Hi,
On Fri, 13 Mar 2009, John Tapsell wrote:
> 2009/3/13 Johannes Schindelin <Johannes.Schindelin@gmx.de>:
>
> > On Fri, 13 Mar 2009, Ealdwulf Wuffinga wrote:
> >
> >> It is BayesianSearch_Debugging.pdf.
> >
> > Now I'll only need a bayesian-search-for-original-url-in-mails.py.
>
> I managed to work it out:
>
> http://github.com/Ealdwulf/bbchop.git/BBChop/doc/BayesianSearch_Debugging.pdf
Thanks, very much appreciated,
Dscho
^ permalink raw reply
* Re: Not pushing all branches?
From: John Tapsell @ 2009-03-13 13:56 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Peter Krefting, git
In-Reply-To: <alpine.DEB.1.00.0903131452390.6288@intel-tinevez-2-302>
2009/3/13 Johannes Schindelin <Johannes.Schindelin@gmx.de>:
> Hi,
>
> On Fri, 13 Mar 2009, John Tapsell wrote:
>
>> Hopefully the first 5 will be applied and the 6 will debated, then
>> grudgingly applied :-)
>
> No. If it has to be applied grudgingly, it is most likely wrong.
If there's an email about this every week from yet another person that
has been bitten by the current default, then the current default is
most likely wrong :-)
John
^ 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