From: Junio C Hamano <junkio@cox.net>
To: git@vger.kernel.org
Subject: [4/4] What's not in 1.5.2 (other bits and pieces)
Date: Wed, 16 May 2007 15:47:16 -0700 [thread overview]
Message-ID: <11793556383977-git-send-email-junkio@cox.net> (raw)
In-Reply-To: <11793556363795-git-send-email-junkio@cox.net>
Here are the leftover pieces I have in todo:TODO file that I did
not mention in the earlier messages. I left them out from the
third message of this series, as (1) some are more of "trivial
fix" category, and (2) others are heavier and would probably not
fit for a single release cycle such as 1.5.3.
The easier ones
---------------
* parse-remote.sh has POSIXLY incorrect shell construct.
Message-ID: <20070505080313.GA12170@gondor.apana.org.au>
* Use 'git diff' not 'git diff-tree' in merge and rebase
From: James Bowes <jbowes@dangerouslyinc.com>
Message-ID: <1178398134288-git-send-email-jbowes@dangerouslyinc.com>
* gitk --left-right
From: Linus Torvalds <torvalds@linux-foundation.org>
Message-ID: <alpine.LFD.0.98.0705051524300.17381@woody.linux-foundation.org>
From: Junio C Hamano <junkio@cox.net>
Message-ID: <7vabwifl23.fsf@assigned-by-dhcp.cox.net>
* Handling pushing into non-bare repository more gracefully.
When git-push is done to a non-bare repository and updates the
branch that is currently checked out, we currently do not do
anything special.
From: Linus Torvalds <torvalds@linux-foundation.org>
Message-ID: <Pine.LNX.4.64.0704160931550.5473@woody.linux-foundation.org>
* git-daemon bug?
From: Franck Bui-Huu <vagabon.xyz@gmail.com>
Message-ID: <450EABD0.1040102@innova-card.com>
Repeated requests against git-daemon makes it stuck under --syslog
[jc: does not reproduce easily for me; has anybody seen it?]
* AsciiDoc 8 would break our documentation.
From: Stefan Richter <stefanr@s5r6.in-berlin.de>
Message-ID: <4523EC14.6070806@s5r6.in-berlin.de>
AsciiDoc 8 does not grok documents written for AsciiDoc 7 out of
the box.
[jc: limbo?]
* Delegate gitweb part to somebody else.
* Use gitattributes for more things.
- 'precious' files that are not tracked but not
build-products. Currently people seem to put them in
.gitignore, but that is not quite right, as .gitignore is
meant for ignoring things that can be lost (build products,
editor backup files). "git clean -x" and "git checkout" to
another branch that has a file where the current branch has a
directory could lose such 'precious' files.
- Customized "diff -p" markers per path (Johannes, on #git
2007-04-30).
I think it makes sense to give an extra parameter to xdiff
machinery to affect how "diff -p" markers are constructed (as
opposed to teach xdiff machinery to read gitattributes -- the
code does not have path information at that level). The
simplest interface would be to pass a regexp and have the
existing code always look for that regexp backwards. A more
complex one would involve a callback function, but I do not
know if that kind of complexity is worth it.
- Others???
* upload-pack support for start fetching from any valid point on
the history, not just published refs. (Erik W. Biederman
<m164jc9ekx.fsf@ebiederm.dsl.xmission.com>)
* Give --stdin to git-log, similar to git-rev-list
From: "Marco Costalba" <mcostalba@gmail.com>
Message-ID: <e5bfff550705110413q28aef3d8k3aeb0d342eeb2016@mail.gmail.com>
* Update the lockfile protocol so that closing and renaming are
done inside lockfile commit time. Some filesystems do not
like an open file renamed and then closed. Come up with a
patch and pass Alex for an Ack.
Probably not so important ones
------------------------------
* daemon --strict-symlink.
* Maybe grok PGP signed text/plain in applymbox as well.
* Mbx (not mbox) support for git-mailsplit.
* git-proxy should be spawned with sh -c 'command' $1 $2.
[jc: should it? -- deciding if it should may not be "trivial",
but if it turns out to be the right thing to do, the change
itself is trivial.]
* Maybe a true git-proxy command that reads the first request
pkt-line, and redirects the request to its real destination.
* test scripts for the relative directory path stuff.
The heavier ones
----------------
* Use blame machinery to track a single file (not path) in a finer
grained way.
From: Linus Torvalds <torvalds@linux-foundation.org>
Message-ID: <alpine.LFD.0.98.0704201554550.9964@woody.linux-foundation.org>
[jc: I have a fixed-up one parked in 'pu' and also outlined what
other things I think are needed in my response:
Message-ID: <7vwt06wqv8.fsf@assigned-by-dhcp.cox.net>
]
* "git fetch" should be able to use foreign SCM import backends
such as svnimport and cvsimport.
* git-clone fails .git/refs/foo (Yann Dirson <ydirson@altern.org>)
<20060610225040.GA7766@nowhere.earth>
prev parent reply other threads:[~2007-05-16 22:47 UTC|newest]
Thread overview: 55+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-05-16 22:47 [0/4] What's not in 1.5.2 (overview) Junio C Hamano
2007-05-16 22:47 ` [1/4] What's not in 1.5.2 (have been cooking in next) Junio C Hamano
2007-05-16 22:47 ` [2/4] What's not in 1.5.2 (will cook " Junio C Hamano
2007-05-16 22:47 ` [3/4] What's not in 1.5.2 (new topics) Junio C Hamano
2007-05-17 4:39 ` Andy Parkins
2007-05-17 5:21 ` Junio C Hamano
2007-05-17 7:51 ` Andy Parkins
2007-05-17 11:02 ` Alex Riesen
2007-05-17 12:46 ` Petr Baudis
2007-05-17 13:46 ` Jeff King
2007-05-17 16:10 ` Petr Baudis
2007-05-17 16:25 ` Jeff King
2007-05-17 17:30 ` Petr Baudis
2007-05-17 17:35 ` Jeff King
2007-05-17 18:49 ` Junio C Hamano
2007-05-18 12:58 ` Jeff King
2007-05-17 18:47 ` Junio C Hamano
2007-05-17 13:45 ` Nicolas Pitre
2007-05-17 21:58 ` Michael S. Tsirkin
2007-05-17 23:41 ` Josef Weidendorfer
2007-05-18 0:32 ` Steven Grimm
2007-05-18 4:50 ` Petr Baudis
2007-05-18 9:18 ` Josef Weidendorfer
2007-05-19 0:56 ` Torgil Svensson
2007-05-18 12:00 ` Jakub Narebski
2007-05-18 12:41 ` Petr Baudis
2007-05-19 16:38 ` Jakub Narebski
2007-05-18 18:37 ` Junio C Hamano
2007-05-18 18:40 ` Julian Phillips
2007-05-18 18:45 ` Junio C Hamano
2007-05-20 0:16 ` Petr Baudis
2007-05-25 9:55 ` News reader woes (was: Re: [3/4] What's not in 1.5.2 (new topics)) Jakub Narebski
2007-05-18 7:57 ` [3/4] What's not in 1.5.2 (new topics) Andy Parkins
2007-05-18 8:43 ` Josef Weidendorfer
2007-05-18 9:21 ` Andy Parkins
2007-05-18 11:08 ` Michael S. Tsirkin
2007-05-18 12:27 ` Josef Weidendorfer
2007-05-18 12:46 ` Michael S. Tsirkin
2007-05-18 15:06 ` Aidan Van Dyk
2007-05-18 15:31 ` Michael S. Tsirkin
2007-05-19 12:50 ` Sven Verdoolaege
2007-05-21 1:10 ` Jakub Narebski
2007-05-18 17:00 ` Junio C Hamano
2007-05-19 18:12 ` Michael S. Tsirkin
2007-05-19 19:56 ` Junio C Hamano
2007-05-18 8:57 ` Michael S. Tsirkin
2007-05-18 9:40 ` Andy Parkins
2007-05-18 10:16 ` Johannes Sixt
2007-05-18 11:22 ` Michael S. Tsirkin
2007-05-18 12:36 ` Andy Parkins
2007-05-19 1:02 ` Steven Grimm
2007-05-19 16:55 ` Josef Weidendorfer
[not found] ` <200705181524.40705.Josef.Weidendorfer@gmx.de>
[not found] ` <20070518133922.GK4708@mellanox.co.il>
[not found] ` <200705181751.15435.Josef.Weidendorfer@gmx.de>
2007-05-18 16:08 ` Petr Baudis
2007-05-18 16:21 ` Michael S. Tsirkin
2007-05-16 22:47 ` Junio C Hamano [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=11793556383977-git-send-email-junkio@cox.net \
--to=junkio@cox.net \
--cc=git@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.