There are broadly two problems with the current SYNOPSIS. First, it
completely omits the detail that paths can be specified. Second, it
attempts to list all the options: this is futile as, in addition to
the options unique to it, it accepts all the options that git-rev-list
accepts. In fixing th
"--" is used to separate pathspecs from the rev specs, and not rev
specs from the options, as the shortlog_usage string currently
indicates. In correcting this usage string, make it consistent with
the log_usage string.
Signed-off-by: Ramkumar Ramachandra
---
builtin/shortlog.c | 4 +---
1 file
'..' is misleading, as there are many other forms that
'git log' can accept as an argument. Replace it with ,
referring to the section "Specifying Ranges" in revisions.txt, and
rewrite the section appropriately.
Signed-off-by: Ramkumar Ramachandra
---
Documentation/git-log.txt | 16 +---
In its current form, the note talks about separating options from
"branch names" and "refnames" in the same sentence. This is entirely
inaccurate, as need not be a set of branch names or
ref names. Rewrite it to use the word "revision range", to be
consistent with the SYNOPSIS.
Signed-off-by: R
The OPTIONS section lists .. as the first item, but this
is inconsistent with the ordering in SYNOPSIS. Move it down until it
appears just before [[--] ...].
Signed-off-by: Ramkumar Ramachandra
---
Documentation/git-log.txt | 14 +++---
1 file changed, 7 insertions(+), 7 deletions(-)
d
To be consistent with the documentation of all the other commands,
remove (-h|--help) from the OPTIONS section.
Signed-off-by: Ramkumar Ramachandra
---
Documentation/git-shortlog.txt | 4
1 file changed, 4 deletions(-)
diff --git a/Documentation/git-shortlog.txt b/Documentation/git-shortlo
In .. and ..., if either or is
omitted, it defaults to 'HEAD'. Add this detail to the document.
Signed-off-by: Ramkumar Ramachandra
---
Documentation/revisions.txt | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/Documentation/revisions.txt b/Documentation/revisions.t
Hi,
The re-roll was necessary due to minor/silly mistakes in v2, as
pointed out by Junio.
The builtin/shortlog.c patch has moved to the end until we change
'..' to '' everywhere else. We use
'' here too.
[4/7] has been replaced with the version Junio fixed up and put in
`pu`.
[6/7] has been up
Junio C Hamano writes:
>> Then the --ignore-removals option could be added using a patch like
>> the following.
>
> adding ignore-removals as a synonym (and keeping it) would be a good
> idea.
>
> We would still need to carry --all and --no-all that have been with
> us ever since we added "-A" op
Junio C Hamano writes:
> Two other things I noticed with the current text are:
> ...
> * The part with the new "-L" option seems to be throwing the
>overall formatting off. Its second paragraph " and
>can take..." is not indented to the same level as its first
>paragraph "Trace the
Jonathan Nieder writes:
> How about something like this?
>
> warning: "git add" run on path with files removed (e.g., '%s')
> hint: use "git add --ignore-removals " to ignore removals
> hint: or "git add --no-ignore-removals " to notice them
> hint: --ignore-removals is th
On Sun, Apr 21, 2013 at 5:22 PM, ode wrote:
> Hi,
>
> I had a big commit I wanted to break up and was wondering if there is
> any way to stage individual lines from the command line.
>
> I am using git add -i but it couldn't split the hunks any smaller.
>
> I went looking on Google and found git-c
Hi,
I had a big commit I wanted to break up and was wondering if there is
any way to stage individual lines from the command line.
I am using git add -i but it couldn't split the hunks any smaller.
I went looking on Google and found git-cola gui client which works for
staging individual lines to
Sorry, you do not have permission to post to the dx-n...@njdxa.org mailing list.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
On Sun, Apr 21, 2013 at 5:00 PM, Junio C Hamano wrote:
> Felipe Contreras writes:
>
>> On Sun, Apr 21, 2013 at 2:02 PM, Andreas Schwab
>> wrote:
>>> Junio C Hamano writes:
>>>
Andreas Schwab writes:
> Felipe Contreras writes:
>
>> + if [ -n "${
Michael Haggerty writes:
> * When I think a batch of patches is ready, I merge them to my master
> and publish my master somewhere. (Or is it better I publish the feature
> branch and leave it to you to merge directly to your master?)
I think I missed this part, but in the case of git-svn, what
Michael Haggerty writes:
> That seems very workable.
That is pretty much it.
> What is your preference regarding the history to date?
The only thing I deeply care about is that initial and subsequent
"git pull" I'll do from you [*1*] will pull in commits that touch
only the "multimail" part in
Felipe Contreras writes:
> On Sun, Apr 21, 2013 at 2:02 PM, Andreas Schwab wrote:
>> Junio C Hamano writes:
>>
>>> Andreas Schwab writes:
>>>
Felipe Contreras writes:
> + if [ -n "${ZSH_VERSION-}" ]; then
> + u="%%"
The definition of a remote-tracking branch in the glossary have been
out-of-date for a while (by e.g. referring to "Pull:" from old-style
$GIT_DIR/remotes files).
Also, the preceding patches have formalized that a remote-tracking branch
must match a configured refspec in order to be usable as an u
We are formalizing a requirement that any remote-tracking branch to be used
as an upstream (i.e. as an argument to --track), _must_ "belong" to a
configured remote by being matched by the "dst" side of a fetch refspec.
This test uses --track against a "remotes/trunk" ref which does not belong
to a
The current code for validating tracking branches (e.g. the argument to
the -t/--track option) hardcodes refs/heads/* and refs/remotes/* as the
potential locations for tracking branches. This works with the refspecs
created by "git clone" or "git remote add", but is suboptimal in other
cases:
- I
We are formalizing a requirement that any remote-tracking branch to be used
as an upstream (i.e. as an argument to --track), _must_ "belong" to a
configured remote by being matched by the "dst" side of a fetch refspec.
This patch encodes the new expected behavior of this test, and marks the
test w
We are formalizing a requirement that any remote-tracking branch to be used
as an upstream (i.e. as an argument to --track), _must_ "belong" to a
configured remote by being matched by the "dst" side of a fetch refspec.
Without this patch, this test would start failing when the new behavior is
intr
The DWIM mode of checkout allows you to run "git checkout foo" when there
is no existing local ref or path called "foo", and there is exactly _one_
remote with a remote-tracking branch called "foo". Git will automatically
create a new local branch called "foo" using the remote-tracking "foo" as
its
When using "git checkout foo" to DWIM the creation of local "foo" from some
existing upstream "foo", we assume conventional refspecs as created by "git
clone" or "git remote add", and fail to work correctly if the current
refspecs do not follow the conventional "refs/remotes/$remote/*" pattern.
Im
The DWIM mode of checkout allows you to run "git checkout foo" when there is
no existing local ref or path called "foo", and there is exactly one remote
with a remote-tracking branch called "foo". Git will then automatically
create a new local branch called "foo" using the remote-tracking "foo" as
Hi,
This is third iteration of this series. The only difference from v2 is
improved test code (in patches #1 and #2) thanks to Jonathan Nieder,
and Eric Wong's ACK to patch #6.
Have fun! :)
...Johan
Johan Herland (8):
t2024: Add tests verifying current DWIM behavior of 'git checkout '
t202
On Sun, Apr 21, 2013 at 2:02 PM, Andreas Schwab wrote:
> Junio C Hamano writes:
>
>> Andreas Schwab writes:
>>
>>> Felipe Contreras writes:
>>>
+ if [ -n "${ZSH_VERSION-}" ]; then
+ u="%%"
+ els
On 04/21/2013 08:44 PM, Junio C Hamano wrote:
> Jonathan Nieder writes:
>
>> My personal preference is that patches come on the git list, are
>> reviewed here, and then go to your fork of the Git project that Junio
>> can periodically pull from at your request (like git-svn). But of
>> course th
Ramkumar Ramachandra writes:
> diff --git a/Documentation/git-shortlog.txt b/Documentation/git-shortlog.txt
> index c7f7f51..2a66518 100644
> --- a/Documentation/git-shortlog.txt
> +++ b/Documentation/git-shortlog.txt
> @@ -8,8 +8,8 @@ git-shortlog - Summarize 'git log' output
> SYNOPSIS
>
Junio C Hamano writes:
> Andreas Schwab writes:
>
>> Felipe Contreras writes:
>>
>>> + if [ -n "${ZSH_VERSION-}" ]; then
>>> + u="%%"
>>> + else
>>> + u="%"
>>> +
Jonathan Nieder writes:
> The current definition of 'revision' sounds like it is saying that a
> revision is a tree object. In reality it is just a commit.
>
> This should be especially useful for people used to other revision
> control systems trying to see how familiar concepts translate into
Ramkumar Ramachandra writes:
> '..' is misleading, as there are many other forms that
> 'git log' can accept as an argument. Replace it with ,
> referring to the section "Specifying Ranges" in revisions.txt, and
> rewrite the section appropriately.
>
> Signed-off-by: Ramkumar Ramachandra
> ---
Jonathan Nieder writes:
> My personal preference is that patches come on the git list, are
> reviewed here, and then go to your fork of the Git project that Junio
> can periodically pull from at your request (like git-svn). But of
> course this is up to you, too.
And also me ;-)
Yes, I very mu
Jonathan Nieder writes:
> The thing is, I'm not convinced this is a bad default. "Shows no diff
> at all for merges" is easy for a person to understand. It is much
> easier to understand its limitations than -c and --cc.
Making "log -p -m" a default before -c/--cc was introduced would
have bee
Jonathan Nieder writes:
> That's why if you want to review the code you are pulling in as a
> whole, it is worthwhile to do
>
> git diff HEAD...FETCH_HEAD
>
> That is how you ask "What code changes does FETCH_HEAD introduce?"
> before putting your stamp of approval on them by merging and pu
Jeff King writes:
> On Sat, Apr 20, 2013 at 11:05:39PM -0700, Jonathan Nieder wrote:
>
>> > Cloning into 'new-baz'...
>> > ssh: Could not resolve hostname /tmp/foo: Success
>> > fatal: Could not read from remote repository.
>>
>> Here's a toy patch. I haven't thought carefully about
Jeff King wrote:
> I don't think that is enough. Something like /path/to/foo:bar would
> trigger !is_url already, but then git_connect fails.
Doh. Here's another try, still untested.
diff --git i/connect.c w/connect.c
index 49e56ba3..fe13942f 100644
--- i/connect.c
+++ w/connect.c
@@ -504,6 +50
John Tapsell wrote:
> Jonathan Nieder wrote:
>> If anyone relies on "git log -p" or "git log -p --cc" output to make
>> sure that the untrusted code they use doesn't introduce unwanted
>> behavior, they are making a serious mistake.
[...]
> You can't just push all the blame on the user for bad def
John Tapsell writes:
> On 21 April 2013 11:21, Jonathan Nieder wrote:
>
>> A merge can completely
>> undo important changes made in a side branch and "-c" and "--cc" will
>> not show it.
>
> Wait, what? This is getting even worse then! Can you expand on this please?
>
> And then how do I show
This is similar in spirit to to "make -C dir ..." and "tar -C dir ...".
Currently finding out the status of a git repository that is located
away from the current working directory without going to that directory
can be done in the following ways:
1. (cd ~/foo && git status)
2. git --git-
On 21 April 2013 11:21, Jonathan Nieder wrote:
> John Tapsell wrote:
>
>> I'm concerned that noone is taking this security risk seriously.
>
> If anyone relies on "git log -p" or "git log -p --cc" output to make
> sure that the untrusted code they use doesn't introduce unwanted
> behavior, they ar
224c2171 (remote.c: introduce remote.pushdefault, 2013-04-02)
introduced the remote.pushdefault configuration variable, but forgot
to teach git-completion.bash about it. Fix this.
Signed-off-by: Ramkumar Ramachandra
---
contrib/completion/git-completion.bash | 5 +
1 file changed, 5 inserti
9f765ce (remote.c: introduce branch..pushremote, 2013-04-02)
introduced the configuration variable branch.*.pushremote, but forgot
to teach git-completion.bash about it. Fix this.
Signed-off-by: Ramkumar Ramachandra
---
contrib/completion/git-completion.bash | 4 ++--
1 file changed, 2 insertio
c47ef57 (diff: introduce diff.submodule configuration variable,
2012-11-13) introduced the diff.submodule configuration variable, but
forgot to teach git-completion.bash about it. Fix this.
Signed-off-by: Ramkumar Ramachandra
---
contrib/completion/git-completion.bash | 5 +
1 file changed,
6fac1b83 (completion: add missing config variables, 2009-06-29) added
"rebase" to the list of completions for "branch.*.*", but forgot to
specify completions for the values that this configuration variable
can take (namely "false" and "true"). Fix this.
Signed-off-by: Ramkumar Ramachandra
---
c
df44483a (diff --stat: add config option to limit graph width,
2012-03-01) added the option diff.startGraphWidth to the list of
configuration variables in git-completion.bash, but failed to notice
that the list is sorted alphabetically. Move it to its rightful place
in the list.
Signed-off-by: Ra
Hi,
I just looked at the config section, and started writing patches, and
kept going until I got bored. So they're pretty random.
Sorry about the triviality of the patches: I was just looking to kill
some time on a lazy Sunday afternoon.
Thanks.
Ramkumar Ramachandra (5):
git-completion.bash:
On Sat, Apr 20, 2013 at 7:07 PM, Felipe Contreras
wrote:
> On Sat, Apr 20, 2013 at 6:07 AM, John Szakmeister
> wrote:
>> I really like the idea of remote-hg, but it appears to be awfully slow
>> on the clone step:
>
> The short answer is no. I do have a couple of patches that improve
> performan
On Sat, Apr 20, 2013 at 11:05:39PM -0700, Jonathan Nieder wrote:
> > Cloning into 'new-baz'...
> > ssh: Could not resolve hostname /tmp/foo: Success
> > fatal: Could not read from remote repository.
>
> Here's a toy patch. I haven't thought carefully about whether it's a
> good idea,
Michael Haggerty wrote:
> Add git-multimail, a tool for generating notification emails for
> pushes to a Git repository. It is largely plug-in compatible with
> post-receive-email, and is proposed to eventually replace that script.
> The advantages of git-multimail relative to post-receive-email
Hi,
Michael Haggerty wrote:
> This series consists of a single patch that adds a directory
> contrib/hooks/git-multimail/ containing five files, described in the
> patch's commit message.
Yay! I look forward to seeing it.
[...]
> The first of these commits
This is the third iteration of submitting git-multimail to Git. The
first pass [1] was a modest trial balloon, proposing to add a new
script to live alongside post-receive-email. Following feedback [2]
from the mailing list, I decided to make the script a full replacement
for post-receive-email (
John Tapsell wrote:
> I'm concerned that noone is taking this security risk seriously.
If anyone relies on "git log -p" or "git log -p --cc" output to make
sure that the untrusted code they use doesn't introduce unwanted
behavior, they are making a serious mistake. A merge can completely
undo im
On Fri, Jan 11, 2013 at 12:48 PM, Manlio Perillo
wrote:
> The git-completion.bash script did not implemented full, git aware,
> support to complete paths, for git commands that operate on files within
> the current working directory or the index.
> +__git_index_file_list_filter_compat ()
> +{
> +
Ramkumar Ramachandra wrote:
> Why do you want to
> separate "revisions" (which are really just "extended SHA-1
> expressions" that incidentally resolve to commit objects) and
> "extended SHA-1 expressions that resolve to objects other than
> commits"?
Ramkumar Ramachandra wrote:
> For the record, 'git rev-parse master:README..HEAD@{3}~2' works just
> fine. I don't know whether you want to consider it "sensible" or not,
> but the current revisions.txt is consistent with this.
rev-list errors out though:
error: Object 15bfea is a blob, not a
Junio C Hamano wrote:
> - A revision range is a slice of history. There is no need for
>"committish revision range" as there is no other kinds of ranges.
For the record, 'git rev-parse master:README..HEAD@{3}~2' works just
fine. I don't know whether you want to consider it "sensible" or not
On 21 April 2013 08:26, Junio C Hamano wrote:
> Simon Ruderich writes:
>
>> diff --git a/Documentation/diff-options.txt b/Documentation/diff-options.txt
>> index 104579d..cd35ec7 100644
>> --- a/Documentation/diff-options.txt
>> +++ b/Documentation/diff-options.txt
>> @@ -24,6 +24,10 @@ ifndef::g
There are broadly two problems with the current SYNOPSIS. First, it
completely omits the detail that paths can be specified. Second, it
attempts to list all the options: this is futile as, in addition to
the options unique to it, it accepts all the options that git-rev-list
accepts. In fixing th
The OPTIONS section lists .. as the first item, but this
is inconsistent with the ordering in SYNOPSIS. Move it down until it
appears just before [[--] ...].
Signed-off-by: Ramkumar Ramachandra
---
Documentation/git-log.txt | 14 +++---
1 file changed, 7 insertions(+), 7 deletions(-)
d
In .. and ..., if either or is
omitted, it defaults to 'HEAD'. Add this detail to the document.
Signed-off-by: Ramkumar Ramachandra
---
Documentation/revisions.txt | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/Documentation/revisions.txt b/Documentation/revisions.t
In its current form, the note talks about separating options from
"branch names" and "refnames" in the same sentence. This is entirely
inaccurate, as need not be a set of branch names or
ref names. Rewrite it to use the word "revision range", to be
consistent with the SYNOPSIS.
Signed-off-by: R
"--" is used to separate pathspecs from the rev specs, and not rev
specs from the options, as the shortlog_usage string currently
indicates. In correcting this usage string, make it consistent with
the log_usage string.
Signed-off-by: Ramkumar Ramachandra
---
builtin/shortlog.c | 4 +---
1 file
'..' is misleading, as there are many other forms that
'git log' can accept as an argument. Replace it with ,
referring to the section "Specifying Ranges" in revisions.txt, and
rewrite the section appropriately.
Signed-off-by: Ramkumar Ramachandra
---
Documentation/git-log.txt | 16 +---
To be consistent with the documentation of all the other commands,
remove (-h|--help) from the OPTIONS section.
Signed-off-by: Ramkumar Ramachandra
---
Documentation/git-shortlog.txt | 4
1 file changed, 4 deletions(-)
diff --git a/Documentation/git-shortlog.txt b/Documentation/git-shortlo
In this round, I've incorporated suggestions made by Junio:
[3/7] is entirely new.
[4/7] and [5/7] together re-order and replace '..' with
'', in contrast to a single patch which attempted to
fix '..' in-place in the previous version.
[6/7] uses "the revision range" instad of "revisions".
[7/7]
Andreas Schwab writes:
> Felipe Contreras writes:
>
>> +if [ -n "${ZSH_VERSION-}" ]; then
>> +u="%%"
>> +else
>> +u="%"
>> +fi
>
> aka u="%$
Felipe Contreras writes:
> When this option is enabled, the prompt gets totally screwed in zsh
> because all the codes start with % in zsh (like they are \ in bas). So
> we need to escape the % character.
It is not that I do not believe that $u needs to duplicate %% in
ZSH, but I hate it when I
Felipe Contreras writes:
> When this option is enabled, the prompt gets totally screwed in zsh
> because all the codes start with % in zsh (like they are \ in bas). So
> we need to escape the % character.
It is not that I do not believe that $u needs to duplicate %% in
ZSH, but I hate it when I
On Sun, Apr 21, 2013 at 4:11 AM, Felipe Contreras
wrote:
> When this option is enabled, the prompt gets totally screwed in zsh
> because all the codes start with % in zsh (like they are \ in bas). So
s/bas/bash/
> we need to escape the % character.
>
> Signed-off-by: Felipe Contreras
--
To unsu
Jonathan Nieder writes:
> Ramkumar Ramachandra wrote:
>
>> I would say the most technically accurate
>> description of what 'git log' takes is a "committish range" (basically
>> a "revision range" that resolves to commits).
>
> What is a revision range that doesn't resolve t
Ramkumar Ramachandra wrote:
> ''::
> Include commits that are reachable from (i.e. ancestors of)
> .
>
> This doesn't make sense because might as well refer to a blob*.
> So this should say s// that names a commit object/.
In other words, my fix is to change the meaning of "revisi
Felipe Contreras writes:
> + if [ -n "${ZSH_VERSION-}" ]; then
> + u="%%"
> + else
> + u="%"
> + fi
aka u="%${ZSH_VERSION:+%}"
Andreas.
--
Ramkumar Ramachandra wrote:
> Yes. If master@{3}~2:README isn't a revision, what is it?
An extended SHA1 expression referring to a blob.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.ker
The current definition of 'revision' sounds like it is saying that a
revision is a tree object. In reality it is just a commit.
This should be especially useful for people used to other revision
control systems trying to see how familiar concepts translate into git
terms.
Reported-by: Ramkumar R
Jonathan Nieder wrote:
> Am I wrong
> in thinking revision is nothing more than a synonym for commit?
Yes. If master@{3}~2:README isn't a revision, what is it? And it
fits into the Specifying Revisions section quite snugly: I see no
reason to mangle the meaning of "revision".
--
To unsubscribe f
Junio C Hamano wrote:
> A revision range is a slice of history, so you don't need any further
> adjective.
>
> Please don't introduce new words that do not add any accuracies nor value.
I was just saying: I don't want to introduce new terms either. I
think revisions.txt needs to be fixed. Under
When this option is enabled, the prompt gets totally screwed in zsh
because all the codes start with % in zsh (like they are \ in bas). So
we need to escape the % character.
Signed-off-by: Felipe Contreras
---
contrib/completion/git-prompt.sh | 6 +-
1 file changed, 5 insertions(+), 1 deleti
Ramkumar Ramachandra wrote:
> I would say the most technically accurate
> description of what 'git log' takes is a "committish range" (basically
> a "revision range" that resolves to commits).
What is a revision range that doesn't resolve to commits? Am I wrong
in thinking
Junio C Hamano wrote:
> Sounds like a bug, if it doesn't.
>
> Patches welcome---I suspect that it can be solved the same way as
> the recent cherry-pick patch by Miklos.
It's not as pressing as the glaring Documentation inaccuracies, so
I'll queue the task.
To exclude this case, I would say the m
Junio C Hamano wrote:
> I think you are trying explain "git log --short A B ^C" as if it
> takes "--short" (which is an option), "A", "B", and "^C" (all of
> which are revisions). And I am saying that is wrong.
>
> It is "--short" (which is an option) and "A B ^C" (which is a
> revision range).
G
Ramkumar Ramachandra writes:
> ... and what about 'git log HEAD^!'? Is that a range?
Of course it _is_ a range; didn't you read it in the "specifying
ranges" section? It is a short-hand for "include HEAD, exclude its
parents", and you can further combine it with other starting points.
> Wha
Ramkumar Ramachandra wrote:
> What's so confusing about it?
[...]
> revision:: A particular state of files and directories which was
> stored in the object database. It is referenced by a commit object.
So a revision is a tree? ("one of the things pointed to by a commit
object, representing a pa
Junio C Hamano writes:
> Ramkumar Ramachandra writes:
>
>> Junio C Hamano wrote:
>>> I think "branch names" was an attempt to make it more newbie
>>> friendly by sacrificing technical accuracy. With the suggested
>>> update (see the review for the previous one), it would be easier to
>>> read i
> On Fri, Apr 19, 2013 at 10:25:46AM -0700, Junio C Hamano wrote:
>>> Junio C Hamano wrote:
You ran 'git add' with neither '-A (--all)' or '--no-all', whose
behaviour will change in Git 2.0 with respect to paths you
removed from your working tree.
* 'git ad
Junio C Hamano wrote:
> A list of revisions is merely a way to specify "revision range" that
> are reachable from any of these revisions listed. "log A B" won't
> stop by just showing A and B (that would be "show A B"), but will
> list those that are reachable from A B, so in the context of
> disc
Ramkumar Ramachandra writes:
> Junio C Hamano wrote:
>> I think "branch names" was an attempt to make it more newbie
>> friendly by sacrificing technical accuracy. With the suggested
>> update (see the review for the previous one), it would be easier to
>> read if this part said "options or the
Junio C Hamano wrote:
> I think "branch names" was an attempt to make it more newbie
> friendly by sacrificing technical accuracy. With the suggested
> update (see the review for the previous one), it would be easier to
> read if this part said "options or the revision range".
Why does it have to
Simon Ruderich writes:
> diff --git a/Documentation/diff-options.txt b/Documentation/diff-options.txt
> index 104579d..cd35ec7 100644
> --- a/Documentation/diff-options.txt
> +++ b/Documentation/diff-options.txt
> @@ -24,6 +24,10 @@ ifndef::git-format-patch[]
> --patch::
> Generate patch (
Jonathan Nieder writes:
> Ramkumar Ramachandra wrote:
>
>> First, and are ways to specify "revisions", not
>> "commits", as gitrevisions.txt would indicate.
>
> What's the difference between a revision and a commit? The definition
> in gitglossary(7) only confuses me.
They are the same, but I
Jonathan Nieder wrote:
> What's the difference between a revision and a commit? The definition
> in gitglossary(7) only confuses me.
What's so confusing about it?
commit:: As a noun: A single point in the Git history; the entire
history of a project is represented as a set of interrelated commit
Jonathan Nieder writes:
> Junio C Hamano wrote:
>
>> But a _real user_ who wants to use a slash there has no way of doing
>> so.
>
> Doesn't foo=// do that in the msys world?
"that" refers to...? Do you mean:
$ value=/; mycmd key="$value"
breaks msys, but you can say
$ value=//;
Ramkumar Ramachandra writes:
> +..::
> + Consider only commits between the named two revisions. When
> + either or is omitted, it defaults to `HEAD`,
> + i.e. the tip of the current branch. For a more complete list
> + of ways to spell .., see
> + linkgit:gitrevisions[7].
94 matches
Mail list logo
