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
Jonas Bang em...@jonasbang.dk 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
Eric Sunshine sunsh...@sunshineco.com 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
Jens Lehmann jens.lehm...@web.de 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
Marat Radchenko ma...@slonopotamus.org 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.
---
Marat Radchenko ma...@slonopotamus.org 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
Jens Lehmann jens.lehm...@web.de 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
(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];
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-Powered-By:
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 tried to
Jeff King p...@peff.net 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
Linus Torvalds torva...@linux-foundation.org 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'
On Mon, Mar 31, 2014 at 11:30 AM, Junio C Hamano gits...@pobox.com 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
Junio C Hamano gits...@pobox.com writes:
Linus Torvalds torva...@linux-foundation.org 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
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
On Mon, Mar 31, 2014 at 11:27:53AM -0700, Junio C Hamano wrote:
Jeff King p...@peff.net 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
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 when values for commit are 'all' (default) or 'none'. The others
('dirty' and 'untracked') have
On Mon, Mar 31, 2014 at 10:59:50AM -0700, Junio C Hamano wrote:
Michael S. Tsirkin m...@redhat.com 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
Michael S. Tsirkin m...@redhat.com 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 m...@redhat.com
---
changes from v2:
explicitly list the kinds of changes against which patch ID is stable
On Mon, Mar 31, 2014 at 11:47 AM, Junio C Hamano gits...@pobox.com 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,
Michael S. Tsirkin m...@redhat.com writes:
Verify that patch ID is now stable against diff split and reordering.
Signed-off-by: Michael S. Tsirkin m...@redhat.com
---
Changes from v2:
added test to verify patch ID is stable against diff splitting
t/t4204-patch-id.sh | 117
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 meant
“the
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
Junio C Hamano gitster at 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
Michael S. Tsirkin m...@redhat.com 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
Michael S. Tsirkin m...@redhat.com 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
On Sat, Mar 29, 2014 at 6:59 PM, Justin Lebar jle...@google.com 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 jle...@google.com
---
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++) {
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 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 most cases
On Mon, Mar 31, 2014 at 12:54:46PM -0700, Junio C Hamano wrote:
Michael S. Tsirkin m...@redhat.com 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
Jens Lehmann jens.lehm...@web.de 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
Thiago Farina tfrans...@gmail.com 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.
Signed-off-by: Justin Lebar jle...@google.com
---
Makefile| 2 +-
builtin/apply.c | 2 +-
builtin/checkout.c | 2 +-
builtin/log.c | 2 +-
builtin/pack-objects.c
Thanks; fixed in v4 (just sent out).
On Mon, Mar 31, 2014 at 12:54 PM, Jason St. John jstj...@purdue.edu wrote:
On Sat, Mar 29, 2014 at 6:59 PM, Justin Lebar jle...@google.com wrote:
This version applies successfully to master, maint, next, and pu. The other
patches in the previous version of
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 jle...@google.com wrote:
Signed-off-by: Justin Lebar jle...@google.com
---
Makefile| 2 +-
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
On Sun, Mar 30, 2014 at 10:29:04AM +0200, Andreas Schwab wrote:
Junio C Hamano gits...@pobox.com 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
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
Michael Haggerty mhag...@alum.mit.edu 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
Michael Haggerty mhag...@alum.mit.edu 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
Michael Haggerty mhag...@alum.mit.edu 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,
- Original Message -
From: Dieter Komendera die...@komendera.com
To: git@vger.kernel.org
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
Michael Haggerty mhag...@alum.mit.edu 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 **)
On Mon, Mar 31, 2014 at 8:58 PM, Jens Lehmann jens.lehm...@web.de 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
On 03/28/2014 03:00 AM, Jeff King wrote:
From: Vicent Marti tan...@gmail.com
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
Michael Haggerty mhag...@alum.mit.edu 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
On 03/31/2014 11:30 PM, Junio C Hamano wrote:
Michael Haggerty mhag...@alum.mit.edu 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
Michael Haggerty mhag...@alum.mit.edu writes:
In the original version of this command, for the single case of the
update command's newvalue, the empty string was interpreted as
being equivalent to 40 0s. This shorthand is unnecessary (binary
input will usually be generated programmatically
Michael Haggerty mhag...@alum.mit.edu 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
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 test
git
Justin Lebar jle...@google.com 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
Duy Nguyen pclo...@gmail.com writes:
On Sat, Mar 29, 2014 at 5:21 AM, Junio C Hamano gits...@pobox.com 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:
Michael S. Tsirkin m...@redhat.com writes:
+ memcpy(ctx, header_ctx,
sizeof ctx);
+ } else {
+ /* Save header ctx for next
hunk. */
+
Signed-off-by: Justin Lebar jle...@google.com
---
Makefile| 2 +-
builtin/apply.c | 2 +-
builtin/checkout.c | 2 +-
builtin/log.c | 2 +-
builtin/pack-objects.c
On 03/31/2014 11:48 PM, Junio C Hamano wrote:
Michael Haggerty mhag...@alum.mit.edu 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
Justin Lebar jle...@google.com 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:50 PM, Junio C Hamano wrote:
Michael Haggerty mhag...@alum.mit.edu 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
Michael Haggerty mhag...@alum.mit.edu writes:
On 03/31/2014 11:40 PM, Junio C Hamano wrote:
Michael Haggerty mhag...@alum.mit.edu 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
On Mon, Mar 31, 2014 at 3:15 PM, Junio C Hamano gits...@pobox.com 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
On 31. 3. 2014 23:47, Ronald Weiss wrote:
On Mon, Mar 31, 2014 at 8:58 PM, Jens Lehmann jens.lehm...@web.de 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
Jeff King p...@peff.net 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
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
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 jens.lehm...@web.de 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
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 Tue, Apr 1, 2014 at 7:29 AM, Junio C Hamano gits...@pobox.com 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
66 matches
Mail list logo
