I also really like the auto_tagger option to format tag names so they are human readable timestamps by adding a separator character. To manually fetch all the autotags (when using the ref-path=autotags option as above), do $ git fetch origin refs/autotags/*:refs/autotags/* That’s part of the point of using an alternate tag type, avoiding syncing them automatically on every fetch. You almost never need to look at autotag refs in development, but if you do, you may need to fetch them manually. auto_tagger options file into your project with these contents: -ref-path=autotagsĪuto_tagger will automatically fetch and push tags in a custom namespace when it needs to. auto_tagger will now do this for you simply by adding one configuration option.ĭrop a. It’s quite easy to create new kinds of refs you just put a new directory in the. A ref is a file that contains a SHA-1 has identifying a commit, and is an entry point into the big network of blobs in the git object database. And it looks like running GitX with thousands of tags can make the app seriously slow and prone to crash.Ī little background: A git tag is just a kind of ref in a special namespace. The other is that git will automatically sync tags on every fetch and push, which can noticeably slow things down when you have a lot of tags. And it defeats the tags menu in the GitHub UI. One is that it pollutes the tag namespace which makes it harder to find tags for releases, etc. wikipedia History of Git open source initiated by Linus Torvalds first release: 7 April 2005 version 2.1.
GITX ALTERNATIVE SOFTWARE
There are a couple problems with generating autotags as standard git tags. Git was initially designed and developed by Linus Torvalds for Linux kernel development in 2005, and has since become the most widely adopted version control system for software development. I pestered Jeff to add this feature after Scott Chacon explained to me how bad it is to create a large number of tags in git. That argument is passed into git merge-base in order to determine the most recent shared commit between that branch, and the current branch.A recent addition to Jeff Dean’s auto_tagger is the ability to use an alternate tag ref type instead of standard git tags. This alias is just a shell script, that is using an argument which refers to the parent branch. My typical flow is to pick the oldest commit (the one at the top), and set all other commits to f (or fixup). You can then use an interactive rebase to pick/reword/edit/squash/etc all commits in your branch, since it diverged from the parent branch. gitconfig: rbi = !sh -c \"git rebase -i `git merge-base $1 HEAD`\". If you instead want to rebase all the commits in your current branch, since the most recent commit it shared with its parent branch, you can add the following alias to. This is only a minor annoyance but it is an annoyance. The whole problem here is that you have to know which commit you have to refer to, either by its SHA, or HEAD~x, etc. The problem with rebasing from a known commit The problem with git rebase -i master is that you may have merge conflicts that you don't necessarily want to deal with at the moment, or you may fix a conflict in one commit, only to fix it again in another commit during the course of the rebase.
The problem with rebasing from a different branch This answer applies if you don't actually want to rebase on top of master, but you'd rather just squash all commits into one, since diverging from master.
Which will show you all the commits on that branch, and piping to cat will disable the pager so you see the first commit immediately.ĮDIT: combining the above gives a fully automated solution: git rebase -i `git log master.other_feature -pretty=format:"%h" | tail -n 1`~ I'm sure there's some magic way to convince git to figure out the root of the tree automatically, but I don't know what it is.ĮDIT: That magic is this: git log master.other_feature | cat # However, if you remove everything, the rebase will be aborted. # If you remove a line here THAT COMMIT WILL BE LOST. # squash = use commit, but meld into previous commit # edit = use commit, but stop for amending Now that I know the root hash I can run this: git rebase -i 38965ed29d89a4136e47b688ca10b522b6bc335fĪnd my editor pops up with this and I can rearrange/squash/whatever as I please. Then run: git rebase -i įor example, I have a repository that I inspected using gitx: Use gitk (*nix), or gitx (OS X) or similar on other platforms, and have a look at which commit was the root of your branch.
0 kommentar(er)
