Bazaar Version Control System Forked As Breezy

[rastersoft]

Good that someone has stepped up to take care of Bazaar, which is still my favorite VCS. I can't stand the strange workflow of git.

Seriously? I used bazaar for one project in an old job, and it was horrible: extremely slow with big files, mainly. But I even tried to use it in what it was what I saw "the logic way of using a VCS" and tried to do several branches... I don't remember how many time did it need for each one, but it was much more that 15 minutes... absurd.

[rastersoft]

I can't stand the strange workflow of git, the constant adding of files (all other VCSes add files if they are new, then it's not necessary to add them again with each commit).

BTW: just using "git commit -a" sends all changes without having to do a "git add XXX" before, working like other VCSes. The idea when no using -a is to allow the user to commit only some of the files.

Also, if you modified a file and just want to revert it to its state in the repository: "git checkout FILE"

I don't see the differences, seriously.

[Cyber Killer]

If git did that by default, I'd not be using git! That would be insanely inconvenient for anyone used to working on several change sets simultaneously.
If I have a small UI change and then decide I want to fix a bug someplace else, I don't want my UI changes automatically added to the commit flow for the bugfix!

That is what branches are for. One changeset, one branch. I work this way and it's super annoying having to add files all the time with each commit (I also do a lot of commits, because I like atomic changes, for bigger I use merges from my working branch).

I'm not a developer, I'm a sysadmin plus I make some small dev projects, usually for myself. I need an easy to use tool, I like the command syntax that Subversion uses, Bazaar and Mercurial have a very similar one. My workflow is make a new branch, do some changes in a few commits, merge the branch. The only advanced thing I need are tools to easily reverse unwanted changes.

Huh? git reset --hard <targetSHA> is fairly straightforward. Or use git revert for documented reverts.
git reflog even gives you the power to do reverts in both directions (i e reverting a revert)

What do you mean by cleanup? Removing untracked files in the working tree? That's what git clean is for. git clean -fd takes care of all your troubles.
git gc helps you prune your repository.

Remove all untracked files from the working tree, git reset --hard doesn't do that, git clean doesn't do anything at all, a total fuckup goes when you do a pull by mistake from a different branch and want to reverse that. I usually end up with deleting the whole tree and doing a fresh clone and manually making my changes again.

I didn't bother reading any books about git, I didn't choose to use it at work. I expect the VCS to work in the usual way that VCSes work.

Ummm. What? git probably got more GUI tools than any other VCS, including ports of SVN and Mercurial tools. Surely there's one good enough for you (NVM that the terminal is far more efficient)

More does not mean they're comfortable to use. No git tool that I found makes use of any nice looking graphical diff like Kompare, not to mention nearly all of them are written in ugly gtk or wxwidgets. Bazaar has only 1 gui tool - Explorer and it easily tops all git tools combined,

[unixfan2001]

That is what branches are for. One changeset, one branch. I work this way and it's super annoying having to add files all the time with each commit (I also do a lot of commits, because I like atomic changes, for bigger I use merges from my working branch).

I'm not a developer, I'm a sysadmin plus I make some small dev projects, usually for myself. I need an easy to use tool, I like the command syntax that Subversion uses, Bazaar and Mercurial have a very similar one. My workflow is make a new branch, do some changes in a few commits, merge the branch. The only advanced thing I need are tools to easily reverse unwanted changes.

Well. As a non-developer, you're obviously not aware of a typical development workflow then.
If I'm trying out things or working on multiple bugs simultaneously, I don't want to constantly switch branches or stash my code.

Ditto for multi-commit solutions. If, for some reason, I want to split a solution into multiple commits, I don't want to be forced to commit the first change prior to working on the second (say, for example, a change set containing a WSDL update, a View change and changes in the View Model. Neatly split into two or three separate commits).

Remove all untracked files from the working tree, git reset --hard doesn't do that,

Of course not. git reset --hard isn't the right tool to remove untracked files. It's mainly used to revert local commits. Or, on rare occasions, remote commits (via git push -f)

git clean doesn't do anything at all,

In that case your copy of git must be broken. git clean -fd conveniently removes all untracked files for me.

a total fuckup goes when you do a pull by mistake from a different branch and want to reverse that. I usually end up with deleting the whole tree and doing a fresh clone and manually making my changes again.

git reflog provides you with a complete history of prior interactions with your repository. Pick a SHA or the HEAD@ prior to the pull operation and apply with git reset --hard <SHA/HEAD>

I didn't bother reading any books about git, I didn't choose to use it at work. I expect the VCS to work in the usual way that VCSes work.

Yea. I figured you weren't doing your proper homework. For some reason today's sysadmins aren't much more educated or diligent than your average layman.

No offense. But all of this sounds like a bad craftsman blaming his perfectly capable tools.

More does not mean they're comfortable to use. No git tool that I found makes use of any nice looking graphical diff like Kompare, not to mention nearly all of them are written in ugly gtk or wxwidgets. Bazaar has only 1 gui tool - Explorer and it easily tops all git tools combined,

git difftool and gitk are both right integrated into the git distribution. Both of these are perfectly capable of providing you with a simple, informational GUI. If that's what you're after.
That being said, most developers choose to either run a diff directly on the terminal or they're using the git diff capabilities integrated right into their favorite editor/IDE.

There are also plenty of good looking, full featured git GUIs that aren't written in GTK or wxwidgets. Like SourceTree, Github Desktop or GitKraken.
And, again, most developers will just use plugins for their favorite editor/IDE.

[Cyber Killer]

Yea. I figured you weren't doing your proper homework. For some reason today's sysadmins aren't much more educated or diligent than your average layman.

No offense. But all of this sounds like a bad craftsman blaming his perfectly capable tools.

Funny thing, I could say exactly the same thing about developers...

I can write ~5 programming languages, I probably cannot name all the tools that I used through my career, and I take time to educate myself on Terraform, Docker, Puppet, OpenStack and a thousand other tools, I can't know everything.

Anyway, svn, bzr and hg work similarly, yet for some uncomprehensible reason Linus decided to make git work differently and due to popularity waterfall, git became used all around. I don't like it (because it's needlessly different than what I used for the last decade) and I don't intend to use it if I don't have to. The problem is I have to, because of git's popularity. The only thing I can do is use another VCS in my own projects, for this I use Bazaar.

[unixfan2001]

Funny thing, I could say exactly the same thing about developers...

I can write ~5 programming languages, I probably cannot name all the tools that I used through my career, and I take time to educate myself on Terraform, Docker, Puppet, OpenStack and a thousand other tools, I can't know everything.

Anyway, svn, bzr and hg work similarly, yet for some uncomprehensible reason Linus decided to make git work differently and due to popularity waterfall, git became used all around. I don't like it (because it's needlessly different than what I used for the last decade) and I don't intend to use it if I don't have to. The problem is I have to, because of git's popularity. The only thing I can do is use another VCS in my own projects, for this I use Bazaar.

And yet somehow Fullstack Developers like me are supposed to do exactly that. Know everything. Funny how that works.

Git is popular because it's actually fairly easy and efficient, once you're used to it. It's a far cry from the clusterfuck that is SVN (and that's coming from someone who used to be very critical of git early on and somewhat of an SVN guru for a long while).

I really don't have too much experience with Mercurial. But if mozilla-central is any testament to its supposed qualities, I'm glad I don't have to use it.

[Delgarde]

If git did that by default, I'd not be using git! That would be insanely inconvenient for anyone used to working on several change sets simultaneously.
If I have a small UI change and then decide I want to fix a bug someplace else, I don't want my UI changes automatically added to the commit flow for the bugfix!

Agreed. I know some people hate the idea of having separate stage and commit steps, but I find it immensely useful. It's extremely common for me to make a bunch of changes to several files – some of which are ready to push, some of which aren't – taking advantage of the ability to stage *partial* changes from those files, then commit them while leaving the unstaged changes local. Very, very useful.

[Delgarde]

Anyway, svn, bzr and hg work similarly, yet for some uncomprehensible reason Linus decided to make git work differently and due to popularity waterfall, git became used all around. I don't like it (because it's needlessly different than what I used for the last decade) and I don't intend to use it if I don't have to. The problem is I have to, because of git's popularity. The only thing I can do is use another VCS in my own projects, for this I use Bazaar.

Eh, if you pick the right subset of tools, then yes, they do work similarly. But I assure you, finding three different VCS tools that all work similarly is the exception rather than the rule... you should try using Clearcase, and see how long it takes before you're bashing your head against a wall. My workplace used it for a good decade, and the nightmares don't fade quickly...

[Delgarde]

Git is popular because it's actually fairly easy and efficient, once you're used to it. It's a far cry from the clusterfuck that is SVN (and that's coming from someone who used to be very critical of git early on and somewhat of an SVN guru for a long while).

Emphasis on those words. It's a great tool, but it does have a challenging learning curve... the basics aren't too bad, but if you want to be productive with it, you do need to be prepared to do some reading, and some of the commands are a bit quirky (Linus is a great engineer, but he's terrible at UX).

[unixfan2001]

Emphasis on those words. It's a great tool, but it does have a challenging learning curve... the basics aren't too bad, but if you want to be productive with it, you do need to be prepared to do some reading, and some of the commands are a bit quirky (Linus is a great engineer, but he's terrible at UX).

Thankfully the great engineering allows for easy customization/extension.