* Re: import files w/ history
From: Jeff King @ 2009-03-08 0:10 UTC (permalink / raw)
To: Csaba Henk; +Cc: git
In-Reply-To: <slrngr299k.1t4t.csaba-ml@beastie.creo.hu>
On Fri, Mar 06, 2009 at 01:29:38PM +0000, Csaba Henk wrote:
> $ git filter-branch --commit-filter '
> if [ $# -lt 3 ] || git diff --stat $3 $1 | grep -q 'sys/dev/disk/vn/vn\.c'
> then
> git commit-tree "$@"
> else
> skip_commit "$@"
> fi' HEAD
Wow, I'll bet that was slow to run. And it's not really what you want.
You are picking commits that changed a particular file, and then
including the _whole_ tree. Remember that commits really record a tree
state; we only think of them as "changes" because they point to a prior
commit with its own tree state. So you are just selecting some subset of
the states, but not cutting down the tree in each state.
What you really want to do is say:
- for every commit, narrow the tree to _just_ the one file
- if there were no changes in the narrowed tree, just throw out the
commit
You can use an --index-filter to do the former, and a --commit-filter to
do the latter (or just use --prune-empty, which is a shorthand).
Another poster had a similar problem, and you can see the right
filter-branch recipe there:
http://article.gmane.org/gmane.comp.version-control.git/111991
> * * *
>
> OK, I then tried to do more RTFM and be more clever and efficient, and
> find a way to specify directly those commits which affect vn.c. As "git
> rev-list" can be invoked like "git rev-list <commit> <path>", and the
> synopsis of "git filter-branch" is like
>
> git filter-branch [options] [--] [<rev-list options>...]
>
> I then gave a try to:
>
> $ git filter-branch -- master sys/dev/disk/vn/vn.c
>
> but no dice -- I got:
>
> fatal: ambiguous argument 'sys/dev/disk/vn/vn.c': unknown revision or
> path not in the working tree.
> Use '--' to separate paths from revisions
> Could not get the commits
>
> Any idea?
I think you need an extra '--' to separate the paths from the revisions
in the rev-list arguments:
git filter-branch -- master -- sys/dev/disk/vn/vn.c
but even that doesn't quite do what you want. It limits the commits that
are shown, similar to your first attempt above, but it doesn't cut down
the tree itself (OTOH, limiting by path rather than using --prune-empty
is likely to run faster, since you won't even look at commits that are
uninteresting. However, it may change the shape of your history with
respect to branching and merging).
-Peff
^ permalink raw reply
* Re: [PATCH 1/2] removed some unused variables
From: Jeff King @ 2009-03-07 23:52 UTC (permalink / raw)
To: Benjamin Kramer; +Cc: Junio C Hamano, git
In-Reply-To: <7f978c810903071202w59a5ca37id6d1fee405c24e9c@mail.gmail.com>
On Sat, Mar 07, 2009 at 09:02:10PM +0100, Benjamin Kramer wrote:
> these variables were unused and can be removed safely
>
> builtin-clone: removed unused variable 'option_no_hardlinks'
I did a double-take here, as I was just looking at option_no_hardlinks
code the other day. But looking at your patch, I think you meant
"use_local_hardlinks".
> @@ -388,9 +386,6 @@ int cmd_clone(int argc, const char **argv, const
> char *prefix)
Your patch is damaged due to wrapping here (and several other places).
Please check your mailer settings.
Other than that, I think it is a fine cleanup.
-Peff
^ permalink raw reply
* Re: Clone a repo and checkout a specifc remote branch
From: Paolo Ciarrocchi @ 2009-03-07 23:25 UTC (permalink / raw)
To: Patrick Notz; +Cc: git list
In-Reply-To: <1cd1989b0903071053l3f7aa35bu8e8e6b7e56cfc34f@mail.gmail.com>
On 3/7/09, Patrick Notz <patnotz@gmail.com> wrote:
>> Something like:
>> $ git clone git://uri_of_the_repo:coolbranch localdir
>> to get a clone of the whole repository and to check out the
>> origin/coolbranch remote branch?
>>
>
> Here's a link to a recent thread on this topic (that started with a
> proposed patch)
>
> http://thread.gmane.org/gmane.comp.version-control.git/111967
>
> You can read the arguments there. Johannes Schindelin noted that the
> normal way to do this is like this:
>
> <quote>
> Besides, the common way to check out something different than the remote's
> HEAD is like this:
>
> $ git clone -n $URL
> $ cd $DIR
> $ git checkout -t origin/$BRANCH
> </quote>
Thank you, very appreciated, I missed that discussion.
I'll add my comments to that thread.
Regards,
--
Paolo
http://paolo.ciarrocchi.googlepages.com/
http://mypage.vodafone.it/
^ permalink raw reply
* Re: [PATCH/RFD] builtin-revert.c: release index lock when cherry-picking an empty commit
From: Chris Johnsen @ 2009-03-07 22:57 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git, Junio C Hamano, Miklos Vajna
In-Reply-To: <alpine.DEB.1.00.0903071212350.10279@pacific.mpi-cbg.de>
On 2009 Mar 7, Johannes Schindelin wrote:
> I wonder, though, if the real root of the problem is that there is
> copied code.
Agreed.
> IOW I think it would be better to introduce a global
> function that writes the index to a tree.
I am not quite sure I follow your meaning here.
We have write_cache_as_tree in cache-tree.c. Is something like that
what you had in mind for "write the index to a tree"?
Could you elaborate on how an "index to tree" function could be
applied to the problem of the inconsistent lock releasing around
commit_locked_index calls? Sorry, for my lack of a clue, I am fairly
new to the code base. Or are you seeing a different code duplication
problem here?
The general form of the code around calls to commit_locked_index
seems to be of the this form:
if (some_condition) /* not all call sites use this */
if (write_cache(...) || commit_locked_index(...))
die(...); /* or return error(...) */
rollback_lock_file(...); /* sometimes missing or distant */
In most cases some_condition is active_cache_changed, but not always
(builtin-apply.c, rerere.c).
The problem with cherry-picking empty commits was that
active_cache_changed (used as some_condition in the general pattern
shown above) would be false, so the write and commit was skipped, but
there was also never any rollback. Later, when cherry-pick exec-ed
commit, the lock file still existed and commit dies.
To make sure a commit or a rollback always happens at every call
site, each one would have to unconditionally call some global
function (write_and_commit_or_rollback_locked_index?, ick) that
conditionally did the write and commit, but unconditionally did the
rollback (basically a no-op if the commit went OK).
> A quick "git grep commit_locked_index" reveals quite a few code
> sites...
Indeed, would such a cleanup be worth the churn? I do not have any
modifications for which this cleanup could be considered preparatory.
Thank you for your help!
--
Chris
^ permalink raw reply
* Re: [EGIT PATCH] Evaluate short refnames into full names during push
From: Shawn O. Pearce @ 2009-03-07 22:48 UTC (permalink / raw)
To: Robin Rosenberg; +Cc: git, Daniel Cheng
In-Reply-To: <1236464299-11491-1-git-send-email-robin.rosenberg@dewire.com>
Robin Rosenberg <robin.rosenberg@dewire.com> wrote:
> @@ -243,10 +244,24 @@ else if (TransportLocal.canHandle(remote))
> final Collection<RefSpec> procRefs = expandPushWildcardsFor(db, specs);
>
> for (final RefSpec spec : procRefs) {
> - final String srcRef = spec.getSource();
> + String srcRef = spec.getSource();
> + final Ref src = db.getRef(srcRef);
> + if (src != null)
> + srcRef = src.getName();
> + String remoteName = spec.getDestination();
> // null destination (no-colon in ref-spec) is a special case
> - final String remoteName = (spec.getDestination() == null ? spec
> - .getSource() : spec.getDestination());
Oh, right. I forgot about the fact that Marek put the code here, as
then "push = master" in a config file works...
OK. I'll apply.
--
Shawn.
^ permalink raw reply
* Re: [PATCH 2/3] config: set help text for --bool-or-int
From: Jeff King @ 2009-03-07 22:48 UTC (permalink / raw)
To: Felipe Contreras; +Cc: git, Junio C Hamano
In-Reply-To: <94a0d4530903071307p46092810rb1637bfc853ee4d1@mail.gmail.com>
On Sat, Mar 07, 2009 at 11:07:46PM +0200, Felipe Contreras wrote:
> On Sat, Mar 7, 2009 at 7:14 PM, Jeff King <peff@peff.net> wrote:
> > The conversion to parse_opt left this as NULL; on glibc
> > systems, the usage message prints
> >
> > --bool-or-int (null)
> >
> > and on other ones, segfaults.
>
> Shouldn't then OPT_BIT make sure there is no crash?
Perhaps, but it doesn't (and I assume you mean usage_with_help, as
OPT_BIT is just filling in the struct). It's not clear what a NULL help
parameter should do, though. Hide the option? Show no help description?
There are already ways to accomplish both of those.
> I was surprised when it didn't complain. I thought on making it "" but
> I wanted to make it visible that there was no documentation for that,
> which is the reason I left it that way.
OK. I think there are really valid options:
1. it's there with a description (which is what my patch does)
2. it's there without a description, because it's obvious what it does
coming after --bool and --int
3. it's hidden
I really don't care which. But what is there now is broken.
-Peff
^ permalink raw reply
* [EGIT PATCH] Evaluate short refnames into full names during push
From: Robin Rosenberg @ 2009-03-07 22:18 UTC (permalink / raw)
To: spearce; +Cc: git, Daniel Cheng, Robin Rosenberg
In-Reply-To: <20090307211008.GP16213@spearce.org>
With this we can use short names like master instead of refs/heads/master
when pushing. This is slightly more convenient. Pushing a delete still
requires the long format.
Signed-off-by: Robin Rosenberg <robin.rosenberg@dewire.com>
---
.../src/org/spearce/jgit/lib/Repository.java | 11 ++++++++++
.../src/org/spearce/jgit/transport/Transport.java | 21 +++++++++++++++++--
2 files changed, 29 insertions(+), 3 deletions(-)
diff --git a/org.spearce.jgit/src/org/spearce/jgit/lib/Repository.java b/org.spearce.jgit/src/org/spearce/jgit/lib/Repository.java
index 30bd4a3..3ab51b1 100644
--- a/org.spearce.jgit/src/org/spearce/jgit/lib/Repository.java
+++ b/org.spearce.jgit/src/org/spearce/jgit/lib/Repository.java
@@ -928,6 +928,17 @@ public String getBranch() throws IOException {
}
/**
+ * Get a ref by name.
+ *
+ * @param name
+ * @return the Ref with the given name, or null if it does not exist
+ * @throws IOException
+ */
+ public Ref getRef(final String name) throws IOException {
+ return refs.readRef(name);
+ }
+
+ /**
* @return all known refs (heads, tags, remotes).
*/
public Map<String, Ref> getAllRefs() {
diff --git a/org.spearce.jgit/src/org/spearce/jgit/transport/Transport.java b/org.spearce.jgit/src/org/spearce/jgit/transport/Transport.java
index 3aec5ca..64745a8 100644
--- a/org.spearce.jgit/src/org/spearce/jgit/transport/Transport.java
+++ b/org.spearce.jgit/src/org/spearce/jgit/transport/Transport.java
@@ -51,6 +51,7 @@
import org.spearce.jgit.errors.NotSupportedException;
import org.spearce.jgit.errors.TransportException;
+import org.spearce.jgit.lib.Constants;
import org.spearce.jgit.lib.NullProgressMonitor;
import org.spearce.jgit.lib.ProgressMonitor;
import org.spearce.jgit.lib.Ref;
@@ -243,10 +244,24 @@ else if (TransportLocal.canHandle(remote))
final Collection<RefSpec> procRefs = expandPushWildcardsFor(db, specs);
for (final RefSpec spec : procRefs) {
- final String srcRef = spec.getSource();
+ String srcRef = spec.getSource();
+ final Ref src = db.getRef(srcRef);
+ if (src != null)
+ srcRef = src.getName();
+ String remoteName = spec.getDestination();
// null destination (no-colon in ref-spec) is a special case
- final String remoteName = (spec.getDestination() == null ? spec
- .getSource() : spec.getDestination());
+ if (remoteName == null) {
+ remoteName = srcRef;
+ } else {
+ if (!remoteName.startsWith(Constants.R_REFS)) {
+ // null source is another special case (delete)
+ if (srcRef != null) {
+ // assume the same type of ref at the destination
+ String srcPrefix = srcRef.substring(0, srcRef.indexOf('/', Constants.R_REFS.length()));
+ remoteName = srcPrefix + "/" + remoteName;
+ }
+ }
+ }
final boolean forceUpdate = spec.isForceUpdate();
final String localName = findTrackingRefName(remoteName, fetchSpecs);
--
1.6.1.285.g35d8b
^ permalink raw reply related
* Re: [PATCH] http: add_fill_function checks if function has been added
From: Junio C Hamano @ 2009-03-07 21:49 UTC (permalink / raw)
To: Tay Ray Chuan; +Cc: git
In-Reply-To: <be6fef0d0903071249s42ac7f94o82461ca32dcdfcd5@mail.gmail.com>
Tay Ray Chuan <rctay89@gmail.com> writes:
> Calling a fill function repeatedly won't break behaviour, because fill
> functions (those that are currently defined in git) are designed to be
> called repeatedly. But it's just useless to call the same fill
> function repeatedly without any reason.
>
> So should I still address the "THIS and THAT breakages"?
Your above explanation is good, but it was given after I asked ;-).
Making unnecessary call repeatedly counts as a breakage your patch fixes,
right?
I didn't look at the callers of add_fill_function(), but "fill" takes a
callback data and different invocation of add_fill_function() could be
passing different callback data. In such a case, doesn't it feel wrong to
omit the "duplicated" calls to register the fill callback? Your patch
makes me suspect that it _might_ be better to fix the callers not to call
the function repeatedly when they know they only want one-shot invocation.
^ permalink raw reply
* git-t4034-diff-words.sh.prb
From: Boyd Lynn Gerber @ 2009-03-07 21:47 UTC (permalink / raw)
To: Git List
Here are the test failures using set -x for git-t4032-diff-words.sh
--
Boyd Gerber <gerberb@zenez.com> 801 849-0213
ZENEZ 1042 East Fort Union #135, Midvale Utah 84047
$ bash ./t4034-diff-words.sh
+ test_description='word diff colors'
+ . ./test-lib.sh
++ ORIGINAL_TERM=xterm
++ LANG=C
++ LC_ALL=C
++ PAGER=cat
++ TZ=UTC
++ TERM=dumb
++ export LANG LC_ALL PAGER TERM TZ
++ EDITOR=:
++ VISUAL=:
++ unset GIT_EDITOR
++ unset AUTHOR_DATE
++ unset AUTHOR_EMAIL
++ unset AUTHOR_NAME
++ unset COMMIT_AUTHOR_EMAIL
++ unset COMMIT_AUTHOR_NAME
++ unset EMAIL
++ unset GIT_ALTERNATE_OBJECT_DIRECTORIES
++ unset GIT_AUTHOR_DATE
++ GIT_AUTHOR_EMAIL=author@example.com
++ GIT_AUTHOR_NAME='A U Thor'
++ unset GIT_COMMITTER_DATE
++ GIT_COMMITTER_EMAIL=committer@example.com
++ GIT_COMMITTER_NAME='C O Mitter'
++ unset GIT_DIFF_OPTS
++ unset GIT_DIR
++ unset GIT_WORK_TREE
++ unset GIT_EXTERNAL_DIFF
++ unset GIT_INDEX_FILE
++ unset GIT_OBJECT_DIRECTORY
++ unset GIT_CEILING_DIRECTORIES
++ unset SHA1_FILE_DIRECTORIES
++ unset SHA1_FILE_DIRECTORY
++ GIT_MERGE_VERBOSITY=5
++ export GIT_MERGE_VERBOSITY
++ export GIT_AUTHOR_EMAIL GIT_AUTHOR_NAME
++ export GIT_COMMITTER_EMAIL GIT_COMMITTER_NAME
++ export EDITOR VISUAL
++ GIT_TEST_CMP='diff -u'
++ unset CDPATH
++ case $(echo $GIT_TRACE |tr "[A-Z]" "[a-z]") in
+++ echo
+++ tr '[A-Z]' '[a-z]'
++ '[' xxterm '!=' xdumb ']'
++ TERM=xterm
++ export TERM
++ '[' -t 1 ']'
++ tput bold
++ tput setaf 1
++ test 0 -ne 0
++ test -n ''
++ test 'word diff colors' '!=' ''
++ test '' = t
++ exec
++ test '' = t
++ exec
++ test_failure=0
++ test_count=0
++ test_fixed=0
++ test_broken=0
++ test_success=0
++ trap die EXIT
+++ pwd
++ TEST_DIRECTORY=/tmp/git-1.6.2/t
++ PATH=/tmp/git-1.6.2/t/..:/usr/local/bin:/usr/gnu/bin:/home/gerberb/bin:/usr/bin:/bin:/sbin:/usr/sbin:/etc:/usr/X11R6/bin
+++ pwd
++ GIT_EXEC_PATH=/tmp/git-1.6.2/t/..
+++ pwd
++ GIT_TEMPLATE_DIR=/tmp/git-1.6.2/t/../templates/blt
++ unset GIT_CONFIG
++ GIT_CONFIG_NOSYSTEM=1
++ GIT_CONFIG_NOGLOBAL=1
++ export PATH GIT_EXEC_PATH GIT_TEMPLATE_DIR GIT_CONFIG_NOSYSTEM GIT_CONFIG_NOGLOBAL
+++ pwd
+++ pwd
++ GITPERLLIB=/tmp/git-1.6.2/t/../perl/blib/lib:/tmp/git-1.6.2/t/../perl/blib/arch/auto/Git
++ export GITPERLLIB
++ test -d ../templates/blt
++ test -x ../test-chmtime
++ . ../GIT-BUILD-OPTIONS
+++ SHELL_PATH=/usr/bin/bash
+++ TAR=gtar
+++ basename ./t4034-diff-words.sh .sh
++ test='trash directory.t4034-diff-words'
++ test '!' -z ''
++ remove_trash='/tmp/git-1.6.2/t/trash directory.t4034-diff-words'
++ rm -fr 'trash directory.t4034-diff-words'
++ test_create_repo 'trash directory.t4034-diff-words'
++ test 1 = 1
+++ pwd
++ owd=/tmp/git-1.6.2/t
++ repo='trash directory.t4034-diff-words'
++ mkdir -p 'trash directory.t4034-diff-words'
++ cd 'trash directory.t4034-diff-words'
++ /tmp/git-1.6.2/t/../git init --template=/tmp/git-1.6.2/t/../templates/blt/
++ mv .git/hooks .git/hooks-disabled
++ cd /tmp/git-1.6.2/t
++ cd -P 'trash directory.t4034-diff-words'
+++ expr ././t4034-diff-words.sh : '.*/\(t[0-9]*\)-[^/]*$'
++ this_test=t4034
+ test_expect_success setup '
git config diff.color.old red
git config diff.color.new green
'
+ test 2 = 2
+ test_skip setup '
git config diff.color.old red
git config diff.color.new green
'
++ expr ././t4034-diff-words.sh : '.*/\(t[0-9]*\)-[^/]*$'
+ this_test=t4034
++ expr 0 + 1
+ this_test=t4034.1
+ to_skip=
+ case "$to_skip" in
+ false
+ say 'expecting success:
git config diff.color.old red
git config diff.color.new green
'
+ say_color info 'expecting success:
git config diff.color.old red
git config diff.color.new green
'
+ test -z info
+ shift
+ echo '* expecting success:
git config diff.color.old red
git config diff.color.new green
'
+ test_run_ '
git config diff.color.old red
git config diff.color.new green
'
+ eval '
git config diff.color.old red
git config diff.color.new green
'
+ eval_ret=0
+ return 0
+ '[' 0 = 0 -a 0 = 0 ']'
+ test_ok_ setup
++ expr 0 + 1
+ test_count=1
++ expr 0 + 1
+ test_success=1
+ say_color '' ' ok 1: setup'
+ test -z ''
+ test -n ''
+ shift
+ echo '* ok 1: setup'
* ok 1: setup
+ echo ''
+ cat
+ cat
+ cat
+ test_expect_success 'word diff with runs of whitespace' '
word_diff --color-words
'
+ test 2 = 2
+ test_skip 'word diff with runs of whitespace' '
word_diff --color-words
'
++ expr ././t4034-diff-words.sh : '.*/\(t[0-9]*\)-[^/]*$'
+ this_test=t4034
++ expr 1 + 1
+ this_test=t4034.2
+ to_skip=
+ case "$to_skip" in
+ false
+ say 'expecting success:
word_diff --color-words
'
+ say_color info 'expecting success:
word_diff --color-words
'
+ test -z info
+ shift
+ echo '* expecting success:
word_diff --color-words
'
+ test_run_ '
word_diff --color-words
'
+ eval '
word_diff --color-words
'
+ eval_ret=0
+ return 0
+ '[' 0 = 0 -a 0 = 0 ']'
+ test_ok_ 'word diff with runs of whitespace'
++ expr 1 + 1
+ test_count=2
++ expr 1 + 1
+ test_success=2
+ say_color '' ' ok 2: word diff with runs of whitespace'
+ test -z ''
+ test -n ''
+ shift
+ echo '* ok 2: word diff with runs of whitespace'
* ok 2: word diff with runs of whitespace
+ echo ''
+ cat
+ cp expect expect.letter-runs-are-words
+ test_expect_success 'word diff with a regular expression' '
word_diff --color-words="[a-z]+"
'
+ test 2 = 2
+ test_skip 'word diff with a regular expression' '
word_diff --color-words="[a-z]+"
'
++ expr ././t4034-diff-words.sh : '.*/\(t[0-9]*\)-[^/]*$'
+ this_test=t4034
++ expr 2 + 1
+ this_test=t4034.3
+ to_skip=
+ case "$to_skip" in
+ false
+ say 'expecting success:
word_diff --color-words="[a-z]+"
'
+ say_color info 'expecting success:
word_diff --color-words="[a-z]+"
'
+ test -z info
+ shift
+ echo '* expecting success:
word_diff --color-words="[a-z]+"
'
+ test_run_ '
word_diff --color-words="[a-z]+"
'
+ eval '
word_diff --color-words="[a-z]+"
'
+ eval_ret=0
+ return 0
+ '[' 0 = 0 -a 0 = 0 ']'
+ test_ok_ 'word diff with a regular expression'
++ expr 2 + 1
+ test_count=3
++ expr 2 + 1
+ test_success=3
+ say_color '' ' ok 3: word diff with a regular expression'
+ test -z ''
+ test -n ''
+ shift
+ echo '* ok 3: word diff with a regular expression'
* ok 3: word diff with a regular expression
+ echo ''
+ test_expect_success 'set a diff driver' '
git config diff.testdriver.wordRegex "[^[:space:]]" &&
cat <<EOF > .gitattributes
pre diff=testdriver
post diff=testdriver
EOF
'
+ test 2 = 2
+ test_skip 'set a diff driver' '
git config diff.testdriver.wordRegex "[^[:space:]]" &&
cat <<EOF > .gitattributes
pre diff=testdriver
post diff=testdriver
EOF
'
++ expr ././t4034-diff-words.sh : '.*/\(t[0-9]*\)-[^/]*$'
+ this_test=t4034
++ expr 3 + 1
+ this_test=t4034.4
+ to_skip=
+ case "$to_skip" in
+ false
+ say 'expecting success:
git config diff.testdriver.wordRegex "[^[:space:]]" &&
cat <<EOF > .gitattributes
pre diff=testdriver
post diff=testdriver
EOF
'
+ say_color info 'expecting success:
git config diff.testdriver.wordRegex "[^[:space:]]" &&
cat <<EOF > .gitattributes
pre diff=testdriver
post diff=testdriver
EOF
'
+ test -z info
+ shift
+ echo '* expecting success:
git config diff.testdriver.wordRegex "[^[:space:]]" &&
cat <<EOF > .gitattributes
pre diff=testdriver
post diff=testdriver
EOF
'
+ test_run_ '
git config diff.testdriver.wordRegex "[^[:space:]]" &&
cat <<EOF > .gitattributes
pre diff=testdriver
post diff=testdriver
EOF
'
+ eval '
git config diff.testdriver.wordRegex "[^[:space:]]" &&
cat <<EOF > .gitattributes
pre diff=testdriver
post diff=testdriver
EOF
'
+ eval_ret=0
+ return 0
+ '[' 0 = 0 -a 0 = 0 ']'
+ test_ok_ 'set a diff driver'
++ expr 3 + 1
+ test_count=4
++ expr 3 + 1
+ test_success=4
+ say_color '' ' ok 4: set a diff driver'
+ test -z ''
+ test -n ''
+ shift
+ echo '* ok 4: set a diff driver'
* ok 4: set a diff driver
+ echo ''
+ test_expect_success 'option overrides .gitattributes' '
word_diff --color-words="[a-z]+"
'
+ test 2 = 2
+ test_skip 'option overrides .gitattributes' '
word_diff --color-words="[a-z]+"
'
++ expr ././t4034-diff-words.sh : '.*/\(t[0-9]*\)-[^/]*$'
+ this_test=t4034
++ expr 4 + 1
+ this_test=t4034.5
+ to_skip=
+ case "$to_skip" in
+ false
+ say 'expecting success:
word_diff --color-words="[a-z]+"
'
+ say_color info 'expecting success:
word_diff --color-words="[a-z]+"
'
+ test -z info
+ shift
+ echo '* expecting success:
word_diff --color-words="[a-z]+"
'
+ test_run_ '
word_diff --color-words="[a-z]+"
'
+ eval '
word_diff --color-words="[a-z]+"
'
+ eval_ret=0
+ return 0
+ '[' 0 = 0 -a 0 = 0 ']'
+ test_ok_ 'option overrides .gitattributes'
++ expr 4 + 1
+ test_count=5
++ expr 4 + 1
+ test_success=5
+ say_color '' ' ok 5: option overrides .gitattributes'
+ test -z ''
+ test -n ''
+ shift
+ echo '* ok 5: option overrides .gitattributes'
* ok 5: option overrides .gitattributes
+ echo ''
+ cat
+ cp expect expect.non-whitespace-is-word
+ test_expect_success 'use regex supplied by driver' '
word_diff --color-words
'
+ test 2 = 2
+ test_skip 'use regex supplied by driver' '
word_diff --color-words
'
++ expr ././t4034-diff-words.sh : '.*/\(t[0-9]*\)-[^/]*$'
+ this_test=t4034
++ expr 5 + 1
+ this_test=t4034.6
+ to_skip=
+ case "$to_skip" in
+ false
+ say 'expecting success:
word_diff --color-words
'
+ say_color info 'expecting success:
word_diff --color-words
'
+ test -z info
+ shift
+ echo '* expecting success:
word_diff --color-words
'
+ test_run_ '
word_diff --color-words
'
+ eval '
word_diff --color-words
'
+ eval_ret=2
+ return 0
+ '[' 0 = 0 -a 2 = 0 ']'
+ test_failure_ 'use regex supplied by driver' '
word_diff --color-words
'
++ expr 5 + 1
+ test_count=6
++ expr 0 + 1
+ test_failure=1
+ say_color error 'FAIL 6: use regex supplied by driver'
+ test -z error
+ shift
+ echo '* FAIL 6: use regex supplied by driver'
* FAIL 6: use regex supplied by driver
+ shift
+ echo '
word_diff --color-words
'
+ sed -e 's/^/ /'
word_diff --color-words
+ test '' = ''
+ echo ''
+ test_expect_success 'set diff.wordRegex option' '
git config diff.wordRegex "[[:alnum:]]+"
'
+ test 2 = 2
+ test_skip 'set diff.wordRegex option' '
git config diff.wordRegex "[[:alnum:]]+"
'
++ expr ././t4034-diff-words.sh : '.*/\(t[0-9]*\)-[^/]*$'
+ this_test=t4034
++ expr 6 + 1
+ this_test=t4034.7
+ to_skip=
+ case "$to_skip" in
+ false
+ say 'expecting success:
git config diff.wordRegex "[[:alnum:]]+"
'
+ say_color info 'expecting success:
git config diff.wordRegex "[[:alnum:]]+"
'
+ test -z info
+ shift
+ echo '* expecting success:
git config diff.wordRegex "[[:alnum:]]+"
'
+ test_run_ '
git config diff.wordRegex "[[:alnum:]]+"
'
+ eval '
git config diff.wordRegex "[[:alnum:]]+"
'
+ eval_ret=0
+ return 0
+ '[' 0 = 0 -a 0 = 0 ']'
+ test_ok_ 'set diff.wordRegex option'
++ expr 6 + 1
+ test_count=7
++ expr 5 + 1
+ test_success=6
+ say_color '' ' ok 7: set diff.wordRegex option'
+ test -z ''
+ test -n ''
+ shift
+ echo '* ok 7: set diff.wordRegex option'
* ok 7: set diff.wordRegex option
+ echo ''
+ cp expect.letter-runs-are-words expect
+ test_expect_success 'command-line overrides config' '
word_diff --color-words="[a-z]+"
'
+ test 2 = 2
+ test_skip 'command-line overrides config' '
word_diff --color-words="[a-z]+"
'
++ expr ././t4034-diff-words.sh : '.*/\(t[0-9]*\)-[^/]*$'
+ this_test=t4034
++ expr 7 + 1
+ this_test=t4034.8
+ to_skip=
+ case "$to_skip" in
+ false
+ say 'expecting success:
word_diff --color-words="[a-z]+"
'
+ say_color info 'expecting success:
word_diff --color-words="[a-z]+"
'
+ test -z info
+ shift
+ echo '* expecting success:
word_diff --color-words="[a-z]+"
'
+ test_run_ '
word_diff --color-words="[a-z]+"
'
+ eval '
word_diff --color-words="[a-z]+"
'
+ eval_ret=0
+ return 0
+ '[' 0 = 0 -a 0 = 0 ']'
+ test_ok_ 'command-line overrides config'
++ expr 7 + 1
+ test_count=8
++ expr 6 + 1
+ test_success=7
+ say_color '' ' ok 8: command-line overrides config'
+ test -z ''
+ test -n ''
+ shift
+ echo '* ok 8: command-line overrides config'
* ok 8: command-line overrides config
+ echo ''
+ cp expect.non-whitespace-is-word expect
+ test_expect_success '.gitattributes override config' '
word_diff --color-words
'
+ test 2 = 2
+ test_skip '.gitattributes override config' '
word_diff --color-words
'
++ expr ././t4034-diff-words.sh : '.*/\(t[0-9]*\)-[^/]*$'
+ this_test=t4034
++ expr 8 + 1
+ this_test=t4034.9
+ to_skip=
+ case "$to_skip" in
+ false
+ say 'expecting success:
word_diff --color-words
'
+ say_color info 'expecting success:
word_diff --color-words
'
+ test -z info
+ shift
+ echo '* expecting success:
word_diff --color-words
'
+ test_run_ '
word_diff --color-words
'
+ eval '
word_diff --color-words
'
+ eval_ret=2
+ return 0
+ '[' 0 = 0 -a 2 = 0 ']'
+ test_failure_ '.gitattributes override config' '
word_diff --color-words
'
++ expr 8 + 1
+ test_count=9
++ expr 1 + 1
+ test_failure=2
+ say_color error 'FAIL 9: .gitattributes override config'
+ test -z error
+ shift
+ echo '* FAIL 9: .gitattributes override config'
* FAIL 9: .gitattributes override config
+ shift
+ echo '
word_diff --color-words
'
+ sed -e 's/^/ /'
word_diff --color-words
+ test '' = ''
+ echo ''
+ test_expect_success 'remove diff driver regex' '
git config --unset diff.testdriver.wordRegex
'
+ test 2 = 2
+ test_skip 'remove diff driver regex' '
git config --unset diff.testdriver.wordRegex
'
++ expr ././t4034-diff-words.sh : '.*/\(t[0-9]*\)-[^/]*$'
+ this_test=t4034
++ expr 9 + 1
+ this_test=t4034.10
+ to_skip=
+ case "$to_skip" in
+ false
+ say 'expecting success:
git config --unset diff.testdriver.wordRegex
'
+ say_color info 'expecting success:
git config --unset diff.testdriver.wordRegex
'
+ test -z info
+ shift
+ echo '* expecting success:
git config --unset diff.testdriver.wordRegex
'
+ test_run_ '
git config --unset diff.testdriver.wordRegex
'
+ eval '
git config --unset diff.testdriver.wordRegex
'
+ eval_ret=0
+ return 0
+ '[' 0 = 0 -a 0 = 0 ']'
+ test_ok_ 'remove diff driver regex'
++ expr 9 + 1
+ test_count=10
++ expr 7 + 1
+ test_success=8
+ say_color '' ' ok 10: remove diff driver regex'
+ test -z ''
+ test -n ''
+ shift
+ echo '* ok 10: remove diff driver regex'
* ok 10: remove diff driver regex
+ echo ''
+ cat
+ test_expect_success 'use configured regex' '
word_diff --color-words
'
+ test 2 = 2
+ test_skip 'use configured regex' '
word_diff --color-words
'
++ expr ././t4034-diff-words.sh : '.*/\(t[0-9]*\)-[^/]*$'
+ this_test=t4034
++ expr 10 + 1
+ this_test=t4034.11
+ to_skip=
+ case "$to_skip" in
+ false
+ say 'expecting success:
word_diff --color-words
'
+ say_color info 'expecting success:
word_diff --color-words
'
+ test -z info
+ shift
+ echo '* expecting success:
word_diff --color-words
'
+ test_run_ '
word_diff --color-words
'
+ eval '
word_diff --color-words
'
+ eval_ret=0
+ return 0
+ '[' 0 = 0 -a 0 = 0 ']'
+ test_ok_ 'use configured regex'
++ expr 10 + 1
+ test_count=11
++ expr 8 + 1
+ test_success=9
+ say_color '' ' ok 11: use configured regex'
+ test -z ''
+ test -n ''
+ shift
+ echo '* ok 11: use configured regex'
* ok 11: use configured regex
+ echo ''
+ echo 'aaa (aaa)'
+ echo 'aaa (aaa) aaa'
+ cat
+ test_expect_success 'test parsing words for newline' '
word_diff --color-words="a+"
'
+ test 2 = 2
+ test_skip 'test parsing words for newline' '
word_diff --color-words="a+"
'
++ expr ././t4034-diff-words.sh : '.*/\(t[0-9]*\)-[^/]*$'
+ this_test=t4034
++ expr 11 + 1
+ this_test=t4034.12
+ to_skip=
+ case "$to_skip" in
+ false
+ say 'expecting success:
word_diff --color-words="a+"
'
+ say_color info 'expecting success:
word_diff --color-words="a+"
'
+ test -z info
+ shift
+ echo '* expecting success:
word_diff --color-words="a+"
'
+ test_run_ '
word_diff --color-words="a+"
'
+ eval '
word_diff --color-words="a+"
'
+ eval_ret=2
+ return 0
+ '[' 0 = 0 -a 2 = 0 ']'
+ test_failure_ 'test parsing words for newline' '
word_diff --color-words="a+"
'
++ expr 11 + 1
+ test_count=12
++ expr 2 + 1
+ test_failure=3
+ say_color error 'FAIL 12: test parsing words for newline'
+ test -z error
+ shift
+ echo '* FAIL 12: test parsing words for newline'
* FAIL 12: test parsing words for newline
+ shift
+ echo '
word_diff --color-words="a+"
'
+ sed -e 's/^/ /'
word_diff --color-words="a+"
+ test '' = ''
+ echo ''
+ echo '(:'
+ echo '('
+ cat
+ test_expect_success 'test when words are only removed at the end' '
word_diff --color-words=.
'
+ test 2 = 2
+ test_skip 'test when words are only removed at the end' '
word_diff --color-words=.
'
++ expr ././t4034-diff-words.sh : '.*/\(t[0-9]*\)-[^/]*$'
+ this_test=t4034
++ expr 12 + 1
+ this_test=t4034.13
+ to_skip=
+ case "$to_skip" in
+ false
+ say 'expecting success:
word_diff --color-words=.
'
+ say_color info 'expecting success:
word_diff --color-words=.
'
+ test -z info
+ shift
+ echo '* expecting success:
word_diff --color-words=.
'
+ test_run_ '
word_diff --color-words=.
'
+ eval '
word_diff --color-words=.
'
+ eval_ret=2
+ return 0
+ '[' 0 = 0 -a 2 = 0 ']'
+ test_failure_ 'test when words are only removed at the end' '
word_diff --color-words=.
'
++ expr 12 + 1
+ test_count=13
++ expr 3 + 1
+ test_failure=4
+ say_color error 'FAIL 13: test when words are only removed at the end'
+ test -z error
+ shift
+ echo '* FAIL 13: test when words are only removed at the end'
* FAIL 13: test when words are only removed at the end
+ shift
+ echo '
word_diff --color-words=.
'+ sed -e 's/^/ /'
word_diff --color-words=.
+ test '' = ''
+ echo ''
+ test_done
+ trap - EXIT
+ test_results_dir=/tmp/git-1.6.2/t/test-results
+ mkdir -p /tmp/git-1.6.2/t/test-results
+ test_results_path=/tmp/git-1.6.2/t/test-results/./t4034-diff-21979
+ echo 'total 13'
+ echo 'success 9'
+ echo 'fixed 0'
+ echo 'broken 0'
+ echo 'failed 4'
+ echo ''
+ test 0 '!=' 0
+ test 0 '!=' 0
+ msg='13 test(s)'
+ case "$test_failure" in
+ say_color error 'failed 4 among 13 test(s)'
+ test -z error
+ shift
+ echo '* failed 4 among 13 test(s)'
* failed 4 among 13 test(s)
+ exit 1
^ permalink raw reply
* Re: [PATCH] MinGW: fix diff --no-index /dev/null ...
From: Junio C Hamano @ 2009-03-07 21:40 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git, Johannes Sixt
In-Reply-To: <alpine.DEB.1.00.0903072133270.10279@pacific.mpi-cbg.de>
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> Unlike other places where a string is compared to /dev/null, in this case
> do not parse a diff, but rather command line parameters that have
> possibly been transformed from /dev/null to nul, so that the file can be
> opened.
> -- snap --
>
> If you like it, may I ask you to amend the message?
>
>> Should this go to 'maint'?
>
> Technically, yes, as it is a fix.
>
> However, it might not be necessary, as literally all Windows work on Git
> happens in git/mingw.git, git/mingw/j6t.git and git/mingw/4msysgit.git.
Yeah, I should have been clearer. Unless msysgit will have a maintenance
track for 1.6.1.X, there is no point.
Thanks for reading my mind and a clarified message I can use for amending.
^ permalink raw reply
* Re: [PATCH] MinGW: fix diff --no-index /dev/null ...
From: Johannes Sixt @ 2009-03-07 21:18 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Johannes Schindelin, git
In-Reply-To: <7v8wnhnl6t.fsf@gitster.siamese.dyndns.org>
On Samstag, 7. März 2009, Junio C Hamano wrote:
> Should this go to 'maint'?
I don't think that's necessary. It fixes only that someone literally writes on
the Windows command line
git diff --no-index nul foo.c
when on Unix one would have written
git diff --no-index /dev/null foo.c
In practice, only the test suite does this ;)
-- Hannes
^ permalink raw reply
* Re: [JGit] Push to new Amazon S3 does not work? ("funny refname")
From: Shawn O. Pearce @ 2009-03-07 21:10 UTC (permalink / raw)
To: Robin Rosenberg; +Cc: Daniel Cheng, git
In-Reply-To: <200903071850.38045.robin.rosenberg.lists@dewire.com>
Robin Rosenberg <robin.rosenberg.lists@dewire.com> wrote:
> lördag 07 mars 2009 17:05:02 skrev Daniel Cheng <j16sdiz+freenet@gmail.com>:
> > Pushing to new Amazon S3 repository does not work.
> > It say "funny refname" without pushing anything:
> >
> > <<<<<<<<<
> > $ jgit push s3 master
> > To amazon-s3://0NQ4APQ8R7S6HQ65TWR2@egitsdiz/1.git
> > ! [remote rejected] master -> master (funny refname)
> > $ s3cmd la
> > DIR s3://egitsdiz/1.git/
> > $
> > >>>>>>>>>
>
> This is not specific to s3. It seems jgit wants a fully qualified ref for the remote
> side, so refs/heads/master will work for the other protocols, and I guess s3 too.
Correct.
The "jgit push" command line client lacks the DWIMery of "git push".
Specifically, from a pure API usage perspective, "jgit push"
is responsible for expanding the user input of "master" into the
"refs/heads/master:refs/heads/master" refspec that the lower level
PushProcess class wants.
Here it failed to do that, and the lower-level transport (rightly)
rejected the invalid ref name.
Side note:
That API definition that says the client should do the DWIMery
of ref expansion also makes it nearly impossible to implement
"push matching" or "randomsha1:master" refspec, as the client
doesn't have the network connection open and doesn't have the
advertised ref information early enough.
The reason we punted on this and didn't do this particular
expansion DWIMery in "jgit push" is we lack a good way to resolve
"master" into "refs/heads/master", or "v1.0" into "refs/tags/v1.0".
Repository does not expose the ref lookup algorithm, only resolve(),
which converts "master" into a SHA-1 ObjectId.
If someone exposed this portion of the resolve logic in the
Repository class, I think it would be a fairly simple change
in Push to support this DIWMery.
But until then, you need to say:
jgit push s3 refs/heads/master:refs/heads/master
or maybe this DWIMery might work:
jgit push s3 refs/heads/master
Its been a while since I passed args. I usually have
remote.$name.push in place for things that I push to.
--
Shawn.
^ permalink raw reply
* Re: [PATCH 2/3] config: set help text for --bool-or-int
From: Felipe Contreras @ 2009-03-07 21:07 UTC (permalink / raw)
To: Jeff King; +Cc: git, Junio C Hamano
In-Reply-To: <1236446046-18319-3-git-send-email-peff@peff.net>
On Sat, Mar 7, 2009 at 7:14 PM, Jeff King <peff@peff.net> wrote:
> The conversion to parse_opt left this as NULL; on glibc
> systems, the usage message prints
>
> --bool-or-int (null)
>
> and on other ones, segfaults.
Shouldn't then OPT_BIT make sure there is no crash?
I was surprised when it didn't complain. I thought on making it "" but
I wanted to make it visible that there was no documentation for that,
which is the reason I left it that way.
--
Felipe Contreras
^ permalink raw reply
* Re: Git memory usage (1): fast-import
From: Shawn O. Pearce @ 2009-03-07 21:01 UTC (permalink / raw)
To: Sam Hocevar; +Cc: git
In-Reply-To: <20090307201920.GE12880@zoy.org>
Sam Hocevar <sam@zoy.org> wrote:
> I joined a project that uses very large binary files (up to 1 GiB) in
> a p4 repository and as I would like to use Git, I am trying to make it
> more memory-efficient when handling huge files.
Yikes. As you saw, this won't play well...
> In practice, it takes even more memory than that. Experiment shows
> that importing six 100 MiB files made of urandom data takes 370 MiB of
> memory [...]
Yes.
As you saw, this is the last object, the current object, the delta
index of the last object (in order to more efficiently compare the
current one to it), and the deflate buffer for the current object,
oh, and probably memory fragmentation....
I'm not surprised a 100 MiB file turned into 370 MiB heap usage.
> - stop trying to compute deltas in fast-import and leave that task
> to other tools
This isn't practical for source code imports, unless we do...
> (optionally, define a file size threshold beyond
> which the last file is not kept in memory, and maybe make that a
> configuration option).
what you suggest here. fast-import is faster than other methods
because we get some delta compression on the content, so the output
pack uses up less virtual memory when the front-end or end-user
finally gets around to doing `git repack -a -d -f` to recompute
the delta chains.
> - use a temporary file to store the deflate data when it reaches a
> given size threshold (and maybe make that a configuration option).
Zoiks. There's no reason for that.
A better method would be to just look at the size of the incoming
blob, and if its over some configured threshold (default e.g. 100
MB is perhaps sane) we just stream the data through deflate()
and into the pack file, with no delta compression.
That would also bypass the "massive" buffer in the last object slot,
as you point out above.
> - also, I haven't tracked all strbuf_* uses in fast-import, but I got
> the feeling that strbuf_release() could be used in a few places
> instead of strbuf_setlen(0) in order to free some memory.
Examples? I haven't gone through the code in detail since it
was modified to use strbufs. But I had the feeling that the code
wasn't freeing strbufs that it would just reuse on the next command,
and that are likely to be "smallish", e.g. just a few KiBs in size.
--
Shawn.
^ permalink raw reply
* After the Release I started the Tests I found a Problem git-t4020-diff-external.sh
From: Boyd Lynn Gerber @ 2009-03-07 21:01 UTC (permalink / raw)
To: Git List
This is on the SCO OpenServer 6.0 MP 4 release.
--
Boyd Gerber <gerberb@zenez.com> 801 849-0213
ZENEZ 1042 East Fort Union #135, Midvale Utah 84047
on t4020-diff-external.sh Here is the message on the failure.
* FAIL 12: force diff with "diff"
echo >.gitattributes "file diff" &&
git diff >actual &&
test_cmp "$TEST_DIRECTORY"/t4020/diff.NUL actual
This is what I see with set -x
+ echo NULZbetweenZwords
+ perl -pe 'y/Z/\000/'
+ test_expect_success 'force diff with "diff"' '
echo >.gitattributes "file diff" &&
git diff >actual &&
test_cmp "$TEST_DIRECTORY"/t4020/diff.NUL actual
'
+ test 2 = 2
+ test_skip 'force diff with "diff"' '
echo >.gitattributes "file diff" &&
git diff >actual &&
test_cmp "$TEST_DIRECTORY"/t4020/diff.NUL actual
'
++ expr ././t4020-diff-external.sh : '.*/\(t[0-9]*\)-[^/]*$'
+ this_test=t4020
++ expr 11 + 1
+ this_test=t4020.12
+ to_skip=
+ case "$to_skip" in
+ false
+ say 'expecting success:
echo >.gitattributes "file diff" &&
git diff >actual &&
test_cmp "$TEST_DIRECTORY"/t4020/diff.NUL actual
'
+ say_color info 'expecting success:
echo >.gitattributes "file diff" &&
git diff >actual &&
test_cmp "$TEST_DIRECTORY"/t4020/diff.NUL actual
'
+ test -z info
+ shift
+ echo '* expecting success:
echo >.gitattributes "file diff" &&
git diff >actual &&
test_cmp "$TEST_DIRECTORY"/t4020/diff.NUL actual
'
+ test_run_ '
echo >.gitattributes "file diff" &&
git diff >actual &&
test_cmp "$TEST_DIRECTORY"/t4020/diff.NUL actual
'
+ eval '
echo >.gitattributes "file diff" &&
git diff >actual &&
test_cmp "$TEST_DIRECTORY"/t4020/diff.NUL actual
'
+ eval_ret=2
+ return 0
+ '[' 0 = 0 -a 2 = 0 ']'
+ test_failure_ 'force diff with "diff"' '
echo >.gitattributes "file diff" &&
git diff >actual &&
test_cmp "$TEST_DIRECTORY"/t4020/diff.NUL actual
'
++ expr 11 + 1
+ test_count=12
++ expr 0 + 1
+ test_failure=1
+ say_color error 'FAIL 12: force diff with "diff"'
+ test -z error
+ shift
+ echo '* FAIL 12: force diff with "diff"'
* FAIL 12: force diff with "diff"
+ shift
+ echo '
echo >.gitattributes "file diff" &&
git diff >actual &&
test_cmp "$TEST_DIRECTORY"/t4020/diff.NUL actual
'+ sed -e 's/^/ /'
echo >.gitattributes "file diff" &&
git diff >actual &&
test_cmp "$TEST_DIRECTORY"/t4020/diff.NUL actual
^ permalink raw reply
* Re: [PATCH] Brown paper bag fix for MinGW 64-bit stat
From: Johannes Schindelin @ 2009-03-07 21:02 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Johannes Sixt, git
In-Reply-To: <7vzlfxnlx2.fsf@gitster.siamese.dyndns.org>
Hi,
On Sat, 7 Mar 2009, Junio C Hamano wrote:
> Johannes Schindelin <johannes.schindelin@gmx.de> writes:
>
> > When overriding the identifier "stat" so that "struct stat" will be
> > substituted with "struct _stati64" everywhere, I tried to fix the calls
> > to the _function_ stat(), too, but I forgot to change the earlier
> > attempt "stat64" to "_stati64" there.
> >
> > So, the stat() calls were overridden by calls to _stati64() instead.
> >
> > Unfortunately, there is a function _stati64() so that I missed that
> > calls to stat() were not actually overridden by calls to mingw_lstat(),
> > but t4200-rerere.sh showed the error.
> >
> > Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
>
> Since this is a fix-up to a new on 'master', I've applied the patch
> myself, but how would we want to handle MinGW related patches in general?
>
> My preference is to have somebody I can rely on receiving Acked forwards
> from (or pulling from).
My preference is to keep the tried and tested mingw.git maintainer... ;-)
Note: IMHO Windows support is really at most beta quality; I would prefer
only those using it who can fix bugs themselves, or have the means to make
others fix the bugs.
So technically, we do not need such a strict and rigid process as for
git.git itself, which is blessed with hundreds of contributors, due to
which is really is ready for the end-user.
Ciao,
Dscho
^ permalink raw reply
* Re: [GSoC] Google Summer of Code 2009 - new ideas
From: Shawn O. Pearce @ 2009-03-07 20:55 UTC (permalink / raw)
To: P Baker; +Cc: git
In-Reply-To: <526944450903071159v3ddc92c5q9b3239f2aef97ac8@mail.gmail.com>
P Baker <me@retrodict.com> wrote:
> I posted to this list serve a few days ago about one of the 2008 SoC
> ideas. Are those ideas still plausible? Specifically, I'm interested
> in pursuing the git-submodule update. Is this off the drawing board?
Its not off the table just because of what someone else proposed
as an ideas list for 2009.
A GSoC project is what the student makes of it. You propose
something that you are interested in working on, that you think
you can complete in the time available within the program calendar,
and that the larger Git community would like to see implemented.
I think your post fell flat a few days ago with no replies because
it just didn't seem to invite any response from people. Remember,
we're all quite busy with our own projects and lives too, just
like you are, and we do Git hacking/emailing in our spare time.
An email needs to be somewhat compelling and invite a reply in
order to get a reply...
--
Shawn.
^ permalink raw reply
* Re: [PATCH] http: add_fill_function checks if function has been added
From: Tay Ray Chuan @ 2009-03-07 20:49 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vy6vhm6it.fsf@gitster.siamese.dyndns.org>
Hi,
On Sun, Mar 8, 2009 at 4:18 AM, Junio C Hamano <gitster@pobox.com> wrote:
> Could you care to explain the following a bit better?
>
> - what "possible issues" you are addressing;
>
> - what changes in the behaviour that are not "obvious" we would be
> suffering from, if we apply this patch;
>
> - in what situation the performance _might_ be affected, in what way and
> to what extent.
(note: "repeatedly" here means looping over it, eg. while(condition)
fill_function(). )
Thanks for taking the time to give this clear and detailed example explanation.
However, at this point of time, I couldn't come up with a convincing
instance of where
*a fill function is added twice or more, and as a result
*something breaks as a result of invoking the function repeatedly
that was why I used the word "possible" as in "possible issues",
because this patch doesn't solve any existing issues (at least none
that I know of now).
Calling a fill function repeatedly won't break behaviour, because fill
functions (those that are currently defined in git) are designed to be
called repeatedly. But it's just useless to call the same fill
function repeatedly without any reason.
So should I still address the "THIS and THAT breakages"?
--
Cheers,
Ray Chuan
^ permalink raw reply
* Re: [PATCH] MinGW: fix diff --no-index /dev/null ...
From: Johannes Schindelin @ 2009-03-07 20:47 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Johannes Sixt
In-Reply-To: <7v8wnhnl6t.fsf@gitster.siamese.dyndns.org>
Hi,
On Sat, 7 Mar 2009, Junio C Hamano wrote:
> Johannes Schindelin <johannes.schindelin@gmx.de> writes:
>
> > diff --git a/diff-no-index.c b/diff-no-index.c
> > index 0a14268..598687b 100644
> > --- a/diff-no-index.c
> > +++ b/diff-no-index.c
> > @@ -38,6 +38,10 @@ static int get_mode(const char *path, int *mode)
> >
> > if (!path || !strcmp(path, "/dev/null"))
> > *mode = 0;
> > +#ifdef _WIN32
> > + else if (!strcasecmp(path, "nul"))
> > + *mode = 0;
> > +#endif
> > else if (!strcmp(path, "-"))
> > *mode = create_ce_mode(0666);
> > else if (lstat(path, &st))
>
> I had a brief "Huh? -- doesn't this call for an is_dev_null() helper"
> moment, but I think you are right that diff-no-index.c is the right place
> to special case it.
You're right, it needs to be explained in the commit message. So how
about this:
-- snip --
Unlike other places where a string is compared to /dev/null, in this case
do not parse a diff, but rather command line parameters that have
possibly been transformed from /dev/null to nul, so that the file can be
opened.
-- snap --
If you like it, may I ask you to amend the message?
> Should this go to 'maint'?
Technically, yes, as it is a fix.
However, it might not be necessary, as literally all Windows work on Git
happens in git/mingw.git, git/mingw/j6t.git and git/mingw/4msysgit.git.
Your call.
Thanks,
Dscho
^ permalink raw reply
* Git memory usage (1): fast-import
From: Sam Hocevar @ 2009-03-07 20:19 UTC (permalink / raw)
To: git
I joined a project that uses very large binary files (up to 1 GiB) in
a p4 repository and as I would like to use Git, I am trying to make it
more memory-efficient when handling huge files.
The first problem I am hitting is with fast-import. Currently it
keeps the last imported file in memory (end of store_object()) in order
to find interesting deltas with the next file. Since most huge binary
files are already compressed, it means that fast-importing two large
X MiB files is going to use at least 3X MiB of memory: once for the
first file, once for the second file, and once for the deflate data
that is going to be as large as the file itself.
In practice, it takes even more memory than that. Experiment shows
that importing six 100 MiB files made of urandom data takes 370 MiB of
memory (http://zoy.org/~sam/git/git-memory-usage.png) (simple script
available at http://zoy.org/~sam/git/gencommit.txt). I am unable to plot
how it behaves with 1 GiB files since I don't have enough memory, but I
don't see why the trend wouldn't stand.
I can understand it not being a priority, but I'm trying to think of
acceptable ways to fix this that do not mess with Git's performance in
more usual cases. Here is what I can think of:
- stop trying to compute deltas in fast-import and leave that task
to other tools (optionally, define a file size threshold beyond
which the last file is not kept in memory, and maybe make that a
configuration option).
- use a temporary file to store the deflate data when it reaches a
given size threshold (and maybe make that a configuration option).
- also, I haven't tracked all strbuf_* uses in fast-import, but I got
the feeling that strbuf_release() could be used in a few places
instead of strbuf_setlen(0) in order to free some memory.
Any thoughts?
--
Sam.
^ permalink raw reply
* Re: jGit Eclipse Plugin Feature
From: Robert Navarro @ 2009-03-07 20:19 UTC (permalink / raw)
To: Tor Arne Vestbø; +Cc: Robin Rosenberg, git
In-Reply-To: <49B2BF9A.9030405@gmail.com>
Hey Guys,
While I haven't programmed java in years, nor have I ever done an
eclipse plugin.....I was looking at the mercurialeclipse plugin for
some inspiration, they do have a recently used drop down on their
push/pull wizards. I'm going to see if I can get up to speed on how
they do this and possibly implement something similar.
However, I do think that a remotes dialog would be very nice,
something that you can just choose from whenever you wanted to do a
push/pull operation.
Thanks for entertaining the idea =D
On Sat, Mar 7, 2009 at 10:40 AM, Tor Arne Vestbø <torarnv@gmail.com> wrote:
>
> Robin Rosenberg wrote:
> > lördag 07 mars 2009 16:58:47 skrev Tor Arne Vestbø <torarnv@gmail.com>:
> >> Robert Navarro wrote:
> >>> Hello,
> >>>
> >>> Sorry about my last "subscribe" email, skipped over this part in the
> >>> wiki...."You don't even need to be subscribed to post, just send an
> >>> email to: "
> >>>
> >>> Anyways.....I wasn't sure where to post this but I'll give it a shot
> >>> here.....I know there is an eclipse jGit plugin in the works and I
> >>> wanted to know if it would be possible to get a remember or recently
> >>> used servers feature added to the push/pull feature.
> >> I have done some initial prototyping of a Remotes View. I'll see if I
> >> can bring that to life somehow.
> >
> > I assumed the feature is about the push dialog. If we have a remotes
> > view it'd be nice to see it there too.
>
> Yepp. I imagine something like a list of remotes, which can be
> referenced at any point a remote is needed, like the push dialog.
> Wizards that need a remote, can display the list of the existing
> remotes, with a "create new" option, which would launch the page from
> the "create new remote" wizard (similar to the "Add new CVS Repository"
> stuff). Something along those lines.
>
> > Where should it remembered? In the workspace or .git/config?
>
> Good question. Will need some thinking :)
>
> Tor Arne
--
~Robert Navarro
^ permalink raw reply
* Re: [PATCH] http: add_fill_function checks if function has been added
From: Junio C Hamano @ 2009-03-07 20:18 UTC (permalink / raw)
To: Tay Ray Chuan; +Cc: git
In-Reply-To: <49B266B0.4020304@gmail.com>
Tay Ray Chuan <rctay89@gmail.com> writes:
> This patch ensures that the same fill function is called once so to
> prevent any possible issues.
>
> Nevertheless, calling a fill function repeatedly in
> ''fill_active_slots'' will not lead to any obvious change in existing
> behavior, though performance might be affected.
>
> ''add_fill_action'' checks if the function to be added has already been
> added. Allocation of memory for the list ''fill_chain*'' is postponed
> until the check passes, unlike previously.
Could you care to explain the following a bit better?
- what "possible issues" you are addressing;
- what changes in the behaviour that are not "obvious" we would be
suffering from, if we apply this patch;
- in what situation the performance _might_ be affected, in what way and
to what extent.
If the patch author does not have clear answers to these questions, how
can others decide if it is worth reading the patch to judge if it is worth
applying?
In other words, I'd expect you to explain the issues like this:
add_fill_function() adds the same fill function twice on the fill_cfg
list; this causes THIS and THAT breakages when the fill function is
called twice.
Ignore add_fill_function() when fill_cfg list already has the function
registered on it to fix this issue. Note however that the new code may
behave very inefficiently under this situation:
- XYZZY happens, then
- FROTZ happens, and then
- NITFOL happens.
In such a case we end up doing FROTZ repeatedly, and ...; we might
want to later optimize this, but a correctly working code is more
important than efficient code that works most of the time but silently
breaks in some cases.
We need to iterate over the existing entries in fill_cfg list to find
duplicates, which may look like an overhead, but the existing function
already needed to do so to queue the new entry at the end anyway, so
this is nothing new.
^ permalink raw reply
* Re: [PATCH] MinGW: fix diff --no-index /dev/null ...
From: Junio C Hamano @ 2009-03-07 20:15 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git, gitster, Johannes Sixt
In-Reply-To: <dba002b9e521c639847650fbaeb8b87b66b9562e.1236441065u.git.johannes.schindelin@gmx.de>
Johannes Schindelin <johannes.schindelin@gmx.de> writes:
> diff --git a/diff-no-index.c b/diff-no-index.c
> index 0a14268..598687b 100644
> --- a/diff-no-index.c
> +++ b/diff-no-index.c
> @@ -38,6 +38,10 @@ static int get_mode(const char *path, int *mode)
>
> if (!path || !strcmp(path, "/dev/null"))
> *mode = 0;
> +#ifdef _WIN32
> + else if (!strcasecmp(path, "nul"))
> + *mode = 0;
> +#endif
> else if (!strcmp(path, "-"))
> *mode = create_ce_mode(0666);
> else if (lstat(path, &st))
I had a brief "Huh? -- doesn't this call for an is_dev_null() helper"
moment, but I think you are right that diff-no-index.c is the right place
to special case it.
Should this go to 'maint'?
> diff --git a/t/t4012-diff-binary.sh b/t/t4012-diff-binary.sh
> index 3cf5b5c..f64aa48 100755
> --- a/t/t4012-diff-binary.sh
> +++ b/t/t4012-diff-binary.sh
> @@ -87,7 +87,7 @@ nul_to_q() {
>
> test_expect_success 'diff --no-index with binary creation' '
> echo Q | q_to_nul >binary &&
> - (:# hide error code from diff, which just indicates differences
> + (: hide error code from diff, which just indicates differences
> git diff --binary --no-index /dev/null binary >current ||
> true
> ) &&
> --
> 1.6.2.327.g0fa6c
^ permalink raw reply
* Re: fetch and pull
From: Junio C Hamano @ 2009-03-07 20:15 UTC (permalink / raw)
To: Bryan Donlan; +Cc: John Dlugosz, Jakub Narebski, git
In-Reply-To: <3e8340490903070000t2780764cocfbf28d538037df5@mail.gmail.com>
Bryan Donlan <bdonlan@gmail.com> writes:
> If the local "dev" is meant to just track the remote, you really ought
> to avoid doing anything very involved in it (unless you're planning on
> merging something into it and pushing the result, that is!). If
> there's no local changes, then you can just pull with impunity, and
> let it fast-forward - or use git merge or git rebase if you've already
> fetched and don't want to spend the few seconds it takes to ask the
> server if there's anything new :)
With git that is not ancient (i.e. v1.5.0 or newer), there is no reason to
have local "dev" that purely track the remote anymore. If you only want
to go-look-and-see, you can check out the remote tracking branch directly
on a detached HEAD with "git checkout origin/dev".
Which means that the only cases we need to make it convenient for users
are to handle these local branches that "track" remote ones when you do
have local changes, or when you plan to have some.
If you do have local changes on "dev" that is marked to track the remove
"dev", and if you are on a branch different from "dev", then we should not
do anything after "git feftch" updates the remote tracking "dev". It
won't fast forward anyway, and we do not need to talk about this case in
this thread.
That leaves only one case. Your "dev" forked from the remote "dev"
sometime in the past, is marked to "track" the latter, but you haven't
done anything on the branch. Should we have a convenient way to
fast-forward it after a "git fetch" that updates the remote "dev"?
I'd actually say we should give users a convenient way to remove the local
branches that are marked to track remote tracking branches but do not have
anything interesting on their own (iow when they can fast-forward to their
corresponding remote tracking branches), if the true motive behind this
thread is "'git push' will notice 'dev' that is left behind and gives
clutter".
Yes, you may earlier thought about building on top of the remote branch,
but you haven't done anything other than creating a branch, you left it
without doing anything interesting and kept it behind.
If you later decide to revisit whatever you wanted to work on by forking
from that branch, you can "git checkout -t -b dev origin/dev" at that time
to recreate the branch just as easily as you would do "git checkout dev",
and between the time you notice that you have a stale "dev" that does not
have anything interesting and the time you decide to really work on the
topic again, you may be better off not cluttering "git branch" output with
such useless local branches.
So how about "git branch --prune --remote=<upstream>" that iterates over
local branches, and if
(1) it is not the current branch; and
(2) it is marked to track some branch taken from the <upstream>; and
(3) it does not have any commits on its own;
then remove that branch? "git remote --prune-local-forks <upstream>" is
also fine; I do not care about which command implements the feature that
much.
The only case I think would be useful to keep a local branch that does not
yet have a commit on its own happens in this workflow:
(1) You notice a bug sometime in the past (or at the tip) of the "dev"
branch you see in the remote;
(2) You bisect, find a faulty commit, and fork your "dev" from that
commit, so that you can work on fixing that single bug, later to be
merged back (because you anticipate the fix would be an involved
series);
(3) But you haven't had a chance to work on the fix yet.
Your fork point in this workflow has a meaning: this is the broken commit
I fix with my commits immediately after it. It should not be rebased nor
fast-forwarded.
But in that case, you shouldn't mark "dev" as tracking the remote's "dev"
to begin with, so the hypothetical "branch --prune --remote=<upstream>"
would not touch such a "fork to address old issues", and we'd be safe.
^ permalink raw reply
* [PATCH 2/2] moved some variables into narrower scopes
From: Benjamin Kramer @ 2009-03-07 20:02 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
they weren't used outside and can be safely moved
builtin-fmt-merge-msg: moved variable to narrower scope
combine-diff: moved variable to narrower scope
log-tree: moved variable to narrower scope
upload-pack: moved variable to narrower scope
upload-pack: removed unused assignment
Signed-off-by: Benjamin Kramer <benny.kra@googlemail.com>
---
builtin-fmt-merge-msg.c | 5 ++---
combine-diff.c | 3 +--
log-tree.c | 6 +++---
upload-pack.c | 5 ++---
4 files changed, 8 insertions(+), 11 deletions(-)
diff --git a/builtin-fmt-merge-msg.c b/builtin-fmt-merge-msg.c
index df18f40..5c5b310 100644
--- a/builtin-fmt-merge-msg.c
+++ b/builtin-fmt-merge-msg.c
@@ -257,7 +257,7 @@ static void shortlog(const char *name, unsigned char *sha1,
int fmt_merge_msg(int merge_summary, struct strbuf *in, struct strbuf *out) {
int limit = 20, i = 0, pos = 0;
char line[1024];
- char *p = line, *sep = "";
+ char *sep = "";
unsigned char head_sha1[20];
const char *current_branch;
@@ -271,9 +271,8 @@ int fmt_merge_msg(int merge_summary, struct strbuf
*in, struct strbuf *out) {
/* get a line */
while (pos < in->len) {
int len;
- char *newline;
+ char *newline, *p = in->buf + pos;
- p = in->buf + pos;
newline = strchr(p, '\n');
len = newline ? newline - p : strlen(p);
pos += len + !!newline;
diff --git a/combine-diff.c b/combine-diff.c
index bccc018..b3b86ae 100644
--- a/combine-diff.c
+++ b/combine-diff.c
@@ -526,7 +526,6 @@ static void dump_sline(struct sline *sline,
unsigned long cnt, int num_parent,
return; /* result deleted */
while (1) {
- struct sline *sl = &sline[lno];
unsigned long hunk_end;
unsigned long rlines;
const char *hunk_comment = NULL;
@@ -592,7 +591,7 @@ static void dump_sline(struct sline *sline,
unsigned long cnt, int num_parent,
struct lline *ll;
int j;
unsigned long p_mask;
- sl = &sline[lno++];
+ struct sline *sl = &sline[lno++];
ll = (sl->flag & no_pre_delete) ? NULL : sl->lost_head;
while (ll) {
fputs(c_old, stdout);
diff --git a/log-tree.c b/log-tree.c
index 84a74e5..63cff74 100644
--- a/log-tree.c
+++ b/log-tree.c
@@ -79,18 +79,18 @@ void show_decorations(struct rev_info *opt, struct
commit *commit)
*/
static int detect_any_signoff(char *letter, int size)
{
- char ch, *cp;
+ char *cp;
int seen_colon = 0;
int seen_at = 0;
int seen_name = 0;
int seen_head = 0;
cp = letter + size;
- while (letter <= --cp && (ch = *cp) == '\n')
+ while (letter <= --cp && *cp == '\n')
continue;
while (letter <= cp) {
- ch = *cp--;
+ char ch = *cp--;
if (ch == '\n')
break;
diff --git a/upload-pack.c b/upload-pack.c
index e15ebdc..a49d872 100644
--- a/upload-pack.c
+++ b/upload-pack.c
@@ -397,12 +397,11 @@ static int get_common_commits(void)
static char line[1000];
unsigned char sha1[20];
char hex[41], last_hex[41];
- int len;
save_commit_buffer = 0;
for(;;) {
- len = packet_read_line(0, line, sizeof(line));
+ int len = packet_read_line(0, line, sizeof(line));
reset_timeout();
if (!len) {
@@ -410,7 +409,7 @@ static int get_common_commits(void)
packet_write(1, "NAK\n");
continue;
}
- len = strip(line, len);
+ strip(line, len);
if (!prefixcmp(line, "have ")) {
switch (got_sha1(line+5, sha1)) {
case -1: /* they have what we do not */
--
1.6.2.81.ge603.dirty
^ permalink raw reply related
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