Re: Stacked GIT 0.1 (a.k.a. quilt for git)

Hi Paul,

Thanks for trying it. As a note, for the moment you should try the
latest daily snapshot since it contains less bugs than the main
(alpha) releases.

Paul Jackson <pj@sgi.com> wrote:
>  1) "Unknown" is misspelled as "Unkown" in a couple places.

Thanks.

>     Before invoking an editor, it would be a good idea to tell the
>     user you are doing so.  If someone is on a telnet session to
>     a system with their $DISPLAY set wrong, they might not even
>     get the terse "16" clue that I got, that they are editing
>     something.

Done.

>     I'd recommend ignoring the exit status of externally invoked
>     editors.

OK, fixed.

>  4) I tried rerunning that "stg init" without further ado, and it
>     failed again (due to the incomplete init above, no doubt), with:
>
[...]
> 	AttributeError: 'NoneType' object has no attribute
> 	'startswith'

The problem here is that the .git/HEAD link is not valid if init
failed. I will fix it for the tonight's snapshot.

>  5) I tried again, doing:
>
> 	rm -fr .git
> 	stg init
> 	# on the commit message edit - just quit 'q', to avoid any error exit
>
>     This failed again, leaving my new git tree in god only knows what bogus state.
>     It failed with:
>
> 	stg init: Commit message not modified

I can remove this condition for init only. The problem is that if it
no longer exists on an non-zero editor exit status, it should at least
check whether the commit message was modified.

>     Try generating fewer fatal errors, and try giving a tiny clue
>     what state (ok or not or how bad) one is left in after an
>     apparently fatal error, and for extra credit, a clue what to do
>     next.

I will try to add as much as information as possible. I initially
wanted to get something working and be able to push/pop patches. I
haven't tried the init command with different editors etc.

>  6) Ok - got through the init that time.

Good.

> Since I am fond of both quilt and Python, and since I need to be
> using git and/or cogito,
> I will poke around some more with this - it's promising.

Great. Pushing/popping works fine at the moment with my kernel tree
(but with less than 10 patches on the stack). It even detected when
the patches I submitted were merged upstream.

The next thing on my plan a log command. I would like to be able to
preserve the history of a patch but this probably won't be available
in an upstream tree pulling from yours.

> I see something about a patch emailer on the todo list -- you're
> welcome to make use of my patch emailer (I use with quilt, though
> it's not tightly bound to quilt) at:
>
>   http://www.speakeasy.org/~pj99/sgi/sendpatchset

Thanks. I will try to include this in a future version.

-- 
Catalin

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