Breezy 2019 summer sprint report

[Sam Bull]

On Sat, 2019-09-07 at 19:27 +0000, Jelmer Vernooij wrote:
> On Sat, Sep 07, 2019 at 02:09:08PM +0100, Sam Bull wrote:
> > On Sun, 2019-09-01 at 14:08 +0000, Jelmer Vernooij wrote:
> > > On Sun, Sep 01, 2019 at 09:26:20AM -0400, Aaron Bentley wrote:
> > > > But brz init-repo is documented to create a shared repository ("Create a
> > > > shared repository for branches to share storage space.").  If Git
> > > > doesn't
> > > > support shared repositories, I'd expect this to fail.  Possibly it
> > > > wouldn't
> > > > support --git at all.
> > > 
> > > So to be more precise: a Git repository supports multiple branches in
> > > a repository, just *only* colocated.
> > 
> > Is it infeasible to create a multi-directory approach? I'm not familiar with
> > the
> > implementation details, but I just imagined the .git directory contains all
> > the
> > data for a Git repo and wouldn't really limit the behaviour of the tool.
> > 	So, the .git directory would be in the repo folder, and then when you
> > branch it just checkouts the files into a subfolder. Then all the
> > status/diff/commit commands would work by comparing the files in the
> > subfolder
> > with the data in the parent .git directory for the given branch name.
> > 
> > If doing this, you'd probably want to rename .git to .brz-git or similar, to
> > ensure that the Git program doesn't try to operate on the repo (I don't see
> > any
> > real advantage in supporting both programs in the same local repo).
> 
> At that point it's no longer a Git repository, and you can't use the
> Git command-line tool on it; it seems you want to just use a Bazaar
> repository instead if you need to use shared repositories, rather than
> adding yet another repository format.

But, if you're ensuring compatibility with the Git program, then Breezy can only
offer minor tweaks over Git (basically nicer log and no staging area), which
loses much of it's appeal.

In my mind the ideal point is when I can create a local repository from Git that
I can use just like a Bazaar repository. At that point, people can freely use
Git or Breezy to work in whichever way they like without having to worry about
what the repo format is (i.e. the choice of repo shouldn't affect how people
choose to work, or what tool they must use).

My main concern, is that my projects are currently using the bzr format, but
this is a barrier for contributions from people that prefer to use Git. If brz
could use a Git repo just like it uses a bzr repo, then I could "upgrade" the
repo format to Git and still have the same advantages while also making it
easier for Git users to contribute. At this point you could stop maintaining the
bzr format as it would no longer have any advantage.

I just don't see any reason to make a local repo compatible with brz and git at
the same time. Adding a command to clone a normal git repo from a brz-git repo
locally should be enough for the cases when you do want to work with Git.
	I'm already unsure what might happen if I accidentally mix git and brz
commands just with the small differences that already exist. For example, if you
git add something to the staging area, and then brz commit x.py, does the
staging area get committed as well? I'm not even sure what the right answer
should be, allowing a mix of git and brz commands just seems dangerous.

Thanks,
Sam
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 195 bytes
Desc: This is a digitally signed message part
URL: <https://lists.ubuntu.com/archives/bazaar/attachments/20190908/9063d835/attachment.sig>