Re: Workflow question

From: Jeff King <peff@peff.net>
Date: Sep 26, 2007, 12:42 UTC
Message-ID: <20070926124243.GB13739@coredump.intra.peff.net>
In-Reply-To: <46F9CA2A.7000107@gmail.com>

On Tue, Sep 25, 2007 at 09:55:38PM -0500, Russ Brown wrote:

> Yes, this is very helpful indeed: thank you for that. /me bookmarks. I
> hadn't actually realised that rebase creates new commits and replaces
> your old ones: I'd thought they just got 'moved' (dunno how I thought it
> worked though!)

It's a necessity, since the commits are named by hash, and the hash encompasses _all_ of the history. So the same change at a different location in history will be a different commit.

And that is why rebases can make merging harder. Git can very quickly compare two commits by hash and say "these are the same commit", or look at them and say "one side has these changes, the other side has these other changes, and here is where they meet." Rebasing ruins that, since the same changes occur in two places with different names.

> I'm just wondering at this point why git lets you checkout remote
> tracking branches if it's something you really shouldn't do. Unless it's
> something you want to be able to do in edge cases to fix screwups maybe?

Junio explained in much more detail, but I use it largely for read-only access ("oh, let me speed-test my branch against the upstream 'master'"; git-checkout master; test test test; git-checkout mybranch).

Show 9 quoted lines

> Thanks for this, it's very useful to read examples of workflows in
> actual use. In fact, I was thinking the other day that it would be good
> to have a site that acts as a directory of many different workflows,
> including descriptions of how they work, how you actually go about
> setting it up and using it day to day (i.e. lists of commands for each
> role/task) and the pros/cons that it provides. I reckon that would help
> newbies out quite a bit (if only for the examples). I've seen a few
> individual examples of workflow but nothing like a comprehensive set of
> them.

I agree. That sort of information is sprinkled throughout the mailing list, but it might be nice on a wiki. I have thought of it as a sort of "git cookbook" where you say "here is a recipe for accomplishing X". The user manual comes close to this for smaller tasks.

-Peff