tiffany uk: fashionables

Among the loads of established rings, tiffany uk . add on gets as being the admit to take into account a classy women in any move of your community. Having said that, a Tiffany Rings Add on is released together with the fasted speeding as being the quick

Re: Re: Segmentation fault with latest git (070c57df)

On Thu, Jan 31, 2013 at 07:27:04AM +, Jongman Heo wrote: > FYI, gdb backtrace and valgrind output attached below, Thanks. Thanks, that's helpful. > #4 0x0812bda0 in string_list_insert (list=0xbfffe7c0, string=0x821ec3c > "refs/remotes/origin/HEAD") at string-list.c:57 > #5 0x08071838 in a

Contemporary pandora bracelet charms work expressly designed for exquisite kids

To remain allowed to maintain pandora bracelet charms wash, you will want to 100 % sharp the application owning a polishing pads especially established to help you polish magical. internal cleansing ones own gold really just before and even acceptable follo

Re: Segmentation fault with latest git (070c57df)

On Thu, Jan 31, 2013 at 08:02:06AM +0100, Antoine Pelisse wrote: > In "clean.c" we have a "string_list" created on the stack with > "STRING_LIST_INIT_NODUP" (there are probably others, I stopped at the > first occurrence). > But, "STRING_LIST_INIT_NODUP" doesn't init the "list->cmp" pointer > whic

Re: Re: Segmentation fault with latest git (070c57df)

On Thu, Jan 31, 2013 at 7:49 AM, Jeff King wrote: > On Thu, Jan 31, 2013 at 01:35:21AM +, Jongman Heo wrote: > >> Looks like following commit causes a segmentation fault in my machine >> (when running git pull or git fetch); >> >> commit 8dd5afc926acb9829ebf56e9b78826a5242cd638 >> Author: Juni

Re: Segmentation fault with latest git (070c57df)

In "clean.c" we have a "string_list" created on the stack with "STRING_LIST_INIT_NODUP" (there are probably others, I stopped at the first occurrence). But, "STRING_LIST_INIT_NODUP" doesn't init the "list->cmp" pointer which can thus be random. I don't have much time to provide a patch right now (

Re: How to identify the users?

Thanks to all. Tomas: I can't find reflog setting of git-http-backend doc(http://www.kernel.org/pub/software/scm/git/docs/git-http-backend.html), I tried this setting: git config core.logAllRefUpdates true and after some test push, the output is as below: >git log -g master commit d34e61baa28eabf

Re: Segmentation fault with latest git (070c57df)

On Thu, Jan 31, 2013 at 01:35:21AM +, Jongman Heo wrote: > Looks like following commit causes a segmentation fault in my machine > (when running git pull or git fetch); > > commit 8dd5afc926acb9829ebf56e9b78826a5242cd638 > Author: Junio C Hamano > Date: Mon Jan 7 12:24:55 2013 -0800 > >

[PATCH 2/2] branch: let branch filters imply --list

Currently, a branch filter like `--contains`, `--merged`, or `--no-merged` is ignored when we are not in listing mode. For example: git branch --contains=foo bar will create the branch "bar" from the current HEAD, ignoring the `--contains` argument entirely. This is not very helpful. There are

[PATCH 1/2] docs: clarify git-branch --list behavior

It was not clear from the "description" section of git-branch(1) that using a meant that you _had_ to use the --list option. Let's clarify that, and while we're at it, reword some clunky and ambiguous sentences. Signed-off-by: Jeff King --- Documentation/git-branch.txt | 16 +--- 1

[PATCH 0/2] improve "git branch --contains= "

On Wed, Jan 30, 2013 at 07:57:03PM +0100, Peter Wu wrote: > Hi, > > I was trying to check whether a certain branch contained a commit and ran: > > git branch --contains ddc150f7a33ae0c9cb16eaac3641abc00f56316f master > > This resulted in: > > fatal: A branch named 'master' already exi

Re: How to identify the users?

(resending previous response. Forgot to turn off HTML, and apprently gmail doesn't wrap lines automatically anymore?) On 31 January 2013 16:52, Scott Yan wrote: > > The user info of git client (user name and email) is set by the users > themselves, so , how to avoid userA pretend to be userB? > >

Re: How to identify the users?

On 01/31/2013 11:38 AM, Tomas Carnecky wrote: > On Thu, 31 Jan 2013 13:52:32 +0800, Scott Yan wrote: >> Hello everyone: >> >> The user info of git client (user name and email) is set by the users >> themselves, so , how to avoid userA pretend to be userB? >> >> Git server could authentication the

Re: How to identify the users?

On Thu, 31 Jan 2013 13:52:32 +0800, Scott Yan wrote: > Hello everyone: > > The user info of git client (user name and email) is set by the users > themselves, so , how to avoid userA pretend to be userB? > > Git server could authentication the user, but it do nothing about the > user info of com

Re: How to identify the users?

Thanks, Andrew. you said: --have the server reject commits that have the 'committer' set to someone other then the authenticated user but I don't know how to do that? Our central repository is hosted by apache, and there are some username and passwords saved by apache to authentication valid use

Re: [PATCH 1/3] gpg: Close stderr once finished with it in verify_signed_buffer()

On Wed, Jan 30, 2013 at 06:01:04PM -0800, Stephen Boyd wrote: > Failing to close the stderr pipe in verify_signed_buffer() causes > git to run out of file descriptors if there are many calls to > verify_signed_buffer(). An easy way to trigger this is to run > > git log --show-signature --merges

[PATCH 1/1] Introduce new build variables INSTALL_MODE_EXECUTABLE and INSTALL_MODE_DATA.

Installation would fail if the target location had anything other than 755/644 file permissions. Therefore replace the hard-coded modes for each $(INSTALL) with variables. Default values are 755/644 but can be over-ridden on the make command line e.g. "make INSTALL_MODE_EXECUTABLE=755 INSTALL_MODE

[PATCH 0/1] Introduce new build variables INSTALL_MODE_EXECUTABLE and INSTALL_MODE_DATA.

During a build/install cycle of the current HEAD whilst attempting to identify the cause of a bug in git version 1.8.0.3 whilst doing: GIT_CURL_VERBOSE=1 git clone -v https://git01.codeplex.com/typescript * GnuTLS recv error (-9): A TLS packet with unexpected length was received. * Closing conne

[PATCH 2/3] run-command: Be more informative about what failed

While debugging an error with verify_signed_buffer() the error messages from run-command weren't very useful: error: cannot create pipe for gpg: Too many open files error: could not run gpg. because they didn't indicate *which* pipe couldn't be created. Print which pipe failed to be created in

[PATCH 3/3] gpg: Allow translation of more error messages

Mark these strings for translation so that error messages are printed in the user's language of choice. Signed-off-by: Stephen Boyd --- gpg-interface.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/gpg-interface.c b/gpg-interface.c index 2c0bed3..474c037 100644 --- a/

[PATCH 0/3] GPG running out of pipes fixes

While running --show-signatures on the linux kernel I noticed that after a while git failed with an error message indicating it had run out of file descriptors. The first patch fixes this problem, and the next two are randmom bits since I was in the area. Stephen Boyd (3): gpg: Close stderr onc

[PATCH 1/3] gpg: Close stderr once finished with it in verify_signed_buffer()

Failing to close the stderr pipe in verify_signed_buffer() causes git to run out of file descriptors if there are many calls to verify_signed_buffer(). An easy way to trigger this is to run git log --show-signature --merges | grep "key" on the linux kernel git repo. Eventually it will fail with

Segmentation fault with latest git (070c57df)

Hi all, Looks like following commit causes a segmentation fault in my machine (when running git pull or git fetch); commit 8dd5afc926acb9829ebf56e9b78826a5242cd638 Author: Junio C Hamano Date: Mon Jan 7 12:24:55 2013 -0800 string-list: allow case-insensitive string list In my case, li

Re: [PATCH] The images from picon and gravatar are always used over http://, and browsers give mixed contents warning when gitweb is served over https://.

Junio C Hamano wrote: > Jonathan Nieder writes: >> Odd. "https://www.gravatar.com/"; also seems to work. I've put in a >> technical support query to find out what the Gravatar admins prefer. > > Thanks; will hold onto Andrej's patch until we hear what the story > is. Good news: a kind person f

Re: "sha1 information is lacking or useless" when rebasing with a submodule pointer conflict

Heiko Voigt writes: > Maybe Martin or Junio immediately see whats going wrong here? I would > need to further dig into the git-am code to find out how to fix it. "am -3" has never worked on a patch that describes changes to any non-blobs; the underlyihng "apply --fake-ancestor" is not prepared t

Re: Anybody know a website with up-to-date git documentation?

On Wed, Jan 30, 2013 at 09:18:24AM -0800, Junio C Hamano wrote: > Max Horn writes: > > [administrivia: please wrap lines to a reasonable width] Curiously, gmail's web interface appears to have started doing this only recently. I've noticed it when trying to respond to others too. > > On 30.01.

Re: Re: "sha1 information is lacking or useless" when rebasing with a submodule pointer conflict

Hi, On Wed, Jan 30, 2013 at 10:56:15PM +0100, Heiko Voigt wrote: > On Wed, Jan 30, 2013 at 12:43:31PM -0600, Michael Sims wrote: > > I'm seeing what might be a bug that was introduced in git 1.7.12 (also > > observed in 1.8.1.2). If not a bug, it's a changed behavior from > > previous versions th

Re: [BUG] incorrect search result returned when using git log with a future date parameter

Jonathan Nieder writes: >> When it is fed 2013-02-12, it is ambiguous and "approxidate" can and >> should use whatever heuristics (including rejection of future) to >> guess what the user wanted, but 2013-02-13 cannot be interpreted in >> any other way, so we should parse it as such. > > FWIW, if

Re: [BUG] incorrect search result returned when using git log with a future date parameter

Junio C Hamano wrote: > When it is fed 2013-02-12, it is ambiguous and "approxidate" can and > should use whatever heuristics (including rejection of future) to > guess what the user wanted, but 2013-02-13 cannot be interpreted in > any other way, so we should parse it as such. FWIW, if you said

Re: "sha1 information is lacking or useless" when rebasing with a submodule pointer conflict

Hi, On Wed, Jan 30, 2013 at 12:43:31PM -0600, Michael Sims wrote: > I'm seeing what might be a bug that was introduced in git 1.7.12 (also > observed in 1.8.1.2). If not a bug, it's a changed behavior from > previous versions that I don't understand. > > Here's the scenario: > * I have a remote

[PATCH v3] CodingGuidelines: add Python coding guidelines

These are kept short by simply deferring to PEP-8. Most of the Python code in Git is already very close to this style (some things in contrib/ are not). Rationale for version suggestions: - Amongst the noise in [1], there isn't any disagreement about using 2.6 as a base (see also [2]), altho

Re: [PATCH 1/3] fixup! mergetool--lib: add functions for finding available tools

On Wed, Jan 30, 2013 at 12:23:34PM -0800, Junio C Hamano wrote: > > diff --git a/git-mergetool--lib.sh b/git-mergetool--lib.sh > > index 25631cd..b6ed2fa 100644 > > --- a/git-mergetool--lib.sh > > +++ b/git-mergetool--lib.sh > > @@ -34,9 +34,9 @@ show_tool_names () { > >

Re: [RFC/PATCH v2] CodingGuidelines: add Python coding guidelines

On Wed, Jan 30, 2013 at 11:05:10AM +0100, Michael Haggerty wrote: > Nit: s/it is supported/it has been supported/ Thanks, I'll fix in the re-roll. > I think this would be a good Python policy. > > I would hate to junk up all Python code with things like > > ' '.encode('ascii') > > though,

Re: git-remote-helpers.txt: should it be gitremote-helpers.txt?

John Keeping writes: > Max Horn's email today prompted me to try reading the git-remote-helpers > man page, so I tried: > > $ git help remote-helpers > No manual entry for gitremote-helpers > > But "man git-remote-helpers" does work. > > It turns out that "builtin/help.c" maps its argumen

Re: [PATCH 1/3] fixup! mergetool--lib: add functions for finding available tools

John Keeping writes: > Signed-off-by: John Keeping > --- > git-mergetool--lib.sh | 5 +++-- > 1 file changed, 3 insertions(+), 2 deletions(-) Thanks. > diff --git a/git-mergetool--lib.sh b/git-mergetool--lib.sh > index 25631cd..b6ed2fa 100644 > --- a/git-mergetool--lib.sh > +++ b/git-mergetoo

git-remote-helpers.txt: should it be gitremote-helpers.txt?

Max Horn's email today prompted me to try reading the git-remote-helpers man page, so I tried: $ git help remote-helpers No manual entry for gitremote-helpers But "man git-remote-helpers" does work. It turns out that "builtin/help.c" maps its argument to a page by prepending "git-" if gi

Re: [PATCH] git_remote_helpers: remove GIT-PYTHON-VERSION upon "clean"

On Wed, Jan 30, 2013 at 11:30:10AM -0800, Junio C Hamano wrote: > fadf8c7 (git_remote_helpers: force rebuild if python version changes, > 2013-01-20) > started using a marker file to keep track of the version of Python interpreter > used for the last build, but forgot to remove it when asked to "m

[PATCH 2/3] fixup! doc: generate a list of valid merge tools

Signed-off-by: John Keeping --- git-mergetool--lib.sh | 40 ++-- 1 file changed, 22 insertions(+), 18 deletions(-) diff --git a/git-mergetool--lib.sh b/git-mergetool--lib.sh index b6ed2fa..b44a2c8 100644 --- a/git-mergetool--lib.sh +++ b/git-mergetool--lib.sh

[PATCH 0/3] mergetool: add user configured commands to '--tool-help'

The first couple of these are fixups to da/mergetool-docs. I think the first one's obvious, but the second one should possible be changed into an incremental patch on top. I did it this way for now since that patch is basically my comments in [1] in patch form. The final patch adds tools from gi

Re: [feature request] git add completion should exclude staged content

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Il 30/01/2013 19:55, Marc Khouzam ha scritto: > [...] The new logic in git-completion.bash tells bash that 'filenames' completion is ongoing so bash will add a '/' after directories. Sadly, tcsh won't do that, so it would be simpler if >

Re: [BUG] incorrect search result returned when using git log with a future date parameter

Caspar Zhang writes: > A date parsing function should parse _all dates with > correctly format_, despite if it's an old date, or the date in the > future. When it is fed 2013-02-12, it is ambiguous and "approxidate" can and should use whatever heuristics (including rejection of future) to g

[PATCH 3/3] mergetool--lib: list user configured tools in '--tool-help'

Signed-off-by: John Keeping --- git-mergetool--lib.sh | 41 - 1 file changed, 40 insertions(+), 1 deletion(-) diff --git a/git-mergetool--lib.sh b/git-mergetool--lib.sh index b44a2c8..e338be5 100644 --- a/git-mergetool--lib.sh +++ b/git-mergetool--lib.sh @

[PATCH 1/3] fixup! mergetool--lib: add functions for finding available tools

Signed-off-by: John Keeping --- git-mergetool--lib.sh | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/git-mergetool--lib.sh b/git-mergetool--lib.sh index 25631cd..b6ed2fa 100644 --- a/git-mergetool--lib.sh +++ b/git-mergetool--lib.sh @@ -34,9 +34,9 @@ show_tool_names () {

[PATCH] git_remote_helpers: remove GIT-PYTHON-VERSION upon "clean"

fadf8c7 (git_remote_helpers: force rebuild if python version changes, 2013-01-20) started using a marker file to keep track of the version of Python interpreter used for the last build, but forgot to remove it when asked to "make clean". Signed-off-by: Junio C Hamano --- git_remote_helpers/Make

Re: What's cooking in git.git (Jan 2013, #11; Wed, 30)

On Wed, Jan 30, 2013 at 11:17:15AM -0800, Junio C Hamano wrote: > Let's do something like this on top of the topic. This looks good to me. > INSTALL | 5 +++-- > 1 file changed, 3 insertions(+), 2 deletions(-) > > diff --git a/INSTALL b/INSTALL > index b96e16d..2dc3b61 100644 > --- a/INSTALL >

Re: What's cooking in git.git (Jan 2013, #11; Wed, 30)

John Keeping writes: > On Wed, Jan 30, 2013 at 10:33:10AM -0800, Junio C Hamano wrote: >> [Discarded] >> >> * jk/update-install-for-p4 (2013-01-20) 1 commit >> . INSTALL: git-p4 doesn't support Python 3 >> >> Made obsolete by bc/git-p4-for-python-2.4 topic. > > I disagree with this - that bra

Re: What's cooking in git.git (Jan 2013, #11; Wed, 30)

On Wed, Jan 30, 2013 at 10:33:10AM -0800, Junio C Hamano wrote: > [Discarded] > > * jk/update-install-for-p4 (2013-01-20) 1 commit > . INSTALL: git-p4 doesn't support Python 3 > > Made obsolete by bc/git-p4-for-python-2.4 topic. I disagree with this - that branch doesn't change INSTALL to list

[BUG] `git branch --contains ID name` creates branch "name"

Hi, I was trying to check whether a certain branch contained a commit and ran: git branch --contains ddc150f7a33ae0c9cb16eaac3641abc00f56316f master This resulted in: fatal: A branch named 'master' already exists. When "name" does not exist, this command creates a branch. I expect this

RE: [feature request] git add completion should exclude staged content

> -Original Message- > From: git-ow...@vger.kernel.org > [mailto:git-ow...@vger.kernel.org] On Behalf Of Manlio Perillo > Sent: Wednesday, January 30, 2013 1:24 PM > To: Marc Khouzam > Cc: 'Junio C Hamano'; 'Michael J Gruber'; 'wookietreiber'; > 'git@vger.kernel.org' > Subject: Re: [feat

[PATCH v3 6/8] upload-pack: optionally allow fetching from the tips of hidden refs

With uploadpack.allowtipsha1inwant configuration option set, future versions of "git fetch" that allow an exact object name (likely to have been obtained out of band) on the LHS of the fetch refspec can make a request with a "want" line that names an object that may not have been advertised due to

[PATCH v3 8/8] WIP: receive.allowupdatestohidden

This does not work yet, and for a good reason. As the side that pushes to a hidden ref never sees that the ref already exists, a request to update such a ref will come in the form of "please _create_ this ref and point it at this object", which will not pass the compare-and-swap based anti-race sa

[PATCH v3 5/8] fetch: use struct ref to represent refs to be fetched

Even though "git fetch" has full infrastructure to parse refspecs to be fetched and match them against the list of refs to come up with the final list of refs to be fetched, the list of refs that are requested to be fetched were internally converted to a plain list of strings at the transport layer

[PATCH v3 7/8] fetch: fetch objects by their exact SHA-1 object names

Teach "git fetch" to accept an exact SHA-1 object name the user may obtain out of band on the LHS of a pathspec, and send it on a "want" message when the server side advertises the allow-tip-sha1-in-want capability. Signed-off-by: Junio C Hamano --- fetch-pack.c | 22 +++

[PATCH v3 4/8] parse_fetch_refspec(): clarify the codeflow a bit

Most parts of the cascaded if/else if/... checked an allowable condition but some checked forbidden conditions. This makes adding new allowable conditions unnecessarily inconvenient. Signed-off-by: Junio C Hamano --- remote.c | 29 - 1 file changed, 12 insertions(+),

[PATCH v3 1/8] upload-pack: share more code

We mark the objects pointed at our refs with "OUR_REF" flag in two functions (mark_our_ref() and send_ref()), but we can just use the former as a helper for the latter. Update the way mark_our_ref() prepares in-core object to use lookup_unknown_object() to delay reading the actual object data, jus

[PATCH v3 3/8] upload/receive-pack: allow hiding ref hierarchies

Teach upload-pack and receive-pack to omit some refs from their initial advertisements by paying attention to the transfer.hiderefs multi-valued configuration variable. Any ref that is under the hierarchies listed on the value of this variable is excluded from responses to requests made by "ls-rem

[PATCH v3 2/8] upload-pack: simplify request validation

Long time ago, we used to punt on a large (read: asking for more than 256 refs) fetch request and instead sent a full pack, because we couldn't fit many refs on the command line of rev-list we run internally to enumerate the objects to be sent. To fix this, 565ebbf (upload-pack: tighten request va

[PATCH v3 0/8] Hiding refs

The third round. - Multi-valued variable transfer.hiderefs lists prefixes of ref hierarchies to be hidden from the requests coming over the network. - A configuration optionally allows uploadpack to accept fetch requests for an object at the tip of a hidden ref. Elsewhere, we discusse

"sha1 information is lacking or useless" when rebasing with a submodule pointer conflict

I'm seeing what might be a bug that was introduced in git 1.7.12 (also observed in 1.8.1.2). If not a bug, it's a changed behavior from previous versions that I don't understand. Here's the scenario: * I have a remote repo containing a pointer to a submodule. * Developer A and Developer B clone t

What's cooking in git.git (Jan 2013, #11; Wed, 30)

Here are the topics that have been cooking. Commits prefixed with '-' are only in 'pu' (proposed updates) while commits prefixed with '+' are in 'next'. As usual, this cycle is expected to last for 8 to 10 weeks, with a preview -rc0 sometime in the middle of next month. You can find the changes

Re: [feature request] git add completion should exclude staged content

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Il 30/01/2013 15:06, Marc Khouzam ha scritto: > [...] >> I will try to update the patch, with your latest suggestions (avoid >> tricky POSIX shell syntax, and CDPATH issue - if I remember >> correctly), >> and with an update for the t/t9902-completion

Re: [PATCH v3 00/11] unify appending of sob

Junio C Hamano writes: > Jonathan Nieder writes: > >> Brandon Casey wrote: >> >>> Round 3. >> >> Thanks for a pleasant read. My only remaining observations are >> cosmetic, except for a portability question in Duy's test script, a >> small behavior change when the commit message ends with an >>

[PATCH 7/7] perl/Git.pm: rename 'ActiveState' to 'Windows'

From: "Gustavo L. de M. Chaves" Windows specific code was mentioning ActiveState Perl specifically, but that code works with Strawberry Perl too. Hence, we rename every instance of 'ActivePerl' to 'Windows' to convey the more general idea. Signed-off-by: Gustavo L. de M. Chaves --- perl/Git.p

[PATCH 1/7] perl/Git.pm: test portably if a path is absolute

From: "Gustavo L. de M. Chaves" The code was testing if a path was absolute by checking if its first character was a '/'. This does not work on Windows. The portable way to do it is to use File::Spec::file_name_is_absolute. Signed-off-by: Gustavo L. de M. Chaves --- perl/Git.pm | 2 +- 1 file

[PATCH 3/7] perl/Git.pm: fix _cmd_close on Windows

From: "Gustavo L. de M. Chaves" The Git::activestate_pipe::CLOSE routine wasn't explicitly returning anything. This means that on Windows the routine _cmd_close wasn't checking correctly the external command's exit code. Now we store the command's exit code on the object created by Git::activest

[PATCH 4/7] perl/Git.pm: escape external command's arguments on Windows

From: "Gustavo L. de M. Chaves" On Windows, the external git commands are invoked using backticks by Git::activestate_pipe::TIEHANDLE, but there was no attempt to properly quote their arguments. This caused problems with all but the simplest command invokations. The arguments are now surrounded

[PATCH 6/7] perl/Git.pm: make command pipe work in slurp-mode on Windows

From: "Gustavo L. de M. Chaves" Git::activestate_pipe::READLINE implementation wasn't working when the pipe was read in slurp-mode (i.e., with $/ undefined). Now, when in slurp-mode it correctly returns the remaining lines joined together. Signed-off-by: Gustavo L. de M. Chaves --- perl/Git.p

[PATCH 5/7] perl/Git.pm: simplify Git::activestate_pipe

From: "Gustavo L. de M. Chaves" Git::activestate_pipe::TIEHANDLE creates an object to keep the external command's output as an array of lines. The object also kept an index into the array to know up to which line had already been read via Git::activestate_pipe::READLINE. We don't really need tha

[PATCH 2/7] perl/Git.pm: set up command environment on Windows

From: "Gustavo L. de M. Chaves" Routine _cmd_exec invokes _setup_git_cmd_env inside the child process before invoking an external git command to set up the environment variables GIT_DIR and GIT_WORK_TREE and, also, to chdir to the repository. But _cmd_exec is only used on Unix. On Windows, it's n

[PATCH 0/7] perl/Git.pm: a bunch of fixes for Windows

From: "Gustavo L. de M. Chaves" I'm working on Git::Hooks, a Perl module to facilitate the implementation of git hooks. (http://search.cpan.org/dist/Git-Hooks/) Git::Hooks uses the Git module implemented in perl/Git.pm and distributed with git. While working on porting Git::Hooks to Windows I s

Re: Anybody know a website with up-to-date git documentation?

Max Horn writes: [administrivia: please wrap lines to a reasonable width] > On 30.01.2013, at 16:59, Sitaram Chamarty wrote: > >> I'm curious... what's wrong with 'git checkout html' from the git repo >> and just browsing them using a web browser? > > Hm, do you mean "make html", perhaps? At lea

Re: Anybody know a website with up-to-date git documentation?

On 30.01.2013, at 16:59, Sitaram Chamarty wrote: > I'm curious... what's wrong with 'git checkout html' from the git repo > and just browsing them using a web browser? Hm, do you mean "make html", perhaps? At least I couldn't figure out what "git checkout html" should do, but out of curiosity g

Re: What's cooking in git.git (Jan 2013, #10; Sun, 27)

Pete Wyckoff writes: > gits...@pobox.com wrote on Sun, 27 Jan 2013 22:45 -0800: >> * pw/git-p4-on-cygwin (2013-01-26) 21 commits >> ... >> Improve "git p4" on Cygwin. The cover letter said it is not yet >> ready for full Windows support so I won't move this to 'next' until >> told by the aut

Re: Anybody know a website with up-to-date git documentation?

Max Horn writes: > does anybody know a website where one can view that latest git > documentation? Here, "latest" means "latest release" (though being > also able to access it for "next" would of course be a nice bonus, > likewise for older versions). Preformatted ones for the tip of 'master' ar

Re: Files excluded but not ignored

Jason Wenger writes: > I prefer to not add core.* files to my ignore listings because I find it > helpful > to see them in git status -- It helps me notice and clean them up > periodically. > Not having them ignored is also good ,because it allows git clean to care of > core.* files. > > T

Re: Anybody know a website with up-to-date git documentation?

On Wed, Jan 30, 2013 at 7:28 PM, Max Horn wrote: > > On 30.01.2013, at 12:54, John Keeping wrote: > >> On Wed, Jan 30, 2013 at 12:46:47PM +0100, Max Horn wrote: >>> does anybody know a website where one can view that latest git >>> documentation? Here, "latest" means "latest release" (though being

Re: [PATCH] git-send-email: add ~/.authinfo parsing

Jeff King writes: > But it would probably make sense for send-email to support the existing > git-credential subsystem, so that it can take advantage of secure > system-specific storage. And that is where we should be pointing new > users. I think contrib/mw-to-git even has credential support wri

Re: [PATCH 4/6] introduce a commit metapack

Jeff King writes: >>From this: > >> Then it will be very natural for the extension data that store the >> commit metainfo to name objects in the pack the .idx file describes >> by the offset in the SHA-1 table. > > I guess your argument is that putting it all in the same file makes it > more natu

Files excluded but not ignored

I prefer to not add core.* files to my ignore listings because I find it helpful to see them in git status -- It helps me notice and clean them up periodically. Not having them ignored is also good ,because it allows git clean to care of core.* files. The problem is that git add -A, git sta

Re: [PATCH] git-send-email: add ~/.authinfo parsing

On Tue, 29 Jan 2013 11:53:19 -0800 Junio C Hamano wrote: JCH> Makes one wonder why .authinfo and not .netrc; JCH> http://www.gnu.org/software/emacs/manual/html_node/auth/Help-for-users.html JCH> phrases it amusingly: JCH> “Netrc” files are usually called .authinfo or .netr JCH>

Re: Bug, feature, or pilot error: format-patch

Ping It would be useful to get some comment on this On 01/28/2013 12:03 PM, Gene Czarcinski wrote: I am not on the mailing list so please CC me. I am running git 1.8.1 on Fedora 18. I aam having what appears to be a problem. Here is the sequence which generally describes what I did and what

ChiarasciuttoVERIFICAINFORMAZIONIalice

return-path: l.huml...@ckibis.cz ChiarasciuttoVERIFICAINFORMAZIONIalice Bella, intelligente, socievole donna per l'uomi in cerca di un incontro ih Italia ad avvuare una relazione seria. ª Il mio indirizzo e-mail bella.do...@yahoo.com Scrivi a me s io ti invierà la mia bella foto s lettere. ÂIryn

Re: [PATCH 4/6] introduce a commit metapack

On Wed, Jan 30, 2013 at 8:56 PM, Duy Nguyen wrote: > However, performance seems to suffer too. Maybe I do more lookups than > necessary, I don't know. Yes, I should have stored the position in the sha-1 <-> offset map instead of the position of the object in .pack file. Even so, performance does

LcandoloVERIFICAINFORAZIONIyahoo

return-path: market...@displaycreative.it LcandoloVERIFICAINFORAZIONIyahoo Bella, intelligente, socievole donna per o'uomo in cerca di un inconteo in talia ae avviare una relazione seria. ±Â Il mio indirizzo e-mail bella.do...@yahoo.com Scrivi q me e ik ti invierà la mia beloa foto e lettere. ¦¯I

RE: [feature request] git add completion should exclude staged content

> -Original Message- > From: git-ow...@vger.kernel.org > [mailto:git-ow...@vger.kernel.org] On Behalf Of Manlio Perillo > Sent: Monday, January 28, 2013 3:16 PM > To: Junio C Hamano > Cc: Michael J Gruber; wookietreiber; git@vger.kernel.org > Subject: Re: [feature request] git add complet

Re: Anybody know a website with up-to-date git documentation?

On 30.01.2013, at 12:54, John Keeping wrote: > On Wed, Jan 30, 2013 at 12:46:47PM +0100, Max Horn wrote: >> does anybody know a website where one can view that latest git >> documentation? Here, "latest" means "latest release" (though being >> also able to access it for "next" would of course be

Re: [PATCH 4/6] introduce a commit metapack

On Tue, Jan 29, 2013 at 04:16:11AM -0500, Jeff King wrote: > When we are doing a commit traversal that does not need to > look at the commit messages themselves (e.g., rev-list, > merge-base, etc), we spend a lot of time accessing, > decompressing, and parsing the commit objects just to find > the

Re: Anybody know a website with up-to-date git documentation?

Hi Max, it seems that this is some sort of caching problem on git-scm.com. I saw you've already opened an issue at https://github.com/github/gitscm-next/issues/232. So there's probably not much you can do right now. And I don't know any better source for documentation right now, apart from the l

Re: Anybody know a website with up-to-date git documentation?

Hi Sebastian, On 30.01.2013, at 12:56, Sebastian Staudt wrote: > Hello Max, > > git-scm.com is the best source and it's not outdated. Then it seems you are using the word "outdated" in a different way than me which I don't understand :-). Sure, it strives to be up-to-date, but fact is that it

Re: What's cooking in git.git (Jan 2013, #10; Sun, 27)

gits...@pobox.com wrote on Sun, 27 Jan 2013 22:45 -0800: > * pw/git-p4-on-cygwin (2013-01-26) 21 commits > - git p4: introduce gitConfigBool > - git p4: avoid shell when calling git config > - git p4: avoid shell when invoking git config --get-all > - git p4: avoid shell when invoking git rev-l

Re: Anybody know a website with up-to-date git documentation?

Hello Max, git-scm.com is the best source and it's not outdated. It gets an update after every single release of Git. See e.g. http://git-scm.com/docs/git-config which was updated in the current stable version. It seems that git-remote-helper's documentation was just not updated since version 1.7.

Re: Anybody know a website with up-to-date git documentation?

On Wed, Jan 30, 2013 at 12:46:47PM +0100, Max Horn wrote: > does anybody know a website where one can view that latest git > documentation? Here, "latest" means "latest release" (though being > also able to access it for "next" would of course be a nice bonus, > likewise for older versions). While

Anybody know a website with up-to-date git documentation?

Hi, does anybody know a website where one can view that latest git documentation? Here, "latest" means "latest release" (though being also able to access it for "next" would of course be a nice bonus, likewise for older versions). While I do have those docs on my local machine, I would like to

[BUG] incorrect search result returned when using git log with a future date parameter

Hi there, when I'm using the commit limit option `--before/--until` when doing `git log` search, I meet a bug when the upper-bound date is 10days later in the future. Here is an example: $ date +%F 2013-01-30 $ git log --oneline --since=2013-01-01 --until=2013-02-01 $ git log --oneline --sin

[BUG] incorrect search result returned when using git log with a future date parameter

Hi there, when I'm using the commit limit option `--before/--until` when doing `git log` search, I meet a bug when the upper-bound date is 10days later in the future. Here is an example: $ date +%F 2013-01-30 $ git log --oneline --since=2013-01-01 --until=2013-02-01 $ git log --oneline --sin

Re: [RFC/PATCH v2] CodingGuidelines: add Python coding guidelines

On 01/29/2013 08:08 PM, John Keeping wrote: > These are kept short by simply deferring to PEP-8. Most of the Python > code in Git is already very close to this style (some things in contrib/ > are not). > > Rationale for version suggestions: > > - Amongst the noise in [1], there isn't any disag

Re: [PATCH/RFC 0/6] commit caching

On Wed, Jan 30, 2013 at 2:18 PM, Jeff King wrote: > On Wed, Jan 30, 2013 at 10:31:43AM +0700, Nguyen Thai Ngoc Duy wrote: > >> On Tue, Jan 29, 2013 at 4:14 PM, Jeff King wrote: >> > The timings from this one are roughly similar to what I posted earlier. >> > Unlike the earlier version, this one k

Re: Updating shared ref from remote helper, or fetch hook

Jed Brown writes: > I'm working on an hg remote helper that uses git notes for the sha1 > revision, so that git users can more easily refer to specific commits > when communicating with hg users. Since there may be multiple > concurrent fast-import streams, I write the notes to a private ref > (