Johan Herland jo...@herland.net writes:
Obviously, the feature would necessarily have to be optional, simply
because Git would have to keep understanding the old commit object
format for a LONG time (probably indefinitely), and there's nothing
you can do to prevent others from creating
Hello,
I installed git for windows 1.9.0 but any push operation I tried with it
produced an error message saying git: 'http-push' is not a git command. Other
commands like pull, add, and commit worked just fine.
At the end of this day I noticed that C:\Program Files
(x86)\Git\libexec\git-core
Setup:
20 people (programmers, artists, designers) with prior SVN knowledge and a
desire to use Git for a new project (mostly on programmers side).
Non-programmers used TortoiseSVN before so choosing TortoiseGit as a GUI was an
obvios step.
We made an in-house presentation introducing basic
Hi.
Obviously, the feature would necessarily have to be optional, simply
because Git would have to keep understanding the old commit object
format for a LONG time (probably indefinitely), and there's nothing
you can do to prevent others from creating old-style commit objects.
Doesn't git
Personally, I am _strongly_ opposed. How I name and juggle my private
branches is nobody else's business in a distributed version control
system.
They are private. My personal workflow. Not part of a commit.
Mercurial inherits the branch label from previous commit, unless
it's specified
From: Johan Herland jo...@herland.net
Subject: Re: Recording the current branch on each commit?
Date: Mon, 28 Apr 2014 01:39:26 +0200
On Sun, Apr 27, 2014 at 10:55 PM, Jeremy Morton ad...@game-point.net wrote:
On 27/04/2014 20:33, Johan Herland wrote:
On Sun, Apr 27, 2014 at 7:38 PM, Jeremy
Silvola Tuomas wrote
Hello,
I installed git for windows 1.9.0 but any push operation I tried with it
produced an error message saying git: 'http-push' is not a git command.
Other commands like pull, add, and commit worked just fine.
At the end of this day I noticed that C:\Program Files
On Mon, Apr 28, 2014 at 7:58 AM, Michael Haggerty mhag...@alum.mit.edu wrote:
On 04/27/2014 10:12 PM, Christian Couder wrote:
It looks like the commit-msg hook is passed a commit
message that can contain lines starting with a '#'.
Those comment lines will be removed from the commit
message
By default, Git used to set $LESS to -FRSX if $LESS was not set by the
user. The FRX flags actually make sense for Git (F and X because Git
sometimes pipes short output to less, and R because Git pipes colored
output). The S flag (chop long lines), on the other hand, is not related
to Git and is a
From: theoleblond theodore.lebl...@gmail.com
Date: Wed, 16 May 2012 06:52:49 -0700
I played around with this quite a bit. After trying some more complex
schemes, I found that what worked best is to just sleep 1 millisecond
between iterations. Though it's a very short time, it still completely
Jeremy Morton wrote:
On 27/04/2014 09:51, Robin Rosenberg wrote:
Currently, git records a checksum, author, commit date/time, and commit
message with every commit (as get be seen from 'git log'). I think it
would be useful if, along with the Author and Date, git recorded the
name of the
Matthieu Moy matthieu@imag.fr writes:
By default, Git used to set $LESS to -FRSX if $LESS was not set by the
user. The FRX flags actually make sense for Git (F and X because Git
sometimes pipes short output to less, and R because Git pipes colored
output). The S flag (chop long lines), on
On 28/04/2014 09:32, Felipe Contreras wrote:
some people to is to always merge with --no-ff, that way you see the branch
name in the merge commit.
But surely, it's recommended with Git that you try to avoid doing
--no-ff merges to avoid commit noise?
Nope. Different people have different
On Mon, Apr 28, 2014 at 9:36 AM, Marat Radchenko ma...@slonopotamus.org wrote:
Silvola Tuomas wrote
Hello,
I installed git for windows 1.9.0 but any push operation I tried with it
produced an error message saying git: 'http-push' is not a git command.
Other commands like pull, add, and
On 28/04/2014 03:30, Sitaram Chamarty wrote:
On 04/28/2014 01:03 AM, Johan Herland wrote:
Yeah, sure. Author and Date (and Committer, for that matter) is just
metadata, and the current branch name is simply just another kind of
metadata. All of them are more-or-less free-form text fields, and
David Kastrup d...@gnu.org writes:
There seem to be a few more occurences (git-sh-setup.sh and pager.c):
Not since f82c3ffd862c7 (Wed Feb 5 2014, move LESS/LV pager environment
to Makefile).
Searching for LESS seems to implicate a few more possible candidates in
contrib/examples:
Jeremy Morton wrote:
On 27/04/2014 10:09, Johan Herland wrote:
On Sun, Apr 27, 2014 at 1:56 AM, Jeremy Mortonad...@game-point.net wrote:
Currently, git records a checksum, author, commit date/time, and commit
message with every commit (as get be seen from 'git log'). I think it
would
On 28/04/2014 07:45, Christian Couder wrote:
Yes, it's possible. Yesterday, I sent the following patch:
[RFC/PATCH 2/2] trailer: add examples to the documentation
and it shows a commit-msg hook to do something like that:
$ cat.git/hooks/commit-msgEOF
#!/bin/sh
git interpret-trailers
On Mon, Apr 28, 2014 at 10:48 AM, Erik Faye-Lund kusmab...@gmail.com wrote:
So it seems that 08900987 (Decide whether to build http-push in the
Makefile) makes a bad assumption about the availability of
curl-config on new libcurl installations; it's not present on stock
Windows builds.
I
Jeremy Morton ad...@game-point.net writes:
On 28/04/2014 09:32, Felipe Contreras wrote:
some people to is to always merge with --no-ff, that way you see the branch
name in the merge commit.
But surely, it's recommended with Git that you try to avoid doing
--no-ff merges to avoid commit
On Mon, Apr 28, 2014 at 10:39 AM, Stepan Kasal ka...@ucw.cz wrote:
From: theoleblond theodore.lebl...@gmail.com
Date: Wed, 16 May 2012 06:52:49 -0700
I played around with this quite a bit. After trying some more complex
schemes, I found that what worked best is to just sleep 1 millisecond
Johan Herland wrote:
On Sun, Apr 27, 2014 at 7:38 PM, Jeremy Morton ad...@game-point.net wrote:
Whatsmore, tracking down which branch a commit pertains to is still rather
difficult using this approach. You can go back through the history and
find Merge branch 'pacman-minigame', but how do
On Mon, Apr 28, 2014 at 11:01 AM, Jeremy Morton ad...@game-point.net wrote:
On 28/04/2014 07:45, Christian Couder wrote:
Yes, it's possible. Yesterday, I sent the following patch:
[RFC/PATCH 2/2] trailer: add examples to the documentation
and it shows a commit-msg hook to do something like
On 28/04/2014 10:02, David Kastrup wrote:
Jeremy Mortonad...@game-point.net writes:
On 28/04/2014 09:32, Felipe Contreras wrote:
some people to is to always merge with --no-ff, that way you see the branch
name in the merge commit.
But surely, it's recommended with Git that you try to avoid
Jeremy Morton wrote:
On 27/04/2014 20:33, Johan Herland wrote:
The problem is not really less tidy commit trees - by which I gather
you mean history graphs that are non-linear. IMHO, the history graph
should reflect parallel/branched development when that is useful.
Blindly rebasing
On 28/04/2014 10:09, Johan Herland wrote:
On Mon, Apr 28, 2014 at 11:01 AM, Jeremy Mortonad...@game-point.net wrote:
On 28/04/2014 07:45, Christian Couder wrote:
Yes, it's possible. Yesterday, I sent the following patch:
[RFC/PATCH 2/2] trailer: add examples to the documentation
and it
On 28/04/2014 10:01, Felipe Contreras wrote:
Jeremy Morton wrote:
On 27/04/2014 20:33, Johan Herland wrote:
The problem is not really less tidy commit trees - by which I gather
you mean history graphs that are non-linear. IMHO, the history graph
should reflect parallel/branched development
Jeremy Morton wrote:
On 28/04/2014 10:01, Felipe Contreras wrote:
Jeremy Morton wrote:
On 27/04/2014 20:33, Johan Herland wrote:
The problem is not really less tidy commit trees - by which I gather
you mean history graphs that are non-linear. IMHO, the history graph
should reflect
On 28/04/2014 10:17, Felipe Contreras wrote:
I don't seem to what? I'm the one arguing for change, and I sent the patches to
fix this default behavior.
Well maybe you should work on phrasing things better - you come across
as quite negative.
--
Best regards,
Jeremy Morton (Jez)
--
To
On Mon, Apr 28, 2014 at 11:01 AM, Erik Faye-Lund kusmab...@gmail.com wrote:
On Mon, Apr 28, 2014 at 10:48 AM, Erik Faye-Lund kusmab...@gmail.com wrote:
So it seems that 08900987 (Decide whether to build http-push in the
Makefile) makes a bad assumption about the availability of
curl-config on
On 04/28/2014 02:22 PM, Jeremy Morton wrote:
On 28/04/2014 03:30, Sitaram Chamarty wrote:
On 04/28/2014 01:03 AM, Johan Herland wrote:
Yeah, sure. Author and Date (and Committer, for that matter) is just
metadata, and the current branch name is simply just another kind of
metadata. All of them
On 04/25/2014 11:07 PM, Christian Couder wrote:
From: Michael Haggerty mhag...@alum.mit.edu
+OPTIONS
+---
+--trim-empty::
+ If the 'value' part of any trailer contains only whitespace,
+ the whole trailer will be removed from the resulting message.
Does this apply to existing
Signed-off-by: Nguyễn Thái Ngọc Duy pclo...@gmail.com
---
builtin/add.c| 6 ++
builtin/apply.c | 9 -
builtin/checkout-index.c | 3 +--
builtin/checkout.c | 11 ---
builtin/clone.c | 7 +++
builtin/commit.c | 33
I hinted about it earlier [1]. It now passes the test suite and with a
design that I'm happy with (thanks to Junio for a suggestion about the
rename problem).
From the user point of view, this reduces the writable size of index
down to the number of updated files. For example my webkit index v4
Signed-off-by: Nguyễn Thái Ngọc Duy pclo...@gmail.com
---
sequencer.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/sequencer.c b/sequencer.c
index bde5f04..7b886a6 100644
--- a/sequencer.c
+++ b/sequencer.c
@@ -679,7 +679,7 @@ static void read_and_refresh_cache(struct
This function is now only used by write_locked_index(). Move it to
read-cache.c (because read-cache.c will need to be aware of
alternate_index_output later) and unexport it.
Signed-off-by: Nguyễn Thái Ngọc Duy pclo...@gmail.com
---
cache.h | 1 -
lockfile.c | 20
Signed-off-by: Nguyễn Thái Ngọc Duy pclo...@gmail.com
---
cache.h| 1 +
resolve-undo.c | 2 +-
2 files changed, 2 insertions(+), 1 deletion(-)
diff --git a/cache.h b/cache.h
index 4133797..7155052 100644
--- a/cache.h
+++ b/cache.h
@@ -272,6 +272,7 @@ static inline unsigned int
Signed-off-by: Nguyễn Thái Ngọc Duy pclo...@gmail.com
---
cache.h | 4
read-cache.c | 11 ++-
2 files changed, 10 insertions(+), 5 deletions(-)
diff --git a/cache.h b/cache.h
index 57ad318..d692b74 100644
--- a/cache.h
+++ b/cache.h
@@ -268,6 +268,10 @@ static inline unsigned
Signed-off-by: Nguyễn Thái Ngọc Duy pclo...@gmail.com
---
unpack-trees.c | 8 ++--
1 file changed, 6 insertions(+), 2 deletions(-)
diff --git a/unpack-trees.c b/unpack-trees.c
index 97fc995..a722685 100644
--- a/unpack-trees.c
+++ b/unpack-trees.c
@@ -246,7 +246,9 @@ static int
Signed-off-by: Nguyễn Thái Ngọc Duy pclo...@gmail.com
---
builtin/blame.c| 2 +-
builtin/update-index.c | 4 ++--
cache-tree.c | 15 +++
cache-tree.h | 2 +-
cache.h| 1 +
read-cache.c | 6 +++---
unpack-trees.c | 2
Signed-off-by: Nguyễn Thái Ngọc Duy pclo...@gmail.com
---
builtin/update-index.c | 6 +++---
cache.h| 1 +
2 files changed, 4 insertions(+), 3 deletions(-)
diff --git a/builtin/update-index.c b/builtin/update-index.c
index 42cbe4b..e0e881b 100644
--- a/builtin/update-index.c
+++
remove_marked_cache_entries() deletes entries marked with
CE_REMOVE. But if there is no such entry, do not mark the index as
changed because that could trigger an index update unnecessarily.
Signed-off-by: Nguyễn Thái Ngọc Duy pclo...@gmail.com
---
read-cache.c | 2 ++
1 file changed, 2
We're running out of room for in-memory flags. But since b60e188
(Strip namelen out of ce_flags into a ce_namelen field - 2012-07-11),
we copy the namelen (first 12 bits) to ce_namelen field. So those bits
are free to use. Just make sure we do not accidentally write any
in-memory flags back.
Signed-off-by: Nguyễn Thái Ngọc Duy pclo...@gmail.com
---
cache-tree.c | 25 +++--
cache-tree.h | 2 +-
merge-recursive.c | 4 +---
sequencer.c| 4 +---
test-dump-cache-tree.c | 7 ---
5 files changed, 18 insertions(+), 24
This split-index mode is designed to keep write cost proportional to
the number of changes the user has made, not the size of the work
tree. (Read cost is another matter, to be dealt separately.)
This mode stores index info in a pair of $GIT_DIR/index and
$GIT_DIR/sharedindex.SHA-1. sharedindex
CE_REMOVE'd entries are removed here because only parts of the code
base (unpack_trees in fact) test this bit when they look for the
presence of an entry. Leaving them may confuse the code ignores this
bit and expects to see a real entry.
Signed-off-by: Nguyễn Thái Ngọc Duy pclo...@gmail.com
---
prepare_to_write_split_index() does the major work, classifying
deleted, updated and added entries. write_link_extension() then just
writes it down.
An observation is, deleting an entry, then adding it back is recorded
as entry X is deleted, entry X is added, not entry X is replaced.
This is
Signed-off-by: Nguyễn Thái Ngọc Duy pclo...@gmail.com
---
builtin/read-tree.c | 2 +-
builtin/reset.c | 2 +-
cache-tree.c| 9 +
cache-tree.h| 2 +-
4 files changed, 8 insertions(+), 7 deletions(-)
diff --git a/builtin/read-tree.c b/builtin/read-tree.c
index
We are sure that after merge_base_index() is done. cache-tree can
still be used with the final index. So don't destroy cache tree.
Signed-off-by: Nguyễn Thái Ngọc Duy pclo...@gmail.com
---
cache.h | 1 +
read-cache.c | 3 ++-
split-index.c | 1 +
3 files changed, 4 insertions(+), 1
Entries that belong to the base index should not be freed. Mark
CE_REMOVE to track them.
Signed-off-by: Nguyễn Thái Ngọc Duy pclo...@gmail.com
---
read-cache.c | 14 --
split-index.c | 12
split-index.h | 1 +
3 files changed, 21 insertions(+), 6 deletions(-)
diff
We know the positions of replaced entries via the replace bitmap in
link extension, so the name path does not have to be stored (it's
still in the shared index). With this, we also have a way to
distinguish additions vs replacements at load time and can catch
broken link extensions.
The large part of this patch just follows CE_ENTRY_CHANGED
marks. replace_index_entry() is updated to update
split_index-base-cache[] as well so base-cache[] does not reference
to a freed entry.
Signed-off-by: Nguyễn Thái Ngọc Duy pclo...@gmail.com
---
builtin/update-index.c | 2 ++
cache.h
Version tests only make sense when all entries are in the same file,
so we can see if version is downgraded to 2 if 3 is not required.
Signed-off-by: Nguyễn Thái Ngọc Duy pclo...@gmail.com
---
t/t2104-update-index-skip-worktree.sh | 2 ++
1 file changed, 2 insertions(+)
diff --git
Signed-off-by: Nguyễn Thái Ngọc Duy pclo...@gmail.com
---
builtin/read-tree.c | 9 +
1 file changed, 9 insertions(+)
diff --git a/builtin/read-tree.c b/builtin/read-tree.c
index 3204c62..e7e1c33 100644
--- a/builtin/read-tree.c
+++ b/builtin/read-tree.c
@@ -155,6 +155,15 @@ int
Signed-off-by: Nguyễn Thái Ngọc Duy pclo...@gmail.com
---
.gitignore | 1 +
Makefile| 1 +
cache.h | 2 +
read-cache.c| 3 +-
t/t1700-split-index.sh (new +x) | 194
Also update SHA-1 after writing. If we do not do that, the second
read_index() will see initialized variable already set and not read
.git/index again, which is fine, except istate-sha1 now has a stale
value.
Signed-off-by: Nguyễn Thái Ngọc Duy pclo...@gmail.com
---
cache.h| 1 +
This could be used to run the whole test suite with split
indexes. Index splitting is carried out at random. git read-tree
also resets the index and forces splitting at the next update.
I had a lot of headaches with the test suite, which proves it
exercises split index pretty good.
If you have a large work tree but only make changes in a subset, then
$GIT_DIR/index's size should be stable after a while. If you change
branches that touch something else, $GIT_DIR/index's size may grow
large that it becomes as slow as the unified index. Do --split-index
again occasionally to
Just a (paranoid?) safety measure..
Signed-off-by: Nguyễn Thái Ngọc Duy pclo...@gmail.com
---
read-cache.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/read-cache.c b/read-cache.c
index f9fc3a5..568bc20 100644
--- a/read-cache.c
+++ b/read-cache.c
@@ -2070,7 +2070,8 @@
Make sure entry addition does not lead to unifying the index. We don't
need to explicitly keep track of new entries. If ce-index is zero,
they're new. Otherwise it's unlikely that they are new, but we'll do a
through check later at writing time.
Signed-off-by: Nguyễn Thái Ngọc Duy
If $GIT_DIR is read only, we can't write $GIT_DIR/sharedindex. This
could happen when $GIT_INDEX_FILE is set to somehwere outside
$GIT_DIR.
Signed-off-by: Nguyễn Thái Ngọc Duy pclo...@gmail.com
---
read-cache.c | 13 ++---
1 file changed, 10 insertions(+), 3 deletions(-)
diff --git
Other fill_stat_cache_info() is on new entries, which should set
CE_ENTRY_ADDED in cache_changed, so we're safe.
Signed-off-by: Nguyễn Thái Ngọc Duy pclo...@gmail.com
---
builtin/apply.c | 8 +---
builtin/checkout-index.c | 1 +
builtin/checkout.c | 1 +
cache.h
Normally scripts do not have to be aware about split indexes because
all shared indexes are in $GIT_DIR. A simple mv $tmp_index
$GIT_DIR/somewhere is enough. Scripts that generate temporary indexes
and move them across repos must be aware about split index and copy
the shared file as well. This
Signed-off-by: Nguyễn Thái Ngọc Duy pclo...@gmail.com
---
ewah/ewok.h | 1 -
1 file changed, 1 deletion(-)
diff --git a/ewah/ewok.h b/ewah/ewok.h
index 0556ca5..f6ad190 100644
--- a/ewah/ewok.h
+++ b/ewah/ewok.h
@@ -100,7 +100,6 @@ int ewah_serialize_native(struct ewah_bitmap *self, int fd);
Hello,
On Mon, Apr 28, 2014 at 11:07:24AM +0200, Erik Faye-Lund wrote:
compat/poll/poll.c comes from Gnulib, so it would be better to submit
the patch there and update.
well, the change is in gnulib since 2012-05-21.
But the two versions has diverged a lot.
Could you please just accept a
From: Paolo Bonzini bonz...@gnu.org
Date: Mon, 21 May 2012 09:52:42 +0200
Backported from Gnulib.
2012-05-21 Paolo Bonzini bonz...@gnu.org
poll/select: prevent busy-waiting. SwitchToThread() only gives away
the rest of the current time slice to another thread in the current
On Mon, Apr 28, 2014 at 1:42 PM, Stepan Kasal ka...@ucw.cz wrote:
From: Paolo Bonzini bonz...@gnu.org
Date: Mon, 21 May 2012 09:52:42 +0200
Backported from Gnulib.
2012-05-21 Paolo Bonzini bonz...@gnu.org
poll/select: prevent busy-waiting. SwitchToThread() only gives away
Felipe Contreras felipe.contre...@gmail.com writes:
Jeremy Morton wrote:
Sounds like the default behaviour of git pull might not be ideal if
it easily causes these problems.
It's not idea. Virtually everyone agrees with that, even Linus
Torvalds, and we have the patches to fix it, but
Jeremy Morton ad...@game-point.net writes:
On 28/04/2014 10:02, David Kastrup wrote:
Jeremy Mortonad...@game-point.net writes:
On 28/04/2014 09:32, Felipe Contreras wrote:
some people to is to always merge with --no-ff, that way you see the
branch
name in the merge commit.
But surely,
Matthieu Moy matthieu@grenoble-inp.fr writes:
David Kastrup d...@gnu.org writes:
There seem to be a few more occurences (git-sh-setup.sh and pager.c):
Not since f82c3ffd862c7 (Wed Feb 5 2014, move LESS/LV pager environment
to Makefile).
The only upstream branch containing this commit
Most manuals on git state that it is bad practice to push -f a branch
after have meddled with its history, because this would risk to upset
the repositories of the coworkers. On the other hand, some workflows use
branches to propose modifications, and need some rewritting of the
history after
David Kastrup d...@gnu.org writes:
Matthieu Moy matthieu@grenoble-inp.fr writes:
David Kastrup d...@gnu.org writes:
There seem to be a few more occurences (git-sh-setup.sh and pager.c):
Not since f82c3ffd862c7 (Wed Feb 5 2014, move LESS/LV pager environment
to Makefile).
The only
The Git CodingGuidelines prefer the $(...) construct for command
substitution instead of using the backquotes `...`.
The backquoted form is the traditional method for command
substitution, and is supported by POSIX. However, all but the
simplest uses become complicated quickly. In particular,
The Git CodingGuidelines prefer the $(...) construct for command
substitution instead of using the backquotes `...`.
The backquoted form is the traditional method for command
substitution, and is supported by POSIX. However, all but the
simplest uses become complicated quickly. In particular,
The Git CodingGuidelines prefer the $(...) construct for command
substitution instead of using the backquotes `...`.
The backquoted form is the traditional method for command
substitution, and is supported by POSIX. However, all but the
simplest uses become complicated quickly. In particular,
The Git CodingGuidelines prefer the $(...) construct for command
substitution instead of using the backquotes `...`.
The backquoted form is the traditional method for command
substitution, and is supported by POSIX. However, all but the
simplest uses become complicated quickly. In particular,
The Git CodingGuidelines prefer the $(...) construct for command
substitution instead of using the backquotes `...`.
The backquoted form is the traditional method for command
substitution, and is supported by POSIX. However, all but the
simplest uses become complicated quickly. In particular,
The Git CodingGuidelines prefer the $(...) construct for command
substitution instead of using the backquotes `...`.
The backquoted form is the traditional method for command
substitution, and is supported by POSIX. However, all but the
simplest uses become complicated quickly. In particular,
The Git CodingGuidelines prefer the $(...) construct for command
substitution instead of using the backquotes `...`.
The backquoted form is the traditional method for command
substitution, and is supported by POSIX. However, all but the
simplest uses become complicated quickly. In particular,
The Git CodingGuidelines prefer the $(...) construct for command
substitution instead of using the backquotes `...`.
The backquoted form is the traditional method for command
substitution, and is supported by POSIX. However, all but the
simplest uses become complicated quickly. In particular,
The Git CodingGuidelines prefer the $(...) construct for command
substitution instead of using the backquotes `...`.
The backquoted form is the traditional method for command
substitution, and is supported by POSIX. However, all but the
simplest uses become complicated quickly. In particular,
The Git CodingGuidelines prefer the $(...) construct for command
substitution instead of using the backquotes `...`.
The backquoted form is the traditional method for command
substitution, and is supported by POSIX. However, all but the
simplest uses become complicated quickly. In particular,
The Git CodingGuidelines prefer the $(...) construct for command
substitution instead of using the backquotes `...`.
The backquoted form is the traditional method for command
substitution, and is supported by POSIX. However, all but the
simplest uses become complicated quickly. In particular,
The Git CodingGuidelines prefer the $(...) construct for command
substitution instead of using the backquotes `...`.
The backquoted form is the traditional method for command
substitution, and is supported by POSIX. However, all but the
simplest uses become complicated quickly. In particular,
The Git CodingGuidelines prefer the $(...) construct for command
substitution instead of using the backquotes `...`.
The backquoted form is the traditional method for command
substitution, and is supported by POSIX. However, all but the
simplest uses become complicated quickly. In particular,
On Mon, Apr 28, 2014 at 11:01 AM, Erik Faye-Lund kusmab...@gmail.com wrote:
On Mon, Apr 28, 2014 at 10:48 AM, Erik Faye-Lund kusmab...@gmail.com wrote:
So it seems that 08900987 (Decide whether to build http-push in the
Makefile) makes a bad assumption about the availability of
curl-config on
Hi kusma,
On Mon, 28 Apr 2014, Erik Faye-Lund wrote:
On Mon, Apr 28, 2014 at 10:48 AM, Erik Faye-Lund kusmab...@gmail.com wrote:
So it seems that 08900987 (Decide whether to build http-push in the
Makefile) makes a bad assumption about the availability of
curl-config on new libcurl
On Mon, Apr 28, 2014 at 3:20 PM, Johannes Schindelin
johannes.schinde...@gmx.de wrote:
Hi kusma,
On Mon, 28 Apr 2014, Erik Faye-Lund wrote:
On Mon, Apr 28, 2014 at 10:48 AM, Erik Faye-Lund kusmab...@gmail.com wrote:
So it seems that 08900987 (Decide whether to build http-push in the
As you may know ReactOS is now working in the new ReactOS Community Edition.
It's a new OS, with new features, redesigned image, powered by the new ReactOS
kernel which boosts its compatibility with apps and drivers. You can see a
comparative, and the new site here:
On Mon, Apr 28, 2014 at 03:20:46PM +0200, Johannes Schindelin wrote:
That way, upstream Git does not have anything to change (and we avoid
discussing five versions of essentially the same patch :-P).
This bug isn't specific to msysGit but also affects all environments
where curl-config is not
When crosscompiling, one cannot rely on `uname` from host system.
Thus, add an option to use `make MINGW=1` for building MinGW build
from non-MinGW host (Linux, for example).
Signed-off-by: Marat Radchenko ma...@slonopotamus.org
---
config.mak.uname | 5 +
1 file changed, 5 insertions(+)
bswap.h uses uint32_t type which might not be defined.
This patch adds direct include so bswap.h can be safely included.
Signed-off-by: Marat Radchenko ma...@slonopotamus.org
---
compat/bswap.h | 2 ++
1 file changed, 2 insertions(+)
diff --git a/compat/bswap.h b/compat/bswap.h
index
Also, pass -D__USE_MINGW_ANSI_STDIO=0 to select MSVCRT-compatible
macro definitions.
Signed-off-by: Marat Radchenko ma...@slonopotamus.org
---
compat/mingw.h| 2 --
compat/msvc.h | 3 +++
config.mak.uname | 3 ++-
git-compat-util.h | 11 ++-
4 files changed, 11 insertions(+),
HAVE_LIBCHARSET_H and NO_R_TO_GCC_LINKER are not specific to
msysGit, they're general MinGW settings.
Signed-off-by: Marat Radchenko ma...@slonopotamus.org
---
config.mak.uname | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/config.mak.uname b/config.mak.uname
index
On MinGW-W64, MsgWaitForMultipleObjects is guarded with #ifndef NOGDI.
Unfortunately, including wingdi.h brings in #define ERROR 0 which
conflicts with several Git internal enums. So, #undef ERROR.
Signed-off-by: Marat Radchenko ma...@slonopotamus.org
---
config.mak.uname | 4 ++--
Also, fix `warning: passing argument 2 of 'mingw_main' from
incompatible pointer type` in http-fetch.c and remote-curl.c.
Signed-off-by: Marat Radchenko ma...@slonopotamus.org
---
config.mak.uname | 2 --
http-fetch.c | 5 +++--
remote-curl.c| 2 +-
3 files changed, 4 insertions(+), 5
-D__USE_MINGW_ACCESS only affects MinGW and does nothing when
MSVC is used.
Signed-off-by: Marat Radchenko ma...@slonopotamus.org
---
config.mak.uname | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/config.mak.uname b/config.mak.uname
index e5edae6..dc87e21 100644
---
To ease cross-compilation process, introduce a single variable
with the prefix to all compiler-related executables.
Signed-off-by: Marat Radchenko ma...@slonopotamus.org
---
Makefile | 13 +
config.mak.uname | 2 +-
2 files changed, 10 insertions(+), 5 deletions(-)
diff
Patches 1 to 14/14 are
Reviewed-by: Matthieu Moy matthieu@imag.fr
(in mailer and then log -p --color-words)
--
Matthieu Moy
http://www-verimag.imag.fr/~moy/
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo
On Mon, Apr 28, 2014 at 3:47 PM, Marat Radchenko ma...@slonopotamus.org wrote:
On Mon, Apr 28, 2014 at 03:20:46PM +0200, Johannes Schindelin wrote:
That way, upstream Git does not have anything to change (and we avoid
discussing five versions of essentially the same patch :-P).
This bug isn't
1 - 100 of 271 matches
Mail list logo
