Ramkumar Ramachandra artag...@gmail.com writes:
Junio C Hamano wrote:
They're not the same thing. It is very much intentional and intended:
the safety net is not to ensure that the push and pull are
symmetrical (i.e. among other things, error out if
branch.$branch.merge is unset), but
On Thu, Jun 20, 2013 at 02:45:04PM -0700, Junio C Hamano wrote:
Jeff King p...@peff.net writes:
I think I got us off-track with my expectation of ending the one case
with a conflicted index. But caring about that is even more unlikely. I
think Thomas's original patch is probably a happy
Hi,
On Mon, Jun 17, 2013 at 11:55:36AM +0200, Fredrik Gustafsson wrote:
set_rev_name is a possible expensive operation. If a submodule has
changes in it, set_rev_name was called twice.
Solution is to move set_rev_name so it's only called once, no matter the
codepath taken.
Looks good to
Junio C Hamano gits...@pobox.com writes:
Like you said, I do not want to contaminate this series with such an
unrelated change. Worse, you are trying to break a sane default by
replacing it with anything goes.
We already have a sane default, which is to error out. We do not
need your
When cloning a repo with --mirror, and adding more remotes later,
get_stale_heads for origin would mark all refs from other repos as stale. In
this situation, with refs-src and refs-dst both equal to refs/*, we should
ignore refs/remotes/* when looking for stale refs to prevent this from
On Thu, Jun 20, 2013 at 06:03:28PM -0400, Jeff King wrote:
OK. I'll prepare a series with both patches. Stand by...
Here it is:
[1/2]: pull: update unborn branch tip after index
[2/2]: pull: merge into unborn by fast-forwarding from empty tree
The first one is mine. The second is Thomas's
When commit d09e79c taught git to pull into an unborn
branch, it first updated the unborn branch to point at the
pulled commit, and then used read-tree to update the index
and working tree. That ordering made sense, since any
failure of the latter step would be due to filesystem
errors, and one
From: Thomas Rast tr...@inf.ethz.ch
The logic for pulling into an unborn branch was originally
designed to be used on a newly-initialized repository
(d09e79c, git-pull: allow pulling into an empty repository,
2006-11-16). It thus did not initially deal with
uncommitted changes in the unborn
Dennis Kaarsemaker den...@kaarsemaker.net writes:
When cloning a repo with --mirror, and adding more remotes later,
get_stale_heads for origin would mark all refs from other repos as stale. In
this situation, with refs-src and refs-dst both equal to refs/*, we should
ignore refs/remotes/*
Thanks; both look obviously good.
--
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
When cloning a repo with --mirror, and adding more remotes later,
get_stale_heads for origin would mark all refs from other repos as stale. In
this situation, with refs-src and refs-dst both equal to refs/*, we should
ignore refs/remotes/* and refs/tags/* when looking for stale refs to
prevent
(Sorry, I sent v2 before seeing this mail)
On do, 2013-06-20 at 15:46 -0700, Junio C Hamano wrote:
Dennis Kaarsemaker den...@kaarsemaker.net writes:
When cloning a repo with --mirror, and adding more remotes later,
get_stale_heads for origin would mark all refs from other repos as stale.
On Thu, Jun 20, 2013 at 03:46:20PM -0700, Junio C Hamano wrote:
Dennis Kaarsemaker den...@kaarsemaker.net writes:
When cloning a repo with --mirror, and adding more remotes later,
get_stale_heads for origin would mark all refs from other repos as stale. In
this situation, with refs-src
On do, 2013-06-20 at 19:08 -0400, Jeff King wrote:
I wonder why Dennis wants to refs/*:refs/* in the first place. It
is not usually a useful thing to have in a non-bare repository,
because fetches will overwrite local work on branches. If he just
wanted the automatic git push --mirror
Dennis Kaarsemaker den...@kaarsemaker.net writes:
Going back to your original example:
[remote origin]
url = git://github.com/git/git.git
fetch = +refs/*:refs/*
mirror = true
[remote peff]
url = git://github.com/peff/git.git
Dennis Kaarsemaker den...@kaarsemaker.net writes:
I'm not doing that in non-bare repositories, neither do I use it for
pushing. It's for a continuous integration system, which never has any
locally created branches or commits, but does integrate things from
different remotes in some cases.
On do, 2013-06-20 at 16:30 -0700, Junio C Hamano wrote:
Maybe there is a miscommunication.
$ git ls-remote git://github.com/git/git.git | grep remotes/
shows that that repository, your origin, has refs/remotes/github/html
Yes, I misunderstood you and see the problem now. Thanks for
Dennis Kaarsemaker den...@kaarsemaker.net writes:
I'd really like to have C as well though, would you accept a patch that
implements it?
I already said I dunno, and asking me 5 minutes after that would not
change my answer X-. I tend to agree with Peff that it is papering
over the underlying
git-prompt.sh lacks tests for PROMPT_COMMAND mode.
Add tests for:
* pcmode prompt without colors
* pcmode prompt with colors for bash
* pcmode prompt with colors for zsh
Having these tests enables an upcoming refactor in
a safe way.
Signed-off-by: Eduardo R. D'Avila erdav...@gmail.com
---
254
__git_ps1_colorize_gitstring() sets color codes and
builds the prompt gitstring. It has duplicated code
to handle color codes for bash and zsh shells.
__git_ps1() also has duplicated logic to build the
prompt gitstring.
Remove duplication of logic to build gitstring in
Do not print a duplicate clean color code when there
is no other indicators other than the current branch
in colored prompt.
Signed-off-by: Eduardo R. D'Avila erdav...@gmail.com
---
1 1 contrib/completion/git-prompt.sh
6 6 t/t9903-bash-prompt.sh
The previously proposed patch set to enable color
prompt in non-PROMPT_COMMAND mode
(http://article.gmane.org/gmane.comp.version-control.git/228017)
introduce some problems with command line editing/browsing/completion,
as explained by Simon Oosthoek, in
Mention that the command below is needed for prompt
in ZSH with PS1:
setopt PROMPT_SUBST
Make it clear that colored prompt is only available
in PROMPT_COMMAND mode.
Signed-off-by: Eduardo R. D'Avila erdav...@gmail.com
---
5 4 contrib/completion/git-prompt.sh
On Fri, Jun 21, 2013 at 12:27:02AM -0400, Brian Gernhardt wrote:
I've bisected it to this commit:
commit 0442743810c6f6c14386a5a9d6bf8e4d69adbc51
Author: Jeff King p...@peff.net
Date: Sun Jun 9 04:07:59 2013 -0400
t/lib-httpd/apache.conf: do not use LockFile in apache = 2.4
I've bisected it to this commit:
commit 0442743810c6f6c14386a5a9d6bf8e4d69adbc51
Author: Jeff King p...@peff.net
Date: Sun Jun 9 04:07:59 2013 -0400
t/lib-httpd/apache.conf: do not use LockFile in apache = 2.4
OS X 10.8.4, apache 2.2.22
I'll also note that the tests fail the first
On Fri, Jun 21, 2013 at 12:30:52AM -0400, Jeff King wrote:
OS X 10.8.4, apache 2.2.22
Hrm. That's quite odd. The patch in its entirety looks like this:
[...]
So it should not be having any effect at all on apache 2.2, unless it
somehow does not like the IfVersion tags.
Just to
On Jun 21, 2013, at 12:42 AM, Jeff King p...@peff.net wrote:
I'm not sure if there is something different between 2.2.16 and 2.2.22,
or something with the particular build. Here's my -V output, in case it
helps:
$ apache2 -V
Server version: Apache/2.2.16 (Debian)
Server built:
On Fri, Jun 21, 2013 at 12:45:25AM -0400, Brian Gernhardt wrote:
I'm not sure if there is something different between 2.2.16 and 2.2.22,
or something with the particular build. Here's my -V output, in case it
helps:
[...]
Doesn't look terribly different from mine.
It turns out that
Here are the topics that have been cooking. Commits prefixed with
'-' are only in 'pu' (proposed updates) while commits prefixed with
'+' are in 'next'.
Among what's new in 'master' and 'next' are many code and
documentation clean-ups.
I am wondering if it may be better for the project for me
On Wed, Jun 19, 2013 at 02:05:06AM +0530, Ramkumar Ramachandra wrote:
Junio C Hamano wrote:
Sounds like making make test build it is a more correct approach,
at least to me. What am I missing?
How exactly? I'm not exactly competent in make, but this is what I
understood from what you
Am 6/20/2013 20:11, schrieb Junio C Hamano:
Johannes Sixt j.s...@viscovery.net writes:
But you can't have this string:
Splitting a commit while rebasing branch '%2$s' on '%3$s'.
neither in the template nor in the translation, because the numbers must
begin at 1 (and must be used without
Merge strategy and its options can be specified in `git rebase`,
but with `--interactive`, they were completely ignored.
Signed-off-by: Arnaud Fontaine ar...@debian.org
---
git-rebase--interactive.sh| 11 ++-
t/t3404-rebase-interactive.sh | 11 +++
2 files changed, 21
101 - 132 of 132 matches
Mail list logo
