Re: Rationale behind 'extern' on protypes in .h files
On 22.12.2013 16:51, Ravi Shekhar Jethani wrote:
Now, my real question :
1) I cannot understand the reason behind making function prototypes as
extern. What purpose does this serve? AFAIK we put definition in a .c
file and the prototype in a .h thats it.
2) Why are some prototypes in some of the .h file are extern and
others are not?
Thank you guys for reading through. Any suggestions are humbly welcome.
Ravi S. Jethani
--
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
That's an interesting question. From my understanding there is no
difference for functions declarations being set to extern or not,
because extern is the default on functions. It is however important
for variables to mark them extern if they're in a header file.
After a quick research on the web, it may be there for historical
reasons. Back then, when there were one pass compilers,
the compiler needed to know where the function is to be found.
(extern was not default at these times?)
Another reason I could make up, would be to indicate,
whether the function is in the c file having the
same name as the header file.
For example in builtin.h there are all the functions declared
extern, as the implementation of the functions are found in
builtin/*.c
In another header cache-tree.h there are function declarations
without explicit extern keyword, and the implementation
is found in the cache-tree.c file (${SAME-NAME-AS-HEADER}.C)
This is however not always the case as found in archive.{c,h}
I'd be also interested in knowing the real reason for this rationale.
Thanks,
Stefan
--
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: Verifiable git archives?
On 09.01.2014 04:10, Andy Lutomirski wrote: It's possible, in principle, to shove enough metadata into the output of 'git archive' to allow anyone to verify (without cloning the repo) to verify that the archive is a correct copy of a given commit. Would this be considered a useful feature? Do you know git bundles? Presumably there would be a 'git untar' command that would report failure if it fails to verify the archive contents. This could be as simple as including copies of the commit object and all relevant tree objects and checking all of the hashes when untarring. I thought the git archive rather had the purpose of creating plain archives not polluted with any gitish stuff. (Even better: allow subsets of the repository to be archived and verified as well.) Stefan -- 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: [msysGit] Consecutive git gc fails on Windows network share
On 20.01.2014 18:16, Torsten Bögershausen wrote: (No top-posting, please see my comments below) On 2014-01-20 15.02, Jochen wrote: On 01/16/2014 10:55 AM, Jochen Haag wrote: Hello, we want to report the following issue, because it seems to be not an intended behaviour. Maybe someone can have a look at it at some point. It is not urgent for us. After upgrading from Git version 1.8.1.msysgit.1 to 1.8.5.2.msysgit.0 we observed that a consecutive git gc fails, in case the Git repo is located on a Windows network share. Operating system used is Windows 7 64 bit SP1. In case git gc fails temporary packs and index remain in .git/objects/pack/. Consecutive means, that git gc is called on an already packed repository (e.g. git gc is called more than once). This is the output given in case of error: U:\GitEnvgit gc Counting objects: 139, done. Delta compression using up to 8 threads. Compressing objects: 100% (71/71), done. Writing objects: 100% (139/139), done. Total 139 (delta 65), reused 139 (delta 65) fatal: renaming '.git/objects/pack/.tmp-7920-pack-ad9d069e7c27ce19cc5b6cde82b4a38bedbf5884.pack' failed: Permission denied error: failed to run repack And here the output with GIT_TRACE = 1: U:\GitEnvgit gc trace: built-in: git 'gc' trace: run_command: 'pack-refs' '--all' '--prune' trace: built-in: git 'pack-refs' '--all' '--prune' trace: run_command: 'reflog' 'expire' '--all' trace: built-in: git 'reflog' 'expire' '--all' trace: run_command: 'repack' '-d' '-l' '-A' '--unpack-unreachable=2.weeks.ago' trace: built-in: git 'repack' '-d' '-l' '-A' '--unpack-unreachable=2.weeks.ago' trace: run_command: 'pack-objects' '--keep-true-parents' '--honor-pack-keep' '--non-empty' '--all' '--reflog' '--unpack-unreachable=2.weeks.ago' '--local' '--delta-base-offset' '.git/objects/pack/.tmp-7612-pack' trace: built-in: git 'pack-objects' '--keep-true-parents' '--honor-pack-keep' '--non-empty' '--all' '--reflog' '--unpack-unreachable=2.weeks.ago' '--local' '--delta-base-offset' '.git/objects/pack/.tmp-7612-pack' Counting objects: 139, done. Delta compression using up to 8 threads. Compressing objects: 100% (71/71), done. Writing objects: 100% (139/139), done. Total 139 (delta 65), reused 139 (delta 65) fatal: renaming '.git/objects/pack/.tmp-7612-pack-ad9d069e7c27ce19cc5b6cde82b4a38bedbf5884.pack' failed: Permission denied error: failed to run repack After running git gc twice, this is what is left in .git/objects/pack/: U:\GitEnv\.git\objects\packls -al total 53676 drwxr-xr-x1 hgj2fe Administ0 Jan 16 10:43 . drwxr-xr-x1 hgj2fe Administ0 Jan 14 12:52 .. -r--r--r--1 hgj2fe Administ 4964 Jan 16 10:43 .tmp-7612-pack-ad9d069e7c27ce19cc5b6cde82b4a38bedbf5884.idx -r--r--r--1 hgj2fe Administ 18315618 Jan 16 10:43 .tmp-7612-pack-ad9d069e7c27ce19cc5b6cde82b4a38bedbf5884.pack -r--r--r--1 hgj2fe Administ 4964 Jan 16 10:40 .tmp-7920-pack-ad9d069e7c27ce19cc5b6cde82b4a38bedbf5884.idx -r--r--r--1 hgj2fe Administ 18315618 Jan 16 10:40 .tmp-7920-pack-ad9d069e7c27ce19cc5b6cde82b4a38bedbf5884.pack -r--r--r--1 hgj2fe Administ 4964 Jan 14 12:52 pack-ad9d069e7c27ce19cc5b6cde82b4a38bedbf5884.idx -r--r--r--1 hgj2fe Administ 18315618 Jan 14 12:52 pack-ad9d069e7c27ce19cc5b6cde82b4a38bedbf5884.pack In case we remove the read-only flag of the pack and index manually before running git gc again, no problem occurs: U:\GitEnv\.git\objects\packgit gc trace: built-in: git 'gc' trace: run_command: 'pack-refs' '--all' '--prune' trace: built-in: git 'pack-refs' '--all' '--prune' trace: run_command: 'reflog' 'expire' '--all' trace: built-in: git 'reflog' 'expire' '--all' trace: run_command: 'repack' '-d' '-l' '-A' '--unpack-unreachable=2.weeks.ago' trace: built-in: git 'repack' '-d' '-l' '-A' '--unpack-unreachable=2.weeks.ago' trace: run_command: 'pack-objects' '--keep-true-parents' '--honor-pack-keep' '--non-empty' '--all' '--reflog' '--unpack-unreachable=2.weeks.ago' '--local' '--delta-base-offset' 'U:/GitEnv/.git/objects/pack/.tmp-3736-pack' trace: built-in: git 'pack-objects' '--keep-true-parents' '--honor-pack-keep' '--non-empty' '--all' '--reflog' '--unpack-unreachable=2.weeks.ago' '--local' '--delta-base-offset' 'U:/GitEnv/.git/objects/pack/.tmp-3736-pack' Counting objects: 139, done. Delta compression using up to 8 threads. Compressing objects: 100% (71/71), done. Writing objects: 100% (139/139), done. Total 139 (delta 65), reused 139 (delta 65) trace: run_command: 'prune-packed' trace: built-in: git 'prune-packed' trace: run_command: 'update-server-info' trace: built-in: git 'update-server-info' trace: run_command: 'prune' '--expire' '2.weeks.ago' trace: built-in: git 'prune' '--expire' '2.weeks.ago' trace: run_command: 'rerere' 'gc' trace: built-in: git 'rerere' 'gc' The problem might be related to this commit:
Re: [PATCH v2 0/2] Fix repack --window-memory=4g regression in 1.8.4
On 22.01.2014 20:58, Junio C Hamano wrote: The command line parser was broken when the command was reimplemented in C in two ways. It incorrectly limited the value range of window-memory and max-pack-size to int, and also stopped grokking the unit suffixes like 2g/400m/8k. These two patches apply on top of 35c14176 (Reword repack documentation to no longer state it's a script, 2013-10-19) and later can be merged down to maint-1.8.4 track and upwards. Junio C Hamano (2): parse-options: refactor human-friendly-integer parser out of pack-objects repack: accept larger window-memory and max-pack-size builtin/pack-objects.c | 25 - builtin/repack.c | 12 ++-- parse-options.c| 17 + parse-options.h| 5 + 4 files changed, 32 insertions(+), 27 deletions(-) I recall we had a discussion about parsing as the shell script just passed them on without altering the argument, while the new c implementation parses the numbers already before passing them on. Junio, thanks for such a quick patch. I'd currently have only little time for open source contributions. The patches seems reasonable to me. Thanks, Stefan -- 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
How to delete all merged branches?
Hi, so I tend to accumulate lots of branches as I'd do one branch per feature. When cleaning up, I'd like to delete all branches, which have been merged. I could use $ git branch -d (which was merged already?) ^C $ git branch --merged # let's find out ... $ # Now run git branch -d with each of the branches. This kind of question has already been discussed, http://stackoverflow.com/questions/6127328/how-can-i-delete-all-git-branches-which-are-already-merged suggests: git branch --merged | grep -v \* | xargs -n 1 git branch -d Now it seems as if this operation would be needed by quite a few people actually. Maybe it's time to integrate into git? I'd be interested, which way would be the most git-like way to do it. I could think of: $ git branch -d --merged # no need to specifiy a branch iff --merged is given with -d $ git branch --delete-merged# comes as an new extra option, doesn't clutter other commands $ git branch -d keyword-for-all-merged-branches Before starting such a feature, I'd like to hear input of others. Thanks, Stefan -- 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][GSOC2014] changed logical chain in branch.c to lookup tables
On 10.03.2014 20:04, TamerTas wrote:
Signed-off-by: TamerTas tamer...@outlook.com
---
branch.c | 31 ---
1 file changed, 8 insertions(+), 23 deletions(-)
diff --git a/branch.c b/branch.c
index 723a36b..397edd3 100644
--- a/branch.c
+++ b/branch.c
@@ -50,6 +50,9 @@ static int should_setup_rebase(const char *origin)
void install_branch_config(int flag, const char *local, const char *origin,
const char *remote)
{
const char *shortname = remote + 11;
+ const char *location[] = {local, remote};
+ const char *type[] = {branch, ref};
+
int remote_is_branch = starts_with(remote, refs/heads/);
struct strbuf key = STRBUF_INIT;
int rebasing = should_setup_rebase(origin);
@@ -77,29 +80,11 @@ void install_branch_config(int flag, const char *local,
const char *origin, cons
strbuf_release(key);
if (flag BRANCH_CONFIG_VERBOSE) {
- if (remote_is_branch origin)
- printf_ln(rebasing ?
- _(Branch %s set up to track remote branch %s
from %s by rebasing.) :
- _(Branch %s set up to track remote branch %s
from %s.),
- local, shortname, origin);
- else if (remote_is_branch !origin)
- printf_ln(rebasing ?
- _(Branch %s set up to track local branch %s
by rebasing.) :
- _(Branch %s set up to track local branch
%s.),
- local, shortname);
- else if (!remote_is_branch origin)
- printf_ln(rebasing ?
- _(Branch %s set up to track remote ref %s by
rebasing.) :
- _(Branch %s set up to track remote ref %s.),
- local, remote);
- else if (!remote_is_branch !origin)
- printf_ln(rebasing ?
- _(Branch %s set up to track local ref %s by
rebasing.) :
- _(Branch %s set up to track local ref %s.),
- local, remote);
- else
- die(BUG: impossible combination of %d and %p,
- remote_is_branch, origin);
+
+printf_ln(rebasing ?
+ _(Branch %s set up to track %s %s %s by rebasing.) :
+ _(Branch %s set up to track %s %s %s.),
+ local, location[!origin], type[remote_is_branch], remote);
}
}
This one is neat, I'd favor this one as opposed to the one posted
earlier today.
Acked-by: Stefan Beller stefanbel...@googlemail.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: Our official home page and logo for the Git project
So this is really bikeshedding at its finest. I'd personally do agree on the logo proposed in the first mail by Junio. However who is the core community, who am I to judge? So maybe the decision process on this issue may need a more centrally steered opinion, so why not call for votes and weight the votes by #number of commits in git.git? 2014-04-13 10:53 GMT+02:00 Javier Domingo Cansino javier...@gmail.com: I think it is a suitable logo. It might not be the one I would think of, but I see with good eyes using it as one of the project logos. Javier Domingo Cansino -- 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 -- 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 is missing from Git v2.0
I don't even think we need to query the user to fill out all of the fields. We can prepopulate a lot of the fields (name, e-mail address, etc.) from OS specific defaults that are available on most systems --- specifically, the default values we would use the name and e-mail address are not specified in a config file. Please don't. Or you end up again with Commiters like sb@localhost, sbeller@(None) or alike. I mean it's just one question once you setup a new computer, so I'd really like to see that question and then answer myself (at university/employer I might put in another email address than at home anyway, and I'm sure my boxes have no sane defaults) 2014-04-24 15:41 GMT+02:00 Theodore Ts'o ty...@mit.edu: On Thu, Apr 24, 2014 at 03:23:54AM -0500, Felipe Contreras wrote: There is evidence for the claim that there won't be those problems. You have absolutely no evidence there there will. Felipe, It's clear that you've not been able to produce evidence that can convince most of the people on this thread. Simply repeating the same assertions over and over again, in a shrill fashion, is not likely to convince those of us who that this would not be a good idea for git v2.0. Creating a ~/.gitconfig file if one doesn't already is one I agree with, and at least on Unix systems, telling them that the config file lives in ~/.gitconfig, or where ever it might happen to be on other platforms, is a good one. If it's in some really weird place on Windows, then sure, we can tell them about git config -e. But the point is to let the user look at the default .gitconfig file, where we can put in comments to help explain what is going on, and perhaps have links to web pages for more information. I don't even think we need to query the user to fill out all of the fields. We can prepopulate a lot of the fields (name, e-mail address, etc.) from OS specific defaults that are available on most systems --- specifically, the default values we would use the name and e-mail address are not specified in a config file. We can just tell the user that we have created a default .gitconfig file, and tell them how they can take a look at it. In the long term, if the worry is how to bridge the gap between complete newbies, one way of dealing with this is to have a tutorial mode (off by default, on in the default .gitconfig) which despenses some helpful hints at certain strategic points (i.e., after five commits, give a message that introduces git log --oneline, after the third merge commit is created by the user, give a message which introduces git log --merge, and so on). The challenge is not strawing over the line to the point where the hints become as annoying as clippy, but that is what UX labs are for, to tune the experience for completely new users to git. Without doing a formal UX experiment, all of us are going to making assertions without formal evidence --- at best some of us who have tutored a few newbies might have some anecdates, but remember the old saying about the plural of anecdote not being data. Cheers, - Ted -- 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 -- 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 is missing from Git v2.0
I may have missunderstood. So today you cannot commit if you don't provide an email address (usually the first time you try to commit, git asks to git config --global author.email=y...@mail.here), if I remember correctly, so there is definitely a valid (i.e. user approved) email address. 2014-04-24 17:47 GMT+02:00 ty...@mit.edu: On Thu, Apr 24, 2014 at 05:00:13PM +0200, Stefan Beller wrote: I don't even think we need to query the user to fill out all of the fields. We can prepopulate a lot of the fields (name, e-mail address, etc.) from OS specific defaults that are available on most systems --- specifically, the default values we would use the name and e-mail address are not specified in a config file. Please don't. Or you end up again with Commiters like sb@localhost, sbeller@(None) or alike. I mean it's just one question once you setup a new computer, so I'd really like to see that question and then answer myself (at university/employer I might put in another email address than at home anyway, and I'm sure my boxes have no sane defaults) But that's no worse than what we have today. What if we print what the defaults were, which might help encourage the user to actually run the git config -e command? - Ted -- 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 4/8] CodingGuidelines: give an example for control statements
On 30.04.2014 23:45, Junio C Hamano wrote: Signed-off-by: Junio C Hamano gits...@pobox.com --- Documentation/CodingGuidelines | 11 +++ 1 file changed, 11 insertions(+) diff --git a/Documentation/CodingGuidelines b/Documentation/CodingGuidelines index 1e0c4cf..d72e912 100644 --- a/Documentation/CodingGuidelines +++ b/Documentation/CodingGuidelines @@ -97,6 +97,17 @@ For shell scripts specifically (not exhaustive): then should be on the next line for if statements, and do should be on the next line for while and for. + (incorrect) At the other patches you used #comments behind oneliners, not sure if that's also suitable here for consistency of the documentation. + if test -f hello; then + do this + fi + + (correct) + if test -f hello + then + do this + fi + - We prefer test over [ ... ]. - We do not write the noiseword function in front of shell -- 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: Big Java repositories to play with?
On 07.05.2014 15:23, Duy Nguyen wrote: I need some big Java repos (over 100k files) to test git status. Actually any repos with long path names and deep/wide directory structure are fine, not only Java ones. Right now I'm aware of gentoo-x86 and webkit. Let me know if you know some others. I'm afraid my Google-foo is not strong enough to search these repos. I believe LibreOffice could do? (Just a guess, maybe I'm wrong) https://www.libreoffice.org/about-us/source-code/ git clone http://anongit.freedesktop.org/git/libreoffice/core.git -- 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: Big Java repositories to play with?
On 07.05.2014 15:38, Stefan Beller wrote: On 07.05.2014 15:23, Duy Nguyen wrote: I need some big Java repos (over 100k files) to test git status. Actually any repos with long path names and deep/wide directory structure are fine, not only Java ones. Right now I'm aware of gentoo-x86 and webkit. Let me know if you know some others. I'm afraid my Google-foo is not strong enough to search these repos. I believe LibreOffice could do? (Just a guess, maybe I'm wrong) https://www.libreoffice.org/about-us/source-code/ git clone http://anongit.freedesktop.org/git/libreoffice/core.git Just tested, just 68k files, so it doesn't meet your requirement. -- 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: Big Java repositories to play with?
On 07.05.2014 16:01, Ævar Arnfjörð Bjarmason wrote:
On Wed, May 7, 2014 at 3:23 PM, Duy Nguyen pclo...@gmail.com wrote:
I need some big Java repos (over 100k files) to test git status.
Actually any repos with long path names and deep/wide directory
structure are fine, not only Java ones. Right now I'm aware of
gentoo-x86 and webkit. Let me know if you know some others. I'm afraid
my Google-foo is not strong enough to search these repos.
1. Take a small repo with a small src directory
2. for i in {1..100}; do cp -Rvp src src-$i; done
3. git add src-*; git commit -mbigger
For some value of 100 you'll end up with a big repo to test git status on.
You just need lots of files to stat(), git status doesn't care about
history, so there's no reason why you need to track down an existing
large repository.
As you may have anomalies of one repo reproduced 100 times then,
it may be better to use 100 different projects?
There is http://gittup.org/gittup/ which is an entire linux distribution
packed into one git repo, but all the individual
projects (kernel, nethack etc) are subprojects. Maybe instead of
having them as subprojects you could add all of them into one large repo?
Also you could just do a git init in your home directory?
--
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 v1 25/25] contrib: remove 'mw-to-git'
On 09.05.2014 12:59, Felipe Contreras wrote: Matthieu Moy wrote: Felipe Contreras felipe.contre...@gmail.com writes: No chance of ever graduating. I see no relationship between the chance of graduating and the removal from contrib/. Read contrib/README. If you want to remove mw-to-git from contrib, then a good starting point would be to explain why you want to do so in the commit message. The purpose of the contrib area is to either a) give visibility to otherwise potentially ignored scripts b) serve a staging area for features before moving into the core. This script doesn't match either of those. It doesn't belong in the contrib/ area. Maybe we could split it a little bit. Similar to the kernel there is a staging area. Ok there are some features, which are not yet promoted to mainline, some never will. But some things like examples/ could be moved out to another directory. (How about Documentation/historicEncounters/ ?) Also we could think about renaming contrib to staging then. However I don't think it's urgent. -- 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 v1 00/25] contrib: cleanup
For discussing these larger changes in the first version you may want to use the -D option of git format-patch? 2014-05-09 4:01 GMT+02:00 Felipe Contreras felipe.contre...@gmail.com: Martin Langhoff wrote: On Thu, May 8, 2014 at 8:58 PM, Felipe Contreras felipe.contre...@gmail.com wrote: Let us be honest, the vast majority of tools in 'contrib/' have no chance of ever graduating, so let's remove them. I am curious -- have you checked what parts of contrib downstreams packageship? I have checked a few, not throughly. From what I can see most of them just copy everything to /usr/share/git without much consideration to what is actually there. The only exception is the shell completions. Are you planning on CC'ing the (inactive) authors/maintainers so they know that if they care they should host those elsewhere? They are already Cc'ed. My candid opinion is that you're trying to force a group of people to undertake a pointless exercise. Contrib in many/most projects is uneven, and folks know that. But it gives upstream a chance to push for some minimal quality, and in turn it gives visibility to a bunch of sometimes useful tools. Yes, but that's not what our contrib/ is supposed to be. Read conrib/README. If my code was going to get the axe, I'd be rather pissed off. If Junio is in agreement that code quality is bad, or tools should have unit tests, then the push could be to address the problem or face removal. For example: contrib maintainer, show you're responsive to bug reports on the list, or face removal; add unit tests (or explain why they aren't needed) or face removal. That's right, and they are Cc'ed so they can respond. Some tools have only one commit or two, and in those I didn't even bother Cc'ing anyone. Moreover, it's not enough that they are actively maintained. Accoding to Junio they need to show that they can't work properly out-of-tree, and thus there's a need for them to be in contrib/. Or they are temporarily in contrib/ so they can become part of the core. That doesn't apply to the tools I proposed to remove here. -- Felipe Contreras -- 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 -- 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 v1 19/25] contrib: remove 'diff-highlight'
It is serious. The purpose of the 'contrib/' area is not clear. The statemens coming from Junio don't match what is on 'contrib/README'. So we have a huge variance of quality all over 'contrib/'. Some tools in contrib have higher quality than what is part of the core (e.g. they have tests, while git-archimport doesn't). How about rewriting the README then? Also as I said in another mail, we could split up the contrib/ area into multiple areas with narrow defined use-cases, i.e. staging/, Documentation/historicTools (the current contrib/examples section), 3rdPartyTools/, Bridges/ (for cooperating with other VCS). So this is a serious attempt at making sure we remain consistent through the core and contrib/. Personally I would like to see everything in contrib/ have *at least* some tests and documentation. Otherwise we know what's going to happen; they are going to rot and nobody will care that the tools don't work any more, or they won't even know what they do and how to use them. -- 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: Should git-remote-hg/bzr be part of the core?
2014-05-12 10:12 GMT+02:00 Felipe Contreras felipe.contre...@gmail.com: Felipe Contreras wrote: Linus Torvalds wrote: Felipe, stop this stupid blaming of everybody but yourself. Show me evidence that this decision was my fault. Junio certainly hasn't said so. You just have no idea what we are talking about. Here, let me show you. I suspect Linus had a reason not to include the mailing lists in the first place and make a huge public discussion, but instead wrote to you personally. I guess this is just Linus desire not to waste the time of everybody as he learned that these discussions are fruitless sometimes. Junio C Hamano wrote [in another thread]: I would not mind asking the others, as your discussion tactic seems to be repeated voices start sounding like a chorus, and a chorus is project concensus. Those who are observing from the sideline, please raise your hand if you think the three-line Clarification Felipe gave us is a fair and accurate clarification. Anybody? I also do not mind seeing hands raised of those who do not agree, even though I already know that they would be a silent majority. I think Junio is behaving very professional unlike you, Felipe. This includes being polite and very patient. Also this includes weighting different reasons to make informed rational decisions. Git being a project widely used and people trusting it for their work needs to have high quality and cannot go left today and go right tomorrow, but most of the decisions are done long-term. Felipe, this may be the reason, why you think nothing changes. It's just slower than you'd like, but with more thoughts weighted. Junio, I think you're doing an awesome job in maintaining Git and leading the community. Stefan -- 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: Should git-remote-hg/bzr be part of the core?
2014-05-12 15:45 GMT+02:00 Paolo Ciarrocchi paolo.ciarroc...@gmail.com: No, sorry but I'm NOT interested in lying to git community. It's not lying. See the Helped-By: lines in git.git commits. Often the help was formulating a correct and easy-to-understand commit message. -- 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/8] Speed up cache loading time
That is clocked at 800 MHz. A repository at this size deserves a better CPU. At 2.5 GHz we spend 183.228ms on loading the index. A reasonable number to me. If we scale other parts of git-status as well as this, we should be able to make git status within 1 or 2 seconds. Which harddrive do you use? Traditional or SSDs? Does have harddrive loading time significant impact here? (just a guess/question) -- 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] various contrib: Fix links in man pages
Inspired by 2147fa7e (2014-07-31 git-push: fix link in man page), I grepped through the whole tree searching for 'gitlink:' occurrences. Signed-off-by: Stefan Beller stefanbel...@gmail.com --- contrib/convert-objects/git-convert-objects.txt | 2 +- contrib/examples/git-svnimport.txt | 2 +- contrib/gitview/gitview.txt | 2 +- 3 files changed, 3 insertions(+), 3 deletions(-) diff --git a/contrib/convert-objects/git-convert-objects.txt b/contrib/convert-objects/git-convert-objects.txt index 0565d83..f871880 100644 --- a/contrib/convert-objects/git-convert-objects.txt +++ b/contrib/convert-objects/git-convert-objects.txt @@ -26,4 +26,4 @@ Documentation by David Greaves, Junio C Hamano and the git-list git@vger.kernel GIT --- -Part of the gitlink:git[7] suite +Part of the linkgit:git[7] suite diff --git a/contrib/examples/git-svnimport.txt b/contrib/examples/git-svnimport.txt index 3bb871e..3f0a9c3 100644 --- a/contrib/examples/git-svnimport.txt +++ b/contrib/examples/git-svnimport.txt @@ -176,4 +176,4 @@ Documentation by Matthias Urlichs sm...@smurf.noris.de. GIT --- -Part of the gitlink:git[7] suite +Part of the linkgit:git[7] suite diff --git a/contrib/gitview/gitview.txt b/contrib/gitview/gitview.txt index 9e12f97..7b5f900 100644 --- a/contrib/gitview/gitview.txt +++ b/contrib/gitview/gitview.txt @@ -28,7 +28,7 @@ OPTIONS args:: - All the valid option for gitlink:git-rev-list[1]. + All the valid option for linkgit:git-rev-list[1]. Key Bindings -- 2.1.0.rc0.52.gaa544bf -- 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] clone.c: don't leak memory in cmd_clone
Free the refspec. Found by scan.coverity.com (Id: 1127806) Signed-off-by: Stefan Beller stefanbel...@gmail.com --- builtin/clone.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/builtin/clone.c b/builtin/clone.c index bbd169c..dd4092b 100644 --- a/builtin/clone.c +++ b/builtin/clone.c @@ -1004,5 +1004,7 @@ int cmd_clone(int argc, const char **argv, const char *prefix) strbuf_release(key); strbuf_release(value); junk_mode = JUNK_LEAVE_ALL; + + free(refspec); return err; } -- 2.1.0.rc2 -- 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] remote.c: don't leak the base branch name in format_tracking_info
Found by scan.coverity.com (Id: 1127809) Signed-off-by: Stefan Beller stefanbel...@gmail.com --- remote.c | 1 + 1 file changed, 1 insertion(+) diff --git a/remote.c b/remote.c index 3d6c86a..2c1458f 100644 --- a/remote.c +++ b/remote.c @@ -1983,6 +1983,7 @@ int format_tracking_info(struct branch *branch, struct strbuf *sb) strbuf_addf(sb, _( (use \git pull\ to merge the remote branch into yours)\n)); } + free(base); return 1; } -- 2.1.0.rc2 -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/2] remote.c: don't leak the base branch name in format_tracking_info
On 10.08.2014 15:57, Stefan Beller wrote: Found by scan.coverity.com (Id: 1127809) Signed-off-by: Stefan Beller stefanbel...@gmail.com --- remote.c | 1 + 1 file changed, 1 insertion(+) diff --git a/remote.c b/remote.c index 3d6c86a..2c1458f 100644 --- a/remote.c +++ b/remote.c @@ -1983,6 +1983,7 @@ int format_tracking_info(struct branch *branch, struct strbuf *sb) strbuf_addf(sb, _( (use \git pull\ to merge the remote branch into yours)\n)); } + free(base); return 1; } Upon testing this one again, I get a warning remote.c: In function ‘format_tracking_info’: remote.c:1986:2: warning: passing argument 1 of ‘free’ discards ‘const’ qualifier from pointer target type [enabled by default] free(base); ^ In file included from git-compat-util.h:103:0, from cache.h:4, from remote.c:1: /usr/include/stdlib.h:483:13: note: expected ‘void *’ but argument is of type ‘const char *’ extern void free (void *__ptr) __THROW; ^ Please ignore this patch. -- 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: Unify subcommand structure; introduce double dashes for all subcommands?
On 23.07.2014 19:52, Junio C Hamano wrote: Stefan Beller stefanbel...@gmail.com writes: A git command is generally setup as: git command [subcommand] [options] ... The subcommands vary wildly by the nature of the command. However all subcommands could at least follow one style. The commands bundle, notes, stash and submodule have subcommands without two leading dashes (i.e. git stash list) as opposed to all other commands (i.e. git tag --list). Sounds familiar. E.g. here is a similar thread about a year ago. http://thread.gmane.org/gmane.comp.version-control.git/231376/focus=231478 Further discussions to make the plan more concrete is very much welcomed. Thanks. So I'd want to add have the subcommands without double dashes ideally. It's just less typing and more english like, not cryptic with dashes. This may come handy for newcomers/beginners using git. It also benefits the powerusers of git as you spare the typing of 2 dashes on the subcommand. I'm currently trying to understand the functions to parse options and I wonder if the following is possible: If there is an option set by OPT_CMDMODE (such as git tag --delete / --verify) we want to add an internal option, (such as PARSE_OPT_NODASH ?), that you can deliver this CMD_MODE option without leading 2 dashes. The current behavior with leading 2 dashes is still supported, but maybe a warning is printed about deprecating the option with 2 dashes. Having this change in place will switch over revert, replace, tag and merge-base to having sane subcommands without dashes possible. Once this change is in, we can rewrite the other commands, which as of now don't require the dashes. Coincidentally these commands heavily rely on option parsing themselves, such as git-notes having this code in place: if (argc 1 || !strcmp(argv[0], list)) result = list(argc, argv, prefix); else if (!strcmp(argv[0], add)) result = add(argc, argv, prefix); else if (!strcmp(argv[0], copy)) result = copy(argc, argv, prefix); ... Does that make sense? Stefan -- 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] remote.c: don't leak the base branch name in format_tracking_info
Found by scan.coverity.com (Id: 1127809)
Signed-off-by: Stefan Beller stefanbel...@gmail.com
---
remote.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/remote.c b/remote.c
index 3d6c86a..894db09 100644
--- a/remote.c
+++ b/remote.c
@@ -1920,7 +1920,7 @@ int stat_tracking_info(struct branch *branch, int
*num_ours, int *num_theirs)
int format_tracking_info(struct branch *branch, struct strbuf *sb)
{
int ours, theirs;
- const char *base;
+ char *base;
int upstream_is_gone = 0;
switch (stat_tracking_info(branch, ours, theirs)) {
@@ -1936,8 +1936,7 @@ int format_tracking_info(struct branch *branch, struct
strbuf *sb)
break;
}
- base = branch-merge[0]-dst;
- base = shorten_unambiguous_ref(base, 0);
+ base = shorten_unambiguous_ref(branch-merge[0]-dst, 0);
if (upstream_is_gone) {
strbuf_addf(sb,
_(Your branch is based on '%s', but the upstream is
gone.\n),
@@ -1983,6 +1982,7 @@ int format_tracking_info(struct branch *branch, struct
strbuf *sb)
strbuf_addf(sb,
_( (use \git pull\ to merge the remote
branch into yours)\n));
}
+ free(base);
return 1;
}
--
2.1.0.rc2
--
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: Unify subcommand structure; introduce double dashes for all subcommands?
On 10.08.2014 20:13, Junio C Hamano wrote: Stefan Beller stefanbel...@gmail.com writes: On 23.07.2014 19:52, Junio C Hamano wrote: Sounds familiar. E.g. here is a similar thread about a year ago. http://thread.gmane.org/gmane.comp.version-control.git/231376/focus=231478 Further discussions to make the plan more concrete is very much welcomed. Thanks. So I'd want to add have the subcommands without double dashes ideally. That is not ideal at all, I am afraid. A command that started only with its primary operating mode, e.g. git tag [-s|-a] tagname [object], may have to gain I do not want to create, I just want to list and the way to signal that has to be an option that cannot be mistaken as its valid first argument (to avoid git tag list that cannot create a tag called list, we use git tag --list). You could add an entirely new command git foo that always takes the command-mode word, i.e. git foo mode$n args, but you will be typing the operating mode name all the time only to save --mode$n for 2=$n, which may not be a good economy in the end. Please do not go there. I see your point. However how often do you really want to create a tag called list? As of now it's easy: git tag list and for listing all tags you'd need to type: git tag --list and if you want to create a tag called --list, I'd assume you'd go git tag -- --list # However: fatal: '--list' is not a valid tag name. So even as of now certain tag names cannot be done easily. Also you have to type two more dashes for an action you'd probably want to perform more often (as opposed to creating a tag 'list') In my (ideal) world we'd rather have this behavior: git tag list # behaves the same as git tag Now creating a tag called 'list' is not as easy, because 'list' is a primary operating mode name, so we need to tell git we're actually meaning the name as opposed to the operating mode: git tag create -- list # or even git tag create -- --list Anyways despite my arguing, it seems you rather want to rather have the leading double dashes everywhere for the operating modes? So the plan is to not touch the parsing, but to adjust notes and stash ? Thanks, Stefan -- 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] blame.c: Add translation to warning about failed revision walk
blame belonging to the group of
ancillaryinterrogators and not to plumbinginterrogators
should have localized error messages?
Signed-off-by: Stefan Beller stefanbel...@gmail.com
---
builtin/blame.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/builtin/blame.c b/builtin/blame.c
index 17d30d0..ca4ba6f 100644
--- a/builtin/blame.c
+++ b/builtin/blame.c
@@ -2700,7 +2700,7 @@ parse_done:
* uninteresting.
*/
if (prepare_revision_walk(revs))
- die(revision walk setup failed);
+ die(_(revision walk setup failed));
if (is_null_sha1(sb.final-object.sha1)) {
o = sb.final-util;
--
2.1.0.rc2
--
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] prepare_revision_walk: Check for return value in all places
Even the documentation tells us:
You should check if it
returns any error (non-zero return code) and if it does not, you can
start using get_revision() to do the iteration.
In preparation for this commit, I grepped all occurrences of
prepare_revision_walk and added error messages, when there were none.
Signed-off-by: Stefan Beller stefanbel...@gmail.com
---
builtin/branch.c | 4 +++-
builtin/commit.c | 3 ++-
remote.c | 3 ++-
3 files changed, 7 insertions(+), 3 deletions(-)
diff --git a/builtin/branch.c b/builtin/branch.c
index 0591b22..ced422b 100644
--- a/builtin/branch.c
+++ b/builtin/branch.c
@@ -653,7 +653,9 @@ static int print_ref_list(int kinds, int detached, int
verbose, int abbrev, stru
add_pending_object(ref_list.revs,
(struct object *) filter, );
ref_list.revs.limited = 1;
- prepare_revision_walk(ref_list.revs);
+
+ if (prepare_revision_walk(ref_list.revs))
+ die(_(revision walk setup failed));
if (verbose)
ref_list.maxwidth = calc_maxwidth(ref_list);
}
diff --git a/builtin/commit.c b/builtin/commit.c
index 7867768..bb84e1d 100644
--- a/builtin/commit.c
+++ b/builtin/commit.c
@@ -1055,7 +1055,8 @@ static const char *find_author_by_nickname(const char
*name)
revs.mailmap = mailmap;
read_mailmap(revs.mailmap, NULL);
- prepare_revision_walk(revs);
+ if (prepare_revision_walk(revs))
+ die(revision walk setup failed);
commit = get_revision(revs);
if (commit) {
struct pretty_print_context ctx = {0};
diff --git a/remote.c b/remote.c
index 894db09..112e4d5 100644
--- a/remote.c
+++ b/remote.c
@@ -1893,7 +1893,8 @@ int stat_tracking_info(struct branch *branch, int
*num_ours, int *num_theirs)
init_revisions(revs, NULL);
setup_revisions(rev_argc, rev_argv, revs, NULL);
- prepare_revision_walk(revs);
+ if (prepare_revision_walk(revs))
+ die(revision walk setup failed);
/* ... and count the commits on each side. */
*num_ours = 0;
--
2.1.0.rc2
--
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: How to give permission to another user on my git remote
On 11.08.2014 13:41, Jagan Teki wrote: Hi, I have created one repository (but I'm not a root user on the server) like $ git init --bare And I do push my changes locally to remote repo where I created. My friend also working the same repo, and he needs to push the changes on the same. I tried by adding below line on the remote config file [config] sharedRepository = true Any help, how to do that. Please see http://git-scm.com/book/en/Git-on-the-Server-Getting-Git-on-a-Server to explore different ways how to use git on a server. Stefan -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/2] prepare_revision_walk: Check for return value in all places
On 11.08.2014 21:09, Junio C Hamano wrote:
Stefan Beller stefanbel...@gmail.com writes:
Even the documentation tells us:
You should check if it
returns any error (non-zero return code) and if it does not, you can
start using get_revision() to do the iteration.
In preparation for this commit, I grepped all occurrences of
prepare_revision_walk and added error messages, when there were none.
Thanks. One niggling thing is that I do not seem to find a way for
the function to actually return an error without dying in it, but
these are independently good changes.
Signed-off-by: Stefan Beller stefanbel...@gmail.com
---
builtin/branch.c | 4 +++-
builtin/commit.c | 3 ++-
remote.c | 3 ++-
3 files changed, 7 insertions(+), 3 deletions(-)
diff --git a/builtin/branch.c b/builtin/branch.c
index 0591b22..ced422b 100644
--- a/builtin/branch.c
+++ b/builtin/branch.c
@@ -653,7 +653,9 @@ static int print_ref_list(int kinds, int detached, int
verbose, int abbrev, stru
add_pending_object(ref_list.revs,
(struct object *) filter, );
ref_list.revs.limited = 1;
-prepare_revision_walk(ref_list.revs);
+
+if (prepare_revision_walk(ref_list.revs))
+die(_(revision walk setup failed));
if (verbose)
ref_list.maxwidth = calc_maxwidth(ref_list);
}
diff --git a/builtin/commit.c b/builtin/commit.c
index 7867768..bb84e1d 100644
--- a/builtin/commit.c
+++ b/builtin/commit.c
@@ -1055,7 +1055,8 @@ static const char *find_author_by_nickname(const char
*name)
revs.mailmap = mailmap;
read_mailmap(revs.mailmap, NULL);
-prepare_revision_walk(revs);
+if (prepare_revision_walk(revs))
+die(revision walk setup failed);
Just reviewed the patch myself and here in commit.c we should have a
localized version, right?
Should I resend the patch with the localisation or could you just amend
that?
commit = get_revision(revs);
if (commit) {
struct pretty_print_context ctx = {0};
diff --git a/remote.c b/remote.c
index 894db09..112e4d5 100644
--- a/remote.c
+++ b/remote.c
@@ -1893,7 +1893,8 @@ int stat_tracking_info(struct branch *branch, int
*num_ours, int *num_theirs)
init_revisions(revs, NULL);
setup_revisions(rev_argc, rev_argv, revs, NULL);
-prepare_revision_walk(revs);
+if (prepare_revision_walk(revs))
+die(revision walk setup failed);
/* ... and count the commits on each side. */
*num_ours = 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
[PATCH] unpack-tree.c: remove dead code
In line 1763 of unpack-tree.c we have a condition on the current tree
if (current) {
...
Within this block of code we can assume current to be non NULL, hence
the code after the statement in line 1796:
if (current)
return ...
cannot be reached.
The proposed patch here changes the order of the current tree and the
newtree part. I'm not sure if that's the right way to handle it.
All referenced lines have been introduced in the same commit
076b0adc (2006-07-30, read-tree: move merge functions to the library),
which was just moving the code around.
The outer condition on the current tree (now in line 1763) was introduced
in c859600954df4c292e, June 2005, [PATCH] read-tree: save more user hassles
during fast-forward.
The inner condition on the current tree was introduced in
ee6566e8d70da682ac4926d, Sept. 2005, [PATCH] Rewrite read-tree
This issue was found by coverity, Id:290002
Signed-off-by: Stefan Beller stefanbel...@gmail.com
---
unpack-trees.c | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
diff --git a/unpack-trees.c b/unpack-trees.c
index c6aa8fb..e6d37ff 100644
--- a/unpack-trees.c
+++ b/unpack-trees.c
@@ -1793,11 +1793,10 @@ int twoway_merge(const struct cache_entry * const *src,
/* all other failures */
if (oldtree)
return o-gently ? -1 : reject_merge(oldtree,
o);
- if (current)
- return o-gently ? -1 : reject_merge(current,
o);
if (newtree)
return o-gently ? -1 : reject_merge(newtree,
o);
- return -1;
+ /* current is definitely exists here */
+ return o-gently ? -1 : reject_merge(current, o);
}
}
else if (newtree) {
--
2.1.0.rc2
--
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] mailsplit.c: remove dead code
This was found by coverity. (Id: 290001) the variable 'output' is only assigned to a value inequal to NUL, after all gotos to the corrupt label. Therefore we can conclude the two removed lines are actually dead code. Signed-off-by: Stefan Beller stefanbel...@gmail.com --- builtin/mailsplit.c | 2 -- 1 file changed, 2 deletions(-) diff --git a/builtin/mailsplit.c b/builtin/mailsplit.c index 06296d4..b499014 100644 --- a/builtin/mailsplit.c +++ b/builtin/mailsplit.c @@ -93,8 +93,6 @@ static int split_one(FILE *mbox, const char *name, int allow_bare) return status; corrupt: - if (output) - fclose(output); unlink(name); fprintf(stderr, corrupt mailbox\n); exit(1); -- 2.1.0.rc2 -- 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] unpack-tree.c: remove dead code
In line 1763 of unpack-tree.c we have a condition on the current tree
if (current) {
...
Within this block of code we can assume current to be non NULL, hence
the code after the statement in line 1796:
if (current)
return ...
cannot be reached.
current/newtree/oldtree are used in the
call to reject_merge() *only* for their path aka ce-name, and they
all point at the same name (there is no rename funkies here); hence
all other failures code path should just rely on current always
being present.
All referenced lines have been introduced in the same commit
076b0adc (2006-07-30, read-tree: move merge functions to the library),
which was just moving the code around.
The outer condition on the current tree (now in line 1763) was introduced
in c859600954df4c292e, June 2005, [PATCH] read-tree: save more user hassles
during fast-forward.
The inner condition on the current tree was introduced in
ee6566e8d70da682ac4926d, Sept. 2005, [PATCH] Rewrite read-tree
This issue was found by coverity, Id:290002
Signed-off-by: Stefan Beller stefanbel...@gmail.com
Helped-by: Junio C Hamano gits...@pobox.com
---
unpack-trees.c | 12
1 file changed, 4 insertions(+), 8 deletions(-)
Did I understand you right, when changing to this one?
diff --git a/unpack-trees.c b/unpack-trees.c
index c6aa8fb..42ee84e 100644
--- a/unpack-trees.c
+++ b/unpack-trees.c
@@ -1789,15 +1789,11 @@ int twoway_merge(const struct cache_entry * const *src,
/* 20 or 21 */
return merged_entry(newtree, current, o);
}
+ else if (o-gently) {
+ return -1 ;
+ }
else {
- /* all other failures */
- if (oldtree)
- return o-gently ? -1 : reject_merge(oldtree,
o);
- if (current)
- return o-gently ? -1 : reject_merge(current,
o);
- if (newtree)
- return o-gently ? -1 : reject_merge(newtree,
o);
- return -1;
+ reject_merge(current, o);
}
}
else if (newtree) {
--
2.1.0.rc2
--
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] mailsplit.c: remove dead code
This was found by coverity. (Id: 290001)
The variable 'output' is assigned to a value
after all gotos to the corrupt label.
Remove the goto by moving the errorhandling code to the
condition, which detects the error.
Signed-off-by: Stefan Beller stefanbel...@gmail.com
Helped-by: René Scharfe l@web.de
---
builtin/mailsplit.c | 17 ++---
1 file changed, 6 insertions(+), 11 deletions(-)
If I understood correctly, this is what you had in mind?
Thanks,
Stefan
diff --git a/builtin/mailsplit.c b/builtin/mailsplit.c
index 06296d4..763cda0 100644
--- a/builtin/mailsplit.c
+++ b/builtin/mailsplit.c
@@ -53,14 +53,16 @@ static int keep_cr;
*/
static int split_one(FILE *mbox, const char *name, int allow_bare)
{
- FILE *output = NULL;
+ FILE *output;
int fd;
int status = 0;
int is_bare = !is_from_line(buf.buf, buf.len);
- if (is_bare !allow_bare)
- goto corrupt;
-
+ if (is_bare !allow_bare) {
+ unlink(name);
+ fprintf(stderr, corrupt mailbox\n);
+ exit(1);
+ }
fd = open(name, O_WRONLY | O_CREAT | O_EXCL, 0666);
if (fd 0)
die_errno(cannot open output file '%s', name);
@@ -91,13 +93,6 @@ static int split_one(FILE *mbox, const char *name, int
allow_bare)
}
fclose(output);
return status;
-
- corrupt:
- if (output)
- fclose(output);
- unlink(name);
- fprintf(stderr, corrupt mailbox\n);
- exit(1);
}
static int populate_maildir_list(struct string_list *list, const char *path)
--
2.1.0.rc2
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/3] Re: [PATCH] unpack-tree.c: remove dead code
On 13.08.2014 01:57, Jonathan Nieder wrote:
Stefan Beller wrote:
In line 1763 of unpack-tree.c we have a condition on the current tree
[...]
The description is describing why the patch is *correct* (i.e., not
going to introduce a bug), while what the reader wants to know is why
the change is *desirable*.
Indeed. Thanks for the reminder!
Is this about making the code more readable, or robust, or suppressing
a static analysis error, or something else? What did the user or
reader want to do that they couldn't do before and now can after this
patch?
In my opinion it's making the code easier to read as there are less
lines of code with less conditionals.
The supression of a static code analysis warning is rather a desired
side effect, but not the main reason for the patch.
[...]
--- a/unpack-trees.c
+++ b/unpack-trees.c
@@ -1789,15 +1789,11 @@ int twoway_merge(const struct cache_entry * const
*src,
/* 20 or 21 */
return merged_entry(newtree, current, o);
}
+else if (o-gently) {
+return -1 ;
+}
(not about this patch) Elsewhere git uses the 'cuddled else':
Yes, I intentionally used this style, as the surrounding code was
using this style. You already added the reformatting follow up patch,
thanks!
if (foo) {
...
} else if (bar) {
...
} else {
...
}
That stylefix would be a topic for a different patch, though.
else {
-/* all other failures */
-if (oldtree)
-return o-gently ? -1 : reject_merge(oldtree,
o);
-if (current)
-return o-gently ? -1 : reject_merge(current,
o);
-if (newtree)
-return o-gently ? -1 : reject_merge(newtree,
o);
-return -1;
Does the static analysis tool support comments like
if (oldtree)
...
if (current)
...
...
/* not reached */
return -1;
? That might be the simplest minimally invasive fix for what coverity
pointed out.
I was looking for things like that, but either the
extensive documentation is well hidden or there is only short
tutorial-like documentation, which doesn't cover this case.
Now that we're looking there, though, it's worth understanding why we
do the 'if oldtree exists, use it, else fall back to, etc' thing. Was
this meant as futureproofing in case commands like 'git checkout' want
to do rename detection some day?
Everywhere else in the file that reject_merge is used, it is as
return o-gently ? -1 : reject_merge(..., o);
The one exception is
!current
oldtree
newtree
oldtree != newtree
!initial_checkout
(#17), which seems like a bug (it should have the same check). Would
it make sense to inline the o-gently check into reject_merge so callers
don't have to care?
In that spirit, I suspect the simplest fix would be
else
return o-gently ? -1 : reject_merge(current, o);
and then all calls could be replaced in a followup patch.
Sensible?
I need to read more code to follow.
Thanks for picking up my inital patch and improving. :)
Stefan
Thanks,
Jonathan Nieder (2):
unpack-trees: use 'cuddled' style for if-else cascade
checkout -m: attempt merge when deletion of path was staged
Stefan Beller (1):
unpack-trees: simplify 'all other failures' case
unpack-trees.c | 31 ++-
1 file changed, 10 insertions(+), 21 deletions(-)
--
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 00/18] Signed push
On 20.08.2014 00:06, Junio C Hamano wrote: While signed tags and commits assert that the objects thusly signed came from you, who signed these objects, there is not a good way to assert that you wanted to have a particular object at the tip of a particular branch. My signing v2.0.1 tag only means I want to call the version v2.0.1, and it does not mean I want to push it out to my 'master' branch---it is likely that I only want it in 'maint', so the signature on the object alone is insufficient. The only assurance to you that 'maint' points at what I wanted to place there comes from your trust on the hosting site and my authentication with it, which cannot easily audited later. This series introduces a cryptographic assurance for ref updates done by git push by introducing a mechanism that allows you to sign a push certificate (for the lack of better name) every time you push. Think of it as working on an axis orthogonal to the traditional signed tags. What kind of additional benefit do we gain? (i.e. why?) The described problem, the lacking auditability of what's pushed at which time, could be worked around like this: Whenever you do a push, you just tag the latest commit in that branch. So there would be tags like: master_2014_08_21 master_2014_08_22 ... maint_2014_08_13 maint_2014_08_21 and so on. Whenever there is no tag at the tip of the branch, we'd know there is something wrong. My guess would be usability as tagging so many branches is cumbersome for a maintainer? Looking at my made-up workaround again: That would produce lots of tags. So I could imagine there would also be lots of push certs. The number of push certs would roughly scale linear to time passed. May this result in slowness over time? Does this patch series mean, we'd get another object type (additional to blobs, commits, tags, trees)? I did not read the code yet, it's just first thoughts, so this weigh this input lightly. Stefan -- 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 00/18] Signed push
On 22.08.2014 22:03, Junio C Hamano wrote: Stefan Beller stefanbel...@gmail.com writes: So there would be tags like: master_2014_08_21 master_2014_08_22 ... maint_2014_08_13 maint_2014_08_21 and so on. Whenever there is no tag at the tip of the branch, we'd know there is something wrong. Who creates that tag? My guess would be usability as tagging so many branches is cumbersome for a maintainer? -- 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 00/18] Signed push
On 22.08.2014 22:33, Junio C Hamano wrote: Stefan Beller stefanbel...@gmail.com writes: On 22.08.2014 22:03, Junio C Hamano wrote: Stefan Beller stefanbel...@gmail.com writes: So there would be tags like: master_2014_08_21 master_2014_08_22 ... maint_2014_08_13 maint_2014_08_21 and so on. Whenever there is no tag at the tip of the branch, we'd know there is something wrong. Who creates that tag? My guess would be usability as tagging so many branches is cumbersome for a maintainer? Did you answer my question? Who creates these tags? It would be up to the one who pushes, the user, or in our case you! This way of working would require the informal notion of 'always tag the last commit before pushing.' As I wrote in the first email, I made up this workaround and wanted to see, what's so bad about that workaround and how to overcome the problems. And all I could find was a burden on the maintainer/user. Sorry, Stefan -- 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 00/18] Signed push
On 23.08.2014 00:32, Junio C Hamano wrote: Stefan Beller stefanbel...@gmail.com writes: On 22.08.2014 22:33, Junio C Hamano wrote: Stefan Beller stefanbel...@gmail.com writes: On 22.08.2014 22:03, Junio C Hamano wrote: Stefan Beller stefanbel...@gmail.com writes: So there would be tags like: master_2014_08_21 master_2014_08_22 ... maint_2014_08_13 maint_2014_08_21 and so on. Whenever there is no tag at the tip of the branch, we'd know there is something wrong. Who creates that tag? My guess would be usability as tagging so many branches is cumbersome for a maintainer? Did you answer my question? Who creates these tags? It would be up to the one who pushes, the user, or in our case you! ... As I wrote in the first email, I made up this workaround and wanted to see, what's so bad about that workaround and how to overcome the problems. And all I could find was a burden on the maintainer/user. burden is not an issue, as I'll be signing the push certificate anyway when I push. A signed tag or a signed commit and signed push certificate solves two completely separate and orthogonal issues. What happens if you break into GitHub or k.org and did $ git tag maint_2014_08_22 master_2014_08_22 Ok, I personally haven't used tags a lot. I just tried to git tag -s testbreaktag v2.1.0 git show testbreaktag # However it would still read: tag v2.1.0 Tagger: Junio C Hamano gits...@pobox.com Date: Fri Aug 15 15:09:28 2014 -0700 So as I do not posess your private key I could not create signed tags even if I were to break into github/k.org to create an extra tag out of the tag signed by me? If you want, you could also remove the original while at it. Considering I'm in the hosting server, could I delete the push cert as well? Now that I deleted the push certificate, I could pretend Junio just forgot to sign the push cert today and we're back at the tag solution? Ah wait! the subsequent push certs would not match, I'd need to delete them as well. The goal is to let us validate without having to trust the hosting site, its management and its software, which is what creates the tag there, controls where the tag sits in refs/ hierarchy and how it is shown to the outside world. Ok, I got the goal. :) Thanks for your patience, Stefan -- 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] bisect: save heap memory. allocate only the required amount
On 24.08.2014 16:17, Arjun Sreedharan wrote:
Find and allocate the required amount instead of
allocating extra 100 bytes
Signed-off-by: Arjun Sreedharan arjun...@gmail.com
---
bisect.c | 7 +--
1 file changed, 5 insertions(+), 2 deletions(-)
diff --git a/bisect.c b/bisect.c
index d6e851d..c96aab0 100644
--- a/bisect.c
+++ b/bisect.c
@@ -215,10 +215,13 @@ static struct commit_list *best_bisection_sorted(struct
commit_list *list, int n
}
qsort(array, cnt, sizeof(*array), compare_commit_dist);
for (p = list, i = 0; i cnt; i++) {
- struct name_decoration *r = xmalloc(sizeof(*r) + 100);
+ char name[100];
Would it make sense to convert the 'name' into a git strbuf?
Please have a look at Documentation/technical/api-strbuf.txt
+ sprintf(name, dist=%d, array[i].distance);
+ int name_len = strlen(name);
+ struct name_decoration *r = xmalloc(sizeof(*r) + name_len);
struct object *obj = (array[i].commit-object);
- sprintf(r-name, dist=%d, array[i].distance);
+ memcpy(r-name, name, name_len + 1);
r-next = add_decoration(name_decoration, obj, r);
p-item = array[i].commit;
p = p-next;
--
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: [RFC] improving advice message from git commit during a merge
On 27.08.2014 20:23, Junio C Hamano wrote: I am not doing this myself soon, though. Hint, hint... I asked once upon a time, if there was a place, which collects such topics for casual contributors and new comers. Would you mind to update the leftover bits at http://git-blame.blogspot.de/search?q=leftoverby-date=true ? Thanks, Stefan -- 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 v2 19/19] signed push: fortify against replay attacks
On 22.08.2014 22:30, Junio C Hamano wrote:
@@ -1226,12 +1232,28 @@ static int delete_only(struct command *commands)
return 1;
}
+static char *prepare_push_cert_nonce(const char *sitename, const char *dir)
+{
+ struct strbuf buf = STRBUF_INIT;
+ unsigned char sha1[20];
+
+ if (!sitename) {
+ static char buf[1024];
+ gethostname(buf, sizeof(buf));
+ sitename = buf;
+ }
+ strbuf_addf(buf, %s:%s:%lu, sitename, dir, time(NULL));
+ hash_sha1_file(buf.buf, buf.len, blob, sha1);
+ return xstrdup(sha1_to_hex(sha1));
+}
+
On every other use of gethostname within git.git we're
checking the return code. And if gethostname fails, we're
either copying in 'localhost' or 'unknown' instead.
Does that make sense here as well?
Found by coverity scan.
Thanks,
Stefan
--
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 v2] use a hashmap to make remotes faster
On 29.07.2014 16:43, Patrick Reynolds wrote:
Remotes are stored as an array, so looking one up or adding one without
duplication is an O(n) operation. Reading an entire config file full of
remotes is O(n^2) in the number of remotes. For a repository with tens of
thousands of remotes, the running time can hit multiple minutes.
Hash tables are way faster. So we add a hashmap from remote name to
struct remote and use it for all lookups. The time to add a new remote to
a repo that already has 50,000 remotes drops from ~2 minutes to 1
second.
We retain the old array of remotes so iterators proceed in config-file
order.
Signed-off-by: Patrick Reynolds patrick.reyno...@github.com
---
mark function with no arguments as taking void
remote.c | 63 ++-
remote.h | 3 +++
2 files changed, 49 insertions(+), 17 deletions(-)
diff --git a/remote.c b/remote.c
index a0701f6..52533e4 100644
--- a/remote.c
+++ b/remote.c
@@ -42,6 +42,7 @@ struct rewrites {
static struct remote **remotes;
static int remotes_alloc;
static int remotes_nr;
+static struct hashmap remotes_hash;
static struct branch **branches;
static int branches_alloc;
@@ -136,26 +137,51 @@ static void add_url_alias(struct remote *remote, const
char *url)
add_pushurl_alias(remote, url);
}
+struct remotes_hash_key {
+ const char *str;
+ int len;
+};
+
+static int remotes_hash_cmp(const struct remote *a, const struct remote *b,
const struct remotes_hash_key *key)
+{
+ if (key)
+ return strncmp(a-name, key-str, key-len) ||
a-name[key-len];
+ else
+ return strcmp(a-name, b-name);
+}
+
+static inline void init_remotes_hash(void)
+{
+ if (!remotes_hash.cmpfn)
+ hashmap_init(remotes_hash, (hashmap_cmp_fn)remotes_hash_cmp,
0);
+}
+
static struct remote *make_remote(const char *name, int len)
{
- struct remote *ret;
- int i;
+ struct remote *ret, *replaced;
+ struct remotes_hash_key lookup;
+ struct hashmap_entry lookup_entry;
- for (i = 0; i remotes_nr; i++) {
- if (len ? (!strncmp(name, remotes[i]-name, len)
-!remotes[i]-name[len]) :
- !strcmp(name, remotes[i]-name))
- return remotes[i];
- }
+ if (!len)
+ len = strlen(name);
+
+ init_remotes_hash();
+ lookup.str = name;
+ lookup.len = len;
+ hashmap_entry_init(lookup_entry, memhash(name, len));
+
+ if ((ret = hashmap_get(remotes_hash, lookup_entry, lookup)) != NULL)
+ return ret;
ret = xcalloc(1, sizeof(struct remote));
ret-prune = -1; /* unspecified */
ALLOC_GROW(remotes, remotes_nr + 1, remotes_alloc);
remotes[remotes_nr++] = ret;
- if (len)
- ret-name = xstrndup(name, len);
- else
- ret-name = xstrdup(name);
+ ret-name = xstrndup(name, len);
+
+ hashmap_entry_init(ret, lookup_entry.hash);
+ replaced = hashmap_put(remotes_hash, ret);
+ assert(replaced == NULL); /* no previous entry overwritten */
return ret;
}
@@ -722,13 +748,16 @@ struct remote *pushremote_get(const char *name)
int remote_is_configured(const char *name)
{
- int i;
+ struct remotes_hash_key lookup;
+ struct hashmap_entry lookup_entry;
read_config();
- for (i = 0; i remotes_nr; i++)
- if (!strcmp(name, remotes[i]-name))
- return 1;
- return 0;
+ init_remotes_hash();
+ lookup.str = name;
+ lookup.len = strlen(name);
+ hashmap_entry_init(lookup_entry, memhash(name, lookup.len));
+
+ return hashmap_get(remotes_hash, lookup_entry, lookup) != NULL;
}
int for_each_remote(each_remote_fn fn, void *priv)
diff --git a/remote.h b/remote.h
index 917d383..81cb5ff 100644
--- a/remote.h
+++ b/remote.h
@@ -1,6 +1,7 @@
#ifndef REMOTE_H
#define REMOTE_H
+#include hashmap.h
#include parse-options.h
enum {
@@ -10,6 +11,8 @@ enum {
};
struct remote {
+ struct hashmap_entry ent; /* must be first */
+
I stumbled about this comment /* must be first */
when reading the changelog.
Why does it need to be first?
Is it a common reason I'm just not aware of,
or would it make sense to put the reason into the comment as well?
Thanks,
Stefan
const char *name;
int origin;
--
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] repack: call prune_packed_objects() and update_server_info() directly
On 13.09.2014 09:28, René Scharfe wrote:
Call the functions behind git prune-packed and git update-server-info
directly instead of using run_command(). This is shorter, easier and
quicker.
Signed-off-by: Rene Scharfe l@web.de
Thanks for cleaning up the literal rewrite of the shell script
and making it look more like a C program.
Reviewed-by: Stefan Beller stefanbel...@gmail.com
---
builtin/repack.c | 23 ++-
1 file changed, 6 insertions(+), 17 deletions(-)
diff --git a/builtin/repack.c b/builtin/repack.c
index fc088db..2aae05d 100644
--- a/builtin/repack.c
+++ b/builtin/repack.c
@@ -377,6 +377,7 @@ int cmd_repack(int argc, const char **argv, const char
*prefix)
/* End of pack replacement. */
if (delete_redundant) {
+ int opts = 0;
sort_string_list(names);
for_each_string_list_item(item, existing_packs) {
char *sha1;
@@ -387,25 +388,13 @@ int cmd_repack(int argc, const char **argv, const char
*prefix)
if (!string_list_has_string(names, sha1))
remove_redundant_pack(packdir, item-string);
}
- argv_array_push(cmd_args, prune-packed);
- if (quiet)
- argv_array_push(cmd_args, --quiet);
-
- memset(cmd, 0, sizeof(cmd));
- cmd.argv = cmd_args.argv;
- cmd.git_cmd = 1;
- run_command(cmd);
- argv_array_clear(cmd_args);
+ if (!quiet isatty(2))
+ opts |= PRUNE_PACKED_VERBOSE;
+ prune_packed_objects(opts);
}
- if (!no_update_server_info) {
- argv_array_push(cmd_args, update-server-info);
- memset(cmd, 0, sizeof(cmd));
- cmd.argv = cmd_args.argv;
- cmd.git_cmd = 1;
- run_command(cmd);
- argv_array_clear(cmd_args);
- }
+ if (!no_update_server_info)
+ update_server_info(0);
remove_temporary_files();
string_list_clear(names, 0);
string_list_clear(rollback, 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
[PATCH] help: Fix size passed to qsort
We actually want to have the size of one 'name' and not the size of the names array. Signed-off-by: Stefan Beller stefanbel...@gmail.com --- help.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/help.c b/help.c index 7af65e2..2072a87 100644 --- a/help.c +++ b/help.c @@ -305,7 +305,7 @@ const char *help_unknown_cmd(const char *cmd) add_cmd_list(main_cmds, aliases); add_cmd_list(main_cmds, other_cmds); qsort(main_cmds.names, main_cmds.cnt, - sizeof(main_cmds.names), cmdname_compare); + sizeof(*main_cmds.names), cmdname_compare); uniq(main_cmds); /* This abuses cmdname-len for levenshtein distance */ -- 2.1.0.238.gce1d3a9 -- 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] t9300-fast-import: fix typo in test description
Signed-off-by: Stefan Beller stefanbel...@gmail.com --- t/t9300-fast-import.sh | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/t/t9300-fast-import.sh b/t/t9300-fast-import.sh index 8a05449..8df0445 100755 --- a/t/t9300-fast-import.sh +++ b/t/t9300-fast-import.sh @@ -2866,7 +2866,7 @@ test_expect_success 'S: notemodify with garbage after sha1 dataref must fail' ' # # notemodify, mark in commit-ish # -test_expect_success 'S: notemodify with garbarge after mark commit-ish must fail' ' +test_expect_success 'S: notemodify with garbage after mark commit-ish must fail' ' test_must_fail git fast-import --import-marks=marks -EOF 2err commit refs/heads/Snotes committer $GIT_COMMITTER_NAME $GIT_COMMITTER_EMAIL $GIT_COMMITTER_DATE -- 2.1.0.238.gce1d3a9 -- 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] t6031-test-merge-recursive: Forgot to add file to be committed
Signed-off-by: Stefan Beller stefanbel...@gmail.com --- t/t6031-merge-recursive.sh | 1 + 1 file changed, 1 insertion(+) diff --git a/t/t6031-merge-recursive.sh b/t/t6031-merge-recursive.sh index a953f1b..6464a16 100755 --- a/t/t6031-merge-recursive.sh +++ b/t/t6031-merge-recursive.sh @@ -13,6 +13,7 @@ test_expect_success 'mode change in one branch: keep changed version' ' git commit -m a git checkout -b b1 master test_chmod +x file1 + git add file1 git commit -m b1 git checkout a1 git merge-recursive master -- a1 b1 -- 2.1.0.238.gce1d3a9 -- 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] merge-recursive: Fix copy-paste mistake
The following issue was found by scan.coverity.com (ID: 1049510), and claimed to be likely a copy-paste mistake. Introduced in 331a1838b (2010-07-02, Try normalizing files to avoid delete/modify conflicts when merging), which is quite a long time ago, so I'm rather unsure if it's of any impact or just went unnoticed. The line after the changed line has a comparison of 'o.len' to 'a.len', so we should assume the lengths may be different. I'd be happy to have a test for this bug(?) attached to t6031-merge-recursive.sh, but I did not manage to come up with a test in a reasonable amount of time. Signed-off-by: Stefan Beller stefanbel...@gmail.com --- merge-recursive.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/merge-recursive.c b/merge-recursive.c index 22315c3..d63524c 100644 --- a/merge-recursive.c +++ b/merge-recursive.c @@ -1555,7 +1555,7 @@ static int blob_unchanged(const unsigned char *o_sha, * unchanged since their sha1s have already been compared. */ if (renormalize_buffer(path, o.buf, o.len, o) | - renormalize_buffer(path, a.buf, o.len, a)) + renormalize_buffer(path, a.buf, a.len, a)) ret = (o.len == a.len !memcmp(o.buf, a.buf, o.len)); error_return: -- 2.1.0.238.gce1d3a9 -- 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: How to compile Git with NDK?
On 22.09.2014 21:04, Robert Dailey wrote: I run the following on Ubuntu: fe@BLD01:~/code/git$ autoconf fe@BLD01:~/code/git$ ./configure --prefix=/home/fe/git-arm --build=x86_64-linux-gnu --host=arm-linux-androideabi configure: Setting lib to 'lib' (the default) configure: Will try -pthread then -lpthread to enable POSIX Threads. configure: CHECKS for site configuration checking for arm-linux-androideabi-gcc... arm-linux-androideabi-gcc checking whether the C compiler works... no configure: error: in `/home/fe/code/git': configure: error: C compiler cannot create executables See `config.log' for more details I have my NDK's prebuilt GCC 4.8 toolchain on PATH (the bin folder). Can someone help me cross compile Git using Android NDK toolchain? Thanks. You don't need autoconf, just type 'make' and you'll be fine. Please read the file INSTALL for installation instructions. Stefan -- 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] de.po: Fixup one translation
English grammar with German words doesn't make it a German translation. ;) We also need to fix the Signed-off-by: Stefan Beller stefanbel...@gmail.com --- po/de.po | 8 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/po/de.po b/po/de.po index e5d2b25..bae3723 100644 --- a/po/de.po +++ b/po/de.po @@ -3463,13 +3463,13 @@ msgid_plural \n %s\n msgstr[0] -Warnung: Sie sind um %d Commit hinterher, nicht verbunden zu\n -einem Ihrer Branches:\n +Warnung: Sie sind um %d Commit hinterher, folgende Commits sind in\n +keinem Ihrer Branches enthalten: \n \n %s\n msgstr[1] -Warnung: Sie sind um %d Commits hinterher, nicht verbunden zu\n -einem Ihrer Branches:\n +Warnung: Sie sind um %d Commits hinterher, folgende Commits sind in\n +keinem Ihrer Branches enthalten: \n \n %s\n -- 2.1.0.238.gce1d3a9 -- 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] de.po: Fixup one translation
On 23.09.2014 10:06, Eric Sunshine wrote: On Tue, Sep 23, 2014 at 3:37 AM, Stefan Beller stefanbel...@gmail.com wrote: English grammar with German words doesn't make it a German translation. ;) We also need to fix the Sentence fragment. Yeah, originally I intended to just fix the singular form and let the plural form slip. But then I did both singular and plural form and forgot about the already started commit message. Anyways I'd assume Ralf will incorporate this patch in a larger patch for the German translation, so the commit message for this particular patch is of minor relevance. Thanks, Stefan Signed-off-by: Stefan Beller stefanbel...@gmail.com --- po/de.po | 8 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/po/de.po b/po/de.po index e5d2b25..bae3723 100644 --- a/po/de.po +++ b/po/de.po @@ -3463,13 +3463,13 @@ msgid_plural \n %s\n msgstr[0] -Warnung: Sie sind um %d Commit hinterher, nicht verbunden zu\n -einem Ihrer Branches:\n +Warnung: Sie sind um %d Commit hinterher, folgende Commits sind in\n +keinem Ihrer Branches enthalten: \n \n %s\n msgstr[1] -Warnung: Sie sind um %d Commits hinterher, nicht verbunden zu\n -einem Ihrer Branches:\n +Warnung: Sie sind um %d Commits hinterher, folgende Commits sind in\n +keinem Ihrer Branches enthalten: \n \n %s\n -- 2.1.0.238.gce1d3a9 -- 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] de.po: Fixup one translation
English grammar with German words doesn't make it a German translation. ;) Signed-off-by: Stefan Beller stefanbel...@gmail.com --- Here we go again without sentence fragments. Thanks, Stefan po/de.po | 8 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/po/de.po b/po/de.po index e5d2b25..bae3723 100644 --- a/po/de.po +++ b/po/de.po @@ -3463,13 +3463,13 @@ msgid_plural \n %s\n msgstr[0] -Warnung: Sie sind um %d Commit hinterher, nicht verbunden zu\n -einem Ihrer Branches:\n +Warnung: Sie sind um %d Commit hinterher, folgende Commits sind in\n +keinem Ihrer Branches enthalten: \n \n %s\n msgstr[1] -Warnung: Sie sind um %d Commits hinterher, nicht verbunden zu\n -einem Ihrer Branches:\n +Warnung: Sie sind um %d Commits hinterher, folgende Commits sind in\n +keinem Ihrer Branches enthalten: \n \n %s\n -- 2.1.0.238.gce1d3a9 -- 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] merge-recursive: Remove miss leading comment
Commented code, which doesn't even compile, is of no use any more?
Signed-off-by: Stefan Beller stefanbel...@gmail.com
---
To be applied on top of sb/merge-recursive-copy-paste-fix
merge-recursive.c | 4
1 file changed, 4 deletions(-)
diff --git a/merge-recursive.c b/merge-recursive.c
index d63524c..8ad4be8 100644
--- a/merge-recursive.c
+++ b/merge-recursive.c
@@ -1686,10 +1686,6 @@ static int merge_content(struct merge_options *o,
static int process_entry(struct merge_options *o,
const char *path, struct stage_data *entry)
{
- /*
- printf(processing entry, clean cache: %s\n, index_only ? yes: no);
- print_index_entry(\tpath: , entry);
- */
int clean_merge = 1;
int normalize = o-renormalize;
unsigned o_mode = entry-stages[1].mode;
--
2.1.0.238.gce1d3a9
--
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: Fix a critical bug in git-cvsexportcommit.perl
On 24.09.2014 10:32, Luke Lee wrote:
I fixed a long standing bug in git-cvsexportcommit.perl script which
corrupt my Perl code several times. This time I figure it out. It's
about keyword expansion. Take a simple example, a Perl code like this:
printf Perl/Tk $Tk::Version ($Tk::platform)\n;
will be incorrectly unexpand by git-cvsexportcommit.perl to:
printf Perl/Tk $Tk$Tk::platform)\n;
This happens when I try to export a git commit to a CVS working
directory *with keyword expansion turned off*. git-cvsexportcommit will
try to simulate what CVS does on unexpanding keywords. However, it *DOES
NOT* realize only valid keywords should be unexpanded. Please help apply
this patch.
Thanks.
Luke Lee
Thanks for sending a patch. :)
From a33096156e376924d3a7ac2b5a42877f9aedee58 Mon Sep 17 00:00:00 2001
From: Luke Lee luke.yx@gmail.com
Date: Wed, 24 Sep 2014 14:38:17 +0800
Subject: [PATCH] Fix a critical bug in git-cvsexportcommit.perl about
unexpanding keywords which incorrectly delete codes that are not expanded
keywords.
Please have a look at Documentation/SubmittingPatches,
also found online at
https://github.com/git/git/blob/master/Documentation/SubmittingPatches
Specially look at section (2) Describe your changes well.
So the headline could be shorter and then in the body of the commit
message you may want to be more descriptive
Also look at section (5) Sign your work
This is to make sure you're legally allowed to send in the patch,
i.e. you're doing it on your own time or your employer allowed you to
send code here to the mailing list.
---
git-cvsexportcommit.perl | 2 +-
1 file changed, 1 insertions(+), 1 deletion(-)
diff --git a/git-cvsexportcommit.perl b/git-cvsexportcommit.perl
index d13f02d..bf41a72 100755
--- a/git-cvsexportcommit.perl
+++ b/git-cvsexportcommit.perl
@@ -309,7 +309,8 @@ foreach my $f (@files) {
while (FILTER_IN)
{
my $line = $_;
- $line =~ s/\$([A-Z][a-z]+):[^\$]+\$/\$$1\$/g;
+ $line =~
s/\$(Author|Date|Header|Id|Locker|Log|RCSfile|Revision|Source|State):[^:\$][^\$]+\$/\$$1\$/g;
print FILTER_OUT $line;
}
close FILTER_IN;
--
2.1.1.303.ga330961.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
--
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] merge-recursive: Fix copy-paste mistake
On 21.09.2014 22:49, Stefan Beller wrote:
I'd be happy to have a test for this bug(?) attached to
t6031-merge-recursive.sh, but I did not manage to
come up with a test in a reasonable amount of time.
So I am just sending out my progress on the testing for this
as I may be short on time within the next days/weeks.
If anyone is interested to write a test for this one,
you may pickup (parts of) the following.
At first a rough script, which makes sure the code in question
is executed.
--8--
#!/bin/sh
# for repetitive testing, delete everything:
rm -rf .git file .gitattributes file_with_more_descriptive_name
git init
# run the actual test
git commit --allow-empty -m 'initial'
echo -n content of file: '\r\n' file
echo -n line 1 '\r\n' file
echo -n line 2 '\r\n' file
git add file
git commit -m 'commit file with \r\n line endings'
git checkout -b secondbranch
git rm file
git commit -m eventually rm file
git checkout master
echo content of file: file
echo line 1 file
echo line 2 file
echo file text=auto .gitattributes
git add file .gitattributes
git commit -m Add text=auto to .gitattributes; Normalize file ending
git add file
git commit -m 'save file with \r\f line ending'
echo
echo
echo
echo
git merge secondbranch -m merging branches with (modify/delete); modify caused
only by normalisation -X renormalize
--8--
Here comes a patch, to be applied to git.git,
which puts printfs all over the place, visualizing the code flow
From 1985955b3ab2bad5ac73cbee92d19f63cdbaa3c9 Mon Sep 17 00:00:00 2001
From: Stefan Beller stefanbel...@gmail.com
Date: Wed, 24 Sep 2014 14:51:55 +0200
Subject: [PATCH] lots of printfs for debugging [PATCH] merge-recursive: Fix
copy-paste mistake
---
merge-recursive.c | 52 +++-
1 file changed, 51 insertions(+), 1 deletion(-)
diff --git a/merge-recursive.c b/merge-recursive.c
index 8ad4be8..9b09a67 100644
--- a/merge-recursive.c
+++ b/merge-recursive.c
@@ -1541,10 +1541,22 @@ static int blob_unchanged(const unsigned char *o_sha,
struct strbuf a = STRBUF_INIT;
int ret = 0; /* assume changed for safety */
+ printf(in blob_unchanged path=%s\n, path);
+
+
if (sha_eq(o_sha, a_sha))
return 1;
+ else
+ printf(continue as o_sha and a_sha are different\n);
+
if (!renormalize)
return 0;
+ else
+ printf(continue as not to renormalize\n);
+
+ printf(testing the patch\n);
+
+
assert(o_sha a_sha);
if (read_sha1_strbuf(o_sha, o) || read_sha1_strbuf(a_sha, a))
@@ -1554,6 +1566,27 @@ static int blob_unchanged(const unsigned char *o_sha,
* performed. Comparison can be skipped if both files are
* unchanged since their sha1s have already been compared.
*/
+
+ printf(o.len %d a.len %d\n, o.len, a.len);
+ printf(o.buf=|%s|\n a.buf=|%s|\n, o.buf, a.buf);
+ struct strbuf dsta = STRBUF_INIT;
+ struct strbuf dsto = STRBUF_INIT;
+
+ renormalize_buffer(path, a.buf, a.len, dsta);
+ printf(dsta=|%s|\n,dsta.buf);
+ renormalize_buffer(path, a.buf, a.len, dsta);
+ printf(dsta=|%s|\n,dsta.buf);
+
+
+ renormalize_buffer(path, o.buf, o.len, dsto);
+ printf(dsto=|%s|\n,dsto.buf);
+ renormalize_buffer(path, o.buf, o.len, dsto);
+ printf(dsto=|%s|\n,dsto.buf);
+
+
+ printf(dsto.len=%d, dsta.len=%d\n, dsto.len, dsta.len);
+
+
if (renormalize_buffer(path, o.buf, o.len, o) |
renormalize_buffer(path, a.buf, a.len, a))
ret = (o.len == a.len !memcmp(o.buf, a.buf, o.len));
@@ -1682,10 +1715,24 @@ static int merge_content(struct merge_options *o,
}
+
+//~ struct stage_data {
+ //~ struct {
+ //~ unsigned mode;
+ //~ unsigned char sha[20];
+ //~ } stages[4];
+ //~ struct rename_conflict_info *rename_conflict_info;
+ //~ unsigned processed:1;
+//~ };
+
/* Per entry merge function */
static int process_entry(struct merge_options *o,
const char *path, struct stage_data *entry)
{
+
+ printf(processing entry %s has rename_conflict_info %p\n, path,
entry-rename_conflict_info);
+ //~ print_index_entry(\tpath: , entry);
+
int clean_merge = 1;
int normalize = o-renormalize;
unsigned o_mode = entry-stages[1].mode;
@@ -1694,9 +1741,10 @@ static int process_entry(struct merge_options *o,
unsigned char *o_sha = stage_sha(entry-stages[1].sha, o_mode);
unsigned char *a_sha = stage_sha(entry-stages[2].sha, a_mode);
unsigned char *b_sha = stage_sha(entry-stages[3].sha, b_mode);
-
+ printf(%s %s %s\n, o_sha, a_sha, b_sha);
entry-processed = 1;
if (entry-rename_conflict_info) {
+ printf(in entry-rename_conflict_info condition\n);
struct rename_conflict_info *conflict_info =
entry-rename_conflict_info
[PATCH 1/2] transport: Free leaking head in transport_print_push_status
From: Stefan Beller sbel...@google.com Found by scan.coverity.com (ID: 1248110) Signed-off-by: Stefan Beller sbel...@google.com --- transport.c | 1 + 1 file changed, 1 insertion(+) diff --git a/transport.c b/transport.c index 055d2a2..fbab6ee 100644 --- a/transport.c +++ b/transport.c @@ -774,6 +774,7 @@ void transport_print_push_status(const char *dest, struct ref *refs, *reject_reasons |= REJECT_NEEDS_FORCE; } } + free(head); } void transport_verify_remote_names(int nr_heads, const char **heads) -- 2.1.2.332.g8071e93 -- 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] .mailmap: Add Stefan Bellers corporate mail address
From: Stefan Beller sbel...@google.com Note that despite the private address being first, Google owns the copyright on this patch as any other patch I'll be sending signed off by the sbel...@google.com address. Signed-off-by: Stefan Beller sbel...@google.com --- .mailmap | 1 + 1 file changed, 1 insertion(+) diff --git a/.mailmap b/.mailmap index 8aefb5a..bb6f52e 100644 --- a/.mailmap +++ b/.mailmap @@ -205,6 +205,7 @@ Shawn O. Pearce spea...@spearce.org Simon Hausmann hausm...@kde.org si...@lst.de Simon Hausmann hausm...@kde.org shaus...@trolltech.com Stefan Beller stefanbel...@gmail.com stefanbel...@googlemail.com +Stefan Beller stefanbel...@gmail.com sbel...@google.com Stefan Naewe stefan.na...@gmail.com stefan.na...@atlas-elektronik.com Stefan Naewe stefan.na...@gmail.com stefan.na...@googlemail.com Stefan Sperling s...@elego.de s...@stsp.name -- 2.1.2.332.g8071e93 -- 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 v2 2/7] send-pack.c: add an --atomic-push command line argument
On Mon, Nov 3, 2014 at 11:12 AM, Ronnie Sahlberg sahlb...@google.com wrote:
This adds support to send-pack to to negotiate and use atomic pushes
/s/to to/to/
iff the server supports it. Atomic pushes are activated by a new command
line flag --atomic-push.
In order to do this we also need to change the semantics for send_pack()
slightly. The existing send_pack() function actually don't sent all the
refs back to the server when multiple refs are involved, for example
when using --all. Several of the failure modes for pushes can already be
detected locally in the send_pack client based on the information from the
initial server side list of all the refs as generated by receive-pack.
Any such refs that we thus know would fail to push are thus pruned from
the list of refs we send to the server to update.
For atomic pushes, we have to deal thus with both failures that are detected
locally as well as failures that are reported back from the server. In order
to do so we treat all local failures as push failures too.
We introduce a new status code REF_STATUS_ATOMIC_PUSH_FAILED so we can
flag all refs that we would normally have tried to push to the server
but we did not due to local failures. This is to improve the error message
back to the end user to flag that these refs failed to update since the
atomic push operation failed.
Signed-off-by: Ronnie Sahlberg sahlb...@google.com
---
Documentation/git-send-pack.txt | 7 ++-
builtin/send-pack.c | 6 +-
remote.h| 3 ++-
send-pack.c | 39 ++-
send-pack.h | 1 +
transport.c | 4
6 files changed, 52 insertions(+), 8 deletions(-)
diff --git a/Documentation/git-send-pack.txt b/Documentation/git-send-pack.txt
index 2a0de42..9296587 100644
--- a/Documentation/git-send-pack.txt
+++ b/Documentation/git-send-pack.txt
@@ -9,7 +9,7 @@ git-send-pack - Push objects over Git protocol to another
repository
SYNOPSIS
[verse]
-'git send-pack' [--all] [--dry-run] [--force]
[--receive-pack=git-receive-pack] [--verbose] [--thin] [host:]directory
[ref...]
+'git send-pack' [--all] [--dry-run] [--force]
[--receive-pack=git-receive-pack] [--verbose] [--thin] [--atomic-push]
[host:]directory [ref...]
DESCRIPTION
---
@@ -62,6 +62,11 @@ be in a separate packet, and the list must end with a
flush packet.
Send a thin pack, which records objects in deltified form based
on objects not included in the pack to reduce network traffic.
+--atomic-push::
+ Use an atomic transaction for updating the refs. If any of the refs
+ fails to update then the entire push will fail without changing any
+ refs.
+
host::
A remote host to house the repository. When this
part is specified, 'git-receive-pack' is invoked via
diff --git a/builtin/send-pack.c b/builtin/send-pack.c
index b564a77..93cb17c 100644
--- a/builtin/send-pack.c
+++ b/builtin/send-pack.c
@@ -13,7 +13,7 @@
#include sha1-array.h
static const char send_pack_usage[] =
-git send-pack [--all | --mirror] [--dry-run] [--force]
[--receive-pack=git-receive-pack] [--verbose] [--thin] [host:]directory
[ref...]\n
+git send-pack [--all | --mirror] [--dry-run] [--force]
[--receive-pack=git-receive-pack] [--verbose] [--thin] [--atomic-push]
[host:]directory [ref...]\n
--all and explicit ref specification are mutually exclusive.;
static struct send_pack_args args;
@@ -170,6 +170,10 @@ int cmd_send_pack(int argc, const char **argv, const
char *prefix)
args.use_thin_pack = 1;
continue;
}
+ if (!strcmp(arg, --atomic-push)) {
+ args.use_atomic_push = 1;
+ continue;
+ }
if (!strcmp(arg, --stateless-rpc)) {
args.stateless_rpc = 1;
continue;
diff --git a/remote.h b/remote.h
index 8b62efd..f346524 100644
--- a/remote.h
+++ b/remote.h
@@ -115,7 +115,8 @@ struct ref {
REF_STATUS_REJECT_SHALLOW,
REF_STATUS_UPTODATE,
REF_STATUS_REMOTE_REJECT,
- REF_STATUS_EXPECTING_REPORT
+ REF_STATUS_EXPECTING_REPORT,
+ REF_STATUS_ATOMIC_PUSH_FAILED
} status;
char *remote_status;
struct ref *peer_ref; /* when renaming */
diff --git a/send-pack.c b/send-pack.c
index 1ccc84c..08602a8 100644
--- a/send-pack.c
+++ b/send-pack.c
@@ -190,7 +190,7 @@ static void advertise_shallow_grafts_buf(struct strbuf
*sb)
for_each_commit_graft(advertise_shallow_grafts_cb, sb);
}
-static int ref_update_to_be_sent(const struct ref *ref, const struct
send_pack_args
Re: [PATCH 0/6] Corrections to the mailmap file
On 07/11/2013 07:33 PM, Junio C Hamano wrote:
Stefan Beller stefanbel...@googlemail.com writes:
I noticed many duplicates in email addresses but having the same name by
running:
# Finding out duplicates by comparing names:
git shortlog -sne |awk '{ NF--; $1=; print }' |sort |uniq -d
Most of these entries are most probably the same person, but we cannot be
sure, as there might be different persons having the same name, then they
are only distinguished by the mail address.
However I suspect most of these to be the same person, having changed
mail addresses.
Here comes an initial batch of corrections to the mailmap file, which
maps people with email addresses of different capitalization onto
the same entity.
(Example n...@mit.edu is the same as n...@mit.edu)
I intend to contact each of the persons individually and ask whether
just their mail address changed, or if they are indeed different persons.
Has anything happen to this topic sice you posted?
I think:
- .(none) is obviously bad, and we can fix without waiting for
responses as long as we know the replacement address is the
address from the list we usually see on the list (3).
- Domain part is defined to be case insensitive (e.g. @mit.edu vs
@MIT.EDU), so both forms are equally valid. The owner of the
address may have preferences (1 and 4), though.
For this, we could just declare we downcase the domain part.
- The local-part, even though RFC 2821 says local-part of a
mailbox MUST BE treated as case sensitive, is often case
insensitive, and User.Name@domain and user.name@domain often name
the same mailbox. The owner of the address may have preferences
(5 and 6), though.
For this, we could just declare we Camel.Case the local part,
after making sure Camel.Case@domain has been used by the owner of
the address on this list.
So where does that leave us?
We can apply without waiting:
1: downcase domain
3: .(none) and we know pau...@samba.org
4: downcase domain
5: We recently saw Dshco calls himself Johannes.Schindelin@domain.
6: The latest one from Nov 2009 uses Toby.Allsopp@domain.
The only possibly iffy one is Alex Riesen, but raa.lkml@domain
seems to be the one he uses here, so I think 2. is also fine.
To be honest, I did not continue to work on this. I was
waiting for the first few patches to be reviewed, because
I was not sure how important you all think this topic
really is. I know projects, which frown upon such
beautyfing commits. Hence I was waiting for an answer,
whether such work is appreciated.
Anyway, last time I tried contributing to git, I was
told to explicitely do it in the open. I did forget
to CC the mailing list when asking Alex Riesen
(2nd patch), whether it's all him.
I do see the benefit of the openess, when discussing code
or documentation, but I wonder if you'd also like to see these
'Hello, are you the person having email x, y and z?'
kind of mails put on the mailing list as well.
That would be 120 to go, which may be undesired?
So I'll start contacting the other people now.
--
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] .mailmap: Map email addresses to names
People change email addresses quite often and sometimes
forget to add their entry to the mailmap file.
I have contacted lots of people, whose name occurs
multiple times in the short log having different
email addresses. The entries in the mailmap of
this patch are either confirmed by them or are trivial.
Trivial means different capitalisation of the domain
(@MIT.EDU and @mit.edu) or the domain was localhost,
(none) or @local.
Additionally to adding (name, email) mappings to the
.mailmap file, it has also been sorted alphabetically.
(which explains the removals, which are added
3 lines later on again)
While the most changes happen at the email addresses,
we also have a name change in here. Karl Hasselström
is now known as Karl Wiberg due to marriage. Congratulations!
To find out whom to contact I used the following small
script:
---
#!/bin/bash
git shortlog -sne |awk '{ NF--; $1=; print }' |sort |uniq -d
mailmapdoubles
while read line ; do
# remove leading whitespace
trimmed=$(echo $line | sed -e 's/^ *//g' -e 's/ *$//g')
echo git shortlog -sne | grep \$trimmed\
done mailmapdoubles mailmapdoubles2
sh mailmapdoubles2
rm mailmapdoubles
rm mailmapdoubles2
---
Also interesting for similar tasks are these snippets:
# Finding out duplicates by comparing email addresses:
git shortlog -sne |awk '{ print $NF }' |sort |uniq -d
# Finding out duplicates by comparing names:
git shortlog -sne |awk '{ NF--; $1=; print }' |sort |uniq -d
---
Signed-off-by: Stefan Beller stefanbel...@googlemail.com
---
.mailmap | 95
1 file changed, 71 insertions(+), 24 deletions(-)
diff --git a/.mailmap b/.mailmap
index 345cce6..1179767 100644
--- a/.mailmap
+++ b/.mailmap
@@ -5,99 +5,146 @@
# same person appearing not to be so.
#
-Alex Bennée kernel-hac...@bennee.com
+Alejandro R. Sedeño ased...@mit.edu ased...@mit.edu
Alexander Gavrilov angavri...@gmail.com
+Alex Bennée kernel-hac...@bennee.com
+Alex Riesen raa.l...@gmail.com fo...@t-online.de
+Alex Riesen raa.l...@gmail.com raa@limbo.localdomain
+Alex Riesen raa.l...@gmail.com r...@steel.home
+Anders Kaseorg ande...@mit.edu ande...@ksplice.com
+Anders Kaseorg ande...@mit.edu ande...@mit.edu
Aneesh Kumar K.V aneesh.ku...@gmail.com
+anonymous li...@horizon.com
+anonymous li...@horizon.net
+Brandon Casey draf...@gmail.com ca...@nrlssc.navy.mil
Brian M. Carlson sand...@crustytoothpaste.ath.cx
Cheng Renquan crq...@gmail.com
Chris Shoemaker c.shoema...@cox.net
-Dan Johnson computerdr...@gmail.com
Dana L. How dana...@gmail.com
Dana L. How h...@deathvalley.cswitch.com
Daniel Barkalow barka...@iabervon.org
+Dan Johnson computerdr...@gmail.com
David D. Kilzer ddkil...@kilzer.net
David Kågedal dav...@lysator.liu.se
+David Reiss dre...@facebook.com dreiss@dreiss-vmware.(none)
David S. Miller da...@davemloft.net
Deskin Miller desk...@umich.edu
Dirk Süsserott newslet...@dirk.my1.cc
Eric S. Raymond e...@thyrsus.com
Erik Faye-Lund kusmab...@gmail.com kusmab...@googlemail.com
-Fredrik Kuivinen freku...@student.liu.se
+Florian Achleitner florian.achleitner.2.6...@gmail.com
florian.achleitner2.6...@gmail.com
+Franck Bui-Huu vagabon@gmail.com fbui...@gmail.com
+Frank Lichtenheld fr...@lichtenheld.de dj...@debian.org
+Frank Lichtenheld fr...@lichtenheld.de flichtenh...@astaro.com
Frédéric Heitzmann frederic.heitzm...@gmail.com
+Fredrik Kuivinen freku...@student.liu.se
+Han-Wen Nienhuys han...@google.com Han-Wen Nienhuys han...@xs4all.nl
H. Merijn Brand h.m.br...@xs4all.nl H.Merijn Brand h.m.br...@xs4all.nl
-H. Peter Anvin h...@bonde.sc.orionmulti.com
-H. Peter Anvin h...@tazenda.sc.orionmulti.com
-H. Peter Anvin h...@trantor.hos.anvin.org
Horst H. von Brand vonbr...@inf.utfsm.cl
+H. Peter Anvin h...@zytor.com h...@bonde.sc.orionmulti.com
+H. Peter Anvin h...@zytor.com h...@smyrno.hos.anvin.org
+H. Peter Anvin h...@zytor.com h...@tazenda.sc.orionmulti.com
+H. Peter Anvin h...@zytor.com h...@trantor.hos.anvin.org
İsmail Dönmez ism...@pardus.org.tr
Jakub Narębski jna...@gmail.com
-Jay Soffian jaysoffian+...@gmail.com
+Jay Soffian jaysoff...@gmail.com jaysoffian+...@gmail.com
+J. Bruce Fields bfie...@citi.umich.edu bfie...@fieldses.org
+J. Bruce Fields bfie...@citi.umich.edu bfie...@pig.linuxdev.us.dell.com
+J. Bruce Fields bfie...@citi.umich.edu bfie...@puzzle.fieldses.org
Jeff King p...@peff.net p...@github.com
Joachim Berdal Haga cjh...@fys.uio.no
+Johannes Schindelin johannes.schinde...@gmx.de johannes.schinde...@gmx.de
Johannes Sixt j...@kdbg.org johannes.s...@telecom.at
-Johannes Sixt j...@kdbg.org j.s...@viscovery.net
Johannes Sixt j...@kdbg.org j.s...@eudaptics.com
+Johannes Sixt j...@kdbg.org j.s...@viscovery.net
+Jonathan Nieder jrnie...@gmail.com jrnie...@uchicago.edu
Jon Loeliger j...@freescale.com
Jon Seymour j...@blackcubes.dyndns.org
-Jonathan Nieder jrnie...@uchicago.edu
Junio C Hamano gits...@pobox.com gits
[PATCH v2] Corrections to the mailmap file
By now I contacted more than half the people, who might get some .mailmap entries. Not all of them have responded, but maybe 2/3 of those, whom I contacted. I used 2 branches to get this work done. One branch having all the proposed patches, where each patch just changes one name, so I can send it to that specific person for review. The second branch would be slightly behind the first branch and only have the patches of the confirmed .mailmap changes. The following patch is a squashed version of the confirmed branch. Whenever somebody confirmed their patch, I'd include it into the confirmed branch and rebase the first branch on top of it. That works fine, if there are no many commits in between, so no merge conflicts occur. Junio, therefore I'd ask to include the following patch as the 1/3 milestone in the mailmap completion, so the number of my local patches floating around is reduced. The 6 patches sent at 4th July are not required anymore, but the following patch directly applies to your master branch. Stefan Beller (1): .mailmap: Map email addresses to names .mailmap | 95 1 file changed, 71 insertions(+), 24 deletions(-) -- 1.8.3.2.636.g7943f03 -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Bug in .mailmap handling?
Hello, you may have noticed I am currently trying to bring the mailmap file of git itself up to date. I noticed some behavior, which I did not expect. Have a look yourself: --- # prepare test environment: mkdir testmailmap cd testmailmap/ git init # do a commit: echo asdf test1 git add test1 git commit -a --author=A a...@example.org -m add test1 # commit with same name, but different email # (different capitalization does the trick already, # but here I am going to use a different mail) echo asdf test2 git add test2 git commit -a --author=A changed_em...@example.org -m add test2 # how do we know it's the same person? git shortlog A (2): add test1 add test2 # reports as expected: git shortlog -sne 1 A a...@example.org 1 A changed_em...@example.org # Adding the line to the mailmap should make life easy, so we know # it's the same person echo A a...@example.org changed_em...@example.org .mailmap # Come on, I just wanted to have it reported as one person! git shortlog -sne 1 A a...@example.org 1 A a...@example.org # So let's try another line in the mailmap file, (small 'a') echo A a...@example.org changed_em...@example.org .mailmap # We're not there yet? git shortlog -sne 1 A a...@example.org 1 A a...@example.org # Now let's write it rather explicit: # (essentially just write 2 lines into the mailmap file) cat EOF .mailmap A a...@example.org changed_em...@example.org A a...@example.org a...@example.org EOF # works as expected now git shortlog -sne 2 A a...@example.org # works as expected now as well git shortlog A (2): add test1 add test2 -- 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] .mailmap: Map email addresses to names
The same kind of cleanup as sent earlier today (2e2ae79df4fabea0157c5eb527b5396eb89185a1 locally here) I asked all the people before, whether they like their lines added. Many had requests to change the order of the mail address. When having this patch applied, you'll notice the bug as described here http://marc.info/?l=gitm=137364524514927w=2 http://www.mail-archive.com/git@vger.kernel.org/msg31964.html (Bug in .mailmap handling?, for example look for Knut Franke) Signed-off-by: Stefan Beller stefanbel...@googlemail.com --- .mailmap | 28 ++-- 1 file changed, 26 insertions(+), 2 deletions(-) diff --git a/.mailmap b/.mailmap index 1179767..1d6ba17 100644 --- a/.mailmap +++ b/.mailmap @@ -7,6 +7,7 @@ Alejandro R. Sedeño ased...@mit.edu ased...@mit.edu Alexander Gavrilov angavri...@gmail.com +Alexey Shumkin alex.crez...@gmail.com zap...@mail.ru Alex Bennée kernel-hac...@bennee.com Alex Riesen raa.l...@gmail.com fo...@t-online.de Alex Riesen raa.l...@gmail.com raa@limbo.localdomain @@ -18,12 +19,15 @@ anonymous li...@horizon.com anonymous li...@horizon.net Brandon Casey draf...@gmail.com ca...@nrlssc.navy.mil Brian M. Carlson sand...@crustytoothpaste.ath.cx +Bryan Larsen br...@larsen.st bryan.lar...@gmail.com +Bryan Larsen br...@larsen.st bryanlar...@yahoo.com Cheng Renquan crq...@gmail.com Chris Shoemaker c.shoema...@cox.net Dana L. How dana...@gmail.com Dana L. How h...@deathvalley.cswitch.com Daniel Barkalow barka...@iabervon.org Dan Johnson computerdr...@gmail.com +David Brown g...@davidb.org dav...@quicinc.com David D. Kilzer ddkil...@kilzer.net David Kågedal dav...@lysator.liu.se David Reiss dre...@facebook.com dreiss@dreiss-vmware.(none) @@ -31,7 +35,10 @@ David S. Miller da...@davemloft.net Deskin Miller desk...@umich.edu Dirk Süsserott newslet...@dirk.my1.cc Eric S. Raymond e...@thyrsus.com +Eric Blake ebl...@redhat.com e...@byu.net +Eric Hanchrow eric.hanch...@gmail.com off...@blarg.net Erik Faye-Lund kusmab...@gmail.com kusmab...@googlemail.com +Eyvind Bernhardsen eyvind.bernhard...@gmail.com eyvind-...@orakel.ntnu.no Florian Achleitner florian.achleitner.2.6...@gmail.com florian.achleitner2.6...@gmail.com Franck Bui-Huu vagabon@gmail.com fbui...@gmail.com Frank Lichtenheld fr...@lichtenheld.de dj...@debian.org @@ -47,19 +54,25 @@ H. Peter Anvin h...@zytor.com h...@tazenda.sc.orionmulti.com H. Peter Anvin h...@zytor.com h...@trantor.hos.anvin.org İsmail Dönmez ism...@pardus.org.tr Jakub Narębski jna...@gmail.com +Jason Riedy e...@eecs.berkeley.edu e...@cs.berkeley.edu +Jason Riedy e...@eecs.berkeley.edu e...@eecs.berkeley.edu Jay Soffian jaysoff...@gmail.com jaysoffian+...@gmail.com J. Bruce Fields bfie...@citi.umich.edu bfie...@fieldses.org J. Bruce Fields bfie...@citi.umich.edu bfie...@pig.linuxdev.us.dell.com J. Bruce Fields bfie...@citi.umich.edu bfie...@puzzle.fieldses.org Jeff King p...@peff.net p...@github.com +Jeff Muizelaar jmuizel...@mozilla.com j...@infidigm.net Joachim Berdal Haga cjh...@fys.uio.no Johannes Schindelin johannes.schinde...@gmx.de johannes.schinde...@gmx.de Johannes Sixt j...@kdbg.org johannes.s...@telecom.at Johannes Sixt j...@kdbg.org j.s...@eudaptics.com Johannes Sixt j...@kdbg.org j.s...@viscovery.net +Jonathan del Strother jon.delstrot...@bestbefore.tv maill...@steelskies.com Jonathan Nieder jrnie...@gmail.com jrnie...@uchicago.edu Jon Loeliger j...@freescale.com -Jon Seymour j...@blackcubes.dyndns.org +Jon Seymour jon.seym...@gmail.com j...@blackcubes.dyndns.org +Josh Triplett j...@joshtriplett.org j...@freedesktop.org +Josh Triplett j...@joshtriplett.org jo...@us.ibm.com Junio C Hamano gits...@pobox.com gits...@pobox.com Junio C Hamano gits...@pobox.com ju...@hera.kernel.org Junio C Hamano gits...@pobox.com ju...@kernel.org @@ -71,11 +84,14 @@ Karl Wiberg k...@treskal.com Karl Hasselström k...@treskal.com Karl Wiberg k...@treskal.com Karl Hasselström k...@yoghurt.hemma.treskal.com Kay Sievers kay.siev...@vrfy.org kay@mam.(none) Kay Sievers kay.siev...@vrfy.org kay.siev...@suse.de +Karsten Blees bl...@dcon.de karsten.bl...@dcon.de +Karsten Blees bl...@dcon.de karsten.bl...@gmail.com Keith Cascio ke...@cs.ucla.edu ke...@cs.ucla.edu Kent Engstrom k...@lysator.liu.se Kevin Leung kevin...@gmail.com Kirill Smelkov k...@navytux.spb.ru k...@landau.phys.spbu.ru Kirill Smelkov k...@navytux.spb.ru k...@mns.spb.ru +Knut Franke knut.fra...@gmx.de k.fra...@science-computing.de Lars Doelle lars.doelle@on-line ! de Lars Doelle lars.doe...@on-line.de Li Hong leeh...@pku.edu.cn @@ -85,11 +101,14 @@ Linus Torvalds torva...@linux-foundation.org torva...@osdl.org Linus Torvalds torva...@linux-foundation.org torva...@ppc970.osdl.org Linus Torvalds torva...@linux-foundation.org torva...@ppc970.osdl.org.(none) Linus Torvalds torva...@linux-foundation.org torva...@woody.linux-foundation.org -Lukas Sandström luk...@etek.chalmers.se +Lukas Sandström luk...@gmail.com luk...@etek.chalmers.se +Matt
Re: Bug in .mailmap handling?
The commands are exactly as given in the first mail. (I run it multiple times, and this exact behavior comes up) I think there is some problem with the capitalisation of the first (if not all) characters. (Hence the small 'a') So either check with these example commands yourself, or take my latest patch for the mailmap to reproduce on real names, please. On 07/12/2013 07:35 PM, Junio C Hamano wrote: Stefan Beller stefanbel...@googlemail.com writes: Hello, you may have noticed I am currently trying to bring the mailmap file of git itself up to date. I noticed some behavior, which I did not expect. Have a look yourself: --- # prepare test environment: mkdir testmailmap cd testmailmap/ git init # do a commit: echo asdf test1 git add test1 git commit -a --author=A a...@example.org -m add test1 # commit with same name, but different email # (different capitalization does the trick already, # but here I am going to use a different mail) echo asdf test2 git add test2 git commit -a --author=A changed_em...@example.org -m add test2 # how do we know it's the same person? git shortlog A (2): add test1 add test2 You don't, and it is a long known behaviour. # reports as expected: git shortlog -sne 1 A a...@example.org 1 A changed_em...@example.org Yes. # Adding the line to the mailmap should make life easy, so we know # it's the same person echo A a...@example.org changed_em...@example.org .mailmap # Come on, I just wanted to have it reported as one person! git shortlog -sne 1 A a...@example.org 1 A a...@example.org Err, where does the lowercase a@ come from in the above? Are we missing some steps before we get here? # So let's try another line in the mailmap file, (small 'a') echo A a...@example.org changed_em...@example.org .mailmap This is , not , I presume? Otherwise changed_email is mapped to two destination, no? # We're not there yet? git shortlog -sne 1 A a...@example.org 1 A a...@example.org Expected, as long as some hidden set-up you did not describe that caused me to say Err, where does the lowercase a@ come from is there, i.e. one of the two commits is done by a...@example.org. # Now let's write it rather explicit: # (essentially just write 2 lines into the mailmap file) cat EOF .mailmap A a...@example.org changed_em...@example.org A a...@example.org a...@example.org EOF # works as expected now git shortlog -sne 2 A a...@example.org Makes sense. # works as expected now as well git shortlog A (2): add test1 add test2 signature.asc Description: OpenPGP digital signature
Re: [PATCH] .mailmap: Map email addresses to names
Which tool would you recommend to sort stuff? Or rather the exact parameters for /usr/bin/sort ? Thanks, Stefan On 07/12/2013 08:57 PM, Jonathan Nieder wrote: Stefan Beller wrote: --- a/.mailmap +++ b/.mailmap @@ -5,99 +5,146 @@ [...] Chris Shoemaker c.shoema...@cox.net -Dan Johnson computerdr...@gmail.com Dana L. How dana...@gmail.com Dana L. How h...@deathvalley.cswitch.com Daniel Barkalow barka...@iabervon.org +Dan Johnson computerdr...@gmail.com Small nit: the sorting looks broken here and in similar places below (the usual ordering is Dan Dana Daniel). 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: [PATCH] .mailmap: Map email addresses to names
From the man page *** WARNING *** The locale specified by the environment affects sort order. Set LC_ALL=C to get the traditional sort order that uses native byte values. And indeed I can avoid being nitpicked again for wrong sorting. ;) On 07/12/2013 09:02 PM, Stefan Beller wrote: Which tool would you recommend to sort stuff? Or rather the exact parameters for /usr/bin/sort ? Thanks, Stefan On 07/12/2013 08:57 PM, Jonathan Nieder wrote: Stefan Beller wrote: --- a/.mailmap +++ b/.mailmap @@ -5,99 +5,146 @@ [...] Chris Shoemaker c.shoema...@cox.net -Dan Johnson computerdr...@gmail.com Dana L. How dana...@gmail.com Dana L. How h...@deathvalley.cswitch.com Daniel Barkalow barka...@iabervon.org +Dan Johnson computerdr...@gmail.com Small nit: the sorting looks broken here and in similar places below (the usual ordering is Dan Dana Daniel). 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
[PATCH] .mailmap: Map email addresses to names
Ok I am sending all confirmed changes now again in one big patch, as the sorting was wrong. Stefan Beller (1): .mailmap: Map email addresses to names .mailmap | 135 +++ 1 file changed, 110 insertions(+), 25 deletions(-) -- 1.8.3.2.790.g9192b0b -- 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] .mailmap: Map email addresses to names
People change email addresses quite often and sometimes
forget to add their entry to the mailmap file.
I have contacted lots of people, whose name occurs
multiple times in the short log having different
email addresses. The entries in the mailmap of
this patch are either confirmed by them or are trivial.
Trivial means different capitalisation of the domain
(@MIT.EDU and @mit.edu) or the domain was localhost,
(none) or @local.
Additionally to adding (name, email) mappings to the
.mailmap file, it has also been sorted alphabetically.
(which explains the removals, which are added
3 lines later on again). The sorting was done using
export LC_ALL=C; /usr/bin/sort without arguments.
While the most changes happen at the email addresses,
we also have a name change in here. Karl Hasselström
is now known as Karl Wiberg due to marriage. Congratulations!
To find out whom to contact I used the following small
script:
-
#!/bin/bash
git shortlog -sne |awk '{ NF--; $1=; print }' |sort |uniq -d
mailmapdoubles
while read line ; do
# remove leading whitespace
trimmed=$(echo $line | sed -e 's/^ *//g' -e 's/ *$//g')
echo git shortlog -sne | grep \$trimmed\
done mailmapdoubles mailmapdoubles2
sh mailmapdoubles2
rm mailmapdoubles
rm mailmapdoubles2
-
Also interesting for similar tasks are these snippets:
# Finding out duplicates by comparing email addresses:
git shortlog -sne |awk '{ print $NF }' |sort |uniq -d
# Finding out duplicates by comparing names:
git shortlog -sne |awk '{ NF--; $1=; print }' |sort |uniq -d
-
Signed-off-by: Stefan Beller stefanbel...@googlemail.com
---
.mailmap | 135 +++
1 file changed, 110 insertions(+), 25 deletions(-)
diff --git a/.mailmap b/.mailmap
index 345cce6..22d3d70 100644
--- a/.mailmap
+++ b/.mailmap
@@ -5,99 +5,184 @@
# same person appearing not to be so.
#
+n...@fluxnic.net n...@cam.org
+Alejandro R. Sedeño ased...@mit.edu ased...@mit.edu
Alex Bennée kernel-hac...@bennee.com
+Alex Riesen raa.l...@gmail.com fo...@t-online.de
+Alex Riesen raa.l...@gmail.com raa@limbo.localdomain
+Alex Riesen raa.l...@gmail.com r...@steel.home
+Alex Vandiver a...@chmrr.net ale...@mit.edu
Alexander Gavrilov angavri...@gmail.com
+Alexey Shumkin alex.crez...@gmail.com zap...@mail.ru
+Anders Kaseorg ande...@mit.edu ande...@ksplice.com
+Anders Kaseorg ande...@mit.edu ande...@mit.edu
Aneesh Kumar K.V aneesh.ku...@gmail.com
+Bernt Hansen be...@norang.ca be...@alumni.uwaterloo.ca
+Brandon Casey draf...@gmail.com ca...@nrlssc.navy.mil
Brian M. Carlson sand...@crustytoothpaste.ath.cx
+Bryan Larsen br...@larsen.st bryan.lar...@gmail.com
+Bryan Larsen br...@larsen.st bryanlar...@yahoo.com
Cheng Renquan crq...@gmail.com
Chris Shoemaker c.shoema...@cox.net
Dan Johnson computerdr...@gmail.com
Dana L. How dana...@gmail.com
Dana L. How h...@deathvalley.cswitch.com
Daniel Barkalow barka...@iabervon.org
+David Brown g...@davidb.org dav...@quicinc.com
David D. Kilzer ddkil...@kilzer.net
David Kågedal dav...@lysator.liu.se
+David Reiss dre...@facebook.com dreiss@dreiss-vmware.(none)
David S. Miller da...@davemloft.net
Deskin Miller desk...@umich.edu
Dirk Süsserott newslet...@dirk.my1.cc
+Eric Blake ebl...@redhat.com e...@byu.net
+Eric Hanchrow eric.hanch...@gmail.com off...@blarg.net
Eric S. Raymond e...@thyrsus.com
Erik Faye-Lund kusmab...@gmail.com kusmab...@googlemail.com
+Eyvind Bernhardsen eyvind.bernhard...@gmail.com eyvind-...@orakel.ntnu.no
+Florian Achleitner florian.achleitner.2.6...@gmail.com
florian.achleitner2.6...@gmail.com
+Franck Bui-Huu vagabon@gmail.com fbui...@gmail.com
+Frank Lichtenheld fr...@lichtenheld.de dj...@debian.org
+Frank Lichtenheld fr...@lichtenheld.de flichtenh...@astaro.com
Fredrik Kuivinen freku...@student.liu.se
Frédéric Heitzmann frederic.heitzm...@gmail.com
H. Merijn Brand h.m.br...@xs4all.nl H.Merijn Brand h.m.br...@xs4all.nl
-H. Peter Anvin h...@bonde.sc.orionmulti.com
-H. Peter Anvin h...@tazenda.sc.orionmulti.com
-H. Peter Anvin h...@trantor.hos.anvin.org
+H. Peter Anvin h...@zytor.com h...@bonde.sc.orionmulti.com
+H. Peter Anvin h...@zytor.com h...@smyrno.hos.anvin.org
+H. Peter Anvin h...@zytor.com h...@tazenda.sc.orionmulti.com
+H. Peter Anvin h...@zytor.com h...@trantor.hos.anvin.org
+Han-Wen Nienhuys han...@google.com Han-Wen Nienhuys han...@xs4all.nl
Horst H. von Brand vonbr...@inf.utfsm.cl
-İsmail Dönmez ism...@pardus.org.tr
+J. Bruce Fields bfie...@citi.umich.edu bfie...@fieldses.org
+J. Bruce Fields bfie...@citi.umich.edu bfie...@pig.linuxdev.us.dell.com
+J. Bruce Fields bfie...@citi.umich.edu bfie...@puzzle.fieldses.org
Jakub Narębski jna...@gmail.com
-Jay Soffian jaysoffian+...@gmail.com
+Jason Riedy e...@eecs.berkeley.edu e...@eecs.berkeley.edu
+Jason Riedy e...@eecs.berkeley.edu e...@cs.berkeley.edu
+Jay Soffian jaysoff...@gmail.com jaysoffian+...@gmail.com
Jeff King p...@peff.net p...@github.com
+Jeff
Re: Bug in .mailmap handling?
On 07/12/2013 10:28 PM, Junio C Hamano wrote: Stefan Beller stefanbel...@googlemail.com writes: # Adding the line to the mailmap should make life easy, so we know # it's the same person echo A a...@example.org changed_em...@example.org .mailmap While I was looking at this, I noticed this piece of code: diff --git a/mailmap.c b/mailmap.c index 2a7b366..418081e 100644 --- a/mailmap.c +++ b/mailmap.c @@ -122,7 +122,7 @@ static char *parse_name_and_email(char *buffer, char **name, while (nend nstart isspace(*nend)) --nend; - *name = (nstart nend ? nstart : NULL); + *name = (nstart = nend ? nstart : NULL); *email = left+1; *(nend+1) = '\0'; *right++ = '\0'; The function is given a buffer A a...@example.org..., nstart scans from the beginning of the buffer, skipping whitespaces (there isn't any, so nstart points at the buffer), while nend starts from one byte before the first '' and skips whitespaces backwards and ends at the first non-whitespace (i.e. it hits A at the beginning of the buffer). nstart == nend in this case for a single-letter name, and an off-by-one error makes it fail to pick up the name, which makes the entry equivalent to a...@example.org changed_em...@example.org without the name. I do not think this bug affected anything you observed, though. git shortlog -sne 1 A a...@example.org 1 A a...@example.org This is coming from mailmap.c::add_mapping() that downcases the e-mail address. changed_em...@example.org is mapped to a...@example.org because of this downcasing, while A a...@example.org does not have any entry for it in the .mailmap file, so it is given back as-is. Hence we see two distinct entries. So do I understand it right, we're having 2 bugs in here? One being triggered by the short name, only one character. So if you want to debug the other bug with a longer name, you can either use a made up name, or run git shortlog -sne |grep Knut in the git repository having the mailmap file already updated. The way the mailmap file is written, I'd assume only one line to be found, as of now 2 lines come up 2 Knut Franke knut.fra...@gmx.de 1 Knut Franke knut.fra...@gmx.de which seems to downcase the whole first email. -- 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] Add a testcase for checking case insensitivity of mail map
Your patch seems to do it. I added a test case which doesn't fail, if your patch is added. Signed-off-by: Stefan Beller stefanbel...@googlemail.com --- t/t4203-mailmap.sh | 33 + 1 file changed, 33 insertions(+) diff --git a/t/t4203-mailmap.sh b/t/t4203-mailmap.sh index 842b754..07152e9 100755 --- a/t/t4203-mailmap.sh +++ b/t/t4203-mailmap.sh @@ -409,4 +409,37 @@ test_expect_success 'Blame output (complex mapping)' ' test_cmp expect actual.fuzz ' +test_expect_success 'cleanup after mailmap.blob tests' ' + rm -f .mailmap +' + +cat expect \EOF + 2 A a...@example.org + 2 Other Author ot...@author.xx + 2 Santa Claus santa.cl...@northpole.xx + 1 A U Thor aut...@example.com + 1 CTO c...@company.xx + 1 Some Dude s...@dude.xx +EOF + +test_expect_success 'Test case sensitivity of Names' ' + # do a commit: + echo asdf test1 + git add test1 + git commit -a --author=A a...@example.org -m add test1 + + # commit with same name, but different email + # (different capitalization does the trick already, + # but here I am going to use a different mail) + echo asdf test2 + git add test2 + git commit -a --author=A changed_em...@example.org -m add test2 + + # Adding the line to the mailmap should make life easy, so we know + # it is the same person + echo A a...@example.org changed_em...@example.org .mailmap + + git shortlog -sne HEAD actual test_cmp expect actual +' + test_done -- 1.8.3.2.776.gfcf213d -- 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] t4203: fix checks for email address remapping
On 07/13/2013 02:35 AM, Eric Sunshine wrote: Two tests in t4203-mailmap.sh set up the mapping b...@company.xx = b...@company.xy in an apparent attempt to check that email address remapping works as expected (in addition to name remapping which is also tested). To test the remapping, git-shortlog is invoked but the invocation lacks the -e option instructing it to show email addresses, hence the tests do not actually prove that address remapping succeeded. Fix this by instructing git-shortlog to output email addresses as well. Signed-off-by: Eric Sunshine sunsh...@sunshineco.com --- The very last git-shortlog complex test in the script does use -e and checks that email address remapping actually works, so it's not clear that this patch is needed. The b...@company.xx = b...@company.xy remapping done by the two tests touched by this patch, however, is misleading to the reader since it seems to imply that these two tests want to check address remapping as well. Perhaps a better change would be to remove the address remapping from these two tests. t/t4203-mailmap.sh | 12 ++-- 1 file changed, 6 insertions(+), 6 deletions(-) diff --git a/t/t4203-mailmap.sh b/t/t4203-mailmap.sh index 842b754..3cf64de 100755 --- a/t/t4203-mailmap.sh +++ b/t/t4203-mailmap.sh @@ -102,10 +102,10 @@ test_expect_success 'mailmap.file non-existent' ' ' cat expect \EOF -Internal Guy (1): +Internal Guy b...@company.xy (1): second -Repo Guy (1): +Repo Guy aut...@example.com (1): initial EOF @@ -114,15 +114,15 @@ test_expect_success 'name entry after email entry' ' mkdir -p internal_mailmap echo b...@company.xy b...@company.xx internal_mailmap/.mailmap echo Internal Guy b...@company.xx internal_mailmap/.mailmap - git shortlog HEAD actual + git shortlog -e HEAD actual test_cmp expect actual ' cat expect \EOF -Internal Guy (1): +Internal Guy b...@company.xy (1): second -Repo Guy (1): +Repo Guy aut...@example.com (1): initial EOF @@ -131,7 +131,7 @@ test_expect_success 'name entry after email entry, case-insensitive' ' mkdir -p internal_mailmap echo b...@company.xy b...@company.xx internal_mailmap/.mailmap echo Internal Guy b...@company.xx internal_mailmap/.mailmap + So here it is capitalized email address (BUGS@), but at the expect file it's still lower cased. I think this is a bug. Junio was trying to fix it in 543f99173c2d2f648d8f846e24875150f7de03d3 (origin/jc/mailmap-case-insensitivity) So I think we need another yet test case there: commited: Internal Guy b...@company.xx Internal Guy b...@company.xy Having just one entry in the mailmap Internal Guy b...@company.xx b...@company.xy should still work with the shortlog -e - git shortlog HEAD actual + git shortlog -e HEAD actual test_cmp expect actual ' -- 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] mailmap: Testing the single letter name case.
This is a regression test for a66e77eab70a08938fdc2227b7ada0f0465c6991 Signed-off-by: Stefan Beller stefanbel...@googlemail.com --- t/t4203-mailmap.sh | 41 + 1 file changed, 41 insertions(+) diff --git a/t/t4203-mailmap.sh b/t/t4203-mailmap.sh index 842b754..9ec87a2 100755 --- a/t/t4203-mailmap.sh +++ b/t/t4203-mailmap.sh @@ -409,4 +409,45 @@ test_expect_success 'Blame output (complex mapping)' ' test_cmp expect actual.fuzz ' +cat expect \EOF +A shortn...@company.xy (2): + eighth + nineth + +A U Thor aut...@example.com (1): + initial + +CTO c...@company.xx (1): + seventh + +Other Author ot...@author.xx (2): + third + fourth + +Santa Claus santa.cl...@northpole.xx (2): + fifth + sixth + +Some Dude s...@dude.xx (1): + second + +EOF + +# Regression test +# Using a single letter name to check for off-by-one errors in parse_name_and_email +test_expect_success 'check mapping for short names' ' + echo one two + git add two + git commit --author A shortn...@company.xx -m eighth + + echo two two + git add two + git commit --author A shortn...@company.xy -m nineth + + echo A shortn...@company.xy shortn...@company.xx .mailmap + git shortlog HEAD -e actual + + test_cmp expect actual +' + test_done -- 1.8.3.2.776.gfcf213d -- 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] mailmap: Testing the single letter name case.
On 07/13/2013 07:38 PM, Junio C Hamano wrote: Stefan Beller stefanbel...@googlemail.com writes: This is a regression test for a66e77eab70a08938fdc2227b7ada0f0465c6991 Sorry, I do not quite get this. If you apply the patch on top of the said commit before that commit, the new test does not pass. But if you apply the patch on top of the said commit, the new test still does not pass. So I am having hard time guessing what you meant by regression test. It is not a66e77 broke something that ought to work, and this shows the breakage. It is not a66e77 fixed something and this shows the previous breakage that got fixed. It may be because the test is depending on ShortName not to be downcased incorrectly, which was to be fixed by a later commit. But after applying this on top of jc/mailmap-case-insensitivity topic, the test does not pass (and reverting a66e77 does not seem to affect the result, either). I am sorry for the bad wording, sorry for wasting your time. This patch was meant to replace 134d1ac9be2ce97c60a7e9187c32980681811cb5 (current test, latest commit on mailmap-case-insensitivity) Indeed the patch tests for both bugs unintentionally. So both the one letter name is being used and the email case sensitivity is checked. So maybe I should redo it again and make 2 explicit test cases for each of the fixes? Stefan -- 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] .mailmap: Combine more (email, name) to individual persons
I got more responses from people regarding the .mailmap file. All added persons gave permission to add them to the .mailmap file. It's mostly email mappings again. However we also have Nick Stokoe, who contributed as Nick Woolley. He changed his name, but kept the email. Signed-off-by: Stefan Beller stefanbel...@googlemail.com --- .mailmap | 42 +++--- 1 file changed, 35 insertions(+), 7 deletions(-) diff --git a/.mailmap b/.mailmap index 22d3d70..9430d14 100644 --- a/.mailmap +++ b/.mailmap @@ -17,6 +17,7 @@ Alexey Shumkin alex.crez...@gmail.com zap...@mail.ru Anders Kaseorg ande...@mit.edu ande...@ksplice.com Anders Kaseorg ande...@mit.edu ande...@mit.edu Aneesh Kumar K.V aneesh.ku...@gmail.com +Ben Walton bdwal...@gmail.com bwal...@artsci.utoronto.ca Bernt Hansen be...@norang.ca be...@alumni.uwaterloo.ca Brandon Casey draf...@gmail.com ca...@nrlssc.navy.mil Brian M. Carlson sand...@crustytoothpaste.ath.cx @@ -24,6 +25,8 @@ Bryan Larsen br...@larsen.st bryan.lar...@gmail.com Bryan Larsen br...@larsen.st bryanlar...@yahoo.com Cheng Renquan crq...@gmail.com Chris Shoemaker c.shoema...@cox.net +Chris Wright chr...@sous-sol.org chr...@osdl.org +Csaba Henk cs...@gluster.com cs...@lowlife.hu Dan Johnson computerdr...@gmail.com Dana L. How dana...@gmail.com Dana L. How h...@deathvalley.cswitch.com @@ -44,8 +47,11 @@ Florian Achleitner florian.achleitner.2.6...@gmail.com florian.achleitner2.6. Franck Bui-Huu vagabon@gmail.com fbui...@gmail.com Frank Lichtenheld fr...@lichtenheld.de dj...@debian.org Frank Lichtenheld fr...@lichtenheld.de flichtenh...@astaro.com -Fredrik Kuivinen freku...@student.liu.se +Fredrik Kuivinen fre...@gmail.com freku...@student.liu.se Frédéric Heitzmann frederic.heitzm...@gmail.com +Garry Dolley gdol...@ucla.edu gdol...@arpnetworks.com +Greg Price pr...@mit.edu pr...@mit.edu +Greg Price pr...@mit.edu pr...@ksplice.com H. Merijn Brand h.m.br...@xs4all.nl H.Merijn Brand h.m.br...@xs4all.nl H. Peter Anvin h...@zytor.com h...@bonde.sc.orionmulti.com H. Peter Anvin h...@zytor.com h...@smyrno.hos.anvin.org @@ -62,6 +68,7 @@ Jason Riedy e...@eecs.berkeley.edu e...@cs.berkeley.edu Jay Soffian jaysoff...@gmail.com jaysoffian+...@gmail.com Jeff King p...@peff.net p...@github.com Jeff Muizelaar jmuizel...@mozilla.com j...@infidigm.net +Jim Meyering j...@meyering.net meyer...@redhat.com Joachim Berdal Haga cjh...@fys.uio.no Johannes Schindelin johannes.schinde...@gmx.de johannes.schinde...@gmx.de Johannes Sixt j...@kdbg.org j.s...@eudaptics.com @@ -95,6 +102,7 @@ Kirill Smelkov k...@navytux.spb.ru k...@mns.spb.ru Knut Franke knut.fra...@gmx.de k.fra...@science-computing.de Lars Doelle lars.doelle@on-line ! de Lars Doelle lars.doe...@on-line.de +Lars Noschinski l...@public.noschinski.de lars.noschin...@rwth-aachen.de Li Hong leeh...@pku.edu.cn Linus Torvalds torva...@linux-foundation.org torva...@evo.osdl.org Linus Torvalds torva...@linux-foundation.org torva...@g5.osdl.org @@ -112,6 +120,7 @@ Martin Langhoff mar...@laptop.org mar...@catalyst.net.nz Martin von Zweigbergk martinv...@gmail.com martin.von.zweigbe...@gmail.com Matt Draisey m...@draisey.ca mattdrai...@sympatico.ca Matt Kraai kr...@ftbfs.org matt.kr...@amo.abbott.com +Matt McCutchen m...@mattmccutchen.net hashprod...@gmail.com Matthias Kestenholz matth...@spinlock.ch m...@spinlock.ch Matthias Urlichs matth...@urlichs.de smurf@kiste.(none) Matthias Urlichs matth...@urlichs.de sm...@smurf.noris.de @@ -120,6 +129,7 @@ Michael J Gruber g...@drmicha.warpmail.net michaeljgruber+gm...@fastmail.fm Michael W. Olson mwol...@gnu.org Michael Witten mfwit...@gmail.com mfwit...@mit.edu Michael Witten mfwit...@gmail.com mfwit...@mit.edu +Michal Rokos michal.ro...@nextsoft.cz ro...@nextsoft.cz Michele Ballabio barra_c...@katamail.com Miklos Vajna vmik...@frugalware.org vmik...@suse.cz Namhyung Kim namhy...@gmail.com namhyung@lge.com @@ -129,14 +139,19 @@ Nanako Shiraishi nana...@lavabit.com Nelson Elhage nelh...@mit.edu nelh...@mit.edu Nelson Elhage nelh...@mit.edu nelh...@ksplice.com Nguyễn Thái Ngọc Duy pclo...@gmail.com +Nick Stokoe n...@noodlefactory.co.uk Nick Woolley n...@noodlefactory.co.uk +Nick Stokoe n...@noodlefactory.co.uk Nick Woolley nickwool...@yahoo.co.uk Nicolas Morey-Chaisemartin devel-...@morey-chaisemartin.com nicolas.mo...@free.fr Nicolas Morey-Chaisemartin devel-...@morey-chaisemartin.com nmo...@kalray.eu +Nicolas Sebrecht nicolas.s@gmx.fr n...@laposte.net Paolo Bonzini bonz...@gnu.org paolo.bonz...@lu.unisi.ch Pascal Obry pas...@obry.net pascal.o...@gmail.com Pascal Obry pas...@obry.net pascal.o...@wanadoo.fr Pat Notz patn...@gmail.com pkn...@sandia.gov Paul Mackerras pau...@samba.org paulus@dorrigo.(none) Paul Mackerras pau...@samba.org paulus@pogo.(none) +Peter Baumann waste.mana...@gmx.de peter.b.baum...@stud.informatik.uni-erlangen.de +Peter Baumann waste.mana...@gmx.de siprb...@stud.informatik.uni-erlangen.de Peter
[PATCH] more mailmap entries
This patch goes on top of branch sb/mailmap-updates Stefan Beller (1): .mailmap: Combine more (email, name) to individual persons .mailmap | 42 +++--- 1 file changed, 35 insertions(+), 7 deletions(-) -- 1.8.3.2.804.g0da7a53.dirty -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] commit: Fix a memory leak in determine_author_info
The date variable is assigned new memory via xmemdupz and 2 lines later it is assigned new memory again via xmalloc, but the first assignment is never freed nor used. --- builtin/commit.c | 1 - 1 file changed, 1 deletion(-) diff --git a/builtin/commit.c b/builtin/commit.c index 790e5ab..00da83c 100644 --- a/builtin/commit.c +++ b/builtin/commit.c @@ -534,7 +534,6 @@ static void determine_author_info(struct strbuf *author_ident) (lb - strlen( ) - (a + strlen(\nauthor ; email = xmemdupz(lb + strlen(), rb - (lb + strlen())); - date = xmemdupz(rb + strlen( ), eol - (rb + strlen( ))); len = eol - (rb + strlen( )); date = xmalloc(len + 2); *date = '@'; -- 1.8.3.2.806.gdee5b9b -- 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/4] daemon.c:handle: Remove unneeded check for null pointer.
addr doesn't need to be checked at that line as it it already accessed
7 lines before in the if (addr-sa_family).
Signed-off-by: Stefan Beller stefanbel...@googlemail.com
---
daemon.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/daemon.c b/daemon.c
index 6aeddcb..5e48c1e 100644
--- a/daemon.c
+++ b/daemon.c
@@ -754,19 +754,19 @@ static void handle(int incoming, struct sockaddr *addr,
socklen_t addrlen)
}
if (addr-sa_family == AF_INET) {
struct sockaddr_in *sin_addr = (void *) addr;
inet_ntop(addr-sa_family, sin_addr-sin_addr, addrbuf + 12,
sizeof(addrbuf) - 12);
snprintf(portbuf, sizeof(portbuf), REMOTE_PORT=%d,
ntohs(sin_addr-sin_port));
#ifndef NO_IPV6
- } else if (addr addr-sa_family == AF_INET6) {
+ } else if (addr-sa_family == AF_INET6) {
struct sockaddr_in6 *sin6_addr = (void *) addr;
char *buf = addrbuf + 12;
*buf++ = '['; *buf = '\0'; /* stpcpy() is cool */
inet_ntop(AF_INET6, sin6_addr-sin6_addr, buf,
sizeof(addrbuf) - 13);
strcat(buf, ]);
snprintf(portbuf, sizeof(portbuf), REMOTE_PORT=%d,
--
1.8.3.2.806.gdee5b9b
--
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] diff-no-index: Remove unused variable.
Signed-off-by: Stefan Beller stefanbel...@googlemail.com
---
diff-no-index.c | 5 +
1 file changed, 1 insertion(+), 4 deletions(-)
diff --git a/diff-no-index.c b/diff-no-index.c
index e66fdf3..842add4 100644
--- a/diff-no-index.c
+++ b/diff-no-index.c
@@ -181,19 +181,18 @@ static int queue_diff(struct diff_options *o,
}
}
void diff_no_index(struct rev_info *revs,
int argc, const char **argv,
int nongit, const char *prefix)
{
int i, prefixlen;
int no_index = 0;
- unsigned options = 0;
const char *paths[2];
/* Were we asked to do --no-index explicitly? */
for (i = 1; i argc; i++) {
if (!strcmp(argv[i], --)) {
i++;
break;
}
if (!strcmp(argv[i], --no-index))
@@ -218,22 +217,20 @@ void diff_no_index(struct rev_info *revs,
if (argc != i + 2)
usagef(git diff %s path path,
no_index ? --no-index : [--no-index]);
diff_setup(revs-diffopt);
for (i = 1; i argc - 2; ) {
int j;
if (!strcmp(argv[i], --no-index))
i++;
- else if (!strcmp(argv[i], -q)) {
- options |= DIFF_SILENT_ON_REMOVED;
+ else if (!strcmp(argv[i], -q))
i++;
- }
else if (!strcmp(argv[i], --))
i++;
else {
j = diff_opt_parse(revs-diffopt, argv + i, argc - i);
if (!j)
die(invalid diff option/value: %s, argv[i]);
i += j;
}
}
--
1.8.3.2.806.gdee5b9b
--
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] commit: Fix a memory leak in determine_author_info
The date variable is assigned new memory via xmemdupz and 2 lines later
it is assigned new memory again via xmalloc, but the first assignment
is never freed nor used.
Signed-off-by: Stefan Beller stefanbel...@googlemail.com
---
builtin/commit.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/builtin/commit.c b/builtin/commit.c
index 790e5ab..00da83c 100644
--- a/builtin/commit.c
+++ b/builtin/commit.c
@@ -528,19 +528,18 @@ static void determine_author_info(struct strbuf
*author_ident)
if (lb == a + strlen(\nauthor ))
/* \nauthor f...@example.com */
name = xcalloc(1, 1);
else
name = xmemdupz(a + strlen(\nauthor ),
(lb - strlen( ) -
(a + strlen(\nauthor ;
email = xmemdupz(lb + strlen(), rb - (lb + strlen()));
- date = xmemdupz(rb + strlen( ), eol - (rb + strlen( )));
len = eol - (rb + strlen( ));
date = xmalloc(len + 2);
*date = '@';
memcpy(date + 1, rb + strlen( ), len);
date[len + 1] = '\0';
}
if (force_author) {
const char *lb = strstr(force_author, );
--
1.8.3.2.806.gdee5b9b
--
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] diff.c: Do not initialize a variable, which gets reassigned anyway.
Signed-off-by: Stefan Beller stefanbel...@googlemail.com
---
diff.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/diff.c b/diff.c
index e53ddad..24382d7 100644
--- a/diff.c
+++ b/diff.c
@@ -1677,21 +1677,19 @@ static void show_stats(struct diffstat_t *data, struct
diff_options *options)
}
/*
* scale the add/delete
*/
add = added;
del = deleted;
if (graph_width = max_change) {
- int total = add + del;
-
- total = scale_linear(add + del, graph_width,
max_change);
+ int total = scale_linear(add + del, graph_width,
max_change);
if (total 2 add del)
/* width = 2 due to the sanity check */
total = 2;
if (add del) {
add = scale_linear(add, graph_width,
max_change);
del = total - add;
} else {
del = scale_linear(del, graph_width,
max_change);
add = total - del;
--
1.8.3.2.806.gdee5b9b
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Bug in git show?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hello, so I wanted to write a script using some git commands, but the output of the git commands is not as expected. I am using git --version git version 1.8.3.2.804.g0da7a53 (current origin/master at git://github.com/gitster/git.git) The command I am trying to use is git --no-pager show --format=%ad commit Expected output: sb@sb:~/OSS/git$ git show --format=%ad 0da7a53^ Fri Jul 12 12:04:19 2013 -0700 sb@sb:~/OSS/git$ git show --format=%ad 0da7a53^^ Fri Jul 12 12:04:17 2013 -0700 sb@sb:~/OSS/git$ git show --format=%ad 0da7a53^^^ Fri Jul 12 12:04:16 2013 -0700 sb@sb:~/OSS/git$ git show --format=%ad 0da7a53 Fri Jul 12 12:04:14 2013 -0700 sb@sb:~/OSS/git$ git show --format=%ad 0da7a53^ Fri Jul 12 12:04:12 2013 -0700 sb@sb:~/OSS/git$ git show --format=%ad 0da7a53^^ Fri Jul 12 12:04:10 2013 -0700 sb@sb:~/OSS/git$ git show --format=%ad 0da7a53^^^ Fri Jul 12 12:04:09 2013 -0700 sb@sb:~/OSS/git$ git show --format=%ad 0da7a53 Fri Jul 12 12:04:07 2013 -0700 However I sometimes also get: sb@sb:~/OSS/git$ git show --format=%ad 0da7a53 Fri Jul 12 10:49:34 2013 -0700 diff --git a/Documentation/RelNotes/1.8.4.txt b/Documentation/RelNotes/1.8.4.txt index 0e50df8..4250e5a 100644 - --- a/Documentation/RelNotes/1.8.4.txt +++ b/Documentation/RelNotes/1.8.4.txt @@ -79,6 +79,13 @@ Foreign interfaces, subsystems and ports. UI, Workflows Features + * gitweb learned to optionally place extra links that point at the + levels higher than the Gitweb pages themselves in the breadcrumbs, + so that it can be used as part of a larger installation. + + * git log --format= now honors i18n.logoutputencoding configuration + variable. + * The push.default=simple mode of git push has been updated to behave like current without requiring a remote tracking information, when you push to a remote that is different from where sb@sb:~/OSS/git$ git show --format=%ad 0da7a53 Fri Jul 12 12:04:07 2013 -0700 diff --cc t/t5505-remote.sh index ee5d65d,8d0f3e3..8f6e392 - --- a/t/t5505-remote.sh +++ b/t/t5505-remote.sh @@@ -61,25 -62,25 +61,25 @@@ test_expect_success C_LOCALE_OUTPUT 're ' test_expect_success 'add another remote' ' -( - cd test - git remote add -f second ../two - tokens_match origin second $(git remote) - check_tracking_branch second master side another - git for-each-ref --format=%(refname) refs/remotes | - sed -e /^refs\/remotes\/origin\//d \ - -e /^refs\/remotes\/second\//d actual - expect So at some commits, also the diff is shown, which should not happen if you're using --format=%ad to my understanding. So far it seems to be deterministic here. (Each commit either always behaves correctly or incorrectly). Initially I suspected it being different for merges or no-merges, but I gut the unexpected behavior for both merge and non-merge commits. Can somebody confirm this behavior or has any idea, whether I am doing something wrong here? Thanks, Stefan -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (GNU/Linux) Comment: Using GnuPG with undefined - http://www.enigmail.net/ iQIcBAEBAgAGBQJR49xHAAoJEJQCPTzLflhqiFcP/0S5M71urjn1Fh5Cz2950wBl cs6+r9wKF5366wv3Ombfh0KrOPQCE7Yv1GWk2r2L008BWrz0wgnsl1xnMnAT00dH 1WzmupWExxwXHAueDisq2qL4dubFrnVxKWvpwxBd3JBbsWNXeTGl5o6dl69zaXdx JHzIHvw1/vrxoCLaflitjcQezuFITOVVoNsYawK12gznjxujONm0sej5TBFUw784 K5KTJNJqxzUf9+Z+88hg2oif7kJlugTIqtH5sRMVwXrkpc12f+HcwROg0srE5ITc 8WpK0s7xgZokUCohMhUXlLAOYJwAZju+K1LExkrQ9T32oP4iAKsJpqcRLAAX6Ig7 OeaWUQ2WX2CfYDExjuV6h+FXAU0qT87iv3PgeZWAnmgDQPUwFboIxuF1Nrpq/FOY Ioe2YOsFOdhmuDjCHEfu0aVNOeejHS8LEkC1IUI/+PzDlEJC/b17SwEdrD4aVCPj RZhz2zI8ZxYHP9ITvMDs1VQRP6jMSAwEtAWg7ac7ypETToOIAxRp2j9Rrjayt8A5 /TZ++wMh7G4Tm/D9+iutQnqzE8E8eiT6i7LgAcDSA3g6oq7/hUzupKU2lc+znO2J wxiwdqYBHWtw1Jc8eaZAJC/NMfxbRzOSCx4lJbO+tpXP0pR/OPIg2f2wUXcAh3zH JC9GdEUVIwN34j2ueoZ8 =G6Oc -END PGP SIGNATURE- -- 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 in git show?
On 07/15/2013 02:12 PM, Matthieu Moy wrote: Stefan Beller stefanbel...@googlemail.com writes: However I sometimes also get: sb@sb:~/OSS/git$ git show --format=%ad 0da7a53 Fri Jul 12 10:49:34 2013 -0700 diff --git a/Documentation/RelNotes/1.8.4.txt b/Documentation/RelNotes/1.8.4.txt index 0e50df8..4250e5a 100644 --- a/Documentation/RelNotes/1.8.4.txt +++ b/Documentation/RelNotes/1.8.4.txt git show will show the diff by default. For merge commits, it shows the --cc diff which is often empty, hence the behavior you see. You want to use git show -s, which suppresses the patch output. Thanks, that's exactly what I am looking for. Stefan signature.asc Description: OpenPGP digital signature
Re: [PATCH] commit: Fix a memory leak in determine_author_info
On 07/15/2013 04:42 PM, Junio C Hamano wrote: Stefan Beller stefanbel...@googlemail.com writes: The date variable is assigned new memory via xmemdupz and 2 lines later it is assigned new memory again via xmalloc, but the first assignment is never freed nor used. --- builtin/commit.c | 1 - 1 file changed, 1 deletion(-) diff --git a/builtin/commit.c b/builtin/commit.c index 790e5ab..00da83c 100644 --- a/builtin/commit.c +++ b/builtin/commit.c @@ -534,7 +534,6 @@ static void determine_author_info(struct strbuf *author_ident) (lb - strlen( ) - (a + strlen(\nauthor ; email = xmemdupz(lb + strlen(), rb - (lb + strlen())); -date = xmemdupz(rb + strlen( ), eol - (rb + strlen( ))); len = eol - (rb + strlen( )); date = xmalloc(len + 2); *date = '@'; Makes sense. I'd assume this is signed-off? As I realised I did not sign it, I resend it with some other findings a few hours later, so you'll find it there as well. See Message-ID 1373837749-14402-2-git-send-email-stefanbel...@googlemail.com [PATCH 2/4] commit: Fix a memory leak in determine_author_info -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 0/2] git diff -q option removal
On 07/15/2013 12:07 AM, Jonathan Nieder wrote:
This feature was obviously never tested with --no-index, so I agree it
makes sense to remove it. Probably the commit message and a comment
should say so, though. E.g.:
diff --no-index: remove nonfunctional -q handling
Before v1.5.6-rc1~41^2~2, the option parsing for diff --no-index
and git diff-files shared code. In git diff-files, -q means
to be silent about removed files. In git diff --no-index, in
various versions it has been an error, an infinite loop, or a no-op.
Simplify the code to clarify that it is now a no-op, continuing to
accept and ignore the -q option in git diff --no-index to avoid
breaking scripts.
I wouldn't mind removing support for -q altogether, by the way (as a
separate change).
Hope that helps,
Jonathan
I am resending the commit with a different wording, thanks to Jonathan.
However I tried to remove support for -q in a separate commit, and
I have some questions about the structure of the files.
(I am sure it's documented, but I cannot find it, so please hint me
where to read.)
The changes in the following patch are in diff_no_index.c, but the
diff_no_index(...) is called from cmd_diff, which is in builtin/diff.c
That cmd_diff is actually called from git.c having the
{ diff, cmd_diff }, entry in handle_internal_command.
My question now is this: Why is the builtin/diff.c relying on stuff
outside of builtin/ ? Wouldn't it be better to move all these files
(such as diff_no_index.c) into the builtin folder as well?
Regarding the removal of the -q option, I tried it in the second patch.
Is it as easy as that, or am I missing the point?
The first patch doesn't change the behavior, so I'd assume it's safe to
apply it to origin/sb/misc-fixes, whereas the second patch will make
git diff complain about the -q option, so I'd assume it would wait for the
next major release?
Before:
touch actual_file
git diff -q actual_file no_file
error: Could not access 'no_file'
echo $?
1
After:
touch actual_file
git diff -q actual_file no_file
fatal: invalid diff option/value: -q
echo $?
128
Thanks,
Stefan
Stefan Beller (2):
diff --no-index: remove nonfunctional -q handling
git diff: Remove -q option to stay silent on missing files.
Documentation/git-diff-files.txt | 6 +-
diff-no-index.c | 5 -
2 files changed, 1 insertion(+), 10 deletions(-)
--
1.8.2.3.10.g2733812
--
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] diff --no-index: remove nonfunctional -q handling
Before v1.5.6-rc1~41^2~2, the option parsing for diff --no-index
and git diff-files shared code. In git diff-files, -q means
to be silent about removed files. In git diff --no-index, in
various versions it has been an error, an infinite loop, or a no-op.
Simplify the code to clarify that it is now a no-op, continuing to
accept and ignore the -q option in git diff --no-index to avoid
breaking scripts.
Signed-off-by: Stefan Beller stefanbel...@googlemail.com
Helped-by: Jonathan Nieder jrnie...@gmail.com
---
diff-no-index.c | 5 +
1 file changed, 1 insertion(+), 4 deletions(-)
diff --git a/diff-no-index.c b/diff-no-index.c
index 74da659..419cd78 100644
--- a/diff-no-index.c
+++ b/diff-no-index.c
@@ -187,7 +187,6 @@ void diff_no_index(struct rev_info *revs,
{
int i, prefixlen;
int no_index = 0;
- unsigned options = 0;
const char *paths[2];
/* Were we asked to do --no-index explicitly? */
@@ -224,10 +223,8 @@ void diff_no_index(struct rev_info *revs,
int j;
if (!strcmp(argv[i], --no-index))
i++;
- else if (!strcmp(argv[i], -q)) {
- options |= DIFF_SILENT_ON_REMOVED;
+ else if (!strcmp(argv[i], -q))
i++;
- }
else if (!strcmp(argv[i], --))
i++;
else {
--
1.8.2.3.10.g2733812
--
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] diff: Remove -q to stay silent on missing files.
This feature was not tested in the test suite, hence we'd remove it for
now. It doesn't seem to be often used anyway.
A google search for git diff -q (match string exactly) only returned
http://stackoverflow.com/questions/11021287/git-detect-if-there-are-untracked-files-quickly
where git diff -q was quoted for its exit code behavior regarding files
being found or not.
Signed-off-by: Stefan Beller stefanbel...@googlemail.com
Proposed-by: Jonathan Nieder jrnie...@gmail.com
---
Documentation/git-diff-files.txt | 6 +-
diff-no-index.c | 2 --
2 files changed, 1 insertion(+), 7 deletions(-)
diff --git a/Documentation/git-diff-files.txt b/Documentation/git-diff-files.txt
index 906774f..d118cfb 100644
--- a/Documentation/git-diff-files.txt
+++ b/Documentation/git-diff-files.txt
@@ -9,7 +9,7 @@ git-diff-files - Compares files in the working tree and the
index
SYNOPSIS
[verse]
-'git diff-files' [-q] [-0|-1|-2|-3|-c|--cc] [common diff options] [path...]
+'git diff-files' [-0|-1|-2|-3|-c|--cc] [common diff options] [path...]
DESCRIPTION
---
@@ -41,10 +41,6 @@ omit diff output for unmerged entries and just show
Unmerged.
diff, similar to the way 'diff-tree' shows a merge
commit with these flags.
--q::
- Remain silent even on nonexistent files
-
-
include::diff-format.txt[]
GIT
diff --git a/diff-no-index.c b/diff-no-index.c
index 419cd78..98a9cf1 100644
--- a/diff-no-index.c
+++ b/diff-no-index.c
@@ -223,8 +223,6 @@ void diff_no_index(struct rev_info *revs,
int j;
if (!strcmp(argv[i], --no-index))
i++;
- else if (!strcmp(argv[i], -q))
- i++;
else if (!strcmp(argv[i], --))
i++;
else {
--
1.8.2.3.10.g2733812
--
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 0/6] Make git show -s easier to discover for users
On 07/16/2013 07:46 PM, Jonathan Nieder wrote: Matthieu Moy wrote: Matthieu Moy (6): t4000-diff-format.sh: modernize style diff: allow --no-patch as synonym for -s diff: allow --patch cie to override -s/--no-patch Documentation/git-show.txt: include common diff options, like git-log.txt Documentation: move description of -s, --no-patch to diff-options.txt Documentation/git-log.txt: capitalize section names Documentation/diff-options.txt | 5 Documentation/git-log.txt | 8 +++ Documentation/git-show.txt | 9 +++ Documentation/rev-list-options.txt | 3 --- diff.c | 30 ++-- t/t4000-diff-format.sh | 48 +++--- 6 files changed, 75 insertions(+), 28 deletions(-) Thanks! I think this series is ready now. Reviewed-by: Jonathan Nieder jrnie...@gmail.com Thanks as well. :) signature.asc Description: OpenPGP digital signature
Re: [PATCH] Fix some sparse warnings
On 07/16/2013 10:53 PM, Philip Oakley wrote:
From: Jeff King p...@peff.net
Sent: Tuesday, July 16, 2013 7:21 AM
On Tue, Jul 16, 2013 at 07:57:20AM +0200, Johannes Sixt wrote:
Am 7/15/2013 19:31, schrieb Ramsay Jones:
Sparse issues three Using plain integer as NULL pointer warnings.
Each warning relates to the use of an '{0}' initialiser expression
in the declaration of an 'struct object_info'.
I question the value of this warning. Initialization with '= {0}' is
a
well-established idiom, and sparse should know about it. Also, plain
0
*is* a null pointer constant.
I agree with you. It's not a bug, and I think sparse is being overly
picky here; it is missing the forest for the trees in interpreting the
idiom.
Still, it may be worth tweaking in the name of eliminating compiler
noise, since it does not cost us very much to do so (and I believe we
have done so in the past, too).
We could also ask people with sparse to turn off the use NULL instead
of 0 warning, but I think it _is_ a useful warning elsewhere (even
though it is never a bug, it violates our style guidelines and may be
an
indication of a bug). It would be nice if sparse learned to ignore the
warning in this particular idiom, but I am not going to hold my breath
for that.
-Peff
--
On the subject of warnings and null pointers, yesterday's Code Project
news linked to a blog on the problems of unexpected optimization bugs,
such as dereferencing a null pointer. Finding Undefined Behavior Bugs
by Finding Dead Code http://blog.regehr.org/archives/970 which links to
the draft of an interesting paper
[http://pdos.csail.mit.edu/~xi/papers/stack-sosp13.pdf]
Does anyone run the new static checker called 'Stack' that precisely
identifies unstable code? [though the paper's conclusion says 'All
Stack source code will be publicly available.' which suggests it's not
yet available]
Or use the ‘-fno-delete-null-pointer-checks’ referred to in the blog
comments (see also index : kernel/git/torvalds/linux.git Add
'-fno-delete-null-pointer-checks' to gcc CFLAGS
https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=a3ca86aea507904148870946d599e07a340b39bf
You're probably already aware of these aspects but I thought it worth
mentioning for the wider readership.
regards
Philip
I recently started contributing and I used cppcheck found at
https://github.com/danmar/cppcheck to submit the patches
at origin/sb/misc-fixes
As it is originally for C++, that tool throws lots of
false-positives (i.e. warns about null pointer dereferencing
when it's not possible to be a null pointer) unfortunately.
Also I hear llvm/clang comes with a good static code analyzer,
which I tried today on a different project.
Though I could not figure out how to use that on a pure C project
such as git, as that tool seems to require a C++ compilation for
doing its static code analysis.
The blog post you linked to seems very interesting and promising. :)
Regards,
Stefan
signature.asc
Description: OpenPGP digital signature
Re: [PATCH 0/2] git diff -q option removal
On 07/17/2013 07:04 PM, Junio C Hamano wrote: Builtins link all sorts of stuff from outside, e.g. diff.c and diffcore-*.c at the toplevel. I do not see diff_no_index.c is any different, so I am probably not understanding your question. Thanks for the explanation. I am not yet very used to gits code structure. So I sometimes think of 'how would I structure things', so I was confused of things in builtin using some parts outside of it. Maybe that folder raised to much expectations for me to be 'the real' core, whereas the files outside, i.e. those files in the top level directory, are just there for other things or scripts. This understanding of the structure seems obviously wrong now. Thanks for clarification. Hmm, do you really get that error message? I think you would get fatal: ambiguous argument 'no_file': unknown revision or path not in the working tree. echo $? 1 Ok here we go (using current origin/master 9c3c367): cd $(mktemp -d) echo test actual_file git diff actual_file no_file # error: Could not access 'no_file' echo $? 1 ## I get the same message as well, if I'm using -- or not. ## also the -q doesn't make a change git init git diff -q -- actual_file no_file echo $? # 0 git diff -- actual_file no_file echo $? # 0 git diff actual_file no_file # fatal: no_file: no such path in the working tree. # Use 'git command -- path...' to specify paths that do not exist locally. echo $? # 128 git diff -q actual_file no_file # fatal: no_file: no such path in the working tree. # Use 'git command -- path...' to specify paths that do not exist locally. echo $? 128 So apparently git diff behaves differently if not in a repo, which is what I tested. The command line parsing infrastructure has changed vastly since show-diff days (see below for a history lesson); A very interesting read, much appreciated. :) If we wanted to make -q follow the spirit of its original addition to show-diff again, we could internally add a diff-filter when the -q option is parsed. I'm rather new to the project, so my opinion may not have much weight, I'll state it anyway: Keeping backwards compatibility is really hard, because you need the knowledge of such history lessons as read above, to understand what should happen, like having an intuitive feeling about such parameters. Hence maintaining/evolving the project will become harder and harder (specially for newcomers). So having one and only one way to achieve the desired output, which fits into the greater structure as it's the case with --diff-filter is easier to remember for both the user and developers. Hence I think keeping the -q option would only make sense for the plumber layer, because there the explicit promise was given to not change stuff every other release. Stefan signature.asc Description: OpenPGP digital signature
[PATCH] .mailmap: Combine more (email, name) to individual persons
I got more responses from people regarding the .mailmap file. All added persons gave permission to add them to the .mailmap file. Signed-off-by: Stefan Beller stefanbel...@googlemail.com --- .mailmap | 10 +++--- 1 file changed, 7 insertions(+), 3 deletions(-) diff --git a/.mailmap b/.mailmap index 9430d14..df8898f 100644 --- a/.mailmap +++ b/.mailmap @@ -28,8 +28,7 @@ Chris Shoemaker c.shoema...@cox.net Chris Wright chr...@sous-sol.org chr...@osdl.org Csaba Henk cs...@gluster.com cs...@lowlife.hu Dan Johnson computerdr...@gmail.com -Dana L. How dana...@gmail.com -Dana L. How h...@deathvalley.cswitch.com +Dana L. How dana...@gmail.com h...@deathvalley.cswitch.com Daniel Barkalow barka...@iabervon.org David Brown g...@davidb.org dav...@quicinc.com David D. Kilzer ddkil...@kilzer.net @@ -52,6 +51,7 @@ Frédéric Heitzmann frederic.heitzm...@gmail.com Garry Dolley gdol...@ucla.edu gdol...@arpnetworks.com Greg Price pr...@mit.edu pr...@mit.edu Greg Price pr...@mit.edu pr...@ksplice.com +Heiko Voigt hvo...@hvoigt.net git-l...@hvoigt.net H. Merijn Brand h.m.br...@xs4all.nl H.Merijn Brand h.m.br...@xs4all.nl H. Peter Anvin h...@zytor.com h...@bonde.sc.orionmulti.com H. Peter Anvin h...@zytor.com h...@smyrno.hos.anvin.org @@ -74,7 +74,8 @@ Johannes Schindelin johannes.schinde...@gmx.de johannes.schinde...@gmx.de Johannes Sixt j...@kdbg.org j.s...@eudaptics.com Johannes Sixt j...@kdbg.org j.s...@viscovery.net Johannes Sixt j...@kdbg.org johannes.s...@telecom.at -Jon Loeliger j...@freescale.com +Jon Loeliger j...@jdl.com j...@freescale.com +Jon Loeliger j...@jdl.com j...@freescale.org Jon Seymour jon.seym...@gmail.com j...@blackcubes.dyndns.org Jonathan Nieder jrnie...@gmail.com jrnie...@uchicago.edu Jonathan del Strother jon.delstrot...@bestbefore.tv maill...@steelskies.com @@ -175,10 +176,13 @@ Sean Estabrooks seanl...@sympatico.ca Sebastian Schuberth sschube...@gmail.com sschube...@visageimaging.com Seth Falcon s...@userprimary.net sfal...@fhcrc.org Shawn O. Pearce spea...@spearce.org +Simon Hausmann hausm...@kde.org si...@lst.de +Simon Hausmann hausm...@kde.org shaus...@trolltech.com Stefan Naewe stefan.na...@gmail.com stefan.na...@atlas-elektronik.com Stefan Naewe stefan.na...@gmail.com stefan.na...@googlemail.com Stefan Sperling s...@elego.de s...@stsp.name Stephen Boyd bebar...@gmail.com sb...@codeaurora.org +Steven Drake sdr...@xnet.co.nz sdr...@ihug.co.nz Steven Grimm kor...@midwinter.com sgrimm@sgrimm-mbp.local Steven Walter stevenrwal...@gmail.com swal...@lexmark.com Steven Walter stevenrwal...@gmail.com swal...@lpdev.prtdev.lexmark.com -- 1.8.3.3.754.g9c3c367.dirty -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] Fix some sparse warnings
On 07/16/2013 10:53 PM, Philip Oakley wrote:
Does anyone run the new static checker called 'Stack' that precisely
identifies unstable code? [though the paper's conclusion says 'All
Stack source code will be publicly available.' which suggests it's not
yet available]
So I started using the clang code analyzer on git. One of the
first warnings actually is this:
object.c:241:7: warning: Branch condition evaluates to a garbage value
if (!eaten)
So that part of object.c lookx like this:
struct object *parse_object(const unsigned char *sha1)
{
int eaten;
...
obj = parse_object_buffer(sha1, type, size, buffer, eaten);
if (!eaten)
free(buffer);
}
And the parse_object_buffer looks like this with respect to the eaten
variable:
struct object *parse_object_buffer(...)
{
int eaten = 0;
if (something)
return NULL;
...
if (something_different)
eaten=1;
*eaten_p = eaten;
}
So what might happen is, that parse_object_buffer exits early, without
executing
*eaten_p = eaten;
Then in the parse_object function eaten was never initialized nor set
inside the call to parse_object_buffer. Then it is obvious that the
free(buffer) is executed depending on garbage left on the stack.
Definitely something what we want to change.
The obvious way to repair this would be to just initialize the eaten variable
inside parse_object.
struct object *parse_object(const unsigned char *sha1)
{
int eaten=0;
...
However I'd like to propose another solution:
In parse_object_buffer we do not have a local eaten variable, but
directly write to *eaten_p. That would be the following patch.
Was there a particular idea or goal behind first having a local eaten
variable, which later near the correct return of the function was used to set
the
eaten_p?
Thanks,
Stefan
signature.asc
Description: OpenPGP digital signature
[PATCH] parse_object_buffer: Correct freeing the buffer.
If we exit early in the function parse_object_buffer, we did not
write to *eaten_p. Then the calling function parse_object, which looks
like the following with respect to the eaten variable, cannot rely on a
proper value set in eaten, hence the freeing of the buffer depends
on random values in memory.
struct object *parse_object(const unsigned char *sha1)
{
int eaten;
...
obj = parse_object_buffer(sha1, type, size, buffer, eaten);
if (!eaten)
free(buffer);
}
This change makes sure, the buffer freeing condition is deterministic.
Signed-off-by: Stefan Beller stefanbel...@googlemail.com
---
object.c | 7 +++
1 file changed, 3 insertions(+), 4 deletions(-)
diff --git a/object.c b/object.c
index cbc7333..d8a4b1f 100644
--- a/object.c
+++ b/object.c
@@ -145,7 +145,7 @@ struct object *lookup_unknown_object(const unsigned char
*sha1)
struct object *parse_object_buffer(const unsigned char *sha1, enum object_type
type, unsigned long size, void *buffer, int *eaten_p)
{
struct object *obj;
- int eaten = 0;
+ *eaten_p = 0;
obj = NULL;
if (type == OBJ_BLOB) {
@@ -164,7 +164,7 @@ struct object *parse_object_buffer(const unsigned char
*sha1, enum object_type t
if (!tree-object.parsed) {
if (parse_tree_buffer(tree, buffer, size))
return NULL;
- eaten = 1;
+ *eaten_p = 1;
}
}
} else if (type == OBJ_COMMIT) {
@@ -174,7 +174,7 @@ struct object *parse_object_buffer(const unsigned char
*sha1, enum object_type t
return NULL;
if (!commit-buffer) {
commit-buffer = buffer;
- eaten = 1;
+ *eaten_p = 1;
}
obj = commit-object;
}
@@ -191,7 +191,6 @@ struct object *parse_object_buffer(const unsigned char
*sha1, enum object_type t
}
if (obj obj-type == OBJ_NONE)
obj-type = type;
- *eaten_p = eaten;
return obj;
}
--
1.8.3.3.754.g9c3c367.dirty
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] Fix some sparse warnings
On 07/18/2013 12:08 AM, Stefan Beller wrote: So I started using the clang code analyzer on git. One of the first warnings actually is this: So in case somebody else would also like to play around with the clang static code analyzer: # get clang: cd good location git clone http://llvm.org/git/llvm.git cd llvm/tools git clone http://llvm.org/git/clang cd good location mkdir build cd build cmake .. # if desired make install # in the Makefile of git change CC = good location/llvm/tools/clang/tools/scan-build/ccc-analyzer # then obviously: make clean make signature.asc Description: OpenPGP digital signature
[PATCH 3/3] apply, find_name_traditional: Do not initialize len to the lines length.
The variable len is set to
len = strchrnul(line, '\n') - line;
unconditionally 9 lines later, hence we can remove the call to strlen.
Signed-off-by: Stefan Beller stefanbel...@googlemail.com
---
builtin/apply.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/builtin/apply.c b/builtin/apply.c
index 1218688..681a40b 100644
--- a/builtin/apply.c
+++ b/builtin/apply.c
@@ -722,7 +722,7 @@ static char *find_name(const char *line, char *def, int
p_value, int terminate)
static char *find_name_traditional(const char *line, char *def, int p_value)
{
- size_t len = strlen(line);
+ size_t len;
size_t date_len;
if (*line == '') {
--
1.8.3.3.754.g9c3c367.dirty
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/3] http-push.c, add_send_request: Do not initialize transfer_request.
That pointer will be assigned to new memory via
request = xmalloc(sizeof(*request));
20 lines later unconditionally anyway, so it's safe to not assign it to an
arbitrary variable.
As this patch is a micro-optimization (for readability?) it would be nice
to have as little work with this patch, so maybe I need a feature to send
a patch without a symmetric number of lines around change-diff. For this
patch I'd be only interested in showing the next 20 lines, but nothing
really before the function declaration.
Signed-off-by: Stefan Beller stefanbel...@googlemail.com
---
http-push.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/http-push.c b/http-push.c
index 395a8cf..6dad188 100644
--- a/http-push.c
+++ b/http-push.c
@@ -663,7 +663,7 @@ static void add_fetch_request(struct object *obj)
static int add_send_request(struct object *obj, struct remote_lock *lock)
{
- struct transfer_request *request = request_queue_head;
+ struct transfer_request *request;
struct packed_git *target;
/* Keep locks active */
--
1.8.3.3.754.g9c3c367.dirty
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/3] treewalk.c: Rename variable ret to cb_bits and remove some dead lines.
The variable name ret sounds like the variable to be returned, but
since e6c111b4 we return error. Hence the variable name is miss leading.
As this variable is used only to extract the bits from the callback of
a tree object, I named it cb_bits for callback bits.
Also the assignment to 0 was removed at the start of the function as well
after the if(interesting) block. Those were unneeded as that variable
is set to the callback return value any time we enter the if(interesting)
block, so we'd overwrite old values anyway.
Signed-off-by: Stefan Beller stefanbel...@googlemail.com
---
tree-walk.c | 11 +--
1 file changed, 5 insertions(+), 6 deletions(-)
diff --git a/tree-walk.c b/tree-walk.c
index c366852..3c323d1 100644
--- a/tree-walk.c
+++ b/tree-walk.c
@@ -324,7 +324,6 @@ static inline int prune_traversal(struct name_entry *e,
int traverse_trees(int n, struct tree_desc *t, struct traverse_info *info)
{
- int ret = 0;
int error = 0;
struct name_entry *entry = xmalloc(n*sizeof(*entry));
int i;
@@ -342,6 +341,7 @@ int traverse_trees(int n, struct tree_desc *t, struct
traverse_info *info)
strbuf_setlen(base, info-pathlen);
}
for (;;) {
+ int cb_bits;
unsigned long mask, dirmask;
const char *first = NULL;
int first_len = 0;
@@ -405,15 +405,14 @@ int traverse_trees(int n, struct tree_desc *t, struct
traverse_info *info)
if (interesting 0)
break;
if (interesting) {
- ret = info-fn(n, mask, dirmask, entry, info);
- if (ret 0) {
- error = ret;
+ cb_bits = info-fn(n, mask, dirmask, entry, info);
+ if (cb_bits 0) {
+ error = cb_bits;
if (!info-show_all_errors)
break;
}
- mask = ret;
+ mask = cb_bits;
}
- ret = 0;
for (i = 0; i n; i++)
if (mask (1ul i))
update_extended_entry(tx + i, entry + i);
--
1.8.3.3.754.g9c3c367.dirty
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] status_printf_ln: Suppress false positive warnings of empty format string.
This is a response to 8dd0ee823f1829a3aa228c3c73e31de5c89b5317.
Instead of having an empty string as format for the printf like function
status_printf_ln, we could insert an empty string into the format
parameter.
A similar fixup commit is found in linux (2e4c332913b5), but there
the empty string is replaced by a string containing one whitespace.
To determine, which approach is better I setup 2 test programs, which
either have a whitespace format ( ) or the empty string (%s, ),
looking like:
-
#include stdlib.h
#include stdio.h
int main (int argc, char** argv) {
long i;
for (i = 0; i 1024*1024*1024; ++i)
printf( );
}
-
Checking the required time of the programs, while redirecting the actual
output (the billion white spaces compared to nothing) to /dev/null
indicates that the approach used in this patch is faster regardless
of the optimization level of gcc.
Also this patch doesn't change output, which favors this approach over
the whitespace approach.
The only thing left to discuss, whether this patch is worth it, as it
only suppresses false positive warnings from gcc, but makes the
code slightly harder to read.
Signed-off-by: Stefan Beller stefanbel...@googlemail.com
---
builtin/commit.c | 2 +-
wt-status.c | 18 +-
2 files changed, 10 insertions(+), 10 deletions(-)
diff --git a/builtin/commit.c b/builtin/commit.c
index 65cf2a7..34bc274 100644
--- a/builtin/commit.c
+++ b/builtin/commit.c
@@ -773,7 +773,7 @@ static int prepare_to_commit(const char *index_file, const
char *prefix,
committer_ident.buf);
if (ident_shown)
- status_printf_ln(s, GIT_COLOR_NORMAL, );
+ status_printf_ln(s, GIT_COLOR_NORMAL, %s, );
saved_color_setting = s-use_color;
s-use_color = 0;
diff --git a/wt-status.c b/wt-status.c
index cb24f1f..912ed88 100644
--- a/wt-status.c
+++ b/wt-status.c
@@ -179,7 +179,7 @@ static void wt_status_print_unmerged_header(struct
wt_status *s)
} else {
status_printf_ln(s, c, _( (use \git add/rm file...\ as
appropriate to mark resolution)));
}
- status_printf_ln(s, c, );
+ status_printf_ln(s, c, %s, );
}
static void wt_status_print_cached_header(struct wt_status *s)
@@ -195,7 +195,7 @@ static void wt_status_print_cached_header(struct wt_status
*s)
status_printf_ln(s, c, _( (use \git reset %s file...\ to
unstage)), s-reference);
else
status_printf_ln(s, c, _( (use \git rm --cached file...\
to unstage)));
- status_printf_ln(s, c, );
+ status_printf_ln(s, c, %s, );
}
static void wt_status_print_dirty_header(struct wt_status *s,
@@ -214,7 +214,7 @@ static void wt_status_print_dirty_header(struct wt_status
*s,
status_printf_ln(s, c, _( (use \git checkout -- file...\ to
discard changes in working directory)));
if (has_dirty_submodules)
status_printf_ln(s, c, _( (commit or discard the untracked or
modified content in submodules)));
- status_printf_ln(s, c, );
+ status_printf_ln(s, c, %s, );
}
static void wt_status_print_other_header(struct wt_status *s,
@@ -226,12 +226,12 @@ static void wt_status_print_other_header(struct wt_status
*s,
if (!advice_status_hints)
return;
status_printf_ln(s, c, _( (use \git %s file...\ to include in
what will be committed)), how);
- status_printf_ln(s, c, );
+ status_printf_ln(s, c, %s, );
}
static void wt_status_print_trailer(struct wt_status *s)
{
- status_printf_ln(s, color(WT_STATUS_HEADER, s), );
+ status_printf_ln(s, color(WT_STATUS_HEADER, s), %s, );
}
#define quote_path quote_path_relative
@@ -1192,7 +1192,7 @@ void wt_status_print(struct wt_status *s)
on_what = _(Not currently on any branch.);
}
}
- status_printf(s, color(WT_STATUS_HEADER, s), );
+ status_printf(s, color(WT_STATUS_HEADER, s), %s, );
status_printf_more(s, branch_status_color, %s, on_what);
status_printf_more(s, branch_color, %s\n, branch_name);
if (!s-is_initial)
@@ -1205,9 +1205,9 @@ void wt_status_print(struct wt_status *s)
free(state.detached_from);
if (s-is_initial) {
- status_printf_ln(s, color(WT_STATUS_HEADER, s), );
+ status_printf_ln(s, color(WT_STATUS_HEADER, s), %s, );
status_printf_ln(s, color(WT_STATUS_HEADER, s), _(Initial
commit));
- status_printf_ln(s, color(WT_STATUS_HEADER, s), );
+ status_printf_ln(s, color(WT_STATUS_HEADER, s), %s, );
}
wt_status_print_updated(s);
@@ -1224,7 +1224,7 @@ void wt_status_print(struct wt_status *s)
if (s
Re: [PATCH] status_printf_ln: Suppress false positive warnings of empty format string.
Even if the variant is faster, it does not matter if its output is incorrect ;-) Agreed. I think we discussed this already? The conclusion was it is silly for GCC to warn on -Wformat-zero-length for user-defined function in the first place, IIRC. func(other, args, fmt,...), when invoked as func(other, args, ), may very well do something useful regardless of the formatting part based on other args. I am sorry, I did not pay attention enough to that specific topic. I was just finding warnings on next and pu, so I wondered how to fix it. signature.asc Description: OpenPGP digital signature
[PATCH] Documentation, git reset: fix typo.
Reported-By: Ibrahim M. Ghazal img...@gmail.com Signed-off-by: Stefan Beller stefanbel...@googlemail.com --- Documentation/git-reset.txt | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/Documentation/git-reset.txt b/Documentation/git-reset.txt index a404b47..f445cb3 100644 --- a/Documentation/git-reset.txt +++ b/Documentation/git-reset.txt @@ -9,7 +9,7 @@ SYNOPSIS [verse] 'git reset' [-q] [tree-ish] [--] paths... -'git reset' (--patch | -p) [tree-sh] [--] [paths...] +'git reset' (--patch | -p) [tree-ish] [--] [paths...] 'git reset' [--soft | --mixed | --hard | --merge | --keep] [-q] [commit] DESCRIPTION -- 1.8.3.3.754.g9c3c367.dirty -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/3] treewalk.c: Rename variable ret to cb_bits and remove some dead lines.
On 07/19/2013 08:13 PM, Junio C Hamano wrote: The ret was meant to mean the return value we got from the callback function, not the return value we would give our caller. Thanks for clarifying. I assumed the ret was meant as the return value of that function as it was the case before e6c111b4c. In other projects I am using ret as the return value we would give our caller as it's such a convenient name for that if you cannot come up with a better name. This rename is a bit misleading in that cb_bits == -1 does not mean full bits set, and it does not tell us much what these bits signify. They are used to answer this question: which one of the trees in t[0..n] did the callback function consumed (hence needs their pointers updated). So perhaps call it trees_used or something? Sounds indeed way better. I'll rename it. By the way, our log message usually do not Capitalize the subject after the area:, i.e. do something like this instead: Subject: [PATCH 1/3] traverse_trees(): clarify return value of the callback Thanks. Thanks for pointing out. As a general question: I was mostly doing micro-optimisations or the mailmap file, which are rather small fixups, which I think are ok for beginners. Is there a tasklist for beginners, other than that? Such as porting shell commands to C or other larger tasks? I used git://github.com/gitster/git.git as remote/origin. There the todo branch has the last commit as of 2012/04, so I also found git://git.kernel.org/pub/scm/git/git.git, where the todo branch seems more up-to-date, but the TODO file there also seems a little dated to me. So is there any up-to-date task list for beginning contributors? Stefan -- 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
