Hello! Languages of the real and artificial is using DISQUS, a powerful comment system, to manage its comments. Learn more.
Community Page
- osteele.com Jump to website »
-
Subscribe -
Community
-
Top Commenters
-
Popular Threads
-
Recent Comments
- NoTV service is not available in my area. Something about low demand :)
- I also read recently about Ethanol polluting more than gasoline. Not sure if its true coz I couldn’t keep up with all of the chemistry..but im very much interested with fuels becoz im a car...
- We got NOtv when we lost cross country wireless and moved to a new house. We found that DSL was a better item and we can actually limit what we see. The NOtv has been a shock to many folks who are...
- Absolutely beautiful post. Thirty minutes after reading it, my whole way of doing git business has changed.
- Wow, this is awesome! You should talk a little more about the code behind how this works, would be a great read.
Jump to original thread »
Git's great! But it's difficult to learn (it was for me, anyway) -- especially the index, which unlike the power-user features, comes up in day-to-day operation.
Here's my path to enlightment, and how I ended up using the index in my particular workflow. There are ot ... Continue reading »
Here's my path to enlightment, and how I ended up using the index in my particular workflow. There are ot ... Continue reading »
1 year ago
1 year ago
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.
1 year ago
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'.
1 year ago
1 year ago
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
1 year ago
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.
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.
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.
1 year ago
1 year ago
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
1 year ago
1 year ago
Great couple of post on Git. I'm learning and this material is gold. Thanks a lot!.
1 year ago
11 months ago
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.
11 months ago
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.
11 months ago
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!
11 months ago
9 months ago
Thanks!
p.s: what do you do your diagrams in?
8 months ago
5 months ago
...which is now my mind-map and non-UML tool of choice, too.