* Fwd: am fails to apply patches for files with CRLF lineendings
From: Brandon Casey @ 2009-12-15 2:09 UTC (permalink / raw)
To: git
In-Reply-To: <ee63ef30912141650ie05baf4kab8505adf160c62e@mail.gmail.com>
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).
---------- Forwarded message ----------
From: Brandon Casey <drafnel@gmail.com>
Date: Mon, Dec 14, 2009 at 6:50 PM
Subject: Re: am fails to apply patches for files with CRLF lineendings
To: Junio C Hamano <gitster@pobox.com>
Cc: Brandon Casey <brandon.casey.ctr@nrlssc.navy.mil>, Björn
Steinbrink <B.Steinbrink@gmx.de>, jk@silentcow.com,
git@vger.kernel.org
On Mon, Dec 14, 2009 at 5:22 PM, Junio C Hamano <gitster@pobox.com> wrote:
>
> Brandon Casey <brandon.casey.ctr@nrlssc.navy.mil> writes:
>
> > My understanding of the problem is that rfc2822 dictates that...
>
> I think the fundamental problem is that what MUA uses as the internal
> storage format doesn't necessarily have to even be RFC-2822, which only
> specifies what should be on-the-wire.
If CRLF is what is on-the-wire, how can the MUA tell whether the
original was also CRLF or whether it was only LF? My assumption was
that the MUA cannot tell, and that things worked for most people
because those people who wanted LF terminated output were on platforms
that used LF termination and their MUA produced output using the
native line termination. Things broke recently for some people since
thunderbird devels decided to start saving emails with CRLF
termination on linux.
>
> The blamed commit took things too
> far.
>
> It actually is the norm to use LF as the line terminator in the body text
> in saved messages (and trailing CR as a true part of the payload), and
> "am" traditionally used that definition. It is meant to read from "mbox"
> format to begin with.
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.
>
> Before the blamed commit, "am" took what was given literally, and it
> treated the trailing CR as part of the payload in a text file, each of
> whose line is LF terminated. This meant that if you sent and your MUA
> didn't corrupt, or more importantly if you ran format-patch yourself to
> produce a patch on content with CRLF line endings and fed it to am without
> any e-mail involved, your CRLF would have been preserved. So in that
> sense, unlike what you said in your message, the blamed commit didn't
> decide that the line termination must be LF. It decided that the line
> termination does not matter, which is a lot worse.
I think it is more correct to say that the line termination in an
email is ambiguous. CRLF does not necessarily mean that the original
had CRLF line termination if RFC-2822 is followed explicitly.
> As long as the use of CR is an internal storage matter and "Save As..."
> doesn't add extra CR that wasn't in the original contents, I wouldn't say
> that such a MUA is broken. In the use case that led to the blamed commit,
> the user is choosing to read directly from the internal storage of MUA,
> bypassing its "Save As..." interface meant to be used to externalize the
> messages,
No, we're using "Save As..." in thunderbird, and it saves with CRLF
line endings. I don't really care for thunderbird and its proclivity
for munging my emails and _not_ doing-the-right-thing in my opinion.
Maybe someone can suggest a mail client that can use imap and provide
the nice sorting of emails into folders like thunderbird does.
-brandon
^ permalink raw reply
* Re: git-reflog 70 minutes at 100% cpu and counting
From: Eric Paris @ 2009-12-15 2:11 UTC (permalink / raw)
To: Nicolas Pitre; +Cc: Jeff King, git
In-Reply-To: <alpine.LFD.2.00.0912141924030.23173@xanadu.home>
On Mon, 2009-12-14 at 19:26 -0500, Nicolas Pitre wrote:
> On Mon, 14 Dec 2009, Eric Paris wrote:
>
> > On Mon, 2009-12-14 at 16:23 -0500, Jeff King wrote:
> > > On Mon, Dec 14, 2009 at 04:20:29PM -0500, Eric Paris wrote:
> > >
> > > > Updated to git-1.6.5.3-1 from Fedora rawhide and still git reflog ran
> > > > for >5 minutes at 100% cpu (I killed it, it didn't finish)
> > > >
> > > > I'm pushing a copy of the whole repo (all 1.9G after bzip compression)
> > > > to
> > > >
> > > > http://people.redhat.com/~eparis/git-tar/
> > >
> > > Wowzers, that's big. Can you send just what's in .git?
> >
> > So I zipped up just .git 1.2G. I did a make clean and zipped up the
> > whole repo 1.3G.
> >
> > Just started pushing the 1.3G file.
> >
> > Maybe having a .git directory that large is the problem?
>
> Shouldn't be, unless your repo is really badly packed.
>
> What's the output of 'git count-objects -v' ?
count: 87065
size: 866744
in-pack: 1203497
packs: 148
size-pack: 976474
prune-packable: 1611
garbage: 0
It's not home movies :) . It's a kernel trees with about 5
'upstream' trees that are remotes, which I update daily. One of the
remotes constantly rebases every day starting with Linus' tree and
pulling in about 150+ branches of work from others all of which might
rebase. I have (needlessly) the tags he keeps of that repo every day.
I daily rebase my work on top of that constantly rebasing tree
(linux-next) using stgit.
I noticed just blindly poking at sizes in my .git/object/pack that the
largest pack is a lot larger than the second and third largest....
-r--r--r-- 1 paris paris 108031039 Feb 12 2009 pack-71a9c0f08c76b8ffd1cf0a14d7cfe991fbc9db80.pack
-r--r--r-- 1 paris paris 32670479 Apr 7 2009 pack-5c8333301012d9b70d70648b287cf540afcc63ed.pack
-r--r--r-- 1 paris paris 26728958 Dec 30 2008 pack-fb8ceb5a33d9881fe771860c6006f55f73ecdf65.pack
And all total there is almost 1G of data in .git/object/pack
If the answer really is that I just have too much data and it can't be
handled, I'm fine exporting my patches getting some clean trees and
starting over till I get in this situation again, but if it really is a
problem/bug that can be solved, the full tar ball of my repo is at
http://people.redhat.com/~eparis/git-tar/
-Eric
^ permalink raw reply
* Re: am fails to apply patches for files with CRLF lineendings
From: Junio C Hamano @ 2009-12-15 2:12 UTC (permalink / raw)
To: Brandon Casey; +Cc: Brandon Casey, Björn Steinbrink, jk, git
In-Reply-To: <ee63ef30912141650ie05baf4kab8505adf160c62e@mail.gmail.com>
Brandon Casey <drafnel@gmail.com> writes:
>> It actually is the norm to use LF as the line terminator in the body text
>> in saved messages (and trailing CR as a true part of the payload), and
>> "am" traditionally used that definition. It is meant to read from "mbox"
>> format to begin with.
>
> But isn't each email in the mbox file supposed to be RFC-2822 formatted
> anyway?
If you are talking about the same "mbox" I was talking about, which is
what I see when I peek "/var/mail/junio", then the answer is no. Their
lines are terminated with a LF, and if you insert CR at the end of the
line it would appear as true payload. DOSsy boxes can have C:\mail\user
or whatever that has DOS text, of course, so there is no "supposed to be".
Having said that, it does not matter an iota in the real world if somebody
declares on _this list_ that it a bug that Thunderbird spits out CRLF text
in response to "Save As..." on platforms where LF is the natural line
terminator [*1*]. Whether it is a bug or not, we still need to help
people with such a program without breaking others.
I saw "peeking the line ending of the first line" as suggested as a
solution, and my gut feeling, without thinking too much about it, is
that it is likely to be the right thing to do, especially if we do
both the check and the necessary conversion in either mailinfo or even
in mailsplit.
[Footnote]
*1* It is a different matter if it was done on _their_ mailing list, and
it would even be better if such a discussion on _their_ mailing list
resulted in a fix over there.
^ permalink raw reply
* Re: git-reflog 70 minutes at 100% cpu and counting
From: Jeff King @ 2009-12-15 2:39 UTC (permalink / raw)
To: Eric Paris; +Cc: git
In-Reply-To: <1260825629.9379.56.camel@localhost>
On Mon, Dec 14, 2009 at 04:20:29PM -0500, Eric Paris wrote:
> I'm pushing a copy of the whole repo (all 1.9G after bzip compression)
> to
>
> http://people.redhat.com/~eparis/git-tar/
>
> But it's going to take a couple hours.
Holy cow. Almost 150 packs, and that's not even everything. The tarball
is missing a bunch of objects, because it points to your kernel-1 as an
alternate. So I suspect we would need that, as well, to recreate.
-Peff
^ permalink raw reply
* Re: Giving command line parameter to textconv command?
From: Nanako Shiraishi @ 2009-12-15 3:11 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Jeff King
In-Reply-To: <7vvdg9ceud.fsf@alter.siamese.dyndns.org>
Quoting Junio C Hamano <gitster@pobox.com>
> Nanako Shiraishi <nanako3@lavabit.com> writes:
>
>> I need this extra script because setting 'nkf -w' for
>> textconv like this
>>
>> [diff "eucjp"]
>> textconv = nkf -w
>>
>> gives an error.
>>
>> % diff --git a/hello.txt b/hello.txt
>> index 696acd7..f07aa1a 100644
>> error: cannot run nkf -w: No such file or directory
>> error: error running textconv command 'nkf -w'
>> fatal: unable to read files to diff
>>
>> Could you fix textconv so that it can be given parameters?
>
> 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.
>
> We might need to introduce diff.*.xtextconv or something.
I experimented with other variables (eg. smudge and clean) and
they honor their command line arguments. If textconv is the only
setting that doesn't, the change may be easier to justify.
By the way, there should be a better description of the filters
in the gitattributes documentation, similar to how [diff "name"]
sections in the .git/config file are described.
-- >8 --
Subject: Illustrate "filter" attribute with an example
The example was taken from aa4ed402c9721170fde2e9e43c3825562070e65e
(Add 'filter' attribute and external filter driver definition).
Signed-off-by: Nanako Shiraishi <nanako3@lavabit.com>
---
diff --git a/Documentation/gitattributes.txt b/Documentation/gitattributes.txt
index 1f472ce..5a45e51 100644
--- a/Documentation/gitattributes.txt
+++ b/Documentation/gitattributes.txt
@@ -197,6 +197,25 @@ intent is that if someone unsets the filter driver definition,
or does not have the appropriate filter program, the project
should still be usable.
+For example, in .gitattributes, you would assign the `filter`
+attribute for paths.
+
+------------------------
+*.c filter=indent
+------------------------
+
+Then you would define a "filter.indent.clean" and "filter.indent.smudge"
+configuration in your .git/config to specify a pair of commands to
+modify the contents of C programs when the source files are checked
+in ("clean" is run) and checked out (no change is made because the
+command is "cat").
+
+------------------------
+[filter "indent"]
+ clean = indent
+ smudge = cat
+------------------------
+
Interaction between checkin/checkout attributes
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
--
Nanako Shiraishi
http://ivory.ap.teacup.com/nanako3/
^ permalink raw reply related
* Re: git-reflog 70 minutes at 100% cpu and counting
From: Nicolas Pitre @ 2009-12-15 3:44 UTC (permalink / raw)
To: Eric Paris; +Cc: Jeff King, git
In-Reply-To: <1260843111.9379.86.camel@localhost>
On Mon, 14 Dec 2009, Eric Paris wrote:
> On Mon, 2009-12-14 at 19:26 -0500, Nicolas Pitre wrote:
> > On Mon, 14 Dec 2009, Eric Paris wrote:
> >
> > > Maybe having a .git directory that large is the problem?
> >
> > Shouldn't be, unless your repo is really badly packed.
> >
> > What's the output of 'git count-objects -v' ?
>
> count: 87065
> size: 866744
> in-pack: 1203497
> packs: 148
> size-pack: 976474
So basically 87K loose objects occupying 846 MB and 1.2M packed objects
occupying 954 MB across 148 packs. That's an horrible repository
layout which would definitely gain by being repacked.
> I noticed just blindly poking at sizes in my .git/object/pack that the
> largest pack is a lot larger than the second and third largest....
That's expected.
> And all total there is almost 1G of data in .git/object/pack
>
> If the answer really is that I just have too much data and it can't be
> handled,
Nope. git should handle that kind of data set perfectly fine. And once
repacked, you should end up with a single pack containing everything and
the total size of your .git/objects directory will probably shrink by
50% or more.
But to be able to repack, your 'git reflog' needs to work correctly, and
the problem is unlikely to be related to the repository size.
Nicolas
^ permalink raw reply
* Re: git-reflog 70 minutes at 100% cpu and counting
From: Nicolas Pitre @ 2009-12-15 3:50 UTC (permalink / raw)
To: Jeff King; +Cc: Eric Paris, git
In-Reply-To: <20091215023918.GA14689@coredump.intra.peff.net>
On Mon, 14 Dec 2009, Jeff King wrote:
> On Mon, Dec 14, 2009 at 04:20:29PM -0500, Eric Paris wrote:
>
> > I'm pushing a copy of the whole repo (all 1.9G after bzip compression)
> > to
> >
> > http://people.redhat.com/~eparis/git-tar/
> >
> > But it's going to take a couple hours.
>
> Holy cow. Almost 150 packs, and that's not even everything. The tarball
> is missing a bunch of objects, because it points to your kernel-1 as an
> alternate. So I suspect we would need that, as well, to recreate.
Hmmm... Rebasing repositories mixed with alternates... I wonder if the
infinite loop might not actually be due to a delta cycle, especially if
the alternate is also rebasing.
So having the alternate, too, would certainly be interesting.
Nicolas
^ permalink raw reply
* Re: [PATCH 03/23] Introduce "skip-worktree" bit in index, teach Git to get/set this bit
From: Nguyen Thai Ngoc Duy @ 2009-12-15 3:51 UTC (permalink / raw)
To: Greg Price; +Cc: git
In-Reply-To: <20091214230619.GA30538@dr-wily.mit.edu>
2009/12/15 Greg Price <price@ksplice.com>:
> I confess I can't tell how the skip-worktree bit does differ from
> assume-unchanged. Is its 'goal' different only in that you have a
> different motivation for introducing it, or does it actually have a
> different effect -- and what is that different effect?
On the fun side, you could use both bits in the same worktree, to
narrow your worktree and have some assume-unchanged files.
Another difference is that with assume-unchanged bit, you make a
promise to Git that those assume-unchanged files are "good", Git does
not have to care for them. If somehow you violate the promise, Git can
harm your files on worktree.
--
Duy
^ permalink raw reply
* Re: git-reflog 70 minutes at 100% cpu and counting
From: Nicolas Pitre @ 2009-12-15 3:58 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Eric Paris, Jeff King, git
In-Reply-To: <7vk4wpax99.fsf@alter.siamese.dyndns.org>
On Mon, 14 Dec 2009, Junio C Hamano wrote:
> Nicolas Pitre <nico@fluxnic.net> writes:
>
> > On Mon, 14 Dec 2009, Eric Paris wrote:
> >
> >> On Mon, 2009-12-14 at 16:23 -0500, Jeff King wrote:
> >> > On Mon, Dec 14, 2009 at 04:20:29PM -0500, Eric Paris wrote:
> >> >
> >> > > Updated to git-1.6.5.3-1 from Fedora rawhide and still git reflog ran
> >> > > for >5 minutes at 100% cpu (I killed it, it didn't finish)
> >> > >
> >> > > I'm pushing a copy of the whole repo (all 1.9G after bzip compression)
> >> > > to
> >> > >
> >> > > http://people.redhat.com/~eparis/git-tar/
> >> >
> >> > Wowzers, that's big. Can you send just what's in .git?
> >>
> >> So I zipped up just .git 1.2G. I did a make clean and zipped up the
> >> whole repo 1.3G.
> >>
> >> Just started pushing the 1.3G file.
> >>
> >> Maybe having a .git directory that large is the problem?
> >
> > Shouldn't be, unless your repo is really badly packed.
> >
> > What's the output of 'git count-objects -v' ?
>
> Didn't somebody say that the trace hints an infinite loop not "slow
> because of bad packing"?
Maybe. But I was curious about the size too, which turns out to be
really bad packing. Of course bad packing shouldn't affect the
correctness of the repository.
Nicolas
^ permalink raw reply
* Re: am fails to apply patches for files with CRLF lineendings
From: Brandon Casey @ 2009-12-15 3:59 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Brandon Casey, Björn Steinbrink, jk, git
In-Reply-To: <7vfx7d7zpp.fsf@alter.siamese.dyndns.org>
On Mon, Dec 14, 2009 at 8:12 PM, Junio C Hamano <gitster@pobox.com> wrote:
> Brandon Casey <drafnel@gmail.com> writes:
>
>>> It actually is the norm to use LF as the line terminator in the body text
>>> in saved messages (and trailing CR as a true part of the payload), and
>>> "am" traditionally used that definition. It is meant to read from "mbox"
>>> format to begin with.
>>
>> But isn't each email in the mbox file supposed to be RFC-2822 formatted
>> anyway?
>
> If you are talking about the same "mbox" I was talking about, which is
> what I see when I peek "/var/mail/junio", then the answer is no.
Yes, that is what I was talking about, but I did not know whether the
individual mails which are separated by "From user@host ..." were
supposed to be in RFC-2822 format or not.
> Their lines are terminated with a LF, and if you insert CR at the end of the
> line it would appear as true payload.
How do you insert CR at the end of the line? Can you use mutt or
something like it to send a mail which contains a CR? I have tried,
and I have not been able to do so. I have tried mutt, mailx, and
sendmail. For sendmail, I of course constructed the email headers by
hand and piped it through sendmail. The CRLF in my tests were
converted to LF by the time they reached /var/mail/casey.
> DOSsy boxes can have C:\mail\user
> or whatever that has DOS text, of course, so there is no "supposed to be".
>
> Having said that, it does not matter an iota in the real world if somebody
> declares on _this list_ that it a bug that Thunderbird spits out CRLF text
> in response to "Save As..." on platforms where LF is the natural line
> terminator [*1*].
I'm not sure it is a bug, just a change in behavior.
> Whether it is a bug or not, we still need to help
> people with such a program without breaking others.
I agree.
> I saw "peeking the line ending of the first line" as suggested as a
> solution, and my gut feeling, without thinking too much about it, is
> that it is likely to be the right thing to do, especially if we do
> both the check and the necessary conversion in either mailinfo or even
> in mailsplit.
Yes, I think it will work as a work-around, unfortunately I cannot
work on implementing this at the moment. I think the better solution,
if it is not too costly, is to detect the presence of CR and produce a
binary patch that can be sent through email and applied by git-am.
-brandon
^ permalink raw reply
* Re: git-reflog 70 minutes at 100% cpu and counting
From: Eric Paris @ 2009-12-15 4:26 UTC (permalink / raw)
To: Nicolas Pitre; +Cc: Jeff King, git
In-Reply-To: <alpine.LFD.2.00.0912142245240.23173@xanadu.home>
On Mon, 2009-12-14 at 22:50 -0500, Nicolas Pitre wrote:
> On Mon, 14 Dec 2009, Jeff King wrote:
>
> > On Mon, Dec 14, 2009 at 04:20:29PM -0500, Eric Paris wrote:
> >
> > > I'm pushing a copy of the whole repo (all 1.9G after bzip compression)
> > > to
> > >
> > > http://people.redhat.com/~eparis/git-tar/
> > >
> > > But it's going to take a couple hours.
> >
> > Holy cow. Almost 150 packs, and that's not even everything. The tarball
> > is missing a bunch of objects, because it points to your kernel-1 as an
> > alternate. So I suspect we would need that, as well, to recreate.
>
> Hmmm... Rebasing repositories mixed with alternates... I wonder if the
> infinite loop might not actually be due to a delta cycle, especially if
> the alternate is also rebasing.
>
> So having the alternate, too, would certainly be interesting.
The alternative repo is slowing pushing up to that same location. That
tar is 855838982, so just a tad bit smaller.
-Eric
^ permalink raw reply
* Re: Giving command line parameter to textconv command?
From: Junio C Hamano @ 2009-12-15 5:56 UTC (permalink / raw)
To: Nanako Shiraishi; +Cc: git, Jeff King
In-Reply-To: <20091215121110.6117@nanako3.lavabit.com>
Nanako Shiraishi <nanako3@lavabit.com> writes:
> I experimented with other variables (eg. smudge and clean) and
> they honor their command line arguments. If textconv is the only
> setting that doesn't, the change may be easier to justify.
Yes, as you found out, convert.c::apply_filter() is aware of the command
line arguments.
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.
- 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.
- merge-index.c::merge_entry() also defines a strict order and semantics
to its parameters, but similar to GIT_EXTERNAL_DIFF, it is not
something you would throw a ready-made program (like an editor or an
pager) and expect it to work, so it wouldn't be an issue either.
Hooks do not even take arbitrary command line arguments, so we don't have
to worry about them.
So it does look like that textconv is the only odd-man out.
^ permalink raw reply
* Re: am fails to apply patches for files with CRLF lineendings
From: Sverre Rabbelier @ 2009-12-15 6:33 UTC (permalink / raw)
To: Brandon Casey; +Cc: git
In-Reply-To: <ee63ef30912141809k27bc73edp20abddd5e9c7c063@mail.gmail.com>
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.
--
Cheers,
Sverre Rabbelier
^ permalink raw reply
* [PATCH] octopus: make merge process simpler to follow
From: Stephen Boyd @ 2009-12-15 6:49 UTC (permalink / raw)
To: git; +Cc: Junio C Hamano, Johannes Sixt, Jari Aalto
In-Reply-To: <7vk4wrrkce.fsf@alter.siamese.dyndns.org>
Its not very easy to understand what heads are being merged given
the current output of an octopus merge. Fix this by replacing the
sha1 with the (usually) better description in GITHEAD_<SHA1>.
Suggested-by: Jari Aalto <jari.aalto@cante.net>
Signed-off-by: Stephen Boyd <bebarino@gmail.com>
---
Thanks both. Here's a replacement. Let me know if you want a reroll.
git-merge-octopus.sh | 11 +++++++----
t/t7602-merge-octopus-many.sh | 33 +++++++++++++++++++++++++++++++++
2 files changed, 40 insertions(+), 4 deletions(-)
diff --git a/git-merge-octopus.sh b/git-merge-octopus.sh
index 825c52c..417e8fb 100755
--- a/git-merge-octopus.sh
+++ b/git-merge-octopus.sh
@@ -61,12 +61,15 @@ do
exit 2
esac
+ eval pretty_name="\$GITHEAD_$SHA1"
+ : ${pretty_name:=$SHA1}
+
common=$(git merge-base --all $SHA1 $MRC) ||
- die "Unable to find common commit with $SHA1"
+ die "Unable to find common commit with $pretty_name"
case "$LF$common$LF" in
*"$LF$SHA1$LF"*)
- echo "Already up-to-date with $SHA1"
+ echo "Already up-to-date with $pretty_name"
continue
;;
esac
@@ -81,7 +84,7 @@ do
# tree as the intermediate result of the merge.
# We still need to count this as part of the parent set.
- echo "Fast-forwarding to: $SHA1"
+ echo "Fast-forwarding to: $pretty_name"
git read-tree -u -m $head $SHA1 || exit
MRC=$SHA1 MRT=$(git write-tree)
continue
@@ -89,7 +92,7 @@ do
NON_FF_MERGE=1
- echo "Trying simple merge with $SHA1"
+ echo "Trying simple merge with $pretty_name"
git read-tree -u -m --aggressive $common $MRT $SHA1 || exit 2
next=$(git write-tree 2>/dev/null)
if test $? -ne 0
diff --git a/t/t7602-merge-octopus-many.sh b/t/t7602-merge-octopus-many.sh
index 01e5415..7377033 100755
--- a/t/t7602-merge-octopus-many.sh
+++ b/t/t7602-merge-octopus-many.sh
@@ -49,4 +49,37 @@ test_expect_success 'merge c1 with c2, c3, c4, ... c29' '
done
'
+cat >expected <<\EOF
+Trying simple merge with c2
+Trying simple merge with c3
+Trying simple merge with c4
+Merge made by octopus.
+ c2.c | 1 +
+ c3.c | 1 +
+ c4.c | 1 +
+ 3 files changed, 3 insertions(+), 0 deletions(-)
+ create mode 100644 c2.c
+ create mode 100644 c3.c
+ create mode 100644 c4.c
+EOF
+
+test_expect_success 'merge output uses pretty names' '
+ git reset --hard c1 &&
+ git merge c2 c3 c4 >actual &&
+ test_cmp actual expected
+'
+
+cat >expected <<\EOF
+Already up-to-date with c4
+Trying simple merge with c5
+Merge made by octopus.
+ c5.c | 1 +
+ 1 files changed, 1 insertions(+), 0 deletions(-)
+ create mode 100644 c5.c
+EOF
+
+test_expect_success 'merge up-to-date output uses pretty names' '
+ git merge c4 c5 >actual &&
+ test_cmp actual expected
+'
test_done
--
1.6.6.rc2.5.g49666
^ permalink raw reply related
* Re: Generic filters for git archive?
From: Russ Dill @ 2009-12-15 7:08 UTC (permalink / raw)
To: René Scharfe; +Cc: git
In-Reply-To: <4B202945.50200@lsrfire.ath.cx>
On Wed, Dec 9, 2009 at 3:48 PM, René Scharfe
<rene.scharfe@lsrfire.ath.cx> wrote:
> Am 08.12.2009 02:06, schrieb Russ Dill:
>> I'm trying to add copyright headers to my source files as they are
>> exported via git archive. eg:
>>
>> * $Copyright$
>>
>> to
>>
>> * Copyright (c) 2003-2009 by Foo Bar
>> *
>> * This program is free software; you can redistribute it and/or modify it
>> * under the terms of the GNU General Public License as published by the
>> * Free Software Foundation; either version 2 of the License, or (at your
>> * option) any later version.
>> *
>> * This program is distributed in the hope that it will be useful, but
>> * WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY
>> * or FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License
>> * for more details.
>> *
>> * You should have received a copy of the GNU General Public License
>> * along with this program; if not, write to the Free Software Foundation,
>> * Inc., 675 Mass Ave, Cambridge, MA 02139, USA.
>>
>> And properly handling things like '# $Copyright$', '// $Copyright$',
>> etc. I have a sed script that does this, but no way to apply it to the
>> output of git archive. I tried setting up a smudge filter that would
>> only smudge output on archive exports, but it doesn't appear that the
>> smudge filters get run on git archive.
>>
>> I am currently running 1.6.3.3
>
> Is the filter attribute contained in a .gitattribute file that's part of
> the tree you are trying to export? If it's only in the worktree copy,
> then you need to use the option --worktree-attributes to make git
> archive use it.
hmm..It does seem to be running. But I'd really like to use the
gitattributes from the tagged version I'm exporting and I don't want
the smudge filter to run on files I'm working on in my source tree,
just on the export.
^ permalink raw reply
* Re: [PATCH 03/23] Introduce "skip-worktree" bit in index, teach Git to get/set this bit
From: Johannes Sixt @ 2009-12-15 7:20 UTC (permalink / raw)
To: Nguyen Thai Ngoc Duy; +Cc: Greg Price, git
In-Reply-To: <fcaeb9bf0912141951l5bbb4baanb991354aa3f11ae4@mail.gmail.com>
Nguyen Thai Ngoc Duy schrieb:
> 2009/12/15 Greg Price <price@ksplice.com>:
>> I confess I can't tell how the skip-worktree bit does differ from
>> assume-unchanged. Is its 'goal' different only in that you have a
>> different motivation for introducing it, or does it actually have a
>> different effect -- and what is that different effect?
>
> On the fun side, you could use both bits in the same worktree, to
> narrow your worktree and have some assume-unchanged files.
>
> Another difference is that with assume-unchanged bit, you make a
> promise to Git that those assume-unchanged files are "good", Git does
> not have to care for them. If somehow you violate the promise, Git can
> harm your files on worktree.
So, the difference is that skip-worktree will not overwrite a file that is
different from the version in the index, but assume-unchanged can? Right?
-- Hannes
^ permalink raw reply
* Re: [PATCH] octopus: make merge process simpler to follow
From: Junio C Hamano @ 2009-12-15 7:32 UTC (permalink / raw)
To: Stephen Boyd; +Cc: git, Junio C Hamano, Johannes Sixt, Jari Aalto
In-Reply-To: <1260859755-3990-1-git-send-email-bebarino@gmail.com>
Stephen Boyd <bebarino@gmail.com> writes:
> Its not very easy to understand what heads are being merged given
> the current output of an octopus merge. Fix this by replacing the
> sha1 with the (usually) better description in GITHEAD_<SHA1>.
>
> Suggested-by: Jari Aalto <jari.aalto@cante.net>
> Signed-off-by: Stephen Boyd <bebarino@gmail.com>
> ---
>
> Thanks both. Here's a replacement. Let me know if you want a reroll.
Ah, thanks and sorry for having you do an extra work. I amended the
assignment further like thi,s but haven't got a chance to push the result out...
eval pretty_name=\${GITHEAD_$SHA1:-$SHA1}
^ permalink raw reply
* Re: [PATCH] octopus: make merge process simpler to follow
From: Stephen Boyd @ 2009-12-15 7:35 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Johannes Sixt, Jari Aalto
In-Reply-To: <7v3a3c3d5p.fsf@alter.siamese.dyndns.org>
On Mon, 2009-12-14 at 23:32 -0800, Junio C Hamano wrote:
> Ah, thanks and sorry for having you do an extra work. I amended the
> assignment further like thi,s but haven't got a chance to push the result out...
>
> eval pretty_name=\${GITHEAD_$SHA1:-$SHA1}
>
Great, thanks.
^ permalink raw reply
* Re: [PATCH] help.autocorrect: do not run a command if the command given is junk
From: Johannes Sixt @ 2009-12-15 7:57 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Johannes Schindelin, Git Mailing List, Alex Riesen
In-Reply-To: <7vaaxlcehw.fsf@alter.siamese.dyndns.org>
Junio C Hamano schrieb:
> Johannes Sixt <j.sixt@viscovery.net> writes:
>
>> On Montag, 14. Dezember 2009, Junio C Hamano wrote:
>>> In the meantime, I think squashing the following in would help us keep the
>>> two magic numbers in sync.
>> I do not think that keeping the numbers in sync is necessary. For example, the
>> similarity requirement for commands that run automatically could be stricter
>> than for the list of suggestions. Then it would be possible that a unique
>> best candidate is not good enough to be run automatically; there would only
>> be a list of suggestions.
>
> Well thought out. Would you want to reroll a patch with two symbolic
> constants then?
I briefly looked into it, but, no, I don't want to reroll the patch. Not
only would the change be larger than I first thought, but I would also
have to find a mis-typed command where a stricter limit makes a difference
*and* where it makes sense that the guessed command is not run
automatically. Moreover, I would also have to *find* a suitable new
similarity limit. Not something I want to do now.
Please take my original patch and squash in your suggested changes. Here
it is for your convenience with an updated commit message (only the
last paragraph changed).
-- Hannes
--- 8< ---
From: Johannes Sixt <j6t@kdbg.org>
Subject: [PATCH] help.autocorrect: do not run a command if the command given is junk
If a given command is not found, then help.c tries to guess which one the
user could have meant. If help.autocorrect is 0 or unset, then a list of
suggestions is given as long as the dissimilarity between the given command
and the candidates is not excessively high. But if help.autocorrect was
non-zero (i.e., a delay after which the command is run automatically), the
latter restriction on dissimilarity was not obeyed.
In my case, this happened:
$ git ..daab02
WARNING: You called a Git command named '..daab02', which does not exist.
Continuing under the assumption that you meant 'read-tree'
in 4.0 seconds automatically...
The patch reuses the similarity limit that is also applied when the list of
suggested commands is printed.
Signed-off-by: Johannes Sixt <j6t@kdbg.org>
---
help.c | 7 +++++--
1 files changed, 5 insertions(+), 2 deletions(-)
diff --git a/help.c b/help.c
index e8db31f..9da97d7 100644
--- a/help.c
+++ b/help.c
@@ -297,6 +297,9 @@ static void add_cmd_list(struct cmdnames *cmds, struct cmdnames *old)
old->names = NULL;
}
+/* An empirically derived magic number */
+#define SIMILAR_ENOUGH(x) ((x) < 6)
+
const char *help_unknown_cmd(const char *cmd)
{
int i, n, best_similarity = 0;
@@ -331,7 +334,7 @@ const char *help_unknown_cmd(const char *cmd)
n = 1;
while (n < main_cmds.cnt && best_similarity == main_cmds.names[n]->len)
++n;
- if (autocorrect && n == 1) {
+ if (autocorrect && n == 1 && SIMILAR_ENOUGH(best_similarity)) {
const char *assumed = main_cmds.names[0]->name;
main_cmds.names[0] = NULL;
clean_cmdnames(&main_cmds);
@@ -349,7 +352,7 @@ const char *help_unknown_cmd(const char *cmd)
fprintf(stderr, "git: '%s' is not a git-command. See 'git --help'.\n", cmd);
- if (best_similarity < 6) {
+ if (SIMILAR_ENOUGH(best_similarity)) {
fprintf(stderr, "\nDid you mean %s?\n",
n < 2 ? "this": "one of these");
--
1.6.6.rc1.46.g1635
^ permalink raw reply related
* Re: [PATCH 03/23] Introduce "skip-worktree" bit in index, teach Git to get/set this bit
From: Nguyen Thai Ngoc Duy @ 2009-12-15 8:05 UTC (permalink / raw)
To: Johannes Sixt; +Cc: Greg Price, git
In-Reply-To: <4B2738D1.90002@viscovery.net>
On Tue, Dec 15, 2009 at 2:20 PM, Johannes Sixt <j.sixt@viscovery.net> wrote:
> Nguyen Thai Ngoc Duy schrieb:
>> 2009/12/15 Greg Price <price@ksplice.com>:
>>> I confess I can't tell how the skip-worktree bit does differ from
>>> assume-unchanged. Is its 'goal' different only in that you have a
>>> different motivation for introducing it, or does it actually have a
>>> different effect -- and what is that different effect?
>>
>> On the fun side, you could use both bits in the same worktree, to
>> narrow your worktree and have some assume-unchanged files.
>>
>> Another difference is that with assume-unchanged bit, you make a
>> promise to Git that those assume-unchanged files are "good", Git does
>> not have to care for them. If somehow you violate the promise, Git can
>> harm your files on worktree.
>
> So, the difference is that skip-worktree will not overwrite a file that is
> different from the version in the index, but assume-unchanged can? Right?
Yes.
--
Duy
^ permalink raw reply
* [PATCH 1/2] filter-branch: remove an unnecessary use of 'git read-tree'
From: Johannes Sixt @ 2009-12-15 8:42 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Johannes Schindelin, Git Mailing List
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>
---
Calling read-tree without arguments is not allowed according to the
documentation. The next patch will enforce this.
-- Hannes
git-filter-branch.sh | 1 -
1 files changed, 0 insertions(+), 1 deletions(-)
diff --git a/git-filter-branch.sh b/git-filter-branch.sh
index cb9d202..195b5ef 100755
--- a/git-filter-branch.sh
+++ b/git-filter-branch.sh
@@ -259,7 +259,6 @@ test -s "$tempdir"/heads ||
GIT_INDEX_FILE="$(pwd)/../index"
export GIT_INDEX_FILE
-git read-tree || die "Could not seed the index"
# map old->new commit ids for rewriting parents
mkdir ../map || die "Could not create map/ directory"
--
1.6.6.rc1.46.g1635
^ permalink raw reply related
* [PATCH 2/2] read-tree: at least one tree-ish argument is required
From: Johannes Sixt @ 2009-12-15 8:43 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Git Mailing List
In-Reply-To: <4B274BDE.8000504@viscovery.net>
From: Johannes Sixt <j6t@kdbg.org>
Previously, it was possible to run read-tree without any arguments,
whereupon it purged the index!
Signed-off-by: Johannes Sixt <j6t@kdbg.org>
---
Discovered by typing
git ..daab02
with help.autocorrect > 0 :-)
-- Hannes
builtin-read-tree.c | 3 +++
1 files changed, 3 insertions(+), 0 deletions(-)
diff --git a/builtin-read-tree.c b/builtin-read-tree.c
index 50413ca..31623b9 100644
--- a/builtin-read-tree.c
+++ b/builtin-read-tree.c
@@ -125,6 +125,9 @@ int cmd_read_tree(int argc, const char **argv,
stage = opts.merge = 1;
}
+ if (argc == 0)
+ usage_with_options(read_tree_usage, read_tree_options);
+
for (i = 0; i < argc; i++) {
const char *arg = argv[i];
--
1.6.6.rc1.46.g1635
^ permalink raw reply related
* potential null dereference
From: Jiri Slaby @ 2009-12-15 12:41 UTC (permalink / raw)
To: git
Hi,
Stanse found the following error in unpack-trees.c:
dereferencing NULL pointer here.[. * o src_index]
int unpack_trees(unsigned len, struct tree_desc *t, struct
unpack_trees_options *o)
{
int ret;
static struct cache_entry *dfc;
...
if (o->src_index) { <-- loc0
o->result.timestamp.sec = o->src_index->timestamp.sec;
o->result.timestamp.nsec = o->src_index->timestamp.nsec;
}
o->merge_size = len;
if (!dfc)
dfc = xcalloc(1, ((1 + (0) + 8) & ~7));
o->df_conflict_entry = dfc;
if (len) {
...
}
if (o->merge) {
while (o->pos < o->src_index->cache_nr) { <-- here
It triggers, because there is a test for o->src_index being NULL at
loc0, but here, it is dereferenced without a check. Can this happen
(e.g. does o->merge != NULL imply o->src_index != NULL)?
Further, there is a warning in log-tree.c:
pointer always points to valid memory here, but checking for not
NULL.[parents]
static int log_tree_diff(struct rev_info *opt, struct commit *commit,
struct log_info *log)
{
int showed_log;
struct commit_list *parents;
unsigned const char *sha1 = commit->object.sha1;
if (!opt->diff && !((&opt->diffopt)->flags & (1 << 14)))
return 0;
parents = commit->parents;
if (!parents) { <-- loc0
if (opt->show_root_diff) {
diff_root_tree_sha1(sha1, "", &opt->diffopt);
log_tree_diff_flush(opt);
}
return !opt->loginfo; <-- loc1
}
if (parents && parents->next) { <-- here
I.e. if parents was NULL at loc0, we escaped at loc1. But we check
parents against NULL here again.
thanks,
--
js
^ permalink raw reply
* Re: Generic filters for git archive?
From: René Scharfe @ 2009-12-15 13:06 UTC (permalink / raw)
To: Russ Dill; +Cc: git
In-Reply-To: <f9d2a5e10912142308o50c8b9edy63bb485658c93a03@mail.gmail.com>
Am 15.12.2009 08:08, schrieb Russ Dill:
> hmm..It does seem to be running. But I'd really like to use the
> gitattributes from the tagged version I'm exporting and I don't want
> the smudge filter to run on files I'm working on in my source tree,
> just on the export.
This seems to work here:
$ git version
git version 1.6.3.3
$ mkdir /tmp/x
$ cd /tmp/x
$ git init
Initialized empty Git repository in /tmp/x/.git/
$ echo sc >a
$ git add a
$ echo '#!/bin/sh' >f
$ echo 'sed "s/sc/Santa Claus/"' >>f
$ chmod 755 f
$ git config filter.sc.smudge ./f
$ echo 'a filter=sc' >.gitattributes
$ git add .gitattributes
$ git commit -m.
[master (root-commit) 57f6bef] .
2 files changed, 2 insertions(+), 0 deletions(-)
create mode 100644 .gitattributes
create mode 100644 a
$ rm .gitattributes
$ git archive --prefix=x HEAD | tar xf - xa
$ cat xa
Santa Claus
$ git archive --prefix=y --worktree-attributes HEAD | tar xf - ya
$ cat ya
sc
The first archive call uses the committed .gitattributes file and runs
the file through the smudge filter. The second one uses the worktree
version, which doesn't exist, so no filtering occurs.
What commands do you use?
Thanks,
René
^ permalink raw reply
* 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
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