Re: [exim-dev] Git changes, viewing and pushing

Αρχική Σελίδα
Delete this message
Reply to this message
Συντάκτης: Todd Lyons
Ημερομηνία:  
Προς: exim-dev
Αντικείμενο: Re: [exim-dev] Git changes, viewing and pushing
On Tue, Aug 3, 2010 at 10:11 AM, Phil Pennock <exim-dev@???> wrote:
> Perhaps I just need more sleep than a leaking air-mattress provides, but
> could a Git expert please help me with two points?


I'm no expert, but I'll put my 2 cents in.

> (1) How to view which changes are in one repository but not another?
>    It's acceptable for the answer to involve my learning about
>    branches in Git and pulling multiple origins to local and diffing
>    them.

>
>    For seeing what's in /users/pdp/exim.git on tahini but not in the
>    master, there must be a better way than looking at the shortlogs of
>    both and trying to spot which changes have and have not made it in?


There is a three dot format. Quoting the gittutorial manpage:

           $ gitk HEAD...FETCH_HEAD


       This means "show everything that is reachable from either one, but
       exclude anything that is reachable from both of them".


So you should be able to do:

gitk origin/master...tahini/master

Untested, I've never used it myself.

>  (2) Selectively pushing commits: how?
>
>     Given four commits in the local tree, replicated to pdp@tahini's
>     tree, *three* of which I wish to push to the master, how do I push
>     those commits?


When you do development work, you create a topic branch to do your
work. A simple example, assuming you have done a pull and are on
branch master:

git checkout -b master_bug_2922
...edit files, test, commit, repeat making 4 total commits.

Now at this point, you decide that you really only wanted three of
those commits and want to hold off on one. You have two choices. The
first choice is to cherry pick those commits back into your master
branch.

The second choice is a bit more labor intensive, but it might be
easier to visualize. All of your commits live in your topic branch,
so export them to email formatted patch files:

git format-patch HEAD~4

Now the last 4 commits are in the current directory, something like this:
[todd@tlyons-lap ~/projects/IV (live)]$ git format-patch HEAD~10
0001-Fixed-Sales-Cal-permission-checking.patch
0002-Bug-fix-for-groups.patch
0003-Sales-Cal-Fixed-Follow-up-permissions.patch
0004-Fixed-can_i-when-passing-in-a-user.patch

Now change back to the master, make a new topic branch, then import
just the three that you want into the topic branch, then merge that
back into the main branch (master in this example) :

git checkout master
git checkout -b master_bug_2922_real
git am 000[123]*.patch
git checkout master
git merge master_bug_2922_real

If everything looks ok:
git push
git branch -d master_bug_2922_real

As an aside, a standard line in my .gitignore is 0*.patch. It helps
to keep those patch files from cluttering output of git status.

>     For the remaining commit, once that's done, what's the correct way
>     to get rid of it as bad work?  Nuke the repository and re-clone?
>     Rollback?


git checkout master
git checkout -b master_bug_2922_next
git am 0004*.patch
git checkout master
git merge master_bug_2922_next

And then push if all looks ok, then delete the topic branch.

If it's not the way you prefer to do things (lots of merge messages in
the history), then there are other ways of using rebase to get rid of
that, but I don't do those.

--
Regards...      Todd
I seek the truth...it is only persistence in self-delusion and
ignorance that does harm.  -- Marcus Aurealius