Good day
I am Ms. CHIANG Lai Yuen JP, I have a private business proposal worth $12.5 Million USD, reply to my private e-mail: (mschiang0...@live.com) for more details if you are interested and willing. Thank You, Ms CHIANG Lai Yuen, JP. -- 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 01/17] Add data structures and basic functions for commit trailers
On Thu, Jan 30, 2014 at 1:49 AM, Christian Couder
chrisc...@tuxfamily.org wrote:
We will use a doubly linked list to store all information
about trailers and their configuration.
This way we can easily remove or add trailers to or from
trailer lists while traversing the lists in either direction.
Signed-off-by: Christian Couder chrisc...@tuxfamily.org
---
diff --git a/trailer.c b/trailer.c
new file mode 100644
index 000..aed25e1
--- /dev/null
+++ b/trailer.c
@@ -0,0 +1,48 @@
+#include cache.h
+/*
+ * Copyright (c) 2013 Christian Couder chrisc...@tuxfamily.org
+ */
+
+static int same_token(struct trailer_item *a, struct trailer_item *b, int
alnum_len)
+{
+ return !strncasecmp(a-token, b-token, alnum_len);
+}
Maybe these functions defined in the header should all be 'static
inline' rather than just 'static'? Making them inline would be
consistent with functions defined in other git headers.
+
+static int same_value(struct trailer_item *a, struct trailer_item *b)
+{
+ return !strcasecmp(a-value, b-value);
+}
+
+static int same_trailer(struct trailer_item *a, struct trailer_item *b, int
alnum_len)
+{
+ return same_token(a, b, alnum_len) same_value(a, b);
+}
+
+/* Get the length of buf from its beginning until its last alphanumeric
character */
+static size_t alnum_len(const char *buf, size_t len)
+{
+ while (--len = 0 !isalnum(buf[len]));
'len' has type size_t, which is unsigned, so the conditional '--len =
0' will always be true (which will result in a crash if 'buf' contains
no alphanumerics).
+ return len + 1;
+}
--
1.8.5.2.201.gacc5987
--
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: Having Git follow symlinks
Johan Herland: I believe a preferable way to manage dotfiles in Git, is to have a script that does the necessary setup/installation from the repo (that lives in some subdirectory of ~) and into ~. Yeah, but then I have copies of the files, instead of having the files themselves under version control, meaning I need to copy them back to push changes back, or to merge them. That is undesirable :-/ I do have a setup script for the CVS repo, but it just sets the symlinks up. The only solution I can see is to split the repo up into several parts, one for each sub-directory that I previously had symlinked. Not perfect, but I guess I can live with that. -- \\// Peter - http://www.softwolves.pp.se/ -- 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: Having Git follow symlinks
On Thu, Jan 30, 2014 at 10:01 AM, Peter Krefting pe...@softwolves.pp.se wrote: Johan Herland: I believe a preferable way to manage dotfiles in Git, is to have a script that does the necessary setup/installation from the repo (that lives in some subdirectory of ~) and into ~. There are tools these days to manage dot files. See for example: https://github.com/RichiH/vcsh Best, Christian. -- 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-draw - draws nearly the full content of a tiny git repository as a graph
On Wed, Jan 29, 2014 at 4:21 PM, Flo sensor...@gmail.com wrote: I just want to present a small tool I wrote. I use it at work to have a tool visualizing the Git basic concepts and data structures which are really really really simple (Linus' words). That helps me teaching my colleagues about Git and answering their questions when Git did not behave as they expected. https://github.com/sensorflo/git-draw/wiki Very nice! Thank you! I tried it on a couple of my test repos that I use when teaching people and it appears you need to munge branch names that contain hyphens in the generated dot file, or dot fails to parse the file. Otherwise, it's a neat tool. Thanks again! -John -- 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
Strange merge output.
Hi, I asked about this problem on #git@freenode and someone suggested I submit it to this list. I have a case where the output of a merge gives a conflict and produces the following file: Code Block A HEAD === Code Block B branch-B Code Block B' (similar to code block B but not exactly the same). Here is what HEAD looks like Code Block A Code Block B' and branch-B: Code Block A Code Block B I thought that taking a conflicted file like above and removing the three following lines: HEAD === branch-B was supposed to produce *exactly* the branch-B version? 1°/ was I wrong to believe this implied promise? 2°/ if not, is this a known problem with git merge's default recursive strategy? (I didn't change any default configuration about merging). 3°/ If yes to question 2°/, is there a known workaround for it? I am trying to move my team to git, but we already have a hard time understanding how it works. I'm really hoping it's a case of us not understanding things and not a bug :-) Thanks in advance for any answer, I'm willing to answer any question to help create a test case for this. Vincent Bernardi P.S.: I am using git 1.8.3.4 - The Kameleoon team. http://www.kameleoon.com-- 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: Strange merge output.
Vincent Bernardi vinc...@kameleoon.com writes: Hi, I asked about this problem on #git@freenode and someone suggested I submit it to this list. I have a case where the output of a merge gives a conflict and produces the following file: Code Block A HEAD === Code Block B branch-B Code Block B' (similar to code block B but not exactly the same). Here is what HEAD looks like Code Block A Code Block B' and branch-B: Code Block A Code Block B I thought that taking a conflicted file like above and removing the three following lines: HEAD === branch-B was supposed to produce *exactly* the branch-B version? No? It will produce the branch-B version in the conflicted area, but that does not mean that conflict resolution might not have been done outside of that area. -- 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] add: don't complain when adding empty project root
[] filepattern is related to current directory too (e.g. *.sh from t won't cover git-rebase.sh, :/*.sh does). Yes a patch to update git-add.txt to use the term pathspec instead of filepattern would be nice. A pointer to pathspec glossary could help discover case-insensitive matching, negative matching.. To somewhat end this thread: I haven't been able to find a patch that really improves the documentation, because Documentation/git-add.txt has already been updated: commit 30784198b766b19a639c199e4365f2a805fc08c6 Author: Junio C Hamano gits...@pobox.com Date: Thu Feb 14 15:51:43 2013 -0800 Documentation/git-add: kill remaining filepattern And all changes are here: http://git-htmldocs.googlecode.com/git/git-add.html But, look at https://www.kernel.org/pub/software/scm/git/docs/git-add.html This page seems to need an update too, and I wonder why: a) The makefile did'nt re-generate html even if it should have b) That page is not owned or updated by the git.git maintainer c) Any other reason? Does anybody know how to trigger an update at kernel.org? /Torsten -- 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: Having Git follow symlinks
Peter Krefting pe...@softwolves.pp.se writes: Yeah, but then I have copies of the files, instead of having the files themselves under version control, meaning I need to copy them back to push changes back, or to merge them. That is undesirable :-/ One option is to have the symlink in the other direction: make /etc/foo a symlink to $GIT_WORKTREE/foo and version the later. -- Matthieu Moy http://www-verimag.imag.fr/~moy/ -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Questions on local clone and push back
On Jan 30, 2014, at 12:43 AM, Arshavir Grigorian grigor...@gmail.com wrote: 1) is this a good approach to achieving what I need If you do not intend to track the parent projects in Git, then yes - that is a good approach. With that said, I recommend tracking each parent project in its own Git repository, and track the shared code in yet another Git repository, and link them using submodule references. 2) I was getting an error when I tied to run git push about the branch being checked out and What's the error when you use the more explicit syntax, `git push remote branch`? Depending on configuration, simply `git push` might not have all the information it needs to work. 3) how do I selectively push / merge only certain commits back to the source repository / branch? You can't. When pushing, pulling, or merging, you can only deal with subsections of the commit graph. With that said, you can rebuild parts of the commit graph using selected commits. Then, that result can be pushed, pulled, or merged. In my experience, you want to avoid picking and choosing commits in the shared repository for each parent project. Maintaining the shared repository is difficult enough. I advise that you find a way to make your shared code configurable for each project, such that you can have one master branch for all, and each project just uses or configures the code differently. With that said, try to keep your configurations to a minimum (within reason) - in general, the more configurations you have, the more difficult the shared library will be to maintain. Hope that helps, - 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: Feature Request Google Authenticator Support
On Thu, Jan 30, 2014 at 5:07 AM, Max Rahm ac90b...@gmail.com wrote: Github supports google authenticator 2-step authentication. I enabled it and how can't figure out how to connect to my github account through git. I've looked pretty hard in the man pages and on google and can't seem to find anything on how to set up git to work with a repository with 2-step verification. Here's a link to my stackoverflow question with my exact problem if there's something I'm missing. http://stackoverflow.com/questions/21447137/git-github-not-working-with-google-authenticator-osx As far as I can tell the feature is not supported. I'd like to be able to use the 2-step authentication but obviously I'd like to be able to push my code :D This sounds like a question for the GitHub support rather than the Git community. -- 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 5/5] builtin/commit.c: reduce scope of variables
Signed-off-by: Elia Pinto gitter.spi...@gmail.com
---
This a reroll of a previous patch. Corrected the declaration
after statement issue.
builtin/commit.c | 11 ++-
1 file changed, 6 insertions(+), 5 deletions(-)
diff --git a/builtin/commit.c b/builtin/commit.c
index 3767478..a684296 100644
--- a/builtin/commit.c
+++ b/builtin/commit.c
@@ -307,7 +307,6 @@ static char *prepare_index(int argc, const char **argv,
const char *prefix,
int fd;
struct string_list partial;
struct pathspec pathspec;
- char *old_index_env = NULL;
int refresh_flags = REFRESH_QUIET;
if (is_status)
@@ -320,6 +319,7 @@ static char *prepare_index(int argc, const char **argv,
const char *prefix,
die(_(index file corrupt));
if (interactive) {
+ char *old_index_env = NULL;
fd = hold_locked_index(index_lock, 1);
refresh_cache_or_die(refresh_flags);
@@ -600,12 +600,10 @@ static int prepare_to_commit(const char *index_file,
const char *prefix,
{
struct stat statbuf;
struct strbuf committer_ident = STRBUF_INIT;
- int commitable, saved_color_setting;
+ int commitable;
struct strbuf sb = STRBUF_INIT;
- char *buffer;
const char *hook_arg1 = NULL;
const char *hook_arg2 = NULL;
- int ident_shown = 0;
int clean_message_contents = (cleanup_mode != CLEANUP_NONE);
int old_display_comment_prefix;
@@ -649,6 +647,7 @@ static int prepare_to_commit(const char *index_file, const
char *prefix,
logfile);
hook_arg1 = message;
} else if (use_message) {
+ char *buffer;
buffer = strstr(use_message_buffer, \n\n);
if (!use_editor (!buffer || buffer[2] == '\0'))
die(_(commit has empty message));
@@ -753,6 +752,8 @@ static int prepare_to_commit(const char *index_file, const
char *prefix,
/* This checks if committer ident is explicitly given */
strbuf_addstr(committer_ident, git_committer_info(IDENT_STRICT));
if (use_editor include_status) {
+ int ident_shown = 0;
+ int saved_color_setting;
char *ai_tmp, *ci_tmp;
if (whence != FROM_COMMIT)
status_printf_ln(s, GIT_COLOR_NORMAL,
@@ -1510,7 +1511,6 @@ int cmd_commit(int argc, const char **argv, const char
*prefix)
struct ref_lock *ref_lock;
struct commit_list *parents = NULL, **pptr = parents;
struct stat statbuf;
- int allow_fast_forward = 1;
struct commit *current_head = NULL;
struct commit_extra_header *extra = NULL;
@@ -1558,6 +1558,7 @@ int cmd_commit(int argc, const char **argv, const char
*prefix)
} else if (whence == FROM_MERGE) {
struct strbuf m = STRBUF_INIT;
FILE *fp;
+ int allow_fast_forward = 1;
if (!reflog_msg)
reflog_msg = commit (merge);
--
1.7.10.4
--
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 jn/pager-lv-default-env] pager test: make fake pager consume all its input
Otherwise there is a race: if 'git log' finishes writing before the pager terminates and closes the pipe, all is well, and if the pager finishes quickly enough then 'git log' terminates with SIGPIPE. died of signal 13 at /build/buildd/git-1.9~rc1/t/test-terminal.perl line 33. not ok 6 - LESS and LV envvars are set for pagination Noticed on Ubuntu PPA builders, where the race was lost about half the time. Compare v1.7.0.2~6^2 (tests: Fix race condition in t7006-pager, 2010-02-22). Reported-by: Anders Kaseorg ande...@mit.edu Signed-off-by: Jonathan Nieder jrnie...@gmail.com --- Anders Kaseorg wrote: On 01/06/2014 09:14 PM, Jonathan Nieder wrote: +PAGER=env pager-env.out +export PAGER + +test_terminal git log [...] On the Ubuntu PPA builders, I’m seeing this new test fail with SIGPIPE about half the time: died of signal 13 at /build/buildd/git-1.9~rc1/t/test-terminal.perl line 33. not ok 6 - LESS and LV envvars are set for pagination Good catch. Sorry for the trouble. t/t7006-pager.sh | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/t/t7006-pager.sh b/t/t7006-pager.sh index 7fe3367..b9365b4 100755 --- a/t/t7006-pager.sh +++ b/t/t7006-pager.sh @@ -40,7 +40,7 @@ test_expect_failure TTY 'pager runs from subdir' ' test_expect_success TTY 'LESS and LV envvars are set for pagination' ' ( sane_unset LESS LV - PAGER=env pager-env.out + PAGER=env pager-env.out; wc export PAGER test_terminal git log -- 1.9.rc1.175.g0b1dcb5 -- 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: Feature Request Google Authenticator Support
On Thu, 2014-01-30, Erik Faye-Lund wrote: On Thu, Jan 30, 2014 at 5:07 AM, Max Rahm ac90b...@gmail.com wrote: Github supports google authenticator 2-step authentication. I enabled it and how can't figure out how to connect to my github account through git. I've looked pretty hard in the man pages and on google and can't seem to find anything on how to set up git to work with a repository with 2-step verification. Here's a link to my stackoverflow question with my exact problem if there's something I'm missing. http://stackoverflow.com/questions/21447137/git-github-not-working-with-google-authenticator-osx As far as I can tell the feature is not supported. I'd like to be able to use the 2-step authentication but obviously I'd like to be able to push my code :D This sounds like a question for the GitHub support rather than the Git community. Especially that Git prides itself that it does not do authenthication, but passes it to appropriate programs, SSH or web server (HTTP). Own git:// protocol is unathenthicated. -- Jakub Narębski -- 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: Feature Request Google Authenticator Support
Hey, On Thu, Jan 30, 2014 at 6:28 AM, Erik Faye-Lund kusmab...@gmail.com wrote: On Thu, Jan 30, 2014 at 5:07 AM, Max Rahm ac90b...@gmail.com wrote: Github supports google authenticator 2-step authentication. I enabled it and how can't figure out how to connect to my github account through git. I've looked pretty hard in the man pages and on google and can't seem to find anything on how to set up git to work with a repository with 2-step verification. Here's a link to my stackoverflow question with my exact problem if there's something I'm missing. http://stackoverflow.com/questions/21447137/git-github-not-working-with-google-authenticator-osx As far as I can tell the feature is not supported. I'd like to be able to use the 2-step authentication but obviously I'd like to be able to push my code :D This sounds like a question for the GitHub support rather than the Git community. Erik is right, for any GitHub questions, emailing supp...@github.com is way better than using this list. The answer to your question, however, is that you have to use a personal access token: https://help.github.com/articles/providing-your-2fa-security-code#through-the-command-line You can generate one from this page, in the Personal Access Tokens section: https://github.com/settings/applications 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: Running make rpm fails on a CentOS 6.3 machine
Hi, Erez Zilber wrote: Writing perl.mak for Git Writing perl.mak for Git rename MakeMaker.tmp = perl.mak: No such file or directory at /usr/share/perl5/ExtUtils/MakeMaker.pm line 1024. make[3]: perl.mak: No such file or directory make[3]: perl.mak: No such file or directory make[3]: *** No rule to make target `perl.mak'. Stop. Looks like MakeMaker is racing against itself. Alas, (on a fairly current Debian system, with perl 5.14.2) I'm not able to reproduce that. Instead, I get this: | $ make -j8 rpm [...] | make[2]: Leaving directory `$HOME/rpmbuild/BUILD/git-1.8.5.3/Documentation' | make[1]: Leaving directory `$HOME/rpmbuild/BUILD/git-1.8.5.3' | + exit 0 | Executing(%install): /bin/sh -e /var/tmp/rpm-tmp.WqNYnx | + umask 022 | + cd $HOME/rpmbuild/BUILD | + cd git-1.8.5.3 | + rm -rf $HOME/rpmbuild/BUILDROOT/git-1.8.5.3-1.x86_64 | + make -j12 'CFLAGS=-O2 -g' \ DESTDIR=$HOME/rpmbuild/BUILDROOT/git-1.8.5.3-1.x86_64 \ ETC_GITCONFIG=/etc/gitconfig prefix=/usr \ mandir=/usr/share/man htmldir=/usr/share/doc/git-1.8.5.3 \ INSTALLDIRS=vendor install install-doc | make[1]: Entering directory `$HOME/rpmbuild/BUILD/git-1.8.5.3' | make[1]: warning: -jN forced in submake: disabling jobserver mode. | make[1]: *** write jobserver: Bad file descriptor. Stop. | make[1]: *** Waiting for unfinished jobs | make[1]: *** write jobserver: Bad file descriptor. Stop. | error: Bad exit status from /var/tmp/rpm-tmp.WqNYnx (%install) | | | RPM build errors: | Bad exit status from /var/tmp/rpm-tmp.WqNYnx (%install) | make: *** [rpm] Error 1 Known problem? A build without -j8 gets further. Thanks, Jonathan -- 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: Running make rpm fails on a CentOS 6.3 machine
Hello,
Jonathan Nieder wrote:
Erez Zilber wrote:
Writing perl.mak for Git
Writing perl.mak for Git
rename MakeMaker.tmp = perl.mak: No such file or directory at /usr/share/perl5/ExtUtils/MakeMaker.pm line 1024.
make[3]: perl.mak: No such file or directory
make[3]: perl.mak: No such file or directory
make[3]: *** No rule to make target `perl.mak'. Stop.
Looks like MakeMaker is racing against itself. Alas, (on a fairly
current Debian system, with perl 5.14.2) I'm not able to reproduce that.
Instead, I get this:
| $ make -j8 rpm
[...]
| make[2]: Leaving directory `$HOME/rpmbuild/BUILD/git-1.8.5.3/Documentation'
| make[1]: Leaving directory `$HOME/rpmbuild/BUILD/git-1.8.5.3'
| + exit 0
| Executing(%install): /bin/sh -e /var/tmp/rpm-tmp.WqNYnx
| + umask 022
| + cd $HOME/rpmbuild/BUILD
| + cd git-1.8.5.3
| + rm -rf $HOME/rpmbuild/BUILDROOT/git-1.8.5.3-1.x86_64
| + make -j12 'CFLAGS=-O2 -g' \
DESTDIR=$HOME/rpmbuild/BUILDROOT/git-1.8.5.3-1.x86_64 \
ETC_GITCONFIG=/etc/gitconfig prefix=/usr \
mandir=/usr/share/man htmldir=/usr/share/doc/git-1.8.5.3 \
INSTALLDIRS=vendor install install-doc
| make[1]: Entering directory `$HOME/rpmbuild/BUILD/git-1.8.5.3'
| make[1]: warning: -jN forced in submake: disabling jobserver mode.
| make[1]: *** write jobserver: Bad file descriptor. Stop.
| make[1]: *** Waiting for unfinished jobs
| make[1]: *** write jobserver: Bad file descriptor. Stop.
| error: Bad exit status from /var/tmp/rpm-tmp.WqNYnx (%install)
|
|
| RPM build errors:
| Bad exit status from /var/tmp/rpm-tmp.WqNYnx (%install)
| make: *** [rpm] Error 1
Known problem? A build without -j8 gets further.
It seems like it's not a problem with el6 or git's Makefiles
themselves. I haven't used the spec file from git.git in ages, but I
have tried to ensure that the one we use in Fedora builds cleanly on
el{5,6}. I use this myself to keep an update git on el6, where Red
Hat has left git at 1.7.1 since the release of el6 however many years
ago. :(
Here's a build I ran just now using the latest Fedora SRPM, showing it
succeeds with make -j5:
http://kojipkgs.fedoraproject.org//work/tasks/3049/6473049/build.log
The build task, with all of the resulting rpms and logs is here:
http://koji.fedoraproject.org/koji/taskinfo?taskID=6473049
(That will remain for a few days or so, at least. Scratch builds like
this aren't kept indefinitely.)
This makes me think that there's something in the git.spec in git.git
that differs from what we use in Fedora/EPEL. I don't have time to
dig into that now, but perhaps someone with time and inclination can
diff the spec files and find the cause.
I know the Fedora/EPEL spec file and what's in git.git have grown
apart a good bit, unfortunately. That's the cost of having a spec
file that is meant to work across a very wide array of RPM-based
systems, I guess. The Fedora/EPEL spec file is fairly specific to the
Fedora/EPEL build tools (mock is the primary build tool).
Hope this helps a little in narrowing down the issue. I'm sorry
I can't be of more assistance at the moment.
--
ToddOpenPGP - KeyID: 0xBEAF0CE3 | URL: www.pobox.com/~tmz/pgp
~~
How am I supposed to hallucinate with all these swirling colors
distracting me?
-- Lisa Simpson
pgpOrbVEb8OdK.pgp
Description: PGP signature
inconsistent include behaviour for core.sharedRepository
After several days of problems with directory permissions in the objects/ directory for shared users, I finally found the cause of an issue that we have been seeing. We are working with several shared repositories. We were trying to use a shared [include] configuration that contained [core] sharedRepository = group This was not being honoured, from an included config file. Using git config, would show that core.sharedRepository was set to 'group', as expected. However, digging through setup.c I see that shared_repository is actually configured using git_config_early(), which does not use the include mechanism that git_config()/ git_config_with_options() uses. This is particularly difficult to debug given the git-config reports values that are not actually used internally. I think that git config should report the correct values, for features that are accessed via git_config_early. Otherwise it is quite difficult to understand the behaviour, without the source code. git version 1.8.2.1 on CentOS release 5.6 (Final) -- Gordon McGregor +1 512 577 9712 -- 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] Ensure __BYTE_ORDER is always set
a201c20 (ewah: support platforms that require aligned reads) added a reliance on the existence of __BYTE_ORDER and __BIG_ENDIAN. However, these macros are spelled without the leading __ on some platforms (OS X at least). In this case, the endian-swapping code was added even when unnecessary, which caused assertion failures in t5310-pack-bitmaps.sh as the code that used the bitmap would read past the end. We already had code to handle this case in compat/bswap.h, but it was only used if we couldn't already find a reasonable version of bswap64. Move the macro-defining and checking code out of a conditional so that either __BYTE_ORDER is defined or we get a compilation error instead of a runtime error in the bitmap code. Signed-off-by: Brian Gernhardt br...@gernhardtsoftware.com --- compat/bswap.h | 24 1 file changed, 12 insertions(+), 12 deletions(-) diff --git a/compat/bswap.h b/compat/bswap.h index 120c6c1..7db09d6 100644 --- a/compat/bswap.h +++ b/compat/bswap.h @@ -80,6 +80,18 @@ static inline uint64_t git_bswap64(uint64_t x) #endif +#if !defined(__BYTE_ORDER) +# if defined(BYTE_ORDER) defined(LITTLE_ENDIAN) defined(BIG_ENDIAN) +# define __BYTE_ORDER BYTE_ORDER +# define __LITTLE_ENDIAN LITTLE_ENDIAN +# define __BIG_ENDIAN BIG_ENDIAN +# endif +#endif + +#if !defined(__BYTE_ORDER) +# error Cannot determine endianness +#endif + #if defined(bswap32) #undef ntohl @@ -101,18 +113,6 @@ static inline uint64_t git_bswap64(uint64_t x) #undef ntohll #undef htonll -#if !defined(__BYTE_ORDER) -# if defined(BYTE_ORDER) defined(LITTLE_ENDIAN) defined(BIG_ENDIAN) -# define __BYTE_ORDER BYTE_ORDER -# define __LITTLE_ENDIAN LITTLE_ENDIAN -# define __BIG_ENDIAN BIG_ENDIAN -# endif -#endif - -#if !defined(__BYTE_ORDER) -# error Cannot determine endianness -#endif - #if __BYTE_ORDER == __BIG_ENDIAN # define ntohll(n) (n) # define htonll(n) (n) -- 1.9.rc0.256.gbc3fa69 -- 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 (Jan 2014, #06; Wed, 29)
From: Junio C Hamano gits...@pobox.com * po/everyday-doc (2014-01-27) 1 commit - Make 'git help everyday' work This may make the said command to emit something, My initial intention ;-) but the source is not meant to be formatted into a manual pages to begin with, and also its contents are a bit stale. True. Your $gmane240286/focus=240334 noted that the top 20 commands has probably changed as well. It may be a good first step in the right direction, but needs more work to at least get the mark-up right before public consumption. Will hold. OK. Probably a slow-time excercise for me. Other contributions welcome. 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
Re: [PATCH] Ensure __BYTE_ORDER is always set
On Thu, Jan 30, 2014 at 02:55:41PM -0500, Brian Gernhardt wrote: a201c20 (ewah: support platforms that require aligned reads) added a reliance on the existence of __BYTE_ORDER and __BIG_ENDIAN. However, these macros are spelled without the leading __ on some platforms (OS X at least). In this case, the endian-swapping code was added even when unnecessary, which caused assertion failures in t5310-pack-bitmaps.sh as the code that used the bitmap would read past the end. We already had code to handle this case in compat/bswap.h, but it was only used if we couldn't already find a reasonable version of bswap64. Move the macro-defining and checking code out of a conditional so that either __BYTE_ORDER is defined or we get a compilation error instead of a runtime error in the bitmap code. Thanks, this makes sense, and matches the assumption that a201c20 made. I do find the failure mode interesting. The endian-swapping code kicked in when it did not, meaning your are on a big-endian system. Is this on an ancient PPC Mac? Or is the problem that the code did not kick in when it should? Either way, we should perhaps be more careful in the bitmap code, too, that the values we get are sensible. It's better to die(your bitmap is broken) than to read off the end of the array. I can't seem to trigger the same failure mode, though. On my x86 system, turning off the endian-swap (i.e., the opposite of what should happen) makes t5310 fail, but it is because we end up trying to set the bit very far into a dynamic bitfield, and die allocating memory. -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] Ensure __BYTE_ORDER is always set
On Thu, Jan 30, 2014 at 03:45:38PM -0500, Jeff King wrote:
Either way, we should perhaps be more careful in the bitmap code, too,
that the values we get are sensible. It's better to die(your bitmap is
broken) than to read off the end of the array. I can't seem to trigger
the same failure mode, though. On my x86 system, turning off the
endian-swap (i.e., the opposite of what should happen) makes t5310 fail,
but it is because we end up trying to set the bit very far into a
dynamic bitfield, and die allocating memory.
I think we could do this with something like the patch below, which
checks two things:
1. When we expand the ewah, it has the same number of bits we claimed
in the on-disk header.
2. The ewah header matches the number of objects in the packfile.
The first catches a corruption in the ewah data itself, and the latter
when the header is corrupted. You can test either by breaking the
endian-swapping. :)
Vicent, can you confirm my assumptions about the round-to-nearest-64 in
the patch below? I assume that the bit_size on-disk may be rounded in
some cases (and it is -- if you take out the rounding, this breaks
things). Is that sane? Or should the on-disk ewah bit_size header always
match the number of objects in the pack, and our writer is just being
sloppy?
diff --git a/ewah/ewah_bitmap.c b/ewah/ewah_bitmap.c
index 9ced2da..a8f77cf 100644
--- a/ewah/ewah_bitmap.c
+++ b/ewah/ewah_bitmap.c
@@ -343,6 +343,18 @@ int ewah_iterator_next(eword_t *next, struct ewah_iterator
*it)
if (it-pointer = it-buffer_size)
return 0;
+ /*
+* If we return more bits than the ewah advertised, then either
+* our data bits or the bit_size field was corrupted, and we
+* risk a caller overwriting their own buffer (if they used
+* bit_size to size their buffer in the first place).
+*
+* We don't have a good way of returning an error here, so let's
+* just die.
+*/
+ if (!it-words_remaining--)
+ die(ewah bitmap contains more bits than it claims);
+
if (it-compressed it-rl) {
it-compressed++;
*next = it-b ? (eword_t)(~0) : 0;
@@ -371,6 +383,8 @@ void ewah_iterator_init(struct ewah_iterator *it, struct
ewah_bitmap *parent)
it-buffer_size = parent-buffer_size;
it-pointer = 0;
+ it-words_remaining = (parent-bit_size + 63) / 64;
+
it-lw = 0;
it-rl = 0;
it-compressed = 0;
diff --git a/ewah/ewok.h b/ewah/ewok.h
index 43adeb5..a3f49de 100644
--- a/ewah/ewok.h
+++ b/ewah/ewok.h
@@ -144,6 +144,7 @@ struct ewah_iterator {
size_t buffer_size;
size_t pointer;
+ size_t words_remaining;
eword_t compressed, literals;
eword_t rl, lw;
int b;
diff --git a/pack-bitmap.c b/pack-bitmap.c
index ae0b57b..a31e529 100644
--- a/pack-bitmap.c
+++ b/pack-bitmap.c
@@ -118,6 +118,7 @@ static struct ewah_bitmap *lookup_stored_bitmap(struct
stored_bitmap *st)
*/
static struct ewah_bitmap *read_bitmap_1(struct bitmap_index *index)
{
+ size_t expected_bits;
struct ewah_bitmap *b = ewah_pool_new();
int bitmap_size = ewah_read_mmap(b,
@@ -130,6 +131,31 @@ static struct ewah_bitmap *read_bitmap_1(struct
bitmap_index *index)
return NULL;
}
+ /*
+* It's OK for us to have too fewer bits than objects, as the EWAH
+* writer may have simply left off an ending that is all-zeroes.
+*
+* However it's not OK for us to have too many bits, as that would
+* entail touching objects that we don't have. We are careful
+* enough to avoid doing so in later code, but in the case of
+* nonsensical values, we would want to avoid even allocating
+* memory to hold the expanded bitmap.
+*
+* There is one exception: we may go over to round up to the next
+* 64-bit ewah word, since the storage comes in chunks of that size.
+*/
+ expected_bits = index-pack-num_objects;
+ if (expected_bits 63) {
+ expected_bits = ~63;
+ expected_bits += 64;
+ }
+ if (b-bit_size expected_bits) {
+ error(unexpected number of bits in bitmap: %PRIuMAX
%PRIuMAX,
+ (uintmax_t)b-bit_size, (uintmax_t)expected_bits);
+ ewah_pool_free(b);
+ return NULL;
+ }
+
index-map_pos += bitmap_size;
return b;
}
--
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] Ensure __BYTE_ORDER is always set
Hi,
Brian Gernhardt wrote:
a201c20 (ewah: support platforms that require aligned reads) added a
reliance on the existence of __BYTE_ORDER and __BIG_ENDIAN. However,
these macros are spelled without the leading __ on some platforms (OS
X at least). In this case, the endian-swapping code was added even
when unnecessary, which caused assertion failures in
t5310-pack-bitmaps.sh as the code that used the bitmap would read past
the end.
We already had code to handle this case in compat/bswap.h, but it was
only used if we couldn't already find a reasonable version of bswap64.
Makes sense. Sorry I missed this.
In an ideal world I would prefer to just rely on ntohll when it's
decent (meaning that the '#if __BYTE_ORDER != __BIG_ENDIAN' block
could be written as
if (ntohll(1) != 1) {
...
}
or
if (ntohll(1) == 1)
; /* Big endian. Nothing to do.
else {
...
}
). But compat/bswap.h already relies on knowing the endianness at
preprocessing time so that wouldn't buy anything.
Another in an ideal world option: make the loop unconditional after
checking that optimizers on big-endian systems realize it's a noop.
In any event, in the real world your patch looks like the right thing
to do.
Reviewed-by: Jonathan Nieder jrnie...@gmail.com
--
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] Ensure __BYTE_ORDER is always set
Hi, Jeff King wrote: I do find the failure mode interesting. The endian-swapping code kicked in when it did not Odd --- wouldn't the #if condition expand to '0 != 0'? -- 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] Git v1.9-rc0
On 01/28/2014 05:58 PM, Kacper Kornet wrote: On Mon, Jan 27, 2014 at 10:58:29AM -0800, Jonathan Nieder wrote: Hi, Kacper Kornet wrote: The change in release numbering also breaks down gitolite v2 setups. One of the gitolite commands, gl-compile-conf, expects the output of git --version to match /git version (\d+)\.(\d+)\.(\d+)/. I have no idea how big problem it is, as I don't know how many people hasn't migrate to gitolite v3 yet. http://qa.debian.org/popcon.php?package=gitolite says there are some. I guess soon we'll see if there are complaints. http://gitolite.com/gitolite/migr.html says gitolite v2 is still maintained. Hopefully the patch to gitolite v2 to fix this would not be too invasive --- e.g., how about this patch (untested)? Thanks, Jonathan diff --git i/src/gl-compile-conf w/src/gl-compile-conf index f497ae5..8508313 100755 --- i/src/gl-compile-conf +++ w/src/gl-compile-conf @@ -394,8 +394,9 @@ die the server. If it is not, please edit ~/.gitolite.rc on the server and set the \$GIT_PATH variable to the correct value\n unless $git_version; -my ($gv_maj, $gv_min, $gv_patchrel) = ($git_version =~ m/git version (\d+)\.(\d+)\.(\d+)/); +my ($gv_maj, $gv_min, $gv_patchrel) = ($git_version =~ m/git version (\d+)\.(\d+)\.([^.-]*)/); die $ABRT I can't understand $git_version\n unless ($gv_maj = 1); +$gv_patchrel = 0 unless ($gv_patchrel =~ m/^\d+$/); $git_version = $gv_maj*1 + $gv_min*100 + $gv_patchrel; # now it's normalised die \n\t\t* AAARGH! *\n . It works for 1.9.rc1 but I think it will fail with final 1.9. The following version should be ok: diff --git a/src/gl-compile-conf b/src/gl-compile-conf index f497ae5..c391468 100755 --- a/src/gl-compile-conf +++ b/src/gl-compile-conf @@ -394,7 +394,7 @@ die the server. If it is not, please edit ~/.gitolite.rc on the server and set the \$GIT_PATH variable to the correct value\n unless $git_version; -my ($gv_maj, $gv_min, $gv_patchrel) = ($git_version =~ m/git version (\d+)\.(\d+)\.(\d+)/); +my ($gv_maj, $gv_min, undef, $gv_patchrel) = ($git_version =~ m/git version (\d+)\.(\d+)(\.(\d+))?/); die $ABRT I can't understand $git_version\n unless ($gv_maj = 1); $git_version = $gv_maj*1 + $gv_min*100 + $gv_patchrel; # now it's normalised Gitolite v3 will be 2 years old in a month or so. I would prefer to use this as an opportunity to encourage people to upgrade; v2 really has nothing going for it now. People who cannot upgrade gitolite should simply cut that whole block of code and throw it out. Distro's should probably do that if they are still keeping gitolite v2 alive, because it is clearly not needed if the same distro is up to 1.9 of git! My policy has been to continue support for critical bugs. A bug that can be fixed by simply deleting the offending code block, with no harm done, is -- to my mind -- not critical enough :-) side note, Kacper: I'd use non-capturing parens than an undef in the destination list. -- 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] Ensure __BYTE_ORDER is always set
On Thu, Jan 30, 2014 at 02:02:33PM -0800, Jonathan Nieder wrote:
In an ideal world I would prefer to just rely on ntohll when it's
decent (meaning that the '#if __BYTE_ORDER != __BIG_ENDIAN' block
could be written as
if (ntohll(1) != 1) {
...
}
or
if (ntohll(1) == 1)
; /* Big endian. Nothing to do.
else {
...
}
). But compat/bswap.h already relies on knowing the endianness at
preprocessing time so that wouldn't buy anything.
Yes, though it would simplify things because we are depending on ntohll
being defined, rather than some obscure macros.
Another in an ideal world option: make the loop unconditional after
checking that optimizers on big-endian systems realize it's a noop.
In any event, in the real world your patch looks like the right thing
to do.
I had the same thought when reading the original patch. The loop after
pre-processing on a big-endian system should look like:
{
size_t i;
for (i = 0; i self-buffer_size; ++i)
self-buffer[i] = self-buffer[i];
}
It really seems like the sort of thing that any halfway decent compiler
should be able to turn into a noop. I'm OK to go that route, and if you
don't have a halfway decent compiler, tough cookies; git will waste your
precious nanoseconds doing a relatively small loop. If this loop
actually mattered, we would probably do better still to leave it in disk
order, and fix it up as-needed only when we look at a particular bitmap
(we do not typically need to look at all of them on disk).
-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] Ensure __BYTE_ORDER is always set
On Thu, Jan 30, 2014 at 02:12:05PM -0800, Jonathan Nieder wrote: Jeff King wrote: I do find the failure mode interesting. The endian-swapping code kicked in when it did not Odd --- wouldn't the #if condition expand to '0 != 0'? I had the same thought. The kicked in when it did not is Brian's claim from the original, which is why I was confused. He replied to me off-list, and I think he may simply have had it backwards. :) -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] Ensure __BYTE_ORDER is always set
[Re-send to include the list. Meant to hit reply all, not just reply.] On Jan 30, 2014, at 3:45 PM, Jeff King p...@peff.net wrote: I do find the failure mode interesting. The endian-swapping code kicked in when it did not, meaning your are on a big-endian system. Is this on an ancient PPC Mac? Or is the problem that the code did not kick in when it should? Erm. I was perhaps writing my analysis too quickly. I was running on a x86_64 Mac, so it wasn't included when it was supposed to be. Or whichever you said that I didn't. ;-) Either way, we should perhaps be more careful in the bitmap code, too, that the values we get are sensible. It's better to die(your bitmap is broken) than to read off the end of the array. I can't seem to trigger the same failure mode, though. On my x86 system, turning off the endian-swap (i.e., the opposite of what should happen) makes t5310 fail, but it is because we end up trying to set the bit very far into a dynamic bitfield, and die allocating memory. To be more specific, I hit an assertion failure at in ewah_iterator_next() (ewah/ewah_bitmap.c:355) when running `git rev-list --test-bitmap HEAD` (and others if I don't have it die immediately). That seems to me that there is a check to ensure it doesn't run off the end. Perhaps you have assertions disabled so hit an error somewhere else? ~~ Brian Gernhardt -- 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] Ensure __BYTE_ORDER is always set
On Thu, Jan 30, 2014 at 4:50 PM, Jeff King p...@peff.net wrote:
I think we could do this with something like the patch below, which
checks two things:
1. When we expand the ewah, it has the same number of bits we claimed
in the on-disk header.
2. The ewah header matches the number of objects in the packfile.
The first catches a corruption in the ewah data itself, and the latter
when the header is corrupted. You can test either by breaking the
endian-swapping. :)
diff --git a/pack-bitmap.c b/pack-bitmap.c
index ae0b57b..a31e529 100644
--- a/pack-bitmap.c
+++ b/pack-bitmap.c
@@ -130,6 +131,31 @@ static struct ewah_bitmap *read_bitmap_1(struct
bitmap_index *index)
return NULL;
}
+ /*
+* It's OK for us to have too fewer bits than objects, as the EWAH
s/fewer/few/
+* writer may have simply left off an ending that is all-zeroes.
+*
+* However it's not OK for us to have too many bits, as that would
+* entail touching objects that we don't have. We are careful
+* enough to avoid doing so in later code, but in the case of
+* nonsensical values, we would want to avoid even allocating
+* memory to hold the expanded bitmap.
+*
+* There is one exception: we may go over to round up to the next
+* 64-bit ewah word, since the storage comes in chunks of that size.
+*/
+ expected_bits = index-pack-num_objects;
+ if (expected_bits 63) {
+ expected_bits = ~63;
+ expected_bits += 64;
+ }
+ if (b-bit_size expected_bits) {
+ error(unexpected number of bits in bitmap: %PRIuMAX
%PRIuMAX,
+ (uintmax_t)b-bit_size, (uintmax_t)expected_bits);
+ ewah_pool_free(b);
+ return NULL;
+ }
+
index-map_pos += bitmap_size;
return b;
}
--
--
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 05/17] strbuf: add strbuf_isspace()
On Thu, Jan 30, 2014 at 1:49 AM, Christian Couder
chrisc...@tuxfamily.org wrote:
This helper function checks if a strbuf
contains only space chars or not.
Signed-off-by: Christian Couder chrisc...@tuxfamily.org
---
diff --git a/strbuf.c b/strbuf.c
index 83caf4a..2124bb8 100644
--- a/strbuf.c
+++ b/strbuf.c
@@ -124,6 +124,13 @@ void strbuf_ltrim(struct strbuf *sb)
sb-buf[sb-len] = '\0';
}
+int strbuf_isspace(struct strbuf *sb)
+{
+ char *b;
+ for (b = sb-buf; *b isspace(*b); b++);
Quoting from the strbuf documentation:
... strbufs may have embedded NULs. An strbuf is NUL
terminated for convenience, but no function in the
strbuf API actually relies on the string being free of
NULs.
So, the termination condition (*b) of this loop is questionable.
Looping from 0 to sb-len makes more sense.
+ return !*b;
Ditto for the return. This will incorrectly return 'true' if an
embedded NUL is encountered.
+}
+
struct strbuf **strbuf_split_buf(const char *str, size_t slen,
int terminator, int max)
{
--
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 12/17] strbuf: add strbuf_replace()
On Thu, Jan 30, 2014 at 1:49 AM, Christian Couder
chrisc...@tuxfamily.org wrote:
Signed-off-by: Christian Couder chrisc...@tuxfamily.org
---
diff --git a/strbuf.c b/strbuf.c
index 2124bb8..e45e513 100644
--- a/strbuf.c
+++ b/strbuf.c
@@ -197,6 +197,13 @@ void strbuf_splice(struct strbuf *sb, size_t pos, size_t
len,
strbuf_setlen(sb, sb-len + dlen - len);
}
+void strbuf_replace(struct strbuf *sb, const char *a, const char *b)
+{
+ char *ptr = strstr(sb-buf, a);
This could be 'const char *'.
+ if (ptr)
+ strbuf_splice(sb, ptr - sb-buf, strlen(a), b, strlen(b));
+}
+
void strbuf_insert(struct strbuf *sb, size_t pos, const void *data, size_t
len)
{
strbuf_splice(sb, pos, 0, data, len);
diff --git a/strbuf.h b/strbuf.h
index 02bff3a..38faf70 100644
--- a/strbuf.h
+++ b/strbuf.h
@@ -111,6 +111,9 @@ extern void strbuf_remove(struct strbuf *, size_t pos,
size_t len);
extern void strbuf_splice(struct strbuf *, size_t pos, size_t len,
const void *, size_t);
+/* first occurence of a replaced with b */
+extern void strbuf_replace(struct strbuf *, const char *a, const char *b);
Updating Documentation/technical/api-strbuf.txt to mention this new
function would be appropriate.
extern void strbuf_add_commented_lines(struct strbuf *out, const char *buf,
size_t size);
extern void strbuf_add(struct strbuf *, const void *, size_t);
--
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 02/17] trailer: process trailers from file and arguments
On Thu, Jan 30, 2014 at 1:49 AM, Christian Couder
chrisc...@tuxfamily.org wrote:
This patch implements the logic that process trailers
from file and arguments.
At the beginning trailers from file are in their own
infile_tok doubly linked list, and trailers from
arguments are in their own arg_tok doubly linked list.
The lists are traversed and when an arg_tok should be
applied, it is removed from its list and inserted
into the infile_tok list.
Signed-off-by: Christian Couder chrisc...@tuxfamily.org
---
diff --git a/trailer.c b/trailer.c
index aed25e1..e9ccfa5 100644
--- a/trailer.c
+++ b/trailer.c
@@ -46,3 +46,192 @@ static size_t alnum_len(const char *buf, size_t len)
+static void apply_arg_if_exist(struct trailer_item *infile_tok,
+ struct trailer_item *arg_tok,
+ int alnum_len)
+{
+ switch (arg_tok-conf-if_exist) {
+ case EXIST_DO_NOTHING:
+ free(arg_tok);
This is freeing arg_tok, but isn't it leaking arg_tok-conf, and
conf-name, conf-key, conf-command? Ditto for all the other
free(arg_tok) invocations elsewhere in the file.
+ break;
+ case EXIST_OVERWRITE:
+ free((char *)infile_tok-value);
+ infile_tok-value = xstrdup(arg_tok-value);
+ free(arg_tok);
+ break;
+ case EXIST_ADD:
+ add_arg_to_infile(infile_tok, arg_tok);
+ break;
+ case EXIST_ADD_IF_DIFFERENT:
+ if (check_if_different(infile_tok, arg_tok, alnum_len, 1))
+ add_arg_to_infile(infile_tok, arg_tok);
+ else
+ free(arg_tok);
+ break;
+ case EXIST_ADD_IF_DIFFERENT_NEIGHBOR:
+ if (check_if_different(infile_tok, arg_tok, alnum_len, 0))
+ add_arg_to_infile(infile_tok, arg_tok);
+ else
+ free(arg_tok);
+ break;
+ }
+}
+
+static void process_infile_tok(struct trailer_item *infile_tok,
+ struct trailer_item **arg_tok_first,
+ enum action_where where)
+{
+ struct trailer_item *arg_tok;
+ struct trailer_item *next_arg;
+
+ int tok_alnum_len = alnum_len(infile_tok-token,
strlen(infile_tok-token));
+ for (arg_tok = *arg_tok_first; arg_tok; arg_tok = next_arg) {
+ next_arg = arg_tok-next;
+ if (same_token(infile_tok, arg_tok, tok_alnum_len)
+ arg_tok-conf-where == where) {
+ /* Remove arg_tok from list */
+ remove_from_list(arg_tok, arg_tok_first);
+ /* Apply arg */
+ apply_arg_if_exist(infile_tok, arg_tok,
tok_alnum_len);
Redundant comments (saying the same thing as the code) can make the
code slightly more difficult to read.
+ /*
+* If arg has been added to infile,
+* then we need to process it too now.
+*/
+ if ((where == WHERE_AFTER ? infile_tok-next :
infile_tok-previous) == arg_tok)
+ infile_tok = arg_tok;
+ }
+ }
+}
--
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] Cleanly redefine (v)snprintf when needed.
When we detect that vsnprintf / snprintf are broken, we #define them to an alternative implementation. On OS X, stdio.h already #define's them, which causes a warning to be issued at the point we re-define them in `git-compat-util.h'. --- git-compat-util.h | 6 ++ 1 file changed, 6 insertions(+) diff --git a/git-compat-util.h b/git-compat-util.h index cbd86c3..614a5e9 100644 --- a/git-compat-util.h +++ b/git-compat-util.h @@ -480,9 +480,15 @@ extern FILE *git_fopen(const char*, const char*); #endif #ifdef SNPRINTF_RETURNS_BOGUS +#ifdef snprintf +#undef snprintf +#endif #define snprintf git_snprintf extern int git_snprintf(char *str, size_t maxsize, const char *format, ...); +#ifdef vsnprintf +#undef vsnprintf +#endif #define vsnprintf git_vsnprintf extern int git_vsnprintf(char *str, size_t maxsize, const char *format, va_list ap); -- 1.9.rc1.1.g186f0be.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
