Felipe Contreras wrote:
>David Lang wrote:
>> the vast majority of people here do not take that attitude.
>
>It's actually the exact opposite. I don't care what is the track record
>of the people in the discussion.
Ah, yes, like that discussion we once had where you totally
didn't run `git log | g
On 05/03/2014 10:12 PM, brian m. carlson wrote:
> This is a preliminary RFC patch series to move all the relevant uses of
> unsigned char [20] to struct object_id. It should not be applied to any
> branch yet.
>
> The goal of this series to improve type-checking in the codebase and to
> make it e
In recent versions of gcc (4.9.0), we get hundreds of these:
advice.c: In function ‘error_resolve_conflict’:
advice.c:79:69: warning: right-hand operand of comma expression has no effect
[-Wunused-value]
error("'%s' is not possible because you have unmerged files.", me);
This is in gcc 4.9.0:
wt-status.c: In function ‘wt_status_print_unmerged_header’:
wt-status.c:191:2: warning: zero-length gnu_printf format string
[-Wformat-zero-length]
status_printf_ln(s, c, "");
^
We could pass -Wno-format-zero-length, but it seems compiler-specific
flags are frow
In recent versions of gcc (4.9.0), we get a few of these:
notes.c: In function ‘notes_display_config’:
notes.c:970:28: warning: right-hand operand of comma expression has no effect
[-Wunused-value]
config_error_nonbool(k);
^
Previous commit explains the reaso
Hi,
I'm getting tons and tons of warnings with gcc 4.9.0. Here are the patches to
fix them all.
Felipe Contreras (3):
Revert "make error()'s constant return value more visible"
Revert "silence some -Wuninitialized false positives"
Silence a bunch of format-zero-length warnings
builtin/co
Felipe Contreras writes:
> David Lang wrote:
>> note that this is one person taking the "I don't see any commits from
>> you so your opinion doesn't count" attitude.
>
> Wrong. I said it doesn't count "for the project".
There are a number of commits from me that actually count. A few old
core p
(Sorry for the late reply, I'm handicapped by some local IT problems)
Peff, do you know if the fix below helps ?
On 2014-04-28 18.16, Jeff King wrote:
> If you have existing decomposed filenames in your git
> repository (e.g., that were created with older versions of
> git that did not precompose
On 05/03/2014 10:12 PM, brian m. carlson wrote:
> Many places throughout the code use "unsigned char [20]" to store object IDs
> (SHA-1 values). This leads to lots of hardcoded numbers throughout the
> codebase. It also leads to confusion about the purposes of a buffer.
>
> Introduce a structure
On 05/03/2014 09:35 AM, Dennis Kaarsemaker wrote:
> On vr, 2014-05-02 at 15:16 -0700, Jonathan Nieder wrote:
>>> $ git checkout -b hotfix/b2
>>> error: unable to resolve reference refs/heads/hotfix/b2: Not a
>> directory
>>> fatal: Failed to lock ref for update: Not a directory
>>>
David Lang wrote:
> note that this is one person taking the "I don't see any commits from
> you so your opinion doesn't count" attitude.
Wrong. I said it doesn't count "for the project". Do you honestly
believe Junio cares about what some random guy on the list thinks about
default aliases? No.
I
On Sat, 3 May 2014, David Kastrup wrote:
Felipe Contreras writes:
David Kastrup wrote:
Richard Hansen writes:
These three usage patterns are at odds; it's hard to change the
default behavior of 'git pull' to favor one usage case without
harming another. Perhaps this is why there's so muc
Richard Hansen wrote:
> On 2014-05-03 05:26, Felipe Contreras wrote:
> > Richard Hansen wrote:
> >
> >> I think the fundamental difference is in the relationship between the
> >> local and the remote branch (which branch derives from the other).
> >> The relationship between the branches determine
Here's a bunch of tests more, and a fixes for Mercurial v3.0.
Felipe Contreras (4):
remote-hg: add more tests
t: remote-hg: add file operation tests
t: remote-hg: trivial cleanups and fixes
remote-hg: add support for hg v3.0
contrib/remote-helpers/git-remote-hg | 6 +-
contrib/remote-
There was a broken && chain, and cat is simpler than echo in a subshell.
Signed-off-by: Felipe Contreras
---
contrib/remote-helpers/test-hg.sh | 14 +++---
1 file changed, 7 insertions(+), 7 deletions(-)
diff --git a/contrib/remote-helpers/test-hg.sh
b/contrib/remote-helpers/test-hg.sh
Inspired by the tests in gitifyhg.
One test is failing, but that's because of a limitation of
remote-helpers.
Signed-off-by: Felipe Contreras
---
contrib/remote-helpers/test-hg.sh | 150 ++
1 file changed, 150 insertions(+)
diff --git a/contrib/remote-helper
Inspired by gitifyhg.
Signed-off-by: Felipe Contreras
---
contrib/remote-helpers/test-hg.sh | 76 +++
1 file changed, 76 insertions(+)
diff --git a/contrib/remote-helpers/test-hg.sh
b/contrib/remote-helpers/test-hg.sh
index 33a434d..df09966 100755
--- a/cont
Signed-off-by: Felipe Contreras
---
contrib/remote-helpers/git-remote-hg | 6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/contrib/remote-helpers/git-remote-hg
b/contrib/remote-helpers/git-remote-hg
index 34cda02..8b02803 100755
--- a/contrib/remote-helpers/git-remote-hg
+
On Sun, May 4, 2014 at 3:49 AM, David Turner wrote:
> On Sat, 2014-05-03 at 15:49 +0700, Duy Nguyen wrote:
>> On Sat, May 3, 2014 at 11:39 AM, David Turner
>> wrote:
>> >> Index v4 and split index (and the following read-cache daemon,
>> >> hopefully)
>> >
>> > Looking at some of the archives fo
On Sat, May 03, 2014 at 08:12:13PM +, brian m. carlson wrote:
> This is a preliminary RFC patch series to move all the relevant uses of
> unsigned char [20] to struct object_id. It should not be applied to any
> branch yet.
>
> The goal of this series to improve type-checking in the codebase
On 4 May 2014 05:22:48 GMT+10:00, Felipe Contreras
wrote:
>I think you should take a look at the Makefile of
>contrib/remote-helpers. I bet something simple like that would work
>just
>fine for subtree.
The current makefile is simple enough, just quirky and likes
to be a special snowflake. 'sall
On 2014-05-03 05:26, Felipe Contreras wrote:
> Richard Hansen wrote:
>
>> I think the fundamental difference is in the relationship between the
>> local and the remote branch (which branch derives from the other).
>> The relationship between the branches determines what the user wants
>> from 'git
On Sat, 2014-05-03 at 15:49 +0700, Duy Nguyen wrote:
> On Sat, May 3, 2014 at 11:39 AM, David Turner
> wrote:
> >> Index v4 and split index (and the following read-cache daemon,
> >> hopefully)
> >
> > Looking at some of the archives for read-cache daemon, it seems to be
> > somewhat similar to w
From: "Jonathan Nieder"
Sent: Friday, May 02, 2014 11:53 PM
Hi,
Philip Oakley wrote:
That assumes that [git pull] doing something is better than doing
nothing,
which is appropriate when the costs on either side are roughly
similar.
I think the conversation's going around in circles.
I agr
Signed-off-by: brian m. carlson
---
builtin/commit.c | 2 +-
builtin/fsck.c | 4 ++--
cache-tree.c | 30 +++---
cache-tree.h | 3 ++-
merge-recursive.c | 2 +-
reachable.c| 2 +-
sequencer.c| 2 +-
test-d
Signed-off-by: brian m. carlson
---
bundle.c | 38 +++---
1 file changed, 19 insertions(+), 19 deletions(-)
diff --git a/bundle.c b/bundle.c
index 1222952..798ba28 100644
--- a/bundle.c
+++ b/bundle.c
@@ -11,11 +11,11 @@
static const char bundle_signature[] = "
This is a preliminary RFC patch series to move all the relevant uses of
unsigned char [20] to struct object_id. It should not be applied to any
branch yet.
The goal of this series to improve type-checking in the codebase and to
make it easier to move to a different hash function if the project
de
Signed-off-by: brian m. carlson
---
combine-diff.c | 54 +++---
diff-lib.c | 10 +-
diff.h | 5 +++--
3 files changed, 35 insertions(+), 34 deletions(-)
diff --git a/combine-diff.c b/combine-diff.c
index 24ca7e2..f97eb3a 100644
Signed-off-by: brian m. carlson
---
bisect.c | 30 +++---
1 file changed, 15 insertions(+), 15 deletions(-)
diff --git a/bisect.c b/bisect.c
index d6e851d..fe53214 100644
--- a/bisect.c
+++ b/bisect.c
@@ -15,7 +15,7 @@
static struct sha1_array good_revs;
static struct s
Signed-off-by: brian m. carlson
---
bulk-checkin.c | 12 ++--
1 file changed, 6 insertions(+), 6 deletions(-)
diff --git a/bulk-checkin.c b/bulk-checkin.c
index 98e651c..92c7b5e 100644
--- a/bulk-checkin.c
+++ b/bulk-checkin.c
@@ -23,7 +23,7 @@ static struct bulk_checkin_state {
stati
Signed-off-by: brian m. carlson
---
branch.c | 16
1 file changed, 8 insertions(+), 8 deletions(-)
diff --git a/branch.c b/branch.c
index 660097b..8dc0d49 100644
--- a/branch.c
+++ b/branch.c
@@ -184,9 +184,9 @@ int validate_new_branchname(const char *name, struct strbuf
*ref,
Signed-off-by: brian m. carlson
---
archive.c | 16
1 file changed, 8 insertions(+), 8 deletions(-)
diff --git a/archive.c b/archive.c
index 3fc0fb2..dba148a 100644
--- a/archive.c
+++ b/archive.c
@@ -255,7 +255,7 @@ static void parse_treeish_arg(const char **argv,
time_
Many places throughout the code use "unsigned char [20]" to store object IDs
(SHA-1 values). This leads to lots of hardcoded numbers throughout the
codebase. It also leads to confusion about the purposes of a buffer.
Introduce a structure for object IDs. This allows us to obtain the benefits
of
The object.h header is included in archive.h for this constant. It will be
used by other parts of the archiving code in the future.
Signed-off-by: brian m. carlson
---
archive-zip.c | 4 ++--
archive.h | 1 +
2 files changed, 3 insertions(+), 2 deletions(-)
diff --git a/archive-zip.c b/arc
James Denholm wrote:
> Matthew Ogilvie wrote:
> > On Sun, Apr 27, 2014 at 12:35:13PM +1000, James Denholm wrote:
> >> Jeff King wrote:
> > Agreed. It also doesn't help that when subtree patches are proposed
> > (especially new features instead of obvious bugs), there often seems
> > to be little
Signed-off-by: Øyvind A. Holm
---
Documentation/RelNotes/2.0.0.txt | 10 +-
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/Documentation/RelNotes/2.0.0.txt b/Documentation/RelNotes/2.0.0.txt
index e6911ac..35e353e 100644
--- a/Documentation/RelNotes/2.0.0.txt
+++ b/Document
Matthew Ogilvie wrote:
> On Sun, Apr 27, 2014 at 12:35:13PM +1000, James Denholm wrote:
>> Jeff King wrote:
> Agreed. It also doesn't help that when subtree patches are proposed
> (especially new features instead of obvious bugs), there often seems
> to be little or no feedback from anyone.
>
>
GVF is already being used in most/all other makefiles in the project,
and has been for _quite_ a while. Hence, drop file-unique gitver and
replace with GIT_VERSION.
Signed-off-by: James Denholm
---
contrib/subtree/Makefile | 11 ---
1 file changed, 8 insertions(+), 3 deletions(-)
diff -
git:Documentation/Makefile establishes asciidoc/xmlto calls as being
handled through their appropriate variables, Hence, change to bring into
congruency with.
Similarly, MANPAGE_XSL exists in git:Documentation/Makefile, while
MANPAGE_NORMAL_XSL does not outside contrib/subtree. Hence, replace
MANP
$(libexecdir) isn't used anywhere else in the project, while
$(gitexecdir) is the standard in the other appropriate makefiles. Hence,
replace the former with the latter.
Signed-off-by: James Denholm
---
contrib/subtree/Makefile | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --
git:Documentation/Makefile and others establish "RM ?= rm -f" as a
convention for rm calls in clean rules, hence follow this convention
instead of simply forcing clean to use rm.
subproj and mainline no longer need to be removed in clean, as they are
no longer created in git:contrib/subtree by "ma
All references were removed in 7ff8463dba0d74fc07a766bed457ae7afcc902b5,
but the assignment itself wasn't. Hence, drop gitdir assignment.
Signed-off-by: James Denholm
---
contrib/subtree/Makefile | 1 -
1 file changed, 1 deletion(-)
diff --git a/contrib/subtree/Makefile b/contrib/subtree/Makefi
contrib/subtree/Makefile is a shambles in regards to it's consistency
with other makefiles, which makes subtree overly painful to include in
build scripts.
The main issues are that calls are made to git itself in the build
process, and that a subtree-exclusive variable is used for specifying
the e
Hi,
I've used the following link to download git source and corresponding
pre-formatted man pages for several months:
https://code.google.com/p/git-core/downloads/
However, the latest version available on the site is git-1.9.0 (last
updated on 2014-02-14).
Is the site still maintained/
Philip Oakley wrote:
> From: "Felipe Contreras"
> > When doing something is better for the vast majority of people, that's
> > what should be done by default, unless the results are catastrophic
> > for
> > the minority.
> >
> > Since doing something is not catastrophic to the minority, it follow
From: "Felipe Contreras"
Sent: Saturday, May 03, 2014 12:23 AM
Philip Oakley wrote:
From: "Felipe Contreras"
> So? No defaults can please absolutely everyone, the best anybody
> can
> do is try to please the majority of people, and merging
> fast-forwards only does that.
That assumes that d
W. Trevor King wrote:
> On Fri, May 02, 2014 at 05:20:11PM -0500, Felipe Contreras wrote:
> > W. Trevor King wrote:
> > > > > The 'git pull' (with 'none' mode) explainer just helps retrain folks
> > > > > that are already using the current 'git pull' incorrectly.
> > > >
> > > > If you are going t
On Fri, May 2, 2014 at 2:13 PM, Junio C Hamano wrote:
[snip]
> Your earlier long-hand, together with the two examples that pulls
> into the same "maint" branch Brian gave us, may give us a better
> starting points to think about a saner way.
>
> To me, the problem sounds like:
>
> Tutorials of
Felipe Contreras writes:
> David Kastrup wrote:
>> Richard Hansen writes:
>>
>> > These three usage patterns are at odds; it's hard to change the
>> > default behavior of 'git pull' to favor one usage case without
>> > harming another. Perhaps this is why there's so much disagreement
>> > abou
Richard Hansen wrote:
> I think the fundamental difference is in the relationship between the
> local and the remote branch (which branch derives from the other).
> The relationship between the branches determines what the user wants
> from 'git pull'.
>
> In my experience 'git pull' is mostly (o
David Kastrup wrote:
> Richard Hansen writes:
>
> > These three usage patterns are at odds; it's hard to change the
> > default behavior of 'git pull' to favor one usage case without
> > harming another. Perhaps this is why there's so much disagreement
> > about what 'git pull' should do.
>
> S
On Sat, May 3, 2014 at 11:39 AM, David Turner wrote:
>> Index v4 and split index (and the following read-cache daemon,
>> hopefully)
>
> Looking at some of the archives for read-cache daemon, it seems to be
> somewhat similar to watchman, right? But I only saw inotify code; what
> about Mac OS?
Hello,
I am currently using git subtree in a project :
https://github.com/asmodehn/wkcmake
This is basically a set of cmake scripts that help writing convention
based (folder hierarchy, etc.) cmake builds.
My setup is that "master" has the set of scripts needed. and many
other branches ("test" a
Richard Hansen writes:
> These three usage patterns are at odds; it's hard to change the
> default behavior of 'git pull' to favor one usage case without harming
> another. Perhaps this is why there's so much disagreement about what
> 'git pull' should do.
Should a screwdriver be turning clockw
On 2014-05-02 14:13, Junio C Hamano wrote:
> Stepping back even further, and thinking what is different between
> these two pulls, we notice that the first one is pulling from the
> place we push back to.
I think the fundamental difference is in the relationship between the
local and the remote br
On Wed, Apr 30, 2014 at 10:35:56AM +0200, Karsten Blees wrote:
> Am 29.04.2014 11:12, schrieb Marat Radchenko:
> > On MinGW, compat/mingw.h defines a 'mingw_main' wrapper function.
> > Fix `warning: passing argument 2 of 'mingw_main' from incompatible
> > pointer type` in http-fetch.c and remote-cu
On vr, 2014-05-02 at 15:16 -0700, Jonathan Nieder wrote:
> > $ git checkout -b hotfix/b2
> > error: unable to resolve reference refs/heads/hotfix/b2: Not a
> directory
> > fatal: Failed to lock ref for update: Not a directory
> > $
>
> That's an ugly message. I think we can do bet
On Wed, Apr 30, 2014 at 01:41:25PM +0200, Stepan Kasal wrote:
> Hello,
>
> On Tue, Apr 29, 2014 at 01:12:04PM +0400, Marat Radchenko wrote:
> > On MinGW-W64, MsgWaitForMultipleObjects is guarded with #ifndef NOGDI.
> >
> > Removal -DNOGDI=1 from config.mak.uname has an undesirable effect of
> > b
58 matches
Mail list logo
