Signed-off-by: Martin von Zweigbergk martinv...@gmail.com
---
t/t3401-rebase-partial.sh | 24
t/t3421-rebase-topology-linear.sh | 58 +++
2 files changed, 58 insertions(+), 24 deletions(-)
diff --git a/t/t3401-rebase-partial.sh
Signed-off-by: Martin von Zweigbergk martinv...@gmail.com
---
t/lib-rebase.sh | 17
t/t3421-rebase-topology-linear.sh | 85 +++
2 files changed, 102 insertions(+)
diff --git a/t/lib-rebase.sh b/t/lib-rebase.sh
index 1e0ff28..4b74ae4
Helped-by: Johannes Sixt j...@kdbg.org
Signed-off-by: Martin von Zweigbergk martinv...@gmail.com
---
t/lib-rebase.sh | 16
t/t3421-rebase-topology-linear.sh | 78 +++
2 files changed, 94 insertions(+)
create mode 100755
t3406 is supposed to test messages from rebase operation, so let's
move tests in t3400 that fit that description into 3406. Most of the
functionality they tested, except for the messages, has now been
subsumed by t3420.
Signed-off-by: Martin von Zweigbergk martinv...@gmail.com
---
Signed-off-by: Martin von Zweigbergk martinv...@gmail.com
---
t/t3421-rebase-topology-linear.sh | 129 ++
1 file changed, 129 insertions(+)
diff --git a/t/t3421-rebase-topology-linear.sh
b/t/t3421-rebase-topology-linear.sh
index f19f0d0..e67add6 100755
---
Update the following:
- Quote 'setup'
- Remove blank lines within test case body
- Use test_commit instead of custom quick_one
- Create branch topic from tag created by test_commit
Signed-off-by: Martin von Zweigbergk martinv...@gmail.com
---
t/t3406-rebase-message.sh | 30
Changes since v5:
* Improved test_linear_range
* Changed TODOs to be about consistency, not --topo-order
Martin von Zweigbergk (7):
add simple tests of consistency across rebase types
add tests for rebasing with patch-equivalence present
add tests for rebasing of empty commits
add
Signed-off-by: Martin von Zweigbergk martinv...@gmail.com
---
t/t3400-rebase.sh | 31 +
t/t3401-rebase-partial.sh | 45 ---
t/t3404-rebase-interactive.sh | 10 +-
t/t3409-rebase-preserve-merges.sh | 53
t/t3425-rebase-topology-merges.sh | 258
Am 6/6/2013 19:40, schrieb Jeff King:
On Thu, Jun 06, 2013 at 10:21:47AM -0700, Junio C Hamano wrote:
The particular deficiency is that when a signal is raise()d whose SIG_DFL
action will cause process death (SIGTERM in this case), the
implementation of raise() just calls exit(3).
After a
On Thu, Jun 06, 2013 at 06:35:43PM -0700, Constantine A. Murenin wrote:
I'm interested in running a web interface to this and other similar
git repositories (FreeBSD and NetBSD git repositories are even much,
much bigger).
Software-wise, is there no way to make cold access for git-log and
A colleague of mine who is well-intentioned and fairly knowledgeable
about git recently caused havoc with our repository while merging
changes on the main line branch into a feature branch. The reason is
that, along the way, he tried to use git stash while the merge was
pending. A few commands
The following changes since commit b5c26758639cd934780620d4dd16854c8fdf8c34:
Sync with maint (2013-06-03 13:00:09 -0700)
are available in the git repository at:
http://github.com/msysgit/git tags/post183-for-junio
for you to fetch changes up to 65db0443710f59a1c05a85688cdccc215ff48333:
Célestin Matte celestin.ma...@ensimag.fr writes:
Subject: [PATCH 01/18] Follow perlcritic's recommendations - level 5 and 4
It would be better to prefix commit messages with git-remote-mediawiki: .
Fix warnings from perlcritic's level 5 and 4.
It would be cool to have a make perlcritic
Célestin Matte celestin.ma...@ensimag.fr writes:
Subject: [PATCH 08/18] Explicitely assign local variable as undef and make a
proper one-instruction-by- line indentation
Try to keep short subject lines. We usually consider that 80 character
is a strict maximum, and to have e.g. git log
On Thu, Jun 6, 2013 at 7:40 PM, Jeff King p...@peff.net wrote:
On Thu, Jun 06, 2013 at 10:21:47AM -0700, Junio C Hamano wrote:
The particular deficiency is that when a signal is raise()d whose SIG_DFL
action will cause process death (SIGTERM in this case), the
implementation of raise()
Currently, the paragraph corresponding to the --tags option in
git-fetch(1) looks like:
-t, --tags
This is a short-hand for giving refs/tags/:refs/tags/ refspec
^^^
this is in bold
On Fri, Jun 7, 2013 at 12:24 PM, Johannes Sixt j.s...@viscovery.net wrote:
Am 6/7/2013 12:12, schrieb Erik Faye-Lund:
On Thu, Jun 6, 2013 at 7:40 PM, Jeff King p...@peff.net wrote:
On Thu, Jun 06, 2013 at 10:21:47AM -0700, Junio C Hamano wrote:
The particular deficiency is that when a signal
Le 07/06/2013 10:10, Matthieu Moy a écrit :
It would be cool to have a make perlcritic target in the Makefile so
that future developers can easily re-run it and avoid repeating the same
mistakes. As much as possible, make perlcritic should produce no
output at the end of your patch series
Am 6/7/2013 14:00, schrieb Erik Faye-Lund:
On Fri, Jun 7, 2013 at 12:24 PM, Johannes Sixt j.s...@viscovery.net wrote:
Am 6/7/2013 12:12, schrieb Erik Faye-Lund:
On Thu, Jun 6, 2013 at 7:40 PM, Jeff King p...@peff.net wrote:
On Thu, Jun 06, 2013 at 10:21:47AM -0700, Junio C Hamano wrote:
The
Hi, I tried to use the new Git feature to push by default to a different
remote you normally pull but I had some problems. I asked in the #git
IRC channel and been told it looks like a bug and to report it here.
I have 2 remotes, origin and upstream. origin is my private fork (and I
can push to
On Fri, Jun 7, 2013 at 2:19 PM, Johannes Sixt j.s...@viscovery.net wrote:
Am 6/7/2013 14:00, schrieb Erik Faye-Lund:
On Fri, Jun 7, 2013 at 12:24 PM, Johannes Sixt j.s...@viscovery.net wrote:
Am 6/7/2013 12:12, schrieb Erik Faye-Lund:
On Thu, Jun 6, 2013 at 7:40 PM, Jeff King p...@peff.net
On Thursday, June 06, 2013 at 23:16 EDT,
Robert Martin rdmart...@gmail.com wrote:
I want to work on a visualization program for git. I was hoping there
was a library that would allow me to monitor a git repo for changes.
Consider it like inotify, but for a git repository (in fact, I think
Am 6/7/2013 14:46, schrieb Erik Faye-Lund:
On Fri, Jun 7, 2013 at 2:19 PM, Johannes Sixt j.s...@viscovery.net wrote:
Am 6/7/2013 14:00, schrieb Erik Faye-Lund:
On Fri, Jun 7, 2013 at 12:24 PM, Johannes Sixt j.s...@viscovery.net wrote:
Am 6/7/2013 12:12, schrieb Erik Faye-Lund:
diff --git
[+CC: jc, jk]
Leandro Lucarella wrote:
I changed branch.master.remote to upstream and set
branch.master.pushremote to origin, but when I do I git push I get an
error:
$ git push --dry-run --verbose
fatal: You are pushing to remote 'origin', which is not the upstream of
your current branch
On Fri, Jun 7, 2013 at 3:07 PM, Johannes Sixt j.s...@viscovery.net wrote:
Am 6/7/2013 14:46, schrieb Erik Faye-Lund:
On Fri, Jun 7, 2013 at 2:19 PM, Johannes Sixt j.s...@viscovery.net wrote:
Am 6/7/2013 14:00, schrieb Erik Faye-Lund:
On Fri, Jun 7, 2013 at 12:24 PM, Johannes Sixt
David Lang wrote:
Well, Felipe is saying that Perl is dieing and we should re-write everything
that exists in Perl to Ruby.
I don't agree with that opinion. More generally, I think the entire
discussion on what _should_ or _should not_ be done is rubbish. What
_will_ and _will not_ happen
Ramkumar Ramachandra artag...@gmail.com writes:
Currently, the paragraph corresponding to the --tags option in
git-fetch(1) looks like:
-t, --tags
This is a short-hand for giving refs/tags/:refs/tags/ refspec
^^^
Junio C Hamano gits...@pobox.com writes:
Ramkumar Ramachandra artag...@gmail.com writes:
Currently, the paragraph corresponding to the --tags option in
git-fetch(1) looks like:
-t, --tags
This is a short-hand for giving refs/tags/:refs/tags/ refspec
Junio C Hamano wrote:
How about this?
Looks good, 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
Junio C Hamano wrote:
So at least for now, the conclusion is to take approach #1, i.e.
somebody who finds related a good addition rewrites it in Perl to
promote it out of contrib/ once the design issues settle (of course
it is still a possibility that no such volunteer appears).
We'll think
Ramkumar Ramachandra wrote:
Add support for completing 'git rev-parse'. List only the options that
are likely to be used on the command-line, as opposed to scripts.
Can we get this patch? I use git rev-list quite a lot, and want completion.
--
To unsubscribe from this list: send the line
Ramkumar Ramachandra artag...@gmail.com writes:
[+CC: jc, jk]
Leandro Lucarella wrote:
I changed branch.master.remote to upstream and set
branch.master.pushremote to origin, but when I do I git push I get an
error:
$ git push --dry-run --verbose
fatal: You are pushing to remote 'origin',
Forgot to cc; sorry about that.
Junio C Hamano gits...@pobox.com writes:
SZEDER Gábor sze...@ira.uka.de writes:
On Thu, Jun 06, 2013 at 03:41:08PM -0700, Junio C Hamano wrote:
* rr/complete-difftool (2013-06-03) 2 commits
(merged to 'next' on 2013-06-04 at 01c7611)
+ completion: clarify
On Thu, Jun 6, 2013 at 6:17 PM, Junio C Hamano gits...@pobox.com wrote:
Célestin Matte celestin.ma...@ensimag.fr writes:
But for a two-endpoint diff Porcelain (not the plumbing diff-files,
diff-index and diff-tree), I do not think it is particularly a bad
idea to add such a typo-detection
On Fri, Jun 07, 2013 at 08:47:59AM -0700, Junio C Hamano wrote:
When branch.$name.push mechanism is introduced and the user uses it,
then upstream, simple, or any other setting for that matter
would be ignored. With
[branch master]
remote = upstream
Matthieu Moy matthieu@grenoble-inp.fr writes:
* Ask the user to build external programs with
make GIT_ROOT=where/git/lives/
* or, ask users to checkout the external program as a subdirectory of
git.git to build it (for example, clang's build installation ask you
to put clang as a
Martin von Zweigbergk martinv...@gmail.com writes:
Changes since v5:
* Improved test_linear_range
* Changed TODOs to be about consistency, not --topo-order
Thanks, looked sensible.
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to
Junio C Hamano wrote:
This shows the triangular support in 1.8.3 is only half-finished;
the other half was discussed a few weeks ago ($gmane/224604)
I intentionally omitted that detail, because it is not directly
related to this bug. We have to fix the existing simple and upstream,
whether or
Leandro Lucarella wrote:
Thanks for the detailed explanations, I think this would cover my use
case. Just for clarification, here are some more details on this use
case, which I think is becoming very popular among github users.
We have a blessed repository (upstream in my case) and only a few
Le 07/06/2013 06:12, Eric Sunshine a écrit :
On Thu, Jun 6, 2013 at 3:34 PM, Célestin Matte
celestin.ma...@ensimag.fr wrote:
Signed-off-by: Célestin Matte celestin.ma...@ensimag.fr
Signed-off-by: Matthieu Moy matthieu@grenoble-inp.fr
---
contrib/mw-to-git/git-remote-mediawiki.perl |
On 6 June 2013 23:33, Fredrik Gustafsson iv...@iveqy.com wrote:
On Thu, Jun 06, 2013 at 06:35:43PM -0700, Constantine A. Murenin wrote:
I'm interested in running a web interface to this and other similar
git repositories (FreeBSD and NetBSD git repositories are even much,
much bigger).
On Fri, Jun 07, 2013 at 10:27:58PM +0530, Ramkumar Ramachandra wrote:
Leandro Lucarella wrote:
Thanks for the detailed explanations, I think this would cover my use
case. Just for clarification, here are some more details on this use
case, which I think is becoming very popular among github
SZEDER Gábor wrote:
Well, people out there might have completion scriplets for their
aliases or custom git commands which use __git_complete_file().
Removing this function would break those scripts.
What is the advantage of using __git_complete_file() over
__git_complete_revlist_file()? Isn't
SZEDER Gábor wrote:
the one at the top because
of the reasons given in $gmane/226272
Sorry about the delay: I went to sleep for a couple of days :P
the one at the bottom because
of the misleading commit message (__git_complete_file() always
completed refs first as part of the ref:file
Leandro Lucarella wrote:
I might try to just switch to current, I feel more comfortable with
simple because I feel is safer to explicitly set the upstream branch,
but is true that most of the time is not necessary.
Be more experimental! Use the lesser-known features, and tell us
about
Célestin Matte celestin.ma...@ensimag.fr writes:
The problem is that I took some policies into account for some parts of
the code, but not for all of it. For instance, in commit [15/18], I put
some numeric values in constants, but not all of them, as I think having
arg[3] in the code does
On Fri, Jun 07, 2013 at 10:05:37AM -0700, Constantine A. Murenin wrote:
On 6 June 2013 23:33, Fredrik Gustafsson iv...@iveqy.com wrote:
On Thu, Jun 06, 2013 at 06:35:43PM -0700, Constantine A. Murenin wrote:
I'm interested in running a web interface to this and other similar
git
Matthieu Moy wrote:
Reading Git for Windows's FAQ
( https://github.com/msysgit/msysgit/wiki/Frequently-Asked-Questions ),
it seems rather clear that the TODO-list is already long to have a
correct Perl support (I'm quite admirative of the work done already).
The POSIX guys shouldn't move
Matthieu Moy wrote:
I think it should be the Git for Windows community, and my feeling is
that the community developing Git for POSIX systems is far more active
than the one making it work for Windows (although we may now have more
windows users than unix users).
If I can be excused for being
Matthieu Moy matthieu@grenoble-inp.fr writes:
The POSIX guys shouldn't move faster than the Windows guys can follow.
That is a very good summary.
It does not mean everybody must always crawl at the same pace as the
slowest people. But it is one of the important things we should
consider,
Ramkumar Ramachandra artag...@gmail.com writes:
I think he way forward on Windows is an implementation like libgit2 or
git# with some sort of gui/ide integration. I never understood why
users on Windows want to use something as POSIX'y as git.git.
Whether it's based on POSIX is an
Ramkumar Ramachandra artag...@gmail.com writes:
SZEDER Gábor wrote:
the one at the top because
of the reasons given in $gmane/226272
Sorry about the delay: I went to sleep for a couple of days :P
the one at the bottom because
of the misleading commit message (__git_complete_file() always
On Fri, Jun 07, 2013 at 10:51:53PM +0530, Ramkumar Ramachandra wrote:
SZEDER Gábor wrote:
Well, people out there might have completion scriplets for their
aliases or custom git commands which use __git_complete_file().
Removing this function would break those scripts.
What is the
Scott McPeak smcp...@coverity.com writes:
I suggest that this problem could easily have been avoided if git
stash refused to run with a pending merge (present MERGE_HEAD file),
since this is crucial repository state that it does not save. This
seems similar to what git cherry-pick does.
Matthieu Moy wrote:
Visual Studio now has official Git support from MS (based on libgit2 if
I understood correctly). That's cool, but not a reason to kill msysgit
IMHO ;-).
Oh, I'm not interested in killing anything. If people want msysgit,
they will work on it: I'm nobody to say otherwise.
Jonathan Nieder wrote:
Ramkumar Ramachandra wrote:
I think he way forward on Windows is
Why is there only one way forward? Why do you get to pick it, given
that you've said you're not interested in working on it?
[...]
I never understood why
On Fri, Jun 07, 2013 at 11:00:14PM +0530, Ramkumar Ramachandra wrote:
SZEDER Gábor wrote:
the one at the top because
of the reasons given in $gmane/226272
Sorry about the delay: I went to sleep for a couple of days :P
the one at the bottom because
of the misleading commit message
Ramkumar Ramachandra artag...@gmail.com writes:
Whether it's based on POSIX is an implementation detail for the user.
The real question is more command-line Vs GUI than POSIX/Win32. Some
Linux users like GUI, some windows users use command-line. I tried IDE
integration with EGIT, and quite
Junio C Hamano wrote:
git log -Gcomplete_file -p contrib/completion found this one:
Now I do not recall suggesting it, and you (and I today after 2
years) may disagree with the rationale, but at least we can read
what was the intended meaning, I think.
Having spent so much time documenting
On 7 June 2013 10:57, Fredrik Gustafsson iv...@iveqy.com wrote:
On Fri, Jun 07, 2013 at 10:05:37AM -0700, Constantine A. Murenin wrote:
On 6 June 2013 23:33, Fredrik Gustafsson iv...@iveqy.com wrote:
On Thu, Jun 06, 2013 at 06:35:43PM -0700, Constantine A. Murenin wrote:
I'm interested in
On Fri, Jun 7, 2013 at 10:20 AM, Junio C Hamano gits...@pobox.com wrote:
Ramkumar Ramachandra artag...@gmail.com writes:
I think Felipe is using the argument that perl is declining to answer
the question why didn't you write git-related in perl instead?;
that's it.
A question which nobody
On Fri, Jun 7, 2013 at 2:00 PM, Matthieu Moy
matthieu@grenoble-inp.fr wrote:
Ramkumar Ramachandra artag...@gmail.com writes:
Whether it's based on POSIX is an implementation detail for the user.
The real question is more command-line Vs GUI than POSIX/Win32. Some
Linux users like GUI,
77c130 (completion: clarify ls-tree, archive, show completion,
2013-06-02) removed __git_complete_file () because it had no callers
left in the file. However, to avoid breaking user scripts that may
depend on this, add it back as a deprecated alias.
Signed-off-by: Ramkumar Ramachandra
On Thu, Jun 6, 2013 at 10:25 PM, Johannes Schindelin
johannes.schinde...@gmx.de wrote:
On Fri, 7 Jun 2013, Ramkumar Ramachandra wrote:
Johannes Schindelin wrote:
My initial reaction, too. It was hard enough to get Perl included with Git
for Windows (because of that pesky Subversion
On Fri, Jun 07, 2013 at 11:41:07AM -0700, Junio C Hamano wrote:
git log -Gcomplete_file -p contrib/completion found this one:
commit 1d66ec587e7d903afdf12a81718772a9eadc15a1
Author: SZEDER Gábor sze...@ira.uka.de
Date: Thu Mar 10 19:12:29 2011 +0100
bash: complete 'git diff
On Thu, Jun 6, 2013 at 3:19 PM, David Lang da...@lang.hm wrote:
On Fri, 7 Jun 2013, Ramkumar Ramachandra wrote:
David Lang wrote:
Perl use may or may not be declining (depending on how you measure it),
but
are you really willing to take on the task of re-writing everything
that's
in Perl
Felipe Contreras wrote:
This is fine by me, but at some point we need to decide how we should
prefix the functions that are supposed to be used by external scripts.
Yeah, I thought __ meant internal :/
Also, maybe we should start adding '# TODO remove in v2.0' so we
remember to do that in
On Fri, Jun 7, 2013 at 2:29 PM, Ramkumar Ramachandra artag...@gmail.com wrote:
Felipe Contreras wrote:
This is fine by me, but at some point we need to decide how we should
prefix the functions that are supposed to be used by external scripts.
Yeah, I thought __ meant internal :/
Also,
On Thu, Jun 06, 2013 at 06:05:44PM -0700, Junio C Hamano wrote:
SZEDER Gábor sze...@ira.uka.de writes:
On Thu, Jun 06, 2013 at 03:41:08PM -0700, Junio C Hamano wrote:
* rr/complete-difftool (2013-06-03) 2 commits
(merged to 'next' on 2013-06-04 at 01c7611)
+ completion: clarify
Am 07.06.2013 08:11, schrieb Martin von Zweigbergk:
Changes since v5:
* Improved test_linear_range
* Changed TODOs to be about consistency, not --topo-order
Martin von Zweigbergk (7):
add simple tests of consistency across rebase types
add tests for rebasing with patch-equivalence
Felipe Contreras wrote:
While at it, why not re-evaluate the whole msysgit approach? I bet we
don't need a whole separate project just to create a Windows
installer. I've written Windows installers before, it's very easy to
do from Linux.
Yeah, taking the pain out of msysgit packaging would
SZEDER Gábor sze...@ira.uka.de writes:
Now I do not recall suggesting it, and you (and I today after 2
years) may disagree with the rationale, but at least we can read
what was the intended meaning, I think.
See
http://thread.gmane.org/gmane.comp.version-control.git/167728/focus=168838
Ramkumar Ramachandra wrote:
commit a lot of good ruby code to contrib*
Oh, by the way: I have a project idea. There's this really popular
project called hub[1] that has an implementation of the GitHub API in
ruby. Unfortunately, it's a terrible piece of software because it
creates an extra
SZEDER Gábor wrote:
because nowadays __git_complete_file() is a wrapper around
__git_complete_revlist_file().
What? It was never anything different from a poorly-named alias for
__git_complete_revlist_file(). You have already agreed that
__git_complete_file() is a horrible name, so why not
Felipe Contreras felipe.contre...@gmail.com writes:
I think we heard enough from packaging folks that a new dependency
is unwelcome.
What are you talking about? Which are these packaging folks we heard from?
Dscho is one of the primary people behind msysgit effort, and I
consulted with
On Fri, Jun 7, 2013 at 2:55 PM, Junio C Hamano gits...@pobox.com wrote:
Felipe Contreras felipe.contre...@gmail.com writes:
I think we heard enough from packaging folks that a new dependency
is unwelcome.
What are you talking about? Which are these packaging folks we heard from?
Dscho is
On Fri, Jun 7, 2013 at 1:04 PM, Célestin Matte
celestin.ma...@ensimag.fr wrote:
Le 07/06/2013 06:12, Eric Sunshine a écrit :
On Thu, Jun 6, 2013 at 3:34 PM, Célestin Matte
celestin.ma...@ensimag.fr wrote:
} elsif ($cmd[0] eq import) {
- die(Invalid
On Thu, Jun 6, 2013 at 2:21 PM, Junio C Hamano gits...@pobox.com wrote:
Felipe Contreras felipe.contre...@gmail.com writes:
On Thu, Jun 6, 2013 at 1:30 PM, Junio C Hamano gits...@pobox.com wrote:
Felipe Contreras felipe.contre...@gmail.com writes:
Pretty much what it says on the tin.
And a
Le 07/06/2013 22:25, Eric Sunshine a écrit :
If you do choose to be more precise, it should be done as a separate
patch. Each conceptually distinct change should have its own patch.
Doing so makes changes easier to review and (generally) easier to
cherry-pick. For example, in this particular
Felipe Contreras (3):
sequencer: trivial fix
test: improve rebase -q test
submodule: remove unnecessary check
sequencer.c | 7 +--
submodule.c | 5 ++---
t/t3400-rebase.sh | 1 +
3 files changed, 8 insertions(+), 5 deletions(-)
--
1.8.3.698.g079b096
--
To unsubscribe
read_cache() already does that check.
Signed-off-by: Felipe Contreras felipe.contre...@gmail.com
---
submodule.c | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
diff --git a/submodule.c b/submodule.c
index ad476ce..8685424 100644
--- a/submodule.c
+++ b/submodule.c
@@ -603,9 +603,8
We should free objects before leaving.
Signed-off-by: Felipe Contreras felipe.contre...@gmail.com
---
sequencer.c | 7 +--
1 file changed, 5 insertions(+), 2 deletions(-)
diff --git a/sequencer.c b/sequencer.c
index ab6f8a7..7eeae2f 100644
--- a/sequencer.c
+++ b/sequencer.c
@@ -626,12
Let's show the output so it's clear why it failed.
Signed-off-by: Felipe Contreras felipe.contre...@gmail.com
---
t/t3400-rebase.sh | 1 +
1 file changed, 1 insertion(+)
diff --git a/t/t3400-rebase.sh b/t/t3400-rebase.sh
index b58fa1a..fb39531 100755
--- a/t/t3400-rebase.sh
+++
Ramkumar Ramachandra artag...@gmail.com writes:
77c130 (completion: clarify ls-tree, archive, show completion,
2013-06-02) removed __git_complete_file () because it had no callers
left in the file. However, to avoid breaking user scripts that may
depend on this, add it back as a deprecated
On Wed, Jun 5, 2013 at 9:17 PM, Junio C Hamano gits...@pobox.com wrote:
Charles McGarvey chazmcgar...@brokenzipper.com writes:
The bug is manifest when running gitweb in a persistent process (e.g.
FastCGI, PSGI), and it's easy to reproduce. If a gitweb request
includes the searchtext
On Fri, Jun 07, 2013 at 12:46:25PM -0700, Junio C Hamano wrote:
Thanks for a pointer. I think what I was suggesting was slightly
different in that I was hoping to see a single helper that knows to
complete to object names (possibly including trees/blobs with the
treeish:path notation),
MinGW's bash does not recognize an exit code -1 as failure. See also
47e3de0e (MinGW: truncate exit()'s argument to lowest 8 bits) and 2488df84
(builtin run_command: do not exit with -1). Exit code 1 is good enough.
Signed-off-by: Johannes Sixt j...@kdbg.org
---
test-chmtime.c | 8
1
In particular:
- move test preparations inside test_expect_success
- place test description on the test_expect_success line
- indent with a tab
Signed-off-by: Johannes Sixt j...@kdbg.org
---
t/t3010-ls-files-killed-modified.sh | 123 ++--
1 file changed, 61
The test cases include many corner-cases of merge-recursive's behavior,
some of them involve type changes and symbolic links. All cases, including
those that are protected by SYMLINKS check only whether the result of
merge-recursive is correctly stored in the database and the index; the
file
In t4023 and t4114, we have to remove the entries using 'git rm' because
otherwise the entries that must turn from symbolic links to regular files
would stay symbolic links in the index. For the same reason, we have to
use 'git mv' instead of plain 'mv' in t3509.
Signed-off-by: Johannes Sixt
Many tests that involve symbolic links actually check only whether our
algorithms are correct by investigating the contents of the object
database and the index. Only some of them check the filesystem.
This series introduces a function test_ln_s_add that inserts a symbolic
link in the index even
The part of the test that is about symbolic links in the index does not
require that the corresponding file system entry is actually a symbolic
link. Use test_ln_s_add to insert a symbolic link in the index. When
the file system does not support symbolic links, we actually have a
regular file in
t-basic hard-codes many object IDs. To cater to file systems that do
not support symbolic links, different IDs are used depending on the
SYMLINKS prerequisite. But we can observe the symbolic links are only
needed to generate index entries. Use test_ln_s_add to generate the
index entries and
There are many instances where the treatment of symbolic links in the
object model and the algorithms are tested, but where it is not
necessary to actually have a symbolic link in the worktree. Make
adjustments to the tests and remove the SYMLINKS prerequisite when
appropriate in trivial cases,
v2 of patch to follow perlcritic's recommandations ([1])
Changes with v1:
- split first commit into 6 different commits
- remove commit [17/18] about moving open() call
- took every other comment into account
[1]: http://thread.gmane.org/gmane.comp.version-control.git/226533
Célestin Matte
Follow perlcritic's InputOutput::RequireEncodingWithUTF8Layer policy
Signed-off-by: Célestin Matte celestin.ma...@ensimag.fr
Signed-off-by: Matthieu Moy matthieu@grenoble-inp.fr
---
contrib/mw-to-git/git-remote-mediawiki.perl |6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
Follow ValuesAndExpressions::ProhibitConstantPragma
Signed-off-by: Célestin Matte celestin.ma...@ensimag.fr
Signed-off-by: Matthieu Moy matthieu@grenoble-inp.fr
---
contrib/mw-to-git/git-remote-mediawiki.perl | 26 +-
1 file changed, 13 insertions(+), 13
Put first parameter of map inside a block, for better readability.
Follow BuiltinFunctions::RequireBlockMap
Signed-off-by: Célestin Matte celestin.ma...@ensimag.fr
Signed-off-by: Matthieu Moy matthieu@grenoble-inp.fr
---
contrib/mw-to-git/git-remote-mediawiki.perl | 14 --
1
Subroutines' parameters should be affected to variable before doing anything
else
Besides, existing instruction affected a variable inside a if, which break
Git's coding style
Signed-off-by: Célestin Matte celestin.ma...@ensimag.fr
Signed-off-by: Matthieu Moy matthieu@grenoble-inp.fr
---
Local variable $url has the same name as a global variable. Changing the name
of the local variable prevents future possible misunderstanding.
Signed-off-by: Célestin Matte celestin.ma...@ensimag.fr
Signed-off-by: Matthieu Moy matthieu@grenoble-inp.fr
---
1 - 100 of 153 matches
Mail list logo
