* Re: [PATCH][RESEND] Escape some tilde characters causing spurious subscripts in documentation
From: Jason Sewall @ 2007-06-24 21:40 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Johannes Schindelin, git
In-Reply-To: <31e9dd080706241031m64c6be37sb4437036fda543c9@mail.gmail.com>
On 6/24/07, Jason Sewall <jasonsewall@gmail.com> wrote:
> On 6/24/07, Junio C Hamano <gitster@pobox.com> wrote:
> > "Jason Sewall" <jasonsewall@gmail.com> writes:
> >
> > > On 6/23/07, Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
> > >
> > >> I just checked with my copy of asciidoc, though, and there is no mangling
> > >> going on, at least in git-bundle.html (which is the only file I checked).
> > >> My asciidoc is version 8.2.1. What is yours?
> > >
> > > I've got 8.1.0; perhaps that's the problem. I wasn't so surprised to
> > > hear the asciidoc 7 and 8 don't get along, but I'm surprised to see
> > > that 8.1 and 8.2 are so different.
> > >
> > > Anyway, 8.1.0 is apparently what's in Fedora 7 (the distro I'm using
> > > right now) so it might be worth hanging on to the patch.
> >
> > FWIW, 7.1.2, 8.2.1 and 7.0.2 all seem to be Ok (the last one is
> > used to format the pages in html and man branches of git.git).
> > It is a bit annoying having to use name\~num at some places and
> > no backslash all others.
> >
> > Two requests:
> >
> > - Documentation/git-rev-parse.txt has '{tilde}<n>'. If you
> > replace that {tilde} with a "~", how does your AsciiDoc
> > format it? Do you see the same breakage?
>
> Kinda. Replacing {tilde} with ~ actually causes asciidoc to fail while
> processing the file; that tilde is 'unmatched' and ends up crossing
> another tag or somesuch.
>
> > - If it breaks, does it fix the breakage if you prefix the "~"
> > with a backslash, instead of using {tilde}?
>
> The escaped tilde works fine.
>
> > If the answer to both questions are "yes", then perhaps we
> > should get rid of the {tilde} macro we define in
> > Documentation/asciidoc.conf file, and use your "\~" solution
> > everywhere.
> >
> > Also do you see any pattern? It does not seem that all the
> > "master~3" are broken for you but only some. If your commit
> > message can describe when quoting is needed, that would help
> > people who would modify the documentation in the future.
>
> I clearly need to read up on Asciidoc formatting directives before I
> could do that with confidence, but I look over it today and see what I
> can do.
Frankly, I don't see any pattern. The git documentation is very fond
of ~ and ^, naturally, and these are inline delimiters in Asciidoc.
Sometimes the places these appear in are unquoted, sometimes
double-quoted, grave-quoted, or single-quoted; any of these can cause
<sub> and <sup> tags in the html output.
I'd suggest that we put all inline revspecs inside $$...$$; this
"inline passthrough" quote obeys outside quoting, and it's what
AsciiMathML uses to avoid fighting reserved characters. Since ~, ^, {,
}, [, ] and more all appear with great frequency in refspecs, this
will save us a lot of escape characters.
There's also a few places where ~ appears in a path name; perhaps we
could put $$...$$ around paths too.
Is there a documentation 'style' file or something like that for git?
Something like that might be useful to help solve this sort of
problem; in addition to unintentional formatting problems like the one
under discussion, there doesn't seem to be a consensus on what sort of
quoting to use for special literal text, like git commands, refspecs,
pathnames, etc. - `, ', and " abound interchangeably.
Jason
P.S. I got smarter about how to find some of these formatting problems
and have found some more 'doc bugs' that I'll put into a patch once
we've decided how to handle this stuff
^ permalink raw reply
* Re: [StGIT RFC] Changing patch@branch syntax
From: Yann Dirson @ 2007-06-24 21:26 UTC (permalink / raw)
To: Catalin Marinas; +Cc: GIT list
In-Reply-To: <b0943d9e0706221529w63a41e82r557179a45b461f61@mail.gmail.com>
On Fri, Jun 22, 2007 at 11:29:14PM +0100, Catalin Marinas wrote:
> On 22/06/07, Yann Dirson <ydirson@altern.org> wrote:
> >On Fri, Jun 22, 2007 at 04:59:05PM +0100, Catalin Marinas wrote:
> >> I also don't think we need to make this distinction in the names as
> >> different commands or options take different type of arguments:
> >>
> >> stg show <patch>
> >> stg series --branch <stack>
> >
> >Currently, "stg show HEAD" or any other git ref does work, except when
> >there are name clashes.
>
> But the argument to 'show' here is either a patch or a git ref (not a
> stack or a pool). It first tries to find a patch and fall back to a
> git ref. You don't specify a stack to 'show'.
Well, currently "stg show <stack>" will just take <stack> as a git
ref, and will show the top commit, which may well be the base commit
of the stack - not very exciting, I agree.
> What might be easier with a complete spec is bash completion. I find
> this mandatory precise description similar to the Hungarian notation.
> Since most of the time I work with push/pop commands, I don't like
> always putting a ":" for every patch
Right, push/pop should only get the local name in the current
patchset, no ":" whatsoever in there. It is not the same for "show",
since we often want to look at patches in other stacks.
> (BTW, what about patch ranges, I don't think they can go across
> multiple stacks).
Right - we probably only want ranges in the rightmost component of a
patchspec.
> >And since we're going to have all of patches, stacks, and pools in the
> >same "stackable" family, we're going to use them interchangeably in
> >more and more places. But there are also places where we can use at
> >will stack names and generic git heads (eg. "stg branch X").
>
> Currently, stack names and git branches are the same. Would this
> change with hydra? I use StGIT to maintain my branches on
> http://www.linux-arm.org/git?p=linux-2.6.git;a=heads and I find the
> stack name == git branch simplification pretty useful.
>
> What commands/options would we have where we need to distinguish
> between stack and patch names?
I have often wondered if it would be useful to have a given
patch@stack as a base for another stack, or maybe as one of the
"heads" of an hydra. Still not sure it would make any sense, however
- especially, proper use of hydras would possibly suppress the need
for the former.
> >I'd rather having a single name-resolution mechanism, instead of one
> >for patches and one for branches.
>
> I don't see why we couldn't have a single name resolution but without
> the mandatory ":". An example (but in reverse order) is internet
> names. I only type "intranet" rather than "intranet." in a browser. To
> fully qualify, I type "intranet.arm.com".
There is a difference, in that in name resolution there is a
well-define algorithm to resolve this, and in that "intranet" alone is
not a valid fully-qualified name. In current StGIT, in cases where
"name" matches both a local patch a git ref... well, we can still ask
for refs/heads/name as fully-qualified name - looks like I had
forgotten that one ;)
Let's try to find a proper solution.
We have on one hand a number of commands (in the patch/stack sets)
that act solely within the patchset, and thus have no need for
referencing stackables outside the current patchset:
new, push, pop, goto, float, sink, clean, uncommit, export,
import, mail, refresh
Similar commands, but which no technical issue restrain from acting on
stackables in other patchsets:
delete, hide, unhide, patches, series, files, log, rename, show
Commands that solely refer to patchsets, not stackables:
applied, unapplied, top, branch, rebase
Commands that need to refer to patches in other patchsets:
pick
Commands that don't care:
assimilate, commit, init, pull, fold
I consider we have a couple of special cases:
clean currently does not care, but see task #5235
rebase currently only needs patchets, do we need to extend that to patches ?
mail currently does not accept --branch or patch@stack but probably could
new creates a patch in the current stack, we may want to unify
this with "branch -c" in some way (maybe "stg
(patch|stack|pool) new" ?)
show is special in that when its arg is not a ref to a patch,
it falls back to git-show. We may want to change
that, to be an stgit-only command.
sync uses non-standard way to refer to the other stack - do we
really need to sync several patches in one command ?
clone is also special, in that it is currently the only one to
have a use for the repo - it could surely be extended
to accept a stackable (eg. "stg clone http://this/repo#pool2:stk1")
To summarize, appart from "show" which does not really need to know
about branches, no current command would have any ambiguity.
A couple of commands in the 1st category will needto be enhanced to be
more useful with pools of stacks (to specify which stack of the pool
to act on), but that does not change the problem, they do not act on
non-stackable git-core branches.
> If it is easier for you, you could create a branch (for-upstream etc.)
> and just send me an email to merge it.
Right. With a bit more work on hydra/pool, I could even tell you to
pull from an pool member ;)
> - concreteCommand, I would write classes with capital first letter
> (unwritten convention in StGIT)
OK
> - why the Repository class definition in stgit/__init__.py? Can it not
> be in a different file?
This is part of the things to clean up. By putting it here I was sure
the class was going to available as stgit.Repository. I'm not fluent
in python yet, I'll have to dig for a better way - that one surely
does not scale at all.
> Also, shourt stgit/git.py be aware of the repository?
I'd rather think that we should have git.Repository (and further
structurate git.py with more objects, like git.Branch), with
stgit-specific stuff in the stgit.Repository subclass.
Best regards,
--
Yann.
^ permalink raw reply
* Re: Darcs
From: Jan Hudec @ 2007-06-24 21:19 UTC (permalink / raw)
To: Martin Langhoff; +Cc: Linus Torvalds, Bu Bacoo, git
In-Reply-To: <46a038f90706241345m4b5ecb80p9f4ec840993023e0@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 2145 bytes --]
On Mon, Jun 25, 2007 at 08:45:57 +1200, Martin Langhoff wrote:
> On 6/25/07, Linus Torvalds <torvalds@linux-foundation.org> wrote:
> >Ahh, a chance to flame! I will never back down from such a challenge!
> >
> >Darcs is .. umm .. ehh..
> >
> >"Academic".
> OTOH, and from the POV of someone closely following the SCM tools in
> the last few years (and using almost all of them), darcs was the first
> usable DSCM in the camp. I am not sure how much of its commandline
> user interface was borrowed from BK or elsewhere, but darcs was
> _easy_, where Arch was extremely hard to use.
Arch is not in fact distributed. One key feature that makes things
distributed is that object (revision in SCM) identity is independent of their
location (repository in SCM). And in Arch that is not true.
Revisions independent of repositories (and branches) is what makes the ad-hoc
branching, that makes git (and hg, bazaar and darcs) so easy, possible. Arch
claimed to have easy branching, but it was still the old explicit model.
(Besides yes, I can confirm that Arch was not the easiest thing to use.)
> The darcs commandset (init, push, pull) is what git, hg and bzr have
> today in common. At least _I_ learned about how it could be easy by
> watching people use Darcs (and feeling very ashamed of my baroque Arch
> usage). The focus on patch tracking (as opposed to "snapshot"
> tracking) and the whole patch algebra are two misfires I'd say.
> Snapshot-tracking DSCMs are winning (faster and fundamentally more
> reliable), and the patch algebra doesn't quite scale and (as far as
> I've heard) sometimes ends in unsolvable corner cases.
IMHO the patch algebra also falls short of it's goal. The idea is supposed to
be that you can cherry-pick easily. However, in practice many changes that
are easy to cherry-pick are textually dependent in something like import
list, list of files in makefile or such. While git cherry-pick will happily
apply such patch and give you a single easy to resolve conflict, darcs will
just insist on pulling the other patch as well.
--
Jan 'Bulb' Hudec <bulb@ucw.cz>
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* [PATCH] git-submodule: provide easy way of adding new submodules
From: Sven Verdoolaege @ 2007-06-24 21:06 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Lars Hjemli
In-Reply-To: <7vir9dtf5z.fsf@assigned-by-dhcp.cox.net>
To make a submodule effectively usable, the path and
a URL where the submodule can be cloned need to be stored
in .gitmodules. This subcommand takes care of setting
this information after cloning the new submodule.
Only the index is updated, so, if needed, the user may still
change the URL or switch to a different branch of the submodule
before committing.
Signed-off-by: Sven Verdoolaege <skimo@kotnet.org>
---
On Sun, Jun 24, 2007 at 10:50:48AM -0700, Junio C Hamano wrote:
> Sven Verdoolaege <skimo@kotnet.org> writes:
>
> > They're different because submodule update (which also calls module_clone)
> > is performed on a module that already exists in the repo and
> > was therefore checked out by git as an empty directory. If you
> > add a new submodule, then there is no reason for the subdirectory
> > to exist already.
>
> Ah, you are absolutely right. Thanks for the clarification.
>
> By the way, when I have to say "thanks for the clarification", I
> think it is an indication that the relevant parts of the code
> need a bit of commenting ;-).
How's this ?
skimo
Documentation/git-submodule.txt | 11 ++++
git-submodule.sh | 102 ++++++++++++++++++++++++++++++++++++--
2 files changed, 107 insertions(+), 6 deletions(-)
diff --git a/Documentation/git-submodule.txt b/Documentation/git-submodule.txt
index f8fb80f..7f0904e 100644
--- a/Documentation/git-submodule.txt
+++ b/Documentation/git-submodule.txt
@@ -8,11 +8,19 @@ git-submodule - Initialize, update or inspect submodules
SYNOPSIS
--------
+'git-submodule' [--quiet] [-b branch] add <repository> [<path>]
'git-submodule' [--quiet] [--cached] [status|init|update] [--] [<path>...]
COMMANDS
--------
+add::
+ Add the given repository as a submodule at the given path
+ to the changeset to be committed next. In particular, the
+ repository is cloned at the specified path, added to the
+ changeset and registered in .gitmodules. If no path is
+ specified, the path is deduced from the repository specification.
+
status::
Show the status of the submodules. This will print the SHA-1 of the
currently checked out commit for each submodule, along with the
@@ -39,6 +47,9 @@ OPTIONS
-q, --quiet::
Only print error messages.
+-b, --branch::
+ Branch of repository to add as submodule.
+
--cached::
Display the SHA-1 stored in the index, not the SHA-1 of the currently
checked out submodule commit. This option is only valid for the
diff --git a/git-submodule.sh b/git-submodule.sh
index 89a3885..67c78f2 100755
--- a/git-submodule.sh
+++ b/git-submodule.sh
@@ -1,13 +1,15 @@
#!/bin/sh
#
-# git-submodules.sh: init, update or list git submodules
+# git-submodules.sh: add, init, update or list git submodules
#
# Copyright (c) 2007 Lars Hjemli
-USAGE='[--quiet] [--cached] [status|init|update] [--] [<path>...]'
+USAGE='[--quiet] [--cached] [add <repo> [-b branch]|status|init|update] [--] [<path>...]'
. git-sh-setup
require_work_tree
+add=
+branch=
init=
update=
status=
@@ -25,6 +27,18 @@ say()
fi
}
+# NEEDSWORK: identical function exists in get_repo_base in clone.sh
+get_repo_base() {
+ (
+ cd "`/bin/pwd`" &&
+ cd "$1" || cd "$1.git" &&
+ {
+ cd .git
+ pwd
+ }
+ ) 2>/dev/null
+}
+
#
# Map submodule path to submodule name
#
@@ -42,6 +56,11 @@ module_name()
#
# Clone a submodule
#
+# Prior to calling, modules_update checks that a possibly existing
+# path is not a git repository.
+# Likewise, module_add checks that path does not exist at all,
+# since it is the location of a new submodule.
+#
module_clone()
{
path=$1
@@ -66,6 +85,53 @@ module_clone()
}
#
+# Add a new submodule to the working tree, .gitmodules and the index
+#
+# $@ = repo [path]
+#
+# optional branch is stored in global branch variable
+#
+module_add()
+{
+ repo=$1
+ path=$2
+
+ if test -z "$repo"; then
+ usage
+ fi
+
+ # Turn the source into an absolute path if
+ # it is local
+ if base=$(get_repo_base "$repo"); then
+ repo="$base"
+ fi
+
+ # Guess path from repo if not specified or strip trailing slashes
+ if test -z "$path"; then
+ path=$(echo "$repo" | sed -e 's|/*$||' -e 's|:*/*\.git$||' -e 's|.*[/:]||g')
+ else
+ path=$(echo "$path" | sed -e 's|/*$||')
+ fi
+
+ test -e "$path" &&
+ die "'$path' already exists"
+
+ git-ls-files --error-unmatch "$path" > /dev/null 2>&1 &&
+ die "'$path' already exists in the index"
+
+ module_clone "$path" "$repo" || exit
+ (unset GIT_DIR && cd "$path" && git checkout -q ${branch:+-b "$branch" "origin/$branch"}) ||
+ die "Unable to checkout submodule '$path'"
+ git add "$path" ||
+ die "Failed to add submodule '$path'"
+
+ GIT_CONFIG=.gitmodules git config submodule."$path".path "$path" &&
+ GIT_CONFIG=.gitmodules git config submodule."$path".url "$repo" &&
+ git add .gitmodules ||
+ die "Failed to register submodule '$path'"
+}
+
+#
# Register submodules in .git/config
#
# $@ = requested paths (default to all)
@@ -173,6 +239,9 @@ modules_list()
while case "$#" in 0) break ;; esac
do
case "$1" in
+ add)
+ add=1
+ ;;
init)
init=1
;;
@@ -185,6 +254,14 @@ do
-q|--quiet)
quiet=1
;;
+ -b|--branch)
+ case "$2" in
+ '')
+ usage
+ ;;
+ esac
+ branch="$2"; shift
+ ;;
--cached)
cached=1
;;
@@ -201,14 +278,27 @@ do
shift
done
-case "$init,$update,$status,$cached" in
-1,,,)
+case "$add,$branch" in
+1,*)
+ ;;
+,)
+ ;;
+,*)
+ usage
+ ;;
+esac
+
+case "$add,$init,$update,$status,$cached" in
+1,,,,)
+ module_add "$@"
+ ;;
+,1,,,)
modules_init "$@"
;;
-,1,,)
+,,1,,)
modules_update "$@"
;;
-,,*,*)
+,,,1,*)
modules_list "$@"
;;
*)
--
1.5.2.2.1064.g59b4
^ permalink raw reply related
* Re: [PATCH] transplant: move a series of commits to a different parent
From: Steffen Prohaska @ 2007-06-24 20:54 UTC (permalink / raw)
To: Alex Riesen; +Cc: git
In-Reply-To: <20070624183552.GA2374@steel.home>
On Jun 24, 2007, at 8:35 PM, Alex Riesen wrote:
> Your script works, just it can be made simplier: no need for diff,
> it'll only hurt perfomance and complicates things. And you don't have
> to care about additions/deletions, and it is trivially extensible to
> support merges, and the current index is untouched - your user can
> continue working in predictable environment.
I understand that I can leave the default index untouched by using
a different index. I knew that this must be possible somehow but was
too lazy to find out how. Thanks for the details.
I don't see how I can avoid tree diffs. As I pointed out earlier I need
to mix the tree of the base commit of the newly built branch with
files that were changed in the series of commits that I'm transplanting.
Just taking the whole tree from the commits I'm transplanting is
_wrong_.
I need to only take files that were touched by a commit. The tree of
the tip of the resulting branch can be quite different from the tree
of the tip of the original branch.
> As to perfomance: read-tree doesn't actually _read_ the blobs to
> populate index, just the trees. And diff-tree has do do the same, but
> also _compare_ two trees recursively: more work, more memory needed.
I'm still pretty convinced that I need tree diffs (not file diffs!).
> BTW, Johannes moved that ident code you copied from git-filter-branch
> into its own shell file, so it can be sourced and trivially reused.
I see, thanks.
Anyway, the script worked for me and I still think it may be useful for
fixing broken repositories resulting from a wrong cvsimport. I would
probably improve many details if someone else considered my work useful.
But up to now it seems as if I failed to explain, why the script would
be needed in the first place.
However, the best way would be to fix git-cvsimport to handle branches
correctly independently of the time of the first commit to a branch;
and avoid insane, broken repositories altogether.
Steffen
^ permalink raw reply
* Re: Darcs
From: Martin Langhoff @ 2007-06-24 20:45 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Bu Bacoo, git
In-Reply-To: <alpine.LFD.0.98.0706241030540.3593@woody.linux-foundation.org>
On 6/25/07, Linus Torvalds <torvalds@linux-foundation.org> wrote:
> Ahh, a chance to flame! I will never back down from such a challenge!
>
> Darcs is .. umm .. ehh..
>
> "Academic".
OTOH, and from the POV of someone closely following the SCM tools in
the last few years (and using almost all of them), darcs was the first
usable DSCM in the camp. I am not sure how much of its commandline
user interface was borrowed from BK or elsewhere, but darcs was
_easy_, where Arch was extremely hard to use.
The darcs commandset (init, push, pull) is what git, hg and bzr have
today in common. At least _I_ learned about how it could be easy by
watching people use Darcs (and feeling very ashamed of my baroque Arch
usage). The focus on patch tracking (as opposed to "snapshot"
tracking) and the whole patch algebra are two misfires I'd say.
Snapshot-tracking DSCMs are winning (faster and fundamentally more
reliable), and the patch algebra doesn't quite scale and (as far as
I've heard) sometimes ends in unsolvable corner cases.
And the closer we get to Darcs UI the happier I feel ;-)
cheers,
martin
^ permalink raw reply
* Re: Stupid quoting...
From: David Kastrup @ 2007-06-24 20:25 UTC (permalink / raw)
To: Robin Rosenberg; +Cc: git
In-Reply-To: <200706242217.48284.robin.rosenberg.lists@dewire.com>
Robin Rosenberg <robin.rosenberg.lists@dewire.com> writes:
> söndag 24 juni 2007 skrev David Kastrup:
>> Robin Rosenberg <robin.rosenberg.lists@dewire.com> writes:
>>
>> > I was still in referernce to those "local conditions" at that
>> > point. It was not meant as a universal statement. Substitutute that
>> > for "A small bunch of swedish speaking people from Stockholm".
>>
>> A wrong encoding is a wrong encoding. Escaping the characters in
>> transition will not magically make the encodings adapt.
>
> Please don't quote me when the content is not in reference to me or what
> I've written.
No idea how that has happened: I actually intended to refer to
something different. Sorry.
--
David Kastrup, Kriemhildstr. 15, 44793 Bochum
^ permalink raw reply
* Re: Stupid quoting...
From: Robin Rosenberg @ 2007-06-24 20:17 UTC (permalink / raw)
To: David Kastrup; +Cc: Jan Hudec, Junio C Hamano, Johannes Schindelin, git
In-Reply-To: <85ejk1cexn.fsf@lola.goethe.zz>
söndag 24 juni 2007 skrev David Kastrup:
> Robin Rosenberg <robin.rosenberg.lists@dewire.com> writes:
>
> > I was still in referernce to those "local conditions" at that
> > point. It was not meant as a universal statement. Substitutute that
> > for "A small bunch of swedish speaking people from Stockholm".
>
> A wrong encoding is a wrong encoding. Escaping the characters in
> transition will not magically make the encodings adapt. Escaping
> characters buys us exactly zilch _unless_ the _channel_ is not 8-bit
> clean. In which case we should use a normal
> mail-armoring/attachment/inline data wrapper.
>
> In fact, when using editors with some heuristics regarding character
> sets (like Emacs), leaving 8-bit characters intact gives the editor a
> chance to guess the correct character set even if it is not the
> default on the receiving end.
>
> Escaping the characters, in contrast, just hides 8-bit usage away in
> transition. An escaped character in the wrong encoding will get
> reconstituted into the wrong encoding.
>
Please don't quote me when the content is not in reference to me or what
I've written.
-- robin
^ permalink raw reply
* Re: Stupid quoting...
From: David Kastrup @ 2007-06-24 19:47 UTC (permalink / raw)
To: Robin Rosenberg; +Cc: Jan Hudec, Junio C Hamano, Johannes Schindelin, git
In-Reply-To: <200706242139.44708.robin.rosenberg.lists@dewire.com>
Robin Rosenberg <robin.rosenberg.lists@dewire.com> writes:
> I was still in referernce to those "local conditions" at that
> point. It was not meant as a universal statement. Substitutute that
> for "A small bunch of swedish speaking people from Stockholm".
A wrong encoding is a wrong encoding. Escaping the characters in
transition will not magically make the encodings adapt. Escaping
characters buys us exactly zilch _unless_ the _channel_ is not 8-bit
clean. In which case we should use a normal
mail-armoring/attachment/inline data wrapper.
In fact, when using editors with some heuristics regarding character
sets (like Emacs), leaving 8-bit characters intact gives the editor a
chance to guess the correct character set even if it is not the
default on the receiving end.
Escaping the characters, in contrast, just hides 8-bit usage away in
transition. An escaped character in the wrong encoding will get
reconstituted into the wrong encoding.
--
David Kastrup, Kriemhildstr. 15, 44793 Bochum
^ permalink raw reply
* Re: [PATCH] Add git-save script
From: Junio C Hamano @ 2007-06-24 19:45 UTC (permalink / raw)
To: Nanako Shiraishi; +Cc: GIT
In-Reply-To: <200706241044.l5OAiMCB012492@mi0.bluebottle.com>
Nanako Shiraishi <nanako3@bluebottle.com> writes:
> Junio C Hamano <gitster@pobox.com> writes:
> ...
>> When you say "#!/bin/sh", you are writing for the family of
>> generic Bourne shells, not specifically for korn nor bash. For
>> example, dash is a fine POSIX shell, but does not grok function
>> noiseword. When in doubt, please stay away from things not in
>> POSIX (e.g. function, [[, ]], ${parameter//pattern/string/}).
>
> Is there a good reference you can point me?
I usually look at this:
http://www.opengroup.org/onlinepubs/000095399/
and click on "Shell and Utilities volume (XCU)", and compare it
with "man bash".
> At first I wanted to do git-add . instead of git-add -u, but then I
> became worried that will add files that are not interesting such as
> temporary files.
As long as .gitignore is set up properly to ignore such
generated files, that shouldn't be a problem.
^ permalink raw reply
* Re: Stupid quoting...
From: Robin Rosenberg @ 2007-06-24 19:39 UTC (permalink / raw)
To: Jan Hudec; +Cc: Junio C Hamano, Johannes Schindelin, David Kastrup, git
In-Reply-To: <20070624162559.GC6979@efreet.light.src>
söndag 24 juni 2007 skrev Jan Hudec:
> On Sun, Jun 24, 2007 at 13:14:45 +0200, Robin Rosenberg wrote:
> > I can't talk about "most" here, only local conditions, i.e. northern
Europe
> > where both the legacy ISO encodings are very common with a steady increase
in
> > UTF-8 usage, in the Linux community. People using OSS in windows almost
> > exclusively get the windows-1252 (for most practical purposes the same as
> > ISO-8859-1).
> >
> > Even a *very* small set of random people you will wind up with people
having
> > different locales.
>
> A small set of *random* people will likely have different locales. But
> a project that would use non-ascii filenames would probably use some
> particular language and thus be run by people that all speak that
language --
> which means they are not random at all and probably will use the same
locale.
I was still in referernce to those "local conditions" at that point. It was
not meant as a universal statement. Substitutute that for "A small bunch of
swedish speaking people from Stockholm".
-- robin
^ permalink raw reply
* [PATCH] detect close failure on just-written file handles
From: Jim Meyering @ 2007-06-24 19:20 UTC (permalink / raw)
To: git
I audited git for potential undetected write failures.
In the cases fixed below, the diagnostics I add mimic the diagnostics
used in surrounding code, even when that means not reporting
the precise strerror(errno) cause of the error.
Signed-off-by: Jim Meyering <jim@meyering.net>
---
builtin-init-db.c | 3 ++-
builtin-rerere.c | 3 ++-
index-pack.c | 3 ++-
refs.c | 6 ++----
4 files changed, 8 insertions(+), 7 deletions(-)
diff --git a/builtin-init-db.c b/builtin-init-db.c
index 0be2d2e..976f47b 100644
--- a/builtin-init-db.c
+++ b/builtin-init-db.c
@@ -40,7 +40,8 @@ static int copy_file(const char *dst, const char *src, int mode)
return fdo;
}
status = copy_fd(fdi, fdo);
- close(fdo);
+ if (close(fdo) != 0)
+ return error("%s: write error: %s", dst, strerror(errno));
if (!status && adjust_shared_perm(dst))
return -1;
diff --git a/builtin-rerere.c b/builtin-rerere.c
index f6409b9..29fb075 100644
--- a/builtin-rerere.c
+++ b/builtin-rerere.c
@@ -57,7 +57,8 @@ static int write_rr(struct path_list *rr, int out_fd)
write_in_full(out_fd, path, length) != length)
die("unable to write rerere record");
}
- close(out_fd);
+ if (close(out_fd) != 0)
+ die("unable to write rerere record");
return commit_lock_file(&write_lock);
}
diff --git a/index-pack.c b/index-pack.c
index 82c8da3..8403c36 100644
--- a/index-pack.c
+++ b/index-pack.c
@@ -634,7 +634,8 @@ static void final(const char *final_pack_name, const char *curr_pack_name,
write_or_die(keep_fd, keep_msg, keep_msg_len);
write_or_die(keep_fd, "\n", 1);
}
- close(keep_fd);
+ if (close(keep_fd) != 0)
+ die("cannot write keep file");
report = "keep";
}
}
diff --git a/refs.c b/refs.c
index 67ac97c..4dc7e8b 100644
--- a/refs.c
+++ b/refs.c
@@ -1106,8 +1106,7 @@ static int log_ref_write(const char *ref_name, const unsigned char *old_sha1,
len += sprintf(logrec + len - 1, "\t%.*s\n", msglen, msg) - 1;
written = len <= maxlen ? write_in_full(logfd, logrec, len) : -1;
free(logrec);
- close(logfd);
- if (written != len)
+ if (close(logfd) != 0 || written != len)
return error("Unable to append to %s", log_file);
return 0;
}
@@ -1204,8 +1203,7 @@ int create_symref(const char *ref_target, const char *refs_heads_master,
goto error_free_return;
}
written = write_in_full(fd, ref, len);
- close(fd);
- if (written != len) {
+ if (close(fd) != 0 || written != len) {
error("Unable to write to %s", lockpath);
goto error_unlink_return;
}
^ permalink raw reply related
* Re: (resend) [PATCH] Don't ignore write failure from git-diff, git-log, etc.
From: Jim Meyering @ 2007-06-24 19:13 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Junio C Hamano, git
In-Reply-To: <alpine.LFD.0.98.0706240951440.3593@woody.linux-foundation.org>
Linus Torvalds <torvalds@linux-foundation.org> wrote:
...
> I also don't think it's very _pretty_ code, and it violates my personal
> coding standards by adding way too deep indentation for the new error
> cases. It was already three indents deep (reasonably fine, but that
> NOT_BARE test wass already pretty ugly), but now it becomes five
> indentation levels deep at its deepest, which is just a sign that things
> should be split up.
I too disliked the form of my patch, and said so.
> I'd also like to know why it does that fcntl() is done,
In the quoted message, I explained that stdout was already
closed in some cases. The fcntl test avoids the EINVAL you'd
get for closing an already-closed file descriptor.
^ permalink raw reply
* [PATCH] Don't ignore a low-probability ref-pack write failure
From: Jim Meyering @ 2007-06-24 19:13 UTC (permalink / raw)
To: git
Without this, if the size of refs_file at that point is ever an exact
multiple of BUFSIZ, then an EIO or ENOSPC error on the final write would
not be diagnosed.
It's not worth worrying about EPIPE here.
Although theoretically possible that someone kill this process
with a manual SIGPIPE, it's not at all likely.
Signed-off-by: Jim Meyering <jim@meyering.net>
---
builtin-pack-refs.c | 2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/builtin-pack-refs.c b/builtin-pack-refs.c
index 1952950..7584992 100644
--- a/builtin-pack-refs.c
+++ b/builtin-pack-refs.c
@@ -105,6 +105,8 @@ static int pack_refs(unsigned int flags)
fprintf(cbdata.refs_file, "# pack-refs with: peeled \n");
for_each_ref(handle_one_ref, &cbdata);
+ if (ferror(cbdata.refs_file))
+ die("failed to write ref-pack file");
if (fflush(cbdata.refs_file) || fsync(fd) || fclose(cbdata.refs_file))
die("failed to write ref-pack file (%s)", strerror(errno));
if (commit_lock_file(&packed) < 0)
^ permalink raw reply related
* Re: [PATCH] transplant: move a series of commits to a different parent
From: Alex Riesen @ 2007-06-24 18:35 UTC (permalink / raw)
To: Steffen Prohaska; +Cc: git
In-Reply-To: <EA80EB51-97F9-4C5F-BEF7-C8C1BF39B8D2@zib.de>
Steffen Prohaska, Sun, Jun 24, 2007 19:13:42 +0200:
> >>I am changing the repository.
> >
> >No, you don't.
>
> Magically, the script solved my problem by creating a new, corrected
> branch that is different from the original one. I didn't run any
> other script. I promise, I ran the script that I sent in the patch.
I meant: "it does not change the working directory". It is irrelevant,
was a bit of confusion on my part.
Your script works, just it can be made simplier: no need for diff,
it'll only hurt perfomance and complicates things. And you don't have
to care about additions/deletions, and it is trivially extensible to
support merges, and the current index is untouched - your user can
continue working in predictable environment.
As to perfomance: read-tree doesn't actually _read_ the blobs to
populate index, just the trees. And diff-tree has do do the same, but
also _compare_ two trees recursively: more work, more memory needed.
BTW, Johannes moved that ident code you copied from git-filter-branch
into its own shell file, so it can be sourced and trivially reused.
^ permalink raw reply
* Re: Darcs
From: Linus Torvalds @ 2007-06-24 17:59 UTC (permalink / raw)
To: Bu Bacoo; +Cc: git
In-Reply-To: <cecbdd220706232232w77a609faxf0e6b2dc37f0d1f4@mail.gmail.com>
On Sun, 24 Jun 2007, Bu Bacoo wrote:
>
> What do you think about darcs?
>
> There was a lot written/spoken about morons and stupidos around
> thinking in cvs / svn, etc... (what would be the words for dudes
> around vss ....).
Ahh, a chance to flame! I will never back down from such a challenge!
Darcs is .. umm .. ehh..
"Academic".
Ok, I realize that's a pretty weak flame, and I'm sorry. It's not that
darcs users are "stupid" or "complete morons" or "donkey turds with arms
and legs", it's just that the whole project is centered around some
academic ideas that have absolutely no relevance in real life, and that
just don't work in practice.
In other words, it's a fun project, but it's largely irrelevant. The whole
underpinning of darcs ("everything is a collection of patches" and the
"patch algebra") is kind of interesting, but it's irrelevant. The thing it
solves is not the thing you want solved, and you really don't want to
handle conflicts at a "patch" level.
I personally think darcs is closer to a smart "quilt" than a "final" SCM.
It's good for keeping track of patches, but let's face it, if you have
really big changes, you don't want to handle them the way darcs does.
And in that sense, I do think the two approaches can _complement_ each
other. A lot of people use quilt (or quite often, something similar, based
on a SCM in the background: git has and stgit and guilt, hg has "mercurial
queues"). And it's absolutely true that you want to have a "fluid" level
too, and darcs can do that.
But you do *not* want to do the whole project history that way. At some
point, you need something that works at another level than patch queues.
Darcs itself kind of has something like this with "checkpointing", but the
fact is, git is just better at this.
So it basically boils down to the fact that I don't think darcs solves the
real problems, and won't scale up. It's versioning model seems *totally*
broken, for example.
Fundmantal example: somebody has a problem/bug. Tell me how to tell a
developer what his exact version is - without creating new tags, and
without having to synchronize the archives. Just tell the developer what
version he is at.
In git, you just give a revision number. In darcs, what the *hell* do you
do? And that's a pretty damn fundamental operation for a source control
management setup! As far as I know, darcs only has patch identities.
Linus
^ permalink raw reply
* Re: [PATCH][RESEND] git-submodule: provide easy way of adding new submodules
From: Junio C Hamano @ 2007-06-24 17:50 UTC (permalink / raw)
To: skimo; +Cc: git, Lars Hjemli
In-Reply-To: <20070624151750.GA997MdfPADPa@greensroom.kotnet.org>
Sven Verdoolaege <skimo@kotnet.org> writes:
> They're different because submodule update (which also calls module_clone)
> is performed on a module that already exists in the repo and
> was therefore checked out by git as an empty directory. If you
> add a new submodule, then there is no reason for the subdirectory
> to exist already.
Ah, you are absolutely right. Thanks for the clarification.
By the way, when I have to say "thanks for the clarification", I
think it is an indication that the relevant parts of the code
need a bit of commenting ;-).
^ permalink raw reply
* Re: [PATCH][RESEND] Escape some tilde characters causing spurious subscripts in documentation
From: Jason Sewall @ 2007-06-24 17:31 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Johannes Schindelin, git
In-Reply-To: <7vbqf5wtrb.fsf@assigned-by-dhcp.cox.net>
On 6/24/07, Junio C Hamano <gitster@pobox.com> wrote:
> "Jason Sewall" <jasonsewall@gmail.com> writes:
>
> > On 6/23/07, Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
> >
> >> I just checked with my copy of asciidoc, though, and there is no mangling
> >> going on, at least in git-bundle.html (which is the only file I checked).
> >> My asciidoc is version 8.2.1. What is yours?
> >
> > I've got 8.1.0; perhaps that's the problem. I wasn't so surprised to
> > hear the asciidoc 7 and 8 don't get along, but I'm surprised to see
> > that 8.1 and 8.2 are so different.
> >
> > Anyway, 8.1.0 is apparently what's in Fedora 7 (the distro I'm using
> > right now) so it might be worth hanging on to the patch.
>
> FWIW, 7.1.2, 8.2.1 and 7.0.2 all seem to be Ok (the last one is
> used to format the pages in html and man branches of git.git).
> It is a bit annoying having to use name\~num at some places and
> no backslash all others.
>
> Two requests:
>
> - Documentation/git-rev-parse.txt has '{tilde}<n>'. If you
> replace that {tilde} with a "~", how does your AsciiDoc
> format it? Do you see the same breakage?
Kinda. Replacing {tilde} with ~ actually causes asciidoc to fail while
processing the file; that tilde is 'unmatched' and ends up crossing
another tag or somesuch.
> - If it breaks, does it fix the breakage if you prefix the "~"
> with a backslash, instead of using {tilde}?
The escaped tilde works fine.
> If the answer to both questions are "yes", then perhaps we
> should get rid of the {tilde} macro we define in
> Documentation/asciidoc.conf file, and use your "\~" solution
> everywhere.
>
> Also do you see any pattern? It does not seem that all the
> "master~3" are broken for you but only some. If your commit
> message can describe when quoting is needed, that would help
> people who would modify the documentation in the future.
I clearly need to read up on Asciidoc formatting directives before I
could do that with confidence, but I look over it today and see what I
can do.
Jason
^ permalink raw reply
* [PATCH 2/2] Check for IO errors after running a command
From: Linus Torvalds @ 2007-06-24 17:29 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Jim Meyering, git
In-Reply-To: <alpine.LFD.0.98.0706240951440.3593@woody.linux-foundation.org>
This is trying to implement the strict IO error checks that Jim Meyering
suggested, but explicitly limits it to just regular files. If a pipe gets
closed on us, we shouldn't complain about it.
[ Side note: feel free to change the S_ISREG() to a !S_ISFIFO(). That
would allow easier testing with /dev/full, which tends to be a character
special device. That said, I think sockets and pipes are generally
interchangeable, which is why I limited it to just regular files. ]
If the subcommand already returned an error, that takes precedence (and we
assume that the subcommand already printed out any relevant messages
relating to it)
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
---
Hmm? I'm not saying this is the only way to do this, but I think this is
at least likely to be obviously just an improvement, and it leaves room
for further tweaking of the logic if Jim or others find other cases that
should be handled.
Side note: I think I made a mistake in making the run_command() a NORETURN
function and putting the exit() into it. It's probably better to instead
just make it return "int", and make the caller do
exit(run_command(...));
and that makes it much prettier to have "run_command()" just return early
if an error happens (or doesn't happen).
For example, then we could just do
status = p->fn(...);
if (status)
return status;
/* Somebody closed stdout? */
if (fstat(fileno(stdout), &st))
return 0;
/* Ignore write errors for pipes and sockets.. */
if (S_ISFIFO(st.st_mode) || S_ISSOCK(st.st_mode))
return 0;
which makes it easy to explain what's going on, and avoids having any deep
indentation at all.
I dunno. This passes all the tests, but it's not like we currently test
for ENOSPC/EIO anyway, or even can do that. If we _just_ disable the thing
for pipes/sockets, we could add a test using /dev/full.
I did check that changing it to !S_ISFIFO() gets the right behaviour, and
"git log | head" doesn't complain, while "git log > /dev/full" does. So
this has gotten some very rudimentary testing, but not in the exact form
I'm actually sending it out.
git.c | 15 ++++++++++++++-
1 files changed, 14 insertions(+), 1 deletions(-)
diff --git a/git.c b/git.c
index 6c728e4..db0118a 100644
--- a/git.c
+++ b/git.c
@@ -224,6 +224,8 @@ struct cmd_struct {
static NORETURN void run_command(struct cmd_struct *p, int argc, const char **argv)
{
+ int status;
+ struct stat st;
const char *prefix;
prefix = NULL;
@@ -237,7 +239,18 @@ static NORETURN void run_command(struct cmd_struct *p, int argc, const char **ar
}
trace_argv_printf(argv, argc, "trace: built-in: git");
- exit(p->fn(argc, argv, prefix));
+ status = p->fn(argc, argv, prefix);
+ if (status)
+ exit(status);
+
+ /* Check for ENOSPC and EIO errors.. */
+ if (!fstat(fileno(stdout), &st) && S_ISREG(st.st_mode)) {
+ if (ferror(stdout))
+ die("write failure on standard output");
+ if (fflush(stdout) || fclose(stdout))
+ die("write failure on standard output: %s", strerror(errno));
+ }
+ exit(0);
}
static void handle_internal_command(int argc, const char **argv)
^ permalink raw reply related
* Re: [PATCH] git-svnimport: added explicit merge graph option -G
From: Steven Grimm @ 2007-06-24 17:27 UTC (permalink / raw)
To: Stas Maximov, git, Junio C Hamano
In-Reply-To: <20070624084427.GA7715@xp.machine.xx>
Peter Baumann wrote:
> Sure, you have to transform the native revision specifieres into
> the GIT commit id's if you only have e.g. "merged r4711:4720 into trunk",
>
IMO the major point of this patch is precisely to *avoid* having to do
that transformation. If you're already going to the trouble of
converting svn identifiers into git identifiers, then you don't need
another tool; you just stick the IDs in the grafts file and you're done.
I agree that this functionality is useful in general, though.
-Steve
^ permalink raw reply
* Re: [PATCH] transplant: move a series of commits to a different parent
From: Steffen Prohaska @ 2007-06-24 17:13 UTC (permalink / raw)
To: Alex Riesen; +Cc: git
In-Reply-To: <20070624093017.GC2467@steel.home>
On Jun 24, 2007, at 11:30 AM, Alex Riesen wrote:
>> I am changing the repository.
>>
>
> No, you don't.
Magically, the script solved my problem by creating a new, corrected
branch that is different from the original one. I didn't run any
other script. I promise, I ran the script that I sent in the patch.
>> I only modify the index for files that have changes in $commit. Their
>> content gets replaced by the content from the commit. I'm leaving
>> all other files untouched.
>
> No, you don't modify anything. Ever tried to run git-status after your
> script finished?
Yes.
> Tried to understand what the output means?
Not really. I instead reset the index to a controlled state.
Steffen
^ permalink raw reply
* [PATCH 1/2] Clean up internal command handling
From: Linus Torvalds @ 2007-06-24 17:10 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Jim Meyering, git
In-Reply-To: <alpine.LFD.0.98.0706240951440.3593@woody.linux-foundation.org>
This should change no code at all, it just moves the definition of "struct
cmd_struct" out, and then splits out the running of the right command into
the "run_command()" function.
It also removes the long-unused 'envp' pointer passing.
This is just preparation for adding some more error checking.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
---
git.c | 52 ++++++++++++++++++++++++++++++----------------------
1 files changed, 30 insertions(+), 22 deletions(-)
diff --git a/git.c b/git.c
index 29b55a1..6c728e4 100644
--- a/git.c
+++ b/git.c
@@ -216,14 +216,34 @@ const char git_version_string[] = GIT_VERSION;
*/
#define NOT_BARE (1<<2)
-static void handle_internal_command(int argc, const char **argv, char **envp)
+struct cmd_struct {
+ const char *cmd;
+ int (*fn)(int, const char **, const char *);
+ int option;
+};
+
+static NORETURN void run_command(struct cmd_struct *p, int argc, const char **argv)
+{
+ const char *prefix;
+
+ prefix = NULL;
+ if (p->option & RUN_SETUP)
+ prefix = setup_git_directory();
+ if (p->option & USE_PAGER)
+ setup_pager();
+ if (p->option & NOT_BARE) {
+ if (is_bare_repository() || is_inside_git_dir())
+ die("%s must be run in a work tree", p->cmd);
+ }
+ trace_argv_printf(argv, argc, "trace: built-in: git");
+
+ exit(p->fn(argc, argv, prefix));
+}
+
+static void handle_internal_command(int argc, const char **argv)
{
const char *cmd = argv[0];
- static struct cmd_struct {
- const char *cmd;
- int (*fn)(int, const char **, const char *);
- int option;
- } commands[] = {
+ static struct cmd_struct commands[] = {
{ "add", cmd_add, RUN_SETUP | NOT_BARE },
{ "annotate", cmd_annotate, RUN_SETUP | USE_PAGER },
{ "apply", cmd_apply },
@@ -307,25 +327,13 @@ static void handle_internal_command(int argc, const char **argv, char **envp)
for (i = 0; i < ARRAY_SIZE(commands); i++) {
struct cmd_struct *p = commands+i;
- const char *prefix;
if (strcmp(p->cmd, cmd))
continue;
-
- prefix = NULL;
- if (p->option & RUN_SETUP)
- prefix = setup_git_directory();
- if (p->option & USE_PAGER)
- setup_pager();
- if ((p->option & NOT_BARE) &&
- (is_bare_repository() || is_inside_git_dir()))
- die("%s must be run in a work tree", cmd);
- trace_argv_printf(argv, argc, "trace: built-in: git");
-
- exit(p->fn(argc, argv, prefix));
+ run_command(p, argc, argv);
}
}
-int main(int argc, const char **argv, char **envp)
+int main(int argc, const char **argv)
{
const char *cmd = argv[0] ? argv[0] : "git-help";
char *slash = strrchr(cmd, '/');
@@ -358,7 +366,7 @@ int main(int argc, const char **argv, char **envp)
if (!prefixcmp(cmd, "git-")) {
cmd += 4;
argv[0] = cmd;
- handle_internal_command(argc, argv, envp);
+ handle_internal_command(argc, argv);
die("cannot handle %s internally", cmd);
}
@@ -390,7 +398,7 @@ int main(int argc, const char **argv, char **envp)
while (1) {
/* See if it's an internal command */
- handle_internal_command(argc, argv, envp);
+ handle_internal_command(argc, argv);
/* .. then try the external ones */
execv_git_cmd(argv);
^ permalink raw reply related
* Re: (resend) [PATCH] Don't ignore write failure from git-diff, git-log, etc.
From: Linus Torvalds @ 2007-06-24 17:08 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Jim Meyering, git
In-Reply-To: <7vzm2pwws8.fsf@assigned-by-dhcp.cox.net>
On Sun, 24 Jun 2007, Junio C Hamano wrote:
>
> I still do not like the fact that this patch makes an error from
> the final stdout flushing override the return value from p->fn()
> even when the function already diagnosed an error
Yeah.
I also don't think it's very _pretty_ code, and it violates my personal
coding standards by adding way too deep indentation for the new error
cases. It was already three indents deep (reasonably fine, but that
NOT_BARE test wass already pretty ugly), but now it becomes five
indentation levels deep at its deepest, which is just a sign that things
should be split up.
I'd also like to know why it does that fcntl() is done, and I also wonder
about that "ferror()" call: it is entirely possible that ferror() is set
due to EPIPE, and in that case, it will *not* set errno to EPIPE at all,
so it will *still* complain about what I consider an invalid situation.
I dunno. I think the ENOSPC worry is a very real and valid one, but I
would really tend prefer something different.
How about this following series of two patches instead, which I'll send as
replies to this email..
Linus
^ permalink raw reply
* Re: Stupid quoting...
From: Jan Hudec @ 2007-06-24 16:25 UTC (permalink / raw)
To: Robin Rosenberg; +Cc: Junio C Hamano, Johannes Schindelin, David Kastrup, git
In-Reply-To: <200706241314.46238.robin.rosenberg.lists@dewire.com>
[-- Attachment #1: Type: text/plain, Size: 1547 bytes --]
On Sun, Jun 24, 2007 at 13:14:45 +0200, Robin Rosenberg wrote:
> söndag 24 juni 2007 skrev Jan Hudec:
> > IMHO it should be the default even for email format. Most projects that use
> > non-ascii filenames probably have all members using same locale. And for
> > such group, it will just work. Also usually the file names, content and
> > commit messages will usually be in the same (though project-specific)
> > encoding, so if charset in content-type is set to that, people with
> different
> > locale able to represent the same characters will still see the names
> > correctly. For other people, the MUA will probably print some escape anyway
> > (it will not screw up the terminal -- it usually knows what it can safely
> > pass to it).
>
> I can't talk about "most" here, only local conditions, i.e. northern Europe
> where both the legacy ISO encodings are very common with a steady increase in
> UTF-8 usage, in the Linux community. People using OSS in windows almost
> exclusively get the windows-1252 (for most practical purposes the same as
> ISO-8859-1).
>
> Even a *very* small set of random people you will wind up with people having
> different locales.
A small set of *random* people will likely have different locales. But
a project that would use non-ascii filenames would probably use some
particular language and thus be run by people that all speak that language --
which means they are not random at all and probably will use the same locale.
--
Jan 'Bulb' Hudec <bulb@ucw.cz>
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* cloning empty repo
From: Marijn Schouten (hkBst) @ 2007-06-24 15:04 UTC (permalink / raw)
To: git
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Hi list,
is there any reason why cloning an empty repository should result in an error
instead of a succesfully cloned empty repo?
Marijn
PS Please CC me
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.4 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFGfogIp/VmCx0OL2wRAnYXAJ9cJAO4WsQihr6iEsEIawA9cpycQACglI8G
lofEKfuidJ1OOv12A9QPK8w=
=p344
-----END PGP SIGNATURE-----
^ 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