Skip to content

Instantly share code, notes, and snippets.

@ctford
Last active August 29, 2015 14:21
Show Gist options
  • Select an option

  • Save ctford/288e2ae7be151b08c239 to your computer and use it in GitHub Desktop.

Select an option

Save ctford/288e2ae7be151b08c239 to your computer and use it in GitHub Desktop.
A sketch of an alternative git porcelain.
# dag is based on git's underlying directed acyclic graph of commits.
#
# There are "labels" (ie branches) that you can "extend" from (ie commit).
dag import "https://github..." # Clone a project from Github.
# cd project
# create some files
dag extend "Change some stuff" # Commit *all* changes (no staging of individual files).
dag label "bug-fix" # Create a branch, which is really just a label.
dag switch "bug-fix" # Checkout the new branch.
# fix a bug
dag switch "master" # Checkout the master branch again.
dag fuse "bugfix" ...or... dag linearize "bugfix" # Merge the bugfix branch (fuse) or rebase it (linearize).
dag linearize "origin" # You can also linearize/rebase from remotes.
dag publish "origin" # Pushing is publishing.
dag remove "bugfix" # Remove the label/branch.
# make some changes
dag compare # Diff the current state against the latest commit ie see what would be commited with extend.
# decide they're dud.
dag clean # Get rid of local changes - though actually put them to an undo stash.
@lifeinchords

Copy link
Copy Markdown

Thanks for sharing these ideas..
Feels like you are renaming the methods/ "API", terms... not changing the way git works.. am I reading that right?

@ctford

ctford commented Jun 1, 2015

Copy link
Copy Markdown
Author

That's part of it, yes, but I'm also trying to exclude complexity that I don't think is warranted.

For example, I don't think that it's useful to commit some files and leave others (I always git commit -am), so I would remove the addition to the staging area. Also, I'm not sure if it's worth having different ways of rebasing against remotes and local branches. In both cases, you are trying to produce a "linearized" history where you take changes from some other source and make it look like your changes postdate them all.

In the end, my goal would be to translate however the new UI works into git, because a) I don't want to write the underlying mechanics myself b) I want this to plug into Github etc, and even to be able to use the git commandline if you want extra power.

@ctford

ctford commented Jun 1, 2015

Copy link
Copy Markdown
Author

Another option is to use rebase, merge and commit, but make them simpler and more consistent.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment