* Re: How to re-use setups in multiple tests?
From: Tom Clarke @ 2007-10-01 12:16 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git
In-Reply-To: <Pine.LNX.4.64.0710011243230.28395@racer.site>
In this case the first test rebases the branch created in setup (it's
testing the rebase merge strategy), the second test should do the same
thing, except check there is a warning if a --message option is
passed.
I suppose I could find the old pre-rebase head and work with that, but
that doesn't seem that clean to me.
Here's the code (non-working):
#!/bin/sh
test_description='merge-rebase backend test'
. ./test-lib.sh
test_expect_success setup '
echo hello >a &&
git add a &&
test_tick && git commit -m initial &&
git checkout -b branch &&
echo hello >b &&
git add b &&
test_tick && git commit -m onbranch &&
git checkout master &&
echo update >a &&
git add a &&
test_tick && git commit -m update
'
test_expect_success 'merging using rebase does not create merge
commit' '
git checkout branch &&
git merge -s rebase master &&
( git log --pretty=oneline ) >actual &&
(
echo "4db7a5a013e67aa623d1fd294e8d46e89b3ace8f
onbranch"
echo "893371811dbd13e85c098b72d1ab42bcfd24c2db update"
echo "0e960b10429bf3f1e168ee2cc7d531ac7c622580
initial"
) >expected &&
git diff -w -u expected actual
'
test_expect_success 'merging using rebase with message gives warning'
'
#doesn't work because the branch has already been rebased and
is therefore up to date
git checkout branch &&
git merge -m "a message" -s rebase master 2>&1 expected &&
(
echo "warning: Message is not used for rebase merge
strategy"
) >expected &&
git diff -w -u expected actual
'
test_done
-Tom
On 10/1/07, Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
> Hi,
>
> On Mon, 1 Oct 2007, Tom Clarke wrote:
>
> > I'm wondering if there's a pattern for re-using setups across several
> > tests, similar to how a setUp function is used in xUnit. The problem is
> > I need the setup to actually be re-run, for each test to start from a
> > clean slate, so using the following doesn't work as the setup is just
> > run before the first test.
>
> We typically do the clean up phase explicitely. Or avoid it.
>
> Example: you want to do something to a branch, but the next step should
> use the original state of the branch.
>
> Solution: "git checkout -b new-branch HEAD~5"
>
> Sorry, unless you are a little less mysterious about the exact use case
> you have in mind, I cannot help more.
>
> Ciao,
> Dscho
>
>
^ permalink raw reply
* Re: git-browser and branch names
From: Jean-François Veillette @ 2007-10-01 12:34 UTC (permalink / raw)
To: Git
In-Reply-To: <ee77f5c20710010424x1f83aa10kcde7033711b02093@mail.gmail.com>
Le 07-10-01 à 07:24, David Symonds a écrit :
>
> Can anyone give me pointers or suggestions as to where to start
> debugging this? Anyone else encountered this?
To debug html/javascript use Firefox and Firebug.
http://www.getfirebug.com/
- jfv
^ permalink raw reply
* Re: How to re-use setups in multiple tests?
From: Johannes Schindelin @ 2007-10-01 12:39 UTC (permalink / raw)
To: Tom Clarke; +Cc: git
In-Reply-To: <550f9510710010516s305c843br53da294f65318862@mail.gmail.com>
Hi,
On Mon, 1 Oct 2007, Tom Clarke wrote:
> In this case the first test rebases the branch created in setup (it's
> testing the rebase merge strategy), the second test should do the same
> thing, except check there is a warning if a --message option is passed.
>
> I suppose I could find the old pre-rebase head and work with that, but
> that doesn't seem that clean to me.
You can use "git reset --hard master@{1}", and it really escapes me why
this should not be clean, and why you want to jump through hoops instead
using a much more complicated technique.
Ciao,
Dscho
^ permalink raw reply
* [PATCH] git-send-email: add a new sendemail.to configuration variable
From: Miklos Vajna @ 2007-10-01 12:42 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Miklos Vajna, git
Several projects prefers to receive patches via a given email address. In these
cases it's handy to configure that address once.
Signed-off-by: Miklos Vajna <vmiklos@frugalware.org>
---
Documentation/git-send-email.txt | 3 +++
git-send-email.perl | 1 +
2 files changed, 4 insertions(+), 0 deletions(-)
diff --git a/Documentation/git-send-email.txt b/Documentation/git-send-email.txt
index 3727776..e38b702 100644
--- a/Documentation/git-send-email.txt
+++ b/Documentation/git-send-email.txt
@@ -159,6 +159,9 @@ sendemail.aliasfiletype::
Format of the file(s) specified in sendemail.aliasesfile. Must be
one of 'mutt', 'mailrc', 'pine', or 'gnus'.
+sendemail.to::
+ Email address (or alias) to always send to.
+
sendemail.cccmd::
Command to execute to generate per patch file specific "Cc:"s.
diff --git a/git-send-email.perl b/git-send-email.perl
index 62e1429..96051bc 100755
--- a/git-send-email.perl
+++ b/git-send-email.perl
@@ -191,6 +191,7 @@ my %config_settings = (
"smtpserverport" => \$smtp_server_port,
"smtpuser" => \$smtp_authuser,
"smtppass" => \$smtp_authpass,
+ "to" => \@to,
"cccmd" => \$cc_cmd,
"aliasfiletype" => \$aliasfiletype,
"bcc" => \@bcclist,
--
1.5.3.2.111.g5166-dirty
^ permalink raw reply related
* Re: How to re-use setups in multiple tests?
From: Tom Clarke @ 2007-10-01 12:46 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git
In-Reply-To: <Pine.LNX.4.64.0710011336530.28395@racer.site>
On 10/1/07, Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
> > I suppose I could find the old pre-rebase head and work with that, but
> > that doesn't seem that clean to me.
>
> You can use "git reset --hard master@{1}", and it really escapes me why
> this should not be clean, and why you want to jump through hoops instead
> using a much more complicated technique.
That'll be because my git knowledge isn't good enough to make it
clean. Thanks for the suggestion :-)
-Tom
^ permalink raw reply
* merging .gitignore
From: martin f krafft @ 2007-10-01 13:03 UTC (permalink / raw)
To: git discussion list
[-- Attachment #1: Type: text/plain, Size: 1220 bytes --]
Dear gits (oh dear…),
we just ran into a problem in a git-managed project and I'd be
interested to learn how you approach this.
Our main line ("upstream"), which tracks a remote repository, does
not have a .gitignore file. For new features, we use feature
branches, and we merge those into an integration branch ("master")
and track them separately of upstream.
Feature branch A has a .gitignore file, and it's been merged into
master for a while. Today, feature branch B failed to merge into
master because it also provides a .gitignore file. We can obviously
resolve the conflict, but I wonder whether there is a better way to
deal with this since we deal with quite a large number of new
feature branches and it's only a matter of time until the next one
will conflict because of .gitignore.
(and yes, this is basically a reincarnation of my case for
.gitignore.d [http://lists.zerezo.com/git/msg627581.html]).
Thoughts,
--
martin; (greetings from the heart of the sun.)
\____ echo mailto: !#^."<*>"|tr "<*> mailto:" net@madduck
kermit: why are there so many songs about rainbows?
fozzy: that's part of what rainbows do.
spamtraps: madduck.bogus@madduck.net
[-- Attachment #2: Digital signature (see http://martin-krafft.net/gpg/) --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: [PATCH] Don't checkout the full tree if avoidable
From: Steven Walter @ 2007-10-01 13:12 UTC (permalink / raw)
To: Eric Wong; +Cc: Junio C Hamano, git
In-Reply-To: <20071001110855.GB10079@muzzle>
On Mon, Oct 01, 2007 at 04:08:55AM -0700, Eric Wong wrote:
> Steven Walter wrote:
> > One criticism of the patch: the trees_match function probably needs to
> > be re-written. My SVN::Perl-foo is weak.
>
> Yep :)
>
> Steven:
>
> How does the following work for you? Which version of SVN do you have,
> by the way? I just found a bug with the way SVN::Client::diff() is
> exported for SVN 1.1.4, hence the SVN::Pool->new_default_sub usage.
swalter@sentra:~% svn --version
svn, version 1.3.2 (r19776)
This version works great; seems to have exactly the same behavior as my
patch. Verified that it still falls back to the do_update code when
trees_match fails.
--
-Steven Walter <stevenrwalter@gmail.com>
"A human being should be able to change a diaper, plan an invasion,
butcher a hog, conn a ship, design a building, write a sonnet, balance
accounts, build a wall, set a bone, comfort the dying, take orders,
give orders, cooperate, act alone, solve equations, analyze a new
problem, pitch manure, program a computer, cook a tasty meal, fight
efficiently, die gallantly. Specialization is for insects."
-Robert Heinlein
^ permalink raw reply
* git-http-push / webDAV
From: Thomas Pasch @ 2007-10-01 13:31 UTC (permalink / raw)
To: git
Hello,
trying to set up a webDAV enabled http push
git server (1.5.3.3) like it is described in
http://www.kernel.org/pub/software/scm/git/docs/howto/setup-git-server-over-http.txt
Tested the apache2 (2.2.6) DAV setup with
cadaver (and tried the browser as well).
With cadaver I could lock files, download
and upload content.
However,
> git push -v upload master
Pushing to http://test@x.x.x.x/git/DepTrack.git/
Fetching remote heads...
refs/
refs/heads/
refs/tags/
updating 'refs/heads/master'
from 0000000000000000000000000000000000000000
to d75dce3fe0e9ec5915feda5574f214bd432ccb14
sending 89 objects
done
Updating remote server info
UNLOCK HTTP error 400
Also tried:
> git-http-push --all --verbose http://x.x.x.x/git/DepTrack.git/ master
Getting pack list
Fetching remote heads...
refs/
refs/heads/
refs/tags/
'refs/heads/master': up-to-date
... and then tried to clone:
> git clone http://test@x.x.x.x/git/DepTrack.git
Initialized empty Git repository in /home/tpasch/tmp/tmp/DepTrack/.git/
Getting alternates list for http://test@x.x.x.x/git/DepTrack.git
Getting pack list for http://test@x.x.x.x/git/DepTrack.git
error: Unable to find d75dce3fe0e9ec5915feda5574f214bd432ccb14 under
http://test@x.x.x.x/git/DepTrack.git
Cannot obtain needed object d75dce3fe0e9ec5915feda5574f214bd432ccb14
Finally, tried a *non-empty* repo at the server:
> git clone --bare /home/tpasch/tmp/tmp/trunk DepTrack.git
Initialized empty Git repository in /data/git/DepTrack.git/
22911 blocks
> cd DepTrack.git/
> git --bare update-server-info
> chmod a+x hooks/post-update
> chown -R wwwrun:www /data/git
... cloned:
> git clone http://test@x.x.x.x/git/DepTrack.git
Initialized empty Git repository in /home/tpasch/tmp/tmp/DepTrack/.git/
got d75dce3fe0e9ec5915feda5574f214bd432ccb14
walk d75dce3fe0e9ec5915feda5574f214bd432ccb14
got 8a459da1fb520cbc2534b87d3c0d8539fa010f45
got 31c3b20e1d7d7ca414a273fe80f4c49466250709
walk 31c3b20e1d7d7ca414a273fe80f4c49466250709
got ca647ac42188a8ed859260503abc41f98fd21be6
[...]
got 7e089ccc1819d4e69b228b3359690f685728248b
Checking 66 files out...
100% (66/66) done
... then modified a file and pushed:
> git add test.txt
> git commit
> git push -v
Pushing to http://test@x.x.x.x/git/DepTrack.git
But this never returns. (Also tried:
> git-http-push --all --verbose http://x.x.x.x/git/DepTrack.git/ master
Getting pack list
Fetching remote heads...
refs/
refs/heads/
refs/tags/
updating 'refs/heads/master'
from d75dce3fe0e9ec5915feda5574f214bd432ccb14
to 07002e0423e803096eb07eb5c46651b00ed20725
sending 3 objects
done
Updating remote server info
UNLOCK HTTP error 400
)
Any suggestions?
Cheers,
Thomas
PS:
This is how I initialized the repo:
> git --bare init
Initialized empty Git repository in /data/git/DepTrack.git/
> git --bare update-server-info
> chmod a+x hooks/post-update
> chown -R wwwrun:www /data/git
> /etc/init.d/apache2 restart
^ permalink raw reply
* Re: How to re-use setups in multiple tests?
From: Karl Hasselström @ 2007-10-01 13:40 UTC (permalink / raw)
To: Tom Clarke; +Cc: Johannes Schindelin, git
In-Reply-To: <550f9510710010546q55209759k4770cd3e78121cfc@mail.gmail.com>
On 2007-10-01 14:46:46 +0200, Tom Clarke wrote:
> On 10/1/07, Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
>
> > > I suppose I could find the old pre-rebase head and work with
> > > that, but that doesn't seem that clean to me.
> >
> > You can use "git reset --hard master@{1}", and it really escapes
> > me why this should not be clean, and why you want to jump through
> > hoops instead using a much more complicated technique.
>
> That'll be because my git knowledge isn't good enough to make it
> clean. Thanks for the suggestion :-)
Another even more foolproof way would be to have the setup create a
(lightweight) tag, and let each subtest reset to that tag.
--
Karl Hasselström, kha@treskal.com
www.treskal.com/kalle
^ permalink raw reply
* Re: merging .gitignore
From: Andy Parkins @ 2007-10-01 13:48 UTC (permalink / raw)
To: git; +Cc: martin f krafft
In-Reply-To: <20071001130314.GA5932@lapse.madduck.net>
On Monday 2007 October 01, martin f krafft wrote:
> Feature branch A has a .gitignore file, and it's been merged into
> master for a while. Today, feature branch B failed to merge into
> master because it also provides a .gitignore file. We can obviously
> resolve the conflict, but I wonder whether there is a better way to
> deal with this since we deal with quite a large number of new
> feature branches and it's only a matter of time until the next one
> will conflict because of .gitignore.
But it _is_ a conflict. Conflicts have to be resolved. I'm having difficulty
understanding what you think git should be doing in these cases?
> (and yes, this is basically a reincarnation of my case for
> .gitignore.d [http://lists.zerezo.com/git/msg627581.html]).
I don't see that that would help. All you are doing with a gitignore.d is
swapping lines for files, the conflicts would still exist. Presumably you
are hoping that the separate branches will make different files in
gitignore.d and hence can't conflict; but then you've just pushed the
conflict to a place where it won't be seen (and also made a terrible mess of
the merged branch gitignore.d).
branchA:.gitignore.d/branchAignores
branchB:.gitignore.d/branchBignores
Over time you would get:
master:.gitignore.d/branchAignores
master:.gitignore.d/branchBignores
master:.gitignore.d/branchCignores
master:.gitignore.d/branchDignores
master:.gitignore.d/branchEignores
master:.gitignore.d/branchFignores
Then, assuming the conflicts you get now occur for a reason, you will get
conflicts within the .gitignore.d/ directory. Let's say branchCignores adds
*.o and branchFignores removes *.o from the ignores. Who is right? Who
knows, and worse than that you didn't see the conflict when it happened so it
wasn't resolved and the master branch was left with conflicts in it.
Of course the conflicts in that case aren't in the form of "<<<<<" markers,
but they are no less conflicts just because they're invisible.
Eventually someone is going to want to combine this ever-increasing set of
ignore files into one. i.e. they'll merge them. In which case why couldn't
you do the merge at the correct time - when the branch was merged?
Andy
--
Dr Andy Parkins, M Eng (hons), MIET
andyparkins@gmail.com
^ permalink raw reply
* Re: merging .gitignore
From: Johannes Schindelin @ 2007-10-01 13:57 UTC (permalink / raw)
To: martin f krafft; +Cc: git discussion list
In-Reply-To: <20071001130314.GA5932@lapse.madduck.net>
Hi,
On Mon, 1 Oct 2007, martin f krafft wrote:
> Feature branch A has a .gitignore file, and it's been merged into
> master for a while. Today, feature branch B failed to merge into
> master because it also provides a .gitignore file.
You might be interested in writing a merge driver. See
Documentation/gitattributes.txt.
Hth,
Dscho
^ permalink raw reply
* Re: [PATCH 1/4] Add a simple option parser for use by builtin-commit.c.
From: Jeff King @ 2007-10-01 15:00 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Jonas Fonseca, Kristian Høgsberg, gitster, git
In-Reply-To: <Pine.LNX.4.64.0710011114310.28395@racer.site>
On Mon, Oct 01, 2007 at 11:14:48AM +0100, Johannes Schindelin wrote:
> We _have_ to modify argv. For example, "git log master -p" is perfectly
> valid.
We're not going to support POSIXLY_CORRECT!? ;)
-Peff
^ permalink raw reply
* [PATCH] Adding rebase merge strategy
From: Tom Clarke @ 2007-10-01 15:08 UTC (permalink / raw)
To: gitster; +Cc: Johannes.Schindelin, git, Tom Clarke
In-Reply-To: <Pine.LNX.4.64.0709281751390.28395@racer.site>
In addition to adding git-merge-rebase.sh, git-merge.sh is modified
to handle the rebase strategy specially and avoids running update-ref
as rebase won't generate a merge commit. It also adds a warning
if a message is supplied when the rebase isn't used as this
will be ignored.
Signed-off-by: Tom Clarke <tom@u2i.com>
---
Incorporated comments from Johannes Schindlen.
.gitignore | 1 +
Documentation/merge-strategies.txt | 6 +++++
Makefile | 2 +-
git-merge-rebase.sh | 17 ++++++++++++++
git-merge.sh | 24 +++++++++++++++++--
t/t3031-merge-rebase.sh | 44 ++++++++++++++++++++++++++++++++++++
6 files changed, 90 insertions(+), 4 deletions(-)
create mode 100755 git-merge-rebase.sh
create mode 100755 t/t3031-merge-rebase.sh
diff --git a/.gitignore b/.gitignore
index e0b91be..fe5cdc4 100644
--- a/.gitignore
+++ b/.gitignore
@@ -73,6 +73,7 @@ git-merge-tree
git-merge-octopus
git-merge-one-file
git-merge-ours
+git-merge-rebase
git-merge-recursive
git-merge-resolve
git-merge-stupid
diff --git a/Documentation/merge-strategies.txt b/Documentation/merge-strategies.txt
index 7df0266..dff1909 100644
--- a/Documentation/merge-strategies.txt
+++ b/Documentation/merge-strategies.txt
@@ -33,3 +33,9 @@ ours::
merge is always the current branch head. It is meant to
be used to supersede old development history of side
branches.
+
+rebase::
+ This rebases the current branch based on a single head.
+ Commits are rewritten as with git-rebase. This doesn't
+ produce a merge. The procedure for dealing with conflicts
+ is the same as with git-rebase.
diff --git a/Makefile b/Makefile
index 8db4dbe..e6d3812 100644
--- a/Makefile
+++ b/Makefile
@@ -215,7 +215,7 @@ SCRIPT_SH = \
git-sh-setup.sh \
git-am.sh \
git-merge.sh git-merge-stupid.sh git-merge-octopus.sh \
- git-merge-resolve.sh git-merge-ours.sh \
+ git-merge-resolve.sh git-merge-ours.sh git-merge-rebase.sh \
git-lost-found.sh git-quiltimport.sh git-submodule.sh \
git-filter-branch.sh \
git-stash.sh
diff --git a/git-merge-rebase.sh b/git-merge-rebase.sh
new file mode 100755
index 0000000..b75be3f
--- /dev/null
+++ b/git-merge-rebase.sh
@@ -0,0 +1,17 @@
+#!/bin/sh
+#
+# Copyright (c) 2007 Tom Clarke
+#
+# Resolve two trees with rebase
+
+# The first parameters up to -- are merge bases ignore them
+while test $1 != "--"; do shift; done
+shift
+
+# ignore the first head, it's not needed in a rebase merge
+shift
+
+# Give up if we are given two or more remotes -- not handling octopus.
+test $# = 1 || exit 2
+
+git rebase $1 || exit 2
diff --git a/git-merge.sh b/git-merge.sh
index 6c513dc..b58bee2 100755
--- a/git-merge.sh
+++ b/git-merge.sh
@@ -16,11 +16,12 @@ test -z "$(git ls-files -u)" ||
LF='
'
-all_strategies='recur recursive octopus resolve stupid ours subtree'
+all_strategies='recur recursive octopus resolve stupid ours subtree rebase'
default_twohead_strategies='recursive'
default_octopus_strategies='octopus'
no_fast_forward_strategies='subtree ours'
-no_trivial_strategies='recursive recur subtree ours'
+no_trivial_strategies='recursive recur subtree ours rebase'
+no_update_ref='rebase'
use_strategies=
allow_fast_forward=t
@@ -81,11 +82,18 @@ finish () {
echo "No merge message -- not updating HEAD"
;;
*)
- git update-ref -m "$rlogm" HEAD "$1" "$head" || exit 1
+ case " $wt_strategy " in
+ *" $no_update_ref "*)
+ ;;
+ *)
+ git update-ref -m "$rlogm" HEAD "$1" "$head" || exit 1
+ ;;
+ esac
;;
esac
;;
esac
+
case "$1" in
'')
;;
@@ -418,6 +426,16 @@ do
;;
esac
+ # Check to see if there's a message in a merge type that won't produce a commit
+ if test $have_message = "t"
+ then
+ case " $strategy " in
+ *" $no_update_ref "*)
+ echo >&2 "warning: Message is not used for $strategy merge strategy"
+ ;;
+ esac
+ fi
+
# Remember which strategy left the state in the working tree
wt_strategy=$strategy
diff --git a/t/t3031-merge-rebase.sh b/t/t3031-merge-rebase.sh
new file mode 100755
index 0000000..daa03b1
--- /dev/null
+++ b/t/t3031-merge-rebase.sh
@@ -0,0 +1,44 @@
+#!/bin/sh
+
+test_description='merge-rebase backend test'
+
+. ./test-lib.sh
+
+test_expect_success setup '
+ echo hello >a &&
+ git add a &&
+ test_tick && git commit -m initial &&
+
+ git checkout -b branch &&
+ echo hello >b &&
+ git add b &&
+ test_tick && git commit -m onbranch &&
+
+ git checkout master &&
+ echo update >a &&
+ git add a &&
+ test_tick && git commit -m update
+'
+test_expect_success 'merging using rebase does not create merge commit' '
+ git checkout branch &&
+ git merge -s rebase master &&
+
+ ( git log --pretty=oneline ) >actual &&
+ (
+ echo "4db7a5a013e67aa623d1fd294e8d46e89b3ace8f onbranch"
+ echo "893371811dbd13e85c098b72d1ab42bcfd24c2db update"
+ echo "0e960b10429bf3f1e168ee2cc7d531ac7c622580 initial"
+ ) >expected &&
+ git diff -w -u expected actual
+'
+git reset --hard HEAD@{2}
+
+test_expect_success 'merging using rebase with message gives warning' '
+ git merge -m "a message" -s rebase master 2> actual &&
+ (
+ echo "warning: Message is not used for rebase merge strategy"
+ ) >expected &&
+ git diff -w -u expected actual
+'
+
+test_done
--
1.5.3.rc7.3.g850f-dirty
^ permalink raw reply related
* Re: Referring a commit-id remote repo.
From: David Brown @ 2007-10-01 15:24 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Git
In-Reply-To: <Pine.LNX.4.64.0710011122500.28395@racer.site>
On Mon, Oct 01, 2007 at 11:25:13AM +0100, Johannes Schindelin wrote:
>On Sun, 30 Sep 2007, David Brown wrote:
>
>> The question I have: is there any way I can look at this particular
>> commit ID on the remote repo? I couldn't come up with any way to get
>> git fetch to retrieve it.
>
>Unless you have push access, no. And this is very much by design. For
>example, when somebody mistakenly pushed a secret (like what lines in the
>kernel infringe on M$ patents, if any) it should be possible to rebase (in
>a hurry), force a push, and have the safe feeling that nobody can fetch
>the secret any longer.
I've found the commits in the 'master' branch, and it looks like the
developer had done a rebase on Sept 3. I've informed the person asking me
the question to use these commit IDs, and hopefully they won't be doing any
rebasing on their master branch.
Dave
^ permalink raw reply
* Re: git-browser and branch names
From: David Symonds @ 2007-10-01 15:34 UTC (permalink / raw)
To: Jean-François Veillette; +Cc: Git
In-Reply-To: <C4186BBD-11BA-4A58-9230-00076FF6F8F7@yahoo.ca>
On 01/10/2007, Jean-François Veillette <jean_francois_veillette@yahoo.ca> wrote:
> Le 07-10-01 à 07:24, David Symonds a écrit :
> >
> > Can anyone give me pointers or suggestions as to where to start
> > debugging this? Anyone else encountered this?
>
> To debug html/javascript use Firefox and Firebug.
> http://www.getfirebug.com/
Great, thanks for the pointer. My first real foray into Javascript has
been successful -- a patch will soon follow.
Dave.
^ permalink raw reply
* [PATCH] Prevent purely-numeric ref names from breaking Javascript.
From: David Symonds @ 2007-10-01 15:37 UTC (permalink / raw)
To: pasky; +Cc: git, David Symonds
When the server reply carrying JSON data to the client browser to render has
a string that looks like a decimal number, it doesn't get quoted. The
client-side Javascript code assumes, however, that all the ref names are
strings, and so calls string functions on decimal number objects if the ref
name is purely numeric (e.g. "2.5"). This patch simply forces the objects that
are escaped for HTML presentation to be coerced into strings, which catches
this case (and possibly others).
---
by-commit.html | 1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/by-commit.html b/by-commit.html
index d759c3e..0aa69b9 100644
--- a/by-commit.html
+++ b/by-commit.html
@@ -35,6 +35,7 @@ format_log_date=function( date )
}
escape_html=function( s )
{
+ s=s+""; // ensure it's a string
s=s.replace( /\&/g, "&" );
s=s.replace( /\</g, "<" );
s=s.replace( /\>/g, ">" );
--
1.5.3.1
^ permalink raw reply related
* Re: [PATCH] Adding rebase merge strategy
From: Johannes Schindelin @ 2007-10-01 15:50 UTC (permalink / raw)
To: Tom Clarke; +Cc: gitster, git
In-Reply-To: <11912513203420-git-send-email-tom@u2i.com>
Hi,
On Mon, 1 Oct 2007, Tom Clarke wrote:
> Incorporated comments from Johannes Schindlen.
Thanks.
> +# Give up if we are given two or more remotes -- not handling octopus.
> +test $# = 1 || exit 2
I think the user wants to know in this case, too. How about
test $# = 1 || {
echo "Cannot handle octopus." >&2
exit 2
}
> diff --git a/t/t3031-merge-rebase.sh b/t/t3031-merge-rebase.sh
> new file mode 100755
> index 0000000..daa03b1
> --- /dev/null
> +++ b/t/t3031-merge-rebase.sh
>
> [...]
>
> + ( git log --pretty=oneline ) >actual &&
Please lose the parentheses here.
> + (
> + echo "4db7a5a013e67aa623d1fd294e8d46e89b3ace8f onbranch"
> + echo "893371811dbd13e85c098b72d1ab42bcfd24c2db update"
> + echo "0e960b10429bf3f1e168ee2cc7d531ac7c622580 initial"
> + ) >expected &&
Why not do it as is done elsewhere in the test suit: use a "cat << EOF"
before "test_expect_success"?
> + (
> + echo "warning: Message is not used for rebase merge strategy"
> + ) >expected &&
Same here.
Other than that, I like it.
Ciao,
Dscho
^ permalink raw reply
* Re: git-http-push / webDAV
From: Eygene Ryabinkin @ 2007-10-01 15:54 UTC (permalink / raw)
To: Thomas Pasch; +Cc: git
In-Reply-To: <4700F6BC.2070701@jentro.com>
Thomas, good day.
Mon, Oct 01, 2007 at 03:31:40PM +0200, Thomas Pasch wrote:
> trying to set up a webDAV enabled http push
> git server (1.5.3.3) like it is described in
>
> http://www.kernel.org/pub/software/scm/git/docs/howto/setup-git-server-over-http.txt
>
> Tested the apache2 (2.2.6) DAV setup with
> cadaver (and tried the browser as well).
> With cadaver I could lock files, download
> and upload content.
>
> However,
>
> > git push -v upload master
> Pushing to http://test@x.x.x.x/git/DepTrack.git/
> Fetching remote heads...
> refs/
> refs/heads/
> refs/tags/
> updating 'refs/heads/master'
> from 0000000000000000000000000000000000000000
> to d75dce3fe0e9ec5915feda5574f214bd432ccb14
> sending 89 objects
> done
> Updating remote server info
> UNLOCK HTTP error 400
And how is your Apache configuration looks like? I used to
make 2.2.4 work flawlessly with git. Perhaps I will get it
a shot with the 2.2.6.
--
Eygene
^ permalink raw reply
* Re: [PATCH 1/4] Add a simple option parser for use by builtin-commit.c.
From: Kristian Høgsberg @ 2007-10-01 16:26 UTC (permalink / raw)
To: Jonas Fonseca; +Cc: gitster, git
In-Reply-To: <20070930131133.GA11209@diku.dk>
On Sun, 2007-09-30 at 15:11 +0200, Jonas Fonseca wrote:
> Hello Kristian,
>
> I have some comments on your patch. Some of the "improvement" might have
> to wait until after your builtin-commit changes hits git.git. However,
> if we could agree on some of the general changes, I could start porting
> other of the main porcelain commands to use the option parser without
> depending on the state of the remaining builtin-commit series.
Hi Jonas,
That's sounds like a good plan. In fact, in you want to update the
patch with your changes (they all sound good) and start porting over
some of the other builtins feel free. I don't have much time follow up
on these comments right now, but I will get to it eventually - unless
you beat me to it of course ;) I will update builtin-commit.c to work
with whatever changes you introduce once I get around to updating that
patch.
> Kristian Høgsberg <krh@redhat.com> wrote Thu, Sep 27, 2007:
> > Signed-off-by: Kristian Høgsberg <krh@redhat.com>
> > ---
> > Makefile | 2 +-
> > parse-options.c | 74 +++++++++++++++++++++++++++++++++++++++++++++++++++++++
> > parse-options.h | 29 +++++++++++++++++++++
> > 3 files changed, 104 insertions(+), 1 deletions(-)
> > create mode 100644 parse-options.c
> > create mode 100644 parse-options.h
> >
> > diff --git a/Makefile b/Makefile
> > index 62bdac6..d90e959 100644
> > --- a/Makefile
> > +++ b/Makefile
> > @@ -310,7 +310,7 @@ LIB_OBJS = \
> > alloc.o merge-file.o path-list.o help.o unpack-trees.o $(DIFF_OBJS) \
> > color.o wt-status.o archive-zip.o archive-tar.o shallow.o utf8.o \
> > convert.o attr.o decorate.o progress.o mailmap.o symlinks.o remote.o \
> > - transport.o bundle.o
> > + transport.o bundle.o parse-options.o
> >
> > BUILTIN_OBJS = \
> > builtin-add.o \
> > diff --git a/parse-options.c b/parse-options.c
> > new file mode 100644
> > index 0000000..2fb30cd
> > --- /dev/null
> > +++ b/parse-options.c
> > @@ -0,0 +1,74 @@
> > +#include "git-compat-util.h"
> > +#include "parse-options.h"
> > +
> > +int parse_options(const char ***argv,
> > + struct option *options, int count,
> > + const char *usage_string)
> > +{
> > + const char *value, *eq;
> > + int i;
> > +
> > + if (**argv == NULL)
> > + return 0;
> > + if ((**argv)[0] != '-')
> > + return 0;
> > + if (!strcmp(**argv, "--"))
> > + return 0;
>
> I don't know if this is a bug, but you do not remove "--" from argv,
> which is later (in the patch that adds builtin-commit.c) passed to
> add_files_to_cache and then get_pathspec where it is not removed or
> detected either.
That's an oversight, good catch.
> > +
> > + value = NULL;
> > + for (i = 0; i < count; i++) {
> > + if ((**argv)[1] == '-') {
> > + if (!prefixcmp(options[i].long_name, **argv + 2)) {
> > + if (options[i].type != OPTION_BOOLEAN)
> > + value = *++(*argv);
> > + goto match;
> > + }
> > +
> > + eq = strchr(**argv + 2, '=');
> > + if (eq && options[i].type != OPTION_BOOLEAN &&
> > + !strncmp(**argv + 2,
> > + options[i].long_name, eq - **argv - 2)) {
> > + value = eq + 1;
> > + goto match;
> > + }
> > + }
> > +
> > + if ((**argv)[1] == options[i].short_name) {
> > + if ((**argv)[2] == '\0') {
> > + if (options[i].type != OPTION_BOOLEAN)
> > + value = *++(*argv);
> > + goto match;
> > + }
> > +
> > + if (options[i].type != OPTION_BOOLEAN) {
> > + value = **argv + 2;
> > + goto match;
> > + }
> > + }
> > + }
> > +
> > + usage(usage_string);
> > +
> > + match:
>
> I think the goto can be avoided by simply breaking out of the above loop
> when an option has been found and add ...
>
> > + switch (options[i].type) {
> case OPTION_LAST
> usage(usage_string);
> break;
>
> > + case OPTION_BOOLEAN:
> > + *(int *)options[i].value = 1;
> > + break;
Yeah, that looks nicer. I think the goto structure is a leftover from
when there was more logic between the loop and the switch. It's good to
get some fresh eyes on this code. Junio didn't like the OPTION_LAST
terminator, so I changed the interface to take a count. We can do
if (i == count)
usage();
else switch (options[i].type) {
...
}
of course.
> I've been looking at builtin-blame.c which IMO has some of the most
> obscure option parsing and maybe this can be changed to increment in
> order to support stuff like changing the meaning by passing the same arg
> multiple times (e.g. "-C -C -C") better.
That would be fine, yes.
> Blame option parsing also sports (enum) flags being masked together,
> this can of course be rewritten to a boolean option followed by
> masking when parse_options is done (to keep it sane).
Yup.
> > + case OPTION_STRING:
> > + if (value == NULL)
> > + die("option %s requires a value.", (*argv)[-1]);
>
> Maybe change this ...
>
> > + *(const char **)options[i].value = value;
> > + break;
> > + case OPTION_INTEGER:
> > + if (value == NULL)
> > + die("option %s requires a value.", (*argv)[-1]);
>
> ... and this to:
>
> if (!value) {
> error("option %s requires a value.", (*argv)[-1]);
> usage(usage_string);
> }
Sure, that's friendlier.
> > + *(int *)options[i].value = atoi(value);
> > + break;
> > + default:
> > + assert(0);
> > + }
> > +
> > + (*argv)++;
> > +
> > + return 1;
> > +}
> > diff --git a/parse-options.h b/parse-options.h
> > new file mode 100644
> > index 0000000..39399c3
> > --- /dev/null
> > +++ b/parse-options.h
> > @@ -0,0 +1,29 @@
> > +#ifndef PARSE_OPTIONS_H
> > +#define PARSE_OPTIONS_H
> > +
> > +enum option_type {
> > + OPTION_BOOLEAN,
> > + OPTION_STRING,
> > + OPTION_INTEGER,
> > + OPTION_LAST,
> > +};
> > +
> > +struct option {
> > + enum option_type type;
> > + const char *long_name;
> > + char short_name;
> > + void *value;
> > +};
>
> Space vs tab indentation.
>
> One of the last things I miss from Cogito is the nice abbreviated help
> messages that was available via '-h'. I don't know if it would be
> acceptable (at least for the main porcelain commands) to put this
> functionality into the option parser by adding a "description" member to
> struct option and have parse_options print a nice:
>
> <error message if any>
> <usage string>
> <option summary>
>
> on failure, or, if that is regarded as too verbose, simply when -h is
> detected.
Yeah, that might be nice. We can add it in a follow-on patch, if the
list agrees that it's a good thing, I guess.
> > +
> > +/* Parse the given options against the list of known options. The
> > + * order of the option structs matters, in that ambiguous
> > + * abbreviations (eg, --in could be short for --include or
> > + * --interactive) are matched by the first option that share the
> > + * prefix.
> > + */
>
> This prefix aware option parsing has not been ported over to the other
> builtins when they were lifted from shell code. It might be nice to have
> of course. Is it really needed?
I don't ever use it myself and I think it's more confusing than helpful.
I only added it to avoid introducing behavior changes in the port. I
don't have strong feelings either way.
> > +
> > +extern int parse_options(const char ***argv,
> > + struct option *options, int count,
> > + const char *usage_string);
>
> I think the interface could be improved a bit. For example, it doesn't
> need to count argument since the last entry in the options array is
> OPTION_LAST and thus the size can be detected that way.
Hehe, yeah, that's how I did it first. I don't have a strong preference
for terminator elements vs. ARRAY_SIZE(), but Junio prefers the
ARRAY_SIZE() approach, I guess. At this point I'm just trying the get
the patches upstream...
> Also, I think for this to be more usable for other built-in programs it
> shouldn't modify argv, but instead take both argc and argv (so we don't
> need to have code like "*++(*argv)" ;), parse _all_ options in one go,
> and return the index (of argv) for any remaining options.
>
> Then the following:
>
> while (parse_options(argv, commit_options, ARRAY_SIZE(commit_options),
> builtin_commit_usage))
> ;
>
> becomes:
>
> int i;
> ...
> i = parse_options(argc, argv, commit_options, builtin_commit_usage);
>
> This fits better with how option parsing is currently done. Take
> builtin-add for example:
>
> for (i = 1 ; i < argc ; i++) {
> const char *arg = argv[i];
> /* ... */
> }
> if (argc <= i)
> usage(builtin_rm_usage);
No objections, I think that looks better too.
> [ BTW, blame option parsing actually wants to know if "--" has been seen,
> but I think that can be worked around by simply checking argv[i - 1]
> after calling the option parser. ]
>
> > +
> > +#endif
>
> OK, I will stop these ramblings here. I hope the fact that I read your
> patch both back and forth and added comments in the process didn't make
> it too confusing.
Heh, that's what I do myself :)
thanks for the comments,
Kristian
^ permalink raw reply
* what's a useful definition of full text index on a repository?
From: David Tweed @ 2007-10-01 16:33 UTC (permalink / raw)
To: Git Mailing List, Jon Smirl
Basically a "blue sky" question about full-text indexing git repositories.
A while back, whilst talking about overall git structure
(see
http://marc.info/?l=git&m=118891945402778&w=2
), Jon Smirl raised the question of putting a full-text index on a
repository. I doubt I full text index is of much use on a code
repository because the question tends to be focussed around either
released versions or immediate git-blame stuff. However, for
repositories of things like evolving documents/presentations/notes
where content is deleted because it doesn't fit the context rather
than being superceded by better stuff, it might be more natural to
search for "where's that paragraph I wrote on 'human' 'vision' and
'kinematic' 'feedback' ?". So I got to thinking about experimenting
with a full text index and even started writing some code. However, I
then realised that it's not obvious what the most useful definition of
a full text index is on evolving files. (To be clear, I'm _not_
thinking about changing the database fundamentals as discussed in the
referenced thread and indeed would put the full-text index into a
different file that just references the existing git db stuff
precisely because I doubt the text index will be of use to most
people.)
A "classical" full-text index seems inappropriate because, if I've got
a long text document that in a blob in commit n1 uses word 'x' in one
section and the corresponding file in descendant commit n2 has the
same text using word 'x' but has changes to a different section of the
document, there's probably no point showing me both documents (and I
can always track through the history once I've got one (commit-id,file
pair)). So in the case of a single word, a "useful" definition would
be the entry for word w in the full-text index should consist of those
(commit-id,file) pairs whose diff with their parent contains an
addition of text containing word w. (This will catch the creation of
the text containing w and then precisely those files which are close
modifications of it but ignore changes to other areas.) This seems to
make sense for a single word. Let's call this the "appearance diff"
definition of a full text index.
However, things become unclear if you consider a query with multiple
words. Consider the simplest case of a linear history where commit n0
adds word "vision" to file p1.tex (with respect to its single parent),
there are some intermediate commits and then commit n7 adds word
"feedback" to p1.tex. Then there's no commit whose diff with its
single parent contains both words "vision" and "feedback". In the
linear history case you could imagine trying to find the first commit
which is a child of _all_ the commits under the "appearance diff"
definition. However, that clearly doesn't "obviously" extend to
general full DAG histories, and in any case it's probably not fully
correct even in the linear case. So maybe a different definition would
be better. So I'm just throwing the question out to the list in case
anyone has any better ideas for what a full-text index on an evolving
set of files ought to be.
(One question is "why do you want to build a table rather than
actively search the full git repo for each query (ie, combination of
words) as you make it?" My primary motivation is that I might in the
future like to do queries on some sort of low processor power
UMPC-type thing, having built the file containing a "full text index"
data structure for the index on a quite beefy desktop. The other point
is that searching natural language text based on a fallible memory
you're more likely to try different combinations of search terms
iteratively to try and hit the right one, so there might be some point
in trying to build an index.)
Anyway, it's currently an idle speculation,
--
cheers, dave tweed__________________________
david.tweed@gmail.com
Rm 124, School of Systems Engineering, University of Reading.
"we had no idea that when we added templates we were adding a Turing-
complete compile-time language." -- C++ standardisation committee
^ permalink raw reply
* Re: metastore (was: Track /etc directory using Git)
From: David Härdeman @ 2007-09-19 19:16 UTC (permalink / raw)
To: martin f krafft
Cc: git, Daniel Barkalow, Johannes Schindelin, Thomas Harning Jr.,
Francis Moreau, Nicolas Vilz
In-Reply-To: <20070916060859.GB24124@piper.oerlikon.madduck.net>
On Sun, Sep 16, 2007 at 08:08:59AM +0200, martin f krafft wrote:
>also sprach Daniel Barkalow <barkalow@iabervon.org> [2007.09.15.2156 +0200]:
>> Configuration options only apply to the local aspects of the repository.
>> That is, when you clone a repository, you don't get the configuration
>> options from it, in general. And changing configuration options on a
>> repository does not have any effect on the content it contains. So
>> configuration options aren't appropriate.
>
>Sure they are. Just like git-commit figures out your email address
>if user.email is missing from git-config, or core.sharedRepository
>or core.umask deal with permissions only when you tell them to,
>you'd have to enable core.track or else git would just do what it
>does right now.
>
>> Git doesn't have any way to represent owners or groups, and they
>> would need to be represented carefully in order to make sense
>> across multiple computers. If you're adding support for
>> metadata-as-content (for more than "is this a script?"), you
>> should be able to cover all of the common cases of extended stuff,
>> like AFS-style ACLs.
>
>Ideally, git should be able to store an open-ended number of
>properties for each object, yes.
I haven't followed the discussion at all I must admit (I wrote metastore
as a quick hack to store some extended metadata and it works for my
purposes as long as I don't do anything fancy). But I agree, if any
changes were made to git, I'd advocate adding arbitrary attributes to
files (much like xattrs) in name=value pairs, then any extended metadata
could be stored in those attributes and external scripts/tools could use
them in some way that makes sense...and also make sure to only update
them when it makes sense.
--
David Härdeman
^ permalink raw reply
* Re: what's a useful definition of full text index on a repository?
From: Jon Smirl @ 2007-10-01 17:25 UTC (permalink / raw)
To: David Tweed; +Cc: Git Mailing List
In-Reply-To: <e1dab3980710010933u6a7324f0wa8230d67ee0846e2@mail.gmail.com>
On 10/1/07, David Tweed <david.tweed@gmail.com> wrote:
> Basically a "blue sky" question about full-text indexing git repositories.
>
> A while back, whilst talking about overall git structure
> (see
>
> http://marc.info/?l=git&m=118891945402778&w=2
>
> ), Jon Smirl raised the question of putting a full-text index on a
> repository. I doubt I full text index is of much use on a code
> repository because the question tends to be focussed around either
> released versions or immediate git-blame stuff. However, for
> repositories of things like evolving documents/presentations/notes
> where content is deleted because it doesn't fit the context rather
> than being superceded by better stuff, it might be more natural to
> search for "where's that paragraph I wrote on 'human' 'vision' and
> 'kinematic' 'feedback' ?". So I got to thinking about experimenting
> with a full text index and even started writing some code. However, I
> then realised that it's not obvious what the most useful definition of
> a full text index is on evolving files. (To be clear, I'm _not_
> thinking about changing the database fundamentals as discussed in the
> referenced thread and indeed would put the full-text index into a
> different file that just references the existing git db stuff
> precisely because I doubt the text index will be of use to most
> people.)
This is what full text is used for with code:
http://lxr.mozilla.org/
It makes grep instant.
For source code you can take the full text concept further and store
parse trees. This lets you instantly find the callers of a function,
or all users of a variable.
Once you have parse trees in the database you can offer refactoring
too. I have used powerful proprietary system that used parse trees to
make complicated refactoring quite easy.
Note that a parse tree database doesn't have to be generated for all
the old revisions, it is mainly usefully for the current HEAD. Same
for the full text index. When you generate this data you end up with
lots of tiny files that need to be kept in sync with the current HEAD.
git is good for holding those files.
You want all this analysis coordinated with git so that when you
commit a change the right parts get regenerated. Linux seems to be
missing good, automated refactoring assistance. Instead the kernel
janitorial work is being done manually.
An example I noticed today. Use of pr_debug() is chaotic in the kernel
source. Many drivers have #if DEBUG their own versions of pr_debug().
Fixing everything to have consistent use of pr_debug is a refactoring
that could probably be mostly automated.
Mozilla is undergoing some massive automated rewrites.
http://blog.mozilla.com/tglek/category/decomtamination/
Full text indexing can also achieve high levels of compression as
stated in the earlier threads. It is full scale dictionary
compression. When it is being used for compression you want to apply
it to all revisions.
> A "classical" full-text index seems inappropriate because, if I've got
> a long text document that in a blob in commit n1 uses word 'x' in one
> section and the corresponding file in descendant commit n2 has the
> same text using word 'x' but has changes to a different section of the
> document, there's probably no point showing me both documents (and I
> can always track through the history once I've got one (commit-id,file
> pair)). So in the case of a single word, a "useful" definition would
> be the entry for word w in the full-text index should consist of those
> (commit-id,file) pairs whose diff with their parent contains an
> addition of text containing word w. (This will catch the creation of
> the text containing w and then precisely those files which are close
> modifications of it but ignore changes to other areas.) This seems to
> make sense for a single word. Let's call this the "appearance diff"
> definition of a full text index.
You would full text index the expanded source text for each revision,
not the delta. There are forms of full text indexes that record the
words position in the document. They let you search for "vision NEAR
feedback"
A good feature of this is finding when a variable or function was first added.
>
> However, things become unclear if you consider a query with multiple
> words. Consider the simplest case of a linear history where commit n0
> adds word "vision" to file p1.tex (with respect to its single parent),
> there are some intermediate commits and then commit n7 adds word
> "feedback" to p1.tex. Then there's no commit whose diff with its
> single parent contains both words "vision" and "feedback". In the
> linear history case you could imagine trying to find the first commit
> which is a child of _all_ the commits under the "appearance diff"
> definition. However, that clearly doesn't "obviously" extend to
> general full DAG histories, and in any case it's probably not fully
> correct even in the linear case. So maybe a different definition would
> be better. So I'm just throwing the question out to the list in case
> anyone has any better ideas for what a full-text index on an evolving
> set of files ought to be.
>
> (One question is "why do you want to build a table rather than
> actively search the full git repo for each query (ie, combination of
> words) as you make it?" My primary motivation is that I might in the
> future like to do queries on some sort of low processor power
> UMPC-type thing, having built the file containing a "full text index"
> data structure for the index on a quite beefy desktop. The other point
> is that searching natural language text based on a fallible memory
> you're more likely to try different combinations of search terms
> iteratively to try and hit the right one, so there might be some point
> in trying to build an index.)
I do admit that these indexes are used to make functions that can be
done with brute force faster. As computers get faster the need for
these decrease. Right now the size of the kernel repo is not growing
faster than the progress of hardware. If you went back are tried to do
these things on a 386 you'd be shouting for indexes tomorrow.
>
> Anyway, it's currently an idle speculation,
>
> --
> cheers, dave tweed__________________________
> david.tweed@gmail.com
> Rm 124, School of Systems Engineering, University of Reading.
> "we had no idea that when we added templates we were adding a Turing-
> complete compile-time language." -- C++ standardisation committee
>
--
Jon Smirl
jonsmirl@gmail.com
^ permalink raw reply
* Re: [PATCH 1/4] Add a simple option parser for use by builtin-commit.c.
From: Johannes Schindelin @ 2007-10-01 18:13 UTC (permalink / raw)
To: Kristian Høgsberg; +Cc: Jonas Fonseca, gitster, git
In-Reply-To: <1191255975.25093.26.camel@hinata.boston.redhat.com>
Hi,
On Mon, 1 Oct 2007, Kristian H?gsberg wrote:
> On Sun, 2007-09-30 at 15:11 +0200, Jonas Fonseca wrote:
>
> > One of the last things I miss from Cogito is the nice abbreviated help
> > messages that was available via '-h'. I don't know if it would be
> > acceptable (at least for the main porcelain commands) to put this
> > functionality into the option parser by adding a "description" member
> > to struct option and have parse_options print a nice:
> >
> > <error message if any>
> > <usage string>
> > <option summary>
> >
> > on failure, or, if that is regarded as too verbose, simply when -h is
> > detected.
>
> Yeah, that might be nice. We can add it in a follow-on patch, if the
> list agrees that it's a good thing, I guess.
That's a good idea; I would put the usage string there, too.
> > > +
> > > +/* Parse the given options against the list of known options. The
> > > + * order of the option structs matters, in that ambiguous
> > > + * abbreviations (eg, --in could be short for --include or
> > > + * --interactive) are matched by the first option that share the
> > > + * prefix.
> > > + */
> >
> > This prefix aware option parsing has not been ported over to the other
> > builtins when they were lifted from shell code. It might be nice to
> > have of course. Is it really needed?
>
> I don't ever use it myself and I think it's more confusing than helpful.
> I only added it to avoid introducing behavior changes in the port. I
> don't have strong feelings either way.
It might be convenient, but I think that it is really more confusing than
helpful, especially with options that share a prefix. Besides, we have
good completion for bash now (and I hear that this "zsh" thing also has
quite good completion), I recommend <TAB> over prefix DWIMery.
> > > +
> > > +extern int parse_options(const char ***argv,
> > > + struct option *options, int count,
> > > + const char *usage_string);
> >
> > I think the interface could be improved a bit. For example, it doesn't
> > need to count argument since the last entry in the options array is
> > OPTION_LAST and thus the size can be detected that way.
>
> Hehe, yeah, that's how I did it first. I don't have a strong preference
> for terminator elements vs. ARRAY_SIZE(), but Junio prefers the
> ARRAY_SIZE() approach, I guess. At this point I'm just trying the get
> the patches upstream...
FWIW I like the ARRAY_SIZE() approach better, too, since it is less error
prone.
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH] Improve bash prompt to detect various states like an unfinished merge
From: Robin Rosenberg @ 2007-10-01 18:29 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, johannes.sixt, spearce
In-Reply-To: <7vabr3tfmq.fsf@gitster.siamese.dyndns.org>
måndag 01 oktober 2007 skrev Junio C Hamano:
> Robin Rosenberg <robin.rosenberg@dewire.com> writes:
>
> > This patch makes the git prompt (when enabled) show if a merge or a
> > rebase is unfinished. It also detects if a bisect is being done as
> > well as detached checkouts.
>
> Since you show the name of the branch anyway, I have to wonder
> why you should say BISECT.
You can wonder around different branches while bisecting. The BISECT
part is there to remind you that you are already doing bisecting, especially
when being away from the prompt for a while. I did some mistakes without it.
> Also if you know you normally get branch name, lack of branch
> name would indicate detached HEAD, I would presume.
Yes, sure, but I like it better this way.
> But other state information may be helpful.
This is an example script, so I'd say it's better to have a little too much
and let people remve stuff they don't like in their personal copies.
-- robin
^ permalink raw reply
* git clone questions relating to cpio
From: Reece Dunn @ 2007-10-01 19:28 UTC (permalink / raw)
To: Git
Hi,
I am running a Linux From Scratch 6.2 system that does not have cpio
installed on it. This means that I can't clone a local repository
unless I install cpio. Is it possible to use a fallback method if cpio
is not present, as there is no NO_CPIO option on make like there is
for OpenSSH, cURL and expat?
Also, I have an external USB hardrive that is mounted onto the virtual
filesystem. Will clones from the USB harddrive (or a USB flash drive
that is mounted) result in a copy being performed, not a hardlink?
Ideally, the hard linking for local clones should be optional. What if
I want to move a repository because, for example, I have imported a
CVS repository and now want to push it to a new bare repository?
- Reece
^ 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