Re: [PATCH 0/11] Misc. pull/merge/am improvements

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Junio C Hamano <junkio@xxxxxxx> wrote:
> Actually I am getting more greedy, and would not mind to have
> clean ups and a few more features in the new release, even the
> ones that we have talked about but have not implemented.

I know Linus wants me to fix the bash completion so it adds a trailing
space when something gets completed and is unique and no additional
text is expected to follow for that argument.  I just haven't put
the effort into it, even though I think I have a solution.

Basically I'm saying I probably could have another round of bash
completion in another week which may be worth considering for
inclusion.  ;-)
 
> I am very tempted to have sliding window mmap() if it helps
> people on cygwin, for example.

Especially now that NO_MMAP is the default on that platform.
At this point it may be ready to graduate to next to try and get a
wider audience.  Since fixing that segfault in pack-objects I can't
break it.  Of course I couldn't break it before you found that error,
so take my words with a grain of salt... ;-)

> Also, I've been running with
> "next" for my daily pushes and pulls without trouble, and I am
> very tempted to push out the shallow-clone topic.

Hasn't that been in next for a while now?  I pretty much always
run next, and have also been using it on that non-publishable
repository for almost two months now.  I've got 20 other users who I
collaborate with on cygwin running next... we haven't had any issue
with the portions of shallow-clone which had already moved in, and
I upgrade that environment almost daily to keep current.  Of course
we also haven't tried to actually use the shallow-clone feature as
we haven't needed it (the repository is only 50 MiB packed).

> Although I do find the detached HEAD attractive and would want
> to have it eventually, I suspect that even if it materializes
> soon enough, it would at least need a couple of weeks of testing
> in 'next', so making -rc1 wait for it might push back the
> release a bit too much.

Agreed.  It would be nice to implement, expecially for a major
release like 1.5.0.  I don't think its that difficult to do, we've
all just been distracted by other topics and nobody has put code
forward for it.  If a well-written implementation materialized in
the next few days it might get enough cooking time before rc1 to
include it.

-- 
Shawn.
-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]