* [PATCH 2/2] make the ST_{C,M}TIME_NSEC macros more function like
From: Kjetil Barvik @ 2009-03-15 11:38 UTC (permalink / raw)
To: git; +Cc: Junio C Hamano, Kjetil Barvik
In-Reply-To: <cover.1237115791.git.barvik@broadpark.no>
Make the macros take a pointer to a 'struct stat'. This is so that it
should be easier to understand what is going on, and that the macros
can later be implemented as a inline function if we want to.
Impact: cosmetic change
Signed-off-by: Kjetil Barvik <barvik@broadpark.no>
---
builtin-fetch-pack.c | 4 ++--
git-compat-util.h | 8 ++++----
read-cache.c | 12 ++++++------
3 files changed, 12 insertions(+), 12 deletions(-)
diff --git a/builtin-fetch-pack.c b/builtin-fetch-pack.c
index d571253..0cd50f3 100644
--- a/builtin-fetch-pack.c
+++ b/builtin-fetch-pack.c
@@ -800,13 +800,13 @@ struct ref *fetch_pack(struct fetch_pack_args *my_args,
int fd;
mtime.sec = st.st_mtime;
- mtime.nsec = ST_MTIME_NSEC(st);
+ mtime.nsec = ST_MTIME_NSEC(&st);
if (stat(shallow, &st)) {
if (mtime.sec)
die("shallow file was removed during fetch");
} else if (st.st_mtime != mtime.sec
#ifdef USE_NSEC
- || ST_MTIME_NSEC(st) != mtime.nsec
+ || ST_MTIME_NSEC(&st) != mtime.nsec
#endif
)
die("shallow file was changed during fetch");
diff --git a/git-compat-util.h b/git-compat-util.h
index 1906253..4a633be 100644
--- a/git-compat-util.h
+++ b/git-compat-util.h
@@ -394,11 +394,11 @@ void git_qsort(void *base, size_t nmemb, size_t size,
#define ST_MTIME_NSEC(st) 0
#else
#ifdef USE_ST_TIMESPEC
-#define ST_CTIME_NSEC(st) ((unsigned int)((st).st_ctimespec.tv_nsec))
-#define ST_MTIME_NSEC(st) ((unsigned int)((st).st_mtimespec.tv_nsec))
+#define ST_CTIME_NSEC(st) ((unsigned int)((st)->st_ctimespec.tv_nsec))
+#define ST_MTIME_NSEC(st) ((unsigned int)((st)->st_mtimespec.tv_nsec))
#else
-#define ST_CTIME_NSEC(st) ((unsigned int)((st).st_ctim.tv_nsec))
-#define ST_MTIME_NSEC(st) ((unsigned int)((st).st_mtim.tv_nsec))
+#define ST_CTIME_NSEC(st) ((unsigned int)((st)->st_ctim.tv_nsec))
+#define ST_MTIME_NSEC(st) ((unsigned int)((st)->st_mtim.tv_nsec))
#endif
#endif
diff --git a/read-cache.c b/read-cache.c
index 3f58711..cff85e3 100644
--- a/read-cache.c
+++ b/read-cache.c
@@ -69,8 +69,8 @@ void fill_stat_cache_info(struct cache_entry *ce, struct stat *st)
{
ce->ce_ctime.sec = (unsigned int)st->st_ctime;
ce->ce_mtime.sec = (unsigned int)st->st_mtime;
- ce->ce_ctime.nsec = ST_CTIME_NSEC(*st);
- ce->ce_mtime.nsec = ST_MTIME_NSEC(*st);
+ ce->ce_ctime.nsec = ST_CTIME_NSEC(st);
+ ce->ce_mtime.nsec = ST_MTIME_NSEC(st);
ce->ce_dev = st->st_dev;
ce->ce_ino = st->st_ino;
ce->ce_uid = st->st_uid;
@@ -204,9 +204,9 @@ static int ce_match_stat_basic(struct cache_entry *ce, struct stat *st)
changed |= CTIME_CHANGED;
#ifdef USE_NSEC
- if (ce->ce_mtime.nsec != ST_MTIME_NSEC(*st))
+ if (ce->ce_mtime.nsec != ST_MTIME_NSEC(st))
changed |= MTIME_CHANGED;
- if (trust_ctime && ce->ce_ctime.nsec != ST_CTIME_NSEC(*st))
+ if (trust_ctime && ce->ce_ctime.nsec != ST_CTIME_NSEC(st))
changed |= CTIME_CHANGED;
#endif
@@ -1299,7 +1299,7 @@ int read_index_from(struct index_state *istate, const char *path)
dst_offset += ce_size(ce);
}
istate->timestamp.sec = st.st_mtime;
- istate->timestamp.nsec = ST_MTIME_NSEC(st);
+ istate->timestamp.nsec = ST_MTIME_NSEC(&st);
while (src_offset <= mmap_size - 20 - 8) {
/* After an array of active_nr index entries,
@@ -1564,7 +1564,7 @@ int write_index(struct index_state *istate, int newfd)
if (ce_flush(&c, newfd) || fstat(newfd, &st))
return -1;
istate->timestamp.sec = (unsigned int)st.st_mtime;
- istate->timestamp.nsec = ST_MTIME_NSEC(st);
+ istate->timestamp.nsec = ST_MTIME_NSEC(&st);
return 0;
}
--
1.6.2.GIT
^ permalink raw reply related
* Re: setting up tracking on push
From: Jay Soffian @ 2009-03-15 12:36 UTC (permalink / raw)
To: John M. Dlugosz; +Cc: git
In-Reply-To: <4845-91917@sneakemail.com>
On Sat, Mar 14, 2009 at 11:28 PM, John M. Dlugosz
<ngnr63q02@sneakemail.com> wrote:
> Things under refs/remotes are remote tracking branches
Yes.
> and local branches
> (under refs/heads) that automatically updated based on a fetch ("store
> locally" means merge or rebase, right?) are also called remote tracking
> branches.
No. The branches under refs/heads are *not* [1] updated by fetch.
- Anything under refs/remotes is a remote tracking branch.
- Anything under refs/heads is a local branch.
Now, often local branches are based on remote tracking branches, in the
sense that you created the local branch _from_ the remote tracking
branch. So periodically, you will want to update the local branch in
order to incorporate your local changes with whatever changes have been
made in the remote tracking branch. Doing this is a two-step process:
1) You update your remote tracking branches using fetch.
2) You integrate the changes from the remote tracking branches into your
local branches using either merge or rebase.
> I think that's why some of us are confused.
I remember being just as confused, but oddly it seems so clear to me
now. I think there is an inflection point where git goes from
"confusing" to "ah hah, it's ingenious!" :-)
Let me try to draw a little ascii art:
Local Repo Remote Repo (origin)
---------- --------------------
refs/remotes/origin/master <-- fetch --- refs/heads/master
|
(merge or rebase)
|
v
refs/heads/master
As changes are made to refs/heads/master on the remote repo, the
corresponding remote tracking branch on the local repo
(refs/remotes/origin/master) will fall behind. Performing a fetch in the
local repo updates its refs/remotes/origin/master to match the remote's
refs/heads/master. Then either merge or rebase in the local repo, while
refs/heads/master is checked out, integrates those changes.
If no changes have been made locally to refs/heads/master, then the
merge operation is a so-called "fast forward".
The confusing part is that there is a switch to "git checkout" and "git
branch" named "--track". A better name would have probably been
"--follow". Regardless, this switch [2], configures branch.<name>.remote
and branch.<name>.merge in the local repo's .git/config. And I mentioned
in a previous message the reason for having these. [3]
[1] You could of course configure fetch to do whatever you like, but it
would be rather unusual to update refs/heads via fetch.
[2] Which is the default in current git when a local branch is created
from a remote tracking branch.
[3] Namely, 1) branch -v, status, and checkout tell you how far
ahead/behind the local branch is from the remote tracking branch;
2) pull can be run w/o having to explicitly tell it what to fetch
and what to merge.
j.
^ permalink raw reply
* Re: excluding files from a merge
From: Jay Soffian @ 2009-03-15 12:47 UTC (permalink / raw)
To: Daniel Jacobs; +Cc: git
In-Reply-To: <loom.20090315T011519-497@post.gmane.org>
On Sat, Mar 14, 2009 at 9:23 PM, Daniel Jacobs <djacobs7@gmail.com> wrote:
> I would like it if every file was merged, except for files that were explictly
> excluded from a merge between these two branches. Is there a good way to do
> this?
Please see http://thread.gmane.org/gmane.comp.version-control.git/110488
(Is there a way to exclude user-specified files or directories from
participating in merges?)
I believe it is the same use case, and Junio provided a very detailed reply.
HTH,
j.
^ permalink raw reply
* [PATCH] Tests: use test_cmp instead of diff where possible
From: Miklos Vajna @ 2009-03-15 13:33 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
Several old tests were written before test_cmp was introduced, convert
these to test_cmp.
Signed-off-by: Miklos Vajna <vmiklos@frugalware.org>
---
I intentionally did not touch t5000 - using test_cmp -r works for me,
since the default is diff -u, but that would break the setup of users
where GIT_TEST_CMP is set to cmp.
t/t0000-basic.sh | 8 ++++----
t/t1100-commit-tree-options.sh | 2 +-
t/t1400-update-ref.sh | 6 +++---
t/t3000-ls-files-others.sh | 4 ++--
t/t3010-ls-files-killed-modified.sh | 4 ++--
t/t5000-tar-tree.sh | 2 +-
t/t9001-send-email.sh | 2 +-
7 files changed, 14 insertions(+), 14 deletions(-)
diff --git a/t/t0000-basic.sh b/t/t0000-basic.sh
index 70df15c..4837300 100755
--- a/t/t0000-basic.sh
+++ b/t/t0000-basic.sh
@@ -127,7 +127,7 @@ cat >expected <<\EOF
EOF
test_expect_success \
'validate git ls-files output for a known tree.' \
- 'diff current expected'
+ 'test_cmp current expected'
test_expect_success \
'writing tree out with git write-tree.' \
@@ -147,7 +147,7 @@ cat >expected <<\EOF
EOF
test_expect_success \
'git ls-tree output for a known tree.' \
- 'diff current expected'
+ 'test_cmp current expected'
# This changed in ls-tree pathspec change -- recursive does
# not show tree nodes anymore.
@@ -166,7 +166,7 @@ cat >expected <<\EOF
EOF
test_expect_success \
'git ls-tree -r output for a known tree.' \
- 'diff current expected'
+ 'test_cmp current expected'
# But with -r -t we can have both.
test_expect_success \
@@ -187,7 +187,7 @@ cat >expected <<\EOF
EOF
test_expect_success \
'git ls-tree -r output for a known tree.' \
- 'diff current expected'
+ 'test_cmp current expected'
test_expect_success \
'writing partial tree out with git write-tree --prefix.' \
diff --git a/t/t1100-commit-tree-options.sh b/t/t1100-commit-tree-options.sh
index 7f7fc36..c4414ff 100755
--- a/t/t1100-commit-tree-options.sh
+++ b/t/t1100-commit-tree-options.sh
@@ -40,6 +40,6 @@ test_expect_success \
test_expect_success \
'compare commit' \
- 'diff expected commit'
+ 'test_cmp expected commit'
test_done
diff --git a/t/t1400-update-ref.sh b/t/t1400-update-ref.sh
index bd58926..54ba3df 100755
--- a/t/t1400-update-ref.sh
+++ b/t/t1400-update-ref.sh
@@ -137,7 +137,7 @@ $B $A $GIT_COMMITTER_NAME <$GIT_COMMITTER_EMAIL> 1117150860 +0000
EOF
test_expect_success \
"verifying $m's log" \
- "diff expect .git/logs/$m"
+ "test_cmp expect .git/logs/$m"
rm -rf .git/$m .git/logs expect
test_expect_success \
@@ -168,7 +168,7 @@ $B $A $GIT_COMMITTER_NAME <$GIT_COMMITTER_EMAIL> 1117150980 +0000
EOF
test_expect_success \
"verifying $m's log" \
- 'diff expect .git/logs/$m'
+ 'test_cmp expect .git/logs/$m'
rm -f .git/$m .git/logs/$m expect
git update-ref $m $D
@@ -272,7 +272,7 @@ $h_FIXED $h_MERGED $GIT_COMMITTER_NAME <$GIT_COMMITTER_EMAIL> 1117151100 +0000 c
EOF
test_expect_success \
'git commit logged updates' \
- "diff expect .git/logs/$m"
+ "test_cmp expect .git/logs/$m"
unset h_TEST h_OTHER h_FIXED h_MERGED
test_expect_success \
diff --git a/t/t3000-ls-files-others.sh b/t/t3000-ls-files-others.sh
index bc0a351..304dd02 100755
--- a/t/t3000-ls-files-others.sh
+++ b/t/t3000-ls-files-others.sh
@@ -42,7 +42,7 @@ test_expect_success \
test_expect_success \
'git ls-files --others should pick up symlinks.' \
- 'diff output expected1'
+ 'test_cmp output expected1'
test_expect_success \
'git ls-files --others --directory to show output.' \
@@ -51,6 +51,6 @@ test_expect_success \
test_expect_success \
'git ls-files --others --directory should not get confused.' \
- 'diff output expected2'
+ 'test_cmp output expected2'
test_done
diff --git a/t/t3010-ls-files-killed-modified.sh b/t/t3010-ls-files-killed-modified.sh
index ec14040..4f5375e 100755
--- a/t/t3010-ls-files-killed-modified.sh
+++ b/t/t3010-ls-files-killed-modified.sh
@@ -75,7 +75,7 @@ EOF
test_expect_success \
'validate git ls-files -k output.' \
- 'diff .output .expected'
+ 'test_cmp .output .expected'
test_expect_success \
'git ls-files -m to show modified files.' \
@@ -91,6 +91,6 @@ EOF
test_expect_success \
'validate git ls-files -m output.' \
- 'diff .output .expected'
+ 'test_cmp .output .expected'
test_done
diff --git a/t/t5000-tar-tree.sh b/t/t5000-tar-tree.sh
index b7e3628..bfd593c 100755
--- a/t/t5000-tar-tree.sh
+++ b/t/t5000-tar-tree.sh
@@ -76,7 +76,7 @@ test_expect_success \
test_expect_success \
'git archive vs. git tar-tree' \
- 'diff b.tar b2.tar'
+ 'test_cmp b.tar b2.tar'
test_expect_success \
'git archive in a bare repo' \
diff --git a/t/t9001-send-email.sh b/t/t9001-send-email.sh
index 08d5b91..4fcc2e1 100755
--- a/t/t9001-send-email.sh
+++ b/t/t9001-send-email.sh
@@ -88,7 +88,7 @@ cat >expected <<\EOF
EOF
test_expect_success \
'Verify commandline' \
- 'diff commandline1 expected'
+ 'test_cmp commandline1 expected'
cat >expected-show-all-headers <<\EOF
0001-Second.patch
--
1.6.2
^ permalink raw reply related
* Re: [PATCH] Autoconf: Disable inline for compilers that don't support it.
From: Allan Caffee @ 2009-03-15 15:21 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vy6v7al37.fsf@gitster.siamese.dyndns.org>
On Sat, 14 Mar 2009, Junio C Hamano wrote:
> Allan Caffee <allan.caffee@gmail.com> writes:
>
> > The Autoconf macro AC_C_INLINE will redefine the inline keyword to whatever the
> > current compiler supports (including possibly nothing).
> >
> > Signed-off-by: Allan Caffee <allan.caffee@gmail.com>
>
> As far as I can tell, this makes scriptlet to set ac_cv_c_inline and then
> the result is written to confdefs.h:
>
> case $ac_cv_c_inline in
> inline | yes) ;;
> *)
> case $ac_cv_c_inline in
> no) ac_val=;;
> *) ac_val=$ac_cv_c_inline;;
> esac
> cat >>confdefs.h <<_ACEOF
> #ifndef __cplusplus
> #define inline $ac_val
> #endif
> _ACEOF
> ;;
> esac
>
> which is used only during the ./configure run but not during the actual
> build.
>
> What am I missing?
My mistake; it looks like this macro will only work the way I described
when using a config.h, which I see git is not currently doing. I
assumed that it would also provide a -D flag to the precompiler if a
configuration header isn't used but this doesn't appear to be case (from
a cursory glance at the macros definition). I could send a patch that
would set up a config header, but that would mean adding an #include
directive to all of the source files (or at least those using inline).
OTOH doing so would allow git to make use of some other handy macros
like AC_C_CONST. Do you think this is worth adding a configuration
header?
^ permalink raw reply
* Re: [PATCH 0/2] git checkout: one bugfix and one cosmetic change
From: Junio C Hamano @ 2009-03-15 18:21 UTC (permalink / raw)
To: Kjetil Barvik; +Cc: git, Scott Chacon
In-Reply-To: <cover.1237115791.git.barvik@broadpark.no>
Kjetil Barvik <barvik@broadpark.no> writes:
> Just one small bugfix patch, and one small cosmetic change.
>
> By the way, I wonder how often the list of 'Primary Authors' and
> 'Contributors' on the webpage http://git-scm.com/about is updated.
> Should'nt it be updated when a new release, like v1.6.2, is made?
Thanks for noticing. Though git-scm.com is not under my control, the site
is considered the official git homepage these days, and I am glad to see
improvements to its contents discussed here. I do not see Scott very
often on this list these days, so I am CC'ing him.
^ permalink raw reply
* Re: setting up tracking on push
From: Junio C Hamano @ 2009-03-15 18:33 UTC (permalink / raw)
To: John M. Dlugosz; +Cc: git
In-Reply-To: <4845-91917@sneakemail.com>
"John M. Dlugosz" <ngnr63q02@sneakemail.com> writes:
> Jay Soffian jaysoffian-at-gmail.com |git| wrote:
>> - The branches under refs/remotes (those shown by "git branch -r") are
>> remote tracking branches. So that tells git fetch where to fetch
>> from, which remote branches to
>> fetch, and where to store those branches locally. In this case, each
>> branch under refs/heads/ on git://git.kernel.org/pub/scm/git/git.git
>> will be fetched and stored locally as refs/remotes/origin/. Locally
>> the branches are called "remote tracking branches".
>
> Things under refs/remotes are remote tracking branches, and local
> branches (under refs/heads) that automatically updated based on a
> fetch ("store locally" means merge or rebase, right?) are also called
> remote tracking branches.
>
> I think that's why some of us are confused.
True; the latter wording invites confusion.
What fetch updates directly from remote site are called "remote tracking
branches". The local branches you intend to keep up to date with respect
to one remote tracking branch is sometimes said to "track" the remote
tracking branch, but because I find it confusing to use the same verb for
this other purpose, I tend to say that local branch (that "tracks" the
other one)
(1) _forked_ from; or
(2) _builds_ on
the remote tracking branch, in order to avoid confusion.
Historically, refs/remotes/ hierarchy did not exist, and "git clone"
created these refspecs after cloning from a two branch project:
refs/heads/master:refs/heads/origin
refs/heads/maint:refs/heads/maint
and created a local master starting at 'origin'.
The expectation was that everybody would work on 'master', occasionally
referring to 'maint', and because 'master' is always checked out, avoid
'fetch' from disturbing it by using a separate local branch 'origin' to
keep track of the advance of the other side, while updating 'maint' that
is not checked out directly.
This was the layout used in the good old times, and worked well *only* in
the most simplistic case. In reality, people used far more branches and
worked on branches other than master.
To fix that, refs/remotes/ hierarchy was introduced, and we started
treating the tracking part of master the same way as other branches, i.e.
refs/heads/*:refs/remotes/origin/*
The local 'maint' in the old layout was called a remote tracking branch,
too, even though it was local. These days, if you use the default layout
"git clone" gives you, you can say refs under refs/remotes/ hierarchy are
all remote tracking branches, and you do not have any remote tracking
branches that are local.
^ permalink raw reply
* Re: [PATCH] Tests: use test_cmp instead of diff where possible
From: René Scharfe @ 2009-03-15 18:42 UTC (permalink / raw)
To: Miklos Vajna; +Cc: Junio C Hamano, git
In-Reply-To: <1237124036-1348-1-git-send-email-vmiklos@frugalware.org>
Miklos Vajna schrieb:
> Several old tests were written before test_cmp was introduced, convert
> these to test_cmp.
>
> Signed-off-by: Miklos Vajna <vmiklos@frugalware.org>
> ---
>
> I intentionally did not touch t5000 - using test_cmp -r works for me,
> since the default is diff -u, but that would break the setup of users
> where GIT_TEST_CMP is set to cmp.
>
> t/t0000-basic.sh | 8 ++++----
> t/t1100-commit-tree-options.sh | 2 +-
> t/t1400-update-ref.sh | 6 +++---
> t/t3000-ls-files-others.sh | 4 ++--
> t/t3010-ls-files-killed-modified.sh | 4 ++--
> t/t5000-tar-tree.sh | 2 +-
> t/t9001-send-email.sh | 2 +-
> 7 files changed, 14 insertions(+), 14 deletions(-)
You _did_ touch t5000, and converted one of the diff calls. I agree
that the ones using the option -r should stay, but the rest could be
switched to test_cmp, too.
>
> diff --git a/t/t0000-basic.sh b/t/t0000-basic.sh
> index 70df15c..4837300 100755
> --- a/t/t0000-basic.sh
> +++ b/t/t0000-basic.sh
> @@ -127,7 +127,7 @@ cat >expected <<\EOF
> EOF
> test_expect_success \
> 'validate git ls-files output for a known tree.' \
> - 'diff current expected'
> + 'test_cmp current expected'
While you're changing this, you could switch the order of the two files,
for consistency. If expected comes first, the command shows how the
test result deviates from the correct output.
>
> test_expect_success \
> 'writing tree out with git write-tree.' \
> @@ -147,7 +147,7 @@ cat >expected <<\EOF
> EOF
> test_expect_success \
> 'git ls-tree output for a known tree.' \
> - 'diff current expected'
> + 'test_cmp current expected'
Same here.
>
> # This changed in ls-tree pathspec change -- recursive does
> # not show tree nodes anymore.
> @@ -166,7 +166,7 @@ cat >expected <<\EOF
> EOF
> test_expect_success \
> 'git ls-tree -r output for a known tree.' \
> - 'diff current expected'
> + 'test_cmp current expected'
Same here.
>
> # But with -r -t we can have both.
> test_expect_success \
> @@ -187,7 +187,7 @@ cat >expected <<\EOF
> EOF
> test_expect_success \
> 'git ls-tree -r output for a known tree.' \
> - 'diff current expected'
> + 'test_cmp current expected'
Same here.
>
> test_expect_success \
> 'writing partial tree out with git write-tree --prefix.' \
> diff --git a/t/t1100-commit-tree-options.sh b/t/t1100-commit-tree-options.sh
> index 7f7fc36..c4414ff 100755
> --- a/t/t1100-commit-tree-options.sh
> +++ b/t/t1100-commit-tree-options.sh
> @@ -40,6 +40,6 @@ test_expect_success \
>
> test_expect_success \
> 'compare commit' \
> - 'diff expected commit'
> + 'test_cmp expected commit'
>
> test_done
> diff --git a/t/t1400-update-ref.sh b/t/t1400-update-ref.sh
> index bd58926..54ba3df 100755
> --- a/t/t1400-update-ref.sh
> +++ b/t/t1400-update-ref.sh
> @@ -137,7 +137,7 @@ $B $A $GIT_COMMITTER_NAME <$GIT_COMMITTER_EMAIL> 1117150860 +0000
> EOF
> test_expect_success \
> "verifying $m's log" \
> - "diff expect .git/logs/$m"
> + "test_cmp expect .git/logs/$m"
> rm -rf .git/$m .git/logs expect
>
> test_expect_success \
> @@ -168,7 +168,7 @@ $B $A $GIT_COMMITTER_NAME <$GIT_COMMITTER_EMAIL> 1117150980 +0000
> EOF
> test_expect_success \
> "verifying $m's log" \
> - 'diff expect .git/logs/$m'
> + 'test_cmp expect .git/logs/$m'
> rm -f .git/$m .git/logs/$m expect
>
> git update-ref $m $D
> @@ -272,7 +272,7 @@ $h_FIXED $h_MERGED $GIT_COMMITTER_NAME <$GIT_COMMITTER_EMAIL> 1117151100 +0000 c
> EOF
> test_expect_success \
> 'git commit logged updates' \
> - "diff expect .git/logs/$m"
> + "test_cmp expect .git/logs/$m"
> unset h_TEST h_OTHER h_FIXED h_MERGED
>
> test_expect_success \
> diff --git a/t/t3000-ls-files-others.sh b/t/t3000-ls-files-others.sh
> index bc0a351..304dd02 100755
> --- a/t/t3000-ls-files-others.sh
> +++ b/t/t3000-ls-files-others.sh
> @@ -42,7 +42,7 @@ test_expect_success \
>
> test_expect_success \
> 'git ls-files --others should pick up symlinks.' \
> - 'diff output expected1'
> + 'test_cmp output expected1'
Same here.
>
> test_expect_success \
> 'git ls-files --others --directory to show output.' \
> @@ -51,6 +51,6 @@ test_expect_success \
>
> test_expect_success \
> 'git ls-files --others --directory should not get confused.' \
> - 'diff output expected2'
> + 'test_cmp output expected2'
Same here.
>
> test_done
> diff --git a/t/t3010-ls-files-killed-modified.sh b/t/t3010-ls-files-killed-modified.sh
> index ec14040..4f5375e 100755
> --- a/t/t3010-ls-files-killed-modified.sh
> +++ b/t/t3010-ls-files-killed-modified.sh
> @@ -75,7 +75,7 @@ EOF
>
> test_expect_success \
> 'validate git ls-files -k output.' \
> - 'diff .output .expected'
> + 'test_cmp .output .expected'
Same here.
>
> test_expect_success \
> 'git ls-files -m to show modified files.' \
> @@ -91,6 +91,6 @@ EOF
>
> test_expect_success \
> 'validate git ls-files -m output.' \
> - 'diff .output .expected'
> + 'test_cmp .output .expected'
And here.
>
> test_done
> diff --git a/t/t5000-tar-tree.sh b/t/t5000-tar-tree.sh
> index b7e3628..bfd593c 100755
> --- a/t/t5000-tar-tree.sh
> +++ b/t/t5000-tar-tree.sh
> @@ -76,7 +76,7 @@ test_expect_success \
>
> test_expect_success \
> 'git archive vs. git tar-tree' \
> - 'diff b.tar b2.tar'
> + 'test_cmp b.tar b2.tar'
>
> test_expect_success \
> 'git archive in a bare repo' \
> diff --git a/t/t9001-send-email.sh b/t/t9001-send-email.sh
> index 08d5b91..4fcc2e1 100755
> --- a/t/t9001-send-email.sh
> +++ b/t/t9001-send-email.sh
> @@ -88,7 +88,7 @@ cat >expected <<\EOF
> EOF
> test_expect_success \
> 'Verify commandline' \
> - 'diff commandline1 expected'
> + 'test_cmp commandline1 expected'
And here, too.
>
> cat >expected-show-all-headers <<\EOF
> 0001-Second.patch
^ permalink raw reply
* Re: Generalised bisection
From: Ealdwulf Wuffinga @ 2009-03-15 19:16 UTC (permalink / raw)
To: Steven Tweed
Cc: Johannes Schindelin, John Tapsell, Christian Couder, Git List
In-Reply-To: <d9c1caea0903130819u770686b1w867f074ffef8fabf@mail.gmail.com>
On Fri, Mar 13, 2009 at 3:19 PM, Steven Tweed <orthochronous@gmail.com> wrote:
> Underflow when using probabilities and lack of precision (rather than
> overflow) when using negated logarithms are well known problems in the
> kind of probabilistic object tracking, inference in graphical networks
> and object identification processes I work with (in computer vision).
> I there may well be other areas of Bayesian decision theory where this
> doesn't happen, and indeed a _very_ quick scan through your document
> suggests that you're adding to tallying information on each timestep
> and recalcuating the entire model from those tallys, which is one of
> the few cases where you can't really do rescaling. I'll try and have a
> more detailled read over the weekend.
That is useful information, thanks.
It is not obvious how to perform this algorithm incrementally, because
of the need to
marginalise out the fault rate. As I understand it, marginalisation
has to be done after you
have incorporated all your information into the model, which means we
can't use the
usual bayesian updating.
> On Fri, Mar 13, 2009 at 12:49 PM, Ealdwulf Wuffinga
> <ealdwulf@googlemail.com> wrote:
>> 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.
>
> Yes, "Numerical Recipes" seems to suggest that computing with
> log-factorials and exponentiating works reasonably, although I've
> never tried it and NR does occasionally get things completely wrong...
I have implemented this and it does indeed allow the program to work
in more cases
without underflow, with ordinary floating point. However, I think the
underflow can still occur
in plausible use cases.
The problem is still the Beta function. In bbchop it is always passed
D and T where D is
the sum of the number of detecting observations in some of the
revisions, and T is the
same for nondetecting observations. Beta(x,y) underflows a python float
if both x and y are > ~550, and also in other cases when one is
smaller and the other,
larger. BBChop never looks again at a revision if the bug has been
observed there, but if
there are a large number of revisions, it might look at enough of them
to cause a problem.
Obviously no-one is going to manually do hundreds of observations, but
I want BBChop
to work in the case where someone runs it on a machine in the corner
for a few days,
or even weeks, to track down a bug which occurs too infrequently to
bisect manually.
Which means I'm still stuck with mpmath, or some equivalent.
Ealdwulf
^ permalink raw reply
* Re: [PATCH 0/2] git checkout: one bugfix and one cosmetic change
From: Junio C Hamano @ 2009-03-15 19:38 UTC (permalink / raw)
To: Scott Chacon; +Cc: git, Kjetil Barvik
In-Reply-To: <7vab7m8x5w.fsf@gitster.siamese.dyndns.org>
Junio C Hamano <gitster@pobox.com> writes:
> Kjetil Barvik <barvik@broadpark.no> writes:
>
>> Just one small bugfix patch, and one small cosmetic change.
>>
>> By the way, I wonder how often the list of 'Primary Authors' and
>> 'Contributors' on the webpage http://git-scm.com/about is updated.
>> Should'nt it be updated when a new release, like v1.6.2, is made?
>
> Thanks for noticing. Though git-scm.com is not under my control, the site
> is considered the official git homepage these days, and I am glad to see
> improvements to its contents discussed here. I do not see Scott very
> often on this list these days, so I am CC'ing him.
Ragarding the list on the page, I have one thought (not complete enough to
be called suggestion) and one datapoint:
(1) The boundary between the "Primary Authors" vs "Contributors" seems to
be set at 50 commits with the current table. This would mean that we
will have a lot more primary authors as project progresses. Is this
desirable?
We have 14999 non-merge commits as of 1.6.2; perhaps a per-cent (or a
half per-cent) cutoff rule would give a more balanced and consistent
view in the longer term [*1*]?
(2) This script:
$ git shortlog -s v1.6.1 | sed -e 's/^[ 0-9]*//' >/var/tmp/1
$ git shortlog -s v1.6.2 | sed -e 's/^[ 0-9]*//' >/var/tmp/2
$ comm -13 /var/tmp/[12]
produces the list of new contributors. There are 39 names [*2*].
[Footnotes]
*1* A more drastic change would be not to have two lists, but just one.
*2* Thanks and welcome.
Allan Caffee, Ben Walton, Benjamin Kramer, Benjamin Sergeant, Benoit
Sigoure, Danijel Tasov, David J. Mellor, Devin Doucette, Dévai Tamás,
Elijah Newren, Eric Kidd, Fabian Franz, Felipe Contreras, Geoffrey
Thomas, Henrik Austad, Jacob Helwig, Jake Goulding, Jeremy White,
Johannes Gilger, Jonas Flodén, Keith Cascio, Kjetil Barvik, Marc
Branchaud, Marc-Andre Lureau, Nazri Ramliy, Pat Notz, Paul Jarc, Peter
Oberndorfer, Ray Chuan, Roy Lee, Serge van den Boom, Sergei Organov,
Stefan Karpinski, Tay Ray Chuan, Ted Pavlic, Tor Arne Vestbø, Vitaly
"_Vi" Shukela, Väinö Järvelä, jidanni@jidanni.org.
^ permalink raw reply
* Re: [PATCH] Autoconf: Disable inline for compilers that don't support it.
From: Junio C Hamano @ 2009-03-15 19:52 UTC (permalink / raw)
To: Allan Caffee; +Cc: git
In-Reply-To: <20090315152127.GA7988@linux.vnet>
Allan Caffee <allan.caffee@gmail.com> writes:
> My mistake; it looks like this macro will only work the way I described
> when using a config.h, which I see git is not currently doing. I
> assumed that it would also provide a -D flag to the precompiler if a
> configuration header isn't used but this doesn't appear to be case (from
> a cursory glance at the macros definition).
The design of our Makefile is such that it will default to some reasonable
values for the make variables depending on the environment, and people who
do not want to use the configure script can override them by creating
custom entries in config.mak manually, which is included by the Makefile.
OPTIONALLY configure can be used to produce config.mak.autogen that is
included just before config.mak is included (so that misdetection by
configure script can be overridden away by config.mak), so the same kind
of overriding happens.
I suspect addition of config.h, unless done carefully, will close the door
to the people who do not use configure to get certain customizations, and
when the same carefulness is applied, we probably do no need to introduce
config.h.
For example, for -Dinline=__inline__, I think you can:
(1) Add something like this near the beginning of the Makefile:
# Define USE_THIS_INLINE=__inline__ if your compiler does not
# understand "inline", but does understand __inline__.
#
# Define NO_INLINE=UnfortunatelyYes if your compiler does not
# understand "inline" at all.
(2) Add something like this after include "config.mak" happens in the
Makefile:
ifdef USE_THIS_INLINE
BASIC_CFLAGS += -Dinline=$(USE_THIS_INLINE)
else
ifdef NO_INLINE
BASIC_CFLAGS += -Dinline=""
endif
endif
(3) Add your new logic to configure.ac, _and_ arrange it to substitute
USE_THIS_INLINE if ac_cv_c_inline is not "inline", and set NO_INLINE
if it detected that the compiler does not understand inline in any
shape or form. You would need two new entries in config.mak.in, I
think.
^ permalink raw reply
* Re: [PATCH 2/2] make the ST_{C,M}TIME_NSEC macros more function like
From: Junio C Hamano @ 2009-03-15 20:01 UTC (permalink / raw)
To: Kjetil Barvik; +Cc: git
In-Reply-To: <0681248ac5c9cedf5f42adeeae89966a89e6d42a.1237115791.git.barvik@broadpark.no>
Kjetil Barvik <barvik@broadpark.no> writes:
> Make the macros take a pointer to a 'struct stat'. This is so that it
> should be easier to understand what is going on, and that the macros
> can later be implemented as a inline function if we want to.
>
> Impact: cosmetic change
Hmm,...
I have to wonder if this cosmetic change is an improvement, though.
I do not have a strong feeling either way, but I think it makes it clear
that these two macros are not lvalues if you do not pass a pointer but
instead pass a structure. An inline function can still take a structure
passed by value as an argument anyway, no?
^ permalink raw reply
* [PATCH] Fix various dead stores found by the clang static analyzer
From: Benjamin Kramer @ 2009-03-15 21:01 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
http-push.c::finish_request(): request is initialized by the for loop
index-pack.c::free_base_data(): b is initialized by the for loop
merge-recursive.c::process_renames(): move compare, remove unused
assigns
merge-recursive.c::process_renames(): remove unused variable renames2
xdiff/xdiffi.c::xdl_recs_cmp(): ec was unused
xdiff/xemit.c::xdl_emit_diff(): xche is always overwritten
Signed-off-by: Benjamin Kramer <benny.kra@googlemail.com>
---
http-push.c | 2 +-
index-pack.c | 2 +-
merge-recursive.c | 11 +++--------
xdiff/xdiffi.c | 5 ++---
xdiff/xemit.c | 2 +-
5 files changed, 8 insertions(+), 14 deletions(-)
diff --git a/http-push.c b/http-push.c
index 30d2d34..6715695 100644
--- a/http-push.c
+++ b/http-push.c
@@ -816,7 +816,7 @@ static void finish_request(struct transfer_request *request)
#ifdef USE_CURL_MULTI
static int fill_active_slot(void *unused)
{
- struct transfer_request *request = request_queue_head;
+ struct transfer_request *request;
if (aborted)
return 0;
diff --git a/index-pack.c b/index-pack.c
index 7fee872..7546822 100644
--- a/index-pack.c
+++ b/index-pack.c
@@ -232,7 +232,7 @@ static void free_base_data(struct base_data *c)
static void prune_base_data(struct base_data *retain)
{
- struct base_data *b = base_cache;
+ struct base_data *b;
for (b = base_cache;
base_cache_used > delta_base_cache_limit && b;
b = b->child) {
diff --git a/merge-recursive.c b/merge-recursive.c
index ee853b9..3e1bc3e 100644
--- a/merge-recursive.c
+++ b/merge-recursive.c
@@ -801,22 +801,19 @@ static int process_renames(struct merge_options *o,
}
for (i = 0, j = 0; i < a_renames->nr || j < b_renames->nr;) {
- int compare;
char *src;
- struct string_list *renames1, *renames2, *renames2Dst;
+ struct string_list *renames1, *renames2Dst;
struct rename *ren1 = NULL, *ren2 = NULL;
const char *branch1, *branch2;
const char *ren1_src, *ren1_dst;
if (i >= a_renames->nr) {
- compare = 1;
ren2 = b_renames->items[j++].util;
} else if (j >= b_renames->nr) {
- compare = -1;
ren1 = a_renames->items[i++].util;
} else {
- compare = strcmp(a_renames->items[i].string,
- b_renames->items[j].string);
+ int compare = strcmp(a_renames->items[i].string,
+ b_renames->items[j].string);
if (compare <= 0)
ren1 = a_renames->items[i++].util;
if (compare >= 0)
@@ -826,14 +823,12 @@ static int process_renames(struct merge_options *o,
/* TODO: refactor, so that 1/2 are not needed */
if (ren1) {
renames1 = a_renames;
- renames2 = b_renames;
renames2Dst = &b_by_dst;
branch1 = o->branch1;
branch2 = o->branch2;
} else {
struct rename *tmp;
renames1 = b_renames;
- renames2 = a_renames;
renames2Dst = &a_by_dst;
branch1 = o->branch2;
branch2 = o->branch1;
diff --git a/xdiff/xdiffi.c b/xdiff/xdiffi.c
index 3e97462..02184d9 100644
--- a/xdiff/xdiffi.c
+++ b/xdiff/xdiffi.c
@@ -293,15 +293,14 @@ int xdl_recs_cmp(diffdata_t *dd1, long off1, long lim1,
for (; off1 < lim1; off1++)
rchg1[rindex1[off1]] = 1;
} else {
- long ec;
xdpsplit_t spl;
spl.i1 = spl.i2 = 0;
/*
* Divide ...
*/
- if ((ec = xdl_split(ha1, off1, lim1, ha2, off2, lim2, kvdf, kvdb,
- need_min, &spl, xenv)) < 0) {
+ if (xdl_split(ha1, off1, lim1, ha2, off2, lim2, kvdf, kvdb,
+ need_min, &spl, xenv) < 0) {
return -1;
}
diff --git a/xdiff/xemit.c b/xdiff/xemit.c
index 05bfa41..c4bedf0 100644
--- a/xdiff/xemit.c
+++ b/xdiff/xemit.c
@@ -132,7 +132,7 @@ int xdl_emit_diff(xdfenv_t *xe, xdchange_t *xscr, xdemitcb_t *ecb,
if (xecfg->flags & XDL_EMIT_COMMON)
return xdl_emit_common(xe, xscr, ecb, xecfg);
- for (xch = xche = xscr; xch; xch = xche->next) {
+ for (xch = xscr; xch; xch = xche->next) {
xche = xdl_get_hunk(xch, xecfg);
s1 = XDL_MAX(xch->i1 - xecfg->ctxlen, 0);
--
1.6.2.173.g9e85
^ permalink raw reply related
* git-svn: creating tags from a subdirectory of trunk
From: Tom Huybrechts @ 2009-03-15 21:18 UTC (permalink / raw)
To: git
Hi,
I'm trying to setup a git mirror of a svn repository. The tags in
this repository are not created trunk it self, but from subdirectories
of trunk. The tags and branches are in the standard places.
e.g:
/trunk/main -> tags/main-1
/trunk/plugins/foo -> tags/foo-1
/trunk/plugins/bar -> tags/bar-1
I run 'git svn clone -s svn-url target'. It starts going over the
history nicely until it reaches the first branch. It calls this branch
something like tags/tag-name@revision, and starts retrieving the
entire project history again from r1. This is repeated for every
branch.
I've created a very small standalone shell script that demonstrates the problem:
=====
#!/bin/bash
REPO=`pwd`/svn-repo
WC=`pwd`/svn-wc
svnadmin create $REPO
REPO=file://$REPO
svn co $REPO $WC
SUBDIR=$WC/trunk/subdir
mkdir $WC/tags $WC/trunk $WC/branches $SUBDIR
svn add $WC/*
svn commit -m "structure" $WC
svn cp -m "create a tag" $REPO/trunk/subdir $REPO/tags/1
git svn clone -s $REPO git-repo
=====
When you run this, the output of git-svn is:
=====
Initialized empty Git repository in /home/tom/experiment/git-repo/.git/
W: +empty_dir: trunk/subdir
r1 = 3b90e67a4d8e9a2d32d4389b0f6ac93e23f38a46 (trunk)
Found possible branch point:
file:///home/tom/experiment/svn-repo/trunk/subdir =>
file:///home/tom/experiment/svn-repo/tags/1, 1
Initializing parent: tags/1@1
r1 = 0ad93ba4a7f6c43de30ab4dd05161662b75a6adb (tags/1@1)
Found branch parent: (tags/1) 0ad93ba4a7f6c43de30ab4dd05161662b75a6adb
Following parent with do_switch
Successfully followed parent
r2 = ce47fc7b4e21000c84da63ad5f643c18118d1918 (tags/1)
Checked out HEAD:
file:///home/tom/experiment/svn-repo/tags/1 r2
=====
Note the tags/1@1 and then starting over again from r1.
It's not so bad in this little example, but try this on a repository
with 200 tags and 16000 revisions...
So my question: is this normal or a bug ? Can I do something to import
this repository correctly ?
Thanks,
Tom
^ permalink raw reply
* Re: [PATCH 2/2] make the ST_{C,M}TIME_NSEC macros more function like
From: Kjetil Barvik @ 2009-03-15 21:59 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7v4oxu7dyn.fsf@gitster.siamese.dyndns.org>
Junio C Hamano <gitster@pobox.com> writes:
> Kjetil Barvik <barvik@broadpark.no> writes:
>
>> Make the macros take a pointer to a 'struct stat'. This is so that it
>> should be easier to understand what is going on, and that the macros
>> can later be implemented as a inline function if we want to.
>>
>> Impact: cosmetic change
>
> Hmm,...
>
> I have to wonder if this cosmetic change is an improvement, though.
>
> I do not have a strong feeling either way, but I think it makes it
> clear that these two macros are not lvalues if you do not pass a
> pointer but instead pass a structure. An inline function can still
> take a structure passed by value as an argument anyway, no?
It seems to woork from a small gcc test, but since C has call-by-
value, and http://en.wikipedia.org/wiki/Call_by_value#Call_by_value
says:
[...] in C or Pascal, calling a function with a large structure as
an argument will cause the entire structure to be copied,
potentially causing serious performance degradation, and mutations
to the structure are invisible to the caller. [...]
So in my eyes it make more sense to be consistent and take the address
of all struct like objects (&st in this case) for all arguments to
"function-like" things.
But, since these 2 are macros, which use textual substitution, I guess
things will work correctly either way, and the compiled result will be
the same. But, I still like the more "function friendly" macros.
-- kjetil
^ permalink raw reply
* Re: excluding files from a merge
From: Nanako Shiraishi @ 2009-03-15 22:14 UTC (permalink / raw)
To: Jay Soffian; +Cc: Daniel Jacobs, git
In-Reply-To: <76718490903150547o1c791d35r5d71000b481f443b@mail.gmail.com>
Quoting Jay Soffian <jaysoffian@gmail.com>:
> On Sat, Mar 14, 2009 at 9:23 PM, Daniel Jacobs <djacobs7@gmail.com> wrote:
>> I would like it if every file was merged, except for files that were explictly
>> excluded from a merge between these two branches. Is there a good way to do
>> this?
>
> Please see http://thread.gmane.org/gmane.comp.version-control.git/110488
> (Is there a way to exclude user-specified files or directories from
> participating in merges?)
>
> I believe it is the same use case, and Junio provided a very detailed reply.
Would it help to have the final summary by Sitaram Chamarty
http://article.gmane.org/gmane.comp.version-control.git/110697
somewhere under Documentation/howto?
--
Nanako Shiraishi
http://ivory.ap.teacup.com/nanako3/
^ permalink raw reply
* Re: git-svn: creating tags from a subdirectory of trunk
From: Eric Wong @ 2009-03-15 23:21 UTC (permalink / raw)
To: Tom Huybrechts; +Cc: git
In-Reply-To: <632a37a0903151418u483ca6cal1582518b9120da8e@mail.gmail.com>
Tom Huybrechts <tom.huybrechts@gmail.com> wrote:
> Hi,
>
> I'm trying to setup a git mirror of a svn repository. The tags in
> this repository are not created trunk it self, but from subdirectories
> of trunk. The tags and branches are in the standard places.
> e.g:
> /trunk/main -> tags/main-1
> /trunk/plugins/foo -> tags/foo-1
> /trunk/plugins/bar -> tags/bar-1
>
> I run 'git svn clone -s svn-url target'. It starts going over the
> history nicely until it reaches the first branch. It calls this branch
> something like tags/tag-name@revision, and starts retrieving the
> entire project history again from r1. This is repeated for every
> branch.
Hi Tom,
This is a known problem with some repositories. My suggestion is to
use individual "fetch" directives for each of those tags you want to
follow.
The -s/--stdlayout is only for projects that follow the SVN-recommended
repository layout exactly and we haven't thought of a generic way to
handle those non-standard tags in repos...
--
Eric Wong
^ permalink raw reply
* Re: setting up tracking on push
From: John M. Dlugosz @ 2009-03-16 1:07 UTC (permalink / raw)
To: git
In-Reply-To: <76718490903150536r2d3e687ckbcc4e1bdb2d2194d@mail.gmail.com>
Jay Soffian jaysoffian-at-gmail.com |git| wrote:
> I remember being just as confused, but oddly it seems so clear to me
> now. I think there is an inflection point where git goes from
> "confusing" to "ah hah, it's ingenious!" :-)
>
>
In this case, the confusion is with different people posting different
meanings for the term, and more generally using the term in different ways.
^ permalink raw reply
* Re: setting up tracking on push
From: Jay Soffian @ 2009-03-16 1:43 UTC (permalink / raw)
To: John M. Dlugosz; +Cc: git
In-Reply-To: <4218-19699@sneakemail.com>
On Sun, Mar 15, 2009 at 9:07 PM, John M. Dlugosz
<ngnr63q02@sneakemail.com> wrote:
> Jay Soffian jaysoffian-at-gmail.com |git| wrote:
> In this case, the confusion is with different people posting different
> meanings for the term, and more generally using the term in different ways.
In that case I'll stop replying to this thread, I wouldn't want to
cause any additional confusion. :-)
j.
^ permalink raw reply
* Re: excluding files from a merge
From: Jay Soffian @ 2009-03-16 1:45 UTC (permalink / raw)
To: Nanako Shiraishi; +Cc: Daniel Jacobs, git
In-Reply-To: <20090316071440.6117@nanako3.lavabit.com>
On Sun, Mar 15, 2009 at 6:14 PM, Nanako Shiraishi <nanako3@lavabit.com> wrote:
> Would it help to have the final summary by Sitaram Chamarty
>
> http://article.gmane.org/gmane.comp.version-control.git/110697
>
> somewhere under Documentation/howto?
I don't think it would hurt. A good explanation of remote tracking
branches, local branches, and what --track means might not hurt
either. :-)
j.
^ permalink raw reply
* [PATCH] grep: prefer builtin over external one when coloring results
From: pclouds @ 2009-03-16 2:20 UTC (permalink / raw)
To: git, rene.scharfe, gitster, thiago.salves
Cc: Nguyễn Thái Ngọc Duy
In-Reply-To: <49B6979B.8080900@lsrfire.ath.cx>
As far as I know, not all grep programs support coloring, so we should
rely on builtin grep. If you want external grep, set
color.grep.external to empty string.
Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com>
---
How about this?
builtin-grep.c | 2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/builtin-grep.c b/builtin-grep.c
index 9e7e766..89489dd 100644
--- a/builtin-grep.c
+++ b/builtin-grep.c
@@ -825,6 +825,8 @@ int cmd_grep(int argc, const char **argv, const char *prefix)
}
}
+ if (opt.color && !opt.color_external)
+ builtin_grep = 1;
if (!opt.pattern_list)
die("no pattern given.");
if ((opt.regflags != REG_NEWLINE) && opt.fixed)
--
1.6.1.446.gc7851
^ permalink raw reply related
* Re: [PATCH] git-push.txt: describe how to default to pushing only current branch
From: Junio C Hamano @ 2009-03-16 4:51 UTC (permalink / raw)
To: Jeff King; +Cc: Chris Johnsen, git
In-Reply-To: <20090314214603.GA20418@sigill.intra.peff.net>
Jeff King <peff@peff.net> writes:
> On Sat, Mar 14, 2009 at 02:25:11PM -0700, Junio C Hamano wrote:
>
>> Jeff King <peff@peff.net> writes:
>>
>> > Actually, looking closer, the information seems to be lost entirely.
>> > Asciidoc renders this to <literal> in the XML, but docbook seems to
>> > throw it away when converting to a manpage. In theory it's possible to
>> > apply our own xsl style to turn this into something else, and I think
>> > that is a better solution than just trying to fix this one spot.
>>
>> When I check the asciidoc output for manpages (which I rarely do), I often
>> render it to Postscript to see the typesetting. I guess not many people
>> consider manpages are for printing anymore but are solely for monospaced
>> terminal consumption these days.
>
> How do you render it? From the XML, or from the roff? Because if I am
> reading it right (which it is entirely possible that I am not), the
> information is lost in the roff version. And that is the version I would
> expect people to be looking at (via man -Tps, or just plain man).
I was agreeing with you; I let "man -Tps -l git-foo.1" render from roff
input and I can see that the output from asciidoc toolchain) prepared as
roff input does not consider printed pages so important anymore.
^ permalink raw reply
* [ANNOUNCE] GIT 1.6.2.1
From: Junio C Hamano @ 2009-03-16 4:52 UTC (permalink / raw)
To: git
The latest maintenance release GIT 1.6.2.1 is available at the
usual places:
http://www.kernel.org/pub/software/scm/git/
git-1.6.2.1.tar.{gz,bz2} (source tarball)
git-htmldocs-1.6.2.1.tar.{gz,bz2} (preformatted docs)
git-manpages-1.6.2.1.tar.{gz,bz2} (preformatted docs)
The RPM binary packages for a few architectures are found in:
RPMS//git-*-1.6.2.1-1.fc9.$arch.rpm (RPM)
----------------------------------------------------------------
GIT v1.6.2.1 Release Notes
==========================
Fixes since v1.6.2
------------------
* .gitignore learned to handle backslash as a quoting mechanism for
comment introduction character "#".
* timestamp output in --date=relative mode used to display timestamps that
are long time ago in the default mode; it now uses "N years M months
ago", and "N years ago".
* git-add -i/-p now works with non-ASCII pathnames.
* "git hash-object -w" did not read from the configuration file from the
correct .git directory.
* git-send-email learned to correctly handle multiple Cc: addresses.
^ permalink raw reply
* Re: What's cooking in git.git (Mar 2009, #01; Tue, 03)
From: Junio C Hamano @ 2009-03-16 4:53 UTC (permalink / raw)
To: Jeff King; +Cc: git
In-Reply-To: <20090303091504.GG3627@coredump.intra.peff.net>
Jeff King <peff@peff.net> writes:
> On Tue, Mar 03, 2009 at 01:01:45AM -0800, Junio C Hamano wrote:
>
>> As an experiment, 'next' and 'pu' stayed open during this release freeze;
>> new topics have been accepted. I have to say that the experiment was a
>> moderate success, and many topics in 'next' seem to be of fairly high
>> quality already, which would mean that we will have a shorter cycle before
>> 1.6.3.
>
> I was going to stay quiet on this issue until after 1.6.3 released, but
> now you have opened the topic. :)
>
> I think seeing the quality of topics in 'next' is only half of
> "success". You have to also consider how much attention was given to the
> about-to-be-released version (and its impact on quality). And I think we
> won't know about that until we see how quickly we need 1.6.3.1. :)
>
> Personally, I know that I have spent much less time focusing on
> 'master'. Like everyone else, I have limited git bandwidth, and topics
> in 'next' are simply more interesting. I think it's easier to put them
> aside for a few weeks if everybody agrees to do so (rather than having
> interesting discussion proceeding without you if you choose to focus on
> 'master').
With the first maintenance release after 1.6.2 behind us, I think we can
start to judge how successful the 1.6.2 cycle was fairly objectively.
During the pre-release freeze, we would want to encorage people to spend
as much time as possible on finding and fixing bugs and regressions in the
frozen 'master', and that was the reason why traditionally we closed
'next' during the pre-release freeze.
But in reality, contributors who had leftover topics on 'next' simply
stopped working on their topics on 'next' without spending the freed up
time on concentrating on 'master'. In an ideal world, the choice would be
between "git time on 'next'" vs "git time on 'master'", and closing 'next'
was meant to force the choice, but instead the outcome became "less git
time until 'next' reopens".
My suspicion, when deciding to keep the 'next' branch open during the
freeze, was that as long as people look at _any_ git code, even if it is
because they are working on their own topic that will never be in the
upcoming release, it would increase the chance of bugs getting discovered.
I do not know the exact count of bugfixes after 1.6.2-rc0 are attributable
to people who happened to notice glitches by accident while working on an
unrelated enhancements, but for me personally, I tend to notice more bugs
when I am not hunting for one but working on something else.
Also as a side effect, we had many topics on 'next' that are already
reasonably mature after 1.6.2, and I think we can have a short cycle for
the next one.
^ permalink raw reply
* Re: [PATCH v2] New config push.default to decide default behavior for push
From: Junio C Hamano @ 2009-03-16 4:55 UTC (permalink / raw)
To: Finn Arne Gangstad; +Cc: git
In-Reply-To: <7viqmbakmt.fsf@gitster.siamese.dyndns.org>
Junio C Hamano <gitster@pobox.com> writes:
> Finn Arne Gangstad <finnag@pvv.org> writes:
>
>> Something like this amended into the last commit? I can amend it on top
>> of the last one and resend if that is better.
>
> Thanks.
>
> I looked at these two patches after squashing them into one, and I think
> it makes sense as the final shape of a two patch series.
I seem to have forgotten to say what the two pieces in the series should
look like here. What I meant was a split along these lines:
(1) introduce the configuration variable, so that people who do not like
the current default can get a different default, but do not warn;
(2) start warning to notify the users of possible different settings and
forcing them to choose now, before we switch the default.
As some people still seem to object to the change of default (and that
includes 20-30% of myself), we may end up deciding not to switch the
default after all, but even in that case, applying the first half would
benefit people who would want different behaviour.
If we were to decide not to switch the default, applying (2) would force
people who want the current default to set the configuration only to
squelch the message, which is an annoying inconvenience.
But since then I thought about this a bit more, and I am inclined to
change my mind. Having (2) will allow people who wish there were a way to
have a different default to discover that there is already an easy way to
do so. The tradeoff between "a slight inconvenience to traditionalist" vs
"helping people to discover the feature designed for them, without which
they would be badly burned" does not look too bad to me.
^ 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