* Re: Teach "approxidate" about weekday syntax
From: Linus Torvalds @ 2005-11-18 17:33 UTC (permalink / raw)
To: Andreas Ericsson; +Cc: David Roundy, git
In-Reply-To: <437E0ECC.8000503@op5.se>
On Fri, 18 Nov 2005, Andreas Ericsson wrote:
>
> 5 months with 73 days each; Chaos, Discord, Confusion, Bureaucracy, The
> Aftermath
> 5 days: Sweetmorn, Boomtime, Pungenday, Prickle-Prickle, Setting Orange
>
> February 29 is "St. Tibs day".
I'm sorry, but having "git log --since=confusion" would just be
irresponsible.
Linus
^ permalink raw reply
* Re: Teach "approxidate" about weekday syntax
From: Linus Torvalds @ 2005-11-18 16:56 UTC (permalink / raw)
To: David Roundy; +Cc: git
In-Reply-To: <20051118121210.GA19714@abridgegame.org>
On Fri, 18 Nov 2005, David Roundy wrote:
>
> Don't forget "high noon"! (and perhaps "tea time"?) :)
Done.
[torvalds@g5 git]$ ./test-date "now" "midnight" "high noon" "tea-time"
now -> bad -> Wed Dec 31 16:00:00 1969
now -> Fri Nov 18 08:50:54 2005
midnight -> bad -> Wed Dec 31 16:00:00 1969
midnight -> Fri Nov 18 00:00:00 2005
high noon -> bad -> Wed Dec 31 16:00:00 1969
high noon -> Thu Nov 17 12:00:00 2005
tea-time -> bad -> Wed Dec 31 16:00:00 1969
tea-time -> Thu Nov 17 17:00:00 2005
Thanks for pointing out tea-time.
This is also written to easily extended to allow people to add their own
important dates like Christmas and their own birthdays.
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
---
diff --git a/date.c b/date.c
index d2a67cc..3e11500 100644
--- a/date.c
+++ b/date.c
@@ -468,12 +468,52 @@ static void update_tm(struct tm *tm, uns
localtime_r(&n, tm);
}
+static void date_yesterday(struct tm *tm, int *num)
+{
+ update_tm(tm, 24*60*60);
+}
+
+static void date_time(struct tm *tm, int hour)
+{
+ if (tm->tm_hour < hour)
+ date_yesterday(tm, NULL);
+ tm->tm_hour = hour;
+ tm->tm_min = 0;
+ tm->tm_sec = 0;
+}
+
+static void date_midnight(struct tm *tm, int *num)
+{
+ date_time(tm, 0);
+}
+
+static void date_noon(struct tm *tm, int *num)
+{
+ date_time(tm, 12);
+}
+
+static void date_tea(struct tm *tm, int *num)
+{
+ date_time(tm, 17);
+}
+
+static const struct special {
+ const char *name;
+ void (*fn)(struct tm *, int *);
+} special[] = {
+ { "yesterday", date_yesterday },
+ { "noon", date_noon },
+ { "midnight", date_midnight },
+ { "tea", date_tea },
+ { NULL }
+};
+
static const char *number_name[] = {
"zero", "one", "two", "three", "four",
"five", "six", "seven", "eight", "nine", "ten",
};
-static struct typelen {
+static const struct typelen {
const char *type;
int length;
} typelen[] = {
@@ -487,7 +527,8 @@ static struct typelen {
static const char *approxidate_alpha(const char *date, struct tm *tm, int *num)
{
- struct typelen *tl;
+ const struct typelen *tl;
+ const struct special *s;
const char *end = date;
int n = 1, i;
@@ -502,9 +543,12 @@ static const char *approxidate_alpha(con
}
}
- if (match_string(date, "yesterday") > 8) {
- update_tm(tm, 24*60*60);
- return end;
+ for (s = special; s->name; s++) {
+ int len = strlen(s->name);
+ if (match_string(date, s->name) == len) {
+ s->fn(tm, num);
+ return end;
+ }
}
if (!*num) {
^ permalink raw reply related
* Rss produced by git is not valid xml?
From: Ismail Donmez @ 2005-11-18 16:33 UTC (permalink / raw)
To: git
Hi all,
I am trying to parse git's rss feed and now xml parsers seems to choke on it
because of an error in the produced feed. Looking at
http://www.kernel.org/git/?p=linux/kernel/git/torvalds/linux-2.6.git;a=rss
line 781 says :
On Thu, 17 Nov 2005, David G\363mez wrote:<br/>
which is part of the commit :
http://www.kernel.org/git/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=05b8b0fafd4cac75d205ecd5ad40992e2cc5934d
This looks like malformed xml to me ( because of \363 part ). Is there any way
to fix this so git rss can be parsed? Or is this legal in xml and parsers are
buggy?
Regards,
ismail
^ permalink raw reply
* Make "git fetch" less verbose by default
From: Linus Torvalds @ 2005-11-18 16:31 UTC (permalink / raw)
To: Junio C Hamano, Git Mailing List
When doing something like
git fetch --tags origin
the excessively verbose output of git fetch makes the result totally
unreadable. It's impossible to tell if it actually fetched anything new or
not, since the screen will fill up with an endless supply of
...
* committish: 9165ec17fde255a1770886189359897dbb541012
tag 'v0.99.7c' of master.kernel.org:/pub/scm/git/git
* refs/tags/v0.99.7c: same as tag 'v0.99.7c' of master.kernel.org:/pub/scm/git/git
...
and any new tags that got fetched will be totally hidden.
So add a new "--verbose" flag to "git fetch" to enable this verbose mode,
but make the default be quiet.
NOTE! The quiet mode will still report about new or changed heads, so if
you are really fetching a new head, you'll see something like this:
[torvalds@g5 git]$ git fetch --tags parent
Packing 6 objects
Unpacking 6 objects
100% (6/6) done
* refs/tags/v1.0rc2: storing tag 'v1.0rc2' of master.kernel.org:/pub/scm/git/git
* refs/tags/v1.0rc3: storing tag 'v1.0rc3' of master.kernel.org:/pub/scm/git/git
* refs/tags/v1.0rc1: storing tag 'v1.0rc1' of master.kernel.org:/pub/scm/git/git
which actually tells you something useful that isn't hidden by all the
useless crud that you already had.
Extensively tested (hey, for me, this _is_ extensive) by doing a
rm .git/refs/tags/v1.0rc*
and re-fetching with both --verbose and without.
NOTE! This means that if the fetch didn't actually fetch anything at all,
git fetch will be totally quiet. I think that's much better than being so
verbose that you can't even tell whether something was fetched or not, but
some people might prefer to get a "nothing to fetch" message in that case.
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
---
diff --git a/git-fetch.sh b/git-fetch.sh
index 8564cbf..6586e77 100755
--- a/git-fetch.sh
+++ b/git-fetch.sh
@@ -12,6 +12,7 @@ IFS="$LF"
tags=
append=
force=
+verbose=
update_head_ok=
while case "$#" in 0) break ;; esac
do
@@ -30,6 +31,9 @@ do
--update-head-o|--update-head-ok)
update_head_ok=t
;;
+ -v|--verbose)
+ verbose=Yes
+ ;;
*)
break
;;
@@ -91,12 +95,12 @@ append_fetch_head () {
then
headc_=$(git-rev-parse --verify "$head_^0") || exit
echo "$headc_ $not_for_merge_ $note_" >>"$GIT_DIR/FETCH_HEAD"
- echo >&2 "* committish: $head_"
- echo >&2 " $note_"
+ [ "$verbose" ] && echo >&2 "* committish: $head_"
+ [ "$verbose" ] && echo >&2 " $note_"
else
echo "$head_ not-for-merge $note_" >>"$GIT_DIR/FETCH_HEAD"
- echo >&2 "* non-commit: $head_"
- echo >&2 " $note_"
+ [ "$verbose" ] && echo >&2 "* non-commit: $head_"
+ [ "$verbose" ] && echo >&2 " $note_"
fi
if test "$local_name_" != ""
then
@@ -116,7 +120,7 @@ fast_forward_local () {
then
if now_=$(cat "$GIT_DIR/$1") && test "$now_" = "$2"
then
- echo >&2 "* $1: same as $3"
+ [ "$verbose" ] && echo >&2 "* $1: same as $3"
else
echo >&2 "* $1: updating with $3"
fi
^ permalink raw reply related
* [PATCH] Fix bug introduced by the latest changes to git-pack-redundant
From: Lukas Sandström @ 2005-11-18 16:30 UTC (permalink / raw)
To: git; +Cc: Lukas Sandström, Alex Riesen, junkio
In-Reply-To: <437C819C.4040507@etek.chalmers.se>
I forgot to initialize part of the pll struct when copying it.
Found by valgrind.
Signed-off-by: Lukas Sandström <lukass@etek.chalmers.se>
---
pack-redundant.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
applies-to: 500482a7b3ebb2ebac182136696cb124332feba8
b51be59ab5b323ef148f833976a9c324d6a27404
diff --git a/pack-redundant.c b/pack-redundant.c
index 2d7183e..3123f45 100644
--- a/pack-redundant.c
+++ b/pack-redundant.c
@@ -442,7 +442,7 @@ void minimize(struct pack_list **min)
break; /* ignore all larger permutations */
if (is_superset(perm->pl, missing)) {
new_perm = xmalloc(sizeof(struct pll));
- new_perm->pl = perm->pl;
+ memcpy(new_perm, perm, sizeof(struct pll));
new_perm->next = perm_ok;
perm_ok = new_perm;
}
---
0.99.9.GIT
^ permalink raw reply related
* Re: "make test" fails with current HEAD
From: Linus Torvalds @ 2005-11-18 16:14 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Matthias Urlichs, git
In-Reply-To: <7vbr0imlha.fsf@assigned-by-dhcp.cox.net>
On Fri, 18 Nov 2005, Junio C Hamano wrote:
>
> And at this point it becomes more and more tempting to have our
> own internal diff generator, without relying on external diff.
>
> A midway compromise solution would be to detect if either file
> is binary ourselves and not to call diff but always say "Binary
> files difer".
Umm.. Why not just say "if the line after the 'diff' line doesn't start
with '@@ ', then it's a binary diff"?
And not care at _all_ about what it says.
We require unified diffs, and they _always_ start with '@@ ' after the
header. No need to check anything else.
Linus
^ permalink raw reply
* Re: Teach "approxidate" about weekday syntax
From: Randy.Dunlap @ 2005-11-18 16:08 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: David Roundy, git
In-Reply-To: <Pine.LNX.4.63.0511181419340.28109@wbgn013.biozentrum.uni-wuerzburg.de>
On Fri, 18 Nov 2005, Johannes Schindelin wrote:
> On Fri, 18 Nov 2005, David Roundy wrote:
>
> > Don't forget "high noon"! (and perhaps "tea time"?) :)
>
> How about "dooms day"? I would like to do this:
>
> git-whatchanged -p --until="dooms day"
>
> Hmm?
Sure, and throw in "ides" (15th afaik) and moon phases
while you are at it.
--
~Randy [who would just use ISO standard date format]
^ permalink raw reply
* Re: [RFC] Applying a graft to a tree and "rippling" the changes through
From: Josef Weidendorfer @ 2005-11-18 15:54 UTC (permalink / raw)
To: git
In-Reply-To: <20051117230723.GD26122@nowhere.earth>
On Friday 18 November 2005 00:07, Yann Dirson wrote:
> Current commit objects refer to a child tree, but to parent _commits_.
> Whereas it seems necessary to walk through the history line, and
> easily get a changelog, it is semantically quite not right: the
> changes we record with a commit indeed come from modification of
> trees, not of commits.
Yes. The change to a tree (which is equalent to 2 trees - new old and
the new one; or for merges multiple old ones and the new one) does not
depend on any history. Unfortunately, we have no separate object to
specify the "the change to a tree". We include this information into
the commit object, and thus, bind it to the history.
This could be changed in git, i.e. put the tree relationship into a
separate object; even comments could be split up in change related and
history related. The question is: is this useful, is there any
important usage scenario that rectifies such a change?
I do not really think so.
> That is, the resulting tree does not depend on
> the history of the parent trees, but on the parent trees themselves.
No, the resulting tree is an independent object, it is the tree ;-)
Do not confuse this with the commit pointing to the tree.
> And similarly, tags usually denote a particular state of the tree,
> "somewhat" independantly of its history: linux-2.6.11 is the same
> beast, whereas the repository holds full history since 0.1 or not.
I agree that tags for tree objects are useful, but what is the problem?
You can do this already.
But tags for commit objects are equally useful, especially signed ones:
they include a fixed history which can not be changed. Eg. they include
all the people which attributed code to the project, and this is important
for license questions. This is the reason that "grafting" should stay
a local workaround.
That the concrete tag "linux-2.6.11" points to a commit, and not to the
tree object, probably was done on purpose; i.e. the creator of the tag
wanted to include the history. If not, he could have made the tag for the
tree object directly.
> Indeed that emphasizes that the history lines are on living on a
> higher level of abstraction that commits.
Hmm.. If you only have tree changes, there is no history. The history
specifies an order of the changes. The changes themselve do not include
any such order.
> Now what if we used
> trees->tree commits, instead of the current commits->tree ones ?
It would be better to not talk about "commits" for tree changes (perhaps
with comments about the change). As said above, tree change objects
could be introduced. The question is why?
> The
> main problem would be to be able to reconstruct those history lines,
> so that we can still extract the log
No problem: You still have the chain of commits, and one commit points
to the parent commit(s) and the corresponding new introduced tree change
objects.
> - what's a better model if we
> loose functionnality ? ;)
There is nothing lost. If you regard the comments entered at "git commit"
time as purely change related, this comments can be put together with the
tree change object. So if you "apply a graft to a tree", (signed) tags for tree
changes would include the comment, and stay valid after "regrafting".
But why would anyone want to sign a change?
> However, I must admit that at this point, I have not found a
> reasonable solution to this problem.
>
> Any genius with a solution out there ? :)
What is the difficult problem here?
Josef
^ permalink raw reply
* Re: current HEAD in bash prompt
From: Alex Riesen @ 2005-11-18 14:57 UTC (permalink / raw)
To: Ben Clifford; +Cc: Git Mailing List
In-Reply-To: <9C44605A-4F0F-42FA-A8ED-A4F7EFA24C32@hawaga.org.uk>
[-- Attachment #1: Type: text/plain, Size: 358 bytes --]
On 11/17/05, Ben Clifford <benc@hawaga.org.uk> wrote:
> After getting a bit confused when having too many branches, and for
> people who don't mind extra forks and like too much info in their
> prompt, I've recently started using this:
>
> export PS1='!\! [\j] \u@\h:\w$(output-git-head-or-blank)\$ '
>
I did almost the same, but in .c (attached).
[-- Attachment #2: current-branch.c --]
[-- Type: application/octet-stream, Size: 504 bytes --]
#include "cache.h"
static const char * basename(const char *p)
{
const char *f = strrchr(p, '/');
return f ? ++f: p;
}
int main(int argc, const char **argv)
{
argv0 = *argv;
setup_git_directory();
if ( argc < 2 ) {
static const char *def[] = { NULL, "HEAD", NULL };
argv = def;
}
while ( *++argv ) {
unsigned char sha1[20];
char *ref = strdup(git_path("%s", *argv));
const char *deref = resolve_ref(ref, sha1, 0);
puts(deref ? basename(deref): *argv);
free(ref);
}
return 0;
}
^ permalink raw reply
* Re: [ANNOUNCE] gitfs pre-release 0.03
From: Paolo Teti @ 2005-11-18 14:20 UTC (permalink / raw)
To: Mitchell Blank Jr; +Cc: git
In-Reply-To: <20051118124532.GG87234@gaz.sfgoth.com>
Great job!
A question: the gitFS in your intent has to became a "clone" of the
Rational MultiVersion File System?
^ permalink raw reply
* Re: [RFC] Applying a graft to a tree and "rippling" the changes through
From: sf @ 2005-11-18 13:57 UTC (permalink / raw)
To: git
In-Reply-To: <20051117230723.GD26122@nowhere.earth>
Yann Dirson wrote:
...
> Current commit objects refer to a child tree, but to parent _commits_.
> Whereas it seems necessary to walk through the history line, and
> easily get a changelog, it is semantically quite not right: the
> changes we record with a commit indeed come from modification of
> trees, not of commits. That is, the resulting tree does not depend on
> the history of the parent trees, but on the parent trees themselves.
I would go even further: The resulting tree does not depend on anything.
A tree is a tree is a tree.
A commit is really just the statement: "I changed the tree from state A
to state B". After all, the commit message does not describe the new
state (neither the old state) but does describe the changes.
> And similarly, tags usually denote a particular state of the tree,
> "somewhat" independantly of its history: linux-2.6.11 is the same
> beast, whereas the repository holds full history since 0.1 or not.
Exactly, the tree "linux-2.6.11" is the tree "linux-2.6.11". How it came
about is totally irrelevant if you are only interested in this
particular version (does anyone download all linux-*.tar.bz2 just to get
linux-2.6.11.tar.bz2?).
> Indeed that emphasizes that the history lines are on living on a
> higher level of abstraction that commits. Now what if we used
> trees->tree commits, instead of the current commits->tree ones ? The
> main problem would be to be able to reconstruct those history lines,
> so that we can still extract the log - what's a better model if we
> loose functionnality ? ;)
You can traverse tree -> commit -> tree -> commit -> tree ... to get the
history. No functionality lost.
> However, I must admit that at this point, I have not found a
> reasonable solution to this problem.
>
> Any genius with a solution out there ? :)
In your model you have a mapping from commits to sets of trees (by way
of commit objects). Now you create the "inverse" mapping from trees to
sets of commits. Both mappings together enable you to walk the history.
Why is git's model different?
1. You have to watch out for circles in history (Git's model ensures
that history is always a DAG).
2. Your model is harder to implement in the typical case (But deleting
from repositiories, partial repositories, augmenting or cutting history
etc. are hard to implement as it is now, if not outright impossible).
3. It is the way repositories have been organized ever since CVS (Git
throws out some concepts of the CVS model, but not all).
Regards
Stephan
^ permalink raw reply
* Re: Teach "approxidate" about weekday syntax
From: Johannes Schindelin @ 2005-11-18 13:20 UTC (permalink / raw)
To: David Roundy; +Cc: git
In-Reply-To: <20051118121210.GA19714@abridgegame.org>
Hi,
On Fri, 18 Nov 2005, David Roundy wrote:
> Don't forget "high noon"! (and perhaps "tea time"?) :)
How about "dooms day"? I would like to do this:
git-whatchanged -p --until="dooms day"
Hmm?
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH] Give python a chance to find "backported" modules
From: Johannes Schindelin @ 2005-11-18 13:18 UTC (permalink / raw)
To: git
In-Reply-To: <Pine.LNX.4.63.0511160331150.15130@wbgn013.biozentrum.uni-wuerzburg.de>
Hi,
On Wed, 16 Nov 2005, Johannes Schindelin wrote:
> python 2.2.1 is perfectly capable of executing git-merge-recursive,
Well, no.
Actually, my tests ran, but only because they were trivial, or next to it.
In line 477 of git-merge-recursive.py, there is a reference to an __iter__
member of a list (the recs object). Python 2.2.1 does not know about that,
but rather wants to do the iteration over the collection iter(recs).
However, this does not work, as some of the contained objects have to be
skipped.
So I bit the bullet, compiled Python 2.4.2, and it works. Sorry for the
noise.
Ciao,
Dscho
^ permalink raw reply
* [ANNOUNCE] gitfs pre-release 0.03
From: Mitchell Blank Jr @ 2005-11-18 12:45 UTC (permalink / raw)
To: git
I've released another pre-release of my gitfs tool tonight. The isn't a ton
of new functionality, but there has been a lot of changes:
% for dir in gitfs-0.0[123]; do echo `cat $dir/*.[ch] | wc -l` $dir; done
2228 gitfs-0.01
2334 gitfs-0.02
8276 gitfs-0.03
This is mostly because I've been working on taking it from the "proof of
concept" phase to a real filesystem. To that end:
* gitfs now does all git operations in a separate thread so accessing a
large file won't cause other filesystem operations to stall. In order
to allow multithreaded operations we no longer use the libfuse API -- we
speak the kernel/fuse API directly. This was a lot of work but it's
actually a much better fit for gitfs since it allows me to map directly
between inode #'s and the internal "gnode"'s, saving a lot of work.
Because of this you no longer need libfuse installed to use gitfs --
all you need to compile is point the Makefile at a <linux/fuse.h>
header -- the one that comes with a >=2.6.14 kernel will work fine.
However, to actually mount a fuse filesystem you'll need the "fusermount"
helper binary from fuse somewhere in $PATH
* We use the sha1_object_info() API in current versions of libgit to
avoid uncompressing blob objects if they're only being stat()'ed.
This is another big speed-up
* gitfs mounts now also create a UNIX domain socket so external clients
can make requests (for instance to optimize things like "diff")
Currently only a few simple commands are implemented, as described in
the README
* Lots of other infrastructure and data-structure work. I'm particularly
proud of my rather scary red-black tree implementation :-)
As usual tarballs are available at:
http://www.sfgoth.com/~mitch/linux/gitfs/
-Mitch
^ permalink raw reply
* Re: Teach "approxidate" about weekday syntax
From: David Roundy @ 2005-11-18 12:12 UTC (permalink / raw)
To: git
In-Reply-To: <Pine.LNX.4.64.0511171520390.13959@g5.osdl.org>
On Thu, Nov 17, 2005 at 03:23:00PM -0800, Linus Torvalds wrote:
> On Thu, 17 Nov 2005, Linus Torvalds wrote:
> >
> > I think I'm done.
>
> The only thing I might want to do is add some support for time-of-day to
> the thing. Notably "noon" and "midnight".
Don't forget "high noon"! (and perhaps "tea time"?) :)
--
David Roundy
http://www.darcs.net
^ permalink raw reply
* Re: master has some toys
From: timo @ 2005-11-18 12:01 UTC (permalink / raw)
To: git
In-Reply-To: <Pine.LNX.4.63.0511171249550.737@wbgn013.biozentrum.uni-wuerzburg.de>
On Thu, Nov 17, 2005 at 12:51:22PM +0100, Johannes Schindelin wrote:
> Hi,
>
> On Thu, 17 Nov 2005, Junio C Hamano wrote:
>
> > It appears we'd better have something like this in the main
> > Makefile, so people do not have to do it themselves everywhere?
>
> I'd like to wait to have a reaction from other people. I vividly remember
> my eyes falling out of my sockets when somebody reported success on cygwin
> without NO_MMAP. If there is *any* cygwin version which fixes it, we
> should rather make people upgrade, no?
>
It is not in the official Cygwin distribution yet. Though I've started the
formalities, moving house as been taking all my spare time. So, the upgrade
worries would be for those people tracking the main git repo. As they are
almost certainly on this list, they should be aware of possible breakage.
I've noted some breakage with git-archimport, git-svnimport and git-cvsimport,
though i have not yet looked into it, some are due to the lack of necessary
tools under Cygwin. I'm re-jigging my distro script to emulate the new package
split and plan to distribute just the git 'core' stuff for the moment.
I was wondering if anyone has scripts that i could use to test the
svn/arch/CVS import/export for expected behavior?
Tim.
"However beautiful the strategy, you should occasionally look at the results."
-- Winston Churchill
^ permalink raw reply
* Re: "make test" fails with current HEAD
From: Matthias Urlichs @ 2005-11-18 11:12 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git
In-Reply-To: <Pine.LNX.4.63.0511181203510.16457@wbgn013.biozentrum.uni-wuerzburg.de>
[-- Attachment #1: Type: text/plain, Size: 649 bytes --]
Hi,
Johannes Schindelin:
> > So I still think a "Just write a 'Binary files FOO and BAR differ' line
> > if the exit status is 2" rule would at least fix the current bug with
> > diff 2.8.7.
>
> Dunno. Am I the only one with an odd feeling about that?
>
I don't really like it either, but frankly I'm not going to write a new
(or integrate an existing) diff implementation for 1.0 ... you want to
do it, feel free. ;-)
--
Matthias Urlichs | {M:U} IT Design @ m-u-it.de | smurf@smurf.noris.de
Disclaimer: The quote was selected randomly. Really. | http://smurf.noris.de
- -
BOFH excuse #217:
The MGs ran out of gas.
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: "make test" fails with current HEAD
From: Johannes Schindelin @ 2005-11-18 11:04 UTC (permalink / raw)
To: Matthias Urlichs; +Cc: git
In-Reply-To: <20051118105415.GN31613@kiste.smurf.noris.de>
Hi,
On Fri, 18 Nov 2005, Matthias Urlichs wrote:
> Johannes Schindelin:
> > From my diff man page:
> >
> > -- snip --
> > DIAGNOSTICS
> > An exit status of 0 means no differences were found, 1 means some
> > differences were found, and 2 means trouble.
> > -- snap --
> >
> > The exit value 2 is ambiguous for at least one version of GNU diff.
> >
> AFAIK, We have
> 0 - no difference
> 1 - produced a reasonable diff
> 1 - produced a bad diff because binary stuff starts
> after 4096-or-whatever bytes and diff didn't notice
> 2 - didn't produce a diff -- binary files differ
> 2 - something else broke
>
> Right now we simply don't consider the second -2- case, because we just
> successfully wrote the two files in question; there's not *that* much
> that can fail after that. The second -1- case is sufficiently rare too.
>
> So I still think a "Just write a 'Binary files FOO and BAR differ' line
> if the exit status is 2" rule would at least fix the current bug with
> diff 2.8.7.
Dunno. Am I the only one with an odd feeling about that?
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH] Add test case for git-config-set
From: Johannes Schindelin @ 2005-11-18 10:57 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vsltuo49q.fsf@assigned-by-dhcp.cox.net>
Hi,
On Thu, 17 Nov 2005, Junio C Hamano wrote:
> Junio C Hamano <junkio@cox.net> writes:
>
> > git-config-set section.key
> >
> > confusingly enough is --unset (we probably would want to require
> > an explicit command line noise-word "--unset" in this case).
As mentioned in my previous mail, this will go.
> A revised suggestion is:
>
> ;# remove all
> git-config-set --unset section.key
No. Just remove one unique entry. If people insist it is a good idea to
throw away all multivars, I'll think about it. But I am not convinced.
Your use case of a multivar does not fit what I think multivars are useful
for.
IMHO, multiple key/value pairs are only sensible when they provide a sort
of subkey, like Linus did in his example:
[proxy]
command=ssh for kernel.org
command=rsh for myprivate.machine
See, there is a subkey, namely "for kernel.org", which can nicely be
expressed as a regex.
IMOHO, your example
[diff]
twohead = resolve
twohead = recursive
would look much better in this way
[diff]
twohead = recursive resolve
Several reasons:
- it is easier to read
- it does the job
- it is clear from the beginning, which one precedes the other
(for me it was not at all clear that the last entry wins...)
> ;# remove values that match rx and then append zero or more values
> git-config-set --remove rx section.key [value...]
As I said. *If*, then these must be two operations, for your security. But
I still don't see a sensible use case of removing all key/value pairs for
a certain key (and possibly a regex for the values).
Rather, if you have a sensible setup, you'll want to set/replace/unset
exactly one entry.
> ;# append one or more values (equivalent to specifying --remove
> ;# with rx that never matches anything). To reduce
> ;# confusion, we always require at least one value here.
> git-config-set section.key value [value...]
I think it is less error prone to add them one by one, else you have to
check the values for uniqueness, too.
> I think (aside from "*-set" now becomes confusing), showing the
> value of the specified key to stdout with
>
> git-config-set section.key
>
> would be a nice addition to complete the suite; has anybody
> noticed that git-var is cumbersome to use for this?
Good point! This will be in my next version.
Ciao,
Dscho
^ permalink raw reply
* Re: "make test" fails with current HEAD
From: Matthias Urlichs @ 2005-11-18 10:54 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git
In-Reply-To: <Pine.LNX.4.63.0511181134080.8037@wbgn013.biozentrum.uni-wuerzburg.de>
[-- Attachment #1: Type: text/plain, Size: 1185 bytes --]
Hi,
Johannes Schindelin:
> From my diff man page:
>
> -- snip --
> DIAGNOSTICS
> An exit status of 0 means no differences were found, 1 means some
> differences were found, and 2 means trouble.
> -- snap --
>
> The exit value 2 is ambiguous for at least one version of GNU diff.
>
AFAIK, We have
0 - no difference
1 - produced a reasonable diff
1 - produced a bad diff because binary stuff starts
after 4096-or-whatever bytes and diff didn't notice
2 - didn't produce a diff -- binary files differ
2 - something else broke
Right now we simply don't consider the second -2- case, because we just
successfully wrote the two files in question; there's not *that* much
that can fail after that. The second -1- case is sufficiently rare too.
So I still think a "Just write a 'Binary files FOO and BAR differ' line
if the exit status is 2" rule would at least fix the current bug with
diff 2.8.7.
--
Matthias Urlichs | {M:U} IT Design @ m-u-it.de | smurf@smurf.noris.de
Disclaimer: The quote was selected randomly. Really. | http://smurf.noris.de
- -
<Knghtbrd> xtifr - beware of james when he's off his medication =3D>
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: [PATCH] Add test case for git-config-set
From: Johannes Schindelin @ 2005-11-18 10:48 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vd5kypjv2.fsf@assigned-by-dhcp.cox.net>
Hi,
On Thu, 17 Nov 2005, Junio C Hamano wrote:
> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
>
> > +test_expect_failure 'ambiguous unset' \
> > + 'git-config-set --unset nextsection.nonewline'
>
> I am not so sure about this case. Shouldn't this remove both?
No. The common case should be a variable with a unique key/value pair. And
in that case, it should be treated as an error if there are already more
than one pair.
> For example, if a Porcelain wants to force pull.twohead to be
> resolve and nothing else, and it wants to do it unconditionally,
> it would first want to empty whatever multivalue there are
> currently, and then insert its own, and I'd imagine the way to
> say that would be like this:
>
> git-config-set --unset pull.twohead '^'
> git-config-set pull.twohead resolve
>
> More simply (I do not think you have a test case for this):
>
> git-config-set pull.twohead resolve '^'
This is a slippery slope. Giving a wrong regex by accident may destroy
*all* your settings. Not what I want.
> I think it is the easiest to explain and understand the
> semantics of config_set_multivalue if it were to first remove all
> existing key-value for matching ones, and then insert what was
> provided by the user.
I'd be very, very careful about that. For sure, I'd want to make the
removing of multiple values a single operation, which leaves a backup of
.git/config behind.
> Extending that multivalue example a bit more, I think it is a
> bit cumbersome for a Porcelain to set pull.twohead to recursive
> and then resolve, with your interface. Even if you had the
> emptying behaviour I suggested above, you would have to say
> something awkard like this:
>
> git-config-set --unset pull.twohead '^'
> git-config-set pull.twohead recursive
> git-config-set pull.twohead resolve no-such-value-should-be-there
Really, I don't see the point in making twohead a multivar:
[diff]
twohead = resolve recursive blabla
This looks much nicer to me, and should be easy to parse (even for human
eyes, who do not particularly like to find one value at the top of
.git/config, and the second on the bottom, which is perfectly possible in
your setup).
> Maybe we could have the shell-level interface like this:
>
> git-config-set [--remove rx] section.key [value...]
As I said, I'd be *very* careful to remove multiple values. So, I would
like to *require* two steps for this.
> git-config-set section.key
>
> confusingly enough is --unset
Okay. That was my original code before introducing multivars, where I did
not have --unset. This will go.
> git-config-set pull.twohead recursive resolve
Oh yes, yes. Just quote "recursive resolve"! Note that it is somewhat
uncommon to make the behaviour of a variable in an ini file depend on its
position... (this is meant as one more point in favor of just one pair).
> The C-level interface would become something like:
>
> git_config_set_multivar(const char *key,
> const char *remove_value_regex,
> const char **values)
>
> where values is a NULL terminated list of values.
The normal use case (for things like "proxy.command", which will hopefully
not become very common) will be to set/replace/unset exactly one value.
For what you want, your proposal might be good, but I deem a unique
key/value pair with a space separated list of methods a better solution.
> BTW, do we want to remove the section after removing the last
> key and making it empty?
No, because you might have comments in there. I am not willing to go as
far as removing something like
[diff]
;might want to use that someday
;twohead = recursive megacool
Ciao,
Dscho
^ permalink raw reply
* Re: "make test" fails with current HEAD
From: Johannes Schindelin @ 2005-11-18 10:35 UTC (permalink / raw)
To: Matthias Urlichs; +Cc: git
In-Reply-To: <pan.2005.11.18.08.56.22.908009@smurf.noris.de>
Hi,
On Fri, 18 Nov 2005, Matthias Urlichs wrote:
> So the trivial fix is to emit our own "Binary files FOO and BAR differ"
> line if the exit status is 2.
>From my diff man page:
-- snip --
DIAGNOSTICS
An exit status of 0 means no differences were found, 1 means some
differences were found, and 2 means trouble.
-- snap --
The exit value 2 is ambiguous for at least one version of GNU diff.
Hth,
Dscho
^ permalink raw reply
* Re: [PATCH 5/5] git-daemon support for user-relative paths.
From: Andreas Ericsson @ 2005-11-18 10:18 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7voe4ird8v.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano wrote:
> exon@op5.se (Andreas Ericsson) writes:
>
>
>>Everything that worked earlier still works insofar as I have
>>remembered testing it.
>
>
> Hmph...
>
:)
I haven't used the daemon without our patches. Everything works as per
spec now though.
>
>>@@ -152,45 +140,17 @@ static int set_dir(const char *dir)
>> * We want a readable HEAD, usable "objects" directory, and
>> * a "git-daemon-export-ok" flag that says that the other side
>> * is ok with us doing this.
>
>
> Well, not anymore about HEAD as far as I can tell... Maybe in
> enter_repo ([PATCH 1/5]) we need to do something like what
> setup.c::is_toplevel_directory() does?
>
Umm... Perhaps. I just noticed that it's possible for the .git/objects
directory to go missing though.
>
>>-static int upload(char *dir)
>>-{
>>- /* Try paths in this order */
>>- static const char *paths[] = { "%s", "%s/.git", "%s.git", "%s.git/.git", NULL };
>
>
> I think this list was added relatively recently as a usability
> measure. Maybe we would want an equivalent in enter_repo()?
It's already there but in a different format. Adding "if (!strict)" to
the previously unconditional 'chdir(".git");' won't change that.
Like I said, I made sure everything that worked before works now too.
> Under strict-path, I think not doing any DWIM like this is fine,
> but otherwise I suspect changing this would break existing
> remotes/origin file people may have. In addition enter_repo()
> as posted does its own DWIM to chdir to ".git" unconditionally
> as I pointed out...
>
DWIM? That's an acronym I don't know.
> Needs a bit more thought, but I think otherwise the basic idea
> is right.
>
Anything I should change before "take four" ?
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
^ permalink raw reply
* Re: [PATCH 1/5] Library code for user-relative paths, take three.
From: Andreas Ericsson @ 2005-11-18 10:14 UTC (permalink / raw)
Cc: Junio C Hamano, git
In-Reply-To: <437DA828.6020207@op5.se>
Andreas Ericsson wrote:
> Junio C Hamano wrote:
>
>>
>>> + /* This is perfectly safe, and people tend to think of the
>>> directory
>>> + * where they ran git-init-db as their repository, so humour
>>> them. */
>>> + (void)chdir(".git");
>>
>>
>>
>> It might be safe, but I think it changes the behaviour of
>> upload-pack with strict case. My gut reaction is we would want
>> "if (!strict)" in front. Thoughts?
>>
>
> As it says in the comment; People tend to think of the directory where
> they ran "git init-db" as their repository, so humour them. It's nice
> for sharing files between devs in the office, and it *is* safe. Do as
> you please though. It's the generality of the
>
Butter-fingers be me. Sorry about that.
What I meant to say was that:
"it's the general idea of the patchset I'm after".
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
^ permalink raw reply
* Re: [PATCH 1/5] Library code for user-relative paths, take three.
From: Andreas Ericsson @ 2005-11-18 10:08 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7v8xvmsu9o.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano wrote:
>
>>+ /* This is perfectly safe, and people tend to think of the directory
>>+ * where they ran git-init-db as their repository, so humour them. */
>>+ (void)chdir(".git");
>
>
> It might be safe, but I think it changes the behaviour of
> upload-pack with strict case. My gut reaction is we would want
> "if (!strict)" in front. Thoughts?
>
As it says in the comment; People tend to think of the directory where
they ran "git init-db" as their repository, so humour them. It's nice
for sharing files between devs in the office, and it *is* safe. Do as
you please though. It's the generality of the
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
^ 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