Re: [PATCH v3 00/26] inotify support
On 03.02.14 05:28, Nguyễn Thái Ngọc Duy wrote:
I managed to review the code 0..12/26, so some parts are missing.
The list below became longer than what I intended,
my comments may be hard to read,
and there is a mixture of minor and major remarks.
I would appreciate if we could have an outline of the protocol
as a seperate document somewhere, to be able to have a look at the protocol
first, before looking into the code.
(Am I using wireshark too much to dream about a dissector ?)
All in all I like the concept, thanks for the work.
1)
write_in_full_timeout()
packet_read_line_timeout()
At other places we handle EINTR after calling poll().
Looking at the code, it could be easier to introduce
a new function xpoll() in wrapper.c, and use that instead
of poll().
2)
Similar for the usage of accept().
I like the idea of xread() xwrite() and all the x functions
so it coud make sense to establish xpoll() and xaccept()
before inotify suppport.
3)
-int unix_stream_listen(const char *path)
+int unix_stream_listen(const char *path, int replace)
{
int fd, saved_errno;
struct sockaddr_un sa;
@@ -103,7 +103,8 @@ int unix_stream_listen(const char *path)
return -1;
fd = unix_stream_socket();
- unlink(path);
+ if (replace)
+ unlink(path);
Minor remark:
As we do not do the replace here:
s/replace/un_link/ may be ?
4)
+++ b/file-watcher.c
{}
+static const char *const file_watcher_usage[] = {
+ N_(git file-watcher [options] socket directory),
+ NULL
+};
Do we already have options here?
I can think about having
-d daemoniye
-u uses Unix doain socket
(And later -t to use a TCP/IP socket, when the repo
is on a mounted NFS (or SAMBA) drive, and the daemon is on a
different machine.
I don't say this patch should include this logic in first round,
But I can see a gain for this kind of setup)
5)
+++ b/file-watcher.c
[]
+static int shutdown_connection(int id)
+{
+ struct connection *conn = conns[id];
+ conns[id] = NULL;
+ pfd[id].fd = -1;
+ if (!conn)
+ return 0;
+ close(conn-sock);
+ free(conn);
+ return 0;
+}
The function is called shutdown_connection(), but it does a close()
Could it be named close_connection() ?
6)
+++ b/file-watcher.c
[]
Do we have a sequence chart about the command flow between the watcher
daemon and the client ?
7)
in 03/26:
This version is also gentler than its friend packet_read_line()
gentler, what does this mean?
because it's designed for side channel I/O that should not abort the
program even if the channel is broken.
I'm not so familar with side-channel I/O. How does it fit in here?
Does this make sense:
In opposite to packet_read_line() which can call die()
to abort the program, read_in_full_timeout() will keep the program running.
(or something like this)
Signed-off-by: Nguyễn Thái Ngọc Duy pclo...@gmail.com
---
cache.h| 1 +
pkt-line.c | 35 +++
pkt-line.h | 1 +
wrapper.c | 21 +
4 files changed, 58 insertions(+)
diff --git a/cache.h b/cache.h
index 718e32b..939db46 100644
--- a/cache.h
+++ b/cache.h
@@ -1230,6 +1230,7 @@ extern int write_or_whine_pipe(int fd, const void *buf,
size_t count, const char
extern void fsync_or_die(int fd, const char *);
extern ssize_t read_in_full(int fd, void *buf, size_t count);
+extern ssize_t read_in_full_timeout(int fd, void *buf, size_t count, int
timeout);
extern ssize_t write_in_full(int fd, const void *buf, size_t count);
extern ssize_t write_in_full_timeout(int fd, const void *buf, size_t count,
int timeout);
static inline ssize_t write_str_in_full(int fd, const char *str)
diff --git a/pkt-line.c b/pkt-line.c
index cf681e9..5a07e97 100644
--- a/pkt-line.c
+++ b/pkt-line.c
@@ -229,3 +229,38 @@ char *packet_read_line_buf(char **src, size_t *src_len,
int *dst_len)
{
return packet_read_line_generic(-1, src, src_len, dst_len);
}
+
In what is the timeout measured ?
seconds, milli years?
As we use poll() I think it is milli seconds.
(I like the idea of naming timeout timeout_ms)
[]
+ len -= 4;
+ if (len = buf_len) {
+ error(protocol error: bad line length %d, len);
+ return NULL;
+ }
+ if ((ret = read_in_full_timeout(fd, buf, len, timeout)) 0)
+ return NULL;
Do we want a packet_trace here?
When a timeout occurs, do we want to close the connection,
marking it as dead?
Or need to look at errno?
+ buf[len] = '\0';
+ if (len_p)
+ *len_p = len;
+ packet_trace(buf, len, 0);
+ return buf;
+}
diff --git a/pkt-line.h b/pkt-line.h
index 4b93a0c..d47dca5 100644
--- a/pkt-line.h
+++ b/pkt-line.h
@@ -69,6 +69,7 @@ int packet_read(int fd, char **src_buffer, size_t *src_len,
char
* packet is written to it.
*/
char *packet_read_line(int fd, int *size);
+char *packet_read_line_timeout(int fd, int timeout, int
[PATCH 0/2] Ignore trailing spaces in .gitignore
Trailing spaces are invisible in most standard editors (*). git diff does show trailing spaces by default. But that does not help newly written .gitignore files. And trailing spaces are the source of frustration when writing .gitignore. So let's ignore them. Nobody sane would put a trailing space in file names. But we could be careful and do it in two steps: warn first, then ignore trailing spaces. Another option is merge two patches in one and be done with it. People can still quote trailing spaces, which will not be ignored (and much more visible). Quoting comes with a cost of doing fnmatch(). But I won't optimize it until I see someone shows me they have a use case for it. (*) either that or my coworkers keep pissing me off on purpose when they never clean trailing spaces. Nguyễn Thái Ngọc Duy (2): dir: warn about trailing spaces in exclude pattern dir: ignore trailing spaces in exclude patterns Documentation/gitignore.txt | 3 +++ dir.c | 9 + 2 files changed, 12 insertions(+) -- 1.8.5.2.240.g8478abd -- 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] dir: warn about trailing spaces in exclude pattern
Signed-off-by: Nguyễn Thái Ngọc Duy pclo...@gmail.com
---
dir.c | 11 +++
1 file changed, 11 insertions(+)
diff --git a/dir.c b/dir.c
index b35b633..9edde44 100644
--- a/dir.c
+++ b/dir.c
@@ -491,6 +491,16 @@ void clear_exclude_list(struct exclude_list *el)
el-filebuf = NULL;
}
+static void check_trailing_spaces(const char *fname, char *buf)
+{
+ int len = strlen(buf);
+ while (len buf[len - 1] == ' ')
+ len--;
+ if (buf[len] != '\0')
+ warning(_(%s: trailing spaces in '%s'. Please quote them.),
+ fname, buf);
+}
+
int add_excludes_from_file_to_list(const char *fname,
const char *base,
int baselen,
@@ -542,6 +552,7 @@ int add_excludes_from_file_to_list(const char *fname,
if (buf[i] == '\n') {
if (entry != buf + i entry[0] != '#') {
buf[i - (i buf[i-1] == '\r')] = 0;
+ check_trailing_spaces(fname, entry);
add_exclude(entry, base, baselen, el, lineno);
}
lineno++;
--
1.8.5.2.240.g8478abd
--
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] dir: ignore trailing spaces in exclude patterns
Signed-off-by: Nguyễn Thái Ngọc Duy pclo...@gmail.com --- Documentation/gitignore.txt | 3 +++ dir.c | 4 +--- 2 files changed, 4 insertions(+), 3 deletions(-) diff --git a/Documentation/gitignore.txt b/Documentation/gitignore.txt index b08d34d..8734c15 100644 --- a/Documentation/gitignore.txt +++ b/Documentation/gitignore.txt @@ -77,6 +77,9 @@ PATTERN FORMAT Put a backslash (`\`) in front of the first hash for patterns that begin with a hash. + - Trailing spaces are ignored unless they are quoted with backlash + (`\`). + - An optional prefix `!` which negates the pattern; any matching file excluded by a previous pattern will become included again. It is not possible to re-include a file if a parent diff --git a/dir.c b/dir.c index 9edde44..7dee5ca 100644 --- a/dir.c +++ b/dir.c @@ -496,9 +496,7 @@ static void check_trailing_spaces(const char *fname, char *buf) int len = strlen(buf); while (len buf[len - 1] == ' ') len--; - if (buf[len] != '\0') - warning(_(%s: trailing spaces in '%s'. Please quote them.), - fname, buf); + buf[len] = '\0'; } int add_excludes_from_file_to_list(const char *fname, -- 1.8.5.2.240.g8478abd -- 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: git best strategy for two version development
On 02/08/2014 03:56 AM, brian m. carlson wrote: On Sat, Feb 08, 2014 at 02:06:41AM +, Carlos Pereira wrote: Hello, I am a git and CVS newbie, I bought and red most of the excellent Pro Git book by Scott Chacon, but I still have a doubt. I have a package that I distribute in two versions differing only in one library: version_A uses this library, version_B uses my own code to replace it. For strategic reasons I want to keep it this way for the time being. Both versions have the same documentation, the same data files, and 99% of the source code is the same (a few makefile changes, two additional files in version_B and some minor changes: a diff -r has only 170 lines). The question is what is the best strategy to manage a situation like this with git? Shall I maintain two different repositories? I don't think so... Apparently the best solution would be to maintain two long term branches, say mater_A and master_B, and merge all later developments in both branches, keeping the initial difference... Specifically: 1) do some new work in branch master_A, commit, etc. 2) checkout master_B and merge the new work in master_B, without merging the initial diff between the two versions. What is the better way to do that? That's pretty much the way to do it. If you check in master-A, then create the master-B branch off of that, copying in the code from B and checking it in, then when you merge from master-A to master-B, git will basically do the right thing. Changes you make on master-A that are specific to that version will probably conflict, but they should be easy to fix up. You are right! git does not try to merge everything, only changes commited on the other branch (branch-A), after creating branch-B... otherwise it would be reverting the work done on the current branch, which does not make much sense... Thank you very much... C I basically do this for a consulting project for a client: there's generic code in master, and a special branch for the client. Since most changes don't touch the modified code, conflicts are infrequent, and I can fix them up when they occur. I also do it for my dotfiles, which vary slightly between home and work. You could also make the changes to master-B as a set of commits on top of master-A, and always rebase master-B on master-A, but this isn't a good solution if other people are going to be using your code. It has the benefits of keeping the history free of frequent merges, which may or may not be important to you; it doesn't really bother me very much. -- 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 00/26] inotify support
Thanks for the comments. I can see I now have some work to do in the
coming weeks :)
On Sat, Feb 8, 2014 at 3:04 PM, Torsten Bögershausen tbo...@web.de wrote:
I would appreciate if we could have an outline of the protocol
as a seperate document somewhere, to be able to have a look at the protocol
first, before looking into the code.
My fear is document becomes outdated because people don't always
remember to update doc when they change code. Which is why I embed the
protocol as comments in handle_command() function. If the final
version [1] is still not easy to read, I'll split the protocol out
into a separate document.
[1] https://github.com/pclouds/git/blob/file-watcher/file-watcher.c#L672
(Am I using wireshark too much to dream about a dissector ?)
Try GIT_TRACE_PACKET=2
1)
write_in_full_timeout()
packet_read_line_timeout()
At other places we handle EINTR after calling poll().
Looking at the code, it could be easier to introduce
a new function xpoll() in wrapper.c, and use that instead
of poll().
Yeah there are already 4 poll call sites before file-watcher jumps in. Will do.
2)
Similar for the usage of accept().
I like the idea of xread() xwrite() and all the x functions
so it coud make sense to establish xpoll() and xaccept()
before inotify suppport.
OK
3)
-int unix_stream_listen(const char *path)
+int unix_stream_listen(const char *path, int replace)
{
int fd, saved_errno;
struct sockaddr_un sa;
@@ -103,7 +103,8 @@ int unix_stream_listen(const char *path)
return -1;
fd = unix_stream_socket();
- unlink(path);
+ if (replace)
+ unlink(path);
Minor remark:
As we do not do the replace here:
s/replace/un_link/ may be ?
Heh, I thought of using the name unlink but it's taken so I chose
replace and did not think of underscore.Will do.
4)
+++ b/file-watcher.c
{}
+static const char *const file_watcher_usage[] = {
+ N_(git file-watcher [options] socket directory),
+ NULL
+};
Do we already have options here?
I can think about having
-d daemoniye
-u uses Unix doain socket
(And later -t to use a TCP/IP socket, when the repo
is on a mounted NFS (or SAMBA) drive, and the daemon is on a
different machine.
I don't say this patch should include this logic in first round,
But I can see a gain for this kind of setup)
Later on we have two, --detach (i.e. daemonize, I reuse the same name
from git-daemon) and --check-support. Transport settings (like unix vs
tcp/ip...) should be config options though. You don't want to specify
it here, then again when you run git status. Actually I should add
--default, that will retrieve socket directory from config key
filewatcher.path, so the user does not have to specify it..
5)
+++ b/file-watcher.c
[]
+static int shutdown_connection(int id)
+{
+ struct connection *conn = conns[id];
+ conns[id] = NULL;
+ pfd[id].fd = -1;
+ if (!conn)
+ return 0;
+ close(conn-sock);
+ free(conn);
+ return 0;
+}
The function is called shutdown_connection(), but it does a close()
Could it be named close_connection() ?
Yes, there was a close_connection() which did something similar, and
then it was killed off. Will rename.
6)
+++ b/file-watcher.c
[]
Do we have a sequence chart about the command flow between the watcher
daemon and the client ?
I suggest you have a look at the file-watcher test. For example, from
[2] we have this sequence
hello
hello
index $SIG $TRASH_DIRECTORY
inconsistent
# Do not call inotify_add_watch()
test-mode
test mode on
# First batch should be all ok
watch
dir1/foo
dir2/foo
dir3/foo
dir4/foo
...
denotes a packet from the client to file-watcher, the opposite
direction. But you can always obtain a real flow with
GIT_TRACE_PACKET=2 (path lists not available though, so really just a
flow).
[2]
https://github.com/pclouds/git/blob/file-watcher/t/t7513-file-watcher.sh#L273
in 03/26:
This version is also gentler than its friend packet_read_line()
gentler, what does this mean?
No dying for whatever error. packet_read_line is designed for git
protocol. It's the main job so if there's an error, dying is the right
thing to do. file-watcher on the other hand is a side job and should
not stop whatever command from doing. Will update commit message.
because it's designed for side channel I/O that should not abort the
program even if the channel is broken.
I'm not so familar with side-channel I/O. How does it fit in here?
To sum up, whatever error in communication with file-watcher should
not stop you from doing whatever you're doing. file-watcher is
contacted whenever $GIT_DIR/index is read, so whatever you're doing
is basically all git commands that involve worktree or index.
Does this make sense:
In opposite to packet_read_line() which can call die()
to abort the program, read_in_full_timeout() will keep the program running.
(or something like this)
Exactly!
diff
[PATCH] builtin/blame.c::prepare_lines: fix allocation size of sb-lineno
If we are calling xrealloc on every single line, the least we can do
is get the right allocation size.
Signed-off-by: David Kastrup d...@gnu.org
---
This should be less contentious than the patch in
URL:http://permalink.gmane.org/gmane.comp.version-control.git/241561,
Message-ID: 1391550392-17118-1-git-send-email-...@gnu.org as it
makes no stylistic decisions whatsoever and only fixes a clear bug.
builtin/blame.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/builtin/blame.c b/builtin/blame.c
index e44a6bb..29eb31c 100644
--- a/builtin/blame.c
+++ b/builtin/blame.c
@@ -1779,7 +1779,7 @@ static int prepare_lines(struct scoreboard *sb)
while (len--) {
if (bol) {
sb-lineno = xrealloc(sb-lineno,
- sizeof(int *) * (num + 1));
+ sizeof(int) * (num + 1));
sb-lineno[num] = buf - sb-final_buf;
bol = 0;
}
@@ -1789,7 +1789,7 @@ static int prepare_lines(struct scoreboard *sb)
}
}
sb-lineno = xrealloc(sb-lineno,
- sizeof(int *) * (num + incomplete + 1));
+ sizeof(int) * (num + incomplete + 1));
sb-lineno[num + incomplete] = buf - sb-final_buf;
sb-num_lines = num + incomplete;
return sb-num_lines;
--
1.8.3.2
--
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] builtin/blame.c::prepare_lines: fix allocation size of sb-lineno
David Kastrup d...@gnu.org writes:
If we are calling xrealloc on every single line, the least we can do
is get the right allocation size.
Signed-off-by: David Kastrup d...@gnu.org
---
This should be less contentious than the patch in
URL:http://permalink.gmane.org/gmane.comp.version-control.git/241561,
Message-ID: 1391550392-17118-1-git-send-email-...@gnu.org as it
makes no stylistic decisions whatsoever and only fixes a clear bug.
builtin/blame.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/builtin/blame.c b/builtin/blame.c
index e44a6bb..29eb31c 100644
--- a/builtin/blame.c
+++ b/builtin/blame.c
@@ -1779,7 +1779,7 @@ static int prepare_lines(struct scoreboard *sb)
while (len--) {
if (bol) {
sb-lineno = xrealloc(sb-lineno,
- sizeof(int *) * (num + 1));
+ sizeof(int) * (num + 1));
But please note that since sb-lineno originally comes from a zeroed
memory area and is passed to xrealloc, this requires that after
int *p;
memset(p, 0, sizeof(p));
the equivalence
((void *)p == NULL)
will hold. While this is true on most platforms, and while the C
standard guarantees the slightly different
((void *)0 == NULL)
is true, it makes no statement concerning the memory representation of
the NULL pointer.
I have not bothered addressing this non-compliance with the C standard
as it would be polishing a turd. A wholesale replacement has already
been proposed, and it's likely that this assumption is prevalent in the
Git codebase elsewhere anyway.
--
David Kastrup
--
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: git: problematic git status output with some translations (such as fr_FR)
On Fri, Dec 20, 2013 at 3:50 AM, Jonathan Nieder jrnie...@gmail.com wrote: Junio C Hamano wrote: Jonathan Nieder jrnie...@gmail.com writes: This includes the colon in the translated string, to make it easier to remember to keep the non-breaking space before it. Hmph, recent 3651e45c (wt-status: take the alignment burden off translators, 2013-11-05) seems to have gone in the different direction when it updated similar code for the non-unmerged paths. Yes, if this seems to go in the right direction, I'd add a follow-up for that when rerolling. Just checking. Did you reroll it or did my filters move some mails to spam/trash folder again? -- Duy -- 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: git best strategy for two version development
Carlos Pereira jose.carlos.pereira at ist.utl.pt writes: Hello, I am a git and CVS newbie, I bought and red most of the excellent Pro Git book by Scott Chacon, but I still have a doubt. I have a package that I distribute in two versions differing only in one library: version_A uses this library, version_B uses my own code to replace it. For strategic reasons I want to keep it this way for the time being. Both versions have the same documentation, the same data files, and 99% of the source code is the same (a few makefile changes, two additional files in version_B and some minor changes: a diff -r has only 170 lines). The question is what is the best strategy to manage a situation like this with git? Shall I maintain two different repositories? I don't think so... If the changes are as small as you say, is it an option to use just one branch but have two possible build configurations? That seems like the easiest way to do it, in my opinion. E.g.: $ make LIB=versionA $ make LIB=versionB Consider the above as pseudo-code, though. I don't know what build system you use or even if your package is even something that is built. But you get the idea. Øsse -- 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 8/9] rebase: add the --gpg-sign option
On 07/02/14 23:50, brian m. carlson wrote:
On Mon, Feb 03, 2014 at 01:42:06PM -0800, Junio C Hamano wrote:
+ --gpg-sign)
+ gpg_sign_opt=-S
+ ;;
+ --gpg-sign=*)
+ # Try to quote only the argument, as this will appear in
human-readable
+ # output as well as being passed to commands.
+ gpg_sign_opt=-S$(git rev-parse --sq-quote ${1#--gpg-sign=} |
+ sed 's/^ //')
Isn't an invocation of sed excessive?
gpg_sign_opt=$(git rev-parse --sq-quote ${1#--gpg-sign=})
gpg_sign_opt=-S${gpg_sign_opt# }
if you really need to strip the leading SP, which I do not think is
a necessary thing to do. It is sufficient to remove the SP before
the variable substitution in the human-readable messages, e.g.
I'm not sure that command line parsing of -S 'foo x...@example.tld'
will work exactly as expected due to the fact that -S doesn't always
take an argument. Your suggestion to use # seems fine, though.
I'm a little embarrassed to admit that in my fifteen years of Unix
experience, I've never learned the variable modifiers for shell, so it
didn't occur to me to use them in this case. Guess it's time to learn
them now.
Same here:
For other readers, I found most google results were only partial on the
issue, missing the '#' symbol option. Here's a more complete ref
http://www.gnu.org/software/bash/manual/bashref.html#Shell-Parameter-Expansion-1
for fellow learners.
Philip
--
--
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
gitweb.cgi bug
On Thu, Feb 6, 2014 at 7:01 AM, Junio C Hamano gits...@pobox.com wrote: The latest maintenance release Git v1.8.5.4 is now available at the usual places. I have an git repo PROJECT.git, the full path is /srv/repo/git/PROJECT.git, when I set git_base_url_list in gitweb.conf: @git_base_url_list = qw(https://192.168.30.239/repo/git git@192.168.30.239:repo/git); I got the result: https://192.168.30.239/repo/git/PROJECT.git git@192.168.30.239:/PROJECT.git This is wrong, it should be (without the leading '/') git@192.168.30.239:PROJECT.git Regards, Dongsheng -- 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] log: add --show-linear-break to help see non-linear history
Signed-off-by: Nguyễn Thái Ngọc Duy pclo...@gmail.com
---
This is a more serious attempt to make non-linear history more
visible without --graph. It looks like this
commit e4ddb05720710213108cd13ddd5a115e12a6211d
Author: Andy Spencer andy753...@gmail.com
tree_entry_interesting: match against all pathspecs
..
commit a0332337be53f266682279c72a5e553986638c87
Author: Jeff King p...@peff.net
t7700: do not use touch unnecessarily
commit 088304bf73b9b4149e04d2246fe08a06eef6e795
Author: Jeff King p...@peff.net
t7501: fix empty commit test with NO_PERL
..
commit 74b4f7f27736f3e196a4eb3db41c68e37a6e2160
Author: Nguyễn Thái Ngọc Duy pclo...@gmail.com
tree-walk.c: ignore trailing slash on submodule in
tree_entry_interesting()
You can use fancier break bars from [1] instead of plain dots. I'm
not sure it works with all combinations of rev-list. But at least
log (with/out pathspec) and log --reverse work.
[1] http://www.ascii-art.de/ascii/ab/border.txt
Documentation/rev-list-options.txt | 7 +
log-tree.c | 4 +++
revision.c | 52 +++---
revision.h | 6 +
4 files changed, 66 insertions(+), 3 deletions(-)
diff --git a/Documentation/rev-list-options.txt
b/Documentation/rev-list-options.txt
index 03533af..a0780be 100644
--- a/Documentation/rev-list-options.txt
+++ b/Documentation/rev-list-options.txt
@@ -750,6 +750,13 @@ This enables parent rewriting, see 'History
Simplification' below.
This implies the `--topo-order` option by default, but the
`--date-order` option may also be specified.
+--show-linear-break[=break bar]::
+ When --graph is not used, all history branches are flatten and
+ could be hard to see that the two consecutive commits do not
+ belong to a linear branch. This option puts a break bar in
+ between them in that case. If `break bar` is specified, it
+ is the string that will be shown instead of the default one.
+
ifdef::git-rev-list[]
--count::
Print a number stating how many commits would have been
diff --git a/log-tree.c b/log-tree.c
index 08970bf..17862f6 100644
--- a/log-tree.c
+++ b/log-tree.c
@@ -805,12 +805,16 @@ int log_tree_commit(struct rev_info *opt, struct commit
*commit)
if (opt-line_level_traverse)
return line_log_print(opt, commit);
+ if (opt-track_linear !opt-linear !opt-reverse_output_stage)
+ printf(\n%s\n, opt-break_bar);
shown = log_tree_diff(opt, commit, log);
if (!shown opt-loginfo opt-always_show_header) {
log.parent = NULL;
show_log(opt);
shown = 1;
}
+ if (opt-track_linear !opt-linear opt-reverse_output_stage)
+ printf(\n%s\n, opt-break_bar);
opt-loginfo = NULL;
maybe_flush_or_die(stdout, stdout);
return shown;
diff --git a/revision.c b/revision.c
index a0df72f..ff3107f 100644
--- a/revision.c
+++ b/revision.c
@@ -1836,6 +1836,12 @@ static int handle_revision_opt(struct rev_info *revs,
int argc, const char **arg
revs-notes_opt.use_default_notes = 1;
} else if (!strcmp(arg, --show-signature)) {
revs-show_signature = 1;
+ } else if (!strcmp(arg, --show-linear-break)) {
+ revs-track_linear = 1;
+ revs-break_bar = ..;
+ } else if (starts_with(arg, --show-linear-break=)) {
+ revs-track_linear = 1;
+ revs-break_bar = xstrdup(arg + 20);
} else if (starts_with(arg, --show-notes=) ||
starts_with(arg, --notes=)) {
struct strbuf buf = STRBUF_INIT;
@@ -2901,6 +2907,32 @@ enum commit_action simplify_commit(struct rev_info
*revs, struct commit *commit)
return action;
}
+define_commit_slab(saved_linear, int);
+
+static void track_linear(struct rev_info *revs, struct commit *commit)
+{
+ struct commit_list *p = revs-previous_parents;
+
+ if (p) {
+ int got_parent = 0;
+ for (; p !got_parent; p = p-next)
+ got_parent = !hashcmp(p-item-object.sha1,
+ commit-object.sha1);
+ revs-linear = got_parent;
+ free_commit_list(revs-previous_parents);
+ } else
+ revs-linear = 1;
+ if (revs-reverse) {
+ if (!revs-saved_linear_slab) {
+ revs-saved_linear_slab = xmalloc(sizeof(struct
saved_linear));
+ init_saved_linear(revs-saved_linear_slab);
+ }
+
+ *saved_linear_at(revs-saved_linear_slab, commit) =
revs-linear;
+ }
+ revs-previous_parents =
Re: [PATCH 1/2] dir: warn about trailing spaces in exclude pattern
On 2014-02-08 09.10, Nguyễn Thái Ngọc Duy wrote:
Signed-off-by: Nguyễn Thái Ngọc Duy pclo...@gmail.com
---
dir.c | 11 +++
1 file changed, 11 insertions(+)
diff --git a/dir.c b/dir.c
index b35b633..9edde44 100644
--- a/dir.c
+++ b/dir.c
@@ -491,6 +491,16 @@ void clear_exclude_list(struct exclude_list *el)
el-filebuf = NULL;
}
+static void check_trailing_spaces(const char *fname, char *buf)
+{
+ int len = strlen(buf);
+ while (len buf[len - 1] == ' ')
+ len--;
+ if (buf[len] != '\0')
Do we need the while loop here, (when we only warn) ?
+ warning(_(%s: trailing spaces in '%s'. Please quote them.),
+ fname, buf);
+}
This is nice. However we can hint the user that there are 2 choices:
warning(_(%s: trailing spaces in '%s'. Please remove them or
quote them.),
+
int add_excludes_from_file_to_list(const char *fname,
const char *base,
int baselen,
@@ -542,6 +552,7 @@ int add_excludes_from_file_to_list(const char *fname,
if (buf[i] == '\n') {
if (entry != buf + i entry[0] != '#') {
buf[i - (i buf[i-1] == '\r')] = 0;
+ check_trailing_spaces(fname, entry);
add_exclude(entry, base, baselen, el, lineno);
}
lineno++;
--
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: gitweb.cgi bug
On Feb 8, 2014, at 8:37 AM, Dongsheng Song wrote: I have an git repo PROJECT.git, the full path is /srv/repo/git/PROJECT.git, when I set git_base_url_list in gitweb.conf: @git_base_url_list = qw(https://192.168.30.239/repo/git git@192.168.30.239:repo/git); I got the result: https://192.168.30.239/repo/git/PROJECT.git git@192.168.30.239:/PROJECT.git This is wrong, it should be (without the leading '/') git@192.168.30.239:PROJECT.git There is no way to generate a fetch url of 'git@192.168.30.239:PROJECT.git' in gitweb. If one of the base urls was 'git@192.168.30.239:.', then you could get a fetch URL of 'git@192.168.30.239:./PROJECT.git' In general, though, I like to stay away from relative paths. Weird things can happen, like HTTP works but SSH doesn't, because the home directory for SSH changed because you used a different user. - Andrew -- 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/2] Ignore trailing spaces in .gitignore
On Sat, Feb 08, 2014 at 03:10:02PM +0700, Nguyễn Thái Ngọc Duy wrote:
Trailing spaces are invisible in most standard editors (*). git diff
does show trailing spaces by default. But that does not help newly
written .gitignore files. And trailing spaces are the source of
frustration when writing .gitignore.
I guess leading spaces are not as frustrating, but I wonder if it would
be more consistent to say that we soak up all whitespace. That is also a
regression, but I agree that these are exceptional cases, and as long as
we provide an out for people to cover them via quoting, ignoring the
whitespace seems like a sane default.
People can still quote trailing spaces, which will not be ignored (and
much more visible). Quoting comes with a cost of doing fnmatch(). But
I won't optimize it until I see someone shows me they have a use case
for it.
I naively expected that:
echo 'trailing\ \ ' .gitignore
would count as quoting, but your patch doesn't handle that. It _does_
seem to work currently (that is, the backslashes go away and we treat it
literally), but I am not sure if that is planned, or simply happens to
work.
I guess by quoting you meant:
echo 'trailing ' .gitignore
Anyway, here are some tests I wrote up while playing with this. They do
not pass with your current patch for the reasons above, but maybe they
will be useful to squash in (either after tweaking the tests, or
tweaking the patch).
diff --git a/t/t0008-ignores.sh b/t/t0008-ignores.sh
index b4d98e6..4dde314 100755
--- a/t/t0008-ignores.sh
+++ b/t/t0008-ignores.sh
@@ -775,4 +775,33 @@ test_expect_success PIPE 'streaming support for --stdin' '
echo $response | grep ^::two
'
+
+#
+# test whitespace handling
+
+test_expect_success 'leading/trailing whitespace is ignored' '
+ mkdir whitespace
+ whitespace/leading
+ whitespace/trailing
+ whitespace/untracked
+ {
+ echo whitespace/leading
+ echo whitespace/trailing
+ } ignore
+ echo whitespace/untracked expect
+ git ls-files -o -X ignore whitespace actual
+ test_cmp expect actual
+'
+
+test_expect_success 'quoting allows trailing whitespace' '
+ rm -rf whitespace
+ mkdir whitespace
+ whitespace/trailing
+ whitespace/untracked
+ echo whitespace/trailing\\ \\ ignore
+ echo whitespace/untracked expect
+ git ls-files -o -X ignore whitespace actual
+ test_cmp expect actual
+'
+
test_done
--
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: Bug tracker (again)
On Sat, Feb 08, 2014 at 02:26:57PM +0700, Duy Nguyen wrote: So I wonder if we use debian bug tracker for git upstream. I haven't used debian tracker much (or debian for that matter). It's probably best just ask instead of searching and guessing. I suppose if debian people (mostly debian git maintainer?) are not opposed to us using their tracker for upstream bugs, then it's just a matter of associating a mail thread with a bug number for tracking. That could be probably be done via email, then reply all to the thread in question with a bug email address. After that all email discussions are also tracked via this bug email. Anybody can help track bugs. Say if 3 weekdays are over and nobody said a thing about something that looks a lot like bug, then it should be tracked (problems that can be quickly fixed do not need tracking). Hmm? All interaction with the Debian BTS (except for viewing bugs) is done over email. That's what I like about it. It will automatically insert an appropriate piece in the subject line (Bug#1393:) and anyone can mail the control bot to manipulate a bug. It also has the concept of usertags, so you can create your own set of tags with user git@vger.kernel.org (or your personal address, if you desire), and then sort and display bugs appropriately. Junio seemed lukewarm on the idea of using a bug tracker; however, I think debbugs (either the Debian BTS or a separate instance) is probably the best-suited to an email-based workflow of all the systems I've used. Of course, it's up to the regulars (and probably ultimately Junio) whether this is something that Git as a project would benefit from. -- brian m. carlson / brian with sandals: Houston, Texas, US +1 832 623 2791 | http://www.crustytoothpaste.net/~bmc | My opinion only OpenPGP: RSA v4 4096b: 88AC E9B2 9196 305B A994 7552 F1BA 225C 0223 B187 signature.asc Description: Digital signature
Re: [PATCH] l10n: de.po: translate 27 new messages
I see you are defining new glossary terms: shallow unvollständig grafted gesondert eingehängt I guess the first one is reasonable if we don't call anything incomplete? (I don't think we do, just checking.) I don't really like 'gesondert eingehängt', how about 'transplantiert' instead? Or just say graft=Graft and use 'mit Grafts' or some similar workaround, since it is a highly specialized term. Ralf Thielow ralf.thie...@gmail.com writes: #: diff.c:113 #, c-format @@ -975,21 +975,23 @@ msgid There is nothing to exclude from by :(exclude) patterns.\n Perhaps you forgot to add either ':/' or '.' ? msgstr +Es gibt nichts, was durch :(exclude) Muster ausgeschlossen wird.\n +Vielleicht haben Sie vergessen entweder ':/' oder '.' hinzuzufügen? Doesn't sound right -- the original seems to describe the situation where you are using :(exclude) without any non-excluded paths, whereas the German first sentence sounds like you are using :(exclude) when it doesn't match any paths. Perhaps it works if translated very liberally: :(exclude) Muster, aber keine anderen Pfadspezifikationen angegeben.\n Vielleicht haben Sie vergessen entweder ':/' oder '.' hinzuzufügen? #: remote.c:753 -#, fuzzy, c-format +#, c-format msgid Cannot fetch both %s and %s to %s -msgstr Kann keine Commit-Beschreibung für %s bekommen +msgstr Kann 'fetch' nicht für %s und %s nach %s ausführen. [...] #: remote.c:761 #, c-format msgid %s tracks both %s and %s -msgstr +msgstr %s folgt %s und %s In both of these the key point is both. Perhaps use sowohl... als auch. #: wt-status.c:275 -#, fuzzy msgid new file -msgstr neue Datei: %s +msgstr neue Datei: [...] #: wt-status.c:285 -#, fuzzy msgid typechange -msgstr Typänderung: %s +msgstr Typänderung: #: wt-status.c:287 -#, fuzzy msgid unknown -msgstr unbekannt:%s +msgstr unbekannt: Do we still need the trailing colon? -- Thomas Rast t...@thomasrast.ch -- 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: [RFH] hackday and GSoC topic suggestions
Jeff King p...@peff.net writes: On a similar note, the GSoC application deadline is Feb 14th. I am happy to be admin again and put together the application, but we will need an idea page. I'll set up a page to collect them, but in the meantime, please dump any ideas/discussion in this thread. Sorry for being so procrastinative :-( I suggest we make it a rule that old projects cannot be proposed from year to year. -- Thomas Rast t...@thomasrast.ch -- 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: [RFH] hackday and GSoC topic suggestions
On Sat, Feb 08, 2014 at 07:43:40PM +0100, Thomas Rast wrote: Jeff King p...@peff.net writes: On a similar note, the GSoC application deadline is Feb 14th. I am happy to be admin again and put together the application, but we will need an idea page. I'll set up a page to collect them, but in the meantime, please dump any ideas/discussion in this thread. Sorry for being so procrastinative :-( I suggest we make it a rule that old projects cannot be proposed from year to year. I would very much agree with that. There are projects that I have posted multiple years, and nobody ever selects them. I should take that as a hint that they are not appealing to students for whatever reason, and are probably just clogging up the ideas list. I'd make an exception for somebody who wants to substantially rework the proposal in an attempt to make it more appealing, or who has a reason why it is being re-proposed (e.g., we had student interest, but we ended up not selecting it due to running out of slots or something). But those should be the exception. -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
Re: [PATCH] l10n: de.po: translate 27 new messages
Thomas Rast t...@thomasrast.ch writes: I see you are defining new glossary terms: shallow unvollständig grafted gesondert eingehängt I guess the first one is reasonable if we don't call anything incomplete? (I don't think we do, just checking.) oberflächlich seems better: a shallow clone is not incomplete: the cloning process ran to completion. I don't really like 'gesondert eingehängt', how about 'transplantiert' instead? I suggest using the actual translation here as it is perfectly fitting for both literal and figurative meaning: aufgepfropft. -- David Kastrup -- 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: [RFH] hackday and GSoC topic suggestions
Jeff King p...@peff.net writes:
Below is a list of features / bugs that I am taking to the hackday.
I have the list below at
https://github.com/trast/git/wiki/Todo-items
(started at git-merge last year). I did a quick triage, but don't take
my word for it. Perhaps it's not too late for your hackathon yet ;-)
Some items may have been fixed by other people when I wasn't looking, so
first check if the problem still exists. The ones I knew are done I
moved to the bottom.
Easy:
* Add -p 'e' when it fails to apply should offer an obvious way of
starting from the original hunk (not the broken one) or both
* filter-branch should apply {tree,index}-filter to HEAD and complain if
it's not invariant (cf. BFG)
* git-config should follow symlinks when rewriting the file, so as to
avoid replacing a symlink at ~/.gitconfig with the actual contents
* git-send-email should complain when given an option --cc= (i.e., --cc
with empty argument) instead of silently not using any address
there. It's easy to accidentally cause this in combination with
$()-expanding a script that searches for the address by name when
there are no matches. Note that the cccmd feature should not error if
it doesn't come up with anything!
Medium difficulty:
* LC_CTYPE=C to work around an old issue in glibc that has since been
fixed (ask jrn). We should autodetect if we still need the fix, and
otherwise avoid it; it causes trouble with localized messages
* rebase -i --exec should be able to work elsewhere so you can continue
doing useful work
* git-send-email could build smarter reference lists if it had
strategies to fetch the in-reply-to email. One obvious, and very
useful for git and linux, strategy to do so would be to append the
References header of the mail obtained from
http://mid.gmane.org/$in_reply_to (follow the 403 and then append /raw
to get the headers).
* git-svn should have a diff subcommand, to match svn's output for
feeding into tools that need the precise format with 'Index:' lines
* Resurrect the move of config var descriptions onto the separate pages
for commands
Hard or unknown difficulty:
* Add -p 's' followed by 'e' fails to apply even a no-op edit if the
context is small
* git-bisect appears to test a linear number of merge bases, thus
ruining its usually log(n) complexity, in cases involving 'git bisect
good origin/next', 'git bisect bad origin/pu', in git.git
* I have a script git-pie which runs 'perl -i -pe' as follows:
#!/bin/sh
cmd=$1
shift
git ls-files -z $@ |
xargs -0 perl -i -pe $cmd
The prompt display (__git_ps1) in the prompt immediately after using
'git pie ...' always shows that there are no uncommitted changes, even
if that is not correct. Hitting RET again yields a correct status.
Already underway or done (only here so people don't say but you dropped
this from the wiki list):
* In-core merge: a clean merge should be able to work fully in memory,
esp. without any worktree
* For the issue of what did the evil merge do, should try to flatten
out the conflicted merge (i.e. mechanically re-merge, and scrap the
conflicted state in favor of conflict hunks in stage 0) and diff that
against the merge result. if that works out, store the tree as a note
somewhere for caching; git-notes should be able to handle that
* For the last point: need a way of storing trees as
notes. Technically the notes infrastructure does not require things
to be blobs, but in practice all the frontends we have error out, or
do worse things, when handed a tree as a note.
* ./t-foo.sh --valgrind should be able to: a) run only a single
specific test under valgrind, using the normal git for the rest; and
b) parallelize over (a) so as to speed up a complete ./t-foo.sh
--valgrind run
--
Thomas Rast
t...@thomasrast.ch
--
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] l10n: de.po: translate 27 new messages
David Kastrup d...@gnu.org writes: Thomas Rast t...@thomasrast.ch writes: I don't really like 'gesondert eingehängt', how about 'transplantiert' instead? I suggest using the actual translation here as it is perfectly fitting for both literal and figurative meaning: aufgepfropft. I didn't pick that one from the dictionary's suggestions because I cannot remember ever using its original meaning. Perhaps I am moving in the wrong circles? ;-) However Ralf pointed out on IRC that we actually have this already: #: builtin/pack-objects.c:2508 msgid do not hide commits by grafts msgstr verbirgt keine Commits mit künstlichen Vorgängern (\grafts\) So it makes more sense to stick to that translation. -- Thomas Rast t...@thomasrast.ch -- 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] l10n: de.po: translate 27 new messages
Thomas Rast t...@thomasrast.ch writes: David Kastrup d...@gnu.org writes: Thomas Rast t...@thomasrast.ch writes: I don't really like 'gesondert eingehängt', how about 'transplantiert' instead? I suggest using the actual translation here as it is perfectly fitting for both literal and figurative meaning: aufgepfropft. I didn't pick that one from the dictionary's suggestions because I cannot remember ever using its original meaning. Perhaps I am moving in the wrong circles? ;-) However Ralf pointed out on IRC that we actually have this already: #: builtin/pack-objects.c:2508 msgid do not hide commits by grafts msgstr verbirgt keine Commits mit künstlichen Vorgängern (\grafts\) So it makes more sense to stick to that translation. verberge keine aufgepfropften Commits seems much more in the spirit of the original terminology. verbirgt keine Commits mit künstlichen Vorgängern is plainly wrong anyway since it is not the commits _with_ grafts which are hidden but rather the commits _provided_ by grafts. -- David Kastrup -- 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 v4] l10n: de.po: translate 28 new messages
Translate 28 new messages came from git.pot update in df49095 (l10n: git.pot: v1.9 round 1 (27 new, 11 removed) and d57b24b (l10n: git.pot: v1.9 round 2 (1 new)). Signed-off-by: Ralf Thielow ralf.thie...@gmail.com --- v4 corrects some translations according to Thomas' review. Thanks for that. With this we also change the translation of shallow which was translated as flach as in flacher Klon. Now we translate it as with Klon/Repository mit unvollständiger Historie. po/de.po | 99 1 file changed, 50 insertions(+), 49 deletions(-) diff --git a/po/de.po b/po/de.po index 7f8aa75..f7c24ce 100644 --- a/po/de.po +++ b/po/de.po @@ -442,9 +442,9 @@ msgstr[0] vor %lu Jahr msgstr[1] vor %lu Jahren #: diffcore-order.c:24 -#, fuzzy, c-format +#, c-format msgid failed to read orderfile '%s' -msgstr Fehler beim Lesen des Objektes '%s'. +msgstr Fehler beim Lesen der Reihenfolgedatei '%s'. #: diff.c:113 #, c-format @@ -975,21 +975,23 @@ msgid There is nothing to exclude from by :(exclude) patterns.\n Perhaps you forgot to add either ':/' or '.' ? msgstr +:(exclude) Muster, aber keine anderen Pfadspezifikationen angegeben.\n +Vielleicht haben Sie vergessen entweder ':/' oder '.' hinzuzufügen? #: remote.c:753 -#, fuzzy, c-format +#, c-format msgid Cannot fetch both %s and %s to %s -msgstr Kann keine Commit-Beschreibung für %s bekommen +msgstr Kann 'fetch' nicht für sowohl %s als auch %s nach %s ausführen. #: remote.c:757 #, c-format msgid %s usually tracks %s, not %s -msgstr +msgstr %s folgt üblicherweise %s, nicht %s #: remote.c:761 #, c-format msgid %s tracks both %s and %s -msgstr +msgstr %s folgt sowohl %s als auch %s #. #. * This last possibility doesn't occur because @@ -997,9 +999,8 @@ msgstr #. * the end of the list. #. #: remote.c:769 -#, fuzzy msgid Internal error -msgstr interner Fehler +msgstr Interner Fehler #: remote.c:1871 #, c-format @@ -1575,33 +1576,28 @@ msgid both modified: msgstr von beiden geändert: #: wt-status.c:275 -#, fuzzy msgid new file -msgstr neue Datei: %s +msgstr neue Datei #: wt-status.c:277 msgid copied -msgstr +msgstr kopiert #: wt-status.c:279 -#, fuzzy msgid deleted msgstr gelöscht #: wt-status.c:285 -#, fuzzy msgid typechange -msgstr Typänderung: %s +msgstr Typänderung #: wt-status.c:287 -#, fuzzy msgid unknown -msgstr unbekannt:%s +msgstr unbekannt #: wt-status.c:289 -#, fuzzy msgid unmerged -msgstr zusammenführen +msgstr nicht zusammengeführt #: wt-status.c:336 msgid new commits, @@ -1633,6 +1629,8 @@ msgid Do not touch the line above.\n Everything below will be removed. msgstr +Ändern Sie nicht die Zeile oberhalb.\n +Alles unterhalb wird entfernt. #: wt-status.c:899 msgid You have unmerged paths. @@ -3963,7 +3961,7 @@ msgstr Tiefe #: builtin/clone.c:93 msgid create a shallow clone of that depth -msgstr erstellt einen flachen Klon mit dieser Tiefe +msgstr erstellt einen Klon mit unvollständiger Historie in dieser Tiefe #: builtin/clone.c:95 msgid clone only one branch, HEAD or --branch @@ -3991,14 +3989,14 @@ msgid reference repository '%s' is not a local repository. msgstr Referenziertes Repository '%s' ist kein lokales Repository. #: builtin/clone.c:256 -#, fuzzy, c-format +#, c-format msgid reference repository '%s' is shallow -msgstr Referenziertes Repository '%s' ist kein lokales Repository. +msgstr Referenziertes Repository '%s' hat eine unvollständige Historie (shallow). #: builtin/clone.c:259 -#, fuzzy, c-format +#, c-format msgid reference repository '%s' is grafted -msgstr referenziert Repository +msgstr Referenziertes Repository '%s' ist mit künstlichen Vorgängern (\grafts\) eingehängt. #: builtin/clone.c:321 #, c-format @@ -4099,16 +4097,17 @@ msgstr #: builtin/clone.c:805 msgid source repository is shallow, ignoring --local -msgstr +msgstr Quelle ist ein Repository mit unvollständiger Historie (shallow), +ignoriere --local #: builtin/clone.c:810 msgid --local is ignored msgstr --local wird ignoriert #: builtin/clone.c:814 builtin/fetch.c:1119 -#, fuzzy, c-format +#, c-format msgid depth %s is not a positive number -msgstr Objekt %s ist kein Blob +msgstr Tiefe %s ist keine positive Zahl #: builtin/clone.c:824 #, c-format @@ -5196,7 +5195,7 @@ msgstr erlaubt Aktualisierung der \HEAD\-Referenz #: builtin/fetch.c:99 msgid deepen history of shallow clone -msgstr vertieft die Historie eines flachen Klons +msgstr vertieft die Historie eines Klons mit unvollständiger Historie #: builtin/fetch.c:101 msgid convert to a complete repository @@ -5215,9 +5214,8 @@ msgid default mode for recursion msgstr Standard-Modus für Rekursion #: builtin/fetch.c:109 -#, fuzzy msgid accept refs that update .git/shallow -msgstr Konnte aktualisierte .gitmodules-Datei nicht lesen +msgstr akzeptiert Referenzen die .git/shallow aktualisieren #: builtin/fetch.c:347 msgid Couldn't find
Re
I wish to discuss a very confidential business proposition with you. -- 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] l10n: de.po: translate 27 new messages
2014-02-08 20:22 GMT+01:00 David Kastrup d...@gnu.org: verberge keine aufgepfropften Commits seems much more in the spirit of the original terminology. verbirgt keine Commits mit künstlichen Vorgängern is plainly wrong anyway since it is not the commits _with_ grafts which are hidden but rather the commits _provided_ by grafts. Maybe verbirgt keine Commits auf Basis künstlicher Vorgänger? -- David Kastrup -- 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] l10n: de.po: translate 27 new messages
Ralf Thielow ralf.thie...@gmail.com writes: 2014-02-08 20:22 GMT+01:00 David Kastrup d...@gnu.org: verberge keine aufgepfropften Commits seems much more in the spirit of the original terminology. verbirgt keine Commits mit künstlichen Vorgängern is plainly wrong anyway since it is not the commits _with_ grafts which are hidden but rather the commits _provided_ by grafts. Maybe verbirgt keine Commits auf Basis künstlicher Vorgänger? No. If at all Verbirgt keine künstlichen Vorgänger or keine künstlichen Vorgängercommits since the künstlicher Vorgänger _is_ the commit that is hidden: the graft, if we are being totally meticulous, is the list of artificial parents for a given commit. The option, when activated, hides those artificial parents. And Do not is not Does not, so Verbirgt seems also wrong as it likely should be Verberge (imperative). But then it would depend on the overall style in which this imperative is usually translated. -- David Kastrup -- 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] l10n: de.po: translate 28 new messages
Ralf Thielow ralf.thie...@gmail.com writes: Translate 28 new messages came from git.pot update in df49095 (l10n: git.pot: v1.9 round 1 (27 new, 11 removed) and d57b24b (l10n: git.pot: v1.9 round 2 (1 new)). Signed-off-by: Ralf Thielow ralf.thie...@gmail.com --- v4 corrects some translations according to Thomas' review. Thanks for that. With this we also change the translation of shallow which was translated as flach as in flacher Klon. Now we translate it as with Klon/Repository mit unvollständiger Historie. I've already stated that I'd just use oberflächlich here. @@ -1633,6 +1629,8 @@ msgid Do not touch the line above.\n Everything below will be removed. msgstr +Ändern Sie nicht die Zeile oberhalb.\n +Alles unterhalb wird entfernt. That's not even grammatical. Ändern Sie nicht die obige Zeile. Alles unterhalb von ihr wird entfernt. -- David Kastrup -- 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] l10n: de.po: translate 27 new messages
2014-02-08 20:59 GMT+01:00 David Kastrup d...@gnu.org: Ralf Thielow ralf.thie...@gmail.com writes: 2014-02-08 20:22 GMT+01:00 David Kastrup d...@gnu.org: verberge keine aufgepfropften Commits seems much more in the spirit of the original terminology. verbirgt keine Commits mit künstlichen Vorgängern is plainly wrong anyway since it is not the commits _with_ grafts which are hidden but rather the commits _provided_ by grafts. Maybe verbirgt keine Commits auf Basis künstlicher Vorgänger? No. If at all Verbirgt keine künstlichen Vorgänger or keine künstlichen Vorgängercommits since the künstlicher Vorgänger _is_ the commit that is hidden: the graft, if we are being totally meticulous, is the list of artificial parents for a given commit. The option, when activated, hides those artificial parents. And Do not is not Does not, so Verbirgt seems also wrong as it likely should be Verberge (imperative). But then it would depend on the overall style in which this imperative is usually translated. Oh, I seem to have misunderstood the thing :/ So I'd be verbirgt keine künstlichen Vorgänger-Commits. For short descriptions of options we currently don't use the imperative. This should be changed. Thanks -- David Kastrup -- 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] l10n: de.po: translate 28 new messages
2014-02-08 21:11 GMT+01:00 David Kastrup d...@gnu.org: Ralf Thielow ralf.thie...@gmail.com writes: Translate 28 new messages came from git.pot update in df49095 (l10n: git.pot: v1.9 round 1 (27 new, 11 removed) and d57b24b (l10n: git.pot: v1.9 round 2 (1 new)). Signed-off-by: Ralf Thielow ralf.thie...@gmail.com --- v4 corrects some translations according to Thomas' review. Thanks for that. With this we also change the translation of shallow which was translated as flach as in flacher Klon. Now we translate it as with Klon/Repository mit unvollständiger Historie. I've already stated that I'd just use oberflächlich here. The Git glossary says A shallow repository has an incomplete history..., and I think Klon/Repository mit unvollständiger Historie is less confusing than oberflächlich. I'd keep unvollständige Historie with a (shallow) behind of each usage to give the user a hint of what's really meant. I'll send a reroll soon. @@ -1633,6 +1629,8 @@ msgid Do not touch the line above.\n Everything below will be removed. msgstr +Ändern Sie nicht die Zeile oberhalb.\n +Alles unterhalb wird entfernt. That's not even grammatical. Ändern Sie nicht die obige Zeile. Alles unterhalb von ihr wird entfernt. Thanks -- David Kastrup -- 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 v5] l10n: de.po: translate 28 new messages
Translate 28 new messages came from git.pot update in df49095 (l10n: git.pot: v1.9 round 1 (27 new, 11 removed) and d57b24b (l10n: git.pot: v1.9 round 2 (1 new)). Signed-off-by: Ralf Thielow ralf.thie...@gmail.com --- po/de.po | 99 1 file changed, 50 insertions(+), 49 deletions(-) diff --git a/po/de.po b/po/de.po index 7f8aa75..205ff88 100644 --- a/po/de.po +++ b/po/de.po @@ -442,9 +442,9 @@ msgstr[0] vor %lu Jahr msgstr[1] vor %lu Jahren #: diffcore-order.c:24 -#, fuzzy, c-format +#, c-format msgid failed to read orderfile '%s' -msgstr Fehler beim Lesen des Objektes '%s'. +msgstr Fehler beim Lesen der Reihenfolgedatei '%s'. #: diff.c:113 #, c-format @@ -975,21 +975,23 @@ msgid There is nothing to exclude from by :(exclude) patterns.\n Perhaps you forgot to add either ':/' or '.' ? msgstr +:(exclude) Muster, aber keine anderen Pfadspezifikationen angegeben.\n +Vielleicht haben Sie vergessen entweder ':/' oder '.' hinzuzufügen? #: remote.c:753 -#, fuzzy, c-format +#, c-format msgid Cannot fetch both %s and %s to %s -msgstr Kann keine Commit-Beschreibung für %s bekommen +msgstr Kann 'fetch' nicht für sowohl %s als auch %s nach %s ausführen. #: remote.c:757 #, c-format msgid %s usually tracks %s, not %s -msgstr +msgstr %s folgt üblicherweise %s, nicht %s #: remote.c:761 #, c-format msgid %s tracks both %s and %s -msgstr +msgstr %s folgt sowohl %s als auch %s #. #. * This last possibility doesn't occur because @@ -997,9 +999,8 @@ msgstr #. * the end of the list. #. #: remote.c:769 -#, fuzzy msgid Internal error -msgstr interner Fehler +msgstr Interner Fehler #: remote.c:1871 #, c-format @@ -1575,33 +1576,28 @@ msgid both modified: msgstr von beiden geändert: #: wt-status.c:275 -#, fuzzy msgid new file -msgstr neue Datei: %s +msgstr neue Datei #: wt-status.c:277 msgid copied -msgstr +msgstr kopiert #: wt-status.c:279 -#, fuzzy msgid deleted msgstr gelöscht #: wt-status.c:285 -#, fuzzy msgid typechange -msgstr Typänderung: %s +msgstr Typänderung #: wt-status.c:287 -#, fuzzy msgid unknown -msgstr unbekannt:%s +msgstr unbekannt #: wt-status.c:289 -#, fuzzy msgid unmerged -msgstr zusammenführen +msgstr nicht zusammengeführt #: wt-status.c:336 msgid new commits, @@ -1633,6 +1629,8 @@ msgid Do not touch the line above.\n Everything below will be removed. msgstr +Ändern Sie nicht die obige Zeile.\n +Alles unterhalb von ihr wird entfernt. #: wt-status.c:899 msgid You have unmerged paths. @@ -3963,7 +3961,7 @@ msgstr Tiefe #: builtin/clone.c:93 msgid create a shallow clone of that depth -msgstr erstellt einen flachen Klon mit dieser Tiefe +msgstr erstellt einen Klon mit unvollständiger Historie (shallow) in dieser Tiefe #: builtin/clone.c:95 msgid clone only one branch, HEAD or --branch @@ -3991,14 +3989,14 @@ msgid reference repository '%s' is not a local repository. msgstr Referenziertes Repository '%s' ist kein lokales Repository. #: builtin/clone.c:256 -#, fuzzy, c-format +#, c-format msgid reference repository '%s' is shallow -msgstr Referenziertes Repository '%s' ist kein lokales Repository. +msgstr Referenziertes Repository '%s' hat eine unvollständige Historie (shallow). #: builtin/clone.c:259 -#, fuzzy, c-format +#, c-format msgid reference repository '%s' is grafted -msgstr referenziert Repository +msgstr Referenziertes Repository '%s' ist mit künstlichen Vorgängern (\grafts\) eingehängt. #: builtin/clone.c:321 #, c-format @@ -4099,16 +4097,17 @@ msgstr #: builtin/clone.c:805 msgid source repository is shallow, ignoring --local -msgstr +msgstr Quelle ist ein Repository mit unvollständiger Historie (shallow), +ignoriere --local #: builtin/clone.c:810 msgid --local is ignored msgstr --local wird ignoriert #: builtin/clone.c:814 builtin/fetch.c:1119 -#, fuzzy, c-format +#, c-format msgid depth %s is not a positive number -msgstr Objekt %s ist kein Blob +msgstr Tiefe %s ist keine positive Zahl #: builtin/clone.c:824 #, c-format @@ -5196,7 +5195,7 @@ msgstr erlaubt Aktualisierung der \HEAD\-Referenz #: builtin/fetch.c:99 msgid deepen history of shallow clone -msgstr vertieft die Historie eines flachen Klons +msgstr vertieft die Historie eines Klons mit unvollständiger Historie (shallow) #: builtin/fetch.c:101 msgid convert to a complete repository @@ -5215,9 +5214,8 @@ msgid default mode for recursion msgstr Standard-Modus für Rekursion #: builtin/fetch.c:109 -#, fuzzy msgid accept refs that update .git/shallow -msgstr Konnte aktualisierte .gitmodules-Datei nicht lesen +msgstr akzeptiert Referenzen die .git/shallow aktualisieren #: builtin/fetch.c:347 msgid Couldn't find remote ref HEAD @@ -5287,7 +5285,8 @@ msgstr %s hat nicht alle erforderlichen Objekte gesendet\n #: builtin/fetch.c:579 #, c-format msgid reject %s because shallow roots are not allowed to be updated -msgstr +msgstr %s wurde
[PATCH 1/4] docs/merge-strategies: remove hyphen from mis-merges
The term mismerges without hyphen is used a few other places in the documentation. Let's update this to be consistent. Signed-off-by: Albert L. Lash, IV ala...@bloomberg.net --- Documentation/merge-strategies.txt | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/Documentation/merge-strategies.txt b/Documentation/merge-strategies.txt index fb6e593..3509498 100644 --- a/Documentation/merge-strategies.txt +++ b/Documentation/merge-strategies.txt @@ -20,7 +20,7 @@ recursive:: merged tree of the common ancestors and uses that as the reference tree for the 3-way merge. This has been reported to result in fewer merge conflicts without - causing mis-merges by tests done on actual merge commits + causing mismerges by tests done on actual merge commits taken from Linux 2.6 kernel development history. Additionally this can detect and handle merges involving renames. This is the default merge strategy when -- 1.8.3.2 -- 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 4/4] docs/git-blame: explain more clearly the example pickaxe use
We state that the following paragraph mentions the pickaxe interface, but the term pickaxe is not then used. This change clarifies that the example command uses the pickaxe interface and what it is searching for. Signed-off-by: Albert L. Lash, IV ala...@bloomberg.net --- Documentation/git-blame.txt | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/Documentation/git-blame.txt b/Documentation/git-blame.txt index 8e70a61..ddb88d0 100644 --- a/Documentation/git-blame.txt +++ b/Documentation/git-blame.txt @@ -35,7 +35,8 @@ Apart from supporting file annotation, Git also supports searching the development history for when a code snippet occurred in a change. This makes it possible to track when a code snippet was added to a file, moved or copied between files, and eventually deleted or replaced. It works by searching for -a text string in the diff. A small example: +a text string in the diff. A small example of the pickaxe interface +that searches for `blame_usage`: - $ git log --pretty=oneline -S'blame_usage' -- 1.8.3.2 -- 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 3/4] docs/git-clone: clarify use of --no-hardlinks option
Current text claims optimization, implying the use of hardlinks, when this option ratchets down the level of efficiency. This change explains the difference made by using this option, namely copying instead of hardlinking, and why it may be useful. Signed-off-by: Albert L. Lash, IV ala...@bloomberg.net --- Documentation/git-clone.txt | 11 --- 1 file changed, 4 insertions(+), 7 deletions(-) diff --git a/Documentation/git-clone.txt b/Documentation/git-clone.txt index bf3dac0..0363d00 100644 --- a/Documentation/git-clone.txt +++ b/Documentation/git-clone.txt @@ -55,15 +55,12 @@ repository is specified as a URL, then this flag is ignored (and we never use the local optimizations). Specifying `--no-local` will override the default when `/path/to/repo` is given, using the regular Git transport instead. -+ -To force copying instead of hardlinking (which may be desirable if you -are trying to make a back-up of your repository), but still avoid the -usual Git aware transport mechanism, `--no-hardlinks` can be used. --no-hardlinks:: - Optimize the cloning process from a repository on a - local filesystem by copying files under `.git/objects` - directory. + Force the cloning process from a repository on a local + filesystem to copy the files under the `.git/objects` + directory instead of using hardlinks. This may be desirable + if you are trying to make a back-up of your repository. --shared:: -s:: -- 1.8.3.2 -- 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/4] docs/git-remote: capitalize first word of initial blurb
All other man files have capitalized descriptions which immediately follow the command's name. Let's capitalize this one too for consistency. Signed-off-by: Albert L. Lash, IV ala...@bloomberg.net --- Documentation/git-remote.txt | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/Documentation/git-remote.txt b/Documentation/git-remote.txt index 2507c8b..cb103c8 100644 --- a/Documentation/git-remote.txt +++ b/Documentation/git-remote.txt @@ -3,7 +3,7 @@ git-remote(1) NAME -git-remote - manage set of tracked repositories +git-remote - Manage set of tracked repositories SYNOPSIS -- 1.8.3.2 -- 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] builtin/blame.c::prepare_lines: fix allocation size of sb-lineno
On Sat, Feb 08, 2014 at 10:49:40AM +0100, David Kastrup wrote: But please note that since sb-lineno originally comes from a zeroed memory area and is passed to xrealloc, this requires that after int *p; memset(p, 0, sizeof(p)); the equivalence ((void *)p == NULL) will hold. While this is true on most platforms, and while the C standard guarantees the slightly different ((void *)0 == NULL) is true, it makes no statement concerning the memory representation of the NULL pointer. I have not bothered addressing this non-compliance with the C standard as it would be polishing a turd. A wholesale replacement has already been proposed, and it's likely that this assumption is prevalent in the Git codebase elsewhere anyway. Yes, we explicitly break this part of the standard in the name of practicality (it simplifies frequently-used code, and machines on which it matters are rare enough that nobody has ever complained about it). So I do not think this is a problem. However, is there a reason not to use: sizeof(*sb-lineno) rather than sizeof(int) to avoid type-mismatch errors entirely (this applies both to this patch, and to any proposed rewrites using malloc). -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
[PATCH] l10n: de.po: correct message when hiding commits by craft
The recent translation was giving the idea that all commits based on a graft were meant to be hidden. Make it clear that it is the graft commit itself. Reported-by: David Kastrup d...@gnu.org Signed-off-by: Ralf Thielow ralf.thie...@gmail.com --- po/de.po | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/po/de.po b/po/de.po index 205ff88..b777ef4 100644 --- a/po/de.po +++ b/po/de.po @@ -7878,7 +7878,7 @@ msgstr Komprimierungsgrad für Paketierung #: builtin/pack-objects.c:2506 msgid do not hide commits by grafts -msgstr verbirgt keine Commits mit künstlichen Vorgängern (\grafts\) +msgstr verbirgt keine künstlichen Vorgänger-Commits (\grafts\) #: builtin/pack-refs.c:6 msgid git pack-refs [options] -- 1.9.rc2.233.ged4ee9f -- 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] l10n: de.po: correct message when hiding commits by craft
The recent translation was giving the idea that all commits based on a graft were meant to be hidden. Make it clear that it is the graft commit itself. Reported-by: David Kastrup d...@gnu.org Signed-off-by: Ralf Thielow ralf.thie...@gmail.com --- po/de.po | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/po/de.po b/po/de.po index 205ff88..b777ef4 100644 --- a/po/de.po +++ b/po/de.po @@ -7878,7 +7878,7 @@ msgstr Komprimierungsgrad für Paketierung #: builtin/pack-objects.c:2506 msgid do not hide commits by grafts -msgstr verbirgt keine Commits mit künstlichen Vorgängern (\grafts\) +msgstr verbirgt keine künstlichen Vorgänger-Commits (\grafts\) #: builtin/pack-refs.c:6 msgid git pack-refs [options] -- 1.9.rc2.233.ged4ee9f -- 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] builtin/blame.c::prepare_lines: fix allocation size of sb-lineno
Jeff King p...@peff.net writes: However, is there a reason not to use: sizeof(*sb-lineno) rather than sizeof(int) to avoid type-mismatch errors entirely (this applies both to this patch, and to any proposed rewrites using malloc). It deviates from the style of the original code by tried and true Git developers. So feel free to roll your own patch here: it's not like this one has any copyrightable content in it. -- David Kastrup -- 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 12/13] Makefile: teach scripts to include make variables
Jeff King p...@peff.net writes: The current scheme for getting build-time variables into a shell script is to munge the script with sed, and stick the munged variable into a special sentinel file so that make knows about the dependency. Instead, we can combine both functions by generating a shell snippet with our value, and then building shell scripts by concatenating their snippets. make then handles the dependency automatically, and it's easy to generate tighter dependencies. We demonstrate here by moving the DIFF substitution into its own snippet, which lets us rebuild only the single affected file when it changes. I can't look right now *why* this happens, but this breaks ./t2300-cd-to-toplevel.sh --valgrind with messages like expecting success: ( cd 'repo' . $(git --exec-path)/git-sh-setup cd_to_toplevel [ $(pwd -P) = $TOPLEVEL ] ) ./test-lib.sh: line 414: /home/thomas/g/t/valgrind/bin/git-sh-setup: No such file or directory not ok 1 - at physical root # # ( # cd 'repo' # . $(git --exec-path)/git-sh-setup # cd_to_toplevel # [ $(pwd -P) = $TOPLEVEL ] # ) # I don't know why it only affects this test, or why it doesn't break when within 'git bisect run' -- probably there's something funky going on in the environment, quite possibly in my own configs. -- Thomas Rast t...@thomasrast.ch -- 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] hashmap.h: make sure map entries are tightly packed
Am 07.02.2014 21:56, schrieb Junio C Hamano:
* kb/fast-hashmap (2014-01-03) 19 commits
- hashmap.h: make sure map entries are tightly packed
(merged to 'next' on 2014-01-03 at dc85001)
[...]
The tip one does not seem to have reached concensus (yet).
See discussion leading up to $gmane/239433.
I'd like to finish this up, so here are the options regarding the tip commit as
I see them, ordered least risk to broadest compiler support:
1.) Drop the tip commit
Wastes 4 bytes of memory per entry on 64-bit platforms (still an improvement
wrt memory, hash.[ch] wastes 4 bytes per bucket).
Works on all platforms.
2.) Keep the tip commit, i.e. __attribute__(__packed__)
Currently in pu at 036ad21.
Fixes the problem for 64-bit GCC only.
May fail on HP, all other platforms #define __attribute__ /* empty */
3.) Replace with the patch below, i.e. #pragma pack
Same as $gmane/239430 + $gmane/239433.
Should fix the problem for most compilers, with unit-test to make sure.
May fail on IRIX/MIPSPro (supposedly wants #pragma pack(0) to reset packing
to default).
I don't know whether IRIX is still relevant (support ended Dec 2013). But if we
fix this issue, I'd like to support as many platforms as possible, even though
I can't test them all. The inline __attribute__ syntax is a dead end in that
respect, so I'd suggest to go for #pragma pack (3). At the very least we
shouldn't stall the rest of the patch series on a hunch that the last
(unfortunately non-standard) patch may break on some legacy system.
Cheers,
Karsten
8
Subject: [PATCH] hashmap.h: make sure map entries are tightly packed
Extending 'struct hashmap_entry' with an int-sized member shouldn't waste
memory on 64-bit systems. This is already documented in api-hashmap.txt,
but struct hashmap_entry needs to be packed for this to work. E.g.
struct name_entry {
struct hashmap_entry ent; /* consists of pointer + int */
int namelen;
char *name;
};
should be 24 instead of 32 bytes.
Packing structures is compiler-specific, most compilers support [1]:
#pragma pack(n) - to set structure packing
#pragma pack() - to reset structure packing to default
Compilers are supposed to ignore unknown #pragmas, so using this without
further #if compiler guards should be safe.
Wasting a few bytes for padding is acceptable, however, compiling the rest
of git with packed structures (and thus mis-aligned arrays of structs) is
not. Add a test to ensure that '#pragma pack()' really resets the packing.
[1] Compiler docs regarding #pragma pack:
http://gcc.gnu.org/onlinedocs/gcc-4.6.2/gcc/Structure_002dPacking-Pragmas.html#Structure_002dPacking-Pragmas
http://msdn.microsoft.com/en-us/library/2e70t5y1%28v=vs.80%29.aspx
http://h21007.www2.hp.com/portal/download/files/unprot/aCxx/Online_Help/pragmas.htm#pragma-PACK
http://clang.llvm.org/docs/UsersManual.html#microsoft-extensions
http://uw714doc.sco.com/en/SDK_cprog/_Preprocessing_Directives.html
http://osr507doc.sco.com/en/tools/ANSI_F.3.13_Preprocessing.html
http://docs.oracle.com/cd/E19422-01/819-3690/Pragmas_App.html#73499
http://publib.boulder.ibm.com/infocenter/comphelp/v7v91/index.jsp?topic=%2Fcom.ibm.vacpp7a.doc%2Fcompiler%2Fref%2Frnpgpack.htm
Supposedly wants #pragma pack(0) to reset:
http://techpubs.sgi.com/library/tpl/cgi-bin/getdoc.cgi/0650/bks/SGI_Developer/books/Pragmas/sgi_html/ch04.html
Not supported:
http://software.intel.com/sites/products/documentation/doclib/iss/2013/compiler/cpp-lin/GUID-DD32852C-A0F9-4AC6-BF67-D10D064CC87A.htm
Signed-off-by: Karsten Blees bl...@dcon.de
---
hashmap.h | 7 +++
t/t0011-hashmap.sh | 6 ++
test-hashmap.c | 17 +
3 files changed, 30 insertions(+)
diff --git a/hashmap.h b/hashmap.h
index a816ad4..93b330b 100644
--- a/hashmap.h
+++ b/hashmap.h
@@ -15,10 +15,17 @@ extern unsigned int memihash(const void *buf, size_t len);
/* data structures */
+/*
+ * Set struct packing to 4 so that we don't waste memory on 64-bit systems.
+ * Struct hashmap_entry is used as prefix to other (un-packed) structures,
+ * so this won't cause alignment issues e.g. for odd elements in an array.
+ */
+#pragma pack(4)
struct hashmap_entry {
struct hashmap_entry *next;
unsigned int hash;
};
+#pragma pack()
typedef int (*hashmap_cmp_fn)(const void *entry, const void *entry_or_key,
const void *keydata);
diff --git a/t/t0011-hashmap.sh b/t/t0011-hashmap.sh
index 391e2b6..3f3c90b 100755
--- a/t/t0011-hashmap.sh
+++ b/t/t0011-hashmap.sh
@@ -237,4 +237,10 @@ test_expect_success 'grow / shrink' '
'
+test_expect_success '#pragma pack() resets packing to default' '
+
+ test_hashmap pragma-pack ok
+
+'
+
test_done
diff --git a/test-hashmap.c b/test-hashmap.c
index f5183fb..64bd9ec 100644
--- a/test-hashmap.c
+++ b/test-hashmap.c
@@ -36,6 +36,12 @@ static struct test_entry *alloc_test_entry(int hash, char
*key, int klen,
return entry;
}
+struct pointer_int
+{
+ void *ptr;
+
Re: [PATCH 0/2] Ignore trailing spaces in .gitignore
On Sat, Feb 8, 2014 at 11:45 PM, Jeff King p...@peff.net wrote:
On Sat, Feb 08, 2014 at 03:10:02PM +0700, Nguyễn Thái Ngọc Duy wrote:
Trailing spaces are invisible in most standard editors (*). git diff
does show trailing spaces by default. But that does not help newly
written .gitignore files. And trailing spaces are the source of
frustration when writing .gitignore.
I guess leading spaces are not as frustrating, but I wonder if it would
be more consistent to say that we soak up all whitespace. That is also a
regression, but I agree that these are exceptional cases, and as long as
we provide an out for people to cover them via quoting, ignoring the
whitespace seems like a sane default.
Hm...
People can still quote trailing spaces, which will not be ignored (and
much more visible). Quoting comes with a cost of doing fnmatch(). But
I won't optimize it until I see someone shows me they have a use case
for it.
I naively expected that:
echo 'trailing\ \ ' .gitignore
would count as quoting, but your patch doesn't handle that. It _does_
seem to work currently (that is, the backslashes go away and we treat it
literally), but I am not sure if that is planned, or simply happens to
work.
No that's what I had in mind. But yeah my patches are flawed.
I guess by quoting you meant:
echo 'trailing ' .gitignore
This makes special. If we follow shell convention then things
between .. should be literal (e.g. * is no longer a wildcard). We
don't support it yet. So I rather go with backslash as it adds less
code.
Anyway, here are some tests I wrote up while playing with this. They do
not pass with your current patch for the reasons above, but maybe they
will be useful to squash in (either after tweaking the tests, or
tweaking the patch).
diff --git a/t/t0008-ignores.sh b/t/t0008-ignores.sh
index b4d98e6..4dde314 100755
--- a/t/t0008-ignores.sh
+++ b/t/t0008-ignores.sh
@@ -775,4 +775,33 @@ test_expect_success PIPE 'streaming support for --stdin'
'
echo $response | grep ^::two
'
+
+#
+# test whitespace handling
+
+test_expect_success 'leading/trailing whitespace is ignored' '
+ mkdir whitespace
+ whitespace/leading
+ whitespace/trailing
+ whitespace/untracked
+ {
+ echo whitespace/leading
+ echo whitespace/trailing
+ } ignore
+ echo whitespace/untracked expect
+ git ls-files -o -X ignore whitespace actual
+ test_cmp expect actual
+'
+
+test_expect_success 'quoting allows trailing whitespace' '
+ rm -rf whitespace
+ mkdir whitespace
+ whitespace/trailing
+ whitespace/untracked
+ echo whitespace/trailing\\ \\ ignore
+ echo whitespace/untracked expect
+ git ls-files -o -X ignore whitespace actual
+ test_cmp expect actual
+'
+
test_done
--
Duy
--
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 v2 0/2] Ignore trailing spaces in .gitignore
This reroll now respects backslash quoting. Thanks Jeff and Torsten for the comments. Nguyễn Thái Ngọc Duy (2): dir: warn about trailing spaces in exclude patterns dir: ignore trailing spaces in exclude patterns Documentation/gitignore.txt | 3 +++ dir.c | 20 t/t0008-ignores.sh | 31 +++ 3 files changed, 54 insertions(+) -- 1.8.5.2.240.g8478abd -- 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 v2 2/2] dir: ignore trailing spaces in exclude patterns
Signed-off-by: Nguyễn Thái Ngọc Duy pclo...@gmail.com
---
Documentation/gitignore.txt | 3 +++
dir.c | 21 -
t/t0008-ignores.sh | 8
3 files changed, 19 insertions(+), 13 deletions(-)
diff --git a/Documentation/gitignore.txt b/Documentation/gitignore.txt
index b08d34d..8734c15 100644
--- a/Documentation/gitignore.txt
+++ b/Documentation/gitignore.txt
@@ -77,6 +77,9 @@ PATTERN FORMAT
Put a backslash (`\`) in front of the first hash for patterns
that begin with a hash.
+ - Trailing spaces are ignored unless they are quoted with backlash
+ (`\`).
+
- An optional prefix `!` which negates the pattern; any
matching file excluded by a previous pattern will become
included again. It is not possible to re-include a file if a parent
diff --git a/dir.c b/dir.c
index 6162209..70076b5 100644
--- a/dir.c
+++ b/dir.c
@@ -491,20 +491,23 @@ void clear_exclude_list(struct exclude_list *el)
el-filebuf = NULL;
}
-static void check_trailing_spaces(const char *fname, char *buf)
+static void trim_trailing_spaces(char *buf)
{
- int i, last_space = -1, len = strlen(buf);
+ int i, last_space = -1, nr_spaces, len = strlen(buf);
for (i = 0; i len; i++)
if (buf[i] == '\\')
i++;
- else if (buf[i] == ' ')
- last_space = i;
- else
+ else if (buf[i] == ' ') {
+ if (last_space == -1) {
+ last_space = i;
+ nr_spaces = 1;
+ } else
+ nr_spaces++;
+ } else
last_space = -1;
- if (last_space == len - 1)
- warning(_(%s: trailing spaces in '%s'. Please quote or remove
them.),
- fname, buf);
+ if (last_space != -1 last_space + nr_spaces == len)
+ buf[last_space] = '\0';
}
int add_excludes_from_file_to_list(const char *fname,
@@ -558,7 +561,7 @@ int add_excludes_from_file_to_list(const char *fname,
if (buf[i] == '\n') {
if (entry != buf + i entry[0] != '#') {
buf[i - (i buf[i-1] == '\r')] = 0;
- check_trailing_spaces(fname, entry);
+ trim_trailing_spaces(entry);
add_exclude(entry, base, baselen, el, lineno);
}
lineno++;
diff --git a/t/t0008-ignores.sh b/t/t0008-ignores.sh
index 9e1d64c..bbaf6b5 100755
--- a/t/t0008-ignores.sh
+++ b/t/t0008-ignores.sh
@@ -779,18 +779,18 @@ test_expect_success PIPE 'streaming support for --stdin' '
#
# test whitespace handling
-test_expect_success 'trailing whitespace is warned' '
+test_expect_success 'trailing whitespace is ignored' '
mkdir whitespace
whitespace/trailing
whitespace/untracked
echo whitespace/trailingignore
cat expect EOF
-whitespace/trailing
whitespace/untracked
EOF
+ : err.expect
git ls-files -o -X ignore whitespace actual 2err
- grep ignore:.*'\''whitespace/trailing '\'' err
- test_cmp expect actual
+ test_cmp expect actual
+ test_cmp err.expect err
'
test_expect_success 'quoting allows trailing whitespace' '
--
1.8.5.2.240.g8478abd
--
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 v2 1/2] dir: warn about trailing spaces in exclude patterns
Signed-off-by: Nguyễn Thái Ngọc Duy pclo...@gmail.com
---
dir.c | 17 +
t/t0008-ignores.sh | 31 +++
2 files changed, 48 insertions(+)
diff --git a/dir.c b/dir.c
index b35b633..6162209 100644
--- a/dir.c
+++ b/dir.c
@@ -491,6 +491,22 @@ void clear_exclude_list(struct exclude_list *el)
el-filebuf = NULL;
}
+static void check_trailing_spaces(const char *fname, char *buf)
+{
+ int i, last_space = -1, len = strlen(buf);
+ for (i = 0; i len; i++)
+ if (buf[i] == '\\')
+ i++;
+ else if (buf[i] == ' ')
+ last_space = i;
+ else
+ last_space = -1;
+
+ if (last_space == len - 1)
+ warning(_(%s: trailing spaces in '%s'. Please quote or remove
them.),
+ fname, buf);
+}
+
int add_excludes_from_file_to_list(const char *fname,
const char *base,
int baselen,
@@ -542,6 +558,7 @@ int add_excludes_from_file_to_list(const char *fname,
if (buf[i] == '\n') {
if (entry != buf + i entry[0] != '#') {
buf[i - (i buf[i-1] == '\r')] = 0;
+ check_trailing_spaces(fname, entry);
add_exclude(entry, base, baselen, el, lineno);
}
lineno++;
diff --git a/t/t0008-ignores.sh b/t/t0008-ignores.sh
index b4d98e6..9e1d64c 100755
--- a/t/t0008-ignores.sh
+++ b/t/t0008-ignores.sh
@@ -775,4 +775,35 @@ test_expect_success PIPE 'streaming support for --stdin' '
echo $response | grep ^::two
'
+
+#
+# test whitespace handling
+
+test_expect_success 'trailing whitespace is warned' '
+ mkdir whitespace
+ whitespace/trailing
+ whitespace/untracked
+ echo whitespace/trailingignore
+ cat expect EOF
+whitespace/trailing
+whitespace/untracked
+EOF
+ git ls-files -o -X ignore whitespace actual 2err
+ grep ignore:.*'\''whitespace/trailing '\'' err
+ test_cmp expect actual
+'
+
+test_expect_success 'quoting allows trailing whitespace' '
+ rm -rf whitespace
+ mkdir whitespace
+ whitespace/trailing
+ whitespace/untracked
+ echo whitespace/trailing\\ \\ ignore
+ echo whitespace/untracked expect
+ : err.expect
+ git ls-files -o -X ignore whitespace actual 2err
+ test_cmp expect actual
+ test_cmp err.expect err
+'
+
test_done
--
1.8.5.2.240.g8478abd
--
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: gitweb.cgi bug
On Sun, Feb 9, 2014 at 12:29 AM, Andrew Keller and...@kellerfarm.com wrote:
On Feb 8, 2014, at 8:37 AM, Dongsheng Song wrote:
I have an git repo PROJECT.git, the full path is /srv/repo/git/PROJECT.git,
when I set git_base_url_list in gitweb.conf:
@git_base_url_list = qw(https://192.168.30.239/repo/git
git@192.168.30.239:repo/git);
I got the result:
https://192.168.30.239/repo/git/PROJECT.git
git@192.168.30.239:/PROJECT.git
This is wrong, it should be (without the leading '/')
git@192.168.30.239:PROJECT.git
There is no way to generate a fetch url of 'git@192.168.30.239:PROJECT.git'
in gitweb.
If one of the base urls was 'git@192.168.30.239:.', then you could get a
fetch URL of 'git@192.168.30.239:./PROJECT.git'
In general, though, I like to stay away from relative paths. Weird things
can happen, like HTTP works but SSH doesn't, because the home directory for
SSH changed because you used a different user.
- Andrew
What's about the following translate rules ?
git@192.168.30.239: - git@192.168.30.239:PROJECT.git
git@192.168.30.239:/ - git@192.168.30.239:/PROJECT.git
git@192.168.30.239:/repo - git@192.168.30.239:/repo/PROJECT.git
git@192.168.30.239:/repo/ - git@192.168.30.239:/repo/PROJECT.git
I don't know Perl, but I think change the following translate code is
not a hard work:
# use per project git URL list in $projectroot/$project/cloneurl
# or make project git URL from git base URL and project name
my $url_tag = URL;
my @url_list = git_get_project_url_list($project);
@url_list = map { $_/$project } @git_base_url_list unless @url_list;
foreach my $git_url (@url_list) {
next unless $git_url;
print format_repo_url($url_tag, $git_url);
$url_tag = ;
}
Regards,
Dongsheng
--
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
