* Re: git adds some text file as binary file by mistake
From: Robin Rosenberg @ 2008-10-31 0:29 UTC (permalink / raw)
To: Ping Yin; +Cc: Michael J Gruber, Git Mailing List
In-Reply-To: <46dff0320810292332y34ea0daemde05b58572946497@mail.gmail.com>
torsdagen den 30 oktober 2008 07.32.47 skrev Ping Yin:
> On Fri, Oct 24, 2008 at 9:30 PM, Ping Yin <pkufranky@gmail.com> wrote:
> > On Fri, Oct 24, 2008 at 8:54 PM, Michael J Gruber
> > <git@drmicha.warpmail.net> wrote:
> >> Ping Yin venit, vidit, dixit 24.10.2008 14:37:
> >>> So what should i do if i want it added as text file?
> >>
> >> You should give us more detail on the file ;)
> >> What's the extension, what's the typical content? It may be a simple
> >> matter of specifying attributes.
> >> Do ordinary diff and grep recognize your files as text?
> >>
> >> Michael
> >>
> >
> > It's just an xml file. I guess maybe there are some hidden characters
> > at the beginning. I will figure it out later because i have no access
> > to that file right now.
> >
> > Ping Yin
> >
>
> I have figured it out. It's just because the BOM characters feff00 in
> the beginning of the utf-8 xml file.
The UTF-8 BOM is EF BB BF, (no NUL.). FEFF is UTF-16 BE (and the third
byte would be 00 for an XML file). I think git currently regards just about
any UTF-16 file as binary becuase of the NUL bytes.
-- robin
^ permalink raw reply
* Re: [PATCH] Documentation: add a planning document for the next CLI revamp
From: Jeff King @ 2008-10-31 0:31 UTC (permalink / raw)
To: Sam Vilain
Cc: git, Johannes Schindelin, Scott Chacon, Tom Preston-Werner, J.H.,
Christian Couder, Kai Blin
In-Reply-To: <20081030002239.D453B21D14E@mail.utsl.gen.nz>
On Wed, Oct 29, 2008 at 05:22:00PM -0700, Sam Vilain wrote:
> Some suggestions, which have been briefly scanned over by some of the
> (remaining) GitTogether attendees. Please keep it constructive! :)
Thanks for putting this together.
> + * 'git stage' would do what 'git add' does now.
> +
> + * 'git unstage' would do what 'git reset --' does now
These seem reasonable.
> + * 'git status' would encourage the user to use
> + 'git diff --staged' to see staged changes as a patch
I notice the commit template message getting longer and longer. Maybe it
is time for status.verbosetemplate (which could default to true, I just
want to be able to turn it off).
> + * 'git commit' with no changes should give useful information about
> + using 'git stage', 'git commit -a' or 'git commit filename ...'
There is already infrastructure that figures out exactly what the
situation is (no changes versus changes in untracked files versus
changes in unstaged files), so it should just be a matter of tweaking
the messages.
> + * 'git add' and 'git rm': no change
> +
> + * 'git update-index' considered plumbing, not changed
Definitely.
> + * 'git revert' deprecated in favour of 'git cherry-pick --revert'
I think I would make it "-R, --reverse", since it really is analagous to
"git diff -R".
> + * 'git undo' would do what 'git checkout HEAD --' does now
This is an awful name, IMHO. It doesn't point out _what_ you're undoing,
so it leaves me with the feeling that you can undo arbitrary things.
I think the name needs to be considered along with related operations.
So think of us as having three "spots": the HEAD (H), the "stage"[1] (S),
and the working tree (W). And we want commands for moving content
between them. Now we have:
W->S: add
H->S: reset --
S->W: checkout --
S->H: commit (no paths)
And if you want to include things that jump the staging area:
W->H: commit (paths or -a)
H->W: checkout HEAD --
So I think with your stage/unstage, we have:
W->S: stage
H->S: unstage
S->W: ?
S->H: commit (no paths)
W->H: commit (paths or -a)
H->W: ?
So I think we can note something: movement commands are related based on
their _destination_. So since both of the missing ones impact the
working tree, they should have a related name.
But do note the difference between "stage vs unstage" as opposed to
"commit versus commit -a". I think this is because the stage sits in the
middle. So it is mentally "which direction are changes coming from" and
not "how _far_ are changes coming from".
So by that rationale, we should have a single command which says "put
stuff in the working tree", with a flag for "from HEAD" versus "from the
staging area." And that's what we have right now with "git checkout".
The real problem with it is that it is an overload of checkout's other
behavior of switching branches.
So what I am saying is "git undo" _must_ support both "put index content
into working tree" as well as "put HEAD content into working tree", or
it will be a step backwards in consistency.
So I guess that doesn't really suggest a name. But "undo" is awful. ;P
Side note: there are actually _other_ places you might want to move
content. Like a stash. So now you can think of it as:
stash
^ ^
/ \
/ \
v v
HEAD <--> stage <--> working tree
So maybe we just need a "git content" command. And then you can "git
content --from=HEAD --to=tree <paths>" or "git content --from=tree
--to=stash", with all equally supporting "--interactive". And of course
I am kidding, because typing that would be awful. But I think
conceptually, it makes sense. To me, anyway.
> + * 'git branch --switch' : alternative to checkout
Blech. I think switching branches is the one thing that checkout does
unconfusedly. And this is much more typing. Not to mention that So I
would rather see "git switch" if checkout is somehow unpalatable.
But I don't know that it is. This seems like an attempt to say "branch
operations should all be part of 'git branch'". But checkout isn't
necessarily a branch operation. Consider detaching HEAD to a tag. Should
it be "git tag --switch"?
> + * 'git push --matching' does what 'git push' does today (without
> + explicit configuration)
I think this is reasonable even without other changes, just to override
any configuration.
> + * 'git push' with no ref args and no 'push =' configuration does
> + what:
> + 'git push origin $(git symbolic-ref HEAD | sed "s!refs/heads/!!")'
> + does today. ie, it only pushes the current branch.
> + If a branch was defined in branch.<name>.push, push to that ref
> + instead of the matching one. If there is no matching ref, and
> + there is a branch.<name>.merge, push back there.
There was a thread between me and Junio some months ago that touched on
this. I don't remember all of the arguments, but it was resolved to keep
the current behavior. Any proposal along these lines should at least
revisit and respond to those arguments.
> + * 'git push' to checked out branch of non-bare repository not
> + allowed without special configuration. Configuration available
I have this patch done and sitting in my repo, but I need to add the
"without special configuration" bit and add tests and docs.
> +Informational
> +-------------
> +
> + * 'git branch' should default to '--color=auto -v'
This should at least be configurable (even if it defaults to "on"). "-v"
is more expensive, and not always wanted.
I, for one, just use "git branch" to get the current branch. I don't
know of a more obvious way to ask for it (and please don't mention an
ever-changing bash prompt).
> + * 'git tag -l' should show more information
I remember somebody talking about this, but not the details. Which
information?
> + * 'git am -3' the default; with global option to make it not the
> + default for those that prefer the speed of -2
I would prefer that personally. I think Linus has been very reasonable
in the past about recognizing that his workflow and speed requirements
aren't always typical, and being willing to accept setting a
configuration flag in those cases. So I think if he ack'd such a patch,
nobody else would complain.
> + * 'git export' command that does what
> + 'git archive --format=tar --prefix=dir | tar x' does now
I agree, if you mean "does what ... does now" means "looks to the user
like ... is happening". This is much more sanely done using
git-checkout-index (though somebody suggested "remote export", which
would need to use tar itself).
> + * 'git init --server' (or similar) should do everything required for
> + exporting::
> +----
> +chmod -R a+rX
> +touch git-daemon-export-ok
> +git gc
> +git update-server-info
> +chmod u+x .git/hooks/post-update
> +git config core.sharedrepository=1
> +----
But not all of those things are necessarily related, and some of them
have security implications. I would hate to get a bug report like "I
used --server because I wanted to share my content via dumb http, but my
repo was p0wned because of too-loose group permissions."
-Peff
^ permalink raw reply
* Re: [PATCH] Documentation: add a planning document for the next CLI revamp
From: Jeff King @ 2008-10-31 0:34 UTC (permalink / raw)
To: Pierre Habouzit; +Cc: Sam Vilain, git, Sam Vilain
In-Reply-To: <20081030132453.GB24098@artemis.corp>
On Thu, Oct 30, 2008 at 02:24:53PM +0100, Pierre Habouzit wrote:
> > + * 'git stage' would do what 'git add' does now.
> -> git stage -i/-p shall do what git add -i/-p does.
Yes, and that is obviously easy.
> > + * 'git unstage' would do what 'git reset --' does now
> -> likely we need a git unstage -i/-p to interactively unstage some
> bits.
Agreed, though this is a bit harder. But I think this should go hand in
hand with "git stash -i" and "git stash apply -i" (as I mentioned in my
other mail in this thread).
-Peff
^ permalink raw reply
* Re: [RFC] gitweb: add 'historyfollow' view that follows renames
From: Jakub Narebski @ 2008-10-31 1:19 UTC (permalink / raw)
To: Blucher, Guy; +Cc: ming.m.lin, robert.moore, git
In-Reply-To: <054F21930D24A0428E5B4588462C7AED0149B4B8@ednex512.dsto.defence.gov.au>
I'm sorry for the delay in reviewing this patch...
On Mon, 27 Oct 2008, Huy Blucher wrote:
[Please try do not lose attributions...]
> > >
> > > What should we add to automatically get all file history?
>
> > While the 'commitdiff' view would, in default gitweb configuration,
> > contain information about file renames, currently 'history' view does
> > not support '--follow' option to git-log. It wouldn't be too hard to
> > add it, but it just wasn't done (well, add to this the fact that
> > --follow works only for simple cases).
>
> We also ran up against this issue because renaming of files in our
> project is a useful bit of information while browsing file history.
>
> I hacked gitweb to add a 'historyfollow' viewing option in addition to
> the 'history' option. Yes, '--follow' is expensive so I didn't just
> make it the default 'history' behaviour.
I would prefer if instead of adding new 'historyfollow' action, which
goes against stated in TODO goal of uniquifying log-like views handling,
the patch added support for '--follow' as extra option to 'history'
view (i.e. a=history;opt=--follow)... on the other hand 'historyfollow'
(or simply 'follow') can be used in pure path_info gitweb URL... Hmm...
>
> The only problem with doing it was that parse_commits in gitweb.perl
> uses git rev-list which doesn't support the '--follow' option like
> git-log does. A bit of hacking to use 'git log --pretty=raw -z' to make
> the output look close to that from rev-list means only minor
> shoe-horning is required (perhaps it would be better to make rev-list
> understand --follow though?).
Either that, or use --pretty=format:<sth> which mimics current use of
"git-rev-list <opts>" output in parse_commits exactly.
And either move parse_commits to use git-log, change git-rev-parse to
understand '--follow', or make parse_commits use git-log with --follow,
git-rev-list otherwise.
>
> I wasn't originally prepared to publish the work here because I don't
> really think it's the best solution. But considering it's come up... I
> include a patch inline against gitweb.perl from v1.6.0.3 that implements
> a 'historyfollow' view.
RFC (usually marked [RFC/PATCH]) patches are good because they allow
others to test and comment on your solution: early review, better to
spot bugs etc. earlier.
>
> Feel free to do with it what you will. It would need some substantial
> tidying up by someone who knows much more about perl than me :)
>
> We use it such that anywhere a 'history' link is provided a
> 'historyfollow' link is also provided next to it - This patch doesn't
> implement that bit though.
>
> Hope it helps.
>
> Cheers,
> Guy.
It would be nice though if such [RFC/PATCH] followed guidelines from
SubmittingPatches on commit messages...
>
> ---
Diffstat?
>
> --- a/gitweb/gitweb.perl
> +++ b/gitweb/gitweb.perl
> @@ -478,6 +478,7 @@ my %actions = (
> "forks" => \&git_forks,
> "heads" => \&git_heads,
> "history" => \&git_history,
> + "historyfollow" => \&git_history_follow,
> "log" => \&git_log,
> "rss" => \&git_rss,
> "atom" => \&git_atom,
> @@ -2311,25 +2312,39 @@ sub parse_commit {
> }
>
> sub parse_commits {
> - my ($commit_id, $maxcount, $skip, $filename, @args) = @_;
> + my ($commit_id, $maxcount, $skip, $mode, $filename, @args) = @_;
Can't you simply pass '--follow' or 'follow' in @args instead of
changing the signature of parse_commits?
> my @cos;
>
> $maxcount ||= 1;
> $skip ||= 0;
>
> local $/ = "\0";
> + # The '--max-count' argument is not available when doing a
> + # '--follow' to 'git log'
> + my $count_arg = ("--max-count=" . $maxcount) ;
> + if (defined $mode && $mode eq "--follow") {
> + $count_arg = "--follow" ;
> + }
I don't understand. Do you mean that
$ git log --max-count=<n> --follow <rev> -- <path>
doesn't work as expected? Hmmm... true, it doesn't work.
Then it is certainly a _BUG_ in git!
>
> - open my $fd, "-|", git_cmd(), "rev-list",
> - "--header",
> +
> + open my $fd, "-|", git_cmd(), "log",
> + "-z",
> + "--pretty=raw",
> @args,
> - ("--max-count=" . $maxcount),
> + ($count_arg ? ($count_arg ) : ()),
Whitespace damage (here visible).
> ("--skip=" . $skip),
> @extra_options,
> $commit_id,
> "--",
> ($filename ? ($filename) : ())
> - or die_error(500, "Open git-rev-list failed");
> + or die_error(500, "Open git-log failed");
> while (my $line = <$fd>) {
> + # Need to put a delimiter on the end of output
> + # 'git-log -z' doesn't put one before EOF like rev-list
> does
> + $line = ($line . '\0');
Doesn't it work if you don't add the above line?
> + # Need to strip the word commit from the start so it
> + # looks like rev-list output
> + $line =~ s/^commit // ;
> my %co = parse_commit_text($line);
Perhaps we should update parse_commit_text instead... or add an option
like parse_commit_text($line, -format=>'log'), or something like that.
> push @cos, \%co;
> }
> @@ -5363,6 +5378,13 @@ sub git_commitdiff_plain {
> }
>
> sub git_history {
> + my $mode = shift || '';
> + my $history_call = "history";
> +
> + if ($mode eq "--follow") {
> + $history_call .= "historyfollow" ;
> + }
> +
I don't quite like this solution...
If '--follow' was passed through @extra_options ('opt') parameter, then
it should be re-used in links thanks to href(..., -replay=>1).
> if (!defined $hash_base) {
> $hash_base = git_get_head_hash($project);
> }
> @@ -5377,7 +5399,7 @@ sub git_history {
> my $limit = sprintf("--max-count=%i", (100 * ($page+1)));
>
> my @commitlist = parse_commits($hash_base, 101, (100 * $page),
> - $file_name, "--full-history")
> + $mode, $file_name,
> "--full-history")
Word wrapped (not only here).
> or die_error(404, "No such file or directory on given
> branch");
>
> if (!defined $hash && defined $file_name) {
> @@ -5398,7 +5420,7 @@ sub git_history {
> my $paging_nav = '';
> if ($page > 0) {
> $paging_nav .=
> - $cgi->a({-href => href(action=>"history",
> hash=>$hash, hash_base=>$hash_base,
> + $cgi->a({-href => href(action=>"$history_call",
> hash=>$hash, hash_base=>$hash_base,
> file_name=>$file_name)},
> "first");
I would add opts=>[@extra_options] instead of changing action=>"history"
to action=>$history_call (the quotes around variable are not needed).
> $paging_nav .= " ⋅ " .
> @@ -5429,6 +5451,11 @@ sub git_history {
> git_footer_html();
> }
>
> +sub git_history_follow {
> + git_history('--follow');
> +}
> +
> +
> sub git_search {
> gitweb_check_feature('search') or die_error(403, "Search is
> disabled");
> if (!defined $searchtext) {
> @@ -5469,7 +5496,7 @@ sub git_search {
> $greptype = "--committer=";
> }
> $greptype .= $searchtext;
> - my @commitlist = parse_commits($hash, 101, (100 *
> $page), undef,
> + my @commitlist = parse_commits($hash, 101, (100 *
> $page), undef, undef,
> $greptype,
> '--regexp-ignore-case',
> $search_use_regexp ?
> '--extended-regexp' : '--fixed-strings');
>
> @@ -5737,7 +5764,7 @@ sub git_feed {
>
> # log/feed of current (HEAD) branch, log of given branch,
> history of file/directory
> my $head = $hash || 'HEAD';
> - my @commitlist = parse_commits($head, 150, 0, $file_name);
> + my @commitlist = parse_commits($head, 150, 0, undef,
> $file_name);
>
> my %latest_commit;
> my %latest_date;
> ---
What I would like to see is the link in the bottom of action bar
(navbar) or just below it, which would list 'follow' as one of possible
'history' view formats (just like '--no-merges' or '--first-parent'
should be).
--
Jakub Narebski
Poland
^ permalink raw reply
* why not TortoiseGit
From: Li Frank-B20596 @ 2008-10-31 1:44 UTC (permalink / raw)
To: git
There are TortoiseCVS, TortoiseSVN, TortoiseBzr, TortoiseHg
Why not ToroiseGit
best regards
Frank Li
^ permalink raw reply
* Re: why not TortoiseGit
From: Jakub Narebski @ 2008-10-31 1:59 UTC (permalink / raw)
To: Li Frank-B20596; +Cc: git
In-Reply-To: <7FD1F85C96D70C4A89DA1DF7667EAE96125890@zch01exm23.fsl.freescale.net>
"Li Frank-B20596" <Frank.Li@freescale.com> writes:
> There are TortoiseCVS, TortoiseSVN, TortoiseBzr, TortoiseHg
> Why not ToroiseGit?
Because GitCheetah
--
Jakub Narebski
Poland
ShadeHawk on #git
^ permalink raw reply
* RE: why not TortoiseGit
From: Li Frank-B20596 @ 2008-10-31 2:02 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git
In-Reply-To: <m3bpx1h6e6.fsf@localhost.localdomain>
GitCheetah seem only GitGui Here and GitBash Here.
TortoiseXXX can show log, diff, commit change ...at explore menu.
Best regards
Frank Li
-----Original Message-----
From: Jakub Narebski [mailto:jnareb@gmail.com]
Sent: Friday, October 31, 2008 9:59 AM
To: Li Frank-B20596
Cc: git@vger.kernel.org
Subject: Re: why not TortoiseGit
"Li Frank-B20596" <Frank.Li@freescale.com> writes:
> There are TortoiseCVS, TortoiseSVN, TortoiseBzr, TortoiseHg Why not
> ToroiseGit?
Because GitCheetah
--
Jakub Narebski
Poland
ShadeHawk on #git
^ permalink raw reply
* Re: why not TortoiseGit
From: George Shammas @ 2008-10-31 3:07 UTC (permalink / raw)
To: Li Frank-B20596; +Cc: Jakub Narebski, git
In-Reply-To: <7FD1F85C96D70C4A89DA1DF7667EAE9612589D@zch01exm23.fsl.freescale.net>
The very very blunt answer is, TortoiseGit doesn't exist because no
one has created it. And this may partly be do to the fact that git is
more powerful then the programs who have it, so its a bigger project
to make it stupid proof.
-G
On Thu, Oct 30, 2008 at 7:02 PM, Li Frank-B20596 <Frank.Li@freescale.com> wrote:
> GitCheetah seem only GitGui Here and GitBash Here.
> TortoiseXXX can show log, diff, commit change ...at explore menu.
>
> Best regards
> Frank Li
>
> -----Original Message-----
> From: Jakub Narebski [mailto:jnareb@gmail.com]
> Sent: Friday, October 31, 2008 9:59 AM
> To: Li Frank-B20596
> Cc: git@vger.kernel.org
> Subject: Re: why not TortoiseGit
>
> "Li Frank-B20596" <Frank.Li@freescale.com> writes:
>
>> There are TortoiseCVS, TortoiseSVN, TortoiseBzr, TortoiseHg Why not
>> ToroiseGit?
>
> Because GitCheetah
>
> --
> Jakub Narebski
> Poland
> ShadeHawk on #git
> --
> 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: why not TortoiseGit
From: Miles Bader @ 2008-10-31 3:53 UTC (permalink / raw)
To: George Shammas; +Cc: Li Frank-B20596, Jakub Narebski, git
In-Reply-To: <dfdaadcd0810302007q658d74c4wfb278999ea10885d@mail.gmail.com>
"George Shammas" <georgyo@gmail.com> writes:
> The very very blunt answer is, TortoiseGit doesn't exist because no
> one has created it. And this may partly be do to the fact that git is
> more powerful then the programs who have it, so its a bigger project
> to make it stupid proof.
... and from what I've seen of tortoise* users, "stupid proof" is very,
very, very, necessary...
-Miles
--
Immortality, n. A toy which people cry for, And on their knees apply for,
Dispute, contend and lie for, And if allowed Would be right proud
Eternally to die for.
^ permalink raw reply
* [PATCH] git-svn: change dashed git-commit-tree to git commit-tree
From: Deskin Miller @ 2008-10-31 4:10 UTC (permalink / raw)
To: git; +Cc: normalperson, gitster
Signed-off-by: Deskin Miller <deskinm@umich.edu>
---
Once again I'm using a copy of git-svn.perl directly, and this fails to exec.
I looked at it more closely and it fails because git binary calls setup_path,
which puts the libexec path into $PATH; of course, this doesn't happen when
git-svn is called directly.
git-svn.perl | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/git-svn.perl b/git-svn.perl
index 2e68c68..56238da 100755
--- a/git-svn.perl
+++ b/git-svn.perl
@@ -2202,7 +2202,7 @@ sub do_git_commit {
}
die "Tree is not a valid sha1: $tree\n" if $tree !~ /^$::sha1$/o;
- my @exec = ('git-commit-tree', $tree);
+ my @exec = ('git', 'commit-tree', $tree);
foreach ($self->get_commit_parents($log_entry)) {
push @exec, '-p', $_;
}
--
1.6.0.3.515.g304f
^ permalink raw reply related
* Re: [PATCH] t4030: Don't use echo -n
From: Brian Gernhardt @ 2008-10-31 5:02 UTC (permalink / raw)
To: Ian Hilt; +Cc: Git Mailing List
In-Reply-To: <20081030235215.GB18221@sys-0.hiltweb.site>
On Oct 30, 2008, at 7:52 PM, Ian Hilt wrote:
> On Thu, Oct 30, 2008 at 06:12:56PM -0400, Brian Gernhardt wrote:
>> Signed-off-by: Brian Gernhardt <benji@silverinsanity.com>
>
> No commit message???
>>
"Don't use echo -n" seemed simple enough to me, as it's the only thing
it does. And the reason is that echo -n isn't portable, as has been
determined previously in git. I'll update this and use the better
replacement "printf" anyway.
> This doesn't apply for me. My tip is up-to-date, but it doesn't
> even have
> this file it t/.
This is based on next and is for a file that isn't in master.
~~ Brian
^ permalink raw reply
* [PATCH] Avoid using non-portable `echo -n` in tests.
From: Brian Gernhardt @ 2008-10-31 5:09 UTC (permalink / raw)
To: Git List; +Cc: Shawn O Pearce
In-Reply-To: <8A4A84EC-51F7-4038-957C-CCA5C00E5977@silverinsanity.com>
Not all /bin/sh have a builtin echo that recognizes -n. Using printf
is far more portable.
Discovered on OS X 10.5.5 in t4030-diff-textconv.sh and changed in all
the test scripts.
Signed-off-by: Brian Gernhardt <benji@silverinsanity.com>
---
t/t2005-checkout-index-symlinks.sh | 2 +-
t/t2102-update-index-symlinks.sh | 4 ++--
t/t4030-diff-textconv.sh | 2 +-
t/t6025-merge-symlinks.sh | 4 ++--
t/t9400-git-cvsserver-server.sh | 2 +-
5 files changed, 7 insertions(+), 7 deletions(-)
diff --git a/t/t2005-checkout-index-symlinks.sh b/t/t2005-checkout-index-symlinks.sh
index ed12c4d..9fa5610 100755
--- a/t/t2005-checkout-index-symlinks.sh
+++ b/t/t2005-checkout-index-symlinks.sh
@@ -13,7 +13,7 @@ file if core.symlinks is false.'
test_expect_success \
'preparation' '
git config core.symlinks false &&
-l=$(echo -n file | git hash-object -t blob -w --stdin) &&
+l=$(printf file | git hash-object -t blob -w --stdin) &&
echo "120000 $l symlink" | git update-index --index-info'
test_expect_success \
diff --git a/t/t2102-update-index-symlinks.sh b/t/t2102-update-index-symlinks.sh
index f195aef..1ed44ee 100755
--- a/t/t2102-update-index-symlinks.sh
+++ b/t/t2102-update-index-symlinks.sh
@@ -13,12 +13,12 @@ even if a plain file is in the working tree if core.symlinks is false.'
test_expect_success \
'preparation' '
git config core.symlinks false &&
-l=$(echo -n file | git hash-object -t blob -w --stdin) &&
+l=$(printf file | git hash-object -t blob -w --stdin) &&
echo "120000 $l symlink" | git update-index --index-info'
test_expect_success \
'modify the symbolic link' '
-echo -n new-file > symlink &&
+printf new-file > symlink &&
git update-index symlink'
test_expect_success \
diff --git a/t/t4030-diff-textconv.sh b/t/t4030-diff-textconv.sh
index 3945731..a235955 100755
--- a/t/t4030-diff-textconv.sh
+++ b/t/t4030-diff-textconv.sh
@@ -105,7 +105,7 @@ index ad8b3d2..67be421
EOF
# make a symlink the hard way that works on symlink-challenged file systems
test_expect_success 'textconv does not act on symlinks' '
- echo -n frotz > file &&
+ printf frotz > file &&
git add file &&
git ls-files -s | sed -e s/100644/120000/ |
git update-index --index-info &&
diff --git a/t/t6025-merge-symlinks.sh b/t/t6025-merge-symlinks.sh
index 53892a5..433c4de 100755
--- a/t/t6025-merge-symlinks.sh
+++ b/t/t6025-merge-symlinks.sh
@@ -18,11 +18,11 @@ git add file &&
git commit -m initial &&
git branch b-symlink &&
git branch b-file &&
-l=$(echo -n file | git hash-object -t blob -w --stdin) &&
+l=$(printf file | git hash-object -t blob -w --stdin) &&
echo "120000 $l symlink" | git update-index --index-info &&
git commit -m master &&
git checkout b-symlink &&
-l=$(echo -n file-different | git hash-object -t blob -w --stdin) &&
+l=$(printf file-different | git hash-object -t blob -w --stdin) &&
echo "120000 $l symlink" | git update-index --index-info &&
git commit -m b-symlink &&
git checkout b-file &&
diff --git a/t/t9400-git-cvsserver-server.sh b/t/t9400-git-cvsserver-server.sh
index c1850d2..f6a2dbd 100755
--- a/t/t9400-git-cvsserver-server.sh
+++ b/t/t9400-git-cvsserver-server.sh
@@ -424,7 +424,7 @@ cd "$WORKDIR"
test_expect_success 'cvs update (-p)' '
touch really-empty &&
echo Line 1 > no-lf &&
- echo -n Line 2 >> no-lf &&
+ printf Line 2 >> no-lf &&
git add really-empty no-lf &&
git commit -q -m "Update -p test" &&
git push gitcvs.git >/dev/null &&
--
1.6.0.3.757.g1e5a4
^ permalink raw reply related
* Re: [PATCH 1/7] Documentation: do not use regexp in refspec descriptions
From: Junio C Hamano @ 2008-10-31 5:35 UTC (permalink / raw)
To: Anders Melchiorsen; +Cc: git, gitster
In-Reply-To: <1225311945-17100-2-git-send-email-mail@cup.kalibalik.dk>
Anders Melchiorsen <mail@cup.kalibalik.dk> writes:
> The refspec format description was a mix of regexp and BNF, making it
> very difficult to read.
>
> The syntax is now easier to read, though wrong: all parts of the
> refspec are actually optional.
It probably is easier to read, but strictly speaking it is not wrong. The
two parts, <src> and <dst>, _always_ exist, even though either or both of
them can be an empty string.
> diff --git a/Documentation/git-push.txt b/Documentation/git-push.txt
> index 6150b1b..df99c0b 100644
> --- a/Documentation/git-push.txt
> +++ b/Documentation/git-push.txt
> @@ -32,7 +32,7 @@ OPTIONS
>
> <refspec>...::
> The canonical format of a <refspec> parameter is
> - `+?<src>:<dst>`; that is, an optional plus `{plus}`, followed
> + `[+]<src>:<dst>`; that is, an optional plus `{plus}`, followed
> by the source ref, followed by a colon `:`, followed by
> the destination ref.
I am wondering if it would be clearer and easier to understand if we just
said:
The canonical format of a <refspec> parameter is
an optional plus `{plus}`, followed by the source ref,
followed by a colon `:`, followed by the destination ref.
Find various forms of refspecs in examples section.
^ permalink raw reply
* Re: [PATCH 3/7] Documentation: rework SHA1 description in git push
From: Junio C Hamano @ 2008-10-31 5:36 UTC (permalink / raw)
To: Anders Melchiorsen; +Cc: git
In-Reply-To: <1225311945-17100-4-git-send-email-mail@cup.kalibalik.dk>
Anders Melchiorsen <mail@cup.kalibalik.dk> writes:
> Get rid of a double pair of parentheses. The arbitrary SHA1 is a
> special case, so it can be postponed a bit.
Hmmm...
Strictly speaking, arbitrary SHA-1 is the general case, and branch name is
a special case of it, but in practice, branch name is the most frequently
used form, and that is why it has the short-hand convention that allows it
to to be pushed to the same name. I agree with the outcome of this patch
(except for one point I'll mention shortly) because I think it is a good
idea to talk about most frequently used form first, not because "branch"
is the general case. IOW, the proposed commit log message is wrong.
> Also mention HEAD, which is possibly the most useful SHA1 in this
> situation.
HEAD is indeed useful, but it falls into the special case of "branch
name", not "arbitrary SHA-1 expression". This distinction is important
because you can push "HEAD" without colon and it will act as if you said
master:master (or whatever branch you are currently on). This is already
described in the existing doc:
The local ref that matches <src> is used
to fast forward the remote ref that matches <dst> (or, if no <dst> was
specified, the same ref that <src> referred to locally).
but I agree that it is unnecessarily hard to understand, because the
document tries to describe the general case first and then relies on the
user to understand that "ref <src> referred to locally" means "branch
name". We should make this part more explicit.
With that in mind, I have two paragraphs to replace the parts your patch
touches as a counterproposal.
> diff --git a/Documentation/git-push.txt b/Documentation/git-push.txt
> index 02c7dae..fb9fb97 100644
> --- a/Documentation/git-push.txt
> +++ b/Documentation/git-push.txt
> @@ -38,9 +38,7 @@ OPTIONS
> by the source ref, followed by a colon `:`, followed by
> the destination ref.
> +
> -The <src> side represents the source branch (or arbitrary
> -"SHA1 expression", such as `master~4` (four parents before the
> -tip of `master` branch); see linkgit:git-rev-parse[1]) that you
> +The <src> side represents the source branch that you
> want to push. The <dst> side represents the destination location.
The <src> is often the name of the branch you would want to push, but it
can be any arbitrary "SHA-1 expression", such as `master~4` (four parents
before the tip of `master` branch -- see linkgit:git-rev-parse[1]), or
`HEAD` (the tip of the current branch). The <dst> tells which ref on the
remote side is updated with this push.
The object referenced by <src> is used to fast forward the ref <dst> on
the remote side. You can omit <dst> to update the same ref on the remote
side as <src> (<src> is often the name of a branch you push, and often you
push to the same branch on the remote side; `git push HEAD` is a handy way
to push only the current branch to the remote side under the same name).
If the optional leading plus `{plus}` is used, the remote ref is updated
even if it does not result in a fast forward update.
> @@ -193,6 +195,10 @@ git push origin master::
> with it. If `master` did not exist remotely, it would be
> created.
>
> +git push origin HEAD:master::
> + Push the current head to the remote ref matching `master` in
> + the `origin` repository.
> +
Additional example is good, but you would want to tell readers that this
would be useful when your current branch is _not_ 'master'.
^ permalink raw reply
* Re: [PATCH] Documentation: add a planning document for the next CLI revamp
From: Sam Vilain @ 2008-10-31 6:40 UTC (permalink / raw)
To: Jeff King
Cc: Sam Vilain, git, Johannes Schindelin, Scott Chacon,
Tom Preston-Werner, J.H., Christian Couder, Kai Blin
In-Reply-To: <20081031003154.GA5745@sigill.intra.peff.net>
On Thu, 2008-10-30 at 20:31 -0400, Jeff King wrote:
> > Some suggestions, which have been briefly scanned over by some of the
> > (remaining) GitTogether attendees. Please keep it constructive! :)
> Thanks for putting this together.
No problem! Thanks for responding. I've been amazed that it seems to
have been largely taken well :) But there are still very important
changes required.
> > + * 'git status' would encourage the user to use
> > + 'git diff --staged' to see staged changes as a patch
>
> I notice the commit template message getting longer and longer. Maybe it
> is time for status.verbosetemplate (which could default to true, I just
> want to be able to turn it off).
Right. We'll have to work through that when we look at how 'git status'
output is displayed. There may be some people who parse the existing
output, but they should get to read the release notes about the proper
ways to do that. I think the whole output could do with a shake-up.
> > + * 'git undo' would do what 'git checkout HEAD --' does now
> This is an awful name, IMHO. It doesn't point out _what_ you're undoing,
As others have said, yes.
> So I think with your stage/unstage, we have:
>
> W->S: stage
> H->S: unstage
> S->W: ?
> S->H: commit (no paths)
> W->H: commit (paths or -a)
> H->W: ?
>
> So I think we can note something: movement commands are related based on
> their _destination_. So since both of the missing ones impact the
> working tree, they should have a related name.
An interesting observation.
I still think it's OK to use 'git revert-files' for this; it just seems
so long. Switches could specify where to and from.
> Side note: there are actually _other_ places you might want to move
> content. Like a stash. So now you can think of it as:
>
> stash
> ^ ^
> / \
> / \
> v v
> HEAD <--> stage <--> working tree
>
> So maybe we just need a "git content" command. And then you can "git
> content --from=HEAD --to=tree <paths>" or "git content --from=tree
> --to=stash", with all equally supporting "--interactive". And of course
> I am kidding, because typing that would be awful. But I think
> conceptually, it makes sense. To me, anyway.
Again interesting, you could look at the stash as a whole bunch of
staged commits yet to happen. Of course, adding a file when the version
in HEAD doesn't match the version in the base of the stash is a bit
insane, so should probably be an error.
I'll have a ponder over this and whether there is a simple word for this
all.
> > + * 'git branch --switch' : alternative to checkout
>
> Blech. I think switching branches is the one thing that checkout does
> unconfusedly. And this is much more typing. Not to mention that So I
> would rather see "git switch" if checkout is somehow unpalatable.
>
> But I don't know that it is. This seems like an attempt to say "branch
> operations should all be part of 'git branch'". But checkout isn't
> necessarily a branch operation. Consider detaching HEAD to a tag. Should
> it be "git tag --switch"?
You're right with all that. I don't think that it is necessarily wrong
to have two ways to get at functionality, depending on whether you start
with the noun or the verb first; so long as it doesn't introduce
confusion. And if anything, I think --switch is wrong; --checkout is
probably more consistent.
I think I might have to mark this one as [maybe], and make it --checkout
- as you say, it would need to go on all the other commands that are
nouns and able to be checked out to be consistent. Let's see how that
looks in round 2.
> > + * 'git push --matching' does what 'git push' does today (without
> > + explicit configuration)
>
> I think this is reasonable even without other changes, just to override
> any configuration.
Excellent, I have another vote towards this push sanity! :)
> > + * 'git push' with no ref args and no 'push =' configuration does
> > + what:
> > + 'git push origin $(git symbolic-ref HEAD | sed "s!refs/heads/!!")'
> > + does today. ie, it only pushes the current branch.
> > + If a branch was defined in branch.<name>.push, push to that ref
> > + instead of the matching one. If there is no matching ref, and
> > + there is a branch.<name>.merge, push back there.
>
> There was a thread between me and Junio some months ago that touched on
> this. I don't remember all of the arguments, but it was resolved to keep
> the current behavior. Any proposal along these lines should at least
> revisit and respond to those arguments.
Right. So, before round 2, I'll read and attempt to summarise that
thread - assuming I can find it! :)
> > + * 'git push' to checked out branch of non-bare repository not
> > + allowed without special configuration. Configuration available
> I have this patch done and sitting in my repo, but I need to add the
> "without special configuration" bit and add tests and docs.
Looking forward to that! Thanks.
> > + * 'git branch' should default to '--color=auto -v'
> This should at least be configurable (even if it defaults to "on"). "-v"
> is more expensive, and not always wanted.
>
> I, for one, just use "git branch" to get the current branch. I don't
> know of a more obvious way to ask for it (and please don't mention an
> ever-changing bash prompt).
What's wrong with 'git symbolic-ref HEAD' ? *ducks*
Of course 'git branch -q' would then be the quick version, or 'git
br' (after git config --global alias.br 'branch -q')
Another command people often want is 'git info' to tell them stuff like
they might get from 'git status' or 'git remote' but without all the
file details...
> > + * 'git tag -l' should show more information
>
> I remember somebody talking about this, but not the details. Which
> information?
Oh, good point. Basically the same stuff that 'git branch -v' shows; in
any case, its behaviour should be relatively consistent compared to 'git
branch'.
> > + * 'git init --server' (or similar) should do everything required for
> > + exporting::
> > +----
> > +chmod -R a+rX
> > +touch git-daemon-export-ok
> > +git gc
> > +git update-server-info
> > +chmod u+x .git/hooks/post-update
> > +git config core.sharedrepository=1
> > +----
>
> But not all of those things are necessarily related, and some of them
> have security implications. I would hate to get a bug report like "I
> used --server because I wanted to share my content via dumb http, but my
> repo was p0wned because of too-loose group permissions."
ok. That should come down to the detail of how '--server' is specified,
I think. I'll expand on that during round 2.
Sam.
^ permalink raw reply
* Re: [PATCH] Documentation: add a planning document for the next CLI revamp
From: Sam Vilain @ 2008-10-31 6:51 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git
In-Reply-To: <gedhh6$urq$1@ger.gmane.org>
On Fri, 2008-10-31 at 00:55 +0100, Jakub Narebski wrote:
> > involves typing the branch name twice. I end up writing things like:
> >
> > git checkout -b {,origin/}wr34251-do-something
>
> Can't you use currently
>
> git checkout --track origin/wr34251-do-something
Ah, that's a new feature. Still, I think it's poorly Huffman coded; far
too verbose.
But let's resume this discussion after I dig up the old thread about
pushing and pulling too... I think it makes sense to look at this as a
whole.
Cheers,
Sam.
^ permalink raw reply
* Re: [PATCH] Use find instead of perl in t5000 to get file modification time
From: Alex Riesen @ 2008-10-31 7:00 UTC (permalink / raw)
To: Sam Vilain; +Cc: Git Mailing List, Junio C Hamano, Jeff King, René Scharfe
In-Reply-To: <1225344554.10803.17.camel@maia.lan>
Sam Vilain, Thu, Oct 30, 2008 06:29:14 +0100:
> On Wed, 2008-10-29 at 11:38 +0100, Alex Riesen wrote:
> > I could not find what exactly does the ActiveState's Perl use for its stat
> > implementation (and honestly, have no motivation to look harder).
> > It seems to honor TZ, but the produced time does not seem to be either
> > local or GMT.
>
> See, the difference is that the perl is portable and your patch isn't.
ActiveState Perl on Windows is portable? To another windows, maybe.
> Can you at least reveal how far out the value printed by the perl
> fragment was from the expected value, and what your TZ offset is in
> seconds. It might be pointing to a deeper problem that could affect
> more than just this test case.
I tried TZ set to CET (my zone), GMT, and UTC. The difference was from
1200 sec to 3600.
^ permalink raw reply
* Re: [PATCH] Documentation: add a planning document for the next CLI revamp
From: Jakub Narebski @ 2008-10-31 7:36 UTC (permalink / raw)
To: Sam Vilain; +Cc: git, Nicolas Pitre
In-Reply-To: <1225435899.20883.25.camel@maia.lan>
Dnia piątek 31. października 2008 07:51, Sam Vilain napisał:
> On Fri, 2008-10-31 at 00:55 +0100, Jakub Narebski wrote:
> > > involves typing the branch name twice. I end up writing things like:
> > >
> > > git checkout -b {,origin/}wr34251-do-something
> >
> > Can't you use currently
> >
> > git checkout --track origin/wr34251-do-something
>
> Ah, that's a new feature. Still, I think it's poorly Huffman coded; far
> too verbose.
Well, either you have a little bit more verbose, or you have to have
some DWIM-mery, which (as usual with DWIM) can go wrong.
--
Jakub Narebski
Poland
^ permalink raw reply
* Re: A typesetting problem with git man pages
From: Teemu Likonen @ 2008-10-31 7:37 UTC (permalink / raw)
To: Jonas Fonseca; +Cc: git
In-Reply-To: <2c6b72b30810291235j554cc21dw4e3da4fdbfe633ee@mail.gmail.com>
Jonas Fonseca (2008-10-29 20:35 +0100) wrote:
> On Wed, Oct 29, 2008 at 20:16, Teemu Likonen <tlikonen@iki.fi> wrote:
>> Does anybody know why "man" prints those ".ft" commands? The
>> corresponding code in git-log.1 file is this:
>>
>> \&.ft C
>> [i18n]
>> commitencoding = ISO\-8859\-1
>> \&.ft
>>
>> Recently I upgraded my system from Debian 4.0 (Etch) to 5.0 (Lenny) and
>> it is possible that some tools which are related to compiling the man
>> pages are now newer versions.
>
> I had a similar problem after upgrading on Ubuntu and came up with a
> patch to optionally disable some of asciidoc.conf (commit
> 7f55cf451c9e7). Try putting DOCBOOK_XSL_172=Yes in your config.mak.
Alas, there are still problems - or at least I have. Let's look at the
"git checkout" manual page and its output in the "EXAMPLES" section:
$ git checkout master âfB(1)âfR
$ git checkout master~2 Makefile âfB(2)âfR
$ rm -f hello.c
$ git checkout hello.c âfB(3)âfR
â
âfB1. âfRswitch branch â
âfB2. âfRtake out a file out of other commit â
âfB3. âfRrestore hello.c from HEAD of current branch
If you have an unfortunate branch that is named hello.c, this step
would be confused as an instruction to switch to that branch. You
should instead write:
$ git checkout -- hello.c
â
.RE
2. After working in a wrong branch, switching to the correct branch
would be done using:
$ git checkout mytopic
The corresponding code in the git-checkout.txt file:
------------
$ git checkout master <1>
$ git checkout master~2 Makefile <2>
$ rm -f hello.c
$ git checkout hello.c <3>
------------
+
<1> switch branch
<2> take out a file out of other commit
<3> restore hello.c from HEAD of current branch
+
If you have an unfortunate branch that is named `hello.c`, this
step would be confused as an instruction to switch to that branch.
You should instead write:
+
------------
$ git checkout -- hello.c
------------
. After working in a wrong branch, switching to the correct
branch would be done using:
+
------------
$ git checkout mytopic
------------
^ permalink raw reply
* Re: [PATCH] Introduce receive.denyDeletes
From: Junio C Hamano @ 2008-10-31 8:04 UTC (permalink / raw)
To: Jan Krüger; +Cc: Shawn O. Pearce, git
In-Reply-To: <20081030194503.2f9ece1a@perceptron>
"Jan Krüger" <jk@jk.gs> writes:
> Can I then delete the branch afterwards without lots of juggling (in
> case the test fails due to a random other reason that the branch
> accidentally getting deleted by receive-pack)? I'd expect I'd have to
> save the exit code to a temporary variable and that's just as ugly.
Although I agree that your attempt to allow the test continue even when
this test fails is a very good practice, I personally do not find the
alternative you mention ugly at all. I actually find that "return 1"
uglier because it feels like it knows too much about how
test_expect_success is implemented.
^ permalink raw reply
* Re: [PATCH] Avoid using non-portable `echo -n` in tests.
From: Junio C Hamano @ 2008-10-31 8:15 UTC (permalink / raw)
To: Brian Gernhardt; +Cc: Git List, Shawn O Pearce
In-Reply-To: <1225429753-70109-1-git-send-email-benji@silverinsanity.com>
Brian Gernhardt <benji@silverinsanity.com> writes:
> Not all /bin/sh have a builtin echo that recognizes -n. Using printf
> is far more portable.
This is much better (minor nit: we do not care if echo is built-in or
/bin/echo); the point of t4030 is to produce an incomplete line ;-).
Will queue, thanks.
^ permalink raw reply
* Re: [PATCH] Documentation: add a planning document for the next CLI revamp
From: Pierre Habouzit @ 2008-10-31 8:20 UTC (permalink / raw)
To: Sam Vilain
Cc: Jeff King, Sam Vilain, git, Johannes Schindelin, Scott Chacon,
Tom Preston-Werner, J.H., Christian Couder, Kai Blin
In-Reply-To: <1225435238.20883.18.camel@maia.lan>
[-- Attachment #1: Type: text/plain, Size: 2655 bytes --]
On Fri, Oct 31, 2008 at 06:40:38AM +0000, Sam Vilain wrote:
> On Thu, 2008-10-30 at 20:31 -0400, Jeff King wrote:
> > > Some suggestions, which have been briefly scanned over by some of the
> > > (remaining) GitTogether attendees. Please keep it constructive! :)
> > Thanks for putting this together.
>
> No problem! Thanks for responding. I've been amazed that it seems to
> have been largely taken well :) But there are still very important
> changes required.
Well, most of it we discussed IRL, that helps tremendously ;)
> I still think it's OK to use 'git revert-files' for this; it just seems
> so long. Switches could specify where to and from.
Well the point is we will probably just deprecate git-revert and remove
it alltogether in git 2.6. At that time you will be able to define
git-revert as an alias to git cherry-pick -R if you're an old fart, or
git revert-files if you're an svn user ;)
But I see no convincing name that hasn't "revert" in them, hence will be
long :/
> Of course 'git branch -q' would then be the quick version, or 'git
> br' (after git config --global alias.br 'branch -q')
oh no, not -q please, -q is quiet, -h is help, -v is verbose. I mean
POSIX should define these. Do not give those switch any other kind of
sementics anymore, we've done that, and it hurts. -Q is fine with me
though.
> Another command people often want is 'git info' to tell them stuff like
> they might get from 'git status' or 'git remote' but without all the
> file details...
And to say to them if they're in the midle of a merge, of a rebase, an
am, on a detached, head, .... what is in the __git_ps1 of bash actually.
> > > + * 'git init --server' (or similar) should do everything required for
> > > + exporting::
> > > +----
> > > +chmod -R a+rX
> > > +touch git-daemon-export-ok
> > > +git gc
> > > +git update-server-info
> > > +chmod u+x .git/hooks/post-update
> > > +git config core.sharedrepository=1
> > > +----
> >
> > But not all of those things are necessarily related, and some of them
> > have security implications. I would hate to get a bug report like "I
> > used --server because I wanted to share my content via dumb http, but my
> > repo was p0wned because of too-loose group permissions."
>
> ok. That should come down to the detail of how '--server' is specified,
> I think. I'll expand on that during round 2.
What about git init --svn-like ? /me *ducks*
--
·O· Pierre Habouzit
··O madcoder@debian.org
OOO http://www.madism.org
[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Re: [PATCH] Avoid using non-portable `echo -n` in tests.
From: Junio C Hamano @ 2008-10-31 8:20 UTC (permalink / raw)
To: Brian Gernhardt; +Cc: Git List, Shawn O Pearce
In-Reply-To: <1225429753-70109-1-git-send-email-benji@silverinsanity.com>
Brian Gernhardt <benji@silverinsanity.com> writes:
> Not all /bin/sh have a builtin echo that recognizes -n. Using printf
> is far more portable.
>
> Discovered on OS X 10.5.5 in t4030-diff-textconv.sh and changed in all
> the test scripts.
I had an impression that OS X was BSDish. Wasn't "echo -n" a BSDism?
^ permalink raw reply
* Re: [PATCH] make git-filter-branch use parse-options.
From: Pierre Habouzit @ 2008-10-31 8:22 UTC (permalink / raw)
To: git; +Cc: pasky, srabbelier
In-Reply-To: <1225383538-23666-2-git-send-email-madcoder@debian.org>
[-- Attachment #1: Type: text/plain, Size: 456 bytes --]
Okay this patch prevents us to use rev-list options in fact, which is
broken I guess, since it prevents --not and a few similar arguments that
can make sense. Please do not apply, I'll try to rework the next patch
though since nobody complained, it's that it looks fine :p
--
·O· Pierre Habouzit
··O madcoder@debian.org
OOO http://www.madism.org
[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Re: A typesetting problem with git man pages
From: Teemu Likonen @ 2008-10-31 8:37 UTC (permalink / raw)
To: Jonas Fonseca; +Cc: git
In-Reply-To: <8763n9tduo.fsf@iki.fi>
Teemu Likonen (2008-10-31 09:37 +0200) wrote:
> Alas, there are still problems - or at least I have. Let's look at the
> "git checkout" manual page and its output in the "EXAMPLES" section:
>
>
> $ git checkout master âfB(1)âfR
> $ git checkout master~2 Makefile âfB(2)âfR
> $ rm -f hello.c
> $ git checkout hello.c âfB(3)âfR
> â
> âfB1. âfRswitch branch â
> âfB2. âfRtake out a file out of other commit â
> âfB3. âfRrestore hello.c from HEAD of current branch
This has been reported to Debian so perhaps the issue is
Debian-specific. I don't know. The bug was found in Debian git-core
package version 1:1.5.6-1.
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=490863
^ 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