Gweezlebur - Latest Comments

Re: How I use Foursquare

jeffhilimire — Thu, 04 Feb 2010 15:51:41 -0000

Yep, great post. If you can't bring yourself to try it first, this is as good a summary of why the people that do use it like it as I've seen.

So what's going to happen when Facebook rolls out a similar service?

Re: My Proposed Solution to the "Can't Comment On RTs" Problem: Retweet-Replies

tpope — Sun, 13 Dec 2009 23:55:36 -0000

This is absolutely the best solution that I can conceive of. It actually surprised and disappointed me the first time I replied to something I retweeted and it didn't work.

Re: My Proposed Solution to the "Can't Comment On RTs" Problem: Retweet-Replies

elliottcable — Sun, 13 Dec 2009 23:36:30 -0000

I like that solution. My *personal* solution was to write a tweet‐short‐URL‐in’ service (http://tau.pe/) and then to tau.pe tweets in a separate tweet *after* retweeting them. I could say whatever I wanted about a tweet, in another tweet, and semantically reference the originally tweet through the tau.pe.

Re: My Proposed Solution to the "Can't Comment On RTs" Problem: Retweet-Replies

Jbyrdman — Sun, 13 Dec 2009 23:32:04 -0000

great Idea....I think it would be simpler if I could reply to your Retweet...to you....so if you retweet something...and I click reply it replies to you, and not your rewtweete...or retweeted..whatever.

Re: Thanks for the Retweets

michaelivey — Sat, 12 Dec 2009 08:54:26 -0000

Really good analogy, Justin. If it fit in 140 I'd have tweeted it.

Re: Thanks for the Retweets

Justin Pease — Fri, 11 Dec 2009 16:00:35 -0000

But yeah, I agree. Pretty much self-promotion.

If you get a present you send the sender a thank you note. You don't send everybody you know a thank you note explaining that someone gave you a present.

Re: Thanks for the Retweets

Justin Pease — Fri, 11 Dec 2009 15:48:41 -0000

Wait a second... is this just a trick to promote @soandso and @someonelese? :p

Re: My Git Workflow

openid-12092 — Fri, 16 Oct 2009 01:59:58 -0000

Thanks for the great post. I just completed my own workflow writeup with a similar flavor: http://www.rand9.com/blog/my-git-workflow

Thanks!

Re: My Git Workflow

slnc — Mon, 16 Feb 2009 15:07:51 -0000

Isn't "git rerere" supossed to solve this specific case?

Re: My Git Workflow

Guillermo — Mon, 02 Feb 2009 12:46:59 -0000

Whell, it isn't correct.

In that example I assume that my local branch master can be ff to origin/master. So git pull --rebase isn't necesary.

Re: My Git Workflow

Guillermo — Mon, 02 Feb 2009 12:39:06 -0000

In my company, I decide to each commit to the repo has one ticket associated. (Excepts some minor bug fixes).
But big tickets take a lot of commits. For that insted of doing a just commit -amend, y commit in another branch, and when finished, y just run something like these:

git fetch && git rebase origin/master && git checkout master && git pull --rebase && git merge my_new_feature --no-ff --no-commit && git commit
Insert my commit message with the associated ticket id.

By these way i always know when a bug is introduced, and can revert some minor commit or all the feature.

In git log of branch master or production, all tickets (merges or simple commits) appers with its own ticket, and ing ginst(or integration system can see the commit and click to go to the ticket easily).

Re: Importing Mephisto comments into Disqus

asdfasf — Tue, 27 Jan 2009 16:10:09 -0000

awesome

Re: My Git Workflow

wdiechmann — Sat, 24 Jan 2009 12:48:49 -0000

Wonderful insights shared, Mike, thank you! :)

One/several of the comments mentions the added trouble handling database versions, and I totally agree - database versioning is troublesome!

Idea: If somebody with the helicopter overview of git wrote a plugin (is that at all possible) to handle dataabase versioning on creating branches and switching between them, they'd probably do something along the lines of:

1. rollback the current database
1.1 dump whatever data is in the database
1.2 drop tables

2. rollforward database on branch
2.1 create tables
2.2 load data

(on Rails projects, you'd have rake db:migrate along to assist in the rolling back/forward, but it would have to be refined to handling data as well)

I know - on large projects, this added workflow would prove to be a inhibitor on branching which is certainly undesireable, but on the other hand, developers would be spared the agonies of recreating databases or finding themselves fighting bugs which really are the consequence of missing syncronizations to database versions.

Just an idea - I'm afraid I am not myself able to take this idea into any kind of beta, though :(

But - again - thank you for sharing, Mike!

Re: My Git Workflow

michaelivey — Sat, 24 Jan 2009 11:50:13 -0000

You could use post-commit hooks to automatically deploy a production branch (see Daniel Miessler's post above) but I'd look into a deployment tool like Capistrano, which was designed for Ruby on Rails but works for any kind of deployment. I'm not a huge fan of using version control as a deployment tool, because I like to be able to control my deployments more.

Re: My Git Workflow

Markux — Sat, 24 Jan 2009 05:03:07 -0000

Hi, I'm using svn, but it lacks in deployment on site production (since I need to login on every site and launch svn up).
How git deploying change on server production (or other server)? Can I distribute change on every server from my local machine?

Re: Biden was never the President

jhulten — Fri, 23 Jan 2009 13:38:21 -0000

In addition, the 25th amendment is very clear about the rules for the VP taking over for the President (see below).

Section 1. In case of the removal of the President from office or of his death or resignation, the Vice President shall become President.

Section 2. Whenever there is a vacancy in the office of the Vice President, the President shall nominate a Vice President who shall take office upon confirmation by a majority vote of both Houses of Congress.

Section 3. Whenever the President transmits to the President pro tempore of the Senate and the Speaker of the House of Representatives his written declaration that he is unable to discharge the powers and duties of his office, and until he transmits to them a written declaration to the contrary, such powers and duties shall be discharged by the Vice President as Acting President.

Section 4. Whenever the Vice President and a majority of either the principal officers of the executive departments or of such other body as Congress may by law provide, transmit to the President pro tempore of the Senate and the Speaker of the House of Representatives their written declaration that the President is unable to discharge the powers and duties of his office, the Vice President shall immediately assume the powers and duties of the office as Acting President.

Thereafter, when the President transmits to the President pro tempore of the Senate and the Speaker of the House of Representatives his written declaration that no inability exists, he shall resume the powers and duties of his office unless the Vice President and a majority of either the principal officers of the executive department or of such other body as Congress may by law provide, transmit within four days to the President pro tempore of the Senate and the Speaker of the House of Representatives their written declaration that the President is unable to discharge the powers and duties of his office. Thereupon Congress shall decide the issue, assembling within forty-eight hours for that purpose if not in session. If the Congress, within twenty-one days after receipt of the latter written declaration, or, if Congress is not in session, within twenty-one days after Congress is required to assemble, determines by two-thirds vote of both Houses that the President is unable to discharge the powers and duties of his office, the Vice President shall continue to discharge the same as Acting President; otherwise, the President shall resume the powers and duties of his office.

Re: My Git Workflow

RayMorgan — Fri, 23 Jan 2009 04:07:42 -0000

We have a similar workflow where I work. We create a topic branch for each ticket that comes. Developers actually do not have access to push back to origin/master, instead we push our topic branches up to a personal fork. We then put in a merge request with the release team and they go through these topic branches, merge them in and push that up to origin/qa which is then tested. If branches failed to merge, the developer then rebases off of the new origin/qa branch and re-pushes up to their fork.

Once the qa branch has been successfully tested, the release team tags the HEAD of qa and deploys that code base. Then finally this is merged back into origin/master so that all the developers can update. It might seem like quite a bit, but it works... and allows some really fast emergency release patterns when they are needed.

Re: My Git Workflow

danielrm26 — Fri, 23 Jan 2009 02:58:36 -0000

Nice. Here's mine: http://dmiessler.com/blog/using-git-to-maintain-your-website

Re: My Git Workflow

mernen — Fri, 23 Jan 2009 02:45:15 -0000

My workflow has changed as time passed, and I believe what changed it the most was to always (and constantly) use add -p. I like to use it as a quick self-review before staging anything. One of the consequences is that I'm using a lot less "checkpoint" commits, since often just staging everything into small chunks is enough. My checkpoint commits usually have crappy messages, like `git commit -m WIP` or `git commit -m '[W] extracted methods'`, and I have to admit that sometimes they are not really enough to remind me of what to write in the final commit message when squashing everything together in the end (I particularly use rebase -i for that, as the checkpoints might actually turn into two or more final commits); I should improve that.

Another characteristic, not directly related to that, is that now I'm working directly on the "main" branch much more often. I realized that a lot of the time when people use the temporary branching pattern (even for small things and with very remote possibility of having to interrupt work), they tried to keep master "clean". Why that? There's origin/master there already, no need to duplicate its function. If the need arises for me to work on something else, *then* I will stash the changes, or create a new branch and back out some commits from master — and often this is just a reset to origin/master. (Of course, if this is something I expect to work for a long time before merging in, then I will just create a new branch from the start.)

Re: My Git Workflow

justinwr — Wed, 21 Jan 2009 09:30:34 -0000

When in Git-SVN, I like to see the merges... because it keeps with how I used to use SVN.

Re: My Git Workflow

justinwr — Wed, 21 Jan 2009 09:29:13 -0000

So when you go to create a new topic branch you just base it off the previous topic branch? Or do you go in and rebase your master from the topic branch where you dcommit'ed?

Re: My Git Workflow

Antti Rasinen — Wed, 21 Jan 2009 07:47:18 -0000

This is precisly what I am using as well. I basically only have topic branches and remote branches and hardly ever anything that tracks the remote branch for a long time.

Re: My Git Workflow

Joao Vitor — Wed, 21 Jan 2009 07:46:39 -0000

git rebase origin/master

Never tried this.
Nice to know that this is possible.

Re: My Git Workflow

Adam Hupp — Wed, 21 Jan 2009 05:11:34 -0000

I have a pretty similar workflow with two changes. First, at step #5 I'm always rebasing against the origin, git-svn in this case. I've never felt the need to rebase against something else.

Also, there's no need to for steps 7-9 since I just dcommit right from topic-branch. This saves a few steps and makes master entirely unnecessary.

Re: My Git Workflow

drogus — Wed, 21 Jan 2009 03:57:40 -0000

# git rebase master
# At this point, either it goes well or I have merge conflicts. If I have conflicts, I fix them, and keep going. It’s better to have conflicts on a topic branch than in master.

Could you write how do you handle these conflicts not to have any commits on top of your topic branch commit? git --amend is very good and I also like it for one commit fixes but often I find it hard to leave this one specified commit on top and I end up with git rebase --interactive anyway :)