On Fri, Aug 22, 2014 at 07:39:59PM +0100, Philip Oakley wrote:
Just a bit of bikeshedding for future improvements..
The .gitignore is another potential user problem area that may benefit form
not being anonymised when problems strike.
Thanks, I had meant to mention some implications for
On 2014-08-23 00.54, Junio C Hamano wrote:
Torsten Bögershausen tbo...@web.de writes:
Commit 95f31e9a correctly points out that the NATIVE_CRLF setting is
incorrectly set on Mingw git. However, the Makefile variable is not
propagated to the C preprocessor and results in no change. This patch
On 08/23/2014 07:23 AM, Jeff King wrote:
I noticed that git pack-refs --all will pack a top-level ref like
refs/foo, but will not actually prune $GIT_DIR/refs/foo. I do not
see the point in having a policy not to pack refs/foo if --all is
given. But even if we did have such a policy, this
On Sat, Aug 23, 2014 at 09:29:36AM +0200, Michael Haggerty wrote:
[1/5]: git-prompt: do not look for refs/stash in $GIT_DIR
[2/5]: pack-refs: prune top-level refs like refs/foo
[3/5]: fast-import: clean up pack_data pointer in end_packfile
[4/5]: fast-import: fix buffer overflow
Signed-off-by: Alex Henrie alexhenri...@gmail.com
---
builtin/commit.c | 2 +-
builtin/ls-files.c | 2 +-
builtin/merge.c| 4 ++--
builtin/notes.c| 2 +-
builtin/rm.c | 2 +-
git-bisect.sh | 4 ++--
git-stash.sh | 2 +-
git.c | 2 +-
8 files changed, 10
Am 22.08.2014 um 21:41 schrieb Martin von Gagern:
On 21.08.2014 13:35, Petr Stodulka wrote:
Hi guys,
I wanted post you patch here for this bug, but I can't find primary
source of this problem [0], because I don't understand some ideas in the
code.
[…]
Any next ideas/hints or explanation
[+cc spearce, as I think this is a bug in code.google.com's sending
side, and he can probably get the attention of the right folks]
On Sat, Aug 23, 2014 at 12:12:08PM +0200, René Scharfe wrote:
Git 1.7.6 clones the repo without reporting an error or warning, but a
check shows that a tree
On Sat, Aug 23, 2014 at 06:56:40AM -0400, Jeff King wrote:
So I think your patch is doing the right thing.
By the way, if you want to add a test to your patch, there is
infrastructure in t5308 to create packs with duplicate objects. If I
understand the problem correctly, you could trigger this
2014-08-21 22:48 GMT+08:00 Jonathan Nieder jrnie...@gmail.com:
Hi,
Jeff King wrote:
However, we do always define $(LIB_H) as a dependency of
po/git.pot. Even though we do not actually try to build that
target, make will still evaluate the dependencies when
reading the Makefile, and expand
On Sat, Aug 23, 2014 at 07:04:59AM -0400, Jeff King wrote:
On Sat, Aug 23, 2014 at 06:56:40AM -0400, Jeff King wrote:
So I think your patch is doing the right thing.
By the way, if you want to add a test to your patch, there is
infrastructure in t5308 to create packs with duplicate
Hi Ralf,
If it is ready for merge, let me know. We have already missed the
v2.1.0 release (it's my fault), I don't want to miss the release of v2.1.1
again. Alex contributed l10n for a new language (Catalan), and
I will send a new pull-request to Junio in a few days.
2014-08-06 1:51 GMT+08:00
Sometimes it's interesting to have a simple output that answers the question:
Are there commits after the latest tag?
One possible solution is to just print a + (plus) signal after the tag.
Example:
git describe --abbrev=1 5261ec5d5
v2.1.0-rc1-2-g5261ec
git describe --abbrev=+ 5261ec5d5
---
Documentation/git-describe.txt | 6 ++
1 file changed, 6 insertions(+)
diff --git a/Documentation/git-describe.txt b/Documentation/git-describe.txt
index d20ca40..e291770 100644
--- a/Documentation/git-describe.txt
+++ b/Documentation/git-describe.txt
@@ -54,6 +54,12 @@ OPTIONS
It will print just a + sign appended to the found tag, if there
are commits between the tag and the supplied commit.
It's useful when you just need a simple output to know if the
supplied commit is an exact match or not.
---
builtin/describe.c | 26 +-
1 file changed, 21
Hi Jiang,
2014-08-23 14:29 GMT+02:00 Jiang Xin worldhello@gmail.com:
Hi Ralf,
If it is ready for merge, let me know. We have already missed the
v2.1.0 release (it's my fault), I don't want to miss the release of v2.1.1
again. Alex contributed l10n for a new language (Catalan), and
I
Attention:
I have a business Proposal that will be of benefit to the both of us and I
shall be compensating you with Forty percent at the final conclusion. If you
are interested please reply ASAP, so I can send you more detail on how we are
going to proceed
I await your urgent response,
On Fri, Aug 22, 2014 at 4:30 PM, Junio C Hamano gits...@pobox.com wrote:
In order to prevent a valid push certificate for pushing into an
repository from getting replayed to push to an unrelated one, send a
nonce string from the receive-pack process and have the signer
include it in the push
On OS X, strlcpy is already #define'd, which causes warnings
in all the files that include `git-compat-util.h'. Note that
this only occurs when building without running ./configure.
---
git-compat-util.h | 3 +++
1 file changed, 3 insertions(+)
diff --git a/git-compat-util.h b/git-compat-util.h
On OS X, strlcpy is already #define'd, which causes warnings
in all the files that include `git-compat-util.h'. Note that
this only occurs when building without running ./configure.
Signed-off-by: Benoit Sigoure tsuna...@gmail.com
---
Resending with the SOB line I forgot.
git-compat-util.h |
19 matches
Mail list logo
