What's the best way to have a "temporary" commit in git?

views:

answers:

What's the best way to have a "temporary" commit in git?

Say I have a project with two branches master and dev. I have a bunch of commits on dev for a special event which once tested are merged into master. Then after the event is over I want to remove the event specific code. However a git reset won't do since other commits have been made since the event code was added.

Currently I use git checkout to checkout the files from before the event was merged in and then use git diff to re-add in the changes that have been made since the event was committed. This seems like a very messy method to me.

Does anyone have a better solution for having temporary code in a project?

Edit: To be clear the changes need to be committed, pushed, uncommitted, pushed.

I beleive stash does what you want.

Splashdust 2010-10-17 13:58:05

Not really, stash will simply stash some changes, it wont help him apply them to a branch and then un-apply them later.

thenduks 2010-10-17 14:00:12

Yes I already know the cool things about stash and use it, the changes need to be committed and pushed then uncommitted and pushed I'll updated my question to make that clearer

Obsidian 2010-10-17 14:02:03

Okay, I see. I misunderstood the question then.

Splashdust 2010-10-17 14:07:27

+3 A:

Take master and create a branch: git checkout -b special-event, make/apply your changes. Once the event is over, simply switch back to master and abandon/delete the branch.

In order to continue making changes, make them on master and merge them into the special branch as you go. git checkout master ... make changes ... git checkout special-event; git merge master.

Alternatively, make all your special-event related changes in one commit, then use git revert when you want to roll them out and specify just that commit.

thenduks 2010-10-17 13:58:37

I've thought of git revert but since the special event code is on a dev branch and merged into the master git revert and merges is..messy. Also there tend to be minor changes (typo fixes) to the event code after it's merged so we end up with a bunch of commits to revert so unless there's a clean way to combine commits and revert the merge git revert doesn't sound too great. Your git branch idea sounds feasible but if I delete the branch is it still logged somewhere so I can check it out again to reuse say a few months later?

Obsidian 2010-10-17 14:08:07

I would suggest using `git rebase master` instead of `git merge master`.

dgnorton 2010-10-17 14:48:31

@Obsidian: The commits will still be around but it will be difficult to find them. In that case, simply leave the branch around (they cost only the length of a sha in a file, aka, free :)).

thenduks 2010-10-17 16:12:17

@dgnorton: Sure. Personal preference depending on how you like your history organized/cleaned/etc.

thenduks 2010-10-17 16:12:44

@thenduks, In many (most?) cases, *rebase* provides the history organization that people expect / want when the topic branch is eventually merged with master.

dgnorton 2010-10-17 18:40:08

Fair enough. Personally I often appreciate the history showing when merges were done. Especially with many people working on the code-base.

thenduks 2010-10-17 20:07:28

I'm going to go with this answer since I find the merges are easier to work with remote repos than using rebase

Obsidian 2010-10-19 15:04:56

+1 A:

git checkout -b event

...make specific event change...

git commit -am "specific event change"

...make another specific event change...

git commit -am "another specific event change"

At this point, the master branch is still intact and the event specific changes are on the event branch. If changes are made to the master branch that are also needed in the event branch, use rebase...

git rebase master

Another answer suggested merging master into event but rebase is usually the better approach. A rebase peels the commits made on the topic branch off, pulls the the updated master forward and then reapplies the topic branch changes on top...as if the topic branch changes were made to the most recent version of master.

In your scenario, when the event is over, simply delete the event branch.

dgnorton 2010-10-17 14:47:01

I've done some testing and found that git rebase doesn't push well it says "To prevent you from losing history, non-fast-forward updates were rejectedMerge the remote changes (e.g. 'git pull') before pushing again. "

Obsidian 2010-10-17 18:55:33

git revert

It will remove any commit, or range of commits that you need to undo. It is also safe to push to a public repo.

Casey 2010-10-17 23:04:05

ansaurus

tags:

views:

answers:

What's the best way to have a "temporary" commit in git?

related questions