git@vger.kernel.org mailing list mirror (one of many)
 help / color / mirror / code / Atom feed
From: Jeff King <peff@peff.net>
To: Russ Brown <pickscrape@gmail.com>
Cc: git@vger.kernel.org
Subject: Re: Workflow question
Date: Wed, 26 Sep 2007 08:42:43 -0400	[thread overview]
Message-ID: <20070926124243.GB13739@coredump.intra.peff.net> (raw)
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).

> 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

  parent reply	other threads:[~2007-09-26 12:42 UTC|newest]

Thread overview: 25+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-09-25 16:43 Workflow question Russ Brown
2007-09-25 19:09 ` Andreas Ericsson
2007-09-25 19:34   ` Jeff King
2007-09-25 19:50     ` Wincent Colaiuta
2007-09-25 20:20       ` Jeff King
2007-09-25 20:37         ` Wincent Colaiuta
2007-09-25 19:42   ` Russ Brown
2007-09-25 20:17     ` Jeff King
2007-09-25 20:56       ` Russ Brown
2007-09-25 21:28         ` Junio C Hamano
2007-09-26  0:01           ` Russ Brown
2007-09-26  0:47         ` Jeff King
2007-09-26  1:51           ` Karl Hasselström
2007-09-26  2:55           ` Russ Brown
2007-09-26  5:29             ` Junio C Hamano
2007-09-26 12:42             ` Jeff King [this message]
2007-09-25 22:38     ` Andreas Ericsson
  -- strict thread matches above, loose matches on Subject: below --
2007-07-24 13:53 workflow question Patrick Doyle
2007-07-24 15:37 ` Alex Riesen
2007-07-24 16:30   ` Patrick Doyle
2007-07-24 16:35     ` Julian Phillips
2007-07-24 20:54       ` Alex Riesen
2007-07-24 20:57     ` Alex Riesen
2007-07-24 21:00       ` J. Bruce Fields
2007-07-24 21:38         ` Linus Torvalds

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: http://vger.kernel.org/majordomo-info.html

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20070926124243.GB13739@coredump.intra.peff.net \
    --to=peff@peff.net \
    --cc=git@vger.kernel.org \
    --cc=pickscrape@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://80x24.org/mirrors/git.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).