* Re: builtin conversion between tabs and spaces
From: Alex Riesen @ 2008-10-15 6:25 UTC (permalink / raw)
To: Stefan Karpinski; +Cc: Git Mailing List
In-Reply-To: <d4bc1a2a0810141844x76223e76xf04e07ece834fc61@mail.gmail.com>
Stefan Karpinski, Wed, Oct 15, 2008 03:44:10 +0200:
> I find myself really wanting to enforce standards in the use of spaces
> versus tabs. I deal with some unruly programmers who refuse to set
> their editors to use soft tabs, but I *hate* tabs in the repo. And of
> course others feel equally strongly about keeping only tabs in the
> repo (e.g. the git repo).
>
> This led me to wonder if it wouldn't make sense to have this
> conversion ability built into git. The following patch implements this
> functionality. It still needs work—it's not meant to be final, just to
> give an idea—but I just wanted to see if people on the git list
> thought this sort of thing would be worthwhile at all.
Is your conversion two-way? IOW, is it possible to convert the
converted file and get the original? (Because all the existing
conversions are reversible)
^ permalink raw reply
* Re: [PATCH] Fix mkpath abuse in dwim_ref/sha1_name.c
From: Alex Riesen @ 2008-10-15 6:20 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Git Mailing List, Shawn O. Pearce
In-Reply-To: <7viqru6a1r.fsf@gitster.siamese.dyndns.org>
Junio C Hamano, Wed, Oct 15, 2008 01:17:52 +0200:
> "Alex Riesen" <raa.lkml@gmail.com> writes:
> >
> > Otherwise the function sometimes fail to resolve obviously correct refnames,
> > because the string data pointed to by "ref" argument were reused.
> >
> But your patch instead rewrites the computation of str2 by bypassing the
> call to "another_function_that_uses_get_pathname()" and duplicating its
> logic, which I do not think is a viable approach in the longer term.
There is not enough logic to bypass there. It's just a dumb sprintf!
I actually saved a useless call (two, if automatic inlining
optimization doesn't work).
> > diff --git a/sha1_name.c b/sha1_name.c
> > index 41b6809..b5b53bf 100644
> > --- a/sha1_name.c
> > +++ b/sha1_name.c
> > @@ -242,6 +242,7 @@ int dwim_ref(const char *str, int len, unsigned char *sha1, char **ref)
> > {
> > const char **p, *r;
> > int refs_found = 0;
> > + char fullref[PATH_MAX];
> >
> > *ref = NULL;
> > for (p = ref_rev_parse_rules; *p; p++) {
> > @@ -249,7 +250,8 @@ int dwim_ref(const char *str, int len, unsigned char *sha1, char **ref)
> > unsigned char *this_result;
> >
> > this_result = refs_found ? sha1_from_ref : sha1;
> > - r = resolve_ref(mkpath(*p, len, str), this_result, 1, NULL);
> > + snprintf(fullref, sizeof(fullref), *p, len, str);
> > + r = resolve_ref(fullref, this_result, 1, NULL);
> > if (r) {
> > if (!refs_found++)
> > *ref = xstrdup(r);
>
> I suspect that I am grossly misleading the code, but I wonder why this xstrdup()
> is not protecting us from the reusing of "the string data pointed to by
> "ref" argument". Are you fixing the overwriting of the string pointed to
> by "str" argument instead?
Yes, I mistyped. xstrdup's called after the breakage happened.
> What specific call chain has this breakage you found?
That's up to this function from builtin_rev_parse and resolve_ref
we're about to call.
^ permalink raw reply
* Re: [PATCH try 2] t1301-shared-repo.sh: don't let a default ACL interfere with the test
From: Johannes Sixt @ 2008-10-15 6:13 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Matt McCutchen, git
In-Reply-To: <7vzll66c5u.fsf@gitster.siamese.dyndns.org>
Junio C Hamano schrieb:
> Matt McCutchen <matt@mattmccutchen.net> writes:
>> diff --git a/t/t1301-shared-repo.sh b/t/t1301-shared-repo.sh
>> index dc85e8b..2275caa 100755
>> --- a/t/t1301-shared-repo.sh
>> +++ b/t/t1301-shared-repo.sh
>> @@ -7,6 +7,9 @@ test_description='Test shared repository initialization'
>>
>> . ./test-lib.sh
>>
>> +# Remove a default ACL from the test dir if possible.
>> +setfacl -k . 2>/dev/null
>> +
>
> Makes me wonder why this is _not_ inside test-lib.sh where it creates the
> test (trash) directory. That way, you would cover future tests that wants
> to see a saner/simpler POSIX permission behaviour, wouldn't you?
But that would also paper over unanticipated bad interactions with strange
ACLs that people might set, wouldn't it? By not placing this into
test-lib.sh there is a higher chance that such an interaction is revealed,
and we can react on it (educate users or fix the code).
-- Hannes
^ permalink raw reply
* Updating Submodules
From: benhill @ 2008-10-15 5:51 UTC (permalink / raw)
To: git
Heyah Folks.
So I have been playing with this for a few hours, and I must be missing
something.
I have created a submodule in my super project with the standard commands:
git submodule add <repo> <path>
No problem. Repo Loads. I push it to origin (github) and the little arrow
designating it as a sub is there.
Then one of my colleagues checks out the super and runs:
git submodule init
git submodule add
...no problems thus far...the repo loads as planned.
The she makes some changes to the submodule, checks them in, pushes them to
origin (also github).
Now, if she tried to check in changes to the super...it is no longer just
the submodule ref that she is checking in...but the whole tree....like it
adds all the files in the submodule to the super...if she were to push to
github, the little arrow would be gone..and the whole tree is there.
What am I doing wrong here? How do you make updates to supers to point to
the head revision of the sub?
Thanks for any help.
Ben
--
View this message in context: http://www.nabble.com/Updating-Submodules-tp19987153p19987153.html
Sent from the git mailing list archive at Nabble.com.
^ permalink raw reply
* Re: tip tree clone fail
From: H. Peter Anvin @ 2008-10-15 5:25 UTC (permalink / raw)
To: Wang Chen
Cc: Ingo Molnar, Petr Baudis, Thomas Gleixner, FNST-Lai Jiangshan,
FJ-KOSAKI Motohiro, git, Junio C Hamano
In-Reply-To: <48F566C4.2050905@cn.fujitsu.com>
Wang Chen wrote:
>
> Yes. My clone is successful. Thanks, Peter.
> But, after cloning, git-pull failed because of conflict.
> I think maybe because Ingo rebased his tree?
> ---
> Auto-merged init/main.c
> CONFLICT (content): Merge conflict in init/main.c
> Auto-merged scripts/bootgraph.pl
> CONFLICT (add/add): Merge conflict in scripts/bootgraph.pl
> Removed sound/soc/at91/eti_b1_wm8731.c
> Automatic merge failed; fix conflicts and then commit the result.
> ---
Yes, the master branch on tip is not rebase-free.
-hpa
^ permalink raw reply
* [PATCH] Fix reading of cloud tags
From: Junio C Hamano @ 2008-10-15 4:27 UTC (permalink / raw)
To: Petr Baudis; +Cc: git, Shawn O. Pearce
In-Reply-To: <20081014000812.GZ4856@spearce.org>
The projectroot path could have SP in it, in which case iterating over
<$git_dir/ctags/*> does not correctly enumerate the cloud tags files at
all.
This can be observed by creating an empty t/trash directory and running
t9500 test. The $projectroot ends with "trash directory.t9500-gitweb-/"
and <$glob> would give "trash", which can be opened and reading from it
immediately yields undef, which in turn gives an undef value warning to
the standard error stream upon attempt to chomp it.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
---
gitweb/gitweb.perl | 4 +++-
1 files changed, 3 insertions(+), 1 deletions(-)
diff --git c/gitweb/gitweb.perl w/gitweb/gitweb.perl
index 1116800..577c041 100755
--- c/gitweb/gitweb.perl
+++ w/gitweb/gitweb.perl
@@ -1805,7 +1805,8 @@ sub git_get_project_ctags {
my $ctags = {};
$git_dir = "$projectroot/$path";
- foreach (<$git_dir/ctags/*>) {
+ opendir D, "$git_dir/ctags";
+ foreach (grep { -f $_ } map { "$git_dir/ctags/$_" } readdir(D)) {
open CT, $_ or next;
my $val = <CT>;
chomp $val;
@@ -1813,6 +1814,7 @@ sub git_get_project_ctags {
my $ctag = $_; $ctag =~ s#.*/##;
$ctags->{$ctag} = $val;
}
+ closedir D;
$ctags;
}
^ permalink raw reply related
* Re: tip tree clone fail
From: Wang Chen @ 2008-10-15 3:43 UTC (permalink / raw)
To: H. Peter Anvin
Cc: Ingo Molnar, Petr Baudis, Thomas Gleixner, FNST-Lai Jiangshan,
FJ-KOSAKI Motohiro, git, Junio C Hamano
In-Reply-To: <48F37073.1030808@zytor.com>
H. Peter Anvin said the following on 2008-10-13 23:59:
> Wang Chen wrote:
>>
>> Ingo, thank you for your work.
>> I can clone more, but error still occurs:
>>
>> Getting alternates list for
>> http://www.kernel.org/pub/scm/linux/kernel/git/x86/linux-2.6-tip.git
>> Also look at
>> http://www.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git/
>> Also look at
>> http://www.kernel.org/pub/scm/linux/kernel/git/sfr/linux-next.git/
>> Getting pack list for
>> http://www.kernel.org/pub/scm/linux/kernel/git/x86/linux-2.6-tip.git
>> error: transfer closed with 8280 bytes remaining to read
>> Getting pack list for
>> http://www.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git/
>> Getting pack list for
>> http://www.kernel.org/pub/scm/linux/kernel/git/sfr/linux-next.git/
>> error: Unable to find 95630fe2917f805a26f8d8beaafb80cd2f729eb5 under
>> http://www.kernel.org/pub/scm/linux/kernel/git/x86/linux-2.6-tip.git
>> Cannot obtain needed object 95630fe2917f805a26f8d8beaafb80cd2f729eb5
>
> I cleaned it up and it should work now.
>
Yes. My clone is successful. Thanks, Peter.
But, after cloning, git-pull failed because of conflict.
I think maybe because Ingo rebased his tree?
---
Auto-merged init/main.c
CONFLICT (content): Merge conflict in init/main.c
Auto-merged scripts/bootgraph.pl
CONFLICT (add/add): Merge conflict in scripts/bootgraph.pl
Removed sound/soc/at91/eti_b1_wm8731.c
Automatic merge failed; fix conflicts and then commit the result.
---
^ permalink raw reply
* Re: builtin conversion between tabs and spaces
From: Stefan Karpinski @ 2008-10-15 1:47 UTC (permalink / raw)
To: Git Mailing List
In-Reply-To: <d4bc1a2a0810141844x76223e76xf04e07ece834fc61@mail.gmail.com>
Appologies for gmail mangling. I will use git send-email for real patches.
On Tue, Oct 14, 2008 at 6:44 PM, Stefan Karpinski
<stefan.karpinski@gmail.com> wrote:
> I find myself really wanting to enforce standards in the use of spaces
> versus tabs. I deal with some unruly programmers who refuse to set
> their editors to use soft tabs, but I *hate* tabs in the repo. And of
> course others feel equally strongly about keeping only tabs in the
> repo (e.g. the git repo).
>
> This led me to wonder if it wouldn't make sense to have this
> conversion ability built into git. The following patch implements this
> functionality. It still needs work—it's not meant to be final, just to
> give an idea—but I just wanted to see if people on the git list
> thought this sort of thing would be worthwhile at all.
>
> If people think it's worth having in git, then how should it be
> configured? I feel like a project should be able to define the
> expected tab size for binary file types. Moreover, the project should
> be able to define the default cannonicalization with resepect to
> whitespace for different files types. Then, if they so desire, each
> git user should be able to override the output format on a
> per-repository basis.
>
> Does this make any sense? Comments?
>
> ---
> diff --git a/convert.c b/convert.c
> index 1816e97..280f45b 100644
> --- a/convert.c
> +++ b/convert.c
> @@ -18,7 +18,7 @@
>
> struct text_stat {
> /* NUL, CR, LF and CRLF counts */
> - unsigned nul, cr, lf, crlf;
> + unsigned nul, cr, lf, crlf, tab;
>
> /* These are just approximations! */
> unsigned printable, nonprintable;
> @@ -48,7 +48,10 @@
> static void gather_stats(const char *buf, unsigned long size, struct
> text_stat *
> else if (c < 32) {
> switch (c) {
> /* BS, HT, ESC and FF */
> - case '\b': case '\t': case '\033': case '\014':
> + case '\t':
> + stats->tab++;
> + /* fall through */
> + case '\b': case '\033': case '\014':
> stats->printable++;
> break;
> case 0:
> @@ -235,6 +238,105 @@
> static int crlf_to_worktree(const char *path, const char *src, size_t len,
> return 1;
> }
>
> +static int tabs_to_spaces(const char *path, const char *src, size_t len,
> +
> struct strbuf *buf, int untabify)
> +{
> + char *to_free = NULL;
> + struct text_stat stats;
> + static const unsigned tab_size = 4;
> + char *spaces;
> +
> + if (!untabify)
> + return 0;
> +
> + /* instead of calling twice, should cache these stats across calls */
> + gather_stats(src, len, &stats);
> +
> + if (!stats.tab)
> + return 0;
> +
> + /* are we "faking" in place editing ? */
> + if (src == buf->buf)
> + to_free = strbuf_detach(buf, NULL);
> +
> + /* this growth may be excessive: not all tabs get tab_size spaces */
> + strbuf_grow(buf, len + tab_size * stats.tab);
> + spaces = (char *) xmalloc(tab_size);
> + memset(spaces, ' ', tab_size);
> + for (;;) {
> + const char *line = src;
> + const char *nl = memchr(src, '\n', len);
> + char *tab;
> + if (!nl)
> + nl = src + len;
> + while (src < nl && (tab = memchr(src, '\t', nl - src))) {
> + strbuf_add(buf, src, tab - src);
> + strbuf_add(buf, spaces, tab_size - ((tab - line) % tab_size));
> + src = tab + 1;
> + }
> + if (src < nl)
> + strbuf_add(buf, src, nl - src);
> + if (nl < src + len)
> + strbuf_addch(buf, '\n');
> + else
> + break;
> + src = nl + 1;
> + len -= src - line;
> + }
> +
> + free(to_free);
> + free(spaces);
> + return 1;
> +}
> +
> +static int spaces_to_tabs(const char *path, const char *src, size_t len,
> +
> struct strbuf *buf, int tabify)
> +{
> + static const unsigned tab_size = 4;
> +
> + if (!tabify)
> + return 0;
> +
> + /* only grow if not in place */
> + if (strbuf_avail(buf) + buf->len < len)
> + strbuf_grow(buf, len - buf->len);
> +
> + for (;;) {
> + int tabs = 0, spaces = 0;
> + const char *line = src;
> + const char *nl = memchr(src, '\n', len);
> + if (!nl)
> + nl = src + len;
> + for (;; src++) {
> + if (*src == ' ') {
> + spaces++;
> + if (spaces == tab_size) {
> + tabs++;
> + spaces = 0;
> + }
> + } else if (*src == '\t') {
> + tabs++;
> + spaces = 0;
> + } else break;
> + }
> + if (line < src) {
> + memset(buf->buf + buf->len, '\t', tabs);
> + memset(buf->buf + buf->len + tabs, ' ', spaces);
> + strbuf_setlen(buf, buf->len + tabs + spaces);
> + }
> + if (src < nl)
> + strbuf_add(buf, src, nl - src);
> + if (nl < src + len)
> + strbuf_addch(buf, '\n');
> + else
> + break;
> + src = nl + 1;
> + len -= src - line;
> + }
> +
> + return 1;
> +}
> +
> struct filter_params {
> const char *src;
> unsigned long size;
> @@ -370,22 +472,29 @@
> static int read_convert_config(const char *var, const char *value, void *cb)
> return 0;
> }
>
> -static void setup_convert_check(struct git_attr_check *check)
> +struct convert_checks {
> + struct git_attr_check crlf, tabs, ident, filter;
> +};
> +
> +static void setup_convert_check(struct convert_checks *checks)
> {
> static struct git_attr *attr_crlf;
> + static struct git_attr *attr_tabs;
> static struct git_attr *attr_ident;
> static struct git_attr *attr_filter;
>
> if (!attr_crlf) {
> attr_crlf = git_attr("crlf", 4);
> + attr_tabs = git_attr("tabs", 4);
> attr_ident = git_attr("ident", 5);
> attr_filter = git_attr("filter", 6);
> user_convert_tail = &user_convert;
> git_config(read_convert_config, NULL);
> }
> - check[0].attr = attr_crlf;
> - check[1].attr = attr_ident;
> - check[2].attr = attr_filter;
> + checks->crlf.attr = attr_crlf;
> + checks->tabs.attr = attr_tabs;
> + checks->ident.attr = attr_ident;
> + checks->filter.attr = attr_filter;
> }
>
> static int count_ident(const char *cp, unsigned long size)
> @@ -566,20 +675,22 @@
> static int git_path_check_ident(const char *path, struct git_attr_check *check)
> return !!ATTR_TRUE(value);
> }
>
> +#define CHECK_ARRAY_SIZE (sizeof(struct convert_checks)/sizeof(struct
> git_attr_check))
> +
> int convert_to_git(const char *path, const char *src, size_t len,
> struct strbuf *dst, enum safe_crlf checksafe)
> {
> - struct git_attr_check check[3];
> + struct convert_checks checks;
> int crlf = CRLF_GUESS;
> int ident = 0, ret = 0;
> const char *filter = NULL;
>
> - setup_convert_check(check);
> - if (!git_checkattr(path, ARRAY_SIZE(check), check)) {
> + setup_convert_check(&checks);
> + if (!git_checkattr(path, CHECK_ARRAY_SIZE, (struct git_attr_check *)
> &checks)) {
> struct convert_driver *drv;
> - crlf = git_path_check_crlf(path, check + 0);
> - ident = git_path_check_ident(path, check + 1);
> - drv = git_path_check_convert(path, check + 2);
> + crlf = git_path_check_crlf(path, &(checks.crlf));
> + ident = git_path_check_ident(path, &(checks.ident));
> + drv = git_path_check_convert(path, &(checks.filter));
> if (drv && drv->clean)
> filter = drv->clean;
> }
> @@ -589,6 +700,11 @@
> int convert_to_git(const char *path, const char *src, size_t len,
> src = dst->buf;
> len = dst->len;
> }
> + ret |= tabs_to_spaces(path, src, len, dst, 1); // get real variable
> + if (ret) {
> + src = dst->buf;
> + len = dst->len;
> + }
> ret |= crlf_to_git(path, src, len, dst, crlf, checksafe);
> if (ret) {
> src = dst->buf;
> @@ -599,17 +715,17 @@
> int convert_to_git(const char *path, const char *src, size_t len,
>
> int convert_to_working_tree(const char *path, const char *src, size_t
> len, struct strbuf *dst)
> {
> - struct git_attr_check check[3];
> + struct convert_checks checks;
> int crlf = CRLF_GUESS;
> int ident = 0, ret = 0;
> const char *filter = NULL;
>
> - setup_convert_check(check);
> - if (!git_checkattr(path, ARRAY_SIZE(check), check)) {
> + setup_convert_check(&checks);
> + if (!git_checkattr(path, CHECK_ARRAY_SIZE, (struct git_attr_check *)
> &checks)) {
> struct convert_driver *drv;
> - crlf = git_path_check_crlf(path, check + 0);
> - ident = git_path_check_ident(path, check + 1);
> - drv = git_path_check_convert(path, check + 2);
> + crlf = git_path_check_crlf(path, &(checks.crlf));
> + ident = git_path_check_ident(path, &(checks.ident));
> + drv = git_path_check_convert(path, &(checks.filter));
> if (drv && drv->smudge)
> filter = drv->smudge;
> }
> @@ -624,5 +740,10 @@
> int convert_to_working_tree(const char *path, const char *src, size_t
> len, struc
> src = dst->buf;
> len = dst->len;
> }
> + ret |= tabs_to_spaces(path, src, len, dst, 1); // get real variable
> + if (ret) {
> + src = dst->buf;
> + len = dst->len;
> + }
> return ret | apply_filter(path, src, len, dst, filter);
> }
>
^ permalink raw reply
* builtin conversion between tabs and spaces
From: Stefan Karpinski @ 2008-10-15 1:44 UTC (permalink / raw)
To: Git Mailing List
In-Reply-To: <d4bc1a2a0810141842q1e50c85au7d813f2e5e37a84c@mail.gmail.com>
I find myself really wanting to enforce standards in the use of spaces
versus tabs. I deal with some unruly programmers who refuse to set
their editors to use soft tabs, but I *hate* tabs in the repo. And of
course others feel equally strongly about keeping only tabs in the
repo (e.g. the git repo).
This led me to wonder if it wouldn't make sense to have this
conversion ability built into git. The following patch implements this
functionality. It still needs work—it's not meant to be final, just to
give an idea—but I just wanted to see if people on the git list
thought this sort of thing would be worthwhile at all.
If people think it's worth having in git, then how should it be
configured? I feel like a project should be able to define the
expected tab size for binary file types. Moreover, the project should
be able to define the default cannonicalization with resepect to
whitespace for different files types. Then, if they so desire, each
git user should be able to override the output format on a
per-repository basis.
Does this make any sense? Comments?
---
diff --git a/convert.c b/convert.c
index 1816e97..280f45b 100644
--- a/convert.c
+++ b/convert.c
@@ -18,7 +18,7 @@
struct text_stat {
/* NUL, CR, LF and CRLF counts */
- unsigned nul, cr, lf, crlf;
+ unsigned nul, cr, lf, crlf, tab;
/* These are just approximations! */
unsigned printable, nonprintable;
@@ -48,7 +48,10 @@
static void gather_stats(const char *buf, unsigned long size, struct
text_stat *
else if (c < 32) {
switch (c) {
/* BS, HT, ESC and FF */
- case '\b': case '\t': case '\033': case '\014':
+ case '\t':
+ stats->tab++;
+ /* fall through */
+ case '\b': case '\033': case '\014':
stats->printable++;
break;
case 0:
@@ -235,6 +238,105 @@
static int crlf_to_worktree(const char *path, const char *src, size_t len,
return 1;
}
+static int tabs_to_spaces(const char *path, const char *src, size_t len,
+
struct strbuf *buf, int untabify)
+{
+ char *to_free = NULL;
+ struct text_stat stats;
+ static const unsigned tab_size = 4;
+ char *spaces;
+
+ if (!untabify)
+ return 0;
+
+ /* instead of calling twice, should cache these stats across calls */
+ gather_stats(src, len, &stats);
+
+ if (!stats.tab)
+ return 0;
+
+ /* are we "faking" in place editing ? */
+ if (src == buf->buf)
+ to_free = strbuf_detach(buf, NULL);
+
+ /* this growth may be excessive: not all tabs get tab_size spaces */
+ strbuf_grow(buf, len + tab_size * stats.tab);
+ spaces = (char *) xmalloc(tab_size);
+ memset(spaces, ' ', tab_size);
+ for (;;) {
+ const char *line = src;
+ const char *nl = memchr(src, '\n', len);
+ char *tab;
+ if (!nl)
+ nl = src + len;
+ while (src < nl && (tab = memchr(src, '\t', nl - src))) {
+ strbuf_add(buf, src, tab - src);
+ strbuf_add(buf, spaces, tab_size - ((tab - line) % tab_size));
+ src = tab + 1;
+ }
+ if (src < nl)
+ strbuf_add(buf, src, nl - src);
+ if (nl < src + len)
+ strbuf_addch(buf, '\n');
+ else
+ break;
+ src = nl + 1;
+ len -= src - line;
+ }
+
+ free(to_free);
+ free(spaces);
+ return 1;
+}
+
+static int spaces_to_tabs(const char *path, const char *src, size_t len,
+
struct strbuf *buf, int tabify)
+{
+ static const unsigned tab_size = 4;
+
+ if (!tabify)
+ return 0;
+
+ /* only grow if not in place */
+ if (strbuf_avail(buf) + buf->len < len)
+ strbuf_grow(buf, len - buf->len);
+
+ for (;;) {
+ int tabs = 0, spaces = 0;
+ const char *line = src;
+ const char *nl = memchr(src, '\n', len);
+ if (!nl)
+ nl = src + len;
+ for (;; src++) {
+ if (*src == ' ') {
+ spaces++;
+ if (spaces == tab_size) {
+ tabs++;
+ spaces = 0;
+ }
+ } else if (*src == '\t') {
+ tabs++;
+ spaces = 0;
+ } else break;
+ }
+ if (line < src) {
+ memset(buf->buf + buf->len, '\t', tabs);
+ memset(buf->buf + buf->len + tabs, ' ', spaces);
+ strbuf_setlen(buf, buf->len + tabs + spaces);
+ }
+ if (src < nl)
+ strbuf_add(buf, src, nl - src);
+ if (nl < src + len)
+ strbuf_addch(buf, '\n');
+ else
+ break;
+ src = nl + 1;
+ len -= src - line;
+ }
+
+ return 1;
+}
+
struct filter_params {
const char *src;
unsigned long size;
@@ -370,22 +472,29 @@
static int read_convert_config(const char *var, const char *value, void *cb)
return 0;
}
-static void setup_convert_check(struct git_attr_check *check)
+struct convert_checks {
+ struct git_attr_check crlf, tabs, ident, filter;
+};
+
+static void setup_convert_check(struct convert_checks *checks)
{
static struct git_attr *attr_crlf;
+ static struct git_attr *attr_tabs;
static struct git_attr *attr_ident;
static struct git_attr *attr_filter;
if (!attr_crlf) {
attr_crlf = git_attr("crlf", 4);
+ attr_tabs = git_attr("tabs", 4);
attr_ident = git_attr("ident", 5);
attr_filter = git_attr("filter", 6);
user_convert_tail = &user_convert;
git_config(read_convert_config, NULL);
}
- check[0].attr = attr_crlf;
- check[1].attr = attr_ident;
- check[2].attr = attr_filter;
+ checks->crlf.attr = attr_crlf;
+ checks->tabs.attr = attr_tabs;
+ checks->ident.attr = attr_ident;
+ checks->filter.attr = attr_filter;
}
static int count_ident(const char *cp, unsigned long size)
@@ -566,20 +675,22 @@
static int git_path_check_ident(const char *path, struct git_attr_check *check)
return !!ATTR_TRUE(value);
}
+#define CHECK_ARRAY_SIZE (sizeof(struct convert_checks)/sizeof(struct
git_attr_check))
+
int convert_to_git(const char *path, const char *src, size_t len,
struct strbuf *dst, enum safe_crlf checksafe)
{
- struct git_attr_check check[3];
+ struct convert_checks checks;
int crlf = CRLF_GUESS;
int ident = 0, ret = 0;
const char *filter = NULL;
- setup_convert_check(check);
- if (!git_checkattr(path, ARRAY_SIZE(check), check)) {
+ setup_convert_check(&checks);
+ if (!git_checkattr(path, CHECK_ARRAY_SIZE, (struct git_attr_check *)
&checks)) {
struct convert_driver *drv;
- crlf = git_path_check_crlf(path, check + 0);
- ident = git_path_check_ident(path, check + 1);
- drv = git_path_check_convert(path, check + 2);
+ crlf = git_path_check_crlf(path, &(checks.crlf));
+ ident = git_path_check_ident(path, &(checks.ident));
+ drv = git_path_check_convert(path, &(checks.filter));
if (drv && drv->clean)
filter = drv->clean;
}
@@ -589,6 +700,11 @@
int convert_to_git(const char *path, const char *src, size_t len,
src = dst->buf;
len = dst->len;
}
+ ret |= tabs_to_spaces(path, src, len, dst, 1); // get real variable
+ if (ret) {
+ src = dst->buf;
+ len = dst->len;
+ }
ret |= crlf_to_git(path, src, len, dst, crlf, checksafe);
if (ret) {
src = dst->buf;
@@ -599,17 +715,17 @@
int convert_to_git(const char *path, const char *src, size_t len,
int convert_to_working_tree(const char *path, const char *src, size_t
len, struct strbuf *dst)
{
- struct git_attr_check check[3];
+ struct convert_checks checks;
int crlf = CRLF_GUESS;
int ident = 0, ret = 0;
const char *filter = NULL;
- setup_convert_check(check);
- if (!git_checkattr(path, ARRAY_SIZE(check), check)) {
+ setup_convert_check(&checks);
+ if (!git_checkattr(path, CHECK_ARRAY_SIZE, (struct git_attr_check *)
&checks)) {
struct convert_driver *drv;
- crlf = git_path_check_crlf(path, check + 0);
- ident = git_path_check_ident(path, check + 1);
- drv = git_path_check_convert(path, check + 2);
+ crlf = git_path_check_crlf(path, &(checks.crlf));
+ ident = git_path_check_ident(path, &(checks.ident));
+ drv = git_path_check_convert(path, &(checks.filter));
if (drv && drv->smudge)
filter = drv->smudge;
}
@@ -624,5 +740,10 @@
int convert_to_working_tree(const char *path, const char *src, size_t
len, struc
src = dst->buf;
len = dst->len;
}
+ ret |= tabs_to_spaces(path, src, len, dst, 1); // get real variable
+ if (ret) {
+ src = dst->buf;
+ len = dst->len;
+ }
return ret | apply_filter(path, src, len, dst, filter);
}
^ permalink raw reply related
* Re: [PATCH] Improve and fix git-check-attr(1)
From: Junio C Hamano @ 2008-10-14 23:58 UTC (permalink / raw)
To: Jonas Fonseca; +Cc: git
In-Reply-To: <20081013175705.GA9538@diku.dk>
Jonas Fonseca <fonseca@diku.dk> writes:
> Always use 'verse' for multi-line synopsis sections. Add output and
> example sections to document what output can be expected.
>
> Signed-off-by: Jonas Fonseca <fonseca@diku.dk>
>
> ---
> Documentation/git-check-attr.txt | 63 +++++++++++++++++++++++++++++++++++++-
> 1 files changed, 62 insertions(+), 1 deletions(-)
>
> At least the first chunk should be applied. The last is a quick attempt
> at documenting the expected output formally and with examples.
> ...
> tg: (340fcf4..) jf/man-git-check-attr (depends on: next)
Should this really have to depend on next? I have a feeling that a large
part of this (sans --stdin/-z) is a 'maint' material.
Could you split this into two patches, one for 'maint' to describe the
output format, and another for 'next' (or 'dp/checkattr') to update the
SYNOPSIS part?
^ permalink raw reply
* Re: [PATCH try 2] t1301-shared-repo.sh: don't let a default ACL interfere with the test
From: Deskin Miller @ 2008-10-14 23:45 UTC (permalink / raw)
To: Matt McCutchen; +Cc: Junio C Hamano, git
In-Reply-To: <1224025227.2699.13.camel@mattlaptop2.local>
On Tue, Oct 14, 2008 at 07:00:27PM -0400, Matt McCutchen wrote:
> On Tue, 2008-10-14 at 15:32 -0700, Junio C Hamano wrote:
> > Makes me wonder why this is _not_ inside test-lib.sh where it creates the
> > test (trash) directory. That way, you would cover future tests that wants
> > to see a saner/simpler POSIX permission behaviour, wouldn't you?
>
> Yes. However, I don't anticipate there being any tests specifically
> about file permissions other than t1301-shared-repo.sh, and if the user
> has set a default ACL on the git source tree, we might want to let trash
> directories obey that setting except in the one case where it breaks the
> test. What do you think?
I'll add a shameless plug for my patch: Fix testcase failure when extended
attributes are in use, available from Gmane at
http://thread.gmane.org/gmane.comp.version-control.git/98170
It's orthogonal to this patch, I think: this patch deals with ACLs overriding
the umask testing we're doing, while my patch deals with parsing the
permissions that ls returns, and applies to instances where extended attributes
are in use which we can't get rid of, like SELinux.
Deskin Miller
^ permalink raw reply
* Re: [PATCH] Fix mkpath abuse in dwim_ref/sha1_name.c
From: Junio C Hamano @ 2008-10-14 23:17 UTC (permalink / raw)
To: Alex Riesen; +Cc: Git Mailing List, Junio C Hamano, Shawn O. Pearce
In-Reply-To: <81b0412b0810140923x5cf58bb9x5acd1517a19e9847@mail.gmail.com>
"Alex Riesen" <raa.lkml@gmail.com> writes:
> From: Alex Riesen <raa.lkml@gmail.com>
> Date: Tue, 14 Oct 2008 18:14:20 +0200
> Subject: [PATCH] Fix mkpath abuse in sha1_name.c
>
> Otherwise the function sometimes fail to resolve obviously correct refnames,
> because the string data pointed to by "ref" argument were reused.
>
> Signed-off-by: Alex Riesen <raa.lkml@gmail.com>
The get_pathname() interface has been handy but it indeed is a bug waiting
to happen, and we have fixed occasional breakages by fixing the earlier
callers to stash the returned value away to keep it from getting
overwritten. I.e. when we have:
str1 = function_that_uses_get_pathname();
...
str2 = another_function_that_uses_get_pathname();
some_processing(str1, str2);
and we have too many other calls to functions that use get_pathname() in
the ... section, str1 will become invalid when we try to feed it to
some_processing(). So far our strategy to fix this kind of breakages has
been to rewrite the above to:
str1 = xstrdup(function_that_uses_get_pathname());
...
str2 = another_function_that_uses_get_pathname();
some_processing(str1, str2);
free(str1);
But your patch instead rewrites the computation of str2 by bypassing the
call to "another_function_that_uses_get_pathname()" and duplicating its
logic, which I do not think is a viable approach in the longer term.
> diff --git a/sha1_name.c b/sha1_name.c
> index 41b6809..b5b53bf 100644
> --- a/sha1_name.c
> +++ b/sha1_name.c
> @@ -242,6 +242,7 @@ int dwim_ref(const char *str, int len, unsigned char *sha1, char **ref)
> {
> const char **p, *r;
> int refs_found = 0;
> + char fullref[PATH_MAX];
>
> *ref = NULL;
> for (p = ref_rev_parse_rules; *p; p++) {
> @@ -249,7 +250,8 @@ int dwim_ref(const char *str, int len, unsigned char *sha1, char **ref)
> unsigned char *this_result;
>
> this_result = refs_found ? sha1_from_ref : sha1;
> - r = resolve_ref(mkpath(*p, len, str), this_result, 1, NULL);
> + snprintf(fullref, sizeof(fullref), *p, len, str);
> + r = resolve_ref(fullref, this_result, 1, NULL);
> if (r) {
> if (!refs_found++)
> *ref = xstrdup(r);
I suspect that I am grossly misleading the code, but I wonder why this xstrdup()
is not protecting us from the reusing of "the string data pointed to by
"ref" argument". Are you fixing the overwriting of the string pointed to
by "str" argument instead?
What specific call chain has this breakage you found?
^ permalink raw reply
* Re: Problem with CRLF line endings and colored diff
From: Jean-Luc Herren @ 2008-10-14 23:08 UTC (permalink / raw)
To: Junio C Hamano, Git List
In-Reply-To: <7v4p3e7r9e.fsf@gitster.siamese.dyndns.org>
Junio C Hamano wrote:
> Jean-Luc Herren <jlh@gmx.ch> writes:
>> <GREEN FOREGROUND>+<RESET><GREEN FOREGROUND>
>> line2<RESET><RED BACKGROUND><CR><RESET><LF>
>
> This is expected and deliberate, as you haven't told about your desire to
> consider carriage-returns not as line termination letter. By default CR
> is just one of the whitespace letters, and colored diff output is
> reminding you that you introduced a line with a trailing whitespace.
Ah, I see, I didn't know I have to tell it that I want to use
CRLF... Works fine now. Sorry for the noise.
jlh
^ permalink raw reply
* from symlinked directory: unable to chdir or not a git archive
From: Marcel M. Cary @ 2008-10-14 22:58 UTC (permalink / raw)
To: git
I'm getting an error:
fatal: 'origin': unable to chdir or not a git archive
when trying to pull even though pushing works just fine. So I don't
think the problem is that the remote repository doesn't exist. (I see
the entry in GitFaq for this error message, but I don't think that
answer quite explains this situation.)
I think it's important that, when pulling, I'm in a directory that is a
symlink into the Git working copy. Having git operate correctly in that
environment is important to me because Git doesn't support checking out
a subdirectory of my project.
A shell transcript follows that illustrates a simplified problem
scenario using Git 1.6.0.1. I see the same error message with 1.6.0.2
and 1.6.0.2.530.g67faa (master branch today).
Is there an easy way around this? Right now I have to cd to the target
of the symlink to do the pull, which is annoying.
Thanks,
Marcel
~/git$ mkdir tmp-repo
~/git$ cd tmp-repo/
~/git/tmp-repo$ git init
Initialized empty Git repository in /home/marcel/git/tmp-repo/.git/
~/git/tmp-repo$ mkdir foo
~/git/tmp-repo$ touch foo/bar
~/git/tmp-repo$ git add foo/bar
~/git/tmp-repo$ git commit -m 'Add empty file'
Created initial commit 651b80a: Add empty file
0 files changed, 0 insertions(+), 0 deletions(-)
create mode 100644 foo/bar
~/git/tmp-repo$ cd ..
~/git$ git clone tmp-repo clone-repo
Initialized empty Git repository in /home/marcel/git/clone-repo/.git/
~/git$ ln -s clone-repo/foo/ foo-link
~/git$ cd foo-link/
~/git/foo-link$ echo hello >> bar
~/git/foo-link$ git commit -a -m 'Say hi'
Created commit 0a92c49: Say hi
1 files changed, 1 insertions(+), 0 deletions(-)
~/git/foo-link$ git push origin master
Counting objects: 7, done.
Writing objects: 100% (4/4), 281 bytes, done.
Total 4 (delta 0), reused 0 (delta 0)
Unpacking objects: 100% (4/4), done.
To /home/marcel/git/tmp-repo/.git
651b80a..0a92c49 master -> master
~/git/foo-link$ git pull
fatal: 'origin': unable to chdir or not a git archive
fatal: The remote end hung up unexpectedly
~/git/foo-link$ cd ~/git/clone-repo/foo
~/git/clone-repo/foo$ git pull
Already up-to-date.
~/git/clone-repo/foo$
on Linux 2.6.18-4-486, ext3
^ permalink raw reply
* Re: [PATCH try 2] t1301-shared-repo.sh: don't let a default ACL interfere with the test
From: Matt McCutchen @ 2008-10-14 23:00 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vzll66c5u.fsf@gitster.siamese.dyndns.org>
On Tue, 2008-10-14 at 15:32 -0700, Junio C Hamano wrote:
> Matt McCutchen <matt@mattmccutchen.net> writes:
> > This test creates files with several different umasks and expects the files to
> > be permissioned according to the umasks, so a default ACL on the test dir causes
>
> Is "to permission" a verb?
I thought it could be, but I'll reword that sentence.
> > the test to fail. To avoid that, remove the default ACL if possible with
> > setfacl(1). (Will work on many systems.)
>
> It is not clear in the comment in parentheses what provision you have made
> not to harm people on systems without setfacl.
>
> I think "if possible" which you already have is a good enough description
> (i.e. "if setfacl fails we do not barf and if you do not have the command
> you probably are not running with a funky default ACL to see this issue
> anyway"), so I'd rather drop the comment in parentheses.
Sure.
> > Signed-off-by: Matt McCutchen <matt@mattmccutchen.net>
> > ---
> > This time with a signoff.
> >
> > t/t1301-shared-repo.sh | 3 +++
> > 1 files changed, 3 insertions(+), 0 deletions(-)
> >
> > diff --git a/t/t1301-shared-repo.sh b/t/t1301-shared-repo.sh
> > index dc85e8b..2275caa 100755
> > --- a/t/t1301-shared-repo.sh
> > +++ b/t/t1301-shared-repo.sh
> > @@ -7,6 +7,9 @@ test_description='Test shared repository initialization'
> >
> > . ./test-lib.sh
> >
> > +# Remove a default ACL from the test dir if possible.
> > +setfacl -k . 2>/dev/null
> > +
>
> Makes me wonder why this is _not_ inside test-lib.sh where it creates the
> test (trash) directory. That way, you would cover future tests that wants
> to see a saner/simpler POSIX permission behaviour, wouldn't you?
Yes. However, I don't anticipate there being any tests specifically
about file permissions other than t1301-shared-repo.sh, and if the user
has set a default ACL on the git source tree, we might want to let trash
directories obey that setting except in the one case where it breaks the
test. What do you think?
Matt
^ permalink raw reply
* [PATCH] pull: allow "git pull origin $something:$current_branch" into an unborn branch
From: Junio C Hamano @ 2008-10-14 22:53 UTC (permalink / raw)
To: Johannes Schindelin, Daniel Barkalow; +Cc: git, spearce
In-Reply-To: <7vk5ca7rw3.fsf@gitster.siamese.dyndns.org>
Some misguided documents floating on the Net suggests this sequence:
mkdir newdir && cd newdir
git init
git remote add origin $url
git pull origin master:master
"git pull" has known about an misguided "pull" like this where the
underlying fetch updates the current branch for a long time, and it also
has known about another form of insanity "git pull origin master" into an
unborn branch, but these two workarounds were not aware of the existence
of each other and did not work well together.
This fixes it.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
---
* This comes on top of js/maint-fetch-update-head. Passes all the tests,
and also its own.
git-pull.sh | 4 ++--
t/t5520-pull.sh | 12 ++++++++++++
2 files changed, 14 insertions(+), 2 deletions(-)
diff --git a/git-pull.sh b/git-pull.sh
index 75c3610..664fe34 100755
--- a/git-pull.sh
+++ b/git-pull.sh
@@ -124,7 +124,7 @@ orig_head=$(git rev-parse --verify HEAD 2>/dev/null)
git fetch --update-head-ok "$@" || exit 1
curr_head=$(git rev-parse --verify HEAD 2>/dev/null)
-if test "$curr_head" != "$orig_head"
+if test -n "$orig_head" && test "$curr_head" != "$orig_head"
then
# The fetch involved updating the current branch.
@@ -172,7 +172,7 @@ esac
if test -z "$orig_head"
then
- git update-ref -m "initial pull" HEAD $merge_head "" &&
+ git update-ref -m "initial pull" HEAD $merge_head "$curr_head" &&
git read-tree --reset -u HEAD || exit 1
exit
fi
diff --git a/t/t5520-pull.sh b/t/t5520-pull.sh
index 997b2db..725771f 100755
--- a/t/t5520-pull.sh
+++ b/t/t5520-pull.sh
@@ -29,6 +29,18 @@ test_expect_success 'checking the results' '
diff file cloned/file
'
+test_expect_success 'pulling into void using master:master' '
+ mkdir cloned-uho &&
+ (
+ cd cloned-uho &&
+ git init &&
+ git pull .. master:master
+ ) &&
+ test -f file &&
+ test -f cloned-uho/file &&
+ test_cmp file cloned-uho/file
+'
+
test_expect_success 'test . as a remote' '
git branch copy master &&
--
1.6.0.2.711.gf1ba4
^ permalink raw reply related
* Re: [PATCH try 2] t1301-shared-repo.sh: don't let a default ACL interfere with the test
From: Junio C Hamano @ 2008-10-14 22:32 UTC (permalink / raw)
To: Matt McCutchen; +Cc: git
In-Reply-To: <1224022216.2699.5.camel@mattlaptop2.local>
Matt McCutchen <matt@mattmccutchen.net> writes:
> This test creates files with several different umasks and expects the files to
> be permissioned according to the umasks, so a default ACL on the test dir causes
Is "to permission" a verb?
> the test to fail. To avoid that, remove the default ACL if possible with
> setfacl(1). (Will work on many systems.)
It is not clear in the comment in parentheses what provision you have made
not to harm people on systems without setfacl.
I think "if possible" which you already have is a good enough description
(i.e. "if setfacl fails we do not barf and if you do not have the command
you probably are not running with a funky default ACL to see this issue
anyway"), so I'd rather drop the comment in parentheses.
> Signed-off-by: Matt McCutchen <matt@mattmccutchen.net>
> ---
> This time with a signoff.
>
> t/t1301-shared-repo.sh | 3 +++
> 1 files changed, 3 insertions(+), 0 deletions(-)
>
> diff --git a/t/t1301-shared-repo.sh b/t/t1301-shared-repo.sh
> index dc85e8b..2275caa 100755
> --- a/t/t1301-shared-repo.sh
> +++ b/t/t1301-shared-repo.sh
> @@ -7,6 +7,9 @@ test_description='Test shared repository initialization'
>
> . ./test-lib.sh
>
> +# Remove a default ACL from the test dir if possible.
> +setfacl -k . 2>/dev/null
> +
Makes me wonder why this is _not_ inside test-lib.sh where it creates the
test (trash) directory. That way, you would cover future tests that wants
to see a saner/simpler POSIX permission behaviour, wouldn't you?
^ permalink raw reply
* Re: Problem with CRLF line endings and colored diff
From: Junio C Hamano @ 2008-10-14 22:20 UTC (permalink / raw)
To: Jean-Luc Herren; +Cc: Git List
In-Reply-To: <48F50B97.9090106@gmx.ch>
Jean-Luc Herren <jlh@gmx.ch> writes:
> <GREEN FOREGROUND>+<RESET><GREEN FOREGROUND>
> line2<RESET><RED BACKGROUND><CR><RESET><LF>
This is expected and deliberate, as you haven't told about your desire to
consider carriage-returns not as line termination letter. By default CR
is just one of the whitespace letters, and colored diff output is
reminding you that you introduced a line with a trailing whitespace.
Check git-config(1) and look for "core.whitespace", paying special
attention to "cr-at-eol".
^ permalink raw reply
* [PATCH try 2] t1301-shared-repo.sh: don't let a default ACL interfere with the test
From: Matt McCutchen @ 2008-10-14 22:10 UTC (permalink / raw)
To: git
In-Reply-To: <1224022020.2699.4.camel@mattlaptop2.local>
This test creates files with several different umasks and expects the files to
be permissioned according to the umasks, so a default ACL on the test dir causes
the test to fail. To avoid that, remove the default ACL if possible with
setfacl(1). (Will work on many systems.)
Signed-off-by: Matt McCutchen <matt@mattmccutchen.net>
---
This time with a signoff.
t/t1301-shared-repo.sh | 3 +++
1 files changed, 3 insertions(+), 0 deletions(-)
diff --git a/t/t1301-shared-repo.sh b/t/t1301-shared-repo.sh
index dc85e8b..2275caa 100755
--- a/t/t1301-shared-repo.sh
+++ b/t/t1301-shared-repo.sh
@@ -7,6 +7,9 @@ test_description='Test shared repository initialization'
. ./test-lib.sh
+# Remove a default ACL from the test dir if possible.
+setfacl -k . 2>/dev/null
+
# User must have read permissions to the repo -> failure on --shared=0400
test_expect_success 'shared = 0400 (faulty permission u-w)' '
mkdir sub && (
--
1.6.0.2.530.gb503b
^ permalink raw reply related
* [PATCH] t1301-shared-repo.sh: don't let a default ACL interfere with the test
From: Matt McCutchen @ 2008-10-14 22:07 UTC (permalink / raw)
To: git
This test creates files with several different umasks and expects the files to
be permissioned according to the umasks, so a default ACL on the test dir causes
the test to fail. To avoid that, remove the default ACL if possible with
setfacl(1). (Will work on many systems.)
---
t/t1301-shared-repo.sh | 3 +++
1 files changed, 3 insertions(+), 0 deletions(-)
diff --git a/t/t1301-shared-repo.sh b/t/t1301-shared-repo.sh
index dc85e8b..2275caa 100755
--- a/t/t1301-shared-repo.sh
+++ b/t/t1301-shared-repo.sh
@@ -7,6 +7,9 @@ test_description='Test shared repository initialization'
. ./test-lib.sh
+# Remove a default ACL from the test dir if possible.
+setfacl -k . 2>/dev/null
+
# User must have read permissions to the repo -> failure on --shared=0400
test_expect_success 'shared = 0400 (faulty permission u-w)' '
mkdir sub && (
--
1.6.0.2.530.gb503b
^ permalink raw reply related
* What's cooking in git.git (Oct 2008, #03; Tue, 14)
From: Junio C Hamano @ 2008-10-14 22:08 UTC (permalink / raw)
To: git
Here are the topics that have been cooking. Commits prefixed
with '-' are only in 'pu' while commits prefixed with '+' are
in 'next'.
The topics list the commits in reverse chronological order. The topics
meant to be merged to the maintenance series have "maint-" in their names.
This round I haven't added anything new yet. Just getting my development
repository back into shape and in sync with what I received from Shawn.
----------------------------------------------------------------
[New Topics]
* js/maint-fetch-update-head (Mon Oct 13 11:36:52 2008 +0200) 1 commit
- Fix fetch/pull when run without --update-head-ok
This looked sane to me.
----------------------------------------------------------------
[Stuck Topics]
* nd/narrow (Wed Oct 1 11:04:09 2008 +0700) 9 commits
- grep: skip files outside sparse checkout area
- checkout_entry(): CE_NO_CHECKOUT on checked out entries.
- Prevent diff machinery from examining worktree outside sparse
checkout
- ls-files: Add tests for --sparse and friends
- update-index: add --checkout/--no-checkout to update
CE_NO_CHECKOUT bit
- update-index: refactor mark_valid() in preparation for new options
- ls-files: add options to support sparse checkout
- Introduce CE_NO_CHECKOUT bit
- Extend index to save more flags
Recently updated with a repost. Shawn says he's been too swamped at
day-job to actively review the series. There has been some discussion on
list about it so its not stalled, but it needs more eyeballs.
----------------------------------------------------------------
[Stalled -- Needs Action to Proceed (or to be dropped)]
* pb/submodule (Fri Sep 12 23:09:19 2008 +0200) 1 commit
- t7400: Add short "git submodule add" testsuite
Still waiting for a reroll. Should be dropped next week if we don't
get one during this coming week.
* bd/blame (Thu Aug 21 18:22:01 2008 -0500) 5 commits
- Use xdiff caching to improve git blame performance
- Allow xdiff machinery to cache hash results for a file
- Always initialize xpparam_t to 0
- Bypass textual patch generation and parsing in git blame
- Allow alternate "low-level" emit function from xdl_diff
Réne had good comments on how the callback should be structured.
* kb/am-directory (Fri Aug 29 15:27:50 2008 -0700) 1 commit
- git-am: Pass the --directory option through to git-apply
I think this is still buggy and drops the option when am stops with
conflicts.
----------------------------------------------------------------
[Will be merged to 'master' soon]
* pb/commit-where (Fri Oct 3 22:13:49 2008 -0400) 4 commits
+ tutorial: update output of git commit
+ reformat informational commit message
+ git commit: Reformat output somewhat
+ builtin-commit.c: show on which branch a commit was added
Shawn thinks this topic is settled for now, and I see that the new output
format does not bother me very much, so please expect this to be merged
soon.
----------------------------------------------------------------
[Actively Cooking]
* tr/workflow-doc (Sat Sep 13 18:11:01 2008 +0200) 2 commits
+ Documentation: Refer to git-rebase(1) to warn against rewriting
+ Documentation: new upstream rebase recovery section in git-rebase
Shawn says that an update came in recently, but they are not here yet.
I'd need to dig it up, but I haven't had time.
* ns/rebase-noverify (Mon Oct 6 14:14:29 2008 +0900) 1 commit
+ rebase --no-verify
This adds --no-verify to git rebase, to avoid the pre-rebase hook. Lacks
documentation but otherwise looks sound.
* mv/merge-noff (Fri Oct 3 14:04:47 2008 +0200) 1 commit
+ builtin-commit: use reduce_heads() only when appropriate
Fixes "git merge --no-ff --no-commit".
* ae/preservemerge (Mon Sep 29 22:28:57 2008 +0200) 1 commit
+ rebase: Support preserving merges in non-interactive mode
* sh/rebase-i-p (Wed Oct 8 01:41:57 2008 -0500) 7 commits
- rebase-i-p: if todo was reordered use HEAD as the rewritten parent
- rebase-i-p: do not include non-first-parent commits touching
UPSTREAM
- rebase-i-p: only list commits that require rewriting in todo
- rebase-i-p: fix 'no squashing merges' tripping up non-merges
- rebase-i-p: delay saving current-commit to REWRITTEN if squashing
- rebase-i-p: use HEAD for updating the ref instead of mapping
OLDHEAD
- rebase-i-p: test to exclude commits from todo based on its parents
Changes the `rebase -i -p` behavior to behave like git sequencer's
rewrite of `rebase -i` would behave.
* sh/maint-rebase3 (Sun Oct 5 23:26:52 2008 -0500) 1 commit
. rebase--interactive: fix parent rewriting for dropped commits
Tentatively dropped from everwhere, waiting for a reroll together with
sh/rebase-i-p.
* pb/rename-rowin32 (Sun Oct 12 21:01:23 2008 -0700) 2 commits
- (squash): index-pack: do not unconditionally make packfile read-
only
- Do not rename read-only files during a push
Supposedly fixes pack file renames on Windows. The (squash) patch is my
attempt to fix its breakage.
* sp/describe-lwtag (Mon Oct 13 07:39:46 2008 -0700) 1 commit
- describe: Make --tags and --all match lightweight tags more often
When the user gives --tags, the request is asking to treat lightweight and
annotated tags at equal weight, and if lightweight ones are closer, they
should be used.
* gb/formatpatch-autonbr (Sun Oct 12 22:18:02 2008 -0700) 2 commits
- (squash) adjust test vector for new behaviour of format-patch
- format-patch: autonumber by default
* jk/diff-convfilter (Sun Oct 5 17:43:45 2008 -0400) 4 commits
- diff: add filter for converting binary to text
- diff: introduce diff.<driver>.binary
- diff: unify external diff and funcname parsing code
- t4012: use test_cmp instead of cmp
A general cleanup on how diff drivers are implemented. Its still
missing documentation updates and tests but doesn't break anything
current as far as I can tell. It needs more review before it can
be slated for 'next'.
* dp/checkattr (Tue Oct 7 04:16:52 2008 +0400) 2 commits
+ check-attr: Add --stdin option
+ check-attr: add an internal check_attr() function
Batch attr lookup via --stdin, for gitk and git-gui.
* mv/clonev (Thu Oct 9 01:40:32 2008 +0200) 1 commit
+ Implement git clone -v
Does what it says it does. This may be ready for master soon,
its a pretty trivial change.
* gb/refactor-pathinfo (Fri Oct 10 20:42:26 2008 +0200) 1 commit
+ gitweb: refactor input parameters parse/validation
A major cleanup on the way gitweb parses its input arguments.
Future gitweb patches to add more arguments into the PATH_INFO
depend upon this initial cleanup work.
* ml/cygwin-filemode (Mon Oct 13 00:33:31 2008 -0400) 1 commit
- compat/cygwin.c - Use cygwin's stat if core.filemode == true
Is ready for 'next'.
* jn/gitweb-customlinks (Sun Oct 12 00:02:32 2008 +0200) 1 commit
- gitweb: Better processing format string in custom links in navbar
Waiting for some sort of response from Pasky.
----------------------------------------------------------------
[On Hold]
* jc/post-simplify (Fri Aug 15 01:34:51 2008 -0700) 2 commits
- revision --simplify-merges: incremental simplification
- revision --simplify-merges: prepare for incremental simplification
I started making this incremental but the progress is not
so great.
* jc/stripspace (Sun Mar 9 00:30:35 2008 -0800) 6 commits
. git-am --forge: add Signed-off-by: line for the author
. git-am: clean-up Signed-off-by: lines
. stripspace: add --log-clean option to clean up signed-off-by:
lines
. stripspace: use parse_options()
. Add "git am -s" test
. git-am: refactor code to add signed-off-by line for the committer
* jc/send-pack-tell-me-more (Thu Mar 20 00:44:11 2008 -0700) 1 commit
- "git push": tellme-more protocol extension
This seems to have a deadlock during communication between the peers.
Someone needs to pick up this topic and resolve the deadlock before it can
continue.
* jc/blame (Wed Jun 4 22:58:40 2008 -0700) 2 commits
- blame: show "previous" information in --porcelain/--incremental
format
- git-blame: refactor code to emit "porcelain format" output
* jk/renamelimit (Sat May 3 13:58:42 2008 -0700) 1 commit
- diff: enable "too large a rename" warning when -M/-C is explicitly
asked for
This would be the right thing to do for command line use,
but gitk will be hit due to tcl/tk's limitation, so I am holding
this back for now.
^ permalink raw reply
* What's in git.git (Oct 2008, #03; Tue, 14)
From: Junio C Hamano @ 2008-10-14 22:08 UTC (permalink / raw)
To: git
Just trying to get my development repository back in sync with what I
received from Shawn. Thanks to everybody, I think maint is ready for
1.6.0.3.
* The 'maint' branch has these fixes since the last announcement.
Junio C Hamano (1):
Update draft release notes to 1.6.0.3
* The 'master' branch has these since the last announcement
in addition to the above.
Jeff King (1):
tests: shell negation portability fix
Junio C Hamano (1):
Update draft release notes to 1.6.1
^ permalink raw reply
* Re: [PATCH v2] Fix fetch/pull when run without --update-head-ok
From: Junio C Hamano @ 2008-10-14 22:07 UTC (permalink / raw)
To: Daniel Barkalow; +Cc: Johannes Schindelin, git, spearce
In-Reply-To: <alpine.LNX.1.00.0810141258050.19665@iabervon.org>
Daniel Barkalow <barkalow@iabervon.org> writes:
> On Tue, 14 Oct 2008, Daniel Barkalow wrote:
> ...
>> That is, it uses --update-head-ok because "git pull origin master:master"
>> will work correctly, regardless of whether the local master is
>> yet-to-be-born or not.
>
> In particular, the --update-head-ok is from b10ac50f, which is what added
> the check to prohibit fetching into the current branch otherwise, back in
> August 2005. There's never been anything preventing updating the current
> branch using "pull".
What you wrote above is correct, and it is all that is necessary to make
"pull master:master" (when 'master' is the current branch) work correctly,
in normal situations. Dscho's patch is in itself is a good thing to do,
but is not necessary when the caller gives --update-head-ok.
Nor is it sufficient. Have you tested the current "git-pull" with or
without Dscho's patch applied to "git-fetch" when 'master' is an unborn
branch? "git-pull" has this piece:
curr_head=$(git rev-parse --verify HEAD 2>/dev/null)
if test "$curr_head" != "$orig_head"
then
# The fetch involved updating the current branch.
# The working tree and the index file is still based on the
# $orig_head commit, but we are merging into $curr_head.
# First update the working tree to match $curr_head.
echo >&2 "Warning: fetch updated the current branch head."
...
fi
The above part (written by yours truly) did not care what happens when the
current branch is unborn. Back then when git-pull was originally written,
nobody was crazy enough to pull into an empty branch and expect it to
work. The code to allow that craziness (look for "initial pull" in the
same script to find a 6-line block near the end) came much later, and the
commit that added the "initial pull" support should have adjusted the
above codeblock if it really wanted to support pulling into an unborn
branch, but it forgot to do so. It also forgot to handle the case where
the originally unborn current branch was fetched into.
If we really care about is "git pull origin master:master" into an unborn
branch, I think we need the attached patch on top, and this is regardless
of Dscho's patch that tightens the check when -update-head-ok is not given.
git-pull.sh | 4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git c/git-pull.sh w/git-pull.sh
index 75c3610..664fe34 100755
--- c/git-pull.sh
+++ w/git-pull.sh
@@ -124,7 +124,7 @@ orig_head=$(git rev-parse --verify HEAD 2>/dev/null)
git fetch --update-head-ok "$@" || exit 1
curr_head=$(git rev-parse --verify HEAD 2>/dev/null)
-if test "$curr_head" != "$orig_head"
+if test -n "$orig_head" && test "$curr_head" != "$orig_head"
then
# The fetch involved updating the current branch.
@@ -172,7 +172,7 @@ esac
if test -z "$orig_head"
then
- git update-ref -m "initial pull" HEAD $merge_head "" &&
+ git update-ref -m "initial pull" HEAD $merge_head "$curr_head" &&
git read-tree --reset -u HEAD || exit 1
exit
fi
^ permalink raw reply related
* Re: Git and tagging hook
From: Daniel Barkalow @ 2008-10-14 21:33 UTC (permalink / raw)
To: Kristis Makris
Cc: Jan Hudec, Andreas Ericsson, Jakub Narebski, git, scmbug-users
In-Reply-To: <1224007401.4073.40.camel@localhost>
On Tue, 14 Oct 2008, Kristis Makris wrote:
> Jan, thanks for trying to clarify this for me.
>
> I am working on adding integration support of Git with bug-trackers,
> using Scmbug. There may be an argument here towards/against distributed
> bug-trackers when it comes to Git.
>
> Maybe there are things here I don't fully understand yet.
>
> On Tue, 2008-10-14 at 19:22 +0200, Jan Hudec wrote:
> > >>> Kristis Makris wrote:
> > >>>> I want the integration when I apply the tag to a local repository, NOT
> > >>>> only when I push/pull.
> >
> > Care to explain why that would ever be useful? It's local, which means that:
> > - the user can take it back without a trace it ever happened (git tag -d or
> > even git update-ref -d) and
> > - noone except the user will see it anyway, so it's not like they should
> > care either.
>
> I have two use cases:
>
> (1) A developer maintains besides his local copy a local bug-tracking
> system in which he tracks his changes. We would like to apply various
> verification policies when he commits or tags. For example, for tagging
> we wants to ensure that he tags giving consistent labels to his
> intermediate builds. e.g. as in:
>
> http://files.mkgnu.net/files/scmbug/SCMBUG_RELEASE_0-26-9/manual/html-single/manual.html#VERIFICATION-CHECKS-CONVENTION-BASED-LABELING
>
> Or he may want to have Git force him to also supply a log message along
> with a tag, so that he can remember later more accurately why a tag was
> created and what it really captures. Even if Git (or other SCM systems)
> don't natively support log messages on tags. Scmbug plans to implement
> this.
Git supports using tags for a variety of other purposes in addition to the
traditional ones (for example, you can tag a version as "the changes I'm
sure of" or "the version I know is broken"; furthermore, your regression
testing system could give you a tag that tags the commit you sent for
testing with the test results). The bug tracker integration should only
care about the traditional use (providing a persistant, human-recognizable
name for a revision). Actually, it would probably be best, for integration
with git, to skip tags entirely, and use the hash. With projects using
git, it is routine to know that the bug was found in some particular
flawed commit that didn't get tagged.
> http://bugzilla.mkgnu.net/show_bug.cgi?id=219
>
>
> (2) I would like to apply various verification policies when work from a
> local repository is finally merged with the central repository. I assume
> there can/will be a central repository, and there is one "software
> product" that is being released somewhere among the many copies.
>
> When its time to merge local changes to a central repository, the
> verification policies may deem that changes are not acceptable to be
> merged with the mainline. e.g. because log messages are too short,
> commits during the merge are issued against bugs in "a central"
> bugtracker that are either closed, assigned to someone else, or just
> plain wrong bug-numbers that belong to other products:
>
> http://files.mkgnu.net/files/scmbug/SCMBUG_RELEASE_0-26-9/manual/html-single/manual.html#VERIFICATION-CHECKS-VALID-LOG-MESSAGE-SIZE
> http://files.mkgnu.net/files/scmbug/SCMBUG_RELEASE_0-26-9/manual/html-single/manual.html#VERIFICATION-CHECKS-OPEN-BUG-STATE
> http://files.mkgnu.net/files/scmbug/SCMBUG_RELEASE_0-26-9/manual/html-single/manual.html#VERIFICATION-CHECKS-VALID-BUG-OWNER
> http://files.mkgnu.net/files/scmbug/SCMBUG_RELEASE_0-26-9/manual/html-single/manual.html#VERIFICATION-CHECKS-VALID-PRODUCT-NAME
>
> (I'm not very clear whether this is how Git works)
>
> Does someone get to write-up a brand new log comment during the merge
> and the merge totally disregards older log comments ? My understanding
> is that log comments on the local copy are preserved (and will need to
> be mapped to bug-numbers in the central bug-tracker.
In general, you send to the central repository, and it rejects you if (a)
a merge would be required; you have to fetch and merge in your local
repository; or (b) there's something wrong with the changes you're making.
For (a), you make a merge commit and try again; the new commit has a log
message, but the old commits retain their log messages. For (b), you make
a different set of commits that does follow the required policy. "git
rebase -i origin/master" will guide you through this process. In general,
you do this before sharing your changes with anybody else, or at least
before sharing them with anyone who cares about the end result, so that
other people see nice commits. It's also possible to rearrange the changes
you made in a bunch of local commits into a series that looks nice and
makes sense and follows the project rules, when your initial work had you
introducing a lot of silly mistakes and fixing them.
> Thus the local verification policies may need to have already been
> configured to comply with future verification policies of the central
> repository. Else (perhaps considerable) mappings/adjustments will be
> needed during the push to the central copy.
In general, there's a ton of adjustment needed between working on a
project and pushing to the central location in any system. With git,
however, version control may be used locally before these adjustments are
made, and this provides a huge benefit in terms of being able to prepare
commits just how they should be, and in terms of being able to avoid
losing work during the adjustments.
In general, you want to have a local understanding of the central
repository rules, so that you can do this mapping while you don't have
network, but there's no reason to prevent saving your work before it
conforms.
-Daniel
*This .sig left intentionally blank*
^ permalink raw reply
* Problem with CRLF line endings and colored diff
From: Jean-Luc Herren @ 2008-10-14 21:13 UTC (permalink / raw)
To: Git List
Hello list!
I'm using CRLF line endings on the files of a project and I'm
running into odd output from 'git diff'. Here are the steps to
reproduce:
git init
echo -e 'line1\r' > file
git add file
echo -e 'line2\r' > file
PAGER='less -R' git diff --color
The output looks like this:
diff --git a/file b/file
index 495181c..a1413a4 100644
--- a/file
+++ b/file
@@ -1 +1 @@
-line1
+line2^M
Note the trailing ^M on the '+' line. After examining that line
it seems it's a bug in git, as that line really looks like this
(<...> denoting ANSI sequences or CR/LF):
<GREEN FOREGROUND>+<RESET><GREEN FOREGROUND>
line2<RESET><RED BACKGROUND><CR><RESET><LF>
The CR and the LF are not after each other, there's an ANSI
sequence in between (because the CR is being highlighted as white
space). That confuses 'less'. The '-' line above does not do
that and thus doesn't have this problem. It also doesn't reset
the color between the '-' and the line:
<RED FOREGROUND>-line1<RESET><CR><LF>
I tried poking around the code, but the diff machinery is more
complex than could be quickly grasped, so I'll let someone that
knows it already have a look.
Using git 1.6.0.2, but have the same problem with HEAD.
jlh
^ 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