Git stash, but more permanently.

[Chad Faragher]

I'm looking for improved git workflow. [This time, +chromium-dev.
Sorry to those receiving this twice.]

I started using git stash recently. I was using it to keep some little
changes I have around.

For example. I'm testing the hung renderer dialog, so I've tweaked
the timeout from 20 seconds down to 2 seconds. But I wouldn't want to
check in this change by accident, yet I always want to build with this
change.

I would commit all my regular work, but stash my timeout changes.
Then I could git cl upload my patch, and git stash apply it when I was
done. It's a bit of a pain because I can't git commit -a anymore but
I was more-or-less happily tolerating that.

Another scenario is that sometimes I sprinkle some extra log messages
around or inject some fake data at points. I'd like to know how to
keep my work without interfering with reitveld workflow.

Can anyone suggest a better workflow to keep around some simple
patches like this?

- Chad

[Scott Graham]

On Mon, Aug 29, 2011 at 1:15 PM, Chad Faragher <wy...@chromium.org> wrote:
> Can anyone suggest a better workflow to keep around some simple
> patches like this?

Does this help?
http://code.google.com/p/chromium/wiki/GitCookbook#Excluding_file(s)_from_git-cl,_while_preserving_them_for_later_u

[Scott Hess]

git stash isn't really magic at all, it just keeps a ref in an area
which doesn't show up as a formal branch, but applying a stashed item
is just the same as cherry-picking a committed item. I generally find
that anything I've stashed for longer than an hour or so loses too
much context to be salvageable, so I often do two things that are
kinda similar to stash.

For some changes, I'll keep two branches, one for the basic change
that I want to checkin, one for all the other crap I need to make sure
it's doing the right thing. Development happens on the latter (I give
that branch the same name with _dev appended). Periodically I'll hop
over to the main branch, cherry-pick the changes, make sure it's all
still compiling and working, then rebase the _dev branch on top of the
main branch, resolving conflicts. You could also rebase -i on the
_dev branch and push the changes past the extra-junk changes, and then
cherry-pick them over to the main branch. Obviously I only upload
from the branch without the extra junk.

For small changes, I'll just keep them at the head of the branch, and
revert them when uploading. As changes get bigger, I find that I'll
sometimes get tied up with merge conflicts during a rebase (the revert
often doesn't merge well because you merged new stuff into the change
it was reverting from).

-scott

On Mon, Aug 29, 2011 at 1:15 PM, Chad Faragher <wy...@chromium.org> wrote:

> --
> Chromium Developers mailing list: chromi...@chromium.org
> View archives, change email options, or unsubscribe:
>    http://groups.google.com/a/chromium.org/group/chromium-dev
>

[Marc-Antoine Ruel]

1. Enable tracking local branches; git config branch.autosetupmerge always

2. Enable rebase on pull; git config branch.autosetuprebase local

3. Base your work branch against your local hacked branch; git checkout -b my_work no_timeout

You can continue to git pull or git svn rebase.

More info at http://www.kernel.org/pub/software/scm/git/docs/git-config.html

It's like pipelining changes http://maruel.github.com/landslide/maruel_git.html#slide11 but without ever sending "1_foo".

M-A

[Dirk Pranke]

I second M-A's recommendation, but you should be aware that using the
"new git" setup, 'gclient sync' will rebase no_timeout onto master and
you'll lose the local changes. We are in conversation with Nicholas,
Chase, et al. to figure out what the ideal solution is here (one
option is to have gclient sync not rebase the main branch if it is
branched off of another local branch).

-- Dirk

[Evan Martin]

On Mon, Aug 29, 2011 at 1:15 PM, Chad Faragher <wy...@chromium.org> wrote:

> For example.  I'm testing the hung renderer dialog, so I've tweaked
> the timeout from 20 seconds down to 2 seconds.  But I wouldn't want to
> check in this change by accident, yet I always want to build with this
> change.

One trick is to add the changed file to .git/info/exclude, so git no
longer tracks it for changes. This of course won't work if you have
other meaningful changes to the file, and it can be really dangerous
if you forget that you added it!

Otherwise, I do roughly what Scott Hess suggested: one branch that is
a combination of all the random junk I am working on, and then I
cherry-pick pieces of it out to new branches as I find pieces of the
larger change that are independently reviewable/testable/committable.

git checkout -b main-feature
hack hack; git commit
git checkout -b minor-refactoring origin
git cherry-pick / git checkout files from main-feature
git cl upload

If the reviews take a while, you can then "git merge" the side
branches back into your main branch so that you can keep the two in
sync. Continuing from the above:

git checkout main-feature
git merge minor-refactoring
continue hacking
(on review feedback)
git checkout minor-refactoring
git commit, git try, etc.
git checkout main-feature
git merge minor-refactoring

But generally that is only necessary when the review process is
breaking down (e.g. taking more than 20 minutes or so).

[Mario Sanchez Prada]

Don't know if it will be better to you or not, but worth sharing
anyway... check out Stacked Git [1], as I understand it it could be a
convenient tool (which works on top of git) for your use cases.

As from the description in the web:

"""
StGit is a Python application providing similar functionality to
Quilt (i.e. pushing/popping patches to/from a stack) on top of Git.
These operations are performed using Git commands and the patches are
stored as Git commit objects, allowing easy merging of the StGit
patches into other repositories using standard Git functionality.
"""

For a good overview of how to use it, check out the tutorial here:
http://www.procode.org/stgit/doc/tutorial.html

Hope you find it interesting,
Mario

[1] http://www.procode.org/stgit/

> - Chad
>