On Sun, Feb 11, 2007 at 04:15:36PM +0100, Guido Guenther wrote:
it seems there can be leftover (untracked) files after a rename that
happened during a recursive merge. Is this intentional? If so
git_load_dirs would have to call 'git-clean' explicitly after the merge
which looks strange (at
On Mon, Feb 12, 2007 at 08:34:02AM +, Gerrit Pape wrote:
Hi Guido, this sound much like #403104, so, yes, src/mpi.c should have
been removed. This has been fixed upstream already, but the fix won't
be in etch unfortunately, see
http://thread.gmane.org/gmane.comp.version-control.git/38617
reassign 410325 git-core
thanks
Dear git maintainer,
it seems there can be leftover (untracked) files after a rename that
happened during a recursive merge. Is this intentional? If so
git_load_dirs would have to call 'git-clean' explicitly after the merge
which looks strange (at least when
Package: git-buildpackage
Version: 0.2.25
Severity: normal
I ran git-import-orig on a new tarball. Since the last import in the git
tree, one file was deleted in the tarball. The file not present in
tarball is still present in both master and upstream branches.
Regards,
--
Arnaud Cornet
--
Hi Arnaud,
On Fri, Feb 09, 2007 at 08:41:55PM +0100, Arnaud Cornet wrote:
I ran git-import-orig on a new tarball. Since the last import in the git
tree, one file was deleted in the tarball. The file not present in
tarball is still present in both master and upstream branches.
Could you send me
Hi Guido,
On ven, fév 09, 2007 at 09:07:56 +0100, Guido Guenther wrote:
Could you send me the git repo and the tarball via private mail or an
URL to clone from to reproduce this? Removals do work fine here (tried
that with dozens of packages).
Actually I was a bit wrong in my bug: in the git
6 matches
Mail list logo