Hi all,
I have discovered a minor security vulnerability. I could send the
patch to the mailing list, but I wanted someone else to take a look
first just to make sure it's minor enough that folks will think it's OK
to publicly announce.
Who should I send the patch to?
Thanks,
Richard
--
To
the shells do not recursively expand, this
avoids arbitrary code execution by specially-crafted branch names such
as '$(IFS=_;cmd=sudo_rm_-rf_/;$cmd)'.
Signed-off-by: Richard Hansen rhan...@bbn.com
---
To see the vulnerability in action, follow the instructions at:
https://github.com/richardhansen
On 2014-04-21 16:24, Jeff King wrote:
On Mon, Apr 21, 2014 at 03:07:28PM -0400, Richard Hansen wrote:
Both bash and zsh subject the value of PS1 to parameter expansion,
command substitution, and arithmetic expansion. Rather than include
the raw, unescaped branch name in PS1 when running
On 2014-04-21 18:33, Junio C Hamano wrote:
Junio C Hamano gits...@pobox.com writes:
Richard Hansen rhan...@bbn.com writes:
Both bash and zsh subject the value of PS1 to parameter expansion,
command substitution, and arithmetic expansion. Rather than include
the raw, unescaped branch name
the shells do not recursively expand, this
avoids arbitrary code execution by specially-crafted branch names such
as '$(IFS=_;cmd=sudo_rm_-rf_/;$cmd)'.
Signed-off-by: Richard Hansen rhan...@bbn.com
---
Changes since v1: update t/t9903-bash-prompt.sh
contrib/completion/git-prompt.sh | 34
On 2014-04-22 13:38, Junio C Hamano wrote:
Michael Haggerty mhag...@alum.mit.edu writes:
While we're at it, I think it would be prudent to ban '-' at the
beginning of reference name segments. For example, reference names like
refs/heads/--cmd=/sbin/halt
On 2014-04-25 03:37, Simon Oosthoek wrote:
(though tbh, I think you'd have to be in an automated situation
to check out a branch that is basically a command to hack your
system, a human would probably figure it too cumbersome, or too
fishy)
You can get in trouble by cloning a malicious
On 2014-04-29 07:17, Felipe Contreras wrote:
Also 'branch.name.rebase' to 'branch.name.pullmode'.
This way 'pull.mode' can be set to 'merge', and the default can be
something else.
The old configurations still work, but get deprecated.
Should users be warned if both pull.rebase and
On 2014-04-28 06:55, Nguyễn Thái Ngọc Duy wrote:
From the user point of view, this reduces the writable size of index
down to the number of updated files. For example my webkit index v4 is
14MB. With a fresh split, I only have to update an index of 200KB.
Every file I touch will add about 80
On 2014-05-01 20:00, Felipe Contreras wrote:
Also 'branch.name.rebase' to 'branch.name.pullmode'.
This way we can add more modes and the default can be something else,
namely it can be set to merge-ff-only, so eventually we can reject
non-fast-forward merges by default.
The old
On 2014-05-02 17:12, Felipe Contreras wrote:
Richard Hansen wrote:
Should branch.autosetuprebase be replaced with a new
branch.autosetupmode setting?
Maybe. But if so, I think that should be done in another series.
Otherwise we'll never have a chance to change anything.
Sure
On 2014-05-02 14:13, Junio C Hamano wrote:
Stepping back even further, and thinking what is different between
these two pulls, we notice that the first one is pulling from the
place we push back to.
I think the fundamental difference is in the relationship between the
local and the remote
On 2014-05-03 05:26, Felipe Contreras wrote:
Richard Hansen wrote:
I think the fundamental difference is in the relationship between the
local and the remote branch (which branch derives from the other).
The relationship between the branches determines what the user wants
from 'git pull
On 2014-05-03 23:08, Felipe Contreras wrote:
Richard Hansen wrote:
Or are you proposing that pull --merge should reverse the parents if and
only if the remote ref is @{u}?
Only if no remote or branch are specified `git pull --merge`.
OK. Let me summarize to make sure I understand your full
On 2014-05-04 06:17, Felipe Contreras wrote:
Richard Hansen wrote:
On 2014-05-03 23:08, Felipe Contreras wrote:
It is the only solution that has been proposed.
It's not the only proposal -- I proposed a few alternatives in my
earlier email (though not in the form of code), and others have
On 2014-05-04 17:13, Felipe Contreras wrote:
Richard Hansen wrote:
On 2014-05-04 06:17, Felipe Contreras wrote:
Richard Hansen wrote:
On 2014-05-03 23:08, Felipe Contreras wrote:
It is the only solution that has been proposed.
It's not the only proposal -- I proposed a few alternatives
On 2014-05-03 06:00, John Szakmeister wrote:
FWIW, at my company, we took another approach. We introduced a `git
ffwd` command that fetches from all remotes, and fast-forwards all
your local branches that are tracking a remote, and everyone on the
team uses it all the time. It should be said
branch names in $PS1): zsh does not expand PS1
by default, but that commit assumed it did. The bug resulted in
prompts containing the literal string '${__git_ps1_branch_name}'
instead of the actual branch name.
Reported-by: Caleb Thompson ca...@calebthompson.io
Signed-off-by: Richard Hansen rhan
On 2014-05-19 19:46, Junio C Hamano wrote:
Jason St. John jstj...@purdue.edu writes:
@@ -53,7 +53,7 @@ Updates since v1.9 series
UI, Workflows Features
* The multi-mail post-receive hook (in contrib/) has been updated
- to a more recent version from the upstream.
+ to a more
On 2014-05-20 20:24, Junio C Hamano wrote:
Fixes since v1.9 series
---
Unless otherwise noted, all the fixes since v1.9 in the maintenance
track are contained in this release (see the maintenance releases'
notes for details).
[...]
* The shell prompt script (in
On 2014-09-30 11:36, Julien Carsique wrote:
From: Julien Carsique julien.carsi...@gmail.com
When using the name option of GIT_PS1_SHOWUPSTREAM to show the upstream
abbrev name, if the upstream name is the same as the local name, then some
space could be saved in the prompt. This is
On 2014-09-30 18:35, Junio C Hamano wrote:
Richard Hansen rhan...@bbn.com writes:
* While this syntax works in both Bash and Zsh (assuming no
pattern-special characters), my preference is to stick to POSIX[1]
when possible.
Nah. The existing script is full of bash-isms like local
in reality. :)
I'll send an updated patch asap. Tell me if I forgot something.
Your list looks complete to me. Thank you for contributing!
-Richard
Regards,
Julien
On 01/10/2014 19:49, Junio C Hamano wrote:
Richard Hansen rhan...@bbn.com writes:
and there is no hope to fix them
On 2014-10-08 15:04, Jess Austin wrote:
Introduce a new environmental variable, GIT_PS1_OMITIGNORED, which
tells __git_ps1 to display nothing when the current directory is
set (e.g. via .gitignore) to be ignored by git. In the absence of
GIT_PS1_OMITIGNORED this change has no effect.
Many
On 2014-10-08 17:37, Jess Austin wrote:
On Wed, Oct 8, 2014 at 4:12 PM, Richard Hansen rhan...@bbn.com wrote:
On 2014-10-08 15:04, Jess Austin wrote:
Introduce a new environmental variable, GIT_PS1_OMITIGNORED, which
tells __git_ps1 to display nothing when the current directory is
set (e.g
On 2014-10-09 06:27, Jess Austin wrote:
On Thu, Oct 9, 2014 at 12:37 AM, Richard Hansen rhan...@bbn.com wrote:
On 2014-10-08 17:37, Jess Austin wrote:
On Wed, Oct 8, 2014 at 4:12 PM, Richard Hansen rhan...@bbn.com wrote:
On 2014-10-08 15:04, Jess Austin wrote:
Introduce a new environmental
On 2014-10-14 14:47, Johannes Sixt wrote:
Am 14.10.2014 um 04:32 schrieb Jess Austin:
diff --git a/contrib/completion/git-prompt.sh
b/contrib/completion/git-prompt.sh
index c5473dc..d7559ff 100644
--- a/contrib/completion/git-prompt.sh
+++ b/contrib/completion/git-prompt.sh
@@ -84,6 +84,11
that noise.
Signed-off-by: Jess Austin jess.aus...@gmail.com
---
On Thu, Oct 9, 2014 at 5:09 PM, Richard Hansen rhan...@bbn.com wrote:
On 2014-10-09 06:27, Jess Austin wrote:
Would you want this configured in each repo (i.e. via a line in
.git/config),
or would you prefer something global so
On 2014-10-15 00:06, Jess Austin wrote:
@@ -501,6 +506,13 @@ __git_ps1 ()
local f=$w$i$s$u
local gitstring=$c$b${f:+$z$f}$r$p
+ if [ -n ${GIT_PS1_HIDE_IF_PWD_IGNORED} ]
+[ $(git config --bool bash.hideIfPwdIgnored) != false ]
+git check-ignore -q .
+
The documentation contains a mix of the two spellings, so include both
in the glossary so that a search for either will lead to the
definition.
Signed-off-by: Richard Hansen rhan...@bbn.com
---
Documentation/glossary-content.txt | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git
Signed-off-by: Richard Hansen rhan...@bbn.com
---
Documentation/glossary-content.txt | 18 ++
1 file changed, 14 insertions(+), 4 deletions(-)
diff --git a/Documentation/glossary-content.txt
b/Documentation/glossary-content.txt
index a2edcc3..44d524b 100644
--- a/Documentation
')
* standardize on 'committish' (don't use 'commit-ish')
* don't base the definition of 'committish' on the broken definition
of 'ref'
* fix the definition of 'treeish' so that it is not based on the
broken definition of 'ref'
* fix the definiton of 'ref'
Richard Hansen (7):
glossary
'
* some search engines don't handle hyphens gracefully
Signed-off-by: Richard Hansen rhan...@bbn.com
---
Documentation/RelNotes/1.6.0.5.txt | 2 +-
Documentation/RelNotes/1.6.2.4.txt | 2 +-
Documentation/RelNotes/1.8.1.2.txt | 2 +-
Documentation/RelNotes/1.8.2.txt
If possible, rev will be dereferenced even if it is not a tag type
(e.g., commit dereferenced to a tree).
Signed-off-by: Richard Hansen rhan...@bbn.com
---
Documentation/revisions.txt | 12
1 file changed, 8 insertions(+), 4 deletions(-)
diff --git a/Documentation/revisions.txt b
Users can already ensure that rev is a tag object by checking the
output of 'git cat-file -t rev', but:
* users may expect rev^{tag} to exist given that rev^{commit},
rev^{tree}, and rev^{blob} all exist
* this syntax is more convenient/natural in some circumstances
Signed-off-by: Richard
On 2013-09-03 03:05, Jeff King wrote:
FWIW, this makes sense to me.
Thank you for the feedback. I posted a reroll of the patch that you've
already replied to, but for the benefit of others searching the mailing
list archive, v3 can be found at
On 2013-09-03 15:03, Eric Sunshine wrote:
On Tue, Sep 3, 2013 at 1:37 PM, Richard Hansen rhan...@bbn.com wrote:
diff --git a/t/t1511-rev-parse-caret.sh b/t/t1511-rev-parse-caret.sh
index eaefc77..5771cbd 100755
--- a/t/t1511-rev-parse-caret.sh
+++ b/t/t1511-rev-parse-caret.sh
@@ -54,6 +61,26
Users can already ensure that rev is a tag object by checking the
output of 'git cat-file -t rev', but:
* users may expect rev^{tag} to exist given that rev^{commit},
rev^{tree}, and rev^{blob} all exist
* this syntax is more convenient/natural in some circumstances
Signed-off-by: Richard
Signed-off-by: Richard Hansen rhan...@bbn.com
---
Documentation/glossary-content.txt | 18 ++
1 file changed, 14 insertions(+), 4 deletions(-)
diff --git a/Documentation/glossary-content.txt
b/Documentation/glossary-content.txt
index 3466ce9..7ad13e1 100644
--- a/Documentation
If possible, rev will be dereferenced even if it is not a tag type
(e.g., commit dereferenced to a tree).
Signed-off-by: Richard Hansen rhan...@bbn.com
---
Documentation/revisions.txt | 12
1 file changed, 8 insertions(+), 4 deletions(-)
diff --git a/Documentation/revisions.txt b
?
I'm not 100% confident that these don't break translations, although
it still builds and make test passes.
Changes since v2:
* standardize on 'tree-ish' instead of 'treeish'
* standardize on 'commit-ish' instead of 'committish'
Richard Hansen (7):
glossary: mention 'treeish
Signed-off-by: Richard Hansen rhan...@bbn.com
---
Documentation/glossary-content.txt | 12
1 file changed, 12 insertions(+)
diff --git a/Documentation/glossary-content.txt
b/Documentation/glossary-content.txt
index 0273095..47e901e 100644
--- a/Documentation/glossary-content.txt
The documentation contains a mix of the two spellings, so include both
in the glossary so that a search for either will lead to the
definition.
Signed-off-by: Richard Hansen rhan...@bbn.com
---
Documentation/glossary-content.txt | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git
A tree-ish isn't a ref. Also, mention dereferencing, and that a
commit dereferences to a tree, to support gitrevisions(7) and
rev-parse's error messages.
Signed-off-by: Richard Hansen rhan...@bbn.com
---
Documentation/glossary-content.txt | 15 ---
1 file changed, 12 insertions
]
Signed-off-by: Richard Hansen rhan...@bbn.com
---
Documentation/config.txt | 4 ++--
Documentation/git-describe.txt | 14 +++---
Documentation/git-fast-import.txt| 26 +-
Documentation/git-name-rev.txt
Replace 'treeish' in documentation and comments with 'tree-ish' to
match gitglossary(7).
The only remaining instances of 'treeish' are:
* variable, function, and macro names
* (also treeish) in the definition of tree-ish in gitglossary(7)
Signed-off-by: Richard Hansen rhan...@bbn.com
On 2013-09-04 18:59, Junio C Hamano wrote:
Philip Oakley philipoak...@iee.org writes:
From: Junio C Hamano gits...@pobox.com
John Keeping j...@keeping.me.uk writes:
I think there are two distinct uses for pull, which boil down to:
(1) git pull
...
Peff already covered (1)---it is
Pass a list of open bzrlib.transport.Transport objects to each bzrlib
function that might create a transport. This enables bzrlib to reuse
existing transports when possible, avoiding multiple concurrent
connections to the same remote server.
If the remote server is accessed via ssh, this fixes a
On 2013-09-07 19:58, Richard Hansen wrote:
Pass a list of open bzrlib.transport.Transport objects to each bzrlib
function that might create a transport. This enables bzrlib to reuse
existing transports when possible, avoiding multiple concurrent
connections to the same remote server
On 2013-09-07 20:30, Felipe Contreras wrote:
On Sat, Sep 7, 2013 at 7:02 PM, Richard Hansen rhan...@bbn.com wrote:
On 2013-09-07 19:58, Richard Hansen wrote:
Pass a list of open bzrlib.transport.Transport objects to each bzrlib
function that might create a transport. This enables bzrlib
on the Python garbage
collector to trigger ssh session termination.)
Signed-off-by: Richard Hansen rhan...@bbn.com
---
Changes from v1:
* add Signed-off-by line
contrib/remote-helpers/git-remote-bzr | 33 +
1 file changed, 21 insertions(+), 12 deletions(-)
diff
On 2013-09-07 22:41, Felipe Contreras wrote:
On Wed, Sep 4, 2013 at 5:59 PM, Junio C Hamano gits...@pobox.com wrote:
Which can be solved by adding the above fail option, and then
renaming them to pull.integrate and branch.name.integrate to
clarify what these variables are about (it is no
On 2013-09-08 14:10, Junio C Hamano wrote:
Richard Hansen rhan...@bbn.com writes:
What about something like:
pull.mergeoptions (defaults to --ff-only)
pull.rebaseoptions (defaults to empty? --preserve-merges?)
branch.name.pull.mergeoptions (defaults to pull.mergeoptions
On 2013-09-08 21:23, Felipe Contreras wrote:
The old configurations still work, but get deprecated.
Should some tests for the deprecated configs be added? We wouldn't want
to accidentally break those.
diff --git a/Documentation/config.txt b/Documentation/config.txt
index ec57a15..9489a59
On 2013-09-09 16:44, Jeff King wrote:
On Mon, Sep 09, 2013 at 09:24:35PM +0100, John Keeping wrote:
I think we need to make sure that we give instructions for how to go
back if the default hasn't done what you wanted. Something like this:
Your pull did not fast-forward, so Git has merged
On 2013-09-10 18:01, Junio C Hamano wrote:
Junio C Hamano gits...@pobox.com writes:
Richard Hansen rhan...@bbn.com writes:
def do_export(parser):
-global parsed_refs, dirname
+global parsed_refs, dirname, transports
As this has been acked by Felipe who knows the script the best
applies
to the file.
The phrase accompanies the file was chosen to support different
default licenses in different subdirectories (e.g., 2-clause BSD for
vcs-svn/*, LGPL2.1+ for xdiff/*).
Signed-off-by: Richard Hansen rhan...@bbn.com
---
I'm bringing this up because, to this layman's eyes, it seems like
On 2013-09-12 18:44, Linus Torvalds wrote:
On Thu, Sep 12, 2013 at 3:30 PM, Junio C Hamano gits...@pobox.com wrote:
Linus, this is not limited to us, so I am bothering you; sorry about
that.
My instinct tells me that some competent lawyers at linux-foundation
helped you with the wording of
}
error: v1.8.3.1^{}^{tag}: expected tag type, but the object dereferences to
tree type
fatal: Needed a single revision
Signed-off-by: Richard Hansen rhan...@bbn.com
---
sha1_name.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/sha1_name.c b/sha1_name.c
index 90419ef..68fd0e4
Signed-off-by: Richard Hansen rhan...@bbn.com
---
Documentation/glossary-content.txt | 11 +++
1 file changed, 11 insertions(+)
diff --git a/Documentation/glossary-content.txt
b/Documentation/glossary-content.txt
index 01365d9..a3cc003 100644
--- a/Documentation/glossary-content.txt
The documentation for the rev^{type} syntax (e.g.,
v1.8.3.1^{tree}) needed some fixing, and while I was at it I thought
I'd be pedantic about tree-ish. Oh, and let's welcome committish to
the party!
-Richard
Richard Hansen (4):
glossary: add 'treeish' as a synonym for 'tree-ish'
glossary
The documentation contains a mix of the two spellings, and including
both makes it possible for users to search the glossary with their
spelling of choice.
Signed-off-by: Richard Hansen rhan...@bbn.com
---
Documentation/glossary-content.txt | 2 +-
1 file changed, 1 insertion(+), 1 deletion
If possible, rev will be dereferenced even if it is not a tag type
(e.g., commit dereferenced to a tree).
Signed-off-by: Richard Hansen rhan...@bbn.com
---
Documentation/revisions.txt | 12
1 file changed, 8 insertions(+), 4 deletions(-)
diff --git a/Documentation/revisions.txt b
Mention dereferencing, and that a commit dereferences to a tree, to
support gitrevisions(7) and rev-parse's error messages.
Signed-off-by: Richard Hansen rhan...@bbn.com
---
Documentation/glossary-content.txt | 16 +---
1 file changed, 13 insertions(+), 3 deletions(-)
diff --git
On 2013-06-19 00:19, Ramkumar Ramachandra wrote:
Is master~3 a committish? What about :/foomery?
Yes; as documented, both of those are refs that point to a commit.
Look at the other forms in gitrevisions(7); master:quuxery,
master^{tree} are notable exceptions.
gitrevisions(7) says that
On 2013-06-19 01:56, Ramkumar Ramachandra wrote:
From gitglossary(7):
ref
A 40-byte hex representation of a SHA-1 or a name that denotes a
particular object. They may be stored in a file under $GIT_DIR/refs/
directory, or in the $GIT_DIR/packed-refs file.
Do master~3 and
On 2013-06-19 11:31, Richard Hansen wrote:
On 2013-06-19 01:56, Ramkumar Ramachandra wrote:
From gitglossary(7):
ref
A 40-byte hex representation of a SHA-1 or a name that denotes a
particular object. They may be stored in a file under $GIT_DIR/refs/
directory
On 2013-06-19 13:09, Junio C Hamano wrote:
Richard Hansen rhan...@bbn.com writes:
The documentation contains a mix of the two spellings, and including
both makes it possible for users to search the glossary with their
spelling of choice.
Is it an option to instead find dashless form
On 2013-06-19 13:14, Junio C Hamano wrote:
object-type-ish does not have anything to do with a ref. Even
when an object is dangling in your object store without being
reachable from any of your refs, it keeps its own ish-ness.
Ah, so your personal definition of ref matches my personal
On 2013-06-19 14:38, Junio C Hamano wrote:
Richard Hansen rhan...@bbn.com writes:
gitrevisions(7) implies that rev^{tag} should work,...
Does it? Is it possible that that should be fixed?
Depends on whether you think ^{tag} is a useful feature or not; see below.
What does it even
On 2013-06-19 13:09, Junio C Hamano wrote:
Richard Hansen rhan...@bbn.com writes:
The documentation contains a mix of the two spellings, and including
both makes it possible for users to search the glossary with their
spelling of choice.
Is it an option to instead find dashless form
On 2013-06-19 17:05, Junio C Hamano wrote:
Richard Hansen rhan...@bbn.com writes:
On 2013-06-19 13:14, Junio C Hamano wrote:
object-type-ish does not have anything to do with a ref. Even
when an object is dangling in your object store without being
reachable from any of your refs, it keeps
On 2013-06-19 18:36, Junio C Hamano wrote:
Ahh. If you had quoted [...] a few exchanges ago I would have
immediately understood what you were trying to say.
Sorry about that, my bad.
In today's world (after packed-refs was introduced), probably
A name that begins with refs/ (e.g.
It looks like commit f8246281af9adb0fdddbcc90d2e19cb5cd5217e5
unintentionally removed the documentation for the `-e` option.
Signed-off-by: Richard Hansen rhan...@bbn.com
---
Documentation/merge-options.txt | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/Documentation/merge
On 2013-09-09 18:49, Felipe Contreras wrote:
On Mon, Sep 9, 2013 at 4:23 PM, Richard Hansen rhan...@bbn.com wrote:
On 2013-09-08 21:23, Felipe Contreras wrote:
The old configurations still work, but get deprecated.
Should some tests for the deprecated configs be added? We wouldn't want
On 2013-08-29 11:23, Felipe Contreras wrote:
Here are the patches that allow transport helpers to be completely
transparent;
renaming branches, deleting them, custom refspecs, --force, --dry-run,
reporting forced update, everything works.
What is the status of these patches?
I would like to
On 2013-08-29 11:23, Felipe Contreras wrote:
For remote-helpers that use 'export' to push.
Signed-off-by: Felipe Contreras felipe.contre...@gmail.com
---
t/t5801-remote-helpers.sh | 8
transport-helper.c| 11 ++-
2 files changed, 14 insertions(+), 5 deletions(-)
On 2013-08-29 11:23, Felipe Contreras wrote:
So that we can covert the exported ref names.
Signed-off-by: Felipe Contreras felipe.contre...@gmail.com
---
Documentation/git-fast-export.txt | 4
builtin/fast-export.c | 30 ++
On 2013-08-29 11:23, Felipe Contreras wrote:
Otherwise they cannot know when to force the push or not (other than
hacks).
Signed-off-by: Felipe Contreras felipe.contre...@gmail.com
---
transport-helper.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/transport-helper.c
On 2013-10-11 19:56, Felipe Contreras wrote:
Matthieu Moy wrote:
Felipe Contreras felipe.contre...@gmail.com writes:
On Mon, Sep 9, 2013 at 9:21 PM, Jeff King p...@peff.net wrote:
On Mon, Sep 09, 2013 at 05:49:36PM -0500, Felipe Contreras wrote:
These deprecation warning messages should be
On 2013-10-11 22:08, Felipe Contreras wrote:
I'm fine with 'echo warning: foo 2', but still, if you really
cared about consistency, there would be a warn() function
So add one! It's only one simple line:
warning() { printf %s\\n warning: $* 2; }
So much discussion for something so
Patch 2/10 (transport-helper: fix extra lines) deleted one copy of the
lines; patch 9/10 (transport-helper: add support to delete branches)
should delete the other copy of the lines.
Signed-off-by: Richard Hansen rhan...@bbn.com
---
transport-helper.c | 3 ---
1 file changed, 3 deletions
On 10/12/2013 03:05 AM, Felipe Contreras wrote:
Hi,
Here are the patches that allow transport helpers to be completely
transparent;
renaming branches, deleting them, custom refspecs, --force, --dry-run,
reporting forced update, everything works.
These patches don't cleanly apply to master
document the new 'force' option
Signed-off-by: Richard Hansen rhan...@bbn.com
---
Documentation/gitremote-helpers.txt | 4
1 file changed, 4 insertions(+)
diff --git a/Documentation/gitremote-helpers.txt
b/Documentation/gitremote-helpers.txt
index f1f4ca9..e75699c 100644
Signed-off-by: Richard Hansen rhan...@bbn.com
---
git-remote-testgit.sh | 18 ++
1 file changed, 18 insertions(+)
diff --git a/git-remote-testgit.sh b/git-remote-testgit.sh
index 6d2f282..80546c1 100755
--- a/git-remote-testgit.sh
+++ b/git-remote-testgit.sh
@@ -6,6 +6,7 @@ url
Signed-off-by: Richard Hansen rhan...@bbn.com
---
t/t5801-remote-helpers.sh | 13 +
1 file changed, 13 insertions(+)
diff --git a/t/t5801-remote-helpers.sh b/t/t5801-remote-helpers.sh
index be543c0..93a7d34 100755
--- a/t/t5801-remote-helpers.sh
+++ b/t/t5801-remote-helpers.sh
On 2013-10-29 04:41, Felipe Contreras wrote:
Richard Hansen wrote:
Signed-off-by: Richard Hansen rhan...@bbn.com
---
git-remote-testgit.sh | 18 ++
1 file changed, 18 insertions(+)
diff --git a/git-remote-testgit.sh b/git-remote-testgit.sh
index 6d2f282..80546c1 100755
Change 'git push' to 'git push -u remote branch' in one of the
test-bzr.sh tests to ensure that the test continues to pass when the
default value of push.default changes to simple.
Also, explicitly set push.default to simple to silence warnings when
using --verbose.
Signed-off-by: Richard Hansen
outside the function.
Signed-off-by: Richard Hansen rhan...@bbn.com
---
contrib/remote-helpers/test-hg.sh | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/contrib/remote-helpers/test-hg.sh
b/contrib/remote-helpers/test-hg.sh
index 53f2bba..558a656 100755
--- a/contrib
A handful of fixes for the git-remote-hg and git-remote-bzr remote
helpers and their unit tests.
Richard Hansen (7):
remote-hg: don't decode UTF-8 paths into Unicode objects
test-bzr.sh, test-hg.sh: allow running from any dir
test-bzr.sh, test-hg.sh: prepare for change to push.default
cd to the t/ subdirectory so that the user doesn't already have to be
in the test directory to run these test scripts.
Signed-off-by: Richard Hansen rhan...@bbn.com
---
contrib/remote-helpers/test-bzr.sh | 1 +
contrib/remote-helpers/test-hg.sh | 1 +
2 files changed, 2 insertions(+)
diff
The internal mercurial API expects ordinary 8-bit string objects, not
Unicode string objects. With this change, the test-hg.sh unit tests
pass again.
Signed-off-by: Richard Hansen rhan...@bbn.com
---
contrib/remote-helpers/git-remote-hg | 2 +-
1 file changed, 1 insertion(+), 1 deletion
The POSIX spec says that the '-a', '-o', and parentheses operands to
the 'test' utility are obsolete extensions due to the potential for
ambiguity. Replace '-o' with '|| test' to avoid unspecified behavior.
Signed-off-by: Richard Hansen rhan...@bbn.com
---
contrib/remote-helpers/test-hg.sh | 2
It's hard to tell which author conversion test failed when the email
addresses look similar.
Signed-off-by: Richard Hansen rhan...@bbn.com
---
contrib/remote-helpers/test-hg.sh | 20 ++--
1 file changed, 10 insertions(+), 10 deletions(-)
diff --git a/contrib/remote-helpers/test
Before, strings like foo@example.com would be converted to
foo. b...@example.com when they should be unknown
foo@example.com.
Signed-off-by: Richard Hansen rhan...@bbn.com
---
contrib/remote-helpers/git-remote-bzr | 7 +++
contrib/remote-helpers/git-remote-hg | 7 +++
contrib
defend against force=foo in the user's environment
Signed-off-by: Richard Hansen rhan...@bbn.com
---
git-remote-testgit.sh | 2 ++
1 file changed, 2 insertions(+)
diff --git a/git-remote-testgit.sh b/git-remote-testgit.sh
index 6d2f282..1cfdea2 100755
--- a/git-remote-testgit.sh
+++ b/git
Signed-off-by: Richard Hansen rhan...@bbn.com
---
contrib/remote-helpers/git-remote-bzr | 34 +-
contrib/remote-helpers/test-bzr.sh| 22 +-
2 files changed, 54 insertions(+), 2 deletions(-)
diff --git a/contrib/remote-helpers/git-remote-bzr
On 2013-11-11 06:51, Felipe Contreras wrote:
Richard Hansen wrote:
Signed-off-by: Richard Hansen rhan...@bbn.com
---
contrib/remote-helpers/git-remote-bzr | 34
+-
contrib/remote-helpers/test-bzr.sh| 22 +-
2 files changed, 54
On 2013-11-11 06:04, Felipe Contreras wrote:
Richard Hansen wrote:
The internal mercurial API expects ordinary 8-bit string objects, not
Unicode string objects. With this change, the test-hg.sh unit tests
pass again.
This makes sense to me, but the tests are already passing for me. How
On 2013-11-11 06:42, Felipe Contreras wrote:
Richard Hansen wrote:
It's hard to tell which author conversion test failed when the email
addresses look similar.
Signed-off-by: Richard Hansen rhan...@bbn.com
---
contrib/remote-helpers/test-hg.sh | 20 ++--
1 file changed, 10
1 - 100 of 255 matches
Mail list logo
