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 fro
On Mon, Apr 01, 2013 at 11:22:36PM -0600, Felipe Contreras wrote:
> On Mon, Apr 1, 2013 at 11:14 PM, Jeff King 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 t
On Mon, Apr 1, 2013 at 11:14 PM, Jeff King 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 been r
On Mon, Apr 01, 2013 at 10:28:04AM -0700, Junio C Hamano wrote:
> Phil Hord 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
On Mon, Apr 1, 2013 at 11:01 PM, Jeff King 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 conne
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 8:22 PM, Jeff King 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 trick:
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 6:26 PM, Junio C Hamano 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 helper process
On Mon, Apr 1, 2013 at 8:30 PM, Jeff King 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 cases
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 protoco
On Mon, Apr 01, 2013 at 05:58:55PM -0600, Felipe Contreras wrote:
> On Mon, Apr 1, 2013 at 5:23 PM, Jeff King 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 c
Felipe Contreras 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 +++
> transport-helper.c| 8 +++
On Mon, Apr 1, 2013 at 5:33 PM, Jeff King 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 b/transport-helper.c
On Mon, Apr 1, 2013 at 5:23 PM, Jeff King 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 (cmd->last
On Mon, Apr 01, 2013 at 11:46:00PM +0200, Antoine Pelisse wrote:
> On Mon, Apr 1, 2013 at 11:14 PM, Felipe Contreras
> wrote:
> > +export TEST_LINT :=
>
> I think "test-lint-executable" still makes sense here.
Also test-lint-shell-syntax, which finds a problem with the current
code:
$ cd con
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
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
A little background would be nice here...what problem are we solving?
> -static int wait_or_whine(pid_t pid, const char
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
Johannes Sixt 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, thanks.
Is it t
On Mon, Apr 1, 2013 at 3:56 PM, Felipe Contreras
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:
http://article.gmane.org/gmane.comp.version-control.git/209581
Felipe Contreras writes:
> The fastimport plugin was only required in the early stage of
> development.
OK, thanks, will queue.
>
> Signed-off-by: Felipe Contreras
> ---
> contrib/remote-helpers/test-bzr.sh | 14 --
> 1 file changed, 14 deletions(-)
>
> diff --git a/contrib/remote
Hi,
On Mon, Apr 1, 2013 at 3:48 PM, Antoine Pelisse 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
>
> ---
> expecting
Do not merge!
Signed-off-by: Felipe Contreras
---
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 persistent_waitpid(struct child_process *
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 occ
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
---
expecting success:
test_when_finished "rm -rf gitrepo*" &&
(
cd hgrepo &&
hg u
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
---
git-remote-testgit| 1 +
t/t5801-remote-helpers.sh | 2 +-
transport-helper.c| 3 +++
3 files changed, 5 i
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 a/
And persistent_waitpid() to recover the information from the last run.
Signed-off-by: Felipe Contreras
---
run-command.c | 46 --
run-command.h | 6 ++
2 files changed, 46 insertions(+), 6 deletions(-)
diff --git a/run-command.c b/run-command.c
i
Hey Felipe,
On Mon, Apr 1, 2013 at 11:14 PM, Felipe Contreras
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 majordomo info at http:
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
---
The new test case r
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 +
contrib/remote-helpers/test-
There was some lingering code that shouldn't have been there in the
first place.
Signed-off-by: Felipe Contreras
---
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
b/contrib/remote-helpers/test-hg-hg-git.sh
in
The fastimport plugin was only required in the early stage of
development.
Signed-off-by: Felipe Contreras
---
contrib/remote-helpers/test-bzr.sh | 14 --
1 file changed, 14 deletions(-)
diff --git a/contrib/remote-helpers/test-bzr.sh
b/contrib/remote-helpers/test-bzr.sh
index 70aa
Since test-lint doesn't seem to work here, lets disable it. It wouldn't
help either way.
Signed-off-by: Felipe Contreras
---
contrib/remote-helpers/Makefile | 1 +
1 file changed, 1 insertion(+)
diff --git a/contrib/remote-helpers/Makefile b/contrib/remote-helpers/Makefile
index 9a76575..9c18ed
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,
intereste
Signed-off-by: Junio C Hamano
---
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
+++ b/t/t6200-fmt-merge-msg.sh
@
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 no
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
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 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 det
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
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
Nguyễn Thái Ngọc Duy 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
> ---
> Documentation/pretty-formats.txt | 3 ++-
> pr
Nguyễn Thái Ngọc Duy 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.
>
> Signed-off-by: N
Nguyễn Thái Ngọc Duy writes:
> Signed-off-by: Nguyễn Thái Ngọc Duy
> ---
> 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
> +++ b/utf8.c
> @@ -266,18 +266,26
Nguyễn Thái Ngọc Duy writes:
> This also adds color support to format_decoration()
>
> Signed-off-by: Nguyễn Thái Ngọc Duy
> ---
> log-tree.c | 60
> +---
> log-tree.h | 3 ++
> pretty.c |
Phil Hord 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
> Writing perl.ma
Junio C Hamano 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 "^{object}" p
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 t
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 s
Sebastian Götte 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 quick respo
Nguyễn Thái Ngọc Duy 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 think the prob
On Mon, Apr 1, 2013 at 8:14 AM, Jens Lehmann wrote:
> Am 01.04.2013 01:50, schrieb Phil Hord:
>> On Sun, Mar 31, 2013 at 4:34 PM, Ramkumar Ramachandra
>> wrote:
>>> Jens Lehmann wrote:
Guess what: submodules are the solution for a certain set of use
cases, and tools like subtree are a s
Nguyễn Thái Ngọc Duy 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 of object islan
Hi Thomas,
On Sun, 31 Mar 2013, Thomas Rast wrote:
> From: Thomas Rast
>
> 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: --valgri
In addition to "--summary-limit " support the form "--summary-limit=",
for consistency with other parameters and commands.
Signed-off-by: Rene Scharfe
---
git-submodule.sh | 17 +++--
1 file changed, 11 insertions(+), 6 deletions(-)
diff --git a/git-submodule.sh b/git-submodule.sh
i
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 de
Am 01.04.2013 01:50, schrieb Phil Hord:
> On Sun, Mar 31, 2013 at 4:34 PM, Ramkumar Ramachandra
> 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 silver
On Tue, Mar 12, 2013 at 1:53 AM, Matthieu Moy
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:
>
> _git_mv ()
> {
>
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 t
On Thu, Feb 28, 2013 at 12:59 PM, Manlio Perillo
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, however; and it seems
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 Verlob
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.
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 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 windo
66 matches
Mail list logo
