Re: [QGIT RFC] Unit tests for QGit

[Jan Hudec <bulb@ucw.cz>]

On Thu, Aug 28, 2008 at 20:54:44 +0200, Marco Costalba wrote:
> On Thu, Aug 28, 2008 at 5:31 PM, Karl Hasselström <kha@treskal.com> wrote:
> > StGit has no per-repo data. It's all per-branch. "stg init" operates
> > on the current branch, not the whole repo.
> 
> Ok. Thanks. In this case the check qgit does is broken, and I think
> not only that because I never had this point clear while developing
> the interface.
> 
> > Hmm. For me, "stg branch" succeeds even if "stg init" has not yet been
> > run (which is arguably as it should be, since it doesn't require that
> > stg init has been run in the current branch). "stg series" or
> > something is probably better for this purpose.

That would indeed mean, that the check does not do what indented and would
show the same symptoms I recalled initially. Seems I can finally reproduce
them.

> But if I run 'stg branch' in a git-only repo this gives an error. This
> conditions, at least until now, has always been working for me.
> 
> 
> > Though if you're concerned about speed (as the comment indicates), you
> > should probably do something cheaper than running stg, such as
> > checking if .git/patches/<branchname> exists.
> >
> 
> Actually the actual code chunk is:
> 
>         // check for a StGIT stack
>          QDir d = gitDir;
> 
>          if (d.exists("patches")) { // early skip
> 
>                  isStGIT = run("stg branch", &stgCurBranch); // slow command
> 
>                  stgCurBranch = stgCurBranch.trimmed();
>          } else
>                  isStGIT = false;

Ook. Ook.

Now I actually wrote the test cases I am begining to understand why it
behaves the way it does. 

So, now there is a test infrastructure plus test case to reproduce this
switching between stgit and non-stgit branch in
git://repo.or.cz/qgit4/bulb.git (http://repo.or.cz/r/qgit4/bulb.git) with
whoping 9 commits. Should I send out a patch series, or do you prefer just
pulling?

Now in my opinion the code could use some refactoring rather than just fixing
the bugs (my long term intent is to add features like topgit support,
push/pull/merge and other things git-gui can do and such). I'd start with
the Git initialization sequence. I'll write tests for the new code, but as
I expect it to have significantly different interface from the old one, I'll
not try to write tests for the current one.

Best regards,
Jan

-- 
						 Jan 'Bulb' Hudec <bulb@ucw.cz>