[url=http://www.pndoracharmonlineshop.ca/] pandora charms[/url] offers
consequently turn out to be an incredibly well-liked make of jewelry. There
are lots of components of jewelry it's possible to purchase. Actually you
will find a wide variety of components of jewelry to select from it's reall
On Wed, Mar 20, 2013 at 02:36:32AM -0400, Andrew Rodland wrote:
> While investigating this StackOverflow question:
> http://stackoverflow.com/questions/15516168/how-to-cross-compile-git-for-arm
> I found that fetch-pack.c uses ST_MTIME_NSEC outside of the protection
> of #ifdef USE_NSEC. This resu
test_config() is already a well-defined function in
test-lib-functions.sh. Don't duplicate it unnecessarily in:
t4018-diff-funcname.sh
t7810-grep.sh
t7811-grep-open.sh
Signed-off-by: Ramkumar Ramachandra
---
Thanks, Junio.
t/t4018-diff-funcname.sh | 5 -
t/t7810-grep.sh |
From: Johannes Sixt
Two tests use GIT_TRACE=3 to dump debugging information of git. On
Windows, however, bash is unable to set up file descriptor 3 correctly
for its child process, so that git reports "Bad file descriptor" on
every trace attempt. The 'git clone' test succeeds nevertheless because
From: Johannes Sixt
MSYS bash considers the part "/g" in the sed expression "s/./=/g" as an
absolute path after an assignment, and mangles it to a C:/something
string. Do not attract bash's attention by avoiding the equals sign.
Signed-off-by: Johannes Sixt
---
t/t2003-checkout-cache-mkdir.sh
On Wed, Mar 20, 2013 at 09:24:44AM +0100, Johannes Sixt wrote:
> From: Johannes Sixt
>
> Two tests use GIT_TRACE=3 to dump debugging information of git. On
> Windows, however, bash is unable to set up file descriptor 3 correctly
> for its child process, so that git reports "Bad file descriptor"
Am 2/21/2013 5:03, schrieb David Aguilar:
> test_expect_success PERL 'difftool -d' '
> - diff=$(git difftool -d --extcmd ls branch) &&
> - echo "$diff" | stdin_contains sub &&
> - echo "$diff" | stdin_contains file
> + git difftool -d --extcmd ls branch >output &&
> + stdin_con
On Wed, Mar 20, 2013 at 8:32 AM, Duy Nguyen wrote:
> On Wed, Mar 20, 2013 at 1:34 AM, Junio C Hamano wrote:
>> This seems to break t7300-clean.sh #8
>
> Repeatedly? I saw some t7300-clean.sh failures when running tests in
> parallel, but never been able to reproduce it alone.
Never mind. There i
Am 3/20/2013 10:33, schrieb Jeff King:
> On Wed, Mar 20, 2013 at 09:24:44AM +0100, Johannes Sixt wrote:
>
>> From: Johannes Sixt
>>
>> Two tests use GIT_TRACE=3 to dump debugging information of git. On
>> Windows, however, bash is unable to set up file descriptor 3 correctly
>> for its child proc
Sounds good to me. I've got a couple of busy days coming up, but should
have time this week.
Danny
On 19/03/2013 19:23, "Pete Wyckoff" wrote:
>danny.tho...@blackboard.com wrote on Mon, 18 Mar 2013 09:26 -0400:
>> Interesting. 'Implementing sitewide pessimistic locking with p4
>>typemap',
>>
When entering a git working dir, optionally run a forked process that
stat all files in the whole workdir and therefore loads stat information
to RAM which will speedup things like git status and so on.
The feature is optional and by default it's off.
Signed-off-by: Fredrik Gustafsson
---
contr
Junio please pull the series from github [1]. I don't want to spam the
list with 45 patches again so I only send patches that are substantially
different from v1:
- documentation for parse_pathspec
- fix wrong operator precendence in git-reset
- fix initialization that may lead to crashes in gi
Currently to fill a struct pathspec, we do:
const char **paths;
paths = get_pathspec(prefix, argv);
...
init_pathspec(&pathspec, paths);
"paths" can only carry bare strings, which loses information from
command line arguments such as pathspec magic or the prefix part's
length for each
This flag is equivalent to builtin/ls-files.c:strip_trailing_slashes()
and is intended to replace that function when ls-files is converted to
use parse_pathspec.
Signed-off-by: Nguyễn Thái Ngọc Duy
---
pathspec.c | 9 +
pathspec.h | 2 ++
2 files changed, 11 insertions(+)
diff --git a/p
PATHSPEC_SYMLINK_LEADING_PATH and _STRIP_SUBMODULE_SLASH_EXPENSIVE are
respectively the alternate implementation of
pathspec.c:die_if_path_beyond_symlink() and
pathspec.c:check_path_for_gitlink(). They are intended to replace
those functions when builtin/add.c and builtin/check-ignore.c are
convert
GUARD_PATHSPEC() marks pathspec-sensitive code, basically all those
that touch anything in 'struct pathspec' except fields "nr" and
"original". GUARD_PATHSPEC() is not supposed to fail. It's mainly to
help the designers to catch unsupported codepaths.
Signed-off-by: Nguyễn Thái Ngọc Duy
---
Docu
This passes the pathspec, more or less unmodified, to
git-add--interactive. The command itself does not process pathspec. It
simply passes the pathspec to other builtin commands. So if all those
commands support pathspec, we're good.
Signed-off-by: Nguyễn Thái Ngọc Duy
---
builtin/add.c | 2
Prepending prefix to pathspec is a trick to workaround the fact that
commands can be executed in a subdirectory, but all git commands run
at worktree's root. The prefix part should always be treated as
literal string. Make it so.
Signed-off-by: Nguyễn Thái Ngọc Duy
---
cache.h| 2 ++
path.c
Style is inconsistent throughout the file. Make the following
changes:
1. Indent everything with tabs.
2. Put the opening quote (') for the test in the same line as
test_expect_succcess, and the closing quote on a line by itself.
Signed-off-by: Ramkumar Ramachandra
---
Another random patch
On 3/19/13 7:08 PM, Junio C Hamano wrote:
> Jonathan Nieder writes:
>
>> Junio C Hamano wrote:
>>> Jonathan Nieder writes:
Test nits:
...
Hope that helps,
Jonathan Nieder (3):
push test: use test_config where appropriate
push test: simplify check of push res
On Wed, Mar 20, 2013 at 1:37 AM, Junio C Hamano wrote:
> I was running "git bisect start pu jch" (jch is a branch I do not
> push out everywhere that is somewhere in the middle of
> "master..pu"), and then after bisection finished, saw this:
>
> $ git branch --with 66887099e096f0258a5ef3b1e745
This follows-up [1], with three important differences:
1. pushremote_get() and remote_get() share code better. Thanks Jeff.
2. All spelling mistakes have been corrected. Thanks Eric.
3. One new test for each of the new configuration variables. The
extra two parts [2/6] and [3/6] preprare the
A small segment where handle_config() parses the branch.remote
configuration variable can be simplified using git_config_string().
Signed-off-by: Ramkumar Ramachandra
---
remote.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/remote.c b/remote.c
index e53a6eb..45b69d6 10
The file was originally created in bcdb34f (Test wildcard push/fetch,
2007-06-08), and only contained tests that exercised wildcard
functionality at the time. In subsequent commits, many other tests
unrelated to wildcards were added but the test description was never
updated. Fix this.
Signed-of
mk_test() creates a repository with the constant name "testrepo", and
this may be limiting for tests that need to create more than one
repository for testing. To fix this, create a new mk_test_with_name()
which accepts the repository name as $1. Reimplement mk_test() as a
special case of this fun
Currently, do_push() in push.c calls remote_get(), which gets the
configured remote for fetching and pushing. Replace this call with a
call to pushremote_get() instead, a new function that will return the
remote configured specifically for pushing. This function tries to
work with the string push
This new configuration variable defines the default remote to push to,
and overrides `branch..remote` for all branches. It is useful
in the typical triangular-workflow setup, where the remote you're
fetching from is different from the remote you're pushing to.
Signed-off-by: Ramkumar Ramachandra
This new configuration variable overrides `remote.pushdefault` and
`branch..remote` for pushes. In a typical triangular-workflow
setup, you would want to set `remote.pushdefault` to specify the
remote to push to for all branches, and use this option to override it
for a specific branch.
Signed-of
On Wed, Mar 20, 2013 at 8:45 PM, Ramkumar Ramachandra
wrote:
> This new configuration variable overrides `remote.pushdefault` and
> `branch..remote` for pushes. In a typical triangular-workflow
> setup, you would want to set `remote.pushdefault` to specify the
> remote to push to for all branches
On Wed, Mar 20, 2013 at 8:44 PM, Ramkumar Ramachandra
wrote:
> remote.c: introduce remote.pushdefault
> remote.c: introduce branch..pushremote
Perhaps we should clarify how this differs from remote.pushurl in the
documentation for it, in git-config and/or git-push. Maybe even
include the desi
Tay Ray Chuan wrote:
> On Wed, Mar 20, 2013 at 8:45 PM, Ramkumar Ramachandra
> wrote:
>> This new configuration variable overrides `remote.pushdefault` and
>> `branch..remote` for pushes. In a typical triangular-workflow
>> setup, you would want to set `remote.pushdefault` to specify the
>> remot
On Monday, March 18, 2013 at 00:27 EDT,
Joydeep Bakshi wrote:
> I have implemented git pre-received hook successfully. And it works on
> the repo level.
> Could anyone suggest how to call branch level hook please ?--
If you need to have different hook behaviors depending on the ref that's
a
Rob Hoelz writes:
> On 3/19/13 7:08 PM, Junio C Hamano wrote:
>> Jonathan Nieder writes:
>>
>>> Junio C Hamano wrote:
Jonathan Nieder writes:
> Test nits:
> ...
> Hope that helps,
>
> Jonathan Nieder (3):
> push test: use test_config where appropriate
> push
Duy Nguyen writes:
>> I think the message should better say "before you started to bisect
>> you were on 'jch'" or something instead.
>
> How about
>
> * (no branch, bisect started on jch)
>
> then?
Sure.
What you are showing is used only to decide where "git bisect reset"
goes to, I think.
--
Hello,
I have information for you about an unclaimed funds in my department.
Please get back to me if interested so I would brief you in details.
Email:lmrle...@live.com
Regards,
Lan Lee
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.ker
Hi,
I experience difference in behavior between `git stash show stash@{0}` and `git
show stash@{0}`:
-
# git stash show --name-status stash@{0}
A a
M conflict.js
# git show --name-status stash@{0}
commit 05aa170746dc4e060f10710a92a
Jonathan Nieder writes:
> A common workflow in large projects is to chdir into a subdirectory of
> interest and only do work there:
>
> cd src
> vi foo.c
> make test
> git add -u
> git commit
>
> The upcoming change to 'git add -u' behavior would not affect such a
>
Jonathan Nieder writes:
> In the spirit of the recent similar change for 'git add -u', avoid
> pestering users that restrict their attention to a subdirectory and
> will not be affected by the coming change in the behavior of pathless
> 'git add -A'.
>
> Signed-off-by: Jonathan Nieder
> ---
> As
Kirill Likhodedov writes:
> The first gives the correct result, while the second doesn't show the
> addition.
> Is it a bug, or I'm just missing something?
stash objects are commits with 2 parents (ie. merge commits). One commit
is the HEAD you stashed from, and the other is the saved state of
Thomas Rast writes:
> So here's a nonrecursive version. Dijkstra is probably turning over
> in his grave as we speak.
>
> I *think* I actually got it right.
You seem to have lost the "if we cannot get delta base, this object
is BAD" check where you measure the size of a deltified object,
which
On Wed, Mar 20, 2013 at 01:15:32PM +0100, Fredrik Gustafsson wrote:
> When entering a git working dir, optionally run a forked process that
> stat all files in the whole workdir and therefore loads stat information
> to RAM which will speedup things like git status and so on.
>
> The feature is o
Jeff King writes:
> But maybe there is some subtle reason I'm missing for having the two
> options separate.
The closest I found was c06ff4908bf9 (Record ns-timestamps if
possible, but do not use it without USE_NSEC, 2009-03-04).
commit c06ff4908bf9ad8bf2448439a3574321c9399b17
Author: Kjetil Ba
On Wed, Mar 20, 2013 at 12:30:47PM +0100, Johannes Sixt wrote:
> > I think that is OK, but I'm curious why this is a problem _now_, and not
> > with the code prior to 97a83fa8. The old GIT_DEBUG_SEND_PACK was also
> > just calling write() to descriptor 3.
>
> Before this change, both affected com
On Wed, Mar 20, 2013 at 10:04:14AM -0700, Junio C Hamano wrote:
> Jeff King writes:
>
> > But maybe there is some subtle reason I'm missing for having the two
> > options separate.
>
> The closest I found was c06ff4908bf9 (Record ns-timestamps if
> possible, but do not use it without USE_NSEC,
Johannes Sixt writes:
> From: Johannes Sixt
>
> MSYS bash considers the part "/g" in the sed expression "s/./=/g" as an
> absolute path after an assignment, and mangles it to a C:/something
> string. Do not attract bash's attention by avoiding the equals sign.
If this breakage is about path man
Jeff King writes:
> So maybe just run "git status >/dev/null"?
In the background? How often would it run? I do not think a single
lockfile solves anything. It may prevent simultaneous runs of two
such "prime the well" processes, but the same user may be working in
two separate repositories.
On Wed, Mar 20, 2013 at 01:06:07PM -0400, Jeff King wrote:
> On Wed, Mar 20, 2013 at 12:30:47PM +0100, Johannes Sixt wrote:
>
> > > I think that is OK, but I'm curious why this is a problem _now_, and not
> > > with the code prior to 97a83fa8. The old GIT_DEBUG_SEND_PACK was also
> > > just calli
Jeff King writes:
> Also, though I think your use of stderr is probably OK, might it be a
> little more robust against future output changes to use:
>
> GIT_TRACE_PACKET=$PWD/$U.D git clone ...
>
> to write directly to the file. The original GIT_DEBUG_SEND_PACK did not
> support such niceties,
Jeff King writes:
> And the cost is that we have another Makefile knob people need to tweak
> that would not otherwise need to be there. Which can be annoying, but is
> also not that huge a cost to deal with (we might want to improve the
> configure script or something, though).
>
> I admit I don
On Wed, Mar 20, 2013 at 10:45:22PM +0530, Ramkumar Ramachandra wrote:
> Fredrik Gustafsson wrote:
> > When entering a git working dir, optionally run a forked process that
> > stat all files in the whole workdir and therefore loads stat information
> > to RAM which will speedup things like git stat
Some test scripts use the GIT_TRACE mechanism to dump
debugging information to descriptor 3 (and point it to a
file using the shell). On Windows, however, bash is unable
to set up descriptor 3. We do not write our trace to the
file, and worse, we may interfere with other operations
happening on des
On Wed, Mar 20, 2013 at 10:15:39AM -0700, Junio C Hamano wrote:
> Jeff King writes:
>
> > So maybe just run "git status >/dev/null"?
>
> In the background? How often would it run? I do not think a single
> lockfile solves anything. It may prevent simultaneous runs of two
> such "prime the we
Fredrik Gustafsson wrote:
> On Wed, Mar 20, 2013 at 10:45:22PM +0530, Ramkumar Ramachandra wrote:
>> Fredrik Gustafsson wrote:
>> > When entering a git working dir, optionally run a forked process that
>> > stat all files in the whole workdir and therefore loads stat information
>> > to RAM which w
When asking Git to merge a tag (such as a signed tag or annotated tag),
it will always create a merge commit even if fast-forward was possible.
It's like having --no-ff present on the command line.
It's a difference from the default behavior described in git-merge.txt.
It should be documented as a
Nguyễn Thái Ngọc Duy writes:
> Junio please pull the series from github [1]
> [1] https://github.com/pclouds/git/commits/parse-pathspec
Please write it like this:
https://github.com/pclouds/git parse-pathspec
so that I can just say
git fetch <>
git diff nd/magic-paths
Hi,
Le mardi 19 mars 2013 à 09:19 -0700, Junio C Hamano a écrit :
> Yann Droneaud writes:
>
> > 1) there's no mention of the git merge behavior in git-merge.1
> Yes; we welcome documentation patches.
>
Sent.
> > 2) git merge VS git merge
> >
> > If is an object (not a lightweight/referen
Ramkumar Ramachandra wrote:
> --- a/remote.c
> +++ b/remote.c
> @@ -356,9 +356,7 @@ static int handle_config(const char *key, const char
> *value, void *cb)
> return 0;
> branch = make_branch(name, subkey - name);
> if (!strcmp(subkey, ".remote"))
Jonathan Nieder wrote:
> Ramkumar Ramachandra wrote:
>
>> --- a/remote.c
>> +++ b/remote.c
>> @@ -356,9 +356,7 @@ static int handle_config(const char *key, const char
>> *value, void *cb)
>> return 0;
>> branch = make_branch(name, subkey - name);
>>
Hi,
Le mercredi 20 mars 2013 à 19:04 +0100, Yann Droneaud a écrit :
> > > 2) git merge VS git merge
> > >
> > > If is an object (not a lightweight/reference tag), git merge
> > > ...
> > > But, if you use the tag object-id instead of its name, for example using
> > > git merge `git parse-rev
Ramkumar Ramachandra wrote:
> --- a/t/t5516-fetch-push.sh
> +++ b/t/t5516-fetch-push.sh
> @@ -1,6 +1,6 @@
> #!/bin/sh
>
> -test_description='fetching and pushing, with or without wildcard'
> +test_description='fetching and pushing'
I'm not thrilled with the description before or after. Would
On Wed, Mar 20, 2013 at 1:31 PM, Junio C Hamano wrote:
> Jeff King writes:
>
>> And the cost is that we have another Makefile knob people need to tweak
>> that would not otherwise need to be there. Which can be annoying, but is
>> also not that huge a cost to deal with (we might want to improve t
Ramkumar Ramachandra wrote:
> mk_test() creates a repository with the constant name "testrepo", and
> this may be limiting for tests that need to create more than one
> repository for testing. To fix this, create a new mk_test_with_name()
> which accepts the repository name as $1. Reimplement mk
Ramkumar Ramachandra wrote:
> Currently, do_push() in push.c calls remote_get(), which gets the
> configured remote for fetching and pushing. Replace this call with a
> call to pushremote_get() instead, a new function that will return the
> remote configured specifically for pushing. This functi
On Wed, Mar 20, 2013 at 02:22:27PM -0400, Andrew Rodland wrote:
> I think it would be good if NO_NSEC and USE_ST_TIMESPEC were
> controlled by configure instead of config.mak, and it doesn't seem
> like too tall of an order.
There is no "instead of" here. The Makefile provides knobs which you can
Ramkumar Ramachandra wrote:
> This new configuration variable defines the default remote to push to,
> and overrides `branch..remote` for all branches.
Micronit: I think this would be easier to explain if it came after
patch 6, since then you could say "In other words, it is a default for
branch.
Jonathan Nieder wrote:
> Ramkumar Ramachandra wrote:
>
>> --- a/t/t5516-fetch-push.sh
>> +++ b/t/t5516-fetch-push.sh
>> @@ -1,6 +1,6 @@
>> #!/bin/sh
>>
>> -test_description='fetching and pushing, with or without wildcard'
>> +test_description='fetching and pushing'
>
> I'm not thrilled with the de
On Wed, Mar 20, 2013 at 11:19:38PM +0530, Ramkumar Ramachandra wrote:
> I think it should be a separate script in contrib/ that people can
> just `eval` in their shell configs; zsh has a chpwd() function for
> example, which seems like the right place to put such a thing.
I was trying to spare the
Ramkumar Ramachandra wrote:
> When I want to add a test for branch..pushremote, I grep
> for branch.*.pushurl, and open files with sensible names; I'm not
> going to open up the file and read a long description of what tests it
> already contains.
Huh? The test_description is output for "./
Jonathan Nieder wrote:
> Ramkumar Ramachandra wrote:
>
>> mk_test() creates a repository with the constant name "testrepo", and
>> this may be limiting for tests that need to create more than one
>> repository for testing. To fix this, create a new mk_test_with_name()
>> which accepts the reposito
On Wed, Mar 20, 2013 at 12:48:06PM -0400, Jeff King wrote:
> Kind of gross, but I guess it is useful to some people.
Yes it is. The questions is if it's gross enough to never
leave my computer, or if someone else can find this useful.
>
> > +__git_recursive_stat ()
> > +{
> > + if test ! -e /t
Ramkumar Ramachandra wrote:
> Signed-off-by: Ramkumar Ramachandra
> ---
> Thanks, Junio.
>
> t/t4018-diff-funcname.sh | 5 -
> t/t7810-grep.sh | 5 -
> t/t7811-grep-open.sh | 5 -
> 3 files changed, 15 deletions(-)
Yeah, that looks like all of them. FWIW,
Reviewed-by:
Ramkumar Ramachandra wrote:
> Jonathan Nieder wrote:
>> I dunno. The helper functions at the top of this test are already
>> intimidating, so I guess I am looking for a way to avoid making that
>> problem worse.
[...]
> My patch does not make the situation worse in any way:
Um, yes it does. It
Yann Droneaud writes:
> But but do not take those remarks as a feature request.
> I was just asking for clarification/comment on the behavior difference
> between merging tag/tag object-id.
If you are asking why things are as they are, the answer is simply
because "git merge $(git rev-parse v1.2
On Wed, Mar 20, 2013 at 07:36:41PM +0100, Fredrik Gustafsson wrote:
> > Yes, I would certainly like my git startup time to be improved. But I
> > don't want to trade my hard drive's life for it.
>
> Does this really increase disk-reads? The fs-cache would make sure that
> the disk reads is almos
Ramkumar Ramachandra writes:
> test_config() is already a well-defined function in
> test-lib-functions.sh. Don't duplicate it unnecessarily in:
>
> t4018-diff-funcname.sh
> t7810-grep.sh
> t7811-grep-open.sh
>
> Signed-off-by: Ramkumar Ramachandra
> ---
> Thanks, Junio.
Heh, I've pushe
Jeff King writes:
> So I think your real complaint is "configure does not set NO_NSEC
> properly", which is something worth fixing.
Yes.
I think our "Meh" was about "do we want to unify USE_NSEC and
NO_NSEC?" and nothing else.
--
To unsubscribe from this list: send the line "unsubscribe git" in
Jonathan Nieder writes:
> Ramkumar Ramachandra wrote:
>
>> This new configuration variable defines the default remote to push to,
>> and overrides `branch..remote` for all branches.
>
> Micronit: I think this would be easier to explain if it came after
> patch 6, since then you could say "In othe
Yann Droneaud wrote:
> When asking Git to merge a tag (such as a signed tag or annotated tag),
> it will always create a merge commit even if fast-forward was possible.
> It's like having --no-ff present on the command line.
Thanks. This looks good, modulo some nitpicks.
[...]
> --- a/Documenta
On Wed, Mar 20, 2013 at 11:41:57AM -0700, Jonathan Nieder wrote:
> Ramkumar Ramachandra wrote:
> > Jonathan Nieder wrote:
>
> >> I dunno. The helper functions at the top of this test are already
> >> intimidating, so I guess I am looking for a way to avoid making that
> >> problem worse.
> [...]
On Wed, Mar 20, 2013 at 11:52:28AM -0700, Junio C Hamano wrote:
> Jeff King writes:
>
> > So I think your real complaint is "configure does not set NO_NSEC
> > properly", which is something worth fixing.
>
> Yes.
>
> I think our "Meh" was about "do we want to unify USE_NSEC and
> NO_NSEC?" and
Ramkumar Ramachandra writes:
> if (name)
> name_given = 1;
> else {
> - name = default_remote_name;
> - name_given = explicit_default_remote_name;
> + if (pushremote_name) {
> + name = pushremote_name;
> +
Yann Droneaud writes:
> When asking Git to merge a tag (such as a signed tag or annotated tag),
> it will always create a merge commit even if fast-forward was possible.
> It's like having --no-ff present on the command line.
>
> It's a difference from the default behavior described in git-merge.
On Tue, Mar 19, 2013 at 12:17 PM, Jeff King wrote:
> To ensure that all depths start at 0, that commit changed
> calls to xmalloc the object_entry list into calls to
> xcalloc. However, it forgot that we grow the list with
> xrealloc later. These extra entries are used when we add an
> object fro
On Wed, Mar 20, 2013 at 03:12:07PM -0400, Eric Sunshine wrote:
> On Tue, Mar 19, 2013 at 12:17 PM, Jeff King wrote:
> > To ensure that all depths start at 0, that commit changed
> > calls to xmalloc the object_entry list into calls to
> > xcalloc. However, it forgot that we grow the list with
>
On Wed, Mar 20, 2013 at 3:13 PM, Jeff King wrote:
> On Wed, Mar 20, 2013 at 03:12:07PM -0400, Eric Sunshine wrote:
>
>> On Tue, Mar 19, 2013 at 12:17 PM, Jeff King wrote:
>> > To ensure that all depths start at 0, that commit changed
>> > calls to xmalloc the object_entry list into calls to
>> >
On Wed, Mar 20, 2013 at 8:16 AM, Nguyễn Thái Ngọc Duy wrote:
> +static void NORETURN unsupported_magic(const char *pattern,
> + unsigned magic,
> + unsigned short_magic)
> +{
> + struct strbuf sb = STRBUF_INIT;
> +
Junio C Hamano wrote:
> Ramkumar Ramachandra writes:
>
>> if (name)
>> name_given = 1;
>> else {
>> - name = default_remote_name;
>> - name_given = explicit_default_remote_name;
>> + if (pushremote_name) {
>> + name
On Wed, Mar 20, 2013 at 8:16 AM, Nguyễn Thái Ngọc Duy wrote:
> diff --git a/Documentation/technical/api-setup.txt
> b/Documentation/technical/api-setup.txt
> index 59a947e..f62528e 100644
> --- a/Documentation/technical/api-setup.txt
> +++ b/Documentation/technical/api-setup.txt
> @@ -28,3 +28,22
Jonathan Nieder wrote:
> Ramkumar Ramachandra wrote:
>
>> This new configuration variable defines the default remote to push to,
>> and overrides `branch..remote` for all branches.
>
> Micronit: I think this would be easier to explain if it came after
> patch 6, since then you could say "In other w
Ramkumar Ramachandra writes:
> ... There is no implicit fallback (like
> "origin"): it just falls back to the .remote codepath, if not
> explicitly specified.
That one sentence is enough to explain the apparent asymmetry, which
bothered me.
--
To unsubscribe from this list: send the line "unsu
On Wed, Mar 20, 2013 at 8:30 AM, Ramkumar Ramachandra
wrote:
> Style is inconsistent throughout the file. Make the following
> changes:
>
> 1. Indent everything with tabs.
>
> 2. Put the opening quote (') for the test in the same line as
>test_expect_succcess, and the closing quote on a line
Jeff King writes:
> ... even though it is more typing, I would argue that:
>
> mk_empty testrepo &&
> git push testrepo ...
>
> is better, because the test script is more readable as a unit.
>
> None of this is that huge a deal to me (and yet I seem to have written a
> page about it :) ), but
Am 19.03.2013 22:36, schrieb Josh Rowe:
Yes, Dedup is in fact a Server-only feature.
Is there an easier way to reproduce the issue than registering and
downloading the Windows Server 2012 evaluation version? It's not that
hard, admittedly, but still.
The reparse point could be decoded as
Eric Sunshine wrote:
> On Wed, Mar 20, 2013 at 8:30 AM, Ramkumar Ramachandra
> wrote:
>> Style is inconsistent throughout the file. Make the following
>> changes:
>>
>> 1. Indent everything with tabs.
>>
>> 2. Put the opening quote (') for the test in the same line as
>>test_expect_succcess,
Junio C Hamano wrote:
> Ramkumar Ramachandra writes:
>
>> test_config() is already a well-defined function in
>> test-lib-functions.sh. Don't duplicate it unnecessarily in:
>>
>> t4018-diff-funcname.sh
>> t7810-grep.sh
>> t7811-grep-open.sh
>>
>> Signed-off-by: Ramkumar Ramachandra
>> ---
Jeff King wrote:
>I
> tend to read the tests in a top-down manner: a test is interesting
> (usually because it fails), and then I want to see what it is doing, so
> I look at any functions it calls, and so forth.
>
> What I usuall
Andrew Wong wrote:
> On 3/19/13, Ramkumar Ramachandra wrote:
>> I know that this is expected behavior, but is there an easy way to get
>> rid of this inconsistency?
>
> You can actually rely on "rebase" to run the appropriate command.
Didn't Junio explicitly mention that this is undesirable earli
On Wed, Mar 20, 2013 at 1:43 PM, Jeff King wrote:
> Some test scripts use the GIT_TRACE mechanism to dump
> debugging information to descriptor 3 (and point it to a
> file using the shell). On Windows, however, bash is unable
> to set up descriptor 3. We do not write our trace to the
> file, and w
Ramkumar Ramachandra wrote:
> Andrew Wong wrote:
>> You can actually rely on "rebase" to run the appropriate command.
>
> Didn't Junio explicitly mention that this is undesirable earlier (from
> the point of view of `rebase -i` design)?
I missed the earlier discussion. Does the documentation (e.
Ramkumar Ramachandra writes:
> Another random patch. Found it while grep'ping around. I thought I
> could automate my work, which would have been the case if it was
> consistently inconsistent. Unfortunately, it wasn't, and I ended up
> doing a lot of manual janitorial work :|
Thanks. It
1 - 100 of 120 matches
Mail list logo
