Re: [PATCH 10/17] get_revision_internal(): make check less mysterious

On 05/21/2013 07:38 PM, Junio C Hamano wrote: > Michael Haggerty writes: > >> The condition under which gc_boundary() is called was previously >> >> if (alloc <= nr) >> >> . But by construction, nr can never exceed alloc, so the check looks >> unnecessarily mysterious. In fact, the purpose

Re: [PATCH 08/17] revision: split some overly-long lines

On 05/21/2013 07:34 PM, Junio C Hamano wrote: > Michael Haggerty writes: > >> Signed-off-by: Michael Haggerty >> --- >> revision.c | 20 ++-- >> revision.h | 32 +--- >> 2 files changed, 35 insertions(+), 17 deletions(-) > > Looks obviously good for

Re: Your windows version has virus ?

On Thu, May 23, 2013 at 12:40 AM, Peter Krefting wrote: > Klavs Rommedahl: > >> I just downloaded your Windows version, and got a virus attack, and a >> trojan. >> So sad to try "a new world" on the net, and then getting attacked. What >> to do ? Any clues ? > > > Which URL did you download from

Re: Your windows version has virus ?

Klavs Rommedahl: I just downloaded your Windows version, and got a virus attack, and a trojan. So sad to try "a new world" on the net, and then getting attacked. What to do ? Any clues ? Which URL did you download from, exactly?

Re: [PATCH v6] Add new git-related helper to contrib

On Wed, May 22, 2013 at 11:07 PM, Felipe Contreras wrote: > On Wed, May 22, 2013 at 7:08 PM, Junio C Hamano wrote: >> Felipe Contreras writes: >> IIRC, git-gui runs two blames, one without any -C and one with (I do not offhand recall how many -C it uses) to show both. >>> >>> 'git blam

Your windows version has virus ?

Hi. I just downloaded your Windows version, and got a virus attack, and a trojan. So sad to try "a new world" on the net, and then getting attacked. What to do ? Any clues ? Sincerely A very very very disapointed - Klavs. Ps : both McAfee, Symantec and Kaspersky find these attacks. Send

Re: [PATCH v6] Add new git-related helper to contrib

On Wed, May 22, 2013 at 7:08 PM, Junio C Hamano wrote: > Felipe Contreras writes: > >>> IIRC, git-gui runs two blames, one without any -C and one with (I do >>> not offhand recall how many -C it uses) to show both. >> >> 'git blame' is a very expensive operation, perhaps we should add >> another

Re: [PATCH v6] Add new git-related helper to contrib

On Wed, May 22, 2013 at 10:23 PM, Felipe Contreras wrote: > This doesn't make any sense: Ah, never mind, it's COPYING the one being modified, not EXTRACTING. -- Felipe Contreras -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.o

Re: [PATCH v6] Add new git-related helper to contrib

This doesn't make any sense: --- cd /tmp rm -rf blame git init blame cd blame cp ~/dev/git/COPYING COPYING git add COPYING git commit -m initial sed -ne 120,140p COPYING >EXTRACTING git add EXTRACTING git commit -m second git log --oneline git blame -C EXTRACTING echo >>COPYING git commit --a

Re: [PATCH] Added guilt.reusebranch configuration option.

On Wed, May 22, 2013 at 11:55:00AM -0700, Junio C Hamano wrote: > But in a triangular workflow, the way to make the result reach the > "upstream" is *not* by pushing there yourself. For developers at > the leaf level, it is to push to their own repository (often on > GitHub), which is different fr

Re: [PATCH v6] Add new git-related helper to contrib

Felipe Contreras writes: >> IIRC, git-gui runs two blames, one without any -C and one with (I do >> not offhand recall how many -C it uses) to show both. > > 'git blame' is a very expensive operation, perhaps we should add > another option so users don't need to run two blames to find this. Yes,

Re: [PATCH v6] Add new git-related helper to contrib

On Wed, May 22, 2013 at 6:42 PM, Junio C Hamano wrote: > Junio C Hamano writes: > The person who moved the code will be on the list regardless, >>> >>> That is exactly the point I have been trying to raise. Does the >>> person appear in the list when you run blame with -CCC? You ask for >>

Re: [PATCH v6] Add new git-related helper to contrib

Junio C Hamano writes: >>> The person who moved the code will be on the list regardless, >> >> That is exactly the point I have been trying to raise. Does the >> person appear in the list when you run blame with -CCC? You ask for > > s/person/commit/; > >> the body of the function, and the -C m

Re: [PATCH v6] Add new git-related helper to contrib

On Wed, May 22, 2013 at 5:53 PM, Junio C Hamano wrote: > Felipe Contreras writes: > >> On Wed, May 22, 2013 at 5:38 PM, Junio C Hamano wrote: >> ... >>> As I already said in the above, the answer is no, when you are >>> trying to find who moved the code from the original place. >> >> But I'm not

Re: [PATCH v6] Add new git-related helper to contrib

Junio C Hamano writes: > Felipe Contreras writes: > >> On Wed, May 22, 2013 at 5:38 PM, Junio C Hamano wrote: >> ... >>> As I already said in the above, the answer is no, when you are >>> trying to find who moved the code from the original place. >> >> But I'm not trying to find who moved the c

Re: [PATCH v6] Add new git-related helper to contrib

Felipe Contreras writes: > On Wed, May 22, 2013 at 5:38 PM, Junio C Hamano wrote: > ... >> As I already said in the above, the answer is no, when you are >> trying to find who moved the code from the original place. > > But I'm not trying to find who moved the code, I'm trying to find > related

Re: [PATCH v6] Add new git-related helper to contrib

On Wed, May 22, 2013 at 5:38 PM, Junio C Hamano wrote: > Felipe Contreras writes: > >>> Depending on the nature of the change in question, it may match well >>> or worse to what you are trying to find out. When you are trying to >>> say "What were you smoking when you implemented this broken log

Re: [PATCH v6] Add new git-related helper to contrib

Felipe Contreras writes: >> Depending on the nature of the change in question, it may match well >> or worse to what you are trying to find out. When you are trying to >> say "What were you smoking when you implemented this broken logic?", >> using -C may be good, but when your question is "Even

[PATCH] bisect: Fix log output for multi-parent skip ranges

On Mon, Apr 22, 2013 at 23:02:29 +0200, Torstein Hegge wrote: > There has to be a better way to get the range of possible first bad > commits, similar to the output of 'git log --bisect --format="%H"'. I just realized that this felt clunky because I didn't understand what '--not' does in git rev-l

Re: [PATCH v6] Add new git-related helper to contrib

On Wed, May 22, 2013 at 2:23 PM, Junio C Hamano wrote: > Felipe Contreras writes: > >> diff --git a/contrib/related/git-related b/contrib/related/git-related >> new file mode 100755 >> index 000..b96dcdd >> --- /dev/null >> +++ b/contrib/related/git-related >> @@ -0,0 +1,124 @@ >> +#!/usr/bin

Re: [RFC/PATCH 2/2] doc: command line interface (cli) dot-repository dwimmery

On Wed, May 22, 2013 at 5:09 PM, Philip Oakley wrote: > From: "Felipe Contreras" > Sent: Wednesday, May 22, 2013 12:03 AM >>> The value of the trick was acknowledged as now being in use >>> http://article.gmane.org/gmane.comp.version-control.git/223572 >> >> >> How is that more useful than 'git

Re: [RFC/PATCH 2/2] doc: command line interface (cli) dot-repository dwimmery

On Wed, May 22, 2013 at 11:50 AM, Junio C Hamano wrote: > Felipe Contreras writes: > >> She told Git that her local svn-branch was the basis for svn-next. She >> DIT NOT TELL Git to fetch from there. She told Git to fetch from any >> location Git thought best to fetch from, either a) or b) would

Re: [RFC/PATCH 2/2] doc: command line interface (cli) dot-repository dwimmery

From: "Felipe Contreras" Sent: Wednesday, May 22, 2013 12:03 AM On Tue, May 21, 2013 at 5:33 PM, Philip Oakley wrote: From: "Felipe Contreras" Sent: Tuesday, May 21, 2013 10:21 PM On Tue, May 21, 2013 at 11:23 AM, Junio C Hamano wrote: "Philip Oakley" writes: On Sat, May 4, 2013 at 2

Re: is it just me, or does --all ignore --no-tags?

On 22 May 2013 17:31, Junio C Hamano wrote: >> So instead of doing; >> git fetch --all --no-tags >> I'm now doing this to avoid the problem; >> git remote | xargs -n 1 git fetch --no-tags > > I suspect that this is 8556646 (fetch --all: pass --tags/--no-tags through to > each remote, 2012-

Re: is it just me, or does --all ignore --no-tags?

> So instead of doing; > git fetch --all --no-tags > I'm now doing this to avoid the problem; > git remote | xargs -n 1 git fetch --no-tags I suspect that this is 8556646 (fetch --all: pass --tags/--no-tags through to each remote, 2012-09-05) which is in 1.7.12.2 and upwards. -- To unsubsc

is it just me, or does --all ignore --no-tags?

I have some peculiar reasons for doing this, but nonetheless I don't believe there's anything illegal here. I have a repo with a bunch of remotes set up to pull in branches and tags from different places, and I need all those branches and tags name-spaced. Eg. to illustrate, the config looks someth

Re: [PATCH 2/2] sha1_name: fix error message for @{}, @{}

On Wed, May 22, 2013 at 6:39 AM, Ramkumar Ramachandra wrote: > Currently, when we try to resolve @{} or @{} when the reflog > doesn't go back far enough, we get errors like: > > # on branch master > $ git show @{1} > fatal: Log for '' only has 7 entries. > > $ git show @{1.days.ago

Re: [PATCH] Document push --no-verify

Junio C Hamano writes: > Thomas Rast writes: > >> ec9 (push: Add support for pre-push hooks, 2013-01-13) forgot to >> add a note to git-push(1) about the new --no-verify option. > > Does it take --verify option (that may well be the default) so that > somebody with > > [alias] put =

Re: git-submodule nested subrepo bug (Segmentation fault)

Ok, version is: 1.8.1.msysgit.1 Segmentation fault at the git clone --recursive http://github.com/Exsul/al_server 0 [main] mkdir 6596 open_stackdumpfile: Dumping stack trace to mkdir.exe.stackdump C:\Users\\libexec\git-core\git-submodule: line 181: 6596 Segmentation fault (core dumped) mkdir -p

Re: Reading commit objects

On Wed, May 22, 2013 at 7:20 AM, Chico Sokol wrote: > I'm not criticizing JGit, guys. It simply doesn't fit into our needs. > We're not interested in mapping git commands in java and don't have > the same RAM limitations. I guess you aren't trying to process the WebKit or Linux kernel repositorie

Re: Reading commit objects

On Wed, May 22, 2013 at 7:25 AM, Chico Sokol wrote: >> Your code is broken. IOUtils is probably corrupting what you get back. >> After inflating the stream you should see the object type ("commit"), >> space, its length in bytes as a base 10 string, and then a NUL ('\0'). >> Following that is the

Re: [PATCH v6] Add new git-related helper to contrib

Junio C Hamano writes: > Felipe Contreras writes: > >> diff --git a/contrib/related/git-related b/contrib/related/git-related >> new file mode 100755 >> index 000..b96dcdd >> --- /dev/null >> +++ b/contrib/related/git-related >> @@ -0,0 +1,124 @@ >> +#!/usr/bin/env ruby >> + >> +# This scrip

Re: [PATCH v6] Add new git-related helper to contrib

Felipe Contreras writes: > diff --git a/contrib/related/git-related b/contrib/related/git-related > new file mode 100755 > index 000..b96dcdd > --- /dev/null > +++ b/contrib/related/git-related > @@ -0,0 +1,124 @@ > +#!/usr/bin/env ruby > + > +# This script finds people that might be interest

Re: [PATCH] Added guilt.reusebranch configuration option.

Theodore Ts'o writes: > On Wed, May 22, 2013 at 10:58:49AM -0700, Junio C Hamano wrote: >> Theodore Ts'o writes: >> >> > I was actually thinking that it might be interesting to have a >> > branch..rewindable, which would change the guilt defaults, and >> > could also key changes in key git beha

Re: override merge.ff = false using --ff-only

Matt McClure writes: > I naively tried to override merge.ff = false using --ff-only on the > command line. I expected that it would override the configured default > and perform a fast-forward merge. Instead, it said: > > $ git config -l | grep -F 'merge.ff' > merge.ff=false > > $ git

Re: first parent, commit graph layout, and pull merge direction

Andreas Krey writes: > A short trial showed that representing first parent chains as > straight lines in the graph does actually improve understandability, > as feature branches clearly stand out as separate lines even when > they no longer carry a branch name. If you have a four-commit segment

Re: [PATCH] Added guilt.reusebranch configuration option.

On Wed, May 22, 2013 at 10:58:49AM -0700, Junio C Hamano wrote: > Theodore Ts'o writes: > > > I was actually thinking that it might be interesting to have a > > branch..rewindable, which would change the guilt defaults, and > > could also key changes in key git behavior which makes it less likely

Re: [PATCH] Added guilt.reusebranch configuration option.

Theodore Ts'o writes: > I was actually thinking that it might be interesting to have a > branch..rewindable, which would change the guilt defaults, and > could also key changes in key git behavior which makes it less likely > that a user shoots him or herself in the foot --- i.e., give warnings >

Re: Avoiding broken Gitweb links and deleted objects

Matt McClure writes: > On Fri, May 10, 2013 at 12:22 PM, Junio C Hamano wrote: >> I think what I missed is that the same logic to ignore side branches >> whose history gets cauterised with such an "ours" merge may apply to >> an "ours" merge that people already make, but the latter may want to >

Re: [PATCH 1/2] sha1_name: fix error message for @{u}

Ramkumar Ramachandra writes: > 2. Callers calling in with programmatic data, and expecting the function >to return and not die(). In this case, why would anyone ever >construct a string containing "@{u}" programmatically in the first >place? If you have to ask why, and cannot answer

Re: [PATCH] Document push --no-verify

Thomas Rast writes: > ec9 (push: Add support for pre-push hooks, 2013-01-13) forgot to > add a note to git-push(1) about the new --no-verify option. Does it take --verify option (that may well be the default) so that somebody with [alias] put = push --no-verify can say "git put --

Re: [PATCH 0/3] Fixing volatile HEAD in push.default = current

Ramkumar Ramachandra writes: > Junio C Hamano wrote: >> The patch may have been done by a wrong motivation, in that it does >> not fundamentally "fix" the itch. The particular "itch" is not >> something we are going to promise to the end users, ever, anyway. > > Just out of curiosity, is it poss

Re: [RFC/PATCH 2/2] doc: command line interface (cli) dot-repository dwimmery

Felipe Contreras writes: > She told Git that her local svn-branch was the basis for svn-next. She > DIT NOT TELL Git to fetch from there. She told Git to fetch from any > location Git thought best to fetch from, either a) or b) would fetch > from the wrong location, but a) would be wronger, you j

Re: English/German terminology, git.git's de.po, and pro-git

On Wednesday 2013-05-22 17:52, Holger Hellmuth (IKS) wrote: >> >> Not sure if German users would know what "hunk" means, in case we >> leave it untranslated. And I'm not sure if I would understand "Kontext". >> I tend to leave it untranslated. > > I don't think "Bereich" is a bad choice. As "hunk"

Re: What's cooking in git.git (May 2013, #05; Mon, 20)

Michael J Gruber writes: >> * mg/more-textconv (2013-05-10) 7 commits >> - grep: honor --textconv for the case rev:path >> - grep: allow to use textconv filters >> - t7008: demonstrate behavior of grep with textconv >> - cat-file: do not die on --textconv without textconv filters >> - show:

Re: [PATCH] Added guilt.reusebranch configuration option.

On Wed, May 22, 2013 at 10:45:31AM -0400, Theodore Ts'o wrote: > I just had another idea (although I haven't had a chance to code up > anything yet). Perhaps instead of, or in addition to, a global > setting (i.e., guilt.reusebranch), perhaps we should have a per-branch > setting, such as branch..

Re: [PATCH v13 02/15] path.c: refactor relative_path(), not only strip prefix

Michael Haggerty writes: >> Different results for relative_path() before and after this refactor: >> >> abs path base path relative (original) relative (refactor) >> = === === >> /a/b/c/ /a/b c/ c/ >>

Remote branch can not be resolved as commit?

I am trying to setup a repository for use inside the LAN, but I have been unable to checkout any branch so far. I am very new to git. The repository is being served from gitblit over https. I have GIT_SSL_NO_VERIFY=true. The repository was created from git svn. git ls-remote shows the remote

Re: English/German terminology, git.git's de.po, and pro-git

Am 22.05.2013 17:16, schrieb Ralf Thielow: hunk = Bereich IMHO "Kontext" is better if you use a German word. Technically the context is something else, but in a German text IMHO it fits nicer when explaining to the user where he/she can select the n-th hunk. Not sure if Ge

Re: Avoiding broken Gitweb links and deleted objects

On Wed, May 22, 2013 at 6:32 AM, Matt McClure wrote: > Is there a way to push/pull reflogs among different repositories? Not that I am aware of, at least not in core git. > In my original scenario: > > 1. the commits are created on a developer machine > 2. pushed to a central origin repository r

Re: English/German terminology, git.git's de.po, and pro-git

2013/5/20 Christian Stimming : > Thanks for the update. I would like to add some comments on this G+E glossary > and I hope you are interested in reading those, even though it is known that I > prefer a "pure Ger" translation. However, as I wrote in my other message I > agree that for the command l

Re: Reading commit objects

Solved! It was exaclty the problem pointed by Shawn. Here is the working code: File dotGit = new File("objects/25/0f67ef017fcb97b5371a302526872cfcadad21"); InflaterInputStream inflaterInputStream = new InflaterInputStream(new FileInputStream(dotGit)); Integer read = inflaterInputStream.read(); wh

Re: [PATCH] Added guilt.reusebranch configuration option.

I just had another idea (although I haven't had a chance to code up anything yet). Perhaps instead of, or in addition to, a global setting (i.e., guilt.reusebranch), perhaps we should have a per-branch setting, such as branch..guiltReuseBranch? I was actually thinking that it might be interesting

Re: [PATCH 0/3] Fixing volatile HEAD in push.default = current

Junio C Hamano wrote: > The patch may have been done by a wrong motivation, in that it does > not fundamentally "fix" the itch. The particular "itch" is not > something we are going to promise to the end users, ever, anyway. Just out of curiosity, is it possible to write a correct fix at all? Eve

Re: [PATCH 0/3] Fixing volatile HEAD in push.default = current

Ramkumar Ramachandra writes: > Why should I lie in the patch? The terminal flipping was a very big > itch I had, and the patch fixes exactly that issue. Showing the real > branch name was an unintended side-effect. > > I just said "early" and showed a nice end-user example in which it > works,

Re: Reading commit objects

> Your code is broken. IOUtils is probably corrupting what you get back. > After inflating the stream you should see the object type ("commit"), > space, its length in bytes as a base 10 string, and then a NUL ('\0'). > Following that is the tree line, and parent(s) if any. I wonder if > IOUtils di

Re: Reading commit objects

I'm not criticizing JGit, guys. It simply doesn't fit into our needs. We're not interested in mapping git commands in java and don't have the same RAM limitations. I know JGit team is doing a great job and we do not intend to build a library with such completeness. Are you guys contributors of JG

Re: English/German terminology, git.git's de.po, and pro-git

2013/5/20 Holger Hellmuth : > Am 19.05.2013 18:56, schrieb Ralf Thielow: > >> 2013/5/16 Holger Hellmuth (IKS) : >>> >>> >> [...] +reset = neu setzen (maybe "umsetzen"?) >>> >>> >>> >>> "zurücksetzen" >>> >> >> "reset" can be used with every existing commit. "zurücksetzen" >> would imp

Re: override merge.ff = false using --ff-only

Hi, Le 22.05.2013 15:21, Matt McClure a écrit : I naively tried to override merge.ff = false using --ff-only on the command line. I expected that it would override the configured default and perform a fast-forward merge. Instead, it said: $ git config -l | grep -F 'merge.ff' merge.ff=

Re: [PATCH] Added guilt.reusebranch configuration option.

On Wed, May 22, 2013 at 03:01:36PM +0200, Per Cederqvist wrote: > When the option is true (the default), Guilt does not create a new Git > branch when patches are applied. This way, you can switch between > Guilt 0.35 and the current version of Guilt with no issues. > > At a future time, maybe a

Re: Avoiding broken Gitweb links and deleted objects

On Fri, May 10, 2013 at 3:34 AM, William Swanson wrote: > I started working on something like this a few weeks ago, but > eventually came to the conclusion that this information does not > belong in the commit graph itself. > > A better approach, I think, would be to enhance the reflogs to the > p

Re: [PATCH] guilt: fix date parsing

On Wed, May 22, 2013 at 08:10:10AM -0400, Theodore Ts'o wrote: > On Tue, May 21, 2013 at 11:39:21PM -0400, Josef 'Jeff' Sipek wrote: > > I applied this one and the "guilt: skip empty line after..." patch. > > Thanks! BTW, it looks like you are not using "git am -s" to apply > these patches? The

Re: Avoiding broken Gitweb links and deleted objects

On Fri, May 10, 2013 at 12:22 PM, Junio C Hamano wrote: > I think what I missed is that the same logic to ignore side branches > whose history gets cauterised with such an "ours" merge may apply to > an "ours" merge that people already make, but the latter may want to > take both histories into ac

[PATCH] Geolocation support

Hi all, this is a hack I made a couple of years ago in order to store my current location in git commits (I travel a lot and being able to associate a place with the commit date helps me to quickly recover what were doing at that time). Long story short, the screeenshot at http://tinypic.com/r/war

override merge.ff = false using --ff-only

I naively tried to override merge.ff = false using --ff-only on the command line. I expected that it would override the configured default and perform a fast-forward merge. Instead, it said: $ git config -l | grep -F 'merge.ff' merge.ff=false $ git merge --ff-only foo fatal: You c

[PATCH] Added guilt.reusebranch configuration option.

When the option is true (the default), Guilt does not create a new Git branch when patches are applied. This way, you can switch between Guilt 0.35 and the current version of Guilt with no issues. At a future time, maybe a year after Guilt with guilt.reusebranch support is released, the default s

Re: [PATCH -v2] guilt: force the use of bare branches

On 05/22/13 14:11, Theodore Ts'o wrote: To make it harder to accidentally do "git push" with a guilt patch applied, "guilt push" changes branch from e.g. "master" to "guilt/master" starting with commit 67d3af63f422. This is a feature which I use for ext4 development; I actually *do* want to be a

Re: [PATCH] push: document --no-verify

On Wed, May 22, 2013 at 02:12:21PM +0200, Thomas Rast wrote: > "Michael S. Tsirkin" writes: > > > commit ec9f937727bcb0fa8a3dfe6af68c188e968a added > > --no-verify flag to git push, but didn't document it. > > It's a useful flag when using pre-push hooks so > > add the documentation. > > > >

Re: [PATCH] push: document --no-verify

"Michael S. Tsirkin" writes: > commit ec9f937727bcb0fa8a3dfe6af68c188e968a added > --no-verify flag to git push, but didn't document it. > It's a useful flag when using pre-push hooks so > add the documentation. > > Suggested-by: Thomas Rast > Cc: Aaron Schrab > Signed-off-by: Michael S. Ts

[PATCH -v2] guilt: force the use of bare branches

To make it harder to accidentally do "git push" with a guilt patch applied, "guilt push" changes branch from e.g. "master" to "guilt/master" starting with commit 67d3af63f422. This is a feature which I use for ext4 development; I actually *do* want to be able to push patches to the dev branch, whi

Re: [PATCH] guilt: fix date parsing

On Tue, May 21, 2013 at 11:39:21PM -0400, Josef 'Jeff' Sipek wrote: > I applied this one and the "guilt: skip empty line after..." patch. Thanks! BTW, it looks like you are not using "git am -s" to apply these patches? The reason why I ask is that whatever you're using isn't removing the [XXX] s

first parent, commit graph layout, and pull merge direction

Hi everyone, I'm just looking into better displays of the commit graph (as displayed with gitk, smartgit, fisheye) - they tend to quickly dissolve into a heap of spaghetti. We had the idea that treating the first parent specially would have some advantage here - including graphically indicating w

[PATCH] push: document --no-verify

commit ec9f937727bcb0fa8a3dfe6af68c188e968a added --no-verify flag to git push, but didn't document it. It's a useful flag when using pre-push hooks so add the documentation. Suggested-by: Thomas Rast Cc: Aaron Schrab Signed-off-by: Michael S. Tsirkin --- Documentation/git-push.txt | 7 +++

[PATCH 1/2] sha1_name: fix error message for @{u}

Currently, when no (valid) upstream is configured for a branch, you get an error like: $ git show @{u} error: No upstream configured for branch 'upstream-error' error: No upstream configured for branch 'upstream-error' fatal: ambiguous argument '@{u}': unknown revision or path not in the w

[PATCH 2/2] sha1_name: fix error message for @{}, @{}

Currently, when we try to resolve @{} or @{} when the reflog doesn't go back far enough, we get errors like: # on branch master $ git show @{1} fatal: Log for '' only has 7 entries. $ git show @{1.days.ago} warning: Log for '' only goes back to Tue, 21 May 2013 14:14:45 +0530.

[PATCH v2 0/2] Fix invalid revision error messages

As Junio pointed out in [0/2], this is not for 1.8.3; it's just a regular "enhacement". In [1/2], I've extended the commit message with the justification I wrote out for Junio. In [2/2], I've made sure to print the "correct" error message everytime: I missed the detached HEAD case last time. I'm

[PATCH] Document push --no-verify

ec9 (push: Add support for pre-push hooks, 2013-01-13) forgot to add a note to git-push(1) about the new --no-verify option. Signed-off-by: Thomas Rast --- The insertion spot is at the end, because the existing ordering is indistinguishable from random. This should also be fixed, but is a m

Re: git-submodule nested subrepo bug (Segmentation fault)

I'm guessing Kirill meant to send this to the list and not just to me. It looks to me like the segfault is in MSys's mkdir.exe and not a Git process. - Forwarded message from Kirill Berezin - From: Kirill Berezin To: John Keeping Date: Wed, 22 May 2013 09:54:47 +0400 Message-ID: Subj

Re: [PATCH v13 02/15] path.c: refactor relative_path(), not only strip prefix

Sorry for coming late to the party. On 05/22/2013 03:40 AM, Jiang Xin wrote: > Original design of relative_path() is simple, just strip the prefix > (*base) from the absolute path (*abs). In most cases, we need a real > relative path, such as: ../foo, ../../bar. That's why there is another > reimp

Re: [PATCH v2] prompt: fix show upstream with svn and zsh

On Wed, May 22, 2013 at 2:40 AM, Thomas Gummerer wrote: > Currently the __git_ps1 git prompt gives the following error with a > repository converted by git-svn, when used with zsh: > >__git_ps1_show_upstream:19: bad pattern: svn_remote[ >__git_ps1_show_upstream:45: bad substitution > > To

Re: What's cooking in git.git (May 2013, #05; Mon, 20)

On Tue, May 21, 2013 at 5:35 PM, Junio C Hamano wrote: > Johan Herland writes: >> On Tue, May 21, 2013 at 2:15 AM, Junio C Hamano wrote: >>> * jh/shorten-refname (2013-05-07) 4 commits >>> - t1514: refname shortening is done after dereferencing symbolic refs >>> - shorten_unambiguous_ref(): Fi

[PATCH v2] prompt: fix show upstream with svn and zsh

Currently the __git_ps1 git prompt gives the following error with a repository converted by git-svn, when used with zsh: __git_ps1_show_upstream:19: bad pattern: svn_remote[ __git_ps1_show_upstream:45: bad substitution To reproduce the problem, the __git_ps1_show_upstream function can be ex

Re: What's cooking in git.git (May 2013, #05; Mon, 20)

BTW, I love our rev-list machinery: log --graph --abbrev-commit --pretty=oneline --decorate --cherry-mark --left-right mjg/grep-textconv...origin/next > 701cdb7 Merge branch 'mg/more-textconv' into next |\ | = afa15f3 (gitster/mg/more-textconv) grep: honor --textconv for the case rev:path | = 3

Re: [PATCH] prompt: fix show upstream with svn and zsh

Felipe Contreras writes: > On Tue, May 21, 2013 at 3:54 PM, Thomas Gummerer wrote: >> Currently the __git_ps1 git prompt gives the following error with a >> repository converted by git-svn, when used with zsh: >> >>__git_ps1_show_upstream:19: bad pattern: svn_remote[ >> >> This was i

Re: [PATCH] prompt: fix show upstream with svn and zsh

SZEDER Gábor writes: > Hi, > > > On Tue, May 21, 2013 at 10:54:27PM +0200, Thomas Gummerer wrote: >> Currently the __git_ps1 git prompt gives the following error with a >> repository converted by git-svn, when used with zsh: >> >> __git_ps1_show_upstream:19: bad pattern: svn_remote[ >> >>

Re: What's cooking in git.git (May 2013, #05; Mon, 20)

Junio C Hamano venit, vidit, dixit 21.05.2013 02:15: > Here are the topics that have been cooking. Commits prefixed with > '-' are only in 'pu' (proposed updates) while commits prefixed with > '+' are in 'next'. > > The final version of 1.8.3 is expected to be tagged late this week. > While apply