Am 30.05.2013 04:55, schrieb Jeff King:
> So while it would be nice to work on paths with colons everywhere, I
> doubt it is worth the effort to start checking it through the whole test
> suite.
And on top of it, on Windows, you can't have a path component or file
name that contains a colon...
--
2013/5/26 Jiang Xin :
> 2013/5/22 Michael Haggerty :
>
>> The old and new versions both seem to be (differently) inconsistent
>> about when the output has a trailing slash. What is the rule?
>
> The reason for introducing patch 02/15 is that we don't want to reinvent
> the wheel. Patch 06/15 (git-
On Wed, May 29, 2013 at 11:40 PM, Felipe Contreras
wrote:
> On Thu, May 30, 2013 at 1:14 AM, Martin von Zweigbergk
> wrote:
>> On Wed, May 29, 2013 at 10:41 PM, Felipe Contreras
>> wrote:
>>> On Thu, May 30, 2013 at 12:30 AM, Martin von Zweigbergk
>>> wrote:
On Wed, May 29, 2013 at 12:09 A
On Thu, May 30, 2013 at 1:14 AM, Martin von Zweigbergk
wrote:
> On Wed, May 29, 2013 at 10:41 PM, Felipe Contreras
> wrote:
>> On Thu, May 30, 2013 at 12:30 AM, Martin von Zweigbergk
>> wrote:
>>> On Wed, May 29, 2013 at 12:09 AM, Johannes Sixt
>>> wrote:
Am 5/29/2013 8:39, schrieb Martin
Hello,
I am Mr. Fang Yong from Wing Lung Bank.I have a secured business proposal worth
US$16.5M .Get back to me for more details.
Regards,
Fang L. Yong
--
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
On Wed, May 29, 2013 at 10:41 PM, Felipe Contreras
wrote:
> On Thu, May 30, 2013 at 12:30 AM, Martin von Zweigbergk
> wrote:
>> On Wed, May 29, 2013 at 12:09 AM, Johannes Sixt wrote:
>>> Am 5/29/2013 8:39, schrieb Martin von Zweigbergk:
+# f
+# /
+# a---b---c---g---h
>>
The docs seem to say that doing
git show-ref --head --tags
would show both the HEAD ref and all the tag refs. However, doing
both --head and either of --tags or --heads would filter out the HEAD
ref.
Signed-off-by: Doug Bell
---
I think this patch could be done better if I refactor the
On Wed, May 29, 2013 at 12:31 AM, Johannes Sixt wrote:
> Am 5/29/2013 8:39, schrieb Martin von Zweigbergk:
>> +test_run_rebase () {
>> + result=$1
>> + shift
>> + test_expect_$result "rebase $* --onto --root with merge-base does not
>> go to root" "
>> + reset_rebase &&
>>
On Thu, May 30, 2013 at 12:30 AM, Martin von Zweigbergk
wrote:
> On Wed, May 29, 2013 at 12:09 AM, Johannes Sixt wrote:
>> Am 5/29/2013 8:39, schrieb Martin von Zweigbergk:
>>> +# f
>>> +# /
>>> +# a---b---c---g---h
>>> +# \
>>> +# d---G---i
>> ...
>>> +test_run_rebase () {
On Wed, May 29, 2013 at 12:09 AM, Johannes Sixt wrote:
> Am 5/29/2013 8:39, schrieb Martin von Zweigbergk:
>> +# f
>> +# /
>> +# a---b---c---g---h
>> +# \
>> +# d---G---i
> ...
>> +test_run_rebase () {
>> + result=$1
>> + shift
>> + test_expect_$result "rebase $*
On Thu, May 30, 2013 at 12:23 AM, Jonathan Nieder wrote:
> Felipe Contreras wrote:
>> On Wed, May 29, 2013 at 6:43 PM, Jonathan Nieder wrote:
>>> A bigger problem (in my opinion) with allowing arbitrary changes to
>>> the meaning of existing commands is that scripts, whether placed in
>>> .sh fi
Felipe Contreras wrote:
> On Wed, May 29, 2013 at 6:43 PM, Jonathan Nieder wrote:
>> Ramkumar Ramachandra wrote:
>>> Making builtins override'able is also a terrible idea. It opens doors
>>> to potential bugs we don't want to deal with. Simple example:
>>>
>>>am = log -1
>>>log = am -3
On Wed, May 29, 2013 at 03:59:51PM -0700, Junio C Hamano wrote:
> Junio C Hamano writes:
>
> >> If we don't want to use \, this can also be done like this:
> >>
> >> FOO << EOF &&
> >> BLABLA
> >> EOF
> >> BAR &&
> >> VAR
> >>
> >> I think this is what you suggest.
> >
> > Yup, that is exactl
On Tue, May 28, 2013 at 9:24 PM, Ramkumar Ramachandra
wrote:
> Oh, and by the way:
>
> We're pretty close we are to replacing branch -v and branch -vv.
>
> brv = for-each-ref --format='%(HEAD)
> %C(green)%<(*)%(refname:short)%C(reset) %<(*)%(objectname:short)
> %(subject)' refs/heads
>
> brvv = fo
This script find people that might be interested in a patch, by going
back through the history for each single hunk modified, and finding
people that reviewed, acknowledge, signed, or authored the code the
patch is modifying.
It does this by running 'git blame' incrementally on each hunk, and then
Jeff King wrote:
> Yes, that is what I would expect git to do in such a situation. You can
> inspect it further, too:
>
> $ git rev-parse f51ac745^:pib/chkpib2.7
> e69de29bb2d1d6434b8b29ae775ad8c2e48c5391
>
> That's the sha1 of the blob containing the content. You can investigate
> informat
Junio C Hamano wrote:
> While you are at it, you may want to check your LESS environment
> variable settings, especially if you find that the command gives you
> control without showing anything for a small (not zero length) file.
Thanks. Thats a good tip. In my case LESS was not set to anything.
On Wed, May 29, 2013 at 6:43 PM, Jonathan Nieder wrote:
> Ramkumar Ramachandra wrote:
>> Bráulio Bhavamitra wrote:
>
>>> Agree, these aliased should work as a fallback or as an automatic short
>>> version
>>
>> Making builtins override'able is also a terrible idea. It opens doors
>> to potential
On Wed, May 29, 2013 at 3:27 PM, Ramkumar Ramachandra
wrote:
> Felipe Contreras wrote:
>> We should probably also add typical shortucts:
>>
>> d = diff
>> l = log
>> f = fetch
>> p = push
>> r = reset
>> ci = commit
>> rb = rebase
>> co = checkout
>> st = status
>> pi = cherry-pick
>> mt = mergeto
On Wed, May 29, 2013 at 10:52:58PM -0400, Jeff King wrote:
> diff --git a/t/test-lib.sh b/t/test-lib.sh
> index ca6bdef..5d84705 100644
> --- a/t/test-lib.sh
> +++ b/t/test-lib.sh
> @@ -600,7 +600,7 @@ fi
> fi
>
> # Test repository
> -TRASH_DIRECTORY="trash directory.$(basename "$0" .sh)"
> +T
On Wed, May 29, 2013 at 07:21:51PM -0700, Junio C Hamano wrote:
> Karsten Blees writes:
>
> > I realize colon was chosen to mimic git-check-attr, however,
> > check-attr prints relative paths only (I think?).
> >
> > How about using TAB or '|' instead? AFAICT, these are typically
> > not used in
On Wed, May 29, 2013 at 3:00 PM, Ramkumar Ramachandra
wrote:
> Felipe Contreras wrote:
>> On Wed, May 29, 2013 at 1:26 PM, Ramkumar Ramachandra
>> wrote:
>>> Bráulio Bhavamitra wrote:
root = rev-parse --show-toplevel
>>>
>>> What is your usecase for this?
>>
>> Some Git commands expect to
On Wed, May 29, 2013 at 6:23 PM, Junio C Hamano wrote:
> Felipe Contreras writes:
>
>> We already rely on cherry-pick for the 'am' mode, but only when using the
>> --keep-empty option, and when in such mode the behavior of 'git rebase'
>> changes
>> completely; more specifically; it's completely
On Thu, May 30, 2013 at 10:49:32AM +1000, Erik de Castro Lopo wrote:
> Look at this commit:
>
> git log --name-status f51ac745a6d4087cc4d77a3cee01db0412955c79
>
> and notice that one of the files modified is "pib/chkpib2.7", so lets
> look at the parent version of that file:
>
> git sho
Erik de Castro Lopo writes:
> Erik de Castro Lopo wrote:
>
>> Does this explanation make sense?
>
> Just to answer my own question, Yes it does.
>
> The file was added in commit 53266574 and was actually zero length
> at that time.
While you are at it, you may want to check your LESS environment
Nguyễn Thái Ngọc Duy writes:
> This makes git use wildmatch by default for all fnmatch() calls. Users
> who want to use system fnmatch (or compat fnmatch) need to set
> NO_WILDMATCH flag.
>
> wildmatch is a drop-in fnmatch replacement with more features. Using
> wildmatch gives us a consistent b
Karsten Blees writes:
> I realize colon was chosen to mimic git-check-attr, however,
> check-attr prints relative paths only (I think?).
>
> How about using TAB or '|' instead? AFAICT, these are typically
> not used in paths or glob patterns.
The primary reason to use ':' in "check-ignore -v" is
This makes git use wildmatch by default for all fnmatch() calls. Users
who want to use system fnmatch (or compat fnmatch) need to set
NO_WILDMATCH flag.
wildmatch is a drop-in fnmatch replacement with more features. Using
wildmatch gives us a consistent behavior across platforms. The
tentative pla
Am 25.05.2013 21:16, schrieb Pat Thoyts:
> On that note -- with this merge as it now stands I get the following
> test failures:
>
> t0008-ignores.sh 155, 158, 162, 164
These tests fail because they use absolute paths, e.g.
"C:/.../global-excludes", which is then translated t
Erik de Castro Lopo wrote:
> Does this explanation make sense?
Just to answer my own question, Yes it does.
The file was added in commit 53266574 and was actually zero length
at that time.
Cheers,
Erik
--
Erik de Castro Lopo
ht
Jeff King wrote:
> Yes, that should work as long as the file is modified and not added. You
> can also say "4d77a3cee^:A/B/C" if you do not want to look up the parent
> id yourself.
Thanks, that's useful to know.
> Note that for a merge commit with multiple parents, the question is more
> comple
On Thu, May 30, 2013 at 12:57 AM, Anthony Ramine wrote:
>>> If the range to match against is [A-_], it will become [a-_] which is an
>>> empty range, ord('a') > ord('_'). I think it is simpler to reuse toupper()
>>> after the fact as I did.
>>>
>>> Anyway maybe I should add a test for that corne
Torsten Bögershausen wrote:
> On 2013-05-28 19.04, Junio C Hamano wrote:
>>
>> Can you tell me what the conclusion on the discussion on your two
>> other patches on 'pu'?
>>
>> * rj/mingw-cygwin (2013-05-08) 2 commits
>> - cygwin: Remove the CYGWIN_V15_WIN32API build variable
>> - mingw: rename W
Junio C Hamano wrote:
>
> * rj/mingw-compat-st-mode-bits (2013-05-28) 1 commit
> - path: Fix a sparse warning
>
> Will merge to 'next'.
Hmm, this breaks the build on cygwin. :(
Now, I always test my patches on Linux, cygwin and MinGW
before sending, ... except that I obviously didn't test
on
On MinGW, sparse issues an "'get_st_mode_bits' not declared. Should
it be static?" warning. The MinGW and MSVC builds do not see the
declaration of this function, within git-compat-util.h, due to its
placement within an preprocessor conditional.
In order to suppress the warning, we simply move th
Here are the topics that have been cooking. Commits prefixed with
'-' are only in 'pu' (proposed updates) while commits prefixed with
'+' are in 'next'.
Usually I avoid issuing "What's cooking" back-to-back, but because I
will be offline for a few days, here is a snapshot of tonight's
status.
So
Ramkumar Ramachandra wrote:
> Bráulio Bhavamitra wrote:
>> Agree, these aliased should work as a fallback or as an automatic short
>> version
>
> Making builtins override'able is also a terrible idea. It opens doors
> to potential bugs we don't want to deal with. Simple example:
>
>am = log
Felipe Contreras writes:
> We already rely on cherry-pick for the 'am' mode, but only when using the
> --keep-empty option, and when in such mode the behavior of 'git rebase'
> changes
> completely; more specifically; it's completely broken. Manually enabling
> --keep-empty to be the default and
Junio C Hamano writes:
>> If we don't want to use \, this can also be done like this:
>>
>> FOO << EOF &&
>> BLABLA
>> EOF
>> BAR &&
>> VAR
>>
>> I think this is what you suggest.
>
> Yup, that is exactly what I meant (but no leading indentation before
> BAR and VAR).
>
> That way, it is a lo
"Michael S. Tsirkin" writes:
>> > +test_suppress_self () {
>> > + test_commit $3 &&
>> > + test_when_finished "git reset --hard HEAD^" &&
>> > + {
>> > + echo "#!$SHELL_PATH"
>> > + echo sed -n -e s/^cccmd--//p \"\$1\"
>> > + }
On Wed, May 29, 2013 at 01:28:52PM -0700, Junio C Hamano wrote:
> "Michael S. Tsirkin" writes:
>
> > Signed-off-by: Michael S. Tsirkin
> > ---
>
> Thanks.
Thanks, I'll address your comments and repost.
You asked some questions below, so I tried to answer.
> > t/t9001-send-email.sh | 41 +
Bráulio Bhavamitra wrote:
> Agree, these aliased should work as a fallback or as an automatic short
> version
Making builtins override'able is also a terrible idea. It opens doors
to potential bugs we don't want to deal with. Simple example:
am = log -1
log = am -3
--
To unsubscribe from
On Wed, May 29, 2013 at 11:48:53AM -0700, Junio C Hamano wrote:
> Jeff King writes:
>
> > On Wed, May 29, 2013 at 11:08:46AM -0700, Junio C Hamano wrote:
> >
> >> This has rather interesting ramifications on cherry-pick and rebase,
> >> though. Both command can handle changes that come from an o
Junio C Hamano wrote:
> The whole point of show-cdup is that people (especially those in
> java land) bury themselves in a hierarchy so deep that it is not
> feasible to tell "Go count the hierarchy and prefix that many ../
> yourself" to them.
Ah.
> The answer to "we cannot count ../" issue is "
Ramkumar Ramachandra writes:
>> cd Documentation; git blame :/Makefile
>
> *scratches head*
You lean new things every day ;-).
> cd Documentation; git blame ../Makefile
>
> Isn't this how pathspecs are specified everywhere?
The whole point of show-cdup is that people (especially thos
Duy Nguyen wrote:
> It's because you don't pad enough spaces after %(refname:short) so the
> starting point of %(upstream:short) on each line is already unaligned,
> I think.
Yeah, my stupidity. I really meant %>|(30), and that works fine.
--
To unsubscribe from this list: send the line "unsubscr
As of 95c6f271 "dir.c: unify is_excluded and is_path_excluded APIs", the
is_excluded API no longer recurses into directories that match an ignore
pattern, and returns the directory's ignored state for all contained paths.
This is OK for normal ignore patterns, i.e. ignoring a directory affects
the
"Michael S. Tsirkin" writes:
> Signed-off-by: Michael S. Tsirkin
> ---
Thanks.
> t/t9001-send-email.sh | 41 +
> 1 file changed, 41 insertions(+)
>
> diff --git a/t/t9001-send-email.sh b/t/t9001-send-email.sh
> index ebd5c5d..36ecf73 100755
> --- a/t/t9
Felipe Contreras wrote:
> We should probably also add typical shortucts:
>
> d = diff
> l = log
> f = fetch
> p = push
> r = reset
> ci = commit
> rb = rebase
> co = checkout
> st = status
> pi = cherry-pick
> mt = mergetool
Terrible idea. We'll be eating up more subcommands that the user
cannot
Junio C Hamano wrote:
>> Some Git commands expect to be in the top level directory (e.g. git blame).
>
> "Git" things we can fix [*1*], but more importantly, build structure
> of many project may require you to go up to the top to build the
> whole thing, so being able to get a relative path to the
Felipe Contreras writes:
> On Wed, May 29, 2013 at 1:26 PM, Ramkumar Ramachandra
> wrote:
>> Bráulio Bhavamitra wrote:
>>> root = rev-parse --show-toplevel
>>
>> What is your usecase for this?
>
> Some Git commands expect to be in the top level directory (e.g. git blame).
"Git" things we can
Here: put this at the end of the series and autosquash.
-- 8< --
From: Ramkumar Ramachandra
Date: Thu, 30 May 2013 01:29:59 +0530
Subject: [PATCH] fixup! HEAD~2
Signed-off-by: Ramkumar Ramachandra
---
builtin/push.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/builtin/
Felipe Contreras wrote:
> On Wed, May 29, 2013 at 1:26 PM, Ramkumar Ramachandra
> wrote:
>> Bráulio Bhavamitra wrote:
>>> root = rev-parse --show-toplevel
>>
>> What is your usecase for this?
>
> Some Git commands expect to be in the top level directory (e.g. git blame).
Um, git blame revert.c
Ramkumar Ramachandra writes:
> Junio C Hamano wrote:
>>> case PUSH_DEFAULT_CURRENT:
>>> + if (!branch)
>>> + die(_(message_detached_head_die), remote->name);
>>> add_refspec("HEAD");
>>> break;
>>
>> Would it hurt to do
>>
>>
Felipe Contreras writes:
>> Has this changed since 0a04e187e669 (completion: zsh: improve bash
>> script loading, 2013-05-24) which I have on 'pu'?
>
> Other than this change, nope.
>
>> If not, I can do this locally to save a roundtrip, if you want.
>
> Great, let's do that.
Done. The diff fro
Kenichi Saita writes:
> The temporary directory prepared by "difftool --dir-diff" to
> show the result of a change can be modified by the user via
> the tree diff program, and we try hard not to lose changes
> to them after tree diff program returns to us.
Thanks; will queue (unless there are ot
On Wed, May 29, 2013 at 1:26 PM, Ramkumar Ramachandra
wrote:
> Bráulio Bhavamitra wrote:
>> root = rev-parse --show-toplevel
>
> What is your usecase for this?
Some Git commands expect to be in the top level directory (e.g. git blame).
>> upstream-remote = !git upstream | sed -e 's/\\/.*$//g'
On Wed, May 29, 2013 at 1:11 PM, Bráulio Bhavamitra wrote:
> -- Forwarded message --
> From: Bráulio Bhavamitra
> Date: Wed, May 29, 2013 at 8:23 AM
> Subject: [git-users] Highlevel (but simple to implement) commands
> provided by default for git
> To: git-us...@googlegroups.com
Junio C Hamano wrote:
>> case PUSH_DEFAULT_CURRENT:
>> + if (!branch)
>> + die(_(message_detached_head_die), remote->name);
>> add_refspec("HEAD");
>> break;
>
> Would it hurt to do
>
> if (!branch_get(NULL))
>
Ramkumar Ramachandra writes:
> Setting push.default to current adds the refspec "HEAD" for the
> transport layer to handle. If "HEAD" doesn't resolve to a branch (and
> since no refspec rhs is specified), the push fails after some time with
> a cryptic error message:
>
> $ git push
> error:
On Wed, May 29, 2013 at 1:44 PM, Junio C Hamano wrote:
> Felipe Contreras writes:
>
>> On Wed, May 29, 2013 at 12:14 PM, Junio C Hamano wrote:
>>> Felipe Contreras writes:
>>>
> I do not see how it makes sense to copy how they deviate from us
> back to our codebase, especially if we pla
On Wed, May 29, 2013 at 12:49 PM, Junio C Hamano wrote:
> Felipe Contreras writes:
>
>> On Wed, May 29, 2013 at 1:17 AM, Johannes Sixt wrote:
>>> Am 5/29/2013 5:24, schrieb Felipe Contreras:
+if [ -z "$script" ]; then
+ local -a locations
+ locations=(
+ '
With this change, the output of the push (with push.default set to
current) changes subtly from:
$ git push
...
* [new branch] HEAD -> push-current-head
to:
$ git push
...
* [new branch] push-current-head -> push-current-head
This patch was written with a different motiv
Setting push.default to current adds the refspec "HEAD" for the
transport layer to handle. If "HEAD" doesn't resolve to a branch (and
since no refspec rhs is specified), the push fails after some time with
a cryptic error message:
$ git push
error: unable to push to unqualified destination: H
With push.default set to upstream or simple, and a detached HEAD, git
push prints the following error:
$ git push
fatal: You are not currently on a branch.
To push the history leading to the current (detached HEAD)
state now, use
git push ram HEAD:
This error is not unique to upstrea
The commit message in [3/3] is rewritten although I've mentioned the
original motivation at the end.
No other changes.
Ramkumar Ramachandra (3):
push: factor out the detached HEAD error message
push: fail early with detached HEAD and current
push: make push.default = current resolve HEAD ea
Junio C Hamano wrote:
> Felipe Contreras writes:
>
> > Junio C Hamano wrote:
> >> * fc/makefile (2013-05-26) 5 commits
> >> - build: do not install git-remote-testpy
> >> - build: add NO_INSTALL variable
> >> - build: cleanup using $<
> >> - build: cleanup using $^
> >> - build: trivial simp
Bráulio Bhavamitra writes:
> root = rev-parse --show-toplevel
Hmm, part of my "cdup" shell function looks something like
cdup () {
... error detection etc...
d=$(git rev-parse --show-toplevel)
cd "$d"
}
so I can quickly go up to the top-level. With "root", I
Karsten Blees gmail.com> writes:
> Øystein: in the meantime, could you check if this fixes the problem
for you?
>
> --- 8< ---
> diff --git a/dir.c b/dir.c
> index a5926fb..13858fe 100644
> --- a/dir.c
> +++ b/dir.c
> -821,6 +821,9 static void prep_exclude(struct
dir_struct *dir, c
Jeff King writes:
> On Wed, May 29, 2013 at 11:08:46AM -0700, Junio C Hamano wrote:
>
>> This has rather interesting ramifications on cherry-pick and rebase,
>> though. Both command can handle changes that come from an old tree
>> before some paths were renamed, but strict patch-id would not spo
Felipe Contreras writes:
> On Wed, May 29, 2013 at 12:14 PM, Junio C Hamano wrote:
>> Felipe Contreras writes:
>>
I do not see how it makes sense to copy how they deviate from us
back to our codebase, especially if we plan to eventually move some
of these tests out of contrib/ ar
"Ákos, Tajti" writes:
> Thanks for clarifying this thing for me! I don't really insist on
> having a master branch it's just that I tried to pull from a
> repository bundle and I got this error message:
>
> "Cannot merge multiple branches into empty head"
>
> The command was:
>
> git pull ../dump
On Wed, May 29, 2013 at 11:08:46AM -0700, Junio C Hamano wrote:
> This has rather interesting ramifications on cherry-pick and rebase,
> though. Both command can handle changes that come from an old tree
> before some paths were renamed, but strict patch-id would not spot
> equivalent changes we
Bráulio Bhavamitra wrote:
> root = rev-parse --show-toplevel
What is your usecase for this?
> upstream = !git for-each-ref --format='%(upstream:short)' $(git
> symbolic-ref -q HEAD)
Again, what is the usecase? What doesn't @{u} do?
> upstream-remote = !git upstream | sed -e 's/\\/.*$//g'
Felipe Contreras writes:
> When we are rebasing without options ('am' mode), the head rebased lives
> in '$g/rebase-apply/head-name', so lets use that information so it's
> reported the same way as if we were doing other rebases (-i or -m).
>
> Signed-off-by: Felipe Contreras
> ---
> contrib/co
Junio C Hamano wrote:
>> Is there something you're not happy with?
>
> By the way, you probably should stop thinking in terms of "me" being
> (un)happy. I am just trying to help by preventing (collectively) us
> making silly mistakes.
As a general principle, okay.
IIRC, nobody else had comments
-- Forwarded message --
From: Bráulio Bhavamitra
Date: Wed, May 29, 2013 at 8:23 AM
Subject: [git-users] Highlevel (but simple to implement) commands
provided by default for git
To: git-us...@googlegroups.com
Hello all,
One of the things I note about git is that is provides most
Jeff King writes:
> I think such a loose patch-id could just be a hash of the filenames that
> were changed by the patch (e.g., the first 32-bits of the sha1 of the
> concatenated filenames). Computing that should be about as expensive as
> a tree-diff. Per observation 2 above, if two commits do
Replied inline.
--
Anthony Ramine
Le 29 mai 2013 à 15:52, Duy Nguyen a écrit :
> On Wed, May 29, 2013 at 8:37 PM, Anthony Ramine wrote:
>> Le 29 mai 2013 à 15:22, Duy Nguyen a écrit :
>>
>>> On Tue, May 28, 2013 at 8:58 PM, Anthony Ramine wrote:
Case folding is not done correctly when m
On Wed, May 29, 2013 at 12:14 PM, Junio C Hamano wrote:
> Felipe Contreras writes:
>
>>> I do not see how it makes sense to copy how they deviate from us
>>> back to our codebase, especially if we plan to eventually move some
>>> of these tests out of contrib/ area, but even without such a plan i
Jeff King writes:
> On Wed, May 29, 2013 at 01:00:00AM -0400, Jeff King wrote:
>
>> So we see 83 and 84 non-verbose, which is good. And we see the actual
>> output from 85 (the output from a "git checkout"). But we do not see the
>> "expecting success" for it. We see it for the _next_ test, which
Felipe Contreras writes:
> On Wed, May 29, 2013 at 1:17 AM, Johannes Sixt wrote:
>> Am 5/29/2013 5:24, schrieb Felipe Contreras:
>>> +if [ -z "$script" ]; then
>>> + local -a locations
>>> + locations=(
>>> + '/etc/bash_completion.d/git' # fedora, old debian
>>> +
Ramkumar Ramachandra writes:
>> * rr/die-on-missing-upstream (2013-05-22) 2 commits
>> - sha1_name: fix error message for @{}, @{}
>> - sha1_name: fix error message for @{u}
>>
>> When a reflog notation is used for implicit "current branch", we
>> did not say which branch and worse said "bran
Junio C Hamano writes:
> Ramkumar Ramachandra writes:
>
>> For rr/rebase-autostash, which is stalled in pu. See $gmane/225689.
>>
>> This is a super-minor fix anyway: if you disagree with something, change
>> it; there's no need to ask me.
>
> As I wasn't the one who were disagreeing, that woul
Junio C Hamano wrote:
> As I wasn't the one who were disagreeing, that would not work
> well.
I meant in the tiny details like echo + gettext versus gettext.
>From the review of v3, nobody had any disagreements; just minor
suggestions: that's what this patch is about anyway.
--
To unsubscribe fro
Ramkumar Ramachandra writes:
> For rr/rebase-autostash, which is stalled in pu. See $gmane/225689.
>
> This is a super-minor fix anyway: if you disagree with something, change
> it; there's no need to ask me.
As I wasn't the one who were disagreeing, that would not work
well.
Was there anybody
Felipe Contreras writes:
> Junio C Hamano wrote:
>> * fc/makefile (2013-05-26) 5 commits
>> - build: do not install git-remote-testpy
>> - build: add NO_INSTALL variable
>> - build: cleanup using $<
>> - build: cleanup using $^
>> - build: trivial simplification
>> (this branch is used by f
Felipe Contreras writes:
>> I do not see how it makes sense to copy how they deviate from us
>> back to our codebase, especially if we plan to eventually move some
>> of these tests out of contrib/ area, but even without such a plan in
>> the future.
>
> They deviate from us, we deviate from them
On Wed, May 29, 2013 at 11:52 AM, Junio C Hamano wrote:
> Felipe Contreras writes:
>
>> Junio C Hamano wrote:
>>> Felipe Contreras writes:
>>>
>>> > Let's show the output so it's clear why it failed.
>>> >
>>> > Signed-off-by: Felipe Contreras
>>> > ---
>>> > t/t3400-rebase.sh | 1 +
>>> > 1 f
On Wed, May 29, 2013 at 11:42 AM, Junio C Hamano wrote:
> Felipe Contreras writes:
>
>> Junio C Hamano wrote:
>>> Felipe Contreras writes:
>>>
>>> > +wanted = get_config('remote-bzr.branches').rstrip().split(', ')
>>>
>>> Two minor nits and one design suggestion:
>>>
>>> - Why rstrip() not
Michael Haggerty writes:
> The commits leading up to this have (hopefully) fixed all of the
> callers of the for_each_ref()-like functions. This commit does the
> last step: documents what each_ref_fn callbacks can assume about
> object lifetimes.
>
> Signed-off-by: Michael Haggerty
I looked a
Michael Haggerty writes:
> The lifetime of the sha1 parameter passed to an each_ref_fn callback
> is not guaranteed, so make a copy for later use.
>
> Signed-off-by: Michael Haggerty
> ---
> bisect.c | 5 +++--
> 1 file changed, 3 insertions(+), 2 deletions(-)
>
> diff --git a/bisect.c b/bisect
Felipe Contreras writes:
> Junio C Hamano wrote:
>> Felipe Contreras writes:
>>
>> > Let's show the output so it's clear why it failed.
>> >
>> > Signed-off-by: Felipe Contreras
>> > ---
>> > t/t3400-rebase.sh | 1 +
>> > 1 file changed, 1 insertion(+)
>> >
>> > diff --git a/t/t3400-rebase.sh
Felipe Contreras writes:
> Junio C Hamano wrote:
>> Felipe Contreras writes:
>>
>> > +wanted = get_config('remote-bzr.branches').rstrip().split(', ')
>>
>> Two minor nits and one design suggestion:
>>
>> - Why rstrip() not strip()?
>
> The purpose of the strip is to remove the _single_
Michael Haggerty writes:
> Change the callers that were already passing copies to
> add_object_array_with_mode() to either skip the copy, or (if the
> memory needed to be allocated anyway) freeing the memory itself.
>
> A part of this commit effectively reverts
>
> 70d26c6e76 read_revisions_f
Am 29.05.2013 06:19, schrieb Duy Nguyen:
> On Wed, May 29, 2013 at 10:41 AM, Duy Nguyen wrote:
>> The changes in this area since 1.8.2.3 seem to be Karsten's (I'm not
>> blaming, just wanted to narrow down the problem). The patterns of
>> interest seem to be
>>
>> !/bin
>> /bin/*
>> !/bin/brew
>>
Michael Haggerty writes:
> The old version copied one entry to its destination position, then
> deleted any matching entries from the tail of the array. This
> required the tail of the array to be copied multiple times. It didn't
> affect the complexity of the algorithm because the whole tail h
The temporary directory prepared by "difftool --dir-diff" to
show the result of a change can be modified by the user via
the tree diff program, and we try hard not to lose changes
to them after tree diff program returns to us.
However, the set of files to be copied back is computed
differently bet
On Wed, May 29, 2013 at 02:06:29PM +0200, Matthieu Moy wrote:
> My use-case is an invalid SSL certificate. Pulling from the wiki with a
> recent version of libwww-perl fails, and git-remote-mediawiki gave no
> clue about the reason. Give the mediawiki API detailed error message, and
> since it is
On Wed, May 29, 2013 at 02:01:59PM +0200, Matthieu Moy wrote:
> > I wonder if we can do something like:
> >
> > our $mw_operation;
> > $mediawiki->{config}->{on_error} = sub {
> > [...]
> > die "$err\n";
> > };
>
> Probably, but that would hardcode the fact that mediawiki errors a
1 - 100 of 170 matches
Mail list logo
