Re: [StGIT PATCH] Don't use patches/<branch>/current

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 15/05/07, Karl Hasselström <kha@xxxxxxxxxxx> wrote:
On 2007-05-15 16:56:33 +0100, Catalin Marinas wrote:

> On 06/05/07, Karl Hasselström <kha@xxxxxxxxxxx> wrote:
>
> > The name of the current patch, if any, is always the last line of
> > patches/<branch>/applied (and there is no current patch if and
> > only if the "applied" file is empty). So use that instead, and
> > stop having to worry about keeping the redundant "current" file
> > up-to-date.
>
> I applied this patch. Could you also send me a patch for the
> bash-completion script as it uses this file?

I realized this myself yesterday or so, and patched it to not need the
current, applied, and unapplied files. Are you OK with that patch, or
would you like one that keeps using {,un}applied?

What is the impact on the bash completion for calling StGIT rather
than reading those files? Is it visible? If I integrate the DAG
patches, there probably isn't other way anyway.

> I think the self.__current_file (same for the base file removed in a
> different patch) should still be available in the Series object and
> removed when deleting a branch, otherwise you get a "Series
> directory ... is not empty" exception.

Ah, very true. I'll whip up a fix.

Same question there: are you OK with a single fix for base, current,
applied, and unapplied, or do you want them separate?

Whatever is easier for you :-), I don't have any preference.

I'll push the patches I integrated in the next hour or so and you can
base your changes on them.

Thanks.

--
Catalin
-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]

  Powered by Linux