Ramkumar Ramachandra wrote:
you'd essentially have to grab the remote.name.push refspec, rewrite
it to replace refs/heads/*: with $HEAD: and feed that refspec to the
transport layer
Um, sorry. It involves two independent steps:
1. add_refspec() $HEAD:$HEAD@{push} to feed to the transport
[1/2] clarifies the commit message to say that a grep didn't find
@{u} or @{upstream} hard-coded by any callers. Thanks to Junio.
[2/2] fixes a small grammar error in the commit message. Thanks to
Eric Sunshine.
Ramkumar Ramachandra (2):
sha1_name: fix error message for @{u}
sha1_name: fix
Currently, when no (valid) upstream is configured for a branch, you get
an error like:
$ git show @{u}
error: No upstream configured for branch 'upstream-error'
error: No upstream configured for branch 'upstream-error'
fatal: ambiguous argument '@{u}': unknown revision or path not in the
Currently, when we try to resolve @{N} or @{date} when the reflog
doesn't go back far enough, we get errors like:
# on branch master
$ git show @{1}
fatal: Log for '' only has 7 entries.
$ git show @{1.days.ago}
warning: Log for '' only goes back to Tue, 21 May 2013 14:14:45
On Fri, May 24, 2013 at 01:57:12AM +0200, Petr Baudis wrote:
Just to clear up on what the best practice is, I'd imagine the setup
to be something like:
(a) Makefile contains inclusion of Makefile.include.
(b) There is a file like Makefile.include.template containing
a
On Thu, May 23, 2013 at 06:53:36PM -0500, Felipe Contreras wrote:
The alternatives are these:
a) you annoy the vast majority of the user-base by making 'git pull' a
dangerous operation that should be avoided, and replaced with 'git
fetch'+'git rebase'.
b) you annoy a minority of the
Am 23.05.2013 21:25, schrieb Andreas Krey:
On Thu, 23 May 2013 11:06:57 +, Andreas Krey wrote:
...
...
Don't do that, then.
Ouch, you're right. The problem is not actually in the
pull; only the *last* pull into a feature branch that
then get pushed back ff to master needs to be reversed.
Junio C Hamano wrote:
[...]
I agree with the other comments, and have made suitable changes.
Let's review your block now.
This transformation is used to find filepairs that represent
two kinds of changes, and is controlled by the -S, -G and
--pickaxe-all options.
Why
On Fri, May 24, 2013 at 4:29 AM, John Keeping j...@keeping.me.uk wrote:
[snip]
Note that in my email that started this, I tried to be clear that I was
talking about git pull *without a branch name*. If this user
explicitly says git pull remote branch then I consider that a clear
indication
On Fri, May 24, 2013 at 09:22:53AM +0100, John Keeping wrote:
On Fri, May 24, 2013 at 01:57:12AM +0200, Petr Baudis wrote:
Just to clear up on what the best practice is, I'd imagine the setup
to be something like:
(a) Makefile contains inclusion of Makefile.include.
(b)
On Fri, May 24, 2013 at 11:40:07AM +0200, Petr Baudis wrote:
On Fri, May 24, 2013 at 09:22:53AM +0100, John Keeping wrote:
On Fri, May 24, 2013 at 01:57:12AM +0200, Petr Baudis wrote:
Just to clear up on what the best practice is, I'd imagine the setup
to be something like:
(a)
On Fri, May 24, 2013 at 11:06:12AM +0100, John Keeping wrote:
I don't see anything wrong with having a template file documenting the
parameters, but I think it's important that there are sensible defaults
in place when the user's configuration file does not specify a value for
a parameter. It
[1/2] replaces pickaxe regex with regex, as suggested by Junio.
[2/2] is now co-authored by Junio. I've taken what I think are the
best changes introduced by both versions and merged them. The
inter-diff follows.
diff --git a/Documentation/diff-options.txt b/Documentation/diff-options.txt
Currently, diffcore-pickaxe reports two distinct errors for the same
user error:
$ git log --pickaxe-regex -S'\1'
fatal: invalid pickaxe regex: Invalid back reference
$ git log -G'\1' # --pickaxe-regex is implied
fatal: invalid log-grep regex: Invalid back reference
Since the
The documentation of -S and -G is very sketchy. Completely rewrite the
sections in Documentation/diff-options.txt and
Documentation/gitdiffcore.txt.
References:
52e9578 ([PATCH] Introducing software archaeologist's tool pickaxe.)
f506b8e (git log/diff: add -Gregexp that greps in the patch text)
On Fri, May 24, 2013 at 12:14:16PM +0200, Petr Baudis wrote:
On Fri, May 24, 2013 at 11:06:12AM +0100, John Keeping wrote:
I don't see anything wrong with having a template file documenting the
parameters, but I think it's important that there are sensible defaults
in place when the user's
Dear List,
I created a dump from a repository. git bundle list-heads prints all the
refs I meant to add. The problem is that after exracting the dump with
git bundle unbundle the target repository doesn't contain any branches
(git branch -a prints nothing). How can we exract a dump so that
On Fri, May 24, 2013 at 11:40:18AM +0100, John Keeping wrote:
So that it continues to Just Work for people using buildroot but you can
create Makefile.config to override those defaults.
Indeed, that doesn't cover some corner cases of (c), but that's not a
big deal in practice I guess.
My
Hi,
I'm not able to sort completions for some weird reason. No matter
what I order I insert stuff into COMPREPLY, bash seems to auto-sort
them lexically. I tried to pass --sort='-committerdate' to git
for-each-ref so I can get a sensible 'git checkout TAB' reply, and
I'm very annoyed that it
On Fri, May 24, 2013 at 5:52 PM, Ákos, Tajti akos.ta...@intland.com wrote:
Dear List,
I created a dump from a repository. git bundle list-heads prints all the
refs I meant to add. The problem is that after exracting the dump with git
bundle unbundle the target repository doesn't contain any
On Fri, May 24, 2013 at 01:03:22PM +0200, Petr Baudis wrote:
On Fri, May 24, 2013 at 11:40:18AM +0100, John Keeping wrote:
So that it continues to Just Work for people using buildroot but you can
create Makefile.config to override those defaults.
Indeed, that doesn't cover some corner
On Fri, May 24, 2013 at 6:33 AM, Ramkumar Ramachandra
artag...@gmail.com wrote:
Hi,
I'm not able to sort completions for some weird reason. No matter
what I order I insert stuff into COMPREPLY, bash seems to auto-sort
them lexically. I tried to pass --sort='-committerdate' to git
On Thu, May 23, 2013 at 10:12 AM, Ramkumar Ramachandra
artag...@gmail.com wrote:
Introduce an AT_KIND_PUSH to be represented as @{p[ush]}. Determine
it using branch.remote.push_refspec.
I think the semantics of this don't make any sense.
git push branch@{upstream}
Is very clear: push
Felipe Contreras wrote:
git push branch@{push}
Is not clear at all: push push of branch?
We can pick the name later. I had to pick a name to write code, and
that happens to be @{push}.
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to
On Fri, 24 May 2013 11:29:00 +, Holger Hellmuth (IKS) wrote:
...
Here is an idea (probably already discussed in the long history of git):
1) the branch name is recorded in a commit (for merges the branch that
is updated)
The branch name is almost completely meaningless. I could just
do my
So, while investigating alignment operators in pretty-formats, I found
out that it's way too much effort and totally not worth it (atleast
not immediately; we can add it later if we want). What I want now is
a useable git-branch output. And I think I can say that I've achieved
it.
I currently
'git branch' shows which branch you are currently on with an '*', but
'git for-each-ref' misses this feature. So, extend the format with
%(HEAD) to do exactly the same thing.
Now you can use the following format in for-each-ref:
%C(red)%(HEAD)%C(reset) %C(green)%(refname:short)%C(reset)
to
Since 'git branch' misses important options like --sort, --count, and
--format that are present in 'git for-each-ref'. Until we are in a
position to fix 'git branch', let us enhance the 'git for-each-ref'
format so it can atleast colorize output.
You can use the following format in for-each-ref:
Introduce %(upstream:track) to display [ahead M, behind N] and
%(upstream:trackshort) to display =, , , or
appropriately (inspired by the contrib/completion/git-prompt.sh).
Now you can use the following format in for-each-ref:
%C(red)%(HEAD)%C(reset)
- Original Message -
From: Thomas Rast tr...@inf.ethz.ch
Sent: Thursday, May 23, 2013 6:56:50 PM
Subject: Re: git stash deletes/drops changes of
Junio C Hamano gits...@pobox.com writes:
Thomas Rast tr...@inf.ethz.ch writes:
So maybe it would be time to first make up our
On Fri, May 24, 2013 at 5:37 AM, Ramkumar Ramachandra
artag...@gmail.com wrote:
Junio C Hamano wrote:
[...]
I agree with the other comments, and have made suitable changes.
Let's review your block now.
This transformation is used to find filepairs that represent
two kinds
Am 24.05.2013 15:42, schrieb Andreas Krey:
On Fri, 24 May 2013 11:29:00 +, Holger Hellmuth (IKS) wrote:
...
Here is an idea (probably already discussed in the long history of git):
1) the branch name is recorded in a commit (for merges the branch that
is updated)
The branch name is almost
On Thu, May 23, 2013 at 7:20 PM, Junio C Hamano gits...@pobox.com wrote:
Thomas Rast tr...@inf.ethz.ch writes:
What are the workflows that are helped if we had such a bit? If
we need to support them, I think you need a real --ignore-changes
bit, not an abuse of --assume-unchanged.
I gather
On Fri, May 24, 2013 at 9:19 PM, Ramkumar Ramachandra
artag...@gmail.com wrote:
There is no need to use a hammer and coerce everything into an atom,
or throw everything out the window and start from scratch to conform
to pretty-formats perfectly. Let's extend the existing format to be
Phil Hord phil.hord at gmail.com writes:
The wording of --ignore-changes suffers the same lack of clarity that
--assume-unchanged does.
What's better? --sequester is probably too obscure. Maybe --hold.
Or --silence. Or --shut-up.
How about --freeze?
--
To unsubscribe from this list:
On Fri, May 24, 2013 at 03:34:26PM +, Jim Greenleaf wrote:
Phil Hord phil.hord at gmail.com writes:
The wording of --ignore-changes suffers the same lack of clarity that
--assume-unchanged does.
What's better? --sequester is probably too obscure. Maybe --hold.
Or --silence. Or
file:///path/to/repo.git/ is converted to a hyperlink while others are
not. Put a backslash to avoid the conversion. Tested with asciidoc
8.6.5.
Signed-off-by: Nguyễn Thái Ngọc Duy pclo...@gmail.com
---
Documentation/urls.txt | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git
John Keeping john at keeping.me.uk writes:
I wonder if this would be better as a file rather than another option to
git-update-index. We already have .git/info/exclude so we could add
.git/info/freeze or .git/info/local with the same syntax as the normal
.gitignore file.
.git/info/freeze
Duy Nguyen wrote:
Usefulness is one thing. Another is maintenance and in that regard I
still think we should be able to remove -v and -vv code (not the
functionality) with this topic.
Why? The topic adds good functionality, doesn't break anything,
doesn't paint us into any corner, and has
Phil Hord wrote:
It fits the beginning of the
document where it says this:
Ah, I missed that. Either way, I'm quite happy with v3: we can change
the first paragraph to use the word transformation if we really
want.
--
To unsubscribe from this list: send the line unsubscribe git in
the body of
On Fri, May 24, 2013 at 03:42:37PM +, Jim Greenleaf wrote:
John Keeping john at keeping.me.uk writes:
I wonder if this would be better as a file rather than another option to
git-update-index. We already have .git/info/exclude so we could add
.git/info/freeze or .git/info/local with
(I haven't caught up with git mails lately, but the @{special}
refactoring caught my eyes..)
On Thu, May 23, 2013 at 10:12 PM, Ramkumar Ramachandra
artag...@gmail.com wrote:
Try this now: configure your current branch's pushremote to push to
refs/heads/*:refs/heads/rr/*. Now, type 'git show
Hi,
On Fri, May 24, 2013 at 05:03:27PM +0530, Ramkumar Ramachandra wrote:
I'm not able to sort completions for some weird reason. No matter
what I order I insert stuff into COMPREPLY, bash seems to auto-sort
them lexically. I tried to pass --sort='-committerdate' to git
for-each-ref so I
Duy Nguyen wrote:
On Thu, May 23, 2013 at 10:12 PM, Ramkumar Ramachandra
artag...@gmail.com wrote:
Try this now: configure your current branch's pushremote to push to
refs/heads/*:refs/heads/rr/*. Now, type 'git show @{p}'. Voila!
Voila what? Why not avoid guessing game and describe what
SZEDER Gábor wrote:
I don't know who does the sorting (Bash or readline), and I don't know
any way to disable it.
Damn; so it's impossible to have a custom-sorted completion list in
bash. Any idea about zsh? I know that there are completion groups,
but I'd really like custom sorting.
--
To
On Fri, May 24, 2013 at 6:18 PM, Ramkumar Ramachandra
artag...@gmail.com wrote:
Damn; so it's impossible to have a custom-sorted completion list in
bash. Any idea about zsh? I know that there are completion groups,
but I'd really like custom sorting.
I think sorting is required for faster
On Fri, May 24, 2013 at 11:15 PM, Ramkumar Ramachandra
artag...@gmail.com wrote:
Duy Nguyen wrote:
On Thu, May 23, 2013 at 10:12 PM, Ramkumar Ramachandra
artag...@gmail.com wrote:
Try this now: configure your current branch's pushremote to push to
refs/heads/*:refs/heads/rr/*. Now, type 'git
Felipe Contreras felipe.contre...@gmail.com writes:
... but I don't see why something small like that
wouldn't make sense:
The pull was not fast-forward, please either merge or rebase.
OK, I think I got what John was getting at and this single liner
message is a good summary of it.
Instead
Duy Nguyen wrote:
Then show @{p} should show the tip commit of rr/master, not the ref
name.
Yes, that is correct.
rev-parse (with an option, maybe) may be a better place for
this.
Er, no. I actually want things like diff @{p}..HEAD. I want it to be
a first-class revision, just like @{u}.
2013/5/23 Bernhard R. Link brl+...@mail.brlink.eu:
* Ralf Thielow ralf.thie...@gmail.com [130522 17:17]:
remote branch = Remote-Branch
remote-tracking branch = Remote-Tracking-Branch
upstream branch= Upstream-Branch
Yes. What's the main reason for using
Hi all,
thanks for all your comments. Here's an updated version of the glossary
including (hopefully) all the changes you've suggested.
Basic repository objects:
blob = Blob
tree = Baum-Objekt (bevorzugt), Tree-Objekt
submodule = Submodul
pack(noun)
Ramkumar Ramachandra artag...@gmail.com writes:
Currently, when we try to resolve @{N} or @{date} when the reflog
doesn't go back far enough, we get errors like:
# on branch master
$ git show @{1}
fatal: Log for '' only has 7 entries.
$ git show @{1.days.ago}
warning:
Phil Hord phil.h...@gmail.com writes:
On Fri, May 24, 2013 at 5:37 AM, Ramkumar Ramachandra
artag...@gmail.com wrote:
Junio C Hamano wrote:
[...]
I agree with the other comments, and have made suitable changes.
Let's review your block now.
This transformation is used to find
On Thu, 23 May 2013 09:01:15 +, Junio C Hamano wrote:
...
Instead of having a nice these six commits marked as 'x' were done
on a branch forked some time ago, to address only this one issue and
to address it fully history that explains how these commits were
related and these commits are
Junio C Hamano wrote:
What is this meant to update? I recall rewriting this part on
purpose.
I was being verbose to show that I handle the detached HEAD case too,
which I missed last time.
Even though it appears unusual and invites confusion, it is very
consistent to say '' when the user
On Fri, 24 May 2013 17:05:26 +, Holger Hellmuth (IKS) wrote:
Am 24.05.2013 15:42, schrieb Andreas Krey:
...
The branch name is almost completely meaningless. I could just
do my feature in my local master and never have a different name.
In which case parent switching in the commit
Ramkumar Ramachandra artag...@gmail.com writes:
The documentation of -S and -G is very sketchy. Completely rewrite the
sections in Documentation/diff-options.txt and
Documentation/gitdiffcore.txt.
References:
52e9578 ([PATCH] Introducing software archaeologist's tool pickaxe.)
f506b8e
Ramkumar Ramachandra artag...@gmail.com writes:
Junio C Hamano wrote:
What is this meant to update? I recall rewriting this part on
purpose.
I was being verbose to show that I handle the detached HEAD case too,
which I missed last time.
Even though it appears unusual and invites
Junio C Hamano wrote:
That is why I rewrote it like so:
The empty string '' is confusing and does not convey information
about whose logs we are inspecting. Change this so that...
Ah, I didn't notice the rewrite in pu. Thanks.
--
To unsubscribe from this list: send the line
Duy Nguyen pclo...@gmail.com writes:
On Fri, May 24, 2013 at 9:19 PM, Ramkumar Ramachandra
artag...@gmail.com wrote:
There is no need to use a hammer and coerce everything into an atom,
or throw everything out the window and start from scratch to conform
to pretty-formats perfectly. Let's
Thanks.
--
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
Ramkumar Ramachandra artag...@gmail.com writes:
Duy Nguyen wrote:
Then show @{p} should show the tip commit of rr/master, not the ref
name.
Yes, that is correct.
rev-parse (with an option, maybe) may be a better place for
this.
Er, no. I actually want things like diff @{p}..HEAD. I
Junio C Hamano wrote:
I am having this feeling that we see more and more of this line of
bad behaviours from some on the list recently to call something that
is working in which they find itch using unnecessarily derogatory
terms, and it makes people simply avoid any discussion that starts
Junio C Hamano wrote:
Yes, the aim of the topic should be to make the machinery flexible
enough so that we can lose -v/-vv implementation and replace them
with calls to the new machinery with canned set of output format
templates.
Definitely. I don't want to keep my ugly alias around
Junio C Hamano wrote:
rev-parse (with an option, maybe) may be a better place for
this.
Er, no. I actually want things like diff @{p}..HEAD. I want it to be
a first-class revision, just like @{u}.
I think Duy's suggestion makes perfect sense; rev-parse already has
a mechanism to expand
Antoine Pelisse wrote:
I think sorting is required for faster look-up, most likely with
dichotomic search. Otherwise it would have to search the whole list
each time.
Oh, it's probably keeping just one copy of the completions in memory
(which has to be sorted for search); this is also used to
-Original Message-
From: git-ow...@vger.kernel.org
[mailto:git-ow...@vger.kernel.org] On Behalf Of Ramkumar Ramachandra
Sent: Friday, May 24, 2013 12:19 PM
To: SZEDER Gábor
Cc: Git List; Felipe Contreras
Subject: Re: [QUERY] How do you sort completions?
SZEDER Gábor wrote:
I
Ramkumar Ramachandra artag...@gmail.com writes:
Junio C Hamano wrote:
rev-parse (with an option, maybe) may be a better place for
this.
Er, no. I actually want things like diff @{p}..HEAD. I want it to be
a first-class revision, just like @{u}.
I think Duy's suggestion makes perfect
Andreas Krey a.k...@gmx.de writes:
On Thu, 23 May 2013 09:01:15 +, Junio C Hamano wrote:
...
Instead of having a nice these six commits marked as 'x' were done
on a branch forked some time ago, to address only this one issue and
to address it fully history that explains how these commits
From: Ramkumar Ramachandra artag...@gmail.com
Sent: Friday, May 24, 2013 3:19 PM
'git branch' shows which branch you are currently on with an '*', but
'git for-each-ref' misses this feature. So, extend the format with
%(HEAD) to do exactly the same thing.
Maybe 'isHEAD' as a better name, or
On Fri, May 24, 2013 at 4:19 PM, Ramkumar Ramachandra
artag...@gmail.com wrote:
@@ -928,12 +936,22 @@ static void emit(const char *cp, const char *ep)
static void show_ref(struct refinfo *info, const char *format, int
quote_style)
{
const char *cp, *sp, *ep;
+ char
The latest feature release Git v1.8.3 is now available at the
usual places.
The release tarballs are found at:
http://code.google.com/p/git-core/downloads/list
and their SHA-1 checksums are:
bfb88c182daeed5601ba860d785ac813433f55f1 git-1.8.3.tar.gz
92cc8ae5f4c1db2e7751ad0dc9c3227ca31080aa
What's cooking in git.git (May 2013, #07; Fri, 24)
--
Here are the topics that have been cooking. Commits prefixed with
'-' are only in 'pu' (proposed updates) while commits prefixed with
'+' are in 'next'.
There are topics that are still in
On Fri, May 24, 2013 at 9:19 PM, Ramkumar Ramachandra
artag...@gmail.com wrote:
So, while investigating alignment operators in pretty-formats, I found
out that it's way too much effort and totally not worth it (atleast
not immediately; we can add it later if we want).
I just had an idea that
On Fri, May 24, 2013 at 7:19 AM, Ramkumar Ramachandra
artag...@gmail.com wrote:
Since 'git branch' misses important options like --sort, --count, and
--format that are present in 'git for-each-ref'. Until we are in a
position to fix 'git branch', let us enhance the 'git for-each-ref'
format
Hi,
Minor fixes since last time.
These patches have been cooking in my github repository, and improve the
situation when bzr servers don't support repositories properly.
Felipe Contreras (8):
remote-bzr: recover from failed clones
remote-bzr: fix for files with spaces
remote-bzr: simplify
Signed-off-by: Felipe Contreras felipe.contre...@gmail.com
---
contrib/remote-helpers/git-remote-bzr | 18 ++
1 file changed, 10 insertions(+), 8 deletions(-)
diff --git a/contrib/remote-helpers/git-remote-bzr
b/contrib/remote-helpers/git-remote-bzr
index 10300c6..8a4df51 100755
Set the maximum number of splits to make when dividing the diff stat
lines based on space characters.
Signed-off-by: Felipe Contreras felipe.contre...@gmail.com
---
contrib/remote-helpers/git-remote-bzr | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git
No need for 'origin', it's only needed for the bzrdir 'sprout' method,
which can be greatly simplified.
Signed-off-by: Felipe Contreras felipe.contre...@gmail.com
---
contrib/remote-helpers/git-remote-bzr | 23 ---
1 file changed, 12 insertions(+), 11 deletions(-)
diff --git
Until the branch is actually going to be used.
Signed-off-by: Felipe Contreras felipe.contre...@gmail.com
---
contrib/remote-helpers/git-remote-bzr | 28 +---
1 file changed, 13 insertions(+), 15 deletions(-)
diff --git a/contrib/remote-helpers/git-remote-bzr
It's not used anyway.
Signed-off-by: Felipe Contreras felipe.contre...@gmail.com
---
contrib/remote-helpers/git-remote-bzr | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/contrib/remote-helpers/git-remote-bzr
b/contrib/remote-helpers/git-remote-bzr
index 202a4f7..80ed59f
Signed-off-by: Felipe Contreras felipe.contre...@gmail.com
---
contrib/remote-helpers/git-remote-bzr | 14 +++---
1 file changed, 7 insertions(+), 7 deletions(-)
diff --git a/contrib/remote-helpers/git-remote-bzr
b/contrib/remote-helpers/git-remote-bzr
index 80ed59f..34025c3 100755
---
If the user specified a list of branches, we ignore what the remote
repository lists, and simply use the branches directly. Since some
remotes don't report the branches correctly, this is useful.
Otherwise either fetch the repo, or the branch.
Signed-off-by: Felipe Contreras
Signed-off-by: Felipe Contreras felipe.contre...@gmail.com
---
contrib/remote-helpers/git-remote-bzr | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/contrib/remote-helpers/git-remote-bzr
b/contrib/remote-helpers/git-remote-bzr
index 3248586..3cd6572 100755
---
Hi,
Since v1 there's a few backward compatibility fixes, and new patches at the end
for new feature, some which require patches to the remote helper
infraestructure.
I've been cooking these for some time now, and they seem to be mostly ready.
The major changes are:
1) Use our own custom push()
Signed-off-by: Felipe Contreras felipe.contre...@gmail.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 8de2aa7..f8d1f9e 100755
---
We only need to get the remote dict once.
Signed-off-by: Felipe Contreras felipe.contre...@gmail.com
---
contrib/remote-helpers/git-remote-hg | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/contrib/remote-helpers/git-remote-hg
b/contrib/remote-helpers/git-remote-hg
index
We prefer tabs to spaces.
Signed-off-by: Felipe Contreras felipe.contre...@gmail.com
---
contrib/remote-helpers/test-bzr.sh | 460 ++---
contrib/remote-helpers/test-hg.sh | 176 +++---
2 files changed, 318 insertions(+), 318 deletions(-)
diff --git
So it's more standardized between all the tests.
Signed-off-by: Felipe Contreras felipe.contre...@gmail.com
---
contrib/remote-helpers/test-bzr.sh | 88 +-
contrib/remote-helpers/test-hg.sh | 12 --
2 files changed, 66 insertions(+), 34 deletions(-)
diff
So that we don't need a temporary directory.
Signed-off-by: Felipe Contreras felipe.contre...@gmail.com
---
contrib/remote-helpers/test-bzr.sh | 21 ++--
contrib/remote-helpers/test-hg-bidi.sh | 15 +--
contrib/remote-helpers/test-hg-hg-git.sh | 33
No need to specify $PWD any more.
Signed-off-by: Felipe Contreras felipe.contre...@gmail.com
---
contrib/remote-helpers/test-bzr.sh | 12 ++--
contrib/remote-helpers/test-hg-bidi.sh | 6 +++---
contrib/remote-helpers/test-hg-hg-git.sh | 6 +++---
@{-1} does the same thing.
Signed-off-by: Felipe Contreras felipe.contre...@gmail.com
---
contrib/remote-helpers/test-hg-bidi.sh | 3 +--
contrib/remote-helpers/test-hg-hg-git.sh | 3 +--
2 files changed, 2 insertions(+), 4 deletions(-)
diff --git a/contrib/remote-helpers/test-hg-bidi.sh
The user might have then configured differently, plus, all of them will
be loaded anyway later on.
Signed-off-by: Felipe Contreras felipe.contre...@gmail.com
---
contrib/remote-helpers/git-remote-hg | 6 +-
1 file changed, 1 insertion(+), 5 deletions(-)
diff --git
This way we don't have to have duplicated Mercurial objects.
Signed-off-by: Felipe Contreras felipe.contre...@gmail.com
---
contrib/remote-helpers/git-remote-hg | 35 ---
1 file changed, 20 insertions(+), 15 deletions(-)
diff --git
In preparation to shift to SHA-1's.
Signed-off-by: Felipe Contreras felipe.contre...@gmail.com
---
contrib/remote-helpers/git-remote-hg | 30 +-
1 file changed, 17 insertions(+), 13 deletions(-)
diff --git a/contrib/remote-helpers/git-remote-hg
We won't be able to count the unmarked commits, but we are not going to
be able to do that anyway when we switch to SHA-1 ids.
Signed-off-by: Felipe Contreras felipe.contre...@gmail.com
---
contrib/remote-helpers/git-remote-hg | 10 +++---
1 file changed, 7 insertions(+), 3 deletions(-)
Signed-off-by: Felipe Contreras felipe.contre...@gmail.com
---
contrib/remote-helpers/git-remote-hg | 16 +---
1 file changed, 13 insertions(+), 3 deletions(-)
diff --git a/contrib/remote-helpers/git-remote-hg
b/contrib/remote-helpers/git-remote-hg
index 07ea104..e2bef7f 100755
---
Otherwise we won't know if revisions are replaced.
Signed-off-by: Felipe Contreras felipe.contre...@gmail.com
---
contrib/remote-helpers/git-remote-hg | 42 +++-
1 file changed, 22 insertions(+), 20 deletions(-)
diff --git a/contrib/remote-helpers/git-remote-hg
As suggested by Jed Brown; there's no need to re-import all the commits.
Cc: Jed Brown j...@59a2.org
Signed-off-by: Felipe Contreras felipe.contre...@gmail.com
---
contrib/remote-helpers/git-remote-hg | 22 ++
1 file changed, 18 insertions(+), 4 deletions(-)
diff --git
Signed-off-by: Felipe Contreras felipe.contre...@gmail.com
---
contrib/remote-helpers/git-remote-hg | 1 +
contrib/remote-helpers/test-hg.sh| 40
2 files changed, 41 insertions(+)
diff --git a/contrib/remote-helpers/git-remote-hg
1 - 100 of 154 matches
Mail list logo
