Bug#894997: [PATCH] git-svn: avoid warning on undef readline()

Eric Wong writes: > Ævar Arnfjörð Bjarmason wrote: >> See https://public-inbox.org/git/86h8oobl36@phe.ftfl.ca/ for the >> original report. > > Thanks for taking a look at this. Also https://bugs.debian.org/894997 > >> --- a/perl/Git.pm >> +++ b/perl/Git.pm

Bug#842477: [PATCH] git-sh-setup: Restore sourcability from outside scripts

Ævar Arnfjörð Bjarmason writes: (commenting out of order) > It's probably worthwhile to split off git-sh-setup into git-sh-setup & > git-sh-setup-internal along with a documentation fix. A lot of what > it's doing (e.g. git_broken_path_fix(), and adding a die() function) > is

Bug#842477: [PATCH] git-sh-setup: Restore sourcability from outside scripts

Anders Kaseorg writes: > v2.10.0-rc0~45^2~2 “i18n: git-sh-setup.sh: mark strings for > translation” broke outside scripts such as guilt that source > git-sh-setup as described in the documentation: > > $ . "$(git --exec-path)/git-sh-setup" > sh: 6: .: git-sh-i18n: not found > >

Bug#434599: [PATCH] git-imap-send: use libcurl for implementation

Bernhard Reiter ock...@raz.or.at writes: Resending this once more, as indicated by xmqqbnp4hu8g@gitster.dls.corp.google.com Hope my formatting and posting style is now conformant. Sorry for the noise. Thanks. The patch does not apply for me (please send a trial message to yourself and

Bug#434599: [PATCH/RFC] git-imap-send: use libcurl for implementation

Bernhard Reiter ock...@raz.or.at writes: Am 2014-08-17 um 20:42 schrieb Jeff King: [...] I'm not sure I understand this comment. Even if SSL is not in use, wouldn't we be passing a regular pipe to curl, which would break? Yeah, we can't do that, and thus would have to keep the handwritten

Bug#757297: 'git status' output is confusing after 'git add -N'

Duy Nguyen pclo...@gmail.com writes: On Thu, Aug 7, 2014 at 7:34 AM, Jonathan Nieder jrnie...@gmail.com wrote: Package: git Version: 1:2.0.0-1 Tags: upstream $ git init foo Initialized empty Git repository in /tmp/t/foo/.git/ $ cd foo $ echo hi README $ git add -N README $

Bug#727226: [PATCH] cvsserver: Determinize output to combat Perl 5.18 hash randomization

Anders Kaseorg ande...@mit.edu writes: Perl 5.18 randomizes the seed used by its hash function, so iterating through hashes results in different orders from run to run: http://perldoc.perl.org/perl5180delta.html#Hash-overhaul This usually broke t9400 (gitcvs.dbname, gitcvs.ext.dbname, when

Bug#666250: [PATCH] Documentation: replace 'vi' for 'editor' to reflect build-time option

Rodrigo Silva li...@rodrigosilva.com writes: At 23:16 29/3/2012, Junio C Hamano wrote: ... I've already rejected this patch once, but that was primarily because the patch was not justified with the above I read everybody else's git uses 'vi' on the Interweb, and even though my distro's manual

Bug#575917: [long] worktree setup cases

Nguyen Thai Ngoc Duy pclo...@gmail.com writes: Assumptions: 1. When .git is a file and contains a relative path, I assume it is relative to .git file's parent directory. read_gitfile_gently() function will make the path absolute, but it depends on (maybe wrong) cwd. Ok. I agree

Bug#554682: [PATCH 2/8] bundle: use libified rev-list --boundary

Jonathan Nieder jrnie...@gmail.com writes: The revision walker produces structured output, which should be a little easier to work with than the text from rev-list. Hmm, doesn't it negatively affect later traversal you would need to do if you smudged the flag bits by running revision traversal

Bug#554682: [PATCH 3/8] bundle: give list_prerequisites() loop body its own function

Jonathan Nieder jrnie...@gmail.com writes: No functional change intended. Signed-off-by: Jonathan Nieder jrnie...@gmail.com --- bundle.c | 57 +++-- 1 files changed, 31 insertions(+), 26 deletions(-) diff --git a/bundle.c b/bundle.c

Bug#578764: 'commit -a' safety

Petr Baudis pa...@suse.cz writes: On Sat, Apr 24, 2010 at 01:10:24PM +0200, Wincent Colaiuta wrote: El 24/04/2010, a las 11:40, Jakub Narebski escribió: I'd like for 'git commit -a' to *fail* if there are staged changes for tracked files, excluding added, removed and renamed files. Thanks

Bug#578764: Please default to 'commit -a' when no changes were added

Goswin von Brederlow goswin-...@web.de writes: But you are already rejecting it in the design phase before there even is a patch. We do review both the design and the implementation on this list, and it actually is a *good* thing if a proposal is rejected when its design is flawed at the

Bug#578764: Please default to 'commit -a' when no changes were added

Goswin von Brederlow goswin-...@web.de writes: Exact. It is therefore not progress to impose some inconvenience to one work flow in order to make another one easier. And in this case we're talking about the difference between having to type an additional -a vs the risk of creating a

Bug#462557: [PATCH] Let 'git command -h' show usage without a git dir

Jonathan Nieder jrnie...@gmail.com writes: diff --git a/git.c b/git.c index bd2c5fe..bfa9518 100644 --- a/git.c +++ b/git.c @@ -220,6 +220,11 @@ const char git_version_string[] = GIT_VERSION; * RUN_SETUP for reading from the configuration file. */ #define NEED_WORK_TREE (12)

Bug#553296: gitignore broken completely

Jeff King p...@peff.net writes: On Fri, Oct 30, 2009 at 02:41:55PM -0400, Jeff King wrote: 6. Revert the patch and rework it so that it will only have effect if there is no -i option on the command line. (That is similiar to a mix of 3 and 4.) Yeah, that would actually

Bug#553296: gitignore broken completely

Jeff King p...@peff.net writes: I am not sure simply reverting is the best choice; the patch does do something useful. And while it strictly breaks backwards compatibility on the output without -i, the old behavior was considered a bug. But the -i behavior is useless now, so we need to figure

Bug#553296: gitignore broken completely

Jeff King p...@peff.net writes: On Fri, Oct 30, 2009 at 12:41:27PM -0700, Junio C Hamano wrote: I've never understood the use of ls-files -i without -o, so in that sense, I have done 2. myself already long time ago. In other words, I do not really care that much, and the choice would

Bug#469250: Commit f5bbc322 to git broke pre-commit hooks which read stdin

Johannes Schindelin [EMAIL PROTECTED] writes: Hi, On Tue, 4 Mar 2008, David Bremner wrote: It looks like line 435 of builtin-commit.c disables stdin for hooks (with the disclaimer that I first looked at the git source ten minutes ago). hook.no_stdin = 1 I'm not sure if this

Bug#469250: Commit f5bbc322 to git broke pre-commit hooks which read stdin

Johannes Sixt [EMAIL PROTECTED] writes: It is not metastore. It is an interactive hook that reads from the user who is sitting on the terminal and invoked the git-commit program. Are you saying stdin should not be directed to /dev/null, or that an interactive hook is required to do

Bug#427078: [PATCH] Create a new manpage for the gitignore format, and reference it elsewhere

Josh Triplett [EMAIL PROTECTED] writes: Thanks, but shouldn't all the in-text mention of gitignore(5) and friends, not just in See Also section, use gitlink:gitignore[5] instead? -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Bug#386495: git-apply fails to apply some patches

Gerrit Pape [EMAIL PROTECTED] writes: ... On top of that, I try to apply this interdiff generated patch: diff -u pciutils-2.1.11/debian/dirs pciutils-2.1.11/debian/dirs --- pciutils-2.1.11/debian/dirs +++ pciutils-2.1.11/debian/dirs @@ -6,0 +7 @@ +var/lib/pciutils and git-apply says:

Bug#386495: [PATCH] apply --unidiff-zero: loosen sanity checks for --unidiff=0 patches

with is a patch without context, this flag may come handy as the last resort. Signed-off-by: Junio C Hamano [EMAIL PROTECTED] --- builtin-apply.c | 112 +++- t/t3403-rebase-skip.sh|4 +- t/t4104-apply-boundary.sh | 115