Hi,
William Giokas wrote:
$ git clone /tmp/foo:bar/baz /tmp/new-baz
but running this gives me this output::
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
On Sat, Apr 20, 2013 at 11:36 PM, Ramkumar Ramachandra
artag...@gmail.com wrote:
Felipe Contreras wrote:
To complement the reason; the zsh folks (or perhaps it's only one; who
works on the git stuff), absolutely prioritize correctness over
speed, that means if it takes ten seconds to list all
Johannes Sixt wrote:
Am 21.04.2013 02:05, schrieb Jonathan Nieder:
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? If I am reading
mingw/msys/rt/src/winsup/cygwin/path.cc correctly then the way to
Ramkumar Ramachandra artag...@gmail.com writes:
First, since and until are ways to specify revisions, not
commits, as gitrevisions.txt would indicate. Second,
'since..until' is simply indicative of how users would normally
want to specify the rev spec: it need not conform to this form, and
Ramkumar Ramachandra artag...@gmail.com writes:
In its current form, the note talks about separating options from
branch names and refnames in the same sentence. This is entirely
inaccurate, as the rev spec need not be a set of branch names or ref
names. Rewrite it to use the word
Felipe Contreras wrote:
First of all, 'gitfast' is just the name I gave to the oh-my-zsh
plugin that uses git.git's completion stuff. The zsh support in git's
bash completion has been working for years, I just copied the stuff to
oh-my-zsh so those guys can use it easily.
Yeah, I know. I
Ramkumar Ramachandra artag...@gmail.com writes:
+since..until::
+ Consider only commits between the named two revisions. When
+ either since or until is omitted, it defaults to `HEAD`,
+ i.e. the tip of the current branch. For a more complete list
+ of ways to spell
Jonathan Nieder jrnie...@gmail.com 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
$
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
Jonathan Nieder jrnie...@gmail.com writes:
Ramkumar Ramachandra wrote:
First, since and until 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
Simon Ruderich si...@ruderich.org 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::
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 be a
Ramkumar Ramachandra artag...@gmail.com 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
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
discussing the
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 add --no-all pathspec',
Junio C Hamano gits...@pobox.com writes:
Ramkumar Ramachandra artag...@gmail.com 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
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
Ramkumar Ramachandra artag...@gmail.com 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
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).
Got it. Your
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 most
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
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 felipe.contre...@gmail.com
---
contrib/completion/git-prompt.sh | 6 +-
1 file
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 the
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 from
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
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
Felipe Contreras felipe.contre...@gmail.com writes:
+ if [ -n ${ZSH_VERSION-} ]; then
+ u=%%
+ else
+ u=%
+ fi
aka u=%${ZSH_VERSION:+%}
Ramkumar Ramachandra wrote:
'rev'::
Include commits that are reachable from (i.e. ancestors of)
rev.
This doesn't make sense because rev might as well refer to a blob*.
So this should say s/rev/rev that names a commit object/.
In other words, my fix is to change the meaning
Jonathan Nieder jrnie...@gmail.com 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
On Sun, Apr 21, 2013 at 4:11 AM, Felipe Contreras
felipe.contre...@gmail.com 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
Felipe Contreras felipe.contre...@gmail.com 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
Felipe Contreras felipe.contre...@gmail.com 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
Andreas Schwab sch...@linux-m68k.org writes:
Felipe Contreras felipe.contre...@gmail.com writes:
+if [ -n ${ZSH_VERSION-} ]; then
+u=%%
+else
+u=%
+
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 'since..until' with
'revision range', in contrast to a single patch which attempted to
fix 'since..until' in-place in the previous version.
[6/7] uses the revision
To be consistent with the documentation of all the other commands,
remove (-h|--help) from the OPTIONS section.
Signed-off-by: Ramkumar Ramachandra artag...@gmail.com
---
Documentation/git-shortlog.txt | 4
1 file changed, 4 deletions(-)
diff --git a/Documentation/git-shortlog.txt
'since..until' is misleading, as there are many other forms that
'git log' can accept as an argument. Replace it with revision range,
referring to the section Specifying Ranges in revisions.txt, and
rewrite the section appropriately.
Signed-off-by: Ramkumar Ramachandra artag...@gmail.com
---
In its current form, the note talks about separating options from
branch names and refnames in the same sentence. This is entirely
inaccurate, as revision range 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.
In rev1..rev2 and rev1...rev2, if either rev1 or rev2 is
omitted, it defaults to 'HEAD'. Add this detail to the document.
Signed-off-by: Ramkumar Ramachandra artag...@gmail.com
---
Documentation/revisions.txt | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git
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
On 21 April 2013 08:26, Junio C Hamano gits...@pobox.com wrote:
Simon Ruderich si...@ruderich.org 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
@@
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,
but
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
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
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
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
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 are
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, but
On Sat, Apr 20, 2013 at 7:07 PM, Felipe Contreras
felipe.contre...@gmail.com wrote:
On Sat, Apr 20, 2013 at 6:07 AM, John Szakmeister j...@szakmeister.net
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
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):
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 artag...@gmail.com
---
contrib/completion/git-completion.bash | 5
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
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 artag...@gmail.com
---
contrib/completion/git-completion.bash | 5 +
1 file
On 21 April 2013 11:21, Jonathan Nieder jrnie...@gmail.com 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,
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
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
Jeff King p...@peff.net 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
Jonathan Nieder jrnie...@gmail.com 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
Jonathan Nieder jrnie...@gmail.com 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
Jonathan Nieder jrnie...@gmail.com 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 ;-)
Ramkumar Ramachandra artag...@gmail.com writes:
'since..until' is misleading, as there are many other forms that
'git log' can accept as an argument. Replace it with revision range,
referring to the section Specifying Ranges in revisions.txt, and
rewrite the section appropriately.
Junio C Hamano gits...@pobox.com writes:
Andreas Schwab sch...@linux-m68k.org writes:
Felipe Contreras felipe.contre...@gmail.com writes:
+ if [ -n ${ZSH_VERSION-} ]; then
+ u=%%
+ else
+
Ramkumar Ramachandra artag...@gmail.com 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
On 04/21/2013 08:44 PM, Junio C Hamano wrote:
Jonathan Nieder jrnie...@gmail.com 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
On Sun, Apr 21, 2013 at 2:02 PM, Andreas Schwab sch...@linux-m68k.org wrote:
Junio C Hamano gits...@pobox.com writes:
Andreas Schwab sch...@linux-m68k.org writes:
Felipe Contreras felipe.contre...@gmail.com writes:
+ if [ -n ${ZSH_VERSION-} ]; then
+
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 branch'
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
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.
Improved-by:
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 starting
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 with
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
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 any
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:
- If
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
Felipe Contreras felipe.contre...@gmail.com writes:
On Sun, Apr 21, 2013 at 2:02 PM, Andreas Schwab sch...@linux-m68k.org wrote:
Junio C Hamano gits...@pobox.com writes:
Andreas Schwab sch...@linux-m68k.org writes:
Felipe Contreras felipe.contre...@gmail.com writes:
+
Michael Haggerty mhag...@alum.mit.edu 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
Michael Haggerty mhag...@alum.mit.edu 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
On Sun, Apr 21, 2013 at 5:00 PM, Junio C Hamano gits...@pobox.com wrote:
Felipe Contreras felipe.contre...@gmail.com writes:
On Sun, Apr 21, 2013 at 2:02 PM, Andreas Schwab sch...@linux-m68k.org
wrote:
Junio C Hamano gits...@pobox.com writes:
Andreas Schwab sch...@linux-m68k.org writes:
Jonathan Nieder jrnie...@gmail.com writes:
How about something like this?
warning: git add run on path with files removed (e.g., '%s')
hint: use git add --ignore-removals pathspec to ignore removals
hint: or git add --no-ignore-removals pathspec to notice them
hint:
Junio C Hamano gits...@pobox.com 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 start and end
can take... is not indented to the same level as its first
Junio C Hamano gits...@pobox.com 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
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
'since..until' to 'revision range' everywhere else. We use
'revision range' here too.
[4/7] has been replaced with the version Junio fixed
To be consistent with the documentation of all the other commands,
remove (-h|--help) from the OPTIONS section.
Signed-off-by: Ramkumar Ramachandra artag...@gmail.com
---
Documentation/git-shortlog.txt | 4
1 file changed, 4 deletions(-)
diff --git a/Documentation/git-shortlog.txt
In rev1..rev2 and rev1...rev2, if either rev1 or rev2 is
omitted, it defaults to 'HEAD'. Add this detail to the document.
Signed-off-by: Ramkumar Ramachandra artag...@gmail.com
---
Documentation/revisions.txt | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git
The OPTIONS section lists since..until as the first item, but this
is inconsistent with the ordering in SYNOPSIS. Move it down until it
appears just before [[--] path...].
Signed-off-by: Ramkumar Ramachandra artag...@gmail.com
---
Documentation/git-log.txt | 14 +++---
1 file changed, 7
'since..until' is misleading, as there are many other forms that
'git log' can accept as an argument. Replace it with revision range,
referring to the section Specifying Ranges in revisions.txt, and
rewrite the section appropriately.
Signed-off-by: Ramkumar Ramachandra artag...@gmail.com
---
In its current form, the note talks about separating options from
branch names and refnames in the same sentence. This is entirely
inaccurate, as revision range 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.
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
-- 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 artag...@gmail.com
---
builtin/shortlog.c
88 matches
Mail list logo
