Zsh Mailing List Archive
Messages sorted by: Reverse Date, Date, Thread, Author

Re: Access to CVS

Phil Pennock wrote:
> IF you want to make the code available on the server you cloned from as
> a branch, and accept that this involves a non-linear history (eg, a
> major feature change where it's worth keeping a more accurate history)
> then:

And if you just want do have a local branch, to do your work in and
still want to enforce linear history, you can use the same workflow as
Phil described. You just need to "replay" your changes on top of
"master". "git rebase" does that.

>   % git push origin feature_foo
>   [ do mailing-list stuff here ]
>   Switch back to master:
>   % git checkout master
>   and get the most recent changes:
>   % git pull

Switch back to the feature branch:

  % git checkout feature_foo

Rebase the feature branch on top of new changes that were just pulled:

  % git rebase master

This does the following (ASCII graphs from git's manual):

 Commit situation before the rebase:

                  A---B---C topic
     ...    D---E---F---G master

 And after:

                         A'--B'--C' topic
     ...    D---E---F---G master

This essentially replays the commits from the topic (or feature) branch
on top of master. That creates commits with different SHA1 sums, hence
the apostrophes with the rebased branch.

>   then bring in your changes:
>   % git merge feature_foo

That merge is a fast-forward then, because it just involves putting the
pointer of the master branch to the tip of the topic branch; because its
linear history again - no real merges involved at all.

>   % git commit
>   % git push
> git help tutorial
> git help tutorial-2
> git help gitcore-tutorial

Those are actually pretty helpful indeed.

Regards, Frank

In protocol design, perfection has been reached not when there is
nothing left to add, but when there is nothing left to take away.
                                                  -- RFC 1925

Messages sorted by: Reverse Date, Date, Thread, Author