Bug#914695: dgit autopkgtest breaks with git 2.20
I fixed this via https://public-inbox.org/git/pull.91.git.gitgitgad...@gmail.com/T/#t and the latest word is that this will be part of v2.20.0-rc2 (which I would expect before Monday, maybe even tonight).
Bug#407722: status of libgit.a
Hi, On Sun, 7 Mar 2010, Paul Menzel wrote: Am Donnerstag, den 19.02.2009, 09:24 + schrieb Gerrit Pape: On Wed, Feb 18, 2009 at 09:10:02AM -0800, Marc Oscar Singer wrote: Gerrit Pape wrote: […] It depends on upstream. Back then, Junio asked to not provide such a library package in Debian, and I respect that. There've been some plans and effort to stabilize the lib in the past, but I'm not sure about the status. Would it be a compromise to provide libgit.a as a static library for until it stabilizes? That's not the compromise, that's the option, I don't know any plans about a shared library. The git-core-dev package that was available for short included such a static library. You really need to talk to upstream if you want this libgit.a. could you please give an update on the status of libgit.a. There had been some people who worked towards a re-entrant libgit.a (read: non-die()ing in library functions). But there were too many others, so that effort stopped. The most likely route for people needing libgit.a would be libgit2: http://git.wiki.kernel.org/index.php/SoC2010Ideas#Complete_libgit2 For example cgit still could not be packaged yet for Debian [1] because of this bug [2]. cgit should not depend on libgit.a, as it is linked statically anyway. Ciao, Dscho
Bug#554682: bug: git-bundle create foo --stdin - segfault
Hi, On Mon, 18 Jan 2010, Joey Hess wrote: j...@gnu:~/tmp/newecho master | git bundle create ../my.bundle --stdin zsh: segmentation fault git bundle create ../my.bundle --stdin Current 'next' fails, too. Some previous Git versions failed with a message like this: error: unrecognized argument: --stdin' Other previous Git versions failed at least with a message such as this: fatal: exec rev-list failed. error: rev-list died Something similar happens to me when I run the initial official revision of git-bundle. The reason is that git rev-list --boundary --pretty=oneline --stdin refuses to run. The bad versions either segfault, or refuse to create empty bundles. And while 8b3dce5 purports to clean things up (even acknowledging that support code for --stdin was removed from bundle.c!), at that time git-bundle was obviously not tested/fixed. Now, I invested a lot of time into the new Git wiki, and into trying to bisect this (it took many, many more steps than the suggested 13, and somewhere in between, the number of commits to be tested even increased!). If you want to fix it, I suggest requiring --stdin to be the only parameter after the bundle file name, and adding a function using strbuf_getline() to parse the stdin into a string_list. Once that is done, you can substitute the argv for the rev-list call with that list (for that, you need to prepopulate with rev-list, --boundary and --pretty=oneline). You can reuse that list for the call to setup_revisions(). Alternatively, you can try to implement the rev-list --boundary by hand (the --pretty=oneline is only needed to get a boundary marker IIRC), taking care to reset the commit flags that were set in the process. (We need to know the boundary commits before actually starting to write the pack, because the bundle file format dictates that the boundary commits are listed as prerequsites in the bundle header.) If you want to go that route (which is arguably more elegant anyway), I suggest having a look at the merge_bases() and get_merge_bases() functions in commit.c, which do something similar (i.e. a revwalk without using revision.c's functions -- because you cannot tell what flags they will use in the future, and they have to be reset after the walk). Ciao, Dscho -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#469250: Commit f5bbc322 to git broke pre-commit hooks which read stdin
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 was by design, but just so you know, this breaks people's hooks. In particular the default metastore pre-commit hook no longer works. I didn't find anything relevant in the docs [1]. Pardon my ignorance, but what business has metastore reading stdin? There should be nothing coming in, so the change you mentioned should be correct, and your hook relies on something it should not rely on. Ciao, Dscho -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#469250: Commit f5bbc322 to git broke pre-commit hooks which read stdin
Hi, On Tue, 4 Mar 2008, Jakub Narebski wrote: Johannes Schindelin [EMAIL PROTECTED] writes: 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 Never mind pre-commit. What about pre-receive and post-receive hooks, both of which gets data on stdin? He was talking about builtin-commit.c. AFAIR there is no code to call pre-receive or post-receive in that file. ;-) IOW the issue does not apply to the hooks you mentioned. Ciao, Dscho -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#417885: unexpected git-cherry-pick conflict
Hi, On Wed, 13 Jun 2007, Gerrit Pape wrote: $ mkdir repo cd repo $ git init Initialized empty Git repository in .git/ $ echo foo file $ ln -s dangling link $ git add . $ git commit -mfoo Created initial commit c6a9189: foo 2 files changed, 2 insertions(+), 0 deletions(-) create mode 100644 file create mode 12 link So, basically your master has a file and a symbolic link. $ git checkout -b branch Switched to a new branch branch $ git rm link rm 'link' $ git commit -mremovelink Created commit 2c60f15: removelink 1 files changed, 0 insertions(+), 1 deletions(-) delete mode 12 link Here, you remove the link from the branch. $ mkdir link $ echo bar link/file $ git add link $ git commit -m adddir Created commit d3b30b5: adddir 1 files changed, 1 insertions(+), 0 deletions(-) create mode 100644 link/file Here you added a directory of the same name as the symbolic link has in master. $ git checkout master Switched to branch master $ git cherry-pick 8ddc4d5 CONFLICT (file/directory): There is a directory with name link in 8ddc4d5... file. Added link as link~HEAD Here you _still_ have the file in master. So that conflict is really expected, since a cherry-pick will only do a three-way merge. I guess you want to use git-rebase instead. Ciao, Dscho -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#417885: unexpected git-cherry-pick conflict
Hi, On Wed, 13 Jun 2007, Gerrit Pape wrote: On Wed, Jun 13, 2007 at 01:58:51PM +0100, Johannes Schindelin wrote: On Wed, 13 Jun 2007, Gerrit Pape wrote: $ git checkout master Switched to branch master $ git cherry-pick 8ddc4d5 CONFLICT (file/directory): There is a directory with name link in 8ddc4d5... file. Added link as link~HEAD Here you _still_ have the file in master. So that conflict is really expected, since a cherry-pick will only do a three-way merge. git-cherry-pick(1) states Given one existing commit, apply the change the patch introduces, and record a new commit that records it. This requires your working tree to be clean (no modifications from the HEAD commit). The patch introduced by the commit that's cherry-pick'ed has nothing to do with the link or new directory, it just changes 'file' $ git show 8ddc4d5 commit 8ddc4d59444a362261e10a3b22324818f5dd2fa7 Author: Gerrit Pape [EMAIL PROTECTED] Date: Wed Jun 13 09:10:30 2007 + file diff --git a/file b/file index 257cc56..3bd1f0e 100644 --- a/file +++ b/file @@ -1 +1,2 @@ foo +bar $ The patch applies to master just fine. Where's my thinking wrong? Hmm. Indeed. Thanks for clearing that up. Will work on it later. Ciao, Dscho -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
