* Re: [PATCH] Respect core.autocrlf when preparing temporary files for external diff
From: Junio C Hamano @ 2009-03-22 23:12 UTC (permalink / raw)
To: Sebastian Schuberth; +Cc: Jeff King, Johannes Schindelin, git
In-Reply-To: <bdca99240903221548y38f31177q6abb88c2f7f87a73@mail.gmail.com>
Sebastian Schuberth <sschuberth@gmail.com> writes:
>> The discussion in the last few messages in this thread speculates that the
>> external programs are more likely to expect representations suitable in
>> the work tree, aka "smudged", than "clean" one. It would be nice to get a
>> datapoint from you as the original reporter to confirm or refute that
>> speculation.
>
> I agree to the speculations. IMHO calling an external diff tool with
> two revisions of a file should result in the same as e.g. checking out
> the two revisions in two different working trees and then launching
> the user's external diff tool on the two working tree files.
Ok.
^ permalink raw reply
* Re: Newbie: Do I need to download the entire repo to work on just 1 file?
From: Geoffrey Lee @ 2009-03-22 23:16 UTC (permalink / raw)
To: Sverre Rabbelier; +Cc: Nicolas Sebrecht, git
In-Reply-To: <fabb9a1e0903221610p3b11f09ctc6a9f4d38b1bda3e@mail.gmail.com>
On Sun, Mar 22, 2009 at 4:10 PM, Sverre Rabbelier <srabbelier@gmail.com> wrote:
> That depends on if he wants to push back to the original repo or not, right?
Correct. You cannot push, fetch, or clone a shallow repo. And for Git
development, it's all about sending patches, so you don't need past
revisions.
-Geoffrey Lee
^ permalink raw reply
* Re: [PATCH 1/7] check_ref_format(): tighten refname rules
From: Junio C Hamano @ 2009-03-22 23:19 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git
In-Reply-To: <alpine.DEB.1.00.0903221539060.10279@pacific.mpi-cbg.de>
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> On Sat, 21 Mar 2009, Junio C Hamano wrote:
>
>> Yes, I know that tightening rules retroactively is bad, but this changes
>> the rules for refnames to forbid:
>
> Tightening rules retroactively is not only bad (if sometimes necessary),
> but tightening rules without giving the user a chance to recover is really
> bad.
>
> 'git branch -m' uses check_ref_format() to check the old name.
Because "git branch -d" still allows a malformed funny branch to be
removed with this patch, I would say it is Ok as long as release notes
clearly says what we are tightening the rule for.
It is very probable that some people may have "master@{24}" in their
repositories, but such a branch cannot be accessed with or without this
patch anyway, and it is unlikely they created it because they wanted to.
"git branch wtf-dot wtf." followed by "git branch -d wtf." also works; for
this one, it might make sense to allow "git branch -m" to rename it, but
I do not think it is worth it.
^ permalink raw reply
* Re: [PATCH] Documentation/git-filter-branch.txt: Remove unnecessary URL quoting
From: Johan Herland @ 2009-03-22 23:20 UTC (permalink / raw)
To: Thomas Rast; +Cc: Junio C Hamano, git
In-Reply-To: <200903201619.56600.trast@student.ethz.ch>
On Friday 20 March 2009, Thomas Rast wrote:
> Johan Herland wrote:
> > Embedding the URL in '+++' causes AsciiDoc (v8.4.1) to generate invalid
> > XML. None of the other URLs in Git's documentation are quoted in this
> > manner. There's no reason to treat this URL differently.
>
> [...]
>
> > -* Clone it with `git clone +++file:///path/to/repo+++`. The clone
> > +* Clone it with `git clone file:///path/to/repo`. The clone
>
> I deliberately wrote it that way because *not* quoting it, at least on
> my box, formats the entire paragraph in monospace. Apparently it
> treats the ` as part of an autodetected URL or some such. This is
> independent of my choice of ASCIIDOC8 or DOCBOOK_XSL_172 settings. Am
> I missing another flag that avoids this problem?
No, I think this is due to version differences in AsciiDoc.
> I have these packages installed from opensuse:
> asciidoc-8.2.7-29.10
I use AsciiDoc v8.4.1 (from Arch Linux), and according to
http://www.methods.co.nz/asciidoc/CHANGELOG.html there are some regression
issues regarding backtick quoting and "inline literal passthrough"s when
upgrading to v8.4.1. According to the changelog I should be able to revert
AsciiDoc to the old behaviour by putting
[attributes]
no-inline-literal=
in my Documentation/asciidoc.conf. However, with this in place, I _still_
get invalid XML generated for git-filter-branch.txt... :(
So, it seems to be an AsciiDoc versioning issue. I'm not sure which of these
AsciiDoc versions are preferable, of if it is possible to format the text in
such a manner that it'll work in both versions.
...Johan
--
Johan Herland, <johan@herland.net>
www.herland.net
^ permalink raw reply
* Re: Git for Windows 1.6.2.1-preview20090322
From: Johannes Schindelin @ 2009-03-22 23:25 UTC (permalink / raw)
To: Jeff King; +Cc: Johannes Sixt, git, msysgit
In-Reply-To: <20090322225315.GC22428@sigill.intra.peff.net>
Hi,
On Sun, 22 Mar 2009, Jeff King wrote:
> On Sun, Mar 22, 2009 at 10:17:23PM +0100, Johannes Schindelin wrote:
>
> > - Some commands are not yet supported on Windows and excluded from the
> > installation; namely: git archimport, git cvsexportcommit, git
> > cvsimport, git cvsserver, git filter-branch, git instaweb, git
> > send-email, git shell.
>
> A few people have asked about filter-branch on Windows recently;
I am not aware of any. But then, I think nobody mentioned it on the
msysgit list (which would be the correct place), and I am likely to have
missed it if it was sent elsewhere.
> JSixt indicated that it works from his built version:
>
> http://article.gmane.org/gmane.comp.version-control.git/112103
>
> Is it time to include it?
Actually, not only Hannes' version runs the test t7003 okay, but also
4msysgit's version.
But let's reduce the differences between git.git and 4msysgit.git further
first.
I'll wait with the next Git for Windows release until the next official
Git version is released, anyway. Or if Steffen wants to take msysGit over
again when he comes back, he will wait until the next official Git
versions is released, anyway.
Ciao,
Dscho
^ permalink raw reply
* Re: Newbie: Do I need to download the entire repo to work on just 1 file?
From: Nicolas Sebrecht @ 2009-03-22 23:31 UTC (permalink / raw)
To: Sverre Rabbelier; +Cc: Nicolas Sebrecht, git, Anthony Rasmussen
In-Reply-To: <fabb9a1e0903221610p3b11f09ctc6a9f4d38b1bda3e@mail.gmail.com>
On Mon, Mar 23, 2009 at 12:10:48AM +0100, Sverre Rabbelier wrote:
>
> Heya,
>
> On Mon, Mar 23, 2009 at 00:10, Nicolas Sebrecht
> <nicolas.s-dev@laposte.net> wrote:
> > No, you don't. Why not use the '--depth <depth>' option of 'git clone' ?
>
> That depends on if he wants to push back to the original repo or not, right?
It depends of what the OP means by "entire repository". You can't
"cherry-pick" one single file without download the entire tree of the
working directory.
You can push with a truncated history. What you can't do is checkout
from the history you don't have in your local repository.
--
Nicolas Sebrecht
^ permalink raw reply
* Re: Newbie: Do I need to download the entire repo to work on just 1 file?
From: Nicolas Sebrecht @ 2009-03-22 23:36 UTC (permalink / raw)
To: Nicolas Sebrecht; +Cc: Sverre Rabbelier, git, Anthony Rasmussen
In-Reply-To: <20090322233120.GC12974@vidovic>
On Mon, Mar 23, 2009 at 12:31:20AM +0100, Nicolas Sebrecht wrote:
> You can push with a truncated history. What you can't do is checkout
> from the history you don't have in your local repository.
I just told my biggest mistake today. It's time to go to the bed.
--
Nicolas Sebrecht
^ permalink raw reply
* GNU patch: new alpha release
From: Andreas Gruenbacher @ 2009-03-22 23:49 UTC (permalink / raw)
To: git
Hello,
I am pleased to announce my first alpha release of GNU patch,
available by anonymouns FTP from:
ftp://alpha.gnu.org/gnu/patch/
The purpose of this release is to allow people to test changes which will
eventually end up in the next stable release.
The last release dates back to June 2004 with version 2.5.9. I would like to
thank Paul Eggert for his work on GNU patch, and for making his code
repository available for import. A new project has been created on Savannah
with the new code repository and the bug-patch@gnu.org mailing list archive:
http://savannah.gnu.org/projects/patch
A lot of things have accumulated since version 2.5.9. I am in the process of
reviewing more bug reports to bug-gnu-utils@gnu.org and bug-patch@gnu.org.
Meanwhile, several issues have already been addressed, and the following user
visible changes have been made:
* A regression test suite has been added ("make check").
* Unless a filename has been specified on the command line, look only
for filenames in the patch until one has been found. Start looking
for hunks only after that. This prevents patch from tripping over
garbage that isn't a patch. When conforming to POSIX, this behavior
is turned off and patch will ask for a filename when none is found.
* Reject more malformed normal format commands and check for trailing
garbage. Recognize ed commands without addresses.
* All reject files have file name headers, which allows to use them
as regular patches.
* When a patch file modifies the same file more than once, patch makes
sure it backs up the original version of the file, rather than any
intermediary versions.
* In the above situation, if there are rejects in more than one of those
patches, the rejects are appended to the same reject file (rather then
overwriting themselves).
* The -r option works correctly even there are rejects in more than one
file. Use the - argument to discard rejects.
* Rejected hunks come out in unified diff format if the input patch was of
that format, otherwise in ordinary context diff form. Use the
--reject-format option to enforce either "context" or "unified" format.
The "diff -p" (--show-c-function) output is preserved.
Changed lines in context format reject files are correctly indicated
with '!' markers as the format defines. Added and removed lines are
still marked with '+' and '-', respectively.
* The file permissions of reject files are no longer set to match the files
they modify. Instead, they retain the default permissions. This is
consistent with reject files to which rejects of multiple files may be
written (-r option).
* The --binary option disables the heuristic for stripping CRs from
line endings in patches. This allows to preserve CRs even in mangled
patches, or in patches generated without the --binary option on non-POSIX
systems.
More fixes and improvements are pending. Please see the project's bug tracker
for a (so far incomplete) list of known issues before reporting those things
again on the mailing list.
Please email bugs or suggestions to <bug-patch@gnu.org>.
Thanks,
Andreas
^ permalink raw reply
* Re: [RFC/PATCH 8/8] user-manual: simplify the user configuration
From: Junio C Hamano @ 2009-03-23 0:00 UTC (permalink / raw)
To: Felipe Contreras; +Cc: Wincent Colaiuta, git
In-Reply-To: <94a0d4530903221601hb3bf8aelf98b22ee560dfb7b@mail.gmail.com>
Felipe Contreras <felipe.contreras@gmail.com> writes:
>> See this lengthy thread:
>>
>> http://article.gmane.org/gmane.comp.version-control.git/106634
>
> I've obviously seen that thread because I started it.
>
> Can you write more than one line to explain your point?
The "lengthy thread" look lengthier than necessary because it has a
more-or-less unrelated side topic ("where is $HOME on Windows"), but I
think the main point by WIncent is that onus lies on whoever repeats the
previous discussion to provide what is different in this round to convince
others to read the patch. For example, this
http://article.gmane.org/gmane.comp.version-control.git/106657
was not answered by you in the previous round, and I do not think this
round is any different.
I personally find that between what Wincent presented in
http://article.gmane.org/gmane.comp.version-control.git/106673
as "Something like either ... or ...", the first one that shows the actual
configuration file contents and then mention 'git config' a good enough
compromise.
^ permalink raw reply
* Re: [RFC/PATCH 8/8] user-manual: simplify the user configuration
From: Wincent Colaiuta @ 2009-03-23 0:07 UTC (permalink / raw)
To: Felipe Contreras; +Cc: git
In-Reply-To: <94a0d4530903221601hb3bf8aelf98b22ee560dfb7b@mail.gmail.com>
El 23/3/2009, a las 0:01, Felipe Contreras escribió:
> On Mon, Mar 23, 2009 at 12:42 AM, Wincent Colaiuta <win@wincent.com>
> wrote:
>> El 22/3/2009, a las 19:05, Felipe Contreras escribió:
>>
>>> This is shorter, avoids the burder to think about the format of the
>>> configuration file, and git config is already used in other places
>>> in
>>> the manual.
>>>
>>> Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com>
>>> ---
>>> Documentation/user-manual.txt | 8 +++-----
>>> 1 files changed, 3 insertions(+), 5 deletions(-)
>>>
>>> diff --git a/Documentation/user-manual.txt b/Documentation/user-
>>> manual.txt
>>> index b7678aa..c6ed940 100644
>>> --- a/Documentation/user-manual.txt
>>> +++ b/Documentation/user-manual.txt
>>> @@ -1015,13 +1015,11 @@ Telling git your name
>>> ---------------------
>>>
>>> Before creating any commits, you should introduce yourself to
>>> git. The
>>> -easiest way to do so is to make sure the following lines appear
>>> in a
>>> -file named `.gitconfig` in your home directory:
>>> +easiest way is to use the linkgit:git-config[1] command:
>>>
>>> ------------------------------------------------
>>> -[user]
>>> - name = Your Name Comes Here
>>> - email = you@yourdomain.example.com
>>> +$ git config --global user.name "Your Name Comes Here"
>>> +$ git config --global user.email you@yourdomain.example.com
>>> ------------------------------------------------
>>>
>>> (See the '"CONFIGURATION FILE"' section of linkgit:git-config[1] for
>>> --
>>> 1.6.2.1.352.gae594
>>
>> See this lengthy thread:
>>
>> http://article.gmane.org/gmane.comp.version-control.git/106634
>
> I've obviously seen that thread because I started it.
Yeah, I noticed that only after sending my message. I hadn't realised
at first because the patch really looked like it was written by
someone who hadn't ever seen the thread, as it doesn't address the
points raised in the thread at all.
> Can you write more than one line to explain your point?
I was thinking mostly of Junio's comments:
http://article.gmane.org/gmane.comp.version-control.git/106667
'I am moderately against changing this part to use "git config". We
traditionally introduced how to set configuration variables first by
editing it in an editor, and this was quite deliberate, in order to
show how the configuration file looks like, to demonstrate that there
is no deep magic in the file format, and to explain that it is
perfectly Ok to edit it without using "git config" command. I actually
wish this section appeared a lot earlier in the document, but
that is a separate issue.'
If you expect him to apply your patch, you'll probably want to address
those concerns (and possibly others raised in referenced thread) in
the commit message.
Cheers,
Wincent
^ permalink raw reply
* Re: [RFC] git gui doesn't call post-checkout hook on checkout or clone
From: Shawn O. Pearce @ 2009-03-23 0:18 UTC (permalink / raw)
To: Jeff King; +Cc: Jens Lehmann, git, gitster
In-Reply-To: <20090322223309.GA22428@sigill.intra.peff.net>
Jeff King <peff@peff.net> wrote:
> On Sun, Mar 22, 2009 at 04:49:05PM +0100, Jens Lehmann wrote:
>
> > When checking out or cloning via git gui, the post-checkout
> > hook is not called. This is a bit unexpected ...
...
> > But is this the right way to do this? Seems like we could
> > surprise some users of git read-tree with this change in
> > behaviour.
>
> No, I think plumbing should not generally call hooks. The right solution
> would be to have git-gui call the post-checkout hook.
+1. git-gui should be invoking the hook. It doesn't. Patches are
welcome. I don't really have time these days for doing my own
development on git-gui, but well coded patches are still accepted.
--
Shawn.
^ permalink raw reply
* Re: [PATCH] Documentation: Reworded example text in git-bisect.txt.
From: J. Bruce Fields @ 2009-03-23 0:23 UTC (permalink / raw)
To: Christian Couder; +Cc: David J. Mellor, gitster, git, Michael J Gruber
In-Reply-To: <200903210528.32392.chriscool@tuxfamily.org>
On Sat, Mar 21, 2009 at 05:28:32AM +0100, Christian Couder wrote:
> Le vendredi 20 mars 2009, David J. Mellor a écrit :
>
> [...]
>
> > @@ -94,14 +95,14 @@ the bisection state).
> > Bisect visualize
> > ~~~~~~~~~~~~~~~~
> >
> > -During the bisection process, you issue the command:
> > +To see the currently remaining suspects in 'gitk', the following command
> > +is issued during the bisection process:
>
> I think it's better to avoid the passive tone, for example like this:
>
> "To see the currently remaining suspects in 'gitk', you issue the following
> command during the bisection process:"
Agreed, but drop the "you" too.
--b.
>
> > ------------
> > $ git bisect visualize
> > ------------
>
> [...]
>
> > @@ -173,8 +175,8 @@ using the "'<commit1>'..'<commit2>'" notation. For
> > example: $ git bisect skip v2.5..v2.6
> > ------------
> >
> > -would mean that no commit between `v2.5` excluded and `v2.6` included
> > -can be tested.
> > +The effect of this would be that no commit between `v2.5` excluded and
> > +`v2.6` included could be tested.
>
> I'd prefer something like:
>
> "This tells the bisect process that no commit between `v2.5` excluded and
> `v2.6` included can be tested."
>
> Otherwise it looks good to me.
>
> Thanks,
> Christian.
>
> --
> To unsubscribe from this list: send the line "unsubscribe git" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH] builtin-fast-export.c: add default case to avoid crash on corrupt repo
From: Shawn O. Pearce @ 2009-03-23 0:26 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Erik Faye-Lund, git, Johannes Schindelin
In-Reply-To: <7vd4cabffl.fsf@gitster.siamese.dyndns.org>
Junio C Hamano <gitster@pobox.com> wrote:
> It
> appears that there is no way to feed a tree object to fast-import, but I
> think the fast-import language can represent a tag that points at another
> tag just fine.
Correct.
This area of the langauge was built around the basic CVS->Git sort
of conversion, where we just wanted to attach the CVS "tag" symbol
onto a Git snapshot that seemed to match it. Annotated tags were
used only because tools like git fetch and git describe prefer to
work with them, and these were (at some point in time) meaningful
labels for these revisions so the project post-conversion should
retain those same labels.
In hindsight, parts of the fast-import langauge are problematic as
they don't fully represent the Git object graph, and this is one
of those areas. It wasn't designed to represent the same range
of structures as Git can represent.
> So the best you can do is perhaps to issue a warning
> "skipping a tag that points at a tree object" and impoement a proper
> handling of a tag that points at a tag.
Or, patch fast-import to expand its language. You could relax
the "from <committish>" rule to be "from <objectish>" and then
create tag a tree using a temporary branch and a from line of
"from temp-branch^{tree}".
--
Shawn.
^ permalink raw reply
* Re: [PATCH] Add --staged to bash completion for git diff
From: Shawn O. Pearce @ 2009-03-23 0:33 UTC (permalink / raw)
To: Kevin McConnell; +Cc: git
In-Reply-To: <372194e70903211629w52705806l5a82c2dde19b73f7@mail.gmail.com>
Kevin McConnell <kevin.mcconnell@gmail.com> wrote:
> The --staged option (synonym for --cached) isn't listed in the
> completion choices for git diff. This tiny patch adds it.
Missing Signed-off-by line?
Otherwise though,
Trivially-Acked-by: Shawn O. Pearce <spearce@spearce.org>
> ---
> contrib/completion/git-completion.bash | 2 +-
> 1 files changed, 1 insertions(+), 1 deletions(-)
>
> diff --git a/contrib/completion/git-completion.bash
> b/contrib/completion/git-completion.bash
> index ed235f7..6bc32df 100755
> --- a/contrib/completion/git-completion.bash
> +++ b/contrib/completion/git-completion.bash
> @@ -899,7 +899,7 @@ _git_diff ()
> local cur="${COMP_WORDS[COMP_CWORD]}"
> case "$cur" in
> --*)
> - __gitcomp "--cached --pickaxe-all --pickaxe-regex
> + __gitcomp "--cached --staged --pickaxe-all --pickaxe-regex
> --base --ours --theirs
> $__git_diff_common_options
> "
--
Shawn.
^ permalink raw reply
* Re: [PATCH] bash completion: add options for 'git fsck'
From: Shawn O. Pearce @ 2009-03-23 0:38 UTC (permalink / raw)
To: Arto Jonsson; +Cc: git
In-Reply-To: <20090322184907.GA31350@lakka.kapsi.fi>
Arto Jonsson <ajonsson@kapsi.fi> wrote:
> Signed-off-by: Arto Jonsson <ajonsson@kapsi.fi>
Acked-by: Shawn O. Pearce <spearce@spearce.org>
> contrib/completion/git-completion.bash | 16 ++++++++++++++++
> 1 files changed, 16 insertions(+), 0 deletions(-)
--
Shawn.
^ permalink raw reply
* Re: [PATCH] Respect core.autocrlf when preparing temporary files for external diff
From: Junio C Hamano @ 2009-03-23 0:39 UTC (permalink / raw)
To: Jeff King; +Cc: Johannes Schindelin, git, Sebastian Schuberth
In-Reply-To: <20090322074643.GA4826@coredump.intra.peff.net>
Jeff King <peff@peff.net> writes:
> On Sun, Mar 22, 2009 at 12:18:33AM -0700, Junio C Hamano wrote:
>
>> Ok. Although I already queued the removal to 'pu' for tonight's pushout
>> and it is way too late to revert that, I think I didn't have to remove the
>> function. The codepath that lets you cheat by borrowing from the checkout
>> runs convert_to_git() when it borrows, and if you are seeing a meaningful
>> optimization even with that overhead, perhaps it would be worth keeping.
>
> I certainly haven't done exhaustive tests. Obviously the one I did was a
> bit contrived. I just think it makes sense to have numbers rather than
> saying "this probably doesn't do anything anymore".
>
>> While the purist in me says #1 above is the right argument to make for
>> feeding "clean" version, I suspect that the textconv or extdiff tools more
>> often are not made from scratch and ported across platforms than are
>> cobbled up together out of tools the script writer finds on his platform.
>> I suspect that Dscho's "a tempfile should look like a checkout" would be
>> much friendlier to them in practice for this reason.
>
> I think you and I have about the same feeling on this, then. As somebody
> who does not actually use smudge/clean filters at all, I am willing to
> defer to Dscho's opinion, which is based on practical experience.
Thanks for a sanity check.
I've split these as two unrelated issues, and have queued
(1) Dscho's patch, that always feeds smudged representation to the
external diff and textconv filter;
(2) A change to reuse_worktree_file() that says "don't reuse" for paths
with CE_VALID set.
in 'pu'.
^ permalink raw reply
* Re: [PATCH 1/4] test-suite: adding a test for fast-export with tag variants
From: Junio C Hamano @ 2009-03-23 0:39 UTC (permalink / raw)
To: Erik Faye-Lund; +Cc: git
In-Reply-To: <1237758620-6116-1-git-send-email-kusmabite@gmail.com>
Erik Faye-Lund <kusmabite@gmail.com> writes:
> Signed-off-by: Erik Faye-Lund <kusmabite@gmail.com>
> ---
> t/t9302-fast-export-tags.sh | 25 +++++++++++++++++++++++++
> 1 files changed, 25 insertions(+), 0 deletions(-)
> create mode 100644 t/t9302-fast-export-tags.sh
>
> diff --git a/t/t9302-fast-export-tags.sh b/t/t9302-fast-export-tags.sh
> new file mode 100644
Make it executable if you need to add a new script, but shouldn't these
small tests be done as an addition to existing t9301, not as a brand new
script?
> index 0000000..2ecac32
> --- /dev/null
> +++ b/t/t9302-fast-export-tags.sh
> @@ -0,0 +1,25 @@
> +#!/bin/sh
> +#
> +# Copyright (c) 2009 Erik Faye-Lund
> +#
> +
> +test_description='git fast-export tag variants'
> +. ./test-lib.sh
> +
> +test_expect_success 'setup' '
> + touch dummy &&
> + git add dummy &&
> + git commit -m "initial commit" &&
> + HEAD_TREE=`git show -s --pretty=raw HEAD | grep tree | sed "s/tree //"` &&
> + git tag tree_tag -m "tagging a tree" $HEAD_TREE &&
> + git tag -a tree_tag-obj -m "tagging a tree" $HEAD_TREE &&
> + git tag tag-obj_tag -m "tagging a tag" tree_tag-obj &&
> + git tag -a tag-obj_tag-obj -m "tagging a tag" tree_tag-obj
> +'
> +
> +test_expect_success 'tree_tag' 'git fast-export tree_tag'
> +test_expect_success 'tree_tag-obj' 'git fast-export tree_tag-obj'
> +test_expect_success 'tag-obj_tag' 'git fast-export tag-obj_tag'
> +test_expect_success 'tag-obj_tag-obj' 'git fast-export tag-obj_tag-obj'
> +
> +test_done
The purpose of the first patch that adds tests is to expose existing
problems, and it is better to say test_expect_failure in them. Later
patch to fix these issues will contain code change and also change to flip
some of the expect_failure to expect_success, and that way we can see what
issue is fixed with which patch more easily.
These tests seem to only care about fast-export not dying, but don't we
also want to check if they produce correct results?
^ permalink raw reply
* Re: [PATCH 3/4] builtin-fast-export.c: fix crash on tagged trees
From: Junio C Hamano @ 2009-03-23 0:39 UTC (permalink / raw)
To: Erik Faye-Lund; +Cc: git, gitster
In-Reply-To: <1237758620-6116-3-git-send-email-kusmabite@gmail.com>
Erik Faye-Lund <kusmabite@gmail.com> writes:
> If a tag object points to a tree (or another unhandled type), the commit-
> pointer is left uninitialized and later dereferenced. This patch adds a default
> case to the switch that issues a warning and skips the object.
>
> Signed-off-by: Erik Faye-Lund <kusmabite@gmail.com>
> ---
> builtin-fast-export.c | 4 ++++
> 1 files changed, 4 insertions(+), 0 deletions(-)
>
> diff --git a/builtin-fast-export.c b/builtin-fast-export.c
> index 02bad1f..c3ce320 100644
> --- a/builtin-fast-export.c
> +++ b/builtin-fast-export.c
> @@ -375,6 +375,10 @@ static void get_tags_and_duplicates(struct object_array *pending,
> case OBJ_BLOB:
> handle_object(tag->object.sha1);
> continue;
> + default: /* OBJ_TAG (nested tags) is already handled */
The comment is good but only if you make this the last patch that comes
after the one that actually fixes the tag-to-tag (currently 4/4), no?
> + warning("Tag points to object of unexpected type %s, skipping.",
> + typename(tag->object.type));
> + continue;
> }
> break;
> default:
> --
> 1.6.2.1.226.gcb2dd
^ permalink raw reply
* Re: [PATCH 1/4] test-suite: adding a test for fast-export with tag variants
From: Erik Faye-Lund @ 2009-03-23 0:55 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Erik Faye-Lund, git
In-Reply-To: <7vfxh59in9.fsf@gitster.siamese.dyndns.org>
On Mon, Mar 23, 2009 at 1:39 AM, Junio C Hamano <gitster@pobox.com> wrote:
>> diff --git a/t/t9302-fast-export-tags.sh b/t/t9302-fast-export-tags.sh
>> new file mode 100644
>
> Make it executable if you need to add a new script, but shouldn't these
> small tests be done as an addition to existing t9301, not as a brand new
> script?
Sure, will do. I just have to figure out how to make it executable in windows ;)
As this is my first test, I was wondering a bit about how much I could
depend on the state of the repo, so I was a bit reluctant to add it to
the same test. But I guess it's easier for everyone in the long term
to put it into the same test, so I'll give it a go.
>> +test_expect_success 'tree_tag' 'git fast-export tree_tag'
>> +test_expect_success 'tree_tag-obj' 'git fast-export tree_tag-obj'
>> +test_expect_success 'tag-obj_tag' 'git fast-export tag-obj_tag'
>> +test_expect_success 'tag-obj_tag-obj' 'git fast-export tag-obj_tag-obj'
>> +
>> +test_done
>
> The purpose of the first patch that adds tests is to expose existing
> problems, and it is better to say test_expect_failure in them. Later
> patch to fix these issues will contain code change and also change to flip
> some of the expect_failure to expect_success, and that way we can see what
> issue is fixed with which patch more easily.
Sure, will do. I was a bit lazy, but updating it as we go will make
stuff easier in the future.
> These tests seem to only care about fast-export not dying, but don't we
> also want to check if they produce correct results?
Well, yeah. But I was working mainly on fixing a crash-bug here, and I
don't think I know enough about the correct output of fast-export to
pull this off. Perhaps tighting up the test is something someone else
would care to do?
--
Erik "kusma" Faye-Lund
kusmabite@gmail.com
(+47) 986 59 656
^ permalink raw reply
* [PATCH 1/5] Documentation: removed some uses of the passive voice in git-bisect.txt.
From: David J. Mellor @ 2009-03-23 1:00 UTC (permalink / raw)
To: gitster; +Cc: git
In-Reply-To: <1237770017-7168-1-git-send-email-dmellor@whistlingcat.com>
Signed-off-by: David J. Mellor <dmellor@whistlingcat.com>
---
Documentation/git-bisect.txt | 18 +++++++++---------
1 files changed, 9 insertions(+), 9 deletions(-)
diff --git a/Documentation/git-bisect.txt b/Documentation/git-bisect.txt
index 93d9fc0..f045d1f 100644
--- a/Documentation/git-bisect.txt
+++ b/Documentation/git-bisect.txt
@@ -95,8 +95,8 @@ the bisection state).
Bisect visualize
~~~~~~~~~~~~~~~~
-To see the currently remaining suspects in 'gitk', the following command
-is issued during the bisection process:
+To see the currently remaining suspects in 'gitk', you issue the following
+command during the bisection process:
------------
$ git bisect visualize
@@ -135,7 +135,7 @@ $ git bisect replay that-file
Avoiding testing a commit
~~~~~~~~~~~~~~~~~~~~~~~~~
-If in the middle of a bisect session, you know that the next suggested
+If, in the middle of a bisect session, you know that the next suggested
revision is not a good one to test (e.g. the change the commit
introduces is known not to work in your environment and you know it
does not have anything to do with the bug you are chasing), you may
@@ -151,8 +151,8 @@ $ git reset --hard HEAD~3 # try 3 revisions before what
# was suggested
------------
-Then compile and test the chosen revision. Afterwards the revision
-is marked as good or bad in the usual manner.
+Then you compile and test the chosen revision. Afterwards you mark
+the revision as good or bad in the usual manner.
Bisect skip
~~~~~~~~~~~~
@@ -175,8 +175,8 @@ using the "'<commit1>'..'<commit2>'" notation. For example:
$ git bisect skip v2.5..v2.6
------------
-The effect of this would be that no commit between `v2.5` excluded and
-`v2.6` included could be tested.
+This tells the bisect process that no commit between `v2.5` excluded and
+`v2.6` included should be tested.
Note that if you also want to skip the first commit of the range you
would issue the command:
@@ -185,8 +185,8 @@ would issue the command:
$ git bisect skip v2.5 v2.5..v2.6
------------
-This would cause the commits between `v2.5` included and `v2.6` included
-to be skipped.
+This tells the bisect process that the commits between `v2.5` included
+and `v2.6` included should be skipped.
Cutting down bisection by giving more parameters to bisect start
--
1.6.2.1
^ permalink raw reply related
* Minor documentation fixes
From: David J. Mellor @ 2009-03-23 1:00 UTC (permalink / raw)
To: gitster; +Cc: git
* removed some uses of the passive voice in git-bisect.txt
* minor grammatical fixes and rewording in git-bundle.txt
* minor grammatical fixes in git-cat-file.txt
* minor grammatical fixes in git-check-attr.txt
* minor grammatical fix in git-check-ref-format.txt
^ permalink raw reply
* [PATCH 3/5] Documentation: minor grammatical fixes in git-cat-file.txt.
From: David J. Mellor @ 2009-03-23 1:00 UTC (permalink / raw)
To: gitster; +Cc: git
In-Reply-To: <1237770017-7168-3-git-send-email-dmellor@whistlingcat.com>
Signed-off-by: David J. Mellor <dmellor@whistlingcat.com>
---
Documentation/git-cat-file.txt | 19 ++++++++++---------
1 files changed, 10 insertions(+), 9 deletions(-)
diff --git a/Documentation/git-cat-file.txt b/Documentation/git-cat-file.txt
index 668f697..390206e 100644
--- a/Documentation/git-cat-file.txt
+++ b/Documentation/git-cat-file.txt
@@ -3,7 +3,8 @@ git-cat-file(1)
NAME
----
-git-cat-file - Provide content or type/size information for repository objects
+git-cat-file - Provide content or type and size information for repository
+objects
SYNOPSIS
@@ -14,19 +15,19 @@ SYNOPSIS
DESCRIPTION
-----------
-In the first form, provides content or type of objects in the repository. The
-type is required unless '-t' or '-p' is used to find the object type, or '-s'
-is used to find the object size.
+In its first form, the command provides the content or the type of an object in
+the repository. The type is required unless '-t' or '-p' is used to find the
+object type, or '-s' is used to find the object size.
-In the second form, a list of object (separated by LFs) is provided on stdin,
-and the SHA1, type, and size of each object is printed on stdout.
+In the second form, a list of objects (separated by linefeeds) is provided on
+stdin, and the SHA1, type, and size of each object is printed on stdout.
OPTIONS
-------
<object>::
The name of the object to show.
For a more complete list of ways to spell object names, see
- "SPECIFYING REVISIONS" section in linkgit:git-rev-parse[1].
+ the "SPECIFYING REVISIONS" section in linkgit:git-rev-parse[1].
-t::
Instead of the content, show the object type identified by
@@ -56,8 +57,8 @@ OPTIONS
stdin. May not be combined with any other options or arguments.
--batch-check::
- Print the SHA1, type, and size of each object provided on stdin. May not be
- combined with any other options or arguments.
+ Print the SHA1, type, and size of each object provided on stdin. May not
+ be combined with any other options or arguments.
OUTPUT
------
--
1.6.2.1
^ permalink raw reply related
* [PATCH 4/5] Documentation: minor grammatical fixes in git-check-attr.txt.
From: David J. Mellor @ 2009-03-23 1:00 UTC (permalink / raw)
To: gitster; +Cc: git
In-Reply-To: <1237770017-7168-4-git-send-email-dmellor@whistlingcat.com>
Signed-off-by: David J. Mellor <dmellor@whistlingcat.com>
---
Documentation/git-check-attr.txt | 16 ++++++++--------
1 files changed, 8 insertions(+), 8 deletions(-)
diff --git a/Documentation/git-check-attr.txt b/Documentation/git-check-attr.txt
index 8c2ac12..50824e3 100644
--- a/Documentation/git-check-attr.txt
+++ b/Documentation/git-check-attr.txt
@@ -14,7 +14,7 @@ SYNOPSIS
DESCRIPTION
-----------
-For every pathname, this command will list if each attr is 'unspecified',
+For every pathname, this command will list if each attribute is 'unspecified',
'set', or 'unset' as a gitattribute on that pathname.
OPTIONS
@@ -23,11 +23,11 @@ OPTIONS
Read file names from stdin instead of from the command-line.
-z::
- Only meaningful with `--stdin`; paths are separated with
- NUL character instead of LF.
+ Only meaningful with `--stdin`; paths are separated with a
+ NUL character instead of a linefeed character.
\--::
- Interpret all preceding arguments as attributes, and all following
+ Interpret all preceding arguments as attributes and all following
arguments as path names. If not supplied, only the first argument will
be treated as an attribute.
@@ -37,12 +37,12 @@ OUTPUT
The output is of the form:
<path> COLON SP <attribute> COLON SP <info> LF
-Where <path> is the path of a file being queried, <attribute> is an attribute
+<path> is the path of a file being queried, <attribute> is an attribute
being queried and <info> can be either:
'unspecified';; when the attribute is not defined for the path.
-'unset';; when the attribute is defined to false.
-'set';; when the attribute is defined to true.
+'unset';; when the attribute is defined as false.
+'set';; when the attribute is defined as true.
<value>;; when a value has been assigned to the attribute.
EXAMPLES
@@ -69,7 +69,7 @@ org/example/MyClass.java: diff: java
org/example/MyClass.java: myAttr: set
---------------
-* Listing attribute for multiple files:
+* Listing an attribute for multiple files:
---------------
$ git check-attr myAttr -- org/example/MyClass.java org/example/NoMyAttr.java
org/example/MyClass.java: myAttr: set
--
1.6.2.1
^ permalink raw reply related
* [PATCH 2/5] Documentation: minor grammatical fixes and rewording in git-bundle.txt.
From: David J. Mellor @ 2009-03-23 1:00 UTC (permalink / raw)
To: gitster; +Cc: git
In-Reply-To: <1237770017-7168-2-git-send-email-dmellor@whistlingcat.com>
This commit also converts all reference specifications to a monospaced font,
as the embedded ~ character used in some of the references sometimes causes
the text up to the next ~ to be displayed incorrectly as a subscript when the
HTML pages are generated. This was tested with asciidoc 8.2.5.
Signed-off-by: David J. Mellor <dmellor@whistlingcat.com>
---
Documentation/git-bundle.txt | 86 +++++++++++++++++++++---------------------
1 files changed, 43 insertions(+), 43 deletions(-)
diff --git a/Documentation/git-bundle.txt b/Documentation/git-bundle.txt
index 57590b1..aee7e4a 100644
--- a/Documentation/git-bundle.txt
+++ b/Documentation/git-bundle.txt
@@ -19,13 +19,13 @@ DESCRIPTION
Some workflows require that one or more branches of development on one
machine be replicated on another machine, but the two machines cannot
-be directly connected so the interactive git protocols (git, ssh,
-rsync, http) cannot be used. This command provides support for
+be directly connected, and therefore the interactive git protocols (git,
+ssh, rsync, http) cannot be used. This command provides support for
'git-fetch' and 'git-pull' to operate by packaging objects and references
in an archive at the originating machine, then importing those into
another repository using 'git-fetch' and 'git-pull'
after moving the archive by some means (i.e., by sneakernet). As no
-direct connection between repositories exists, the user must specify a
+direct connection between the repositories exists, the user must specify a
basis for the bundle that is held by the destination repository: the
bundle assumes that all objects in the basis are already in the
destination repository.
@@ -43,7 +43,7 @@ verify <file>::
bundle format itself as well as checking that the prerequisite
commits exist and are fully linked in the current repository.
'git-bundle' prints a list of missing commits, if any, and exits
- with non-zero status.
+ with a non-zero status.
list-heads <file>::
Lists the references defined in the bundle. If followed by a
@@ -53,14 +53,14 @@ list-heads <file>::
unbundle <file>::
Passes the objects in the bundle to 'git-index-pack'
for storage in the repository, then prints the names of all
- defined references. If a reflist is given, only references
- matching those in the given list are printed. This command is
+ defined references. If a list of references is given, only
+ references matching those in the list are printed. This command is
really plumbing, intended to be called only by 'git-fetch'.
[git-rev-list-args...]::
A list of arguments, acceptable to 'git-rev-parse' and
- 'git-rev-list', that specify the specific objects and references
- to transport. For example, "master~10..master" causes the
+ 'git-rev-list', that specifies the specific objects and references
+ to transport. For example, `master\~10..master` causes the
current master reference to be packaged along with all objects
added since its 10th ancestor commit. There is no explicit
limit to the number of references and objects that may be
@@ -71,24 +71,24 @@ unbundle <file>::
A list of references used to limit the references reported as
available. This is principally of use to 'git-fetch', which
expects to receive only those references asked for and not
- necessarily everything in the pack (in this case, 'git-bundle' is
- acting like 'git-fetch-pack').
+ necessarily everything in the pack (in this case, 'git-bundle' acts
+ like 'git-fetch-pack').
SPECIFYING REFERENCES
---------------------
'git-bundle' will only package references that are shown by
'git-show-ref': this includes heads, tags, and remote heads. References
-such as master~1 cannot be packaged, but are perfectly suitable for
+such as `master\~1` cannot be packaged, but are perfectly suitable for
defining the basis. More than one reference may be packaged, and more
than one basis can be specified. The objects packaged are those not
contained in the union of the given bases. Each basis can be
-specified explicitly (e.g., ^master~10), or implicitly (e.g.,
-master~10..master, --since=10.days.ago master).
+specified explicitly (e.g. `^master\~10`), or implicitly (e.g.
+`master\~10..master`, `--since=10.days.ago master`).
It is very important that the basis used be held by the destination.
-It is okay to err on the side of conservatism, causing the bundle file
-to contain objects already in the destination as these are ignored
+It is okay to err on the side of caution, causing the bundle file
+to contain objects already in the destination, as these are ignored
when unpacking at the destination.
EXAMPLE
@@ -97,13 +97,13 @@ EXAMPLE
Assume you want to transfer the history from a repository R1 on machine A
to another repository R2 on machine B.
For whatever reason, direct connection between A and B is not allowed,
-but we can move data from A to B via some mechanism (CD, email, etc).
-We want to update R2 with developments made on branch master in R1.
+but we can move data from A to B via some mechanism (CD, email, etc.).
+We want to update R2 with development made on the branch master in R1.
-To bootstrap the process, you can first create a bundle that doesn't have
-any basis. You can use a tag to remember up to what commit you sent out
-in order to make it easy to later update the other repository with
-incremental bundle,
+To bootstrap the process, you can first create a bundle that does not have
+any basis. You can use a tag to remember up to what commit you last
+processed, in order to make it easy to later update the other repository
+with an incremental bundle:
----------------
machineA$ cd R1
@@ -111,17 +111,17 @@ machineA$ git bundle create file.bundle master
machineA$ git tag -f lastR2bundle master
----------------
-Then you sneakernet file.bundle to the target machine B. Because you don't
-have to have any object to extract objects from such a bundle, not only
-you can fetch/pull from a bundle, you can clone from it as if it was a
-remote repository.
+Then you transfer file.bundle to the target machine B. If you are creating
+the repository on machine B, then you can clone from the bundle as if it
+were a remote repository instead of creating an empty repository and then
+pulling or fetching objects from the bundle:
----------------
machineB$ git clone /home/me/tmp/file.bundle R2
----------------
This will define a remote called "origin" in the resulting repository that
-lets you fetch and pull from the bundle. $GIT_DIR/config file in R2 may
+lets you fetch and pull from the bundle. The $GIT_DIR/config file in R2 will
have an entry like this:
------------------------
@@ -130,12 +130,12 @@ have an entry like this:
fetch = refs/heads/*:refs/remotes/origin/*
------------------------
-You can fetch/pull to update the resulting mine.git repository after
-replacing the bundle you store at /home/me/tmp/file.bundle with incremental
-updates from here on.
+To update the resulting mine.git repository, you can fetch or pull after
+replacing the bundle stored at /home/me/tmp/file.bundle with incremental
+updates.
-After working more in the original repository, you can create an
-incremental bundle to update the other:
+After working some more in the original repository, you can create an
+incremental bundle to update the other repository:
----------------
machineA$ cd R1
@@ -143,8 +143,8 @@ machineA$ git bundle create file.bundle lastR2bundle..master
machineA$ git tag -f lastR2bundle master
----------------
-and sneakernet it to the other machine to replace /home/me/tmp/file.bundle,
-and pull from it.
+You then transfer the bundle to the other machine to replace
+/home/me/tmp/file.bundle, and pull from it.
----------------
machineB$ cd R2
@@ -152,49 +152,49 @@ machineB$ git pull
----------------
If you know up to what commit the intended recipient repository should
-have the necessary objects for, you can use that knowledge to specify the
+have the necessary objects, you can use that knowledge to specify the
basis, giving a cut-off point to limit the revisions and objects that go
in the resulting bundle. The previous example used lastR2bundle tag
-for this purpose, but you can use other options you would give to
+for this purpose, but you can use any other options that you would give to
the linkgit:git-log[1] command. Here are more examples:
-You can use a tag that is present in both.
+You can use a tag that is present in both:
----------------
$ git bundle create mybundle v1.0.0..master
----------------
-You can use a basis based on time.
+You can use a basis based on time:
----------------
$ git bundle create mybundle --since=10.days master
----------------
-Or you can use the number of commits.
+You can use the number of commits:
----------------
$ git bundle create mybundle -10 master
----------------
You can run `git-bundle verify` to see if you can extract from a bundle
-that was created with a basis.
+that was created with a basis:
----------------
$ git bundle verify mybundle
----------------
This will list what commits you must have in order to extract from the
-bundle and will error out if you don't have them.
+bundle and will error out if you do not have them.
A bundle from a recipient repository's point of view is just like a
-regular repository it fetches/pulls from. You can for example map
-refs, like this example, when fetching:
+regular repository which it fetches or pulls from. You can, for example, map
+references when fetching:
----------------
$ git fetch mybundle master:localRef
----------------
-Or see what refs it offers.
+You can also see what references it offers.
----------------
$ git ls-remote mybundle
--
1.6.2.1
^ permalink raw reply related
* [PATCH 5/5] Documentation: minor grammatical fix in git-check-ref-format.txt.
From: David J. Mellor @ 2009-03-23 1:00 UTC (permalink / raw)
To: gitster; +Cc: git
In-Reply-To: <1237770017-7168-5-git-send-email-dmellor@whistlingcat.com>
Signed-off-by: David J. Mellor <dmellor@whistlingcat.com>
---
Documentation/git-check-ref-format.txt | 40 ++++++++++++++++----------------
1 files changed, 20 insertions(+), 20 deletions(-)
diff --git a/Documentation/git-check-ref-format.txt b/Documentation/git-check-ref-format.txt
index 034223c..171b683 100644
--- a/Documentation/git-check-ref-format.txt
+++ b/Documentation/git-check-ref-format.txt
@@ -3,7 +3,7 @@ git-check-ref-format(1)
NAME
----
-git-check-ref-format - Make sure ref name is well formed
+git-check-ref-format - Ensures that a reference name is well formed
SYNOPSIS
--------
@@ -11,40 +11,40 @@ SYNOPSIS
DESCRIPTION
-----------
-Checks if a given 'refname' is acceptable, and exits non-zero if
-it is not.
+Checks if a given 'refname' is acceptable, and exits with a non-zero
+status if it is not.
A reference is used in git to specify branches and tags. A
-branch head is stored under `$GIT_DIR/refs/heads` directory, and
-a tag is stored under `$GIT_DIR/refs/tags` directory. git
-imposes the following rules on how refs are named:
+branch head is stored under the `$GIT_DIR/refs/heads` directory, and
+a tag is stored under the `$GIT_DIR/refs/tags` directory. git
+imposes the following rules on how references are named:
-. It can include slash `/` for hierarchical (directory)
+. They can include slash `/` for hierarchical (directory)
grouping, but no slash-separated component can begin with a
- dot `.`;
+ dot `.`.
-. It cannot have two consecutive dots `..` anywhere;
+. They cannot have two consecutive dots `..` anywhere.
-. It cannot have ASCII control character (i.e. bytes whose
+. They cannot have ASCII control characters (i.e. bytes whose
values are lower than \040, or \177 `DEL`), space, tilde `~`,
caret `{caret}`, colon `:`, question-mark `?`, asterisk `*`,
- or open bracket `[` anywhere;
+ or open bracket `[` anywhere.
-. It cannot end with a slash `/`.
+. They cannot end with a slash `/`.
-These rules makes it easy for shell script based tools to parse
-refnames, pathname expansion by the shell when a refname is used
+These rules make it easy for shell script based tools to parse
+reference names, pathname expansion by the shell when a reference name is used
unquoted (by mistake), and also avoids ambiguities in certain
-refname expressions (see linkgit:git-rev-parse[1]). Namely:
+reference name expressions (see linkgit:git-rev-parse[1]):
-. double-dot `..` are often used as in `ref1..ref2`, and in some
- context this notation means `{caret}ref1 ref2` (i.e. not in
- ref1 and in ref2).
+. A double-dot `..` is often used as in `ref1..ref2`, and in some
+ contexts this notation means `{caret}ref1 ref2` (i.e. not in
+ `ref1` and in `ref2`).
-. tilde `~` and caret `{caret}` are used to introduce postfix
+. A tilde `~` and caret `{caret}` are used to introduce the postfix
'nth parent' and 'peel onion' operation.
-. colon `:` is used as in `srcref:dstref` to mean "use srcref\'s
+. A colon `:` is used as in `srcref:dstref` to mean "use srcref\'s
value and store it in dstref" in fetch and push operations.
It may also be used to select a specific object such as with
'git-cat-file': "git cat-file blob v1.3.3:refs.c".
--
1.6.2.1
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox