* Re: [PATCH] Documentation: fix typos, grammar, asciidoc syntax
From: Markus Heidelberg @ 2008-12-20 13:18 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7v3agj1gvp.fsf@gitster.siamese.dyndns.org>
Junio C Hamano, 20.12.2008:
> Markus Heidelberg <markus.heidelberg@web.de> writes:
>
> > @@ -172,7 +172,7 @@ only the primary branches. In addition, if you happen to be on
> > your topic branch, it is shown as well.
> >
> > ------------
> > -$ git show-branch --reflog='10,1 hour ago' --list master
> > +$ git show-branch --reflog="10,1 hour ago" --list master
> > ------------
>
> Is this just a personal taste, or a correction to typography?
When using single quotes, the manpage displayed backticks. I don't know
how to obtain single quotes in the manpage, if this is preferred. The
HTML page worked though: single quotes were translated to single quotes,
double quotes to double quotes.
> Other than this one, I did not find anything else in your patch that
> looked iffy. Thanks for lending a good set of eyeballs.
Thanks, this happens when reading a lot of documentation :)
^ permalink raw reply
* Applying patches from a patch set
From: Mark Ryden @ 2008-12-20 14:37 UTC (permalink / raw)
To: git
Hello,
I am subscribed to some linux kernel subsystem mailing list; in this
list there are sometimes patchsets with more than
30-40 patches.
I am using gmail web interface client.
In order to apply a patch set I copy and paste each patch from the
patchset into a file, and then apply that patch.
I assume that there is a better way.
Recently I encountered a fatal error when doing so (and I am not sure
what caused it).
So my question is: does anyone know a more elegant way of applying a
large patchset ?
Maybe there is better mail client with which this process can be done easily ?
(I remember there was something called git apply-mbox in the past).
Rgs,
Mark
^ permalink raw reply
* Re: rsync deprecated?
From: Miklos Vajna @ 2008-12-20 17:02 UTC (permalink / raw)
To: demerphq; +Cc: Mike Hommey, Junio C Hamano, git
In-Reply-To: <9b18b3110812200212o46edf51eoaff43ec1b8fc3913@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 599 bytes --]
On Sat, Dec 20, 2008 at 11:12:11AM +0100, demerphq <demerphq@gmail.com> wrote:
> Is there a bug tracking tool that git uses? I asked on #git on irc and
> they said to just mail the list, but ive not seen any response to my
> mail at all and the timing of Junios comment makes me wonder if my
> report was seen by list regulars at all.
You did the right thing, just nobody who read your mail had enough
time/knowledge/motivation to reply something constructive for you.
Similar to patches, I think if you get no answer in 3 days, you can try
to reply to your own mail, bringing the topic up again.
[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Re: rsync deprecated?
From: demerphq @ 2008-12-20 17:08 UTC (permalink / raw)
To: Miklos Vajna; +Cc: Mike Hommey, Junio C Hamano, git
In-Reply-To: <20081220170219.GS21154@genesis.frugalware.org>
2008/12/20 Miklos Vajna <vmiklos@frugalware.org>:
> On Sat, Dec 20, 2008 at 11:12:11AM +0100, demerphq <demerphq@gmail.com> wrote:
>> Is there a bug tracking tool that git uses? I asked on #git on irc and
>> they said to just mail the list, but ive not seen any response to my
>> mail at all and the timing of Junios comment makes me wonder if my
>> report was seen by list regulars at all.
>
> You did the right thing, just nobody who read your mail had enough
> time/knowledge/motivation to reply something constructive for you.
>
> Similar to patches, I think if you get no answer in 3 days, you can try
> to reply to your own mail, bringing the topic up again.
Ah, yes. Being new on this list it is all too easy to suffer from
Warnock Dilemma.
cheers,
Yves
--
perl -Mre=debug -e "/just|another|perl|hacker/"
^ permalink raw reply
* Re: RFC: Change whatchanged to report changes from merges by default?
From: Mark Burton @ 2008-12-20 17:22 UTC (permalink / raw)
To: git
In-Reply-To: <20081220104232.5ff1b7c0@crow>
Hi,
On further studying, I see that 1aec7917dc (git log: don't do merge
diffs by default) makes git log only show the log message by default
for merges. OK, no problem with that.
However, in my mind, whatchanged is misleading when it doesn't output
anything (by default) for merges because, in my mind, that implies that
nothing has changed when, in fact, whole heaps of stuff could have been
merged in. So, if you forget to add the -m option, whatchanged will silently
ignore all the merged stuff and leave the poor user in the dark.
So, if changing the default behaviour is acceptable, I still think it would
be better if ignore_merges is set to 0 in cmd_whatchanged() but I guess an
alternative would be to set always_show_header, instead.
Any thoughts?
Cheers,
Mark
^ permalink raw reply
* Re: how to check remote git repo for updates without pull/fetch
From: James Cloos @ 2008-12-20 17:32 UTC (permalink / raw)
To: Ivan Zorin; +Cc: git
In-Reply-To: <494BC89F.9070107@gmail.com>
[-- Attachment #1: Type: text/plain, Size: 27 bytes --]
Here is the script I use:
[-- Attachment #2: git-need-pull-p --]
[-- Type: text/plain, Size: 168 bytes --]
#!/bin/bash
#
# does this git repo need a pull?
#
l=$(git log|head -1|awk '{print $NF}')
r=$(git ls-remote origin heads/master|awk '{print $1}')
test "${r}" != "${l}"
[-- Attachment #3: Type: text/plain, Size: 76 bytes --]
-JimC
--
James Cloos <cloos@jhcloos.com> OpenPGP: 1024D/ED7DAEA6
^ permalink raw reply
* Re: Applying patches from a patch set
From: Jakub Narebski @ 2008-12-20 19:25 UTC (permalink / raw)
To: Mark Ryden; +Cc: git
In-Reply-To: <dac45060812200637m49c71aa5x3c25010fa00f4a63@mail.gmail.com>
"Mark Ryden" <markryde@gmail.com> writes:
> I am subscribed to some linux kernel subsystem mailing list; in this
> list there are sometimes patchsets with more than
> 30-40 patches.
I hope in proper patch series...
> I am using gmail web interface client.
Better use some standalone mail program. Patch series should be send
in thread, either as reply to the cover letter message, or threaded
each being reply to previous patch... beside being numbered; IIRC
GMail web interface doesn't have threading implemented...
> In order to apply a patch set I copy and paste each patch from the
> patchset into a file, and then apply that patch.
You use raw view, I assume? Otherwise you would fail afoul word
wrapping and other whitespace mangling, at least...
[...]
> (I remember there was something called git apply-mbox in the past).
You can use "git am" for that, which is modern equivalent, and which
can do (almost) everything git-apply-mbox did.
--
Jakub Narebski
Poland
ShadeHawk on #git
^ permalink raw reply
* Re: Git weekly links: 2008-51
From: Jakub Narebski @ 2008-12-20 19:50 UTC (permalink / raw)
To: Felipe Contreras; +Cc: git list
In-Reply-To: <94a0d4530812200416m1caa96f2je2bf478f65bd7d12@mail.gmail.com>
"Felipe Contreras" <felipe.contreras@gmail.com> writes:
> This week tortoisegit stole the spotlight. Maybe there weren't many
> other links, or maybe I failed to notice them. Also, many people liked
> the comment of Linus Torvalds regarding C++ in git.
>
> blog version:
> http://gitlog.wordpress.com/2008/12/20/git-weekly-links-2008-51/
>
> == Articles ==
>
> Re: [RFC] Convert builin-mailinfo.c to use The Better String Library.
> Linus Torvalds creates some buzz
> http://lwn.net/Articles/249460/
A not countered counter:
C++ is a horrible language
http://skepticalmethodologist.wordpress.com/2008/12/17/c-is-a-horrible-language/
> == General links ==
>
> tortoisegit
> http://code.google.com/p/tortoisegit/
What about "Git Extensions":
https://sourceforge.net/projects/gitextensions/
http://github.com/spdr870/gitextensions/
And "TortoiseGit Challenge":
http://github.com/blog/256-tortoisegit-challenge
--
Jakub Narebski
Poland
ShadeHawk on #git
^ permalink raw reply
* Re: [PATCH] Documentation: fix typos, grammar, asciidoc syntax
From: Junio C Hamano @ 2008-12-20 20:08 UTC (permalink / raw)
To: markus.heidelberg; +Cc: git
In-Reply-To: <200812201418.38707.markus.heidelberg@web.de>
Markus Heidelberg <markus.heidelberg@web.de> writes:
> Junio C Hamano, 20.12.2008:
>> Markus Heidelberg <markus.heidelberg@web.de> writes:
>>
>> > @@ -172,7 +172,7 @@ only the primary branches. In addition, if you happen to be on
>> > your topic branch, it is shown as well.
>> >
>> > ------------
>> > -$ git show-branch --reflog='10,1 hour ago' --list master
>> > +$ git show-branch --reflog="10,1 hour ago" --list master
>> > ------------
>>
>> Is this just a personal taste, or a correction to typography?
>
> When using single quotes, the manpage displayed backticks.
It does not seem to do that to me:
$ git help show-branch | grep 10,1 | od -bc
0000000 040 040 040 040 040 040 040 040 040 040 044 040 147 151 164 040
$ g i t
0000020 163 150 157 167 055 142 162 141 156 143 150 040 055 055 162 145
s h o w - b r a n c h - - r e
0000040 146 154 157 147 075 342 200 231 061 060 054 061 040 150 157 165
f l o g = 342 200 231 1 0 , 1 h o u
0000060 162 040 141 147 157 342 200 231 040 055 055 154 151 163 164 040
r a g o 342 200 231 - - l i s t
0000100 155 141 163 164 145 162 012
m a s t e r \n
It does not use ASCII single quote ' (\047) but the result still does
render well enough to keep anybody who are typing, following the printed
examples, from mistaking it from a backquote:
http://pics.livejournal.com/gitster/pic/00009pk0/g6
But in this particular case, because sq/dq does not make any difference to
the example, I am Ok to change it to dq. But I suspect there are many
other places that do need to use sq in examples, so...
^ permalink raw reply
* Re: Applying patches from a patch set
From: Junio C Hamano @ 2008-12-20 20:06 UTC (permalink / raw)
To: Mark Ryden; +Cc: git
In-Reply-To: <dac45060812200637m49c71aa5x3c25010fa00f4a63@mail.gmail.com>
"Mark Ryden" <markryde@gmail.com> writes:
> Hello,
> I am subscribed to some linux kernel subsystem mailing list; in this
> list there are sometimes patchsets with more than
> 30-40 patches.
> I am using gmail web interface client.
>
> In order to apply a patch set I copy and paste each patch from the
> patchset into a file, and then apply that patch.
> I assume that there is a better way.
> Recently I encountered a fatal error when doing so (and I am not sure
> what caused it).
>
> So my question is: does anyone know a more elegant way of applying a
> large patchset ?
> Maybe there is better mail client with which this process can be done easily ?
First mistake(?) is you seem to be doing copy&paste from browser. Don't.
It can easily damage whitespaces. Find out how your webmail interface
allows you to save selected messages in a mbox and let you download it.
Then
$ git am that-mbox-file
^ permalink raw reply
* Re: RFC: Change whatchanged to report changes from merges by default?
From: Junio C Hamano @ 2008-12-20 20:09 UTC (permalink / raw)
To: Mark Burton; +Cc: git
In-Reply-To: <20081220104232.5ff1b7c0@crow>
Mark Burton <markb@ordern.com> writes:
> Is it just an accident of history or by design that whatchanged
> requires the -m option to show changes introduced by merges but
> diff and git log show those changes without requiring any extra
> options?
Mostly personal preference and inertia..
I personally do not see any reason for anybody to use whatchanged (what a
long single-word to type!) since around git version v1.0.0 or so. Back
then, whatchanged was a good way to satisfy "I want a quick sanity check,
but I want to see a bit more than just names of files to assure me. But I
want to get that without actually running the diffs or stats because I
consider that anything that takes more than half a second is too
expensive." But ever since we made the diff generation built-in, the
performance objection ceased to be an issue. These days I'd imagine that
"log --name-only" or even "log --stat" would be perfectly acceptable and
easier to explain alternative, especially if you happen to be a very early
adopter whose fingers are trained to type "whatchanged".
IOW, I consider "whatchanged" a command that is kept only for old timers'
sake. There is no reason to promote it, but there is no reason to
deprecate it, either. Which means the answer to this question...
> Would it not make more sense to have git whatchanged show the changes
> introduced by merges by default and then people can use the (already
> supported) --no-merges option to suppress that behaviour?
... is a NO spelled in capital letters.
^ permalink raw reply
* Re: [PATCH] git-mergetool: properly handle "git mergetool -- filename"
From: Junio C Hamano @ 2008-12-20 20:09 UTC (permalink / raw)
To: David Aguilar; +Cc: git
In-Reply-To: <593cce2ad8b4d21995b24f0186e846d98306ae60.1229734788.git.davvid@gmail.com>
Thanks.
^ permalink raw reply
* Re: [PATCH 1/4] Introduce commit notes
From: Junio C Hamano @ 2008-12-20 20:09 UTC (permalink / raw)
To: Jeff King
Cc: Robin Rosenberg, Johannes Schindelin, Govind Salinas,
Git Mailing List
In-Reply-To: <20081220082304.GA5693@coredump.intra.peff.net>
Jeff King <peff@peff.net> writes:
> On Sat, Dec 20, 2008 at 12:17:46AM -0800, Junio C Hamano wrote:
>
>> > 1. git am /the/patch
>> > 2. patch -p1 <.git/rebase-apply/patch
>> > 3. manually inspect the results for sanity, and fix up the cache.h
>> > bit that failed totally
>> > 4. git add -u && git add notes.[ch]
>> > 5. git am --resolved
>>
>> I usually skip 2-4 and edit .git/rebase-apply/patch in place instead, and
>> run "git am" instead of step 5.
>
> How do you track down the source of the conflict to do the patch fixup?
Old fashioned way, by looking at the patch and the file that the patch is
supposed to apply and reading the contexts.
^ permalink raw reply
* Re: [PATCH] Remove the requirement opaquelocktoken uri scheme
From: Junio C Hamano @ 2008-12-20 20:09 UTC (permalink / raw)
To: Kirill A. Korinskiy; +Cc: git
In-Reply-To: <1229753986-5193-1-git-send-email-catap@catap.ru>
"Kirill A. Korinskiy" <catap@catap.ru> writes:
> ...
> This resulted in push failure (often resulted in "cannot lock existing
> info/refs" error message) when talking to a server that does not use
> opaquelocktoken URI scheme.
>
> Signed-off-by: Kirill A. Korinskiy <catap@catap.ru>
Thanks.
^ permalink raw reply
* Re: [PATCH] git-send-email: handle email address with quoted comma
From: Junio C Hamano @ 2008-12-20 20:09 UTC (permalink / raw)
To: Matt Kraai; +Cc: git
In-Reply-To: <loom.20081219T162504-25@post.gmane.org>
Matt Kraai <kraai@ftbfs.org> writes:
> Howdy,
>
> Wu Fengguang <fengguang.wu <at> intel.com> writes:
>> +sub split_addrs {
>> + return parse_line('\s*,\s*', 1, @_);
>> +}
>> +
>
> I'm not sure it's still a good idea to use parse_line. It should work OK for
> now, since split_addrs is only passed one string. If anyone ever tries to pass
> it a list of strings, however, parse_line will ignore all but the first.
Yikes, I should have caught this. As you point out, this is a breakage
waiting to happen until somebody restructures the callers. We should
futureproof it by using quotewords() instead.
^ permalink raw reply
* Re: RFC: Change whatchanged to report changes from merges by default?
From: Mark Burton @ 2008-12-20 20:21 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vvdtewqvy.fsf@gitster.siamese.dyndns.org>
On Sat, 20 Dec 2008 12:09:05 -0800
Junio C Hamano <gitster@pobox.com> wrote:
> IOW, I consider "whatchanged" a command that is kept only for old timers'
> sake. There is no reason to promote it, but there is no reason to
> deprecate it, either. Which means the answer to this question...
>
> > Would it not make more sense to have git whatchanged show the changes
> > introduced by merges by default and then people can use the (already
> > supported) --no-merges option to suppress that behaviour?
>
> ... is a NO spelled in capital letters.
OK (spelled in capital letters), I won't submit the patch.
Cheers,
Mark
^ permalink raw reply
* Re: [PATCH] Documentation: fix typos, grammar, asciidoc syntax
From: Teemu Likonen @ 2008-12-20 20:39 UTC (permalink / raw)
To: Junio C Hamano; +Cc: markus.heidelberg, git
In-Reply-To: <7v3agiy5gs.fsf@gitster.siamese.dyndns.org>
Junio C Hamano (2008-12-20 12:08 -0800) wrote:
> Markus Heidelberg <markus.heidelberg@web.de> writes:
>
>> Junio C Hamano, 20.12.2008:
>>> Markus Heidelberg <markus.heidelberg@web.de> writes:
>>> > -$ git show-branch --reflog='10,1 hour ago' --list master
>>> > +$ git show-branch --reflog="10,1 hour ago" --list master
>>> Is this just a personal taste, or a correction to typography?
>>
>> When using single quotes, the manpage displayed backticks.
>
> It does not seem to do that to me:
The single quote (') in asciidoc turns into \' in the man page
typesetting language and its meaning is acute accent (´, U+00B4). In
Ascii-only environment \' is displayed as a single quote but it is still
logically an acute accent. For example, my UTF-8 terminals as well as
Postscript output (man -Tps) display \' as acute accent.
To get the logical single quote the man page source should contain \(aq
or \[aq] . Don't know how to make asciidoc do this.
^ permalink raw reply
* [EGIT PATCH] Tell Eclipse not to convert some of the patch input files.
From: Robin Rosenberg @ 2008-12-20 20:42 UTC (permalink / raw)
To: spearce; +Cc: git, Robin Rosenberg
By default Eclipse silently converts non-UTF-8 characters to
a surrogate code point when it encounters invalid UTF-8. Since
a few of the patch input files are meant to be read as bytes
it is more appropriate and safer to assume ISO-8859-1 which
can represent any byte sequence.
Signed-off-by: Robin Rosenberg <robin.rosenberg@dewire.com>
---
.../.settings/org.eclipse.core.resources.prefs | 5 ++++-
1 files changed, 4 insertions(+), 1 deletions(-)
diff --git a/org.spearce.jgit.test/.settings/org.eclipse.core.resources.prefs b/org.spearce.jgit.test/.settings/org.eclipse.core.resources.prefs
index a2724ba..d691a8e 100644
--- a/org.spearce.jgit.test/.settings/org.eclipse.core.resources.prefs
+++ b/org.spearce.jgit.test/.settings/org.eclipse.core.resources.prefs
@@ -1,3 +1,6 @@
-#Mon Aug 11 16:05:15 PDT 2008
+#Sat Dec 20 21:21:24 CET 2008
eclipse.preferences.version=1
+encoding//tst-rsrc/org/spearce/jgit/patch/testGetText_BothISO88591.patch=ISO-8859-1
+encoding//tst-rsrc/org/spearce/jgit/patch/testGetText_Convert.patch=ISO-8859-1
+encoding//tst-rsrc/org/spearce/jgit/patch/testGetText_DiffCc.patch=ISO-8859-1
encoding/<project>=UTF-8
--
1.6.1.rc3.56.gd0306
^ permalink raw reply related
* Re: [PATCH] Documentation: fix typos, grammar, asciidoc syntax
From: Markus Heidelberg @ 2008-12-20 21:02 UTC (permalink / raw)
To: Teemu Likonen; +Cc: Junio C Hamano, git
In-Reply-To: <87tz8yponl.fsf@iki.fi>
Teemu Likonen, 20.12.2008:
> Junio C Hamano (2008-12-20 12:08 -0800) wrote:
>
> > Markus Heidelberg <markus.heidelberg@web.de> writes:
> >
> >> Junio C Hamano, 20.12.2008:
> >>> Markus Heidelberg <markus.heidelberg@web.de> writes:
>
> >>> > -$ git show-branch --reflog='10,1 hour ago' --list master
> >>> > +$ git show-branch --reflog="10,1 hour ago" --list master
>
> >>> Is this just a personal taste, or a correction to typography?
> >>
> >> When using single quotes, the manpage displayed backticks.
> >
> > It does not seem to do that to me:
>
> The single quote (') in asciidoc turns into \' in the man page
> typesetting language and its meaning is acute accent (´, U+00B4).
Oh, right, it's not a backtick for me, but this acute accent. The other
direction downwards.
^ permalink raw reply
* Re: [PATCH] Documentation: fix typos, grammar, asciidoc syntax
From: Markus Heidelberg @ 2008-12-20 21:13 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7v3agiy5gs.fsf@gitster.siamese.dyndns.org>
Junio C Hamano, 20.12.2008:
> Markus Heidelberg <markus.heidelberg@web.de> writes:
>
> > Junio C Hamano, 20.12.2008:
> >> Markus Heidelberg <markus.heidelberg@web.de> writes:
> >>
> >> > @@ -172,7 +172,7 @@ only the primary branches. In addition, if you happen to be on
> >> > your topic branch, it is shown as well.
> >> >
> >> > ------------
> >> > -$ git show-branch --reflog='10,1 hour ago' --list master
> >> > +$ git show-branch --reflog="10,1 hour ago" --list master
> >> > ------------
> >>
> >> Is this just a personal taste, or a correction to typography?
> >
> > When using single quotes, the manpage displayed backticks.
>
> It does not seem to do that to me:
>
> $ git help show-branch | grep 10,1 | od -bc
> 0000040 146 154 157 147 075 342 200 231 061 060 054 061 040 150 157 165
> f l o g = 342 200 231 1 0 , 1 h o u
I get this instead:
0000040 145 146 154 157 147 075 302 264 061 060 054 061 040 150 157 165
e f l o g = 302 264 1 0 , 1 h o u
> It does not use ASCII single quote ' (\047) but the result still does
> render well enough to keep anybody who are typing, following the printed
> examples, from mistaking it from a backquote:
>
> http://pics.livejournal.com/gitster/pic/00009pk0/g6
Yes, I was wrong, it wasn't a backtick.
^ permalink raw reply
* Re: [PATCH] Documentation: fix typos, grammar, asciidoc syntax
From: Teemu Likonen @ 2008-12-20 21:18 UTC (permalink / raw)
To: Junio C Hamano; +Cc: markus.heidelberg, git
In-Reply-To: <87tz8yponl.fsf@iki.fi>
Teemu Likonen (2008-12-20 22:39 +0200) wrote:
> To get the logical single quote the man page source should contain \(aq
> or \[aq] . Don't know how to make asciidoc do this.
But \(aq seems to be groff-specific and not necessarily portable. Oh
well, quotation marks are really a mess in man pages. Some reference:
http://www.mail-archive.com/groff@gnu.org/msg04150.html
But char " should be reliable anyway. It renders as Ascii double quote.
^ permalink raw reply
* Re: [PATCH] Documentation: fix typos, grammar, asciidoc syntax
From: Teemu Likonen @ 2008-12-20 21:37 UTC (permalink / raw)
To: markus.heidelberg; +Cc: Junio C Hamano, git
In-Reply-To: <200812202213.45029.markus.heidelberg@web.de>
Markus Heidelberg (2008-12-20 22:13 +0100) wrote:
> Junio C Hamano, 20.12.2008:
>> f l o g = 342 200 231 1 0 , 1 h o u
^^^^^^^^^^^
This is $E2 $80 $99 in hex and it's the UTF-8 sequence for U+2019 RIGHT
SINGLE QUOTATION MARK (’).
> I get this instead:
> e f l o g = 302 264 1 0 , 1 h o u
^^^^^^^
And this is $C2 $B4 in hex and it's U+00B4 ACUTE ACCENT (´) in UTF-8
encoding. This is what I get too with groff, in terminal and PostScript.
Weird that Junio is getting different output for \' in the man page
source.
But this is nothing yet, Emacs' "M-x woman" renders them as _grave
accents_ aka backticks (`, U+0060 GRAVE ACCENT). Nice.
^ permalink raw reply
* Re: [PATCH] Add a documentat on how to revert a faulty merge
From: Boyd Stephen Smith Jr. @ 2008-12-20 22:12 UTC (permalink / raw)
To: git; +Cc: Nanako Shiraishi, Junio C Hamano
In-Reply-To: <20081220202702.6117@nanako3.lavabit.com>
[-- Attachment #1: Type: text/plain, Size: 1708 bytes --]
On Saturday 2008 December 20 05:27:02 Nanako Shiraishi wrote:
> +Date: Fri, 19 Dec 2008 00:45:19 -0800
> +From: Linus Torvalds <torvalds@linux-foundation.org>, Junio C Hamano
> <gitster@pobox.com> +Subject: Re: Odd merge behaviour involving reverts
> +Abstract: Sometimes a branch that was already merged to the mainline
> + is later found to be faulty. Linus and Junio give guidance on
> + recovering from such a premature merge and continuing development
> + after the offending branch is fixed.
> +Message-ID: <7vocz8a6zk.fsf@gitster.siamese.dyndns.org>
> +References: <alpine.LFD.2.00.0812181949450.14014@localhost.localdomain>
> +
> +Alan <alan@clueserver.org> said:
I don't like the email headers as part of the documentation. It would be
better to have a title and abstract in prose.
Also, your email gave me some errors from 'git am':
.dotest/patch:40: indent with spaces.
/
.dotest/patch:57: indent with spaces.
/
.dotest/patch:91: indent with spaces.
/
.dotest/patch:103: indent with spaces.
/
.dotest/patch:110: indent with spaces.
/ /
warning: squelched 3 whitespace errors
warning: 8 lines add whitespace errors.
Those errors aside, I think it's better formatted than what I had ready. I
also think it would be nice to also modify the git-revert manpage to
reference this documentation in the description on the -m option.
--
Boyd Stephen Smith Jr. ,= ,-_-. =.
bss@iguanasuicide.net ((_/)o o(\_))
ICQ: 514984 YM/AIM: DaTwinkDaddy `-'(. .)`-'
http://iguanasuicide.net/ \_/
[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Re: [PATCH] Make git revert warn the user when reverting a merge commit.
From: Boyd Stephen Smith Jr. @ 2008-12-20 22:54 UTC (permalink / raw)
To: git; +Cc: Robin Rosenberg, Junio C Hamano
In-Reply-To: <200812200808.02011.robin.rosenberg.lists@dewire.com>
[-- Attachment #1: Type: text/plain, Size: 1575 bytes --]
On Saturday 2008 December 20 01:08:01 Robin Rosenberg wrote:
> fredag 19 december 2008 03:39:15 skrev Boyd Stephen Smith Jr.:
> > On Thursday 2008 December 18 18:21:25 Linus Torvalds wrote:
> > > I suspect we should warn about reverting merges.
>
> Or mention the reverted parent in the commit message since it is not
> obvious.
>
> ---
> builtin-revert.c | 4 ++++
> 1 files changed, 4 insertions(+), 0 deletions(-)
>
> diff --git a/builtin-revert.c b/builtin-revert.c
> index 4038b41..fc59229 100644
> --- a/builtin-revert.c
> +++ b/builtin-revert.c
> @@ -352,6 +352,10 @@ static int revert_or_cherry_pick(int argc, const char
> **argv) add_to_msg(oneline_body + 1);
> add_to_msg("\"\n\nThis reverts commit ");
> add_to_msg(sha1_to_hex(commit->object.sha1));
> + if (commit->parents->next) {
> + add_to_msg(" removing\ncontributions from ");
> + add_to_msg(sha1_to_hex(parent->object.sha1));
> + }
> add_to_msg(".\n");
> } else {
> base = parent;
I'm still new to the code, but parent is the "mainline" specified on the
command-line, which (I think) is actually the parent to be reverted to, so we
are actually removing contributions from all the *other* parents. So, the
message may be backward. Because of that, I'd say the patch doesn't handle
octopus merges well, either.
--
Boyd Stephen Smith Jr. ,= ,-_-. =.
bss@iguanasuicide.net ((_/)o o(\_))
ICQ: 514984 YM/AIM: DaTwinkDaddy `-'(. .)`-'
http://iguanasuicide.net/ \_/
[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* [EGIT PATCH] Use the possible resources's specific encoding for quickdiff
From: Robin Rosenberg @ 2008-12-20 23:14 UTC (permalink / raw)
To: spearce; +Cc: git, Robin Rosenberg
Encoding can be defined in many places. It could be defined for a specific
resource, workspace, JVM invocation or platform. Let Eclipse handle the
logic. We always ask for the current revisions encoding, which in theory
could be different from the encoding specified for the version we are
retrieving.
Signed-off-by: Robin Rosenberg <robin.rosenberg@dewire.com>
---
.../egit/ui/internal/decorators/GitDocument.java | 20 +++++++++++++++++++-
1 files changed, 19 insertions(+), 1 deletions(-)
diff --git a/org.spearce.egit.ui/src/org/spearce/egit/ui/internal/decorators/GitDocument.java b/org.spearce.egit.ui/src/org/spearce/egit/ui/internal/decorators/GitDocument.java
index a985a68..a9c0c7d 100644
--- a/org.spearce.egit.ui/src/org/spearce/egit/ui/internal/decorators/GitDocument.java
+++ b/org.spearce.egit.ui/src/org/spearce/egit/ui/internal/decorators/GitDocument.java
@@ -9,8 +9,10 @@
import java.io.IOException;
+import org.eclipse.core.resources.IEncodedStorage;
import org.eclipse.core.resources.IProject;
import org.eclipse.core.resources.IResource;
+import org.eclipse.core.runtime.CoreException;
import org.eclipse.jface.text.Document;
import org.eclipse.team.core.RepositoryProvider;
import org.spearce.egit.core.GitProvider;
@@ -66,7 +68,23 @@ void populate() throws IOException {
Activator.trace("(GitQuickDiffProvider) compareTo: " + baseline);
ObjectLoader loader = repository.openBlob(blobEnry.getId());
byte[] bytes = loader.getBytes();
- String s = new String(bytes); // FIXME Platform default charset. should be Eclipse default
+ String charset;
+ // Get the encoding for the current version. As a matter of
+ // principle one might want to use the eclipse settings for the
+ // version we are retrieving as that may be defined by the
+ // project settings, but there is no historic API for this.
+ IEncodedStorage encodedStorage = ((IEncodedStorage)resource);
+ try {
+ if (encodedStorage != null)
+ charset = encodedStorage.getCharset();
+ else
+ charset = resource.getParent().getDefaultCharset();
+ } catch (CoreException e) {
+ charset = Constants.CHARACTER_ENCODING;
+ }
+ // Finally we could consider validating the content with respect
+ // to the content. We don't do that here.
+ String s = new String(bytes, charset);
set(s);
Activator.trace("(GitQuickDiffProvider) has reference doc, size=" + s.length() + " bytes");
} else {
--
1.6.1.rc3.56.gd0306
^ permalink raw reply related
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