commit cd74a041 filtered duplicate email addresses, especially with the --auto option. However, it broke a common practice of cc'ing yourself on a patch. [nb, I don't do this myself, but there are several legit reasons] This patch allows you to do something like: stg mail --to=<someaddr> --cc=<myaddr> --auto <patch> Under my testing, with <myaddr> in the Signed-off-by: path: - we still do not send duplicates to <myaddr> (cd74a041 still holds) - we do not Cc: <myaddr> unless ...

Hi, I ran in to a warning message while cloning a remote repository. The message is warning: remote HEAD refers to nonexistent ref, unable to checkout. After the cloning i couldn't see any remote files. The .git folder is created successfully. Regards, Shameem --

Hi there. I have: $ git version git version 1.6.5.1.1367.gcd48 $ git config --get core.autocrlf false A repository with some UNIX (LF) and some Windows (CRLF) files. (and no: I will not change the files. My editors handle CRLF and LF correctly) My problem: 'git am' can't handle changes in CRLF files because the patch gets converted (by git mailsplit) to contain only LF. Which is wrong IMHO. git-am on my msysgit version looks like this (lines: ...

I'm doing that. In the post-receive hook I have: << while read oldrev newrev ref; do trac_post_receive_record_log "$oldrev" "$newrev" "$ref" gtest send_mail_post_receive "$oldrev" "$newrev" "$ref" gtest \ pascal@obry.net another@here.com the trac_post_receive_record_log is to add log into trac bug tracker. the send_mail_post_receive is to send a message to the recipients listed. The 4th parameter is the name of the project. The send_mail_post_receive function ...

On Fri, 13 Nov 2009 11:42 +0100, "Matthieu Moy" Thank you for your suggestions. I've added a new post-receive hook using the code from post-receive-email. The hook is executable and is placed in the remote directory. The push is made from my local pc via ssh, but after the push nothing seems to happen: the hook is not executed on the server side. It does not depend from the code inside the hook: even the unique "touch foobar" command does not work. Where do I have to look? Thanks --

Contact the repository owner and let them know. The error occurs because their HEAD symbolic reference points to a branch that does not exist. They can fix this by running `git symbolic-ref HEAD refs/heads/$branch` to point I think you may be able to do: $ git branch -r $ git reset --hard $branch where $branch is one of the origin/ names printed by branch -r. Because the source repository didn't tell us what default branch name you should use (it has a bad HEAD) I can't suggest ...

The second change is good but why do you remove -v from the synopsis section? Why is it a good idea? Manual pages for many other commands list --verbose in their synopsis section. --

Put the main part of 'log' view generation into git_log_body, similarly how it is done for 'shortlog' and 'history' views (and also for 'tags' and 'heads' views). This is preparation for extracting common code between 'log', 'shortlog' and 'history' actions. Signed-off-by: Jakub Narebski <jnareb@gmail.com> --- This is pure refactoring: output should change. gitweb/gitweb.perl | 81 ++++++++++++++++++++++++++++++--------------------- 1 files changed, 48 insertions(+), 33 ...

Make git_history use git_log_generic, passing git_history_body as one of its paramaters. This required changes to git_log_generic, in particular passing more things as parameters. While refactoring common code of 'log', 'shortlog' and 'history' view, we did unify pagination, using always the form used by 'history' view, namely first * prev * next in place of HEAD * prev * next used by 'log' and 'shortlog' views. The 'history' view now supports commit limiting via 'hpb' ...

Yes, of course, it should be "output should not change" (as opposed to later patches, which unify not only code but some of looks). -- Jakub Narebski Poland --

Hmm, it makes perfect sense to me :-) Does the explanation in 1/2 make more sense? The first sentence describes what Subversion does, the second what Oh yes, SVN gets the merges wrong in an alarming number of cases, it's really shocking. I only stay sane at work because I tell myself that Yes. Toby. --

I have checked both $GIT_DIR/config and ~/.gitconfig and autocrlf has not been set. I have then set autocrlf = false for the Windows repository and still the file didn't show up as modified. On Linux, I've added autocrlf = true (resp. autocrlf = input) for the repository and still the file shows up as modified. Not that I don't like this behavior, but I don't understand it :) Windows Git version is 1.6.5.1, Linux version is 1.6.3.3. -- Best regards, Marc Strapetz ============= syntevo ...

It is usually set by default by the installer. Look at %INSTALLDIR%\etc\gitconfig, it should contain [core] autoCRLF = true among other things. -- \\// Peter - http://www.softwolves.pp.se/ --

Without the "ref_map = next" there is no change: glibc still complains about corruption and abort the execution. With the "ref_map = next" then git simply segfaults. I simply have zero time to investigate the issue myself now unfortunately. Nicolas --

Yep, this fixes it for me on Linux too. Please resend to Junio with my ACK. Nicolas --

In ref_remove_duplicates, when we encounter a duplicate and remove it from the list we need to make sure that the prev pointer stays pointing at the last entry and also skip over adding the just freed entry to the string_list. Previously fetch could crash with: *** glibc detected *** git: corrupted double-linked list: ... Also add a test to try and catch problems with duplicate removal in the future. Acked-by: Nicolas Pitre <nico@fluxnic.net> Signed-off-by: Julian Phillips ...

I noticed you removed the discussion I added about the situation in which maint will *not* be a subset of master i.e. when the user has cherry-picked commits from other branches. This type of cherry-pick is described as a valid operation, though one to generally be avoided earlier in the man page. If we tell users that the occasional cherry-pick to maint is ok, then shouldn't we explain how that affects the release process? Cheers, Raman --

I'm confused. Shouldn't your distro take care of updating the completion for you? And wouldn't update-git-completion be more suited as part of a makefile if it was needed at all? --

Ah ok. I think this proves even more that pregenerating the completion is a bad idea. With dynamic population we don't have these problems and it only takes 250ms more to load on a P3 700Mhz. Maybe we should try and speedup 'git help -a' and 'git merge -s help' instead? Perhaps options for the command/porcelain lists and available strategies formatted for script consumption? I doubt it will be as fast as compiling, but every bit helps apparently. Side Note: Running git merge -s help ...

On my slow laptop (P3 600MHz), system-wide bash completions take too much time to load (> 2s), and a significant fraction of this time is spent loading git-completion.bash: $ time bash -c ". ./git-completion.bash" # hot cache, before this patch real 0m0.509s user 0m0.310s sys 0m0.180s Kirill noticed that most of the time is spent warming up merge_strategy, all_command & porcelain_command caches. Since git is not used in each and every interactive xterm, it seems best to load ...

I was under the impression that setting variables during completion meant they were lost at the end of the completion cycle. So to be safe I put a 'sleep 5' in __git_list_porcelain_commands() and it only stalled me once :-) I see a small problem, but it can be fixed in another patch. git merge -s <TAB><TAB> the first time when you're not in a git directory will make git merge -s <TAB><TAB> after never complete correctly even in a git directory. I guess this become more serious if git ...

If you're running your list without munging Reply-to, congratulations to you. I'll avoid it from now on on this list. However, it's the case that for many, many lists out there, if I did not include myself in a Reply-to, the list would set the Reply-to to the list, and most MUAs would automatically exclude me from the reply. cjs -- Curt Sampson <cjs@starling-software.com> +81 90 7737 2974 Functional programming in all senses of the word: ...

Hi Greg, Almost. I called it "bookmark" so that the abbreviated command does not clash with "merge". And there are possible goto targets you have never been at: - A - B - C \ / D If C is your HEAD, and you "rebase -i -p B", before cherry-picking D, you have to "goto A". So I strongly advise against trying to give all goto targets a name, just the obvious one: onto (you do not need upstream, as all the commits which At the moment, it gives you the status (which ...