Duy Nguyen wrote:
On Mon, Apr 1, 2013 at 11:48 AM, Jonathan Nieder jrnie...@gmail.com wrote:
I'm afraid I can't imagine when --no-respect-skip-worktree would be
useful. That can easily be a failure of my imagination, though.
There may be scripts that expect git checkout -- foo to reset
CALL FOR PAPERS
** Find the conference links via http://www.wseas.org
Rhodes Island, Greece, July 16-19, 2013
Scientific Sponsors: Technical University of Sofia, Bulgaria, Polytechnic
University of Bari, Italy
and University Politehnica of Bucharest, Romania
17th CSCC
On Wed, Mar 27, 2013 at 02:40:51PM +0100, Gauthier Östervall wrote:
Colors that are changeable in Preferences gave no sufficient control,
putting colors in the config file allows for easier configuration and
sharing of color schemes.
win32: Make the default foreground color that of window
On Wed, Feb 20, 2013 at 12:14:20AM +0100, Dirk wrote:
Hi,
I added a file history browser for a single file in the gitk. I use git log
with the option --follow. This option is useful for the user switch from cvs
to git. He misses a history from only one file and the function Highlight
On Sun, Feb 03, 2013 at 06:37:42PM +, Anand Kumria wrote:
Hi Pau,
I've not been able to find the canonical location of your gitk repository.
I've tried kernel.org, samba.org and ozlabs.org; none of them to have
it - nor does any amount of google searching I do reveal the location.
I
Genau das, was sind die Quintessenz spannenden Edelstein Verlobungsringe
derzeit zur Verfügung? Möglicherweise sind der Inbegriff eleganten
Diamant-Verlobungsringe Diamant solitaire Ringe in populären Stilen wie
Behälter Diamant-Verlobungsringe, trellis Diamant-Verlobungsringe, Dom
Edelstein
On Thu, Feb 28, 2013 at 12:59 PM, Manlio Perillo
manlio.peri...@gmail.com wrote:
[1] Basically, on my system I need the following change at the end of
the file:
-_git
+autoload -U +X compinit compinit
+compdef _git git gitk
I don't know the reason,
Am 31.03.2013 22:34, schrieb Ramkumar Ramachandra:
Are you aware that current Git code already stats all files across
all submodules recursive by default? So (again) no problem here, we
do that already (unless configured otherwise).
I didn't know that. Why does it do this?
To show the user
On Tue, Mar 12, 2013 at 1:53 AM, Matthieu Moy
matthieu@grenoble-inp.fr wrote:
If I add a simple 'echo $cur 2' instead of the case, the problem
reappears. Somehow, the fact that I'm accessing $cur seems to create the
segfault. Actually, the minimalistic _git_mv reproducing the problem is:
Am 01.04.2013 01:50, schrieb Phil Hord:
On Sun, Mar 31, 2013 at 4:34 PM, Ramkumar Ramachandra
artag...@gmail.com wrote:
Jens Lehmann wrote:
Guess what: submodules are the solution for a certain set of use
cases, and tools like subtree are a solution for another set of
use cases. There is no
On 04/01/2013 04:47 AM, Junio C Hamano wrote:
I'll squash in something like the following and push out the result
on 'pu' tonight. Please check to see if I made silly mistakes while
doing so.
Thanks.
builtin/merge.c | 18 ++
1 file changed, 10 insertions(+), 8
In addition to --summary-limit n support the form --summary-limit=n,
for consistency with other parameters and commands.
Signed-off-by: Rene Scharfe rene.scha...@lsrfire.ath.cx
---
git-submodule.sh | 17 +++--
1 file changed, 11 insertions(+), 6 deletions(-)
diff --git
Hi Thomas,
On Sun, 31 Mar 2013, Thomas Rast wrote:
From: Thomas Rast tr...@inf.ethz.ch
I had a quick-and-dirty edit to t/valgrind/valgrind.sh in my trees
while we did the index-pack investigation. This small series is the
proper way of achieving the same.
Thomas Rast (3):
t/README:
Nguyễn Thái Ngọc Duy pclo...@gmail.com writes:
The last use of check_everything_connected after this series is
fetch.c:quickfetch(), which I think is unnecessary. It can only catch
errors if we have incomplete object islands in repo, which could
happen before this series.
A typical source
On Mon, Apr 1, 2013 at 8:14 AM, Jens Lehmann jens.lehm...@web.de wrote:
Am 01.04.2013 01:50, schrieb Phil Hord:
On Sun, Mar 31, 2013 at 4:34 PM, Ramkumar Ramachandra
artag...@gmail.com wrote:
Jens Lehmann wrote:
Guess what: submodules are the solution for a certain set of use
cases, and
Nguyễn Thái Ngọc Duy pclo...@gmail.com writes:
index-pack --strict looks up and follows parent commits. If shallow
information is not ready by the time index-pack is run, index-pack may
be lead to non-existent objects. Make fetch-pack save shallow file to
disk before invoking index-pack.
I
Sebastian Götte ja...@physik.tu-berlin.de writes:
On 04/01/2013 04:47 AM, Junio C Hamano wrote:
I'll squash in something like the following and push out the result
on 'pu' tonight. Please check to see if I made silly mistakes while
doing so.
Thanks.
...
Looks fine to me.
Thanks for a
Junio C Hamano [mailto:gis...@pobox.com] wrote:
As long as
the format will be backward compatible to allow existing users use existing
tools
to deal with cases the existing tools can handle, then that is OK. I didn't
get that
impression which is where my non starter came from.
I see now.
I have not seen this before, which makes me think it is something new
in the makefiles. But maybe it was a one-time fluke. When I ran
'make' again, it proceeded as normal.
My previous build was on pre-rebase 'next' at c1ece63. I did not try
a 'make clean' in between, but I have since. I tried
Junio C Hamano gits...@pobox.com writes:
Because the primary use case of this option is to implement end-user
input validation, I think it would be helpful to clarify use of the
peeler here. Perhaps
...
A SQUASH??? patch on top of your original is queued on 'pu',
together with the earlier
Phil Hord phil.h...@gmail.com writes:
I have not seen this before, which makes me think it is something new
in the makefiles. But maybe it was a one-time fluke. When I ran
'make' again, it proceeded as normal.
...
$ make prefix=/home/hordp all doc man
...
GEN git-add--interactive
Nguyễn Thái Ngọc Duy pclo...@gmail.com writes:
This also adds color support to format_decoration()
Signed-off-by: Nguyễn Thái Ngọc Duy pclo...@gmail.com
---
log-tree.c | 60
+---
log-tree.h | 3 ++
Nguyễn Thái Ngọc Duy pclo...@gmail.com writes:
Signed-off-by: Nguyễn Thái Ngọc Duy pclo...@gmail.com
---
utf8.c | 20 ++--
utf8.h | 1 +
2 files changed, 15 insertions(+), 6 deletions(-)
diff --git a/utf8.c b/utf8.c
index 82c2ddf..38322a1 100644
--- a/utf8.c
+++
Nguyễn Thái Ngọc Duy pclo...@gmail.com writes:
The commit encoding is parsed by logmsg_reencode, there's no need for
the caller to re-parse it again. The reencoded message now has the new
encoding, not the original one. The caller would need to read commit
object again before parsing.
Nguyễn Thái Ngọc Duy pclo...@gmail.com writes:
This is not simply convenient over %C(auto,xxx). Some placeholders
(actually only one, %d) do multi coloring and we can't emit a multiple
colors with %C(auto,xxx).
Signed-off-by: Nguyễn Thái Ngọc Duy pclo...@gmail.com
---
On Fri, Mar 29, 2013 at 04:32:00PM -0400, Jeff King wrote:
Agreed. Although I think it's getting out of my domain. I'm not even
sure how many factors are involved.
There's the load factor that causes us to grow, and the growth factor of
how aggressively we expand when we do need to grow.
The last three patches are a lot of fun. It would be nice to have
some test vectors for them.
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
The output of git submodule deinit sub of a populated submodule prints
rm 'sub'
as the first line unless used with the -f option.
The rm 'sub' line is exactly the same output the user gets when using
git rm sub (because that command is used with the --dry-run option under
the hood to
This is a patch I posted as an illustration, and then have been
carrying in my tree a while, with some tests.
Junio C Hamano (3):
merge: a random object may not necssarily be a commit
t6200: use test_config/test_unconfig
t6200: test message for merging of an annotated tag
builtin/merge.c
The user could have said git merge $(git rev-parse v1.0.0); we
shouldn't mark it as Merge commit '1598fb...' as the merge
name, even though such an invocation might be crazy.
We could even read the tag header from the tag object and replace
the object name the user gave us, but let's not
The tests were already well protected from previous ones by running
git config --unset on variables early they do not want to see, but
it is easier to make sure they start from a clean state by using
more modern test_config/test_unconfig helper functions.
It turns out that the last test depended
Signed-off-by: Junio C Hamano gits...@pobox.com
---
t/t6200-fmt-merge-msg.sh | 39 +++
1 file changed, 39 insertions(+)
diff --git a/t/t6200-fmt-merge-msg.sh b/t/t6200-fmt-merge-msg.sh
index f84bb0c..f73ecea 100755
--- a/t/t6200-fmt-merge-msg.sh
+++
Here are the topics that have been cooking. Commits prefixed with
'-' are only in 'pu' (proposed updates) while commits prefixed with
'+' are in 'next'.
A handful of topics that have been stalled for quite a while have
been discarded; for those that are not superseded by something else,
Since test-lint doesn't seem to work here, lets disable it. It wouldn't
help either way.
Signed-off-by: Felipe Contreras felipe.contre...@gmail.com
---
contrib/remote-helpers/Makefile | 1 +
1 file changed, 1 insertion(+)
diff --git a/contrib/remote-helpers/Makefile
The fastimport plugin was only required in the early stage of
development.
Signed-off-by: Felipe Contreras felipe.contre...@gmail.com
---
contrib/remote-helpers/test-bzr.sh | 14 --
1 file changed, 14 deletions(-)
diff --git a/contrib/remote-helpers/test-bzr.sh
There was some lingering code that shouldn't have been there in the
first place.
Signed-off-by: Felipe Contreras felipe.contre...@gmail.com
---
contrib/remote-helpers/test-hg-hg-git.sh | 1 -
1 file changed, 1 deletion(-)
diff --git a/contrib/remote-helpers/test-hg-hg-git.sh
Hi,
Here are a few fixes for the test framework on the remote-helpers.
Felipe Contreras (3):
remote-helpers: fix the run of all tests
remote-bzr: remove stale check code for tests
remote-hg: fix hg-git test-case
contrib/remote-helpers/Makefile | 1 +
Using 'git rerere forget .' after a merge that involved binary files
runs into an infinite loop if the binary file contains a zero byte.
Replace a strchrnul by memchr because the former does not make progress
as soon as the NUL is encountered.
Signed-off-by: Johannes Sixt j...@kdbg.org
---
The
Hey Felipe,
On Mon, Apr 1, 2013 at 11:14 PM, Felipe Contreras
felipe.contre...@gmail.com wrote:
+export TEST_LINT :=
I think test-lint-executable still makes sense here.
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More
And persistent_waitpid() to recover the information from the last run.
Signed-off-by: Felipe Contreras felipe.contre...@gmail.com
---
run-command.c | 46 --
run-command.h | 6 ++
2 files changed, 46 insertions(+), 6 deletions(-)
diff --git
Otherwise transport-helper will continue checking for refs and other
things what will confuse the user more.
---
git-remote-testgit| 11 +++
t/t5801-remote-helpers.sh | 19 +++
transport-helper.c| 8
3 files changed, 38 insertions(+)
diff --git
This way the test reliably succeeds (in catching the failure).
Not sure what's the proper way to do this, but here it is for the
record.
Signed-off-by: Felipe Contreras felipe.contre...@gmail.com
---
git-remote-testgit| 1 +
t/t5801-remote-helpers.sh | 2 +-
transport-helper.c|
Hi,
The first patch does all the work, the second patch uses it; basically, this is
needed so the transport-helper code is able to check if the remote-helper child
is stilll running. Without this support, the status of the remote-helper files
and configuration can end up very badly when errors
Do not merge!
Signed-off-by: Felipe Contreras felipe.contre...@gmail.com
---
run-command.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a/run-command.c b/run-command.c
index 16833df..6f20d5f 100644
--- a/run-command.c
+++ b/run-command.c
@@ -234,6 +234,7 @@ static pid_t
Hi,
On Mon, Apr 1, 2013 at 3:48 PM, Antoine Pelisse apeli...@gmail.com wrote:
I'm having an error in contrib/remote-helpers/test-hg.sh and it
reproduces on every version I tested since you implemented it. Is it
something in my environment that would make it wrong ?
Cheers,
Antoine
---
Felipe Contreras felipe.contre...@gmail.com writes:
The fastimport plugin was only required in the early stage of
development.
OK, thanks, will queue.
Signed-off-by: Felipe Contreras felipe.contre...@gmail.com
---
contrib/remote-helpers/test-bzr.sh | 14 --
1 file changed,
On Mon, Apr 1, 2013 at 3:56 PM, Felipe Contreras
felipe.contre...@gmail.com wrote:
You probably have a very old version of mercurial that has a bug, this
should workaround the issue:
http://thread.gmane.org/gmane.comp.version-control.git/209491
I meant:
Johannes Sixt j...@kdbg.org writes:
Using 'git rerere forget .' after a merge that involved binary files
runs into an infinite loop if the binary file contains a zero byte.
Replace a strchrnul by memchr because the former does not make progress
as soon as the NUL is encountered.
Hmph,
Hi,
Le lundi 01 avril 2013 à 12:57 -0700, Junio C Hamano a écrit :
The user could have said git merge $(git rev-parse v1.0.0); we
shouldn't mark it as Merge commit '1598fb...' as the merge
name, even though such an invocation might be crazy.
We could even read the tag header from the
On Mon, Apr 01, 2013 at 03:46:41PM -0600, Felipe Contreras wrote:
And persistent_waitpid() to recover the information from the last run.
Signed-off-by: Felipe Contreras felipe.contre...@gmail.com
A little background would be nice here...what problem are we solving?
-static int
On Mon, Apr 01, 2013 at 03:46:42PM -0600, Felipe Contreras wrote:
Otherwise transport-helper will continue checking for refs and other
things what will confuse the user more.
[...]
diff --git a/transport-helper.c b/transport-helper.c
index cb3ef7d..dfdfa7a 100644
--- a/transport-helper.c
On Mon, Apr 01, 2013 at 11:46:00PM +0200, Antoine Pelisse wrote:
On Mon, Apr 1, 2013 at 11:14 PM, Felipe Contreras
felipe.contre...@gmail.com wrote:
+export TEST_LINT :=
I think test-lint-executable still makes sense here.
Also test-lint-shell-syntax, which finds a problem with the
On Mon, Apr 1, 2013 at 5:23 PM, Jeff King p...@peff.net wrote:
On Mon, Apr 01, 2013 at 03:46:41PM -0600, Felipe Contreras wrote:
-static int wait_or_whine(pid_t pid, const char *argv0)
+static pid_t persistent_waitpid(struct child_process *cmd, pid_t pid, int
*stat_loc)
+{
+ if
On Mon, Apr 1, 2013 at 5:33 PM, Jeff King p...@peff.net wrote:
On Mon, Apr 01, 2013 at 03:46:42PM -0600, Felipe Contreras wrote:
Otherwise transport-helper will continue checking for refs and other
things what will confuse the user more.
[...]
diff --git a/transport-helper.c
Felipe Contreras felipe.contre...@gmail.com writes:
Otherwise transport-helper will continue checking for refs and other
things what will confuse the user more.
---
Sign-off?
git-remote-testgit| 11 +++
t/t5801-remote-helpers.sh | 19 +++
On Mon, Apr 01, 2013 at 05:58:55PM -0600, Felipe Contreras wrote:
On Mon, Apr 1, 2013 at 5:23 PM, Jeff King p...@peff.net wrote:
On Mon, Apr 01, 2013 at 03:46:41PM -0600, Felipe Contreras wrote:
-static int wait_or_whine(pid_t pid, const char *argv0)
+static pid_t
On Mon, Apr 01, 2013 at 06:12:45PM -0600, Felipe Contreras wrote:
Checking asynchronously for death like this is subject to a rac
condition; the helper may be about to die but not have died yet. In
practice we may catch some cases, but this seems like an indication that
the protocol is
On Mon, Apr 1, 2013 at 8:30 PM, Jeff King p...@peff.net wrote:
On Mon, Apr 01, 2013 at 06:12:45PM -0600, Felipe Contreras wrote:
Checking asynchronously for death like this is subject to a rac
condition; the helper may be about to die but not have died yet. In
practice we may catch some
On Mon, Apr 1, 2013 at 6:26 PM, Junio C Hamano gits...@pobox.com wrote:
OK, so the idea is that fetch_with_import() does
- get_helper(transport), which spawns a helper process;
- get_importer(transport, fastimport), which spawns a fast-import
and make it read from the output of the
On Mon, Apr 01, 2013 at 10:51:20PM -0600, Felipe Contreras wrote:
So in fetch_with_import, we have a remote-helper, and we have a
bidirectional pipe to it. We then call get_importer, which starts
fast-import, whose stdin is connected to the stdout of the remote
helper. We tell the
On Mon, Apr 1, 2013 at 8:22 PM, Jeff King p...@peff.net wrote:
On Mon, Apr 01, 2013 at 05:58:55PM -0600, Felipe Contreras wrote:
Are you saying that even if we have stored the result of a waitpid
command, if errno is EINTR, then we should still loop waitpid()? If
so, I guess this would do the
On Mon, Apr 01, 2013 at 11:11:20PM -0600, Felipe Contreras wrote:
But if we know from reading waitpid(3) that waitpid should only fail due
to EINTR, or due to bogus arguments (e.g., a pid that does not exist or
has already been reaped), then maybe something like this makes sense:
On Mon, Apr 1, 2013 at 11:01 PM, Jeff King p...@peff.net wrote:
On Mon, Apr 01, 2013 at 10:51:20PM -0600, Felipe Contreras wrote:
So in fetch_with_import, we have a remote-helper, and we have a
bidirectional pipe to it. We then call get_importer, which starts
fast-import, whose stdin is
On Mon, Apr 01, 2013 at 10:28:04AM -0700, Junio C Hamano wrote:
Phil Hord phil.h...@gmail.com writes:
I have not seen this before, which makes me think it is something new
in the makefiles. But maybe it was a one-time fluke. When I ran
'make' again, it proceeded as normal.
...
$
On Mon, Apr 1, 2013 at 11:14 PM, Jeff King p...@peff.net wrote:
On Mon, Apr 01, 2013 at 11:11:20PM -0600, Felipe Contreras wrote:
But if we know from reading waitpid(3) that waitpid should only fail due
to EINTR, or due to bogus arguments (e.g., a pid that does not exist or
has already
On Mon, Apr 01, 2013 at 11:22:36PM -0600, Felipe Contreras wrote:
On Mon, Apr 1, 2013 at 11:14 PM, Jeff King p...@peff.net wrote:
On Mon, Apr 01, 2013 at 11:11:20PM -0600, Felipe Contreras wrote:
But if we know from reading waitpid(3) that waitpid should only fail due
to EINTR, or due
On Mon, Apr 01, 2013 at 12:57:17PM -0700, Junio C Hamano wrote:
The user could have said git merge $(git rev-parse v1.0.0); we
shouldn't mark it as Merge commit '1598fb...' as the merge
name, even though such an invocation might be crazy.
We could even read the tag header from the tag
67 matches
Mail list logo
