Control: fixed -1 4.1
Control: tag -1 - fixed 4.1
Control: close -1
Hopefully this will actually close this bug...
--
Ian JacksonThese opinions are my own.
If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.
Control: tag -1 fixed 4.1
Sam Hartman writes ("Bug#871908: dgit fails to work when .git is a reference
not a directory"):
> I tested with dgit 4.1 and it worked well enough to dgit build-source.
> I did not check through a full push mostly because I don't have any
&
Hi.
I tested with dgit 4.1 and it worked well enough to dgit build-source.
I did not check through a full push mostly because I don't have any
packages to push ATM.
However if it works that well, I think it is conclusive.
Hi. I will check this later today once I finish catching up from
debconf at $dayjob.
That said:
1) I did already confirm that if you handle .git correctly, everything
else works. That is, I moved the git directory to be a directory,
changed .git/config to remove a no-longer-necessary override o
I have uploaded dgit 4.1 to experimental. Can you please try it and
let me know if it works better in this situation ? It is supposed to
have support for .git as a file pointing elsewhere.
Warning: I have not tested it in this case so it may go wrong. I have
tested it in the "git subtree" case.
Hello,
On Sun, Aug 13 2017, Ian Jackson wrote:
> Sean, if you felt like it you could take my chiark master
> (92667fc40d49284a19475b031f79eba6fc883548) finalise the changelog and
> upload it to experimental as 4.1.
I can't obtain your master over an authenticated channel, but I too lack
my key -
Control: retitle -1 possible further problem(s) when working _in_ a submodule
Sam Hartman writes ("Re: Bug#871908: dgit fails to work when .git is a
reference not a directory"):
> My case is different.
> I have a super-repository of a lot of related packages with each
> subm
> "Ian" == Ian Jackson writes:
That bug appears to be about a case where there are submodules in the
repository I give to dgit as input.
My case is different.
I have a super-repository of a lot of related packages with each
submodule corresponding to one complete Debian package.
It seems lik
Hello,
On Sat, Aug 12 2017, Sam Hartman wrote:
> If you git clone --recursive a project including submodules, you tend
> to get all the submodule git directories under .git/modules in the
> master git directory.
As a general rule dgit does not support submodules: #726953.
I think that this bug
Control: retitle -1 want better error reporting when there are submodules
dgit does not work with submodules. See #726953.
However,
Sam Hartman writes ("Bug#871908: dgit fails to work when .git is a reference
not a directory"):
> If you git clone --recursive a project includi
package: dgit
version: 3.12
If you git clone --recursive a project including submodules, you tend to
get all the submodule git directories under .git/modules in the master
git directory.
Then you get a .git file in the submodule working tree that looks a lot
like this:
hartmans@permutation-city:l
11 matches
Mail list logo
