Junio C Hamano writes:
> Junio C Hamano writes:
>
>>> While the result is more consistent and more predictable in the case
>>> of merged cherry picks, it is also slower in every case.
>>
>> Consistent and predictable, perhaps, but I am not sure "exact" would
>> be a good word.
>
> Another thing
On Fri, Jan 10, 2014 at 04:41:20AM -0500, Jeff King wrote:
> That being said, we could further optimize this by not opening the files
> at all (and make that the responsibility of do_one_ref, which we are
> avoiding here). I am slightly worried about the open() cost of my
> solution. It's amortize
Hi,
On Thu, Jan 09, 2014 at 02:18:40PM -0800, W. Trevor King wrote:
> On Thu, Jan 09, 2014 at 10:40:52PM +0100, Jens Lehmann wrote:
> > Am 09.01.2014 20:55, schrieb W. Trevor King:
> > > On Thu, Jan 09, 2014 at 08:23:07PM +0100, Jens Lehmann wrote:
> > >> Am 09.01.2014 18:32, schrieb W. Trevor Kin
On 01/14/2014 10:50 AM, Jeff King wrote:
> On Fri, Jan 10, 2014 at 04:41:20AM -0500, Jeff King wrote:
>
>> That being said, we could further optimize this by not opening the files
>> at all (and make that the responsibility of do_one_ref, which we are
>> avoiding here). I am slightly worried about
Hi,
I just did a rebase, and it throws an error like this:
Applying: comment1
Applying: comment2
Applying: comment3
Applying: comment4
Applying: patch_with_binary_files
fatal: git diff header lacks filename information when removing 1
leading pathname component (line 7330213)
Repository lacks nec
On 14 January 2014 12:48, demerphq wrote:
> Hi,
>
> I just did a rebase, and it throws an error like this:
>
> Applying: comment1
> Applying: comment2
> Applying: comment3
> Applying: comment4
> Applying: patch_with_binary_files
> fatal: git diff header lacks filename information when removing 1
>
Hi everyone,
I have completed Bulgarian translation for gtik and git-gui. Should I
submit them via this list as inline patches?
Kind regards:
al_shopov
--
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 ht
hi folks,
I have a git server which gets pushes of data (not code) from a couple
hundred VMs every hour. Every round of pushes leaves two stray .keep
files, so I am guessing two clients are having problems completing the
push. The contents being pushed are reports of a puppet run.
Is there a hand
git can't execute hooks no partitions mounted with noexec - even if
those are just scripts with shebang line and they actualy work by
hooks/./post-comit (because I use small patch on kernel that allows
running scripts that way on noexec partition)
fs/exec.c
//error = -EACCES;
//if
On Tue, Jan 14, 2014 at 11:24:45AM +0100, Heiko Voigt wrote:
> On Thu, Jan 09, 2014 at 02:18:40PM -0800, W. Trevor King wrote:
> > Users who are worried about loosing local updates should not be
> > using a checkout-style updates. If they are using a
> > checkout-style update, and they ask for an
On Tue, Jan 14, 2014 at 9:54 AM, Martin Langhoff
wrote:
> Is there a handy way to list the blobs in a pack, so I can feed them
> to git-cat-file and see what's in there? I'm sure that'll help me
> narrow down on the issue.
git show-index <
/var/lib/ppg/reports.git/objects/pack/pack-22748bcca7f50
The latest maintenance release Git v1.8.5.3 is now available at
the usual places, backporting the fixes that happened on the
'master' front.
The release tarballs are found at:
http://code.google.com/p/git-core/downloads/list
and their SHA-1 checksums are:
767aa30c0f569f9b6e04cb215dfeec0c013
Ivan Zakharyaschev writes:
> Hello!
>
> git-1.8.4.4
>
> The manpage for git-pull mentions -m in a comment:
>
> --edit, -e, --no-edit
> Invoke an editor before committing successful mechanical merge to further edit
> the auto-generated merge message, so that the user can explain and justify the
>
Diagnosing errors with git over ssh has historically required tooling
up for debugging or looking at things from the client side, because
git does not log anything on the server side.
It would be a boon to those running busy git servers to be able to
diagnose by looking at a log. It can be both ol
On 2014-01-14 19.26, Junio C Hamano wrote:
> Ivan Zakharyaschev writes:
>
>> Hello!
>>
>> git-1.8.4.4
>>
>> The manpage for git-pull mentions -m in a comment:
>>
>> --edit, -e, --no-edit
>> Invoke an editor before committing successful mechanical merge to further
>> edit
>> the auto-generated me
Junio C Hamano writes:
> The "pick the one that exactly matches if exists" can be thought of
> an easy hack to hide the problems that come from this arbitrary
> choice. ...
> Instead, "pass the whole blame to the one that exactly matches" hack
> keeps larger blocks of text unsplit, clumping rela
Perhaps the receiving process is dying hard and leaving
stuff behind? Out-of-memory, out of disk space?
-Martin
On Tuesday, January 14, 2014 10:10:31 am Martin Langhoff
wrote:
> On Tue, Jan 14, 2014 at 9:54 AM, Martin Langhoff
>
> wrote:
> > Is there a handy way to list the blobs in a pack,
Torsten Bögershausen writes:
>> Subject: Documentaiotn: exclude irrelevant options from "git pull"
>^^
> (Small nit ??)
;-).
They are now a small two patch series, with typofix for the above.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body o
On Tue, Jan 14, 2014 at 2:36 PM, Martin Fick wrote:
> Perhaps the receiving process is dying hard and leaving
> stuff behind? Out-of-memory, out of disk space?
Yes, that's my guess as well. This server had gc misconfigured, so it
hit ENOSPC a few weeks ago.
It is likely that the .lock files we
10eb64f5 (git pull manpage: don't include -n from fetch-options.txt,
2008-01-25) introduced a way to exclude some parts of included
source when building git-pull documentation, and later 409b8d82
(Documentation/git-pull: put verbosity options before merge/fetch
ones, 2010-02-24) attempted to use th
Even though "--[no-]edit" can be used with "git pull", the
explanation of the interaction between this option and the "-m"
option does not make sense within the context of "git pull". Use
the conditional inclusion mechanism to remove this part from "git
pull" documentation, while keeping it for "g
On Tue, Jan 14, 2014 at 08:57:09AM -0800, W. Trevor King wrote:
> > > On Thu, Jan 09, 2014 at 10:40:52PM +0100, Jens Lehmann wrote:
> > > > Am 09.01.2014 20:55, schrieb W. Trevor King:
> > > > > Maybe you meant "for checkout I can easily overwrite the local
> > > > > changes with the upstream branc
On Tue, Jan 14, 2014 at 09:58:30PM +0100, Heiko Voigt wrote:
> A typical workflow where a feature in a project needs some extension or
> change in a submodule goes like this:
>
> 1. The developer does his changes locally implementing everything
>needed. To commit he creates a local branch in t
Hi,
On Tue, Jan 14, 2014 at 11:24:45AM +0100, Heiko Voigt wrote:
> I will write another post about how I think we should/can proceed.
and here is my suggestion how we should proceed.
I think there have been many interesting ideas in this thread but IMO
some of them tried to achieve a little bit
Michael Haggerty writes:
> We used to use two separate rules for the normal ref resolution
> dwimming and dwimming done to decide which remote ref to grab. The
> third parameter to refname_match() selected which rules to use.
>
> When these two rules were harmonized in
>
> 2011-11-04 dd621df
On Tue, Jan 14, 2014 at 01:42:09PM -0800, W. Trevor King wrote:
> On Tue, Jan 14, 2014 at 09:58:30PM +0100, Heiko Voigt wrote:
> > A typical workflow where a feature in a project needs some extension or
> > change in a submodule goes like this:
> >
> > 1. The developer does his changes locally imp
On Tue, Jan 14, 2014 at 10:46:08PM +0100, Heiko Voigt wrote:
> I would like to step back a bit and get back to the original problem
> at hand: Francescos original use case of an attached head for direct
> commits on a stable branch in a submodule. How about we finish
> discussing the exact solution
On Tue, Jan 14, 2014 at 11:19:07PM +0100, Heiko Voigt wrote:
> On Tue, Jan 14, 2014 at 01:42:09PM -0800, W. Trevor King wrote:
> > The “gitlinked commits must be in the subproject's master” rule
> > protects you from blowing stuff away here. You could use rebase- or
> > merge-style integration as
On Tue, Jan 14, 2014 at 02:22:31PM -0800, W. Trevor King wrote:
> On Tue, Jan 14, 2014 at 10:46:08PM +0100, Heiko Voigt wrote:
> > I would like to step back a bit and get back to the original problem
> > at hand: Francescos original use case of an attached head for direct
> > commits on a stable br
I couldn't find a duplicate in the JIRA instance.
According to the documentation of check-ref-format, a branch name such
as @mybranch is valid. Yet 'git check-ref-format --branch @mybranch@{u}'
claims @mybranch is an invalid branch name. yet I am able to create the
branch (which would seem the
p...@padd.com wrote on Mon, 13 Jan 2014 19:18 -0500:
> dam...@iwi.me wrote on Mon, 13 Jan 2014 14:37 +0100:
> > I am trying to clone a perforce repository via git and I am having the
> > following backtrace :
> >
> > {14:20}~/projects/:master ✗ ➭ git p4 clone //depot/@all .
> > Importing revi
The following message is a courtesy copy of an article
that has been posted to gmane.comp.version-control.git as well.
Junio C Hamano writes:
> Thomas Ackermann writes:
>>> > But for the simple use case where you only have a master
>>> > branch I consider it not really helpful and - at least for
Keith Derrick writes:
> I couldn't find a duplicate in the JIRA instance.
Don't worry, we do not use any JIRA instance ;-)
> According to the documentation of check-ref-format, a branch name such
> as @mybranch is valid.
Correct.
> Yet 'git check-ref-format --branch @mybranch@{u}'
> claims
Since 918dbf58, git-gui crashes if started with Tk 8.4. The reason is that
tk < 8.5 does not support -stretch option for panedwindow.
Without the option it's not possible to properly expand the right half -
the commit area is expanded, while desired behavior is to expand the diff
area. So the whol
2014/1/14 Heiko Voigt :
> On Tue, Jan 14, 2014 at 02:22:31PM -0800, W. Trevor King wrote:
>> On Tue, Jan 14, 2014 at 10:46:08PM +0100, Heiko Voigt wrote:
>> > I would like to step back a bit and get back to the original problem
>> > at hand: Francescos original use case of an attached head for dire
I've matured this opinion about "local-branch" some days ago, but I
couldn't join the discussion because I was extremely busy. Hope it's
is still current (and correct).
2014/1/9 W. Trevor King
>
> @@ -339,7 +339,19 @@ module_clone()
> echo "gitdir: $rel/$a" >"$sm_path/.git"
>
> re
On Wed, Jan 15, 2014 at 01:18:12AM +0100, Francesco Pretto wrote:
> I've matured this opinion about "local-branch" some days ago, but I
> couldn't join the discussion because I was extremely busy. Hope it's
> is still current (and correct).
I think the discussion is still open, but actions are pos
On Wed, Jan 15, 2014 at 1:44 AM, Martin Langhoff
wrote:
> Diagnosing errors with git over ssh has historically required tooling
> up for debugging or looking at things from the client side, because
> git does not log anything on the server side.
>
> It would be a boon to those running busy git ser
On Tue, Jan 14, 2014 at 8:51 PM, Duy Nguyen wrote:
> We'll need to output the error side bands to stderr
> too in case side-band is used.
Agreed, we'd need to "tee" the output so it gets to the logger _and_ to stderr.
I thought perhaps daemon.c would have something in this spirit, but
the trivia
On Tue, Jan 14, 2014 at 03:45:27PM -0800, Junio C Hamano wrote:
> > Yet 'git check-ref-format --branch @mybranch@{u}'
> > claims @mybranch is an invalid branch name.
>
> I do not think it claims any such thing.
>
> $ git check-ref-format --branch @foo@{u}; echo $?
> fatal: '@foo@{u}' is
On Mon, Jan 13, 2014 at 12:55 PM, Junio C Hamano wrote:
> "Jason St. John" writes:
>
>> What AsciiDoc formatter (and version) do you use?
>
> $ asciidoc --version
> asciidoc 8.6.8
>
> Checking with www.methods.co.nz/asciidoc, I am behind by about 2
> months, it seems, though.
I just went
Hi,
what are the possible causes of this?
After stash pop, refs/stash becomes 40 zeroes.
This is the only stash, so refs/stash should be deleted after pop.
However, it becomes 40 zeroes.
git 1.8.x
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord
Also, logs/refs/stash becomes empty (0 bytes of file size) after pop.
2014/1/15 乙酸鋰 :
> Hi,
>
> what are the possible causes of this?
> After stash pop, refs/stash becomes 40 zeroes.
> This is the only stash, so refs/stash should be deleted after pop.
> However, it becomes 40 zeroes.
>
> git 1.8.x
Jeff King writes:
> Is that what "--branch" does? I have never used it, but the manpage
> seems to suggest it is about _parsing_ (which, IMHO, means it probably
> should have been an option to rev-parse, but that is another issue
> altogether).
Ahh, of course you are right. I never use it, and
On Tue, Jan 14, 2014 at 11:46:58PM -0800, Junio C Hamano wrote:
> Jeff King writes:
>
> > Is that what "--branch" does? I have never used it, but the manpage
> > seems to suggest it is about _parsing_ (which, IMHO, means it probably
> > should have been an option to rev-parse, but that is anothe
45 matches
Mail list logo