* TortoiseGIT
From: Laszlo Papp @ 2009-12-15 15:41 UTC (permalink / raw)
To: git
Hello,
I had got a problem in the past with cr + lf between windows and linux
client(maybe now too).
I heard that from more experienced users I need to set autocrlf +
safecrlf on windows, and core.autocrlf false on linux (which is the
default), but If I set core.autocrlf true on linux too, it worked
normally, after a git pull on windows I don't see any modified file
that should be committed, not the case in core.autocrlf false.
Could someone explain this habbit of git, please ?
Everybody said I need to set autocrlf for false, but it doesn't work
so, just with true on linux client, what do I do wrong ?
It's okay now for me, because it works without any problem, I just
don't understand the behaviour of it, and I don't know whether it will
cause further problems.
Thanks in advance!
Best Regards,
Laszlo Papp
^ permalink raw reply
* Re: am fails to apply patches for files with CRLF lineendings
From: Brandon Casey @ 2009-12-15 16:04 UTC (permalink / raw)
To: Sverre Rabbelier; +Cc: Brandon Casey, git
In-Reply-To: <fabb9a1e0912142233u42fc4bb6k70ef7c539cc1ae76@mail.gmail.com>
Sverre Rabbelier wrote:
> Heya,
>
> On Tue, Dec 15, 2009 at 03:09, Brandon Casey <drafnel@gmail.com> wrote:
>> Forwarding to the list. The original was bounced since gmail sent a
>> multipart mime version with html. Seems we can't disable html
>> composing in the gmail settings anymore (I thought we used to be able
>> to).
>
> You can, it remembers when you click "« Plain Text", at least, it does
> for me :P.
Thanks, that seemed to be the case for the last few emails I wrote.
They defaulted to plain text.
-brandon
^ permalink raw reply
* Re: core.worktree bug
From: Nguyen Thai Ngoc Duy @ 2009-12-15 16:30 UTC (permalink / raw)
To: Robin Rosenberg; +Cc: git
In-Reply-To: <200912071115.48085.robin.rosenberg.lists@dewire.com>
On Mon, Dec 07, 2009 at 11:15:47AM +0100, Robin Rosenberg wrote:
> $ git config core.worktree $(cd ../r1;pwd)
> $ git status
> # On branch master
> # Changed but not updated:
> # (use "git add/rm <file>..." to update what will be committed)
> # (use "git checkout -- <file>..." to discard changes in working directory)
> #
> # deleted: f
> #
> no changes added to commit (use "git add" and/or "git commit -a")
>
> => Seems the config is actually honored even though GIT_DIR is not set.
>
> Bisect tells me 4f38f6b5bafb1f7f85c7b54d0bb0a0e977cd947c broke it. My main point is that I am
You should have CCed me.
> implementing this in JGit so I want the same behaviour. Question: Should we try to fix this
> in git so it matches the documentation or fix the documentation to match behaviour.
>
> The breakage appeared over a year ago and no one has complained.
This is, I think, due to the shared use of git_work_tree_cfg. When
setup_git_directory_gently() comes close to the end, work_tree has
been detected and set. Then check_repository_format_gently() is
called to make sure the repository is valid. Among the checks are
core.worktree check, which overrides the previously-set git_work_tree_cfg.
This might be the fix, or a start of new breakages. I'll need to look
at this again and make a proper patch message with tests if it's
really correct.
diff --git a/setup.c b/setup.c
index f67250b..1385edb 100644
--- a/setup.c
+++ b/setup.c
@@ -280,6 +280,18 @@ const char *read_gitfile_gently(const char *path)
return path;
}
+static int check_repository_work_tree(const char *var, const char *value, void *cb)
+{
+ if (strcmp(var, "core.worktree") == 0) {
+ if (!value)
+ return config_error_nonbool(var);
+ free(git_work_tree_cfg);
+ git_work_tree_cfg = xstrdup(value);
+ inside_work_tree = -1;
+ }
+ return 0;
+}
+
/*
* We cannot decide in this function whether we are in the work tree or
* not, since the config can only be read _after_ this function was called.
@@ -317,6 +329,7 @@ const char *setup_git_directory_gently(int *nongit_ok)
if (!work_tree_env) {
retval = set_work_tree(gitdirenv);
/* config may override worktree */
+ git_config(check_repository_work_tree, NULL);
if (check_repository_format_gently(nongit_ok))
return NULL;
return retval;
@@ -394,6 +407,7 @@ const char *setup_git_directory_gently(int *nongit_ok)
die_errno("Cannot change to '%s/..'", cwd);
}
+ git_config(check_repository_work_tree, NULL);
inside_git_dir = 0;
if (!work_tree_env)
inside_work_tree = 1;
@@ -471,12 +485,6 @@ int check_repository_format_version(const char *var, const char *value, void *cb
is_bare_repository_cfg = git_config_bool(var, value);
if (is_bare_repository_cfg == 1)
inside_work_tree = -1;
- } else if (strcmp(var, "core.worktree") == 0) {
- if (!value)
- return config_error_nonbool(var);
- free(git_work_tree_cfg);
- git_work_tree_cfg = xstrdup(value);
- inside_work_tree = -1;
}
return 0;
}
--
Duy
^ permalink raw reply related
* Re: Giving command line parameter to textconv command?
From: Jeff King @ 2009-12-15 16:49 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Nanako Shiraishi, git
In-Reply-To: <7vfx7c3hmb.fsf@alter.siamese.dyndns.org>
On Mon, Dec 14, 2009 at 09:56:28PM -0800, Junio C Hamano wrote:
> Let's try to do a bit more work to make the coverage complete. After
> scanning "git grep -e start_async -e run_command" output, here is what I
> came up with:
>
> - editor.c::launch_editor() that allows a custom editor named via
> GIT_EDITOR does seem to honor your command line arguments.
>
> - pager.c::setup_pager() is used for GIT_PAGER and it does honor your
> command line arguments.
>
> - ll-merge.c::ll_ext_merge() that is used to handle custom merge drivers
> lets the user specify command line via templating to replace %O %A %B
> and naturally it needs to be aware of the command line arguments.
I think it is important to note in user-facing documentation (like
release notes describing the proposed textconv change) that these are
not just "honor your command line arguments" but "execute your command
with /bin/sh". Maybe that is obviously how it is implemented, but I
think it should be made clear that you have the power to use (and
responsibility to protect yourself from) arbitrary shell code.
> - diff.c::run_external_diff() that runs GIT_EXTERNAL_DIFF defines that
> the command has to take 7 parameters in a fixed order, and is not
> designed to permute its arguments like ll_ext_merge() does, but these
> days people don't use it directly (they use it indirectly via
> "difftool" wrapper), so it probably is not an issue.
There is also diff.*.command, which I think people _do_ set manually (I
used to, until I wrote textconv. :) ). It does not use the shell
currently. I agree that people almost certainly have to write a
shell-script wrapper anyway. But I wonder if we should pass it through
the shell, just for the sake of consistency with the other variables (in
particular, if textconv changes, I think diff.*.command is closely
related).
-Peff
^ permalink raw reply
* Re: Giving command line parameter to textconv command?
From: Jeff King @ 2009-12-15 17:03 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Nanako Shiraishi, git
In-Reply-To: <7vvdg9ceud.fsf@alter.siamese.dyndns.org>
On Mon, Dec 14, 2009 at 03:31:38PM -0800, Junio C Hamano wrote:
> The change to do so looks like this; it has a few side effects:
>
> - If somebody else were relying on the fact that 'nkf -w' names the
> entire command, it now will run 'nkf' command with '-w' as an argument,
> and it will break such a set-up. IOW, command that has an IFS white
> space in its path will now need to be quoted from the shell.
>
> You can see the fallout from this in the damage made to t/ hierarchy in
> the attached patch.
>
> - You can now use $HOME and other environment variables your shell
> expands when defining your textconv command.
>
> Overall I think it is a good direction to go, but we need to be careful
> about how we transition the existing repositories that use the old
> semantics.
I agree that this is a good change. My only reservation would be that
spawning a shell would be slightly slower (think "git log -p"). However:
1. textconv is dog-slow already, as it has to dump each blob to a
tempfile[1].
2. There is an obvious optimization, which is that you can skip the
shell if there are no metacharacters (in fact, we seem to be doing
that already in launch_editor).
> We might need to introduce diff.*.xtextconv or something.
I am torn on this. I don't like introducing behavior changes that might
hurt people (and really, I think we are just talking about people with
textconv pointing to a program by its full path that has a space in it).
But I also hate carrying around baggage crap like xtextconv forever. It
makes git harder to explain why there are two variables that do almost
the same thing, and the one they want to use is probably the one with
the crappier, unlikely-to-be-guessed name.
So I am somewhat inclined to call it a bug fix, but I don't feel very
strongly.
-Peff
[1] The current textconv interface is really nice for things like just
using "antiword" out of the box. But I wrote a new interface which can
be much faster: it calls the textconv filter with the blob name, and
then the filter is responsible for using cat-file to get at the blob.
This means the filter can look at only part of a blob (e.g., if we are
interested in the metadata tags at the beginning of a large media file),
and it can cache answers as it sees fit, avoiding access to the blob
entirely.
I need to polish the code a bit and submit it. Obviously this is not
meant to replace the existing textconv, but rather to supplement it, for
when "fast and inconvenient" is better than "slow and simple". What is
the best way to configure this? I can imagine "diff.*.textconvType =
fast", or also "diff.*.fastTextconv".
-Peff
^ permalink raw reply
* Re: [PATCH 1/2] filter-branch: remove an unnecessary use of 'git read-tree'
From: Johannes Schindelin @ 2009-12-15 17:19 UTC (permalink / raw)
To: Johannes Sixt; +Cc: Junio C Hamano, Git Mailing List
In-Reply-To: <4B274BDE.8000504@viscovery.net>
Hi,
On Tue, 15 Dec 2009, Johannes Sixt wrote:
> From: Johannes Sixt <j6t@kdbg.org>
>
> The intent of this particular call to 'git read-tree' was to fill an
> index. But in fact, it only allocated an empty index. Later in the
> program, the index is filled anyway by calling read-tree with specific
> commits, and considering that elsewhere the index is even removed (i.e.,
> it is not relied upon that the index file exists), this first call of
> read-tree is completely redundant.
Yes, indeed.
Ciao,
Dscho
^ permalink raw reply
* Re: Giving command line parameter to textconv command?
From: Junio C Hamano @ 2009-12-15 17:23 UTC (permalink / raw)
To: Jeff King; +Cc: Junio C Hamano, Nanako Shiraishi, git
In-Reply-To: <20091215170321.GB21322@coredump.intra.peff.net>
Jeff King <peff@peff.net> writes:
> [1] The current textconv interface is really nice for things like just
> using "antiword" out of the box. But I wrote a new interface which can
> be much faster: it calls the textconv filter with the blob name, and
> then the filter is responsible for using cat-file to get at the blob.
> This means the filter can look at only part of a blob (e.g., if we are
> interested in the metadata tags at the beginning of a large media file),
> and it can cache answers as it sees fit, avoiding access to the blob
> entirely.
>
> I need to polish the code a bit and submit it. Obviously this is not
> meant to replace the existing textconv, but rather to supplement it, for
> when "fast and inconvenient" is better than "slow and simple". What is
> the best way to configure this? I can imagine "diff.*.textconvType =
> fast", or also "diff.*.fastTextconv".
"diff.*.blobfilter"?
^ permalink raw reply
* the 100 mb push
From: Joey Hess @ 2009-12-15 19:23 UTC (permalink / raw)
To: git
[-- Attachment #1: Type: text/plain, Size: 3109 bytes --]
Is it normal for git push to sometimes transfer much more data
than seems necessary? Here is a case where that happens:
joey@gnu:~/src/p.t>git branch
* master
pristine-tar
testsuite
joey@gnu:~/src/p.t>git remote show origin
* remote origin
Fetch URL: ssh://joey@git.kitenet.net/srv/git/pristine-tar.test
Push URL: ssh://joey@git.kitenet.net/srv/git/pristine-tar.test
HEAD branch: master
Remote branches:
master tracked
pristine-tar tracked
testsuite tracked
Local branches configured for 'git pull':
master merges with remote master
pristine-tar merges with remote pristine-tar
testsuite merges with remote testsuite
Local refs configured for 'git push':
master pushes to master (fast forwardable)
pristine-tar pushes to pristine-tar (up to date)
testsuite pushes to testsuite (local out of date)
Here, master is a typical small project branch. It has a 1 line change
made locally.
Meanwhile, the testsuite branch is a 100+ mb monster, containing a lot
of big binaries. In it, a small change has been made in the origin
repo. In the local repo, a *lot* of *big* files have been deleted from
the same branch, about 20 mb of files were removed all told. But the diff
for this change should be quite small.
So, testsuite needs to be merged before it can be pushed, but git push
doesn't tell me that. Instead, it goes off and does this for 2+ hours:
joey@gnu:~/src/p.t>git push
Counting objects: 241, done.
Delta compression using up to 2 threads.
Compressing objects: 100% (206/206), done.
Writing objects: 15% (36/237), 2.16 MiB | 15 KiB/s
^C
It seems to be uploading the entire repo over the wire, and this is a
typical asymmetric network connection, so that goes slow. (Took me a
while to realize it was not just auto-gcing the repo locally.)
Once I realized what was going on, it was easy to merge it as shown
below, and then the push transferred an appropriatly small amount of data.
So, my question is, assuming this is not a straight up bug in git, would
it make sense to avoid this gotcha in some way?
joey@gnu:~/src/p.t2>git checkout testsuite
Switched to branch 'testsuite'
Your branch is ahead of 'origin/testsuite' by 1 commit.
joey@gnu:~/src/p.t2>git pull
remote: Counting objects: 5, done.
remote: Compressing objects: 100% (3/3), done.
remote: Total 3 (delta 2), reused 0 (delta 0)
Unpacking objects: 100% (3/3), done.
From ssh://git.kitenet.net/srv/git/pristine-tar.test
3c16948..fce7ec1 testsuite -> origin/testsuite
Merge made by recursive.
Makefile | 5 ++++-
1 files changed, 4 insertions(+), 1 deletions(-)
joey@gnu:~/src/p.t2>git push
Counting objects: 13, done.
Delta compression using up to 2 threads.
Compressing objects: 100% (8/8), done.
Writing objects: 100% (8/8), 889 bytes, done.
Total 8 (delta 5), reused 0 (delta 0)
To ssh://joey@git.kitenet.net/srv/git/pristine-tar.test
aab45a1..cc93945 master -> master
fce7ec1..d82f225 testsuite -> testsuite
git version 1.6.5.3
--
see shy jo
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 828 bytes --]
^ permalink raw reply
* Re: [PATCH v5 1/7] reset: do not accept a mixed reset in a .git dir
From: Christian Couder @ 2009-12-15 19:41 UTC (permalink / raw)
To: Junio C Hamano
Cc: git, Linus Torvalds, Johannes Schindelin, Stephan Beyer,
Daniel Barkalow, Jakub Narebski, Paolo Bonzini, Johannes Sixt,
Stephen Boyd
In-Reply-To: <7vtyvvn9wx.fsf@alter.siamese.dyndns.org>
On samedi 12 décembre 2009, Junio C Hamano wrote:
> Christian Couder <chriscool@tuxfamily.org> writes:
> > It is strange and fragile that a mixed reset is disallowed in a bare
> > repo but is allowed in a .git dir. So this patch simplifies things
> > by only allowing soft resets when not in a working tree.
>
> I would not mind what you said were "I find the difference strange", as
> it is a fairly subjective word. But if you say "fragile", you would need
> to defend the use of the word better. What kind of misuse does it
> invite, and what grave consequences such misuses would cause? I do not
> see any fragility and I would want to understand it better so that I can
> write about it in the Release Note to warn people and encourage them to
> upgrade.
>
> More importantly, I think the difference between the two actually makes
> sense. A bare repository by definition does _not_ have any work tree so
> there is no point in having the index file in there. On the other hand,
> even though it is not necessary to "cd .git && git reset HEAD^", I don't
> see a strong reason why it needs to be disallowed.
Ok. I have the following patch now:
---------- 8< ---------------
commit c20f969db6e565f2fe854b95202c3ef95ad0ff42
Author: Christian Couder <chriscool@tuxfamily.org>
Date: Thu Dec 10 22:10:07 2009 +0100
reset: improve mixed reset error message when in a bare repo
When running a "git reset --mixed" in a bare repository, the
message displayed is:
fatal: This operation must be run in a work tree
fatal: Could not reset index file to revision 'HEAD^'.
This message is a little bit misleading as a mixed reset is ok in
a git directory, so it is not absolutely needed to run it in a
work tree.
So this patch improves upon the above by changing the message to:
fatal: mixed reset is not allowed in a bare repository
This patch is also needed to speed up "git reset" by using
unpack_tree() directly (instead of execing "git read-tree"). A
following patch will do just that.
While at it, instead of disallowing "git reset --option" outside
a work tree only when option is "hard" or "merge", we now disallow
it except when option is "soft" or "mixed", as it is safer if we
ever add options to "git reset".
diff --git a/builtin-reset.c b/builtin-reset.c
index 11d1c6e..ac3505b 100644
--- a/builtin-reset.c
+++ b/builtin-reset.c
@@ -286,11 +286,15 @@ int cmd_reset(int argc, const char **argv, const char
*pre
if (reset_type == NONE)
reset_type = MIXED; /* by default */
- if ((reset_type == HARD || reset_type == MERGE)
- && !is_inside_work_tree())
+ if (reset_type != SOFT && reset_type != MIXED
+ && !is_inside_work_tree())
die("%s reset requires a work tree",
reset_type_names[reset_type]);
+ if (reset_type == MIXED && is_bare_repository())
+ die("%s reset is not allowed in a bare repository",
+ reset_type_names[reset_type]);
+
/* Soft reset does not touch the index file nor the working tree
* at all, but requires them in a good order. Other resets reset
* the index file to the tree object we are switching to. */
---------- 8< ---------------
> On the other hand, I don't see a strong reason why such a use needs to be
> supported, other than "we've allowed it for a long time, and people may
> have hooks (they typically start in $GIT_DIR) that rely on it", which by
> itself is not something strong enough to veto the change. It is only a
> minor incompatibility and I can be persuaded to listen to a pros-and-cons
> argument.
>
> An honest justification might have been "This change to disallow a mixed
> reset in $GIT_DIR of a repository with a work tree will break existing
> scripts, but I think it is not widely used _for such and such reasons_,
> and can easily be worked around. On the other hand, this change vastly
> simplifies the reimplementation of 'reset' _because X and Y and Z_".
My opinion is that it works this way just by accident not by design (that's
why I said "fragile"). But if we don't want to take any risk of regression,
then let's use the new patch above.
> > This patch is also needed to speed up "git reset" by using
> > unpack_tree() directly (instead of execing "git read-tree").
>
> It is very unclear _why_ it is "needed" from this description.
The reason is that after the next patch, it will not fail in a bare
repository, so if we don't change anything, the test that checks that it
fails in a bare repo will fail. I will add this explanation to the new
patch.
Best regards,
Christian.
^ permalink raw reply related
* Re: the 100 mb push
From: Shawn O. Pearce @ 2009-12-15 19:42 UTC (permalink / raw)
To: Joey Hess; +Cc: git
In-Reply-To: <20091215192338.GA16654@gnu.kitenet.net>
Joey Hess <joey@kitenet.net> wrote:
> Is it normal for git push to sometimes transfer much more data
> than seems necessary? Here is a case where that happens:
Yes.
> Meanwhile, the testsuite branch is a 100+ mb monster, containing a lot
> of big binaries. In it, a small change has been made in the origin
> repo. In the local repo, a *lot* of *big* files have been deleted from
> the same branch, about 20 mb of files were removed all told. But the diff
> for this change should be quite small.
>
> So, testsuite needs to be merged before it can be pushed, but git push
> doesn't tell me that. Instead, it goes off and does this for 2+ hours:
The problem here is, unlike fetch, push does not do a common
ancestor negotiation. The sending side (your push client)
just assumes the remote side has *only* what the remote side
advertised.
Since the remote side advertised a commit on the testsuite branch
that your client doesn't have, your client was forced to assume
there was no common ancestor and sent the entire thing.
This usually doesn't show up that badly because the delta tends to
be smaller (no huge binary files), tends to be a strict fast forward
(so your client contains what the remote advertised), and tags may
help to limit the upload size by being at fixed points in the history
(so at worst you upload since the last tag).
Junio wrote a patch series for git push over a year ago to make
it do common ancestor negotiation like git fetch does, but it had
a deadlock problem and the patch series got dropped. Not enough
people were interested to help Junio carry it through to being
ready for inclusion.
--
Shawn.
^ permalink raw reply
* Re: the 100 mb push
From: Junio C Hamano @ 2009-12-15 20:00 UTC (permalink / raw)
To: Joey Hess; +Cc: git
In-Reply-To: <20091215192338.GA16654@gnu.kitenet.net>
Joey Hess <joey@kitenet.net> writes:
> So, my question is, assuming this is not a straight up bug in git, would
> it make sense to avoid this gotcha in some way?
The "push" support was originally written for people who push into their
own repositories for publishing (i.e. almost always fast-forwarding) and
lacked the elaborate common ancestor discovery negotiation the "fetch"
side had.
Suppose you have a rewound or forked history, like this:
(their side)
*---Y pu
/
*---X
/
*---*---Z master
(your side)
*---X---*---A pu
/
*---*---Z---*---B master
- You were in sync when the 'pu' was at X with them; somebody pushed a
few commits on top of it (forked case); or
- You were in sync when the 'pu' was at Y with them (you pushed it their
last time yourself), but you rebuilt 'pu' since then (rewound case).
If you run "git push there master +pu", it learns that the tips of
'master' and 'pu' are at Z and Y respectively at their end. Because the
protocol did not negotiate the common ancestor, it would try to send:
rev-list A B ^Z ^Y
but using only the information available at your end locally.
Because you either never have heard of (in a forked case) or no longer
know (in a rewound case) what 'Y' is, in order to update 'pu', you end up
sending commits 'Z..A', duplicating 'Z..X' part, because "^Y" cannot
participate in the ancestory computation. Commits 'Z..B' will be sent to
update 'master'.
And this aspect of "git push" protocol hasn't changed much since it was
written.
In contrast, the protocol used for "fetch" tries to discover 'X' in such a
case by a little exchange, like this:
downloader: Your tip is at 'Y'? I've never heard of it. Please
tell me about its parents.
uploader: It is this "Y^", and its parent is 'X', and ...
downloader: Ok, I know what 'X' is. I heard enough to proceed. Thank you.
^ permalink raw reply
* Re: [PATCH v5 1/7] reset: do not accept a mixed reset in a .git dir
From: Junio C Hamano @ 2009-12-15 20:17 UTC (permalink / raw)
To: Christian Couder
Cc: git, Linus Torvalds, Johannes Schindelin, Stephan Beyer,
Daniel Barkalow, Jakub Narebski, Paolo Bonzini, Johannes Sixt,
Stephen Boyd
In-Reply-To: <200912152041.36194.chriscool@tuxfamily.org>
Christian Couder <chriscool@tuxfamily.org> writes:
> This patch is also needed to speed up "git reset" by using
> unpack_tree() directly (instead of execing "git read-tree"). A
> following patch will do just that.
This still doesn't seem to explain anything that the part you added after
your patch.
> While at it, instead of disallowing "git reset --option" outside
> a work tree only when option is "hard" or "merge", we now disallow
> it except when option is "soft" or "mixed", as it is safer if we
> ever add options to "git reset".
I fail to see any sane logic behind this reasoning; you cannot decide if
you need to allow or disallow the new --option with unspecified semantics
until you have that --option, and you are saying
Hmm, "reset --option" that does not work when it should work is a bug,
just like "reset --option" that does not refuse to work when it should
refuse is, and you cannot decide if you should allow a new --option until
you have it. Your "disallowing everything the code does not know about by
default" doesn't particularly sound safer to me. I'd suggest dropping it
from this patch.
It is perfectly fine to have a change like that, if it makes the logic
easier to follow with the updated repertoire when a new --option is added,
but not before.
>> An honest justification might have been "This change to disallow a mixed
>> reset in $GIT_DIR of a repository with a work tree will break existing
>> scripts, but I think it is not widely used _for such and such reasons_,
>> and can easily be worked around. On the other hand, this change vastly
>> simplifies the reimplementation of 'reset' _because X and Y and Z_".
>
> My opinion is that it works this way just by accident not by design (that's
> why I said "fragile").
And do you still think it is accident after I explained the difference
between the two for you (or perhaps you didn't read it)?
>> > This patch is also needed to speed up "git reset" by using
>> > unpack_tree() directly (instead of execing "git read-tree").
>>
>> It is very unclear _why_ it is "needed" from this description.
>
> The reason is that after the next patch, it will not fail in a bare
> repository,...
That sounds as if you want to change the definition of what the expected
behaviour is early, because you want to claim a regression you will later
introduce is not a regression. I hope that is not the case.
^ permalink raw reply
* Re: [PATCH v5 1/7] reset: do not accept a mixed reset in a .git dir
From: Junio C Hamano @ 2009-12-15 20:20 UTC (permalink / raw)
To: Christian Couder
Cc: git, Linus Torvalds, Johannes Schindelin, Stephan Beyer,
Daniel Barkalow, Jakub Narebski, Paolo Bonzini, Johannes Sixt,
Stephen Boyd
In-Reply-To: <200912152041.36194.chriscool@tuxfamily.org>
Christian Couder <chriscool@tuxfamily.org> writes:
> diff --git a/builtin-reset.c b/builtin-reset.c
> index 11d1c6e..ac3505b 100644
> --- a/builtin-reset.c
> +++ b/builtin-reset.c
> @@ -286,11 +286,15 @@ int cmd_reset(int argc, const char **argv, const char
> *pre
> if (reset_type == NONE)
> reset_type = MIXED; /* by default */
>
> - if ((reset_type == HARD || reset_type == MERGE)
> - && !is_inside_work_tree())
> + if (reset_type != SOFT && reset_type != MIXED
> + && !is_inside_work_tree())
> die("%s reset requires a work tree",
> reset_type_names[reset_type]);
>
> + if (reset_type == MIXED && is_bare_repository())
> + die("%s reset is not allowed in a bare repository",
> + reset_type_names[reset_type]);
This patch text itself makes sense, I think, except the first part.
^ permalink raw reply
* Re: [PATCH v5 1/7] reset: do not accept a mixed reset in a .git dir
From: Junio C Hamano @ 2009-12-15 20:25 UTC (permalink / raw)
To: Christian Couder
Cc: git, Linus Torvalds, Johannes Schindelin, Stephan Beyer,
Daniel Barkalow, Jakub Narebski, Paolo Bonzini, Johannes Sixt,
Stephen Boyd
In-Reply-To: <7vskbcyot5.fsf@alter.siamese.dyndns.org>
Junio C Hamano <gitster@pobox.com> writes:
>> The reason is that after the next patch, it will not fail in a bare
>> repository,...
>
> That sounds as if you want to change the definition of what the expected
> behaviour is early, because you want to claim a regression you will later
> introduce is not a regression. I hope that is not the case.
Hmm...
By "after the next patch, it will not fail in a bare repository",
did you mean "if the next patch blindly replaced an external call to
read-tree with an internal call to unpack_trees(), it will change the
behaviour, and we will end up allowing '--mixed in bare'. To prevent it
from happening, cmd_reset() should check that condition upfront"?
Then you were not trying to hide regressions (which makes me happier).
But then doesn't the change belong to the next patch, not this one?
^ permalink raw reply
* Git on QNX
From: Tarmigan @ 2009-12-15 21:23 UTC (permalink / raw)
To: Git Mailing List; +Cc: mkraai
Is anyone running git on QNX?
I have compiled and installed it (see config below) but it is failing
a number of the tests. I suspect that many of the later failures are
related to the earlier ones, so I think the earlier ones are probably
more interesting. Am I missing some makefile options?
Despite the test failures, I have been running the binaries
successfully for a couple days. I'm not planning on using git on QNX
very heavily or for very long, but as long as I'm on QNX I figured I
try to get git to work on it.
Here's the tests that are currently failing:
t0000.42 absolute path works as expected
t0006.14 parse date (2008-02-14 20:30:45)
t1002-read-tree-m-u-2way.sh lots of failures
t1100.4 compare commit
t1400.22,27,38,41
t1410.8 reflog delete
t2300.4,5 cd-to-toplevel
t3200.5,30 branch (maybe same as date in t0006.14?)
t3900.10,18 NO_ICONV?
t3901 NO_ICONV?
t4013-diff-various.sh lots of failures
t4201.3 shortlog encoding (NO_ICONV?)
t5000.13 tar tree validate file modification time
t5100-mailinfo.sh
t5510-fetch.sh
I got impatient after about t5600 because QNX in a virtual machine is
very slow. If anyone else wants to try it, you can download a QNX
.iso, get a free 30-day evaluation license and install and run in a
virtual machine.
I have started to look into t0000.42 a little. The symlinks seem to
get setup properly but make_absolute_path gives incorrect results:
# ls -l second/other
lrwxrwxrwx 1 root root 8 Dec 15 12:27 second/other -> ../first
# ../../test-path-utils make_absolute_path third/../second/other/.git/syml
/root/git/t/trash directory.t0000-basic/second/other/.git/syml
# ../../test-path-utils make_absolute_path second/other/.git/syml
/root/git/t/trash directory.t0000-basic/second/other/.git/syml
# ../../test-path-utils make_absolute_path second/other
/root/git/t/trash directory.t0000-basic/second/first <---- THIS LOOKS WRONG
# ../../test-path-utils make_absolute_path second/other/
/root/git/t/trash directory.t0000-basic/second/first <---- THIS LOOKS WRONG
# ../../test-path-utils make_absolute_path second/other/.git
../.git <---- THIS LOOKS WRONG
If anyone has any ideas or interest in the other failing tests, I can
provide more specific information.
Here's the diff that I applied to make git compile (cut-n-paste +
gmail warning) and it's on top of 9a424b27. I would like to properly
submit some bits of it once the tests are passing.
Thanks,
Tarmigan
--------
diff --git a/Makefile b/Makefile
index 4a1e5bc..ca78dcd 100644
--- a/Makefile
+++ b/Makefile
@@ -934,6 +934,30 @@ ifeq ($(uname_S),HP-UX)
NO_SYS_SELECT_H = YesPlease
SNPRINTF_RETURNS_BOGUS = YesPlease
endif
+ifeq ($(uname_S),QNX)
+ NO_OPENSSL=YesPlease
+ NO_CURL=YesPlease
+ NEEDS_SOCKET=YesPlease
+ NO_D_TYPE_IN_DIRENT=YesPlease
+ NO_STRCASESTR=YesPlease
+ NO_MEMMEM = YesPlease
+ NO_STRLCPY = YesPlease
+ NO_MKDTEMP = YesPlease
+ NO_MKSTEMPS = YesPlease
+ #NO_ICONV=YesPlease
+ OLD_ICONV=UnfortunatelyYes
+ NEEDS_LIBICONV=yes
+ ICONVDIR=/opt
+ NO_R_TO_GCC_LINKER=UnfortunatelyYes
+ NO_DEFLATE_BOUND=yes
+ FREAD_READS_DIRECTORIES=UnfortunatelyYes
+ NO_PTHREADS=UnfortunatelyYes
+ NO_MMAP=YesPlease
+ NO_NSEC=YesPlease
+ PERL_PATH=/opt/bin/perl
+ #NO_HSTRERROR = YesPlease
+ #NO_SYS_SELECT_H = YesPlease
+endif
ifeq ($(uname_S),Windows)
GIT_VERSION := $(GIT_VERSION).MSVC
pathsep = ;
diff --git a/builtin-fetch-pack.c b/builtin-fetch-pack.c
index 8ed4a6f..5cbc16c 100644
--- a/builtin-fetch-pack.c
+++ b/builtin-fetch-pack.c
@@ -778,7 +778,7 @@ static int fetch_pack_config(const char *var,
const char *value, void *cb)
return git_default_config(var, value, cb);
}
-static struct lock_file lock;
+static struct lock_file lockfile;
static void fetch_pack_setup(void)
{
@@ -958,14 +958,14 @@ struct ref *fetch_pack(struct fetch_pack_args *my_args,
)
die("shallow file was changed during fetch");
- fd = hold_lock_file_for_update(&lock, shallow,
+ fd = hold_lock_file_for_update(&lockfile, shallow,
LOCK_DIE_ON_ERROR);
if (!write_shallow_commits(&sb, 0)
|| write_in_full(fd, sb.buf, sb.len) != sb.len) {
unlink_or_warn(shallow);
- rollback_lock_file(&lock);
+ rollback_lock_file(&lockfile);
} else {
- commit_lock_file(&lock);
+ commit_lock_file(&lockfile);
}
strbuf_release(&sb);
}
diff --git a/git-compat-util.h b/git-compat-util.h
index 5c59687..857e938 100644
--- a/git-compat-util.h
+++ b/git-compat-util.h
@@ -42,6 +42,11 @@
/* Approximation of the length of the decimal representation of this type. */
#define decimal_length(x) ((int)(sizeof(x) * 2.56 + 0.5) + 1)
+#if defined(__QNX__)
+#define getpagesize() sysconf(_SC_PAGESIZE)
+#define SA_RESTART 0
+#endif
+
#if defined(__sun__)
/*
* On Solaris, when _XOPEN_EXTENDED is set, its header file
@@ -55,7 +60,7 @@
# else
# define _XOPEN_SOURCE 500
# endif
-#elif !defined(__APPLE__) && !defined(__FreeBSD__) &&
!defined(__USLC__) && !defined(_M_UNIX) && !defined(sgi)
+#elif !defined(__APPLE__) && !defined(__FreeBSD__) &&
!defined(__USLC__) && !defined(_M_UNIX) && !defined(sgi) &&
!defined(__QNX__)
#define _XOPEN_SOURCE 600 /* glibc2 and AIX 5.3L need 500, OpenBSD
needs 600 for S_ISLNK() */
#define _XOPEN_SOURCE_EXTENDED 1 /* AIX 5.3L needs this */
#endif
@@ -79,6 +84,7 @@
#include <stdlib.h>
#include <stdarg.h>
#include <string.h>
+#include <strings.h>
#include <errno.h>
#include <limits.h>
#include <sys/param.h>
^ permalink raw reply related
* New Proposal (simple) for Metadata in Git Commits: git-meta
From: Sam Elliott @ 2009-12-15 21:27 UTC (permalink / raw)
To: git
Hi,
I had this idea a day or so again, and have written a simple
implementation to storing some semi-structured data in a git commit
message. This means that it's much easier for data to be found and
scraped from a certain commit, for instance what issue numbers commits
refer to or close.
The entirety of the idea is expressed here: http://lenary.github.com/hackery/2009/12/git-meta/
I have so far built an implementation of a way to get the data out of
a commit. I am still investigating how to get this info into the
commit message before the git-commit command so that it doesn't have
to be entirely hand-written.
I was just looking for feedback and to see whether the mailing list
thinks this is a good idea or not? Any help would also be greatly
appreciated.
Thanks!
Sam
--
Sam Elliott
sam@lenary.co.uk
--
^ permalink raw reply
* Re: Git on QNX
From: Junio C Hamano @ 2009-12-15 21:42 UTC (permalink / raw)
To: Tarmigan; +Cc: Git Mailing List, mkraai
In-Reply-To: <905315640912151323s4b158565o2e74ce018b64dc72@mail.gmail.com>
Tarmigan <tarmigan+git@gmail.com> writes:
> diff --git a/builtin-fetch-pack.c b/builtin-fetch-pack.c
> index 8ed4a6f..5cbc16c 100644
> --- a/builtin-fetch-pack.c
> +++ b/builtin-fetch-pack.c
> @@ -778,7 +778,7 @@ static int fetch_pack_config(const char *var,
> const char *value, void *cb)
> return git_default_config(var, value, cb);
> }
>
> -static struct lock_file lock;
> +static struct lock_file lockfile;
>
> static void fetch_pack_setup(void)
> {
> @@ -958,14 +958,14 @@ struct ref *fetch_pack(struct fetch_pack_args *my_args,
> )
> die("shallow file was changed during fetch");
>
> - fd = hold_lock_file_for_update(&lock, shallow,
> + fd = hold_lock_file_for_update(&lockfile, shallow,
> LOCK_DIE_ON_ERROR);
> if (!write_shallow_commits(&sb, 0)
> || write_in_full(fd, sb.buf, sb.len) != sb.len) {
> unlink_or_warn(shallow);
> - rollback_lock_file(&lock);
> + rollback_lock_file(&lockfile);
> } else {
> - commit_lock_file(&lock);
> + commit_lock_file(&lockfile);
> }
> strbuf_release(&sb);
> }
Is this because QNX uses "lock" as some global identifier for some other
purpose? I think moving the file-scope-static definition to the scope
it is used in without renaming would make a cleaner patch.
> diff --git a/git-compat-util.h b/git-compat-util.h
> index 5c59687..857e938 100644
> --- a/git-compat-util.h
> +++ b/git-compat-util.h
> @@ -79,6 +84,7 @@
> #include <stdlib.h>
> #include <stdarg.h>
> #include <string.h>
> +#include <strings.h>
> #include <errno.h>
> #include <limits.h>
> #include <sys/param.h>
Other hunks are QNX specific enough but this hunk is worrisome; you cannot
tell how you are hurting other platforms with this change. Can you tell
declarations of which functions are missing on QNX without this change?
^ permalink raw reply
* Re: New Proposal (simple) for Metadata in Git Commits: git-meta
From: Shawn O. Pearce @ 2009-12-15 22:05 UTC (permalink / raw)
To: Sam Elliott; +Cc: git
In-Reply-To: <93857A5A-744E-4A7C-B42D-23A56A48AAF7@lenary.co.uk>
Sam Elliott <sam@lenary.co.uk> wrote:
> I had this idea a day or so again, and have written a simple
> implementation to storing some semi-structured data in a git commit
> message. This means that it's much easier for data to be found and
> scraped from a certain commit, for instance what issue numbers commits
> refer to or close.
So from your web page, this is basically just YAML shoved into the
footer of the message:
--8<--
Written half of the functionality. Namely the querying half.
---git-meta---
awesome: true
Github:
user: lenary
---git-meta---
-->8--
Why do we need the --git-meta-- delimiter lines?
JGit and Gerrit Code Review have already been following Git tradition
by using footer messages as metadata. E.g. we have lines like:
--8<--
init: Don't abort on empty directory
The following sequence should work:
mkdir testgit
java -jar gerrit.war init -d testgit
Since testgit is empty, it should be acceptable for us to populate the
directory with our files.
Bug: issue 358
Change-Id: Ia85f31802066f8d39b042d3d057d33950a5035fd
Signed-off-by: Shawn O. Pearce <sop@google.com>
-->8--
The JGit commit message parser has special logic to handle lines
that smell like one of these tag lines. So long as there is no
blank line in the footer paragraph, each of these tags can be read
and processed. Continuation lines should start with whitespace.
I don't remember my YAML well enough, but isn't this existing
standard still parseable by a YAML processor?
If you dropped the --git-meta-- tags above, JGit would happily
recognize the awesome: and Github: tags, but it might need a bit
more work to recognize the nested user: tag. Also, you'd be able
to use git-meta on the git and Linux kernel repositories to pull
out and work with Signed-off-by, Acked-by, etc.
--
Shawn.
^ permalink raw reply
* Re: Git on QNX
From: Tarmigan @ 2009-12-15 22:13 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Git Mailing List, mkraai
In-Reply-To: <7v6387zzfi.fsf@alter.siamese.dyndns.org>
On Tue, Dec 15, 2009 at 1:42 PM, Junio C Hamano <gitster@pobox.com> wrote:
> Tarmigan <tarmigan+git@gmail.com> writes:
>
>> diff --git a/builtin-fetch-pack.c b/builtin-fetch-pack.c
>> index 8ed4a6f..5cbc16c 100644
>> --- a/builtin-fetch-pack.c
>> +++ b/builtin-fetch-pack.c
>> @@ -778,7 +778,7 @@ static int fetch_pack_config(const char *var,
>> const char *value, void *cb)
>> return git_default_config(var, value, cb);
>> }
>>
>> -static struct lock_file lock;
>> +static struct lock_file lockfile;
>>
>> static void fetch_pack_setup(void)
>> {
>> @@ -958,14 +958,14 @@ struct ref *fetch_pack(struct fetch_pack_args *my_args,
>> )
>> die("shallow file was changed during fetch");
>>
>> - fd = hold_lock_file_for_update(&lock, shallow,
>> + fd = hold_lock_file_for_update(&lockfile, shallow,
>> LOCK_DIE_ON_ERROR);
>> if (!write_shallow_commits(&sb, 0)
>> || write_in_full(fd, sb.buf, sb.len) != sb.len) {
>> unlink_or_warn(shallow);
>> - rollback_lock_file(&lock);
>> + rollback_lock_file(&lockfile);
>> } else {
>> - commit_lock_file(&lock);
>> + commit_lock_file(&lockfile);
>> }
>> strbuf_release(&sb);
>> }
>
> Is this because QNX uses "lock" as some global identifier for some other
> purpose? I think moving the file-scope-static definition to the scope
> it is used in without renaming would make a cleaner patch.
Yes, exactly that reason. I agree the declaration should just move
into fetch_pack() as a static, but I didn't realize that until after I
had renamed all of the uses, and I was lazy as this was not for
submission.
>
>> diff --git a/git-compat-util.h b/git-compat-util.h
>> index 5c59687..857e938 100644
>> --- a/git-compat-util.h
>> +++ b/git-compat-util.h
>> @@ -79,6 +84,7 @@
>> #include <stdlib.h>
>> #include <stdarg.h>
>> #include <string.h>
>> +#include <strings.h>
>> #include <errno.h>
>> #include <limits.h>
>> #include <sys/param.h>
>
> Other hunks are QNX specific enough but this hunk is worrisome; you cannot
> tell how you are hurting other platforms with this change. Can you tell
> declarations of which functions are missing on QNX without this change?
strcasecmp()
http://www.opengroup.org/onlinepubs/000095399/functions/strcasecmp.html
I agree that this change could affect other platforms and they've
gotten along fine without it so far. I'm surprised no others have
needed it. Would it be better wrapped in a #ifdef?
Thanks,
Tarmigan
^ permalink raw reply
* core.autocrlf & Cygwin - files incorrectly flagged as modified
From: David Antliff @ 2009-12-15 22:24 UTC (permalink / raw)
To: git
I approached the Cygwin mailing list about this problem, and the package
maintainer suggested I ask here as well, in case someone can shed some light on
this.
I am using git-1.6.4.2 (as part of Cygwin-1.7 beta) and I've observed some
behaviour that seems wrong to me.
When we deployed git on Cygwin, we decided to set core.autocrlf=true, as many of
our users are working with DOS/Windows files (CRLF endings). Some users are
using Linux and working on the same code. I'm not actually sure why we chose to
use this setting - there's a lot of conflicting advice around. I think the final
decision was made so that kdiff3 would operate correctly. However we did go to
lengths to ensure that everyone is using the same configuration setting.
The problem is that sometimes, after a git-clone, the output of git-status and
git-diff shows entire files as being different. However these files have not
been modified by the user - only git has had a chance to change them (due to
autocrlf=true). But surely if git has converted the file automatically, it
should know that it has to compensate for this when comparing with the local
repository?
And I think it usually does this and almost all files behave properly. The
problem arises when the source-controlled file contains lines with trailing
whitespace. In this situation, git-diff clearly indicates a difference and this
blocks merges and checkouts.
I suspect what is happening is that the line conversion routine in git might be
stripping trailing whitespace, as well as converting the line endings. This
operation is not properly accounted for in the reverse direction, and the file
is flagged as modified.
The Cygwin git package maintainer has indicated that he thinks this might be a
bug: http://cygwin.com/ml/cygwin/2009-12/msg00466.html
Also, as cloned files are converted to DOS-line-endings, by default Cygwin's
bash cannot run any scripts as they have the wrong line endings. I have to set
the 'permanent' bash variable SHELLOPTS to include 'igncr' before bash scripts
can run. Perhaps this is wrong and git on Cygwin (with binary mounts) should be
converting to UNIX line endings instead?
At one point I tried switching off core.autocrlf for myself but this caused a
lot of conflicts due to mismatched line-endings. It seems to me that if we want
to switch to this, *everyone* has to do it at once.
I'd like to know whether this is a problem worthy of further investigation,
whether it should fall in the git or Cygwin camp, and whether I really ought to
be using autocrlf=true please.
^ permalink raw reply
* git svn clone just stops
From: Mark Jerkovic @ 2009-12-15 22:19 UTC (permalink / raw)
To: git
Hi all,
I am new to Git and I am attempting to clone a SVN repository
(containing approximately 60,000 commits) to Git.
Using Git v1.6.0.4 with the following command:
git svn clone https://path/to/svn/repo/trunk project.git
--authors-file=svnauthors.txt --no-metadata
the process just ends without any messages and the Git repository is
empty. I have attempted this four times already, and each time it has
stopped after a different revision, so I can't pin it down to a
particular commit.
Has anyone experienced this before? Is there a log anywhere that
records what is happening during this process?
Thanks,
Mark.
^ permalink raw reply
* Re: am fails to apply patches for files with CRLF lineendings
From: Andreas Schwab @ 2009-12-15 22:52 UTC (permalink / raw)
To: Björn Steinbrink
Cc: Brandon Casey, Junio C Hamano, Brandon Casey, jk, git
In-Reply-To: <20091215012514.GB1317@atjola.homenet>
Björn Steinbrink <B.Steinbrink@gmx.de> writes:
> Right. And checking, after sending a patch containing CRs with mutt, it
> lost those CRs. Even the local copy saved directly by mutt, which didn't
> leave my box, lacks the CRs. So it seems basically impossible to send
> patches to CRLF files inline.
If you want to send mail containing a bare CR you need to encode it.
Andreas.
--
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5
"And now for something completely different."
^ permalink raw reply
* Re: Fwd: am fails to apply patches for files with CRLF lineendings
From: Andreas Schwab @ 2009-12-15 23:18 UTC (permalink / raw)
To: Brandon Casey; +Cc: git
In-Reply-To: <ee63ef30912141809k27bc73edp20abddd5e9c7c063@mail.gmail.com>
Brandon Casey <drafnel@gmail.com> writes:
> But isn't each email in the mbox file supposed to be RFC-2822
> formatted anyway? If so, then my reading of RFC-2822 says that there
> should only be CRLF everywhere and no bare CR or bare LF. But maybe
> everyone has just been ignoring that part of RFC-2822? I'm not an
> email expert, so I really don't know.
RFC 2822 specifies a *transport* format, where each text lines is
represented by terminating it with CRLF. Any other use is outside the
scope of that RFC. The mbox format normally uses the native format for
text files, which means LF terminated lines when used under Unix.
Andreas.
--
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5
"And now for something completely different."
^ permalink raw reply
* Re: [PATCH 1/2] filter-branch: remove an unnecessary use of 'git read-tree'
From: Junio C Hamano @ 2009-12-16 0:19 UTC (permalink / raw)
To: Johannes Sixt; +Cc: Johannes Schindelin, Git Mailing List
In-Reply-To: <4B274BDE.8000504@viscovery.net>
Johannes Sixt <j.sixt@viscovery.net> writes:
> From: Johannes Sixt <j6t@kdbg.org>
>
> The intent of this particular call to 'git read-tree' was to fill an
> index. But in fact, it only allocated an empty index. Later in the
> program, the index is filled anyway by calling read-tree with specific
> commits, and considering that elsewhere the index is even removed (i.e.,
> it is not relied upon that the index file exists), this first call of
> read-tree is completely redundant.
>
> Signed-off-by: Johannes Sixt <j6t@kdbg.org>
Very true. The only thing it would have done is to error out early when
the user mistakenly tried to run the command in a directory in which s/he
does not have write access to, before running potentially expensive
commit listing with rev-list, but then the user would have failed to
create the tempdir before that to begin with.
Will queue, but it doesn't seem urgent to put it in 1.6.6 or 1.6.5.X
maint (i.e. nothing is broken without this patch).
> Calling read-tree without arguments is not allowed according to the
> documentation.
I think saying "is not allowed" is going a bit too far. The documentation
simply does not list it as a _useful_ thing to do, that's all.
By the way, I notice that the command still insists on being run in a
clean work tree with a clean index at the beginning, but isn't everything
done inside the tempdir (i.e. ".git-rewrite" by default) these days,
including the temporary work tree tree-filter creates with "checkout-index
-fqua"? It is obviously not a topic of this patch, but we may want to
stop doing that if we are not rewriting the current commit (which we will
know by the time we list the commits to be rewritten with rev-list before
actually starting to rewrite).
^ permalink raw reply
* Re: am fails to apply patches for files with CRLF lineendings
From: Andreas Schwab @ 2009-12-16 0:38 UTC (permalink / raw)
To: Björn Steinbrink
Cc: Brandon Casey, Junio C Hamano, Brandon Casey, jk, git
In-Reply-To: <m26387voiy.fsf@igel.home>
Andreas Schwab <schwab@linux-m68k.org> writes:
> Björn Steinbrink <B.Steinbrink@gmx.de> writes:
>
>> Right. And checking, after sending a patch containing CRs with mutt, it
>> lost those CRs. Even the local copy saved directly by mutt, which didn't
>> leave my box, lacks the CRs. So it seems basically impossible to send
>> patches to CRLF files inline.
>
> If you want to send mail containing a bare CR you need to encode it.
Btw, this mail had a stray CR added to the last line when I sent it out
(properly encoded as quoted-printable), but that didn't make it through
gmane. :-)
Andreas.
--
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5
"And now for something completely different."
^ 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