Except that "git-clone" doesn't work with Git >= 1.6. If you ask the question, I suspect you have a rather old version of Git and you're a beginner. Git's user-friendlyness to newbies greatly improved over the last versions, so I'd suggest upgrading. -- Matthieu Moy http://www-verimag.imag.fr/~moy/ --

Out-of-memory errors can either be actual lack of memory, or bugs (like code trying to call xmalloc(-1) by mistake). A little more information may help tracking bugs reported by users. Signed-off-by: Matthieu Moy <Matthieu.Moy@imag.fr> --- I don't promise miracle ;-). But at least, the diagnosis allows one to distinguish small allocations, huge ones, and silly errors like small Sounds good. Not sure why we don't basically use the %lu version everywhere though. wrapper.c | 3 ++- ...

Hi Tay, Ah yes. It looks like I missed this earlier. Sorry for the noise. -- Ram --

Hi Stephen, Thanks for the testcase! Offhand, it definitely looks like a bug. I'm investigating to figure out which part of the chain is at fault. -- Ram --

Hi Johannes, Ah, just when I was about to post the series. Excellent idea! I'll drop Jonathan's patch and fixup the series to do this in a few I'll use git_config_bool_or_int for this -- we've traded off the ability to say "infinite" though. -- Ram --

Hi, The first three parts make `merge.log` and `--log` an integer. While at it, drop the deprecated `--summary` option: blame tells me that it was marked deprecated back in 2008. The series is based on pu for no good reason. Thanks to Johannes and Jonathan for their inputs. -- Ram Ramkumar Ramachandra (4): fmt-merge-msg: Make the number of log entries in commit message configurable fmt-merge-msg: Update command line options to sync with config options fmt-merge-msg: ...

Hi Jakub, Hm, I think I found a bug in the option parser. Currently writing a patch. $ git fmt-merge-msg --log < .git/FETCH_HEAD error: option `log' requires a value $ git fmt-merge-msg --log= < .git/FETCH_HEAD $ # Works -- Ram --

Hi Jonathan, Oops. I forgot about the new policy: when a patch isn't ready for inclusion, I must say that explicitly and sign off so others can base their work on my patch, right? Looks good- since you're interested in this too, I'll include your patch, test it and post a series to the list. Thanks. -- Ram --

Hi Yaroslav, You're perhpas looking for something like this? Warning: Untested. -- 8< -- commit 86c34c682345843d9138882a85ba36faf10e0d95 Author: Ramkumar Ramachandra <artagnon@gmail.com> Date: Fri Aug 20 12:12:59 2010 +0530 fmt-merge-msg: Make the number of log entries in shortlog configurable Introduce a new configuration option called merge.logLimit to limit the number of log entries displayed in the shortlog of a merge commit configurable. Set the default ...

Hi, There's now a new patch in the series; thanks to Jakub for poking me hard enough :) -- Ram Ramkumar Ramachandra (5): parse-options: Allow PARSE_OPT_NOARG in integer arguments fmt-merge-msg: Make the number of log entries in commit message configurable fmt-merge-msg: Update command line options to sync with config options fmt-merge-msg: Remove deprecated --summary option fmt-merge-msg: Update fmt-merge-msg and merge-config documentation ...

Hi Felipe, No, Johannes can't. He's not a bureaucrat [1]. [1]: https://git.wiki.kernel.org/index.php?title=Special:ListUsers&group=bureaucrat -- Ram --

Update the documentation of fmt-merge-msg and merge-config to reflect the fact that `merge.log` can either be a boolean or integer option now, instead of just a boolean. Signed-off-by: Ramkumar Ramachandra <artagnon@gmail.com> Cc: Johannes Sixt <j.sixt@viscovery.net> Cc: Jonathan Nieder <jrnieder@gmail.com> --- Documentation/git-fmt-merge-msg.txt | 24 +++++++++--------------- Documentation/merge-config.txt | 8 ++++++-- 2 files changed, 15 insertions(+), 17 deletions(-) diff ...

Update the `--log` and `--summary` command line options to be integers and have the same effect as the `merge.log` and `merge.summary` configuration options. Signed-off-by: Ramkumar Ramachandra <artagnon@gmail.com> Cc: Johannes Sixt <j.sixt@viscovery.net> Cc: Jonathan Nieder <jrnieder@gmail.com> --- builtin/fmt-merge-msg.c | 19 +++++++++---------- 1 files changed, 9 insertions(+), 10 deletions(-) diff --git a/builtin/fmt-merge-msg.c b/builtin/fmt-merge-msg.c index 66b1cbd..67f24f8 ...

Update the documentation of fmt-merge-msg and merge-config to reflect the fact that `merge.log` can either be a boolean or integer option now, instead of just a boolean. Signed-off-by: Ramkumar Ramachandra <artagnon@gmail.com> --- Documentation/git-fmt-merge-msg.txt | 20 +++++++++----------- Documentation/merge-config.txt | 8 ++++++-- 2 files changed, 15 insertions(+), 13 deletions(-) diff --git a/Documentation/git-fmt-merge-msg.txt b/Documentation/git-fmt-merge-msg.txt index ...

Update the documentation of 'git shell' to mention the interactive mode and COMMAND_DIR. Also provide a hint when interactive mode is not available in the shell. Signed-off-by: Ramkumar Ramachandra <artagnon@gmail.com> Cc: Greg Brockman <gdb@MIT.EDU> Cc: Petr Baudis <pasky@suse.cz> --- Documentation/git-receive-pack.txt | 2 +- Documentation/git-shell.txt | 27 ++++++++++++++++----------- shell.c | 7 +++++-- 3 files changed, 22 insertions(+), 14 ...

Make the `merge.log` option either an integer or boolean instead of just a boolean. The integer can be used to specify how many merged commits to summarize (at maximum) in the merge message. Let true mean 20. Default to false. Signed-off-by: Ramkumar Ramachandra <artagnon@gmail.com> Reported-by: Yaroslav Halchenko <debian@onerussian.com> Thanks-to: Johannes Sixt <j.sixt@viscovery.net> Thanks-to: Jonathan Nieder <jrnieder@gmail.com> --- builtin/fmt-merge-msg.c | 23 +++++++++++++++-------- ...

Update the `--log` and `--summary` command line options to be integers and have the same effect as the `merge.log` and `merge.summary` configuration options. Signed-off-by: Ramkumar Ramachandra <artagnon@gmail.com> Cc: Johannes Sixt <j.sixt@viscovery.net> Cc: Jonathan Nieder <jrnieder@gmail.com> --- builtin/fmt-merge-msg.c | 24 ++++++++++++------------ 1 files changed, 12 insertions(+), 12 deletions(-) diff --git a/builtin/fmt-merge-msg.c b/builtin/fmt-merge-msg.c index ...

Hi Jonathan, Elegant. OPT_INTEGER for integers without the ability to represent infinity, and OPT_INT_INF for integers with definite representation Nice. You're making the caller pass the `inf_val` argument - this way, each caller can figure out some integer that's outside its sane range Okay, you've used the same character "n" for OPT_INTEGER and OPT_INT_INF. Thanks for the pleasant reading. -- Ram --

I must say, you guys have an odd sense of aesthetics :) --

No problem. I was very happily to isolate it outside the large repo I was working with... Contrary to my first e-mail, 'git checkout -b branchFoo tagFoo' doesn't solve the problem... My guess is I got lazy and did a "normal" local clone (no file URL) when I was testing. Data from further testing: - doing a "normal" local clone doesn't emit the error - a remote clone over ssh does emit the error (so it's not just file:///) - in a brand new repo (init'ed, not cloned) 'git fetch ../foo ...

After a lot of guess and check, it appears the issue is somehow related to the refs/original directory created by filter-branch. If that directory is moved out of refs/ or deleted the clone succeeds. Digging further, a simple rename of refs/original/refs/tags/tagFoo to anything else also fixes the problem. A simplified test case is: git init foo cd foo echo A >> foo.txt git add foo.txt git commit -m "Created foo" git tag -am "Tagging foo" tagFoo git filter-branch --env-filter 'export ...

I'm just posting this to the list because I should really already be in bed... Running t7610-mergetool with -q isn't quiet. This is also noticeable when running the full test suite in a TAP harness (e.g. prove). $ ./t7610-mergetool.sh -q Normal merge conflict for 'file1': {local}: modified {remote}: modified Normal merge conflict for 'file2': {local}: created {remote}: created Normal merge conflict for 'subdir/file3': {local}: modified {remote}: modified # passed all 7 ...

No special reason, I just thought it was more natural to save it at the ... but given that this approach is evidently less portable your way is Thanks, I'll re-roll in a bit at squash your fixes in, if that's OK? Charles. --

mergetool used /dev/tty to switch back to receiving input from the user via inside a block with a redirected stdin. This harms testability, so change mergetool to save its original stdin to an alternative fd in this block and restore it for those sub-commands that need the original stdin. Includes additional compatibility fix from Jonathan Nieder. Tested-by: Jonathan Nieder <jrnieder@gmail.com> Signed-off-by: Charles Bailey <charles@hashpling.org> --- Now works on ksh as well as bash ...

Ok so please apply Duy's patch perhaps with an improved commit message. Thanks, Christian. --

Hi Git Developers, Shame on me but couldn't figure out if there is any official bug tracker for git -- previously I just complained here, so keeping the tradition: merge.log (or merge.summary) enables a really nice feature of including a list of commits involved in the merge. Unfortunately it is limited to 20 entries and only includes total number of included commits if that is larger than 20. Looking at the source code (if I got it right) static int do_fmt_merge_msg(int merge_title, ...

On Wed, Aug 11, 2010 at 5:24 PM, Ramkumar Ramachandra Why hasn't this been done? Also, Johannes can give admin rights too. -- Felipe Contreras --

What is this patch based on? I don't see a branch that has these two --

If (and this may be a big IF) it is reasonable to add paths to .gitignore that you do not want to lose, then you would want to have three classes of untracked paths: "precious but ignored", "trashable" (and by definition ignored), and "unignored" (and by definition is not ignored and is precious). As I already pointed out, we don't support the "precious but ignored" class. So an obvious alternate solution to your particular case is not to add such a path to the gitignore mechanism. I have a ...

Sorry but why? Doesn't NOARG mean "Do not take an argument, if you give me an argument that is an error"? I would understand if this were OPT_OPTARG, though. --

There's also the slightly longer but somewhat prettier '"'"'. - Hari --

I don't miss it. But can we still write in the config file [merge] log as a short-hand for [merge] log = true ? If *that* were not possible anymore, it would be a regression. -- Hannes --

Hi all I'm experiencing the following error while pushing a git repo (home directory) to my QNAP TS-210: user@mypc:~$ git push origin master Counting objects: 12532, done. Delta compression using up to 2 threads. Compressing objects: 100% (8974/8974), done. fatal: Out of memory, malloc failed, 986.06 MiB | 1.65 MiB/s error: pack-objects died of signal 13 error: pack-objects died with strange error error: failed to push some refs ...

I'm using git version 1.7.0.4 on my Kubuntu 10.04 Laptop and git version 1.7.1.1 on my QNAP NAS. On my Laptop and on the NAS, when I execute: sudo sysctl vm.overcommit_memory I get: vm.overcommit_memory = 0 Do you propose to set this to '2' in order to disable overcommitting? If yes, where (on the Laptop and/or on the NAS)? Thanks, Tom --

----- Original Message ----- From: Clemens Buchacher I like the idea... :) My vote doesn't count, though... Josh --

Perhaps --depth=0 should also work as if --tags were specified on command line? BTW. shouldn't git fetch tags that point to commits If there were more options that use <n> == 0 to actually mean unlimited (infinity), perhaps it would be better to extend parseopt to provide for such situation, e.g. OPT_INT_INF or something. This way we would avoid code duplication. ... oh, wait, the newly introduced[1] git-merge `--log-limit' option uses --log-limit=0 to mean unlimited. [1] ...

Shouldn't it be +'git fmt-merge-msg' [-m <message>] [--log[=<n>] | --no-log] -F <file> i.e. isn't <n> in '--log' optional? -- Jakub Narebski Poland ShadeHawk on #git --

(+cc: Nicolas, who knows the packing code pretty well) Hi, What version of git are you using? Do you have overcommit accounting enabled? I am not sure this is the problem you are running into, but pack-objects like many other parts of git uses mmap() to read packfiles, which can I don't know --- this is out of my depth. :) Good luck, Jonathan --

It might be interesting to try echo 1 >/proc/sys/vm/overcommit_memory but 0 is generally the only sane setting. --

That was fast. Thanks for checking. --

The current output (with Asciidoc 8.5.2) seems a bit broken: given two directories ‘d` and d2, there is a difference between using git rm 'd*’ and ‘git rm 'd/\*\’`, as the former will also remove all of directory d2. In other words, the markup parses as given two directories << d` and _d2_, there is a difference between using _git rm 'd* >>_ and << git rm 'd/\*\ >> `. I suspect there is an asciidoc bug involved (why is ' a candidate closing-quote mark when it is preceded by a ...

The intended text looks like this: · Adds content from all *.txt files under Documentation directory and its subdirectories: $ git add Documentation/\*.txt Note that the asterisk * is quoted from the shell in this example; this lets the command include the files from subdirectories of Documentation/ directory. The current asciidoc 8.5.2 output has a backslash before _every_ asterisk, which is more confusing than it needs to be. Reported-by: Frédéric Brière ...

Because there is no unescaped apostrophe to pair it with, asciidoc does not consider this apostrophe a candidate for escaping and the backslash passes through. Reported-by: Frédéric Brière <fbriere@fbriere.net> Signed-off-by: Jonathan Nieder <jrnieder@gmail.com> --- Documentation/git-show-branch.txt | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/Documentation/git-show-branch.txt b/Documentation/git-show-branch.txt index 81ba296..01fc157 100644 --- ...

The intended text is "it's O(N * T) vs O(N * T * M)". Asciidoc notices the spaces around the asterisks so there is no need to escape them (and if you try, it passes the backslashes through). Cc: Christian Couder <chriscool@tuxfamily.org> Signed-off-by: Jonathan Nieder <jrnieder@gmail.com> --- That's the end of the series. Thanks for reading. Documentation/git-bisect-lk2009.txt | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/Documentation/git-bisect-lk2009.txt ...

Signed-off-by: Jonathan Nieder <jrnieder@gmail.com> --- Documentation/user-manual.txt | 4 ++-- 1 files changed, 2 insertions(+), 2 deletions(-) diff --git a/Documentation/user-manual.txt b/Documentation/user-manual.txt index 22aee34..fecc4eb 100644 --- a/Documentation/user-manual.txt +++ b/Documentation/user-manual.txt @@ -4251,9 +4251,9 @@ Two things are interesting here: negative numbers in case of different errors--and 0 on success. - the variable `sha1` in the function ...

Part of the run_merge_tool codepath. The only place this is called with TOOL_MODE=merge is by merge_file which has stdin redirected, I would think this should work, but it doesn't feel idiomatic. Why not save stdin a little earlier, so the reader does not have to track down whether it has been redirected? The test quietly passes for me with dash but fails with ksh: /home/jrn/src/git4/git-mergetool: line 303: 3: cannot open [Bad file descriptor] With the patch below on top, it ...

The symmetric difference or merge-base operator ... as used by rev-list and diff is actually three period characters. If it gets replaced by an ellipsis glyph in the manual, that would stop readers from copying and pasting it. Signed-off-by: Jonathan Nieder <jrnieder@gmail.com> --- Documentation/git-checkout.txt | 2 +- Documentation/git-push.txt | 2 +- Documentation/git-rebase.txt | 2 +- Documentation/rev-list-options.txt | 2 +- 4 files changed, 4 ...

Intended output: git rm Documentation/\*.txt Removes all *.txt files from the index that are under the Documentation directory and any of its subdirectories. Note that the asterisk * is quoted from the shell in this example; this lets git, and not the shell, expand the pathnames of files and subdirectories under the Documentation/ directory. Without this change, there are too many backslashes output. Tested with asciidoc 8.5.2. Reported-by: Frédéric Brière ...

Due to some unpleasant interaction between the `quote', 'italics', and `monospace` rules, a certain paragraph ends up rendered like so: ‘short` is a character for the short option (e.g. <tt>'e\’</tt> for <tt>-e</tt>, use <tt>0</tt> to omit), Use the {apostrophe} to avoid this. While at it, escape "->" strings: they are meant as a literal two-character C operator, not a right-pointing arrow. Reported-by: Frédéric Brière <fbriere@fbriere.net> Signed-off-by: Jonathan Nieder ...

Just a proof of concept. Cc: René Scharfe <rene.scharfe@lsrfire.ath.cx> Signed-off-by: Jonathan Nieder <jrnieder@gmail.com> --- Something like this, maybe. Documentation/technical/api-parse-options.txt | 6 ++++++ builtin/grep.c | 8 ++++++-- grep.c | 8 +++++--- grep.h | 4 ++-- parse-options.c | 21 +++++++++++++++++++++ ...

Yep, someone else recently sent a report about such a sed version, too. It is breaking our fragile minds; we ought to find some way to deal with it, but we haven't yet. Jonathan --

For some reason, various manual pages have an asterisk escaped with \ in the synopsis. Since there is no other asterisk to pair it with, Asciidoc does not consider this asterisk escapable, so it passes the backslash through. Each page either uses [verse] or has only one asterisk, so it is safe to drop the backslashes (checked with asciidoc 8.5.2). Signed-off-by: Jonathan Nieder <jrnieder@gmail.com> --- Documentation/git-checkout-index.txt | 2 +- Documentation/git-commit-tree.txt | ...

What do you mean by remove? If you want to undo changes that are in the current patch you can do something like: git checkout HEAD~1 filename stg refresh If you want to retain the changes but move them to another patch: git reset HEAD filename stg refresh -i I regularly use the first method, the second method I _think_ will work but haven't tried it. --

Ick. Interestingly, the new paths I added for additional output are not being triggered here. Rather, "normal" renames are being considered unprocessed (I had a faulty assumption in the previous patch that a clean merge would have cleared out the higher stage entries in dst_entry as a side effect). Because of this, normal renames are needlessly re-processed in process_entry(), and trigger extra output as a side-effect. One could work around this by the following patch, though it'd be ...

How much memory is there on the machine where the pushed data is going? Nicolas --

clone_local() function disregards --depth. Make it more apparent. Also hint users that file:// works with --depth. Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com> --- builtin/clone.c | 8 ++++++-- 1 files changed, 6 insertions(+), 2 deletions(-) diff --git a/builtin/clone.c b/builtin/clone.c index efb1e6f..e787cf2 100644 --- a/builtin/clone.c +++ b/builtin/clone.c @@ -361,7 +361,7 @@ static void write_remote_refs(const struct ref *local_refs) int cmd_clone(int argc, const ...

On Sat, Aug 21, 2010 at 1:41 AM, Ramkumar Ramachandra Please see <AANLkTi=3z9gJdT8LL3NANFyppUjvOVcrszjf5J5zAKPe@mail.gmail.com> -- Cheers, Ray Chuan --

Hello all, I am filtering our repo with git-filter-branch, but as the sed script runs with LANG=C LC_ALL=C (7 bit US ASCII), it dies on commits authored by our team members with accented names. Why are the locales "C"? For compatibility with older sed? I've changed to LANG=en_US.UTF-8, will my change will cause other git-breakage? git-filter-branch 95: LANG=C LC_ALL=C sed -ne "$pick_id_script" 95: LANG=en_US.UTF-8 sed -ne "$pick_id_script" Regards, Richard --

I'm new to git and I wonder what is the difference between two commands: "git clone" and "git-clone" and which one should be use? -- View this message in context: http://git.661346.n2.nabble.com/git-commands-tp5443370p5443370.html Sent from the git mailing list archive at Nabble.com. --