What you describe sounds no different from using a branch, except that by checkpointing into the index, you're losing all of your recent history.
oliver
· 1 year ago
Something I maybe didn't make clear enough is that I actually don't want the fine-grained history in the repository. I might make a checkpoint every five minutes, and many of these checkpoints are pretty low quality; I don't want them persisted.
It would be nice to have all the checkpoints persisted until the next persistable commit, and then blow them away at that point. (I just made up "persistable commit" to mean one that I want to keep in the repository, as opposed to the ones that represent ephemeral checkpoints, if I implement checkpointing as commit.) The alternative for doing that that I mention is to commit checkpoints, and then rebase them away. One disadvantage of doing this is the extra step of the rebase, along with having to remember where to rebase from. The other is that "git diff head" won't tell me what I want. Maybe tagging every persistable commit solves both these problems.
Or I could, as you suggest, make a branch, commit my checkpoints into it, "merge -squash" it into the target branch, and then delete the branch. Then a persistable commit becomes "git checkout {original}; git merge --squash wip; git commit; git checkout -b wip", where {original} depends on which branch I started from. And "git diff head" becomes "git diff {original}", where, again, {original} depends on where I started. This is heavier weight than I want, but again, maybe some scripting and/or tags makes it easier.
Right now I like the fact that "git checkout head .", "git stash", and "git checkout -m -b" operate on everything since the last persistable commit. All those things would be harder, or I'd need to write more scripts/tagging to do them, if checkpoints were commits too.
Anyway, I really started out trying to draw a picture of how the index fit in, not to try to promote my particular workflow. I've added a disclaimer paragraph to try to make this clearer.
Gwern
· 1 year ago
"I got hit by the exponential merge bug in Darcs (since fixed?)..."
Yes, in Darcs 2 (just recently released). It's a very solid release, but I can't speak to whether it would be more satisfactory as far as 'going back in time'.
Anonymous
· 1 year ago
It might not hurt to make your underlined edits look different than your underlined links.
bartman
· 1 year ago
I love the diagrams!
One unmentioned commit management feature is `git commit --amend` which would allow you to update the last commit with new edits. If you're familiar with `git rebase -i` squashing, then this is like squashing your index into the last commit. You could also amend with the working files by using `git commit --amend -a` or providing specific files on the command line.
I think both `git stash` and `git commit --amend` have their uses, and I use them both in my workflow.
Finally, I would also like to mention that `git add -i` has a hidden feature of being able to stage individual lines of change, not complete files. If there is some debug code in your file, you can commit everything else. You can also use `git gui` to stage individual "hunks" (blocks of a diff) for commit.
-Bart
Gene Hunt
· 1 year ago
I'm a happy Mercurial user (like simple things) but I'm interested in what Git has to offer to have a better workflow.
That is, with Mercurial you could do a similar workflow using queues. They are just a series of patches which are stacked over the history of your local repository. They can be reordered, pushed, poped... and whatnot.
hg add hg del ... hg qrefresh #commits work to the top patch of queue (mywork). This is the checkpointing command
When you are happy with the patch and want to make it a "real" revision, just:
hg qremove --rev mywork
And that is, I don't know if I'm mising part of your workflow, please let me know what you think about this.
Gene Hunt
· 1 year ago
Sorry if this is a comment repost (browser crashed when first submiting)
I'm a happy Mercurial user (like simple things) but I'm interested in what Git has to offer to have a better workflow.
That is, with Mercurial you could do a similar workflow using queues. They are just a series of patches which are stacked over the history of your local repository. They can be reordered, pushed, poped... and whatnot.
hg add hg del ... hg qrefresh #commits work to the top patch of queue (mywork). This is the checkpointing command
When you are happy with the patch and want to make it a "real" revision, just:
hg qremove --rev mywork
And that is, I don't know if I'm mising part of your workflow, please let me know what you think about this.
stacktracer
· 1 year ago
Your diagrams are exactly what's been missing from all the git tutorials out there.
K. Adam Christensen
· 1 year ago
Excellent article.
You mentioned that you use git-p4 and I have been trying to use it; however, things aren't working nicely for me. If you need article ideas, I would love to hear about how you set that up and any pitfalls you have run into.
Cheers
RichB
· 1 year ago
So it's like a (local) TFS shelveset?
sergio
· 1 year ago
Your del.icio.us link in the first paragraph is broken. It is working as a relative link.
Great couple of post on Git. I'm learning and this material is gold. Thanks a lot!.
Ben
· 1 year ago
Ditto. If the article had nothing else, that one picture is worth a thousand typed or spoken words.
Anonymous
· 1 year ago
is there any articles that shows how to do continuous integration with git???
git is complex. i've been trying to use it but still don't get the core concept. i'm just using it as i am using svn.
Anonymous
· 1 year ago
is there any articles that shows how to do continuous integration with git???
git is complex. i've been trying to use it but still don't get the core concept. i'm just using it as i am using svn.
I had worked out a similar diagram to your first one when I first had to learn to use git (the only way I could understand it was to visualize it), only I've now discovered from your diagram that mine had some important things missing. Thanks for filling in the holes in my grasp of git and giving me a good starting point for improving my own workflow!
malcolm
· 1 year ago
Thank you for the great diagram illustrating the action of different git commands. On its own, this is the most helpful description of git I have seen anywhere. I hope you don't mind, I linked your image from here: http://hackage.haskell.org/trac/ghc/wiki/GitFor...
elvy
· 1 year ago
Awesome diagrams - wish I had found them earlier, they should be on the main git site / tutorials under suggested workflows - Thanks! p.s: what do you do your diagrams in?
Nathan Stien
· 1 year ago
I'll add to the chorus of praise for the diagrams. I had been baffled by the index until seeing these. I'm also curious what authoring software you used for them.
All Comments
It would be nice to have all the checkpoints persisted until the next persistable commit, and then blow them away at that point. (I just made up "persistable commit" to mean one that I want to keep in the repository, as opposed to the ones that represent ephemeral checkpoints, if I implement checkpointing as commit.) The alternative for doing that that I mention is to commit checkpoints, and then rebase them away. One disadvantage of doing this is the extra step of the rebase, along with having to remember where to rebase from. The other is that "git diff head" won't tell me what I want. Maybe tagging every persistable commit solves both these problems.
Or I could, as you suggest, make a branch, commit my checkpoints into it, "merge -squash" it into the target branch, and then delete the branch. Then a persistable commit becomes "git checkout {original}; git merge --squash wip; git commit; git checkout -b wip", where {original} depends on which branch I started from. And "git diff head" becomes "git diff {original}", where, again, {original} depends on where I started. This is heavier weight than I want, but again, maybe some scripting and/or tags makes it easier.
Right now I like the fact that "git checkout head .", "git stash", and "git checkout -m -b" operate on everything since the last persistable commit. All those things would be harder, or I'd need to write more scripts/tagging to do them, if checkpoints were commits too.
Anyway, I really started out trying to draw a picture of how the index fit in, not to try to promote my particular workflow. I've added a disclaimer paragraph to try to make this clearer.
Yes, in Darcs 2 (just recently released). It's a very solid release, but I can't speak to whether it would be more satisfactory as far as 'going back in time'.
One unmentioned commit management feature is `git commit --amend` which would allow you to update the last commit with new edits. If you're familiar with `git rebase -i` squashing, then this is like squashing your index into the last commit. You could also amend with the working files by using `git commit --amend -a` or providing specific files on the command line.
I think both `git stash` and `git commit --amend` have their uses, and I use them both in my workflow.
Finally, I would also like to mention that `git add -i` has a hidden feature of being able to stage individual lines of change, not complete files. If there is some debug code in your file, you can commit everything else. You can also use `git gui` to stage individual "hunks" (blocks of a diff) for commit.
-Bart
That is, with Mercurial you could do a similar workflow using queues. They are just a series of patches which are stacked over the history of your local repository. They can be reordered, pushed, poped... and whatnot.
So it would work like this.
hg qinit #init queues
hg qnew mywork #new queue patch
Now you do your work:
hg add
hg del
...
hg qrefresh #commits work to the top patch of queue (mywork). This is the checkpointing command
When you are happy with the patch and want to make it a "real" revision, just:
hg qremove --rev mywork
And that is, I don't know if I'm mising part of your workflow, please let me know what you think about this.
I'm a happy Mercurial user (like simple things) but I'm interested in what Git has to offer to have a better workflow.
That is, with Mercurial you could do a similar workflow using queues. They are just a series of patches which are stacked over the history of your local repository. They can be reordered, pushed, poped... and whatnot.
So it would work like this.
hg qinit #init queues
hg qnew mywork #new queue patch
Now you do your work:
hg add
hg del
...
hg qrefresh #commits work to the top patch of queue (mywork). This is the checkpointing command
When you are happy with the patch and want to make it a "real" revision, just:
hg qremove --rev mywork
And that is, I don't know if I'm mising part of your workflow, please let me know what you think about this.
You mentioned that you use git-p4 and I have been trying to use it; however, things aren't working nicely for me. If you need article ideas, I would love to hear about how you set that up and any pitfalls you have run into.
Cheers
Great couple of post on Git. I'm learning and this material is gold. Thanks a lot!.
git is complex. i've been trying to use it but still don't get the core concept. i'm just using it as i am using svn.
git is complex. i've been trying to use it but still don't get the core concept. i'm just using it as i am using svn.
I had worked out a similar diagram to your first one when I first had to learn to use git (the only way I could understand it was to visualize it), only I've now discovered from your diagram that mine had some important things missing. Thanks for filling in the holes in my grasp of git and giving me a good starting point for improving my own workflow!
Thanks!
p.s: what do you do your diagrams in?
...which is now my mind-map and non-UML tool of choice, too.