From: Junio C Hamano <junkio@cox.net>
To: linux@horizon.com
Cc: git@vger.kernel.org
Subject: Re: [DRAFT] Branching and merging with git
Date: Thu, 16 Nov 2006 15:47:19 -0800 [thread overview]
Message-ID: <7vslgj2bug.fsf@assigned-by-dhcp.cox.net> (raw)
In-Reply-To: <20061116221701.4499.qmail@science.horizon.com> (linux@horizon.com's message of "16 Nov 2006 17:17:01 -0500")
linux@horizon.com writes:
> I know it took me a while to get used to playing with branches, and I
> still get nervous when doing something creative. So I've been trying
> to get more comfortable, and wrote the following to document what I've
> learned.
>
> It's a first draft - I just finished writing it, so there are probably
> some glaring errors - but I thought it might be of interest anyway.
This is a greatest write-up I've seen for the past several
months. I find it very balanced to point out the quirks people
would find difficult and explain why things are so by including
historical notes in appropriate places when needed. Definitely
Documentation/ material when copyediting is done.
I have finished only the first half because it's not my git day
today, but so far...
> * Naming revisions
>...
> Second, you can refer to a head or tag name. Git looks in the
> following places, in order, for a head:
> 1) .git
> 2) .git/refs
> 3) .git/refs/heads
> 4) .git/refs/tags
You might want to check this with the array in sha1_name.c::get_sha1_basic().
I think tags comes earlier than heads.
> 2) Revert changes to a small number of files.
>
> git checkout [<revision>] [--] <paths>
> will copy the version of the <paths> from the index to the working
> directory. If a <revision> is given, the index for those paths will
> be updated from the given revision before copying from the index to
> the working tree.
>
> Unlike the version with no <paths> specified, this does NOT update
> HEAD, even if <paths> is ".".
It's great that you talk correctly about the latest feature-fix
that is queued for maint but not yet pushed out.
> 2) By path name. This is a feature which appears to be unique to git.
> If you give git-rev-list (or git-log, or gitk, or qgit) a list of
> pathname prefixes, it will list only commits which touch those
> paths. So "git log drivers/scsi include/scsi" will list only
> commits which alters a file whose name begins with drivers/scsi
> or include/scsi.
>
> (If there's any possible ambiguity between a path name and a commit
> name, git-rev-list will refuse to proceed. You can resolve it by
> including "--" on the command line. Everything before that is a
> commit name; everything after is a path.)
>
> This filter is in addition to the ancestry filter. It's also rather
> clever about omitting unnecessary detail. In particular, if there's
> a side branch which does touch drivers/scsi, then the entire branch,
> and the merge at the end, will be removed from the log.
"If there's a side branch which does NOT touch the paths..." I think.
> * Alternate branch naming
>
> The original git scheme mixes tracking branches with all the other heads.
> This requires that you remember which branches are tracking branches and
> which aren't. Hopefully, you remember what all your branches are for,
> but if you track a lot of remote repositories, you might not remember
> what every remote branch is for and what you called it locally.
I think you wanted to mention .git/refs/remotes hierarchy and
separate-remote here, but haven't elaborated yet...
> * Remote tags
>
> TODO: Figure out how remote tags work, under what circumstances
> they are fetched, and what git does if there are conflicts.
refs/tags namespace is not policed at all by git and is treated
as a global namespace, controlled mostly by social convention
that your "upstream" (or central distribution point) supplies
tags for people who use it to synchronize to share. Also, since
there is no guarantee that tags point at commits (v2.6.11-tree
tag is a pointer to a tree object, for example), there is no
farst-forward check performed for them.
The rule we use to autofollow tags currently is:
When you use shorthand fetch (or pull), we find tags that do not
exist locally, and if the object they point at are already found
in the repository then we fetch them automatically. So for
example, if you are only tracking my 'maint' and not 'master'
nor 'next', and if you have tags up to v1.4.3.2, your "git fetch
origin" would update your copy of 'maint' and bring the commits
reachable from the tip of my 'maint'. After that it notices
that v1.4.3.3, v1.4.3.4, v1.4.3.5 tags are in my repository but
missing from yours. It also notices that now you have
v1.4.3.3^{}, v1.4.3.4^{} and v1.4.3.5^{} in your repository, so
it issues another round of "git fetch" internally to fetch these
three tags. At the same time it would also notice that I have
v1.4.4 tag that you do not have, but v1.4.4^0 commit is not
something you would get by fetching 'maint', so it would not
fetch it automatically.
next prev parent reply other threads:[~2006-11-16 23:47 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 [this message]
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
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=7vslgj2bug.fsf@assigned-by-dhcp.cox.net \
--to=junkio@cox.net \
--cc=git@vger.kernel.org \
--cc=linux@horizon.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.
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).