This is a better fix for 8d849957d81fc0480a52570d66cc3c2a688ecb1b.
All that was required to fix the original issue was to remove the extra
mc call, i.e. change [mc "Sorry, gitk cannot run..."] to simply
"Sorry, gitk cannot run..." Changing the signature of proc show_error
was unnecessary and intro
On Sun, Apr 05, 2015 at 10:13:21PM -0400, Eric Sunshine wrote:
> > - strbuf_grow(sb, 1);
> > + strbuf_grow_ch(sb);
>
> strbuf_grow_ch() seems overly special-case. What about instead taking
> advantage of inline strbuf_avail() to do something like this?
>
> if (!st
On Mon, Apr 06, 2015 at 12:39:15AM +0200, René Scharfe wrote:
> >...this. I think that effort might be better spent on a ref storage
> >format that's more efficient, simpler (with respect to subtle races and
> >such), and could provide other features (e.g., transactional atomicity).
>
> Such as a
On Tue, Jan 06, 2015 at 12:52:00PM -0500, Marc Branchaud wrote:
> Signed-off-by: Marc Branchaud
> ---
>
> I often open multiple gitk windows in the same working directory to examine
> other branches or refs in the repo. This change allows me to distinguish
> which window is showing what.
>
> Th
On Thu, Apr 02, 2015 at 03:05:06PM -0600, Alex Henrie wrote:
> Signed-off-by: Alex Henrie
> ---
> gitk | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/gitk b/gitk
> index 9a2daf3..30fcd30 100755
> --- a/gitk
> +++ b/gitk
> @@ -4066,7 +4066,7 @@ set known_view_options {
>
On Mon, Mar 23, 2015 at 10:18:16AM -0400, Marc Branchaud wrote:
> Signed-off-by: Marc Branchaud
Thanks, applied.
Paul.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-
On Thu, Apr 02, 2015 at 03:05:35PM -0600, Alex Henrie wrote:
> This partially reverts commit 8d849957d81fc0480a52570d66cc3c2a688ecb1b.
... and brings back the bug that 8d849957d81f solves, as far as I can
see. If that's not the case then you need to explain that in the
patch description.
Paul.
-
On Fri, Mar 27, 2015 at 10:34:25AM +0100, Peter Krefting wrote:
> Please find attached (for text encoding reasons) an update to the Swedish
> translation for gitk.
Thanks, applied.
Paul.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.k
On Fri, Apr 03, 2015 at 09:28:00PM -0400, Martin d'Anjou wrote:
> On 15-04-03 07:05 PM, Alex Henrie wrote:
> >2015-02-18 12:27 GMT-07:00 Martin d'Anjou :
> >>It appears I have uncovered inconsistent behaviour in gitk. Looks like
> >>a bug. I have a picture here:
> >>https://docs.google.com/document
I’m having trouble understanding why I cannot stash changes to a submodule.
When adding a submodule to a repository (`git submodule add
./sub-repo`), I can then run `git stash` and `git stash pop` with
expected results—the submodule disappears and reappears in the working
tree.
However, when I tr
On Sat, Apr 4, 2015 at 9:11 PM, Jeff King wrote:
> We have to call strbuf_grow anytime we are going to add data
> to a strbuf. In most cases, it's a noop (since we grow the
> buffer aggressively), and the cost of the function call and
> size check is dwarfed by the actual buffer operation.
>
> For
By using a tree with multiple identical files and allowing copy detection to
choose any one of them, the check in the test is unnecessarily complex. We can
simplify by:
* Modify source file (file2) before copying the file.
* Check that only file2 is the source in the output of "p4 filelog".
* Rem
Am 05.04.2015 um 20:59 schrieb Jeff King:
Still, the numbers are promising. Here's are comparisons
against for-each-ref on torvalds/linux, which has a 218M
packed-refs file:
$ time git for-each-ref \
--format='%(objectname) %(refname)' \
refs/remotes/2325298/ |
wc -c
4
Luke Diamand wrote on Sun, 05 Apr 2015 20:27:11 +0100
> On 28/03/15 12:28, Vitor Antunes wrote:
> > I'm adding a test case for a scenario I was confronted with when using
> > branch
> > detection and a client view specification. It is possible that the
> > implemented
> > fix may not cover all p
On Tue, Feb 24, 2015 at 11:09 PM, Jeff King wrote:
> I wanted to make one more announcement about this, since a few more
> details have been posted at:
>
> http://git-merge.com/
>
> since my last announcement. Specifically, I wanted to call attention to
> the contributor's summit on the 8th. Bas
Am 05.04.2015 um 20:52 schrieb Jeff King:
On Sun, Apr 05, 2015 at 03:41:39PM +0200, René Scharfe wrote:
I wonder if pluggable reference backends could help here. Storing refs
in a database table indexed by refname should simplify things.
...this. I think that effort might be better spent on a
Koosha Khajehmoogahi writes:
> diff --git a/Documentation/rev-list-options.txt
> b/Documentation/rev-list-options.txt
> index f620ee4..0bb2390 100644
> --- a/Documentation/rev-list-options.txt
> +++ b/Documentation/rev-list-options.txt
> @@ -96,12 +96,24 @@ if it is part of the log message.
> -
Oliver Runge writes:
> I'm using git version 2.4.0-rc1. The same behavior exists in 2.1.0.
>
> Trying the same with rev-list results in:
>> git rev-list --pretty=format:"%h ..." HEAD~3...HEAD
> commit 826aed50cbb072d8f159e4c8ba0f9bd3df21a234
> 826aed5 ...
> commit 915e44c6357f3bd9d5fa498a201872c4
Jeff King writes:
> On Sun, Apr 05, 2015 at 01:27:32AM -0400, Jeff King wrote:
>
>> On Sun, Apr 05, 2015 at 12:56:14AM -0400, Jeff King wrote:
>>
>> > The big downside is that our input strings are no longer NUL-clean
>> > (reading "foo\0bar\n" would yield just "foo". I doubt that matters in
>>
"Yi, EungJun" writes:
> Hello. I am serving a git hosting service for my company.
>
> Sometimes I want to send a warning message to users who use my
> service; e.g. the service will be shutdown tomorrow for a while
> temporary.
>
> I know it is possible to a remote message by hooks or HTTP body i
Jeff King writes:
> So we'd have to either:
>
> 1. Decide that doesn't matter.
>
> 2. Have callers specify a "damn the NULs, I want it fast" flag.
The callers that used to call fgets and then later rewritten to
strbuf_getwholeline(), either of the above obviously should be OK,
and because th
karthik nayak writes:
> On 04/05/2015 01:16 PM, Junio C Hamano wrote:
>
>> If it semantically does not make sense to ask for the typename
>> without asking for the type code, then we can and should make that
>> as a new calling convention _all_ callers must follow.
>>
>> In other words, I think i
On 28/03/15 12:28, Vitor Antunes wrote:
I'm adding a test case for a scenario I was confronted with when using branch
detection and a client view specification. It is possible that the implemented
fix may not cover all possible scenarios, but there is no regression in the
available tests.
Vitor
On Sun, Apr 05, 2015 at 02:52:59PM -0400, Jeff King wrote:
> Right now we parse all of the packed-refs file into an in-memory cache,
> and then do single lookups from that cache. Doing an mmap() and a binary
> search is way faster (and costs less memory) for doing individual
> lookups. It relies o
On Sun, Apr 05, 2015 at 03:41:39PM +0200, René Scharfe wrote:
> > The main culprits seem to be d0f810f (which introduced some extra
> > expensive code for each ref) and my 10c497a, which switched from fgets()
> > to strbuf_getwholeline. It turns out that strbuf_getwholeline is really
> > slow.
>
Update sha1_loose_object_info() to optionally allow it to read
from a loose object file of unknown/bogus type; as the function
usually returns the type of the object it read in the form of enum
for known types, add an optional "typename" field to receive the
name of the type in textual form and a f
On Sun, Apr 05, 2015 at 09:36:04PM +0700, Duy Nguyen wrote:
> On Sun, Apr 5, 2015 at 11:56 AM, Jeff King wrote:
> > So we'd have to either:
> >
> > 1. Decide that doesn't matter.
> >
> > 2. Have callers specify a "damn the NULs, I want it fast" flag.
>
> 2+. Avoid FILE* interface and go with
Hello. I am serving a git hosting service for my company.
Sometimes I want to send a warning message to users who use my
service; e.g. the service will be shutdown tomorrow for a while
temporary.
I know it is possible to a remote message by hooks or HTTP body if an
error occured. But it seems tha
On Sun, Apr 05, 2015 at 04:19:50PM +0200, Lionel CHAZALLON wrote:
> > Le 5 avr. 2015 à 14:17, John Keeping a écrit :
> >
> > On Sun, Apr 05, 2015 at 11:31:54AM +, LongChair . wrote:
> >> I have been looking into ignoring a subdirectory of my tree for
> >> diffing with upstream. I'll explain
On Sun, Apr 5, 2015 at 11:56 AM, Jeff King wrote:
> So we'd have to either:
>
> 1. Decide that doesn't matter.
>
> 2. Have callers specify a "damn the NULs, I want it fast" flag.
2+. Avoid FILE* interface and go with syscalls for reading
packed-refs? If mmaping the entire file could be a prob
Hello John,
Thanks for the answer. I am also using some GUI client (smartgit). Is there any
way to make this part of the repo attributes / configuration so that my git GUI
would use it ?
Lionel.
> Le 5 avr. 2015 à 14:17, John Keeping a écrit :
>
> On Sun, Apr 05, 2015 at 11:31:54AM +, L
Am 05.04.2015 um 03:06 schrieb Jeff King:
> As I've mentioned before, I have some repositories with rather large
> numbers of refs. The worst one has ~13 million refs, for a 1.6GB
> packed-refs file. So I was saddened by this:
>
>$ time git.v2.0.0 rev-parse refs/heads/foo >/dev/null 2>&1
>
Need a Soft, Business, Home or Private Loan? Then Email Us Back as we would be
glad to assist.
Regards,
John Ryder
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-inf
On Sun, Apr 05, 2015 at 11:31:54AM +, LongChair . wrote:
> I have been looking into ignoring a subdirectory of my tree for
> diffing with upstream. I'll explain the situation below :
>
> My tree is a fork of an upstream repo. There is a specific directory
> in my tree lets call it foo/bar th
Hello,
I have been looking into ignoring a subdirectory of my tree for diffing with
upstream.
I'll explain the situation below :
My tree is a fork of an upstream repo.
There is a specific directory in my tree lets call it foo/bar that i would like
to ignore for diff. This directory includes onl
Some git hosting services, like Github, a url to a git repository can
be changed by changing the name of the repository by the owner. If
someone tries to get the repository with the old url, usually the
hosting service serves the request with the repository indiciated by
the new url. It is very hel
On 04/05/2015 01:16 PM, Junio C Hamano wrote:
karthik nayak writes:
So, it makes me wonder what guarantee we have that this does not
dereference a NULL here.
As per my code, oi->typename is only pointing to something when oi->typep
is ( As oi->typename is currently only used in cat-file.c)
karthik nayak writes:
>> So, it makes me wonder what guarantee we have that this does not
>> dereference a NULL here.
>>
> As per my code, oi->typename is only pointing to something when oi->typep
> is ( As oi->typename is currently only used in cat-file.c).
> But what you're saying also is true,
38 matches
Mail list logo
