Git / DVCS workflows

[Solar]

I am in the process of writing some porcelain wrapper for git, to ease my hate-hate relationship with that noteworthy.

As I fully intend to release this to the public at some point, I'd ask those of you who use git, or some other DVCS, about...

What operations are essential to your DVCS workflow?

Git makes a whole lot of things possible, but this flexibility comes at a price of complexity. I'd like to reduce the complexity "as far as possible, but no further".

So far supported are the following operations:

Meta:

• Creating a new repository (init)
• Copying a repository (clone)

Informational:

• Showing who changed which line of code in a given file last (blame)
• Showing changes between working directory and HEAD (diff)
• Showing a log of commits, both on the repo as a whole and a given file / directory (log)
• Showing info on the current repo, including remote URL and available branches (info, new composite command)
• Showing status of the current repo, including unmerged commits, unpushed commits, and local changes (status, new composite command)

Local:

• Add files / directories to VCS (add)
• Move / rename files / directories in VCS (move)
• Remove files / directories from VCS (rm)
• Revert a file to its committed state (checkout)

Repository:

• Find commit introducing a change by binary search (bisect)
• Commit local changes to local repo (commit)
• Combine multiple local commits into one (squash, new composite command)
• Temporarily putting away local changes, reapplying them, removing them (stash)
• Undo a local commit (uncommit, new composite command replacing --amend)

Branches:

• Merge incoming commits to your current branch (merge)
• Create a local branch (branch)
• Re-base local commits to HEAD (rebase)
• Remove a local branch (branch -d)
• Switch to a different local branch (switch)

Remote:

• Publish local commits to remote repository (push)
• Get incoming commits from remote repository (fetch)

I'd like to hear what else a DVCS should be able to do.

To stress, this is not about providing everything, this is about providing everything you need in order to make a public beta viable. I am looking at reducing git's complexity, not emulating it -- but I would like to not be lacking essential features before going public.

Thank you in advance for your feedback.

[nullplan]

Well, honestly, it appears I am a bit old-fashioned, which is ironic considering my age, but anyway: What I usually need from a VCS is what SVN would offer if creating a new repository was a bit more expedient. So create, add/copy/remove, clone, branch, merge, tag, blame, diff, log, info. That gets me to the 80% mark. Very rarely I will need something as esoteric as rebase, but it does happen (and SVN has absolutely no support for it). Even the ability to have multiple remotes I don't need all that often. Hell, I have lots of repos on my disk right now that have no remote at all.

One thing I dislike about git is how it handles deleted branches, and since we are currently switching from SVN to Git at work, this is falling onto our feet hard. See, SVN is a versioned file system (or at least, that is what is presented as user interface), so if a branch is deleted, I can always ask for the state of the repository from before the deletion and look at the branch. I can still see what branches were outstanding at the time and what commits were made on that branch. And what the branch was called. In Git, however, once a branch is deleted, it is gone. The name might still be around in the reflog for a while, until that too is forgotten, and then the only evidence of the branch is the merge commit. There is no easy way to display all commits that were on the branch. It just becomes a mess. Maybe I'm using it wrong, but it appears we just have to leave old branches around.

[Korona]

There is an easy way to see what was on the branch: "git log <commit hash>^2" where the hash identifies the merge commit (for example "git log 1dcd1320d364a75e455fff0ef1b5ecfebdd10fb7^2"). ^2 selects the second parent of the merge commit (= the merged branch).

[Korona]

Regarding the OP's question: I regularly use "git commit --fixup" / "git rebase -i --autosquash" to prepare commit series before publishing them. Another common operation is "git apply" / "git am" to apply patches. "git reset" to move the branch pointer is also frequently used.

IMHO, git's naming and its overloads of various commands are pretty bad from a usability perspective, compare "git reset --hard" (which checks out files) vs. "git reset" (which moves the branch pointer)
Another thing that git gets wrong by default is that "git pull" merges into the current branch instead of rebasing. Merging on pull is fundamentally broken IMHO (unless you're pulling a PR into master). New git versions at least warn about this behavior.

[vvaltchev]

@Solar In addition to the features you mentioned, the interactive rebase (git rebase -i <commit>) is used a lot on local branched when working at open source projects, because people care a lot about the story behind a series of patches, not just about the current state of the code. So, being able to re-write the history by re-ordering commits, changing their description and commit-message is an important feature for many developers.

Also, it's imporant being able to resolve merge/rebase conflicts somehow. I believe the bisect feature is a must for me and many other people. The cherry-pick feature is also widely used. The support for tags is essential.

Finally, git format-patch and git am are extremely useful as well to export a series of patches (see the Linux kernel model).

One more (advanced) thing: the add-patch feature (git add -p) is useful to have a clearner history because it allows to stage only part of a file.

I hope this feedback will help you.

[Solar]

What I usually need from a VCS is what SVN would offer if creating a new repository was a bit more expedient.

Pretty exactly where I am coming from. I never really understood the hype about git, and especially not the trashtalking SVN got in the process -- SVN pretty much hit my sweet spot, and in some regards I am using it as inspiration for improvements (e.g. 'svn info', which git has no equivalent for at all, and 'svn blame' which is readable while 'git blame' is not).

...tag...

I am thinking hard about this one, and am currently considering to suggest using SVN's approach for tags instead of 'git tag': Just create an appropriately-named branch...

Even the ability to have multiple remotes I don't need all that often. Hell, I have lots of repos on my disk right now that have no remote at all.

I was wondering if that (multiple remotes) is a scenario people are actually using. Virtually all environments I've seen so far use a very classic approach with one single repo that everyone is cloning from and done with.

One thing I dislike about git is how it handles deleted branches...

Another bit of valuable advice. I positively despise the casual way in which git makes outright deletion of information possible, indeed part of its workflow. My idea for this wrapper is to allow for local modifications any which way, but once it's public, it's public, and should not be tampered with. That, to me, is the whole idea of version control: Always being able to walk back on the timeline.

Regarding the OP's question: I regularly use "git commit --fixup" / "git rebase -i --autosquash" to prepare commit series before publishing them.

I understand the desire to "fix up" commits locally before pushing. So far I offer two subcommands for that -- 'squash' to merge multiple (by default: all) local commits into one (done by 'reset --soft' and a recommit plus lots of sanity checks), and 'uncommit', which undoes a commit so you could re-do it correctly (a 'git reset --mixed' with sanity checks so you do not walk back into already published history.)

The idea here is to not add complex command line options and "magic commit messages" and whatnot, but work with simple and intuitive operations.

Would that float your boat, or is there something you'd be missing?

'apply' is something done just as well by 'patch'... but yes, I've been thinking about a 'mkpatch' / 'patch' command pair of some description. WIll think about that.

And yes, the naming and command overloading is part of what I abhor about git. Linus might have been looking for a powertool to maintain the kernel sources, but most people are looking for a tool that makes version control easy and then gets out of the bloody way.

Thanks for your input!

[Solar]

Also, it's imporant being able to resolve merge/rebase conflicts somehow.

I will add sanity checks to ensure that you cannot rebase a commit once it's published -- only your local (not-yet-published) commits. Actually I am thinking about making it the default behavior -- kind of like SVN does it: You cannot commit something not based on the head of the branch. But I am still working on the details there.

I believe the bisect feature is a must for me and many other people.

Already implemented.

The cherry-pick feature is also widely used. The support for tags is essential.

I really don't like either of them... but will have another look.

Finally, git format-patch and git am are extremely useful as well to export a series of patches (see the Linux kernel model).

The idea is to provide a tool for the developer, not the repo maintainer -- the latter will likely be used and well-versed in git anyway, and miss any features my wrapper won't provide. If I ever received a patch by mail, it was a couple of lines at best and easier edited in by hand than figuring out how my VCS might assist me in it. I think I'll pass on those.

One more (advanced) thing: the add-patch feature (git add -p) is useful to have a clearner history because it allows to stage only part of a file.

Yes... I like that feature in e.g. Git Fork... problem is, so far I've managed to make do without the index, removing it entirely from the workflow, which I considered a really nice win. I am somewhat reluctant to add it (and having to explain it in documentation) just for this feature.

Plus, it effectively means you are checking in a code version you have not tested in that form. Dislike...

I hope this feedback will help you.

Of course, thank you.

[Korona]

The idea here is to not add complex command line options and "magic commit messages" and whatnot, but work with simple and intuitive operations.

The magic commit messages are indeed quite hacky but I like the ability to modify commits further down (by more than one commit) in the history even if they are already published (e.g., to a branch for review; once stuff is on the main branch or a public feature branch, it should of course not be changed again).

Regarding the git/SVN debate here: for me it's exactly the other way around. I despise SVN every time I have to use it. With git I can reasonably work even without an internet connection or with an unstable connection (e.g., while flying or in a train). SVN makes it impossible to even read the repository properly without being online; it's need for locks is a mess, and it is overall quite slow (due to the fact that half of its operations connect to the server), to the point of disturbing one's workflow. I would take any DVCS over SVN these days.

[Solar]

Not allowing post-push modifications is pretty much set in stone for me, since it is basically impossible to tell what might be a breaking change and what not beyond that point.

It is also my biggest grievance with git. A VCS simply should not allow such operations through its enduser frontend.

[vvaltchev]

Not allowing post-push modifications is pretty much set in stone for me, since it is basically impossible to tell what might be a breaking change and what not beyond that point.

It is also my biggest grievance with git. A VCS simply should not allow such operations through its enduser frontend.

If I've understood correctly, you're stating that you're not OK to have a temporary/working remote branch and periodically force-push your changes there. I totally agree that for public branches force-pushes should not be allowed, but why not allow people to save local commits on a remote machine? People do it all the time, and nobody else's work is affected by that, because the branch is private.

If you disallow that, the workaround would be to create a new private remote branch everytime the history of the local branch is rewritten. OK, some companies working on closed-source software adopt the exact opposite of git's model: history can never be rewritten, no matter what. Only the final shape of the code matters. That makes people push larger patches remotely by squashing all the commits in the local git branches (yes, sometimes git is used locally even if the public server is something else like SVN or Perforce) and loosing the detailed history. But, for open source that practice is rarely accepted AFAIK.

[vvaltchev]

Plus, it effectively means you are checking in a code version you have not tested in that form. Dislike...

Totally agree on that. Creating the "perfect commit history" has a high price. It requires the developer to run tests on every single commit in the series after re-writing the history and yes, it's error-prone. For closed source projects, I'll probably go with the "untouchable commit history" model, while for open source it's tricky because there is a lot of value in having super-small and perfect commits when submitting a series for review. It works well for open source, because it kind of pushes more work down to the individual contributors, allowing the mantainers to scale more.

In conclusion, are you're targeting more open source or closed-source projects?

[nullplan]

I never really understood the hype about git, and especially not the trashtalking SVN got in the process

Well, one thing Git does better than SVN is merging. In Git, all that happens is that a commit with two parents is put into history. In SVN, all commits from the branch are squashed into a single merge commit in the merged branch. The effect is, when you've done that for a while, then blame any file, in Git the line will be blamed on the commit that actually changed it, and in SVN it will be blamed on the merge revision. So if you are on trunk/master, trying to understand why a certain line was added, then Git will provide the revision with that reason in the commit message (unless it isn't in the message, and then you punch the developer responsible), and in SVN you then have to look up the Repo-Browser in that revision and locate the branch and then blame the file again, and then find out the reason in the commit message. Yeah, I know, technically the merging developer should also know what that change was about, but the world doesn't always work that way.

I was wondering if that (multiple remotes) is a scenario people are actually using

I've used it once. At work, we are buying a component from a vendor in source code form. But that code requires changes. So I have a repo on my laptop that has the vendor's github and our gitlab as remotes, and I regularly pull the changes from github, review them and push them to gitlab. That way, we don't need to give every developer on our end access to the vendor's github, and we are in control of the stuff that is actually put into our software.

With SVN the only way would have been to sent source code tarballs and patch files back and forth.

[Solar]

@vvaltchev:

I am targeting the 90% of cases which, to my experience and that of a sizeable number of colleagues I have spoken with so far, are not considering the kind of detailed history grooming you are describing, open source or not.

To me (and many others), keeping commits small and singular in purpose is something done before you commit, because that is the way to work effectively. For me (and many others), the ability to rewrite published history (by purpose, or worse, by accident) is something that would be a show-stopper if there weren't outside forces at work that make using a different VCS a non-option.

If you are fine and comfortable with the kind of remote-grooming workflow you are describing, by all means use git. Apparently you are not my target audience, and no harm done. Thanks for your feekback anyway!

[AJ]

Hi Solar,

Your OP pretty much covers everything I use (and more - I'm a one man band so don't really care about 'blame' etc...). Just one note which I don't actually think is an oversight, is that in the OP you mention git fetch, but not git pull.

Cheers,
Adam

[Solar]

Not an oversight. I am not yet clear about the details, but I feel that 'git pull' (fetch plus merge before you even see what is incoming) is a broken design. If I decide to go with the merge, the workflow will be update -- (check) -- merge. I will however have a very long and hard look at update -- rebase (the way e.g. SVN handles incoming commits). Not decided yet. But if it is a merge, call it a merge, and DO a merge.