[Kde-scm-interest] [PATCH] scripty

[Chani]

On June 1, 2009 14:03:44 Thiago Macieira wrote:
> Chani wrote:
> >git reset doesn't change what local branch I'm on, does it? it resets
> > that branch to be all clean? so I have to make sure I reset it to the
> > right branch... eew...
>
> git reset simply changes what commit the current checkout points to. If
> you have a branch checked out, that branch is moved to the commit you give
> it.
>
> So:
>   git commit -a -m "foo"
>   git reset HEAD~
>
> Moves the current branch to HEAD~ (the parent commit of HEAD), which means
> it's like the commit never happened.
>
> If you pass reset the --hard option, besides moving the branch, it *also*
> checks out the files.
>
> For example, in a Qt checkout, the following is entirely permissible:
>
>   git checkout foo
>   git reset --hard origin/master
>   git reset --hard origin/4.5
>
> The two commands change completely the contents of the checkout (and move
> the branch "foo" too). It really doesn't matter how you created foo. That
> also means you don't have to create many local branches for scripty: one
> branch suffices, as long as you keep resetting between them. The difference
> will be when you push.
>
> Now, note that reset --hard *only* touches files that are in the
> repository. It will not touch files that are not tracked. If, in the
> process of resetting, a new file must be checked out, but the given file
> already exists, it complains and refuses to continue.
>
> That's why you have to do a git clean before you reset.
>
> >although since we're about to checkout a different branch, maybe commits
> > on that other branch don't matter. scripty itself will try to undo its
> > commits if it fails to push, anyways.
> >
> >so I could find out what branch I'm on and reset that, or I could do the
> > reset after the checkout, or I could just be lazy and not reset.
>
> Or you could completely ignore which branch you're on and simply work on
> the branches you have to work on.
>
> The following code will operate with a single local branch (doesn't matter
> which one you start on!):
>
> set -e   # exit if any command fails
> for branch in `branches_for_module $module`; do
>   # Check out the latest commit in branch $branch
>   git fetch
>   git clean -x -d -f
>   git reset --hard origin/$branch
>
>   # Scripty tasks
>   update_xml
>   commit_desktop_changes
>
>   # Get the latest changes to reduce the chances of push failing
>   # Since HEAD points to origin/$branch, this pull will not create merges
>   # If any of the .desktop files we've changed are also changed upstream,
>   # pull will fail. If that happens, clean up and go on to the next branch
>   git pull origin $branch || { git reset --hard; continue; }
>
>   # Commit and push
>   git commit -a -m "SVN_SILENT made messages (.desktop)"
>   git push origin HEAD:$branch || true    # ignore if it fails
> done

ahh, if only scripty were actually so clean that a simple continue; would work 
;)

anyways, I mostly see what you mean now.

but my knowledge of git is still fuzzy... would this be no slower than 
checking out the branches? would I still have to have tracking branches 
created, to get a git fetch to actually download the files for the remote 
branches I care about?
I want to be sure that git's not going to be redownloading all files on every 
reset, or downloading branches I don't actually need, or anything.

-- 
This message brought to you by eevil bananas and the number 3.
www.chani3.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: This is a digitally signed message part.
Url : http://mail.kde.org/pipermail/kde-scm-interest/attachments/20090601/50d9462e/attachment.sig