Far more often it's why in all the screaming nine hells is the code written this way?! I need to change code, but it has some odd features, and I need to puzzle them out to avoid breaking something important. Why? Because as a code archeologist, rarely do I start with wanting to know what work was done on a branch. Always use git merge -no-ff to merge task branches you want that merge commit and history bubble, even for just one commit.Link each task branch with an associated issue in the issue tracker using a simple naming convention.Here's two simple steps that will greatly help archeology and development. That is, I don't believe people will remember to add a tag once they're done with a branch. Reliable in that they aid daily development and doesn't add an extra step to the process of getting work done. What you want is to ensure the information relevant to archeologists can be found by reliable means. Put another way, branches archive themselves. Commits pointed by refs are safe from GC.Įdit: Found a perl implementation of the same idea by git-atticĮdit^2: Found a blog post where Gitster himself using the same technique. Commits without any ref will be GC'd after 3 months (or a couple of weeks without reflog), let alone manual git gc -prune. List-archive = for-each-ref -sort=-authordate -format='%(refname) %(objectname:short) %(contents:subject)' refs/archive/Īlso, you may want to configure remotes like push = +refs/archive/*:refs/archive/* to push archived branches automatically (or just specify on push like git push origin refs/archive/*:refs/archive/* for one-shot ).Īnother way is to writing down SHA1 somewhere before deleting branch, but it has limitations. Still, you can list them with git for-each-ref.Īdd-archive = "!git update-ref refs/archive/$(date '+%Y%m%d-%s')" Refs with non-standard prefix (here refs/archive) won't show up on usual git branch, git log nor git tag. Restore the branch (if needed): git branch topic refs/archive/old-topic.Archive the branch: git update-ref refs/archive/old-topic topic & git branch -D topic.If you want more control over what you pull down, or if you'd like to submit changes to GitSavvy, you should pull down the repository directly and restart the editor.Yes, you can create a ref with some non-standard prefix using git update-ref. If GitSavvy fails to operate correctly in this configuration, make sure to confirm the Git path you're using in the config. Note: If you're using 64-bit Windows, the path to the Git binary may not be as you expect. Open the command palette and start typing Package Control: Install Package.Install the Sublime Text Package Control plugin if you don't have it already.Open files on GitHub in the browser, with lines pre-selected. Reference issues and collaborators in commits. View and manipulate local and remote tags. View and manipulate local and remote branches. (Un)stage and revert individual lines and hunks.ĭisplay and overview and offer actions to manipulate your project state. It can also be accessed from within Sublime by opening the command palette and typing GitSavvy: help. Documentationįeature documentation can be found here. For the best experience, use the latest ST3 dev build. Also, GitSavvy takes advantage of certain features of ST3 that have bugs in earlier ST3 releases. Note: GitSavvy requires Git versions at or greater than 2.18.0. status, branch, tag, and rebase dashboards.git diff view, allowing user to (un)stage hunks across all files.GitHub-style blame view, showing hunk metadata and ability to view the commit that made the change.opening the current file on GitHub at the selected line.issue/collaborator referencing when committing.inline diff viewing, including quick navigation between modified hunks and the ability to (un)stage files by hunk or by line (respectfully stolen from SourceTree, GitX, et al).basic Git functionality init, add, commit, amend, checkout, pull, push, etc.Sublime Text 3 plugin providing the following features:
0 Comments
Leave a Reply. |