On 5/13/2014 5:47 PM, Felipe Contreras wrote:
Junio C Hamano wrote:
Felipe Contreras writes:
Sigh, you just don't seem to understand that you are thinking
about a different issue. I don't think there's any other way I
can explain it to you.
Perhaps pointing out which commit(s) to revert mig
On Tue, May 13, 2014 at 09:07:12AM -0700, Jonathan Nieder wrote:
> Hi,
>
> Jeremiah Mahler wrote:
>
> > # from a string
> > $ git format-patch --signature "from a string" origin
> >
> > # or from a file
> > $ git format-patch --signature ~/.signature origin
>
> Interesting. But... what
Ronnie Sahlberg wrote:
> Make ref_update_reject_duplicates return any error that occurs through a
> new strbuf argument.
Sensible. The caller-visible effect would be that now
ref_transaction_commit() can pass back a helpful error message through
its "err" argument when asked to make multiple upd
Ronnie Sahlberg wrote:
> Could you please calm down and adjust your behavior. This constant
> hostility and rudeness makes the mailing list very unpleasant.
I explaind that to him multiple times. In the mail I replied to he is
once again assuming I'm a *insert-your-favorite-non-smart-adjective*,
On Sat, 2014-05-10 at 15:16 +0700, Duy Nguyen wrote:
> On Sat, May 3, 2014 at 6:14 AM, wrote:
> > The most sigificant patch uses Facebook's watchman daemon[1] to monitor
> > the repository work tree for changes. This makes allows git status
> > to avoid traversing the entire work tree to find ch
What's cooking in git.git (May 2014, #03; Tue, 13)
--
Here are the topics that have been cooking. Commits prefixed with
'-' are only in 'pu' (proposed updates) while commits prefixed with
'+' are in 'next'.
The tip of the 'master' branch has past v
James Denholm writes:
> I'm not sure that can actually happen - peel_committish is essentially
> implemented as `rev-parse $arg^0` (though with a bit of bling, of
> course), and to my understanding FETCH_HEAD will always parse to a
> committish - I could have missed something, of course.
$ git
On Wed, 2014-05-14 at 05:54 +0700, Duy Nguyen wrote:
> On Wed, May 14, 2014 at 5:38 AM, David Turner
> wrote:
> > On Mon, 2014-05-12 at 17:45 +0700, Duy Nguyen wrote:
> >> This is your quote from above, moved down a bit:
> >>
> >> > update_fs_cache should only have to update based on what it has
On Tue, May 13, 2014 at 3:22 PM, Felipe Contreras
wrote:
> Junio C Hamano wrote:
>> Felipe Contreras writes:
>>
>> > The tools are now maintained out-of-tree, and they have a regression in
>> > v2.0.
>>
>> You seem not to understand at all what a regression is.
>>
>> My understanding is that vers
Ronnie Sahlberg wrote:
> Add a strbuf argument to _commit so that we can pass an error string back to
> the caller. So that we can do error logging from the caller instead of from
> _commit.
>
> Longer term plan is to first convert all callers to use onerr==QUIET_ON_ERR
> and craft any log message
Junio C Hamano wrote:
> Felipe Contreras writes:
>
> > Junio, do you honestly think I am a troll?
>
> You certainly are acting like one, aren't you?
I'm deeply offended by the fact that would think that I'm purposely
intent on provoking people, or disrupting more important discussions.
I under
On Tue, May 13, 2014 at 12:34:13PM -0700, Junio C Hamano wrote:
> James Denholm writes:
> > I felt that defining revp would be a little more self-documenting than
> > using $rev^0.
>
> That is a good decision, but as long as we are attempting to peel,
> don't we want to stop the damage when it do
Junio C Hamano wrote:
> Felipe Contreras writes:
>
> > Sigh, you just don't seem to understand that you are thinking about a
> > different issue. I don't think there's any other way I can explain it to
> > you.
>
> Perhaps pointing out which commit(s) to revert might be a good point
> to start.
On Wed, May 14, 2014 at 5:38 AM, David Turner wrote:
> On Mon, 2014-05-12 at 17:45 +0700, Duy Nguyen wrote:
>> This is your quote from above, moved down a bit:
>>
>> > update_fs_cache should only have to update based on what it has learned
>> > from watchman. So if no .gitignore has been changed,
On Tue, May 13, 2014 at 3:44 PM, Jonathan Nieder wrote:
> Ronnie Sahlberg wrote:
>
>> Allow ref_transaction_free to be called with NULL and in extension allow
>> ref_transaction_rollback to be called for a NULL transaction.
>
> In extension = as a result?
>
> Makes sense. It lets someone do the u
Ronnie Sahlberg wrote:
> Allow ref_transaction_free to be called with NULL and in extension allow
> ref_transaction_rollback to be called for a NULL transaction.
In extension = as a result?
Makes sense. It lets someone do the usual
struct ref_transaction *transaction;
int ret =
Felipe Contreras writes:
> Sigh, you just don't seem to understand that you are thinking about a
> different issue. I don't think there's any other way I can explain it to
> you.
Perhaps pointing out which commit(s) to revert might be a good point
to start.
--
To unsubscribe from this list: send
Martin Langhoff wrote:
> I have had patches and contributions rejected in the past, sometimes
> rudely. Same has happened to many others, if you contribute long
> enough, it is pretty much guaranteed that it will happen to you.
> Maintainer is wrong, or you are wrong, or someone is just having a b
On Mon, 2014-05-12 at 17:45 +0700, Duy Nguyen wrote:
> This is your quote from above, moved down a bit:
>
> > update_fs_cache should only have to update based on what it has learned
> > from watchman. So if no .gitignore has been changed, it should not have
> > to do very much work.
> >
> > I cou
Junio C Hamano wrote:
> Felipe Contreras writes:
>
> > The tools are now maintained out-of-tree, and they have a regression in
> > v2.0.
>
> You seem not to understand at all what a regression is.
>
> My understanding is that versions of remote-hg shipped with all
> versions of Git did not work
William Giokas wrote:
> On Tue, May 13, 2014 at 03:24:51PM -0500, Felipe Contreras wrote:
> > William Giokas wrote:
> > > On Tue, May 13, 2014 at 02:09:55PM -0500, Felipe Contreras wrote:
> > > > As you say, it's perfectly OK.
> > >
> > > But wrong. Yes, it works, but it's not how it should be don
Signed-off-by: Josef 'Jeff' Sipek
On Tue, May 13, 2014 at 10:31:02PM +0200, Per Cederqvist wrote:
> This is analogous to how "guilt push" now fails when there are no more
> patches to push. Like push, the "--all" argument still succeeds even
> if there was no need to pop anything.
>
> Updated t
On Tue, May 13, 2014 at 10:30:52PM +0200, Per Cederqvist wrote:
> The 'echo %s' construct sometimes processes escape sequences. (This
%s? Should this be $s?
Otherwise, looks good.
> happens, for instance, under Ubuntu 14.04 when /bin/sh is actually
> dash.) We don't want that to happen when w
Felipe Contreras writes:
> The tools are now maintained out-of-tree, and they have a regression in
> v2.0.
You seem not to understand at all what a regression is.
My understanding is that versions of remote-hg shipped with all
versions of Git did not work with Hg 3.0, so not working with Hg 3.0
Signed-off-by: Josef 'Jeff' Sipek
On Tue, May 13, 2014 at 10:30:46PM +0200, Per Cederqvist wrote:
> There were two problems with the old code:
>
> - Since "set -e" is in effect (that is set in scaffold) the run-test
>script exited immediately if a t-*.sh script failed. This is not
>nic
Signed-off-by: Josef 'Jeff' Sipek
On Tue, May 13, 2014 at 10:30:53PM +0200, Per Cederqvist wrote:
> Give an error message if no patches are applied. Added a test case
> that never terminates unless this fix is applied.
>
> Signed-off-by: Per Cederqvist
> ---
> guilt-graph | 9 ++
On Tue, May 13, 2014 at 10:30:56PM +0200, Per Cederqvist wrote:
> Quote quotes with a backslash in the "guilt graph" output. Otherwise,
> the "dot" file could contain syntax errors.
>
> Added a test case.
>
> Signed-off-by: Per Cederqvist
> ---
> guilt-graph | 2 ++
> regression/t-03
On Tue, May 13, 2014 at 10:31:00PM +0200, Per Cederqvist wrote:
> Only one invocation of "disp" or "_disp" actually needed backslash
> processing. In quite a few instances, it was wrong to do backslash
> processing, as the message contained data derived from the user.
>
> Created the new function
On Tue, May 13, 2014 at 10:31:01PM +0200, Per Cederqvist wrote:
> This makes it easier to script operations on the entire queue, for
> example run the test suite on each patch in the queue:
>
> guilt pop -a;while guilt push; do make test||break; done
>
> This brings "guilt push" in line with
The tools are now maintained out-of-tree, and they have a regression in
v2.0. It's better to start warning the users as soon as possible.
Can't possibly introduce regressions.
Signed-off-by: Felipe Contreras
---
contrib/remote-helpers/git-remote-bzr | 3 +++
contrib/remote-helpers/git-remote-hg
Signed-off-by: Josef 'Jeff' Sipek
On Tue, May 13, 2014 at 10:30:55PM +0200, Per Cederqvist wrote:
> git branch names can contain commas. Check that "guilt graph" works
> even in that case.
>
> Signed-off-by: Per Cederqvist
> ---
> regression/t-033.out | 65
>
Felipe,
someone can contribute positively, and also be very destructive.
Your positive contributions, nobody will deny.
However, you have to tame the other part to be good company.
I have had patches and contributions rejected in the past, sometimes
rudely. Same has happened to many others, if
Sorry, I accidentally replied to the v1 of this patch...
On Tue, May 13, 2014 at 05:33:21PM -0400, Jeff Sipek wrote:
> On Fri, Mar 21, 2014 at 08:31:57AM +0100, Per Cederqvist wrote:
> > git branch names can contain commas. Check that "guilt graph" works
> > even in that case.
> >
> > Signed-off
On Fri, Mar 21, 2014 at 08:31:57AM +0100, Per Cederqvist wrote:
> git branch names can contain commas. Check that "guilt graph" works
> even in that case.
>
> Signed-off-by: Per Cederqvist
> ---
> regression/t-033.out | 62
>
> regression/t-
On Tue, May 13, 2014 at 10:30:43PM +0200, Per Cederqvist wrote:
> Test that we can combine any combination of patches with empty and
> non-empty messages, both with and without guilt.diffstat. (All
> patches are empty.)
>
> Signed-off-by: Per Cederqvist
> ---
> regression/t-035.out | 467
> +++
On Tue, May 13, 2014 at 10:54 PM, Jeff Sipek wrote:
> On Tue, May 13, 2014 at 04:45:47PM -0400, Theodore Ts'o wrote:
>> On Tue, May 13, 2014 at 10:30:36PM +0200, Per Cederqvist wrote:
> ...
>> > - Changed behavior: by default, guilt no longer changes branch when
>> >you push a patch. You nee
Since git 2.0.0 starting git gui in a submodule using a gitfile fails with
the following error:
No working directory ../../../
couldn't change working directory
to "../../../": no such file or
directory
This is because "git rev-parse --show-toplevel" is only run when git gui
sees a g
Thanks for the reminder, I'm currently looking into that.
Am 13.05.2014 10:30, schrieb Chris Packham:
> Hi,
>
> On 13/05/14 11:45, Yann Dirson wrote:
>> In 2.0rc2, git-gui is unable to work inside submodules, where 1.9.2
>> did not show such a problem:
>>
>>
>> yann@home:~$ cd /tmp/
>> yann@home:
On Tue, May 13, 2014 at 10:30:42PM +0200, Per Cederqvist wrote:
> A patch file consists of:
>
> (1) the description
> (2) optional diffstat
> (3) the patches
>
> When extracting the patch, we only want part 3. The do_get_patch used
> to give us part 2 and part 3. That made for instance this ser
Junio C Hamano wrote:
> The way I envision the longer term shape of git-remote-hg.py in the
> contrib/ is either one of these two:
>
> (1) manage it just like contrib/hooks/multimail/, keeping a
> reasonably fresh and known-to-be-good snapshot, while making it
> clear that my tree is n
Signed-off-by: Josef 'Jeff' Sipek
On Tue, May 13, 2014 at 10:30:40PM +0200, Per Cederqvist wrote:
> Signed-off-by: Per Cederqvist
> ---
> guilt-import-commit | 6 +++---
> 1 file changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/guilt-import-commit b/guilt-import-commit
> index 20dcee2
Felipe Contreras writes:
> Junio, do you honestly think I am a troll?
You certainly are acting like one, aren't you?
--
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-i
On Tue, May 13, 2014 at 03:24:51PM -0500, Felipe Contreras wrote:
> William Giokas wrote:
> > On Tue, May 13, 2014 at 02:09:55PM -0500, Felipe Contreras wrote:
> > > As you say, it's perfectly OK.
> >
> > But wrong. Yes, it works, but it's not how it should be done when we
> > have a code review s
William Giokas <1007...@gmail.com> writes:
> +try:
> +from mercurial.changegroup import getbundle
> +
> +except ImportError:
> +def getbundle(repo, **kwargs):
> +return repo.getbundle(**kwargs)
> +
> import re
> import sys
> import os
> @@ -985,7 +992,8 @@ def push_unsafe(repo,
On Tue, May 13, 2014 at 10:31:05PM +0200, Per Cederqvist wrote:
> Signed-off-by: Per Cederqvist
> ---
> .dir-locals.el | 3 +++
> Documentation/Contributing | 15 +++
> 2 files changed, 18 insertions(+)
> create mode 100644 .dir-locals.el
>
> diff --git a/.dir-locals.el
On Tue, May 13, 2014 at 04:45:47PM -0400, Theodore Ts'o wrote:
> On Tue, May 13, 2014 at 10:30:36PM +0200, Per Cederqvist wrote:
...
> > - Changed behavior: by default, guilt no longer changes branch when
> >you push a patch. You need to do "git config guilt.reusebranch
> >false" to re-en
On Tue, May 13, 2014 at 10:30:36PM +0200, Per Cederqvist wrote:
> I recently found myself sitting on a train with a computer in front of
> me. I tried to use "guilt import-commit", which seemed to work, but
> when I tried to "guilt push" the commits I had just imported I got
> some errors. It tur
A reasonable regression fix. Will queue for 2.0 final.
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
Signed-off-by: Per Cederqvist
---
.dir-locals.el | 3 +++
Documentation/Contributing | 15 +++
2 files changed, 18 insertions(+)
create mode 100644 .dir-locals.el
diff --git a/.dir-locals.el b/.dir-locals.el
new file mode 100644
index 000..50ef2b7
--- /dev/null
+++
Signed-off-by: Per Cederqvist
Signed-off-by: Josef 'Jeff' Sipek
---
guilt-patchbomb | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/guilt-patchbomb b/guilt-patchbomb
index 1231418..164b10c 100755
--- a/guilt-patchbomb
+++ b/guilt-patchbomb
@@ -47,7 +47,7 @@ if [ $? -ne 0 ]; t
Signed-off-by: Per Cederqvist
Signed-off-by: Josef 'Jeff' Sipek
---
guilt-rebase | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/guilt-rebase b/guilt-rebase
index fd28e48..a1714a0 100755
--- a/guilt-rebase
+++ b/guilt-rebase
@@ -66,7 +66,7 @@ pop_all_patches
git merge --no-c
Use --no-decorate in the call to git log that tries to read the commit
message to produce patch names. Otherwise, if the user has set
log.decorate to short or full, the patch name will be less useful.
Modify the t-034.sh test case to demonstrate that this is needed.
Signed-off-by: Per Cederqvist
Only one invocation of "disp" or "_disp" actually needed backslash
processing. In quite a few instances, it was wrong to do backslash
processing, as the message contained data derived from the user.
Created the new function "disp_e" that should be used when backslash
processing is required, and c
When the option is true (the default), Guilt does not create a new Git
branch when patches are applied. This way, you can switch between
Guilt 0.35 and the current version of Guilt with no issues.
At a future time, maybe a year after Guilt with guilt.reusebranch
support is released, the default s
This makes it easier to script operations on the entire queue, for
example run the test suite on each patch in the queue:
guilt pop -a;while guilt push; do make test||break; done
This brings "guilt push" in line with the push operation in Mercurial
Queues (hg qpush), which fails when there ar
Fix remove_topic() in t-061.sh so that it doesn't print a git hash.
Signed-off-by: Per Cederqvist
Signed-off-by: Josef 'Jeff' Sipek
---
regression/t-061.out | 1 -
regression/t-061.sh | 2 +-
2 files changed, 1 insertion(+), 2 deletions(-)
diff --git a/regression/t-061.out b/regression/t-061.
This is analogous to how "guilt push" now fails when there are no more
patches to push. Like push, the "--all" argument still succeeds even
if there was no need to pop anything.
Updated the test suite.
Signed-off-by: Per Cederqvist
---
guilt-pop| 17 +++--
regression/t-
Quote quotes with a backslash in the "guilt graph" output. Otherwise,
the "dot" file could contain syntax errors.
Added a test case.
Signed-off-by: Per Cederqvist
---
guilt-graph | 2 ++
regression/t-033.out | 22 ++
regression/t-033.sh | 9 +
3 files ch
git branch names can contain commas. Check that "guilt graph" works
even in that case.
Signed-off-by: Per Cederqvist
---
regression/t-033.out | 65
regression/t-033.sh | 39 +++
2 files changed, 104 insertions(+)
This fix relies on the fact that git branch names can not contain ":".
Signed-off-by: Per Cederqvist
Signed-off-by: Josef 'Jeff' Sipek
---
guilt-graph | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/guilt-graph b/guilt-graph
index 56d0e77..924a63e 100755
--- a/guilt-graph
++
The 'echo %s' construct sometimes processes escape sequences. (This
happens, for instance, under Ubuntu 14.04 when /bin/sh is actually
dash.) We don't want that to happen when we are importing commits, so
use 'printf %s "$s"' instead.
(The -E option of bash that explicitly disables backslash exp
Give an error message if no patches are applied. Added a test case
that never terminates unless this fix is applied.
Signed-off-by: Per Cederqvist
---
guilt-graph | 9 +++--
regression/t-033.out | 3 +++
regression/t-033.sh | 13 +
3 files changed, 23 insertions(+),
The valid_patchname now lets "git check-ref-format" do its job instead
of trying (and failing) to implement the same rules. See
git-check-ref-format(1) for a list of the rules.
Refer to the git-check-ref-format(1) man page in the error messages
produced when valid_patchname indicates that the nam
Try harder to create patch names that adhere to the rules in
git-check-ref-format(1) when deriving a patch name from the commit
message. Verify that the derived name using "git check-ref-format",
and as a final fallback simply use the patch name "x" (to ensure that
the code is future-proof in case
William Giokas wrote:
> On Tue, May 13, 2014 at 02:09:55PM -0500, Felipe Contreras wrote:
> > William Giokas wrote:
> > > On Tue, May 13, 2014 at 10:30:26AM -0700, Junio C Hamano wrote:
> >
> > > > Why do we "import changegroup" unconditionally, even though it
> > > > is only used in the n
There were two problems with the old code:
- Since "set -e" is in effect (that is set in scaffold) the run-test
script exited immediately if a t-*.sh script failed. This is not
nice, as we want the error report that test_failed prints.
- The code ran "cd -" between running the t-*.sh scr
If you run something like "guilt header '.*'" the command would crash,
because the grep comand that tries to ensure that the patch exist
would detect a match, but the later code expected the match to be
exact.
Fixed by comparing exact strings.
And as a creeping feature "guilt header" will now try
Signed-off-by: Per Cederqvist
---
regression/t-028.out | 7 +++
regression/t-028.sh | 4
2 files changed, 11 insertions(+)
diff --git a/regression/t-028.out b/regression/t-028.out
index 1564c09..ea72a3a 100644
--- a/regression/t-028.out
+++ b/regression/t-028.out
@@ -49,3 +49,10 @@ Sig
The shouldfail function already redirects stderr to stdout, so there
is no need to do the same in t-028.sh and t-021.sh.
Signed-off-by: Per Cederqvist
Signed-off-by: Josef 'Jeff' Sipek
---
regression/t-021.sh | 2 +-
regression/t-025.sh | 2 +-
regression/t-028.sh | 2 +-
3 files changed, 3 ins
The "cmd" and "shouldfail" functions checked the exit status of the
replace_path function instead of the actual command that was running.
(The $? construct checks the exit status of the last command in a
pipeline, not the first command.)
Updated t-032.sh, which used "shouldfail" instead of "cmd" i
William Giokas <1007...@gmail.com> writes:
> In mercurial 3.0, getbundle was moved to the changegroup module, and
> gained a new argument. Due to this we cannot simply start using
> getbundle(...) imported from either one unconditionally, as that would
> cause errors in mercurial 3.0 without chang
Test that empty patches are handled correctly, both with and without
the guilt.diffstat configuration option.
Signed-off-by: Per Cederqvist
---
regression/t-020.out | 250 +++
regression/t-020.sh | 60 +
2 files changed, 310 insertion
Test that we can combine any combination of patches with empty and
non-empty messages, both with and without guilt.diffstat. (All
patches are empty.)
Signed-off-by: Per Cederqvist
---
regression/t-035.out | 467 +++
regression/t-035.sh | 62
The argument parser arbitrarily refused to accept more than 4
arguments. That made it impossible to run "guilt new -f -s -m msg
patch". Removed the checks for the number of arguments from the
"guilt new" parser -- the other checks that are already there are
enough to catch all errors.
Give a bet
A patch file consists of:
(1) the description
(2) optional diffstat
(3) the patches
When extracting the patch, we only want part 3. The do_get_patch used
to give us part 2 and part 3. That made for instance this series of
operations fail if guilt.diffstat is true:
guilt push empty-1
gu
Ensure that the file really is deleted.
Signed-off-by: Per Cederqvist
Signed-off-by: Josef 'Jeff' Sipek
---
regression/t-026.out | 15 +++
regression/t-026.sh | 5 -
2 files changed, 19 insertions(+), 1 deletion(-)
diff --git a/regression/t-026.out b/regression/t-026.out
inde
Signed-off-by: Per Cederqvist
---
guilt-import-commit | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/guilt-import-commit b/guilt-import-commit
index 20dcee2..f14647c 100755
--- a/guilt-import-commit
+++ b/guilt-import-commit
@@ -23,7 +23,7 @@ if ! must_commit_first; the
Signed-off-by: Per Cederqvist
Signed-off-by: Josef 'Jeff' Sipek
---
guilt-delete | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/guilt-delete b/guilt-delete
index 3e394f8..967ac10 100755
--- a/guilt-delete
+++ b/guilt-delete
@@ -49,7 +49,7 @@ series_remove_patch "$patch"
g
Explicitly set guilt.diffstat to its default value. Without this, the
027 test (and possibly others) fail if guilt.diffstat is set to true
in ~/.gitconfig.
Signed-off-by: Per Cederqvist
Signed-off-by: Josef 'Jeff' Sipek
---
regression/scaffold | 1 +
1 file changed, 1 insertion(+)
diff --git
This is version two of the patch series I sent back on 21 Mar 2014. I
have addressed all feedback to date, updated the coding style, and
added signed-off-by lines from Jeff Sipek for those commits that I
have received an explicit approval from him (but only if I have not
made any other change to t
Hi,
Ronnie Sahlberg wrote:
> This patch series is based on next and expands on the transaction API.
Sorry to take so long to get to this.
For the future, it's easier to review patches based on some particular
branch that got merged into next, since next is a moving target
(series come and go fr
In mercurial 3.0, getbundle was moved to the changegroup module, and
gained a new argument. Due to this we cannot simply start using
getbundle(...) imported from either one unconditionally, as that would
cause errors in mercurial 3.0 without changing the syntax, and errors in
mercurial <3.0 if we d
On Tue, May 13, 2014 at 07:57:08AM +0200, Johannes Sixt wrote:
> Am 5/13/2014 1:10, schrieb Max Kirillov:
>> --- a/t/t7007-show.sh
>> +++ b/t/t7007-show.sh
>> @@ -25,6 +25,7 @@ test_expect_success 'set up a bit of history' '
>> git checkout -b side HEAD^^ &&
>> test_commit side2 &&
>>
On Tue, May 13, 2014 at 12:26:42PM -0700, Junio C Hamano wrote:
> Hmph. Having these as two separate commits would mean that 1/2
> alone will break the test, hurting bisectability a little bit. The
> necessary adjustments in this patch is small enough that we may be
> better off squashing them in
On Tue, May 13, 2014 at 02:09:55PM -0500, Felipe Contreras wrote:
> William Giokas wrote:
> > On Tue, May 13, 2014 at 10:30:26AM -0700, Junio C Hamano wrote:
>
> > > Why do we "import changegroup" unconditionally, even though it
> > > is only used in the new codepath meant only for version
William Giokas wrote:
> On Tue, May 13, 2014 at 10:30:26AM -0700, Junio C Hamano wrote:
> > Why do we "import changegroup" unconditionally, even though it
> > is only used in the new codepath meant only for version 3.0 or
> > higher, not inside the "if" block that decides if we need th
James Denholm writes:
> cmd_add_commit() is passed FETCH_HEAD by cmd_add_repository, which is
> then rev-parsed into an object ID. However, if the user is fetching a
> tag rather than a branch HEAD, such as by executing:
>
> $ git subtree add -P oldGit https://github.com/git/git.git tags/v1.8.0
>
Max Kirillov writes:
> 'git show' used to print extra newline after merge commit, and it was
> recorded so into the test reference data. Now when the behavior is
> fixed, the tests should be updated.
>
> Signed-off-by: Max Kirillov
> ---
Hmph. Having these as two separate commits would mean th
In mercurial 3.0, getbundle was moved to the changegroup module, and
gained a new argument. Due to this we cannot simply start using
getbundle(...) imported from either one unconditionally, as that would
cause errors in mercurial 3.0 without changing the syntax, and errors in
mercurial <3.0 if we d
Junio C Hamano wrote:
> Martin Langhoff writes:
>
> > On Fri, May 9, 2014 at 5:54 PM, Felipe Contreras
> > wrote:
> >> You are once more twisting the sequence of events.
> >
> > Found this gem looking for background to the proposed removal to code of
> > mine.
> >
> > Felipe, if you are wanting
sze...@ira.uka.de writes:
> Commit 59d3924fb (prompt: fix missing file errors in zsh) added the
> helper function eread() to git-prompt.sh. That function should be in
> the git "namespace", i.e. prefixed with __git_, otherwise it might
> collide with a function of the same name in the user'
On Tue, May 13, 2014 at 10:30:26AM -0700, Junio C Hamano wrote:
> Torsten Bögershausen writes:
>
> > I did some testing with Git 2.0-rc3 + 58aee0864adeeb5363f.
> > The remote-helper tests for hg-git worked OK
> > with both hg version 2.9 and 3.0 under both Mac OS and Linux.
> >
> > Should we cons
The earlier documentation made vague references to "is set to build
on". Flesh that out with references to the config settings, so folks
can use git-config(1) to get more detail on what @{upstream} means.
For example, @{upstream} does not care about remote.pushdefault or
branch..pushremote.
Signe
Martin Langhoff wrote:
> On Tue, May 13, 2014 at 2:05 PM, Felipe Contreras
> wrote:
> > This tool doesn't even work anyway.
>
> It doesn't? Bug report / more info please?
Show me that it does. The documentation is lacking, and there's no tests
at all.
So it's hard to say is anybody supposed to
Junio C Hamano wrote:
> It is time to catch regressions by asking wider audiences who do not
> normally follow Git development (i.e. those who are not the ones that
> follow 'master' and rebuild/install it once or twice a week for their
> daily use).
And you have one of those regressions in Git v
Martin Langhoff writes:
> On Fri, May 9, 2014 at 5:54 PM, Felipe Contreras
> wrote:
>> You are once more twisting the sequence of events.
>
> Found this gem looking for background to the proposed removal to code of mine.
>
> Felipe, if you are wanting to have a war of words with Junio, go have
>
Martin Langhoff writes:
> On Thu, May 8, 2014 at 9:33 PM, Felipe Contreras
> wrote:
>> No updates since 2010, and no tests.
>
> NAK.
>
> IMHO, this is quite unfriendly.
>
> Is this removal based on your opinion, or Junio's position (or
> consensus from maintainers from the list)? If there is a c
On Tue, May 13, 2014 at 2:05 PM, Felipe Contreras
wrote:
> This tool doesn't even work anyway.
It doesn't? Bug report / more info please?
cheers,
m
--
martin.langh...@gmail.com
- ask interesting questions
- don't get distracted with shiny stuff - working code first
~ http://docs.moodle.
On Fri, May 9, 2014 at 1:44 PM, Junio C Hamano wrote:
> Eric Wong writes:
>
>> Felipe Contreras wrote:
>>> No updates since 2010, and no tests.
>>
>> Who benefits from this removal? Is this causing a maintenance
>> burden for Junio?
>
> No. See http://thread.gmane.org/gmane.comp.version-contro
Martin Langhoff wrote:
> On Thu, May 8, 2014 at 9:33 PM, Felipe Contreras
> wrote:
> > No updates since 2010, and no tests.
>
> NAK.
>
> IMHO, this is quite unfriendly.
>
> Is this removal based on your opinion, or Junio's position (or
> consensus from maintainers from the list)? If there is a
1 - 100 of 142 matches
Mail list logo
