* [PATCH] guilt doc: use literal paragraphs for example commands
From: Wu Fengguang @ 2008-12-18 11:39 UTC (permalink / raw)
To: Josef Jeff Sipek; +Cc: git@vger.kernel.org
Display example commands verbatim by indenting the paragraphs.
Signed-off-by: Wu Fengguang <fengguang.wu@intel.com>
---
Documentation/guilt-add.txt | 4 ++--
Documentation/guilt-delete.txt | 2 +-
Documentation/guilt-diff.txt | 2 +-
Documentation/guilt-help.txt | 4 ++--
Documentation/guilt-init.txt | 7 +++----
Documentation/guilt-new.txt | 6 +++---
Documentation/guilt-rebase.txt | 5 ++---
7 files changed, 14 insertions(+), 16 deletions(-)
--- guilt.orig/Documentation/guilt-add.txt
+++ guilt/Documentation/guilt-add.txt
@@ -23,8 +23,8 @@ EXAMPLES
Create and add a new file example.c
-$ touch example.c
-$ guilt-add example.c
+ $ touch example.c
+ $ guilt-add example.c
Author
------
--- guilt.orig/Documentation/guilt-delete.txt
+++ guilt/Documentation/guilt-delete.txt
@@ -25,7 +25,7 @@ EXAMPLES
--------
Delete a patch called 'foobar':
-$ guilt-delete foobar
+ $ guilt-delete foobar
Author
------
--- guilt.orig/Documentation/guilt-diff.txt
+++ guilt/Documentation/guilt-diff.txt
@@ -18,7 +18,7 @@ OPTIONS
-------
-z::
Output a interdiff against the top-most applied patch. This should
- produce the same diff as "guilt-new -f foo".
+ produce the same diff as "+guilt-new -f foo+".
<path>...::
Restrict diff output to a given set of files.
--- guilt.orig/Documentation/guilt-help.txt
+++ guilt/Documentation/guilt-help.txt
@@ -18,11 +18,11 @@ EXAMPLES
Open the guilt-status man page
-$ guilt-help status
+ $ guilt-help status
Open the guilt man page
-$ guilt-help
+ $ guilt-help
Author
------
--- guilt.orig/Documentation/guilt-init.txt
+++ guilt/Documentation/guilt-init.txt
@@ -17,13 +17,12 @@ EXAMPLES
--------
First, get a repository to work on. Here's one that we'll use as an example:
-$ git-clone git://git.kernel.org/pub/scm/linux/kernel/jsipek/guilt-hello.git
+ $ git-clone git://git.kernel.org/pub/scm/linux/kernel/jsipek/guilt-hello.git
Now, it initialize the patches directory using guilt's init command:
-$ cd hello
-
-$ guilt-init
+ $ cd hello
+ $ guilt-init
Author
------
--- guilt.orig/Documentation/guilt-new.txt
+++ guilt/Documentation/guilt-new.txt
@@ -42,16 +42,16 @@ EXAMPLES
Create a new patch called 'foobar':
-$ guilt-new foobar
+ $ guilt-new foobar
Create a patch called 'foo' and supply a patch description interactively:
-$ guilt-new -e foo
+ $ guilt-new -e foo
Create a patch called 'bar' with a provided patch description and sign off
on the patch:
-$ guilt-new -s -m patch-fu bar
+ $ guilt-new -s -m patch-fu bar
Author
------
--- guilt.orig/Documentation/guilt-rebase.txt
+++ guilt/Documentation/guilt-rebase.txt
@@ -24,9 +24,8 @@ EXAMPLES
Rebase current tree against Linus's 2.6 tree
-$ git-fetch git://git.kernel.org/pub/scm/linux/kernel/git/tovalds/linux-2.6.git
-
-$ guilt-rebase FETCH_HEAD
+ $ git-fetch git://git.kernel.org/pub/scm/linux/kernel/git/tovalds/linux-2.6.git
+ $ guilt-rebase FETCH_HEAD
Author
------
^ permalink raw reply
* [PATCH][RESEND] guilt: add option guilt.diffstat
From: Wu Fengguang @ 2008-12-18 11:26 UTC (permalink / raw)
To: Josef Jeff Sipek; +Cc: git@vger.kernel.org, Boyd Stephen Smith Jr.
In-Reply-To: <20081213131700.GA8649@localhost>
Introduce option guilt.diffstat so that we don't have to type
"guilt refresh --diffstat" in its full form every time.
Signed-off-by: Wu Fengguang <fengguang.wu@intel.com>
---
Jeff: This patch is against the latest guilt v0.32-rc1.
Documentation/guilt-refresh.txt | 10 ++++++++--
guilt | 9 ++++++++-
2 files changed, 16 insertions(+), 3 deletions(-)
--- guilt.orig/guilt
+++ guilt/guilt
@@ -646,7 +646,7 @@ __refresh_patch()
[ ! -z "$4" ] && diffopts="-C -M --find-copies-harder"
- if [ ! -z "$5" ]; then
+ if [ -n "$5" -o $diffstat = "true" ]; then
(
echo "---"
git diff --stat $diffopts "$2"
@@ -737,10 +737,17 @@ guilt_hook()
# used for: git apply -C <val>
guilt_push_diff_context=1
+# default diffstat value: true or false
+DIFFSTAT_DEFAULT="false"
+
#
# Parse any part of .git/config that belongs to us
#
+# generate diffstat?
+diffstat=`git config --bool guilt.diffstat`
+[ -z "$diffstat" ] && diffstat=$DIFFSTAT_DEFAULT
+
#
# The following gets run every time this file is source'd
#
--- guilt.orig/Documentation/guilt-refresh.txt
+++ guilt/Documentation/guilt-refresh.txt
@@ -20,8 +20,14 @@ OPTIONS
format (e.g., rename and copy detection).
--diffstat::
- Include a diffstat output in the patch file. Useful for cases where
- patches will be submitted with other tools.
+Include a diffstat output in the patch file. Useful for cases where
+patches will be submitted with other tools.
++
+If the command line option is omitted, the corresponding git-config
+option "guilt.diffstat" will be queried. So this would enable diffstat
+output by default:
+
+ git config --global guilt.diffstat true
Author
------
^ permalink raw reply
* Re: [PATCH] gitk: Ensure that "Reset branch" menu entry is enabled
From: Johannes Sixt @ 2008-12-18 10:42 UTC (permalink / raw)
To: Paul Mackerras; +Cc: Git Mailing List
In-Reply-To: <1228308200-28693-1-git-send-email-j6t@kdbg.org>
Johannes Sixt schrieb:
> Consider this sequence of events:
>
> 1. Detach HEAD and fire up gitk
> 2. Call the context menu on some commit. Notice that the last menu entry
> says "Detached HEAD: can't reset" and it is disabled.
> 3. Now checkout some regular branch (e.g. 'master') using the context menu.
> 4. Call the context menu again on some commit.
>
> Previously, at this point the last menu entry said "Reset master branch
> to here", but it was still disabled. With this fix it is now enabled again.
Did you consider this patch?
-- Hannes
>
> Signed-off-by: Johannes Sixt <j6t@kdbg.org>
> ---
> gitk | 2 +-
> 1 files changed, 1 insertions(+), 1 deletions(-)
>
> diff --git a/gitk b/gitk
> index f7f1776..6c4022a 100755
> --- a/gitk
> +++ b/gitk
> @@ -7950,7 +7950,7 @@ proc rowmenu {x y id} {
> if {$id ne $nullid && $id ne $nullid2} {
> set menu $rowctxmenu
> if {$mainhead ne {}} {
> - $menu entryconfigure 7 -label [mc "Reset %s branch to here" $mainhead]
> + $menu entryconfigure 7 -label [mc "Reset %s branch to here" $mainhead] -state normal
> } else {
> $menu entryconfigure 7 -label [mc "Detached head: can't reset" $mainhead] -state disabled
> }
^ permalink raw reply
* Re: [PATCH] gitk: Use check-buttons' -text property instead of separate labels
From: Johannes Sixt @ 2008-12-18 10:41 UTC (permalink / raw)
To: Paul Mackerras; +Cc: git
In-Reply-To: <200812022142.16095.j6t@kdbg.org>
Johannes Sixt schrieb:
> Previously the check-buttons' labels in the Preferences were separate
> widgets. This had the disadvantage that in order to toggle the check-button
> with the mouse the check-box had to be clicked. With this change the
> check-box can also be toggled by clicking the label.
Did you consider this patch?
-- Hannes
> Signed-off-by: Johannes Sixt <j6t@kdbg.org>
> ---
> gitk | 30 ++++++++++--------------------
> 1 files changed, 10 insertions(+), 20 deletions(-)
>
> diff --git a/gitk b/gitk
> index 64a873d..ee1941c 100755
> --- a/gitk
> +++ b/gitk
> @@ -10079,15 +10079,11 @@ proc doprefs {} {
> -font optionfont
> spinbox $top.maxpct -from 1 -to 100 -width 4 -textvariable maxgraphpct
> grid x $top.maxpctl $top.maxpct -sticky w
> - frame $top.showlocal
> - label $top.showlocal.l -text [mc "Show local changes"] -font optionfont
> - checkbutton $top.showlocal.b -variable showlocalchanges
> - pack $top.showlocal.b $top.showlocal.l -side left
> + checkbutton $top.showlocal -text [mc "Show local changes"] \
> + -font optionfont -variable showlocalchanges
> grid x $top.showlocal -sticky w
> - frame $top.autoselect
> - label $top.autoselect.l -text [mc "Auto-select SHA1"] -font optionfont
> - checkbutton $top.autoselect.b -variable autoselect
> - pack $top.autoselect.b $top.autoselect.l -side left
> + checkbutton $top.autoselect -text [mc "Auto-select SHA1"] \
> + -font optionfont -variable autoselect
> grid x $top.autoselect -sticky w
>
> label $top.ddisp -text [mc "Diff display options"]
> @@ -10095,20 +10091,14 @@ proc doprefs {} {
> label $top.tabstopl -text [mc "Tab spacing"] -font optionfont
> spinbox $top.tabstop -from 1 -to 20 -width 4 -textvariable tabstop
> grid x $top.tabstopl $top.tabstop -sticky w
> - frame $top.ntag
> - label $top.ntag.l -text [mc "Display nearby tags"] -font optionfont
> - checkbutton $top.ntag.b -variable showneartags
> - pack $top.ntag.b $top.ntag.l -side left
> + checkbutton $top.ntag -text [mc "Display nearby tags"] \
> + -font optionfont -variable showneartags
> grid x $top.ntag -sticky w
> - frame $top.ldiff
> - label $top.ldiff.l -text [mc "Limit diffs to listed paths"] -font optionfont
> - checkbutton $top.ldiff.b -variable limitdiffs
> - pack $top.ldiff.b $top.ldiff.l -side left
> + checkbutton $top.ldiff -text [mc "Limit diffs to listed paths"] \
> + -font optionfont -variable limitdiffs
> grid x $top.ldiff -sticky w
> - frame $top.lattr
> - label $top.lattr.l -text [mc "Support per-file encodings"] -font optionfont
> - checkbutton $top.lattr.b -variable perfile_attrs
> - pack $top.lattr.b $top.lattr.l -side left
> + checkbutton $top.lattr -text [mc "Support per-file encodings"] \
> + -font optionfont -variable perfile_attrs
> grid x $top.lattr -sticky w
>
> entry $top.extdifft -textvariable extdifftool
--
DI Johannes Sixt
Leiter Softwareentwicklung
Viscovery Software GmbH
Landstrasse 11
A-4020 Linz, Austria
T: +43-1-532 0570-51
M: +43-676-8494 9571
F: +43-1-532 0570-33
j.sixt@viscovery.net
www.viscovery.net
t u r n y o u r d a t a i n t o r e a l v a l u e !
^ permalink raw reply
* Re: [PATCHv5 2/3] gitweb: add patches view
From: Jakub Narebski @ 2008-12-18 9:33 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Giuseppe Bilotta, git, Petr Baudis
In-Reply-To: <7v4p12hv5q.fsf@gitster.siamese.dyndns.org>
On Thu, 18 Dec 2008, Junio C Hamano wrote:
> Giuseppe Bilotta <giuseppe.bilotta@gmail.com> writes:
>
> > sub git_commitdiff {
> > my $format = shift || 'html';
> > + my %params = @_;
> > ...
> > + if ($params{-single}) {
> > + push @commit_spec, '-1';
> > + } else {
> > + if ($patch_max > 0) {
> > ...
> > + }
> > @@ -5625,6 +5635,10 @@ sub git_commitdiff_plain {
> >
> > # format-patch-style patches
> > sub git_patch {
> > + git_commitdiff('patch', -single=> 1);
> > +}
>
> Hmm, if you are changing the interface this way, wouldn't it make more
> sense to also do this?
>
> git_commitdiff(--format => 'patch', --single => 1);
> git_commitdiff(--format => 'html');
The first argument (format) is _required_, second is _optional_;
I'd rather use named parameters trick only for optional parameters.
Because with more than one optional parameter function call begins
to be cryptic; also flag (boolean) parameters are more readable
when used as named parameters.
--
Jakub Narebski
Poland
^ permalink raw reply
* [PATCH] gitk: Allow unbalanced quotes/braces in commit headers
From: Kevin Ballard @ 2008-12-18 9:26 UTC (permalink / raw)
To: Paul Mackerras, demerphq, git; +Cc: Kevin Ballard
When parsing commits, gitk treats the headers of the commit as tcl lists.
This causes errors if the header contains an unbalanced quote or open brace.
Splitting the line on spaces allows us to treat it as a set of words instead
of as a tcl list, which prevents errors.
Signed-off-by: Kevin Ballard <kevin@sb.org>
---
gitk | 5 +++--
1 files changed, 3 insertions(+), 2 deletions(-)
diff --git a/gitk b/gitk
index a5e24e4..83b45cd 100755
--- a/gitk
+++ b/gitk
@@ -1601,13 +1601,14 @@ proc parsecommit {id contents listed} {
set header [string range $contents 0 [expr {$hdrend - 1}]]
set comment [string range $contents [expr {$hdrend + 2}] end]
foreach line [split $header "\n"] {
+ set line [split $line " "]
set tag [lindex $line 0]
if {$tag == "author"} {
set audate [lindex $line end-1]
- set auname [lrange $line 1 end-2]
+ set auname [join [lrange $line 1 end-2] " "]
} elseif {$tag == "committer"} {
set comdate [lindex $line end-1]
- set comname [lrange $line 1 end-2]
+ set comname [join [lrange $line 1 end-2] " "]
}
}
set headline {}
--
1.6.1.rc3.334.g7365d
^ permalink raw reply related
* Re: git-format-patch patch
From: Junio C Hamano @ 2008-12-18 8:42 UTC (permalink / raw)
To: Jeff King; +Cc: jidanni, git
In-Reply-To: <20081218083515.GB29356@coredump.intra.peff.net>
Jeff King <peff@peff.net> writes:
> ... Besides the format not being applicable by regular git tools:
>
> - there is no commit message describing the changes, nor the reasoning
> behind them
>
> - it was not sent to the maintainer (who does read the list, but does
> not always read every message).
Actually, it would probably be a good idea not to send your first patch to
me and instead to request for comments from the list ;-)n
The worst offence of the message was the choice of bad Subject that
strongly encouraged anyone to skip it. Consider:
Subject: [PATCH] document "format-patch --in-reply-to" better
or something like that.
^ permalink raw reply
* Re: Announcement: Git Extensions stable (windows shell extensions)
From: Sverre Rabbelier @ 2008-12-18 8:36 UTC (permalink / raw)
To: Henk; +Cc: git
In-Reply-To: <1229587749729-1672012.post@n2.nabble.com>
On Thu, Dec 18, 2008 at 09:09, Henk <henk_westhuis@hotmail.com> wrote:
> If you have problems during development, please ask, I might allready
> encountered some. Especially when you are starting on the features that need
> userinteraction like push/pull/clone/mergetool. These cannot just be run as
> a command and catching the standard output. In the version of GitExtensions
> I published I just run the commands, but I allready have a prototype build
> in c# combined with some c++ that directly calls some (exported) Git
> functions. Just executing git.exe is the fastest way of creating a gui, but
> its not the best way of doiing things.
Perhaps you could consider contributing to libgit2 for this purpose, I
reckon C# has some way to import C libraries, yes?
--
Cheers,
Sverre Rabbelier
^ permalink raw reply
* Re: git-format-patch patch
From: Jeff King @ 2008-12-18 8:35 UTC (permalink / raw)
To: jidanni; +Cc: git
In-Reply-To: <877i5yy149.fsf@jidanni.org>
On Thu, Dec 18, 2008 at 04:53:42AM +0800, jidanni@jidanni.org wrote:
> I'm still reading the manpage about submitting proper patches, so for now:
It looks like you didn't even use git to create it (since it is a
context diff and the filenames are obviously bogus). If you are
committed to improving git, then surely using it is not so bad? :)
Try cloning git://git.kernel.org/pub/scm/git/git.git, or if you just
have a tarball, at least do "cd /path/to/git && git init && git add . &&
git commit -m 'import from git version $whatever'". Then you can make
your changes and have git track them and prepare them for submission.
Then read Documentation/SubmittingPatches, which covers some of the
basics. Besides the format not being applicable by regular git tools:
- there is no commit message describing the changes, nor the reasoning
behind them
- it was not sent to the maintainer (who does read the list, but does
not always read every message).
> --in-reply-to=Message-Id::
> Make the first mail (or all the mails with --no-thread) appear as a
> reply to the given Message-Id, which avoids breaking threads to
> ! provide a new patch series. Generates coresponding References and
> ! In-Reply-To headers. Angle brackets around <Message-Id> are optional.
As for the change itself, it looks reasonable to me.
-Peff
^ permalink raw reply
* Re: Suggestion: better error reporting when setting HEAD
From: Jeff King @ 2008-12-18 8:25 UTC (permalink / raw)
To: Francois Marier; +Cc: Junio C Hamano, git, sam.vilain
In-Reply-To: <20081218055825.GQ6708@isafjordur.dyndns.org>
[Junio cc'd, as I think he may have comments on the patch at the end]
On Thu, Dec 18, 2008 at 06:58:25PM +1300, Francois Marier wrote:
> If you take any valid git repo and then do the following:
>
> git symbolic-ref HEAD master
> (instead of "git symbolic-ref HEAD refs/heads/master")
>
> then other git commands (e.g. "git log") will return this error message:
>
> fatal: Not a git repository
I've done this exact same thing, and it is very annoying.
> I'd like to suggest two "usability" improvements:
>
> 1- changing the error message to explain why the directory is no longer
> considered a git repo. Maybe something along the lines of:
>
> fatal: Invalid reference in .git/HEAD
This can be done, but is more complex than you might hope; the test for
"is this is a git directory" may get run multiple times while trying to
find out if we are in a repo. So giving a reason why we aren't in a git
repo is going to end up something like:
I tried X, but its HEAD ref had cruft in it;
then I tried Y, but it had no HEAD file;
then I gave up
Obviously with a working tree, the first directory with the '.git' repo
is a likely candidate for being the right thing, but with an error. But
if you are looking for a bare repository, then it could be any parent
directory. Maybe it is worth just spewing "there is a HEAD file here,
but it doesn't look right" when it fails to validate. It would give a
false positive if you had a file named HEAD (and you weren't actually in
a git repo), but that is unlikely to happen. And if you get multiple
ones, so be it.
> 2- To prevent this error from happening in the first place, git-symbolic-ref
> could refuse to change HEAD to a non-existent ref.
Actually, we sometimes need to point to non-existent refs; these are
"branches yet to be born". The reason that the new HEAD doesn't validate
is that it is supposed to start with "refs/".
We could fix it like this:
diff --git a/builtin-symbolic-ref.c b/builtin-symbolic-ref.c
index bfc78bb..08fa3ce 100644
--- a/builtin-symbolic-ref.c
+++ b/builtin-symbolic-ref.c
@@ -44,6 +44,8 @@ int cmd_symbolic_ref(int argc, const char **argv, const char *prefix)
check_symref(argv[0], quiet);
break;
case 2:
+ if (prefixcmp(argv[1], "refs/"))
+ die("Refusing to point %s outside of refs/", argv[0]);
create_symref(argv[0], argv[1], msg);
break;
default:
which tries to match the behavior used by validate_headref, but there
are a few open questions:
- Should it require this of _all_ symbolic refs, or just HEAD?
- Should there be a "-f" force option?
- Should it be moved to the create_symref library function. It gets
called in several places, and I didn't audit all of them.
- I looked at trying to share validate_headref's logic (so they don't
get out of sync), but really the only thing that applies is the
"refs" check. The rest is about checking parts of the symref that are
outside of the actual content.
- This doesn't allow a sha1 for detached HEAD. However, that currently
doesn't work _anyway_, as it creates a HEAD with "ref: $SHA1", which
is totally bogus.
-Peff
^ permalink raw reply related
* Re: Announcement: Git Extensions stable (windows shell extensions)
From: Henk @ 2008-12-18 8:09 UTC (permalink / raw)
To: git
In-Reply-To: <1976ea660812171757s37e8435cxc4d34ade04635b81@mail.gmail.com>
If you have problems during development, please ask, I might allready
encountered some. Especially when you are starting on the features that need
userinteraction like push/pull/clone/mergetool. These cannot just be run as
a command and catching the standard output. In the version of GitExtensions
I published I just run the commands, but I allready have a prototype build
in c# combined with some c++ that directly calls some (exported) Git
functions. Just executing git.exe is the fastest way of creating a gui, but
its not the best way of doiing things.
Li Frank wrote:
>
> Great Work!
> TortoiseGit start late. But it reuse many TortoiseSVN work.
> I believe TortoiseGit can catch.
>
--
View this message in context: http://n2.nabble.com/Announcement%3A-Git-Extensions-stable-%28windows-shell-extensions%29-tp1669264p1672012.html
Sent from the git mailing list archive at Nabble.com.
^ permalink raw reply
* Re: How to maintain private/secret/confidential branch.
From: Daniel Barkalow @ 2008-12-18 8:03 UTC (permalink / raw)
To: Łukasz Lew; +Cc: Alexander Potashev, Nick Andrew, git
In-Reply-To: <c55009e70812171431l7eab33b2x28c5b4360118880b@mail.gmail.com>
[-- Attachment #1: Type: TEXT/PLAIN, Size: 5090 bytes --]
On Wed, 17 Dec 2008, Łukasz Lew wrote:
> >> > Often, resolve easy conflicts where my mixed-work branch introduced bugs
> >> > that I fixed later and have now adopted the fixed code
> >> >
> >> > Then I repeat until I don't have any more good changes in mixed-work
> >> > (either I have nothing, only debugging cruft, or only stuff I haven't
> >> > gotten to work yet). If there's nothing but cruft, I've fully merged the
> >> > topic, and I delete the branch.
> >> >
> >> > Eventually, I'm satisfied with what I've cleaned up, and I do:
> >> > $ git push origin submit:master
> >> >
> >> > Also, I generally have a bunch of "mixed-work" branches, each containing
> >> > different stuff that isn't ready. I'll periodicly go through all of them
> >> > and rebase onto "submit" or "origin/master" (or, sometimes, give up on
> >> > them and delete them).
> >> >
> >> > (One thing that would be nice to have is a "git apply --interactive" which
> >> > applies the user's choice of hunks, like "git add -i" adds them)
> >>
> >> I totally agree.
> >>
> >> I would appriciate rebase --copy option, which doesn't move, but copy
> >> the changelists like cherry-pick.
> >
> > There's work in progress on a generalization of "rebase -i" that could be
> > seeded with the "cherry-pick" operations instead of the "rebase"
> > operations. I think that's what you'd like.
>
> I always wanted to have system that would allow me manipulation of
> patches as features.
> I.e: I have one patch for feature X, one for Y, one for debugging X,
> one for debugging Y, etc.
> Then I would just pick some of them, work with them to create new ones.
>
> The basic operations would be use/unuse patch, combine sequence of
> patches into one (with commit messages of subpatches saved somewhere),
> uncombine patch into sequence of patches.
> Easy way of spliting atomic patch (diff) into several more so I can
> add more commit messages.
>
> Now this would resemble directory structure, I could copy/move/remove
> patches from/to various bigger packs of patches. Merging would detect
> duplicates of course.
>
> Git took me for the first time close to this ideal.
Git works from the point of view of a developer producing the ideal
development history that doesn;t (necessarily) include false starts, bugs
fixed in private, and changes mixed together. Or rather, git allows a
developer to make commits again knowing the full outcome of the series.
It also works from the point of view of a maintainer who merges or does
not merge the output of developers working in this mode.
It doesn't really quite handle the work of an integrator whose work is to
manage a patch queue. I think it needs some additional tools which allow
the user do work which consists of operations like "replace this
patch/branch with a new version", "suppress this patch/branch", "reorder
these patches/branches", and the main thing: "produce a version of my
current series with conflict resolutions"
This would actually be really helpful to have explicitly represented, so
that people could actually bisect the -mm series to find the operation
that Andrew did that caused a problem to enter the series, which would be
something like adding a patch that doesn't work with other patches in the
series. Note that this is different from bisecting within the failing
state of the -mm tree, which finds where the series seen as a difference
from mainline, fails; if you know that -mm yesterday works and -mm today
fails, the difference might be that a branch merged early in the series
was updated to a version incompatible with a branch later in the series
that hasn't changed, and you'd want to finger the update rather than the
point in the series where kernels start failing.
> > On the other hand, remember
> > that you can just make a new branch based on your endpoint and rebase it
> > on your upstream; there's no reason that you can't "unzip" the history
> > past the point where the branch you're modifying was created.
>
> I never thought about that. It works indeed.
There's a lot you can do when branches are as cheap and flexible as git's
branches are.
> >> Then we could use rebase -i (with edit) instead of apply.
> >>
> >> PS
> >> Why after edit in rebase -i the change is already commited? I always
> >> have to reset;add -i
> >
> > There's (currently) no equivalent of the index (storing the contents of
> > the commit in progress) for the message (and author info, etc). On the
> > other hand, you can use "git commit --amend" to alter the commit on top
> > (including the files), and you can do "git diff HEAD HEAD^ | git apply" to
> > get reverts into your worktree that you can add (or not add).
>
> Good idea, thanks.
> BTW is it diff | apply the same as revert --no-commit?
Largely, although you can give the diff/apply pair paths you want to
revert, and not revert the whole thing. And the second commit can be
anything with the diff/apply pair, not just HEAD^, which is what revert
does, so it's a worthwhile generalization to understand.
-Daniel
*This .sig left intentionally blank*
^ permalink raw reply
* [PATCH v2] gitk: force the focus to the main window on Windows
From: Johannes Sixt @ 2008-12-18 7:30 UTC (permalink / raw)
To: Paul Mackerras; +Cc: Git Mailing List, Johannes Schindelin
In-Reply-To: <18761.29020.237388.687560@cargo.ozlabs.ibm.com>
From: Johannes Sixt <j6t@kdbg.org>
On msysGit, the focus is first on the (Tk) console. This console is then
hidden, but keeps the focus. Work around that by forcing the focus onto
the gitk window.
This fixes msysGit issue 14. Diagnosed and originally fixed by
Johannes Schindelin.
Signed-off-by: Johannes Sixt <j6t@kdbg.org>
---
Paul Mackerras schrieb:
> At least put a if {[tk windowingsystem] eq "win32"} in there.
> (msysGit is a windows thing, isn't it?)
I did that.
-- Hannes
gitk | 5 +++++
1 files changed, 5 insertions(+), 0 deletions(-)
diff --git a/gitk b/gitk
index b63109b..121b621 100644
--- a/gitk
+++ b/gitk
@@ -10898,4 +10898,9 @@ if {[info exists permviews]} {
addviewmenu $n
}
}
+
+if {[tk windowingsystem] eq "win32"} {
+ focus -force .
+}
+
getcommits {}
--
1.6.1.rc3.950.g5dd2
^ permalink raw reply related
* [PATCHv6 4/4] gitweb: link to patch(es) view in commit(diff) and (short)log view
From: Giuseppe Bilotta @ 2008-12-18 7:13 UTC (permalink / raw)
To: git; +Cc: Jakub Narebski, Petr Baudis, Junio C Hamano, Giuseppe Bilotta
In-Reply-To: <1229584399-23879-4-git-send-email-giuseppe.bilotta@gmail.com>
We link to patch view in commit and commitdiff view, and to patches view
in log and shortlog view.
In (short)log view, the link is only offered when the number of commits
shown is no more than the allowed maximum number of patches.
Signed-off-by: Giuseppe Bilotta <giuseppe.bilotta@gmail.com>
---
gitweb/gitweb.perl | 30 ++++++++++++++++++++++++++++--
1 files changed, 28 insertions(+), 2 deletions(-)
diff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl
index 78aaebe..fd8bc29 100755
--- a/gitweb/gitweb.perl
+++ b/gitweb/gitweb.perl
@@ -5024,6 +5024,15 @@ sub git_log {
my $paging_nav = format_paging_nav('log', $hash, $head, $page, $#commitlist >= 100);
+ my ($patch_max) = gitweb_get_feature('patches');
+ if ($patch_max) {
+ if ($patch_max < 0 || @commitlist <= $patch_max) {
+ $paging_nav .= " ⋅ " .
+ $cgi->a({-href => href(action=>"patches", -replay=>1)},
+ "patches");
+ }
+ }
+
git_header_html();
git_print_page_nav('log','', $hash,undef,undef, $paging_nav);
@@ -5103,6 +5112,11 @@ sub git_commit {
} @$parents ) .
')';
}
+ if (gitweb_check_feature('patches')) {
+ $formats_nav .= " | " .
+ $cgi->a({-href => href(action=>"patch", -replay=>1)},
+ "patch");
+ }
if (!defined $parent) {
$parent = "--root";
@@ -5416,9 +5430,8 @@ sub git_commitdiff {
my %params = @_;
my $format = $params{-format} || 'html';
- my $patch_max;
+ my ($patch_max) = gitweb_get_feature('patches');
if ($format eq 'patch') {
- ($patch_max) = gitweb_get_feature('patches');
die_error(403, "Patch view not allowed") unless $patch_max;
}
@@ -5436,6 +5449,11 @@ sub git_commitdiff {
$formats_nav =
$cgi->a({-href => href(action=>"commitdiff_plain", -replay=>1)},
"raw");
+ if ($patch_max) {
+ $formats_nav .= " | " .
+ $cgi->a({-href => href(action=>"patch", -replay=>1)},
+ "patch");
+ }
if (defined $hash_parent &&
$hash_parent ne '-c' && $hash_parent ne '--cc') {
@@ -5992,6 +6010,14 @@ sub git_shortlog {
$cgi->a({-href => href(-replay=>1, page=>$page+1),
-accesskey => "n", -title => "Alt-n"}, "next");
}
+ my $patch_max = gitweb_check_feature('patches');
+ if ($patch_max) {
+ if ($patch_max < 0 || @commitlist <= $patch_max) {
+ $paging_nav .= " ⋅ " .
+ $cgi->a({-href => href(action=>"patches", -replay=>1)},
+ "patches");
+ }
+ }
git_header_html();
git_print_page_nav('shortlog','', $hash,$hash,$hash, $paging_nav);
--
1.5.6.5
^ permalink raw reply related
* [PATCHv6 3/4] gitweb: add patches view
From: Giuseppe Bilotta @ 2008-12-18 7:13 UTC (permalink / raw)
To: git; +Cc: Jakub Narebski, Petr Baudis, Junio C Hamano, Giuseppe Bilotta
In-Reply-To: <1229584399-23879-3-git-send-email-giuseppe.bilotta@gmail.com>
The only difference between patch and patches view is in the treatement
of single commits: the former only displays a single patch, whereas the
latter displays a patchset leading to the specified commit.
Signed-off-by: Giuseppe Bilotta <giuseppe.bilotta@gmail.com>
---
gitweb/gitweb.perl | 15 ++++++++++++++-
1 files changed, 14 insertions(+), 1 deletions(-)
diff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl
index 18d43e7..78aaebe 100755
--- a/gitweb/gitweb.perl
+++ b/gitweb/gitweb.perl
@@ -530,6 +530,7 @@ our %actions = (
"history" => \&git_history,
"log" => \&git_log,
"patch" => \&git_patch,
+ "patches" => \&git_patches,
"rss" => \&git_rss,
"atom" => \&git_atom,
"search" => \&git_search,
@@ -5530,7 +5531,15 @@ sub git_commitdiff {
}
push @commit_spec, '-n', "$hash_parent..$hash";
} else {
- push @commit_spec, '-1', '--root', $hash;
+ if ($params{-single}) {
+ push @commit_spec, '-1';
+ } else {
+ if ($patch_max > 0) {
+ push @commit_spec, "-$patch_max";
+ }
+ push @commit_spec, "-n";
+ }
+ push @commit_spec, '--root', $hash;
}
open $fd, "-|", git_cmd(), "format-patch", '--encoding=utf8',
'--stdout', @commit_spec
@@ -5626,6 +5635,10 @@ sub git_commitdiff_plain {
# format-patch-style patches
sub git_patch {
+ git_commitdiff(-format => 'patch', -single=> 1);
+}
+
+sub git_patches {
git_commitdiff(-format => 'patch');
}
--
1.5.6.5
^ permalink raw reply related
* [PATCHv6 2/4] gitweb: change call pattern for git_commitdiff
From: Giuseppe Bilotta @ 2008-12-18 7:13 UTC (permalink / raw)
To: git; +Cc: Jakub Narebski, Petr Baudis, Junio C Hamano, Giuseppe Bilotta
In-Reply-To: <1229584399-23879-2-git-send-email-giuseppe.bilotta@gmail.com>
Since we are going to introduce an additional parameter for
git_commitdiff to tune patch view, we switch to named/hash-based
parameter passing for clarity and robustness.
---
gitweb/gitweb.perl | 7 ++++---
1 files changed, 4 insertions(+), 3 deletions(-)
diff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl
index 1006dfe..18d43e7 100755
--- a/gitweb/gitweb.perl
+++ b/gitweb/gitweb.perl
@@ -5412,7 +5412,8 @@ sub git_blobdiff_plain {
}
sub git_commitdiff {
- my $format = shift || 'html';
+ my %params = @_;
+ my $format = $params{-format} || 'html';
my $patch_max;
if ($format eq 'patch') {
@@ -5620,12 +5621,12 @@ sub git_commitdiff {
}
sub git_commitdiff_plain {
- git_commitdiff('plain');
+ git_commitdiff(-format => 'plain');
}
# format-patch-style patches
sub git_patch {
- git_commitdiff('patch');
+ git_commitdiff(-format => 'patch');
}
sub git_history {
--
1.5.6.5
^ permalink raw reply related
* [PATCHv6 1/4] gitweb: add patch view
From: Giuseppe Bilotta @ 2008-12-18 7:13 UTC (permalink / raw)
To: git; +Cc: Jakub Narebski, Petr Baudis, Junio C Hamano, Giuseppe Bilotta
In-Reply-To: <1229584399-23879-1-git-send-email-giuseppe.bilotta@gmail.com>
The output of commitdiff_plain is not intended for git-am:
* when given a range of commits, commitdiff_plain publishes a single
patch with the message from the first commit, instead of a patchset
* the hand-built email format replicates the commit summary both as
email subject and as first line of the email itself, resulting in
a duplication if the output is used with git-am.
We thus create a new view that can be fed to git-am directly, allowing
patch exchange via gitweb. The new view exposes the output of git
format-patch directly, limiting it to a single patch in the case of a
single commit.
A configurable upper limit defaulting to 16 is imposed on the number of
commits which will be included in a patchset, to prevent DoS attacks on
the server. Setting the limit to 0 will disable the patch view, setting
it to a negative number will remove the limit.
Signed-off-by: Giuseppe Bilotta <giuseppe.bilotta@gmail.com>
---
gitweb/gitweb.perl | 69 +++++++++++++++++++++++++++++++++++++++++++++++++++-
1 files changed, 68 insertions(+), 1 deletions(-)
diff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl
index 6eb370d..1006dfe 100755
--- a/gitweb/gitweb.perl
+++ b/gitweb/gitweb.perl
@@ -330,6 +330,21 @@ our %feature = (
'ctags' => {
'override' => 0,
'default' => [0]},
+
+ # The maximum number of patches in a patchset generated in patch
+ # view. Set this to 0 or undef to disable patch view, or to a
+ # negative number to remove any limit.
+
+ # To disable system wide have in $GITWEB_CONFIG
+ # $feature{'patches'}{'default'} = [0];
+ # To have project specific config enable override in $GITWEB_CONFIG
+ # $feature{'patches'}{'override'} = 1;
+ # and in project config gitweb.patches = 0|n;
+ # where n is the maximum number of patches allowed in a patchset.
+ 'patches' => {
+ 'sub' => \&feature_patches,
+ 'override' => 0,
+ 'default' => [16]},
);
sub gitweb_get_feature {
@@ -411,6 +426,16 @@ sub feature_pickaxe {
return ($_[0]);
}
+sub feature_patches {
+ my @val = (git_get_project_config('patches', '--int'));
+
+ if (@val) {
+ return @val;
+ }
+
+ return ($_[0]);
+}
+
# checking HEAD file with -e is fragile if the repository was
# initialized long time ago (i.e. symlink HEAD) and was pack-ref'ed
# and then pruned.
@@ -504,6 +529,7 @@ our %actions = (
"heads" => \&git_heads,
"history" => \&git_history,
"log" => \&git_log,
+ "patch" => \&git_patch,
"rss" => \&git_rss,
"atom" => \&git_atom,
"search" => \&git_search,
@@ -5387,6 +5413,13 @@ sub git_blobdiff_plain {
sub git_commitdiff {
my $format = shift || 'html';
+
+ my $patch_max;
+ if ($format eq 'patch') {
+ ($patch_max) = gitweb_get_feature('patches');
+ die_error(403, "Patch view not allowed") unless $patch_max;
+ }
+
$hash ||= $hash_base || "HEAD";
my %co = parse_commit($hash)
or die_error(404, "Unknown commit object");
@@ -5484,7 +5517,23 @@ sub git_commitdiff {
open $fd, "-|", git_cmd(), "diff-tree", '-r', @diff_opts,
'-p', $hash_parent_param, $hash, "--"
or die_error(500, "Open git-diff-tree failed");
-
+ } elsif ($format eq 'patch') {
+ # For commit ranges, we limit the output to the number of
+ # patches specified in the 'patches' feature.
+ # For single commits, we limit the output to a single patch,
+ # diverging from the git-format-patch default.
+ my @commit_spec = ();
+ if ($hash_parent) {
+ if ($patch_max > 0) {
+ push @commit_spec, "-$patch_max";
+ }
+ push @commit_spec, '-n', "$hash_parent..$hash";
+ } else {
+ push @commit_spec, '-1', '--root', $hash;
+ }
+ open $fd, "-|", git_cmd(), "format-patch", '--encoding=utf8',
+ '--stdout', @commit_spec
+ or die_error(500, "Open git-format-patch failed");
} else {
die_error(400, "Unknown commitdiff format");
}
@@ -5533,6 +5582,14 @@ sub git_commitdiff {
print to_utf8($line) . "\n";
}
print "---\n\n";
+ } elsif ($format eq 'patch') {
+ my $filename = basename($project) . "-$hash.patch";
+
+ print $cgi->header(
+ -type => 'text/plain',
+ -charset => 'utf-8',
+ -expires => $expires,
+ -content_disposition => 'inline; filename="' . "$filename" . '"');
}
# write patch
@@ -5554,6 +5611,11 @@ sub git_commitdiff {
print <$fd>;
close $fd
or print "Reading git-diff-tree failed\n";
+ } elsif ($format eq 'patch') {
+ local $/ = undef;
+ print <$fd>;
+ close $fd
+ or print "Reading git-format-patch failed\n";
}
}
@@ -5561,6 +5623,11 @@ sub git_commitdiff_plain {
git_commitdiff('plain');
}
+# format-patch-style patches
+sub git_patch {
+ git_commitdiff('patch');
+}
+
sub git_history {
if (!defined $hash_base) {
$hash_base = git_get_head_hash($project);
--
1.5.6.5
^ permalink raw reply related
* [PATCHv6 0/4] gitweb: patch view
From: Giuseppe Bilotta @ 2008-12-18 7:13 UTC (permalink / raw)
To: git; +Cc: Jakub Narebski, Petr Baudis, Junio C Hamano, Giuseppe Bilotta
Sixth iteration of the patch view in gitweb, that exposes the
git-format-patch output directly, allowing patchset exchange via gitweb.
As suggested by Junio, the call pattern for git_commitdiff is changed to
use named parameters even for the first parameter (-format).
Giuseppe Bilotta (4):
gitweb: add patch view
gitweb: change call pattern for git_commitdiff
gitweb: add patches view
gitweb: link to patch(es) view in commit(diff) and (short)log view
gitweb/gitweb.perl | 109 +++++++++++++++++++++++++++++++++++++++++++++++++++-
1 files changed, 108 insertions(+), 1 deletions(-)
^ permalink raw reply
* Suggestion: better error reporting when setting HEAD
From: Francois Marier @ 2008-12-18 5:58 UTC (permalink / raw)
To: git; +Cc: sam.vilain
(Please CC me on your replies, thanks)
If you take any valid git repo and then do the following:
git symbolic-ref HEAD master
(instead of "git symbolic-ref HEAD refs/heads/master")
then other git commands (e.g. "git log") will return this error message:
fatal: Not a git repository
I'd like to suggest two "usability" improvements:
1- changing the error message to explain why the directory is no longer
considered a git repo. Maybe something along the lines of:
fatal: Invalid reference in .git/HEAD
2- To prevent this error from happening in the first place, git-symbolic-ref
could refuse to change HEAD to a non-existent ref.
Cheers,
Francois
^ permalink raw reply
* Re: [PATCHv5 2/3] gitweb: add patches view
From: Junio C Hamano @ 2008-12-18 6:09 UTC (permalink / raw)
To: Giuseppe Bilotta; +Cc: git, Jakub Narebski, Petr Baudis
In-Reply-To: <1229422290-6213-3-git-send-email-giuseppe.bilotta@gmail.com>
Giuseppe Bilotta <giuseppe.bilotta@gmail.com> writes:
> sub git_commitdiff {
> my $format = shift || 'html';
> + my %params = @_;
> ...
> + if ($params{-single}) {
> + push @commit_spec, '-1';
> + } else {
> + if ($patch_max > 0) {
> ...
> + }
> @@ -5625,6 +5635,10 @@ sub git_commitdiff_plain {
>
> # format-patch-style patches
> sub git_patch {
> + git_commitdiff('patch', -single=> 1);
> +}
Hmm, if you are changing the interface this way, wouldn't it make more
sense to also do this?
git_commitdiff(--format => 'patch', --single => 1);
git_commitdiff(--format => 'html');
^ permalink raw reply
* Re: [PATCH] Enable threaded delta search on Mac OS X/Darwin
From: Junio C Hamano @ 2008-12-18 6:02 UTC (permalink / raw)
To: Arjen Laarhoven; +Cc: git
In-Reply-To: <1229502025-15340-1-git-send-email-arjen@yaph.org>
I will apply this one, as I do not have an access to these machines and
there is no point for me to be holding onto it. People who may be
affected, please test and report.
^ permalink raw reply
* Re: [PATCH] Add git-edit-index.perl
From: Jeff King @ 2008-12-18 4:37 UTC (permalink / raw)
To: Neil Roberts; +Cc: git
In-Reply-To: <20081217204749.GA18261@janet.wally>
On Wed, Dec 17, 2008 at 08:47:49PM +0000, Neil Roberts wrote:
> This script can be used to edit a file in the index without affecting
> your working tree. It checkouts a copy of the file to a temporary file
> and runs an editor on it. If the editor completes successfully with a
> non-empty file then it updates the index with the new data.
Hmm. Neat idea. I have used add-interactive's "e"dit patch option to do
a similar thing, but it is often unwieldy (e.g., just yesterday I had a
patch that removed about 30 lines and added 1 -- rather than munging the
diff, it would have been simpler to re-add the line in a staged
version).
Thinking out loud: One thing that would make this more useful would be
providing the content of the work tree file in some way. Like seeing the
whole file but with "conflict markers" showing two versions of each
hunk, like:
a line in both files
<<<<<<< staged
a line only in the staged version
=======
a line only in the working tree version
>>>>>>> working tree
and then you can edit around that. Of course, then you _have_ to
edit every hunk since you have just stuck the conflict marker cruft. I
guess a savvy user could just open both versions in their editor and
pull content from one buffer to the other other.
> This is useful to fine tune the results from git add -p. For example
> sometimes your unrelated changes are too close together and
> git-add--interactive will refuse to split them up. Using this script
> you can add both the changes and later edit the index file to
> temporarily remove one of the changes.
Have you tried using the edit-patch option in "git add -p"? I'm curious
if you would like that better for your cases, or if you find this way
more natural.
> .gitignore | 1 +
> Makefile | 1 +
> git-edit-index.perl | 98 +++++++++++++++++++++++++++++++++++++++++++++++++++
I have to wonder if this wouldn't be better as part of
git-add--interactive? I guess technically you aren't "adding" from the
work tree since it is purely looking at the staged version. But it seems
to be part of the same workflow, as you are munging content in the
index.
> +sub check_file_size {
> + my ($fn) = @_;
> + my ($dev, $ino, $mode, $nlink, $uid, $gid, $rdev, $size,
> + $atime, $mtime, $ctime, $blksize, $blocks) = stat($fn);
> +
> + $size;
> +}
FYI, a shorthand for this is:
(stat $fn))[7];
or you may consider:
use File::stat;
stat($fn)->size;
which is nicely readable.
> + unless (system($editor, $tmp_fn) == 0
> + && check_file_size($tmp_fn)) {
> + # If the editor failed, the file has disappeared or it
> + # has zero size then give up
> + delete_temp_files(@file_list);
> + die("Editor failed or file has zero size");
I guess you are aborting on a zero-size file to allow the user a chance
to say "oops, I want to scrap the changes I've saved so far". But you
are disallowing making a file empty by this process. Which I guess is
not all that common, but it still seems restrictive. I wonder if asking
for confirmation might make more sense.
Also, does it make sense to delete the temp files if the editor failed?
The user may have put work into the file, but we are not successfully
updating the index; so we may be deleting useful work that could be
recovered.
> + unless (defined($hash) && $hash =~ /\A[0-9a-f]{40}\z/) {
> + delete_temp_files(@file_list);
> + die("Failed to add new file");
Again, if we fail to hash for whatever reason, we should not delete the
useful work that the user might have done.
-Peff
^ permalink raw reply
* Re: rsync deprecated?
From: Markus Heidelberg @ 2008-12-18 4:13 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vljuei2xw.fsf@gitster.siamese.dyndns.org>
Junio C Hamano, 18.12.2008:
> Markus Heidelberg <markus.heidelberg@web.de> writes:
>
> > in the "Merging external work" section of the gitcore-tutorial it is
> > stated that the rsync transport is deprecated. The description was added
> > in commit 914328a (Update tutorial., 2005-08-30) together with the
> > "deprecated" note. Having never heard/read this before and since this
> > commit is quite old, I wonder if it is still the case or there was a
> > solution for this problem.
>
> Sorry, I do not quite understand what you perceive as "this problem".
The problem described in the rsync section in gitcore-tutorial:
"can produce unexpected results when you download from the public
repository while the repository owner is uploading into it via rsync
transport. Most notably, it could update the files under refs/ which
holds the object name of the topmost commits before uploading the
files in objects/ - the downloader would obtain head commit object
name while that object itself is still not available in the
repository."
I only thought about git itself uploading into and downloading from the
repository with push and fetch, respectively. And wondered where the
problem with the order of refs and objects was. But I just realized, it
can of course be uploaded with plain rsync, too.
> It has been deprecated for too long a time. Maybe it is time to remove
> the support, instead of carrying the deprecated command forever? Is that
> the problem you are talking about?
Yes, this is the answer to my question. I thought maybe it's not
deprecated anymore, because the only place where it is called so, is
gitcore-tutorial.
^ permalink raw reply
* Re: [PATCH] gitk: force focus to main window
From: Paul Mackerras @ 2008-12-18 4:09 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Johannes Sixt, Git Mailing List
In-Reply-To: <alpine.DEB.1.00.0812180413240.14632@racer>
Johannes Schindelin writes:
> > At least put a if {[tk windowingsystem] eq "win32"} in there. (msysGit
> > is a windows thing, isn't it?)
>
> Yeah, because on other platforms, when you start gitk, you don't want it
> to take focus. Yeah, right.
No - on other platforms I have a window manager that gives focus to
new applications automatically. Or, if I don't want new applications
to grab the focus, I tell the window manager that that's what the
policy should be. Either way the application shouldn't forcibly and
unilaterally grab the focus.
I'm prepared (predisposed, even :-) to believe that windows sucks, so
I'll take the patch if it only affects windows.
Paul.
^ permalink raw reply
* Re: Is it possible to roll back unstaged changes while leaving the staged ones for the next commit?
From: Nanako Shiraishi @ 2008-12-18 3:34 UTC (permalink / raw)
To: Tim Visher; +Cc: Junio C Hamano, git
In-Reply-To: <c115fd3c0812171722g93dbeefw2fb5bf7641dfe394@mail.gmail.com>
Quoting "Tim Visher" <tim.visher@gmail.com>:
> On Wed, Dec 17, 2008 at 5:59 PM, Junio C Hamano <gitster@pobox.com> wrote:
>> How about omitting the "git commit" and do "git checkout PATH" after you
>> are done with the staging? IOW, (1) above.
>
> Huh. I guess I was under the impression that doing the `git checkout
> PATH` would destroy the staged content as well as the unstaged. This
> isn't the case?
A short answer is "no it is not the case."
I was about to quote "git checkout" documentation to you because I was reasonably sure that Junio won't respond to people who ask a question whose answer is plainly described in the manual pages, but I think the description of the command is a little confusing especially for people who read it for the first time.
This is a patch to clarify the sentence.
-- 8< -- Cut Here -- 8< --
Subject: Clarify documentation of "git checkout <tree-ish> paths" syntax
The SYNOPSIS section of the manual writes:
git checkout [options] [<tree-ish>] [--] <paths>...
but the DESCRIPTION says that this form checks the paths out "from the
index, or from a named commit." A later sentence refers to the same
argument as "<tree-ish> argument", but it is not clear that these two
sentences are talking about the same command line argument for first-time
readers.
Signed-off-by: Nanako Shiraishi <nanako3@lavabit.com>
---
Documentation/git-checkout.txt | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/Documentation/git-checkout.txt b/Documentation/git-checkout.txt
index 168333a..bbdfa40 100644
--- a/Documentation/git-checkout.txt
+++ b/Documentation/git-checkout.txt
@@ -27,7 +27,7 @@ the first namespace level.
When <paths> are given, this command does *not* switch
branches. It updates the named paths in the working tree from
-the index file, or from a named commit. In
+the index file, or from a named <tree-ish> (most often a commit). In
this case, the `-b` options is meaningless and giving
either of them results in an error. <tree-ish> argument can be
used to specify a specific tree-ish (i.e. commit, tag or tree)
--
Nanako Shiraishi
http://ivory.ap.teacup.com/nanako3/
^ 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