* Re: [PATCH Cogito] Fix README asciidoc formatting
From: Petr Baudis @ 2005-10-11 21:43 UTC (permalink / raw)
To: Jonas Fonseca; +Cc: git
In-Reply-To: <20051002105601.GB9934@diku.dk>
Dear diary, on Sun, Oct 02, 2005 at 12:56:01PM CEST, I got a letter
where Jonas Fonseca <fonseca@diku.dk> told me that...
> BTW, what about adding some notatation info for those boxes? It looks
> very creative for an introduction document.
What do you mean by "notation info"?
> commit ca52918a9a6e02e55d878d8f5e68672432940337
> tree 60d270e8b45beeee9361b13284ff2eefec746fd6
> parent 9356837de630644323c800e2accad2618d7393f9
> author Jonas Fonseca <fonseca@diku.dk> Sun, 02 Oct 2005 12:45:03 +0200
> committer Jonas Fonseca <fonseca@antimatter.(none)> Sun, 02 Oct 2005 12:45:03 +0200
>
> README | 5 +++++
> 1 files changed, 5 insertions(+), 0 deletions(-)
>
> diff --git a/README b/README
> --- a/README
> +++ b/README
> @@ -305,11 +305,13 @@ will `cg-clone` do?
>
> +--------+
> +--------+
> +
> First it creates an empty repository
>
> +--------+
> $ origin<
> +--------+
> +
> Then it creates an 'origin' head, and will copy all the history from the
> remote repository's 'master' head there. So this head exists to reflect
> the state of the remote repository. The important point is that it is
..snip..
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
VI has two modes: the one in which it beeps and the one in which
it doesn't.
^ permalink raw reply
* Re: How to restore the original head after `git-reset --hard master^`
From: Junio C Hamano @ 2005-10-11 21:37 UTC (permalink / raw)
To: Ben Lau; +Cc: git
In-Reply-To: <434BD65A.9000108@ust.hk>
Ben Lau <benlau@ust.hk> writes:
> After involves the command `git-reset --hard master^` in a
> repository, the working
> tree , current head and index are restored to the parent of master. That
> includes
> the content of '.git/refs/head/master'. Although the original commit
> object is still existed
> , I couldn't find it back.
I think you can find it in .git/ORIG_HEAD.
^ permalink raw reply
* Re: [PATCH] Try URI quoting for embedded TAB and LF in pathnames
From: Linus Torvalds @ 2005-10-11 20:56 UTC (permalink / raw)
To: Paul Eggert
Cc: Junio C Hamano, Robert Fitzsimons, Alex Riesen, git, Kai Ruemmler
In-Reply-To: <87slv7zvqj.fsf@penguin.cs.ucla.edu>
On Tue, 11 Oct 2005, Paul Eggert wrote:
>
> Yes, quite true. But we don't have to come up with something that's
> perfect in all cases, just something that's good enough to handle
> cases that we expect will be common in practice, in a world where
> UTF-8 is the preferred encoding for non-ASCII characters.
The thing is, I can almost guarantee you that any quoting in the high
characters is going to be _worse_ than no quoting at all.
Exactly because quoting as UTF-8 is the wrong thing when it isn't actually
UTF-8, and quoting as non-UTF-8 is the wrong thing when it _is_.
Not quoting at all, on the other hand, is unambigious. If you have a
mailer that corrupts your text stream (which-ever type it is), then it's
clearly the mailers problem. The _mailer_ at least has a chance in hell to
know what character set it is getting mailed as.
The other alternative is to quote _everything_ non-ASCII. That's
definitely reliable, but it's also unquestionably ugly as hell, especially
in the long run.
Yes, there are some complex quoting approaches you can do, which quote
things "correctly" (ie at a byte stream level) _and_ keep it valid UTF-8
at the same time.
For example, you can read it as a UTF-8 stream, but then quote things at a
byte level (ie if you quote one "character", you quote _all_ bytes in that
character). And you quote if:
- the UTF-8 _character_ is in the 0x80-0x9f control range
- any _raw_byte_ is in the 0x80-0x9f range (it might not be UTF-8)
- any _raw_byte_ is 0xfe-0xff (illegal UTF-8 character)
- misformed UTF-8 (non-shortest sequence, or just generally invalid
sequences with missing or wrong high bits)
but quite frankly, that's a pretty painful thing to write. The upside is
that it's easy to decode: you can _unquote_ it just as a byte stream.
Linus
^ permalink raw reply
* Re: [RFC] Cleaning up die() error messages
From: H. Peter Anvin @ 2005-10-11 20:50 UTC (permalink / raw)
To: Matthias Urlichs; +Cc: git
In-Reply-To: <pan.2005.10.11.19.48.04.675482@smurf.noris.de>
Matthias Urlichs wrote:
>
> IMHO, common library code should not be allowed to die.
> (Yes, that does imply replacing all the xmalloc() calls.)
>
The sane way to do this is probably to call an overridable git_die()
function, which can be specified by the user to use longjmp(), to use
exceptions, or do something else appropriately.
However, a much bigger problem is cleanup.
-hpa
^ permalink raw reply
* Re: [PATCH] git-fetch --tags: deal with tags with spaces in them.
From: Matthias Urlichs @ 2005-10-11 19:55 UTC (permalink / raw)
To: git
In-Reply-To: <7virw4zlod.fsf_-_@assigned-by-dhcp.cox.net>
Hi, Junio C Hamano wrote:
> I cheated by creating a small repository
> with funky tag names locally while testing.
Your patch is missing the file "t/t5410-send-funky-names.sh".
;-)
--
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
- -
Being generous is inborn; being altruistic is a learned perversity. No
resemblance ...
-- Lazarus Long
^ permalink raw reply
* Re: [PATCH] Adapt tutorial to cygwin and add test case
From: Junio C Hamano @ 2005-10-11 19:57 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git
In-Reply-To: <Pine.LNX.4.63.0510111333160.27109@wbgn013.biozentrum.uni-wuerzburg.de>
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> -And this is where we start using the `.git/HEAD` file. The `HEAD` file is
> +And this is where we create the `.git/refs/heads/master` file. This file is
> supposed to contain the reference to the top-of-tree, and since that's
> exactly what `git-commit-tree` spits out, we can do this all with a simple
> shell pipeline:
>
> ------------------------------------------------
> -echo "Initial commit" | git-commit-tree $(git-write-tree) > .git/HEAD
> +echo "Initial commit" | \
> + git-commit-tree $(git-write-tree) > .git/refs/heads/master
> ------------------------------------------------
Hmm. This is not wrong, but does not feel right. The point we
are explaining here is that there is a HEAD pointer that knows
about the current branch, and after making a commit, we update
it to record the new tip of the branch.
The Kosher way would be
tree=$(git-write-tree)
commit=$(echo 'Initial commit' | git-commit-tree $tree)
git-update-ref HEAD $(commit)
but looks quite intimidating as a tutorial material.
> @@ -691,7 +695,9 @@ other point in the history than the curr
> just telling `git checkout` what the base of the checkout would be.
> In other words, if you have an earlier tag or branch, you'd just do
>
> - git checkout -b mybranch earlier-commit
> +------------
> +git checkout -b mybranch earlier-commit
> +------------
The original was both ugly and did not use boxquote. There is
no excuse for ugliness, but not using boxquote was for a
reason. The boxquoted "type this" examples were not to be
missed, lest the later steps we explain would either not work or
would produce results that is different from what we show. This
particular step is "if you were doing something different, you
would do this", implying "but do not do that here if you are
following the tutorial steps because that is not what we are
doing here". Maybe we should use boxquote but make an explicit
comment that this is a tangent here?
> @@ -699,17 +705,29 @@ and check out the state at that time.
>
> You can always just jump back to your original `master` branch by doing
>
> - git checkout master
> +------------
> +git checkout master
> +------------
Same here.
> @@ -870,8 +889,10 @@ Now, let's pretend you are the one who d
> to the `master` branch. Let's go back to `mybranch`, and run
> resolve to get the "upstream changes" back to your branch.
>
> - git checkout mybranch
> - git resolve HEAD master "Merge upstream changes."
> +------------
> +git checkout mybranch
> +git resolve HEAD master "Merge upstream changes."
> +------------
But not here.
> diff --git a/t/t1200-tutorial.sh b/t/t1200-tutorial.sh
> new file mode 100644
> index 0000000..35db799
This is an extremely good addition, thanks.
^ permalink raw reply
* Re: [PATCH] Use git-update-ref and git-symbolic-ref in tests
From: Junio C Hamano @ 2005-10-11 19:57 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git, junkio
In-Reply-To: <Pine.LNX.4.63.0510111601460.27536@wbgn013.biozentrum.uni-wuerzburg.de>
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> This makes all tests pass on cygwin.
Thanks. Forgot about these tests.
^ permalink raw reply
* Re: [RFC] Cleaning up die() error messages
From: Matthias Urlichs @ 2005-10-11 19:48 UTC (permalink / raw)
To: git
In-Reply-To: <7vzmph42j2.fsf@assigned-by-dhcp.cox.net>
Hi, Junio C Hamano wrote:
> One thing to keep in mind is how badly this C part might
> interact with the libification effort going on underwater.
Not too badly.
> Since current code Smurf is working on is based on 0.99.6 and
I've merged it up once already; will do that again soon.
> many small pieces need to be reviewed anyway, I am not so much
> worried about forward porting the changes.
I've also mostly succeeded in keeping the individual patches clean so that
everything still builds (and verifies), so it might be easiest to just
merge with it. ;-)
But we'll cross that bridge when we get to it.
> But some die()s that
> are in the parts that will be moved to the common library code
> would also want to use this prog global somehow.
IMHO, common library code should not be allowed to die.
(Yes, that does imply replacing all the xmalloc() calls.)
My library effort has a buffer for the (first) error message. The
caller can elect to suppress printing it, so that it can be formatted
appropriately. Python, for instance, will wrap errors in an exception.
The way I structured it so far, a C program would do
git_env = git_env_new();
die_if_null(git_env());
git_env->print_error = 0;
[...]
git_whatever(git_env, ...);
if (git_env->error) {
fprintf(stderr, "%s: doing whatever: %s\n",
my_program_name, git_env->error);
git_env_clear_error(git_env);
goto whatever_bad_so_go_clean_up;
}
--
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
- -
A hundred mouths, a hundred tongues, And throats of brass, inspired with
iron lungs.
-- Virgil
^ permalink raw reply
* Re: [PATCH] Try URI quoting for embedded TAB and LF in pathnames
From: Paul Eggert @ 2005-10-11 19:42 UTC (permalink / raw)
To: Linus Torvalds
Cc: Junio C Hamano, Robert Fitzsimons, Alex Riesen, git, Kai Ruemmler
In-Reply-To: <Pine.LNX.4.64.0510111121030.14597@g5.osdl.org>
Linus Torvalds <torvalds@osdl.org> writes:
> the simplest question to ask is "what are we protecting against?"
I'd like to protect against:
1. File names that cannot be handled correctly with the current
formats. Newline is the obvious problem here, along with
(arguably) tab and space.
2. Common transliterations of patches. Many programs (and mailers,
alas) expand tabs to spaces, append CR to lines, prepend spaces
to lines, break lines at spaces, etc. 'patch' already deals
with this to some extent, but it'd be nice if the format
resisted these transliterations better.
3. Humans misreading patches. The patch format is intended to be
human-readable, after all.
4. Reencoded patches. Programs like Emacs can and will convert
patches from UTF-8 to EUC-JP, for example.
You convinced me that (4) is not worth the hassle, but I'd still like
to address (1)-(3) when it's easy.
> invalid UTF-8 [is] invalid UTF-8
Yes, but (2) and (3) can lose information about invalid UTF-8 if we
don't suitably protect the encoding errors. I daresay that many
mailers will mishandle invalid UTF-8, for example.
> There _is_ something you may want to quote, namely the standard CSI
> terminal escapes.
If I understand you aright, we could do that by modifying my previous
proposal to escape all bytes in the UTF-8 representation of a control
character. In Unicode, the characters 0080 through 009F are control
characters, so that should suffice to quote the terminal escapes you
mentioned. (Perhaps we should also escape unassigned Unicode
characters too, on the theory that they might become control
characters in the future.)
> For any UTF-8 quoting scheme you come up with, I'll point out
> something that it does wrong or looks horrible for a Latin1 filename
> ;)
Yes, quite true. But we don't have to come up with something that's
perfect in all cases, just something that's good enough to handle
cases that we expect will be common in practice, in a world where
UTF-8 is the preferred encoding for non-ASCII characters.
^ permalink raw reply
* Improve config file escape sanity checking
From: Linus Torvalds @ 2005-10-11 19:13 UTC (permalink / raw)
To: Junio C Hamano, Git Mailing List
I had meant to disallow unknown escape characters in the config file
parser, but instead an unknown escaped character would silently pass
through as itself. That's correct for some cases (notably '\' itself), but
wasn't correct in general.
This fixes it, and makes the parser write a nice error message if the
config file contains bogus escaped characters.
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
---
diff --git a/config.c b/config.c
index f3c4fa4..510456c 100644
--- a/config.c
+++ b/config.c
@@ -64,7 +64,12 @@ static char *parse_value(void)
case 'n':
c = '\n';
break;
- return NULL;
+ /* Some characters escape as themselves */
+ case '\\': case '"':
+ break;
+ /* Reject unknown escape sequences */
+ default:
+ return NULL;
}
value[len++] = c;
continue;
^ permalink raw reply related
* Re: [PATCH] Try URI quoting for embedded TAB and LF in pathnames
From: Linus Torvalds @ 2005-10-11 18:37 UTC (permalink / raw)
To: Paul Eggert
Cc: Junio C Hamano, Robert Fitzsimons, Alex Riesen, git, Kai Ruemmler
In-Reply-To: <87ek6s0w34.fsf@penguin.cs.ucla.edu>
[-- Attachment #1: Type: TEXT/PLAIN, Size: 2436 bytes --]
On Tue, 11 Oct 2005, Paul Eggert wrote:
>
> For example, the simplest approach is to say a byte is funny if it is
> space, backslash, quote, an ASCII control character, or is non-ASCII.
> But this will cause perfectly-reasonable UTF-8 file names to be
> presented in git format using unreadable strings like "a\293\203\257b"
> or whatever.
I think the simplest question to ask is "what are we protecting against?"
There's only two characters that are _really_ special diff itself: \n and
\t. The former is obvious, the latter just because the regular gnu diff
format puts a tab between the name and the date (and if you _knew_ the
date was always there you could just work backwards, but since not all
diffs even put a date, \t ends up being special in practice).
So what else would you want to protect against? I hope not 8-bit
cleanness: if some stupid protocol still isn't 8-bit clean, it should be
fixed.
And \0 is already impossible, at least on sane systems.
So arguably you don't need to quote anything else than \n and \t (and that
obviously means you have to quote \ itself). That means that any filename
always shows "sanely" in its own byte locale, and everything is readable,
regardless of whether it's UTF-8 or just plain byte-encoded Latin1, or
anything else.
So I don't think you should quote invalid UTF-8: it's invalid UTF-8
whether Ãtis quoted or not.
Linus
PS. There _is_ something you may want to quote, namely the standard CSI
terminal escapes. Not because they wouldn't pass through, but because some
people might just "cat" a patch. This is debatable. Now, they are in all
in the range 0x00-0x1f and 0x80-0x9f, and since UTF-8 encoding is supposed
to happen before it (but you don't know how many get that right), if you
want to quote those characters, you need to do so _both_ for the "raw"
format and for the UTF-8 format.
Now, the UTF-8 format for that high range is actually the same character,
except preceded by a 0xc2 (I think), so the simplest thing is to do
quoting _purely_ on a byte-stream level (ignore any UTF-8 stuff), and
screw the fact that you end up with a non-UTF-8 sequence (character 0x0080
is UTF-8 sequence 0xC2 0x80, and would be quoted as 0xC2 + "\200", which
is no longer valid in UTF-8).
It gets quite nasty. For any UTF-8 quoting scheme you come up with, I'll
point out something that it does wrong or looks horrible for a Latin1
filename ;)
^ permalink raw reply
* Re: [PATCH] Try URI quoting for embedded TAB and LF in pathnames
From: Paul Eggert @ 2005-10-11 18:03 UTC (permalink / raw)
To: Linus Torvalds
Cc: Junio C Hamano, Robert Fitzsimons, Alex Riesen, git, Kai Ruemmler
In-Reply-To: <Pine.LNX.4.64.0510110802470.14597@g5.osdl.org>
Linus Torvalds <torvalds@osdl.org> writes:
> Personally, I'd like the normal C quoting the best.
That would be fine with me too. How about if we use the equivalent of
--quoting-style="c" for file names that contain funny bytes, and no
quoting for other file names? So, for example, something like this:
diff --git "space tab\tnewline\nquote\"backslash\\" b/dee/pqr
similarity index 72%
rename from "space tab\tnewline\nquote\"backslash\\"
rename to dee/pqr
index 9ee055c..243fbbc 100644
--- "space tab\tnewline\nquote\"backslash\\"
+++ b/dee/pqr
@@ -1 +1,3 @@
Fri Oct 7 23:19:04 PDT 2005
+foo
+foo
The surrounding double-quotes are an extra indication to the human
reader that there is something weird about the quoted file name.
> Use filenames as if they are just binary blobs of data,
> that's the only thing that has a high chance of success.
Thanks for thinking those things through. I agree mostly, but there's
still a technical problem, in that we have to decide what a "funny
byte" is if we are using C-style quoting. For example, the simplest
approach is to say a byte is funny if it is space, backslash, quote,
an ASCII control character, or is non-ASCII. But this will cause
perfectly-reasonable UTF-8 file names to be presented in git format
using unreadable strings like "a\293\203\257b" or whatever.
Perhaps it would be better to say that a byte is "funny" if it is
space, backslash, quote, an ASCII control character, or a byte that is
not part of a valid UTF-8 encoding. This will let UTF-8 file names
through unscathed, while still warning the reader when funny business
is going on. File names with other encodings (e.g., Shift-JIS) will
contain lots of backslashes, but that's OK: we don't mind making
nonstandard encodings hard-to-read, so long as we preserve the bytes
correctly.
We could implement in other GNU applications by having a new quoting
style that supports this quoting behavior. I can arrange for that.
> If somebody wants to use names with tabs and newlines, is he really
> going to work with diffs? Or is it just a driver error?
The current-supported scheme with 'diff' and 'patch' should work for
everything but newlines. I like the idea of getting it to work even
with newlines, and I am willing to sacrifice old patches with file
names starting with '"' (extremely rare, if any) to get newlines to
work. Among other things I worry about people submitting
purposely-malformed patches in non-git environments.
^ permalink raw reply
* Re: [PATCH] Support custom build options in config.mak
From: Daniel Barkalow @ 2005-10-11 17:18 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git, junkio
In-Reply-To: <Pine.LNX.4.63.0510110948170.19774@wbgn013.biozentrum.uni-wuerzburg.de>
On Tue, 11 Oct 2005, Johannes Schindelin wrote:
> +ifneq (,$(wildcard config.mak))
> +include config.mak
> +endif
> +
You can just do:
-include config.mak
for the same effect; it includes the file if it exists, and doesn't
complain if it doesn't exist. (It also means that make has a clearer idea
of what it's doing, which doesn't matter in this case, but is good in
general.)
-Daniel
*This .sig left intentionally blank*
^ permalink raw reply
* Re: How to restore the original head after `git-reset --hard master^`
From: Linus Torvalds @ 2005-10-11 17:04 UTC (permalink / raw)
To: Daniel Barkalow; +Cc: Ben Lau, git
In-Reply-To: <Pine.LNX.4.63.0510111240410.23242@iabervon.org>
On Tue, 11 Oct 2005, Daniel Barkalow wrote:
>
> That reminds me: if you lose all of your refs, it's hard to get them back,
> because git-fsck-objects aborts if you don't specify any heads or have any
> refs. Is there some reason for this check?
"git prune" is the reason for that check. Pruning your whole object store
is likely not what you want ;)
You might make it abort only when "--unreachable" has been specified..
Linus
^ permalink raw reply
* Re: How to restore the original head after `git-reset --hard master^`
From: Daniel Barkalow @ 2005-10-11 16:58 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Ben Lau, git
In-Reply-To: <Pine.LNX.4.64.0510110856520.14597@g5.osdl.org>
On Tue, 11 Oct 2005, Linus Torvalds wrote:
> On Tue, 11 Oct 2005, Ben Lau wrote:
> >
> > After involves the command `git-reset --hard master^` in a repository,
> > the working tree , current head and index are restored to the parent of
> > master. That includes the content of '.git/refs/head/master'. Although
> > the original commit object is still existed , I couldn't find it back.
> >
> > Is there anyway to recover the original master branch ?
>
> Just run "git-fsck-objects" and look at any dangling commits. The commit
> and related objects are still there (unless you've run "git prune"), so
> once you find the name of it, you're all done.
That reminds me: if you lose all of your refs, it's hard to get them back,
because git-fsck-objects aborts if you don't specify any heads or have any
refs. Is there some reason for this check?
-Daniel
*This .sig left intentionally blank*
^ permalink raw reply
* Re: [RFC] Cleaning up die() error messages
From: H. Peter Anvin @ 2005-10-11 16:11 UTC (permalink / raw)
To: Alex Riesen; +Cc: Elfyn McBratney, git
In-Reply-To: <81b0412b0510110802lbcdebe0m17bce7ca81ea76d2@mail.gmail.com>
Alex Riesen wrote:
> On 10/10/05, Elfyn McBratney <beu@gentoo.org> wrote:
>
>> int main (int argc, char **argv)
>> {
>> set_prog_name(argv[0]);
>
>
> I'd also use readlink on /proc/self/exe by default (if set_prog_name
> _not_ called).
> It simplifies the code at least on linux, and makes possible very slow
> transition for other platforms. So you don't have to update each and
> every .c file containing "main[[:space:]]*(" ;)
It's really better just to put the stuff at the beginning of each main.
If that's too annoying, librarize main and rename your mains "git_main".
-hpa
^ permalink raw reply
* Re: How to restore the original head after `git-reset --hard master^`
From: Linus Torvalds @ 2005-10-11 15:59 UTC (permalink / raw)
To: Ben Lau; +Cc: git
In-Reply-To: <434BD65A.9000108@ust.hk>
On Tue, 11 Oct 2005, Ben Lau wrote:
>
> After involves the command `git-reset --hard master^` in a repository,
> the working tree , current head and index are restored to the parent of
> master. That includes the content of '.git/refs/head/master'. Although
> the original commit object is still existed , I couldn't find it back.
>
> Is there anyway to recover the original master branch ?
Just run "git-fsck-objects" and look at any dangling commits. The commit
and related objects are still there (unless you've run "git prune"), so
once you find the name of it, you're all done.
First check that you have the right one by doing
git log <name-you-found>
and if that looks right, you can just do
git reset --hard <name-you-found>
and you should be back in business.
Linus
^ permalink raw reply
* Re: [PATCH] Try URI quoting for embedded TAB and LF in pathnames
From: Linus Torvalds @ 2005-10-11 15:17 UTC (permalink / raw)
To: Paul Eggert
Cc: Junio C Hamano, Robert Fitzsimons, Alex Riesen, git, Kai Ruemmler
In-Reply-To: <87mzlgh8xa.fsf@penguin.cs.ucla.edu>
On Mon, 10 Oct 2005, Paul Eggert wrote:
>
> An issue I hadn't really had time to think about is the character
> encoding of file names.
Please don't. Use filenames as if they are just binary blobs of data,
that's the only thing that has a high chance of success. Yes, it too can
break in the presense of something _else_ doing character translation
and/or people moving a patch from one encoding to another , buthat's
just true of anything.
Eventually everybody will hopefully use UTF-8, and nothing else really
matters, but the thing is, if you see filenames as just blobs of data,
that works with UTF-8 too, so it's not "wrong" even in the long run. And
until everybody has one single encoding, you simply won't be able to tell,
and the likelihood that you'd screw up is pretty high.
The happy part of the "binary blob" approach is that users _understand_
it. People who actively use different encoding formats are (painfully)
aware of conversions, and they may curse you for not doing the random
encoding format of the day, but they will be able to handle it.
In contrast, if you start doing conversions, I guarantee you that people
will _not_ be able to handle it when you do something strange - you've
changed the data.
Personally, I'd like the normal C quoting the best. Leave space as-is, and
quote TAB/NL as \t and \n respectively. It's pretty universally understood
in programming circles even outside of C, and it's not like a very
uncommon patch format like that really needs to be well-understood outside
of those circles.
It also has a very obvious and ASCII-safe format for other characters (ie
just the normal octal escapes: \377 etc..
That said, I personally don't think it's necessarily even worth it. If
somebody wants to use names with tabs and newlines, is he really going to
work with diffs? Or is it just a driver error?
Linus
^ permalink raw reply
* How to restore the original head after `git-reset --hard master^`
From: Ben Lau @ 2005-10-11 15:12 UTC (permalink / raw)
To: git
Hi all,
After involves the command `git-reset --hard master^` in a
repository, the working
tree , current head and index are restored to the parent of master. That
includes
the content of '.git/refs/head/master'. Although the original commit
object is still existed
, I couldn't find it back.
Is there anyway to recover the original master branch ? or I have to
restore the branch
manually by finding out all the child of current head? If that is the
solution , what command
could provide this information?
Thanks
^ permalink raw reply
* Re: [RFC] Cleaning up die() error messages
From: Alex Riesen @ 2005-10-11 15:02 UTC (permalink / raw)
To: Elfyn McBratney; +Cc: git
In-Reply-To: <20051010105008.GB30202@gentoo.org>
On 10/10/05, Elfyn McBratney <beu@gentoo.org> wrote:
> int main (int argc, char **argv)
> {
> set_prog_name(argv[0]);
I'd also use readlink on /proc/self/exe by default (if set_prog_name
_not_ called).
It simplifies the code at least on linux, and makes possible very slow
transition for other platforms. So you don't have to update each and
every .c file containing "main[[:space:]]*(" ;)
^ permalink raw reply
* Re: [PATCH] cg-tag - add support for longer commit messages
From: Linus Torvalds @ 2005-10-11 14:57 UTC (permalink / raw)
To: Martin Langhoff; +Cc: git
In-Reply-To: <11289987493327-git-send-email-martin@catalyst.net.nz>
On Tue, 11 Oct 2005, Martin Langhoff wrote:
>
> Added an -m switch that points to a filename which contains a (potentially
> long) tag message.
At least core git has "-m 'message'" and "-F 'file'" (with long versions
being "--message" and "--file" respectively) for this kind of thing in
"git commit". Maybe it would be good to make that the standard interface.
When scripting, using a separate file is often inconvenient, and giving
the message as an argument much nicer. So you do often want both.
Linus
^ permalink raw reply
* Re: [PATCH] First cut of a Cygwin package creation target.
From: Tim O Callaghan @ 2005-10-11 14:39 UTC (permalink / raw)
To: git
In-Reply-To: <23711.145.36.10.111.1129040793.squirrel@www.dspsrv.com>
I should also mention that in my (probably misguided) enthusiasm for
the Cygwin port, i proposed myself as the package maintainer on the
cygwin-app list. If people don't think i'm gittish enough to handle
it, i am more than happy let them take over. Otherwise i will attempt
to go through the procedures needed to get it into the Cygwin distro.
For those interested, a copy of the generated Cygwin packages can be found
at:
http://www.dspsrv.com/~timo/
If there are no objections, i'll send them onto the Cygwin people sometime
tomorrow.
Tim.
"Money can't buy friends, but it can get you a better class of enemy."
- Spike Milligan
^ permalink raw reply
* [PATCH] First cut of a Cygwin package creation target.
From: Tim O Callaghan @ 2005-10-11 14:26 UTC (permalink / raw)
To: git
The new make target 'cygwinpackage' creates dist tars based on the
Cygwin package guidelines at:http://cygwin.com/setup.html
The tar packages when created are placed in the cygwin directory with
the Cygwin setup specific setup.hint file, ready for distribution.
Signed-off-by: Tim O'Callaghan <timo@dspsrv.com>
---
Makefile | 20 ++++++++++++++++++++
cygwin/setup.hint | 11 +++++++++++
2 files changed, 31 insertions(+), 0 deletions(-)
mode change 100644 => 100755 Makefile
create mode 100755 cygwin/setup.hint
applies-to: 2bab3caf63fc29f249c792289365abaf1cfa071b
ba3be06048f361afc80baae30b00dd6e022386d0
diff --git a/Makefile b/Makefile
old mode 100644
new mode 100755
index c31af7b..1a227ed
--- a/Makefile
+++ b/Makefile
@@ -441,6 +441,26 @@ deb: dist
dpkg-source -b $(GIT_TARNAME)
cd $(GIT_TARNAME) && fakeroot debian/rules binary
+unexport prefix
+export prefix=/
+export DESTDIR=/tmp/cygwin/usr
+cygwinpackage: all
+ strip -s *.exe
+ rm -f $(GIT_TARNAME)*.tar*
+ ./git-tar-tree HEAD $(GIT_TARNAME) > $(GIT_TARNAME)-src.tar
+ mkdir -p $(GIT_TARNAME)
+ cp README $(GIT_TARNAME)/git-core-$(GIT_VERSION).README
+ $(TAR) rf $(GIT_TARNAME).tar
$(GIT_TARNAME)/git-core-$(GIT_VERSION).README
+ @rm -rf $(GIT_TARNAME)
+ bzip2 $(GIT_TARNAME)-src.tar
+ rm -rf $(DESTDIR)
+ mkdir -p $(DESTDIR)/man/man1 $(DESTDIR)/man/man7
$(DESTDIR)/share/Cygwin
+ cp README $(DESTDIR)/share/Cygwin/git-core-$(GIT_VERSION).README
+ $(MAKE) install
+ $(MAKE) -C Documentation install
+ cd /tmp/cygwin; $(TAR) -jcf /tmp/$(GIT_TARNAME).tar.bz2 *
+ mv /tmp/$(GIT_TARNAME).tar.bz2 ./$(GIT_TARNAME)-src.tar.bz2 ./cygwin
+
### Cleaning rules
clean:
diff --git a/cygwin/setup.hint b/cygwin/setup.hint
new file mode 100755
index 0000000..580eecc
--- /dev/null
+++ b/cygwin/setup.hint
@@ -0,0 +1,11 @@
+# git-core setup.hint - file required by cygwin package manager
+#
+# short description
+sdesc: "Git-core - SCM Developed for the Linux kernel"
+# long description
+ldesc: "Git-core - SCM Developed for the Linux kernel - now available to
the windows masses via the magic of Cygwin"
+# package category
+category: Archive Devel
+# dependencies
+requires: cygwin libiconv zlib openssl curl-devel diff merge ssh
+
---
0.99.8.GIT
^ permalink raw reply related
* [PATCH] Use git-update-ref and git-symbolic-ref in tests
From: Johannes Schindelin @ 2005-10-11 14:02 UTC (permalink / raw)
To: git, junkio
This makes all tests pass on cygwin.
Signed-off-by: Johannes Schindelin <Johannes.Schindelin@gmx.de>
---
t/t5000-tar-tree.sh | 6 +++---
t/t6001-rev-list-merge-order.sh | 2 +-
t/t6002-rev-list-bisect.sh | 2 +-
t/t6003-rev-list-topo-order.sh | 2 +-
4 files changed, 6 insertions(+), 6 deletions(-)
applies-to: c6ce0dfdf028e37ae907628a56895afc14d6d7a0
f86f79547964a7e9d23535c4971d757117800aa2
diff --git a/t/t5000-tar-tree.sh b/t/t5000-tar-tree.sh
index 5dffb8e..4db1bb1 100755
--- a/t/t5000-tar-tree.sh
+++ b/t/t5000-tar-tree.sh
@@ -41,8 +41,8 @@ test_expect_success \
find a -type l | xargs git-update-index --add &&
treeid=`git-write-tree` &&
echo $treeid >treeid &&
- TZ=GMT GIT_COMMITTER_DATE="2005-05-27 22:00:00" \
- git-commit-tree $treeid </dev/null >.git/HEAD'
+ git-update-ref HEAD $(TZ=GMT GIT_COMMITTER_DATE="2005-05-27 22:00:00" \
+ git-commit-tree $treeid </dev/null)'
test_expect_success \
'git-tar-tree' \
@@ -59,7 +59,7 @@ test_expect_success \
test_expect_success \
'git-get-tar-commit-id' \
'git-get-tar-commit-id <b.tar >b.commitid &&
- diff .git/HEAD b.commitid'
+ diff .git/$(git-symbolic-ref HEAD) b.commitid'
test_expect_success \
'extract tar archive' \
diff --git a/t/t6001-rev-list-merge-order.sh b/t/t6001-rev-list-merge-order.sh
index 0101242..8ec9ebb 100755
--- a/t/t6001-rev-list-merge-order.sh
+++ b/t/t6001-rev-list-merge-order.sh
@@ -108,7 +108,7 @@ save_tag h2 unique_commit g4 tree -p g2
save_tag g3 unique_commit g5 tree -p g2
save_tag g4 unique_commit g6 tree -p g3 -p h2
-tag l5 > .git/HEAD
+git-update-ref HEAD $(tag l5)
test_expect_success 'rev-list has correct number of entries' 'git-rev-list HEAD | wc -l | tr -s " "' <<EOF
19
diff --git a/t/t6002-rev-list-bisect.sh b/t/t6002-rev-list-bisect.sh
index 42fcbc6..693de9b 100755
--- a/t/t6002-rev-list-bisect.sh
+++ b/t/t6002-rev-list-bisect.sh
@@ -58,7 +58,7 @@ on_committer_date "1971-08-16 00:00:15"
on_committer_date "1971-08-16 00:00:16" save_tag l3 unique_commit l3 tree -p a4
on_committer_date "1971-08-16 00:00:17" save_tag l4 unique_commit l4 tree -p l3
on_committer_date "1971-08-16 00:00:18" save_tag l5 unique_commit l5 tree -p l4
-tag l5 > .git/HEAD
+git-update-ref HEAD $(tag l5)
# E
diff --git a/t/t6003-rev-list-topo-order.sh b/t/t6003-rev-list-topo-order.sh
index 88d14ee..3c4c44c 100755
--- a/t/t6003-rev-list-topo-order.sh
+++ b/t/t6003-rev-list-topo-order.sh
@@ -77,7 +77,7 @@ save_tag h2 unique_commit g4 tree -p g2
save_tag g3 unique_commit g5 tree -p g2
save_tag g4 unique_commit g6 tree -p g3 -p h2
-tag l5 > .git/HEAD
+git-update-ref HEAD $(tag l5)
test_expect_success 'rev-list has correct number of entries' 'git-rev-list HEAD | wc -l | tr -s " "' <<EOF
19
---
0.99.8.GIT
^ permalink raw reply related
* Re: [PATCH] gitk: Add "Refs" menu
From: Paul Mackerras @ 2005-10-11 12:17 UTC (permalink / raw)
To: Pavel Roskin; +Cc: git
In-Reply-To: <1128559088.32103.8.camel@dv>
Pavel Roskin writes:
> This patch adds "Refs" menu to gitk. It makes all branches, tags and
> other ref objects appear as menu items. Selecting one of the items
> selects the corresponding line in the view.
Sorry I haven't responded before - I have got way behind with my email
due to a vacation and to concentrating on the merge of the ppc32 and
ppc64 kernel sources. It will probably be a bit longer before I can
get to look at this.
Thanks,
Paul.
^ 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