[PATCH] ls-remote: document the '--get-url' option
While looking for a way to expand the URL of a remote that uses a 'url.name.insteadOf' config option I stumbled over the undocumented '--get-url' option of 'git ls-remote'. This adds some minimum documentation for that option. And while at it, also add that option to the '-h' output. Signed-off-by: Stefan Naewe stefan.na...@gmail.com --- Documentation/git-ls-remote.txt | 4 builtin/ls-remote.c | 2 +- 2 files changed, 5 insertions(+), 1 deletion(-) diff --git a/Documentation/git-ls-remote.txt b/Documentation/git-ls-remote.txt index 7a9b86a..a2ebf1d 100644 --- a/Documentation/git-ls-remote.txt +++ b/Documentation/git-ls-remote.txt @@ -42,6 +42,10 @@ OPTIONS it successfully talked with the remote repository, whether it found any matching refs. +--get-url:: + Expand the URL of the given remote repository taking into account any + url.base.insteadOf config setting (See linkgit:git-config[1]). + repository:: Location of the repository. The shorthand defined in $GIT_DIR/branches/ can be used. Use . (dot) to list references in diff --git a/builtin/ls-remote.c b/builtin/ls-remote.c index 41c88a9..25e83cf 100644 --- a/builtin/ls-remote.c +++ b/builtin/ls-remote.c @@ -5,7 +5,7 @@ static const char ls_remote_usage[] = git ls-remote [--heads] [--tags] [-u exec | --upload-pack exec]\n - [-q|--quiet] [--exit-code] [repository [refs...]]; + [-q|--quiet] [--exit-code] [--get-url] [repository [refs...]]; /* * Is there one among the list of patterns that match the tail part -- 1.7.12 -- 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
RE: [PATCH/RFC v4 02/13] read-cache.c: Re-read index if index file changed
From: Thomas Gummerer [mailto:t.gumme...@gmail.com]
Sent: Monday, August 27, 2012 11:40 AM
To: Joachim Schmitz
Cc: git@vger.kernel.org
Subject: Re: [PATCH/RFC v4 02/13] read-cache.c: Re-read index if index file
changed
On 08/25, Joachim Schmitz wrote:
Thomas Gummerer t.gumme...@gmail.com schrieb im Newsbeitrag
news:134529-6925-3-git-send-email-
t.gumme...@gmail.com...
[...]
+ usleep(10*1000);
usleep() is not available to anybody, e.g. it is not in HP NonStop (not in
every case at least)
Bye, Jojo
Thanks for noticing, will be fixed in the re-roll.
Instead of
usleep(10*1000);
You could use
poll(NULL, 0, 10);
instead, similar to what help.c is doing
This may need a fix in compat/win32/poll.c though:
diff --git a/compat/win32/poll.c b/compat/win32/poll.c
--- a/compat/win32/poll.c
+++ b/compat/win32/poll.c
@@ -350,7 +350,7 @@ poll (struct pollfd *pfd, nfds_t nfd, int timeout)
/* EFAULT is not necessary to implement, but let's do it in the
simplest case. */
- if (!pfd)
+ if (!pfd nfd)
{
errno = EFAULT;
return -1;
That fix would be needed anyhow...
Bye, Jojo
--
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
RE: poll() emulation in git
From: Paolo Bonzini [mailto:paolo.bonz...@gmail.com] On Behalf Of Paolo
Bonzini
Sent: Thursday, September 06, 2012 5:15 PM
To: Joachim Schmitz
Cc: git@vger.kernel.org; 'Junio C Hamano'; 'Erik Faye-Lund';
bug-gnu...@gnu.org; rsbec...@nexbridge.com
Subject: Re: poll() emulation in git
Il 06/09/2012 16:44, Joachim Schmitz ha scritto:
Yes, it's an usleep(autocorrect * 10) basically (poll takes
milliseconds, not micro).
OK, it is _supposed_ to do this usleep(), but is does not, as poll()
returns early with EFAULT in this case:
/* EFAULT is not necessary to implement, but let's do it in the
simplest case. */
if (!pfd)
{
errno = EFAULT;
return -1;
}
poll() is doing this before calling select(), so won't sleep.
So there's a bug in {gnulib|git}'s poll(), right?
Yes, it should be if (!pfd nfd).
Are you going to fix this in gnulib?
Bye, Jojo
--
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
RE: poll() emulation in git
From: Paolo Bonzini [mailto:paolo.bonz...@gmail.com] On Behalf Of Paolo Bonzini Sent: Thursday, September 06, 2012 4:32 PM To: Joachim Schmitz Cc: git@vger.kernel.org; 'Junio C Hamano'; 'Erik Faye-Lund'; bug-gnu...@gnu.org; rsbec...@nexbridge.com Subject: Re: poll() emulation in git Il 06/09/2012 16:02, Joachim Schmitz ha scritto: ... # else char data[64]; r = recv (fd, data, sizeof (data), MSG_PEEK); socket_errno = (r 0) ? errno : 0; # endif if (r == 0) happened |= POLLHUP; /* If the event happened on an unconnected server socket, that's fine. */ else if (r 0 || ( /* (r == -1) */ socket_errno == ENOTCONN)) happened |= (POLLIN | POLLRDNORM) sought; /* Distinguish hung-up sockets from other errors. */ else if (socket_errno == ESHUTDOWN || socket_errno == ECONNRESET || socket_errno == ECONNABORTED || socket_errno == ENETRESET) happened |= POLLHUP; #ifdef __TANDEM /* as we can't recv(...,MSG_PEEK) on a non-socket */ else if (socket_errno == ENOTSOCK) happened |= (POLLIN | POLLRDNORM) sought; #endif else happened |= POLLERR; } ... We won't detect POLLHUP that way I think. However it seems to work, we've been able to clone, push, pull, branch that way with NonStop being the (ssh-)server, something that didn't work at all without that hack (and yes, I believe it is just that). Someone in for a cleaner way of managing this? I suppose it works to always handle ENOTSOCK that way, even on non-__TANDEM systems. Will you be fixing this in gnulib? How? Bye, Jojo -- 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
Re: [PATCH] ls-remote: document the '--get-url' option
Stefan Naewe stefan.na...@gmail.com writes: +--get-url:: + Expand the URL of the given remote repository taking into account any + url.base.insteadOf config setting (See linkgit:git-config[1]). This should probably also mention that it suppresses the normal output. (I wonder why this isn't a subcommand of git remote.) Andreas. -- Andreas Schwab, sch...@linux-m68k.org GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 And now for something completely different. -- 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
Re: [PATCH] doc: move rev-list option -n from git-log.txt to rev-list-options.txt
Nguyễn Thái Ngọc Duy venit, vidit, dixit 06.09.2012 16:28: rev-list-options.txt is included in git-rev-list.txt. This makes sure rev-list man page also shows that, and at one place, together with equivalent options -n and --max-count. Signed-off-by: Nguyễn Thái Ngọc Duy pclo...@gmail.com --- Documentation/git-log.txt | 6 ++ Documentation/rev-list-options.txt | 3 ++- 2 tập tin đã bị thay đổi, 4 được thêm vào(+), 5 bị xóa(-) That is one reason why core.local=C (repo specific) and git -c core.locale=C (can be used in an alias) would be useful ;) diff --git a/Documentation/git-log.txt b/Documentation/git-log.txt index 1f90620..585dac4 100644 --- a/Documentation/git-log.txt +++ b/Documentation/git-log.txt @@ -24,10 +24,6 @@ each commit introduces are shown. OPTIONS --- --n:: - Limits the number of commits to show. - Note that this is a commit limiting option, see below. - since..until:: Show only commits between the named two commits. When either since or until is omitted, it defaults to @@ -137,6 +133,8 @@ Examples This makes sense only when following a strict policy of merging all topic branches when staying on a single integration branch. +`git log -3`:: + Limits the number of commits to show to 3. Discussion -- diff --git a/Documentation/rev-list-options.txt b/Documentation/rev-list-options.txt index def1340..1b15ea9 100644 --- a/Documentation/rev-list-options.txt +++ b/Documentation/rev-list-options.txt @@ -8,7 +8,8 @@ ordering and formatting options, such as '--reverse'. -- --n 'number':: +-number:: +-n number:: --max-count=number:: Limit the number of commits to output. This looks OK. I noticed though that the man pages of git-log and git-rev-list still look more different than they would need to, e.g. regarding the way limitting by paths is explained more prominently with git-log. But that may just be being more user friendly for git-log's man page than for git rev-list's, which is OK. Michael -- 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
Re: [PATCH] ls-remote: document the '--get-url' option
On Fri, Sep 7, 2012 at 10:28 AM, Andreas Schwab sch...@linux-m68k.org wrote:
Stefan Naewe stefan.na...@gmail.com writes:
+--get-url::
+ Expand the URL of the given remote repository taking into account any
+ url.base.insteadOf config setting (See linkgit:git-config[1]).
This should probably also mention that it suppresses the normal output.
Like this: http://cloud.github.com/downloads/snaewe/git/git-ls-remote.html
(I also added a simple example. I'll create a new patch if it's OK)
(I wonder why this isn't a subcommand of git remote.)
Good question...
Stefan
--
python -c print '73746566616e2e6e6165776540676d61696c2e636f6d'.decode('hex')
--
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
Re: poll() emulation in git
Il 07/09/2012 09:39, Joachim Schmitz ha scritto: I suppose it works to always handle ENOTSOCK that way, even on non-__TANDEM systems. Will you be fixing this in gnulib? How? I don't have access to the system, so it's best if you post the patches yourself to bug-gnulib and git mailing lists (separately, since the code is cross-pollinated but forked). Paolo -- 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
Re: [PATCH 0/3] pre-merge-hook
Junio C Hamano venit, vidit, dixit 06.09.2012 20:34:
Michael J Gruber g...@drmicha.warpmail.net writes:
Junio C Hamano venit, vidit, dixit 06.09.2012 07:07:
Michael J Gruber g...@drmicha.warpmail.net writes:
The pre-commit hook is often used to ensure certain properties
of each comitted tree like formatting or coding standards,
validity (lint/make) or code quality (make test). But merges
introduce new commits unless they are fast forwards, and
therefore they can break these properties because the
pre-commit hook is not run by git merge.
Introduce a pre-merge hook which works for (non ff, automatic)
merges like pre-commit does for commits. Typically this will
just call the pre-commit hook (like in the sample hook), but it
does not need to.
When your merge asks for a help from you to resolve conflict,
you conclude with git commit, and at that point, pre-commit
hook will have a chance to reject it, presumably. That means for
any project that wants to audit a merge via hook, their
pre-commit hook MUST be prepared to look at and judge a merge.
Given that, is a separate hook that can just call the pre-commit
but does not need to really needed and useful?
I admit that I haven't thought things through, but adding a
boolean merge.usePreCommitHook smells like a more appropriate
approach to me.
I dunno.
That would be an option ;)
I said I dunno as others may have opinions on the best direction to
go.
Sure. I meant to make a pun the config option approach being an option.
Either works for me, and if we don't change the current behaviour
(pre-commit-hook resp. no hook for non-automatic merges resp.
automatic merges) the config option is probably less confusing.
If we were to go in the pre-commit has to be prepared to vet a merge
already, so let it handle the automerge case direction, I have
another suggestion.
Because you need to support merge --no-verify to override the hook
anyway, I think it makes sense to introduce merge --verify to force
it trigger the hook (and it needs to percolate up to pull).
People who want it always on may want a boolean merge.verify, but
that should come in a separate step. The patch that implements it
must make sure all our internal uses of merge is updated to pass
--no-verify, unless there is a very good reason.
Hmm. Nothing calls cmd_merge() nor the relevant parts. git pull calls
git merge and should probably obey that option. All others (am etc.)
call git-merge-${strategy} directly and are not affected by the option.
Am I overlooking something?
Another direction to go would be to deprecate the commit is the way
to conclude a merge that stopped in the middle due to a conflict
asking for your help and introduce merge --continue [*1*]. That
would open a way to a separate pre/post-merge hook much cleanly. At
that point it would be clear that pre-commit won't be involved in
merge (i.e. the user never will use git commit when merging).
I am fairly negative on the current mess imposed on git commit that
has to know who called it and behave differently (look for whence
in builtin/commit.c), and would rather not to see it made worse by
piling call pre-merge if exists and in a merge, or call pre-commit
kind of hack on top of it.
That is a mess, yes. Part of it is due to the fact that both
builtin/{commit,merge}.c do a lot of commit stuff in parallel, often
with copy pasted code, and commit needs to be aware of other states
(in-am, in-rebase) also.
My feeling is that builtin/merge.c should rather get rid of the stuff
that parallels things that builtin/commit.c does, so that all is in one
place. (I think that redundancy is to blame for the inconsistent hook
behaviour for merges even within builtin/merge.c).
[Footnote]
*1* This has been brought up a few times during discussion on
sequencer and mergy operations, and I think it makes sense in the
longer term. am and rebase were first to use --continue,
instead of having the user to use commit to conclude, and later
cherry-pick and revert have been updated to follow suit, so
merge may be the only oddball remaining now.
git merge --continue to commit a resolved merge, but code-wise
builtin/commit.c taking over because it's just one more case?
I afraid that restructuring is beyond my available Git capacity and my
self-imposed constraint to avoid anything with backwards compatibility
or migration plan issues. (I took this up because I thought it's within,
to share something I've been using for a while.)
I fully agree that a big-picture-solution is preferable.
Michael
--
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
Re: [PATCH 0/9] new git check-ignore sub-command
On Sun, Sep 2, 2012 at 9:35 PM, Junio C Hamano gits...@pobox.com wrote:
* avoid unnnecessary braces {} around single statement blocks, e.g.
-if (exclude) {
+if (exclude)
return exclude;
-}
* else should follow close brace '}' of if clause, e.g.
if (...) {
...
-}
-else {
+} else {
...
What about when the if clause requires braces but the else clause
doesn't? Should it be
if (...) {
...;
...;
} else
...;
or
if (...) {
...;
...;
}
else
...;
?
--
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
Re: [PATCH/RFC] l10n: de.po: translate 2 new messages
I just notice that the 1st line of the orignal message below has only 56 characters, much shorter than other lines. It is because this is a warning message, and would add a prefix: warning: . #: builtin/push.c:151 msgid push.default is unset; its implicit value is changing in\n Git 2.0 from 'matching' to 'simple'. To squelch this message\n and maintain the current behavior after the default changes, use:\n \n git config --global push.default matching\n For this reason, translations as follows are not well-formed. So I rewind git-po, and your commits may need a bit amend. Swedish update from Peter: +push.default har inte ställts in; dess underförstådda värde ändras i\n +Git 2.0 från \matching\ till \simple\. För att undertrycka det här\n +meddelandet och behålla nuvarande beteende efter att förvalet ändras,\n +skriver du:\n +\n + git config --global push.default matching\n Vietnamese update form Trần Ngọc Quân: +msgstr +push.default chưa được đặt, giá trị ngầm định của nó đã được thay đổi trong\n +Git 2.0 từ 'matching' thành 'simple'. Để chấm dứt lời nhắc nhở này\n +và duy trì cách xử lý sau những thay đổi mặc định này, hãy chạy lệnh:\n +\n + git config --global push.default matching\n 2012/9/6 Ralf Thielow ralf.thie...@gmail.com: Translate 2 new messages came from git.pot update in ccfca8d (l10n: Update git.pot (2 new, 4 removed messages)). Signed-off-by: Ralf Thielow ralf.thie...@gmail.com --- Hi German l10n team, please review this small update on German translation. This patch here is based on a preparation commit which just contains the msgmerge change. For an easier review, I'll copy the first message in english in this email. The second change shows that there are some newlines, came from 'msgmerge', on places where we don't want to have them. I'll fix that soon. A hint on this translation: I've translated See 'git help config' and search for as Führe 'git help config' aus und suche nach..., not as Siehe 'git help config' und suche nach... because the second doesn't sound good to me. Perhaps someone else has a better idea. Thanks, Ralf #: builtin/push.c:151 msgid push.default is unset; its implicit value is changing in\n Git 2.0 from 'matching' to 'simple'. To squelch this message\n and maintain the current behavior after the default changes, use:\n \n git config --global push.default matching\n \n To squelch this message and adopt the new behavior now, use:\n \n git config --global push.default simple\n \n See 'git help config' and search for 'push.default' for further information.\n (the 'simple' mode was introduced in Git 1.7.11. Use the similar mode\n 'current' instead of 'simple' if you sometimes use older versions of Git) po/de.po | 20 ++-- 1 Datei geändert, 18 Zeilen hinzugefügt(+), 2 Zeilen entfernt(-) diff --git a/po/de.po b/po/de.po index f3d232e..df5187e 100644 --- a/po/de.po +++ b/po/de.po @@ -4431,6 +4431,23 @@ msgid (the 'simple' mode was introduced in Git 1.7.11. Use the similar mode\n 'current' instead of 'simple' if you sometimes use older versions of Git) msgstr +'push.default' ist nicht gesetzt; der implizit gesetzte Wert wird in\n +Git 2.0 von 'matching' nach 'simple' geändert. Um diese Meldung zu unter-\n +drücken und das aktuelle Verhalten nach Änderung des Standardwertes\n +beizubehalten, benutze: +\n + git config --global push.default matching\n +\n +Um diese Meldung zu unterdrücken und das neue Verhalten jetzt zu übernehmen,\n +benutze:\n +\n + git config --global push.default simple\n +\n +Führe 'git help config' aus und suche nach 'push.default' für weitere +Informationen.\n +(Der Modus 'simple' wurde in Git 1.7.11 eingeführt. Benutze den gleichartigen + Modus 'current' anstatt 'simple', falls du gelegentlich ältere Versionen von + Git benutzt) #: builtin/push.c:199 msgid @@ -4453,7 +4470,6 @@ msgstr für weitere Details. #: builtin/push.c:212 -#, fuzzy msgid Updates were rejected because a pushed branch tip is behind its remote\n counterpart. If you did not intend to push that branch, you may want to\n @@ -4465,7 +4481,7 @@ msgstr beabsichtigt hast, diesen Zweig zu versenden, kannst du auch den zu versendenden\n Zweig spezifizieren oder die Konfigurationsvariable 'push.default' zu -'current'\n +'simple', 'current'\n oder 'upstream' setzen, um nur den aktuellen Zweig zu versenden. #: builtin/push.c:218 -- 1.7.12 -- 蒋鑫 北京群英汇信息技术有限公司 邮件: worldhello@gmail.com 网址: http://www.ossxp.com/ 博客: http://www.worldhello.net/ 微博: http://weibo.com/gotgit/ 电话: 010-51262007, 18601196889 -- 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
[PATCH] Document MKDIR_WO_TRAILING_SLASH in Makefile
Signed-off-by: Joachim Schmitz j...@schmitz-digital.de --- Makefile | 2 ++ 1 file changed, 2 insertions(+) diff --git a/Makefile b/Makefile index ac49320..03e245a 100644 --- a/Makefile +++ b/Makefile @@ -90,6 +90,8 @@ all:: # # Define NO_MKDTEMP if you don't have mkdtemp in the C library. # +# Define MKDIR_WO_TRAILING_SLASH if your mkdir() can't deal with trailing slash. +# # Define NO_MKSTEMPS if you don't have mkstemps in the C library. # # Define NO_STRTOK_R if you don't have strtok_r in the C library. -- 1.7.12 -- 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
[PATCH v3 0/4] Support non-WIN32 systems lacking poll()
Here's now my series or patches to make the win32 implementation of poll() available to other platforms: 1 - poll() exits too early with EFAULT if 1st arg is NULL, as discussed with Paolo Bonzini from the gnulib team 2 - make poll available for other platforms lacking it by moving it into a separate directory and adjusting Makefile 3 - fix some win32 specific dependencies in poll.c by #ifdef the inclusion of two header files 4 - make poll() work on platforms that can't recv() on a non-socket, namely HP NonStop Bye, Jojo -- 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
RE: [PATCH v3 1/4] poll() exits too early with EFAULT if 1st arg is NULL
If poll() is used as a milli-second sleep, like in help.c, by passing a NULL
in the 1st and a 0 in the 2nd arg, it exits with EFAULT.
As per Paolo Bonzini, the original author, this is a bug and to be fixed like
in this commit, which is not to exit if the 2nd arg is 0.
Signed-off-by: Joachim Schmitz j...@schmitz-digital.de
---
compat/win32/poll.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/compat/win32/poll.c b/compat/win32/poll.c
index 403eaa7..9e7a25c 100644
--- a/compat/win32/poll.c
+++ b/compat/win32/poll.c
@@ -349,7 +349,7 @@ poll (struct pollfd *pfd, nfds_t nfd, int timeout)
/* EFAULT is not necessary to implement, but let's do it in the
simplest case. */
- if (!pfd)
+ if (!pfd nfd)
{
errno = EFAULT;
return -1;
--
1.7.12
--
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
RE: [PATCH v3 2/4] make poll available for other platforms lacking it
move poll.[ch] out of compat/win32/ into compat/poll/ and adjust
Makefile with the changed paths. Adding comments to Makefile about how/when
to enable it and add logic for this
Signed-off-by: Joachim Schmitz j...@schmitz-digital.de
---
Makefile | 20 +++-
compat/{win32 = poll}/poll.c | 0
compat/{win32 = poll}/poll.h | 0
3 files changed, 15 insertions(+), 5 deletions(-)
rename compat/{win32 = poll}/poll.c (100%)
rename compat/{win32 = poll}/poll.h (100%)
diff --git a/Makefile b/Makefile
index ac49320..7893297 100644
--- a/Makefile
+++ b/Makefile
@@ -152,6 +152,11 @@ all::
#
# Define NO_MMAP if you want to avoid mmap.
#
+# Define NO_SYS_POLL_H if you don't have sys/poll.h.
+#
+# Define NO_POLL if you do not have or don't want to use poll().
+# This also implies NO_SYS_POLL_H.
+#
# Define NO_PTHREADS if you do not have or do not want to use Pthreads.
#
# Define NO_PREAD if you have a problem with pread() system call (e.g.
@@ -598,10 +603,10 @@ LIB_H += compat/bswap.h
LIB_H += compat/cygwin.h
LIB_H += compat/mingw.h
LIB_H += compat/obstack.h
+LIB_H += compat/poll/poll.h
LIB_H += compat/precompose_utf8.h
LIB_H += compat/terminal.h
LIB_H += compat/win32/dirent.h
-LIB_H += compat/win32/poll.h
LIB_H += compat/win32/pthread.h
LIB_H += compat/win32/syslog.h
LIB_H += connected.h
@@ -1220,7 +1225,7 @@ ifeq ($(uname_S),Windows)
NO_PREAD = YesPlease
NEEDS_CRYPTO_WITH_SSL = YesPlease
NO_LIBGEN_H = YesPlease
- NO_SYS_POLL_H = YesPlease
+ NO_POLL_H = YesPlease
NO_SYMLINK_HEAD = YesPlease
NO_IPV6 = YesPlease
NO_UNIX_SOCKETS = YesPlease
@@ -1261,7 +1266,7 @@ ifeq ($(uname_S),Windows)
BASIC_CFLAGS = -nologo -I. -I../zlib -Icompat/vcbuild
-Icompat/vcbuild/include -DWIN32 -D_CONSOLE -DHAVE_STRING_H
-D_CRT_SECURE_NO_WARNINGS -D_CRT_NONSTDC_NO_DEPRECATE
COMPAT_OBJS = compat/msvc.o compat/winansi.o \
compat/win32/pthread.o compat/win32/syslog.o \
- compat/win32/poll.o compat/win32/dirent.o
+ compat/win32/dirent.o
COMPAT_CFLAGS = -D__USE_MINGW_ACCESS -DNOGDI -DHAVE_STRING_H
-DHAVE_ALLOCA_H -Icompat -Icompat/regex -Icompat/win32
-DSTRIP_EXTENSION=\.exe\
BASIC_LDFLAGS = -IGNORE:4217 -IGNORE:4049 -NOLOGO -SUBSYSTEM:CONSOLE
-NODEFAULTLIB:MSVCRT.lib
EXTLIBS = user32.lib advapi32.lib shell32.lib wininet.lib ws2_32.lib
@@ -1316,7 +1321,7 @@ ifneq (,$(findstring MINGW,$(uname_S)))
NO_PREAD = YesPlease
NEEDS_CRYPTO_WITH_SSL = YesPlease
NO_LIBGEN_H = YesPlease
- NO_SYS_POLL_H = YesPlease
+ NO_POLL_H = YesPlease
NO_SYMLINK_HEAD = YesPlease
NO_UNIX_SOCKETS = YesPlease
NO_SETENV = YesPlease
@@ -1351,7 +1356,7 @@ ifneq (,$(findstring MINGW,$(uname_S)))
COMPAT_CFLAGS += -DSTRIP_EXTENSION=\.exe\
COMPAT_OBJS += compat/mingw.o compat/winansi.o \
compat/win32/pthread.o compat/win32/syslog.o \
- compat/win32/poll.o compat/win32/dirent.o
+ compat/win32/dirent.o
EXTLIBS += -lws2_32
PTHREAD_LIBS =
X = .exe
@@ -1605,6 +1610,11 @@ ifdef NO_GETTEXT
BASIC_CFLAGS += -DNO_GETTEXT
USE_GETTEXT_SCHEME ?= fallthrough
endif
+ifdef NO_POLL
+ NO_SYS_POLL_H = YesPlease
+ COMPAT_CFLAGS += -DNO_POLL -Icompat/poll
+ COMPAT_OBJS += compat/poll/poll.o
+endif
ifdef NO_STRCASESTR
COMPAT_CFLAGS += -DNO_STRCASESTR
COMPAT_OBJS += compat/strcasestr.o
diff --git a/compat/win32/poll.c b/compat/poll/poll.c
similarity index 100%
rename from compat/win32/poll.c
rename to compat/poll/poll.c
diff --git a/compat/win32/poll.h b/compat/poll/poll.h
similarity index 100%
rename from compat/win32/poll.h
rename to compat/poll/poll.h
--
1.7.12
--
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
RE: [PATCH v3 3/4] fix some win32 specific dependencies in poll.c
In order for non-win32 platforms to be able to use poll.c, #ifdef the inclusion of two header files Signed-off-by: Joachim Schmitz j...@schmitz-digital.de --- compat/poll/poll.c | 8 ++-- 1 file changed, 6 insertions(+), 2 deletions(-) diff --git a/compat/poll/poll.c b/compat/poll/poll.c index 9e7a25c..e4b8319 100644 --- a/compat/poll/poll.c +++ b/compat/poll/poll.c @@ -24,7 +24,9 @@ # pragma GCC diagnostic ignored -Wtype-limits #endif -#include malloc.h +#if defined(WIN32) +# include malloc.h +#endif #include sys/types.h @@ -48,7 +50,9 @@ #else # include sys/time.h # include sys/socket.h -# include sys/select.h +# ifndef NO_SYS_SELECT_H +# include sys/select.h +# endif # include unistd.h #endif -- 1.7.12 -- 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
RE: [PATCH v3 4/4] make poll() work on platforms that can't recv() on a non-socket
HP NonStop can't recv() on a non-socket, this commit cates for this. So far for HP NonStop only, via #ifdef __TANDEM, but it may be usefull for others too. A similar patch got sent to gnulib. Signed-off-by: Joachim Schmitz j...@schmitz-digital.de --- compat/poll/poll.c | 5 + 1 file changed, 5 insertions(+) diff --git a/compat/poll/poll.c b/compat/poll/poll.c index e4b8319..10a204e 100644 --- a/compat/poll/poll.c +++ b/compat/poll/poll.c @@ -306,6 +306,11 @@ compute_revents (int fd, int sought, fd_set *rfds, fd_set *wfds, fd_set *efds) || socket_errno == ECONNABORTED || socket_errno == ENETRESET) happened |= POLLHUP; +#ifdef __TANDEM /* can't use recv() on non-socket */ + else if (/* (r == -1) */ socket_errno == ENOTSOCK) + happened |= (POLLIN | POLLRDNORM) sought; +#endif + else happened |= POLLERR; } -- 1.7.12 -- 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
Re: What's cooking in git.git (Sep 2012, #01; Tue, 4)
On 09/04, Junio C Hamano wrote: * tg/index-v5 (2012-08-17) 13 commits . p0002-index.sh: add perf test for the index formats . update-index.c: rewrite index when index-version is given . Write resolve-undo data for index-v5 . Write index-v5 cache-tree data . Write index-v5 . Read cache-tree in index-v5 . Read resolve-undo data . Read index-v5 . Make in-memory format aware of stat_crc . Add documentation of the index-v5 file format . t2104: Don't fail for index versions other than [23] . read-cache.c: Re-read index if index file changed . Move index v2 specific functions to their own file A GSoC project. Was waiting for comments from mentors and stakeholders, but nothing seems to be happening, other than breakage fixes on Cygwin. May discard. I was planning on continuing to work on this topic as part of my Bachelor Thesis. I had a brief discussion with Thomas Rast on IRC about this today. Because I am planning to implement an api for partial loading we decided it's probably best to hold off until that's implemented, because parts of this series may change and it's going to take me a while to implement the api. As for the actual look of the api, I think something along the lines of what was discussed at [1] would fit well. The commands would then learn to use this api. (First the commands that just read the index and later the commands that read and write the index, but for that the api will have to support writing the index) [1] http://thread.gmane.org/gmane.comp.version-control.git/198283/focus=198739 -- 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
[BUG?] git rebase not accepting :/ syntax
In 1.7.10.3, git rebase -i :/Merge will complain with:
fatal: Needed a single revision
invalid upstream :/Merge
... whereas git rev-parse :/Merge has no problem resolving
to a single revision. OTOH, git rebase -i HEAD^{/Merge} does
work, and rev-parse resolves it to the same commit.
Is that due in some way to the semantic differences between the two
revspecs, or is that just a bug ?
--
Yann Dirson - Bertin Technologies
--
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
Re: [ANNOUNCE] tig-1.0
Hi Jonas, With tig 1.0 how to feed specific revisions to the main view? The following hack worked until tig 0.17: [alias] tignowalk-helper = !git rev-list --pretty=raw --no-walk --stdin TIG_MAIN_CMD=git tignowalk-helper $tmp tig /dev/tty Cheers, JB 2012/5/10 Jonas Fonseca fons...@diku.dk: Hello, Version 1.0 of tig is now available. This release brings many smaller tweaks and improvements as well as a number of fixes and compatibility changes to work with the newer versions of git. See the release notes below for a detailed list of changes. Note that the master repository has been moved to: git://github.com/jonas/tig.git. So if you were tracking the old master repository, please update your .git/config or run: $ git remote set-url origin git://github.com/jonas/tig.git What is tig? Tig is an ncurses-based text-mode interface for git. It functions mainly as a git repository browser, but can also assist in staging changes for commit at chunk level and act as a pager for output from various git commands. - Homepage:http://jonas.nitro.dk/tig/ - Manual: http://jonas.nitro.dk/tig/manual.html - Tarballs:http://jonas.nitro.dk/tig/releases/ - Git URL: git://github.com/jonas/tig.git - Gitweb: http://repo.or.cz/w/tig.git Release notes - The master repository is git://github.com/jonas/tig.git, and the old master repository (http://jonas.nitro.dk/tig/tig.git) will be retired. Improvements: - Use git-log(1)s default commit ordering. The old behavior can be restored by adding `set commit-order = topo` to ~/.tigrc. - Support staging of single lines. Bound to '1' default. (GH #21) - Use +lineno to open the initial view at an arbitrary line. (GH #20) - Add show-notes ~/.tigrc option. Notes are displayed by default. - Support jumping to specific SHAs in the main view. - Decorate replaced commits. - Display line numbers in main view. - Colorize binary diff stats. (GH #17) - Custom colorization of lines matching a string prefix (GH #16). Example configuration: color Reported-by: green default - Use git's color settings for the main, status and diff views. Put `set read-git-colors = no` in ~/.tigrc to disable. - Handle editor options with multiple arguments. (GH #12) - Show filename when running tig blame with copy detection. (GH #19) - Use 'source path' command to load additional files from ~/.tigrc - User-defined commands prefixed with '@' are run with no console output, e.g. bind generic 3 !@rm sys$command - Make display of space changes togglable in the diff and stage view. Bound to 'W' by default. - Use per-file encoding specified in gitattributes(5) for blobs and unstaged files. - Obsolete commit-encoding option and pass --encoding=UTF-8 to revision commands. - Main view: show uncommitted changes as staged/unstaged commits. Can be disabled by putting `set show-changes = no` in ~/.tigrc. - Add %(prompt) external command variable, which will prompt for the argument value. - Log information about git commands when the TIG_TRACE environment variable is set. Example: `TIG_TRACE=/tmp/tig.log tig` - Branch view: Show the title of the last commit. - Increase the author auto-abbreviation threshold to 10. (GH #49) - For old commits show number of years in relative dates. (GH #50) Bug fixes: - Fix navigation behavior when going from branch to main view. (GH #38) - Fix segfault when sorting the tree view by author name. - Fix diff stat navigation for unmodified files with stat changes. - Show branches/refs which names are a substring of the current branch. - Stage view: fix off-by-one error when jumping to a file in a diff with only one file. - Fix diff-header colorization. (GH #15) Change summary -- The diffstat and log summary for changes made in this release. BUGS|6 +- INSTALL |5 +- Makefile| 29 +- NEWS| 56 + SITES |4 +- TODO| 41 - VERSION |1 - asciidoc.conf |3 + contrib/aspell.dict | 17 +- contrib/release.sh |4 +- contrib/tig-completion.bash |4 +- contrib/tig.spec.in |2 +- contrib/tigrc |1 - git.h | 55 + io.c| 167 +++- io.h| 14 +- manual.txt | 13 +- refs.c | 242 refs.h | 41 + tig.1.txt | 15 +- tig.c | 2514 ++- tig.h | 107 ++- tigmanual.7.txt |2 +- tigrc.5.txt | 99 ++- 24 files changed, 2368 insertions(+), 1074
Re: [BUG?] git rebase not accepting :/ syntax
Yann Dirson dir...@bertin.fr writes:
In 1.7.10.3, git rebase -i :/Merge will complain with:
fatal: Needed a single revision
invalid upstream :/Merge
... whereas git rev-parse :/Merge has no problem resolving
to a single revision.
git rebase actually calls git rev-parse :/Merge^0, which due to the
unlimited nature of :/ doesn't work.
OTOH, git rebase -i HEAD^{/Merge} does work, and rev-parse resolves
it to the same commit.
OTOH, git rev-parse HEAD^{/Merge}^0 works as expected.
Andreas.
--
Andreas Schwab, sch...@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5
And now for something completely different.
--
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
Re: approxidate parsing for bad time units
On Thu, Sep 06, 2012 at 02:01:30PM -0700, Jeffrey Middleton wrote: I'm generally very happy with the fuzzy parsing. It's a great feature that is designed to and in general does save users a lot of time and thought. In this case I don't think it does. The problems are: (1) It's not ignoring things it can't understand, it's silently interpreting them in a useless way. Right, but we would then need to come up with a list of things it _does_ understand. So right now I can say 6 June or 6th of June or even 6 de June, and it works because we just ignore the cruft in the middle. So I think you'd need to either whitelist what everybody is typing, or blacklist some common typos (or convince people to be stricter in what they type). So I do think it's worth improving. (Yes, I know, send patches; I'll think about it.) You read my mind. :) -Peff -- 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
Binary file-friendly merge -Xours or -Xtheirs?
Hi all- Helping a coworker resolve merge conflicts today I found I wanted a -Xtheirs that completely replaces conflicted binary files with the copy from the incoming branch. In other words rather than doing $ git merge maint ... conflicts occur ... $ git checkout --theirs -- path/to/binary-file $ git add path/to/binary-file $ git commit I'd like to do $ git merge -Xbinary_theirs maint ... binary conflicts are resolved automatically ... From reading the docs it's obvious the current -Xours and -Xtheirs expect to work on hunks, so I (mostly) understand the current behavior, but as a user it feels like I'm telling you how to resolve conflicts, please do the same thing for binary files. I am missing a solution that already exists? Or is this perhaps an improvement that could be made? Thanks, Stephen -- 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
RE: [PATCH v4 4/4] make poll() work on platforms that can't recv() on a non-socket
This way it gets added to gnulib too. Signed-off-by: Joachim Schmitz j...@schmitz-digital.de --- compat/poll/poll.c | 5 + 1 file changed, 4 insertions(+) diff --git a/compat/poll/poll.c b/compat/poll/poll.c index e4b8319..10a204e 100644 --- a/compat/poll/poll.c +++ b/compat/poll/poll.c @@ -306,6 +306,10 @@ compute_revents (int fd, int sought, fd_set *rfds, fd_set *wfds, fd_set *efds) || socket_errno == ECONNABORTED || socket_errno == ENETRESET) happened |= POLLHUP; + /* some systems can't use recv() on non-socket, including HP NonStop */ + else if (/* (r == -1) */ socket_errno == ENOTSOCK) + happened |= (POLLIN | POLLRDNORM) sought; + else happened |= POLLERR; } -- 1.7.12 -- 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
Re: [PATCH/RFC] l10n: de.po: translate 2 new messages
On Fri, Sep 7, 2012 at 12:31 PM, Jiang Xin worldhello@gmail.com wrote: I just notice that the 1st line of the orignal message below has only 56 characters, much shorter than other lines. It is because this is a warning message, and would add a prefix: warning: . #: builtin/push.c:151 msgid push.default is unset; its implicit value is changing in\n Git 2.0 from 'matching' to 'simple'. To squelch this message\n and maintain the current behavior after the default changes, use:\n \n git config --global push.default matching\n For this reason, translations as follows are not well-formed. So I rewind git-po, and your commits may need a bit amend. I admit that I don't really understand what you mean. I can't see a big difference in line lengths. It's not more than others have. Do you mean that the first line just lacks of a warning: part? In this case, the message needs to get fixed. Imagine that this line starts with warning: , the updated German translation would looks like this: msgstr Warnung: 'push.default' ist nicht gesetzt; der implizit gesetzte Wert wird\n in Git 2.0 von 'matching' nach 'simple' geändert. Um diese Meldung zu\n unterdrücken und das aktuelle Verhalten nach Änderung des Standardwertes\n beizubehalten, benutze: [...] I'll send you another pull request contains this update. -- 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
Re: [PATCH v3] Support for setitimer() on platforms lacking it
Joachim Schmitz j...@schmitz-digital.de writes:
HP NonStop (currently) doesn't have setitimer(). The previous attempt of an
emulation (reverted by this commit) was not a real substitute for a recurring
itimer (as here we also don't have SA_RESTART, so can't re-arm the timer).
As setitimer() is only used in cases of perceived latency and it doesn't
affect
correctness, it now gets disabled entirely, if NO_SETITIMER is set.
HP NonStop does provide struct itimerval, but other platforms may not, so this
is taken care of in this commit too, by setting NO_STRUCT_ITIMERVAL.
Signed-off-by: Joachim Schmitz j...@schmitz-digital.de
The end-result looks simple and nice (thanks for NO_STRUCT_ITIMERVAL).
As we are not going to include the earlier failed attempt in our
longer-term history (i.e. 'master', that never rewinds), however,
I would prefer to see a replacement patch (as opposed to this one
that incrementally updates the previous failed attempt). I could
squash this into the previous one myself though ;-)
Thanks.
---
Makefile | 5 +
compat/itimer.c | 50 --
git-compat-util.h | 11 +--
3 files changed, 14 insertions(+), 52 deletions(-)
delete mode 100644 compat/itimer.c
diff --git a/Makefile b/Makefile
index ac49320..7be555b 100644
--- a/Makefile
+++ b/Makefile
@@ -157,6 +157,11 @@ all::
# Define NO_PREAD if you have a problem with pread() system call (e.g.
# cygwin1.dll before v1.5.22).
#
+# Define NO_SETITIMER if you don't have setitimer()
+#
+# Define NO_STRUCT_ITIMERVAL if you don't have struct itimerval
+# This also implies NO_SETITIMER
+#
# Define NO_THREAD_SAFE_PREAD if your pread() implementation is not
# thread-safe. (e.g. compat/pread.c or cygwin)
#
diff --git a/compat/itimer.c b/compat/itimer.c
deleted file mode 100644
index 713f1ff..000
--- a/compat/itimer.c
+++ /dev/null
@@ -1,50 +0,0 @@
-#include ../git-compat-util.h
-
-static int git_getitimer(int which, struct itimerval *value)
-{
- int ret = 0;
-
- switch (which) {
- case ITIMER_REAL:
- value-it_value.tv_usec = 0;
- value-it_value.tv_sec = alarm(0);
- ret = 0; /* if alarm() fails, we get a SIGLIMIT */
- break;
- case ITIMER_VIRTUAL: /* FALLTHRU */
- case ITIMER_PROF: errno = ENOTSUP; ret = -1; break;
- default: errno = EINVAL; ret = -1;
- }
- return ret;
-}
-
-int git_setitimer(int which, const struct itimerval *value,
- struct itimerval *ovalue)
-{
- int ret = 0;
-
- if (!value
- || value-it_value.tv_usec 0
- || value-it_value.tv_usec 100
- || value-it_value.tv_sec 0) {
- errno = EINVAL;
- return -1;
- }
-
- else if (ovalue)
- if (!git_getitimer(which, ovalue))
- return -1; /* errno set in git_getitimer() */
-
- else
- switch (which) {
- case ITIMER_REAL:
- alarm(value-it_value.tv_sec +
- (value-it_value.tv_usec 0) ? 1 : 0);
- ret = 0; /* if alarm() fails, we get a SIGLIMIT */
- break;
- case ITIMER_VIRTUAL: /* FALLTHRU */
- case ITIMER_PROF: errno = ENOTSUP; ret = -1; break;
- default: errno = EINVAL; ret = -1;
- }
-
- return ret;
-}
diff --git a/git-compat-util.h b/git-compat-util.h
index 18089f0..4628d7a 100644
--- a/git-compat-util.h
+++ b/git-compat-util.h
@@ -162,9 +162,16 @@
#define probe_utf8_pathname_composition(a,b)
#endif
+#ifdef NO_STRUCT_ITIMERVAL
+struct itimerval {
+ struct timeval it_interval;
+ struct timeval it_value;
+}
+#define NO_SETITIMER
+#endif
+
#ifdef NO_SETITIMER
-#define setitimer(a,b,c) git_setitimer((a),(b),(c))
-extern int git_setitimer(int, const struct itimerval *, struct itimerval *);
+#define setitimer(which,value,ovalue)
#endif
#ifdef MKDIR_WO_TRAILING_SLASH
--
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
Re: [PATCH 0/9] new git check-ignore sub-command
Adam Spiers g...@adamspiers.org writes:
On Sun, Sep 2, 2012 at 9:35 PM, Junio C Hamano gits...@pobox.com wrote:
* avoid unnnecessary braces {} around single statement blocks, e.g.
-if (exclude) {
+if (exclude)
return exclude;
-}
* else should follow close brace '}' of if clause, e.g.
if (...) {
...
-}
-else {
+} else {
...
What about when the if clause requires braces but the else clause
doesn't? Should it be
if (...) {
...;
...;
} else
...;
or
if (...) {
...;
...;
}
else
...;
?
Neither. We try to do (but often fail ;-)
if (...) {
...;
...;
} else {
...;
}
following the kernel style, unless there is good reason not to.
--
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
Re: [PATCH/RFC] l10n: de.po: translate 2 new messages
On Fri, Sep 7, 2012 at 6:36 PM, Ralf Thielow ralf.thie...@gmail.com wrote: On Fri, Sep 7, 2012 at 12:31 PM, Jiang Xin worldhello@gmail.com wrote: I just notice that the 1st line of the orignal message below has only 56 characters, much shorter than other lines. It is because this is a warning message, and would add a prefix: warning: . #: builtin/push.c:151 msgid push.default is unset; its implicit value is changing in\n Git 2.0 from 'matching' to 'simple'. To squelch this message\n and maintain the current behavior after the default changes, use:\n \n git config --global push.default matching\n For this reason, translations as follows are not well-formed. So I rewind git-po, and your commits may need a bit amend. I admit that I don't really understand what you mean. I can't see a big difference in line lengths. It's not more than others I got it. This warning: is added automatically. Sorry -- 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
Re: [PATCHv2] fetch --all: pass --tags/--no-tags through to each remote
Dan Johnson computerdr...@gmail.com writes:
When fetch is invoked with --all, we need to pass the tag-following
preference to each individual fetch; without this, we will always
auto-follow tags, preventing us from fetching the remote tags into a
remote-specific namespace, for example.
Reported-by: Oswald Buddenhagen o...@kde.org
Signed-off-by: Dan Johnson computerdr...@gmail.com
---
On Sat, Sep 1, 2012 at 7:22 AM, Jeff King p...@peff.net wrote:
Hmm. We allocate argv in fetch_multiple like this:
const char *argv[12] = { fetch, --append };
and then add a bunch of options to it, along with the name of the
remote. By my count, the current code can hit exactly 12 (including the
terminating NULL) if all options are set. Your patch would make it
possible to overflow. Of course, I may be miscounting since it is
extremely error-prone to figure out the right number by tracing each
possible conditional.
Maybe we should switch it to a dynamic argv_array? Like this:
[1/2]: argv-array: add pop function
[2/2]: fetch: use argv_array instead of hand-building arrays
This version is re-rolled to be on top of jk/argv-array, avoiding the issue of
the fixed-size array entirely. If needed, we could of course use the old
version of this patch and bump the number, but I figure this is preferable.
Thanks. Queued.
--
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
Re: [PATCH/RFC] l10n: de.po: translate 2 new messages
On Fri, Sep 7, 2012 at 7:05 PM, Ralf Thielow ralf.thie...@gmail.com wrote: On Fri, Sep 7, 2012 at 6:36 PM, Ralf Thielow ralf.thie...@gmail.com wrote: On Fri, Sep 7, 2012 at 12:31 PM, Jiang Xin worldhello@gmail.com wrote: I just notice that the 1st line of the orignal message below has only 56 characters, much shorter than other lines. It is because this is a warning message, and would add a prefix: warning: . #: builtin/push.c:151 msgid push.default is unset; its implicit value is changing in\n Git 2.0 from 'matching' to 'simple'. To squelch this message\n and maintain the current behavior after the default changes, use:\n \n git config --global push.default matching\n For this reason, translations as follows are not well-formed. So I rewind git-po, and your commits may need a bit amend. I admit that I don't really understand what you mean. I can't see a big difference in line lengths. It's not more than others I got it. This warning: is added automatically. Sorry The update would looks like this: msgstr 'push.default' ist nicht gesetzt; der implizit gesetzte Wert\n wird in Git 2.0 von 'matching' nach 'simple' geändert. Um diese Meldung zu\n unterdrücken und das aktuelle Verhalten nach Änderung des Standardwertes\n ... -- 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
Re: [PATCH] doc: move rev-list option -n from git-log.txt to rev-list-options.txt
Michael J Gruber g...@drmicha.warpmail.net writes: Nguyễn Thái Ngọc Duy venit, vidit, dixit 06.09.2012 16:28: rev-list-options.txt is included in git-rev-list.txt. This makes sure rev-list man page also shows that, and at one place, together with equivalent options -n and --max-count. Signed-off-by: Nguyễn Thái Ngọc Duy pclo...@gmail.com --- Documentation/git-log.txt | 6 ++ Documentation/rev-list-options.txt | 3 ++- 2 tập tin đã bị thay đổi, 4 được thêm vào(+), 5 bị xóa(-) That is one reason why core.local=C (repo specific) and git -c core.locale=C (can be used in an alias) would be useful ;) Or LC_ALL=C LANG=C git format-patch It does not bother me (even though I do not read Vietnamese), but this has been brought up a few times, and we may want to revert the i18n of the diffstat summary. It does not seem to add much value to the system but annoys people. After all, the upstream diffstat does not localizes this string (I just checked diffstat-1.55 with Jan 2012 timestamp). -- 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
Re: [PATCH] Document MKDIR_WO_TRAILING_SLASH in Makefile
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
Re: [PATCH] Document MKDIR_WO_TRAILING_SLASH in Makefile
Joachim Schmitz j...@schmitz-digital.de writes: Signed-off-by: Joachim Schmitz j...@schmitz-digital.de --- Makefile | 2 ++ 1 file changed, 2 insertions(+) diff --git a/Makefile b/Makefile index ac49320..03e245a 100644 --- a/Makefile +++ b/Makefile @@ -90,6 +90,8 @@ all:: # # Define NO_MKDTEMP if you don't have mkdtemp in the C library. # +# Define MKDIR_WO_TRAILING_SLASH if your mkdir() can't deal with trailing slash. +# # Define NO_MKSTEMPS if you don't have mkstemps in the C library. # # Define NO_STRTOK_R if you don't have strtok_r in the C library. Not really. make MKDIR_WO_TRAILING_SLASH=YesPlease won't do anything. You would need at least something like this, no? Makefile | 5 + 1 file changed, 5 insertions(+) diff --git c/Makefile w/Makefile index 66e8216..21b4816 100644 --- c/Makefile +++ w/Makefile @@ -90,6 +90,8 @@ all:: # # Define NO_MKDTEMP if you don't have mkdtemp in the C library. # +# Define MKDIR_WO_TRAILING_SLASH if your mkdir() can't deal with trailing slash. +# # Define NO_MKSTEMPS if you don't have mkstemps in the C library. # # Define NO_STRTOK_R if you don't have strtok_r in the C library. @@ -1639,6 +1641,9 @@ ifdef NO_MKDTEMP COMPAT_CFLAGS += -DNO_MKDTEMP COMPAT_OBJS += compat/mkdtemp.o endif +ifdef MKDIR_WO_TRAILING_SLASH + COMPAT_CFLAGS += -DMKDIR_WO_TRAILING_SLASH +endif ifdef NO_MKSTEMPS COMPAT_CFLAGS += -DNO_MKSTEMPS endif -- 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
Re: [PATCH/RFC] l10n: de.po: translate 2 new messages
Ralf Thielow ralf.thie...@gmail.com writes: On Fri, Sep 7, 2012 at 6:36 PM, Ralf Thielow ralf.thie...@gmail.com wrote: On Fri, Sep 7, 2012 at 12:31 PM, Jiang Xin worldhello@gmail.com wrote: I just notice that the 1st line of the orignal message below has only 56 characters, much shorter than other lines. It is because this is a warning message, and would add a prefix: warning: . #: builtin/push.c:151 msgid push.default is unset; its implicit value is changing in\n Git 2.0 from 'matching' to 'simple'. To squelch this message\n and maintain the current behavior after the default changes, use:\n \n git config --global push.default matching\n For this reason, translations as follows are not well-formed. So I rewind git-po, and your commits may need a bit amend. I admit that I don't really understand what you mean. I can't see a big difference in line lengths. It's not more than others I got it. This warning: is added automatically. Sorry We may want to revisit this behaviour, by the way. If you have a long string that barely happens to fit on a line with warning: prefix in the original, your translation might want to spell it in two lines, i.e. warning(_(A quick brown fox jumps over the lazy dog.)); which gives warning: A quick brown fox jumps over the lazy dog.LF might want to turn into warning(AA qquuiicckk bbrroowwnn ffooxx\n jjuummppss oovveerr tthhee llaazzyy ddoogg.); and currently gives: wwaarrnniinngg: AA qquuiicckk bbrroowwnn ffooxxLF jjuummppss oovveerr tthhee llaazzyy ddoogg.LF But we may want to give wwaarrnniinngg: AA qquuiicckk bbrroowwnn ffooxxLF wwaarrnniinngg: jjuummppss oovveerr tthhee llaazzyy ddoogg.LF instead. Check out the way advice.c::advise() does its hints: prefix for hints, but we probably would want to avoid anything that allocates more memory in the die() codepath. -- 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
Re: [PATCH] ls-remote: document the '--get-url' option
Stefan Naewe stefan.na...@gmail.com writes: While looking for a way to expand the URL of a remote that uses a 'url.name.insteadOf' config option I stumbled over the undocumented '--get-url' option of 'git ls-remote'. This adds some minimum documentation for that option. And while at it, also add that option to the '-h' output. Signed-off-by: Stefan Naewe stefan.na...@gmail.com --- Documentation/git-ls-remote.txt | 4 builtin/ls-remote.c | 2 +- 2 files changed, 5 insertions(+), 1 deletion(-) diff --git a/Documentation/git-ls-remote.txt b/Documentation/git-ls-remote.txt index 7a9b86a..a2ebf1d 100644 --- a/Documentation/git-ls-remote.txt +++ b/Documentation/git-ls-remote.txt @@ -42,6 +42,10 @@ OPTIONS it successfully talked with the remote repository, whether it found any matching refs. +--get-url:: + Expand the URL of the given remote repository taking into account any + url.base.insteadOf config setting (See linkgit:git-config[1]). + I'll queue this, after adding ... and exit without talking to the remote. 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
RE: [PATCH] Document MKDIR_WO_TRAILING_SLASH in Makefile
-Original Message- From: Junio C Hamano [mailto:gits...@pobox.com] Sent: Friday, September 07, 2012 7:30 PM To: Joachim Schmitz Cc: git@vger.kernel.org Subject: Re: [PATCH] Document MKDIR_WO_TRAILING_SLASH in Makefile Joachim Schmitz j...@schmitz-digital.de writes: Signed-off-by: Joachim Schmitz j...@schmitz-digital.de --- Makefile | 2 ++ 1 file changed, 2 insertions(+) diff --git a/Makefile b/Makefile index ac49320..03e245a 100644 --- a/Makefile +++ b/Makefile @@ -90,6 +90,8 @@ all:: # # Define NO_MKDTEMP if you don't have mkdtemp in the C library. # +# Define MKDIR_WO_TRAILING_SLASH if your mkdir() can't deal with trailing slash. +# # Define NO_MKSTEMPS if you don't have mkstemps in the C library. # # Define NO_STRTOK_R if you don't have strtok_r in the C library. Not really. make MKDIR_WO_TRAILING_SLASH=YesPlease won't do anything. You would need at least something like this, no? Yes, that is better, thanks Makefile | 5 + 1 file changed, 5 insertions(+) diff --git c/Makefile w/Makefile index 66e8216..21b4816 100644 --- c/Makefile +++ w/Makefile @@ -90,6 +90,8 @@ all:: # # Define NO_MKDTEMP if you don't have mkdtemp in the C library. # +# Define MKDIR_WO_TRAILING_SLASH if your mkdir() can't deal with trailing slash. +# # Define NO_MKSTEMPS if you don't have mkstemps in the C library. # # Define NO_STRTOK_R if you don't have strtok_r in the C library. @@ -1639,6 +1641,9 @@ ifdef NO_MKDTEMP COMPAT_CFLAGS += -DNO_MKDTEMP COMPAT_OBJS += compat/mkdtemp.o endif +ifdef MKDIR_WO_TRAILING_SLASH + COMPAT_CFLAGS += -DMKDIR_WO_TRAILING_SLASH +endif ifdef NO_MKSTEMPS COMPAT_CFLAGS += -DNO_MKSTEMPS endif -- 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
RE: [PATCH v3] Support for setitimer() on platforms lacking it
From: Junio C Hamano [mailto:gits...@pobox.com] Sent: Friday, September 07, 2012 6:41 PM To: Joachim Schmitz Cc: git@vger.kernel.org Subject: Re: [PATCH v3] Support for setitimer() on platforms lacking it Joachim Schmitz j...@schmitz-digital.de writes: HP NonStop (currently) doesn't have setitimer(). The previous attempt of an emulation (reverted by this commit) was not a real substitute for a recurring itimer (as here we also don't have SA_RESTART, so can't re-arm the timer). As setitimer() is only used in cases of perceived latency and it doesn't affect correctness, it now gets disabled entirely, if NO_SETITIMER is set. HP NonStop does provide struct itimerval, but other platforms may not, so this is taken care of in this commit too, by setting NO_STRUCT_ITIMERVAL. Signed-off-by: Joachim Schmitz j...@schmitz-digital.de The end-result looks simple and nice (thanks for NO_STRUCT_ITIMERVAL). As we are not going to include the earlier failed attempt in our longer-term history (i.e. 'master', that never rewinds), however, I would prefer to see a replacement patch (as opposed to this one that incrementally updates the previous failed attempt). I could squash this into the previous one myself though ;-) Yes, please ;-) Bye, Jojo -- 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
help doing a hotfix bisect: cherry-pick -m ??
hi all. Im trying to add a jumplabel implementation into dynamic-debug, and have run into an include-dependency problem. Ive managed to resolve 1 problem, and am now stuck on how to use cherry-pick -m 1st, the problem Ive handled (just for setup, story) I did a simple hotfix bisection, adding: --- a/include/linux/dynamic_debug.h +++ b/include/linux/dynamic_debug.h +#include linux/jump_label.h + This bisect run pointed to: commit b202952075f62603bea9bfb6ebc6b0420db11949 Author: Gleb Natapov g...@redhat.com Date: Sun Nov 27 17:59:09 2011 +0200 perf, core: Rate limit perf_sched_events jump_label patching jump_lable patching is very expensive operation that involves pausing al cpus. The patching of perf_sched_events jump_label is easily controllabl from userspace by unprivileged user. ... That commit adds #include linux/workqueue.h to dynamic_debug.h, so I split the workqueue and _deferred elements out to jump_label_deferred.h, and updated the _deferred users. The result builds cleanly and boots. However, once I try adding the above hotfix patch again, I get another handful of compile-errs (minus 1 that got fixed by above) And now Im running into bisection troubles. There are a 1/2 dozen patches to jump-label between Gleb's and -rc4, which make my patch against rc4 inapplicable. Ive tried to use the cherry-pick example from the help to pick them all up: but it craps out (tech term) git rev-list --reverse b2029520..dyndbg/jump-3a -- include/linux/jump_label.h | git cherry-pick -n --stdin error: could not apply c5905af... static keys: Introduce 'struct static_key', static_key_true()/false() and static_key_slow_[inc|dec]() hint: after resolving the conflicts, mark the corrected paths hint: with 'git add paths' or 'git rm paths' So I tried again, adding kernel/jump_label.c git rev-list --reverse b2029520..dyndbg/jump-3a -- include/linux/jump_label.h kernel/jump_label.c | git cherry-pick -n --stdin error: Commit 9e31905f293ae84e4f120ed9e414031eaefa0bdf is a merge but no -m option was given. fatal: cherry-pick failed Ive tried several variations on -m arg, trying 1, 2, parent-sha, (thats quite wrong) I keep getting this err: git rev-list --reverse b2029520..dyndbg/jump-3a -- include/linux/jump_label.h kernel/jump_label.c | git cherry-pick -n --stdin -m 1 error: Mainline was specified but commit 9cdbe1cbac4ec318037297175587a0080acc9d11 is not a merge. I find the -m help text completely unenlightening. what is a parent number ? where does it start from ? Im trying to cherry pick from master to hotfix-2, I presume thats a normal/natural usage. are parent numbers relative to the branch Im on, or the branch Im cherry-picking from ? or something else completely. Broader question: presuming I do manage to cherry-pick the right set commits, should I drop the -n ? Im thinking that having a hotfix branch, and merging --no-commit would work better, especially when bisection lands on a commit which already contains some of those in the hotfix branch. Am I thinking rightly ? Anything else to add ?? Since concrete, in-context advice would be so much more helpful than tips using foo, bar, etc, Ive pushed my branch to github, user jimc, branch dyndbg/jump-3a git://github.com/jimc/linux-2.6.git https://github.com/jimc/linux-2.6.git https://github.com/jimc/linux-2.6/tree/dyndbg/jump-3a thanks in advance. -- 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
Re: [ANNOUNCE] tig-1.0
On Fri, Sep 7, 2012 at 9:41 AM, Jean-Baptiste Quenot j...@caraldi.com wrote: Hi Jonas, Hello Jean-Baptiste With tig 1.0 how to feed specific revisions to the main view? The following hack worked until tig 0.17: [alias] tignowalk-helper = !git rev-list --pretty=raw --no-walk --stdin TIG_MAIN_CMD=git tignowalk-helper $tmp tig /dev/tty The possibility to specify commands was removed in favor of improving options given on the command line. In this spirit, I suggest to support something like the following: tig --no-walk --stdin tmp-file Would that cover your use case? -- Jonas Fonseca -- 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
[PATCH 0/2] multiline prefixes on messages
This is a short implementation of an idea i have, based on Junio's comment. It might not follows the coding style, the comments can be adverse and so on... Just want to know if it's the right direction. This series introduces a function that allows to add a prefix to multilined messages. The function itself is an extraction of the code of advice.c::advice(). Extract this as a separate function has the advantage that we can mark these prefixes for translation and can produce a nicer output. Junio said that we should probably avoid memory allocation on die() codepaths, but warning messages are acceptable, I think. If the series is basically acceptable, the usage: messages are also a cancidate for migration to this. Ralf Thielow (2): advice: extract function to print messages with prefix i18n: mark prefix warning: for translation advice.c | 14 ++ advice.h | 1 + usage.c | 2 +- 3 Dateien geändert, 12 Zeilen hinzugefügt(+), 5 Zeilen entfernt(-) -- 1.7.12.176.g3fc0e4c.dirty -- 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
[PATCH 2/2] i18n: mark prefix warning: for translation
Signed-off-by: Ralf Thielow ralf.thie...@gmail.com
---
usage.c | 2 +-
1 Datei geändert, 1 Zeile hinzugefügt(+), 1 Zeile entfernt(-)
diff --git a/usage.c b/usage.c
index a2a6678..162a4b2 100644
--- a/usage.c
+++ b/usage.c
@@ -44,7 +44,7 @@ static void error_builtin(const char *err, va_list params)
static void warn_builtin(const char *warn, va_list params)
{
- vreportf(warning: , warn, params);
+ print_with_prefix(_(warning:), warn, params);
}
/* If we are in a dlopen()ed .so write to a global variable would segfault
--
1.7.12.176.g3fc0e4c.dirty
--
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
[PATCH 1/2] advice: extract function to print messages with prefix
Extract a function that allows to print messages
with a prefix.
Signed-off-by: Ralf Thielow ralf.thie...@gmail.com
---
advice.c | 14 ++
advice.h | 1 +
2 Dateien geändert, 11 Zeilen hinzugefügt(+), 4 Zeilen entfernt(-)
diff --git a/advice.c b/advice.c
index edfbd4a..e73d53b 100644
--- a/advice.c
+++ b/advice.c
@@ -25,25 +25,31 @@ static struct {
{ detachedhead, advice_detached_head },
};
-void advise(const char *advice, ...)
+void print_with_prefix(const char *prefix, const char *msg, ...)
{
struct strbuf buf = STRBUF_INIT;
va_list params;
const char *cp, *np;
- va_start(params, advice);
- strbuf_vaddf(buf, advice, params);
+ va_start(params, msg);
+ strbuf_vaddf(buf, msg, params);
va_end(params);
for (cp = buf.buf; *cp; cp = np) {
np = strchrnul(cp, '\n');
- fprintf(stderr, _(hint: %.*s\n), (int)(np - cp), cp);
+ fprintf(stderr, %s %.*s\n, prefix, (int)(np - cp), cp);
if (*np)
np++;
}
strbuf_release(buf);
}
+void advise(const char *advice, ...)
+{
+ va_list vl;
+ print_with_prefix(_(hint:), advice, vl);
+}
+
int git_default_advice_config(const char *var, const char *value)
{
const char *k = skip_prefix(var, advice.);
diff --git a/advice.h b/advice.h
index f3cdbbf..328e255 100644
--- a/advice.h
+++ b/advice.h
@@ -14,6 +14,7 @@ extern int advice_implicit_identity;
extern int advice_detached_head;
int git_default_advice_config(const char *var, const char *value);
+void print_with_prefix(const char *prefix, const char *msg, ...);
void advise(const char *advice, ...);
int error_resolve_conflict(const char *me);
extern void NORETURN die_resolve_conflict(const char *me);
--
1.7.12.176.g3fc0e4c.dirty
--
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
Re: help doing a hotfix bisect: cherry-pick -m ??
Jim Cromie jim.cro...@gmail.com writes: Broader question: Im thinking that having a hotfix branch, and merging --no-commit would work better, especially when bisection lands on a commit which already contains some of those in the hotfix branch. When your history leading to the bad commit contains only part of the hot-fix branch and not all of it, that may work better. -- 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
Re: [PATCH 1/2] advice: extract function to print messages with prefix
Ralf Thielow ralf.thie...@gmail.com writes:
Extract a function that allows to print messages
with a prefix.
Signed-off-by: Ralf Thielow ralf.thie...@gmail.com
---
advice.c | 14 ++
advice.h | 1 +
2 Dateien geändert, 11 Zeilen hinzugefügt(+), 4 Zeilen entfernt(-)
diff --git a/advice.c b/advice.c
index edfbd4a..e73d53b 100644
--- a/advice.c
+++ b/advice.c
@@ -25,25 +25,31 @@ static struct {
{ detachedhead, advice_detached_head },
};
-void advise(const char *advice, ...)
+void print_with_prefix(const char *prefix, const char *msg, ...)
{
struct strbuf buf = STRBUF_INIT;
va_list params;
const char *cp, *np;
- va_start(params, advice);
- strbuf_vaddf(buf, advice, params);
+ va_start(params, msg);
+ strbuf_vaddf(buf, msg, params);
va_end(params);
for (cp = buf.buf; *cp; cp = np) {
np = strchrnul(cp, '\n');
- fprintf(stderr, _(hint: %.*s\n), (int)(np - cp), cp);
+ fprintf(stderr, %s %.*s\n, prefix, (int)(np - cp), cp);
Hrm, naively, printf(%s: %.*s\n, _(hint), ...) might look more
natural, but I vaguely recall that the current code places _()
around the entire hint: %.*s\n on purpose. IIRC, it was to allow
translations that flow from RTL e.g. .siht od t'nod :tnih.
Doesn't this patch break it?
--
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
Re: [PATCH 1/2] advice: extract function to print messages with prefix
On Fri, Sep 7, 2012 at 9:32 PM, Junio C Hamano gits...@pobox.com wrote:
Ralf Thielow ralf.thie...@gmail.com writes:
Extract a function that allows to print messages
with a prefix.
Signed-off-by: Ralf Thielow ralf.thie...@gmail.com
---
advice.c | 14 ++
advice.h | 1 +
2 Dateien geändert, 11 Zeilen hinzugefügt(+), 4 Zeilen entfernt(-)
diff --git a/advice.c b/advice.c
index edfbd4a..e73d53b 100644
--- a/advice.c
+++ b/advice.c
@@ -25,25 +25,31 @@ static struct {
{ detachedhead, advice_detached_head },
};
-void advise(const char *advice, ...)
+void print_with_prefix(const char *prefix, const char *msg, ...)
{
struct strbuf buf = STRBUF_INIT;
va_list params;
const char *cp, *np;
- va_start(params, advice);
- strbuf_vaddf(buf, advice, params);
+ va_start(params, msg);
+ strbuf_vaddf(buf, msg, params);
va_end(params);
for (cp = buf.buf; *cp; cp = np) {
np = strchrnul(cp, '\n');
- fprintf(stderr, _(hint: %.*s\n), (int)(np - cp), cp);
+ fprintf(stderr, %s %.*s\n, prefix, (int)(np - cp), cp);
Hrm, naively, printf(%s: %.*s\n, _(hint), ...) might look more
natural, but I vaguely recall that the current code places _()
around the entire hint: %.*s\n on purpose. IIRC, it was to allow
translations that flow from RTL e.g. .siht od t'nod :tnih.
Doesn't this patch break it?
Sorry but I don't know what you mean with translations that flow
from RTL e.g. .siht od t'nod :tnih. so I can't check this.
As far as I can see the callers only put a simple message in it,
e.g. advise(_(Commit your changes or stash them to proceed.));
So I don't think that this patch would break anything.
--
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
Re: [PATCH 3/5] path.c: Use vsnpath() in the implementation of git_path()
Junio C Hamano wrote:
Ramsay Jones ram...@ramsay1.demon.co.uk writes:
The current implementation of git_path() is essentially the same as
that of vsnpath(), with two minor differences. First, git_path()
currently insists that the git directory path is no longer than
PATH_MAX-100 characters in length. However, vsnpath() does not
attempt this arbitrary 100 character reservation for the remaining
path components. Second, vsnpath() uses the is_dir_sep() macro,
rather than comparing directly to '/', to determine if the git_dir
path component ends with a path separator.
In order to benefit from the above improvements,...
In the longer term, I think this goes in the right direction, but
the loss of reservation, especially when we know git_path() is used
by some callers to get the base directory in $GIT_DIR that want to
append stuff after the returned directory path to form the final
pathname, is a bit worrysome. It may be hiding a bug (lack of
proper limit check) on the callers' side.
Hmm, at first I could not see what you found worrysome here.
After all, the number of inputs which leads to success (i.e. does
not result in an /bad-path/ return) has been *increased* with
this patch.
However, I suppose you are concerned about something like this:
char *git_dir = git_path();
if (strcmp(git_dir, /bad-path/) != 0) {
/*
* Having studied the implementation of git_path(), I know
* that the buffer pointed to by git_dir has space for an
* additional 100 chars. This is enough room to concatenate
* the doberry path, so this is safe ...
*/
strcat(git_dir, doberry); /* oops */
}
Yes?
Hmm, yes it would be a little disapointing to see such parasitic code!
;-)
You said above: ... especially when we know git_path() is used
by some callers to get the base directory in $GIT_DIR Can you
point me to an example of such a caller; I have been unable to find
any code which does this.
ATB,
Ramsay Jones
--
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
Re: [PATCH 2/5] path.c: Don't discard the return value of vsnpath()
Junio C Hamano wrote: cleanup_path() is a quick-and-dirty hack that only deals with leading ./// (e.g. foo//bar is not reduced to foo/bar), and the callers that allocate 4 bytes for buf to hold foo may not be able to fit it if for some reason there are some bytes that must be cleaned, e.g. .///foo. The worst part of its use is that buf and ret could be different, which means you cannot safely do: char *buf = xmalloc(...); buf = git_snpath(buf, n, %s, ...); ... use buf ... free(buf); Hmm, this seems very unnatural to me; it would never have occurred to me to use anything other than a stack allocated buffer (or *maybe* a global buffer) when calling git_snpath(). In this situation (ie a dynamically allocated buffer used to hold the result), why would you not use git_pathdup()? (which does not suffer this problem.) I guess it does not matter what I find unnatural, ... :( but instead have to do something like: char *path, *buf = xmalloc(...); path = git_snpath(buf, n, %s, ...); ... use path ... free(buf); And this series goes in a direction of making more callers aware of the twisted calling convention, which smells really bad. Note that, prior to commit aba13e7c (git_pathdup: returns xstrdup-ed copy of the formatted path, 27-10-2008), git_snpath() was calling cleanup_path() in the non-error return path. I suspect that this commit did not intend to fix the git_snpath() interface and only did so by accident. (That's a guess, of course) However, I much prefer git_snpath(), git_pathdup() and git_path() return the same result string given the same inputs! :D ATB, Ramsay Jones -- 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
Re: [PATCH v3 3/3] checkout: reorder option handling
Nguyễn Thái Ngọc Duy pclo...@gmail.com writes:
+ if (opts-track != BRANCH_TRACK_UNSPECIFIED)
+ die(_(%s cannot be used with updating paths), --track);
I think most of the places we try to enclose these literals inside
quotes, so I'd squash in a patch to make this:
die(_('%s' cannot be used with updating paths), --track);
and update others to match.
+ if (new-name !new-commit)
+ die(_(Cannot switch branch to a non-commit '%s'.),
+ new-name);
This is one of the only few places that end a sentence with a full-stop.
+ /* Try to give more helpful suggestion, new_branch
+argc 1 will be caught later */
Style;
+ if (opts.new_branch argc == 1)
+ die(_(Cannot update paths and switch to branch '%s' at
the same time.\n
+ Did you intend to checkout '%s' which can not be
resolved as commit?),
+ opts.new_branch, argv[0]);
if (opts.force_detach)
die(_(git checkout: --detach does not take a path
argument));
I tried this codepath and the message left me feeling uneasy. I'd do:
die(_(git checkout: --detach does not take a path argument
'%s'),
argv[0]);
Other than these, I didn't find anything obviously wrong with my
final review before merging to 'next', so I'll merge it soonish.
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
Re: checkout extra files
Junio C Hamano gits...@pobox.com writes: But that is not what is happening at all. What goes on is far simpler than that. - the shell sees '*', matches it against working tree files, to obtain f1 and f2; - the shell tells git to checkout e6f935e -- f1 f2; - git looks into the tree of e6f935e to find paths that match f1 and f2. When git is run by the shell in the last step, it has _no_ clue that the end user typed * from the shell. It only sees f1 and f2 on the command line. There is no set T to be intersected with set W, so stop thinking in those terms, and you will be fine. Now the question is, _you_ will be fine, but can the documentation be updated in such a way so that it will help _others_ to also stop thinking about intersection between set W and set T? I do not have a good answer to that. Let's do this. I do not want a shell tutorial in git checkout documentation, but this would fit better in the documentation for the CLI convention. -- 8 -- gitcli: contrast wildcard given to shell and to git People who are not used to working with shell may intellectually understand how the command line argument is massaged by the shell but still have a hard time visualizing the difference between letting the shell expand fileglobs and having Git see the fileglob to use as a pathspec. Signed-off-by: Junio C Hamano gits...@pobox.com --- Documentation/gitcli.txt | 16 1 file changed, 16 insertions(+) diff --git c/Documentation/gitcli.txt w/Documentation/gitcli.txt index ea17f7a..220621b 100644 --- c/Documentation/gitcli.txt +++ w/Documentation/gitcli.txt @@ -38,6 +38,22 @@ arguments. Here are the rules: you have to say either `git diff HEAD --` or `git diff -- HEAD` to disambiguate. + * Many commands allow wildcards in paths, but you need to protect +them from getting globbed by the shell. These two mean different things: ++ + +$ git checkout -- *.c +$ git checkout -- \*.c + ++ +The former lets your shell expand the fileglob, and you are asking +the dot-C files in your working tree to be overwritten with the version +in the index. The latter passes the `*.c` to Git, and you are asking +the paths in the index that match the pattern to be checked out to your +working tree. After running `git add hello.c; rm hello.c`, you will _not_ +see `hello.c` in your working tree with the former, but with the latter +you will. + When writing a script that is expected to handle random user-input, it is a good practice to make it explicit which arguments are which by placing disambiguating `--` at appropriate places. -- 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
Re: [PATCH 1/2] advice: extract function to print messages with prefix
Ralf Thielow ralf.thie...@gmail.com writes: On Fri, Sep 7, 2012 at 9:32 PM, Junio C Hamano gits...@pobox.com wrote: - fprintf(stderr, _(hint: %.*s\n), (int)(np - cp), cp); + fprintf(stderr, %s %.*s\n, prefix, (int)(np - cp), cp); Hrm, naively, printf(%s: %.*s\n, _(hint), ...) might look more natural, but I vaguely recall that the current code places _() around the entire hint: %.*s\n on purpose. IIRC, it was to allow translations that flow from RTL e.g. .siht od t'nod :tnih. Doesn't this patch break it? Sorry but I don't know what you mean with translations that flow from RTL e.g. .siht od t'nod :tnih. so I can't check this. As far as I can see the callers only put a simple message in it, e.g. advise(_(Commit your changes or stash them to proceed.)); So I don't think that this patch would break anything. Your patch would not allow target languages that want to put the _(hint) at the *tail* end of each line of the message. With the original, with something like this: msgid hint: %.*s\n msgstr %.*s :tnih\n you could do that if you wanted to. -- 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
Re: [PATCH 1/2] advice: extract function to print messages with prefix
On Fri, Sep 7, 2012 at 10:52 PM, Junio C Hamano gits...@pobox.com wrote: Ralf Thielow ralf.thie...@gmail.com writes: On Fri, Sep 7, 2012 at 9:32 PM, Junio C Hamano gits...@pobox.com wrote: - fprintf(stderr, _(hint: %.*s\n), (int)(np - cp), cp); + fprintf(stderr, %s %.*s\n, prefix, (int)(np - cp), cp); Hrm, naively, printf(%s: %.*s\n, _(hint), ...) might look more natural, but I vaguely recall that the current code places _() around the entire hint: %.*s\n on purpose. IIRC, it was to allow translations that flow from RTL e.g. .siht od t'nod :tnih. Doesn't this patch break it? Sorry but I don't know what you mean with translations that flow from RTL e.g. .siht od t'nod :tnih. so I can't check this. As far as I can see the callers only put a simple message in it, e.g. advise(_(Commit your changes or stash them to proceed.)); So I don't think that this patch would break anything. Your patch would not allow target languages that want to put the _(hint) at the *tail* end of each line of the message. With the original, with something like this: msgid hint: %.*s\n msgstr %.*s :tnih\n you could do that if you wanted to. Is there a need actually? It's easy to add a _(...) around this string, but then we'll have a msgid in git.pot without ever having a sensible translation. Not? -- 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
Re: [PATCH 1/2] advice: extract function to print messages with prefix
Ralf Thielow ralf.thie...@gmail.com writes: On Fri, Sep 7, 2012 at 10:52 PM, Junio C Hamano gits...@pobox.com wrote: Ralf Thielow ralf.thie...@gmail.com writes: On Fri, Sep 7, 2012 at 9:32 PM, Junio C Hamano gits...@pobox.com wrote: - fprintf(stderr, _(hint: %.*s\n), (int)(np - cp), cp); + fprintf(stderr, %s %.*s\n, prefix, (int)(np - cp), cp); Hrm, naively, printf(%s: %.*s\n, _(hint), ...) might look more natural, but I vaguely recall that the current code places _() around the entire hint: %.*s\n on purpose. IIRC, it was to allow translations that flow from RTL e.g. .siht od t'nod :tnih. Doesn't this patch break it? Sorry but I don't know what you mean with translations that flow from RTL e.g. .siht od t'nod :tnih. so I can't check this. As far as I can see the callers only put a simple message in it, e.g. advise(_(Commit your changes or stash them to proceed.)); So I don't think that this patch would break anything. Your patch would not allow target languages that want to put the _(hint) at the *tail* end of each line of the message. With the original, with something like this: msgid hint: %.*s\n msgstr %.*s :tnih\n you could do that if you wanted to. Is there a need actually? It's easy to add a _(...) around this string, but then we'll have a msgid in git.pot without ever having a sensible translation. Not? As I said vaguely recall, even though I don't have a first-hand experience in such a language, I know I was talked into doing it this way when we did 23cb5bf (i18n of multi-line advice messages, 2011-12-22). Could you dig around the list archive to see? -- 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
Re: [PATCH 1/2] advice: extract function to print messages with prefix
Junio C Hamano gits...@pobox.com writes: experience in such a language, I know I was talked into doing it this way when we did 23cb5bf (i18n of multi-line advice messages, 2011-12-22). Could you dig around the list archive to see? Heh, don't bother. Instead, start reading from here: http://thread.gmane.org/gmane.comp.version-control.git/187592/focus=187601 and learn what happened to the topic by going forward, or why it was done that way by going backwards. 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
Re: Binary file-friendly merge -Xours or -Xtheirs?
Stephen Bash b...@genarts.com writes:
From reading the docs it's obvious the current -Xours and -Xtheirs
expect to work on hunks, so I (mostly) understand the current
behavior, but as a user it feels like I'm telling you how to
resolve conflicts, please do the same thing for binary files.
Even though merge-recursive accepts -Xours/-Xtheirs, I do not think
the low-level merge machinery for anything but the text merge is
aware of the option.
It may be just the matter of something like this, though (completely
untested).
ll-merge.c | 25 -
1 file changed, 20 insertions(+), 5 deletions(-)
diff --git i/ll-merge.c w/ll-merge.c
index f3f7692..fee578f 100644
--- i/ll-merge.c
+++ w/ll-merge.c
@@ -46,16 +46,31 @@ static int ll_binary_merge(const struct ll_merge_driver
*drv_unused,
assert(opts);
/*
-* The tentative merge result is ours for the final round,
-* or common ancestor for an internal merge. Still return
-* conflicted merge status.
+* The tentative merge result is the or common ancestor for an internal
merge.
*/
- stolen = opts-virtual_ancestor ? orig : src1;
+ if (opts-virtual_ancestor) {
+ stolen = orig;
+ } else {
+ switch (opts-variant) {
+ default:
+ case XDL_MERGE_FAVOR_OURS:
+ stolen = src1;
+ break;
+ case XDL_MERGE_FAVOR_THEIRS:
+ stolen = src2;
+ break;
+ }
+ }
result-ptr = stolen-ptr;
result-size = stolen-size;
stolen-ptr = NULL;
- return 1;
+
+ /*
+* With -Xtheirs or -Xours, we have cleanly merged;
+* otherwise we got a conflict.
+*/
+ return (opts-variant ? 0 : 1);
}
static int ll_xdl_merge(const struct ll_merge_driver *drv_unused,
--
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
Re: help doing a hotfix bisect: cherry-pick -m ??
On Fri, Sep 7, 2012 at 1:27 PM, Junio C Hamano gits...@pobox.com wrote: Jim Cromie jim.cro...@gmail.com writes: Broader question: Im thinking that having a hotfix branch, and merging --no-commit would work better, especially when bisection lands on a commit which already contains some of those in the hotfix branch. When your history leading to the bad commit contains only part of the hot-fix branch and not all of it, that may work better. good, I have a 1/2 grip at least. thank you. any tips on how to use the -m option ? Ive had no success passing small integers, and I need to include the commits from the merged branch The only alternative I have is to rework the split *_deferred patch on top of the merge-point, and hope that it tests ok with the original hotfix patch, then I can probably do the bisect. -- 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
Re: Encrypted repositories
Well, everybody can access the objects, but they're encrypted, so you need the repo key (which, of course isn't contained in the repo itself ;-p) to decrypt them. So, in short, blobs are not encrypted with the hash of their contents as encryption keys at all. No, the blobs are encrypted with their content hash as key, and the encrypted blob will be stored with it's content hash as object id. For the usecases I have in mind (backups, filesharing, etc) this wouldn't hurt so much, if the objects are compressed before encryption. For that kind of usage pattern, you are better off looking at encrypted tarballs or zip archives. No, that doesn't give us anything like history, incremental synchronization, etc, etc. What I finnaly wanna has is a usual git, just with encryption, but I can live with loosing differential compression. cu -- Mit freundlichen Grüßen / Kind regards Enrico Weigelt VNC - Virtual Network Consult GmbH Head Of Development Pariser Platz 4a, D-10117 Berlin Tel.: +49 (30) 3464615-20 Fax: +49 (30) 3464615-59 enrico.weig...@vnc.biz; www.vnc.de -- 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
Re: Encrypted repositories
On Fri, Sep 7, 2012 at 8:34 PM, Enrico Weigelt enrico.weig...@vnc.biz wrote: Well, everybody can access the objects, but they're encrypted, so you need the repo key (which, of course isn't contained in the repo itself ;-p) to decrypt them. So, in short, blobs are not encrypted with the hash of their contents as encryption keys at all. No, the blobs are encrypted with their content hash as key, and the encrypted blob will be stored with it's content hash as object id. For the usecases I have in mind (backups, filesharing, etc) this wouldn't hurt so much, if the objects are compressed before encryption. For that kind of usage pattern, you are better off looking at encrypted tarballs or zip archives. No, that doesn't give us anything like history, incremental synchronization, etc, etc. What I finnaly wanna has is a usual git, just with encryption, but I can live with loosing differential compression. Something like this? https://gist.github.com/873637 I've never tried it myself, who knows if it works, but google found it when I searched for git clean smudge filter encryption. I hope that helps, -- David -- 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
Re: What's cooking in git.git (Sep 2012, #02; Fri, 7)
On 07.09.12 23:55, Junio C Hamano wrote: [Discarded] * jc/sanitize-nkd-lazy-iconv-open (2012-07-31) 1 commit . macos: lazily initialize iconv Teach the code that works around NKD/NKC gotcha on MacOS to call iconv_open() only when it is necessary, in the hope of avoiding set-up overhead. It turns out that there was no noticeable improvements. My vote is not to discard the branch: Even if the improvements are not measurable, the lazy iconv_open is a good coding style. It might inspire people to use resources carefully, and only allocate them if they are really needed. -- 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
