On Tue, Apr 1, 2014 at 7:29 AM, Junio C Hamano wrote:
> * nd/multiple-work-trees (2014-03-25) 28 commits
> - count-objects: report unused files in $GIT_DIR/repos/...
> - gc: support prune --repos
> - gc: style change -- no SP before closing bracket
> - prune: strategies for linked checkouts
>
Here are the topics that have been cooking. Commits prefixed with
'-' are only in 'pu' (proposed updates) while commits prefixed with
'+' are in 'next'.
More topics merged to 'master', some of which are fallouts from GSoC
microprojects, some are updates to docs. C/C++ funcname pattern
update is
On 1. 4. 2014 0:50, Ronald Weiss wrote:
On 31. 3. 2014 23:47, Ronald Weiss wrote:
On Mon, Mar 31, 2014 at 8:58 PM, Jens Lehmann wrote:
As Junio mentioned it would be great if you could teach the add
command also honor the --ignore-submodule command line option in
a companion patch. In the cour
Four patches queued on 'pu' as-is (but retitled). I didn't read
everything very carefully, though.
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
Jeff King writes:
> On Mon, Mar 31, 2014 at 10:23:44AM -0700, Junio C Hamano wrote:
>
>> SET_PTR() may not be used, but are there places where SET_INT() is
>> abused with a cast-to-pointer for the same effect? I didn't check,
>> but if there are such places, converting them to use SET_PTR() with
On 31. 3. 2014 23:47, Ronald Weiss wrote:
> On Mon, Mar 31, 2014 at 8:58 PM, Jens Lehmann wrote:
>> As Junio mentioned it would be great if you could teach the add
>> command also honor the --ignore-submodule command line option in
>> a companion patch. In the course of doing so you'll easily see
On Mon, Mar 31, 2014 at 3:15 PM, Junio C Hamano wrote:
> As you are doing -3 (not the -p3), it would have:
>
> * noticed that the patch is trying to update "baz/file";
>
> * noticed that there is no "baz/file" but it could salvage the
>patch by doing a three-way merge, in case that the patch
Michael Haggerty writes:
> On 03/31/2014 11:40 PM, Junio C Hamano wrote:
>> Michael Haggerty writes:
>>
>>> Since full const correctness is beyond the ability of C's type system,
>>> just put the const where it doesn't do any harm. A (struct ref_update
>>> **) can be passed to a (struct ref_up
On 03/31/2014 11:51 PM, Junio C Hamano wrote:
> Michael Haggerty writes:
>
>> Make (most of) the error messages for invalid input have the same
>> format [1]:
>>
>> $COMMAND [SP $REFNAME]: $MESSAGE
>>
>> Update the tests accordingly.
>>
>> [1] A few error messages are left with their old form
On 03/31/2014 11:50 PM, Junio C Hamano wrote:
> Michael Haggerty writes:
>
>> This case wants to test passing a bad refname to the "update" command.
>> But it also passes too few arguments to "update", which muddles the
>> situation: which error should be diagnosed? So split this test into
>> tw
Justin Lebar writes:
> diff --git a/builtin/clean.c b/builtin/clean.c
> index 5502957..977a068 100644
> --- a/builtin/clean.c
> +++ b/builtin/clean.c
> @@ -903,11 +903,11 @@ int cmd_clean(int argc, const char **argv, const char
> *prefix)
>
> if (!interactive && !dry_run && !force) {
>
On 03/31/2014 11:48 PM, Junio C Hamano wrote:
> Michael Haggerty writes:
>
>> This is the (slightly inconsistent) status quo; make sure it doesn't
>> change by accident.
>
> Interesting. So "oldvalue" being empty is "we do not care what it
> is" (as opposed to "we know it must not exist yet" ak
On 03/31/2014 11:40 PM, Junio C Hamano wrote:
> Michael Haggerty writes:
>
>> Since full const correctness is beyond the ability of C's type system,
>> just put the const where it doesn't do any harm. A (struct ref_update
>> **) can be passed to a (struct ref_update * const *) argument, but not
Sverre Rabbelier writes:
> Hi,
>
> I noticed something very odd with git am, and have been able to narrow
> it down to a minimal example.
>
> git init tmp
> cd tmp
> mkdir -p foo/bar/baz
> cd foo/bar/baz
> echo file > file
> git add file
> git commit -m "1"
> echo other > other
> echo mo
Signed-off-by: Justin Lebar
---
Makefile| 2 +-
builtin/apply.c | 2 +-
builtin/checkout.c | 2 +-
builtin/log.c | 2 +-
builtin/pack-objects.c | 2 +-
colum
Signed-off-by: Justin Lebar
---
builtin/clean.c | 6 +++---
builtin/commit.c | 2 +-
git-add--interactive.perl | 4 ++--
perl/Git/SVN.pm | 4 ++--
sha1_file.c | 2 +-
t/t1001-read-tree-m-2way.sh | 2 +-
t/t40
Signed-off-by: Justin Lebar
---
contrib/examples/git-commit.sh | 2 +-
contrib/svn-fe/svn-fe.txt | 4 ++--
2 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/contrib/examples/git-commit.sh b/contrib/examples/git-commit.sh
index 23ffb02..4aab1a6 100755
--- a/contrib/examples/git-c
Signed-off-by: Justin Lebar
---
Documentation/CodingGuidelines | 4 ++--
Documentation/config.txt| 6 +++---
Documentation/diff-generate-patch.txt | 2 +-
Documentation/diff-options.txt | 2 +-
Documentation/e
On 03/31/2014 11:36 PM, Junio C Hamano wrote:
> Michael Haggerty writes:
>
>> Test that the argument is properly terminated by either whitespace or
>> a NUL character, even if it is quoted, to be consistent with the
>> non-quoted case. Adjust the tests to expect the new error message.
>> Add a d
"Michael S. Tsirkin" writes:
> + memcpy(&ctx, &header_ctx,
> sizeof ctx);
> + } else {
> + /* Save header ctx for next
> hunk. */
> +
Duy Nguyen writes:
> On Sat, Mar 29, 2014 at 5:21 AM, Junio C Hamano wrote:
>> * nd/gc-aggressive (2014-03-17) 4 commits
>> - gc --aggressive: three phase repacking
>> - gc --aggressive: make --depth configurable
>> - pack-objects: support --keep
>> - environment.c: fix constness for odb_pac
Justin Lebar writes:
> Thanks; fixed in v4 (just sent out).
I only saw [3/4] that was marked with (v3) at the end, without
[{1,2,4}/4]. As you seem to be renumbering from the very original
(which had "l10n" at number 3), only sending out what you changed,
expecting that everybody else knows wha
Hi,
I noticed something very odd with git am, and have been able to narrow
it down to a minimal example.
git init tmp
cd tmp
mkdir -p foo/bar/baz
cd foo/bar/baz
echo file > file
git add file
git commit -m "1"
echo other > other
echo more >> file
git add file other
git commit -m "my tes
Michael Haggerty writes:
> Make (most of) the error messages for invalid input have the same
> format [1]:
>
> $COMMAND [SP $REFNAME]: $MESSAGE
>
> Update the tests accordingly.
>
> [1] A few error messages are left with their old form, because
> $COMMAND and $REFNAME aren't passed all th
On Mon, Mar 31, 2014 at 10:37 PM, Jens Lehmann wrote:
> ... maybe the best way is to leave index_differs_from() unchanged
> and call that function with the correct diff_flags instead:
>
> + int diff_flags = DIFF_OPT_OVERRIDE_SUBMODULE_CONFIG;
> + if (ignore_submodule_ar
Michael Haggerty writes:
> This case wants to test passing a bad refname to the "update" command.
> But it also passes too few arguments to "update", which muddles the
> situation: which error should be diagnosed? So split this test into
> two:
>
> * One that passes too few arguments to update
>
On 03/31/2014 11:30 PM, Junio C Hamano wrote:
> Michael Haggerty writes:
>
>> The test
>>
>> stdin -z create ref fails with zero new value
>>
>> actually passes an empty new value, not a zero new value. So rename
>> the test s/zero/empty/, and change the expected error from
>>
>> fatal:
Michael Haggerty writes:
> In the original version of this command, for the single case of the
> "update" command's , the empty string was interpreted as
> being equivalent to 40 "0"s. This shorthand is unnecessary (binary
> input will usually be generated programmatically anyway), and it
> comp
Michael Haggerty writes:
> This is the (slightly inconsistent) status quo; make sure it doesn't
> change by accident.
Interesting. So "oldvalue" being empty is "we do not care what it
is" (as opposed to "we know it must not exist yet" aka 0{40}), and
"newvalue" being empty is the same as "delet
On 03/28/2014 03:00 AM, Jeff King wrote:
From: Vicent Marti
When pack-objects is computing the reachability bitmap to
serve a fetch request, it can erroneously die() if some of
the UNINTERESTING objects are not present. Upload-pack
throws away HAVE lines from the client for objects we do not
ha
On Mon, Mar 31, 2014 at 8:58 PM, Jens Lehmann wrote:
> As Junio mentioned it would be great if you could teach the add
> command also honor the --ignore-submodule command line option in
> a companion patch. In the course of doing so you'll easily see if
> I was right or not, then please just order
Michael Haggerty writes:
> Since full const correctness is beyond the ability of C's type system,
> just put the const where it doesn't do any harm. A (struct ref_update
> **) can be passed to a (struct ref_update * const *) argument, but not
> to a (const struct ref_update **) argument.
Sounds
- Original Message -
From: "Dieter Komendera"
To:
Sent: Monday, March 31, 2014 10:04 PM
Subject: Bug report: git add . -p "Argument list too long"
Hi there,
since a while when I want to stage diffs in one of my big repos with
"git add . -p” I get this error:
Can't exec "git": Arg
Michael Haggerty writes:
> Test that the argument is properly terminated by either whitespace or
> a NUL character, even if it is quoted, to be consistent with the
> non-quoted case. Adjust the tests to expect the new error message.
> Add a docstring to the function, incorporating the comments t
Michael Haggerty writes:
> The test
>
> stdin -z create ref fails with zero new value
>
> actually passes an empty new value, not a zero new value. So rename
> the test s/zero/empty/, and change the expected error from
>
> fatal: create $c given zero new value
>
> to
>
> fatal: creat
Michael Haggerty writes:
> Subject: Re: [PATCH v2 02/27] t1400: Provide more usual input to the command
This applies to the patches throughout the series, but during the
microproject reviews, Eric pointed out that we seem to start the
summary after area: on the subject with lowercase and omit th
Hi there,
since a while when I want to stage diffs in one of my big repos with "git add .
-p” I get this error:
Can't exec "git": Argument list too long at
/usr/local/Cellar/git/1.9.1/libexec/git-core/git-add--interactive line 180.
Died at /usr/local/Cellar/git/1.9.1/libexec/git-core/git-add--i
On Sun, Mar 30, 2014 at 10:29:04AM +0200, Andreas Schwab wrote:
> Junio C Hamano writes:
>
> > As OPT_SET_PTR() is about setting the pointer value to intptr_t defval,
> > a follow-up patch on top of this fix (see attached) may not be a bad
> > thing to have, but that patch alone will not fix thi
On Mon, Mar 31, 2014 at 10:23:44AM -0700, Junio C Hamano wrote:
> SET_PTR() may not be used, but are there places where SET_INT() is
> abused with a cast-to-pointer for the same effect? I didn't check,
> but if there are such places, converting them to use SET_PTR() with
> their existing cast rem
Sorry, still figuring out the right workflow here: The subject should
say v4, and it should say patch 3/4.
On Mon, Mar 31, 2014 at 2:04 PM, Justin Lebar wrote:
> Signed-off-by: Justin Lebar
> ---
> Makefile| 2 +-
> builtin/apply.c
Thanks; fixed in v4 (just sent out).
On Mon, Mar 31, 2014 at 12:54 PM, Jason St. John wrote:
> On Sat, Mar 29, 2014 at 6:59 PM, Justin Lebar wrote:
>> This version applies successfully to master, maint, next, and pu. The other
>> patches in the previous version of this queue apply successfully
Signed-off-by: Justin Lebar
---
Makefile| 2 +-
builtin/apply.c | 2 +-
builtin/checkout.c | 2 +-
builtin/log.c | 2 +-
builtin/pack-objects.c | 2 +-
colum
Thiago Farina writes:
> In imap-send.c:socket_perror() we pass |func| as a parameter, which I
> think it is the name of the function that "called" socket_perror, or
> the name of the function which generated an error.
>
> But at line 184 and 187 it always assume it was SSL_connect.
>
> Should we
Jens Lehmann writes:
> I'd prefer a solution that doesn't change any defaults for the
> checkout use case (again). Maybe it is a better route to revert
> this series, then add tests describing the current behavior for
> checkout submodules as a next step before adding the branch mode
> for rebase
On Mon, Mar 31, 2014 at 12:54:46PM -0700, Junio C Hamano wrote:
> "Michael S. Tsirkin" writes:
>
> > The hash used is mostly an internal implementation detail, isn't it?
>
> Yes, but that does not mean we can break people who keep an external
> database indexed with the patch-id by changing the
On Mon, Mar 31, 2014 at 09:35:07PM +0200, Jens Lehmann wrote:
> Am 28.03.2014 04:36, schrieb W. Trevor King:
> > The main drawback to this approach is that we're changing a default,
> > but I agree with John's:
> >
> > On Fri, Mar 28, 2014 at 12:21:23AM +0100, Johan Herland wrote:
> >> I expect in
Am 31.03.2014 20:58, schrieb Jens Lehmann:
> Am 31.03.2014 02:07, schrieb Ronald Weiss:
>> The tests immediately revealed, that the patch was not complete. It
>> didn't work with commit message given on command line (-m). To make
>> that work, I had to also patch the index_differs_from function in
On 03/31/2014 07:56 PM, Ronnie Sahlberg wrote:
> I am new to git, so sorry If I overlooked something.
>
> I think there might be a race in ref_transaction_commit() when
> deleting references.
>
> /* Perform deletes now that updates are safely completed */
> for (i = 0; i < n; i++) {
>
On Sat, Mar 29, 2014 at 6:59 PM, Justin Lebar wrote:
> This version applies successfully to master, maint, next, and pu. The other
> patches in the previous version of this queue apply successfully without any
> changes.
>
> Signed-off-by: Justin Lebar
>
> ---
> Makefile
"Michael S. Tsirkin" writes:
> The hash used is mostly an internal implementation detail, isn't it?
Yes, but that does not mean we can break people who keep an external
database indexed with the patch-id by changing the default under
them, and "they can give --unstable option to work it around"
"Michael S. Tsirkin" writes:
> though it does look like an unrelated enhancement to me.
> Agree?
Yes, that is exactly why I said "opens interesting opportunity" and
"making it possible" ;-) They are all very related, but they do not
have to graduate as parts of the same series.
The important th
Am 28.03.2014 04:36, schrieb W. Trevor King:
> gitmodule(5) mentioned 'master' as the default remote branch, but
> folks using checkout-style updates are unlikely to care which upstream
> branch their commit comes from (they only care that the clone fetches
> that commit). If they haven't set subm
> Junio C Hamano pobox.com> writes:
>
>
> I would have to say that there is already an established pattern to
> pick ranges that normal people understand well and it would be silly
> to invent another more verbose way to express the same thing. You
> tell your Print Dialog which page to print wi
Am 28.03.2014 18:10, schrieb W. Trevor King:
> On Fri, Mar 28, 2014 at 05:57:50PM +0100, Jens Lehmann wrote:
>> Am 28.03.2014 04:58, schrieb W. Trevor King:
>>> On Thu, Mar 27, 2014 at 08:52:55PM -0700, W. Trevor King wrote:
No the remote branch is in the upstream subproject. I suppose I mean
"Michael S. Tsirkin" writes:
> Verify that patch ID is now stable against diff split and reordering.
>
> Signed-off-by: Michael S. Tsirkin
> ---
>
> Changes from v2:
> added test to verify patch ID is stable against diff splitting
>
> t/t4204-patch-id.sh | 117
> +
On Mon, Mar 31, 2014 at 12:08:36PM -0700, Junio C Hamano wrote:
> "Michael S. Tsirkin" writes:
>
> > Clarify that patch ID is now a sum of hashes, not a hash.
> > Document --stable and --unstable flags.
> >
> > Signed-off-by: Michael S. Tsirkin
> > ---
> >
> > changes from v2:
> > explicitly
On Mon, Mar 31, 2014 at 11:47 AM, Junio C Hamano wrote:
>
> Instead, make it act like so:
>
> $ git diff --no-index --color=words a b
> error: option `color' expects "always", "auto", or "never"
> fatal: invalid diff option/value: --color=words
Thanks,
Linus
--
"Michael S. Tsirkin" writes:
> Clarify that patch ID is now a sum of hashes, not a hash.
> Document --stable and --unstable flags.
>
> Signed-off-by: Michael S. Tsirkin
> ---
>
> changes from v2:
> explicitly list the kinds of changes against which patch ID is stable
>
> Documentation/git
On Mon, Mar 31, 2014 at 10:59:50AM -0700, Junio C Hamano wrote:
> "Michael S. Tsirkin" writes:
>
> > Patch id changes if users
> > 1. reorder file diffs that make up a patch
> > or
> > 2. split a patch up to multiple diffs that touch the same path
> > (keeping hunks within a single diff ordered t
Am 31.03.2014 02:07, schrieb Ronald Weiss:
> Git commit honors the 'ignore' setting from .gitmodules or .git/config,
> but didn't allow to override it from command line, like other commands do.
>
> Useful values for commit are 'all' (default) or 'none'. The others
> ('dirty' and 'untracked') have
On Mon, Mar 31, 2014 at 11:27:53AM -0700, Junio C Hamano wrote:
> Jeff King writes:
>
> > That being said, git _could_ be more liberal in accepting a content-type
> > with parameters (even though it does not know about any parameters, and
> > charset here is completely meaningless). I have mixed
diff_opt_parse() returns the number of options parsed, or often
returns error() which is defined to return -1. Yes, return value of
0 is "I did not process that option at all", which should cause the
caller to say that, but negative return should not be forgotten.
This bug the caused it to infini
Junio C Hamano writes:
> Linus Torvalds writes:
>
>> I hit this oddity when not remembering the right syntax for --color-words..
>>
>> Try this (outside of a git repository):
>>
>>touch a b
>>git diff -u --color=words a b
>>
>> and watch it scroll (infinitely) printing out
>>
>>error
On Mon, Mar 31, 2014 at 11:30 AM, Junio C Hamano wrote:
>
> Hmph, interesting. "outside a repository" is the key, it seems.
Well, you can do it inside a repository too, but then you need to use
the "--no-index" flag to get the "diff two files" behavior. It will
result in the same infinite error
Linus Torvalds writes:
> I hit this oddity when not remembering the right syntax for --color-words..
>
> Try this (outside of a git repository):
>
>touch a b
>git diff -u --color=words a b
>
> and watch it scroll (infinitely) printing out
>
>error: option `color' expects "always", "au
Jeff King writes:
> That being said, git _could_ be more liberal in accepting a content-type
> with parameters (even though it does not know about any parameters, and
> charset here is completely meaningless). I have mixed feelings on that.
It may be just a matter of replacing strbuf_cmp() with
I hit this oddity when not remembering the right syntax for --color-words..
Try this (outside of a git repository):
touch a b
git diff -u --color=words a b
and watch it scroll (infinitely) printing out
error: option `color' expects "always", "auto", or "never"
forever.
I haven't trie
karthik nayak writes:
> if there is any way
> where i could contribute to git via bug fixes or something similar
Yes, it is called the Git mailing list, and you are posting to
one. ;-)
This project works primarily with "scratch your itch" principle.
When you see bugs or room for improvement in
On Mon, Mar 31, 2014 at 07:19:09PM +0200, Siggi wrote:
> here are the two outputs you wanted to see.
The interesting bit is at the end...
> < HTTP/1.1 200 OK
> < Date: Mon, 31 Mar 2014 17:04:57 GMT
> * Server Apache/2.2.22 (Ubuntu) is not blacklisted
> < Server: Apache/2.2.22 (Ubuntu)
> < X-Powe
"Michael S. Tsirkin" writes:
> Patch id changes if users
> 1. reorder file diffs that make up a patch
> or
> 2. split a patch up to multiple diffs that touch the same path
> (keeping hunks within a single diff ordered to make patch valid).
>
> As the result is functionally equivalent, a different
(now without HTML formatting)
I am new to git, so sorry If I overlooked something.
I think there might be a race in ref_transaction_commit() when
deleting references.
/* Perform deletes now that updates are safely completed */
for (i = 0; i < n; i++) {
struct ref_update *update = updates[i];
i
Jens Lehmann writes:
> Am 29.03.2014 16:39, schrieb Charles Bailey:
>> AIX doesn't make a distiction between EEXIST and ENOTEMPTY so relying on
>> the strerror string for the rmdir failure is fragile. Just test that the
>> start of the string matches the Git controlled "failed to rmdir..."
>> err
Marat Radchenko writes:
> Patches summary:
> 1. Fix initial issue (incorrect cast causing crash on 64-bit MSVC)
> 2. Improve OPT_SET_PTR to prevent same errors in future
> 3. Purge OPT_SET_PTR away since nobody uses it
>
> *Optional* patch №3 is separated from №1 and №2 so that if someone someday
Marat Radchenko writes:
> Do not force users of OPT_SET_PTR to cast pointer to correct
> underlying pointer type by integrating cast into OPT_SET_PTR macro.
>
> Cast is required to prevent 'initialization makes integer from pointer
> without a cast' compiler warning.
> ---
Signed-off-by (and pro
Eric Sunshine writes:
> Since the relational operators are fairly self-explanatory, you could
> drop the prose explanation, though that might make it too cryptic:
>
> A number prefixed with '<', '<=', '>', or '>=' matches test
> numbers meeting the specified relation.
I would have to say
Jens Lehmann writes:
>> Changes in add.c and cache.h (and related compilo fix in checkout.c) are
>> needed to make it work for "commit -a" too.
>
> Looking good so far, but we definitely need tests for this new option.
>
> But I wonder if it would make more sense to start by teaching the
> --igno
"Jonas Bang" writes:
>> For some people it is also a norm to keep files that have been modified from
>> HEAD and/or index without committing for a long time (e.g. earlier, Linus
>> said
>> that the version in Makefile is updated and kept modified in the working tree
>> long before a new release
Hello,
Now that i have already submitted my proposal to GSOC , i was
wondering if there is any way
where i could contribute to git via bug fixes or something similar to
the microprojects which
was available prior to GSOC application.
Also wondering if any clarification was needed as per my proposal
Good day,
We give loan to dedicated Christian, contact us to solve your financial
problem, email marieloanlend...@gmail.com
Mrs Marie
--
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.ke
79 matches
Mail list logo
