When we fetch a pack that does not contain an object we
expected to receive, we get an error like:
$ git init --bare tmp.git && cd tmp.git
$ git fetch ../parent.git
[...]
error: Could not read 964953ec7bcc0245cb1d0db4095455edd21a2f2e
fatal: Failed to traverse parents of commit
b8247b40c
All the reviews about Kitchen Design Lancashire are good from what I can see.
-
Kitchen Design Lancashire Reviews
--
View this message in context:
http://git.661346.n2.nabble.com/Kitchen-Design-Lancashire-Reviews-tp7610271.html
Sent from the git mailing list archive at Nabble.com.
--
To u
Hi Junio,
The following changes since commit b28aeab4ec1df28f3be3cb62ff4b85e5332d8d13:
Git 2.0-rc3 (2014-05-09 11:23:55 -0700)
are available in the git repository at:
git://github.com/git-l10n/git-po master
for you to fetch changes up to 1c3c8410ef02750b8be84cea32ffee8f70918ae9:
l10n: U
On 05/11/2014 11:34 PM, Junio C Hamano wrote:
Sitaram Chamarty writes:
But what I was looking for was validation from git.git folks of the idea
of replicating what "git clone -l" does, for an *existing* repo.
For example, I'm assuming that bringing in only the objects -- without
any of the re
Hi,
Recently Junio said he was willing to hear the opinion of other people
regarding the move from contrib to the core[1]. This move is already
under way, but suddenly Junio changed his mind.
I have repeatedly asked him to clarify what argument changed his mind,
but he hasn't done so. Hopefully h
When "git show -s" is called for merge commit it prints extra newline
between any merge commit and the next one. This looks especially ugly for
--oneline and other single-line formats. Looks very much like a bug.
The code in question exists since commit 3969cf7db1. Probably the
correct condition s
Junio C Hamano wrote:
> Felipe Contreras writes:
>
> > Junio C Hamano wrote:
> >> * fc/remote-helpers-hg-bzr-graduation (2014-04-29) 11 commits
> >> - remote-hg: trivial cleanups
> >> - remote-hg: make sure we omit multiple heads
> >> - git-remote-hg: use internal clone's hgrc
> >> - t: remot
On Sun, 2014-05-11 at 07:21 +0700, Duy Nguyen wrote:
> On Sun, May 11, 2014 at 1:38 AM, David Turner
> wrote:
> >> I got "warning: Watchman watch error: Got bad JSON from watchman
> >> get-sockname: '[' or '{' expected near end of file". Any ideas what I
> >> did wrong? I'm using watchman.git and
So, I've spent some time in the #git channel on Freenode chatting
about this, and we couldn't figure it out. I can't reproduce it in a
newly-made repository, but it's reproducible with the repository I've
been working in.
> git status
On branch Master
Your branch is ahead of 'ec/Master
> I addressed every issue reported constructively, every bug report was
> fixed, every patch reviewed and usually improved by me. I made sure
> users of older versions wouldn't be affected negatively when the marks
> file was upgraded, and I even setup automatic tests for different
> versions Bazaa
Junio C Hamano writes:
> Is making that decision as the maintainer unilateral?
Without addressing anything else, this point is vacuous. The whole
point of begin "maintainer" is that you are the one making the
decisions. Of course making a decision from the position of the one
making the decisi
Sitaram Chamarty writes:
> But what I was looking for was validation from git.git folks of the idea
> of replicating what "git clone -l" does, for an *existing* repo.
>
> For example, I'm assuming that bringing in only the objects -- without
> any of the refs pointing to them, making them all dan
Ævar Arnfjörð Bjarmason writes:
> Change the display of hunks in hunk splitting mode to preserve the diff
> heading, which hasn't been done ever since the hunk splitting was
> initially added in v1.4.4.2-270-g835b2ae.
>
> Splitting the first hunk of this patch will now result in:
>
> Stage t
Felipe Contreras writes:
> Junio C Hamano wrote:
>> * fc/remote-helpers-hg-bzr-graduation (2014-04-29) 11 commits
>> - remote-hg: trivial cleanups
>> - remote-hg: make sure we omit multiple heads
>> - git-remote-hg: use internal clone's hgrc
>> - t: remote-hg: split into setup test
>> - remo
Jeff King writes:
> On Tue, May 06, 2014 at 03:29:37PM -0700, Junio C Hamano wrote:
>
>> That's kind of W*A*T magic, and I generally try to avoid magic, as
>> long as it solves your "can we make both -O2 with new compilers and
>> -O3 happy?" I wouldn't complain ;-)
>
> I agree it's rather magical
Change the display of hunks in hunk splitting mode to preserve the diff
heading, which hasn't been done ever since the hunk splitting was
initially added in v1.4.4.2-270-g835b2ae.
Splitting the first hunk of this patch will now result in:
Stage this hunk [y,n,q,a,d,/,j,J,g,s,e,?]? s
Split
Junio C Hamano wrote:
> That's kind of W*A*T magic, and I generally try to avoid magic, as
> long as it solves your "can we make both -O2 with new compilers and
> -O3 happy?" I wouldn't complain ;-)
In case anybody is looking for a non-hacky way of doing this that
doesn't depend on the gcc version
17 matches
Mail list logo
