* 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
* Re: [PATCH] Make git revert warn the user when reverting a merge commit.
From: Robin Rosenberg @ 2008-12-20 23:31 UTC (permalink / raw)
To: Boyd Stephen Smith Jr.; +Cc: git, Junio C Hamano
In-Reply-To: <200812201654.23110.bss@iguanasuicide.net>
lördag 20 december 2008 23:54:19 skrev Boyd Stephen Smith Jr.:
> 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
Indeed the message is backward. How about "removing all contributions except from"... etc ?
An alternative, would be "removing changes relative to .." (mainline). The changes are
the contributions from all other parents. I have to huge interest in the exact phrase used.
> octopus merges well, either.
Same problem, I think.
-- robin
^ permalink raw reply
* Re: how to check remote git repo for updates without pull/fetch
From: David Aguilar @ 2008-12-20 23:41 UTC (permalink / raw)
To: James Cloos; +Cc: Ivan Zorin, git
In-Reply-To: <m3skoi21m3.fsf@lugabout.jhcloos.org>
2008/12/20 James Cloos <cloos@jhcloos.com>:
>
> #!/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}"
>
>
> -JimC
> --
> James Cloos <cloos@jhcloos.com> OpenPGP: 1024D/ED7DAEA6
>
>
Hello
Your script will report false positives if you run that in a branch
where you've made local commits since git log's output will list a
commit that's not on the remote side. Thus it'lll say 'you need to
pull' when really what happened was that you committed locally and the
sha1 test is no longer equal. This is one of the reasons why it's a
good idea to always keep your local master clean.
There's two things you can do:
1. assume that you always keep your local 'master' branch clean.
That'll let you quickly compare your local master versus origin's
master:
#!/bin/sh
remotemaster=$(git ls-remote origin heads/master | awk '{print $1}')
localmaster=$(git rev-parse master)
test "$remotemaster" = "$localmaster"
2. You might have a local branch that's not called master but is
tracking origin/master. Or, your master branch might not be clean.
You can accomodate that workflow with:
#!/bin/sh
remotemaster=$(git ls-remote origin heads/master | awk '{print $1}')
branchpoint=$(git merge-base origin/master HEAD)
test "$remotemaster" = "$branchpoint"
The difference is that we're checking against the branch point. If
origin/master is beyond the branch point then chances are you need to
pull.
---- off topic, but related ----
BTW one sound recommendation that I've heard on this list is that your
topic branches should really be free of any unrelated changes.
Pulling stuff in "just because" changes the branch. It's no longer
just "topic" -- it's now "topic" + whatever they happened to push
upstream. That has some implications in that it makes it harder to
review what exactly went into the specific topic/feature since the
branch's history now contains unrelated changes.
An advantage of keeping your topic branches clean is that you can run:
git diff $(git merge-base HEAD origin/master)
in your topic branch and you'll see *only* the changes that went into
that branch. If you get into the habit of pulling stuff in then
you'll see your changes *and* stuff you've pulled in, which probably
has nothing to do with the original topic/feature, etc. etc.
Anyways, this is an entirely different topic/conversation and might
not apply to your specific circumstance but I figured I'd mention it
nonetheless.
--
David
^ permalink raw reply
* Re: how to check remote git repo for updates without pull/fetch
From: Boyd Stephen Smith Jr. @ 2008-12-21 0:02 UTC (permalink / raw)
To: git; +Cc: David Aguilar, James Cloos, Ivan Zorin
In-Reply-To: <402731c90812201541r510170tbe1d56b7261e8146@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 1223 bytes --]
On Saturday 2008 December 20 17:41:13 David Aguilar wrote:
> 2008/12/20 James Cloos <cloos@jhcloos.com>:
> > #!/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}"
> >
> >
> > -JimC
> > --
> > James Cloos <cloos@jhcloos.com> OpenPGP: 1024D/ED7DAEA6
>
> Hello
>
> Your script will report false positives if you run that in a branch
> where you've made local commits since git log's output will list a
> commit that's not on the remote side.
Change the last line to:
test "${r}" != "$(git merge-base "${r}" "${l}")" and those false positives
should go away.
The script is far from a complete solution to the OPs problem though. It only
checks one, specific remote branch. It only checks against the current
branch. It is the core of something that might be useful as another
subcommand to 'git remote' though.
--
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
* [PATCH] Have manpage reference new documentation on reverting merges.
From: Boyd Stephen Smith Jr. @ 2008-12-21 0:32 UTC (permalink / raw)
To: git, Nanako Shiraishi, Junio C Hamano
Signed-off-by: Boyd Stephen Smith Jr <bss@iguanasuicide.net>
---
An example addition to the manpage for revert that references Nanako
Shiraishi's new documentation.
Documentation/git-revert.txt | 4 ++++
1 files changed, 4 insertions(+), 0 deletions(-)
diff --git a/Documentation/git-revert.txt b/Documentation/git-revert.txt
index caa0729..ea36bdf 100644
--- a/Documentation/git-revert.txt
+++ b/Documentation/git-revert.txt
@@ -45,6 +45,10 @@ OPTIONS
the mainline and allows revert to reverse the change
relative to the specified parent.
+ Reverting a merge commit does not completely "undo" the effect of the
+ merge and it may make future merges more difficult. For more details,
+ please read Documentation/howto/revert-a-faulty-merge.txt.
+
--no-edit::
With this option, 'git-revert' will not start the commit
message editor.
--
1.5.6
--
Boyd Stephen Smith Jr. ,= ,-_-. =.
bss@iguanasuicide.net ((_/)o o(\_))
ICQ: 514984 YM/AIM: DaTwinkDaddy `-'(. .)`-'
http://iguanasuicide.net/ \_/
^ permalink raw reply related
* [PATCH] connect.c: stricter port validation, silence compiler warning
From: René Scharfe @ 2008-12-21 1:12 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Git Mailing List
In addition to checking if the provided port is numeric, also check
that the string isn't empty and that the port number is within the
valid range. Incidentally, this silences a compiler warning about
ignoring strtol's return value.
Signed-off-by: Rene Scharfe <rene.scharfe@lsrfire.ath.cx>
---
connect.c | 4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/connect.c b/connect.c
index 584e04c..2f55ad2 100644
--- a/connect.c
+++ b/connect.c
@@ -480,8 +480,8 @@ char *get_port(char *host)
char *p = strchr(host, ':');
if (p) {
- strtol(p+1, &end, 10);
- if (*end == '\0') {
+ long port = strtol(p + 1, &end, 10);
+ if (end != p + 1 && *end == '\0' && 0 <= port && port < 65536) {
*p = '\0';
return p+1;
}
--
1.6.1.rc3.52.g589372
^ permalink raw reply related
* [PATCH] fast-import.c: stricter strtoul check, silence compiler warning
From: René Scharfe @ 2008-12-21 1:28 UTC (permalink / raw)
To: Git Mailing List; +Cc: Junio C Hamano
Store the return value of strtoul() in order to avoid compiler
warnings on Ubuntu 8.10.
Also check errno after each call, which is the only way to notice
an overflow without making ULONG_MAX an illegal date.
Signed-off-by: Rene Scharfe <rene.scharfe@lsrfire.ath.cx>
---
I don't really like the first part, as we're ignoring the return
value anyway, even if we store it in the variable "date", so this
is quite useless. But better to have a bit more useless code
than to see these equally useless warnings on every build.
Turning them off completely is not a good idea, since some of
them resulted in useful fixes (see 47d32af2, 304dcf26, 7be77de2).
fast-import.c | 11 +++++++----
1 files changed, 7 insertions(+), 4 deletions(-)
diff --git a/fast-import.c b/fast-import.c
index 171d178..a6bce66 100644
--- a/fast-import.c
+++ b/fast-import.c
@@ -1748,18 +1748,21 @@ static int validate_raw_date(const char *src, char *result, int maxlen)
{
const char *orig_src = src;
char *endp, sign;
+ unsigned long date;
- strtoul(src, &endp, 10);
- if (endp == src || *endp != ' ')
+ errno = 0;
+
+ date = strtoul(src, &endp, 10);
+ if (errno || endp == src || *endp != ' ')
return -1;
src = endp + 1;
if (*src != '-' && *src != '+')
return -1;
sign = *src;
- strtoul(src + 1, &endp, 10);
- if (endp == src || *endp || (endp - orig_src) >= maxlen)
+ date = strtoul(src + 1, &endp, 10);
+ if (errno || endp == src || *endp || (endp - orig_src) >= maxlen)
return -1;
strcpy(result, orig_src);
--
1.6.1.rc3.52.g589372
^ permalink raw reply related
* [PATCH 1/2] fast-import: add special mode; copy from parent.
From: Felipe Contreras @ 2008-12-21 2:11 UTC (permalink / raw)
To: git; +Cc: Felipe Contreras
Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com>
---
Documentation/git-fast-import.txt | 1 +
fast-import.c | 41 +++++++++++++++++++++---------------
2 files changed, 25 insertions(+), 17 deletions(-)
diff --git a/Documentation/git-fast-import.txt b/Documentation/git-fast-import.txt
index c2f483a..9d4231e 100644
--- a/Documentation/git-fast-import.txt
+++ b/Documentation/git-fast-import.txt
@@ -484,6 +484,7 @@ in octal. Git only supports the following modes:
* `160000`: A gitlink, SHA-1 of the object refers to a commit in
another repository. Git links can only be specified by SHA or through
a commit mark. They are used to implement submodules.
+* `-`: A special mode; copy the parent's mode.
In both formats `<path>` is the complete path of the file to be added
(if not already existing) or modified (if already existing).
diff --git a/fast-import.c b/fast-import.c
index 3c035a5..a00d3fe 100644
--- a/fast-import.c
+++ b/fast-import.c
@@ -1356,7 +1356,7 @@ static int tree_content_set(
struct tree_entry *root,
const char *p,
const unsigned char *sha1,
- const uint16_t mode,
+ uint16_t mode,
struct tree_content *subtree)
{
struct tree_content *t = root->tree;
@@ -1382,7 +1382,9 @@ static int tree_content_set(
&& e->versions[1].mode == mode
&& !hashcmp(e->versions[1].sha1, sha1))
return 0;
- e->versions[1].mode = mode;
+ if (mode == S_IFREG)
+ mode = e->versions[0].mode;
+ e->versions[1].mode = (mode == S_IFREG) ? (S_IFREG | 0644) : mode;
hashcpy(e->versions[1].sha1, sha1);
if (e->tree)
release_tree_content_recursive(e->tree);
@@ -1417,7 +1419,7 @@ static int tree_content_set(
tree_content_set(e, slash1 + 1, sha1, mode, subtree);
} else {
e->tree = subtree;
- e->versions[1].mode = mode;
+ e->versions[1].mode = (mode == S_IFREG) ? (S_IFREG | 0644) : mode;
hashcpy(e->versions[1].sha1, sha1);
}
hashclr(root->versions[1].sha1);
@@ -1862,20 +1864,25 @@ static void file_change_m(struct branch *b)
unsigned char sha1[20];
uint16_t mode, inline_data = 0;
- p = get_mode(p, &mode);
- if (!p)
- die("Corrupt mode: %s", command_buf.buf);
- switch (mode) {
- case S_IFREG | 0644:
- case S_IFREG | 0755:
- case S_IFLNK:
- case S_IFGITLINK:
- case 0644:
- case 0755:
- /* ok */
- break;
- default:
- die("Corrupt mode: %s", command_buf.buf);
+ if (!prefixcmp(p, "- ")) {
+ mode = 0;
+ p += 2;
+ } else {
+ p = get_mode(p, &mode);
+ if (!p)
+ die("Corrupt mode: %s", command_buf.buf);
+ switch (mode) {
+ case S_IFREG | 0644:
+ case S_IFREG | 0755:
+ case S_IFLNK:
+ case S_IFGITLINK:
+ case 0644:
+ case 0755:
+ /* ok */
+ break;
+ default:
+ die("Corrupt mode: %s", command_buf.buf);
+ }
}
if (*p == ':') {
--
1.6.0.6.3.g7ccbd
^ 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