* Re: [RFC] git rm -u
From: Matthieu Moy @ 2013-02-25 19:39 UTC (permalink / raw)
To: Antoine Pelisse
Cc: Junio C Hamano, Eric James Michael Ritz, Tomas Carnecky, git
In-Reply-To: <CALWbr2y-CN9A346avc4AG+FN9NHgPXKvWuU-nbcyjt08DavVjw@mail.gmail.com>
Antoine Pelisse <apelisse@gmail.com> writes:
>> "git rm" really seems to be a better place for removing files from the
>> index.
>
> Then, I don't exactly understand the meaning of git-rm but being a
> _shortcut_ for "remove and stage".
"git rm --cached" is exactly "remove from index".
And even without --cached, as you notice yourself, it does a "remove and
stage [removal]", so why would it be inappropriate to stage a removal?
--
Matthieu Moy
http://www-verimag.imag.fr/~moy/
^ permalink raw reply
* Re: [RFC] git rm -u
From: Junio C Hamano @ 2013-02-25 19:47 UTC (permalink / raw)
To: Matthieu Moy
Cc: Antoine Pelisse, Eric James Michael Ritz, Tomas Carnecky, git
In-Reply-To: <vpqliac41zf.fsf@grenoble-inp.fr>
Matthieu Moy <Matthieu.Moy@grenoble-inp.fr> writes:
> Antoine Pelisse <apelisse@gmail.com> writes:
>
>>> "git rm" really seems to be a better place for removing files from the
>>> index.
>>
>> Then, I don't exactly understand the meaning of git-rm but being a
>> _shortcut_ for "remove and stage".
>
> "git rm --cached" is exactly "remove from index".
>
> And even without --cached, as you notice yourself, it does a "remove and
> stage [removal]", so why would it be inappropriate to stage a removal?
I do not think "git rm" is a bad place to add the feature; I was
questioning if "-u" is an appropriate option. The option "-u" given
to "git add" is internally called "take worktree changes", and we
would need the option to "git rm" with that internal meaning. The
superficial meaning "updated" that "-u" in "add -u" stands for does
not really match what "git rm --take-worktree-changes" wants to do,
as we obviously do not want to remove all updated/modified files.
^ permalink raw reply
* Re: [PATCH] diff: Fix rename pretty-print when suffix and prefix overlap
From: Antoine Pelisse @ 2013-02-25 19:50 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vzjyu3we1.fsf@alter.siamese.dyndns.org>
On Sun, Feb 24, 2013 at 10:15 AM, Junio C Hamano <gitster@pobox.com> wrote:
> Antoine Pelisse <apelisse@gmail.com> writes:
>
>> When considering a rename for two files that have a suffix and a prefix
>> that can overlap, a confusing line is shown. As an example, renaming
>> "a/b/b/c" to "a/b/c" shows "a/b/{ => }/b/c".
>
> This would be vastly more readable if it had "It should show XXX
> instead" somewhere in the description, perhaps at the end of this
> sentence. It can also be after "thus the { => }" below, but I think
> giving the expected output earlier would be more appropriate.
Good catch, this would probably be better:
When considering a rename for two files that have a suffix and a prefix
that can overlap, a confusing line is shown. As an example, renaming
"a/b/b/c" to "a/b/c" shows "a/b/{ => }/b/c", instead of "a/b/{ => b}/c"
>> Currently, what we do is calculate the common prefix ("a/b/"), and the
>> common suffix ("/b/c"), but the same "/b/" is actually counted both in
>> prefix and suffix. Then when calculating the size of the non-common part,
>> we end-up with a negative value which is reset to 0, thus the "{ => }".
>
> In this example, the common prefix would be "a/b/" and the common
> suffix that does not overlap with the prefix part would be "/c", so
> I am imagining that "a/b/{ => b}/c" would be the desired output?
Yes, at least that's what I expected.
> This is a really old thinko (dating back to June 2005). I'll queue
> the patch on maint-1.7.6 (because 1.7.6.6 is slightly more than one
> year old while 1.7.5.4 is a lot older) to allow distros that issue
> incremental fixes on top of ancient versions of Git to pick up the
> fix if they wanted to. Perhaps we would want to add a few tests?
I can easily understand why that was missed.
I will try to resubmit with tests very soon.
^ permalink raw reply
* Re: Possible regression in ref advertisement
From: Carlos Martín Nieto @ 2013-02-25 19:54 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, peff
In-Reply-To: <7vip5gxkgy.fsf@alter.siamese.dyndns.org>
On Mon, 2013-02-25 at 11:27 -0800, Junio C Hamano wrote:
> Carlos Martín Nieto <cmn@elego.de> writes:
>
> > On Mon, 2013-02-25 at 10:31 -0800, Junio C Hamano wrote:
> > ...
> >> Interesting. "git ls-remote . | grep 1.8.0-" for maint, master,
> >> next and pu produce identical results for me, all showing peeled
> >> ones correctly.
> >
> > Bisection leads me to Peff's 435c8332 (2012-10-04; upload-pack: use
> > peel_ref for ref advertisements) and reverting that commit brings the
> > -rc3^{} back.
>
> A shot in the dark, as I do not seem to be able to reproduce the issue
> with anything that contains the commit. Perhaps your .git/packed-refs
> is corrupt?
My packed-refs file did not end with LF. It seems it must or the parser
won't consider the last tag in the file to have a peeled target and mine
didn't. I don't how the ended up this way but it looks like there's is a
bug in the parser (or does the format force you to have LF at the end?)
cmn
^ permalink raw reply
* Re: Possible regression in ref advertisement
From: Junio C Hamano @ 2013-02-25 20:07 UTC (permalink / raw)
To: Carlos Martín Nieto; +Cc: git, peff
In-Reply-To: <1361822092.30765.12.camel@centaur.cmartin.tk>
Carlos Martín Nieto <cmn@elego.de> writes:
>> A shot in the dark, as I do not seem to be able to reproduce the issue
>> with anything that contains the commit. Perhaps your .git/packed-refs
>> is corrupt?
>
> My packed-refs file did not end with LF. It seems it must or the parser
> won't consider the last tag in the file to have a peeled target and mine
> didn't. I don't how the ended up this way but it looks like there's is a
> bug in the parser (or does the format force you to have LF at the end?)
It is unclear what kind of corruption your packed-refs file had, as
there are multiple ways for a file not to "end with LF", but anyway.
As packed-refs file is expected to be a text file, it is not
surprising to get an undefined result if the it ends with an
incomplete line.
I do not offhand recall if we tolerate lines with CRLF endings; as
far as I know we do not _write_ CRLF out, and because we do not
expect people to muck directly with editor bypassing "pack-refs", I
would not be surprised if we didn't do anything special for people
who make the lines end with with CRLF the file, either.
I'd be more worried about the possibly lost entries after that
incomplete line (and also possibly truncated end part of the tagname
on the last, incomplete line). Perhaps fsck should diagnose such an
anomaly as repository corruption? Perhaps we should enhance the
file format a bit (right now, the first "capability" line should say
something like "# pack-refs with: peeled" to say it was created with
the version of pack-refs that can record peeled tags, but we can add
other capabilities to extend the format) to add checksums to detect
corruption?
^ permalink raw reply
* Re: [PATCH] git-compat-util.h: Provide missing netdb.h definitions
From: Junio C Hamano @ 2013-02-25 20:16 UTC (permalink / raw)
To: David Michael; +Cc: git@vger.kernel.org
In-Reply-To: <CAEvUa7n_EsKnKQNuyvSiZW8s_rZv4oQrFNDX9wa_JSr_REj89w@mail.gmail.com>
Thanks.
^ permalink raw reply
* Re: [PATCH ] t4210-log-i18n: spell encoding name "UTF-8" correctly
From: Jeff King @ 2013-02-25 20:31 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Johannes Sixt, Thomas Haller, Git List
In-Reply-To: <7vmwusxlfm.fsf@alter.siamese.dyndns.org>
On Mon, Feb 25, 2013 at 11:06:37AM -0800, Junio C Hamano wrote:
> Jeff King <peff@peff.net> writes:
>
> > ... I think the simplest thing would just be:
> >
> > diff --git a/utf8.c b/utf8.c
> > index 1087870..8d42b50 100644
> > --- a/utf8.c
> > +++ b/utf8.c
> > @@ -507,6 +507,17 @@ char *reencode_string(const char *in, const char *out_encoding, const char *in_e
> >
> > if (!in_encoding)
> > return NULL;
> > +
> > + /*
> > + * Some platforms do not have the variously spelled variants of
> > + * UTF-8, so let us feed iconv the most official spelling, which
> > + * should hopefully be accepted everywhere.
> > + */
> > + if (is_encoding_utf8(in_encoding))
> > + in_encoding = "UTF-8";
> > + if (is_encoding_utf8(out_encoding))
> > + out_encoding = "UTF-8";
> > +
> > conv = iconv_open(out_encoding, in_encoding);
> > if (conv == (iconv_t) -1)
> > return NULL;
> >
> > Does that fix the tests for you? It's a larger change, but I think it
> > makes git friendlier all around for people on Windows.
>
> Yeah, if this is confirmed to work OK (from eyeballing I do not see
> a reason why not...) I agree this is the cleanest way forward.
The only reason I can think of is that you specify "utf8", your platform
understands "utf8" but not "UTF-8", and we rewrite it silently to
"UTF-8". That seems somewhat unlikely, but to be on the safe side, why
don't we do it as a fallback? That should be fine performance-wise, as
it only triggers on the error case.
Like this:
-- >8 --
Subject: [PATCH] utf8: accept alternate spellings of UTF-8
The iconv implementation on many platforms will accept
variants of UTF-8, including "UTF8", "utf-8", and "utf8",
but some do not. We make allowances in our code to treat
them all identically, but we sometimes hand the string from
the user directly to iconv. In this case, the platform iconv
may or may not work.
There are really four levels of platform iconv support for
these synonyms:
1. All synonyms understood (e.g., glibc).
2. Only the official "UTF-8" understood (e.g., Windows).
3. Official "UTF-8" not understood, but some other synonym
understood (it's not known whether such a platform exists).
4. Neither "UTF-8" nor any synonym understood (e.g.,
ancient systems, or ones without utf8 support
installed).
This patch teaches git to fall back to using the official
"UTF-8" spelling when iconv_open fails (and the encoding was
one of the synonym spellings). This makes things more
convenient to users of type 2 systems, as they can now use
any of the synonyms for the log output encoding.
Type 1 systems are not affected, as iconv already works on
the first try.
Type 4 systems are not affected, as both attempts already
fail.
Type 3 systems will not benefit from the feature, but
because we only use "UTF-8" as a fallback, they will not be
regressed (i.e., you can continue to use "utf8" if your
platform supports it). We could try all the various
synonyms, but since such systems are not even known to
exist, it's not worth the effort.
Signed-off-by: Jeff King <peff@peff.net>
---
JSixt, can you double-check that this passes t4210 for you?
utf8.c | 20 ++++++++++++++++++--
1 file changed, 18 insertions(+), 2 deletions(-)
diff --git a/utf8.c b/utf8.c
index 1087870..8f6e84b 100644
--- a/utf8.c
+++ b/utf8.c
@@ -507,9 +507,25 @@ char *reencode_string(const char *in, const char *out_encoding, const char *in_e
if (!in_encoding)
return NULL;
+
conv = iconv_open(out_encoding, in_encoding);
- if (conv == (iconv_t) -1)
- return NULL;
+ if (conv == (iconv_t) -1) {
+ /*
+ * Some platforms do not have the variously spelled variants of
+ * UTF-8, so let's fall back to trying the most official
+ * spelling. We do so only as a fallback in case the platform
+ * does understand the user's spelling, but not our official
+ * one.
+ */
+ if (is_encoding_utf8(in_encoding))
+ in_encoding = "UTF-8";
+ if (is_encoding_utf8(out_encoding))
+ out_encoding = "UTF-8";
+ conv = iconv_open(out_encoding, in_encoding);
+ if (conv == (iconv_t) -1)
+ return NULL;
+ }
+
out = reencode_string_iconv(in, strlen(in), conv);
iconv_close(conv);
return out;
--
1.8.1.4.4.g265d2fa
^ permalink raw reply related
* Re: Possible regression in ref advertisement
From: Carlos Martín Nieto @ 2013-02-25 20:35 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, peff
In-Reply-To: <7v1uc4ximl.fsf@alter.siamese.dyndns.org>
On Mon, 2013-02-25 at 12:07 -0800, Junio C Hamano wrote:
> Carlos Martín Nieto <cmn@elego.de> writes:
>
> >> A shot in the dark, as I do not seem to be able to reproduce the issue
> >> with anything that contains the commit. Perhaps your .git/packed-refs
> >> is corrupt?
> >
> > My packed-refs file did not end with LF. It seems it must or the parser
> > won't consider the last tag in the file to have a peeled target and mine
> > didn't. I don't how the ended up this way but it looks like there's is a
> > bug in the parser (or does the format force you to have LF at the end?)
>
> It is unclear what kind of corruption your packed-refs file had, as
> there are multiple ways for a file not to "end with LF", but anyway.
I mean that the file ended at the end of the peeled id. It was missing
the last empty line.
>
> As packed-refs file is expected to be a text file, it is not
> surprising to get an undefined result if the it ends with an
> incomplete line.
I guess that depends on what you mean by incomplete. All the data is
there, just that it had
<tag id> SP <refname> LF ^<peeled id>
as the last entry instead of
<tag id> SP <refname> LF ^<peeled id> LF
The parser skips the last entry if there is no trailing LF (the same
happens for lightweight tags, though here it simply doesn't report
them).
>
> I do not offhand recall if we tolerate lines with CRLF endings; as
> far as I know we do not _write_ CRLF out, and because we do not
> expect people to muck directly with editor bypassing "pack-refs", I
> would not be surprised if we didn't do anything special for people
> who make the lines end with with CRLF the file, either.
I wouldn't expect it to work. It would probably skip over those entries.
>
> I'd be more worried about the possibly lost entries after that
> incomplete line (and also possibly truncated end part of the tagname
> on the last, incomplete line). Perhaps fsck should diagnose such an
> anomaly as repository corruption? Perhaps we should enhance the
> file format a bit (right now, the first "capability" line should say
> something like "# pack-refs with: peeled" to say it was created with
> the version of pack-refs that can record peeled tags, but we can add
> other capabilities to extend the format) to add checksums to detect
> corruption?
>
I just tested and the parser ignores any malformed lines. The ones after
it are fine. Nothing complains though, ls-remote just shows the next
entry. I'd expect at least fsck to complain, but it doesn't say
anything. Presumably they all use the same parser that just ignores
anything it doesn't like.
cmn
^ permalink raw reply
* Re: [PATCH] Makefile: make mandir, htmldir and infodir absolute
From: Junio C Hamano @ 2013-02-25 20:35 UTC (permalink / raw)
To: John Keeping; +Cc: Jonathan Nieder, git, Steffen Prohaska, Jakub Narebski
In-Reply-To: <20130224195500.GA27578@serenity.lan>
John Keeping <john@keeping.me.uk> writes:
> This matches the use of the variables with the same names in autotools,
> reducing the potential for user surprise.
>
> Using relative paths in these variables also causes issues if they are
> exported from the Makefile, as discussed in commit c09d62f (Makefile: do
> not export mandir/htmldir/infodir, 2013-02-12).
>
> Suggested-by: Junio C Hamano <gitster@pobox.com>
> Signed-off-by: John Keeping <john@keeping.me.uk>
> ---
> On Tue, Feb 12, 2013 at 03:09:53PM -0800, Junio C Hamano wrote:
>> A longer term fix is to introduce runtime_{man,html,info}dir variables
>> to hold these funny values, and make {man,html,info}dir variables
>> to have real paths whose default values begin with $(prefix), but
>> as a first step, stop exporting them from the top-level Makefile.
>
> Here's an attempt at doing that.
>
> If this is sensible, should bindir_relative be calculated in the same
> way?
Thanks for taking the cue from existing bindir_relative, which I
overlooked. Calling these *dir_relative, not runtime_*dir as I
hinted, makes a lot more sense and overall makes things consistent.
As most people would want to say bindir=/usr/local/bin and not
bindir_relative=bin from the command line (and I suspect that people
coming from ./configure would not even have a way to specify the
latter), I think your suggestion to make bindir the primary one and
derive bindir_relative from it makes sense.
What do Windows folks think?
[patch unsnipped for others' reference]
> Makefile | 36 +++++++++++++++++++++---------------
> 1 file changed, 21 insertions(+), 15 deletions(-)
>
> diff --git a/Makefile b/Makefile
> index 7c75e3b..087eec4 100644
> --- a/Makefile
> +++ b/Makefile
> @@ -360,33 +360,39 @@ STRIP ?= strip
> # Among the variables below, these:
> # gitexecdir
> # template_dir
> -# mandir
> -# infodir
> -# htmldir
> # sysconfdir
> # can be specified as a relative path some/where/else;
> # this is interpreted as relative to $(prefix) and "git" at
> # runtime figures out where they are based on the path to the executable.
> +# Additionally, the following will be treated as relative by "git" if they
> +# begin with "$(prefix)/":
> +# mandir
> +# infodir
> +# htmldir
> # This can help installing the suite in a relocatable way.
>
> prefix = $(HOME)
> bindir_relative = bin
> bindir = $(prefix)/$(bindir_relative)
> -mandir = share/man
> -infodir = share/info
> +mandir = $(prefix)/share/man
> +infodir = $(prefix)/share/info
> gitexecdir = libexec/git-core
> mergetoolsdir = $(gitexecdir)/mergetools
> sharedir = $(prefix)/share
> gitwebdir = $(sharedir)/gitweb
> localedir = $(sharedir)/locale
> template_dir = share/git-core/templates
> -htmldir = share/doc/git-doc
> +htmldir = $(prefix)/share/doc/git-doc
> ETC_GITCONFIG = $(sysconfdir)/gitconfig
> ETC_GITATTRIBUTES = $(sysconfdir)/gitattributes
> lib = lib
> # DESTDIR =
> pathsep = :
>
> +mandir_relative = $(patsubst $(prefix)/%,%,$(mandir))
> +infodir_relative = $(patsubst $(prefix)/%,%,$(infodir))
> +htmldir_relative = $(patsubst $(prefix)/%,%,$(htmldir))
> +
> export prefix bindir sharedir sysconfdir gitwebdir localedir
>
> CC = cc
> @@ -1548,12 +1554,12 @@ ETC_GITATTRIBUTES_SQ = $(subst ','\'',$(ETC_GITATTRIBUTES))
> DESTDIR_SQ = $(subst ','\'',$(DESTDIR))
> bindir_SQ = $(subst ','\'',$(bindir))
> bindir_relative_SQ = $(subst ','\'',$(bindir_relative))
> -mandir_SQ = $(subst ','\'',$(mandir))
> -infodir_SQ = $(subst ','\'',$(infodir))
> +mandir_relative_SQ = $(subst ','\'',$(mandir_relative))
> +infodir_relative_SQ = $(subst ','\'',$(infodir_relative))
> localedir_SQ = $(subst ','\'',$(localedir))
> gitexecdir_SQ = $(subst ','\'',$(gitexecdir))
> template_dir_SQ = $(subst ','\'',$(template_dir))
> -htmldir_SQ = $(subst ','\'',$(htmldir))
> +htmldir_relative_SQ = $(subst ','\'',$(htmldir_relative))
> prefix_SQ = $(subst ','\'',$(prefix))
> gitwebdir_SQ = $(subst ','\'',$(gitwebdir))
>
> @@ -1685,9 +1691,9 @@ strip: $(PROGRAMS) git$X
>
> git.sp git.s git.o: GIT-PREFIX
> git.sp git.s git.o: EXTRA_CPPFLAGS = \
> - '-DGIT_HTML_PATH="$(htmldir_SQ)"' \
> - '-DGIT_MAN_PATH="$(mandir_SQ)"' \
> - '-DGIT_INFO_PATH="$(infodir_SQ)"'
> + '-DGIT_HTML_PATH="$(htmldir_relative_SQ)"' \
> + '-DGIT_MAN_PATH="$(mandir_relative_SQ)"' \
> + '-DGIT_INFO_PATH="$(infodir_relative_SQ)"'
>
> git$X: git.o GIT-LDFLAGS $(BUILTIN_OBJS) $(GITLIBS)
> $(QUIET_LINK)$(CC) $(ALL_CFLAGS) -o $@ git.o \
> @@ -1697,9 +1703,9 @@ help.sp help.s help.o: common-cmds.h
>
> builtin/help.sp builtin/help.s builtin/help.o: common-cmds.h GIT-PREFIX
> builtin/help.sp builtin/help.s builtin/help.o: EXTRA_CPPFLAGS = \
> - '-DGIT_HTML_PATH="$(htmldir_SQ)"' \
> - '-DGIT_MAN_PATH="$(mandir_SQ)"' \
> - '-DGIT_INFO_PATH="$(infodir_SQ)"'
> + '-DGIT_HTML_PATH="$(htmldir_relative_SQ)"' \
> + '-DGIT_MAN_PATH="$(mandir_relative_SQ)"' \
> + '-DGIT_INFO_PATH="$(infodir_relative_SQ)"'
>
> version.sp version.s version.o: GIT-VERSION-FILE GIT-USER-AGENT
> version.sp version.s version.o: EXTRA_CPPFLAGS = \
^ permalink raw reply
* Re: [PATCH ] t4210-log-i18n: spell encoding name "UTF-8" correctly
From: Jeff King @ 2013-02-25 20:36 UTC (permalink / raw)
To: Torsten Bögershausen
Cc: Johannes Sixt, Junio C Hamano, Thomas Haller, Git List
In-Reply-To: <512BB377.2010403@web.de>
On Mon, Feb 25, 2013 at 07:54:47PM +0100, Torsten Bögershausen wrote:
> (beside that I couldn't find t4210 somewhere),
It's newly added in 04deccd.
> diff --git a/utf8.c b/utf8.c
> index a4ee665..e9850d0 100644
> --- a/utf8.c
> +++ b/utf8.c
> @@ -487,6 +487,10 @@ char *reencode_string(const char *in, const char *out_encoding, const char *in_e
> if (!in_encoding)
> return NULL;
> conv = iconv_open(out_encoding, in_encoding);
> + if (conv == (iconv_t) -1 && errno == EINVAL) {
> + conv = iconv_open(is_encoding_utf8(out_encoding) ? "UTF-8" : out_encoding,
> + is_encoding_utf8(in_encoding) ? "UTF-8" : in_encoding);
> + }
Yeah, I think this is pretty close to the patch I just sent. You do the
fallback, which I think is sane to prevent any possible regression (for
"type 3" systems, as I called them in my commit). I don't know if it is
worth checking errno; we should get the same failure either way, and I'd
worry slightly about some odd iconv implementation does not use EINVAL.
And of course, I like my indentation and commit message better. :)
-Peff
^ permalink raw reply
* Re: [PATCH ] t4210-log-i18n: spell encoding name "UTF-8" correctly
From: Torsten Bögershausen @ 2013-02-25 21:00 UTC (permalink / raw)
To: Jeff King; +Cc: Johannes Sixt, Junio C Hamano, Thomas Haller, Git List
In-Reply-To: <20130225151916.GA7725@sigill.intra.peff.net>
On 25.02.13 16:19, Jeff King wrote:
> On Mon, Feb 25, 2013 at 09:37:50AM +0100, Johannes Sixt wrote:
>
>> From: Johannes Sixt <j6t@kdbg.org>
>>
>> iconv on Windows does not know the encoding name "utf8", and does not
>> re-encode log messages when this name is given. Request "UTF-8" encoding.
>>
>> Signed-off-by: Johannes Sixt <j6t@kdbg.org>
>> ---
>> I'm not sure whether I'm right to say that "UTF-8" is the correct
>> spelling. Anyway, 'iconv -l' on my old Linux box lists "UTF8", but on
>> Windows it does not.
>
> UTF-8 is correct according to:
>
> https://en.wikipedia.org/wiki/Utf8#Official_name_and_variants
>
>> A more correct fix would probably be to use is_encoding_utf8() in more
>> places, but it's outside my time budget look after it.
>
> Yeah, I wonder if this is a symptom of a deeper issue, which is that
> utf-8 has many synonyms, and we would prefer to canonicalize the
> encoding name before generating an object to avoid inconsistencies (of
> course we cannot do so for every imaginable encoding, but utf-8 is a
> pretty obvious one we handle already). We _should_ be generating commits
> with no encoding header at all for utf-8, though.
>
> And indeed, it looks like that is the case. commit_tree_extended has:
>
> /* Not having i18n.commitencoding is the same as having utf-8 */
> encoding_is_utf8 = is_encoding_utf8(git_commit_encoding);
>
> [...]
>
> if (!encoding_is_utf8)
> strbuf_addf(&buffer, "encoding %s\n", git_commit_encoding);
>
>
> which makes me think that this first hunk...
>
>> diff --git a/t/t4210-log-i18n.sh b/t/t4210-log-i18n.sh
>> index 52a7472..b1956e2 100755
>> --- a/t/t4210-log-i18n.sh
>> +++ b/t/t4210-log-i18n.sh
>> @@ -15,7 +15,7 @@ test_expect_success 'create commits in different encodings' '
>> t${utf8_e}st
>> EOF
>> git add msg &&
>> - git -c i18n.commitencoding=utf8 commit -F msg &&
>> + git -c i18n.commitencoding=UTF-8 commit -F msg &&
>> cat >msg <<-EOF &&
>> latin1
>
> ...should be a no-op; the utf8 there should never be seen by anybody but
> git. Can you confirm that is the case?
>
>> @@ -30,7 +30,7 @@ test_expect_success 'log --grep searches in log output encoding (utf8)' '
>> latin1
>> utf8
>> EOF
>> - git log --encoding=utf8 --format=%s --grep=$utf8_e >actual &&
>> + git log --encoding=UTF-8 --format=%s --grep=$utf8_e >actual &&
>> test_cmp expect actual
>> '
>
> This one will feed it to iconv, though, because the latin1 commit will
> need to be re-encoded. I think the simplest thing would just be:
>
> diff --git a/utf8.c b/utf8.c
> index 1087870..8d42b50 100644
> --- a/utf8.c
> +++ b/utf8.c
> @@ -507,6 +507,17 @@ char *reencode_string(const char *in, const char *out_encoding, const char *in_e
>
> if (!in_encoding)
> return NULL;
> +
> + /*
> + * Some platforms do not have the variously spelled variants of
> + * UTF-8, so let us feed iconv the most official spelling, which
> + * should hopefully be accepted everywhere.
> + */
> + if (is_encoding_utf8(in_encoding))
> + in_encoding = "UTF-8";
> + if (is_encoding_utf8(out_encoding))
> + out_encoding = "UTF-8";
> +
> conv = iconv_open(out_encoding, in_encoding);
> if (conv == (iconv_t) -1)
> return NULL;
>
> Does that fix the tests for you? It's a larger change, but I think it
> makes git friendlier all around for people on Windows.
>
> -Peff
> --
Thanks, I'm OK with your version.
And a test on cygwin was OK for the new t4210.
^ permalink raw reply
* Re: Possible regression in ref advertisement
From: Junio C Hamano @ 2013-02-25 21:16 UTC (permalink / raw)
To: Carlos Martín Nieto; +Cc: git, peff
In-Reply-To: <1361824519.31692.12.camel@centaur.cmartin.tk>
Carlos Martín Nieto <cmn@elego.de> writes:
>> As packed-refs file is expected to be a text file, it is not
>> surprising to get an undefined result if the it ends with an
>> incomplete line.
>
> I guess that depends on what you mean by incomplete.
I used that word in the POSIX sense, i.e.
http://pubs.opengroup.org/onlinepubs/9699919799/xrat/V4_xbd_chap03.html#tag_21_03_00_67
Unless the user edited the file, an incomplete line may indicate
that the file has been truncated when (or after) it was written, and
we have to suspect not just that the last "line" may have been
truncated (in this case, not having the full 40-hex object name),
but other records that should have been after that line were lost.
We may want to detect such corruption at runtime, at least at
strategic places; making it a hard runtime error will make it
difficult to use Git itself to recover from such an corruption
(e.g. you may have a healty mirror from which you can recover refs
with "fetch --mirror").
We should at least refrain from running repack/gc to make things
worse, for example.
^ permalink raw reply
* Re: [PATCH 1/1] Fix date checking in case if time was not initialized.
From: Mike Gorchak @ 2013-02-25 21:47 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7va9qsxjzk.fsf@alter.siamese.dyndns.org>
>> So is_date() always return negative result for the text string where
>> date is placed before time like '2008-02-14 20:30:45'.
> Yes, it returns this -1 on other platforms, but...
>> It must fail on
>> other platforms as well.
It also fails under Linux, but real problem is not here, it is just an
unoptimal date parser.
> ... the input '2008-02-14 20:30:45' still parses fine for others
> (including me). That is what is puzzling.
> A shot in the dark: perhaps your time_t is unsigned?
Yeah, it was a headshot :) It really due to unsigned time_t. I will
send two patches right now with fixes regarding unsigned time_t
comparison.
^ permalink raw reply
* [PATCH 1/1] Fix unsigned time_t comparison
From: Mike Gorchak @ 2013-02-25 21:51 UTC (permalink / raw)
To: git
Do not compare time_t (less comparison) with -1. If time_t
is unsigned this leads to always true comparison.
Signed-off-by: Mike Gorchak <mike.gorchak.qnx@gmail.com>
---
date.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/date.c b/date.c
index 57331ed..1ac28e5 100644
--- a/date.c
+++ b/date.c
@@ -383,7 +383,7 @@ static int is_date(int year, int month, int day,
struct tm *now_tm, time_t now,
* sense to specify timestamp way into the future. Make
* sure it is not later than ten days from now...
*/
- if (now + 10*24*3600 < specified)
+ if ((specified != -1) && (now + 10*24*3600 < specified))
return 0;
tm->tm_mon = r->tm_mon;
tm->tm_mday = r->tm_mday;
--
1.8.2-rc0
^ permalink raw reply related
* [PATCH 1/1] Fix time offset calculation in case of unsigned time_t
From: Mike Gorchak @ 2013-02-25 21:53 UTC (permalink / raw)
To: git
Fix time offset calculation expression in case if time_t
is unsigned. This code works fine for signed and
unsigned time_t.
Signed-off-by: Mike Gorchak <mike.gorchak.qnx@gmail.com>
---
date.c | 11 +++++++++--
1 file changed, 9 insertions(+), 2 deletions(-)
diff --git a/date.c b/date.c
index 1ac28e5..11ee7b4 100644
--- a/date.c
+++ b/date.c
@@ -648,6 +648,7 @@ int parse_date_basic(const char *date, unsigned
long *timestamp, int *offset)
struct tm tm;
int tm_gmt;
unsigned long dummy_timestamp;
+ time_t temp_time;
int dummy_offset;
if (!timestamp)
@@ -694,8 +695,14 @@ int parse_date_basic(const char *date, unsigned
long *timestamp, int *offset)
/* mktime uses local timezone */
*timestamp = tm_to_time_t(&tm);
- if (*offset == -1)
- *offset = ((time_t)*timestamp - mktime(&tm)) / 60;
+ if (*offset == -1) {
+ temp_time = mktime(&tm);
+ if ((time_t)*timestamp > temp_time) {
+ *offset = ((time_t)*timestamp - temp_time) / 60;
+ } else {
+ *offset = -(int)((temp_time - (time_t)*timestamp) / 60);
+ }
+ }
if (*timestamp == -1)
return -1;
--
1.8.2-rc0
^ permalink raw reply related
* [PATCH/RFC] dir.c: Make git-status --ignored even more consistent
From: Karsten Blees @ 2013-02-25 22:01 UTC (permalink / raw)
To: Nguyễn Thái Ngọc Duy
Cc: git, Junio C Hamano, kusmabite, Ramkumar Ramachandra, Robert Zeh,
finnag, apelisse, peff
In-Reply-To: <1360999078-27196-1-git-send-email-pclouds@gmail.com>
The new "git-status --ignored" handling introduced with 721ac4ed "dir.c:
Make git-status --ignored more consistent" and a45fb697 "status: always
report ignored tracked directories" still has a few flaws in the
"--untracked-files=normal" case:
- It lists directories that match the exclude pattern, even if they are
tracked, instead of the untracked files and directories that are
_affected_ by the exclude pattern. This is inconsistent with the listing
of untracked files and directories. Additionally, an entire (tracked)
directory may be listed as ignored while contained files are listed as
modified.
- With an untracked directory between the ignored directory and files, the
directory is dropped.
- With a tracked directory between the ignored directory and files, both
the directory and the individual files are listed as ignored.
Change "git-status --ignored --untracked-files=normal" so that it no longer
lists tracked directories. This is already in line with gitignore(5) and
api-directory-listing.txt, so we don't need to update documentation.
In the git-status case, always use is_path_excluded() instead of
is_excluded(). The latter doesn't check if one of the parent directories
is excluded, and we need the full picture when recursing into ignored
directories. As is_path_excluded() is even more complex, only do this for
untracked files and directories. Keep the original is_excluded() check in
the DIR_COLLECT_IGNORED case so that git-add is not affected.
In read_directory_recursive, pass along the check_only parameter when
recursing into sub directories, so that we don't accidentally call
dir_add_name in the check_only case.
Signed-off-by: Karsten Blees <blees@dcon.de>
---
See also: https://github.com/kblees/git/commits/kb/git-status-ignored
Revisiting dir.c, I noticed that the added complexity in .gitignore
processing was just recently introduced by these two changes:
- a45fb697 status: always report ignored tracked directories
- 721ac4ed dir.c: Make git-status --ignored more consistent
Instead of skipping gitignore checks under very special 'safe'
circumstances, this patch focuses on fixing pre-existing bugs
first. The correctness of lazy gitignore checks is then obvious (I
hope) by the very definition of gitignore(5):
"gitignore - Specifies intentionally *untracked* files to ignore"
[emphasis added].
There's still lots of room for improvement, e.g.:
- prevent "git-status --ignored" from scanning everything twice
- integrate struct path_exclude_check into struct dir_struct to
save setup costs of is_path_excluded
Cheers,
Karsten
dir.c | 138 ++++++++++++++++++++-------------------------
t/t7061-wtstatus-ignore.sh | 65 +++++++++++++++++++--
wt-status.c | 2 +-
3 files changed, 123 insertions(+), 82 deletions(-)
diff --git a/dir.c b/dir.c
index 57394e4..1a5440f 100644
--- a/dir.c
+++ b/dir.c
@@ -884,6 +884,17 @@ int is_path_excluded(struct path_exclude_check *check,
return 0;
}
+static int check_path_excluded(struct dir_struct *dir,
+ const char *name, int namelen, int *dtype)
+{
+ struct path_exclude_check check;
+ int excluded;
+ path_exclude_check_init(&check, dir);
+ excluded = is_path_excluded(&check, name, namelen, dtype);
+ path_exclude_check_clear(&check);
+ return excluded;
+}
+
static struct dir_entry *dir_entry_new(const char *pathname, int len)
{
struct dir_entry *ent;
@@ -897,8 +908,7 @@ static struct dir_entry *dir_entry_new(const char *pathname, int len)
static struct dir_entry *dir_add_name(struct dir_struct *dir, const char *pathname, int len)
{
- if (!(dir->flags & DIR_SHOW_IGNORED) &&
- cache_name_exists(pathname, len, ignore_case))
+ if (cache_name_exists(pathname, len, ignore_case))
return NULL;
ALLOC_GROW(dir->entries, dir->nr+1, dir->alloc);
@@ -1000,9 +1010,8 @@ static enum exist_status directory_exists_in_index(const char *dirname, int len)
* traversal routine.
*
* Case 1: If we *already* have entries in the index under that
- * directory name, we recurse into the directory to see all the files,
- * unless the directory is excluded and we want to show ignored
- * directories
+ * directory name, we always recurse into the directory to see
+ * all the files.
*
* Case 2: If we *already* have that directory name as a gitlink,
* we always continue to see it as a gitlink, regardless of whether
@@ -1016,9 +1025,9 @@ static enum exist_status directory_exists_in_index(const char *dirname, int len)
* just a directory, unless "hide_empty_directories" is
* also true and the directory is empty, in which case
* we just ignore it entirely.
- * if we are looking for ignored directories, look if it
- * contains only ignored files to decide if it must be shown as
- * ignored or not.
+ * if we are looking for ignored directories, we also hide
+ * directories with untracked files (i.e. that are already
+ * listed in the untracked section).
* (b) if it looks like a git directory, and we don't have
* 'no_gitlinks' set we treat it as a gitlink, and show it
* as a directory.
@@ -1031,15 +1040,13 @@ enum directory_treatment {
};
static enum directory_treatment treat_directory(struct dir_struct *dir,
- const char *dirname, int len, int exclude,
- const struct path_simplify *simplify)
+ const char *dirname, int len, const struct path_simplify *simplify)
{
+ int dt = DT_DIR, exclude;
+
/* The "len-1" is to strip the final '/' */
switch (directory_exists_in_index(dirname, len-1)) {
case index_directory:
- if ((dir->flags & DIR_SHOW_OTHER_DIRECTORIES) && exclude)
- break;
-
return recurse_into_directory;
case index_gitdir:
@@ -1060,65 +1067,61 @@ static enum directory_treatment treat_directory(struct dir_struct *dir,
/* This is the "show_other_directories" case */
+ exclude = check_path_excluded(dir, dirname, len-1, &dt);
+
/*
* We are looking for ignored files and our directory is not ignored,
* check if it contains only ignored files
*/
if ((dir->flags & DIR_SHOW_IGNORED) && !exclude) {
- int ignored;
- dir->flags &= ~DIR_SHOW_IGNORED;
- dir->flags |= DIR_HIDE_EMPTY_DIRECTORIES;
- ignored = read_directory_recursive(dir, dirname, len, 1, simplify);
- dir->flags &= ~DIR_HIDE_EMPTY_DIRECTORIES;
- dir->flags |= DIR_SHOW_IGNORED;
-
- return ignored ? ignore_directory : show_directory;
+ int untracked;
+ dir->flags &= ~(DIR_SHOW_IGNORED|DIR_SHOW_OTHER_DIRECTORIES);
+ untracked = read_directory_recursive(dir, dirname, len, 1, simplify);
+ dir->flags |= (DIR_SHOW_IGNORED|DIR_SHOW_OTHER_DIRECTORIES);
+
+ /*
+ * Don't list the directory as ignored if it is already listed
+ * as untracked.
+ */
+ if (untracked)
+ return ignore_directory;
}
- if (!(dir->flags & DIR_SHOW_IGNORED) &&
- !(dir->flags & DIR_HIDE_EMPTY_DIRECTORIES))
+
+ if (!(dir->flags & DIR_SHOW_IGNORED) && exclude)
+ return ignore_directory;
+
+ if (!(dir->flags & DIR_HIDE_EMPTY_DIRECTORIES))
return show_directory;
if (!read_directory_recursive(dir, dirname, len, 1, simplify))
return ignore_directory;
return show_directory;
}
+enum path_treatment {
+ path_ignored,
+ path_handled,
+ path_recurse
+};
+
/*
* Decide what to do when we find a file while traversing the
- * filesystem. Mostly two cases:
- *
- * 1. We are looking for ignored files
- * (a) File is ignored, include it
- * (b) File is in ignored path, include it
- * (c) File is not ignored, exclude it
+ * filesystem.
*
- * 2. Other scenarios, include the file if not excluded
+ * Case 1: The file is in the index: always ignore.
*
- * Return 1 for exclude, 0 for include.
+ * Case 2: The file is not in the index: check if the file is excluded.
*/
-static int treat_file(struct dir_struct *dir, struct strbuf *path, int exclude, int *dtype)
+static enum path_treatment treat_file(struct dir_struct *dir,
+ struct strbuf *path, const struct path_simplify *simplify,
+ int *dtype)
{
- struct path_exclude_check check;
- int exclude_file = 0;
-
- if (exclude)
- exclude_file = !(dir->flags & DIR_SHOW_IGNORED);
- else if (dir->flags & DIR_SHOW_IGNORED) {
- /* Always exclude indexed files */
- struct cache_entry *ce = index_name_exists(&the_index,
- path->buf, path->len, ignore_case);
-
- if (ce)
- return 1;
-
- path_exclude_check_init(&check, dir);
-
- if (!is_path_excluded(&check, path->buf, path->len, dtype))
- exclude_file = 1;
-
- path_exclude_check_clear(&check);
- }
+ if (cache_name_exists(path->buf, path->len, ignore_case))
+ return path_ignored;
- return exclude_file;
+ if (check_path_excluded(dir, path->buf, path->len, dtype) !=
+ !!(dir->flags & DIR_SHOW_IGNORED))
+ return path_ignored;
+ return path_handled;
}
/*
@@ -1233,29 +1236,16 @@ static int get_dtype(struct dirent *de, const char *path, int len)
return dtype;
}
-enum path_treatment {
- path_ignored,
- path_handled,
- path_recurse
-};
-
static enum path_treatment treat_one_path(struct dir_struct *dir,
struct strbuf *path,
const struct path_simplify *simplify,
int dtype, struct dirent *de)
{
- int exclude = is_excluded(dir, path->buf, &dtype);
- if (exclude && (dir->flags & DIR_COLLECT_IGNORED)
+ if ((dir->flags & DIR_COLLECT_IGNORED)
+ && is_excluded(dir, path->buf, &dtype)
&& exclude_matches_pathspec(path->buf, path->len, simplify))
dir_add_ignored(dir, path->buf, path->len);
- /*
- * Excluded? If we don't explicitly want to show
- * ignored files, ignore it
- */
- if (exclude && !(dir->flags & DIR_SHOW_IGNORED))
- return path_ignored;
-
if (dtype == DT_UNKNOWN)
dtype = get_dtype(de, path->buf, path->len);
@@ -1265,7 +1255,7 @@ static enum path_treatment treat_one_path(struct dir_struct *dir,
case DT_DIR:
strbuf_addch(path, '/');
- switch (treat_directory(dir, path->buf, path->len, exclude, simplify)) {
+ switch (treat_directory(dir, path->buf, path->len, simplify)) {
case show_directory:
break;
case recurse_into_directory:
@@ -1276,12 +1266,7 @@ static enum path_treatment treat_one_path(struct dir_struct *dir,
break;
case DT_REG:
case DT_LNK:
- switch (treat_file(dir, path, exclude, &dtype)) {
- case 1:
- return path_ignored;
- default:
- break;
- }
+ return treat_file(dir, path, simplify, &dtype);
}
return path_handled;
}
@@ -1334,8 +1319,7 @@ static int read_directory_recursive(struct dir_struct *dir,
switch (treat_path(dir, de, &path, baselen, simplify)) {
case path_recurse:
contents += read_directory_recursive(dir, path.buf,
- path.len, 0,
- simplify);
+ path.len, check_only, simplify);
continue;
case path_ignored:
continue;
diff --git a/t/t7061-wtstatus-ignore.sh b/t/t7061-wtstatus-ignore.sh
index 0da1214..7a73448 100755
--- a/t/t7061-wtstatus-ignore.sh
+++ b/t/t7061-wtstatus-ignore.sh
@@ -96,7 +96,7 @@ cat >expected <<\EOF
?? expected
EOF
-test_expect_success 'status ignored tracked directory with --ignore' '
+test_expect_success 'status tracked directory with --ignore' '
rm -rf untracked-ignored &&
mkdir tracked &&
: >tracked/committed &&
@@ -113,7 +113,7 @@ cat >expected <<\EOF
?? expected
EOF
-test_expect_success 'status ignored tracked directory with --ignore -u' '
+test_expect_success 'status tracked directory with --ignore -u' '
git status --porcelain --ignored -u >actual &&
test_cmp expected actual
'
@@ -122,10 +122,10 @@ cat >expected <<\EOF
?? .gitignore
?? actual
?? expected
-!! tracked/
+!! tracked/uncommitted
EOF
-test_expect_success 'status ignored tracked directory and uncommitted file with --ignore' '
+test_expect_success 'status tracked directory and uncommitted file with --ignore' '
: >tracked/uncommitted &&
git status --porcelain --ignored >actual &&
test_cmp expected actual
@@ -138,6 +138,63 @@ cat >expected <<\EOF
!! tracked/uncommitted
EOF
+test_expect_success 'status tracked directory and uncommitted file with --ignore -u' '
+ git status --porcelain --ignored -u >actual &&
+ test_cmp expected actual
+'
+
+cat >expected <<\EOF
+?? .gitignore
+?? actual
+?? expected
+!! tracked/untracked/
+EOF
+
+test_expect_success 'status ignored untracked directory and uncommitted file with --ignore' '
+ rm -rf tracked/uncommitted &&
+ mkdir tracked/untracked &&
+ : >tracked/untracked/uncommitted &&
+ git status --porcelain --ignored >actual &&
+ test_cmp expected actual
+'
+
+cat >expected <<\EOF
+?? .gitignore
+?? actual
+?? expected
+!! tracked/untracked/uncommitted
+EOF
+
+test_expect_success 'status ignored untracked directory and uncommitted file with --ignore -u' '
+ git status --porcelain --ignored -u >actual &&
+ test_cmp expected actual
+'
+
+cat >expected <<\EOF
+?? .gitignore
+?? actual
+?? expected
+!! tracked/tracked/uncommitted
+EOF
+
+test_expect_success 'status ignored tracked directory and uncommitted file with --ignore' '
+ rm -rf tracked/untracked &&
+ mkdir tracked/tracked &&
+ : >tracked/tracked/committed &&
+ : >tracked/tracked/uncommitted &&
+ git add -f tracked/tracked/committed &&
+ git commit -m. &&
+ git status --porcelain --ignored >actual &&
+ test_cmp expected actual
+'
+
+cat >expected <<\EOF
+?? .gitignore
+?? actual
+?? expected
+!! tracked/tracked/uncommitted
+EOF
+
test_expect_success 'status ignored tracked directory and uncommitted file with --ignore -u' '
git status --porcelain --ignored -u >actual &&
test_cmp expected actual
diff --git a/wt-status.c b/wt-status.c
index ef405d0..79eb124 100644
--- a/wt-status.c
+++ b/wt-status.c
@@ -518,7 +518,7 @@ static void wt_status_collect_untracked(struct wt_status *s)
dir.nr = 0;
dir.flags = DIR_SHOW_IGNORED;
if (s->show_untracked_files != SHOW_ALL_UNTRACKED_FILES)
- dir.flags |= DIR_SHOW_OTHER_DIRECTORIES;
+ dir.flags |= DIR_SHOW_OTHER_DIRECTORIES | DIR_HIDE_EMPTY_DIRECTORIES;
fill_directory(&dir, s->pathspec);
for (i = 0; i < dir.nr; i++) {
struct dir_entry *ent = dir.entries[i];
--
1.8.1.2.7988.ge3e3ca2
^ permalink raw reply related
* Re: [PATCH 1/1] Fix date checking in case if time was not initialized.
From: Junio C Hamano @ 2013-02-25 22:07 UTC (permalink / raw)
To: git
In-Reply-To: <CAHXAxrO4c=s0pjNpXK171HUbQT06jm-VAxNNK1DAqZEZfz6OtA@mail.gmail.com>
Mike Gorchak <mike.gorchak.qnx@gmail.com> writes:
>>> So is_date() always return negative result for the text string where
>>> date is placed before time like '2008-02-14 20:30:45'.
>> Yes, it returns this -1 on other platforms, but...
>>> It must fail on
>>> other platforms as well.
>
> It also fails under Linux, but real problem is not here, it is just an
> unoptimal date parser.
The test does _not_ fail. That if condition does return -1 on Linux
and BSD, and making tm_to_time_t() return a failure, but the caller
goes on, ending up with the right values in year/month/date in the
tm struct, which is the primary thing the function is used for.
As you said, what is_date() wants to see is if the caller guessed
the order of three combinations of year/month/date correctly, it
cannot necessarily assume the caller already has seen the
hour/minutes/seconds yet, so _temporarily_ feeding a valud set of
values to hour/minutes/seconds when calling tm_to_time_t() is a good
workaround. So the change in your patch sounds correct and use of a
temporary tm to avoid contaminating the hour/minutes/seconds passed
to the is_date() function while doing so looks good.
>> ... the input '2008-02-14 20:30:45' still parses fine for others
>> (including me). That is what is puzzling.
>
>> A shot in the dark: perhaps your time_t is unsigned?
>
> Yeah, it was a headshot :) It really due to unsigned time_t. I will
> send two patches right now with fixes regarding unsigned time_t
> comparison.
If your time_t is unsigned, the error returned from tm_to_time_t()
will appear to be a time in a distant future, which will prevent
is_date() to return "Yeah, you guessed the order of year, month, and
date correctly" to its caller. The code would need to pick a safer
mechanism to signal a failure from tm_to_time_t() to its callers.
^ permalink raw reply
* Re: [PATCH 1/1] Fix unsigned time_t comparison
From: Junio C Hamano @ 2013-02-25 22:10 UTC (permalink / raw)
To: Mike Gorchak; +Cc: git
In-Reply-To: <CAHXAxrMZODO07_dPep-yKgrzD1228iSMGUXX06xkKDmoZF4+qA@mail.gmail.com>
Mike Gorchak <mike.gorchak.qnx@gmail.com> writes:
> Do not compare time_t (less comparison) with -1. If time_t
> is unsigned this leads to always true comparison.
>
> Signed-off-by: Mike Gorchak <mike.gorchak.qnx@gmail.com>
> ---
> date.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/date.c b/date.c
> index 57331ed..1ac28e5 100644
> --- a/date.c
> +++ b/date.c
> @@ -383,7 +383,7 @@ static int is_date(int year, int month, int day,
> struct tm *now_tm, time_t now,
> * sense to specify timestamp way into the future. Make
> * sure it is not later than ten days from now...
> */
> - if (now + 10*24*3600 < specified)
> + if ((specified != -1) && (now + 10*24*3600 < specified))
> return 0;
> tm->tm_mon = r->tm_mon;
> tm->tm_mday = r->tm_mday;
This is good enough band-aid for now (as it won't change the
semantics for anybody), but I suspect in the longer term we would
want to pick a different mechanims to signal errors, so that we can
specify timestamp that is before 1970.
Thanks, will queue.
^ permalink raw reply
* Re: [PATCH 1/1] Fix unsigned time_t comparison
From: Junio C Hamano @ 2013-02-25 22:27 UTC (permalink / raw)
To: Mike Gorchak; +Cc: git
In-Reply-To: <CAHXAxrMZODO07_dPep-yKgrzD1228iSMGUXX06xkKDmoZF4+qA@mail.gmail.com>
Mike Gorchak <mike.gorchak.qnx@gmail.com> writes:
> Do not compare time_t (less comparison) with -1. If time_t
> is unsigned this leads to always true comparison.
>
> Signed-off-by: Mike Gorchak <mike.gorchak.qnx@gmail.com>
> ---
> date.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/date.c b/date.c
> index 57331ed..1ac28e5 100644
> --- a/date.c
> +++ b/date.c
> @@ -383,7 +383,7 @@ static int is_date(int year, int month, int day,
> struct tm *now_tm, time_t now,
Line-wrapped. Will manually fix while applying.
Thanks.
> * sense to specify timestamp way into the future. Make
> * sure it is not later than ten days from now...
> */
> - if (now + 10*24*3600 < specified)
> + if ((specified != -1) && (now + 10*24*3600 < specified))
> return 0;
> tm->tm_mon = r->tm_mon;
> tm->tm_mday = r->tm_mday;
^ permalink raw reply
* Re: [PATCH] diff: Fix rename pretty-print when suffix and prefix overlap
From: Philip Oakley @ 2013-02-25 22:36 UTC (permalink / raw)
To: Antoine Pelisse; +Cc: Junio C Hamano, git
In-Reply-To: <CALWbr2yviqF68zF7mBbhaXW7oFar0YRqROBWXwqjo7UNgZNVBQ@mail.gmail.com>
On 25/02/13 19:50, Antoine Pelisse wrote:
> On Sun, Feb 24, 2013 at 10:15 AM, Junio C Hamano <gitster@pobox.com> wrote:
>> Antoine Pelisse <apelisse@gmail.com> writes:
>>
>>> When considering a rename for two files that have a suffix and a prefix
>>> that can overlap, a confusing line is shown. As an example, renaming
>>> "a/b/b/c" to "a/b/c" shows "a/b/{ => }/b/c".
>>
>> This would be vastly more readable if it had "It should show XXX
>> instead" somewhere in the description, perhaps at the end of this
>> sentence. It can also be after "thus the { => }" below, but I think
>> giving the expected output earlier would be more appropriate.
>
> Good catch, this would probably be better:
>
> When considering a rename for two files that have a suffix and a prefix
> that can overlap, a confusing line is shown. As an example, renaming
> "a/b/b/c" to "a/b/c" shows "a/b/{ => }/b/c", instead of "a/b/{ => b}/c"
>
>>> Currently, what we do is calculate the common prefix ("a/b/"), and the
>>> common suffix ("/b/c"), but the same "/b/" is actually counted both in
>>> prefix and suffix. Then when calculating the size of the non-common part,
>>> we end-up with a negative value which is reset to 0, thus the "{ => }".
>>
>> In this example, the common prefix would be "a/b/" and the common
>> suffix that does not overlap with the prefix part would be "/c", so
>> I am imagining that "a/b/{ => b}/c" would be the desired output?
>
> Yes, at least that's what I expected.
Surely it would be "a/b/{b => }/c", that is, we have reduced the number
of b's by one. Or am I misunderstanding something?
(I'm guessing it was an all too obvious typo that was misread)
>
>> This is a really old thinko (dating back to June 2005). I'll queue
>> the patch on maint-1.7.6 (because 1.7.6.6 is slightly more than one
>> year old while 1.7.5.4 is a lot older) to allow distros that issue
>> incremental fixes on top of ancient versions of Git to pick up the
>> fix if they wanted to. Perhaps we would want to add a few tests?
>
> I can easily understand why that was missed.
> I will try to resubmit with tests very soon.
Philip
^ permalink raw reply
* Re: [PATCH] diff: Fix rename pretty-print when suffix and prefix overlap
From: Antoine Pelisse @ 2013-02-25 22:41 UTC (permalink / raw)
To: Philip Oakley; +Cc: Junio C Hamano, git
In-Reply-To: <512BE787.1090901@iee.org>
>>> In this example, the common prefix would be "a/b/" and the common
>>> suffix that does not overlap with the prefix part would be "/c", so
>>> I am imagining that "a/b/{ => b}/c" would be the desired output?
>>
>>
>> Yes, at least that's what I expected.
>
>
> Surely it would be "a/b/{b => }/c", that is, we have reduced the number of
> b's by one. Or am I misunderstanding something?
> (I'm guessing it was an all too obvious typo that was misread)
Indeed, read to fast and reproduced in suggested new message.
a/b/b/c => a/b/c is equivalent to a/b/{b => }/c
Thank you for proof-reading.
^ permalink raw reply
* [PATCH v5] user-manual: Standardize backtick quoting
From: W. Trevor King @ 2013-02-25 22:53 UTC (permalink / raw)
To: Git; +Cc: Junio C Hamano, Jonathan Nieder, Drew Northup, W. Trevor King
In-Reply-To: <4f89fdc5b3c11868614ce5ac9f8aa0fbd9c00ba4.1361146398.git.wking@tremily.us>
From: "W. Trevor King" <wking@tremily.us>
I tried to always use backticks for:
* Paths and filenames (e.g. `.git/config`)
* Compound refs (e.g. `origin/HEAD`)
* Git commands (e.g. `git log`)
* Command arguments (e.g. `--pretty`)
* URLs (e.g. `git://`), as a subset of command arguments
* Special characters (e.g. `+` in diffs).
* Config options (e.g. `branch.<name>.remote`)
Branch and tag names are sometimes set off with double quotes,
sometimes set off with backticks, and sometimes left bare. I tried to
judge when the intention was introducing new terms or conventions
(double quotes), to reference a recently used command argument
(backticks), or to reference the abstract branch/commit (left bare).
Obviously these are not particularly crisp definitions, so my
decisions are fairly arbitrary ;). When a reference had already been
introduced, I changed further double-quoted instances to backticked
instances.
When new backticks increased the length of a line beyond others in
that block, I re-wrapped blocks to 72 columns.
Signed-off-by: W. Trevor King <wking@tremily.us>
---
This patch was not present in v4. Changes from v3:
* Rebased onto v1.8.2-rc1, after both my earlier cleanups and the
git/Git/GIT standardization from 2de9b71 (Documentation: the name of
the system is 'Git', not 'git', 2013-01-21).
It's probably easier to review this if you just apply the patch and
then go back through with --word-diff ;).
Documentation/user-manual.txt | 286 +++++++++++++++++++++---------------------
1 file changed, 144 insertions(+), 142 deletions(-)
diff --git a/Documentation/user-manual.txt b/Documentation/user-manual.txt
index 5f36f81..0170a23 100644
--- a/Documentation/user-manual.txt
+++ b/Documentation/user-manual.txt
@@ -19,7 +19,7 @@ Further chapters cover more specialized topics.
Comprehensive reference documentation is available through the man
pages, or linkgit:git-help[1] command. For example, for the command
-"git clone <repo>", you can either use:
+`git clone <repo>`, you can either use:
------------------------------------------------
$ man git-clone
@@ -66,11 +66,11 @@ $ git clone git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git
The initial clone may be time-consuming for a large project, but you
will only need to clone once.
-The clone command creates a new directory named after the project ("git"
-or "linux-2.6" in the examples above). After you cd into this
+The clone command creates a new directory named after the project (`git`
+or `linux-2.6` in the examples above). After you cd into this
directory, you will see that it contains a copy of the project files,
called the <<def_working_tree,working tree>>, together with a special
-top-level directory named ".git", which contains all the information
+top-level directory named `.git`, which contains all the information
about the history of the project.
[[how-to-check-out]]
@@ -188,7 +188,7 @@ As you can see, a commit shows who made the latest change, what they
did, and why.
Every commit has a 40-hexdigit id, sometimes called the "object name" or the
-"SHA-1 id", shown on the first line of the "git show" output. You can usually
+"SHA-1 id", shown on the first line of the `git show` output. You can usually
refer to a commit by a shorter name, such as a tag or a branch name, but this
longer name can also be useful. Most importantly, it is a globally unique
name for this commit: so if you tell somebody else the object name (for
@@ -268,35 +268,35 @@ Manipulating branches
Creating, deleting, and modifying branches is quick and easy; here's
a summary of the commands:
-git branch::
+`git branch`::
list all branches
-git branch <branch>::
- create a new branch named <branch>, referencing the same
+`git branch <branch>`::
+ create a new branch named `<branch>`, referencing the same
point in history as the current branch
-git branch <branch> <start-point>::
- create a new branch named <branch>, referencing
- <start-point>, which may be specified any way you like,
+`git branch <branch> <start-point>`::
+ create a new branch named `<branch>`, referencing
+ `<start-point>`, which may be specified any way you like,
including using a branch name or a tag name
-git branch -d <branch>::
- delete the branch <branch>; if the branch you are deleting
+`git branch -d <branch>`::
+ delete the branch `<branch>`; if the branch you are deleting
points to a commit which is not reachable from the current
branch, this command will fail with a warning.
-git branch -D <branch>::
+`git branch -D <branch>`::
even if the branch points to a commit not reachable
from the current branch, you may know that that commit
is still reachable from some other branch or tag. In that
case it is safe to use this command to force Git to delete
the branch.
-git checkout <branch>::
- make the current branch <branch>, updating the working
- directory to reflect the version referenced by <branch>
-git checkout -b <new> <start-point>::
- create a new branch <new> referencing <start-point>, and
+`git checkout <branch>`::
+ make the current branch `<branch>`, updating the working
+ directory to reflect the version referenced by `<branch>`
+`git checkout -b <new> <start-point>`::
+ create a new branch `<new>` referencing `<start-point>`, and
check it out.
The special symbol "HEAD" can always be used to refer to the current
-branch. In fact, Git uses a file named "HEAD" in the .git directory to
-remember which branch is current:
+branch. In fact, Git uses a file named `HEAD` in the `.git` directory
+to remember which branch is current:
------------------------------------------------
$ cat .git/HEAD
@@ -346,7 +346,7 @@ of the HEAD in the repository that you cloned from. That repository
may also have had other branches, though, and your local repository
keeps branches which track each of those remote branches, called
remote-tracking branches, which you
-can view using the "-r" option to linkgit:git-branch[1]:
+can view using the `-r` option to linkgit:git-branch[1]:
------------------------------------------------
$ git branch -r
@@ -364,7 +364,7 @@ In this example, "origin" is called a remote repository, or "remote"
for short. The branches of this repository are called "remote
branches" from our point of view. The remote-tracking branches listed
above were created based on the remote branches at clone time and will
-be updated by "git fetch" (hence "git pull") and "git push". See
+be updated by `git fetch` (hence `git pull`) and `git push`. See
<<Updating-a-repository-With-git-fetch>> for details.
You might want to build on one of these remote-tracking branches
@@ -374,7 +374,7 @@ on a branch of your own, just as you would for a tag:
$ git checkout -b my-todo-copy origin/todo
------------------------------------------------
-You can also check out "origin/todo" directly to examine it or
+You can also check out `origin/todo` directly to examine it or
write a one-off patch. See <<detached-head,detached head>>.
Note that the name "origin" is just the name that Git uses by default
@@ -386,17 +386,17 @@ Naming branches, tags, and other references
Branches, remote-tracking branches, and tags are all references to
commits. All references are named with a slash-separated path name
-starting with "refs"; the names we've been using so far are actually
+starting with `refs`; the names we've been using so far are actually
shorthand:
- - The branch "test" is short for "refs/heads/test".
- - The tag "v2.6.18" is short for "refs/tags/v2.6.18".
- - "origin/master" is short for "refs/remotes/origin/master".
+ - The branch `test` is short for `refs/heads/test`.
+ - The tag `v2.6.18` is short for `refs/tags/v2.6.18`.
+ - `origin/master` is short for `refs/remotes/origin/master`.
The full name is occasionally useful if, for example, there ever
exists a tag and a branch with the same name.
-(Newly created refs are actually stored in the .git/refs directory,
+(Newly created refs are actually stored in the `.git/refs` directory,
under the path given by their name. However, for efficiency reasons
they may also be packed together in a single file; see
linkgit:git-pack-refs[1]).
@@ -418,7 +418,7 @@ Eventually the developer cloned from will do additional work in her
repository, creating new commits and advancing the branches to point
at the new commits.
-The command "git fetch", with no arguments, will update all of the
+The command `git fetch`, with no arguments, will update all of the
remote-tracking branches to the latest version found in her
repository. It will not touch any of your own branches--not even the
"master" branch that was created for you on clone.
@@ -438,7 +438,7 @@ $ git fetch linux-nfs
-------------------------------------------------
New remote-tracking branches will be stored under the shorthand name
-that you gave "git remote add", in this case linux-nfs:
+that you gave `git remote add`, in this case `linux-nfs`:
-------------------------------------------------
$ git branch -r
@@ -446,10 +446,10 @@ linux-nfs/master
origin/master
-------------------------------------------------
-If you run "git fetch <remote>" later, the remote-tracking branches for the
-named <remote> will be updated.
+If you run `git fetch <remote>` later, the remote-tracking branches
+for the named `<remote>` will be updated.
-If you examine the file .git/config, you will see that Git has added
+If you examine the file `.git/config`, you will see that Git has added
a new stanza:
-------------------------------------------------
@@ -462,7 +462,7 @@ $ cat .git/config
-------------------------------------------------
This is what causes Git to track the remote's branches; you may modify
-or delete these configuration options by editing .git/config with a
+or delete these configuration options by editing `.git/config` with a
text editor. (See the "CONFIGURATION FILE" section of
linkgit:git-config[1] for details.)
@@ -499,7 +499,7 @@ Bisecting: 3537 revisions left to test after this
[65934a9a028b88e83e2b0f8b36618fe503349f8e] BLOCK: Make USB storage depend on SCSI rather than selecting it [try #6]
-------------------------------------------------
-If you run "git branch" at this point, you'll see that Git has
+If you run `git branch` at this point, you'll see that Git has
temporarily moved you in "(no branch)". HEAD is now detached from any
branch and points directly to a commit (with commit id 65934...) that
is reachable from "master" but not from v2.6.18. Compile and test it,
@@ -545,11 +545,11 @@ id, and check it out with:
$ git reset --hard fb47ddb2db...
-------------------------------------------------
-then test, run "bisect good" or "bisect bad" as appropriate, and
+then test, run `bisect good` or `bisect bad` as appropriate, and
continue.
-Instead of "git bisect visualize" and then "git reset --hard
-fb47ddb2db...", you might just want to tell Git that you want to skip
+Instead of `git bisect visualize` and then `git reset --hard
+fb47ddb2db...`, you might just want to tell Git that you want to skip
the current commit:
-------------------------------------------------
@@ -561,8 +561,8 @@ bad one between some first skipped commits and a later bad commit.
There are also ways to automate the bisecting process if you have a
test script that can tell a good from a bad commit. See
-linkgit:git-bisect[1] for more information about this and other "git
-bisect" features.
+linkgit:git-bisect[1] for more information about this and other `git
+bisect` features.
[[naming-commits]]
Naming commits
@@ -591,7 +591,7 @@ $ git show HEAD~4 # the great-great-grandparent
-------------------------------------------------
Recall that merge commits may have more than one parent; by default,
-^ and ~ follow the first parent listed in the commit, but you can
+`^` and `~` follow the first parent listed in the commit, but you can
also choose:
-------------------------------------------------
@@ -640,7 +640,7 @@ running
$ git tag stable-1 1b2e1d63ff
-------------------------------------------------
-You can use stable-1 to refer to the commit 1b2e1d63ff.
+You can use `stable-1` to refer to the commit 1b2e1d63ff.
This creates a "lightweight" tag. If you would also like to include a
comment with the tag, and possibly sign it cryptographically, then you
@@ -669,7 +669,7 @@ $ git log -S'foo()' # commits which add or remove any file data
-------------------------------------------------
And of course you can combine all of these; the following finds
-commits since v2.5 which touch the Makefile or any file under fs:
+commits since v2.5 which touch the `Makefile` or any file under `fs`:
-------------------------------------------------
$ git log v2.5.. Makefile fs/
@@ -681,7 +681,7 @@ You can also ask git log to show patches:
$ git log -p
-------------------------------------------------
-See the "--pretty" option in the linkgit:git-log[1] man page for more
+See the `--pretty` option in the linkgit:git-log[1] man page for more
display options.
Note that git log starts with the most recent commit and works
@@ -742,8 +742,8 @@ Examples
Counting the number of commits on a branch
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-Suppose you want to know how many commits you've made on "mybranch"
-since it diverged from "origin":
+Suppose you want to know how many commits you've made on `mybranch`
+since it diverged from `origin`:
-------------------------------------------------
$ git log --pretty=oneline origin..mybranch | wc -l
@@ -780,7 +780,7 @@ $ git rev-list master
e05db0fd4f31dde7005f075a84f96b360d05984b
-------------------------------------------------
-Or you could recall that the ... operator selects all commits
+Or you could recall that the `...` operator selects all commits
contained reachable from either one reference or the other but not
both; so
@@ -880,7 +880,7 @@ Showing commits unique to a given branch
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Suppose you would like to see all the commits reachable from the branch
-head named "master" but not from any other head in your repository.
+head named `master` but not from any other head in your repository.
We can list all the heads in this repository with
linkgit:git-show-ref[1]:
@@ -894,7 +894,7 @@ a07157ac624b2524a059a3414e99f6f44bebc1e7 refs/heads/master
1e87486ae06626c2f31eaa63d26fc0fd646c8af2 refs/heads/tutorial-fixes
-------------------------------------------------
-We can get just the branch-head names, and remove "master", with
+We can get just the branch-head names, and remove `master`, with
the help of the standard utilities cut and grep:
-------------------------------------------------
@@ -939,7 +939,7 @@ is preceded by `project/`. The output file format is inferred from
the output file extension if possible, see linkgit:git-archive[1] for
details.
-Versions of Git older than 1.7.7 don't know about the 'tar.gz' format,
+Versions of Git older than 1.7.7 don't know about the `tar.gz` format,
you'll need to use gzip explicitly:
-------------------------------------------------
@@ -1062,7 +1062,7 @@ at step 3, Git maintains a snapshot of the tree's contents in a
special staging area called "the index."
At the beginning, the content of the index will be identical to
-that of the HEAD. The command "git diff --cached", which shows
+that of the HEAD. The command `git diff --cached`, which shows
the difference between the HEAD and the index, should therefore
produce no output at that point.
@@ -1101,7 +1101,7 @@ $ git diff
shows the difference between the working tree and the index file.
-Note that "git add" always adds just the current contents of a file
+Note that `git add` always adds just the current contents of a file
to the index; further changes to the same file will be ignored unless
you run `git add` on the file again.
@@ -1172,8 +1172,9 @@ annoying to have these untracked files lying around; e.g. they make
`git add .` practically useless, and they keep showing up in the output of
`git status`.
-You can tell Git to ignore certain files by creating a file called .gitignore
-in the top level of your working directory, with contents such as:
+You can tell Git to ignore certain files by creating a file called
+`.gitignore` in the top level of your working directory, with contents
+such as:
-------------------------------------------------
# Lines starting with '#' are considered comments.
@@ -1197,10 +1198,10 @@ for other users who clone your repository.
If you wish the exclude patterns to affect only certain repositories
(instead of every repository for a given project), you may instead put
-them in a file in your repository named .git/info/exclude, or in any file
-specified by the `core.excludesfile` configuration variable. Some Git
-commands can also take exclude patterns directly on the command line.
-See linkgit:gitignore[5] for the details.
+them in a file in your repository named `.git/info/exclude`, or in any
+file specified by the `core.excludesfile` configuration variable.
+Some Git commands can also take exclude patterns directly on the
+command line. See linkgit:gitignore[5] for the details.
[[how-to-merge]]
How to merge
@@ -1213,10 +1214,10 @@ linkgit:git-merge[1]:
$ git merge branchname
-------------------------------------------------
-merges the development in the branch "branchname" into the current
+merges the development in the branch `branchname` into the current
branch.
-A merge is made by combining the changes made in "branchname" and the
+A merge is made by combining the changes made in `branchname` and the
changes made up to the latest commit in your current branch since
their histories forked. The work tree is overwritten by the result of
the merge when this combining is done cleanly, or overwritten by a
@@ -1338,7 +1339,7 @@ that part is not conflicting and is not shown. Same for stage 3).
The diff above shows the differences between the working-tree version of
file.txt and the stage 2 and stage 3 versions. So instead of preceding
-each line by a single "+" or "-", it now uses two columns: the first
+each line by a single `+` or `-`, it now uses two columns: the first
column is used for differences between the first parent and the working
directory copy, and the second for differences between the second parent
and the working directory copy. (See the "COMBINED DIFF FORMAT" section
@@ -1613,7 +1614,7 @@ dangling tree b24c2473f1fd3d91352a624795be026d64c8841f
You will see informational messages on dangling objects. They are objects
that still exist in the repository but are no longer referenced by any of
-your branches, and can (and will) be removed after a while with "gc".
+your branches, and can (and will) be removed after a while with `gc`.
You can run `git fsck --no-dangling` to suppress these messages, and still
view real errors.
@@ -1625,9 +1626,9 @@ Recovering lost changes
Reflogs
^^^^^^^
-Say you modify a branch with +linkgit:git-reset[1] \--hard+, and then
-realize that the branch was the only reference you had to that point in
-history.
+Say you modify a branch with <<fixing-mistakes,`git reset --hard`>>,
+and then realize that the branch was the only reference you had to
+that point in history.
Fortunately, Git also keeps a log, called a "reflog", of all the
previous values of each branch. So in this case you can still find the
@@ -1638,8 +1639,8 @@ $ git log master@{1}
-------------------------------------------------
This lists the commits reachable from the previous version of the
-"master" branch head. This syntax can be used with any Git command
-that accepts a commit, not just with git log. Some other examples:
+`master` branch head. This syntax can be used with any Git command
+that accepts a commit, not just with `git log`. Some other examples:
-------------------------------------------------
$ git show master@{2} # See where the branch pointed 2,
@@ -1743,8 +1744,8 @@ one step:
$ git pull origin master
-------------------------------------------------
-In fact, if you have "master" checked out, then this branch has been
-configured by "git clone" to get changes from the HEAD branch of the
+In fact, if you have `master` checked out, then this branch has been
+configured by `git clone` to get changes from the HEAD branch of the
origin repository. So often you can
accomplish the above with just a simple
@@ -1759,11 +1760,11 @@ the current branch.
More generally, a branch that is created from a remote-tracking branch
will pull
by default from that branch. See the descriptions of the
-branch.<name>.remote and branch.<name>.merge options in
+`branch.<name>.remote` and `branch.<name>.merge` options in
linkgit:git-config[1], and the discussion of the `--track` option in
linkgit:git-checkout[1], to learn how to control these defaults.
-In addition to saving you keystrokes, "git pull" also helps you by
+In addition to saving you keystrokes, `git pull` also helps you by
producing a default commit message documenting the branch and
repository that you pulled from.
@@ -1771,7 +1772,7 @@ repository that you pulled from.
<<fast-forwards,fast-forward>>; instead, your branch will just be
updated to point to the latest commit from the upstream branch.)
-The `git pull` command can also be given "." as the "remote" repository,
+The `git pull` command can also be given `.` as the "remote" repository,
in which case it just merges in a branch from the current repository; so
the commands
@@ -1796,7 +1797,7 @@ $ git format-patch origin
-------------------------------------------------
will produce a numbered series of files in the current directory, one
-for each patch in the current branch but not in origin/HEAD.
+for each patch in the current branch but not in `origin/HEAD`.
`git format-patch` can include an initial "cover letter". You can insert
commentary on individual patches after the three dash line which
@@ -1818,7 +1819,7 @@ Importing patches to a project
Git also provides a tool called linkgit:git-am[1] (am stands for
"apply mailbox"), for importing such an emailed series of patches.
Just save all of the patch-containing messages, in order, into a
-single mailbox file, say "patches.mbox", then run
+single mailbox file, say `patches.mbox`, then run
-------------------------------------------------
$ git am -3 patches.mbox
@@ -1826,7 +1827,7 @@ $ git am -3 patches.mbox
Git will apply each patch in order; if any conflicts are found, it
will stop, and you can fix the conflicts as described in
-"<<resolving-a-merge,Resolving a merge>>". (The "-3" option tells
+"<<resolving-a-merge,Resolving a merge>>". (The `-3` option tells
Git to perform a merge; if you would prefer it just to abort and
leave your tree and index untouched, you may omit that option.)
@@ -1902,7 +1903,7 @@ We explain how to do this in the following sections.
Setting up a public repository
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-Assume your personal repository is in the directory ~/proj. We
+Assume your personal repository is in the directory `~/proj`. We
first create a new clone of the repository and tell `git daemon` that it
is meant to be public:
@@ -1912,10 +1913,10 @@ $ touch proj.git/git-daemon-export-ok
-------------------------------------------------
The resulting directory proj.git contains a "bare" git repository--it is
-just the contents of the ".git" directory, without any files checked out
+just the contents of the `.git` directory, without any files checked out
around it.
-Next, copy proj.git to the server where you plan to host the
+Next, copy `proj.git` to the server where you plan to host the
public repository. You can use scp, rsync, or whatever is most
convenient.
@@ -1926,8 +1927,8 @@ Exporting a Git repository via the Git protocol
This is the preferred method.
If someone else administers the server, they should tell you what
-directory to put the repository in, and what git:// URL it will appear
-at. You can then skip to the section
+directory to put the repository in, and what `git://` URL it will
+appear at. You can then skip to the section
"<<pushing-changes-to-a-public-repository,Pushing changes to a public
repository>>", below.
@@ -1962,7 +1963,7 @@ $ mv hooks/post-update.sample hooks/post-update
(For an explanation of the last two lines, see
linkgit:git-update-server-info[1] and linkgit:githooks[5].)
-Advertise the URL of proj.git. Anybody else should then be able to
+Advertise the URL of `proj.git`. Anybody else should then be able to
clone or pull from that URL, for example with a command line like:
-------------------------------------------------
@@ -1985,8 +1986,8 @@ access, which you will need to update the public repository with the
latest changes created in your private repository.
The simplest way to do this is using linkgit:git-push[1] and ssh; to
-update the remote branch named "master" with the latest state of your
-branch named "master", run
+update the remote branch named `master` with the latest state of your
+branch named `master`, run
-------------------------------------------------
$ git push ssh://yourserver.com/~you/proj.git master:master
@@ -2002,7 +2003,7 @@ As with `git fetch`, `git push` will complain if this does not result in a
<<fast-forwards,fast-forward>>; see the following section for details on
handling this case.
-Note that the target of a "push" is normally a
+Note that the target of a `push` is normally a
<<def_bare_repository,bare>> repository. You can also push to a
repository that has a checked-out working tree, but a push to update the
currently checked-out branch is denied by default to prevent confusion.
@@ -2030,9 +2031,9 @@ which lets you do the same push with just
$ git push public-repo master
-------------------------------------------------
-See the explanations of the remote.<name>.url, branch.<name>.remote,
-and remote.<name>.push options in linkgit:git-config[1] for
-details.
+See the explanations of the `remote.<name>.url`,
+`branch.<name>.remote`, and `remote.<name>.push` options in
+linkgit:git-config[1] for details.
[[forcing-push]]
What to do when a push fails
@@ -2167,7 +2168,7 @@ linkgit:git-fetch[1] to keep them up-to-date; see
Now create the branches in which you are going to work; these start out
at the current tip of origin/master branch, and should be set up (using
-the --track option to linkgit:git-branch[1]) to merge changes in from
+the `--track` option to linkgit:git-branch[1]) to merge changes in from
Linus by default.
-------------------------------------------------
@@ -2186,7 +2187,7 @@ Important note! If you have any local changes in these branches, then
this merge will create a commit object in the history (with no local
changes Git will simply do a "fast-forward" merge). Many people dislike
the "noise" that this creates in the Linux history, so you should avoid
-doing this capriciously in the "release" branch, as these noisy commits
+doing this capriciously in the `release` branch, as these noisy commits
will become part of the permanent history when you ask Linus to pull
from the release branch.
@@ -2228,7 +2229,7 @@ patches), and create a new branch from a recent stable tag of
Linus's branch. Picking a stable base for your branch will:
1) help you: by avoiding inclusion of unrelated and perhaps lightly
tested changes
-2) help future bug hunters that use "git bisect" to find problems
+2) help future bug hunters that use `git bisect` to find problems
-------------------------------------------------
$ git checkout -b speed-up-spinlocks v2.6.35
@@ -2253,9 +2254,9 @@ It is unlikely that you would have any conflicts here ... but you might if you
spent a while on this step and had also pulled new versions from upstream.
Some time later when enough time has passed and testing done, you can pull the
-same branch into the "release" tree ready to go upstream. This is where you
+same branch into the `release` tree ready to go upstream. This is where you
see the value of keeping each patch (or patch series) in its own branch. It
-means that the patches can be moved into the "release" tree in any order.
+means that the patches can be moved into the `release` tree in any order.
-------------------------------------------------
$ git checkout release && git pull . speed-up-spinlocks
@@ -2288,7 +2289,7 @@ If it has been merged, then there will be no output.)
Once a patch completes the great cycle (moving from test to release,
then pulled by Linus, and finally coming back into your local
-"origin/master" branch), the branch for this change is no longer needed.
+`origin/master` branch), the branch for this change is no longer needed.
You detect this when the output from:
-------------------------------------------------
@@ -2303,8 +2304,8 @@ $ git branch -d branchname
Some changes are so trivial that it is not necessary to create a separate
branch and then merge into each of the test and release branches. For
-these changes, just apply directly to the "release" branch, and then
-merge that into the "test" branch.
+these changes, just apply directly to the `release` branch, and then
+merge that into the `test` branch.
After pushing your work to `mytree`, you can use
linkgit:git-request-pull[1] to prepare a "please pull" request message
@@ -2475,8 +2476,8 @@ you are rewriting history.
Keeping a patch series up to date using git rebase
--------------------------------------------------
-Suppose that you create a branch "mywork" on a remote-tracking branch
-"origin", and create some commits on top of it:
+Suppose that you create a branch `mywork` on a remote-tracking branch
+`origin`, and create some commits on top of it:
-------------------------------------------------
$ git checkout -b mywork origin
@@ -2488,7 +2489,7 @@ $ git commit
-------------------------------------------------
You have performed no merges into mywork, so it is just a simple linear
-sequence of patches on top of "origin":
+sequence of patches on top of `origin`:
................................................
o--o--O <-- origin
@@ -2497,7 +2498,7 @@ sequence of patches on top of "origin":
................................................
Some more interesting work has been done in the upstream project, and
-"origin" has advanced:
+`origin` has advanced:
................................................
o--o--O--o--o--o <-- origin
@@ -2505,7 +2506,7 @@ Some more interesting work has been done in the upstream project, and
a--b--c <-- mywork
................................................
-At this point, you could use "pull" to merge your changes back in;
+At this point, you could use `pull` to merge your changes back in;
the result would create a new merge commit, like this:
................................................
@@ -2524,7 +2525,7 @@ $ git rebase origin
-------------------------------------------------
This will remove each of your commits from mywork, temporarily saving
-them as patches (in a directory named ".git/rebase-apply"), update mywork to
+them as patches (in a directory named `.git/rebase-apply`), update mywork to
point at the latest version of origin, then apply each of the saved
patches to the new mywork. The result will look like:
@@ -2795,10 +2796,10 @@ arbitrary name:
$ git fetch origin todo:my-todo-work
-------------------------------------------------
-The first argument, "origin", just tells Git to fetch from the
+The first argument, `origin`, just tells Git to fetch from the
repository you originally cloned from. The second argument tells Git
-to fetch the branch named "todo" from the remote repository, and to
-store it locally under the name refs/heads/my-todo-work.
+to fetch the branch named `todo` from the remote repository, and to
+store it locally under the name `refs/heads/my-todo-work`.
You can also fetch branches from other repositories; so
@@ -2806,8 +2807,8 @@ You can also fetch branches from other repositories; so
$ git fetch git://example.com/proj.git master:example-master
-------------------------------------------------
-will create a new branch named "example-master" and store in it the
-branch named "master" from the repository at the given URL. If you
+will create a new branch named `example-master` and store in it the
+branch named `master` from the repository at the given URL. If you
already have a branch named example-master, it will attempt to
<<fast-forwards,fast-forward>> to the commit given by example.com's
master branch. In more detail:
@@ -2816,7 +2817,7 @@ master branch. In more detail:
git fetch and fast-forwards
---------------------------
-In the previous example, when updating an existing branch, "git fetch"
+In the previous example, when updating an existing branch, `git fetch`
checks to make sure that the most recent commit on the remote
branch is a descendant of the most recent commit on your copy of the
branch before updating your copy of the branch to point at the new
@@ -2842,11 +2843,11 @@ resulting in a situation like:
o--o--o <-- new head of the branch
................................................
-In this case, "git fetch" will fail, and print out a warning.
+In this case, `git fetch` will fail, and print out a warning.
In that case, you can still force Git to update to the new head, as
described in the following section. However, note that in the
-situation above this may mean losing the commits labeled "a" and "b",
+situation above this may mean losing the commits labeled `a` and `b`,
unless you've already created a reference of your own pointing to
them.
@@ -2861,7 +2862,7 @@ descendant of the old head, you may force the update with:
$ git fetch git://example.com/proj.git +master:refs/remotes/example/master
-------------------------------------------------
-Note the addition of the "+" sign. Alternatively, you can use the "-f"
+Note the addition of the `+` sign. Alternatively, you can use the `-f`
flag to force updates of all the fetched branches, as in:
-------------------------------------------------
@@ -2875,7 +2876,7 @@ may be lost, as we saw in the previous section.
Configuring remote-tracking branches
------------------------------------
-We saw above that "origin" is just a shortcut to refer to the
+We saw above that `origin` is just a shortcut to refer to the
repository that you originally cloned from. This information is
stored in Git configuration variables, which you can see using
linkgit:git-config[1]:
@@ -2984,7 +2985,7 @@ Commit Object
~~~~~~~~~~~~~
The "commit" object links a physical state of a tree with a description
-of how we got there and why. Use the --pretty=raw option to
+of how we got there and why. Use the `--pretty=raw` option to
linkgit:git-show[1] or linkgit:git-log[1] to examine your favorite
commit:
@@ -3026,7 +3027,7 @@ of the tree referred to by this commit with the trees associated with
its parents. In particular, Git does not attempt to record file renames
explicitly, though it can identify cases where the existence of the same
file data at changing paths suggests a rename. (See, for example, the
--M option to linkgit:git-diff[1]).
+`-M` option to linkgit:git-diff[1]).
A commit is usually created by linkgit:git-commit[1], which creates a
commit whose parent is normally the current HEAD, and whose tree is
@@ -3077,7 +3078,7 @@ Blob Object
~~~~~~~~~~~
You can use linkgit:git-show[1] to examine the contents of a blob; take,
-for example, the blob in the entry for "COPYING" from the tree above:
+for example, the blob in the entry for `COPYING` from the tree above:
------------------------------------------------
$ git show 6ff87c4664
@@ -3160,14 +3161,14 @@ nLE/L9aUXdWeTFPron96DLA=
See the linkgit:git-tag[1] command to learn how to create and verify tag
objects. (Note that linkgit:git-tag[1] can also be used to create
"lightweight tags", which are not tag objects at all, but just simple
-references whose names begin with "refs/tags/").
+references whose names begin with `refs/tags/`).
[[pack-files]]
How Git stores objects efficiently: pack files
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Newly created objects are initially created in a file named after the
-object's SHA-1 hash (stored in .git/objects).
+object's SHA-1 hash (stored in `.git/objects`).
Unfortunately this system becomes inefficient once a project has a
lot of objects. Try this on an old project:
@@ -3208,9 +3209,9 @@ $ git prune
to remove any of the "loose" objects that are now contained in the
pack. This will also remove any unreferenced objects (which may be
-created when, for example, you use "git reset" to remove a commit).
+created when, for example, you use `git reset` to remove a commit).
You can verify that the loose objects are gone by looking at the
-.git/objects directory or by running
+`.git/objects` directory or by running
------------------------------------------------
$ git count-objects
@@ -3237,7 +3238,7 @@ branch still exists, as does everything it pointed to. The branch
pointer itself just doesn't, since you replaced it with another one.
There are also other situations that cause dangling objects. For
-example, a "dangling blob" may arise because you did a "git add" of a
+example, a "dangling blob" may arise because you did a `git add` of a
file, but then, before you actually committed it and made it part of the
bigger picture, you changed something else in that file and committed
that *updated* thing--the old state that you added originally ends up
@@ -3280,14 +3281,14 @@ $ git show <dangling-blob/tree-sha-goes-here>
------------------------------------------------
to show what the contents of the blob were (or, for a tree, basically
-what the "ls" for that directory was), and that may give you some idea
+what the `ls` for that directory was), and that may give you some idea
of what the operation was that left that dangling object.
Usually, dangling blobs and trees aren't very interesting. They're
almost always the result of either being a half-way mergebase (the blob
will often even have the conflict markers from a merge in it, if you
have had conflicting merges that you fixed up by hand), or simply
-because you interrupted a "git fetch" with ^C or something like that,
+because you interrupted a `git fetch` with ^C or something like that,
leaving _some_ of the new objects in the object database, but just
dangling and useless.
@@ -3298,16 +3299,16 @@ state, you can just prune all unreachable objects:
$ git prune
------------------------------------------------
-and they'll be gone. But you should only run "git prune" on a quiescent
+and they'll be gone. But you should only run `git prune` on a quiescent
repository--it's kind of like doing a filesystem fsck recovery: you
don't want to do that while the filesystem is mounted.
-(The same is true of "git fsck" itself, btw, but since
+(The same is true of `git fsck` itself, btw, but since
`git fsck` never actually *changes* the repository, it just reports
on what it found, `git fsck` itself is never 'dangerous' to run.
Running it while somebody is actually changing the repository can cause
confusing and scary messages, but it won't actually do anything bad. In
-contrast, running "git prune" while somebody is actively changing the
+contrast, running `git prune` while somebody is actively changing the
repository is a *BAD* idea).
[[recovering-from-repository-corruption]]
@@ -3345,7 +3346,7 @@ missing blob 4b9458b3786228369c63936db65827de3cc06200
Now you know that blob 4b9458b3 is missing, and that the tree 2d9263c6
points to it. If you could find just one copy of that missing blob
object, possibly in some other repository, you could move it into
-.git/objects/4b/9458b3... and be done. Suppose you can't. You can
+`.git/objects/4b/9458b3...` and be done. Suppose you can't. You can
still examine the tree that pointed to it with linkgit:git-ls-tree[1],
which might output something like:
@@ -3360,10 +3361,10 @@ $ git ls-tree 2d9263c6d23595e7cb2a21e5ebbb53655278dff8
------------------------------------------------
So now you know that the missing blob was the data for a file named
-"myfile". And chances are you can also identify the directory--let's
-say it's in "somedirectory". If you're lucky the missing copy might be
+`myfile`. And chances are you can also identify the directory--let's
+say it's in `somedirectory`. If you're lucky the missing copy might be
the same as the copy you have checked out in your working tree at
-"somedirectory/myfile"; you can test whether that's right with
+`somedirectory/myfile`; you can test whether that's right with
linkgit:git-hash-object[1]:
------------------------------------------------
@@ -3418,7 +3419,7 @@ $ git hash-object -w <recreated-file>
and your repository is good again!
-(Btw, you could have ignored the fsck, and started with doing a
+(Btw, you could have ignored the `fsck`, and started with doing a
------------------------------------------------
$ git log --raw --all
@@ -3432,7 +3433,7 @@ just missing one particular blob version.
The index
-----------
-The index is a binary file (generally kept in .git/index) containing a
+The index is a binary file (generally kept in `.git/index`) containing a
sorted list of path names, each with permissions and the SHA-1 of a blob
object; linkgit:git-ls-files[1] can show you the contents of the index:
@@ -3572,7 +3573,7 @@ $ ls -a
The `git submodule add <repo> <path>` command does a couple of things:
-- It clones the submodule from <repo> to the given <path> under the
+- It clones the submodule from `<repo>` to the given `<path>` under the
current directory and by default checks out the master branch.
- It adds the submodule's clone path to the linkgit:gitmodules[5] file and
adds this file to the index, ready to be committed.
@@ -3700,11 +3701,11 @@ Unable to checkout '261dfac35cb99d380eb966e102c1197139f7fa24' in submodule path
In older Git versions it could be easily forgotten to commit new or modified
files in a submodule, which silently leads to similar problems as not pushing
-the submodule changes. Starting with Git 1.7.0 both "git status" and "git diff"
+the submodule changes. Starting with Git 1.7.0 both `git status` and `git diff`
in the superproject show submodules as modified when they contain new or
-modified files to protect against accidentally committing such a state. "git
-diff" will also add a "-dirty" to the work tree side when generating patch
-output or used with the --submodule option:
+modified files to protect against accidentally committing such a state. `git
+diff` will also add a `-dirty` to the work tree side when generating patch
+output or used with the `--submodule` option:
-------------------------------------------------
$ git diff
@@ -3880,7 +3881,7 @@ or, if you want to check out all of the index, use `-a`.
NOTE! `git checkout-index` normally refuses to overwrite old files, so
if you have an old version of the tree already checked out, you will
-need to use the "-f" flag ('before' the "-a" flag or the filename) to
+need to use the `-f` flag ('before' the `-a` flag or the filename) to
'force' the checkout.
@@ -3891,7 +3892,7 @@ from one representation to the other:
Tying it all together
~~~~~~~~~~~~~~~~~~~~~
-To commit a tree you have instantiated with "git write-tree", you'd
+To commit a tree you have instantiated with `git write-tree`, you'd
create a "commit" object that refers to that tree and the history
behind it--most notably the "parent" commits that preceded it in
history.
@@ -4152,8 +4153,9 @@ As a result, the general consistency of an object can always be tested
independently of the contents or the type of the object: all objects can
be validated by verifying that (a) their hashes match the content of the
file and (b) the object successfully inflates to a stream of bytes that
-forms a sequence of <ascii type without space> {plus} <space> {plus} <ascii decimal
-size> {plus} <byte\0> {plus} <binary object data>.
+forms a sequence of
+`<ascii type without space> + <space> + <ascii decimal size> +
+<byte\0> + <binary object data>`.
The structured objects can further have their structure and
connectivity to other objects verified. This is generally done with
@@ -4632,10 +4634,10 @@ Think about how to create a clear chapter dependency graph that will
allow people to get to important topics without necessarily reading
everything in between.
-Scan Documentation/ for other stuff left out; in particular:
+Scan `Documentation/` for other stuff left out; in particular:
- howto's
-- some of technical/?
+- some of `technical/`?
- hooks
- list of commands in linkgit:git[1]
--
1.8.2.rc0.16.g20a599e
^ permalink raw reply related
* Re: [PATCH v2 0/2] improve-wincred-compatibility
From: Karsten Blees @ 2013-02-25 23:39 UTC (permalink / raw)
To: Junio C Hamano
Cc: kusmabite, git, msysgit, Jeff King, patthoyts,
Johannes.Schindelin
In-Reply-To: <7vsj4k3nbu.fsf@alter.siamese.dyndns.org>
Am 25.02.2013 07:43, schrieb Junio C Hamano:
> Erik Faye-Lund <kusmabite@gmail.com> writes:
>
>> On Thu, Jan 10, 2013 at 1:10 PM, Karsten Blees <karsten.blees@gmail.com> wrote:
>>> Changes since initial version (see attached diff for details):
>>> - split in two patches
>>> - removed unused variables
>>> - improved the dll error message
>>> - changed ?: to if else
>>> - added comments
>>>
>>> Also available here:
>>> https://github.com/kblees/git/tree/kb/improve-wincred-compatibility-v2
>>> git pull git://github.com/kblees/git.git kb/improve-wincred-compatibility-v2
>>>
>>> Karsten Blees (2):
>>> wincred: accept CRLF on stdin to simplify console usage
>>> wincred: improve compatibility with windows versions
>>>
>>> .../credential/wincred/git-credential-wincred.c | 206 ++++++++-------------
>>> 1 file changed, 75 insertions(+), 131 deletions(-)
>>>
>>
>> Wonderful!
>>
>> Acked-by: Erik Faye-Lund <kusmabite@gmail.com>
>
> I'm in the "marking leftover bits" mode today, and noticed that
> nothing happened for this topic in my tree. Did msysgit folks expect
> me to pick this up directly, or did you guys want to feed this series
> to me (with possibly other changes you worked on outside this list)?
>
The second patch changes the credential format in a backward-incompatible way, so I think this should be in git.git, too (better than having two incompatible versions around).
@Pat, Dscho: the rebase-merge script should automatically drop patches found in upstream, correct?
--
--
*** Please reply-to-all at all times ***
*** (do not pretend to know who is subscribed and who is not) ***
*** Please avoid top-posting. ***
The msysGit Wiki is here: https://github.com/msysgit/msysgit/wiki - Github accounts are free.
You received this message because you are subscribed to the Google
Groups "msysGit" group.
To post to this group, send email to msysgit@googlegroups.com
To unsubscribe from this group, send email to
msysgit+unsubscribe@googlegroups.com
For more options, and view previous threads, visit this group at
http://groups.google.com/group/msysgit?hl=en_US?hl=en
---
You received this message because you are subscribed to the Google Groups "msysGit" group.
To unsubscribe from this group and stop receiving emails from it, send an email to msysgit+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
^ permalink raw reply
* Re: [PATCH 12/13] Documentation/Makefile: update git guide links
From: Philip Oakley @ 2013-02-25 23:43 UTC (permalink / raw)
To: Junio C Hamano; +Cc: GitList
In-Reply-To: <7vd2vp3qru.fsf@alter.siamese.dyndns.org>
On 25/02/13 05:29, Junio C Hamano wrote:
> Philip Oakley <philipoakley@iee.org> writes:
>
>> @@ -35,6 +37,8 @@ MAN_XML=$(patsubst %.txt,%.xml,$(MAN_TXT))
>> MAN_HTML=$(patsubst %.txt,%.html,$(MAN_TXT))
>>
>> OBSOLETE_HTML = git-remote-helpers.html
>> +OBSOLETE_HTML = everyday.html
>> +OBSOLETE_HTML = user-manual.html
>> DOC_HTML=$(MAN_HTML) $(OBSOLETE_HTML)
>
> If you are keeping track of inventory of "guides" in a new static
> array, do you still need to look up "giteveryday" or "gituser-manual"
> when the user asks for guide documents?
I'm only keeping track in the new static array of the 'common guides'
and I'd hoped that these two could be included.
>
> In other words, can't you change the side that launches the document
> viewer so that we do not have to rename anything in the first place?
>
The current help code will only show either 'git-<cmd>' man pages, or
'git<guide>' pages so the current everyday and user-manual pages aren't
served by the existing help code.
$ git help everyday
No manual entry for giteveryday
Hence the need for the rename and 'obsolete page' entries.
I'm guessing that serving any old .txt or .html page from the
Documentation directories isn't sensible (rather than being prefix
based), but it is a possibility.
Philip
^ permalink raw reply
* Re: [PATCH 05/13] Help.c: add list_common_guides_help() function
From: Philip Oakley @ 2013-02-25 23:43 UTC (permalink / raw)
To: Junio C Hamano; +Cc: GitList
In-Reply-To: <7vk3px3qzp.fsf@alter.siamese.dyndns.org>
On 25/02/13 05:24, Junio C Hamano wrote:
> "Philip Oakley" <philipoakley@iee.org> writes:
>
>> From: "Junio C Hamano" <gitster@pobox.com>
>> Sent: Sunday, February 24, 2013 9:01 AM
>>> Philip Oakley <philipoakley@iee.org> writes:
>>>
>>>> diff --git a/common-guides.h b/common-guides.h
>>>> new file mode 100644
>>>> index 0000000..a8ad8d1
>>>> --- /dev/null
>>>> +++ b/common-guides.h
>>>> @@ -0,0 +1,12 @@
>>>> +/* Automatically generated by ./generate-guidelist.sh */
>>>> +/* re-use struct cmdname_help in common-commands.h */
>>>
>>> Huh?
>> The first comment line fortells of patch 6 which can generate this .h
>> file.
>
> The Huh? was about that one, not about reuse. I do not want to see
> a build artifact kept in the history without a good reason.
>
I'd copied it from generate-cmdlist.sh which is a common-cmd.h
dependency and was introduced by
commit a87cd02ce02e97083eb76eb8b9bfeb2e46800fd7
Author: Fredrik Kuivinen <freku045@student.liu.se>
Date: Thu Mar 9 17:24:19 2006 +0100
Nicer output from 'git'
[jc: with suggestions by Jan-Benedict Glaw]
Signed-off-by: Fredrik Kuivinen <freku045@student.liu.se>
Signed-off-by: Junio C Hamano <junkio@cox.net>
The reason in this (my) case, as then, is that it states how the file is
generated so that it can be regenerated later. If the patches are
successful then I'd want the generate-guidelist and generate-cmdlist to
be joined together as an integral part of generating the help system data.
Mind you each review point turns over another stone that needs to be
considered, such as the Makefile link of common-commands.h and similarly
for the Documentation/Makefile - I'm thinking of the issues around
'gitk' and its ilk which isn't a common command (because it has no
hyphen) yet is in the command list, so can be confused with the support
documentation, however I don't mark it as a common guide, so that's OK.
('git help k' does offer the gitk man page ;-)
I'll tidy up the series over the next few days to include the points so far
Philip
^ 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