From: linux@horizon.com
To: junkio@cox.net, linux@horizon.com
Cc: git@vger.kernel.org
Subject: Re: [DRAFT] Branching and merging with git
Date: 16 Nov 2006 22:17:47 -0500 [thread overview]
Message-ID: <20061117031747.30672.qmail@science.horizon.com> (raw)
In-Reply-To: <7vac2q281q.fsf@assigned-by-dhcp.cox.net>
Overall, thank you. I'm trying to merge all your comments
into the document to make it better, but there are enough that
it's taking me a while.
>> One outstanding problem with git's man pages is that often the most detail
>> is in the command page that was written first, not the user-friendly
>> one that you should use.
>
> This is a very important point to remember not for users but for
> us in git community. Thanks for writing it down.
There's a great example coming up, in the git-show
example you gave me. That's a very sparse man page...
> Dodecapus would find a few, no hits on doedecapus ;-).
Wups, thanks.
>> * Deleting branches
>>
>> "git branch -d <head>" is safe. It deletes the given <head>, but first
>> it checks that the commit is reachable some other way. That is, you
>> merged the branch in somewhere, or you never did any edits on that branch.
>
> It is not "somewhere" but "in the current branch", so in a sense
> it is a bit stricter than that. While on 'master' "branch -d
> topic" would not remove the topic branch head if it is not fully
> merged to my 'master' so that is a reasonable safety measure,
> but when I am on 'next' it will happily remove it. It is
> recoverable because it is reachable from 'next', though.
Oh! Thanks for the info. The limitation makes a certain
amount of sense, and as I'd never run into it, I'm not going to
complain.
> The reason is because 'git pull $url $branch' (typical Linus's
> use) and 'git pull' (defaulting to 'origin' and using the
> tracking branch mapping stored in .git/remotes/origin prepared
> by git-clone) are sign of very different workflows. The former
> tends to be a one-shot event while the latter is most often
> synchronizing with either an upstream or a common distribution
> point (i.e. shared central repostiory). When you are fetching
> from somebody in a one-shot manner, most likely as a part of
> 'pull', you do not want to get the tag the other person has made
> to mark his private work in progress. But in the latter case,
> the other end is where everybody who works in the same area
> fetches from, and sharing the tags found there among the
> developers by default is desirable, and more importantly there
> is no risk of accidentally getting private tags, since the other
> end is a public distribution point and by definition should not
> have private tags that would clutter your refs/tags hierarchy.
I'll work this in somehow, thanks.
> Here you _might_ want to mention an alternative workflow that
> uses rebase, which seems to be the way Wine folks run their
> project. Talking about all the different possibilities tends to
> cloud things and may not add value to the document, so I am just
> mentioning it as a possibility but I do not know if talking
> about rebase is useful in the context of this document.
Done, thanks.
>> The primitive that does the merging is called (guess what?) git-merge.
>> And you can use that if you want. If you want to create a so-called
>> octopus merge, with more than two parents, you have to.
>
> This is not true; "git pull . topicA topicB topicC" works as
> expected. But we probably would not want to even talk about
> Octopus in a document like this. It is a curosity, and
> sometimes tends to make histories even less cluttered, but
> otherwise it does not add much value.
Sorry; the SYNOPSIS line for git-pull had me fooled.
>> However, it's usually easier to use the git-pull wrapper. This merges
>> the changes from some other branch into the current HEAD and generates
>> a commit message automatically.
>>
>> git-merge lets you specify the commit message (rather than generating it
>> automatically) and use a non-HEAD destination branch, but those options
>> are usually more annoying than useful.
>
> I haven't tried for a long time, but I do not think non-HEAD
> destination even works at all. It might be better not to even
> mention git-merge at this point of the document.
Well, I want to at least say "you think so, wouldn't you?"
>> * How merging operates
>
> You might also want to mention that recursive first 3-way merges
> the renames. If O->A renames a path while O->B keeps it, the
> resulting stages are written under the new name.
Thanks! I wondered how that happened!
>> * When merging goes wrong
> Another tool to help the user decide how the mess should be
> sorted out is "git log --merge -- $path". It gives the logs of
> commits that touched the path while the two branches were forked.
The things I never knew about...
>> Git-rebase can also help you divide up work. Suppose you've mixed up
>> development of two features in the current HEAD, a branch called "dev".
>
> Ancestry graph before and after this procedure would help the
> reader a lot here.
I figured the (excellent) pictures in git-rebase would save me the
trouble, but yeah, I suppose so.
> They were conflicts during the virtual ancestor computation by
> recursive (the merge between 'a' and 'b' commits in your earlier
> example). When a virtual ancestor is created, it can textually
> have conflicted merge, but that is recorded along with conflict
> markers without manual resolving for obvious reasons. If two
> branches that use the virtual ancestor modifies the conflicted
> region the same way (because they needed to resolve that
> conflict in their branch), the final 3-way merge that uses the
> virtual ancestor as the merge-base will replace that conflicted
> region with their changes. This "even conflict markers can be
> eliminated by a merge resolution" behaviour is what inspired
> git-rerere, by the way.
Cool, thanks! I added mention of this.
> If you are using this particular commit as an example, you might
> also want to tell your readers about:
>
> git show -M 3f69d405
>
> (-M is there to make the output more readable, because this
> merge involved a few renames).
I'm wondering what the heck that does! I get a super-short diff with
no mention of any renames at all. Is this passed on to git-diff-tree?
What does "detect renames" mean if it doesn't tell me about them?
I'm actually confused.
diff --cc builtin-read-tree.c
index ec40d01,99e7c75..716f792
--- a/builtin-read-tree.c
+++ b/builtin-read-tree.c
@@@ -9,9 -9,9 +9,10 @@@
#include "object.h"
#include "tree.h"
+ #include "cache-tree.h"
#include <sys/time.h>
#include <signal.h>
+#include "builtin.h"
static int reset = 0;
next prev parent reply other threads:[~2006-11-17 3:18 UTC|newest]
Thread overview: 66+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-11-16 22:17 [DRAFT] Branching and merging with git linux
2006-11-16 23:47 ` Junio C Hamano
2006-11-17 1:13 ` linux
2006-11-17 1:31 ` Junio C Hamano
2006-11-17 1:09 ` Junio C Hamano
2006-11-17 3:17 ` linux [this message]
2006-11-17 5:55 ` Junio C Hamano
2006-11-17 9:37 ` Jakub Narebski
2006-11-17 9:41 ` Jakub Narebski
2006-11-17 10:37 ` Jakub Narebski
2006-11-17 15:32 ` Theodore Tso
2006-11-17 15:57 ` Sean
2006-11-17 16:19 ` Nguyen Thai Ngoc Duy
2006-11-17 16:25 ` Marko Macek
2006-11-17 16:33 ` Petr Baudis
2006-11-17 16:34 ` Sean
[not found] ` <20061117113404.810fd4ea.seanlkml@sympatico.ca>
2006-11-17 16:53 ` Petr Baudis
2006-11-17 17:01 ` Sean
[not found] ` <20061117120154.3eaf5611.seanlkml@sympatico.ca>
2006-11-17 21:31 ` Petr Baudis
2006-11-17 22:36 ` Chris Riddoch
2006-11-17 22:50 ` Petr Baudis
2006-11-17 23:30 ` Sean
2006-11-17 18:21 ` J. Bruce Fields
2006-11-18 0:13 ` linux
2006-11-18 0:32 ` Jakub Narebski
2006-11-18 0:40 ` Junio C Hamano
2006-11-18 1:11 ` Junio C Hamano
2006-11-20 23:51 ` [DRAFT 2] " linux
2006-11-22 11:02 ` [Patch to DRAFT 2 (1/2)] " Junio C Hamano
2006-11-22 11:02 ` [Patch to DRAFT 2 (2/2)] " Junio C Hamano
2006-11-22 13:36 ` Rene Scharfe
2006-12-04 1:19 ` [DRAFT 2] " J. Bruce Fields
2006-12-04 7:23 ` J. Bruce Fields
2006-12-04 10:56 ` Johannes Schindelin
2006-12-15 21:38 ` Jakub Narebski
2006-12-15 21:41 ` J. Bruce Fields
2006-11-22 11:51 ` [DRAFT] " Junio C Hamano
2006-11-19 17:50 ` J. Bruce Fields
2006-11-19 17:59 ` Git manuals Petr Baudis
2006-11-19 18:16 ` Jakub Narebski
2006-11-19 19:50 ` Robin Rosenberg
2006-11-19 19:36 ` J. Bruce Fields
2006-11-26 4:01 ` [PATCH] Documentation: add a "git user's manual" J. Bruce Fields
2006-11-17 17:44 ` [DRAFT] Branching and merging with git J. Bruce Fields
2006-11-17 18:16 ` Jakub Narebski
2007-01-03 17:04 ` Theodore Tso
2007-01-03 17:08 ` Junio C Hamano
2007-01-04 5:28 ` linux
2007-01-04 6:11 ` Junio C Hamano
2007-01-07 23:44 ` J. Bruce Fields
2007-01-08 0:24 ` Junio C Hamano
2007-01-08 2:35 ` J. Bruce Fields
2007-01-08 13:04 ` David Kågedal
2007-01-08 14:03 ` Theodore Tso
2007-01-09 2:41 ` J. Bruce Fields
2007-01-09 8:46 ` Andreas Ericsson
2007-01-09 15:49 ` J. Bruce Fields
2007-01-09 16:58 ` Theodore Tso
2007-01-10 4:15 ` J. Bruce Fields
2007-01-08 0:40 ` Theodore Tso
2007-01-08 0:46 ` J. Bruce Fields
2007-01-08 1:22 ` Jakub Narebski
2007-01-08 1:46 ` Horst H. von Brand
2007-01-08 2:22 ` J. Bruce Fields
2007-01-08 12:38 ` Guilhem Bonnefille
2007-01-09 4:17 ` J. Bruce Fields
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
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20061117031747.30672.qmail@science.horizon.com \
--to=linux@horizon.com \
--cc=git@vger.kernel.org \
--cc=junkio@cox.net \
/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.
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 NNTP newsgroup(s).