Breezy 2019 summer sprint report

[Jelmer Vernooij]

On Sun, Sep 08, 2019 at 01:17:02PM +0100, Sam Bull wrote:
> 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.
I think the UI differences are bigger than just nicer log messages...

> 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).
Unfortunately it's not as simple as that - the brz-git format that you
suggest would perhaps work for shared repositories, but there are many
other bzr-specific features that it could not support, such as
multiple authors per commit, rename tracking or bug tracking.

For these features, you want the Bazaar format - they can not be
represented in Git.

> 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.
In this case, you just want to use the git format.

> 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.
It allows you to mix and match git and brz commands - I use it like
this all the time, and don't see why it should be considered
dangerous.

Jelmer

-- 
Jelmer Vernooij <jelmer at jelmer.uk>
PGP Key: https://www.jelmer.uk/D729A457.asc