* Re: auto gc
From: Jens Axboe @ 2007-11-15 8:28 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: git
In-Reply-To: <20071115082004.GL14735@spearce.org>
On Thu, Nov 15 2007, Shawn O. Pearce wrote:
> Jens Axboe <jens.axboe@oracle.com> wrote:
> ...
> > Packing your repository for optimum performance. You may also
> > run "git gc" manually. See "git help gc" for more information.
> > Generating pack...
> > [...]
> >
> > This is extremely annoying behaviour! If I'm on battery or just in a bit
> > of a hurry, I defeinitely don't want git second guessing me and deciding
> > that it's time to run git gc.
> >
> > I'd suggest just printing a hint that running git gc would increase
> > performance, doing it automatically is definitely bad style (even more
> > so when then yet again changed git refs layout even breaks old scripts,
> > when git gc has run).
>
> Set the following and it won't run automatically anymore for you:
>
> git config --global gc.auto 0
> git config --global gc.autopacklimit 0
OK
> More recently this message has been changed to:
>
> Packing your repository for optimum performance. You may also
> run "git gc" manually. See "git help gc" for more information.
Great, that's a lot more appropriate in my opinion. I'll just update to
a later git.
Thanks!
--
Jens Axboe
^ permalink raw reply
* Re: [PATCH v2] Bisect reset: remove bisect refs that may have been packed.
From: Junio C Hamano @ 2007-11-15 8:34 UTC (permalink / raw)
To: Christian Couder; +Cc: git, Johannes Sixt
In-Reply-To: <7vwssj6hw8.fsf@gitster.siamese.dyndns.org>
Junio C Hamano <gitster@pobox.com> writes:
> Christian Couder <chriscool@tuxfamily.org> writes:
>
>> If refs were ever packed in the middle of bisection, the bisect
>> refs were not removed from the "packed-refs" file.
>>
>> This patch fixes this problem by using "git update-ref -d $ref $hash"
>> in "bisect_clean_state".
>>
>> Signed-off-by: Christian Couder <chriscool@tuxfamily.org>
>
> Thanks. Just a few nits.
>
> On top of your patch...
>
> - You forgot to remove one "removal of filesystem refs";
Ooops. 'test -d "$GIT_DIR/refs/bisect"' is used as a signal
that we are bisecting for the rest of the code, so we cannot
lose that rm -fr there.
I think a longer term clean-up would be not to treat "bisect" as
a reserved branch name but use detached HEAD while bisecting.
But that is a larger topic.
^ permalink raw reply
* Re: Cloning empty repositories, was Re: What is the idea for bare repositories?
From: Andreas Ericsson @ 2007-11-15 8:42 UTC (permalink / raw)
To: Bill Lear; +Cc: Johannes Schindelin, Junio C Hamano, git
In-Reply-To: <18235.34578.886521.944550@lisa.zopyra.com>
Bill Lear wrote:
>
> What's wrong with 'git init --mirror git://host/repo'?
It wouldn't match other --mirror options. You would want it to set up
refs/remotes namespace for you, but the other --mirror options (those
in push/fetch) are meant to explicitly ignore refs/remotes and make
sure branches are named exactly the same on both sides (hence --mirror).
I wouldn't mind if it was given some other option that did what you
wanted, but having --mirror mean two such very different things would
be bad.
"git init --remote origin=git://host/repo", where the lhs of the equal
sign would default to "origin" might be a good way to implement it.
Personally I don't have any problems with the current way of getting
things done, so it's not my itch.
>
>> (I actually think that it is another example of cvs/svn damage, where you
>> _need_ to clone first, or otherwise you will _never_ be able to commit
>> to the repository.)
>
> I think there is a tendency here to blame every shortcoming of git on
> someone else's supposedly unsanitary past rather than facing up to
> inherent problems in git itself. We have several very senior, very
> dedicated software developers who LOVE git, and who loathe CVS, but
> who nevertheless find many vexing issues in git.
>
git is not perfect. It's just better than everything else. Bringing up
those vexing issues here is one way of making it better though, so thanks
for doing that. :)
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
^ permalink raw reply
* Re: [PATCH v2] Bisect reset: remove bisect refs that may have been packed.
From: Shawn O. Pearce @ 2007-11-15 8:49 UTC (permalink / raw)
To: Johannes Sixt; +Cc: Junio C Hamano, Christian Couder, git
In-Reply-To: <473C02F9.4020402@viscovery.net>
Johannes Sixt <j.sixt@viscovery.net> wrote:
> Junio C Hamano schrieb:
> >+ git for-each-ref --format='%(refname) %(objectname)' refs/bisect/\*
> >refs/heads/bisect |
> >+ while read ref hash
>
> If you also swap %(refname) and %(objectname), then this is also not prone
> to whitespace in refnames. (Yes, I know, there shouldn't be such, but...)
What's this obsession with whitespace in refnames? Twice in like
two days people are talking about whitespace in refnames.
WHITESPACE IS NOT PERMITTED IN REFNAMES.
Do we need to apply the following patch, to keep people from creating
refs by hand with whitespace in them? Is this really that common?
git rev-parse HEAD >'.git/refs/heads/..i have spaces hah!'
diff --git a/refs.c b/refs.c
index aff02cd..b95bf83 100644
--- a/refs.c
+++ b/refs.c
@@ -246,6 +246,7 @@ static struct ref_list *get_ref_dir(const char *base, struct ref_list *list)
struct stat st;
int flag;
int namelen;
+ int check;
if (de->d_name[0] == '.')
continue;
@@ -261,6 +262,9 @@ static struct ref_list *get_ref_dir(const char *base, struct ref_list *list)
list = get_ref_dir(ref, list);
continue;
}
+ check = check_ref_format(ref);
+ if (check != 0 && check != -2)
+ continue;
if (!resolve_ref(ref, sha1, 1, &flag)) {
error("%s points nowhere!", ref);
continue;
--
Shawn.
^ permalink raw reply related
* Re: Cloning empty repositories, was Re: What is the idea for bare repositories?
From: Andreas Ericsson @ 2007-11-15 8:51 UTC (permalink / raw)
To: David Kastrup
Cc: Junio C Hamano, Sergei Organov, Matthieu Moy, Johannes Schindelin,
Bill Lear, Jan Wielemaker, git
In-Reply-To: <85mytg1f6n.fsf@lola.goethe.zz>
David Kastrup wrote:
> Junio C Hamano <gitster@pobox.com> writes:
>
>> But cloning void to start the same project by multiple people
>> and pushing their initial commits as roots to start a project
>> indicates the lack of developer communication (besides, it just
>> feels like a bad style, a hangover from centralized SCM
>> mentality, but that is fine).
>
> I do not like the approach of policy by force. It assumes that the
> developers know better than the users what the users are going to do
> with git.
>
Junio just said "but that is fine", so afaiu he's not against allowing
it per se. It's just that him and the other frequent contributors don't
have this particular problem, so if *they* fix it it will
a) Not be done with enthusiasm, and it would indeed drain enthusiasm and
happiness from the project.
b) Perhaps not be done the way those who want this feature would like it.
c) Take another scarce resource (time) from other, more pressing issues
which may or may not affect your workflow too.
Junio also suggested what's likely to be needed for this to work "properly",
ie, an extension to the git protocol to let it transfer symref content.
Since empty repositories have HEAD pointing to refs/heads/master by default,
you might get away with a simpler implementation.
> For example, I use git for tracking and versioning installations and
> updaters of complex programs. They are basically built into a directory
> tree, and this tree is checked into a bare repository in a branch
> corresponding to a particular customer. The trees are _target_ trees
> created completely by something akin to make install. So every checkin
> is from scratch. The checkins for a particular customer happen in one
> branch so that it is easy to generate a diff and from that an updater
> (the diff gets converted into a batch file removing old files and a zip
> file unpacking new files over the old ones).
>
> There simply is no common reference/starting point for the disparate
> branches. I have some "README" in master, but that is an utterly stupid
> and unnatural starting point.
>
> One might argue that one should use one repository per customer and just
> share the objects (many of which are similar). But that disallows
> making diffs between the trees of different customers. Since the
> purpose of git here is just to track history and not do any sort of
> merging or rebasing, there are no interesting ancestry connections
> between branches.
>
> Am I stupid for using git for this sort of thing? I believe not. And
> yet git developers choose to call me stupid because my work flow does
> not lend any sense to a common ancestor commit.
>
Not stupid, but most likely unusual. Optimizing git for your needs would
imho be a bad idea. It's perfectly fine to use a tool for something else
than what it was intended for, but then you'll have to live with the
fact that it *will* have a few shortcomings and that you'll have to work
around them or fix them yourself.
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
^ permalink raw reply
* Re: [PATCH v2] Bisect reset: remove bisect refs that may have been packed.
From: Jeff King @ 2007-11-15 8:52 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: Johannes Sixt, Junio C Hamano, Christian Couder, git
In-Reply-To: <20071115084934.GN14735@spearce.org>
On Thu, Nov 15, 2007 at 03:49:34AM -0500, Shawn O. Pearce wrote:
> What's this obsession with whitespace in refnames? Twice in like
> two days people are talking about whitespace in refnames.
I even had Junio convinced at one point!
I am not actually creating such refs, but I think my brain was still
fried from the URL encoding discussion, and I was overly paranoid about
spaces.
-Peff
^ permalink raw reply
* [PATCH 1/3] git-bisect: war on "sed"
From: Junio C Hamano @ 2007-11-15 9:00 UTC (permalink / raw)
To: git; +Cc: Christian Couder, Ralf Wildenhues
In-Reply-To: <20071115081807.06fe092b.chriscool@tuxfamily.org>
We do not need to pipe "echo" to "sed" only to strip refs/heads/
from the beginning. We are assuming not-so-ancient shells these
days.
Also there is no need to avoid assuming \012 is the LF; we do
not run on EBCDIC, sorry. Other parts of the script already
uses tr to convert separator to LF that way.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
---
git-bisect.sh | 5 ++---
1 files changed, 2 insertions(+), 3 deletions(-)
diff --git a/git-bisect.sh b/git-bisect.sh
index 46a7b8d..3a21033 100755
--- a/git-bisect.sh
+++ b/git-bisect.sh
@@ -71,7 +71,7 @@ bisect_start() {
;;
refs/heads/*)
[ -s "$GIT_DIR/head-name" ] && die "won't bisect on seeked tree"
- echo "$head" | sed 's#^refs/heads/##' >"$GIT_DIR/head-name"
+ echo "${head#refs/heads/}" >"$GIT_DIR/head-name"
;;
*)
die "Bad HEAD - strange symbolic ref"
@@ -275,8 +275,7 @@ exit_if_skipped_commits () {
if expr "$_tried" : ".*[|].*" > /dev/null ; then
echo "There are only 'skip'ped commit left to test."
echo "The first bad commit could be any of:"
- echo "$_tried" | sed -e 's/[|]/\
-/g'
+ echo "$_tried" | tr '[|]' '[\012]'
echo "We cannot bisect more!"
exit 2
fi
--
1.5.3.5.1780.gca2b
^ permalink raw reply related
* [PATCH 2/3] git-bisect: use update-ref to mark good/bad commits
From: Junio C Hamano @ 2007-11-15 9:01 UTC (permalink / raw)
To: Christian Couder; +Cc: git
In-Reply-To: <20071115081807.06fe092b.chriscool@tuxfamily.org>
This removes the last instance of making a ref by hand with
"echo SHA1 >.git/refs/$refname" from the script and replaces it
with update-ref.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
---
git-bisect.sh | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/git-bisect.sh b/git-bisect.sh
index 3a21033..4b74a7b 100755
--- a/git-bisect.sh
+++ b/git-bisect.sh
@@ -130,7 +130,7 @@ bisect_write() {
good|skip) tag="$state"-"$rev" ;;
*) die "Bad bisect_write argument: $state" ;;
esac
- echo "$rev" >"$GIT_DIR/refs/bisect/$tag"
+ git update-ref "refs/bisect/$tag" "$rev"
echo "# $state: "$(git show-branch $rev) >>"$GIT_DIR/BISECT_LOG"
test -z "$nolog" && echo "git-bisect $state $rev" >>"$GIT_DIR/BISECT_LOG"
}
--
1.5.3.5.1780.gca2b
^ permalink raw reply related
* [PATCH 3/3] git-bisect: modernize branch shuffling hack
From: Junio C Hamano @ 2007-11-15 9:01 UTC (permalink / raw)
To: Christian Couder; +Cc: git
In-Reply-To: <20071115081807.06fe092b.chriscool@tuxfamily.org>
When switching to a new rev, we first made "new-bisect" branch to
point at the chosen commit, attempt to switch to it, and then
finally renamed the new-bisect branch to bisect by hand when
successful. This is so that we can catch checkout failure (your
local modification may interfere with switching to the chosen
version) without losing information on which commit the next
attempt should be made.
Rewrite it using a more modern form but without breaking the
safety.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
---
git-bisect.sh | 5 ++---
1 files changed, 2 insertions(+), 3 deletions(-)
diff --git a/git-bisect.sh b/git-bisect.sh
index 4b74a7b..dae8a8e 100755
--- a/git-bisect.sh
+++ b/git-bisect.sh
@@ -316,10 +316,9 @@ bisect_next() {
exit_if_skipped_commits "$bisect_rev"
echo "Bisecting: $bisect_nr revisions left to test after this"
- echo "$bisect_rev" >"$GIT_DIR/refs/heads/new-bisect"
+ git branch -f new-bisect "$bisect_rev"
git checkout -q new-bisect || exit
- mv "$GIT_DIR/refs/heads/new-bisect" "$GIT_DIR/refs/heads/bisect" &&
- GIT_DIR="$GIT_DIR" git symbolic-ref HEAD refs/heads/bisect
+ git branch -M new-bisect bisect
git show-branch "$bisect_rev"
}
--
1.5.3.5.1780.gca2b
^ permalink raw reply related
* Re: [PATCH] Unify the use of standard set of exclude files
From: Junio C Hamano @ 2007-11-15 9:03 UTC (permalink / raw)
To: Jeff King
Cc: git, shunichi fuji, Pierre Habouzit, Andreas Ericsson,
Johannes Schindelin
In-Reply-To: <20071115070429.GD10185@sigill.intra.peff.net>
Jeff King <peff@peff.net> writes:
> git-add--interactive:list_untracked needs something like this, but I
> don't think your patch will work. We need something more like this (also
> on maint because your standard exclude patch is):
>
> -- >8 --
> git-ls-files: add --exclude-standard
>
> This provides a way for scripts to get at the new standard exclude
> function.
I like this, along with the patch to add--interactive.
Will forge your signature ;-).
^ permalink raw reply
* Re: [PATCH] Unify the use of standard set of exclude files
From: Jeff King @ 2007-11-15 9:15 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vbq9v6fue.fsf@gitster.siamese.dyndns.org>
On Thu, Nov 15, 2007 at 01:03:05AM -0800, Junio C Hamano wrote:
> Will forge your signature ;-).
Oops, thank you. :)
-Peff
^ permalink raw reply
* Re: [PATCH 1/3] git-bisect: war on "sed"
From: Miles Bader @ 2007-11-15 9:29 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Christian Couder, Ralf Wildenhues
In-Reply-To: <7voddv6fxz.fsf@gitster.siamese.dyndns.org>
Junio C Hamano <gitster@pobox.com> writes:
> We do not need to pipe "echo" to "sed" only to strip refs/heads/
> from the beginning. We are assuming not-so-ancient shells these
> days.
What's wrong with sed?
-Miles
--
[|nurgle|] ddt- demonic? so quake will have an evil kinda setting? one that
will make every christian in the world foamm at the mouth?
[iddt] nurg, that's the goal
^ permalink raw reply
* Re: [PATCH 1/3] git-bisect: war on "sed"
From: Wincent Colaiuta @ 2007-11-15 9:36 UTC (permalink / raw)
To: Miles Bader; +Cc: Junio C Hamano, git, Christian Couder, Ralf Wildenhues
In-Reply-To: <buozlxfeu0z.fsf@dhapc248.dev.necel.com>
El 15/11/2007, a las 10:29, Miles Bader escribió:
> Junio C Hamano <gitster@pobox.com> writes:
>> We do not need to pipe "echo" to "sed" only to strip refs/heads/
>> from the beginning. We are assuming not-so-ancient shells these
>> days.
>
> What's wrong with sed?
Nothing, but using it means forking a new process unnecessarily, and
the shorter form without sed is arguably more readable:
- echo "$head" | sed 's#^refs/heads/##' >"$GIT_DIR/head-name"
+ echo "${head#refs/heads/}" >"$GIT_DIR/head-name"
Cheers,
Wincent
^ permalink raw reply
* [PATCH] git-p4: Fix direct import from perforce after fetching changes through git from origin
From: Simon Hausmann @ 2007-11-15 9:38 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
[-- Attachment #1: Type: text/plain, Size: 1981 bytes --]
When using an existing git repository to cache the perforce import we don't fetch the
branch mapping from perforce as that is a slow operation. However the origin repository
may not be fully up-to-date and therefore it may be necessary to import more changes
directly from Perforce. Such a direct import needs self.knownBranches to be set up though,
so initialize it from the existing p4/* git branches.
Signed-off-by: Simon Hausmann <simon@lst.de>
---
contrib/fast-import/git-p4 | 15 +++++++++++++--
1 files changed, 13 insertions(+), 2 deletions(-)
diff --git a/contrib/fast-import/git-p4 b/contrib/fast-import/git-p4
index c148b5a..c869bb8 100755
--- a/contrib/fast-import/git-p4
+++ b/contrib/fast-import/git-p4
@@ -1207,6 +1207,15 @@ class P4Sync(Command):
for branch in lostAndFoundBranches:
self.knownBranches[branch] = branch
+ def getBranchMappingFromGitBranches(self):
+ branches = p4BranchesInGit(self.importIntoRemotes)
+ for branch in branches.keys():
+ if branch == "master":
+ branch = "main"
+ else:
+ branch = branch[len(self.projectName):]
+ self.knownBranches[branch] = branch
+
def listExistingP4GitBranches(self):
# branches holds mapping from name to commit
branches = p4BranchesInGit(self.importIntoRemotes)
@@ -1541,8 +1550,10 @@ class P4Sync(Command):
## FIXME - what's a P4 projectName ?
self.projectName = self.guessProjectName()
- if not self.hasOrigin:
- self.getBranchMapping();
+ if self.hasOrigin:
+ self.getBranchMappingFromGitBranches()
+ else:
+ self.getBranchMapping()
if self.verbose:
print "p4-git branches: %s" % self.p4BranchesInGit
print "initial parents: %s" % self.initialParents
--
1.5.3.5.576.gfe6193
[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply related
* Re: [PATCH 1/3] git-bisect: war on "sed"
From: Miles Bader @ 2007-11-15 9:53 UTC (permalink / raw)
To: Wincent Colaiuta; +Cc: Junio C Hamano, git, Christian Couder, Ralf Wildenhues
In-Reply-To: <995F69D5-4ABC-44E7-BA2B-5E276479EDA1@wincent.com>
Wincent Colaiuta <win@wincent.com> writes:
> the shorter form without sed is arguably more readable:
>
> - echo "$head" | sed 's#^refs/heads/##' >"$GIT_DIR/head-name"
> + echo "${head#refs/heads/}" >"$GIT_DIR/head-name"
Er, I suppose -- if you are acquainted with that particular shell
variable syntax (I suspect knowledge of sed is far more widespread).
[personally, I know that syntax has something to do with replacing
something with something else, but really haven't much clue other than
that, and I always _thought_ it was bash-specific and so avoided using
any of that stuff.]
-miles
--
People who are more than casually interested in computers should have at
least some idea of what the underlying hardware is like. Otherwise the
programs they write will be pretty weird. -- Donald Knuth
^ permalink raw reply
* Re: [PATCH 1/3] git-bisect: war on "sed"
From: Andreas Ericsson @ 2007-11-15 10:06 UTC (permalink / raw)
To: Miles Bader
Cc: Wincent Colaiuta, Junio C Hamano, git, Christian Couder,
Ralf Wildenhues
In-Reply-To: <buotznnesw9.fsf@dhapc248.dev.necel.com>
Miles Bader wrote:
> Wincent Colaiuta <win@wincent.com> writes:
>> the shorter form without sed is arguably more readable:
>>
>> - echo "$head" | sed 's#^refs/heads/##' >"$GIT_DIR/head-name"
>> + echo "${head#refs/heads/}" >"$GIT_DIR/head-name"
>
> Er, I suppose -- if you are acquainted with that particular shell
> variable syntax (I suspect knowledge of sed is far more widespread).
>
> [personally, I know that syntax has something to do with replacing
> something with something else, but really haven't much clue other than
> that, and I always _thought_ it was bash-specific and so avoided using
> any of that stuff.]
>
It says "remove refs/heads/ from the beginning of the string pointed to
by $head".
It's not a bashism. Some extensions to that syntax are though (I think).
If you want to be sure of portability, use sed instead. git uses this
syntax often enough that it's worth using everywhere, but usually only
in porcelain commands which one can relatively safely assume are run on
at least decently up-to-date developer workstations.
You'll note that stuff that absolutely *has* to reside server-side are
entirely in C.
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
^ permalink raw reply
* Re: git-clean won't read global ignore
From: Matthieu Moy @ 2007-11-15 10:07 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Pierre Habouzit, shunichi fuji, git
In-Reply-To: <7vsl39l0b7.fsf@gitster.siamese.dyndns.org>
Junio C Hamano <gitster@pobox.com> writes:
> We probably could change git-ls-files to use the standard set
> when no excludes are specified from the command line, or
> something like that, but this will be a change in semantics that
> would affect the scripts in a subtle way. I am somewhat
> reluctant to make such a change.
+1 for your introduction of setup_standard_excludes().
And woh, I was writting a mail to say that adding a --exclude-standard
would be cool, but it has been implemented even before I said it would
be cool.
Nothing to add, except "Thanks Junio, Thanks Jeff!" :-).
At last, I'll be able to write
$ git ls-files -o --exclude-standard >> .gitignore
$ $EDITOR .gitignore
--
Matthieu
^ permalink raw reply
* Re: [PATCH 1/3] git-bisect: war on "sed"
From: David Kastrup @ 2007-11-15 10:14 UTC (permalink / raw)
To: git
In-Reply-To: <473C1A29.2010703@op5.se>
Andreas Ericsson <ae@op5.se> writes:
>> Wincent Colaiuta <win@wincent.com> writes:
>>> + echo "${head#refs/heads/}" >"$GIT_DIR/head-name"
>
> It says "remove refs/heads/ from the beginning of the string pointed
> to by $head".
>
> It's not a bashism. Some extensions to that syntax are though (I
> think).
General replace anywhere.
> If you want to be sure of portability, use sed instead.
Guffaw.
> git uses this syntax often enough that it's worth using everywhere,
> but usually only in porcelain commands which one can relatively
> safely assume are run on at least decently up-to-date developer
> workstations.
Huh? It is used throughout. That's why "make install" will install
xxx.sh scripts as xxx after possibly replacing the initial #!/bin/sh
line with a shell known to be reasonably conformant on a particular
system.
--
David Kastrup
^ permalink raw reply
* [BUG] encoding problem with format-patch + send-email
From: Uwe Kleine-König @ 2007-11-15 10:57 UTC (permalink / raw)
To: git; +Cc: Brian Swetland, Russell King - ARM Linux, Nicolas Pitre
Hello,
Brian just stumbled over a problem with format-patch + send-email.
format-patch only adds Content-Type and Content-Transfer-Encoding
headers iff the body needs it.
send-email adds "From: A. U. Thor <author@tld>" to the body if sender
and From: in the patch to send differ.
Both is just fine, but if the author has some non-ascii characters in
her name but the body is ascii-only the resulting mail is broken.
What about adding the Content-Type and Content-Transfer-Encoding headers
in any case?
Best regards
Uwe
--
Uwe Kleine-König, Software Engineer
Digi International GmbH Branch Breisach, Küferstrasse 8, 79206 Breisach, Germany
Tax: 315/5781/0242 / VAT: DE153662976 / Reg. Amtsgericht Dortmund HRB 13962
^ permalink raw reply
* Re: [PATCH 1/3] git-bisect: war on "sed"
From: Miles Bader @ 2007-11-15 11:00 UTC (permalink / raw)
To: David Kastrup
Cc: Wincent Colaiuta, Junio C Hamano, git, Christian Couder,
Ralf Wildenhues
In-Reply-To: <86tznn4y7v.fsf@lola.quinscape.zz>
On Nov 15, 2007 7:09 PM, David Kastrup <dak@gnu.org> wrote:
> > Er, I suppose -- if you are acquainted with that particular shell
> > variable syntax (I suspect knowledge of sed is far more widespread).
>
> sed is rather bad with regard to portability. If you take a look at
> the respective portability section in the autoconf file, it is almost
> longer than that of Bourne shells.
I don't think that's really a fair characterization -- almost all of
the autoconf sed portability caveats concern weird corner cases in the
dusty corners of the language (and some are "common" issues with other
tools, i.e., avoiding ^ and $ inside of regexp groups).
For typical straightforward usage, there seems little problem.
[The main portability problems I've actually _noticed_ with sed are
the "-e" versus ";" issue and what happens with "\n" in various
contexts...]
-Miles
--
Do not taunt Happy Fun Ball.
^ permalink raw reply
* Re: [PATCH] user-manual.txt: fix a few mistakes
From: Sergei Organov @ 2007-11-15 10:36 UTC (permalink / raw)
To: J. Bruce Fields; +Cc: git, gitster
In-Reply-To: <20071114181858.GH14254@fieldses.org>
"J. Bruce Fields" <bfields@fieldses.org> writes:
> On Tue, Nov 13, 2007 at 09:19:39PM +0300, Sergei Organov wrote:
>>
>> Signed-off-by: Sergei Organov <osv@javad.com>
>> ---
>> Documentation/user-manual.txt | 8 ++++----
>> 1 files changed, 4 insertions(+), 4 deletions(-)
>>
>> diff --git a/Documentation/user-manual.txt b/Documentation/user-manual.txt
>> index d99adc6..a169ef0 100644
>> --- a/Documentation/user-manual.txt
>> +++ b/Documentation/user-manual.txt
>> @@ -475,7 +475,7 @@ Bisecting: 3537 revisions left to test after this
>> If you run "git branch" at this point, you'll see that git has
>> temporarily moved you to a new branch named "bisect". This branch
>> points to a commit (with commit id 65934...) that is reachable from
>> -v2.6.19 but not from v2.6.18. Compile and test it, and see whether
>> +"master" but not from v2.6.18. Compile and test it, and see whether
>> it crashes. Assume it does crash. Then:
>>
>> -------------------------------------------------
>> @@ -1367,7 +1367,7 @@ If you make a commit that you later wish you hadn't, there are two
>> fundamentally different ways to fix the problem:
>>
>> 1. You can create a new commit that undoes whatever was done
>> - by the previous commit. This is the correct thing if your
>> + by the old commit. This is the correct thing if your
>> mistake has already been made public.
>>
>> 2. You can go back and modify the old commit. You should
>> @@ -1567,8 +1567,8 @@ old history using, for example,
>> $ git log master@{1}
>> -------------------------------------------------
>>
>> -This lists the commits reachable from the previous version of the head.
>> -This syntax can be used to with any git command that accepts a commit,
>
> I actually prefer "head" here. On something like:
>
> A--B--C
> /
> o--o--o
> \
> o--o--o
>
>
> The term "branch" could be used to refer to the whole line of
> development consisting of A, B, and C. The term "head", on the other
> hand, refers to either C or a ref that points to it. We also use the
> terms "branch head" or just "branch" for that case, but I think "head"
> is more precise.
Then I'd suggest to be precise here, e.g.:
"This lists the commits reachable from the previous version of the
"master" branch head."
The real reason for me to replacing "head" with "branch" in the first
place was that a few lines below there is example for HEAD, and I wanted
to make it more obvious that those is entirely different.
--
Sergei.
^ permalink raw reply
* Re: [PATCH 1/3] git-bisect: war on "sed"
From: David Kastrup @ 2007-11-15 11:18 UTC (permalink / raw)
To: git
In-Reply-To: <fc339e4a0711150300n64b9d670o1e183553a9de0cba@mail.gmail.com>
"Miles Bader" <miles@gnu.org> writes:
> On Nov 15, 2007 7:09 PM, David Kastrup <dak@gnu.org> wrote:
>> > Er, I suppose -- if you are acquainted with that particular shell
>> > variable syntax (I suspect knowledge of sed is far more widespread).
>>
>> sed is rather bad with regard to portability. If you take a look at
>> the respective portability section in the autoconf file, it is almost
>> longer than that of Bourne shells.
>
> I don't think that's really a fair characterization -- almost all of
> the autoconf sed portability caveats concern weird corner cases in the
> dusty corners of the language (and some are "common" issues with other
> tools, i.e., avoiding ^ and $ inside of regexp groups).
>
> For typical straightforward usage, there seems little problem.
>
> [The main portability problems I've actually _noticed_ with sed are
> the "-e" versus ";" issue and what happens with "\n" in various
> contexts...]
What about character classes containing the pattern delimiter, \+, \?,
\|, nested grouping, anchors in groups, * after groups? That's all
rather straightforward usage.
--
David Kastrup
^ permalink raw reply
* Re: refining .gitignores
From: Bruce Stephens @ 2007-11-15 11:39 UTC (permalink / raw)
To: Alex Riesen; +Cc: git
In-Reply-To: <20071114230258.GG3973@steel.home>
Alex Riesen <raa.lkml@gmail.com> writes:
> Bruce Stephens, Wed, Nov 14, 2007 23:36:06 +0100:
>> How do I get a list of files (in HEAD, say) that would be ignored by
>> the .gitignore files (and the other usual settings)?
>>
>> It feels like something like this ought to work:
>>
>> git ls-files -z | xargs -0 git ls-files --ignored
>>
>> But listing its arguments that are ignored by .gitignore (etc.)
>> doesn't seem to be what "git ls-files --ignored" does. Or at least,
>> not quite as straightforwardly as that.
>
> git ls-files --exclude-per-directory=.gitignore -X .git/info/exclude -i -o
That doesn't seem to work.
For example, if I add '*.c' to .gitignores in git.git, I can't seem to
get that command to display any .c files.
Run on its own, it displays lots of files, but no .c files. Run with
an argument (such as builtin-add.c), it displays nothing.
>> The motivation is (obviously) that I fear some of the .gitignore
>> patterns are too broad, and a reasonable check is that none of the
>> files that are already committed would be caught by the patterns.
>
> git ls-files --exclude-per-directory=.gitignore -X .git/info/exclude -i
That also doesn't seem to do quite what I want, and probably in the
same way. I see git add returns non-zero error status if a file is
ignored, so I can do it with
excluded=()
for f in $(git ls-files)
do
git add $f || excluded=($excluded $f)
done
But that feels kind of clunky. I feel I'm missing something basic
about how git ls-files is intended to work, or something.
^ permalink raw reply
* Re: Problem in our test setup
From: Johannes Schindelin @ 2007-11-15 11:40 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vzlxg6kzt.fsf@gitster.siamese.dyndns.org>
Hi,
On Wed, 14 Nov 2007, Junio C Hamano wrote:
> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
>
> > Because my prefix is the default prefix, which is $HOME/bin, and which
> > is not turned off in the tests. So git finds "runstatus", because it
> > is still installed.
>
> Yes, we have a problem.
>
> We could solve this for commands issued in "git foo" form by not looking
> for "git-foo" anywhere other than in git_exec_path. The scripts and
> tests only prepend GIT_EXEC_PATH to their PATH and run "git foo" or
> "git-foo", but if we replace all of them to the non-dash form, wouldn't
> that solve the issue as well?
Funnily enough, it _is_ the non-dash form that I replaced. What happens
is this: the git wrapper looks for a builtin named 'runstatus', does not
find it, then calls out for something like 'git-runstatus', which is found
in my $HOME/bin.
Sorry,
Dscho
^ permalink raw reply
* Re: Warning: cvsexportcommit considered dangerous
From: Alex Bennee @ 2007-11-15 11:59 UTC (permalink / raw)
To: Robin Rosenberg; +Cc: Johannes Schindelin, Steffen Prohaska, Git Mailing List
In-Reply-To: <200711050005.28561.robin.rosenberg.lists@dewire.com>
On Mon, 2007-11-05 at 00:05 +0100, Robin Rosenberg wrote:
> söndag 04 november 2007 skrev Johannes Schindelin:
> > Hi,
> > On Sun, 4 Nov 2007, Steffen Prohaska wrote:
> > > On Nov 4, 2007, at 5:41 PM, Johannes Schindelin wrote:
> > > > ever since the up-to-date check was changed to use just one call to
> > > > "cvs status", a bug was present. Now cvsexportcommit expects "cvs
> > > > status" to return the results in the same order as the file names were
> > > > passed.
> > > I do not know why it wasn't applied. I forgot re-checking after my
> > > vacation.
I think at the time it was felt the speed hit was too great on large
trees. Although my view still is we should always go for correctness
over speed.
> > It slipped by me, because of holiday, too. (I was on my well needed
> > holiday then.)
> >
> > But that patch really seems like a step back to me. The line "File: ...
> > Status: ..." should be parsable enough to fix the bug properly, instead of
> > undoing the optimisation.
> Unfortunately it's not that easy to parse. It *can* be done by looking at the
> repository path, and the CVS/Root etc, but it's not nice.
I also worry about corner cases in parsing code, especially if you have
to start poking around in CVS/Root files. Another (ugly) method could be
a two pass attempt, falling back to an individual status call if the
"optimized" version isn't sure.
> > AFAICS Robin replied with a "let's see if a proper fix materialises", and
> > I kind of hope that it will materialise soon.
I've not had another go at fixing this mainly due to being too busy. The
current patch works for me.
> Still hoping :). BTW, wouldn't this err on the right side anyway, i.e. if an
> existing file was not up to date and was wrongly thought to not exist or a new
> file was thought to be up-to-date, I would get an error and would not be able
> to commit. I've never seen it though and I always have a clean CVS checkout
> so the potential bug seems unlikely to me.
It's not just new files that can break (btw another fix has gone in to
ensure directories are added to CVS trees in order).
--
Alex, homepage: http://www.bennee.com/~alex/
Nothing in life is to be feared. It is only to be understood.
^ 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