A note from the maintainer

A note from the maintainer

[Junio C Hamano]

Welcome to the Git development community.

This message is written by the maintainer and talks about how Git
project is managed, and how you can work with it.

* Mailing list and the community

The development is primarily done on the Git mailing list. Help
requests, feature proposals, bug reports and patches should be sent to
the list address <git@vger.kernel.org>.  You don't have to be
subscribed to send messages.  The convention on the list is to keep
everybody involved on Cc:, so it is unnecessary to say "Please Cc: me,
I am not subscribed".

Before sending patches, please read Documentation/SubmittingPatches
and Documentation/CodingGuidelines to familiarize yourself with the
project convention.

If you sent a patch and you did not hear any response from anybody for
several days, it could be that your patch was totally uninteresting,
but it also is possible that it was simply lost in the noise.  Please
do not hesitate to send a reminder message in such a case.  Messages
getting lost in the noise may be a sign that those who can evaluate
your patch don't have enough mental/time bandwidth to process them
right at the moment, and it often helps to wait until the list traffic
becomes calmer before sending such a reminder.

The list archive is available at a few public sites:

        http://news.gmane.org/gmane.comp.version-control.git/
        http://marc.info/?l=git
        http://www.spinics.net/lists/git/

For those who prefer to read it over NNTP:

        nntp://news.gmane.org/gmane.comp.version-control.git

When you point at a message in a mailing list archive, using
gmane is often the easiest to follow by readers, like this:

        http://thread.gmane.org/gmane.comp.version-control.git/27/focus=217

as it also allows people who subscribe to the mailing list as gmane
newsgroup to "jump to" the article.

Some members of the development community can sometimes be found on
the #git and #git-devel IRC channels on Freenode.  Their logs are
available at:

        http://colabti.org/irclogger/irclogger_log/git
        http://colabti.org/irclogger/irclogger_log/git-devel

There is a volunteer-run newsletter to serve our community ("Git Rev
News" http://git.github.io/rev_news/rev_news.html).

Git is a member project of software freedom conservancy, a non-profit
organization (https://sfconservancy.org/).  To reach a committee of
liaisons to the conservancy, contact them at <git@sfconservancy.org>.


* Reporting bugs

When you think git does not behave as you expect, please do not stop
your bug report with just "git does not work".  "I used git in this
way, but it did not work" is not much better, neither is "I used git
in this way, and X happend, which is broken".  It often is that git is
correct to cause X happen in such a case, and it is your expectation
that is broken. People would not know what other result Y you expected
to see instead of X, if you left it unsaid.

Please remember to always state

 - what you wanted to achieve;

 - what you did (the version of git and the command sequence to reproduce
   the behavior);

 - what you saw happen (X above);

 - what you expected to see (Y above); and

 - how the last two are different.

See http://www.chiark.greenend.org.uk/~sgtatham/bugs.html for further
hints.

If you think you found a security-sensitive issue and want to disclose
it to us without announcing it to wider public, please contact us at
our security mailing list <git-security@googlegroups.com>.


* Repositories and documentation.

My public git.git repositories are at:

  git://git.kernel.org/pub/scm/git/git.git/
  https://kernel.googlesource.com/pub/scm/git/git
  git://repo.or.cz/alt-git.git/
  https://github.com/git/git/
  git://git.sourceforge.jp/gitroot/git-core/git.git/
  git://git-core.git.sourceforge.net/gitroot/git-core/git-core/

A few web interfaces are found at:

  http://git.kernel.org/cgit/git/git.git
  https://kernel.googlesource.com/pub/scm/git/git
  http://repo.or.cz/w/alt-git.git

Preformatted documentation from the tip of the "master" branch can be
found in:

  git://git.kernel.org/pub/scm/git/git-{htmldocs,manpages}.git/
  git://repo.or.cz/git-{htmldocs,manpages}.git/
  https://github.com/gitster/git-{htmldocs,manpages}.git/

Also GitHub shows the manual pages formatted in HTML (with a
formatting backend different from the one that is used to create the
above) at:

  http://git-scm.com/docs/git


* How various branches are used.

There are four branches in git.git repository that track the source tree
of git: "master", "maint", "next", and "pu".

The "master" branch is meant to contain what are very well tested and
ready to be used in a production setting.  Every now and then, a
"feature release" is cut from the tip of this branch.  They used to be
named with three dotted decimal digits (e.g. "1.8.5"), but recently we
switched the versioning scheme and "feature releases" are named with
three-dotted decimal digits that ends with ".0" (e.g. "1.9.0").

The last such release was 2.7.0 done on Jan 4th, 2016. You can expect
that the tip of the "master" branch is always more stable than any of
the released versions.

Whenever a feature release is made, "maint" branch is forked off from
"master" at that point.  Obvious, safe and urgent fixes after a
feature release are applied to this branch and maintenance releases
are cut from it.  The maintenance releases used to be named with four
dotted decimal, named after the feature release they are updates to
(e.g. "1.8.5.1" was the first maintenance release for "1.8.5" feature
release).  These days, maintenance releases are named by incrementing
the last digit of three-dotted decimal name (e.g. "2.6.3" is the
third maintenance release for the "2.6" series).

New features never go to the 'maint' branch.  This branch is also
merged into "master" to propagate the fixes forward as needed.

A new development does not usually happen on "master". When you send a
series of patches, after review on the mailing list, a separate topic
branch is forked from the tip of "master" and your patches are queued
there, and kept out of "master" while people test it out. The quality of
topic branches are judged primarily by the mailing list discussions.

Topic branches that are in good shape are merged to the "next" branch. In
general, the "next" branch always contains the tip of "master".  It might
not be quite rock-solid, but is expected to work more or less without major
breakage. The "next" branch is where new and exciting things take place. A
topic that is in "next" is expected to be polished to perfection before it
is merged to "master".  Please help this process by building & using the
"next" branch for your daily work, and reporting any new bugs you find to
the mailing list, before the breakage is merged down to the "master".

The "pu" (proposed updates) branch bundles all the remaining topic
branches the maintainer happens to have seen.  There is no guarantee that
the maintainer has enough bandwidth to pick up any and all topics that
are remotely promising from the list traffic, so please do not read
too much into a topic being on (or not on) the "pu" branch.  This
branch is mainly to remind the maintainer that the topics in them may
turn out to be interesting when they are polished, nothing more.  The
topics on this branch aren't usually complete, well tested, or well
documented and they often need further work.  When a topic that was
in "pu" proves to be in a testable shape, it is merged to "next".

You can run "git log --first-parent master..pu" to see what topics are
currently in flight.  Sometimes, an idea that looked promising turns out
to be not so good and the topic can be dropped from "pu" in such a case.

The two branches "master" and "maint" are never rewound, and "next"
usually will not be either.  After a feature release is made from
"master", however, "next" will be rebuilt from the tip of "master"
using the topics that didn't make the cut in the feature release.

Note that being in "next" is not a guarantee to appear in the next
release, nor even in any future release.  There were cases that topics
needed reverting a few commits in them before graduating to "master",
or a topic that already was in "next" was reverted from "next" because
fatal flaws were found in it after it was merged to "next".


* Other people's trees.

Documentation/SubmittingPatches outlines to whom your proposed changes
should be sent.  As described in contrib/README, I would delegate fixes
and enhancements in contrib/ area to the primary contributors of them.

Although the following are included in git.git repository, they have their
own authoritative repository and maintainers:

 - git-gui/ comes from git-gui project, maintained by Pat Thoyts:

        git://repo.or.cz/git-gui.git

 - gitk-git/ comes from Paul Mackerras's gitk project:

        git://ozlabs.org/~paulus/gitk

 - po/ comes from the localization coordinator, Jiang Xin:

	https://github.com/git-l10n/git-po/

When sending proposed updates and fixes to these parts of the system,
please base your patches on these trees, not git.git (the former two
even have different directory structures).

A note from the maintainer

[Junio C Hamano]

I used to send this soon after each feature release, but somehow I
forgot for about a full year X-<.  Better late than never, I guess.

--- >8 ---
Welcome to the Git development community.

This message is written by the maintainer and talks about how Git
project is managed, and how you can work with it.

The current maintainer is Junio C Hamano <gitster@pobox.com>.  Spam
filters learned that legitimate messages come only from a very few
sender addresses that are known to be good to this address, and all
other messages are likely to be spam unless they are also sent to the
mailing list at the same time (i.e. "Reply-all" to the list message
would reach the mailbox, but "Reply" will likely be thrown into the
spam folder), so please do not send a message to this address unless
it is also sent to the mailing list as well.


* Mailing list and the community

The development is primarily done on the Git mailing list. Help
requests, feature proposals, bug reports and patches should be sent to
the list address <git@vger.kernel.org>.  You don't have to be
subscribed to send messages.  The convention on the list is to keep
everybody involved on Cc:, so it is unnecessary to say "Please Cc: me,
I am not subscribed".

As an anti-spam measure, the mailing list software rejects messages
that are not text/plain and drops them on the floor.  If you are a
GMail user, you'd want to make sure "Plain text mode" is checked.

Before sending patches, please read Documentation/SubmittingPatches
and Documentation/CodingGuidelines to familiarize yourself with the
project convention.

If you sent a patch and you did not hear any response from anybody for
several days, it could be that your patch was totally uninteresting,
but it also is possible that it was simply lost in the noise.  Please
do not hesitate to send a reminder message in such a case.  Messages
getting lost in the noise may be a sign that those who can evaluate
your patch don't have enough mental/time bandwidth to process them
right at the moment, and it often helps to wait until the list traffic
becomes calmer before sending such a reminder.

The list archive is available at a few public sites:

        https://lore.kernel.org/git/
        https://marc.info/?l=git
        https://www.spinics.net/lists/git/

For those who prefer to read it over NNTP:

	nntp://nntp.lore.kernel.org/org.kernel.vger.git
        nntp://news.public-inbox.org/inbox.comp.version-control.git

are available.

When you point at a message in a mailing list archive, using its
message ID is often the most robust (if not very friendly) way to do
so, like this:

	https://lore.kernel.org/git/Pine.LNX.4.58.0504150753440.7211@ppc970.osdl.org

Often these web interfaces accept the message ID with enclosing <>
stripped (like the above example to point at one of the most important
message in the Git list).

Some members of the development community can sometimes be found on
the #git and #git-devel IRC channels on Libera Chat.  Their logs are
available at:

        https://colabti.org/ircloggy/git/last
        https://colabti.org/ircloggy/git-devel/last

There is a volunteer-run newsletter to serve our community ("Git Rev
News" https://git.github.io/rev_news/).

Git is a member project of software freedom conservancy, a non-profit
organization (https://sfconservancy.org/).  To reach a committee of
liaisons to the conservancy, contact them at <git@sfconservancy.org>.

For our expectations on the behaviour of the community participants
towards each other, see CODE_OF_CONDUCT.md at the top level of the source
tree, or:

    https://github.com/git/git/blob/master/CODE_OF_CONDUCT.md


* Reporting bugs

When you think git does not behave as you expect, please do not stop
your bug report with just "git does not work".  "I used git in this
way, but it did not work" is not much better, neither is "I used git
in this way, and X happend, which is broken".  It often is that git is
correct to cause X happen in such a case, and it is your expectation
that is broken.  People would not know what other result Y you
expected to see instead of X, if you left it unsaid.

Please remember to always state

 - what you wanted to achieve;

 - what you did (the version of git and the command sequence to reproduce
   the behavior);

 - what you saw happen (X above);

 - what you expected to see (Y above); and

 - how the last two are different.

See https://www.chiark.greenend.org.uk/~sgtatham/bugs.html for further
hints.  Our `git bugreport` tool gives you a handy way you can use to
make sure you do not forget these points when filing a bug report.

If you think you found a security-sensitive issue and want to disclose
it to us without announcing it to wider public, please contact us at
our security mailing list <git-security@googlegroups.com>.  This is
a closed list that is limited to people who need to know early about
vulnerabilities, including:

  - people triaging and fixing reported vulnerabilities
  - people operating major git hosting sites with many users
  - people packaging and distributing git to large numbers of people

where these issues are discussed without risk of the information
leaking out before we're ready to make public announcements.


* Repositories and documentation.

My public git.git repositories are (mirrored) at:

  https://git.kernel.org/pub/scm/git/git.git/
  https://kernel.googlesource.com/pub/scm/git/git
  https://repo.or.cz/alt-git.git/
  https://github.com/git/git/
  https://gitlab.com/git-vcs/git/

This one shows not just the main integration branches, but also
individual topics broken out:

  https://github.com/gitster/git/

A few web interfaces are found at:

  https://git.kernel.org/pub/scm/git/git.git
  https://kernel.googlesource.com/pub/scm/git/git
  https://repo.or.cz/w/alt-git.git

Preformatted documentation from the tip of the "master" branch can be
found in:

  https://git.kernel.org/pub/scm/git/git-{htmldocs,manpages}.git/
  https://repo.or.cz/git-{htmldocs,manpages}.git/
  https://github.com/gitster/git-{htmldocs,manpages}.git/

The manual pages formatted in HTML for the tip of 'master' can be
viewed online at:

  https://git.github.io/htmldocs/git.html


* How various branches are used.

There are four "integration" branches in git.git repository that track
the source tree of git: "master", "maint", "next", and "seen".  They
however almost never get new commits made directly on them.  Instead,
a branch is forked from either "master" or "maint" for each "topic",
whether it is a new feature or a fix for a bug, and holds a set of
commits that belong to the same theme.  Such a "topic branch" is then
merged to these integration branches.

The "master" branch is meant to contain what are very well tested and
ready to be used in a production setting.  Every now and then, a
"feature release" is cut from the tip of this branch.  They used to be
named with three dotted decimal digits (e.g., "1.8.5"), but we have
switched the versioning scheme and "feature releases" are named with
three-dotted decimal digits that ends with ".0" (e.g., "1.9.0").

The last such release was 2.44 done on Feb 22nd, 2024.  We aim to keep
that the tip of the "master" branch is always more stable than any of
the released versions.

Whenever a feature release is made, "maint" branch is forked off from
"master" at that point.  Obvious and safe fixes after a feature
release are merged to this branch and maintenance releases are cut
from it.  Usually the topic branches that contain these fixes are
merged to the "master" branch first, before getting merged to the
"maint" branch, to reduce the chance of last-minute issues, but
things like embargoed security fixes may first appear in the "maint"
and merged up to "master" at the same time.  The maintenance releases
used to be named with four dotted decimal, named after the feature
release they are updates to (e.g., "1.8.5.1" was the first maintenance
release for "1.8.5" feature release).  These days, maintenance releases
are named by incrementing the last digit of three-dotted decimal name
(e.g., "2.43.2" was the second maintenance release for the "2.43" series).

New features almost never go to the "maint" branch.  It is merged into
"master" primarily to propagate the description in the release notes
forward.

When you send a series of patches, after review discussions on the
mailing list, a separate topic branch is forked from the tip of
"master" (or somewhere older, especially when the topic is about
fixing an earlier bug) and your patches are applied on that topic
branch, and kept out of "master" while people test it out.  The
quality of topic branches are judged primarily by the mailing list
discussions.

Topic branches that are in good shape are merged to the "next" branch.
The "next" branch is where new and exciting things take place.  In
general, the "next" branch always contains the tip of "master".  It
might not be quite rock-solid, but is expected to work more or less
without major breakage.  A topic that is in "next" is expected to be
polished to perfection before it is merged to "master".  Please help
this process by building & using the "next" branch for your daily
work, and reporting any new bugs you find to the mailing list, before
the breakage is merged down to the "master".

The "seen" (formerly "pu", proposed updates) branch bundles the
remaining topic branches the maintainer happens to have seen to remind
the maintainer that the topics in them might become interesting when
they are polished.

The contributors can use it to anticipate what topics from others
may cause conflict with their own work, and find people who are
working on these topics to talk to before the potential conflicts
get out of control.  It would be a good idea to fork from maint or
master to grow a topic and to test (1) it by itself, (2) a temporary
merge of it to 'next' and (3) a temporary merge to it to 'seen',
before publishing it.

Consider that a topic only in "seen" is not part of "git" yet.  When a
topic that was in "seen" proves to be in a testable shape, it is
merged to "next".

You can run "git log --first-parent master..seen" to see what topics
are currently in flight.  Sometimes, a topic that looked promising
proves to be a bad idea and the topic gets dropped from "seen" in such
a case.  The output of the above "git log" talks about a "jch" branch,
which is an early part of the "seen" branch; that branch contains all
topics that are in "next" and a bit more (but not all of "seen") and
is used by the maintainer for his daily work.

The two branches "master" and "maint" are never rewound, and "next"
usually will not be either.  After a feature release is made from
"master", however, "next" will be rebuilt from the tip of "master"
using the topics that didn't make the cut in the feature release.
Some topics that used to be in "next" during the previous cycle may
get ejected from "next" when this happens.

A natural consequence of how "next" and "seen" bundles topics together
is that until a topic is merged to "next", updates to it is expected
by replacing the patch(es) in the topic with an improved version, and
once a topic is merged to "next", updates to it needs to come as
incremental patches, pointing out what was wrong in the previous
patches and how the problem was corrected.  The idea is that if many
reviewers thought it has seen enough eyeballs and is good enough for
"next", yet we later find that there was something we all missed, that
is worth a separate explanation, e.g., "The primary motivation behind
the series is still good, but for such and such reasons we missed this
case we are fixing.", hence we prefer follow-up incremental patches.

Note that being in "next" is not a guarantee to appear in the next
release, nor even in any future release.  There were cases that topics
needed reverting a few commits in them before graduating to "master",
or a topic that already was in "next" was reverted from "next" because
fatal flaws were found in it after it was merged to "next".


* Other people's trees.

Documentation/SubmittingPatches outlines to whom your proposed changes
should be sent.  As described in contrib/README, I would delegate fixes
and enhancements in contrib/ area to the primary contributors of them.

Although the following are included in git.git repository, they have their
own authoritative repository and maintainers:

 - git-gui/ comes from git-gui project, maintained by Pratyush Yadav:

        https://github.com/prati0100/git-gui.git

 - gitk-git/ comes from Paul Mackerras's gitk project:

        git://ozlabs.org/~paulus/gitk

 - po/ comes from the localization coordinator, Jiang Xin:

	https://github.com/git-l10n/git-po/

When sending proposed updates and fixes to these parts of the system,
please base your patches on these trees, not git.git (the former two
even have different directory structures).

Re: A note from the maintainer

[Brian Lyles]

Hi Junio

On Wed, Mar 20, 2024 at 11:18 AM Junio C Hamano <gitster@pobox.com> wrote:

> If you sent a patch and you did not hear any response from anybody for
> several days, it could be that your patch was totally uninteresting,
> but it also is possible that it was simply lost in the noise. Please
> do not hesitate to send a reminder message in such a case.  Messages
> getting lost in the noise may be a sign that those who can evaluate
> your patch don't have enough mental/time bandwidth to process them
> right at the moment, and it often helps to wait until the list traffic
> becomes calmer before sending such a reminder.

I think it would be good to revise this wording in future iterations.
"Totally uninteresting" is a bit ambiguous, and also sounds quite
negative (at least to me).

To me, this initially sounded like it meant "your patch was not
something that the git maintainers would be interested in accepting". I
*suspect* that what is actually meant here is "your patch was
straightforward and non-controversial to the point that no members of
the list saw it and felt the need to comment on it", though to be honest
I am not 100% sure.

If it is expected that a "totally uninteresting" patch might, in fact,
end up in your tree without further comment, I think it could be helpful
to indicate that as well.

Here is what comes to my mind based on my (very likely not full)
understanding of the process:

    If you have sent a patch to the list and have not heard any response
	for several days, a few things may have happened:
	
	- Your patch was straightforward and non-controversial, so no
	  members of the list felt the need to comment on it
	- The members of the list that would review your patch do not have
	  the time to process them at the moment
	- Your patch was simply lost in the noise

	If you are unsure, keep an eye on the next few "What's cooking in
	git.git" emails. If your patch does not make an appearance there
	within a week or so, you may want to send out a reminder. It often
	helps to wait until the list traffic becomes calmer before sending a
	reminder.

I don't know how accurate that actually is, but I think it conveys the
tone and clarity that I am getting at.

-- 
Thank you,
Brian Lyles

Re: A note from the maintainer

[Junio C Hamano]

"Brian Lyles" <brianmlyles@gmail.com> writes:

> To me, this initially sounded like it meant "your patch was not
> something that the git maintainers would be interested in accepting". I
> *suspect* that what is actually meant here is "your patch was
> straightforward and non-controversial to the point that no members of
> the list saw it and felt the need to comment on it", though to be honest
> I am not 100% sure.

I actually meant what I wrote.

It is possible that the reason why your patch did not receive any
response was because it was uninspiring, looked useless, and did not
deserve anybody's attention.  But it is also possible that it was
lost in the noise.

And pinging on the topic by responding to your own message is not
just acceptable but very much appreciated way to remind others who
may have missed it, in case it is the latter.

If a topic is truly obvious and straight-forward, it may be taken
silently to 'seen' and even to 'next', and since it is suggested for
the contributors to look at "master..seen", such a topic would not
fall into the "hear nothing about it from anybody for a long time"
category anyway.

Re: A note from the maintainer

[Brian Lyles]

On Wed, Mar 20, 2024 at 8:01 PM Junio C Hamano <gitster@pobox.com> wrote:

> "Brian Lyles" <brianmlyles@gmail.com> writes:
> 
>> To me, this initially sounded like it meant "your patch was not
>> something that the git maintainers would be interested in accepting". I
>> *suspect* that what is actually meant here is "your patch was
>> straightforward and non-controversial to the point that no members of
>> the list saw it and felt the need to comment on it", though to be honest
>> I am not 100% sure.
> 
> I actually meant what I wrote.
> 
> It is possible that the reason why your patch did not receive any
> response was because it was uninspiring, looked useless, and did not
> deserve anybody's attention.  But it is also possible that it was
> lost in the noise.
> 
> And pinging on the topic by responding to your own message is not
> just acceptable but very much appreciated way to remind others who
> may have missed it, in case it is the latter.
> 
> If a topic is truly obvious and straight-forward, it may be taken
> silently to 'seen' and even to 'next', and since it is suggested for
> the contributors to look at "master..seen", such a topic would not
> fall into the "hear nothing about it from anybody for a long time"
> category anyway.

Thanks for the clarification. I do still think that a change in the
wording and tone of this section could help make the project appear more
friendly to new contributors. Phrases like "totally uninteresting",
"uninspiring", "looked useless", and "did not deserve anybody's
attention" are all fairly harsh sounding, even if sometimes true.

Something more along the lines of "Mailing list members may not have
seen the value of the proposed changes" or "Your patch may not have
presented a convincing argument for being accepted" might land a little
more gently and make someone more willing to make another attempt at a
more compelling patch rather than feeling harshly rejected and leaving
with a bad taste in their mouth about the project like has happened in
the past [1].

[1]: https://lore.kernel.org/git/xmqq7ck7x10y.fsf@gitster.g/

Simply food for thought from someone relatively new to the list.

-- 
Thank you,
Brian Lyles

Re: A note from the maintainer

[Junio C Hamano]

"Brian Lyles" <brianmlyles@gmail.com> writes:

>> I actually meant what I wrote.
>> 
>> It is possible that the reason why your patch did not receive any
>> response was because it was uninspiring, looked useless, and did not
>> deserve anybody's attention.  But it is also possible that it was
>> lost in the noise.
>> ...
> Thanks for the clarification. I do still think that a change in the
> wording and tone of this section could help make the project appear more
> friendly to new contributors. Phrases like "totally uninteresting",
> "uninspiring", "looked useless", and "did not deserve anybody's
> attention" are all fairly harsh sounding, even if sometimes true.

You completely lost me.  How much harsh words are used before "But
it is also possible" would not make the project sound less friendly
at all.

Let me try again.

You see your patch was sent but did not receive any reaction.  You
might start thinking: "hmm, perhaps my patch was so horrible" and
you might think all the bad and harsh things about the quality of
your patch.

But do not let such thought stop you from pinging the thread again,
because the quality of your patch may not at all be the reason why
you did not receive any reaction.  It could be just people were
swamped and your patch fell into cracks, and there was nothing wrong
with it.

Re: A note from the maintainer

[Brian Lyles]

> "Brian Lyles" <brianmlyles@gmail.com> writes:
> 
>>> I actually meant what I wrote.
>>> 
>>> It is possible that the reason why your patch did not receive any
>>> response was because it was uninspiring, looked useless, and did not
>>> deserve anybody's attention.  But it is also possible that it was
>>> lost in the noise.
>>> ...
>> Thanks for the clarification. I do still think that a change in the
>> wording and tone of this section could help make the project appear more
>> friendly to new contributors. Phrases like "totally uninteresting",
>> "uninspiring", "looked useless", and "did not deserve anybody's
>> attention" are all fairly harsh sounding, even if sometimes true.
> 
> You completely lost me.  How much harsh words are used before "But
> it is also possible" would not make the project sound less friendly
> at all.
> 
> Let me try again.
> 
> You see your patch was sent but did not receive any reaction.  You
> might start thinking: "hmm, perhaps my patch was so horrible" and
> you might think all the bad and harsh things about the quality of
> your patch.
> 
> But do not let such thought stop you from pinging the thread again,
> because the quality of your patch may not at all be the reason why
> you did not receive any reaction.  It could be just people were
> swamped and your patch fell into cracks, and there was nothing wrong
> with it.

Ah, okay -- I think I am better understanding the intent vs. how I
(mis)interpreted it initially. My initial interpretation was more along
the lines of "there are two possibilities: Either it was uninteresting,
or it got missed". This re-phrasing reads more as "don't assume it was
uninteresting, it may have simply been missed". Both true, but the
latter reads better in my opinion.

Thank you for clarifying. I will let you decide if some updated wording
is warranted in future notes from the maintainer, or if I simply
interpreted things in a way that you do not think others would.

-- 
Thank you,
Brian Lyles

Re: A note from the maintainer

[Junio C Hamano]

"Brian Lyles" <brianmlyles@gmail.com> writes:

> Thank you for clarifying. I will let you decide if some updated wording
> is warranted in future notes from the maintainer, or if I simply
> interpreted things in a way that you do not think others would.

Perhaps like this, then?

diff --git a/MaintNotes b/MaintNotes
index 57aa6dd..18d8bcb 100644
--- a/MaintNotes
+++ b/MaintNotes
@@ -34,8 +34,8 @@ and Documentation/CodingGuidelines to familiarize yourself with the
 project convention.
 
 If you sent a patch and you did not hear any response from anybody for
-several days, it could be that your patch was totally uninteresting,
-but it also is possible that it was simply lost in the noise.  Please
+several days, it does not necessarily mean that your patch was totally
+uninteresting; it may mearly mean that it was lost in the noise.  Please
 do not hesitate to send a reminder message in such a case.  Messages
 getting lost in the noise may be a sign that those who can evaluate
 your patch don't have enough mental/time bandwidth to process them

Re: A note from the maintainer

[Brian Lyles]

Hi Junio

On Thu, Mar 21, 2024 at 9:06 PM Junio C Hamano <gitster@pobox.com> wrote:

> "Brian Lyles" <brianmlyles@gmail.com> writes:
> 
>> Thank you for clarifying. I will let you decide if some updated wording
>> is warranted in future notes from the maintainer, or if I simply
>> interpreted things in a way that you do not think others would.
> 
> Perhaps like this, then?
> 
> diff --git a/MaintNotes b/MaintNotes
> index 57aa6dd..18d8bcb 100644
> --- a/MaintNotes
> +++ b/MaintNotes
> @@ -34,8 +34,8 @@ and Documentation/CodingGuidelines to familiarize yourself with the
>  project convention.
>  
>  If you sent a patch and you did not hear any response from anybody for
> -several days, it could be that your patch was totally uninteresting,
> -but it also is possible that it was simply lost in the noise.  Please
> +several days, it does not necessarily mean that your patch was totally
> +uninteresting; it may mearly mean that it was lost in the noise.  Please
>  do not hesitate to send a reminder message in such a case.  Messages
>  getting lost in the noise may be a sign that those who can evaluate
>  your patch don't have enough mental/time bandwidth to process them

I think that makes the intended meaning much clearer. Minor spelling
correction: s/mearly/merely/

-- 
Thank you,
Brian Lyles

Re: A note from the maintainer

[Junio C Hamano]

"Brian Lyles" <brianmlyles@gmail.com> writes:

> I think that makes the intended meaning much clearer. Minor spelling
> correction: s/mearly/merely/

Thanks.

A note from the maintainer

[Junio C Hamano]

Welcome to the Git development community.

This message is written by the maintainer and talks about how Git
project is managed, and how you can work with it.

The current maintainer is Junio C Hamano <gitster@pobox.com>; please
do not send any message to this address unless it also goes to the
mailing list, because it is likely that such a message will not be
seen by any human being.  Spam filters learned that legitimate
messages to the address come only from a very few sender addresses
that are known to be good, and messages from all others are likely to
be spam unless they are also sent to the mailing list at the same time
(i.e. "Reply-all" to the list message would reach the mailbox, but
"Reply" will likely be thrown into the spam folder).


* Mailing list and the community

The development is primarily done on the Git mailing list. Help
requests, feature proposals, bug reports and patches should be sent to
the list address <git@vger.kernel.org>.  You don't have to be
subscribed to send messages.  The convention on the list is to keep
everybody involved on Cc:, so it is unnecessary to say "Please Cc: me,
I am not subscribed".

As an anti-spam measure, the mailing list software rejects messages
that are not text/plain and drops them on the floor.  If you are a
GMail user, you'd want to make sure "Plain text mode" is checked.

Before sending patches, please read Documentation/SubmittingPatches
and Documentation/CodingGuidelines to familiarize yourself with the
project convention.

If you sent a patch and you did not hear any response from anybody for
several days, it could be that your patch was totally uninteresting,
but it also is possible that it was simply lost in the noise.  Please
do not hesitate to send a reminder message in such a case.  Messages
getting lost in the noise may be a sign that those who can evaluate
your patch don't have enough mental/time bandwidth to process them
right at the moment, and it often helps to wait until the list traffic
becomes calmer before sending such a reminder.

The list archive is available at a few public sites:

        http://lore.kernel.org/git/
        http://marc.info/?l=git
        http://www.spinics.net/lists/git/

For those who prefer to read it over NNTP:

	nntp://nntp.lore.kernel.org/org.kernel.vger.git
        nntp://news.public-inbox.org/inbox.comp.version-control.git

are available.

When you point at a message in a mailing list archive, using its
message ID is often the most robust (if not very friendly) way to do
so, like this:

	http://lore.kernel.org/git/Pine.LNX.4.58.0504150753440.7211@ppc970.osdl.org

Often these web interfaces accept the message ID with enclosing <>
stripped (like the above example to point at one of the most important
message in the Git list).

Some members of the development community can sometimes be found on
the #git and #git-devel IRC channels on Libera Chat.  Their logs are
available at:

        http://colabti.org/irclogger/irclogger_log/git
        http://colabti.org/irclogger/irclogger_log/git-devel

There is a volunteer-run newsletter to serve our community ("Git Rev
News" http://git.github.io/rev_news/).

Git is a member project of software freedom conservancy, a non-profit
organization (https://sfconservancy.org/).  To reach a committee of
liaisons to the conservancy, contact them at <git@sfconservancy.org>.

For our expectations on the behaviour of the community participants
towards each other, see CODE_OF_CONDUCT.md at the top level of the source
tree, or:

    https://github.com/git/git/blob/master/CODE_OF_CONDUCT.md


* Reporting bugs

When you think git does not behave as you expect, please do not stop
your bug report with just "git does not work".  "I used git in this
way, but it did not work" is not much better, neither is "I used git
in this way, and X happend, which is broken".  It often is that git is
correct to cause X happen in such a case, and it is your expectation
that is broken. People would not know what other result Y you expected
to see instead of X, if you left it unsaid.

Please remember to always state

 - what you wanted to achieve;

 - what you did (the version of git and the command sequence to reproduce
   the behavior);

 - what you saw happen (X above);

 - what you expected to see (Y above); and

 - how the last two are different.

See http://www.chiark.greenend.org.uk/~sgtatham/bugs.html for further
hints.  Our `git bugreport` tool gives you a handy way you can use to
make sure you do not forget these points when filing a bug report.

If you think you found a security-sensitive issue and want to disclose
it to us without announcing it to wider public, please contact us at
our security mailing list <git-security@googlegroups.com>.  This is
a closed list that is limited to people who need to know early about
vulnerabilities, including:

  - people triaging and fixing reported vulnerabilities
  - people operating major git hosting sites with many users
  - people packaging and distributing git to large numbers of people

where these issues are discussed without risk of the information
leaking out before we're ready to make public announcements.


* Repositories and documentation.

My public git.git repositories are (mirrored) at:

  https://git.kernel.org/pub/scm/git/git.git/
  https://kernel.googlesource.com/pub/scm/git/git
  https://repo.or.cz/alt-git.git/
  https://github.com/git/git/
  https://gitlab.com/git-vcs/git/

This one shows not just the main integration branches, but also
individual topics broken out:

  https://github.com/gitster/git/

A few web interfaces are found at:

  http://git.kernel.org/pub/scm/git/git.git
  https://kernel.googlesource.com/pub/scm/git/git
  http://repo.or.cz/w/alt-git.git

Preformatted documentation from the tip of the "master" branch can be
found in:

  https://git.kernel.org/pub/scm/git/git-{htmldocs,manpages}.git/
  https://repo.or.cz/git-{htmldocs,manpages}.git/
  https://github.com/gitster/git-{htmldocs,manpages}.git/

The manual pages formatted in HTML for the tip of 'master' can be
viewed online at:

  https://git.github.io/htmldocs/git.html


* How various branches are used.

There are four "integration" branches in git.git repository that track
the source tree of git: "master", "maint", "next", and "seen".  They
however almost never get new commits made directly on them.  Instead,
a branch is forked from either "master" or "maint" for each "topic",
whether it is a new feature or fix for a bug, and holds a set of
commits that belong to the same theme, and then such a "topic branch"
is merged to these integration branches.

The "master" branch is meant to contain what are very well tested and
ready to be used in a production setting.  Every now and then, a
"feature release" is cut from the tip of this branch.  They used to be
named with three dotted decimal digits (e.g. "1.8.5"), but we have
switched the versioning scheme and "feature releases" are named with
three-dotted decimal digits that ends with ".0" (e.g. "1.9.0").

The last such release was 2.40 done on Mar 13rd, 2023.  You can expect
that the tip of the "master" branch is always more stable than any of
the released versions.

Whenever a feature release is made, "maint" branch is forked off from
"master" at that point.  Obvious and safe fixes after a feature
release are merged to this branch and maintenance releases are cut
from it.  Usually these fixes are merged to the "master" branch first,
several days before merged to the "maint" branch, to reduce the chance
of last-minute issues, but things like embargoed security fixes may
first appear in the maintenance tracks and merged up to "master" at
the same time.  The maintenance releases used to be named with
four dotted decimal, named after the feature release they are updates
to (e.g. "1.8.5.1" was the first maintenance release for "1.8.5"
feature release).  These days, maintenance releases are named by
incrementing the last digit of three-dotted decimal name (e.g.
"2.29.2" was the second maintenance release for the "2.29" series).

New features never go to the "maint" branch.  It is merged into
"master" primarily to propagate the description in the release notes
forward.

A new development does not usually happen on "master". When you send a
series of patches, after review on the mailing list, a separate topic
branch is forked from the tip of "master" (or somewhere older, especially
when the topic is about fixing an earlier bug) and your patches are queued
there, and kept out of "master" while people test it out. The quality of
topic branches are judged primarily by the mailing list discussions.

Topic branches that are in good shape are merged to the "next" branch. In
general, the "next" branch always contains the tip of "master".  It might
not be quite rock-solid, but is expected to work more or less without major
breakage. The "next" branch is where new and exciting things take place. A
topic that is in "next" is expected to be polished to perfection before it
is merged to "master".  Please help this process by building & using the
"next" branch for your daily work, and reporting any new bugs you find to
the mailing list, before the breakage is merged down to the "master".

The "seen" (formerly "pu", proposed updates) branch bundles all the
remaining topic branches the maintainer happens to have seen.  There
is no guarantee that the maintainer has enough bandwidth to pick up any
and all topics that are remotely promising from the list traffic, so
please do not read too much into a topic being on (or not on) the "seen"
branch.  This branch is mainly to remind the maintainer that the topics
in them may turn out to be interesting when they are polished, nothing
more, but can be used by contributors to anticipate what topics from
others may cause conflict with your work, and find people who are working.
on these topics to talk to before the potential conflicts get out of
control. The topics on this branch aren't usually complete, well tested,
or well documented and they often need further work.  When a topic that
was in "seen" proves to be in a testable shape, it is merged to "next".

You can run "git log --first-parent master..seen" to see what topics are
currently in flight.  Sometimes, an idea that looked promising turns out
to be not so good and the topic can be dropped from "seen" in such a case.
The output of the above "git log" talks about a "jch" branch, which is an
early part of the "seen" branch; that branch contains all topics that
are in "next" and a bit more (but not all of "seen") and is used by the
maintainer for his daily work.  Using the tip of this branch, instead of
'next', as your daily driver is also recommended.

The two branches "master" and "maint" are never rewound, and "next"
usually will not be either.  After a feature release is made from
"master", however, "next" will be rebuilt from the tip of "master"
using the topics that didn't make the cut in the feature release.
Some topics that used to be in "next" during the previous cycle may
get ejected from "next" when this happens.

A natural consequence of how "next" and "seen" bundles topics together
is that until a topic is merged to "next", updates to it is expected
by replacing the patch(es) in the topic with an improved version,
and once a topic is merged to "next", updates to it needs to come as
incremental patches, pointing out what was wrong in the previous
patches and how the problem was corrected.

Note that being in "next" is not a guarantee to appear in the next
release, nor even in any future release.  There were cases that topics
needed reverting a few commits in them before graduating to "master",
or a topic that already was in "next" was reverted from "next" because
fatal flaws were found in it after it was merged to "next".


* Other people's trees.

Documentation/SubmittingPatches outlines to whom your proposed changes
should be sent.  As described in contrib/README, I would delegate fixes
and enhancements in contrib/ area to the primary contributors of them.

Although the following are included in git.git repository, they have their
own authoritative repository and maintainers:

 - git-gui/ comes from git-gui project, maintained by Pratyush Yadav:

        https://github.com/prati0100/git-gui.git

 - gitk-git/ comes from Paul Mackerras's gitk project:

        git://ozlabs.org/~paulus/gitk

 - po/ comes from the localization coordinator, Jiang Xin:

	https://github.com/git-l10n/git-po/

When sending proposed updates and fixes to these parts of the system,
please base your patches on these trees, not git.git (the former two
even have different directory structures).

A note from the maintainer

[Junio C Hamano]

Welcome to the Git development community.

This message is written by the maintainer and talks about how Git
project is managed, and how you can work with it.

The current maintainer is Junio C Hamano <gitster@pobox.com>; please
do not send any message to this address unless it also goes to the
mailing list, because it is likely that such a message will not be
seen by any human being.  Spam filters learned that legitimate
messages to the address come only from a very few sender addresses
that are known to be good, and messages from all others are likely to
be spam unless they are also sent to the mailing list at the same time
(i.e. "Reply-all" to the list message would reach the mailbox, but
"Reply" will likely be thrown into the spam folder).


* Mailing list and the community

The development is primarily done on the Git mailing list. Help
requests, feature proposals, bug reports and patches should be sent to
the list address <git@vger.kernel.org>.  You don't have to be
subscribed to send messages.  The convention on the list is to keep
everybody involved on Cc:, so it is unnecessary to say "Please Cc: me,
I am not subscribed".

As an anti-spam measure, the mailing list software rejects messages
that are not text/plain and drops them on the floor.  If you are a
GMail user, you'd want to make sure "Plain text mode" is checked.

Before sending patches, please read Documentation/SubmittingPatches
and Documentation/CodingGuidelines to familiarize yourself with the
project convention.

If you sent a patch and you did not hear any response from anybody for
several days, it could be that your patch was totally uninteresting,
but it also is possible that it was simply lost in the noise.  Please
do not hesitate to send a reminder message in such a case.  Messages
getting lost in the noise may be a sign that those who can evaluate
your patch don't have enough mental/time bandwidth to process them
right at the moment, and it often helps to wait until the list traffic
becomes calmer before sending such a reminder.

The list archive is available at a few public sites:

        http://lore.kernel.org/git/
        http://marc.info/?l=git
        http://www.spinics.net/lists/git/

For those who prefer to read it over NNTP:

	nntp://nntp.lore.kernel.org/org.kernel.vger.git
        nntp://news.public-inbox.org/inbox.comp.version-control.git

are available.

When you point at a message in a mailing list archive, using its
message ID is often the most robust (if not very friendly) way to do
so, like this:

	http://lore.kernel.org/git/Pine.LNX.4.58.0504150753440.7211@ppc970.osdl.org

Often these web interfaces accept the message ID with enclosing <>
stripped (like the above example to point at one of the most important
message in the Git list).

Some members of the development community can sometimes be found on
the #git and #git-devel IRC channels on Libera Chat.  Their logs are
available at:

        http://colabti.org/irclogger/irclogger_log/git
        http://colabti.org/irclogger/irclogger_log/git-devel

There is a volunteer-run newsletter to serve our community ("Git Rev
News" http://git.github.io/rev_news/).

Git is a member project of software freedom conservancy, a non-profit
organization (https://sfconservancy.org/).  To reach a committee of
liaisons to the conservancy, contact them at <git@sfconservancy.org>.

For our expectations on the behaviour of the community participants
towards each other, see CODE_OF_CONDUCT.md at the top level of the source
tree, or:

    https://github.com/git/git/blob/master/CODE_OF_CONDUCT.md


* Reporting bugs

When you think git does not behave as you expect, please do not stop
your bug report with just "git does not work".  "I used git in this
way, but it did not work" is not much better, neither is "I used git
in this way, and X happend, which is broken".  It often is that git is
correct to cause X happen in such a case, and it is your expectation
that is broken. People would not know what other result Y you expected
to see instead of X, if you left it unsaid.

Please remember to always state

 - what you wanted to achieve;

 - what you did (the version of git and the command sequence to reproduce
   the behavior);

 - what you saw happen (X above);

 - what you expected to see (Y above); and

 - how the last two are different.

See http://www.chiark.greenend.org.uk/~sgtatham/bugs.html for further
hints.  Our `git bugreport` tool gives you a handy way you can use to
make sure you do not forget these points when filing a bug report.

If you think you found a security-sensitive issue and want to disclose
it to us without announcing it to wider public, please contact us at
our security mailing list <git-security@googlegroups.com>.  This is
a closed list that is limited to people who need to know early about
vulnerabilities, including:

  - people triaging and fixing reported vulnerabilities
  - people operating major git hosting sites with many users
  - people packaging and distributing git to large numbers of people

where these issues are discussed without risk of the information
leaking out before we're ready to make public announcements.


* Repositories and documentation.

My public git.git repositories are (mirrored) at:

  https://git.kernel.org/pub/scm/git/git.git/
  https://kernel.googlesource.com/pub/scm/git/git
  https://repo.or.cz/alt-git.git/
  https://github.com/git/git/
  https://gitlab.com/git-vcs/git/

This one shows not just the main integration branches, but also
individual topics broken out:

  https://github.com/gitster/git/

A few web interfaces are found at:

  http://git.kernel.org/pub/scm/git/git.git
  https://kernel.googlesource.com/pub/scm/git/git
  http://repo.or.cz/w/alt-git.git

Preformatted documentation from the tip of the "master" branch can be
found in:

  https://git.kernel.org/pub/scm/git/git-{htmldocs,manpages}.git/
  https://repo.or.cz/git-{htmldocs,manpages}.git/
  https://github.com/gitster/git-{htmldocs,manpages}.git/

The manual pages formatted in HTML for the tip of 'master' can be
viewed online at:

  https://git.github.io/htmldocs/git.html


* How various branches are used.

There are four "integration" branches in git.git repository that track
the source tree of git: "master", "maint", "next", and "seen".  They
however almost never get new commits made directly on them.  Instead,
a branch is forked from either "master" or "maint" for each "topic",
whether it is a new feature or fix for a bug, and holds a set of
commits that belong to the same theme, and then such a "topic branch"
is merged to these integration branches.

The "master" branch is meant to contain what are very well tested and
ready to be used in a production setting.  Every now and then, a
"feature release" is cut from the tip of this branch.  They used to be
named with three dotted decimal digits (e.g. "1.8.5"), but we have
switched the versioning scheme and "feature releases" are named with
three-dotted decimal digits that ends with ".0" (e.g. "1.9.0").

The last such release was 2.38 done on Oct 3rd, 2022.  You can expect
that the tip of the "master" branch is always more stable than any of
the released versions.

Whenever a feature release is made, "maint" branch is forked off from
"master" at that point.  Obvious and safe fixes after a feature
release are merged to this branch and maintenance releases are cut
from it.  Usually these fixes are merged to the "master" branch first,
several days before merged to the "maint" branch, to reduce the chance
of last-minute issues, but things like embargoed security fixes may
first appear in the maintenance tracks and merged up to "master" at
the same time.  The maintenance releases used to be named with
four dotted decimal, named after the feature release they are updates
to (e.g. "1.8.5.1" was the first maintenance release for "1.8.5"
feature release).  These days, maintenance releases are named by
incrementing the last digit of three-dotted decimal name (e.g.
"2.38.2" was the second maintenance release for the "2.38" series).

New features never go to the "maint" branch.  It is merged into
"master" primarily to propagate the description in the release notes
forward.

A new development does not usually happen on "master". When you send a
series of patches, after review on the mailing list, a separate topic
branch is forked from the tip of "master" (or somewhere older, especially
when the topic is about fixing an earlier bug) and your patches are queued
there, and kept out of "master" while people test it out. The quality of
topic branches are judged primarily by the mailing list discussions.

Topic branches that are in good shape are merged to the "next" branch. In
general, the "next" branch always contains the tip of "master".  It might
not be quite rock-solid, but is expected to work more or less without major
breakage. The "next" branch is where new and exciting things take place. A
topic that is in "next" is expected to be polished to perfection before it
is merged to "master".  Please help this process by building & using the
"next" branch for your daily work, and reporting any new bugs you find to
the mailing list, before the breakage is merged down to the "master".

The "seen" (formerly "pu", proposed updates) branch bundles all the
remaining topic branches the maintainer happens to have seen.  There
is no guarantee that the maintainer has enough bandwidth to pick up any
and all topics that are remotely promising from the list traffic, so
please do not read too much into a topic being on (or not on) the "seen"
branch.  This branch is mainly to remind the maintainer that the topics
in them may turn out to be interesting when they are polished, nothing
more.  The topics on this branch aren't usually complete, well tested,
or well documented and they often need further work.  When a topic that
was in "seen" proves to be in a testable shape, it is merged to "next".

You can run "git log --first-parent master..seen" to see what topics are
currently in flight.  Sometimes, an idea that looked promising turns out
to be not so good and the topic can be dropped from "seen" in such a case.
The output of the above "git log" talks about a "jch" branch, which is an
early part of the "seen" branch; that branch contains all topics that
are in "next" and a bit more (but not all of "seen") and is used by the
maintainer for his daily work.

The two branches "master" and "maint" are never rewound, and "next"
usually will not be either.  After a feature release is made from
"master", however, "next" will be rebuilt from the tip of "master"
using the topics that didn't make the cut in the feature release.
Some topics that used to be in "next" during the previous cycle may
get ejected from "next" when this happens.

A natural consequence of how "next" and "seen" bundles topics together
is that until a topic is merged to "next", updates to it is expected
by replacing the patch(es) in the topic with an improved version,
and once a topic is merged to "next", updates to it needs to come as
incremental patches, pointing out what was wrong in the previous
patches and how the problem was corrected.

Note that being in "next" is not a guarantee to appear in the next
release, nor even in any future release.  There were cases that topics
needed reverting a few commits in them before graduating to "master",
or a topic that already was in "next" was reverted from "next" because
fatal flaws were found in it after it was merged to "next".


* Other people's trees.

Documentation/SubmittingPatches outlines to whom your proposed changes
should be sent.  As described in contrib/README, I would delegate fixes
and enhancements in contrib/ area to the primary contributors of them.

Although the following are included in git.git repository, they have their
own authoritative repository and maintainers:

 - git-gui/ comes from git-gui project, maintained by Pratyush Yadav:

        https://github.com/prati0100/git-gui.git

 - gitk-git/ comes from Paul Mackerras's gitk project:

        git://ozlabs.org/~paulus/gitk

 - po/ comes from the localization coordinator, Jiang Xin:

	https://github.com/git-l10n/git-po/

When sending proposed updates and fixes to these parts of the system,
please base your patches on these trees, not git.git (the former two
even have different directory structures).

A note from the maintainer

[Junio C Hamano]

Welcome to the Git development community.

This message is written by the maintainer and talks about how Git
project is managed, and how you can work with it.

The current maintainer is Junio C Hamano <gitster@pobox.com>; please
do not send any message to this address unless it also goes to the
mailing list, because it is likely that such a message will not be
seen by any human being.  Spam filters learned that legitimate
messages to the address come only from a very few sender addresses
that are known to be good, and messages from all others are likely to
be spam unless they are also sent to the mailing list at the same time
(i.e. "Reply-all" to the list message would reach the mailbox, but
"Reply" will likely be thrown into the spam folder).


* Mailing list and the community

The development is primarily done on the Git mailing list. Help
requests, feature proposals, bug reports and patches should be sent to
the list address <git@vger.kernel.org>.  You don't have to be
subscribed to send messages.  The convention on the list is to keep
everybody involved on Cc:, so it is unnecessary to say "Please Cc: me,
I am not subscribed".

As an anti-spam measure, the mailing list software rejects messages
that are not text/plain and drops them on the floor.  If you are a
GMail user, you'd want to make sure "Plain text mode" is checked.

Before sending patches, please read Documentation/SubmittingPatches
and Documentation/CodingGuidelines to familiarize yourself with the
project convention.

If you sent a patch and you did not hear any response from anybody for
several days, it could be that your patch was totally uninteresting,
but it also is possible that it was simply lost in the noise.  Please
do not hesitate to send a reminder message in such a case.  Messages
getting lost in the noise may be a sign that those who can evaluate
your patch don't have enough mental/time bandwidth to process them
right at the moment, and it often helps to wait until the list traffic
becomes calmer before sending such a reminder.

The list archive is available at a few public sites:

        http://lore.kernel.org/git/
        http://marc.info/?l=git
        http://www.spinics.net/lists/git/

For those who prefer to read it over NNTP:

	nntp://nntp.lore.kernel.org/org.kernel.vger.git
        nntp://news.public-inbox.org/inbox.comp.version-control.git

are available.

When you point at a message in a mailing list archive, using its
message ID is often the most robust (if not very friendly) way to do
so, like this:

	http://lore.kernel.org/git/Pine.LNX.4.58.0504150753440.7211@ppc970.osdl.org

Often these web interfaces accept the message ID with enclosing <>
stripped (like the above example to point at one of the most important
message in the Git list).

Some members of the development community can sometimes be found on
the #git and #git-devel IRC channels on Libera Chat.  Their logs are
available at:

        http://colabti.org/irclogger/irclogger_log/git
        http://colabti.org/irclogger/irclogger_log/git-devel

There is a volunteer-run newsletter to serve our community ("Git Rev
News" http://git.github.io/rev_news/).

Git is a member project of software freedom conservancy, a non-profit
organization (https://sfconservancy.org/).  To reach a committee of
liaisons to the conservancy, contact them at <git@sfconservancy.org>.

For our expectations on the behaviour of the community participants
towards each other, see CODE_OF_CONDUCT.md at the top level of the source
tree, or:

    https://github.com/git/git/blob/master/CODE_OF_CONDUCT.md


* Reporting bugs

When you think git does not behave as you expect, please do not stop
your bug report with just "git does not work".  "I used git in this
way, but it did not work" is not much better, neither is "I used git
in this way, and X happend, which is broken".  It often is that git is
correct to cause X happen in such a case, and it is your expectation
that is broken. People would not know what other result Y you expected
to see instead of X, if you left it unsaid.

Please remember to always state

 - what you wanted to achieve;

 - what you did (the version of git and the command sequence to reproduce
   the behavior);

 - what you saw happen (X above);

 - what you expected to see (Y above); and

 - how the last two are different.

See http://www.chiark.greenend.org.uk/~sgtatham/bugs.html for further
hints.  Our `git bugreport` tool gives you a handy way you can use to
make sure you do not forget these points when filing a bug report.

If you think you found a security-sensitive issue and want to disclose
it to us without announcing it to wider public, please contact us at
our security mailing list <git-security@googlegroups.com>.  This is
a closed list that is limited to people who need to know early about
vulnerabilities, including:

  - people triaging and fixing reported vulnerabilities
  - people operating major git hosting sites with many users
  - people packaging and distributing git to large numbers of people

where these issues are discussed without risk of the information
leaking out before we're ready to make public announcements.


* Repositories and documentation.

My public git.git repositories are (mirrored) at:

  https://git.kernel.org/pub/scm/git/git.git/
  https://kernel.googlesource.com/pub/scm/git/git
  https://repo.or.cz/alt-git.git/
  https://github.com/git/git/
  https://gitlab.com/git-vcs/git/

This one shows not just the main integration branches, but also
individual topics broken out:

  https://github.com/gitster/git/

A few web interfaces are found at:

  http://git.kernel.org/pub/scm/git/git.git
  https://kernel.googlesource.com/pub/scm/git/git
  http://repo.or.cz/w/alt-git.git

Preformatted documentation from the tip of the "master" branch can be
found in:

  https://git.kernel.org/pub/scm/git/git-{htmldocs,manpages}.git/
  https://repo.or.cz/git-{htmldocs,manpages}.git/
  https://github.com/gitster/git-{htmldocs,manpages}.git/

The manual pages formatted in HTML for the tip of 'master' can be
viewed online at:

  https://git.github.io/htmldocs/git.html


* How various branches are used.

There are four "integration" branches in git.git repository that track
the source tree of git: "master", "maint", "next", and "seen".  They
however almost never get new commits made directly on them.  Instead,
a branch is forked from either "master" or "maint" for each "topic",
whether it is a new feature or fix for a bug, and holds a set of
commits that belong to the same theme, and then such a "topic branch"
is merged to these integration branches.

The "master" branch is meant to contain what are very well tested and
ready to be used in a production setting.  Every now and then, a
"feature release" is cut from the tip of this branch.  They used to be
named with three dotted decimal digits (e.g. "1.8.5"), but we have
switched the versioning scheme and "feature releases" are named with
three-dotted decimal digits that ends with ".0" (e.g. "1.9.0").

The last such release was 2.38 done on Oct 3rd, 2022.  You can expect
that the tip of the "master" branch is always more stable than any of
the released versions.

Whenever a feature release is made, "maint" branch is forked off from
"master" at that point.  Obvious and safe fixes after a feature
release are merged to this branch and maintenance releases are cut
from it.  Usually these fixes are merged to the "master" branch first,
several days before merged to the "maint" branch, to reduce the chance
of last-minute issues, but things like embargoed security fixes may
first appear in the maintenance tracks and merged up to "master" at
the same time.  The maintenance releases used to be named with
four dotted decimal, named after the feature release they are updates
to (e.g. "1.8.5.1" was the first maintenance release for "1.8.5"
feature release).  These days, maintenance releases are named by
incrementing the last digit of three-dotted decimal name (e.g.
"2.29.2" was the second maintenance release for the "2.29" series).

New features never go to the "maint" branch.  It is merged into
"master" primarily to propagate the description in the release notes
forward.

A new development does not usually happen on "master". When you send a
series of patches, after review on the mailing list, a separate topic
branch is forked from the tip of "master" (or somewhere older, especially
when the topic is about fixing an earlier bug) and your patches are queued
there, and kept out of "master" while people test it out. The quality of
topic branches are judged primarily by the mailing list discussions.

Topic branches that are in good shape are merged to the "next" branch. In
general, the "next" branch always contains the tip of "master".  It might
not be quite rock-solid, but is expected to work more or less without major
breakage. The "next" branch is where new and exciting things take place. A
topic that is in "next" is expected to be polished to perfection before it
is merged to "master".  Please help this process by building & using the
"next" branch for your daily work, and reporting any new bugs you find to
the mailing list, before the breakage is merged down to the "master".

The "seen" (formerly "pu", proposed updates) branch bundles all the
remaining topic branches the maintainer happens to have seen.  There
is no guarantee that the maintainer has enough bandwidth to pick up any
and all topics that are remotely promising from the list traffic, so
please do not read too much into a topic being on (or not on) the "seen"
branch.  This branch is mainly to remind the maintainer that the topics
in them may turn out to be interesting when they are polished, nothing
more.  The topics on this branch aren't usually complete, well tested,
or well documented and they often need further work.  When a topic that
was in "seen" proves to be in a testable shape, it is merged to "next".

You can run "git log --first-parent master..seen" to see what topics are
currently in flight.  Sometimes, an idea that looked promising turns out
to be not so good and the topic can be dropped from "seen" in such a case.
The output of the above "git log" talks about a "jch" branch, which is an
early part of the "seen" branch; that branch contains all topics that
are in "next" and a bit more (but not all of "seen") and is used by the
maintainer for his daily work.

The two branches "master" and "maint" are never rewound, and "next"
usually will not be either.  After a feature release is made from
"master", however, "next" will be rebuilt from the tip of "master"
using the topics that didn't make the cut in the feature release.
Some topics that used to be in "next" during the previous cycle may
get ejected from "next" when this happens.

A natural consequence of how "next" and "seen" bundles topics together
is that until a topic is merged to "next", updates to it is expected
by replacing the patch(es) in the topic with an improved version,
and once a topic is merged to "next", updates to it needs to come as
incremental patches, pointing out what was wrong in the previous
patches and how the problem was corrected.

Note that being in "next" is not a guarantee to appear in the next
release, nor even in any future release.  There were cases that topics
needed reverting a few commits in them before graduating to "master",
or a topic that already was in "next" was reverted from "next" because
fatal flaws were found in it after it was merged to "next".


* Other people's trees.

Documentation/SubmittingPatches outlines to whom your proposed changes
should be sent.  As described in contrib/README, I would delegate fixes
and enhancements in contrib/ area to the primary contributors of them.

Although the following are included in git.git repository, they have their
own authoritative repository and maintainers:

 - git-gui/ comes from git-gui project, maintained by Pratyush Yadav:

        https://github.com/prati0100/git-gui.git

 - gitk-git/ comes from Paul Mackerras's gitk project:

        git://ozlabs.org/~paulus/gitk

 - po/ comes from the localization coordinator, Jiang Xin:

	https://github.com/git-l10n/git-po/

When sending proposed updates and fixes to these parts of the system,
please base your patches on these trees, not git.git (the former two
even have different directory structures).

A note from the maintainer

[Junio C Hamano]

Welcome to the Git development community.

This message is written by the maintainer and talks about how Git
project is managed, and how you can work with it.

The current maintainer is Junio C Hamano <gitster@pobox.com>; please
do not send any message to this address unless it also goes to the
mailing list, because it is likely that such a message will not be
seen by any human being.  Spam filters learned that legitimate
messages to the address come only from a very few sender addresses
that are known to be good, and messages from all others are likely to
be spam unless they are also sent to the mailing list at the same time
(i.e. "Reply-all" to the list message would reach the mailbox, but
"Reply" will likely be thrown into the spam folder).


* Mailing list and the community

The development is primarily done on the Git mailing list. Help
requests, feature proposals, bug reports and patches should be sent to
the list address <git@vger.kernel.org>.  You don't have to be
subscribed to send messages.  The convention on the list is to keep
everybody involved on Cc:, so it is unnecessary to say "Please Cc: me,
I am not subscribed".

As an anti-spam measure, the mailing list software rejects messages
that are not text/plain and drops them on the floor.  If you are a
GMail user, you'd want to make sure "Plain text mode" is checked.

Before sending patches, please read Documentation/SubmittingPatches
and Documentation/CodingGuidelines to familiarize yourself with the
project convention.

If you sent a patch and you did not hear any response from anybody for
several days, it could be that your patch was totally uninteresting,
but it also is possible that it was simply lost in the noise.  Please
do not hesitate to send a reminder message in such a case.  Messages
getting lost in the noise may be a sign that those who can evaluate
your patch don't have enough mental/time bandwidth to process them
right at the moment, and it often helps to wait until the list traffic
becomes calmer before sending such a reminder.

The list archive is available at a few public sites:

        http://lore.kernel.org/git/
        http://marc.info/?l=git
        http://www.spinics.net/lists/git/

For those who prefer to read it over NNTP:

	nntp://nntp.lore.kernel.org/org.kernel.vger.git
        nntp://news.public-inbox.org/inbox.comp.version-control.git

are available.

When you point at a message in a mailing list archive, using its
message ID is often the most robust (if not very friendly) way to do
so, like this:

	http://lore.kernel.org/git/Pine.LNX.4.58.0504150753440.7211@ppc970.osdl.org

Often these web interfaces accept the message ID with enclosing <>
stripped (like the above example to point at one of the most important
message in the Git list).

Some members of the development community can sometimes be found on
the #git and #git-devel IRC channels on Libera Chat.  Their logs are
available at:

        http://colabti.org/irclogger/irclogger_log/git
        http://colabti.org/irclogger/irclogger_log/git-devel

There is a volunteer-run newsletter to serve our community ("Git Rev
News" http://git.github.io/rev_news/).

Git is a member project of software freedom conservancy, a non-profit
organization (https://sfconservancy.org/).  To reach a committee of
liaisons to the conservancy, contact them at <git@sfconservancy.org>.

For our expectations on the behaviour of the community participants
towards each other, see CODE_OF_CONDUCT.md at the top level of the source
tree, or:

    https://github.com/git/git/blob/master/CODE_OF_CONDUCT.md


* Reporting bugs

When you think git does not behave as you expect, please do not stop
your bug report with just "git does not work".  "I used git in this
way, but it did not work" is not much better, neither is "I used git
in this way, and X happend, which is broken".  It often is that git is
correct to cause X happen in such a case, and it is your expectation
that is broken. People would not know what other result Y you expected
to see instead of X, if you left it unsaid.

Please remember to always state

 - what you wanted to achieve;

 - what you did (the version of git and the command sequence to reproduce
   the behavior);

 - what you saw happen (X above);

 - what you expected to see (Y above); and

 - how the last two are different.

See http://www.chiark.greenend.org.uk/~sgtatham/bugs.html for further
hints.  Our `git bugreport` tool gives you a handy way you can use to
make sure you do not forget these points when filing a bug report.

If you think you found a security-sensitive issue and want to disclose
it to us without announcing it to wider public, please contact us at
our security mailing list <git-security@googlegroups.com>.  This is
a closed list that is limited to people who need to know early about
vulnerabilities, including:

  - people triaging and fixing reported vulnerabilities
  - people operating major git hosting sites with many users
  - people packaging and distributing git to large numbers of people

where these issues are discussed without risk of the information
leaking out before we're ready to make public announcements.


* Repositories and documentation.

My public git.git repositories are (mirrored) at:

  https://git.kernel.org/pub/scm/git/git.git/
  https://kernel.googlesource.com/pub/scm/git/git
  https://repo.or.cz/alt-git.git/
  https://github.com/git/git/
  https://gitlab.com/git-vcs/git/

This one shows not just the main integration branches, but also
individual topics broken out:

  https://github.com/gitster/git/

A few web interfaces are found at:

  http://git.kernel.org/pub/scm/git/git.git
  https://kernel.googlesource.com/pub/scm/git/git
  http://repo.or.cz/w/alt-git.git

Preformatted documentation from the tip of the "master" branch can be
found in:

  https://git.kernel.org/pub/scm/git/git-{htmldocs,manpages}.git/
  https://repo.or.cz/git-{htmldocs,manpages}.git/
  https://github.com/gitster/git-{htmldocs,manpages}.git/

The manual pages formatted in HTML for the tip of 'master' can be
viewed online at:

  https://git.github.io/htmldocs/git.html


* How various branches are used.

There are four "integration" branches in git.git repository that track
the source tree of git: "master", "maint", "next", and "seen".  They
however almost never get new commits made directly on them.  Instead,
a branch is forked from either "master" or "maint" for each "topic",
whether it is a new feature or fix for a bug, and holds a set of
commits that belong to the same theme, and then such a "topic branch"
is merged to these integration branches.

The "master" branch is meant to contain what are very well tested and
ready to be used in a production setting.  Every now and then, a
"feature release" is cut from the tip of this branch.  They used to be
named with three dotted decimal digits (e.g. "1.8.5"), but we have
switched the versioning scheme and "feature releases" are named with
three-dotted decimal digits that ends with ".0" (e.g. "1.9.0").

The last such release was 2.37 done on June 27th, 2022.  You can expect
that the tip of the "master" branch is always more stable than any of
the released versions.

Whenever a feature release is made, "maint" branch is forked off from
"master" at that point.  Obvious and safe fixes after a feature
release are merged to this branch and maintenance releases are cut
from it.  Usually these fixes are merged to the "master" branch first,
several days before merged to the "maint" branch, to reduce the chance
of last-minute issues, but things like embargoed security fixes may
first appear in the maintenance tracks and merged up to "master" at
the same time.  The maintenance releases used to be named with
four dotted decimal, named after the feature release they are updates
to (e.g. "1.8.5.1" was the first maintenance release for "1.8.5"
feature release).  These days, maintenance releases are named by
incrementing the last digit of three-dotted decimal name (e.g.
"2.29.2" was the second maintenance release for the "2.29" series).

New features never go to the "maint" branch.  It is merged into
"master" primarily to propagate the description in the release notes
forward.

A new development does not usually happen on "master". When you send a
series of patches, after review on the mailing list, a separate topic
branch is forked from the tip of "master" (or somewhere older, especially
when the topic is about fixing an earlier bug) and your patches are queued
there, and kept out of "master" while people test it out. The quality of
topic branches are judged primarily by the mailing list discussions.

Topic branches that are in good shape are merged to the "next" branch. In
general, the "next" branch always contains the tip of "master".  It might
not be quite rock-solid, but is expected to work more or less without major
breakage. The "next" branch is where new and exciting things take place. A
topic that is in "next" is expected to be polished to perfection before it
is merged to "master".  Please help this process by building & using the
"next" branch for your daily work, and reporting any new bugs you find to
the mailing list, before the breakage is merged down to the "master".

The "seen" (formerly "pu", proposed updates) branch bundles all the
remaining topic branches the maintainer happens to have seen.  There
is no guarantee that the maintainer has enough bandwidth to pick up any
and all topics that are remotely promising from the list traffic, so
please do not read too much into a topic being on (or not on) the "seen"
branch.  This branch is mainly to remind the maintainer that the topics
in them may turn out to be interesting when they are polished, nothing
more.  The topics on this branch aren't usually complete, well tested,
or well documented and they often need further work.  When a topic that
was in "seen" proves to be in a testable shape, it is merged to "next".

You can run "git log --first-parent master..seen" to see what topics are
currently in flight.  Sometimes, an idea that looked promising turns out
to be not so good and the topic can be dropped from "seen" in such a case.
The output of the above "git log" talks about a "jch" branch, which is an
early part of the "seen" branch; that branch contains all topics that
are in "next" and a bit more (but not all of "seen") and is used by the
maintainer for his daily work.

The two branches "master" and "maint" are never rewound, and "next"
usually will not be either.  After a feature release is made from
"master", however, "next" will be rebuilt from the tip of "master"
using the topics that didn't make the cut in the feature release.
Some topics that used to be in "next" during the previous cycle may
get ejected from "next" when this happens.

A natural consequence of how "next" and "seen" bundles topics together
is that until a topic is merged to "next", updates to it is expected
by replacing the patch(es) in the topic with an improved version,
and once a topic is merged to "next", updates to it needs to come as
incremental patches, pointing out what was wrong in the previous
patches and how the problem was corrected.

Note that being in "next" is not a guarantee to appear in the next
release, nor even in any future release.  There were cases that topics
needed reverting a few commits in them before graduating to "master",
or a topic that already was in "next" was reverted from "next" because
fatal flaws were found in it after it was merged to "next".


* Other people's trees.

Documentation/SubmittingPatches outlines to whom your proposed changes
should be sent.  As described in contrib/README, I would delegate fixes
and enhancements in contrib/ area to the primary contributors of them.

Although the following are included in git.git repository, they have their
own authoritative repository and maintainers:

 - git-gui/ comes from git-gui project, maintained by Pratyush Yadav:

        https://github.com/prati0100/git-gui.git

 - gitk-git/ comes from Paul Mackerras's gitk project:

        git://ozlabs.org/~paulus/gitk

 - po/ comes from the localization coordinator, Jiang Xin:

	https://github.com/git-l10n/git-po/

When sending proposed updates and fixes to these parts of the system,
please base your patches on these trees, not git.git (the former two
even have different directory structures).

A note from the maintainer

[Junio C Hamano]

Welcome to the Git development community.

This message is written by the maintainer and talks about how Git
project is managed, and how you can work with it.

The current maintainer is Junio C Hamano <gitster@pobox.com>; please
do not send any message to this address unless it also goes to the
mailing list, because it is likely that such a message will not be
seen by any human being.  Spam filters learned that legitimate
messages to the address come only from a very few sender addresses
that are known to be good, and messages from all others are likely to
be spam unless they are also sent to the mailing list at the same time
(i.e. "Reply-all" to the list message would reach the mailbox, but
"Reply" will likely be thrown into the spam folder).


* Mailing list and the community

The development is primarily done on the Git mailing list. Help
requests, feature proposals, bug reports and patches should be sent to
the list address <git@vger.kernel.org>.  You don't have to be
subscribed to send messages.  The convention on the list is to keep
everybody involved on Cc:, so it is unnecessary to say "Please Cc: me,
I am not subscribed".

As an anti-spam measure, the mailing list software rejects messages
that are not text/plain and drops them on the floor.  If you are a
GMail user, you'd want to make sure "Plain text mode" is checked.

Before sending patches, please read Documentation/SubmittingPatches
and Documentation/CodingGuidelines to familiarize yourself with the
project convention.

If you sent a patch and you did not hear any response from anybody for
several days, it could be that your patch was totally uninteresting,
but it also is possible that it was simply lost in the noise.  Please
do not hesitate to send a reminder message in such a case.  Messages
getting lost in the noise may be a sign that those who can evaluate
your patch don't have enough mental/time bandwidth to process them
right at the moment, and it often helps to wait until the list traffic
becomes calmer before sending such a reminder.

The list archive is available at a few public sites:

        http://lore.kernel.org/git/
        http://marc.info/?l=git
        http://www.spinics.net/lists/git/

For those who prefer to read it over NNTP:

	nntp://nntp.lore.kernel.org/org.kernel.vger.git
        nntp://news.public-inbox.org/inbox.comp.version-control.git

are available.

When you point at a message in a mailing list archive, using its
message ID is often the most robust (if not very friendly) way to do
so, like this:

	http://lore.kernel.org/git/Pine.LNX.4.58.0504150753440.7211@ppc970.osdl.org

Often these web interfaces accept the message ID with enclosing <>
stripped (like the above example to point at one of the most important
message in the Git list).

Some members of the development community can sometimes be found on
the #git and #git-devel IRC channels on Libera Chat.  Their logs are
available at:

        http://colabti.org/irclogger/irclogger_log/git
        http://colabti.org/irclogger/irclogger_log/git-devel

There is a volunteer-run newsletter to serve our community ("Git Rev
News" http://git.github.io/rev_news/).

Git is a member project of software freedom conservancy, a non-profit
organization (https://sfconservancy.org/).  To reach a committee of
liaisons to the conservancy, contact them at <git@sfconservancy.org>.

For our expectations on the behaviour of the community participants
towards each other, see CODE_OF_CONDUCT.md at the top level of the source
tree, or:

    https://github.com/git/git/blob/master/CODE_OF_CONDUCT.md


* Reporting bugs

When you think git does not behave as you expect, please do not stop
your bug report with just "git does not work".  "I used git in this
way, but it did not work" is not much better, neither is "I used git
in this way, and X happend, which is broken".  It often is that git is
correct to cause X happen in such a case, and it is your expectation
that is broken. People would not know what other result Y you expected
to see instead of X, if you left it unsaid.

Please remember to always state

 - what you wanted to achieve;

 - what you did (the version of git and the command sequence to reproduce
   the behavior);

 - what you saw happen (X above);

 - what you expected to see (Y above); and

 - how the last two are different.

See http://www.chiark.greenend.org.uk/~sgtatham/bugs.html for further
hints.  Our `git bugreport` tool gives you a handy way you can use to
make sure you do not forget these points when filing a bug report.

If you think you found a security-sensitive issue and want to disclose
it to us without announcing it to wider public, please contact us at
our security mailing list <git-security@googlegroups.com>.  This is
a closed list that is limited to people who need to know early about
vulnerabilities, including:

  - people triaging and fixing reported vulnerabilities
  - people operating major git hosting sites with many users
  - people packaging and distributing git to large numbers of people

where these issues are discussed without risk of the information
leaking out before we're ready to make public announcements.


* Repositories and documentation.

My public git.git repositories are (mirrored) at:

  https://git.kernel.org/pub/scm/git/git.git/
  https://kernel.googlesource.com/pub/scm/git/git
  https://repo.or.cz/alt-git.git/
  https://github.com/git/git/
  https://gitlab.com/git-vcs/git/

This one shows not just the main integration branches, but also
individual topics broken out:

  https://github.com/gitster/git/

A few web interfaces are found at:

  http://git.kernel.org/pub/scm/git/git.git
  https://kernel.googlesource.com/pub/scm/git/git
  http://repo.or.cz/w/alt-git.git

Preformatted documentation from the tip of the "master" branch can be
found in:

  https://git.kernel.org/pub/scm/git/git-{htmldocs,manpages}.git/
  https://repo.or.cz/git-{htmldocs,manpages}.git/
  https://github.com/gitster/git-{htmldocs,manpages}.git/

The manual pages formatted in HTML for the tip of 'master' can be
viewed online at:

  https://git.github.io/htmldocs/git.html


* How various branches are used.

There are four "integration" branches in git.git repository that track
the source tree of git: "master", "maint", "next", and "seen".  They
however almost never get new commits made directly on them.  Instead,
a branch is forked from either "master" or "maint" for each "topic",
whether it is a new feature or fix for a bug, and holds a set of
commits that belong to the same theme, and then such a "topic branch"
is merged to these integration branches.

The "master" branch is meant to contain what are very well tested and
ready to be used in a production setting.  Every now and then, a
"feature release" is cut from the tip of this branch.  They used to be
named with three dotted decimal digits (e.g. "1.8.5"), but we have
switched the versioning scheme and "feature releases" are named with
three-dotted decimal digits that ends with ".0" (e.g. "1.9.0").

The last such release was 2.37 done on June 27th, 2022.  You can expect
that the tip of the "master" branch is always more stable than any of
the released versions.

Whenever a feature release is made, "maint" branch is forked off from
"master" at that point.  Obvious and safe fixes after a feature
release are merged to this branch and maintenance releases are cut
from it.  Usually these fixes are merged to the "master" branch first,
several days before merged to the "maint" branch, to reduce the chance
of last-minute issues.  The maintenance releases used to be named with
four dotted decimal, named after the feature release they are updates
to (e.g. "1.8.5.1" was the first maintenance release for "1.8.5"
feature release).  These days, maintenance releases are named by
incrementing the last digit of three-dotted decimal name (e.g.
"2.29.2" was the second maintenance release for the "2.29" series).

New features never go to the "maint" branch.  It is merged into
"master" primarily to propagate the description in the release notes
forward.

A new development does not usually happen on "master". When you send a
series of patches, after review on the mailing list, a separate topic
branch is forked from the tip of "master" (or somewhere older, especially
when the topic is about fixing an earlier bug) and your patches are queued
there, and kept out of "master" while people test it out. The quality of
topic branches are judged primarily by the mailing list discussions.

Topic branches that are in good shape are merged to the "next" branch. In
general, the "next" branch always contains the tip of "master".  It might
not be quite rock-solid, but is expected to work more or less without major
breakage. The "next" branch is where new and exciting things take place. A
topic that is in "next" is expected to be polished to perfection before it
is merged to "master".  Please help this process by building & using the
"next" branch for your daily work, and reporting any new bugs you find to
the mailing list, before the breakage is merged down to the "master".

The "seen" (formerly "pu", proposed updates) branch bundles all the
remaining topic branches the maintainer happens to have seen.  There
is no guarantee that the maintainer has enough bandwidth to pick up any
and all topics that are remotely promising from the list traffic, so
please do not read too much into a topic being on (or not on) the "seen"
branch.  This branch is mainly to remind the maintainer that the topics
in them may turn out to be interesting when they are polished, nothing
more.  The topics on this branch aren't usually complete, well tested,
or well documented and they often need further work.  When a topic that
was in "seen" proves to be in a testable shape, it is merged to "next".

You can run "git log --first-parent master..seen" to see what topics are
currently in flight.  Sometimes, an idea that looked promising turns out
to be not so good and the topic can be dropped from "seen" in such a case.
The output of the above "git log" talks about a "jch" branch, which is an
early part of the "seen" branch; that branch contains all topics that
are in "next" and a bit more (but not all of "seen") and is used by the
maintainer for his daily work.

The two branches "master" and "maint" are never rewound, and "next"
usually will not be either.  After a feature release is made from
"master", however, "next" will be rebuilt from the tip of "master"
using the topics that didn't make the cut in the feature release.
Some topics that used to be in "next" during the previous cycle may
get ejected from "next" when this happens.

A natural consequence of how "next" and "seen" bundles topics together
is that until a topic is merged to "next", updates to it is expected
by replacing the patch(es) in the topic with an improved version,
and once a topic is merged to "next", updates to it needs to come as
incremental patches, pointing out what was wrong in the previous
patches and how the problem was corrected.

Note that being in "next" is not a guarantee to appear in the next
release, nor even in any future release.  There were cases that topics
needed reverting a few commits in them before graduating to "master",
or a topic that already was in "next" was reverted from "next" because
fatal flaws were found in it after it was merged to "next".


* Other people's trees.

Documentation/SubmittingPatches outlines to whom your proposed changes
should be sent.  As described in contrib/README, I would delegate fixes
and enhancements in contrib/ area to the primary contributors of them.

Although the following are included in git.git repository, they have their
own authoritative repository and maintainers:

 - git-gui/ comes from git-gui project, maintained by Pratyush Yadav:

        https://github.com/prati0100/git-gui.git

 - gitk-git/ comes from Paul Mackerras's gitk project:

        git://ozlabs.org/~paulus/gitk

 - po/ comes from the localization coordinator, Jiang Xin:

	https://github.com/git-l10n/git-po/

When sending proposed updates and fixes to these parts of the system,
please base your patches on these trees, not git.git (the former two
even have different directory structures).

A note from the maintainer

[Junio C Hamano]

Welcome to the Git development community.

This message is written by the maintainer and talks about how Git
project is managed, and how you can work with it.

The current maintainer is Junio C Hamano <gitster@pobox.com>; please
do not send any message to this address unless it also goes to the
mailing list, because it is likely that such a message will not be
seen by any human being.  Spam filters learned that legitimate
messages to the address come only from a very few sender addresses
that are known to be good, and messages from all others are likely to
be spam unless they are also sent to the mailing list at the same time
(i.e. "Reply-all" to the list message would reach the mailbox, but
"Reply" will likely be thrown into the spam folder).


* Mailing list and the community

The development is primarily done on the Git mailing list. Help
requests, feature proposals, bug reports and patches should be sent to
the list address <git@vger.kernel.org>.  You don't have to be
subscribed to send messages.  The convention on the list is to keep
everybody involved on Cc:, so it is unnecessary to say "Please Cc: me,
I am not subscribed".

As an anti-spam measure, the mailing list software rejects messages
that are not text/plain and drops them on the floor.  If you are a
GMail user, you'd want to make sure "Plain text mode" is checked.

Before sending patches, please read Documentation/SubmittingPatches
and Documentation/CodingGuidelines to familiarize yourself with the
project convention.

If you sent a patch and you did not hear any response from anybody for
several days, it could be that your patch was totally uninteresting,
but it also is possible that it was simply lost in the noise.  Please
do not hesitate to send a reminder message in such a case.  Messages
getting lost in the noise may be a sign that those who can evaluate
your patch don't have enough mental/time bandwidth to process them
right at the moment, and it often helps to wait until the list traffic
becomes calmer before sending such a reminder.

The list archive is available at a few public sites:

        http://lore.kernel.org/git/
        http://marc.info/?l=git
        http://www.spinics.net/lists/git/

For those who prefer to read it over NNTP:

	nntp://nntp.lore.kernel.org/org.kernel.vger.git
        nntp://news.public-inbox.org/inbox.comp.version-control.git

are available.

When you point at a message in a mailing list archive, using its
message ID is often the most robust (if not very friendly) way to do
so, like this:

	http://lore.kernel.org/git/Pine.LNX.4.58.0504150753440.7211@ppc970.osdl.org

Often these web interfaces accept the message ID with enclosing <>
stripped (like the above example to point at one of the most important
message in the Git list).

Some members of the development community can sometimes be found on
the #git and #git-devel IRC channels on Libera Chat.  Their logs are
available at:

        http://colabti.org/irclogger/irclogger_log/git
        http://colabti.org/irclogger/irclogger_log/git-devel

There is a volunteer-run newsletter to serve our community ("Git Rev
News" http://git.github.io/rev_news/).

Git is a member project of software freedom conservancy, a non-profit
organization (https://sfconservancy.org/).  To reach a committee of
liaisons to the conservancy, contact them at <git@sfconservancy.org>.

For our expectations on the behaviour of the community participants
towards each other, see CODE_OF_CONDUCT.md at the top level of the source
tree, or:

    https://github.com/git/git/blob/master/CODE_OF_CONDUCT.md


* Reporting bugs

When you think git does not behave as you expect, please do not stop
your bug report with just "git does not work".  "I used git in this
way, but it did not work" is not much better, neither is "I used git
in this way, and X happend, which is broken".  It often is that git is
correct to cause X happen in such a case, and it is your expectation
that is broken. People would not know what other result Y you expected
to see instead of X, if you left it unsaid.

Please remember to always state

 - what you wanted to achieve;

 - what you did (the version of git and the command sequence to reproduce
   the behavior);

 - what you saw happen (X above);

 - what you expected to see (Y above); and

 - how the last two are different.

See http://www.chiark.greenend.org.uk/~sgtatham/bugs.html for further
hints.  Our `git bugreport` tool gives you a handy way you can use to
make sure you do not forget these points when filing a bug report.

If you think you found a security-sensitive issue and want to disclose
it to us without announcing it to wider public, please contact us at
our security mailing list <git-security@googlegroups.com>.  This is
a closed list that is limited to people who need to know early about
vulnerabilities, including:

  - people triaging and fixing reported vulnerabilities
  - people operating major git hosting sites with many users
  - people packaging and distributing git to large numbers of people

where these issues are discussed without risk of the information
leaking out before we're ready to make public announcements.


* Repositories and documentation.

My public git.git repositories are (mirrored) at:

  https://git.kernel.org/pub/scm/git/git.git/
  https://kernel.googlesource.com/pub/scm/git/git
  https://repo.or.cz/alt-git.git/
  https://github.com/git/git/
  https://gitlab.com/git-vcs/git/

This one shows not just the main integration branches, but also
individual topics broken out:

  https://github.com/gitster/git/

A few web interfaces are found at:

  http://git.kernel.org/pub/scm/git/git.git
  https://kernel.googlesource.com/pub/scm/git/git
  http://repo.or.cz/w/alt-git.git

Preformatted documentation from the tip of the "master" branch can be
found in:

  https://git.kernel.org/pub/scm/git/git-{htmldocs,manpages}.git/
  https://repo.or.cz/git-{htmldocs,manpages}.git/
  https://github.com/gitster/git-{htmldocs,manpages}.git/

The manual pages formatted in HTML for the tip of 'master' can be
viewed online at:

  https://git.github.io/htmldocs/git.html


* How various branches are used.

There are four "integration" branches in git.git repository that track
the source tree of git: "master", "maint", "next", and "seen".  They
however almost never get new commits made directly on them.  Instead,
a branch is forked from either "master" or "maint" for each "topic",
whether it is a new feature or fix for a bug, and holds a set of
commits that belong to the same theme, and then such a "topic branch"
is merged to these integration branches.

The "master" branch is meant to contain what are very well tested and
ready to be used in a production setting.  Every now and then, a
"feature release" is cut from the tip of this branch.  They used to be
named with three dotted decimal digits (e.g. "1.8.5"), but we have
switched the versioning scheme and "feature releases" are named with
three-dotted decimal digits that ends with ".0" (e.g. "1.9.0").

The last such release was 2.36 done on Apr 18th, 2022.  You can expect
that the tip of the "master" branch is always more stable than any of
the released versions.

Whenever a feature release is made, "maint" branch is forked off from
"master" at that point.  Obvious and safe fixes after a feature
release are merged to this branch and maintenance releases are cut
from it.  Usually these fixes are merged to the "master" branch first,
several days before merged to the "maint" branch, to reduce the chance
of last-minute issues.  The maintenance releases used to be named with
four dotted decimal, named after the feature release they are updates
to (e.g. "1.8.5.1" was the first maintenance release for "1.8.5"
feature release).  These days, maintenance releases are named by
incrementing the last digit of three-dotted decimal name (e.g.
"2.29.2" was the second maintenance release for the "2.29" series).

New features never go to the "maint" branch.  It is merged into
"master" primarily to propagate the description in the release notes
forward.

A new development does not usually happen on "master". When you send a
series of patches, after review on the mailing list, a separate topic
branch is forked from the tip of "master" (or somewhere older, especially
when the topic is about fixing an earlier bug) and your patches are queued
there, and kept out of "master" while people test it out. The quality of
topic branches are judged primarily by the mailing list discussions.

Topic branches that are in good shape are merged to the "next" branch. In
general, the "next" branch always contains the tip of "master".  It might
not be quite rock-solid, but is expected to work more or less without major
breakage. The "next" branch is where new and exciting things take place. A
topic that is in "next" is expected to be polished to perfection before it
is merged to "master".  Please help this process by building & using the
"next" branch for your daily work, and reporting any new bugs you find to
the mailing list, before the breakage is merged down to the "master".

The "seen" (formerly "pu", proposed updates) branch bundles all the
remaining topic branches the maintainer happens to have seen.  There
is no guarantee that the maintainer has enough bandwidth to pick up any
and all topics that are remotely promising from the list traffic, so
please do not read too much into a topic being on (or not on) the "seen"
branch.  This branch is mainly to remind the maintainer that the topics
in them may turn out to be interesting when they are polished, nothing
more.  The topics on this branch aren't usually complete, well tested,
or well documented and they often need further work.  When a topic that
was in "seen" proves to be in a testable shape, it is merged to "next".

You can run "git log --first-parent master..seen" to see what topics are
currently in flight.  Sometimes, an idea that looked promising turns out
to be not so good and the topic can be dropped from "seen" in such a case.
The output of the above "git log" talks about a "jch" branch, which is an
early part of the "seen" branch; that branch contains all topics that
are in "next" and a bit more (but not all of "seen") and is used by the
maintainer for his daily work.

The two branches "master" and "maint" are never rewound, and "next"
usually will not be either.  After a feature release is made from
"master", however, "next" will be rebuilt from the tip of "master"
using the topics that didn't make the cut in the feature release.
Some topics that used to be in "next" during the previous cycle may
get ejected from "next" when this happens.

A natural consequence of how "next" and "seen" bundles topics together
is that until a topic is merged to "next", updates to it is expected
by replacing the patch(es) in the topic with an improved version,
and once a topic is merged to "next", updates to it needs to come as
incremental patches, pointing out what was wrong in the previous
patches and how the problem was corrected.

Note that being in "next" is not a guarantee to appear in the next
release, nor even in any future release.  There were cases that topics
needed reverting a few commits in them before graduating to "master",
or a topic that already was in "next" was reverted from "next" because
fatal flaws were found in it after it was merged to "next".


* Other people's trees.

Documentation/SubmittingPatches outlines to whom your proposed changes
should be sent.  As described in contrib/README, I would delegate fixes
and enhancements in contrib/ area to the primary contributors of them.

Although the following are included in git.git repository, they have their
own authoritative repository and maintainers:

 - git-gui/ comes from git-gui project, maintained by Pratyush Yadav:

        https://github.com/prati0100/git-gui.git

 - gitk-git/ comes from Paul Mackerras's gitk project:

        git://ozlabs.org/~paulus/gitk

 - po/ comes from the localization coordinator, Jiang Xin:

	https://github.com/git-l10n/git-po/

When sending proposed updates and fixes to these parts of the system,
please base your patches on these trees, not git.git (the former two
even have different directory structures).

A note from the maintainer

[Junio C Hamano]

Welcome to the Git development community.

This message is written by the maintainer and talks about how Git
project is managed, and how you can work with it.

The current maintainer is Junio C Hamano <gitster@pobox.com>; please
do not send any message to this address unless it also goes to the
mailing list, because it is likely that such a message will not be
seen by any human being.  Spam filters learned that legitimate
messages to the address come only from a very few sender addresses
that are known to be good, and messages from all others are likely to
be spam unless they are also sent to the mailing list at the same time
(i.e. "Reply-all" to the list message would reach the mailbox, but
"Reply" will likely be thrown into the spam folder).


* Mailing list and the community

The development is primarily done on the Git mailing list. Help
requests, feature proposals, bug reports and patches should be sent to
the list address <git@vger.kernel.org>.  You don't have to be
subscribed to send messages.  The convention on the list is to keep
everybody involved on Cc:, so it is unnecessary to say "Please Cc: me,
I am not subscribed".

As an anti-spam measure, the mailing list software rejects messages
that are not text/plain and drops them on the floor.  If you are a
GMail user, you'd want to make sure "Plain text mode" is checked.

Before sending patches, please read Documentation/SubmittingPatches
and Documentation/CodingGuidelines to familiarize yourself with the
project convention.

If you sent a patch and you did not hear any response from anybody for
several days, it could be that your patch was totally uninteresting,
but it also is possible that it was simply lost in the noise.  Please
do not hesitate to send a reminder message in such a case.  Messages
getting lost in the noise may be a sign that those who can evaluate
your patch don't have enough mental/time bandwidth to process them
right at the moment, and it often helps to wait until the list traffic
becomes calmer before sending such a reminder.

The list archive is available at a few public sites:

        http://lore.kernel.org/git/
        http://marc.info/?l=git
        http://www.spinics.net/lists/git/

For those who prefer to read it over NNTP:

	nntp://nntp.lore.kernel.org/org.kernel.vger.git
        nntp://news.public-inbox.org/inbox.comp.version-control.git

are available.

When you point at a message in a mailing list archive, using its
message ID is often the most robust (if not very friendly) way to do
so, like this:

	http://lore.kernel.org/git/Pine.LNX.4.58.0504150753440.7211@ppc970.osdl.org

Often these web interfaces accept the message ID with enclosing <>
stripped (like the above example to point at one of the most important
message in the Git list).

Some members of the development community can sometimes be found on
the #git and #git-devel IRC channels on FreeNode (historically, but
the IRC situation is in flux at the moment).  Their logs are available
at:

        http://colabti.org/irclogger/irclogger_log/git
        http://colabti.org/irclogger/irclogger_log/git-devel

There is a volunteer-run newsletter to serve our community ("Git Rev
News" http://git.github.io/rev_news/).

Git is a member project of software freedom conservancy, a non-profit
organization (https://sfconservancy.org/).  To reach a committee of
liaisons to the conservancy, contact them at <git@sfconservancy.org>.

For our expectations on the behaviour of the community participants
towards each other, see CODE_OF_CONDUCT.md at the top level of the source
tree, or:

    https://github.com/git/git/blob/master/CODE_OF_CONDUCT.md


* Reporting bugs

When you think git does not behave as you expect, please do not stop
your bug report with just "git does not work".  "I used git in this
way, but it did not work" is not much better, neither is "I used git
in this way, and X happend, which is broken".  It often is that git is
correct to cause X happen in such a case, and it is your expectation
that is broken. People would not know what other result Y you expected
to see instead of X, if you left it unsaid.

Please remember to always state

 - what you wanted to achieve;

 - what you did (the version of git and the command sequence to reproduce
   the behavior);

 - what you saw happen (X above);

 - what you expected to see (Y above); and

 - how the last two are different.

See http://www.chiark.greenend.org.uk/~sgtatham/bugs.html for further
hints.  Our `git bugreport` tool gives you a handy way you can use to
make sure you do not forget these points when filing a bug report.

If you think you found a security-sensitive issue and want to disclose
it to us without announcing it to wider public, please contact us at
our security mailing list <git-security@googlegroups.com>.  This is
a closed list that is limited to people who need to know early about
vulnerabilities, including:

  - people triaging and fixing reported vulnerabilities
  - people operating major git hosting sites with many users
  - people packaging and distributing git to large numbers of people

where these issues are discussed without risk of the information
leaking out before we're ready to make public announcements.


* Repositories and documentation.

My public git.git repositories are (mirrored) at:

  https://git.kernel.org/pub/scm/git/git.git/
  https://kernel.googlesource.com/pub/scm/git/git
  https://repo.or.cz/alt-git.git/
  https://github.com/git/git/
  https://gitlab.com/git-vcs/git/

This one shows not just the main integration branches, but also
individual topics broken out:

  https://github.com/gitster/git/

A few web interfaces are found at:

  http://git.kernel.org/pub/scm/git/git.git
  https://kernel.googlesource.com/pub/scm/git/git
  http://repo.or.cz/w/alt-git.git

Preformatted documentation from the tip of the "master" branch can be
found in:

  https://git.kernel.org/pub/scm/git/git-{htmldocs,manpages}.git/
  https://repo.or.cz/git-{htmldocs,manpages}.git/
  https://github.com/gitster/git-{htmldocs,manpages}.git/

The manual pages formatted in HTML for the tip of 'master' can be
viewed online at:

  https://git.github.io/htmldocs/git.html


* How various branches are used.

There are four "integration" branches in git.git repository that track
the source tree of git: "master", "maint", "next", and "seen".  They
however almost never get new commits made directly on them.  Instead,
a branch is forked from either "master" or "maint" for each "topic",
whether it is a new feature or fix for a bug, and holds a set of
commits that belong to the same theme, and then such a "topic branch"
is merged to these integration branches.

The "master" branch is meant to contain what are very well tested and
ready to be used in a production setting.  Every now and then, a
"feature release" is cut from the tip of this branch.  They used to be
named with three dotted decimal digits (e.g. "1.8.5"), but we have
switched the versioning scheme and "feature releases" are named with
three-dotted decimal digits that ends with ".0" (e.g. "1.9.0").

The last such release was 2.35 done on Jan 24th, 2022.  You can expect
that the tip of the "master" branch is always more stable than any of
the released versions.

Whenever a feature release is made, "maint" branch is forked off from
"master" at that point.  Obvious and safe fixes after a feature
release are merged to this branch and maintenance releases are cut
from it.  Usually these fixes are merged to the "master" branch first,
several days before merged to the "maint" branch, to reduce the chance
of last-minute issues.  The maintenance releases used to be named with
four dotted decimal, named after the feature release they are updates
to (e.g. "1.8.5.1" was the first maintenance release for "1.8.5"
feature release).  These days, maintenance releases are named by
incrementing the last digit of three-dotted decimal name (e.g.
"2.29.2" was the second maintenance release for the "2.29" series).

New features never go to the "maint" branch.  It is merged into
"master" primarily to propagate the description in the release notes
forward.

A new development does not usually happen on "master". When you send a
series of patches, after review on the mailing list, a separate topic
branch is forked from the tip of "master" (or somewhere older, especially
when the topic is about fixing an earlier bug) and your patches are queued
there, and kept out of "master" while people test it out. The quality of
topic branches are judged primarily by the mailing list discussions.

Topic branches that are in good shape are merged to the "next" branch. In
general, the "next" branch always contains the tip of "master".  It might
not be quite rock-solid, but is expected to work more or less without major
breakage. The "next" branch is where new and exciting things take place. A
topic that is in "next" is expected to be polished to perfection before it
is merged to "master".  Please help this process by building & using the
"next" branch for your daily work, and reporting any new bugs you find to
the mailing list, before the breakage is merged down to the "master".

The "seen" (formerly "pu", proposed updates) branch bundles all the
remaining topic branches the maintainer happens to have seen.  There
is no guarantee that the maintainer has enough bandwidth to pick up any
and all topics that are remotely promising from the list traffic, so
please do not read too much into a topic being on (or not on) the "seen"
branch.  This branch is mainly to remind the maintainer that the topics
in them may turn out to be interesting when they are polished, nothing
more.  The topics on this branch aren't usually complete, well tested,
or well documented and they often need further work.  When a topic that
was in "seen" proves to be in a testable shape, it is merged to "next".

You can run "git log --first-parent master..seen" to see what topics are
currently in flight.  Sometimes, an idea that looked promising turns out
to be not so good and the topic can be dropped from "seen" in such a case.
The output of the above "git log" talks about a "jch" branch, which is an
early part of the "seen" branch; that branch contains all topics that
are in "next" and a bit more (but not all of "seen") and is used by the
maintainer for his daily work.

The two branches "master" and "maint" are never rewound, and "next"
usually will not be either.  After a feature release is made from
"master", however, "next" will be rebuilt from the tip of "master"
using the topics that didn't make the cut in the feature release.
Some topics that used to be in "next" during the previous cycle may
get ejected from "next" when this happens.

A natural consequence of how "next" and "seen" bundles topics together
is that until a topic is merged to "next", updates to it is expected
by replacing the patch(es) in the topic with an improved version,
and once a topic is merged to "next", updates to it needs to come as
incremental patches, pointing out what was wrong in the previous
patches and how the problem was corrected.

Note that being in "next" is not a guarantee to appear in the next
release, nor even in any future release.  There were cases that topics
needed reverting a few commits in them before graduating to "master",
or a topic that already was in "next" was reverted from "next" because
fatal flaws were found in it after it was merged to "next".


* Other people's trees.

Documentation/SubmittingPatches outlines to whom your proposed changes
should be sent.  As described in contrib/README, I would delegate fixes
and enhancements in contrib/ area to the primary contributors of them.

Although the following are included in git.git repository, they have their
own authoritative repository and maintainers:

 - git-gui/ comes from git-gui project, maintained by Pratyush Yadav:

        https://github.com/prati0100/git-gui.git

 - gitk-git/ comes from Paul Mackerras's gitk project:

        git://ozlabs.org/~paulus/gitk

 - po/ comes from the localization coordinator, Jiang Xin:

	https://github.com/git-l10n/git-po/

When sending proposed updates and fixes to these parts of the system,
please base your patches on these trees, not git.git (the former two
even have different directory structures).

A note from the maintainer

[Junio C Hamano]

Welcome to the Git development community.

This message is written by the maintainer and talks about how Git
project is managed, and how you can work with it.

The current maintainer is Junio C Hamano <gitster@pobox.com>; please
do not send any private message to this address, because it is likely
that such a message will not be seen by any human being.  Spam filters
learned that legitimate messages to the address come only from a very
few sender addresses that are known to be good, and messages from all
others are likely to be spam unless they are also sent to the mailing
list at the same time (i.e. "Reply-all" to the list message would
reach the mailbox, but "Reply" will likely be thrown into the spam
folder).


* Mailing list and the community

The development is primarily done on the Git mailing list. Help
requests, feature proposals, bug reports and patches should be sent to
the list address <git@vger.kernel.org>.  You don't have to be
subscribed to send messages.  The convention on the list is to keep
everybody involved on Cc:, so it is unnecessary to say "Please Cc: me,
I am not subscribed".

As an anti-spam measure, the mailing list software rejects messages
that are not text/plain and drops them on the floor.  If you are a
GMail user, you'd want to make sure "Plain text mode" is checked.

Before sending patches, please read Documentation/SubmittingPatches
and Documentation/CodingGuidelines to familiarize yourself with the
project convention.

If you sent a patch and you did not hear any response from anybody for
several days, it could be that your patch was totally uninteresting,
but it also is possible that it was simply lost in the noise.  Please
do not hesitate to send a reminder message in such a case.  Messages
getting lost in the noise may be a sign that those who can evaluate
your patch don't have enough mental/time bandwidth to process them
right at the moment, and it often helps to wait until the list traffic
becomes calmer before sending such a reminder.

The list archive is available at a few public sites:

        http://lore.kernel.org/git/
        http://marc.info/?l=git
        http://www.spinics.net/lists/git/

For those who prefer to read it over NNTP:

	nntp://nntp.lore.kernel.org/org.kernel.vger.git
        nntp://news.public-inbox.org/inbox.comp.version-control.git

are available.

When you point at a message in a mailing list archive, using its
message ID is often the most robust (if not very friendly) way to do
so, like this:

	http://lore.kernel.org/git/Pine.LNX.4.58.0504150753440.7211@ppc970.osdl.org

Often these web interfaces accept the message ID with enclosing <>
stripped (like the above example to point at one of the most important
message in the Git list).

Some members of the development community can sometimes be found on
the #git and #git-devel IRC channels on FreeNode (historically, but
the IRC situation is in flux at the moment).  Their logs are available
at:

        http://colabti.org/irclogger/irclogger_log/git
        http://colabti.org/irclogger/irclogger_log/git-devel

There is a volunteer-run newsletter to serve our community ("Git Rev
News" http://git.github.io/rev_news/).

Git is a member project of software freedom conservancy, a non-profit
organization (https://sfconservancy.org/).  To reach a committee of
liaisons to the conservancy, contact them at <git@sfconservancy.org>.

For our expectations on the behaviour of the community participants
towards each other, see CODE_OF_CONDUCT.md at the top level of the source
tree, or:

    https://github.com/git/git/blob/master/CODE_OF_CONDUCT.md


* Reporting bugs

When you think git does not behave as you expect, please do not stop
your bug report with just "git does not work".  "I used git in this
way, but it did not work" is not much better, neither is "I used git
in this way, and X happend, which is broken".  It often is that git is
correct to cause X happen in such a case, and it is your expectation
that is broken. People would not know what other result Y you expected
to see instead of X, if you left it unsaid.

Please remember to always state

 - what you wanted to achieve;

 - what you did (the version of git and the command sequence to reproduce
   the behavior);

 - what you saw happen (X above);

 - what you expected to see (Y above); and

 - how the last two are different.

See http://www.chiark.greenend.org.uk/~sgtatham/bugs.html for further
hints.  Our `git bugreport` tool gives you a handy way you can use to
make sure you do not forget these points when filing a bug report.

If you think you found a security-sensitive issue and want to disclose
it to us without announcing it to wider public, please contact us at
our security mailing list <git-security@googlegroups.com>.  This is
a closed list that is limited to people who need to know early about
vulnerabilities, including:

  - people triaging and fixing reported vulnerabilities
  - people operating major git hosting sites with many users
  - people packaging and distributing git to large numbers of people

where these issues are discussed without risk of the information
leaking out before we're ready to make public announcements.


* Repositories and documentation.

My public git.git repositories are (mirrored) at:

  https://git.kernel.org/pub/scm/git/git.git/
  https://kernel.googlesource.com/pub/scm/git/git
  https://repo.or.cz/alt-git.git/
  https://github.com/git/git/
  https://gitlab.com/git-vcs/git/

This one shows not just the main integration branches, but also
individual topics broken out:

  https://github.com/gitster/git/

A few web interfaces are found at:

  http://git.kernel.org/pub/scm/git/git.git
  https://kernel.googlesource.com/pub/scm/git/git
  http://repo.or.cz/w/alt-git.git

Preformatted documentation from the tip of the "master" branch can be
found in:

  https://git.kernel.org/pub/scm/git/git-{htmldocs,manpages}.git/
  https://repo.or.cz/git-{htmldocs,manpages}.git/
  https://github.com/gitster/git-{htmldocs,manpages}.git/

The manual pages formatted in HTML for the tip of 'master' can be
viewed online at:

  https://git.github.io/htmldocs/git.html


* How various branches are used.

There are four "integration" branches in git.git repository that track
the source tree of git: "master", "maint", "next", and "seen".  They
however almost never get new commits made directly on them.  Instead,
a branch is forked from either "master" or "maint" for each "topic",
whether it is a new feature or fix for a bug, and holds a set of
commits that belong to the same theme, and then such a "topic branch"
is merged to these integration branches.

The "master" branch is meant to contain what are very well tested and
ready to be used in a production setting.  Every now and then, a
"feature release" is cut from the tip of this branch.  They used to be
named with three dotted decimal digits (e.g. "1.8.5"), but we have
switched the versioning scheme and "feature releases" are named with
three-dotted decimal digits that ends with ".0" (e.g. "1.9.0").

The last such release was 2.33 done on August 16th, 2021.  You can
expect that the tip of the "master" branch is always more stable than
any of the released versions.

Whenever a feature release is made, "maint" branch is forked off from
"master" at that point.  Obvious and safe fixes after a feature
release are merged to this branch and maintenance releases are cut
from it.  Usually these fixes are merged to the "master" branch first,
several days before merged to the "maint" branch, to reduce the chance
of last-minute issues.  The maintenance releases used to be named with
four dotted decimal, named after the feature release they are updates
to (e.g. "1.8.5.1" was the first maintenance release for "1.8.5"
feature release).  These days, maintenance releases are named by
incrementing the last digit of three-dotted decimal name (e.g.
"2.29.2" was the second maintenance release for the "2.29" series).

New features never go to the "maint" branch.  It is merged into
"master" primarily to propagate the description in the release notes
forward.

A new development does not usually happen on "master". When you send a
series of patches, after review on the mailing list, a separate topic
branch is forked from the tip of "master" (or somewhere older, especially
when the topic is about fixing an earlier bug) and your patches are queued
there, and kept out of "master" while people test it out. The quality of
topic branches are judged primarily by the mailing list discussions.

Topic branches that are in good shape are merged to the "next" branch. In
general, the "next" branch always contains the tip of "master".  It might
not be quite rock-solid, but is expected to work more or less without major
breakage. The "next" branch is where new and exciting things take place. A
topic that is in "next" is expected to be polished to perfection before it
is merged to "master".  Please help this process by building & using the
"next" branch for your daily work, and reporting any new bugs you find to
the mailing list, before the breakage is merged down to the "master".

The "seen" (formerly "pu", proposed updates) branch bundles all the
remaining topic branches the maintainer happens to have seen.  There
is no guarantee that the maintainer has enough bandwidth to pick up any
and all topics that are remotely promising from the list traffic, so
please do not read too much into a topic being on (or not on) the "seen"
branch.  This branch is mainly to remind the maintainer that the topics
in them may turn out to be interesting when they are polished, nothing
more.  The topics on this branch aren't usually complete, well tested,
or well documented and they often need further work.  When a topic that
was in "seen" proves to be in a testable shape, it is merged to "next".

You can run "git log --first-parent master..seen" to see what topics are
currently in flight.  Sometimes, an idea that looked promising turns out
to be not so good and the topic can be dropped from "seen" in such a case.
The output of the above "git log" talks about a "jch" branch, which is an
early part of the "seen" branch; that branch contains all topics that
are in "next" and a bit more (but not all of "seen") and is used by the
maintainer for his daily work.

The two branches "master" and "maint" are never rewound, and "next"
usually will not be either.  After a feature release is made from
"master", however, "next" will be rebuilt from the tip of "master"
using the topics that didn't make the cut in the feature release.
Some topics that used to be in "next" during the previous cycle may
get ejected from "next" when this happens.

A natural consequence of how "next" and "seen" bundles topics together
is that until a topic is merged to "next", updates to it is expected
by replacing the patch(es) in the topic with an improved version,
and once a topic is merged to "next", updates to it needs to come as
incremental patches, pointing out what was wrong in the previous
patches and how the problem was corrected.

Note that being in "next" is not a guarantee to appear in the next
release, nor even in any future release.  There were cases that topics
needed reverting a few commits in them before graduating to "master",
or a topic that already was in "next" was reverted from "next" because
fatal flaws were found in it after it was merged to "next".


* Other people's trees.

Documentation/SubmittingPatches outlines to whom your proposed changes
should be sent.  As described in contrib/README, I would delegate fixes
and enhancements in contrib/ area to the primary contributors of them.

Although the following are included in git.git repository, they have their
own authoritative repository and maintainers:

 - git-gui/ comes from git-gui project, maintained by Pratyush Yadav:

        https://github.com/prati0100/git-gui.git

 - gitk-git/ comes from Paul Mackerras's gitk project:

        git://ozlabs.org/~paulus/gitk

 - po/ comes from the localization coordinator, Jiang Xin:

	https://github.com/git-l10n/git-po/

When sending proposed updates and fixes to these parts of the system,
please base your patches on these trees, not git.git (the former two
even have different directory structures).

A note from the maintainer

[Junio C Hamano]

Welcome to the Git development community.

This message is written by the maintainer and talks about how Git
project is managed, and how you can work with it.

The current maintainer is Junio C Hamano <gitster@pobox.com>; please
do not send any private message to this address, because it is likely
that such a message will not be seen by any human being.  Spam filters
learned that legitimate messages to the address come only from a very
few sender addresses that are known to be good, and messages from all
others are likely to be spam unless they are also sent to the mailing
list at the same time (i.e. "Reply-all" to the list message would
reach the mailbox, but "Reply" will likely be thrown into the spam
folder).


* Mailing list and the community

The development is primarily done on the Git mailing list. Help
requests, feature proposals, bug reports and patches should be sent to
the list address <git@vger.kernel.org>.  You don't have to be
subscribed to send messages.  The convention on the list is to keep
everybody involved on Cc:, so it is unnecessary to say "Please Cc: me,
I am not subscribed".

As an anti-spam measure, the mailing list software rejects messages
that are not text/plain and drops them on the floor.  If you are a
GMail user, you'd want to make sure "Plain text mode" is checked.

Before sending patches, please read Documentation/SubmittingPatches
and Documentation/CodingGuidelines to familiarize yourself with the
project convention.

If you sent a patch and you did not hear any response from anybody for
several days, it could be that your patch was totally uninteresting,
but it also is possible that it was simply lost in the noise.  Please
do not hesitate to send a reminder message in such a case.  Messages
getting lost in the noise may be a sign that those who can evaluate
your patch don't have enough mental/time bandwidth to process them
right at the moment, and it often helps to wait until the list traffic
becomes calmer before sending such a reminder.

The list archive is available at a few public sites:

        http://lore.kernel.org/git/
        http://marc.info/?l=git
        http://www.spinics.net/lists/git/

For those who prefer to read it over NNTP:

	nntp://nntp.lore.kernel.org/org.kernel.vger.git
        nntp://news.public-inbox.org/inbox.comp.version-control.git

are available.

When you point at a message in a mailing list archive, using its
message ID is often the most robust (if not very friendly) way to do
so, like this:

	http://lore.kernel.org/git/Pine.LNX.4.58.0504150753440.7211@ppc970.osdl.org

Often these web interfaces accept the message ID with enclosing <>
stripped (like the above example to point at one of the most important
message in the Git list).

Some members of the development community can sometimes be found on
the #git and #git-devel IRC channels on FreeNode (historically, but
the IRC situation is in flux at the moment).  Their logs are available
at:

        http://colabti.org/irclogger/irclogger_log/git
        http://colabti.org/irclogger/irclogger_log/git-devel

There is a volunteer-run newsletter to serve our community ("Git Rev
News" http://git.github.io/rev_news/).

Git is a member project of software freedom conservancy, a non-profit
organization (https://sfconservancy.org/).  To reach a committee of
liaisons to the conservancy, contact them at <git@sfconservancy.org>.

For our expectations on the behaviour of the community participants
towards each other, see CODE_OF_CONDUCT.md at the top level of the source
tree, or:

    https://github.com/git/git/blob/master/CODE_OF_CONDUCT.md


* Reporting bugs

When you think git does not behave as you expect, please do not stop
your bug report with just "git does not work".  "I used git in this
way, but it did not work" is not much better, neither is "I used git
in this way, and X happend, which is broken".  It often is that git is
correct to cause X happen in such a case, and it is your expectation
that is broken. People would not know what other result Y you expected
to see instead of X, if you left it unsaid.

Please remember to always state

 - what you wanted to achieve;

 - what you did (the version of git and the command sequence to reproduce
   the behavior);

 - what you saw happen (X above);

 - what you expected to see (Y above); and

 - how the last two are different.

See http://www.chiark.greenend.org.uk/~sgtatham/bugs.html for further
hints.  Our `git bugreport` tool gives you a handy way you can use to
make sure you do not forget these points when filing a bug report.

If you think you found a security-sensitive issue and want to disclose
it to us without announcing it to wider public, please contact us at
our security mailing list <git-security@googlegroups.com>.  This is
a closed list that is limited to people who need to know early about
vulnerabilities, including:

  - people triaging and fixing reported vulnerabilities
  - people operating major git hosting sites with many users
  - people packaging and distributing git to large numbers of people

where these issues are discussed without risk of the information
leaking out before we're ready to make public announcements.


* Repositories and documentation.

My public git.git repositories are (mirrored) at:

  https://git.kernel.org/pub/scm/git/git.git/
  https://kernel.googlesource.com/pub/scm/git/git
  https://repo.or.cz/alt-git.git/
  https://github.com/git/git/
  https://gitlab.com/git-vcs/git/

This one shows not just the main integration branches, but also
individual topics broken out:

  https://github.com/gitster/git/

A few web interfaces are found at:

  http://git.kernel.org/pub/scm/git/git.git
  https://kernel.googlesource.com/pub/scm/git/git
  http://repo.or.cz/w/alt-git.git

Preformatted documentation from the tip of the "master" branch can be
found in:

  https://git.kernel.org/pub/scm/git/git-{htmldocs,manpages}.git/
  https://repo.or.cz/git-{htmldocs,manpages}.git/
  https://github.com/gitster/git-{htmldocs,manpages}.git/

The manual pages formatted in HTML for the tip of 'master' can be
viewed online at:

  https://git.github.io/htmldocs/git.html


* How various branches are used.

There are four branches in git.git repository that track the source tree
of git: "master", "maint", "next", and "seen".

The "master" branch is meant to contain what are very well tested and
ready to be used in a production setting.  Every now and then, a
"feature release" is cut from the tip of this branch.  They used to be
named with three dotted decimal digits (e.g. "1.8.5"), but we have
switched the versioning scheme and "feature releases" are named with
three-dotted decimal digits that ends with ".0" (e.g. "1.9.0").

The last such release was 2.32 done on June 6th, 2021.  You can expect
that the tip of the "master" branch is always more stable than any of
the released versions.

Whenever a feature release is made, "maint" branch is forked off from
"master" at that point.  Obvious and safe fixes after a feature
release are applied to this branch and maintenance releases are cut
from it.  Usually the fixes are merged to the "master" branch first,
several days before merged to the "maint" branch, to reduce the chance
of last-minute issues.  The maintenance releases used to be named with
four dotted decimal, named after the feature release they are updates
to (e.g. "1.8.5.1" was the first maintenance release for "1.8.5"
feature release).  These days, maintenance releases are named by
incrementing the last digit of three-dotted decimal name (e.g. "2.29.2"
was the second maintenance release for the "2.29" series).

New features never go to the 'maint' branch.  It is merged into "master"
primarily to propagate the description in the release notes forward.

A new development does not usually happen on "master". When you send a
series of patches, after review on the mailing list, a separate topic
branch is forked from the tip of "master" (or somewhere older, especially
when the topic is about fixing an earlier bug) and your patches are queued
there, and kept out of "master" while people test it out. The quality of
topic branches are judged primarily by the mailing list discussions.

Topic branches that are in good shape are merged to the "next" branch. In
general, the "next" branch always contains the tip of "master".  It might
not be quite rock-solid, but is expected to work more or less without major
breakage. The "next" branch is where new and exciting things take place. A
topic that is in "next" is expected to be polished to perfection before it
is merged to "master".  Please help this process by building & using the
"next" branch for your daily work, and reporting any new bugs you find to
the mailing list, before the breakage is merged down to the "master".

The "seen" (formerly "pu", proposed updates) branch bundles all the
remaining topic branches the maintainer happens to have seen.  There
is no guarantee that the maintainer has enough bandwidth to pick up any
and all topics that are remotely promising from the list traffic, so
please do not read too much into a topic being on (or not on) the "seen"
branch.  This branch is mainly to remind the maintainer that the topics
in them may turn out to be interesting when they are polished, nothing
more.  The topics on this branch aren't usually complete, well tested,
or well documented and they often need further work.  When a topic that
was in "seen" proves to be in a testable shape, it is merged to "next".

You can run "git log --first-parent master..seen" to see what topics are
currently in flight.  Sometimes, an idea that looked promising turns out
to be not so good and the topic can be dropped from "seen" in such a case.
The output of the above "git log" talks about a "jch" branch, which is an
early part of the "seen" branch; that branch contains all topics that
are in "next" and a bit more (but not all of "seen") and is used by the
maintainer for his daily work.

The two branches "master" and "maint" are never rewound, and "next"
usually will not be either.  After a feature release is made from
"master", however, "next" will be rebuilt from the tip of "master"
using the topics that didn't make the cut in the feature release.
Some topics that used to be in "next" during the previous cycle may
get ejected from "next" when this happens.

A natural consequence of how "next" and "seen" bundles topics together
is that until a topic is merged to "next", updates to it is expected
by replacing the patch(es) in the topic with an improved version,
and once a topic is merged to "next", updates to it needs to come as
incremental patches, pointing out what was wrong in the previous
patches and how the problem was corrected.

Note that being in "next" is not a guarantee to appear in the next
release, nor even in any future release.  There were cases that topics
needed reverting a few commits in them before graduating to "master",
or a topic that already was in "next" was reverted from "next" because
fatal flaws were found in it after it was merged to "next".


* Other people's trees.

Documentation/SubmittingPatches outlines to whom your proposed changes
should be sent.  As described in contrib/README, I would delegate fixes
and enhancements in contrib/ area to the primary contributors of them.

Although the following are included in git.git repository, they have their
own authoritative repository and maintainers:

 - git-gui/ comes from git-gui project, maintained by Pratyush Yadav:

        https://github.com/prati0100/git-gui.git

 - gitk-git/ comes from Paul Mackerras's gitk project:

        git://ozlabs.org/~paulus/gitk

 - po/ comes from the localization coordinator, Jiang Xin:

	https://github.com/git-l10n/git-po/

When sending proposed updates and fixes to these parts of the system,
please base your patches on these trees, not git.git (the former two
even have different directory structures).

A note from the maintainer

[Junio C Hamano]

Welcome to the Git development community.

This message is written by the maintainer and talks about how Git
project is managed, and how you can work with it.

The current maintainer is Junio C Hamano <gitster@pobox.com>; please
do not send any private message to this address, because it is likely
that such a message will not be seen by any human being.  Spam filters
learned that legitimate messages to the address come only from a very
few sender addresses that are known to be good, and messages from all
others are likely to be spam unless they are also sent to the mailing
list at the same time (i.e. "Reply-all" to the list message would
reach the mailbox, but "Reply" will likely be thrown into the spam
folder).


* Mailing list and the community

The development is primarily done on the Git mailing list. Help
requests, feature proposals, bug reports and patches should be sent to
the list address <git@vger.kernel.org>.  You don't have to be
subscribed to send messages.  The convention on the list is to keep
everybody involved on Cc:, so it is unnecessary to say "Please Cc: me,
I am not subscribed".

As an anti-spam measure, the mailing list software rejects messages
that are not text/plain and drops them on the floor.  If you are a
GMail user, you'd want to make sure "Plain text mode" is checked.

Before sending patches, please read Documentation/SubmittingPatches
and Documentation/CodingGuidelines to familiarize yourself with the
project convention.

If you sent a patch and you did not hear any response from anybody for
several days, it could be that your patch was totally uninteresting,
but it also is possible that it was simply lost in the noise.  Please
do not hesitate to send a reminder message in such a case.  Messages
getting lost in the noise may be a sign that those who can evaluate
your patch don't have enough mental/time bandwidth to process them
right at the moment, and it often helps to wait until the list traffic
becomes calmer before sending such a reminder.

The list archive is available at a few public sites:

        http://lore.kernel.org/git/
        http://marc.info/?l=git
        http://www.spinics.net/lists/git/

For those who prefer to read it over NNTP:

	nntp://nntp.lore.kernel.org/org.kernel.vger.git
        nntp://news.public-inbox.org/inbox.comp.version-control.git

are available.

When you point at a message in a mailing list archive, using its
message ID is often the most robust (if not very friendly) way to do
so, like this:

	http://lore.kernel.org/git/Pine.LNX.4.58.0504150753440.7211@ppc970.osdl.org

Often these web interfaces accept the message ID with enclosing <>
stripped (like the above example to point at one of the most important
message in the Git list).

Some members of the development community can sometimes be found on
the #git and #git-devel IRC channels on Freenode.  Their logs are
available at:

        http://colabti.org/irclogger/irclogger_log/git
        http://colabti.org/irclogger/irclogger_log/git-devel

There is a volunteer-run newsletter to serve our community ("Git Rev
News" http://git.github.io/rev_news/).

Git is a member project of software freedom conservancy, a non-profit
organization (https://sfconservancy.org/).  To reach a committee of
liaisons to the conservancy, contact them at <git@sfconservancy.org>.

For our expectations on the behaviour of the community participants
towards each other, see CODE_OF_CONDUCT.md at the top level of the source
tree, or:

    https://github.com/git/git/blob/master/CODE_OF_CONDUCT.md


* Reporting bugs

When you think git does not behave as you expect, please do not stop
your bug report with just "git does not work".  "I used git in this
way, but it did not work" is not much better, neither is "I used git
in this way, and X happend, which is broken".  It often is that git is
correct to cause X happen in such a case, and it is your expectation
that is broken. People would not know what other result Y you expected
to see instead of X, if you left it unsaid.

Please remember to always state

 - what you wanted to achieve;

 - what you did (the version of git and the command sequence to reproduce
   the behavior);

 - what you saw happen (X above);

 - what you expected to see (Y above); and

 - how the last two are different.

See http://www.chiark.greenend.org.uk/~sgtatham/bugs.html for further
hints.  Our `git bugreport` tool gives you a handy way you can use to
make sure you do not forget these points when filing a bug report.

If you think you found a security-sensitive issue and want to disclose
it to us without announcing it to wider public, please contact us at
our security mailing list <git-security@googlegroups.com>.  This is
a closed list that is limited to people who need to know early about
vulnerabilities, including:

  - people triaging and fixing reported vulnerabilities
  - people operating major git hosting sites with many users
  - people packaging and distributing git to large numbers of people

where these issues are discussed without risk of the information
leaking out before we're ready to make public announcements.


* Repositories and documentation.

My public git.git repositories are (mirrored) at:

  https://git.kernel.org/pub/scm/git/git.git/
  https://kernel.googlesource.com/pub/scm/git/git
  https://repo.or.cz/alt-git.git/
  https://github.com/git/git/
  https://gitlab.com/git-vcs/git/

This one shows not just the main integration branches, but also
individual topics broken out:

  https://github.com/gitster/git/

A few web interfaces are found at:

  http://git.kernel.org/pub/scm/git/git.git
  https://kernel.googlesource.com/pub/scm/git/git
  http://repo.or.cz/w/alt-git.git

Preformatted documentation from the tip of the "master" branch can be
found in:

  https://git.kernel.org/pub/scm/git/git-{htmldocs,manpages}.git/
  https://repo.or.cz/git-{htmldocs,manpages}.git/
  https://github.com/gitster/git-{htmldocs,manpages}.git/

The manual pages formatted in HTML for the tip of 'master' can be
viewed online at:

  https://git.github.io/htmldocs/git.html


* How various branches are used.

There are four branches in git.git repository that track the source tree
of git: "master", "maint", "next", and "seen".

The "master" branch is meant to contain what are very well tested and
ready to be used in a production setting.  Every now and then, a
"feature release" is cut from the tip of this branch.  They used to be
named with three dotted decimal digits (e.g. "1.8.5"), but we have
switched the versioning scheme and "feature releases" are named with
three-dotted decimal digits that ends with ".0" (e.g. "1.9.0").

The last such release was 2.31 done on Mar 15th, 2021.  You can expect
that the tip of the "master" branch is always more stable than any of
the released versions.

Whenever a feature release is made, "maint" branch is forked off from
"master" at that point.  Obvious and safe fixes after a feature
release are applied to this branch and maintenance releases are cut
from it.  Usually the fixes are merged to the "master" branch first,
several days before merged to the "maint" branch, to reduce the chance
of last-minute issues.  The maintenance releases used to be named with
four dotted decimal, named after the feature release they are updates
to (e.g. "1.8.5.1" was the first maintenance release for "1.8.5"
feature release).  These days, maintenance releases are named by
incrementing the last digit of three-dotted decimal name (e.g. "2.29.2"
was the second maintenance release for the "2.29" series).

New features never go to the 'maint' branch.  It is merged into "master"
primarily to propagate the description in the release notes forward.

A new development does not usually happen on "master". When you send a
series of patches, after review on the mailing list, a separate topic
branch is forked from the tip of "master" (or somewhere older, especially
when the topic is about fixing an earlier bug) and your patches are queued
there, and kept out of "master" while people test it out. The quality of
topic branches are judged primarily by the mailing list discussions.

Topic branches that are in good shape are merged to the "next" branch. In
general, the "next" branch always contains the tip of "master".  It might
not be quite rock-solid, but is expected to work more or less without major
breakage. The "next" branch is where new and exciting things take place. A
topic that is in "next" is expected to be polished to perfection before it
is merged to "master".  Please help this process by building & using the
"next" branch for your daily work, and reporting any new bugs you find to
the mailing list, before the breakage is merged down to the "master".

The "seen" (formerly "pu", proposed updates) branch bundles all the
remaining topic branches the maintainer happens to have seen.  There
is no guarantee that the maintainer has enough bandwidth to pick up any
and all topics that are remotely promising from the list traffic, so
please do not read too much into a topic being on (or not on) the "seen"
branch.  This branch is mainly to remind the maintainer that the topics
in them may turn out to be interesting when they are polished, nothing
more.  The topics on this branch aren't usually complete, well tested,
or well documented and they often need further work.  When a topic that
was in "seen" proves to be in a testable shape, it is merged to "next".

You can run "git log --first-parent master..seen" to see what topics are
currently in flight.  Sometimes, an idea that looked promising turns out
to be not so good and the topic can be dropped from "seen" in such a case.
The output of the above "git log" talks about a "jch" branch, which is an
early part of the "seen" branch; that branch contains all topics that
are in "next" and a bit more (but not all of "seen") and is used by the
maintainer for his daily work.

The two branches "master" and "maint" are never rewound, and "next"
usually will not be either.  After a feature release is made from
"master", however, "next" will be rebuilt from the tip of "master"
using the topics that didn't make the cut in the feature release.
Some topics that used to be in "next" during the previous cycle may
get ejected from "next" when this happens.

A natural consequence of how "next" and "seen" bundles topics together
is that until a topic is merged to "next", updates to it is expected
by replacing the patch(es) in the topic with an improved version,
and once a topic is merged to "next", updates to it needs to come as
incremental patches, pointing out what was wrong in the previous
patches and how the problem was corrected.

Note that being in "next" is not a guarantee to appear in the next
release, nor even in any future release.  There were cases that topics
needed reverting a few commits in them before graduating to "master",
or a topic that already was in "next" was reverted from "next" because
fatal flaws were found in it after it was merged to "next".


* Other people's trees.

Documentation/SubmittingPatches outlines to whom your proposed changes
should be sent.  As described in contrib/README, I would delegate fixes
and enhancements in contrib/ area to the primary contributors of them.

Although the following are included in git.git repository, they have their
own authoritative repository and maintainers:

 - git-gui/ comes from git-gui project, maintained by Pratyush Yadav:

        https://github.com/prati0100/git-gui.git

 - gitk-git/ comes from Paul Mackerras's gitk project:

        git://ozlabs.org/~paulus/gitk

 - po/ comes from the localization coordinator, Jiang Xin:

	https://github.com/git-l10n/git-po/

When sending proposed updates and fixes to these parts of the system,
please base your patches on these trees, not git.git (the former two
even have different directory structures).

Re: A note from the maintainer

[Bagas Sanjaya]

On 27/03/21 05.53, Junio C Hamano wrote:
> Welcome to the Git development community.
> 
> This message is written by the maintainer and talks about how Git
> project is managed, and how you can work with it.
> 
> The current maintainer is Junio C Hamano <gitster@pobox.com>; please
> do not send any private message to this address, because it is likely
> that such a message will not be seen by any human being.  Spam filters
> learned that legitimate messages to the address come only from a very
> few sender addresses that are known to be good, and messages from all
> others are likely to be spam unless they are also sent to the mailing
> list at the same time (i.e. "Reply-all" to the list message would
> reach the mailbox, but "Reply" will likely be thrown into the spam
> folder).
> 
> 
> * Mailing list and the community
> 
> The development is primarily done on the Git mailing list. Help
> requests, feature proposals, bug reports and patches should be sent to
> the list address <git@vger.kernel.org>.  You don't have to be
> subscribed to send messages.  The convention on the list is to keep
> everybody involved on Cc:, so it is unnecessary to say "Please Cc: me,
> I am not subscribed".
> 
> As an anti-spam measure, the mailing list software rejects messages
> that are not text/plain and drops them on the floor.  If you are a
> GMail user, you'd want to make sure "Plain text mode" is checked.
> 
> Before sending patches, please read Documentation/SubmittingPatches
> and Documentation/CodingGuidelines to familiarize yourself with the
> project convention.
> 
> If you sent a patch and you did not hear any response from anybody for
> several days, it could be that your patch was totally uninteresting,
> but it also is possible that it was simply lost in the noise.  Please
> do not hesitate to send a reminder message in such a case.  Messages
> getting lost in the noise may be a sign that those who can evaluate
> your patch don't have enough mental/time bandwidth to process them
> right at the moment, and it often helps to wait until the list traffic
> becomes calmer before sending such a reminder.
> 
> The list archive is available at a few public sites:
> 
>          http://lore.kernel.org/git/
>          http://marc.info/?l=git
>          http://www.spinics.net/lists/git/
> 
> For those who prefer to read it over NNTP:
> 
> 	nntp://nntp.lore.kernel.org/org.kernel.vger.git
>          nntp://news.public-inbox.org/inbox.comp.version-control.git
> 
> are available.
> 
> When you point at a message in a mailing list archive, using its
> message ID is often the most robust (if not very friendly) way to do
> so, like this:
> 
> 	http://lore.kernel.org/git/Pine.LNX.4.58.0504150753440.7211@ppc970.osdl.org
> 
> Often these web interfaces accept the message ID with enclosing <>
> stripped (like the above example to point at one of the most important
> message in the Git list).
> 
> Some members of the development community can sometimes be found on
> the #git and #git-devel IRC channels on Freenode.  Their logs are
> available at:
> 
>          http://colabti.org/irclogger/irclogger_log/git
>          http://colabti.org/irclogger/irclogger_log/git-devel
> 
> There is a volunteer-run newsletter to serve our community ("Git Rev
> News" http://git.github.io/rev_news/).
> 
> Git is a member project of software freedom conservancy, a non-profit
> organization (https://sfconservancy.org/).  To reach a committee of
> liaisons to the conservancy, contact them at <git@sfconservancy.org>.
> 
> For our expectations on the behaviour of the community participants
> towards each other, see CODE_OF_CONDUCT.md at the top level of the source
> tree, or:
> 
>      https://github.com/git/git/blob/master/CODE_OF_CONDUCT.md
> 
> 
> * Reporting bugs
> 
> When you think git does not behave as you expect, please do not stop
> your bug report with just "git does not work".  "I used git in this
> way, but it did not work" is not much better, neither is "I used git
> in this way, and X happend, which is broken".  It often is that git is
> correct to cause X happen in such a case, and it is your expectation
> that is broken. People would not know what other result Y you expected
> to see instead of X, if you left it unsaid.
> 
> Please remember to always state
> 
>   - what you wanted to achieve;
> 
>   - what you did (the version of git and the command sequence to reproduce
>     the behavior);
> 
>   - what you saw happen (X above);
> 
>   - what you expected to see (Y above); and
> 
>   - how the last two are different.
> 
> See http://www.chiark.greenend.org.uk/~sgtatham/bugs.html for further
> hints.  Our `git bugreport` tool gives you a handy way you can use to
> make sure you do not forget these points when filing a bug report.
> 
> If you think you found a security-sensitive issue and want to disclose
> it to us without announcing it to wider public, please contact us at
> our security mailing list <git-security@googlegroups.com>.  This is
> a closed list that is limited to people who need to know early about
> vulnerabilities, including:
> 
>    - people triaging and fixing reported vulnerabilities
>    - people operating major git hosting sites with many users
>    - people packaging and distributing git to large numbers of people
> 
> where these issues are discussed without risk of the information
> leaking out before we're ready to make public announcements.
> 
> 
> * Repositories and documentation.
> 
> My public git.git repositories are (mirrored) at:
> 
>    https://git.kernel.org/pub/scm/git/git.git/
>    https://kernel.googlesource.com/pub/scm/git/git
>    https://repo.or.cz/alt-git.git/
>    https://github.com/git/git/
>    https://gitlab.com/git-vcs/git/
> 
> This one shows not just the main integration branches, but also
> individual topics broken out:
> 
>    https://github.com/gitster/git/
> 
> A few web interfaces are found at:
> 
>    http://git.kernel.org/pub/scm/git/git.git
>    https://kernel.googlesource.com/pub/scm/git/git
>    http://repo.or.cz/w/alt-git.git
> 
> Preformatted documentation from the tip of the "master" branch can be
> found in:
> 
>    https://git.kernel.org/pub/scm/git/git-{htmldocs,manpages}.git/
>    https://repo.or.cz/git-{htmldocs,manpages}.git/
>    https://github.com/gitster/git-{htmldocs,manpages}.git/
> 
> The manual pages formatted in HTML for the tip of 'master' can be
> viewed online at:
> 
>    https://git.github.io/htmldocs/git.html
> 
> 
> * How various branches are used.
> 
> There are four branches in git.git repository that track the source tree
> of git: "master", "maint", "next", and "seen".
> 
> The "master" branch is meant to contain what are very well tested and
> ready to be used in a production setting.  Every now and then, a
> "feature release" is cut from the tip of this branch.  They used to be
> named with three dotted decimal digits (e.g. "1.8.5"), but we have
> switched the versioning scheme and "feature releases" are named with
> three-dotted decimal digits that ends with ".0" (e.g. "1.9.0").
> 
> The last such release was 2.31 done on Mar 15th, 2021.  You can expect
> that the tip of the "master" branch is always more stable than any of
> the released versions.
> 
> Whenever a feature release is made, "maint" branch is forked off from
> "master" at that point.  Obvious and safe fixes after a feature
> release are applied to this branch and maintenance releases are cut
> from it.  Usually the fixes are merged to the "master" branch first,
> several days before merged to the "maint" branch, to reduce the chance
> of last-minute issues.  The maintenance releases used to be named with
> four dotted decimal, named after the feature release they are updates
> to (e.g. "1.8.5.1" was the first maintenance release for "1.8.5"
> feature release).  These days, maintenance releases are named by
> incrementing the last digit of three-dotted decimal name (e.g. "2.29.2"
> was the second maintenance release for the "2.29" series).
> 
> New features never go to the 'maint' branch.  It is merged into "master"
> primarily to propagate the description in the release notes forward.
> 
> A new development does not usually happen on "master". When you send a
> series of patches, after review on the mailing list, a separate topic
> branch is forked from the tip of "master" (or somewhere older, especially
> when the topic is about fixing an earlier bug) and your patches are queued
> there, and kept out of "master" while people test it out. The quality of
> topic branches are judged primarily by the mailing list discussions.
> 
> Topic branches that are in good shape are merged to the "next" branch. In
> general, the "next" branch always contains the tip of "master".  It might
> not be quite rock-solid, but is expected to work more or less without major
> breakage. The "next" branch is where new and exciting things take place. A
> topic that is in "next" is expected to be polished to perfection before it
> is merged to "master".  Please help this process by building & using the
> "next" branch for your daily work, and reporting any new bugs you find to
> the mailing list, before the breakage is merged down to the "master".
> 
> The "seen" (formerly "pu", proposed updates) branch bundles all the
> remaining topic branches the maintainer happens to have seen.  There
> is no guarantee that the maintainer has enough bandwidth to pick up any
> and all topics that are remotely promising from the list traffic, so
> please do not read too much into a topic being on (or not on) the "seen"
> branch.  This branch is mainly to remind the maintainer that the topics
> in them may turn out to be interesting when they are polished, nothing
> more.  The topics on this branch aren't usually complete, well tested,
> or well documented and they often need further work.  When a topic that
> was in "seen" proves to be in a testable shape, it is merged to "next".
> 
> You can run "git log --first-parent master..seen" to see what topics are
> currently in flight.  Sometimes, an idea that looked promising turns out
> to be not so good and the topic can be dropped from "seen" in such a case.
> The output of the above "git log" talks about a "jch" branch, which is an
> early part of the "seen" branch; that branch contains all topics that
> are in "next" and a bit more (but not all of "seen") and is used by the
> maintainer for his daily work.
> 
> The two branches "master" and "maint" are never rewound, and "next"
> usually will not be either.  After a feature release is made from
> "master", however, "next" will be rebuilt from the tip of "master"
> using the topics that didn't make the cut in the feature release.
> Some topics that used to be in "next" during the previous cycle may
> get ejected from "next" when this happens.
> 
> A natural consequence of how "next" and "seen" bundles topics together
> is that until a topic is merged to "next", updates to it is expected
> by replacing the patch(es) in the topic with an improved version,
> and once a topic is merged to "next", updates to it needs to come as
> incremental patches, pointing out what was wrong in the previous
> patches and how the problem was corrected.
> 
> Note that being in "next" is not a guarantee to appear in the next
> release, nor even in any future release.  There were cases that topics
> needed reverting a few commits in them before graduating to "master",
> or a topic that already was in "next" was reverted from "next" because
> fatal flaws were found in it after it was merged to "next".
> 
> 
> * Other people's trees.
> 
> Documentation/SubmittingPatches outlines to whom your proposed changes
> should be sent.  As described in contrib/README, I would delegate fixes
> and enhancements in contrib/ area to the primary contributors of them.
> 
> Although the following are included in git.git repository, they have their
> own authoritative repository and maintainers:
> 
>   - git-gui/ comes from git-gui project, maintained by Pratyush Yadav:
> 
>          https://github.com/prati0100/git-gui.git
> 
>   - gitk-git/ comes from Paul Mackerras's gitk project:
> 
>          git://ozlabs.org/~paulus/gitk
> 
>   - po/ comes from the localization coordinator, Jiang Xin:
> 
> 	https://github.com/git-l10n/git-po/
> 
> When sending proposed updates and fixes to these parts of the system,
> please base your patches on these trees, not git.git (the former two
> even have different directory structures).
> 
Grazie Junio for this message note.

I would like to see the note above in CONTRIBUTING.md, because new
contributors will most likely read CONTRIBUTING.md rather than searching
this ML archive for the note.

-- 
An old man doll... just what I always wanted! - Clara

A note from the maintainer

[Junio C Hamano]

Welcome to the Git development community.

This message is written by the maintainer and talks about how Git
project is managed, and how you can work with it.

The current maintainer is Junio C Hamano <gitster@pobox.com>; please
do not send any private message to this address, because it is likely
that such a message will not be seen by any human being.  Spam filters
learned that legitimate messages to the address come only from a very
few sender addresses that are known to be good, and messages from all
others are likely to be spam unless they are also sent to the mailing
list at the same time (i.e. "Reply-all" to the list message would
reach the mailbox, but "Reply" will likely be thrown into the spam
folder).


* Mailing list and the community

The development is primarily done on the Git mailing list. Help
requests, feature proposals, bug reports and patches should be sent to
the list address <git@vger.kernel.org>.  You don't have to be
subscribed to send messages.  The convention on the list is to keep
everybody involved on Cc:, so it is unnecessary to say "Please Cc: me,
I am not subscribed".

As an anti-spam measure, the mailing list software rejects messages
that are not text/plain and drops them on the floor.  If you are a
GMail user, you'd want to make sure "Plain text mode" is checked.

Before sending patches, please read Documentation/SubmittingPatches
and Documentation/CodingGuidelines to familiarize yourself with the
project convention.

If you sent a patch and you did not hear any response from anybody for
several days, it could be that your patch was totally uninteresting,
but it also is possible that it was simply lost in the noise.  Please
do not hesitate to send a reminder message in such a case.  Messages
getting lost in the noise may be a sign that those who can evaluate
your patch don't have enough mental/time bandwidth to process them
right at the moment, and it often helps to wait until the list traffic
becomes calmer before sending such a reminder.

The list archive is available at a few public sites:

        http://lore.kernel.org/git/
        http://marc.info/?l=git
        http://www.spinics.net/lists/git/

For those who prefer to read it over NNTP:

	nntp://nntp.lore.kernel.org/org.kernel.vger.git
        nntp://news.public-inbox.org/inbox.comp.version-control.git

are available.

When you point at a message in a mailing list archive, using its
message ID is often the most robust (if not very friendly) way to do
so, like this:

	http://lore.kernel.org/git/Pine.LNX.4.58.0504150753440.7211@ppc970.osdl.org

Often these web interfaces accept the message ID with enclosing <>
stripped (like the above example to point at one of the most important
message in the Git list).

Some members of the development community can sometimes be found on
the #git and #git-devel IRC channels on Freenode.  Their logs are
available at:

        http://colabti.org/irclogger/irclogger_log/git
        http://colabti.org/irclogger/irclogger_log/git-devel

There is a volunteer-run newsletter to serve our community ("Git Rev
News" http://git.github.io/rev_news/).

Git is a member project of software freedom conservancy, a non-profit
organization (https://sfconservancy.org/).  To reach a committee of
liaisons to the conservancy, contact them at <git@sfconservancy.org>.

For our expectations on the behaviour of the community participants
towards each other, see CODE_OF_CONDUCT.md at the top level of the source
tree, or:

    https://github.com/git/git/blob/master/CODE_OF_CONDUCT.md


* Reporting bugs

When you think git does not behave as you expect, please do not stop
your bug report with just "git does not work".  "I used git in this
way, but it did not work" is not much better, neither is "I used git
in this way, and X happend, which is broken".  It often is that git is
correct to cause X happen in such a case, and it is your expectation
that is broken. People would not know what other result Y you expected
to see instead of X, if you left it unsaid.

Please remember to always state

 - what you wanted to achieve;

 - what you did (the version of git and the command sequence to reproduce
   the behavior);

 - what you saw happen (X above);

 - what you expected to see (Y above); and

 - how the last two are different.

See http://www.chiark.greenend.org.uk/~sgtatham/bugs.html for further
hints.  Our `git bugreport` tool gives you a handy way you can use to
make sure you do not forget these points when filing a bug report.

If you think you found a security-sensitive issue and want to disclose
it to us without announcing it to wider public, please contact us at
our security mailing list <git-security@googlegroups.com>.  This is
a closed list that is limited to people who need to know early about
vulnerabilities, including:

  - people triaging and fixing reported vulnerabilities
  - people operating major git hosting sites with many users
  - people packaging and distributing git to large numbers of people

where these issues are discussed without risk of the information
leaking out before we're ready to make public announcements.


* Repositories and documentation.

My public git.git repositories are (mirrored) at:

  https://git.kernel.org/pub/scm/git/git.git/
  https://kernel.googlesource.com/pub/scm/git/git
  https://repo.or.cz/alt-git.git/
  https://github.com/git/git/
  https://gitlab.com/git-vcs/git/

This one shows not just the main integration branches, but also
individual topics broken out:

  https://github.com/gitster/git/

A few web interfaces are found at:

  http://git.kernel.org/pub/scm/git/git.git
  https://kernel.googlesource.com/pub/scm/git/git
  http://repo.or.cz/w/alt-git.git

Preformatted documentation from the tip of the "master" branch can be
found in:

  https://git.kernel.org/pub/scm/git/git-{htmldocs,manpages}.git/
  https://repo.or.cz/git-{htmldocs,manpages}.git/
  https://github.com/gitster/git-{htmldocs,manpages}.git/

The manual pages formatted in HTML for the tip of 'master' can be
viewed online at:

  https://git.github.io/htmldocs/git.html


* How various branches are used.

There are four branches in git.git repository that track the source tree
of git: "master", "maint", "next", and "seen".

The "master" branch is meant to contain what are very well tested and
ready to be used in a production setting.  Every now and then, a
"feature release" is cut from the tip of this branch.  They used to be
named with three dotted decimal digits (e.g. "1.8.5"), but we have
switched the versioning scheme and "feature releases" are named with
three-dotted decimal digits that ends with ".0" (e.g. "1.9.0").

The last such release was 2.31 done on Mar 15th, 2021.  You can expect
that the tip of the "master" branch is always more stable than any of
the released versions.

Whenever a feature release is made, "maint" branch is forked off from
"master" at that point.  Obvious and safe fixes after a feature
release are applied to this branch and maintenance releases are cut
from it.  Usually the fixes are merged to the "master" branch first,
several days before merged to the "maint" branch, to reduce the chance
of last-minute issues.  The maintenance releases used to be named with
four dotted decimal, named after the feature release they are updates
to (e.g. "1.8.5.1" was the first maintenance release for "1.8.5"
feature release).  These days, maintenance releases are named by
incrementing the last digit of three-dotted decimal name (e.g. "2.29.2"
was the second maintenance release for the "2.29" series).

New features never go to the 'maint' branch.  It is merged into "master"
primarily to propagate the description in the release notes forward.

A new development does not usually happen on "master". When you send a
series of patches, after review on the mailing list, a separate topic
branch is forked from the tip of "master" (or somewhere older, especially
when the topic is about fixing an earlier bug) and your patches are queued
there, and kept out of "master" while people test it out. The quality of
topic branches are judged primarily by the mailing list discussions.

Topic branches that are in good shape are merged to the "next" branch. In
general, the "next" branch always contains the tip of "master".  It might
not be quite rock-solid, but is expected to work more or less without major
breakage. The "next" branch is where new and exciting things take place. A
topic that is in "next" is expected to be polished to perfection before it
is merged to "master".  Please help this process by building & using the
"next" branch for your daily work, and reporting any new bugs you find to
the mailing list, before the breakage is merged down to the "master".

The "seen" (formerly "pu", proposed updates) branch bundles all the
remaining topic branches the maintainer happens to have seen.  There
is no guarantee that the maintainer has enough bandwidth to pick up any
and all topics that are remotely promising from the list traffic, so
please do not read too much into a topic being on (or not on) the "seen"
branch.  This branch is mainly to remind the maintainer that the topics
in them may turn out to be interesting when they are polished, nothing
more.  The topics on this branch aren't usually complete, well tested,
or well documented and they often need further work.  When a topic that
was in "seen" proves to be in a testable shape, it is merged to "next".

You can run "git log --first-parent master..seen" to see what topics are
currently in flight.  Sometimes, an idea that looked promising turns out
to be not so good and the topic can be dropped from "seen" in such a case.
The output of the above "git log" talks about a "jch" branch, which is an
early part of the "seen" branch; that branch contains all topics that
are in "next" and a bit more (but not all of "seen") and is used by the
maintainer for his daily work.

The two branches "master" and "maint" are never rewound, and "next"
usually will not be either.  After a feature release is made from
"master", however, "next" will be rebuilt from the tip of "master"
using the topics that didn't make the cut in the feature release.
Some topics that used to be in "next" during the previous cycle may
get ejected from "next" when this happens.

A natural consequence of how "next" and "seen" bundles topics together
is that until a topic is merged to "next", updates to it is expected
by replacing the patch(es) in the topic with an improved version,
and once a topic is merged to "next", updates to it needs to come as
incremental patches, pointing out what was wrong in the previous
patches and how the problem was corrected.

Note that being in "next" is not a guarantee to appear in the next
release, nor even in any future release.  There were cases that topics
needed reverting a few commits in them before graduating to "master",
or a topic that already was in "next" was reverted from "next" because
fatal flaws were found in it after it was merged to "next".


* Other people's trees.

Documentation/SubmittingPatches outlines to whom your proposed changes
should be sent.  As described in contrib/README, I would delegate fixes
and enhancements in contrib/ area to the primary contributors of them.

Although the following are included in git.git repository, they have their
own authoritative repository and maintainers:

 - git-gui/ comes from git-gui project, maintained by Pratyush Yadav:

        https://github.com/prati0100/git-gui.git

 - gitk-git/ comes from Paul Mackerras's gitk project:

        git://ozlabs.org/~paulus/gitk

 - po/ comes from the localization coordinator, Jiang Xin:

	https://github.com/git-l10n/git-po/

When sending proposed updates and fixes to these parts of the system,
please base your patches on these trees, not git.git (the former two
even have different directory structures).

A note from the maintainer

[Junio C Hamano]

Welcome to the Git development community.

This message is written by the maintainer and talks about how Git
project is managed, and how you can work with it.

The current maintainer is Junio C Hamano <gitster@pobox.com>; please
do not send any private message to this address, because it is likely
that such a message will not be seen by any human being.  Spam filters
learned that legitimate messages to the address come only from a very
few sender addresses that are known to be good, and messages from all
others are likely to be spam unless they are also sent to the mailing
list at the same time (i.e. "Reply-all" to the list message would
reach the mailbox, but "Reply" will likely be thrown into the spam
folder).


* Mailing list and the community

The development is primarily done on the Git mailing list. Help
requests, feature proposals, bug reports and patches should be sent to
the list address <git@vger.kernel.org>.  You don't have to be
subscribed to send messages.  The convention on the list is to keep
everybody involved on Cc:, so it is unnecessary to say "Please Cc: me,
I am not subscribed".

As an anti-spam measure, the mailing list software rejects messages
that are not text/plain and drops them on the floor.  If you are a
GMail user, you'd want to make sure "Plain text mode" is checked.

Before sending patches, please read Documentation/SubmittingPatches
and Documentation/CodingGuidelines to familiarize yourself with the
project convention.

If you sent a patch and you did not hear any response from anybody for
several days, it could be that your patch was totally uninteresting,
but it also is possible that it was simply lost in the noise.  Please
do not hesitate to send a reminder message in such a case.  Messages
getting lost in the noise may be a sign that those who can evaluate
your patch don't have enough mental/time bandwidth to process them
right at the moment, and it often helps to wait until the list traffic
becomes calmer before sending such a reminder.

The list archive is available at a few public sites:

        http://lore.kernel.org/git/
        http://marc.info/?l=git
        http://www.spinics.net/lists/git/

For those who prefer to read it over NNTP:

	nntp://nntp.lore.kernel.org/org.kernel.vger.git
        nntp://news.public-inbox.org/inbox.comp.version-control.git

are available.

When you point at a message in a mailing list archive, using its
message ID is often the most robust (if not very friendly) way to do
so, like this:

	http://lore.kernel.org/git/Pine.LNX.4.58.0504150753440.7211@ppc970.osdl.org

Often these web interfaces accept the message ID with enclosing <>
stripped (like the above example to point at one of the most important
message in the Git list).

Some members of the development community can sometimes be found on
the #git and #git-devel IRC channels on Freenode.  Their logs are
available at:

        http://colabti.org/irclogger/irclogger_log/git
        http://colabti.org/irclogger/irclogger_log/git-devel

There is a volunteer-run newsletter to serve our community ("Git Rev
News" http://git.github.io/rev_news/).

Git is a member project of software freedom conservancy, a non-profit
organization (https://sfconservancy.org/).  To reach a committee of
liaisons to the conservancy, contact them at <git@sfconservancy.org>.

For our expectations on the behaviour of the community participants
towards each other, see CODE_OF_CONDUCT.md at the top level of the source
tree, or:

    https://github.com/git/git/blob/master/CODE_OF_CONDUCT.md


* Reporting bugs

When you think git does not behave as you expect, please do not stop
your bug report with just "git does not work".  "I used git in this
way, but it did not work" is not much better, neither is "I used git
in this way, and X happend, which is broken".  It often is that git is
correct to cause X happen in such a case, and it is your expectation
that is broken. People would not know what other result Y you expected
to see instead of X, if you left it unsaid.

Please remember to always state

 - what you wanted to achieve;

 - what you did (the version of git and the command sequence to reproduce
   the behavior);

 - what you saw happen (X above);

 - what you expected to see (Y above); and

 - how the last two are different.

See http://www.chiark.greenend.org.uk/~sgtatham/bugs.html for further
hints.  Our `git bugreport` tool gives you a handy way you can use to
make sure you do not forget these points when filing a bug report.

If you think you found a security-sensitive issue and want to disclose
it to us without announcing it to wider public, please contact us at
our security mailing list <git-security@googlegroups.com>.  This is
a closed list that is limited to people who need to know early about
vulnerabilities, including:

  - people triaging and fixing reported vulnerabilities
  - people operating major git hosting sites with many users
  - people packaging and distributing git to large numbers of people

where these issues are discussed without risk of the information
leaking out before we're ready to make public announcements.


* Repositories and documentation.

My public git.git repositories are (mirrored) at:

  https://git.kernel.org/pub/scm/git/git.git/
  https://kernel.googlesource.com/pub/scm/git/git
  https://repo.or.cz/alt-git.git/
  https://github.com/git/git/
  https://gitlab.com/git-vcs/git/

This one shows not just the main integration branches, but also
individual topics broken out:

  https://github.com/gitster/git/

A few web interfaces are found at:

  http://git.kernel.org/pub/scm/git/git.git
  https://kernel.googlesource.com/pub/scm/git/git
  http://repo.or.cz/w/alt-git.git

Preformatted documentation from the tip of the "master" branch can be
found in:

  https://git.kernel.org/pub/scm/git/git-{htmldocs,manpages}.git/
  https://repo.or.cz/git-{htmldocs,manpages}.git/
  https://github.com/gitster/git-{htmldocs,manpages}.git/

The manual pages formatted in HTML for the tip of 'master' can be
viewed online at:

  https://git.github.io/htmldocs/git.html


* How various branches are used.

There are four branches in git.git repository that track the source tree
of git: "master", "maint", "next", and "seen".

The "master" branch is meant to contain what are very well tested and
ready to be used in a production setting.  Every now and then, a
"feature release" is cut from the tip of this branch.  They used to be
named with three dotted decimal digits (e.g. "1.8.5"), but we have
switched the versioning scheme and "feature releases" are named with
three-dotted decimal digits that ends with ".0" (e.g. "1.9.0").

The last such release was 2.30 done on Dec 28th, 2020.  You can expect
that the tip of the "master" branch is always more stable than any of
the released versions.

Whenever a feature release is made, "maint" branch is forked off from
"master" at that point.  Obvious and safe fixes after a feature
release are applied to this branch and maintenance releases are cut
from it.  Usually the fixes are merged to the "master" branch first,
several days before merged to the "maint" branch, to reduce the chance
of last-minute issues.  The maintenance releases used to be named with
four dotted decimal, named after the feature release they are updates
to (e.g. "1.8.5.1" was the first maintenance release for "1.8.5"
feature release).  These days, maintenance releases are named by
incrementing the last digit of three-dotted decimal name (e.g. "2.29.2"
was the second maintenance release for the "2.29" series).

New features never go to the 'maint' branch.  It is merged into "master"
primarily to propagate the description in the release notes forward.

A new development does not usually happen on "master". When you send a
series of patches, after review on the mailing list, a separate topic
branch is forked from the tip of "master" (or somewhere older, especially
when the topic is about fixing an earlier bug) and your patches are queued
there, and kept out of "master" while people test it out. The quality of
topic branches are judged primarily by the mailing list discussions.

Topic branches that are in good shape are merged to the "next" branch. In
general, the "next" branch always contains the tip of "master".  It might
not be quite rock-solid, but is expected to work more or less without major
breakage. The "next" branch is where new and exciting things take place. A
topic that is in "next" is expected to be polished to perfection before it
is merged to "master".  Please help this process by building & using the
"next" branch for your daily work, and reporting any new bugs you find to
the mailing list, before the breakage is merged down to the "master".

The "seen" (formerly "pu", proposed updates) branch bundles all the
remaining topic branches the maintainer happens to have seen.  There
is no guarantee that the maintainer has enough bandwidth to pick up any
and all topics that are remotely promising from the list traffic, so
please do not read too much into a topic being on (or not on) the "seen"
branch.  This branch is mainly to remind the maintainer that the topics
in them may turn out to be interesting when they are polished, nothing
more.  The topics on this branch aren't usually complete, well tested,
or well documented and they often need further work.  When a topic that
was in "seen" proves to be in a testable shape, it is merged to "next".

You can run "git log --first-parent master..seen" to see what topics are
currently in flight.  Sometimes, an idea that looked promising turns out
to be not so good and the topic can be dropped from "seen" in such a case.
The output of the above "git log" talks about a "jch" branch, which is an
early part of the "seen" branch; that branch contains all topics that
are in "next" and a bit more (but not all of "seen") and is used by the
maintainer for his daily work.

The two branches "master" and "maint" are never rewound, and "next"
usually will not be either.  After a feature release is made from
"master", however, "next" will be rebuilt from the tip of "master"
using the topics that didn't make the cut in the feature release.
Some topics that used to be in "next" during the previous cycle may
get ejected from "next" when this happens.

A natural consequence of how "next" and "seen" bundles topics together
is that until a topic is merged to "next", updates to it is expected
by replacing the patch(es) in the topic with an improved version,
and once a topic is merged to "next", updates to it needs to come as
incremental patches, pointing out what was wrong in the previous
patches and how the problem was corrected.

Note that being in "next" is not a guarantee to appear in the next
release, nor even in any future release.  There were cases that topics
needed reverting a few commits in them before graduating to "master",
or a topic that already was in "next" was reverted from "next" because
fatal flaws were found in it after it was merged to "next".


* Other people's trees.

Documentation/SubmittingPatches outlines to whom your proposed changes
should be sent.  As described in contrib/README, I would delegate fixes
and enhancements in contrib/ area to the primary contributors of them.

Although the following are included in git.git repository, they have their
own authoritative repository and maintainers:

 - git-gui/ comes from git-gui project, maintained by Pratyush Yadav:

        https://github.com/prati0100/git-gui.git

 - gitk-git/ comes from Paul Mackerras's gitk project:

        git://ozlabs.org/~paulus/gitk

 - po/ comes from the localization coordinator, Jiang Xin:

	https://github.com/git-l10n/git-po/

When sending proposed updates and fixes to these parts of the system,
please base your patches on these trees, not git.git (the former two
even have different directory structures).

A note from the maintainer

[Junio C Hamano]

Welcome to the Git development community.

This message is written by the maintainer and talks about how Git
project is managed, and how you can work with it.

The current maintainer is Junio C Hamano <gitster@pobox.com>; please
do not send any private message to this address, because it is likely
that such a message will not be seen by any human being.  Spam filters
learned that legitimate messages to the address come only from a very
few sender addresses that are known to be good, and messages from all
others are likely to be spam unless they are also sent to the mailing
list at the same time (i.e. "Reply-all" to the list message would
reach the mailbox, but "Reply" will likely be thrown into the spam
folder).


* Mailing list and the community

The development is primarily done on the Git mailing list. Help
requests, feature proposals, bug reports and patches should be sent to
the list address <git@vger.kernel.org>.  You don't have to be
subscribed to send messages.  The convention on the list is to keep
everybody involved on Cc:, so it is unnecessary to say "Please Cc: me,
I am not subscribed".

As an anti-spam measure, the mailing list software rejects messages
that are not text/plain and drops them on the floor.  If you are a
GMail user, you'd want to make sure "Plain text mode" is checked.

Before sending patches, please read Documentation/SubmittingPatches
and Documentation/CodingGuidelines to familiarize yourself with the
project convention.

If you sent a patch and you did not hear any response from anybody for
several days, it could be that your patch was totally uninteresting,
but it also is possible that it was simply lost in the noise.  Please
do not hesitate to send a reminder message in such a case.  Messages
getting lost in the noise may be a sign that those who can evaluate
your patch don't have enough mental/time bandwidth to process them
right at the moment, and it often helps to wait until the list traffic
becomes calmer before sending such a reminder.

The list archive is available at a few public sites:

        http://lore.kernel.org/git/
        http://marc.info/?l=git
        http://www.spinics.net/lists/git/

For those who prefer to read it over NNTP:

	nntp://nntp.lore.kernel.org/org.kernel.vger.git
        nntp://news.public-inbox.org/inbox.comp.version-control.git

are available.

When you point at a message in a mailing list archive, using its
message ID is often the most robust (if not very friendly) way to do
so, like this:

	http://lore.kernel.org/git/Pine.LNX.4.58.0504150753440.7211@ppc970.osdl.org

Often these web interfaces accept the message ID with enclosing <>
stripped (like the above example to point at one of the most important
message in the Git list).

Some members of the development community can sometimes be found on
the #git and #git-devel IRC channels on Freenode.  Their logs are
available at:

        http://colabti.org/irclogger/irclogger_log/git
        http://colabti.org/irclogger/irclogger_log/git-devel

There is a volunteer-run newsletter to serve our community ("Git Rev
News" http://git.github.io/rev_news/).

Git is a member project of software freedom conservancy, a non-profit
organization (https://sfconservancy.org/).  To reach a committee of
liaisons to the conservancy, contact them at <git@sfconservancy.org>.

For our expectations on the behaviour of the community participants
towards each other, see CODE_OF_CONDUCT.md at the top level of the source
tree, or:

    https://github.com/git/git/blob/master/CODE_OF_CONDUCT.md


* Reporting bugs

When you think git does not behave as you expect, please do not stop
your bug report with just "git does not work".  "I used git in this
way, but it did not work" is not much better, neither is "I used git
in this way, and X happend, which is broken".  It often is that git is
correct to cause X happen in such a case, and it is your expectation
that is broken. People would not know what other result Y you expected
to see instead of X, if you left it unsaid.

Please remember to always state

 - what you wanted to achieve;

 - what you did (the version of git and the command sequence to reproduce
   the behavior);

 - what you saw happen (X above);

 - what you expected to see (Y above); and

 - how the last two are different.

See http://www.chiark.greenend.org.uk/~sgtatham/bugs.html for further
hints.  Our `git bugreport` tool gives you a handy way you can use to
make sure you do not forget these points when filing a bug report.

If you think you found a security-sensitive issue and want to disclose
it to us without announcing it to wider public, please contact us at
our security mailing list <git-security@googlegroups.com>.  This is
a closed list that is limited to people who need to know early about
vulnerabilities, including:

  - people triaging and fixing reported vulnerabilities
  - people operating major git hosting sites with many users
  - people packaging and distributing git to large numbers of people

where these issues are discussed without risk of the information
leaking out before we're ready to make public announcements.


* Repositories and documentation.

My public git.git repositories are (mirrored) at:

  git://git.kernel.org/pub/scm/git/git.git/
  https://kernel.googlesource.com/pub/scm/git/git
  git://repo.or.cz/alt-git.git/
  https://github.com/git/git/

This one shows not just the main integration branches, but also
individual topics broken out:

  git://github.com/gitster/git/

A few web interfaces are found at:

  http://git.kernel.org/pub/scm/git/git.git
  https://kernel.googlesource.com/pub/scm/git/git
  http://repo.or.cz/w/alt-git.git

Preformatted documentation from the tip of the "master" branch can be
found in:

  git://git.kernel.org/pub/scm/git/git-{htmldocs,manpages}.git/
  git://repo.or.cz/git-{htmldocs,manpages}.git/
  https://github.com/gitster/git-{htmldocs,manpages}.git/

The manual pages formatted in HTML for the tip of 'master' can be
viewed online at:

  https://git.github.io/htmldocs/git.html


* How various branches are used.

There are four branches in git.git repository that track the source tree
of git: "master", "maint", "next", and "seen".

The "master" branch is meant to contain what are very well tested and
ready to be used in a production setting.  Every now and then, a
"feature release" is cut from the tip of this branch.  They used to be
named with three dotted decimal digits (e.g. "1.8.5"), but we have
switched the versioning scheme and "feature releases" are named with
three-dotted decimal digits that ends with ".0" (e.g. "1.9.0").

The last such release was 2.29 done on Oct 19th, 2020.  You can expect
that the tip of the "master" branch is always more stable than any of
the released versions.

Whenever a feature release is made, "maint" branch is forked off from
"master" at that point.  Obvious and safe fixes after a feature
release are applied to this branch and maintenance releases are cut
from it.  Usually the fixes are merged to the "master" branch first,
several days before merged to the "maint" branch, to reduce the chance
of last-minute issues.  The maintenance releases used to be named with
four dotted decimal, named after the feature release they are updates
to (e.g. "1.8.5.1" was the first maintenance release for "1.8.5"
feature release).  These days, maintenance releases are named by
incrementing the last digit of three-dotted decimal name (e.g. "2.29.2"
was the second maintenance release for the "2.29" series).

New features never go to the 'maint' branch.  It is merged into "master"
primarily to propagate the description in the release notes forward.

A new development does not usually happen on "master". When you send a
series of patches, after review on the mailing list, a separate topic
branch is forked from the tip of "master" (or somewhere older, especially
when the topic is about fixing an earlier bug) and your patches are queued
there, and kept out of "master" while people test it out. The quality of
topic branches are judged primarily by the mailing list discussions.

Topic branches that are in good shape are merged to the "next" branch. In
general, the "next" branch always contains the tip of "master".  It might
not be quite rock-solid, but is expected to work more or less without major
breakage. The "next" branch is where new and exciting things take place. A
topic that is in "next" is expected to be polished to perfection before it
is merged to "master".  Please help this process by building & using the
"next" branch for your daily work, and reporting any new bugs you find to
the mailing list, before the breakage is merged down to the "master".

The "seen" (formerly "pu", proposed updates) branch bundles all the
remaining topic branches the maintainer happens to have seen.  There
is no guarantee that the maintainer has enough bandwidth to pick up any
and all topics that are remotely promising from the list traffic, so
please do not read too much into a topic being on (or not on) the "seen"
branch.  This branch is mainly to remind the maintainer that the topics
in them may turn out to be interesting when they are polished, nothing
more.  The topics on this branch aren't usually complete, well tested,
or well documented and they often need further work.  When a topic that
was in "seen" proves to be in a testable shape, it is merged to "next".

You can run "git log --first-parent master..seen" to see what topics are
currently in flight.  Sometimes, an idea that looked promising turns out
to be not so good and the topic can be dropped from "seen" in such a case.
The output of the above "git log" talks about a "jch" branch, which is an
early part of the "seen" branch; that branch contains all topics that
are in "next" and a bit more (but not all of "seen") and is used by the
maintainer for his daily work.

The two branches "master" and "maint" are never rewound, and "next"
usually will not be either.  After a feature release is made from
"master", however, "next" will be rebuilt from the tip of "master"
using the topics that didn't make the cut in the feature release.
Some topics that used to be in "next" during the previous cycle may
get ejected from "next" when this happens.

A natural consequence of how "next" and "seen" bundles topics together
is that until a topic is merged to "next", updates to it is expected
by replacing the patch(es) in the topic with an improved version,
and once a topic is merged to "next", updates to it needs to come as
incremental patches, pointing out what was wrong in the previous
patches and how the problem was corrected.

Note that being in "next" is not a guarantee to appear in the next
release, nor even in any future release.  There were cases that topics
needed reverting a few commits in them before graduating to "master",
or a topic that already was in "next" was reverted from "next" because
fatal flaws were found in it after it was merged to "next".


* Other people's trees.

Documentation/SubmittingPatches outlines to whom your proposed changes
should be sent.  As described in contrib/README, I would delegate fixes
and enhancements in contrib/ area to the primary contributors of them.

Although the following are included in git.git repository, they have their
own authoritative repository and maintainers:

 - git-gui/ comes from git-gui project, maintained by Pratyush Yadav:

        https://github.com/prati0100/git-gui.git

 - gitk-git/ comes from Paul Mackerras's gitk project:

        git://ozlabs.org/~paulus/gitk

 - po/ comes from the localization coordinator, Jiang Xin:

	https://github.com/git-l10n/git-po/

When sending proposed updates and fixes to these parts of the system,
please base your patches on these trees, not git.git (the former two
even have different directory structures).

A note from the maintainer

[Junio C Hamano]

[Administrivia]
    As I sent the latest issue of the "What's cooking" report
    yesterday, and there is no change other than the "v0
    repositories take any extensions known to us for now" regression
    fixes in today's rc1, I am not sending a new "What's cooking"
    out, even though we tagged 2.28.0-rc1 today.  Instead, I'll send
    this one out, as it has been a while...


Welcome to the Git development community.

This message is written by the maintainer and talks about how Git
project is managed, and how you can work with it.

The current maintainer is Junio C Hamano <gitster@pobox.com>; please
do not send any private message to this address, because it is likely
that such a message will not be seen by any human being.  Spam filters
learned that legitimate messages to the address come only from a very
few sender addresses that are known to be good, and messages from all
others are likely to be spam unless they are also sent to the mailing
list at the same time (i.e. "Reply-all" to the list message would
reach the mailbox, but "Reply" will likely be thrown into the spam
folder).


* Mailing list and the community

The development is primarily done on the Git mailing list. Help
requests, feature proposals, bug reports and patches should be sent to
the list address <git@vger.kernel.org>.  You don't have to be
subscribed to send messages.  The convention on the list is to keep
everybody involved on Cc:, so it is unnecessary to say "Please Cc: me,
I am not subscribed".

As an anti-spam measure, the mailing list software rejects messages
that are not text/plain and drops them on the floor.  If you are a
GMail user, you'd want to make sure "Plain text mode" is checked.

Before sending patches, please read Documentation/SubmittingPatches
and Documentation/CodingGuidelines to familiarize yourself with the
project convention.

If you sent a patch and you did not hear any response from anybody for
several days, it could be that your patch was totally uninteresting,
but it also is possible that it was simply lost in the noise.  Please
do not hesitate to send a reminder message in such a case.  Messages
getting lost in the noise may be a sign that those who can evaluate
your patch don't have enough mental/time bandwidth to process them
right at the moment, and it often helps to wait until the list traffic
becomes calmer before sending such a reminder.

The list archive is available at a few public sites:

        http://lore.kernel.org/git/
        http://marc.info/?l=git
        http://www.spinics.net/lists/git/

For those who prefer to read it over NNTP:

	nntp://nntp.lore.kernel.org/org.kernel.vger.git
        nntp://news.public-inbox.org/inbox.comp.version-control.git

are available.

When you point at a message in a mailing list archive, using its
message ID is often the most robust (if not very friendly) way to do
so, like this:

	http://lore.kernel.org/git/Pine.LNX.4.58.0504150753440.7211@ppc970.osdl.org

Often these web interfaces accept the message ID with enclosing <>
stripped (like the above example to point at one of the most important
message in the Git list).

Some members of the development community can sometimes be found on
the #git and #git-devel IRC channels on Freenode.  Their logs are
available at:

        http://colabti.org/irclogger/irclogger_log/git
        http://colabti.org/irclogger/irclogger_log/git-devel

There is a volunteer-run newsletter to serve our community ("Git Rev
News" http://git.github.io/rev_news/).

Git is a member project of software freedom conservancy, a non-profit
organization (https://sfconservancy.org/).  To reach a committee of
liaisons to the conservancy, contact them at <git@sfconservancy.org>.

For our expectations on the behaviour of the community participants
towards each other, see CODE_OF_CONDUCT.md at the top level of the source
tree, or:

    https://github.com/git/git/blob/master/CODE_OF_CONDUCT.md


* Reporting bugs

When you think git does not behave as you expect, please do not stop
your bug report with just "git does not work".  "I used git in this
way, but it did not work" is not much better, neither is "I used git
in this way, and X happend, which is broken".  It often is that git is
correct to cause X happen in such a case, and it is your expectation
that is broken. People would not know what other result Y you expected
to see instead of X, if you left it unsaid.

Please remember to always state

 - what you wanted to achieve;

 - what you did (the version of git and the command sequence to reproduce
   the behavior);

 - what you saw happen (X above);

 - what you expected to see (Y above); and

 - how the last two are different.

See http://www.chiark.greenend.org.uk/~sgtatham/bugs.html for further
hints.

If you think you found a security-sensitive issue and want to disclose
it to us without announcing it to wider public, please contact us at
our security mailing list <git-security@googlegroups.com>.  This is
a closed list that is limited to people who need to know early about
vulnerabilities, including:

  - people triaging and fixing reported vulnerabilities
  - people operating major git hosting sites with many users
  - people packaging and distributing git to large numbers of people

where these issues are discussed without risk of the information
leaking out before we're ready to make public announcements.


* Repositories and documentation.

My public git.git repositories are (mirrored) at:

  git://git.kernel.org/pub/scm/git/git.git/
  https://kernel.googlesource.com/pub/scm/git/git
  git://repo.or.cz/alt-git.git/
  https://github.com/git/git/

This one shows not just the main integration branches, but also
individual topics broken out:

  git://github.com/gitster/git/

A few web interfaces are found at:

  http://git.kernel.org/pub/scm/git/git.git
  https://kernel.googlesource.com/pub/scm/git/git
  http://repo.or.cz/w/alt-git.git

Preformatted documentation from the tip of the "master" branch can be
found in:

  git://git.kernel.org/pub/scm/git/git-{htmldocs,manpages}.git/
  git://repo.or.cz/git-{htmldocs,manpages}.git/
  https://github.com/gitster/git-{htmldocs,manpages}.git/

The manual pages formatted in HTML for the tip of 'master' can be
viewed online at:

  https://git.github.io/htmldocs/git.html


* How various branches are used.

There are four branches in git.git repository that track the source tree
of git: "master", "maint", "next", and "seen".

The "master" branch is meant to contain what are very well tested and
ready to be used in a production setting.  Every now and then, a
"feature release" is cut from the tip of this branch.  They used to be
named with three dotted decimal digits (e.g. "1.8.5"), but we have
switched the versioning scheme and "feature releases" are named with
three-dotted decimal digits that ends with ".0" (e.g. "1.9.0").

The last such release was 2.27 done on Jun 1st, 2020.  You can expect
that the tip of the "master" branch is always more stable than any of
the released versions.

Whenever a feature release is made, "maint" branch is forked off from
"master" at that point.  Obvious and safe fixes after a feature
release are applied to this branch and maintenance releases are cut
from it.  Usually the fixes are merged to the "master" branch first,
several days before merged to the "maint" branch, to reduce the chance
of last-minute issues.  The maintenance releases used to be named with
four dotted decimal, named after the feature release they are updates
to (e.g. "1.8.5.1" was the first maintenance release for "1.8.5"
feature release).  These days, maintenance releases are named by
incrementing the last digit of three-dotted decimal name (e.g. "2.26.1"
was the first maintenance release for the "2.26" series).

New features never go to the 'maint' branch.  It is merged into "master"
primarily to propagate the description in the release notes forward.

A new development does not usually happen on "master". When you send a
series of patches, after review on the mailing list, a separate topic
branch is forked from the tip of "master" (or somewhere older, especially
when the topic is about fixing an earlier bug) and your patches are queued
there, and kept out of "master" while people test it out. The quality of
topic branches are judged primarily by the mailing list discussions.

Topic branches that are in good shape are merged to the "next" branch. In
general, the "next" branch always contains the tip of "master".  It might
not be quite rock-solid, but is expected to work more or less without major
breakage. The "next" branch is where new and exciting things take place. A
topic that is in "next" is expected to be polished to perfection before it
is merged to "master".  Please help this process by building & using the
"next" branch for your daily work, and reporting any new bugs you find to
the mailing list, before the breakage is merged down to the "master".

The "seen" (formerly "pu", proposed updates) branch bundles all the
remaining topic branches the maintainer happens to have seen.  There
is no guarantee that the maintainer has enough bandwidth to pick up any
and all topics that are remotely promising from the list traffic, so
please do not read too much into a topic being on (or not on) the "seen"
branch.  This branch is mainly to remind the maintainer that the topics
in them may turn out to be interesting when they are polished, nothing
more.  The topics on this branch aren't usually complete, well tested,
or well documented and they often need further work.  When a topic that
was in "seen" proves to be in a testable shape, it is merged to "next".

You can run "git log --first-parent master..seen" to see what topics are
currently in flight.  Sometimes, an idea that looked promising turns out
to be not so good and the topic can be dropped from "seen" in such a case.
The output of the above "git log" talks about a "jch" branch, which is an
early part of the "seen" branch; that branch contains all topics that
are in "next" and a bit more (but not all of "seen") and is used by the
maintainer for his daily work.

The two branches "master" and "maint" are never rewound, and "next"
usually will not be either.  After a feature release is made from
"master", however, "next" will be rebuilt from the tip of "master"
using the topics that didn't make the cut in the feature release.
Some topics that used to be in "next" during the previous cycle may
get ejected from "next" when this happens.

A natural consequence of how "next" and "seen" bundles topics together
is that until a topic is merged to "next", updates to it is expected
by replacing the patch(es) in the topic with an improved version,
and once a topic is merged to "next", updates to it needs to come as
incremental patches, pointing out what was wrong in the previous
patches and how the problem was corrected.

Note that being in "next" is not a guarantee to appear in the next
release, nor even in any future release.  There were cases that topics
needed reverting a few commits in them before graduating to "master",
or a topic that already was in "next" was reverted from "next" because
fatal flaws were found in it after it was merged to "next".


* Other people's trees.

Documentation/SubmittingPatches outlines to whom your proposed changes
should be sent.  As described in contrib/README, I would delegate fixes
and enhancements in contrib/ area to the primary contributors of them.

Although the following are included in git.git repository, they have their
own authoritative repository and maintainers:

 - git-gui/ comes from git-gui project, maintained by Pratyush Yadav:

        https://github.com/prati0100/git-gui.git

 - gitk-git/ comes from Paul Mackerras's gitk project:

        git://ozlabs.org/~paulus/gitk

 - po/ comes from the localization coordinator, Jiang Xin:

	https://github.com/git-l10n/git-po/

When sending proposed updates and fixes to these parts of the system,
please base your patches on these trees, not git.git (the former two
even have different directory structures).

A note from the maintainer

[Junio C Hamano]

Welcome to the Git development community.

This message is written by the maintainer and talks about how Git
project is managed, and how you can work with it.

* Mailing list and the community

The development is primarily done on the Git mailing list. Help
requests, feature proposals, bug reports and patches should be sent to
the list address <git@vger.kernel.org>.  You don't have to be
subscribed to send messages.  The convention on the list is to keep
everybody involved on Cc:, so it is unnecessary to say "Please Cc: me,
I am not subscribed".

As an anti-spam measure, the mailing list software rejects messages
that are not text/plain and drops them on the floor.  If you are a
GMail user, you'd want to make sure "Plain text mode" is checked.

Before sending patches, please read Documentation/SubmittingPatches
and Documentation/CodingGuidelines to familiarize yourself with the
project convention.

If you sent a patch and you did not hear any response from anybody for
several days, it could be that your patch was totally uninteresting,
but it also is possible that it was simply lost in the noise.  Please
do not hesitate to send a reminder message in such a case.  Messages
getting lost in the noise may be a sign that those who can evaluate
your patch don't have enough mental/time bandwidth to process them
right at the moment, and it often helps to wait until the list traffic
becomes calmer before sending such a reminder.

The list archive is available at a few public sites:

        http://lore.kernel.org/git/
        http://marc.info/?l=git
        http://www.spinics.net/lists/git/

For those who prefer to read it over NNTP:

	nntp://nntp.lore.kernel.org/org.kernel.vger.git
        nntp://news.public-inbox.org/inbox.comp.version-control.git

are available.

When you point at a message in a mailing list archive, using its
message ID is often the most robust (if not very friendly) way to do
so, like this:

	http://lore.kernel.org/git/Pine.LNX.4.58.0504150753440.7211@ppc970.osdl.org

Often these web interfaces accept the message ID with enclosing <>
stripped (like the above example to point at one of the most important
message in the Git list).

Some members of the development community can sometimes be found on
the #git and #git-devel IRC channels on Freenode.  Their logs are
available at:

        http://colabti.org/irclogger/irclogger_log/git
        http://colabti.org/irclogger/irclogger_log/git-devel

There is a volunteer-run newsletter to serve our community ("Git Rev
News" http://git.github.io/rev_news/rev_news.html).

Git is a member project of software freedom conservancy, a non-profit
organization (https://sfconservancy.org/).  To reach a committee of
liaisons to the conservancy, contact them at <git@sfconservancy.org>.

For our expectations on the behaviour of the community participants
towards each other, see CODE_OF_CONDUCT.md at the top level of the source
tree, or:

    https://github.com/git/git/blob/master/CODE_OF_CONDUCT.md


* Reporting bugs

When you think git does not behave as you expect, please do not stop
your bug report with just "git does not work".  "I used git in this
way, but it did not work" is not much better, neither is "I used git
in this way, and X happend, which is broken".  It often is that git is
correct to cause X happen in such a case, and it is your expectation
that is broken. People would not know what other result Y you expected
to see instead of X, if you left it unsaid.

Please remember to always state

 - what you wanted to achieve;

 - what you did (the version of git and the command sequence to reproduce
   the behavior);

 - what you saw happen (X above);

 - what you expected to see (Y above); and

 - how the last two are different.

See http://www.chiark.greenend.org.uk/~sgtatham/bugs.html for further
hints.

If you think you found a security-sensitive issue and want to disclose
it to us without announcing it to wider public, please contact us at
our security mailing list <git-security@googlegroups.com>.  This is
a closed list that is limited to people who need to know early about
vulnerabilities, including:

  - people triaging and fixing reported vulnerabilities
  - people operating major git hosting sites with many users
  - people packaging and distributing git to large numbers of people

where these issues are discussed without risk of the information
leaking out before we're ready to make public announcements.


* Repositories and documentation.

My public git.git repositories are (mirrored) at:

  git://git.kernel.org/pub/scm/git/git.git/
  https://kernel.googlesource.com/pub/scm/git/git
  git://repo.or.cz/alt-git.git/
  https://github.com/git/git/

This one shows not just the main integration branches, but also
individual topics broken out:

  git://github.com/gitster/git/

A few web interfaces are found at:

  http://git.kernel.org/pub/scm/git/git.git
  https://kernel.googlesource.com/pub/scm/git/git
  http://repo.or.cz/w/alt-git.git

Preformatted documentation from the tip of the "master" branch can be
found in:

  git://git.kernel.org/pub/scm/git/git-{htmldocs,manpages}.git/
  git://repo.or.cz/git-{htmldocs,manpages}.git/
  https://github.com/gitster/git-{htmldocs,manpages}.git/

The manual pages formatted in HTML for the tip of 'master' can be
viewed online at:

  https://git.github.io/htmldocs/git.html


* How various branches are used.

There are four branches in git.git repository that track the source tree
of git: "master", "maint", "next", and "pu".

The "master" branch is meant to contain what are very well tested and
ready to be used in a production setting.  Every now and then, a
"feature release" is cut from the tip of this branch.  They used to be
named with three dotted decimal digits (e.g. "1.8.5"), but we have
switched the versioning scheme and "feature releases" are named with
three-dotted decimal digits that ends with ".0" (e.g. "1.9.0").

The last such release was 2.27 done on Jun 1st, 2020.  You can expect
that the tip of the "master" branch is always more stable than any of
the released versions.

Whenever a feature release is made, "maint" branch is forked off from
"master" at that point.  Obvious and safe fixes after a feature
release are applied to this branch and maintenance releases are cut
from it.  Usually the fixes are merged to the "master" branch first,
several days before merged to the "maint" branch, to reduce the chance
of last-minute issues.  The maintenance releases used to be named with
four dotted decimal, named after the feature release they are updates
to (e.g. "1.8.5.1" was the first maintenance release for "1.8.5"
feature release).  These days, maintenance releases are named by
incrementing the last digit of three-dotted decimal name (e.g. "2.26.1"
was the first maintenance release for the "2.26" series).

New features never go to the 'maint' branch.  It is merged into "master"
primarily to propagate the description in the release notes forward.

A new development does not usually happen on "master". When you send a
series of patches, after review on the mailing list, a separate topic
branch is forked from the tip of "master" (or somewhere older, especially
when the topic is about fixing an earlier bug) and your patches are queued
there, and kept out of "master" while people test it out. The quality of
topic branches are judged primarily by the mailing list discussions.

Topic branches that are in good shape are merged to the "next" branch. In
general, the "next" branch always contains the tip of "master".  It might
not be quite rock-solid, but is expected to work more or less without major
breakage. The "next" branch is where new and exciting things take place. A
topic that is in "next" is expected to be polished to perfection before it
is merged to "master".  Please help this process by building & using the
"next" branch for your daily work, and reporting any new bugs you find to
the mailing list, before the breakage is merged down to the "master".

The "pu" (proposed updates) branch bundles all the remaining topic
branches the maintainer happens to have seen.  There is no guarantee that
the maintainer has enough bandwidth to pick up any and all topics that
are remotely promising from the list traffic, so please do not read
too much into a topic being on (or not on) the "pu" branch.  This
branch is mainly to remind the maintainer that the topics in them may
turn out to be interesting when they are polished, nothing more.  The
topics on this branch aren't usually complete, well tested, or well
documented and they often need further work.  When a topic that was
in "pu" proves to be in a testable shape, it is merged to "next".

You can run "git log --first-parent master..pu" to see what topics are
currently in flight.  Sometimes, an idea that looked promising turns out
to be not so good and the topic can be dropped from "pu" in such a case.
The output of the above "git log" talks about a "jch" branch, which is an
early part of the "pu" branch; that branch contains all topics that
are in "next" and a bit more (but not all of "pu") and is used by the
maintainer for his daily work.

The two branches "master" and "maint" are never rewound, and "next"
usually will not be either.  After a feature release is made from
"master", however, "next" will be rebuilt from the tip of "master"
using the topics that didn't make the cut in the feature release.
Some topics that used to be in "next" during the previous cycle may
get ejected from "next" when this happens.

A natural consequence of how "next" and "pu" bundles topics together
is that until a topic is merged to "next", updates to it is expected
by replacing the patch(es) in the topic with an improved version,
and once a topic is merged to "next", updates to it needs to come as
incremental patches, pointing out what was wrong in the previous
patches and how the problem was corrected.

Note that being in "next" is not a guarantee to appear in the next
release, nor even in any future release.  There were cases that topics
needed reverting a few commits in them before graduating to "master",
or a topic that already was in "next" was reverted from "next" because
fatal flaws were found in it after it was merged to "next".


* Other people's trees.

Documentation/SubmittingPatches outlines to whom your proposed changes
should be sent.  As described in contrib/README, I would delegate fixes
and enhancements in contrib/ area to the primary contributors of them.

Although the following are included in git.git repository, they have their
own authoritative repository and maintainers:

 - git-gui/ comes from git-gui project, maintained by Pratyush Yadav:

        https://github.com/prati0100/git-gui.git

 - gitk-git/ comes from Paul Mackerras's gitk project:

        git://ozlabs.org/~paulus/gitk

 - po/ comes from the localization coordinator, Jiang Xin:

	https://github.com/git-l10n/git-po/

When sending proposed updates and fixes to these parts of the system,
please base your patches on these trees, not git.git (the former two
even have different directory structures).

Re: A note from the maintainer

[Kaartic Sivaraam]

Hi Junio,

On 01-06-2020 22:03, Junio C Hamano wrote:
> 
> There is a volunteer-run newsletter to serve our community ("Git Rev
> News" http://git.github.io/rev_news/rev_news.html).
>

It seems the Rev News page has moved to:

    https://git.github.io/rev_news/index.html

The following works too:

    https://git.github.io/rev_news

> 
> * Reporting bugs
> 
> When you think git does not behave as you expect, please do not stop
> your bug report with just "git does not work".  "I used git in this
> way, but it did not work" is not much better, neither is "I used git
> in this way, and X happend, which is broken".  It often is that git is
> correct to cause X happen in such a case, and it is your expectation
> that is broken. People would not know what other result Y you expected
> to see instead of X, if you left it unsaid.
> 
> Please remember to always state
> 
>  - what you wanted to achieve;
> 
>  - what you did (the version of git and the command sequence to reproduce
>    the behavior);
> 
>  - what you saw happen (X above);
> 
>  - what you expected to see (Y above); and
> 
>  - how the last two are different.
> 
> See http://www.chiark.greenend.org.uk/~sgtatham/bugs.html for further
> hints.
> 

I wonder if it might be worth mentioning `git bugreport` somewhere here.

> When sending proposed updates and fixes to these parts of the system,
> please base your patches on these trees, not git.git (the former two
> even have different directory structures).
> 

Thanks for routinely sending these informative notes! :)

-- 
Sivaraam

Re: A note from the maintainer

[Junio C Hamano]

Kaartic Sivaraam <kaartic.sivaraam@gmail.com> writes:

> On 01-06-2020 22:03, Junio C Hamano wrote:
>> 
>> There is a volunteer-run newsletter to serve our community ("Git Rev
>> News" http://git.github.io/rev_news/rev_news.html).
>>
>
> It seems the Rev News page has moved to:
>
>     https://git.github.io/rev_news/index.html
>
> The following works too:
>
>     https://git.github.io/rev_news

Thanks.  I am on "vacation", so will address this later in the week.

A note from the maintainer

[Junio C Hamano]

[jc: as I said earlier, I'll be offline for a week, but remembered
that I haven't sent this out for a while---I tried to make a habit
of sending this message out after every feature release, and we had
one recently, so it is a good time to send one from the airport
lounge before I fly out.]

Welcome to the Git development community.

This message is written by the maintainer and talks about how Git
project is managed, and how you can work with it.

* Mailing list and the community

The development is primarily done on the Git mailing list. Help
requests, feature proposals, bug reports and patches should be sent to
the list address <git@vger.kernel.org>.  You don't have to be
subscribed to send messages.  The convention on the list is to keep
everybody involved on Cc:, so it is unnecessary to say "Please Cc: me,
I am not subscribed".

As an anti-spam measure, the mailing list software rejects messages
that are not text/plain and drops them on the floor.  If you are a
GMail user, you'd want to make sure "Plain text mode" is checked.

Before sending patches, please read Documentation/SubmittingPatches
and Documentation/CodingGuidelines to familiarize yourself with the
project convention.

If you sent a patch and you did not hear any response from anybody for
several days, it could be that your patch was totally uninteresting,
but it also is possible that it was simply lost in the noise.  Please
do not hesitate to send a reminder message in such a case.  Messages
getting lost in the noise may be a sign that those who can evaluate
your patch don't have enough mental/time bandwidth to process them
right at the moment, and it often helps to wait until the list traffic
becomes calmer before sending such a reminder.

The list archive is available at a few public sites:

        http://public-inbox.org/git/
        http://marc.info/?l=git
        http://www.spinics.net/lists/git/

For those who prefer to read it over NNTP:

        nntp://news.public-inbox.org/inbox.comp.version-control.git
	nntp://news.gmane.org/gmane.comp.version-control.git

are available.

When you point at a message in a mailing list archive, using its
message ID is often the most robust (if not very friendly) way to do
so, like this:

	http://public-inbox.org/git/Pine.LNX.4.58.0504150753440.7211@ppc970.osdl.org

Often these web interfaces accept the message ID with enclosing <>
stripped (like the above example to point at one of the most important
message in the Git list).

Some members of the development community can sometimes be found on
the #git and #git-devel IRC channels on Freenode.  Their logs are
available at:

        http://colabti.org/irclogger/irclogger_log/git
        http://colabti.org/irclogger/irclogger_log/git-devel

There is a volunteer-run newsletter to serve our community ("Git Rev
News" http://git.github.io/rev_news/rev_news.html).

Git is a member project of software freedom conservancy, a non-profit
organization (https://sfconservancy.org/).  To reach a committee of
liaisons to the conservancy, contact them at <git@sfconservancy.org>.


* Reporting bugs

When you think git does not behave as you expect, please do not stop
your bug report with just "git does not work".  "I used git in this
way, but it did not work" is not much better, neither is "I used git
in this way, and X happend, which is broken".  It often is that git is
correct to cause X happen in such a case, and it is your expectation
that is broken. People would not know what other result Y you expected
to see instead of X, if you left it unsaid.

Please remember to always state

 - what you wanted to achieve;

 - what you did (the version of git and the command sequence to reproduce
   the behavior);

 - what you saw happen (X above);

 - what you expected to see (Y above); and

 - how the last two are different.

See http://www.chiark.greenend.org.uk/~sgtatham/bugs.html for further
hints.

If you think you found a security-sensitive issue and want to disclose
it to us without announcing it to wider public, please contact us at
our security mailing list <git-security@googlegroups.com>.  This is
a closed list that is limited to people who need to know early about
vulnerabilities, including:

  - people triaging and fixing reported vulnerabilities
  - people operating major git hosting sites with many users
  - people packaging and distributing git to large numbers of people

where these issues are discussed without risk of the information
leaking out before we're ready to make public announcements.


* Repositories and documentation.

My public git.git repositories are (mirrored) at:

  git://git.kernel.org/pub/scm/git/git.git/
  https://kernel.googlesource.com/pub/scm/git/git
  git://repo.or.cz/alt-git.git/
  https://github.com/git/git/
  git://git-core.git.sourceforge.net/gitroot/git-core/git-core/

This one shows not just the main integration branches, but also
individual topics broken out:

  git://github.com/gitster/git/

A few web interfaces are found at:

  http://git.kernel.org/cgit/git/git.git
  https://kernel.googlesource.com/pub/scm/git/git
  http://repo.or.cz/w/alt-git.git

Preformatted documentation from the tip of the "master" branch can be
found in:

  git://git.kernel.org/pub/scm/git/git-{htmldocs,manpages}.git/
  git://repo.or.cz/git-{htmldocs,manpages}.git/
  https://github.com/gitster/git-{htmldocs,manpages}.git/

The manual pages formatted in HTML for the tip of 'master' can be
viewed online at:

  https://git.github.io/htmldocs/git.html


* How various branches are used.

There are four branches in git.git repository that track the source tree
of git: "master", "maint", "next", and "pu".

The "master" branch is meant to contain what are very well tested and
ready to be used in a production setting.  Every now and then, a
"feature release" is cut from the tip of this branch.  They used to be
named with three dotted decimal digits (e.g. "1.8.5"), but recently we
switched the versioning scheme and "feature releases" are named with
three-dotted decimal digits that ends with ".0" (e.g. "1.9.0").

The last such release was 2.15 done on Oct 30th, 2017.  You can expect
that the tip of the "master" branch is always more stable than any of
the released versions.

Whenever a feature release is made, "maint" branch is forked off from
"master" at that point.  Obvious and safe fixes after a feature
release are applied to this branch and maintenance releases are cut
from it.  Usually the fixes are merged to the "master" branch first,
several days before merged to the "maint" branch, to reduce the chance
of last-minute issues.  The maintenance releases used to be named with
four dotted decimal, named after the feature release they are updates
to (e.g. "1.8.5.1" was the first maintenance release for "1.8.5"
feature release).  These days, maintenance releases are named by
incrementing the last digit of three-dotted decimal name (e.g. "2.12.1"
was the first maintenance release for the "2.12" series).

New features never go to the 'maint' branch.  It is merged into "master"
primarily to propagate the description in the release notes forward.

A new development does not usually happen on "master". When you send a
series of patches, after review on the mailing list, a separate topic
branch is forked from the tip of "master" (or somewhere older, especially
when the topic is about fixing an earlier bug) and your patches are queued
there, and kept out of "master" while people test it out. The quality of
topic branches are judged primarily by the mailing list discussions.

Topic branches that are in good shape are merged to the "next" branch. In
general, the "next" branch always contains the tip of "master".  It might
not be quite rock-solid, but is expected to work more or less without major
breakage. The "next" branch is where new and exciting things take place. A
topic that is in "next" is expected to be polished to perfection before it
is merged to "master".  Please help this process by building & using the
"next" branch for your daily work, and reporting any new bugs you find to
the mailing list, before the breakage is merged down to the "master".

The "pu" (proposed updates) branch bundles all the remaining topic
branches the maintainer happens to have seen.  There is no guarantee that
the maintainer has enough bandwidth to pick up any and all topics that
are remotely promising from the list traffic, so please do not read
too much into a topic being on (or not on) the "pu" branch.  This
branch is mainly to remind the maintainer that the topics in them may
turn out to be interesting when they are polished, nothing more.  The
topics on this branch aren't usually complete, well tested, or well
documented and they often need further work.  When a topic that was
in "pu" proves to be in a testable shape, it is merged to "next".

You can run "git log --first-parent master..pu" to see what topics are
currently in flight.  Sometimes, an idea that looked promising turns out
to be not so good and the topic can be dropped from "pu" in such a case.
The output of the above "git log" talks about a "jch" branch, which is an
early part of the "pu" branch; that branch contains all topics that
are in "next" and a bit more (but not all of "pu") and is used by the
maintainer for his daily work.

The two branches "master" and "maint" are never rewound, and "next"
usually will not be either.  After a feature release is made from
"master", however, "next" will be rebuilt from the tip of "master"
using the topics that didn't make the cut in the feature release.

A natural consequence of how "next" and "pu" bundles topics together
is that until a topic is merged to "next", updates to it is expected
by replacing the patch(es) in the topic with an improved version,
and once a topic is merged to "next", updates to it needs to come as
incremental patches, pointing out what was wrong in the previous
patches and how the problem was corrected.

Note that being in "next" is not a guarantee to appear in the next
release, nor even in any future release.  There were cases that topics
needed reverting a few commits in them before graduating to "master",
or a topic that already was in "next" was reverted from "next" because
fatal flaws were found in it after it was merged to "next".


* Other people's trees.

Documentation/SubmittingPatches outlines to whom your proposed changes
should be sent.  As described in contrib/README, I would delegate fixes
and enhancements in contrib/ area to the primary contributors of them.

Although the following are included in git.git repository, they have their
own authoritative repository and maintainers:

 - git-gui/ comes from git-gui project, maintained by Pat Thoyts:

        git://repo.or.cz/git-gui.git

 - gitk-git/ comes from Paul Mackerras's gitk project:

        git://ozlabs.org/~paulus/gitk

 - po/ comes from the localization coordinator, Jiang Xin:

	https://github.com/git-l10n/git-po/

When sending proposed updates and fixes to these parts of the system,
please base your patches on these trees, not git.git (the former two
even have different directory structures).

A note from the maintainer

[Junio C Hamano]

Welcome to the Git development community.

This message is written by the maintainer and talks about how Git
project is managed, and how you can work with it.

* Mailing list and the community

The development is primarily done on the Git mailing list. Help
requests, feature proposals, bug reports and patches should be sent to
the list address <git@vger.kernel.org>.  You don't have to be
subscribed to send messages.  The convention on the list is to keep
everybody involved on Cc:, so it is unnecessary to say "Please Cc: me,
I am not subscribed".

As an anti-spam measure, the mailing list software rejects messages
that are not text/plain and drops them on the floor.  If you are a
GMail user, you'd want to make sure "Plain text mode" is checked.

Before sending patches, please read Documentation/SubmittingPatches
and Documentation/CodingGuidelines to familiarize yourself with the
project convention.

If you sent a patch and you did not hear any response from anybody for
several days, it could be that your patch was totally uninteresting,
but it also is possible that it was simply lost in the noise.  Please
do not hesitate to send a reminder message in such a case.  Messages
getting lost in the noise may be a sign that those who can evaluate
your patch don't have enough mental/time bandwidth to process them
right at the moment, and it often helps to wait until the list traffic
becomes calmer before sending such a reminder.

The list archive is available at a few public sites:

        http://public-inbox.org/git/
        http://marc.info/?l=git
        http://www.spinics.net/lists/git/

For those who prefer to read it over NNTP:

        nntp://news.public-inbox.org/inbox.comp.version-control.git
	nntp://news.gmane.org/gmane.comp.version-control.git

are available.

When you point at a message in a mailing list archive, using its
message ID is often the most robust (if not very friendly) way to do
so, like this:

	http://public-inbox.org/git/Pine.LNX.4.58.0504150753440.7211@ppc970.osdl.org

Often these web interfaces accept the message ID with enclosing <>
stripped (like the above example to point at one of the most important
message in the Git list).

Some members of the development community can sometimes be found on
the #git and #git-devel IRC channels on Freenode.  Their logs are
available at:

        http://colabti.org/irclogger/irclogger_log/git
        http://colabti.org/irclogger/irclogger_log/git-devel

There is a volunteer-run newsletter to serve our community ("Git Rev
News" http://git.github.io/rev_news/rev_news.html).

Git is a member project of software freedom conservancy, a non-profit
organization (https://sfconservancy.org/).  To reach a committee of
liaisons to the conservancy, contact them at <git@sfconservancy.org>.


* Reporting bugs

When you think git does not behave as you expect, please do not stop
your bug report with just "git does not work".  "I used git in this
way, but it did not work" is not much better, neither is "I used git
in this way, and X happend, which is broken".  It often is that git is
correct to cause X happen in such a case, and it is your expectation
that is broken. People would not know what other result Y you expected
to see instead of X, if you left it unsaid.

Please remember to always state

 - what you wanted to achieve;

 - what you did (the version of git and the command sequence to reproduce
   the behavior);

 - what you saw happen (X above);

 - what you expected to see (Y above); and

 - how the last two are different.

See http://www.chiark.greenend.org.uk/~sgtatham/bugs.html for further
hints.

If you think you found a security-sensitive issue and want to disclose
it to us without announcing it to wider public, please contact us at
our security mailing list <git-security@googlegroups.com>.  This is
a closed list that is limited to people who need to know early about
vulnerabilities, including:

  - people triaging and fixing reported vulnerabilities
  - people operating major git hosting sites with many users
  - people packaging and distributing git to large numbers of people

where these issues are discussed without risk of the information
leaking out before we're ready to make public announcements.


* Repositories and documentation.

My public git.git repositories are at:

  git://git.kernel.org/pub/scm/git/git.git/
  https://kernel.googlesource.com/pub/scm/git/git
  git://repo.or.cz/alt-git.git/
  https://github.com/git/git/
  git://git.sourceforge.jp/gitroot/git-core/git.git/
  git://git-core.git.sourceforge.net/gitroot/git-core/git-core/

This one shows not just the main integration branches, but also
individual topics broken out:

  git://github.com/gitster/git/

A few web interfaces are found at:

  http://git.kernel.org/cgit/git/git.git
  https://kernel.googlesource.com/pub/scm/git/git
  http://repo.or.cz/w/alt-git.git

Preformatted documentation from the tip of the "master" branch can be
found in:

  git://git.kernel.org/pub/scm/git/git-{htmldocs,manpages}.git/
  git://repo.or.cz/git-{htmldocs,manpages}.git/
  https://github.com/gitster/git-{htmldocs,manpages}.git/

The manual pages formatted in HTML for the tip of 'master' can be
viewed online at:

  https://git.github.io/htmldocs/git.html


* How various branches are used.

There are four branches in git.git repository that track the source tree
of git: "master", "maint", "next", and "pu".

The "master" branch is meant to contain what are very well tested and
ready to be used in a production setting.  Every now and then, a
"feature release" is cut from the tip of this branch.  They used to be
named with three dotted decimal digits (e.g. "1.8.5"), but recently we
switched the versioning scheme and "feature releases" are named with
three-dotted decimal digits that ends with ".0" (e.g. "1.9.0").

The last such release was 2.15 done on Oct 30th, 2017.  You can expect
that the tip of the "master" branch is always more stable than any of
the released versions.

Whenever a feature release is made, "maint" branch is forked off from
"master" at that point.  Obvious and safe fixes after a feature
release are applied to this branch and maintenance releases are cut
from it.  Usually the fixes are merged to the "master" branch first,
several days before merged to the "maint" branch, to reduce the chance
of last-minute issues.  The maintenance releases used to be named with
four dotted decimal, named after the feature release they are updates
to (e.g. "1.8.5.1" was the first maintenance release for "1.8.5"
feature release).  These days, maintenance releases are named by
incrementing the last digit of three-dotted decimal name (e.g. "2.12.1"
was the first maintenance release for the "2.12" series).

New features never go to the 'maint' branch.  This branch is also
merged into "master" to propagate the fixes forward as needed.

A new development does not usually happen on "master". When you send a
series of patches, after review on the mailing list, a separate topic
branch is forked from the tip of "master" (or somewhere older, especially
when the topic is about fixing an earlier bug) and your patches are queued
there, and kept out of "master" while people test it out. The quality of
topic branches are judged primarily by the mailing list discussions.

Topic branches that are in good shape are merged to the "next" branch. In
general, the "next" branch always contains the tip of "master".  It might
not be quite rock-solid, but is expected to work more or less without major
breakage. The "next" branch is where new and exciting things take place. A
topic that is in "next" is expected to be polished to perfection before it
is merged to "master".  Please help this process by building & using the
"next" branch for your daily work, and reporting any new bugs you find to
the mailing list, before the breakage is merged down to the "master".

The "pu" (proposed updates) branch bundles all the remaining topic
branches the maintainer happens to have seen.  There is no guarantee that
the maintainer has enough bandwidth to pick up any and all topics that
are remotely promising from the list traffic, so please do not read
too much into a topic being on (or not on) the "pu" branch.  This
branch is mainly to remind the maintainer that the topics in them may
turn out to be interesting when they are polished, nothing more.  The
topics on this branch aren't usually complete, well tested, or well
documented and they often need further work.  When a topic that was
in "pu" proves to be in a testable shape, it is merged to "next".

You can run "git log --first-parent master..pu" to see what topics are
currently in flight.  Sometimes, an idea that looked promising turns out
to be not so good and the topic can be dropped from "pu" in such a case.
The output of the above "git log" talks about a "jch" branch, which is an
early part of the "pu" branch; that branch contains all topics that
are in "next" and a bit more (but not all of "pu") and is used by the
maintainer for his daily work.

The two branches "master" and "maint" are never rewound, and "next"
usually will not be either.  After a feature release is made from
"master", however, "next" will be rebuilt from the tip of "master"
using the topics that didn't make the cut in the feature release.

A natural consequence of how "next" and "pu" bundles topics together
is that until a topic is merged to "next", updates to it is expected
by replacing the patch(es) in the topic with an improved version,
and once a topic is merged to "next", updates to it needs to come as
incremental patches, pointing out what was wrong in the previous
patches and how the problem was corrected.

Note that being in "next" is not a guarantee to appear in the next
release, nor even in any future release.  There were cases that topics
needed reverting a few commits in them before graduating to "master",
or a topic that already was in "next" was reverted from "next" because
fatal flaws were found in it after it was merged to "next".


* Other people's trees.

Documentation/SubmittingPatches outlines to whom your proposed changes
should be sent.  As described in contrib/README, I would delegate fixes
and enhancements in contrib/ area to the primary contributors of them.

Although the following are included in git.git repository, they have their
own authoritative repository and maintainers:

 - git-gui/ comes from git-gui project, maintained by Pat Thoyts:

        git://repo.or.cz/git-gui.git

 - gitk-git/ comes from Paul Mackerras's gitk project:

        git://ozlabs.org/~paulus/gitk

 - po/ comes from the localization coordinator, Jiang Xin:

	https://github.com/git-l10n/git-po/

When sending proposed updates and fixes to these parts of the system,
please base your patches on these trees, not git.git (the former two
even have different directory structures).

A note from the maintainer

[Junio C Hamano]

Welcome to the Git development community.

This message is written by the maintainer and talks about how Git
project is managed, and how you can work with it.

* Mailing list and the community

The development is primarily done on the Git mailing list. Help
requests, feature proposals, bug reports and patches should be sent to
the list address <git@vger.kernel.org>.  You don't have to be
subscribed to send messages.  The convention on the list is to keep
everybody involved on Cc:, so it is unnecessary to say "Please Cc: me,
I am not subscribed".

Before sending patches, please read Documentation/SubmittingPatches
and Documentation/CodingGuidelines to familiarize yourself with the
project convention.

If you sent a patch and you did not hear any response from anybody for
several days, it could be that your patch was totally uninteresting,
but it also is possible that it was simply lost in the noise.  Please
do not hesitate to send a reminder message in such a case.  Messages
getting lost in the noise may be a sign that those who can evaluate
your patch don't have enough mental/time bandwidth to process them
right at the moment, and it often helps to wait until the list traffic
becomes calmer before sending such a reminder.

The list archive is available at a few public sites:

        http://public-inbox.org/git/
        http://marc.info/?l=git
        http://www.spinics.net/lists/git/

For those who prefer to read it over NNTP:

        nntp://news.public-inbox.org/inbox.comp.version-control.git
	nntp://news.gmane.org/gmane.comp.version-control.git

are available.

When you point at a message in a mailing list archive, using its
message ID is often the most robust (if not very friendly) way to do
so, like this:

	http://public-inbox.org/git/Pine.LNX.4.58.0504150753440.7211@ppc970.osdl.org

Often these web interfaces accept the message ID with enclosing <>
stripped (like the above example to point at one of the most important
message in the Git list).

Some members of the development community can sometimes be found on
the #git and #git-devel IRC channels on Freenode.  Their logs are
available at:

        http://colabti.org/irclogger/irclogger_log/git
        http://colabti.org/irclogger/irclogger_log/git-devel

There is a volunteer-run newsletter to serve our community ("Git Rev
News" http://git.github.io/rev_news/rev_news.html).

Git is a member project of software freedom conservancy, a non-profit
organization (https://sfconservancy.org/).  To reach a committee of
liaisons to the conservancy, contact them at <git@sfconservancy.org>.


* Reporting bugs

When you think git does not behave as you expect, please do not stop
your bug report with just "git does not work".  "I used git in this
way, but it did not work" is not much better, neither is "I used git
in this way, and X happend, which is broken".  It often is that git is
correct to cause X happen in such a case, and it is your expectation
that is broken. People would not know what other result Y you expected
to see instead of X, if you left it unsaid.

Please remember to always state

 - what you wanted to achieve;

 - what you did (the version of git and the command sequence to reproduce
   the behavior);

 - what you saw happen (X above);

 - what you expected to see (Y above); and

 - how the last two are different.

See http://www.chiark.greenend.org.uk/~sgtatham/bugs.html for further
hints.

If you think you found a security-sensitive issue and want to disclose
it to us without announcing it to wider public, please contact us at
our security mailing list <git-security@googlegroups.com>.  This is
a closed list that is limited to people who need to know early about
vulnerabilities, including:

  - people triaging and fixing reported vulnerabilities
  - people operating major git hosting sites with many users
  - people packaging and distributing git to large numbers of people

where these issues are discussed without risk of the information
leaking out before we're ready to make public announcements.


* Repositories and documentation.

My public git.git repositories are at:

  git://git.kernel.org/pub/scm/git/git.git/
  https://kernel.googlesource.com/pub/scm/git/git
  git://repo.or.cz/alt-git.git/
  https://github.com/git/git/
  git://git.sourceforge.jp/gitroot/git-core/git.git/
  git://git-core.git.sourceforge.net/gitroot/git-core/git-core/

This one shows not just the main integration branches, but also
individual topics broken out:

  git://github.com/gitster/git/

A few web interfaces are found at:

  http://git.kernel.org/cgit/git/git.git
  https://kernel.googlesource.com/pub/scm/git/git
  http://repo.or.cz/w/alt-git.git

Preformatted documentation from the tip of the "master" branch can be
found in:

  git://git.kernel.org/pub/scm/git/git-{htmldocs,manpages}.git/
  git://repo.or.cz/git-{htmldocs,manpages}.git/
  https://github.com/gitster/git-{htmldocs,manpages}.git/

The manual pages formatted in HTML for the tip of 'master' can be
viewed online at:

  https://git.github.io/htmldocs/git.html


* How various branches are used.

There are four branches in git.git repository that track the source tree
of git: "master", "maint", "next", and "pu".

The "master" branch is meant to contain what are very well tested and
ready to be used in a production setting.  Every now and then, a
"feature release" is cut from the tip of this branch.  They used to be
named with three dotted decimal digits (e.g. "1.8.5"), but recently we
switched the versioning scheme and "feature releases" are named with
three-dotted decimal digits that ends with ".0" (e.g. "1.9.0").

The last such release was 2.15 done on Oct 30th, 2017.  You can expect
that the tip of the "master" branch is always more stable than any of
the released versions.

Whenever a feature release is made, "maint" branch is forked off from
"master" at that point.  Obvious and safe fixes after a feature
release are applied to this branch and maintenance releases are cut
from it.  Usually the fixes are merged to the "master" branch first,
several days before merged to the "maint" branch, to reduce the chance
of last-minute issues.  The maintenance releases used to be named with
four dotted decimal, named after the feature release they are updates
to (e.g. "1.8.5.1" was the first maintenance release for "1.8.5"
feature release).  These days, maintenance releases are named by
incrementing the last digit of three-dotted decimal name (e.g. "2.12.1"
was the first maintenance release for the "2.12" series).

New features never go to the 'maint' branch.  This branch is also
merged into "master" to propagate the fixes forward as needed.

A new development does not usually happen on "master". When you send a
series of patches, after review on the mailing list, a separate topic
branch is forked from the tip of "master" (or somewhere older, especially
when the topic is about fixing an earlier bug) and your patches are queued
there, and kept out of "master" while people test it out. The quality of
topic branches are judged primarily by the mailing list discussions.

Topic branches that are in good shape are merged to the "next" branch. In
general, the "next" branch always contains the tip of "master".  It might
not be quite rock-solid, but is expected to work more or less without major
breakage. The "next" branch is where new and exciting things take place. A
topic that is in "next" is expected to be polished to perfection before it
is merged to "master".  Please help this process by building & using the
"next" branch for your daily work, and reporting any new bugs you find to
the mailing list, before the breakage is merged down to the "master".

The "pu" (proposed updates) branch bundles all the remaining topic
branches the maintainer happens to have seen.  There is no guarantee that
the maintainer has enough bandwidth to pick up any and all topics that
are remotely promising from the list traffic, so please do not read
too much into a topic being on (or not on) the "pu" branch.  This
branch is mainly to remind the maintainer that the topics in them may
turn out to be interesting when they are polished, nothing more.  The
topics on this branch aren't usually complete, well tested, or well
documented and they often need further work.  When a topic that was
in "pu" proves to be in a testable shape, it is merged to "next".

You can run "git log --first-parent master..pu" to see what topics are
currently in flight.  Sometimes, an idea that looked promising turns out
to be not so good and the topic can be dropped from "pu" in such a case.
The output of the above "git log" talks about a "jch" branch, which is an
early part of the "pu" branch; that branch contains all topics that
are in "next" and a bit more (but not all of "pu") and is used by the
maintainer for his daily work.

The two branches "master" and "maint" are never rewound, and "next"
usually will not be either.  After a feature release is made from
"master", however, "next" will be rebuilt from the tip of "master"
using the topics that didn't make the cut in the feature release.

A natural consequence of how "next" and "pu" bundles topics together
is that until a topic is merged to "next", updates to it is expected
by replacing the patch(es) in the topic with an improved version,
and once a topic is merged to "next", updates to it needs to come as
incremental patches, pointing out what was wrong in the previous
patches and how the problem was corrected.

Note that being in "next" is not a guarantee to appear in the next
release, nor even in any future release.  There were cases that topics
needed reverting a few commits in them before graduating to "master",
or a topic that already was in "next" was reverted from "next" because
fatal flaws were found in it after it was merged to "next".


* Other people's trees.

Documentation/SubmittingPatches outlines to whom your proposed changes
should be sent.  As described in contrib/README, I would delegate fixes
and enhancements in contrib/ area to the primary contributors of them.

Although the following are included in git.git repository, they have their
own authoritative repository and maintainers:

 - git-gui/ comes from git-gui project, maintained by Pat Thoyts:

        git://repo.or.cz/git-gui.git

 - gitk-git/ comes from Paul Mackerras's gitk project:

        git://ozlabs.org/~paulus/gitk

 - po/ comes from the localization coordinator, Jiang Xin:

	https://github.com/git-l10n/git-po/

When sending proposed updates and fixes to these parts of the system,
please base your patches on these trees, not git.git (the former two
even have different directory structures).

Re: A note from the maintainer

[Johannes Schindelin]

Hi Junio,

On Mon, 30 Oct 2017, Junio C Hamano wrote:

> The development is primarily done on the Git mailing list. Help
> requests, feature proposals, bug reports and patches should be sent to
> the list address <git@vger.kernel.org>.  You don't have to be
> subscribed to send messages.  The convention on the list is to keep
> everybody involved on Cc:, so it is unnecessary to say "Please Cc: me,
> I am not subscribed".

I have heard about a dozen complaints that mails were simply eaten by the
mailing list. At least some of those cases were due to HTML (or
HTML/plain) mails being quietly dropped, and it caused more than just
minor frustration.

Maybe mention this in your maintainer's note, to help stave off such
problems?

Ciao,
Dscho

A note from the maintainer

[Junio C Hamano]

Welcome to the Git development community.

This message is written by the maintainer and talks about how Git
project is managed, and how you can work with it.

* Mailing list and the community

The development is primarily done on the Git mailing list. Help
requests, feature proposals, bug reports and patches should be sent to
the list address <git@vger.kernel.org>.  You don't have to be
subscribed to send messages.  The convention on the list is to keep
everybody involved on Cc:, so it is unnecessary to say "Please Cc: me,
I am not subscribed".

Before sending patches, please read Documentation/SubmittingPatches
and Documentation/CodingGuidelines to familiarize yourself with the
project convention.

If you sent a patch and you did not hear any response from anybody for
several days, it could be that your patch was totally uninteresting,
but it also is possible that it was simply lost in the noise.  Please
do not hesitate to send a reminder message in such a case.  Messages
getting lost in the noise may be a sign that those who can evaluate
your patch don't have enough mental/time bandwidth to process them
right at the moment, and it often helps to wait until the list traffic
becomes calmer before sending such a reminder.

The list archive is available at a few public sites:

        http://public-inbox.org/git/
        http://marc.info/?l=git
        http://www.spinics.net/lists/git/

For those who prefer to read it over NNTP:

        nntp://news.public-inbox.org/inbox.comp.version-control.git
	nntp://news.gmane.org/gmane.comp.version-control.git

are available.

When you point at a message in a mailing list archive, using its
message ID is often the most robust (if not very friendly) way to do
so, like this:

	http://public-inbox.org/git/Pine.LNX.4.58.0504150753440.7211@ppc970.osdl.org

Often these web interfaces accept the message ID with enclosing <>
stripped (like the above example to point at one of the most important
message in the Git list).

Some members of the development community can sometimes be found on
the #git and #git-devel IRC channels on Freenode.  Their logs are
available at:

        http://colabti.org/irclogger/irclogger_log/git
        http://colabti.org/irclogger/irclogger_log/git-devel

There is a volunteer-run newsletter to serve our community ("Git Rev
News" http://git.github.io/rev_news/rev_news.html).

Git is a member project of software freedom conservancy, a non-profit
organization (https://sfconservancy.org/).  To reach a committee of
liaisons to the conservancy, contact them at <git@sfconservancy.org>.


* Reporting bugs

When you think git does not behave as you expect, please do not stop
your bug report with just "git does not work".  "I used git in this
way, but it did not work" is not much better, neither is "I used git
in this way, and X happend, which is broken".  It often is that git is
correct to cause X happen in such a case, and it is your expectation
that is broken. People would not know what other result Y you expected
to see instead of X, if you left it unsaid.

Please remember to always state

 - what you wanted to achieve;

 - what you did (the version of git and the command sequence to reproduce
   the behavior);

 - what you saw happen (X above);

 - what you expected to see (Y above); and

 - how the last two are different.

See http://www.chiark.greenend.org.uk/~sgtatham/bugs.html for further
hints.

If you think you found a security-sensitive issue and want to disclose
it to us without announcing it to wider public, please contact us at
our security mailing list <git-security@googlegroups.com>.  This is
a closed list that is limited to people who need to know early about
vulnerabilities, including:

  - people triaging and fixing reported vulnerabilities
  - people operating major git hosting sites with many users
  - people packaging and distributing git to large numbers of people

where these issues are discussed without risk of the information
leaking out before we're ready to make public announcements.


* Repositories and documentation.

My public git.git repositories are at:

  git://git.kernel.org/pub/scm/git/git.git/
  https://kernel.googlesource.com/pub/scm/git/git
  git://repo.or.cz/alt-git.git/
  https://github.com/git/git/
  git://git.sourceforge.jp/gitroot/git-core/git.git/
  git://git-core.git.sourceforge.net/gitroot/git-core/git-core/

This one shows not just the main integration branches, but also
individual topics broken out:

  git://github.com/gitster/git/

A few web interfaces are found at:

  http://git.kernel.org/cgit/git/git.git
  https://kernel.googlesource.com/pub/scm/git/git
  http://repo.or.cz/w/alt-git.git

Preformatted documentation from the tip of the "master" branch can be
found in:

  git://git.kernel.org/pub/scm/git/git-{htmldocs,manpages}.git/
  git://repo.or.cz/git-{htmldocs,manpages}.git/
  https://github.com/gitster/git-{htmldocs,manpages}.git/

The manual pages formatted in HTML for the tip of 'master' can be
viewed online at:

  https://git.github.io/htmldocs/git.html


* How various branches are used.

There are four branches in git.git repository that track the source tree
of git: "master", "maint", "next", and "pu".

The "master" branch is meant to contain what are very well tested and
ready to be used in a production setting.  Every now and then, a
"feature release" is cut from the tip of this branch.  They used to be
named with three dotted decimal digits (e.g. "1.8.5"), but recently we
switched the versioning scheme and "feature releases" are named with
three-dotted decimal digits that ends with ".0" (e.g. "1.9.0").

The last such release was 2.14 done on Aug 4th, 2017.  You can expect
that the tip of the "master" branch is always more stable than any of
the released versions.

Whenever a feature release is made, "maint" branch is forked off from
"master" at that point.  Obvious and safe fixes after a feature
release are applied to this branch and maintenance releases are cut
from it.  Usually the fixes are merged to the "master" branch first,
several days before merged to the "maint" branch, to reduce the chance
of last-minute issues.  The maintenance releases used to be named with
four dotted decimal, named after the feature release they are updates
to (e.g. "1.8.5.1" was the first maintenance release for "1.8.5"
feature release).  These days, maintenance releases are named by
incrementing the last digit of three-dotted decimal name (e.g. "2.12.1"
was the first maintenance release for the "2.12" series).

New features never go to the 'maint' branch.  This branch is also
merged into "master" to propagate the fixes forward as needed.

A new development does not usually happen on "master". When you send a
series of patches, after review on the mailing list, a separate topic
branch is forked from the tip of "master" (or somewhere older, especially
when the topic is about fixing an earlier bug) and your patches are queued
there, and kept out of "master" while people test it out. The quality of
topic branches are judged primarily by the mailing list discussions.

Topic branches that are in good shape are merged to the "next" branch. In
general, the "next" branch always contains the tip of "master".  It might
not be quite rock-solid, but is expected to work more or less without major
breakage. The "next" branch is where new and exciting things take place. A
topic that is in "next" is expected to be polished to perfection before it
is merged to "master".  Please help this process by building & using the
"next" branch for your daily work, and reporting any new bugs you find to
the mailing list, before the breakage is merged down to the "master".

The "pu" (proposed updates) branch bundles all the remaining topic
branches the maintainer happens to have seen.  There is no guarantee that
the maintainer has enough bandwidth to pick up any and all topics that
are remotely promising from the list traffic, so please do not read
too much into a topic being on (or not on) the "pu" branch.  This
branch is mainly to remind the maintainer that the topics in them may
turn out to be interesting when they are polished, nothing more.  The
topics on this branch aren't usually complete, well tested, or well
documented and they often need further work.  When a topic that was
in "pu" proves to be in a testable shape, it is merged to "next".

You can run "git log --first-parent master..pu" to see what topics are
currently in flight.  Sometimes, an idea that looked promising turns out
to be not so good and the topic can be dropped from "pu" in such a case.
The output of the above "git log" talks about a "jch" branch, which is an
early part of the "pu" branch; that branch contains all topics that
are in "next" and a bit more (but not all of "pu") and is used by the
maintainer for his daily work.

The two branches "master" and "maint" are never rewound, and "next"
usually will not be either.  After a feature release is made from
"master", however, "next" will be rebuilt from the tip of "master"
using the topics that didn't make the cut in the feature release.

A natural consequence of how "next" and "pu" bundles topics together
is that until a topic is merged to "next", updates to it is expected
by replacing the patch(es) in the topic with an improved version,
and once a topic is merged to "next", updates to it needs to come as
incremental patches, pointing out what was wrong in the previous
patches and how the problem was corrected.

Note that being in "next" is not a guarantee to appear in the next
release, nor even in any future release.  There were cases that topics
needed reverting a few commits in them before graduating to "master",
or a topic that already was in "next" was reverted from "next" because
fatal flaws were found in it after it was merged to "next".


* Other people's trees.

Documentation/SubmittingPatches outlines to whom your proposed changes
should be sent.  As described in contrib/README, I would delegate fixes
and enhancements in contrib/ area to the primary contributors of them.

Although the following are included in git.git repository, they have their
own authoritative repository and maintainers:

 - git-gui/ comes from git-gui project, maintained by Pat Thoyts:

        git://repo.or.cz/git-gui.git

 - gitk-git/ comes from Paul Mackerras's gitk project:

        git://ozlabs.org/~paulus/gitk

 - po/ comes from the localization coordinator, Jiang Xin:

	https://github.com/git-l10n/git-po/

When sending proposed updates and fixes to these parts of the system,
please base your patches on these trees, not git.git (the former two
even have different directory structures).

A note from the maintainer

[Junio C Hamano]

Welcome to the Git development community.

This message is written by the maintainer and talks about how Git
project is managed, and how you can work with it.

* Mailing list and the community

The development is primarily done on the Git mailing list. Help
requests, feature proposals, bug reports and patches should be sent to
the list address <git@vger.kernel.org>.  You don't have to be
subscribed to send messages.  The convention on the list is to keep
everybody involved on Cc:, so it is unnecessary to say "Please Cc: me,
I am not subscribed".

Before sending patches, please read Documentation/SubmittingPatches
and Documentation/CodingGuidelines to familiarize yourself with the
project convention.

If you sent a patch and you did not hear any response from anybody for
several days, it could be that your patch was totally uninteresting,
but it also is possible that it was simply lost in the noise.  Please
do not hesitate to send a reminder message in such a case.  Messages
getting lost in the noise may be a sign that those who can evaluate
your patch don't have enough mental/time bandwidth to process them
right at the moment, and it often helps to wait until the list traffic
becomes calmer before sending such a reminder.

The list archive is available at a few public sites:

        http://public-inbox.org/git/
        http://marc.info/?l=git
        http://www.spinics.net/lists/git/

For those who prefer to read it over NNTP:

        nntp://news.public-inbox.org/inbox.comp.version-control.git
	nntp://news.gmane.org/gmane.comp.version-control.git

are available.

When you point at a message in a mailing list archive, using its
message ID is often the most robust (if not very friendly) way to do
so, like this:

	http://public-inbox.org/git/Pine.LNX.4.58.0504150753440.7211@ppc970.osdl.org

Often these web interfaces accept the message ID with enclosing <>
stripped (like the above example to point at one of the most important
message in the Git list).

Some members of the development community can sometimes be found on
the #git and #git-devel IRC channels on Freenode.  Their logs are
available at:

        http://colabti.org/irclogger/irclogger_log/git
        http://colabti.org/irclogger/irclogger_log/git-devel

There is a volunteer-run newsletter to serve our community ("Git Rev
News" http://git.github.io/rev_news/rev_news.html).

Git is a member project of software freedom conservancy, a non-profit
organization (https://sfconservancy.org/).  To reach a committee of
liaisons to the conservancy, contact them at <git@sfconservancy.org>.


* Reporting bugs

When you think git does not behave as you expect, please do not stop
your bug report with just "git does not work".  "I used git in this
way, but it did not work" is not much better, neither is "I used git
in this way, and X happend, which is broken".  It often is that git is
correct to cause X happen in such a case, and it is your expectation
that is broken. People would not know what other result Y you expected
to see instead of X, if you left it unsaid.

Please remember to always state

 - what you wanted to achieve;

 - what you did (the version of git and the command sequence to reproduce
   the behavior);

 - what you saw happen (X above);

 - what you expected to see (Y above); and

 - how the last two are different.

See http://www.chiark.greenend.org.uk/~sgtatham/bugs.html for further
hints.

If you think you found a security-sensitive issue and want to disclose
it to us without announcing it to wider public, please contact us at
our security mailing list <git-security@googlegroups.com>.  This is
a closed list that is limited to people who need to know early about
vulnerabilities, including:

  - people triaging and fixing reported vulnerabilities
  - people operating major git hosting sites with many users
  - people packaging and distributing git to large numbers of people

where these issues are discussed without risk of the information
leaking out before we're ready to make public announcements.


* Repositories and documentation.

My public git.git repositories are at:

  git://git.kernel.org/pub/scm/git/git.git/
  https://kernel.googlesource.com/pub/scm/git/git
  git://repo.or.cz/alt-git.git/
  https://github.com/git/git/
  git://git.sourceforge.jp/gitroot/git-core/git.git/
  git://git-core.git.sourceforge.net/gitroot/git-core/git-core/

This one shows not just the main integration branches, but also
individual topics broken out:

  git://github.com/gitster/git/

A few web interfaces are found at:

  http://git.kernel.org/cgit/git/git.git
  https://kernel.googlesource.com/pub/scm/git/git
  http://repo.or.cz/w/alt-git.git

Preformatted documentation from the tip of the "master" branch can be
found in:

  git://git.kernel.org/pub/scm/git/git-{htmldocs,manpages}.git/
  git://repo.or.cz/git-{htmldocs,manpages}.git/
  https://github.com/gitster/git-{htmldocs,manpages}.git/

The manual pages formatted in HTML for the tip of 'master' can be
viewed online at:

  https://git.github.io/htmldocs/git.html


* How various branches are used.

There are four branches in git.git repository that track the source tree
of git: "master", "maint", "next", and "pu".

The "master" branch is meant to contain what are very well tested and
ready to be used in a production setting.  Every now and then, a
"feature release" is cut from the tip of this branch.  They used to be
named with three dotted decimal digits (e.g. "1.8.5"), but recently we
switched the versioning scheme and "feature releases" are named with
three-dotted decimal digits that ends with ".0" (e.g. "1.9.0").

The last such release was 2.12 done on Feb 24th, 2017. You can expect
that the tip of the "master" branch is always more stable than any of
the released versions.

Whenever a feature release is made, "maint" branch is forked off from
"master" at that point.  Obvious and safe fixes after a feature
release are applied to this branch and maintenance releases are cut
from it.  Usually the fixes are merged to the "master" branch first,
several days before merged to the "maint" branch, to reduce the chance
of last-minute issues.  The maintenance releases used to be named with
four dotted decimal, named after the feature release they are updates
to (e.g. "1.8.5.1" was the first maintenance release for "1.8.5"
feature release).  These days, maintenance releases are named by
incrementing the last digit of three-dotted decimal name (e.g. "2.12.1"
was the first maintenance release for the "2.12" series).

New features never go to the 'maint' branch.  This branch is also
merged into "master" to propagate the fixes forward as needed.

A new development does not usually happen on "master". When you send a
series of patches, after review on the mailing list, a separate topic
branch is forked from the tip of "master" (or somewhere older, especially
when the topic is about fixing an earlier bug) and your patches are queued
there, and kept out of "master" while people test it out. The quality of
topic branches are judged primarily by the mailing list discussions.

Topic branches that are in good shape are merged to the "next" branch. In
general, the "next" branch always contains the tip of "master".  It might
not be quite rock-solid, but is expected to work more or less without major
breakage. The "next" branch is where new and exciting things take place. A
topic that is in "next" is expected to be polished to perfection before it
is merged to "master".  Please help this process by building & using the
"next" branch for your daily work, and reporting any new bugs you find to
the mailing list, before the breakage is merged down to the "master".

The "pu" (proposed updates) branch bundles all the remaining topic
branches the maintainer happens to have seen.  There is no guarantee that
the maintainer has enough bandwidth to pick up any and all topics that
are remotely promising from the list traffic, so please do not read
too much into a topic being on (or not on) the "pu" branch.  This
branch is mainly to remind the maintainer that the topics in them may
turn out to be interesting when they are polished, nothing more.  The
topics on this branch aren't usually complete, well tested, or well
documented and they often need further work.  When a topic that was
in "pu" proves to be in a testable shape, it is merged to "next".

You can run "git log --first-parent master..pu" to see what topics are
currently in flight.  Sometimes, an idea that looked promising turns out
to be not so good and the topic can be dropped from "pu" in such a case.
The output of the above "git log" talks about a "jch" branch, which is an
early part of the "pu" branch; that branch contains all topics that
are in "next" and a bit more (but not all of "pu") and is used by the
maintainer for his daily work.

The two branches "master" and "maint" are never rewound, and "next"
usually will not be either.  After a feature release is made from
"master", however, "next" will be rebuilt from the tip of "master"
using the topics that didn't make the cut in the feature release.

A natural consequence of how "next" and "pu" bundles topics together
is that until a topic is merged to "next", updates to it is expected
by replacing the patch(es) in the topic with an improved version,
and once a topic is merged to "next", updates to it needs to come as
incremental patches, pointing out what was wrong in the previous
patches and how the problem was corrected.

Note that being in "next" is not a guarantee to appear in the next
release, nor even in any future release.  There were cases that topics
needed reverting a few commits in them before graduating to "master",
or a topic that already was in "next" was reverted from "next" because
fatal flaws were found in it after it was merged to "next".


* Other people's trees.

Documentation/SubmittingPatches outlines to whom your proposed changes
should be sent.  As described in contrib/README, I would delegate fixes
and enhancements in contrib/ area to the primary contributors of them.

Although the following are included in git.git repository, they have their
own authoritative repository and maintainers:

 - git-gui/ comes from git-gui project, maintained by Pat Thoyts:

        git://repo.or.cz/git-gui.git

 - gitk-git/ comes from Paul Mackerras's gitk project:

        git://ozlabs.org/~paulus/gitk

 - po/ comes from the localization coordinator, Jiang Xin:

	https://github.com/git-l10n/git-po/

When sending proposed updates and fixes to these parts of the system,
please base your patches on these trees, not git.git (the former two
even have different directory structures).

A note from the maintainer

[Junio C Hamano]

Welcome to the Git development community.

This message is written by the maintainer and talks about how Git
project is managed, and how you can work with it.

* Mailing list and the community

The development is primarily done on the Git mailing list. Help
requests, feature proposals, bug reports and patches should be sent to
the list address <git@vger.kernel.org>.  You don't have to be
subscribed to send messages.  The convention on the list is to keep
everybody involved on Cc:, so it is unnecessary to say "Please Cc: me,
I am not subscribed".

Before sending patches, please read Documentation/SubmittingPatches
and Documentation/CodingGuidelines to familiarize yourself with the
project convention.

If you sent a patch and you did not hear any response from anybody for
several days, it could be that your patch was totally uninteresting,
but it also is possible that it was simply lost in the noise.  Please
do not hesitate to send a reminder message in such a case.  Messages
getting lost in the noise may be a sign that those who can evaluate
your patch don't have enough mental/time bandwidth to process them
right at the moment, and it often helps to wait until the list traffic
becomes calmer before sending such a reminder.

The list archive is available at a few public sites:

        http://public-inbox.org/git/
        http://marc.info/?l=git
        http://www.spinics.net/lists/git/

For those who prefer to read it over NNTP:

        nntp://news.public-inbox.org/inbox.comp.version-control.git
	nntp://news.gmane.org/gmane.comp.version-control.git

are available.

When you point at a message in a mailing list archive, using its
message ID is often the most robust (if not very friendly) way to do
so, like this:

	http://public-inbox.org/git/Pine.LNX.4.58.0504150753440.7211@ppc970.osdl.org

Often these web interfaces accept the message ID with enclosing <>
stripped (like the above example to point at one of the most important
message in the Git list).

Some members of the development community can sometimes be found on
the #git and #git-devel IRC channels on Freenode.  Their logs are
available at:

        http://colabti.org/irclogger/irclogger_log/git
        http://colabti.org/irclogger/irclogger_log/git-devel

There is a volunteer-run newsletter to serve our community ("Git Rev
News" http://git.github.io/rev_news/rev_news.html).

Git is a member project of software freedom conservancy, a non-profit
organization (https://sfconservancy.org/).  To reach a committee of
liaisons to the conservancy, contact them at <git@sfconservancy.org>.


* Reporting bugs

When you think git does not behave as you expect, please do not stop
your bug report with just "git does not work".  "I used git in this
way, but it did not work" is not much better, neither is "I used git
in this way, and X happend, which is broken".  It often is that git is
correct to cause X happen in such a case, and it is your expectation
that is broken. People would not know what other result Y you expected
to see instead of X, if you left it unsaid.

Please remember to always state

 - what you wanted to achieve;

 - what you did (the version of git and the command sequence to reproduce
   the behavior);

 - what you saw happen (X above);

 - what you expected to see (Y above); and

 - how the last two are different.

See http://www.chiark.greenend.org.uk/~sgtatham/bugs.html for further
hints.

If you think you found a security-sensitive issue and want to disclose
it to us without announcing it to wider public, please contact us at
our security mailing list <git-security@googlegroups.com>.  This is
a closed list that is limited to people who need to know early about
vulnerabilities, including:

  - people triaging and fixing reported vulnerabilities
  - people operating major git hosting sites with many users
  - people packaging and distributing git to large numbers of people

where these issues are discussed without risk of the information
leaking out before we're ready to make public announcements.


* Repositories and documentation.

My public git.git repositories are at:

  git://git.kernel.org/pub/scm/git/git.git/
  https://kernel.googlesource.com/pub/scm/git/git
  git://repo.or.cz/alt-git.git/
  https://github.com/git/git/
  git://git.sourceforge.jp/gitroot/git-core/git.git/
  git://git-core.git.sourceforge.net/gitroot/git-core/git-core/

This one shows not just the main integration branches, but also
individual topics broken out:

  git://github.com/gitster/git/

A few web interfaces are found at:

  http://git.kernel.org/cgit/git/git.git
  https://kernel.googlesource.com/pub/scm/git/git
  http://repo.or.cz/w/alt-git.git

Preformatted documentation from the tip of the "master" branch can be
found in:

  git://git.kernel.org/pub/scm/git/git-{htmldocs,manpages}.git/
  git://repo.or.cz/git-{htmldocs,manpages}.git/
  https://github.com/gitster/git-{htmldocs,manpages}.git/

The manual pages formatted in HTML for the tip of 'master' can be
viewed online at:

  https://git.github.io/htmldocs/git.html


* How various branches are used.

There are four branches in git.git repository that track the source tree
of git: "master", "maint", "next", and "pu".

The "master" branch is meant to contain what are very well tested and
ready to be used in a production setting.  Every now and then, a
"feature release" is cut from the tip of this branch.  They used to be
named with three dotted decimal digits (e.g. "1.8.5"), but recently we
switched the versioning scheme and "feature releases" are named with
three-dotted decimal digits that ends with ".0" (e.g. "1.9.0").

The last such release was 2.12 done on Feb 24th, 2017. You can expect
that the tip of the "master" branch is always more stable than any of
the released versions.

Whenever a feature release is made, "maint" branch is forked off from
"master" at that point.  Obvious and safe fixes after a feature
release are applied to this branch and maintenance releases are cut
from it.  Usually the fixes are merged to the "master" branch first,
several days before merged to the "maint" branch, to reduce the chance
of last-minute issues.  The maintenance releases used to be named with
four dotted decimal, named after the feature release they are updates
to (e.g. "1.8.5.1" was the first maintenance release for "1.8.5"
feature release).  These days, maintenance releases are named by
incrementing the last digit of three-dotted decimal name (e.g. "2.12.1"
was the first maintenance release for the "2.12" series).

New features never go to the 'maint' branch.  This branch is also
merged into "master" to propagate the fixes forward as needed.

A new development does not usually happen on "master". When you send a
series of patches, after review on the mailing list, a separate topic
branch is forked from the tip of "master" (or somewhere older, especially
when the topic is about fixing an earlier bug) and your patches are queued
there, and kept out of "master" while people test it out. The quality of
topic branches are judged primarily by the mailing list discussions.

Topic branches that are in good shape are merged to the "next" branch. In
general, the "next" branch always contains the tip of "master".  It might
not be quite rock-solid, but is expected to work more or less without major
breakage. The "next" branch is where new and exciting things take place. A
topic that is in "next" is expected to be polished to perfection before it
is merged to "master".  Please help this process by building & using the
"next" branch for your daily work, and reporting any new bugs you find to
the mailing list, before the breakage is merged down to the "master".

The "pu" (proposed updates) branch bundles all the remaining topic
branches the maintainer happens to have seen.  There is no guarantee that
the maintainer has enough bandwidth to pick up any and all topics that
are remotely promising from the list traffic, so please do not read
too much into a topic being on (or not on) the "pu" branch.  This
branch is mainly to remind the maintainer that the topics in them may
turn out to be interesting when they are polished, nothing more.  The
topics on this branch aren't usually complete, well tested, or well
documented and they often need further work.  When a topic that was
in "pu" proves to be in a testable shape, it is merged to "next".

You can run "git log --first-parent master..pu" to see what topics are
currently in flight.  Sometimes, an idea that looked promising turns out
to be not so good and the topic can be dropped from "pu" in such a case.
The output of the above "git log" talks about a "jch" branch, which is an
early part of the "pu" branch; that branch contains all topics that
are in "next" and a bit more (but not all of "pu") and is used by the
maintainer for his daily work.

The two branches "master" and "maint" are never rewound, and "next"
usually will not be either.  After a feature release is made from
"master", however, "next" will be rebuilt from the tip of "master"
using the topics that didn't make the cut in the feature release.

A natural consequence of how "next" and "pu" bundles topics together
is that until a topic is merged to "next", updates to it is expected
by replacing the patch(es) in the topic with an improved version,
and once a topic is merged to "next", updates to it needs to come as
incremental patches, pointing out what was wrong in the previous
patches and how the problem was corrected.

Note that being in "next" is not a guarantee to appear in the next
release, nor even in any future release.  There were cases that topics
needed reverting a few commits in them before graduating to "master",
or a topic that already was in "next" was reverted from "next" because
fatal flaws were found in it after it was merged to "next".


* Other people's trees.

Documentation/SubmittingPatches outlines to whom your proposed changes
should be sent.  As described in contrib/README, I would delegate fixes
and enhancements in contrib/ area to the primary contributors of them.

Although the following are included in git.git repository, they have their
own authoritative repository and maintainers:

 - git-gui/ comes from git-gui project, maintained by Pat Thoyts:

        git://repo.or.cz/git-gui.git

 - gitk-git/ comes from Paul Mackerras's gitk project:

        git://ozlabs.org/~paulus/gitk

 - po/ comes from the localization coordinator, Jiang Xin:

	https://github.com/git-l10n/git-po/

When sending proposed updates and fixes to these parts of the system,
please base your patches on these trees, not git.git (the former two
even have different directory structures).

A note from the maintainer

[Junio C Hamano]

Welcome to the Git development community.

This message is written by the maintainer and talks about how Git
project is managed, and how you can work with it.

* Mailing list and the community

The development is primarily done on the Git mailing list. Help
requests, feature proposals, bug reports and patches should be sent to
the list address <git@vger.kernel.org>.  You don't have to be
subscribed to send messages.  The convention on the list is to keep
everybody involved on Cc:, so it is unnecessary to say "Please Cc: me,
I am not subscribed".

Before sending patches, please read Documentation/SubmittingPatches
and Documentation/CodingGuidelines to familiarize yourself with the
project convention.

If you sent a patch and you did not hear any response from anybody for
several days, it could be that your patch was totally uninteresting,
but it also is possible that it was simply lost in the noise.  Please
do not hesitate to send a reminder message in such a case.  Messages
getting lost in the noise may be a sign that those who can evaluate
your patch don't have enough mental/time bandwidth to process them
right at the moment, and it often helps to wait until the list traffic
becomes calmer before sending such a reminder.

The list archive is available at a few public sites:

        http://public-inbox.org/git/
        http://marc.info/?l=git
        http://www.spinics.net/lists/git/

For those who prefer to read it over NNTP:

        nntp://news.public-inbox.org/inbox.comp.version-control.git
	nntp://news.gmane.org/gmane.comp.version-control.git

are available.

When you point at a message in a mailing list archive, using its
message ID is often the most robust (if not very friendly) way to do
so, like this:

	http://public-inbox.org/git/Pine.LNX.4.58.0504150753440.7211@ppc970.osdl.org

Often these web interfaces accept the message ID with enclosing <>
stripped (like the above example to point at one of the most important
message in the Git list).

Some members of the development community can sometimes be found on
the #git and #git-devel IRC channels on Freenode.  Their logs are
available at:

        http://colabti.org/irclogger/irclogger_log/git
        http://colabti.org/irclogger/irclogger_log/git-devel

There is a volunteer-run newsletter to serve our community ("Git Rev
News" http://git.github.io/rev_news/rev_news.html).

Git is a member project of software freedom conservancy, a non-profit
organization (https://sfconservancy.org/).  To reach a committee of
liaisons to the conservancy, contact them at <git@sfconservancy.org>.


* Reporting bugs

When you think git does not behave as you expect, please do not stop
your bug report with just "git does not work".  "I used git in this
way, but it did not work" is not much better, neither is "I used git
in this way, and X happend, which is broken".  It often is that git is
correct to cause X happen in such a case, and it is your expectation
that is broken. People would not know what other result Y you expected
to see instead of X, if you left it unsaid.

Please remember to always state

 - what you wanted to achieve;

 - what you did (the version of git and the command sequence to reproduce
   the behavior);

 - what you saw happen (X above);

 - what you expected to see (Y above); and

 - how the last two are different.

See http://www.chiark.greenend.org.uk/~sgtatham/bugs.html for further
hints.

If you think you found a security-sensitive issue and want to disclose
it to us without announcing it to wider public, please contact us at
our security mailing list <git-security@googlegroups.com>.  This is
a closed list that is limited to people who need to know early about
vulnerabilities, including:

  - people triaging and fixing reported vulnerabilities
  - people operating major git hosting sites with many users
  - people packaging and distributing git to large numbers of people

where these issues are discussed without risk of the information
leaking out before we're ready to make public announcements.


* Repositories and documentation.

My public git.git repositories are at:

  git://git.kernel.org/pub/scm/git/git.git/
  https://kernel.googlesource.com/pub/scm/git/git
  git://repo.or.cz/alt-git.git/
  https://github.com/git/git/
  git://git.sourceforge.jp/gitroot/git-core/git.git/
  git://git-core.git.sourceforge.net/gitroot/git-core/git-core/

This one shows not just the main integration branches, but also
individual topics broken out:

  git://github.com/gitster/git/

A few web interfaces are found at:

  http://git.kernel.org/cgit/git/git.git
  https://kernel.googlesource.com/pub/scm/git/git
  http://repo.or.cz/w/alt-git.git

Preformatted documentation from the tip of the "master" branch can be
found in:

  git://git.kernel.org/pub/scm/git/git-{htmldocs,manpages}.git/
  git://repo.or.cz/git-{htmldocs,manpages}.git/
  https://github.com/gitster/git-{htmldocs,manpages}.git/

The manual pages formatted in HTML for the tip of 'master' can be
viewed online at:

  https://git.github.io/htmldocs/git.html


* How various branches are used.

There are four branches in git.git repository that track the source tree
of git: "master", "maint", "next", and "pu".

The "master" branch is meant to contain what are very well tested and
ready to be used in a production setting.  Every now and then, a
"feature release" is cut from the tip of this branch.  They used to be
named with three dotted decimal digits (e.g. "1.8.5"), but recently we
switched the versioning scheme and "feature releases" are named with
three-dotted decimal digits that ends with ".0" (e.g. "1.9.0").

The last such release was 2.12 done on Feb 24th, 2017. You can expect
that the tip of the "master" branch is always more stable than any of
the released versions.

Whenever a feature release is made, "maint" branch is forked off from
"master" at that point.  Obvious and safe fixes after a feature
release are applied to this branch and maintenance releases are cut
from it.  Usually the fixes are merged to the "master" branch first,
several days before merged to the "maint" branch, to reduce the chance
of last-minute issues.  The maintenance releases used to be named with
four dotted decimal, named after the feature release they are updates
to (e.g. "1.8.5.1" was the first maintenance release for "1.8.5"
feature release).  These days, maintenance releases are named by
incrementing the last digit of three-dotted decimal name (e.g. "2.12.1"
was the first maintenance release for the "2.12" series).

New features never go to the 'maint' branch.  This branch is also
merged into "master" to propagate the fixes forward as needed.

A new development does not usually happen on "master". When you send a
series of patches, after review on the mailing list, a separate topic
branch is forked from the tip of "master" (or somewhere older, especially
when the topic is about fixing an earlier bug) and your patches are queued
there, and kept out of "master" while people test it out. The quality of
topic branches are judged primarily by the mailing list discussions.

Topic branches that are in good shape are merged to the "next" branch. In
general, the "next" branch always contains the tip of "master".  It might
not be quite rock-solid, but is expected to work more or less without major
breakage. The "next" branch is where new and exciting things take place. A
topic that is in "next" is expected to be polished to perfection before it
is merged to "master".  Please help this process by building & using the
"next" branch for your daily work, and reporting any new bugs you find to
the mailing list, before the breakage is merged down to the "master".

The "pu" (proposed updates) branch bundles all the remaining topic
branches the maintainer happens to have seen.  There is no guarantee that
the maintainer has enough bandwidth to pick up any and all topics that
are remotely promising from the list traffic, so please do not read
too much into a topic being on (or not on) the "pu" branch.  This
branch is mainly to remind the maintainer that the topics in them may
turn out to be interesting when they are polished, nothing more.  The
topics on this branch aren't usually complete, well tested, or well
documented and they often need further work.  When a topic that was
in "pu" proves to be in a testable shape, it is merged to "next".

You can run "git log --first-parent master..pu" to see what topics are
currently in flight.  Sometimes, an idea that looked promising turns out
to be not so good and the topic can be dropped from "pu" in such a case.
The output of the above "git log" talks about a "jch" branch, which is an
early part of the "pu" branch; that branch contains all topics that
are in "next" and a bit more (but not all of "pu") and is used by the
maintainer for his daily work.

The two branches "master" and "maint" are never rewound, and "next"
usually will not be either.  After a feature release is made from
"master", however, "next" will be rebuilt from the tip of "master"
using the topics that didn't make the cut in the feature release.

A natural consequence of how "next" and "pu" bundles topics together
is that until a topic is merged to "next", updates to it is expected
by replacing the patch(es) in the topic with an improved version,
and once a topic is merged to "next", updates to it needs to come as
incremental patches, pointing out what was wrong in the previous
patches and how the problem was corrected.

Note that being in "next" is not a guarantee to appear in the next
release, nor even in any future release.  There were cases that topics
needed reverting a few commits in them before graduating to "master",
or a topic that already was in "next" was reverted from "next" because
fatal flaws were found in it after it was merged to "next".


* Other people's trees.

Documentation/SubmittingPatches outlines to whom your proposed changes
should be sent.  As described in contrib/README, I would delegate fixes
and enhancements in contrib/ area to the primary contributors of them.

Although the following are included in git.git repository, they have their
own authoritative repository and maintainers:

 - git-gui/ comes from git-gui project, maintained by Pat Thoyts:

        git://repo.or.cz/git-gui.git

 - gitk-git/ comes from Paul Mackerras's gitk project:

        git://ozlabs.org/~paulus/gitk

 - po/ comes from the localization coordinator, Jiang Xin:

	https://github.com/git-l10n/git-po/

When sending proposed updates and fixes to these parts of the system,
please base your patches on these trees, not git.git (the former two
even have different directory structures).

A note from the maintainer

[Junio C Hamano]

Welcome to the Git development community.

This message is written by the maintainer and talks about how Git
project is managed, and how you can work with it.

* Mailing list and the community

The development is primarily done on the Git mailing list. Help
requests, feature proposals, bug reports and patches should be sent to
the list address <git@vger.kernel.org>.  You don't have to be
subscribed to send messages.  The convention on the list is to keep
everybody involved on Cc:, so it is unnecessary to say "Please Cc: me,
I am not subscribed".

Before sending patches, please read Documentation/SubmittingPatches
and Documentation/CodingGuidelines to familiarize yourself with the
project convention.

If you sent a patch and you did not hear any response from anybody for
several days, it could be that your patch was totally uninteresting,
but it also is possible that it was simply lost in the noise.  Please
do not hesitate to send a reminder message in such a case.  Messages
getting lost in the noise may be a sign that those who can evaluate
your patch don't have enough mental/time bandwidth to process them
right at the moment, and it often helps to wait until the list traffic
becomes calmer before sending such a reminder.

The list archive is available at a few public sites:

        http://public-inbox.org/git/
        http://marc.info/?l=git
        http://www.spinics.net/lists/git/

For those who prefer to read it over NNTP:

        nntp://news.public-inbox.org/inbox.comp.version-control.git
	nntp://news.gmane.org/gmane.comp.version-control.git

are available.

When you point at a message in a mailing list archive, using its
message ID is often the most robust (if not very friendly) way to do
so, like this:

	http://public-inbox.org/git/Pine.LNX.4.58.0504150753440.7211@ppc970.osdl.org

Often these web interfaces accept the message ID with enclosing <>
stripped (like the above example to point at one of the most important
message in the Git list).

Some members of the development community can sometimes be found on
the #git and #git-devel IRC channels on Freenode.  Their logs are
available at:

        http://colabti.org/irclogger/irclogger_log/git
        http://colabti.org/irclogger/irclogger_log/git-devel

There is a volunteer-run newsletter to serve our community ("Git Rev
News" http://git.github.io/rev_news/rev_news.html).

Git is a member project of software freedom conservancy, a non-profit
organization (https://sfconservancy.org/).  To reach a committee of
liaisons to the conservancy, contact them at <git@sfconservancy.org>.


* Reporting bugs

When you think git does not behave as you expect, please do not stop
your bug report with just "git does not work".  "I used git in this
way, but it did not work" is not much better, neither is "I used git
in this way, and X happend, which is broken".  It often is that git is
correct to cause X happen in such a case, and it is your expectation
that is broken. People would not know what other result Y you expected
to see instead of X, if you left it unsaid.

Please remember to always state

 - what you wanted to achieve;

 - what you did (the version of git and the command sequence to reproduce
   the behavior);

 - what you saw happen (X above);

 - what you expected to see (Y above); and

 - how the last two are different.

See http://www.chiark.greenend.org.uk/~sgtatham/bugs.html for further
hints.

If you think you found a security-sensitive issue and want to disclose
it to us without announcing it to wider public, please contact us at
our security mailing list <git-security@googlegroups.com>.  This is
a closed list that is limited to people who need to know early about
vulnerabilities, including:

  - people triaging and fixing reported vulnerabilities
  - people operating major git hosting sites with many users
  - people packaging and distributing git to large numbers of people

where these issues are discussed without risk of the information
leaking out before we're ready to make public announcements.


* Repositories and documentation.

My public git.git repositories are at:

  git://git.kernel.org/pub/scm/git/git.git/
  https://kernel.googlesource.com/pub/scm/git/git
  git://repo.or.cz/alt-git.git/
  https://github.com/git/git/
  git://git.sourceforge.jp/gitroot/git-core/git.git/
  git://git-core.git.sourceforge.net/gitroot/git-core/git-core/

This one shows not just the main integration branches, but also
individual topics broken out:

  git://github.com/gitster/git/

A few web interfaces are found at:

  http://git.kernel.org/cgit/git/git.git
  https://kernel.googlesource.com/pub/scm/git/git
  http://repo.or.cz/w/alt-git.git

Preformatted documentation from the tip of the "master" branch can be
found in:

  git://git.kernel.org/pub/scm/git/git-{htmldocs,manpages}.git/
  git://repo.or.cz/git-{htmldocs,manpages}.git/
  https://github.com/gitster/git-{htmldocs,manpages}.git/

The manual pages formatted in HTML for the tip of 'master' can be
viewed online at:

  https://git.github.io/htmldocs/git.html


* How various branches are used.

There are four branches in git.git repository that track the source tree
of git: "master", "maint", "next", and "pu".

The "master" branch is meant to contain what are very well tested and
ready to be used in a production setting.  Every now and then, a
"feature release" is cut from the tip of this branch.  They used to be
named with three dotted decimal digits (e.g. "1.8.5"), but recently we
switched the versioning scheme and "feature releases" are named with
three-dotted decimal digits that ends with ".0" (e.g. "1.9.0").

The last such release was 2.12 done on Feb 24th, 2017. You can expect
that the tip of the "master" branch is always more stable than any of
the released versions.

Whenever a feature release is made, "maint" branch is forked off from
"master" at that point.  Obvious and safe fixes after a feature
release are applied to this branch and maintenance releases are cut
from it.  Usually the fixes are merged to the "master" branch first,
several days before merged to the "maint" branch, to reduce the chance
of last-minute issues.  The maintenance releases used to be named with
four dotted decimal, named after the feature release they are updates
to (e.g. "1.8.5.1" was the first maintenance release for "1.8.5"
feature release).  These days, maintenance releases are named by
incrementing the last digit of three-dotted decimal name (e.g. "2.12.1"
was the first maintenance release for the "2.12" series).

New features never go to the 'maint' branch.  This branch is also
merged into "master" to propagate the fixes forward as needed.

A new development does not usually happen on "master". When you send a
series of patches, after review on the mailing list, a separate topic
branch is forked from the tip of "master" (or somewhere older, especially
when the topic is about fixing an earlier bug) and your patches are queued
there, and kept out of "master" while people test it out. The quality of
topic branches are judged primarily by the mailing list discussions.

Topic branches that are in good shape are merged to the "next" branch. In
general, the "next" branch always contains the tip of "master".  It might
not be quite rock-solid, but is expected to work more or less without major
breakage. The "next" branch is where new and exciting things take place. A
topic that is in "next" is expected to be polished to perfection before it
is merged to "master".  Please help this process by building & using the
"next" branch for your daily work, and reporting any new bugs you find to
the mailing list, before the breakage is merged down to the "master".

The "pu" (proposed updates) branch bundles all the remaining topic
branches the maintainer happens to have seen.  There is no guarantee that
the maintainer has enough bandwidth to pick up any and all topics that
are remotely promising from the list traffic, so please do not read
too much into a topic being on (or not on) the "pu" branch.  This
branch is mainly to remind the maintainer that the topics in them may
turn out to be interesting when they are polished, nothing more.  The
topics on this branch aren't usually complete, well tested, or well
documented and they often need further work.  When a topic that was
in "pu" proves to be in a testable shape, it is merged to "next".

You can run "git log --first-parent master..pu" to see what topics are
currently in flight.  Sometimes, an idea that looked promising turns out
to be not so good and the topic can be dropped from "pu" in such a case.
The output of the above "git log" talks about a "jch" branch, which is an
early part of the "pu" branch; that branch contains all topics that
are in "next" and a bit more (but not all of "pu") and is used by the
maintainer for his daily work.

The two branches "master" and "maint" are never rewound, and "next"
usually will not be either.  After a feature release is made from
"master", however, "next" will be rebuilt from the tip of "master"
using the topics that didn't make the cut in the feature release.

A natural consequence of how "next" and "pu" bundles topics together
is that until a topic is merged to "next", updates to it is expected
by replacing the patch(es) in the topic with an improved version,
and once a topic is merged to "next", updates to it needs to come as
incremental patches, pointing out what was wrong in the previous
patches and how the problem was corrected.

Note that being in "next" is not a guarantee to appear in the next
release, nor even in any future release.  There were cases that topics
needed reverting a few commits in them before graduating to "master",
or a topic that already was in "next" was reverted from "next" because
fatal flaws were found in it after it was merged to "next".


* Other people's trees.

Documentation/SubmittingPatches outlines to whom your proposed changes
should be sent.  As described in contrib/README, I would delegate fixes
and enhancements in contrib/ area to the primary contributors of them.

Although the following are included in git.git repository, they have their
own authoritative repository and maintainers:

 - git-gui/ comes from git-gui project, maintained by Pat Thoyts:

        git://repo.or.cz/git-gui.git

 - gitk-git/ comes from Paul Mackerras's gitk project:

        git://ozlabs.org/~paulus/gitk

 - po/ comes from the localization coordinator, Jiang Xin:

	https://github.com/git-l10n/git-po/

When sending proposed updates and fixes to these parts of the system,
please base your patches on these trees, not git.git (the former two
even have different directory structures).

A note from the maintainer

[Junio C Hamano]

Welcome to the Git development community.

This message is written by the maintainer and talks about how Git
project is managed, and how you can work with it.

* Mailing list and the community

The development is primarily done on the Git mailing list. Help
requests, feature proposals, bug reports and patches should be sent to
the list address <git@vger.kernel.org>.  You don't have to be
subscribed to send messages.  The convention on the list is to keep
everybody involved on Cc:, so it is unnecessary to say "Please Cc: me,
I am not subscribed".

Before sending patches, please read Documentation/SubmittingPatches
and Documentation/CodingGuidelines to familiarize yourself with the
project convention.

If you sent a patch and you did not hear any response from anybody for
several days, it could be that your patch was totally uninteresting,
but it also is possible that it was simply lost in the noise.  Please
do not hesitate to send a reminder message in such a case.  Messages
getting lost in the noise may be a sign that those who can evaluate
your patch don't have enough mental/time bandwidth to process them
right at the moment, and it often helps to wait until the list traffic
becomes calmer before sending such a reminder.

The list archive is available at a few public sites:

        http://public-inbox.org/git/
        http://marc.info/?l=git
        http://www.spinics.net/lists/git/

For those who prefer to read it over NNTP:

        nntp://news.public-inbox.org/inbox.comp.version-control.git
	nntp://news.gmane.org/gmane.comp.version-control.git

are available.

When you point at a message in a mailing list archive, using its
message ID is often the most robust (if not very friendly) way to do
so, like this:

	http://public-inbox.org/git/Pine.LNX.4.58.0504150753440.7211@ppc970.osdl.org

Often these web interfaces accept the message ID with enclosing <>
stripped (like the above example to point at one of the most important
message in the Git list).

Some members of the development community can sometimes be found on
the #git and #git-devel IRC channels on Freenode.  Their logs are
available at:

        http://colabti.org/irclogger/irclogger_log/git
        http://colabti.org/irclogger/irclogger_log/git-devel

There is a volunteer-run newsletter to serve our community ("Git Rev
News" http://git.github.io/rev_news/rev_news.html).

Git is a member project of software freedom conservancy, a non-profit
organization (https://sfconservancy.org/).  To reach a committee of
liaisons to the conservancy, contact them at <git@sfconservancy.org>.


* Reporting bugs

When you think git does not behave as you expect, please do not stop
your bug report with just "git does not work".  "I used git in this
way, but it did not work" is not much better, neither is "I used git
in this way, and X happend, which is broken".  It often is that git is
correct to cause X happen in such a case, and it is your expectation
that is broken. People would not know what other result Y you expected
to see instead of X, if you left it unsaid.

Please remember to always state

 - what you wanted to achieve;

 - what you did (the version of git and the command sequence to reproduce
   the behavior);

 - what you saw happen (X above);

 - what you expected to see (Y above); and

 - how the last two are different.

See http://www.chiark.greenend.org.uk/~sgtatham/bugs.html for further
hints.

If you think you found a security-sensitive issue and want to disclose
it to us without announcing it to wider public, please contact us at
our security mailing list <git-security@googlegroups.com>.  This is
a closed list that is limited to people who need to know early about
vulnerabilities, including:

  - people triaging and fixing reported vulnerabilities
  - people operating major git hosting sites with many users
  - people packaging and distributing git to large numbers of people

where these issues are discussed without risk of the information
leaking out before we're ready to make public announcements.


* Repositories and documentation.

My public git.git repositories are at:

  git://git.kernel.org/pub/scm/git/git.git/
  https://kernel.googlesource.com/pub/scm/git/git
  git://repo.or.cz/alt-git.git/
  https://github.com/git/git/
  git://git.sourceforge.jp/gitroot/git-core/git.git/
  git://git-core.git.sourceforge.net/gitroot/git-core/git-core/

A few web interfaces are found at:

  http://git.kernel.org/cgit/git/git.git
  https://kernel.googlesource.com/pub/scm/git/git
  http://repo.or.cz/w/alt-git.git

Preformatted documentation from the tip of the "master" branch can be
found in:

  git://git.kernel.org/pub/scm/git/git-{htmldocs,manpages}.git/
  git://repo.or.cz/git-{htmldocs,manpages}.git/
  https://github.com/gitster/git-{htmldocs,manpages}.git/

The manual pages formatted in HTML for the tip of 'master' can be
viewed online at:

  https://git.github.io/htmldocs/git.html


* How various branches are used.

There are four branches in git.git repository that track the source tree
of git: "master", "maint", "next", and "pu".

The "master" branch is meant to contain what are very well tested and
ready to be used in a production setting.  Every now and then, a
"feature release" is cut from the tip of this branch.  They used to be
named with three dotted decimal digits (e.g. "1.8.5"), but recently we
switched the versioning scheme and "feature releases" are named with
three-dotted decimal digits that ends with ".0" (e.g. "1.9.0").

The last such release was 2.12 done on Feb 24th, 2017. You can expect
that the tip of the "master" branch is always more stable than any of
the released versions.

Whenever a feature release is made, "maint" branch is forked off from
"master" at that point.  Obvious and safe fixes after a feature
release are applied to this branch and maintenance releases are cut
from it.  Usually the fixes are merged to the "master" branch first,
several days before merged to the "maint" branch, to reduce the chance
of last-minute issues.  The maintenance releases used to be named with
four dotted decimal, named after the feature release they are updates
to (e.g. "1.8.5.1" was the first maintenance release for "1.8.5"
feature release).  These days, maintenance releases are named by
incrementing the last digit of three-dotted decimal name (e.g. "2.11.1"
was the first maintenance release for the "2.11" series).

New features never go to the 'maint' branch.  This branch is also
merged into "master" to propagate the fixes forward as needed.

A new development does not usually happen on "master". When you send a
series of patches, after review on the mailing list, a separate topic
branch is forked from the tip of "master" and your patches are queued
there, and kept out of "master" while people test it out. The quality of
topic branches are judged primarily by the mailing list discussions.

Topic branches that are in good shape are merged to the "next" branch. In
general, the "next" branch always contains the tip of "master".  It might
not be quite rock-solid, but is expected to work more or less without major
breakage. The "next" branch is where new and exciting things take place. A
topic that is in "next" is expected to be polished to perfection before it
is merged to "master".  Please help this process by building & using the
"next" branch for your daily work, and reporting any new bugs you find to
the mailing list, before the breakage is merged down to the "master".

The "pu" (proposed updates) branch bundles all the remaining topic
branches the maintainer happens to have seen.  There is no guarantee that
the maintainer has enough bandwidth to pick up any and all topics that
are remotely promising from the list traffic, so please do not read
too much into a topic being on (or not on) the "pu" branch.  This
branch is mainly to remind the maintainer that the topics in them may
turn out to be interesting when they are polished, nothing more.  The
topics on this branch aren't usually complete, well tested, or well
documented and they often need further work.  When a topic that was
in "pu" proves to be in a testable shape, it is merged to "next".

You can run "git log --first-parent master..pu" to see what topics are
currently in flight.  Sometimes, an idea that looked promising turns out
to be not so good and the topic can be dropped from "pu" in such a case.
The output of the above "git log" talks about a "jch" branch, which is an
early part of the "pu" branch; that branch contains all topics that
are in "next" and a bit more (but not all of "pu") and is used by the
maintainer for his daily work.

The two branches "master" and "maint" are never rewound, and "next"
usually will not be either.  After a feature release is made from
"master", however, "next" will be rebuilt from the tip of "master"
using the topics that didn't make the cut in the feature release.

A natural consequence of how "next" and "pu" bundles topics together
is that until a topic is merged to "next", updates to it is expected
by replacing the patch(es) in the topic with an improved version,
and once a topic is merged to "next", updates to it needs to come as
incremental patches, pointing out what was wrong in the previous
patches and how the problem was corrected.

Note that being in "next" is not a guarantee to appear in the next
release, nor even in any future release.  There were cases that topics
needed reverting a few commits in them before graduating to "master",
or a topic that already was in "next" was reverted from "next" because
fatal flaws were found in it after it was merged to "next".


* Other people's trees.

Documentation/SubmittingPatches outlines to whom your proposed changes
should be sent.  As described in contrib/README, I would delegate fixes
and enhancements in contrib/ area to the primary contributors of them.

Although the following are included in git.git repository, they have their
own authoritative repository and maintainers:

 - git-gui/ comes from git-gui project, maintained by Pat Thoyts:

        git://repo.or.cz/git-gui.git

 - gitk-git/ comes from Paul Mackerras's gitk project:

        git://ozlabs.org/~paulus/gitk

 - po/ comes from the localization coordinator, Jiang Xin:

	https://github.com/git-l10n/git-po/

When sending proposed updates and fixes to these parts of the system,
please base your patches on these trees, not git.git (the former two
even have different directory structures).

A note from the maintainer

[Junio C Hamano]

Welcome to the Git development community.

This message is written by the maintainer and talks about how Git
project is managed, and how you can work with it.

* Mailing list and the community

The development is primarily done on the Git mailing list. Help
requests, feature proposals, bug reports and patches should be sent to
the list address <git@vger.kernel.org>.  You don't have to be
subscribed to send messages.  The convention on the list is to keep
everybody involved on Cc:, so it is unnecessary to say "Please Cc: me,
I am not subscribed".

Before sending patches, please read Documentation/SubmittingPatches
and Documentation/CodingGuidelines to familiarize yourself with the
project convention.

If you sent a patch and you did not hear any response from anybody for
several days, it could be that your patch was totally uninteresting,
but it also is possible that it was simply lost in the noise.  Please
do not hesitate to send a reminder message in such a case.  Messages
getting lost in the noise may be a sign that those who can evaluate
your patch don't have enough mental/time bandwidth to process them
right at the moment, and it often helps to wait until the list traffic
becomes calmer before sending such a reminder.

The list archive is available at a few public sites:

        http://public-inbox.org/git/
        http://marc.info/?l=git
        http://www.spinics.net/lists/git/

For those who prefer to read it over NNTP:

        nntp://news.public-inbox.org/inbox.comp.version-control.git
	nntp://news.gmane.org/gmane.comp.version-control.git

are available.

When you point at a message in a mailing list archive, using its
message ID is often the most robust (if not very friendly) way to do
so, like this:

	http://public-inbox.org/git/Pine.LNX.4.58.0504150753440.7211@ppc970.osdl.org

Often these web interfaces accept the message ID with enclosing <>
stripped (like the above example to point at one of the most important
message in the Git list).

Some members of the development community can sometimes be found on
the #git and #git-devel IRC channels on Freenode.  Their logs are
available at:

        http://colabti.org/irclogger/irclogger_log/git
        http://colabti.org/irclogger/irclogger_log/git-devel

There is a volunteer-run newsletter to serve our community ("Git Rev
News" http://git.github.io/rev_news/rev_news.html).

Git is a member project of software freedom conservancy, a non-profit
organization (https://sfconservancy.org/).  To reach a committee of
liaisons to the conservancy, contact them at <git@sfconservancy.org>.


* Reporting bugs

When you think git does not behave as you expect, please do not stop
your bug report with just "git does not work".  "I used git in this
way, but it did not work" is not much better, neither is "I used git
in this way, and X happend, which is broken".  It often is that git is
correct to cause X happen in such a case, and it is your expectation
that is broken. People would not know what other result Y you expected
to see instead of X, if you left it unsaid.

Please remember to always state

 - what you wanted to achieve;

 - what you did (the version of git and the command sequence to reproduce
   the behavior);

 - what you saw happen (X above);

 - what you expected to see (Y above); and

 - how the last two are different.

See http://www.chiark.greenend.org.uk/~sgtatham/bugs.html for further
hints.

If you think you found a security-sensitive issue and want to disclose
it to us without announcing it to wider public, please contact us at
our security mailing list <git-security@googlegroups.com>.  This is
a closed list that is limited to people who need to know early about
vulnerabilities, including:

  - people triaging and fixing reported vulnerabilities
  - people operating major git hosting sites with many users
  - people packaging and distributing git to large numbers of people

where these issues are discussed without risk of the information
leaking out before we're ready to make public announcements.


* Repositories and documentation.

My public git.git repositories are at:

  git://git.kernel.org/pub/scm/git/git.git/
  https://kernel.googlesource.com/pub/scm/git/git
  git://repo.or.cz/alt-git.git/
  https://github.com/git/git/
  git://git.sourceforge.jp/gitroot/git-core/git.git/
  git://git-core.git.sourceforge.net/gitroot/git-core/git-core/

A few web interfaces are found at:

  http://git.kernel.org/cgit/git/git.git
  https://kernel.googlesource.com/pub/scm/git/git
  http://repo.or.cz/w/alt-git.git

Preformatted documentation from the tip of the "master" branch can be
found in:

  git://git.kernel.org/pub/scm/git/git-{htmldocs,manpages}.git/
  git://repo.or.cz/git-{htmldocs,manpages}.git/
  https://github.com/gitster/git-{htmldocs,manpages}.git/

The manual pages formatted in HTML for the tip of 'master' can be
viewed online at:

  https://git.github.io/htmldocs/git.html


* How various branches are used.

There are four branches in git.git repository that track the source tree
of git: "master", "maint", "next", and "pu".

The "master" branch is meant to contain what are very well tested and
ready to be used in a production setting.  Every now and then, a
"feature release" is cut from the tip of this branch.  They used to be
named with three dotted decimal digits (e.g. "1.8.5"), but recently we
switched the versioning scheme and "feature releases" are named with
three-dotted decimal digits that ends with ".0" (e.g. "1.9.0").

The last such release was 2.11 done on Nov 29th, 2016. You can expect
that the tip of the "master" branch is always more stable than any of
the released versions.

Whenever a feature release is made, "maint" branch is forked off from
"master" at that point.  Obvious and safe fixes after a feature
release are applied to this branch and maintenance releases are cut
from it.  Usually the fixes are merged to the "master" branch first,
several days before merged to the "maint" branch, to reduce the chance
of last-minute issues.  The maintenance releases used to be named with
four dotted decimal, named after the feature release they are updates
to (e.g. "1.8.5.1" was the first maintenance release for "1.8.5"
feature release).  These days, maintenance releases are named by
incrementing the last digit of three-dotted decimal name (e.g. "2.10.2"
is the second maintenance release for the "2.10" series).

New features never go to the 'maint' branch.  This branch is also
merged into "master" to propagate the fixes forward as needed.

A new development does not usually happen on "master". When you send a
series of patches, after review on the mailing list, a separate topic
branch is forked from the tip of "master" and your patches are queued
there, and kept out of "master" while people test it out. The quality of
topic branches are judged primarily by the mailing list discussions.

Topic branches that are in good shape are merged to the "next" branch. In
general, the "next" branch always contains the tip of "master".  It might
not be quite rock-solid, but is expected to work more or less without major
breakage. The "next" branch is where new and exciting things take place. A
topic that is in "next" is expected to be polished to perfection before it
is merged to "master".  Please help this process by building & using the
"next" branch for your daily work, and reporting any new bugs you find to
the mailing list, before the breakage is merged down to the "master".

The "pu" (proposed updates) branch bundles all the remaining topic
branches the maintainer happens to have seen.  There is no guarantee that
the maintainer has enough bandwidth to pick up any and all topics that
are remotely promising from the list traffic, so please do not read
too much into a topic being on (or not on) the "pu" branch.  This
branch is mainly to remind the maintainer that the topics in them may
turn out to be interesting when they are polished, nothing more.  The
topics on this branch aren't usually complete, well tested, or well
documented and they often need further work.  When a topic that was
in "pu" proves to be in a testable shape, it is merged to "next".

You can run "git log --first-parent master..pu" to see what topics are
currently in flight.  Sometimes, an idea that looked promising turns out
to be not so good and the topic can be dropped from "pu" in such a case.
The output of the above "git log" talks about a "jch" branch, which is an
early part of the "pu" branch; that branch contains all topics that
are in "next" and a bit more (but not all of "pu") and is used by the
maintainer for his daily work.

The two branches "master" and "maint" are never rewound, and "next"
usually will not be either.  After a feature release is made from
"master", however, "next" will be rebuilt from the tip of "master"
using the topics that didn't make the cut in the feature release.

Note that being in "next" is not a guarantee to appear in the next
release, nor even in any future release.  There were cases that topics
needed reverting a few commits in them before graduating to "master",
or a topic that already was in "next" was reverted from "next" because
fatal flaws were found in it after it was merged to "next".


* Other people's trees.

Documentation/SubmittingPatches outlines to whom your proposed changes
should be sent.  As described in contrib/README, I would delegate fixes
and enhancements in contrib/ area to the primary contributors of them.

Although the following are included in git.git repository, they have their
own authoritative repository and maintainers:

 - git-gui/ comes from git-gui project, maintained by Pat Thoyts:

        git://repo.or.cz/git-gui.git

 - gitk-git/ comes from Paul Mackerras's gitk project:

        git://ozlabs.org/~paulus/gitk

 - po/ comes from the localization coordinator, Jiang Xin:

	https://github.com/git-l10n/git-po/

When sending proposed updates and fixes to these parts of the system,
please base your patches on these trees, not git.git (the former two
even have different directory structures).

A note from the maintainer

[Junio C Hamano]

Welcome to the Git development community.

This message is written by the maintainer and talks about how Git
project is managed, and how you can work with it.

* Mailing list and the community

The development is primarily done on the Git mailing list. Help
requests, feature proposals, bug reports and patches should be sent to
the list address <git@vger.kernel.org>.  You don't have to be
subscribed to send messages.  The convention on the list is to keep
everybody involved on Cc:, so it is unnecessary to say "Please Cc: me,
I am not subscribed".

Before sending patches, please read Documentation/SubmittingPatches
and Documentation/CodingGuidelines to familiarize yourself with the
project convention.

If you sent a patch and you did not hear any response from anybody for
several days, it could be that your patch was totally uninteresting,
but it also is possible that it was simply lost in the noise.  Please
do not hesitate to send a reminder message in such a case.  Messages
getting lost in the noise may be a sign that those who can evaluate
your patch don't have enough mental/time bandwidth to process them
right at the moment, and it often helps to wait until the list traffic
becomes calmer before sending such a reminder.

The list archive is available at a few public sites:

        http://public-inbox.org/git/
        http://marc.info/?l=git
        http://www.spinics.net/lists/git/

For those who prefer to read it over NNTP:

        nntp://news.public-inbox.org/inbox.comp.version-control.git
	nntp://news.gmane.org/gmane.comp.version-control.git

are available.

When you point at a message in a mailing list archive, using its
message ID is often the most robust (if not very friendly) way to do
so, like this:

	http://public-inbox.org/git/Pine.LNX.4.58.0504150753440.7211@ppc970.osdl.org

Often these web interfaces accept the message ID with enclosing <>
stripped (like the above example to point at one of the most important
message in the Git list).

Some members of the development community can sometimes be found on
the #git and #git-devel IRC channels on Freenode.  Their logs are
available at:

        http://colabti.org/irclogger/irclogger_log/git
        http://colabti.org/irclogger/irclogger_log/git-devel

There is a volunteer-run newsletter to serve our community ("Git Rev
News" http://git.github.io/rev_news/rev_news.html).

Git is a member project of software freedom conservancy, a non-profit
organization (https://sfconservancy.org/).  To reach a committee of
liaisons to the conservancy, contact them at <git@sfconservancy.org>.


* Reporting bugs

When you think git does not behave as you expect, please do not stop
your bug report with just "git does not work".  "I used git in this
way, but it did not work" is not much better, neither is "I used git
in this way, and X happend, which is broken".  It often is that git is
correct to cause X happen in such a case, and it is your expectation
that is broken. People would not know what other result Y you expected
to see instead of X, if you left it unsaid.

Please remember to always state

 - what you wanted to achieve;

 - what you did (the version of git and the command sequence to reproduce
   the behavior);

 - what you saw happen (X above);

 - what you expected to see (Y above); and

 - how the last two are different.

See http://www.chiark.greenend.org.uk/~sgtatham/bugs.html for further
hints.

If you think you found a security-sensitive issue and want to disclose
it to us without announcing it to wider public, please contact us at
our security mailing list <git-security@googlegroups.com>.  This is
a closed list that is limited to people who need to know early about
vulnerabilities, including:

  - people triaging and fixing reported vulnerabilities
  - people operating major git hosting sites with many users
  - people packaging and distributing git to large numbers of people

where these issues are discussed without risk of the information
leaking out before we're ready to make public announcements.


* Repositories and documentation.

My public git.git repositories are at:

  git://git.kernel.org/pub/scm/git/git.git/
  https://kernel.googlesource.com/pub/scm/git/git
  git://repo.or.cz/alt-git.git/
  https://github.com/git/git/
  git://git.sourceforge.jp/gitroot/git-core/git.git/
  git://git-core.git.sourceforge.net/gitroot/git-core/git-core/

A few web interfaces are found at:

  http://git.kernel.org/cgit/git/git.git
  https://kernel.googlesource.com/pub/scm/git/git
  http://repo.or.cz/w/alt-git.git

Preformatted documentation from the tip of the "master" branch can be
found in:

  git://git.kernel.org/pub/scm/git/git-{htmldocs,manpages}.git/
  git://repo.or.cz/git-{htmldocs,manpages}.git/
  https://github.com/gitster/git-{htmldocs,manpages}.git/

The manual pages formatted in HTML for the tip of 'master' can be
viewed online at:

  https://git.github.io/htmldocs/git.html


* How various branches are used.

There are four branches in git.git repository that track the source tree
of git: "master", "maint", "next", and "pu".

The "master" branch is meant to contain what are very well tested and
ready to be used in a production setting.  Every now and then, a
"feature release" is cut from the tip of this branch.  They used to be
named with three dotted decimal digits (e.g. "1.8.5"), but recently we
switched the versioning scheme and "feature releases" are named with
three-dotted decimal digits that ends with ".0" (e.g. "1.9.0").

The last such release was 2.10 done on Sep 2nd, 2016. You can expect
that the tip of the "master" branch is always more stable than any of
the released versions.

Whenever a feature release is made, "maint" branch is forked off from
"master" at that point.  Obvious and safe fixes after a feature
release are applied to this branch and maintenance releases are cut
from it.  Usually the fixes are merged to the "master" branch first,
several days before merged to the "maint" branch, to reduce the chance
of last-minute issues.  The maintenance releases used to be named with
four dotted decimal, named after the feature release they are updates
to (e.g. "1.8.5.1" was the first maintenance release for "1.8.5"
feature release).  These days, maintenance releases are named by
incrementing the last digit of three-dotted decimal name (e.g. "2.9.3"
is the third maintenance release for the "2.9" series).

New features never go to the 'maint' branch.  This branch is also
merged into "master" to propagate the fixes forward as needed.

A new development does not usually happen on "master". When you send a
series of patches, after review on the mailing list, a separate topic
branch is forked from the tip of "master" and your patches are queued
there, and kept out of "master" while people test it out. The quality of
topic branches are judged primarily by the mailing list discussions.

Topic branches that are in good shape are merged to the "next" branch. In
general, the "next" branch always contains the tip of "master".  It might
not be quite rock-solid, but is expected to work more or less without major
breakage. The "next" branch is where new and exciting things take place. A
topic that is in "next" is expected to be polished to perfection before it
is merged to "master".  Please help this process by building & using the
"next" branch for your daily work, and reporting any new bugs you find to
the mailing list, before the breakage is merged down to the "master".

The "pu" (proposed updates) branch bundles all the remaining topic
branches the maintainer happens to have seen.  There is no guarantee that
the maintainer has enough bandwidth to pick up any and all topics that
are remotely promising from the list traffic, so please do not read
too much into a topic being on (or not on) the "pu" branch.  This
branch is mainly to remind the maintainer that the topics in them may
turn out to be interesting when they are polished, nothing more.  The
topics on this branch aren't usually complete, well tested, or well
documented and they often need further work.  When a topic that was
in "pu" proves to be in a testable shape, it is merged to "next".

You can run "git log --first-parent master..pu" to see what topics are
currently in flight.  Sometimes, an idea that looked promising turns out
to be not so good and the topic can be dropped from "pu" in such a case.
The output of the above "git log" talks about a "jch" branch, which is an
early part of the "pu" branch; that branch contains all topics that
are in "next" and a bit more (but not all of "pu") and is used by the
maintainer for his daily work.

The two branches "master" and "maint" are never rewound, and "next"
usually will not be either.  After a feature release is made from
"master", however, "next" will be rebuilt from the tip of "master"
using the topics that didn't make the cut in the feature release.

Note that being in "next" is not a guarantee to appear in the next
release, nor even in any future release.  There were cases that topics
needed reverting a few commits in them before graduating to "master",
or a topic that already was in "next" was reverted from "next" because
fatal flaws were found in it after it was merged to "next".


* Other people's trees.

Documentation/SubmittingPatches outlines to whom your proposed changes
should be sent.  As described in contrib/README, I would delegate fixes
and enhancements in contrib/ area to the primary contributors of them.

Although the following are included in git.git repository, they have their
own authoritative repository and maintainers:

 - git-gui/ comes from git-gui project, maintained by Pat Thoyts:

        git://repo.or.cz/git-gui.git

 - gitk-git/ comes from Paul Mackerras's gitk project:

        git://ozlabs.org/~paulus/gitk

 - po/ comes from the localization coordinator, Jiang Xin:

	https://github.com/git-l10n/git-po/

When sending proposed updates and fixes to these parts of the system,
please base your patches on these trees, not git.git (the former two
even have different directory structures).

A note from the maintainer

[Junio C Hamano]

Welcome to the Git development community.

This message is written by the maintainer and talks about how Git
project is managed, and how you can work with it.

* Mailing list and the community

The development is primarily done on the Git mailing list. Help
requests, feature proposals, bug reports and patches should be sent to
the list address <git@vger.kernel.org>.  You don't have to be
subscribed to send messages.  The convention on the list is to keep
everybody involved on Cc:, so it is unnecessary to say "Please Cc: me,
I am not subscribed".

Before sending patches, please read Documentation/SubmittingPatches
and Documentation/CodingGuidelines to familiarize yourself with the
project convention.

If you sent a patch and you did not hear any response from anybody for
several days, it could be that your patch was totally uninteresting,
but it also is possible that it was simply lost in the noise.  Please
do not hesitate to send a reminder message in such a case.  Messages
getting lost in the noise may be a sign that those who can evaluate
your patch don't have enough mental/time bandwidth to process them
right at the moment, and it often helps to wait until the list traffic
becomes calmer before sending such a reminder.

The list archive is available at a few public sites:

        http://public-inbox.org/git/
        http://marc.info/?l=git
        http://www.spinics.net/lists/git/

For those who prefer to read it over NNTP:

	nntp://news.gmane.org/gmane.comp.version-control.git
        nntp://news.public-inbox.org/inbox.comp.version-control.git

are available.

When you point at a message in a mailing list archive, using its
message ID is often the most robust (if not very friendly) way to do
so, like this:

	http://public-inbox.org/git/Pine.LNX.4.58.0504150753440.7211@ppc970.osdl.org

Often these web interfaces accept the message ID with enclosing <>
stripped (like the above example to point at one of the most important
message in the Git list).

Some members of the development community can sometimes be found on
the #git and #git-devel IRC channels on Freenode.  Their logs are
available at:

        http://colabti.org/irclogger/irclogger_log/git
        http://colabti.org/irclogger/irclogger_log/git-devel

There is a volunteer-run newsletter to serve our community ("Git Rev
News" http://git.github.io/rev_news/rev_news.html).

Git is a member project of software freedom conservancy, a non-profit
organization (https://sfconservancy.org/).  To reach a committee of
liaisons to the conservancy, contact them at <git@sfconservancy.org>.


* Reporting bugs

When you think git does not behave as you expect, please do not stop
your bug report with just "git does not work".  "I used git in this
way, but it did not work" is not much better, neither is "I used git
in this way, and X happend, which is broken".  It often is that git is
correct to cause X happen in such a case, and it is your expectation
that is broken. People would not know what other result Y you expected
to see instead of X, if you left it unsaid.

Please remember to always state

 - what you wanted to achieve;

 - what you did (the version of git and the command sequence to reproduce
   the behavior);

 - what you saw happen (X above);

 - what you expected to see (Y above); and

 - how the last two are different.

See http://www.chiark.greenend.org.uk/~sgtatham/bugs.html for further
hints.

If you think you found a security-sensitive issue and want to disclose
it to us without announcing it to wider public, please contact us at
our security mailing list <git-security@googlegroups.com>.  This is
a closed list that is limited to people who need to know early about
vulnerabilities, including:

  - people triaging and fixing reported vulnerabilities
  - people operating major git hosting sites with many users
  - people packaging and distributing git to large numbers of people

where these issues are discussed without risk of the information
leaking out before we're ready to make public announcements.


* Repositories and documentation.

My public git.git repositories are at:

  git://git.kernel.org/pub/scm/git/git.git/
  https://kernel.googlesource.com/pub/scm/git/git
  git://repo.or.cz/alt-git.git/
  https://github.com/git/git/
  git://git.sourceforge.jp/gitroot/git-core/git.git/
  git://git-core.git.sourceforge.net/gitroot/git-core/git-core/

A few web interfaces are found at:

  http://git.kernel.org/cgit/git/git.git
  https://kernel.googlesource.com/pub/scm/git/git
  http://repo.or.cz/w/alt-git.git

Preformatted documentation from the tip of the "master" branch can be
found in:

  git://git.kernel.org/pub/scm/git/git-{htmldocs,manpages}.git/
  git://repo.or.cz/git-{htmldocs,manpages}.git/
  https://github.com/gitster/git-{htmldocs,manpages}.git/

The manual pages formatted in HTML for the tip of 'master' can be
viewed online at:

  https://git.github.io/htmldocs/git.html


* How various branches are used.

There are four branches in git.git repository that track the source tree
of git: "master", "maint", "next", and "pu".

The "master" branch is meant to contain what are very well tested and
ready to be used in a production setting.  Every now and then, a
"feature release" is cut from the tip of this branch.  They used to be
named with three dotted decimal digits (e.g. "1.8.5"), but recently we
switched the versioning scheme and "feature releases" are named with
three-dotted decimal digits that ends with ".0" (e.g. "1.9.0").

The last such release was 2.10 done on Sep 2nd, 2016. You can expect
that the tip of the "master" branch is always more stable than any of
the released versions.

Whenever a feature release is made, "maint" branch is forked off from
"master" at that point.  Obvious and safe fixes after a feature
release are applied to this branch and maintenance releases are cut
from it.  Usually the fixes are merged to the "master" branch first,
several days before merged to the "maint" branch, to reduce the chance
of last-minute issues.  The maintenance releases used to be named with
four dotted decimal, named after the feature release they are updates
to (e.g. "1.8.5.1" was the first maintenance release for "1.8.5"
feature release).  These days, maintenance releases are named by
incrementing the last digit of three-dotted decimal name (e.g. "2.9.3"
is the third maintenance release for the "2.9" series).

New features never go to the 'maint' branch.  This branch is also
merged into "master" to propagate the fixes forward as needed.

A new development does not usually happen on "master". When you send a
series of patches, after review on the mailing list, a separate topic
branch is forked from the tip of "master" and your patches are queued
there, and kept out of "master" while people test it out. The quality of
topic branches are judged primarily by the mailing list discussions.

Topic branches that are in good shape are merged to the "next" branch. In
general, the "next" branch always contains the tip of "master".  It might
not be quite rock-solid, but is expected to work more or less without major
breakage. The "next" branch is where new and exciting things take place. A
topic that is in "next" is expected to be polished to perfection before it
is merged to "master".  Please help this process by building & using the
"next" branch for your daily work, and reporting any new bugs you find to
the mailing list, before the breakage is merged down to the "master".

The "pu" (proposed updates) branch bundles all the remaining topic
branches the maintainer happens to have seen.  There is no guarantee that
the maintainer has enough bandwidth to pick up any and all topics that
are remotely promising from the list traffic, so please do not read
too much into a topic being on (or not on) the "pu" branch.  This
branch is mainly to remind the maintainer that the topics in them may
turn out to be interesting when they are polished, nothing more.  The
topics on this branch aren't usually complete, well tested, or well
documented and they often need further work.  When a topic that was
in "pu" proves to be in a testable shape, it is merged to "next".

You can run "git log --first-parent master..pu" to see what topics are
currently in flight.  Sometimes, an idea that looked promising turns out
to be not so good and the topic can be dropped from "pu" in such a case.

The two branches "master" and "maint" are never rewound, and "next"
usually will not be either.  After a feature release is made from
"master", however, "next" will be rebuilt from the tip of "master"
using the topics that didn't make the cut in the feature release.

Note that being in "next" is not a guarantee to appear in the next
release, nor even in any future release.  There were cases that topics
needed reverting a few commits in them before graduating to "master",
or a topic that already was in "next" was reverted from "next" because
fatal flaws were found in it after it was merged to "next".


* Other people's trees.

Documentation/SubmittingPatches outlines to whom your proposed changes
should be sent.  As described in contrib/README, I would delegate fixes
and enhancements in contrib/ area to the primary contributors of them.

Although the following are included in git.git repository, they have their
own authoritative repository and maintainers:

 - git-gui/ comes from git-gui project, maintained by Pat Thoyts:

        git://repo.or.cz/git-gui.git

 - gitk-git/ comes from Paul Mackerras's gitk project:

        git://ozlabs.org/~paulus/gitk

 - po/ comes from the localization coordinator, Jiang Xin:

	https://github.com/git-l10n/git-po/

When sending proposed updates and fixes to these parts of the system,
please base your patches on these trees, not git.git (the former two
even have different directory structures).

Re: A note from the maintainer

[Jakub Narębski]

W dniu 03.09.2016 o 04:17, Junio C Hamano pisze:

> Please remember to always state
> 
>  - what you wanted to achieve;
> 
>  - what you did (the version of git and the command sequence to reproduce
>    the behavior);

I wonder if it be worth adding to not use aliases (or expand them).  I have
seen quite a few such questions on StackOverflow...

> 
>  - what you saw happen (X above);
> 
>  - what you expected to see (Y above); and
> 
>  - how the last two are different.

Re: A note from the maintainer

[Junio C Hamano]

Jakub Narębski <jnareb@gmail.com> writes:

> W dniu 03.09.2016 o 04:17, Junio C Hamano pisze:
>
>> Please remember to always state
>> 
>>  - what you wanted to achieve;
>> 
>>  - what you did (the version of git and the command sequence to reproduce
>>    the behavior);
>
> I wonder if it be worth adding to not use aliases (or expand them).  I have
> seen quite a few such questions on StackOverflow...

    - how others can reproduce what you did (the version of git and
      the command sequence);

perhaps?

>> 
>>  - what you saw happen (X above);
>> 
>>  - what you expected to see (Y above); and
>> 
>>  - how the last two are different.

A note from the maintainer

[Junio C Hamano]

Welcome to the Git development community.

This message is written by the maintainer and talks about how Git
project is managed, and how you can work with it.

* Mailing list and the community

The development is primarily done on the Git mailing list. Help
requests, feature proposals, bug reports and patches should be sent to
the list address <git@vger.kernel.org>.  You don't have to be
subscribed to send messages.  The convention on the list is to keep
everybody involved on Cc:, so it is unnecessary to say "Please Cc: me,
I am not subscribed".

Before sending patches, please read Documentation/SubmittingPatches
and Documentation/CodingGuidelines to familiarize yourself with the
project convention.

If you sent a patch and you did not hear any response from anybody for
several days, it could be that your patch was totally uninteresting,
but it also is possible that it was simply lost in the noise.  Please
do not hesitate to send a reminder message in such a case.  Messages
getting lost in the noise may be a sign that those who can evaluate
your patch don't have enough mental/time bandwidth to process them
right at the moment, and it often helps to wait until the list traffic
becomes calmer before sending such a reminder.

The list archive is available at a few public sites:

        http://public-inbox.org/git/
        http://marc.info/?l=git
        http://www.spinics.net/lists/git/

For those who prefer to read it over NNTP:

	nntp://news.gmane.org/gmane.comp.version-control.git

is still available.  An alternative

        nntp://news.public-inbox.org/inbox.comp.version-control.git

will become usable once it catches up with old messages.

When you point at a message in a mailing list archive, using its
message ID is often the most robust (if not very friendly) way to do
so, like this:

	http://public-inbox.org/git/Pine.LNX.4.58.0504150753440.7211@ppc970.osdl.org

Often these web interfaces accept the message ID with enclosing <>
stripped (like the above example to point at one of the most important
message in the Git list).

Some members of the development community can sometimes be found on
the #git and #git-devel IRC channels on Freenode.  Their logs are
available at:

        http://colabti.org/irclogger/irclogger_log/git
        http://colabti.org/irclogger/irclogger_log/git-devel

There is a volunteer-run newsletter to serve our community ("Git Rev
News" http://git.github.io/rev_news/rev_news.html).

Git is a member project of software freedom conservancy, a non-profit
organization (https://sfconservancy.org/).  To reach a committee of
liaisons to the conservancy, contact them at <git@sfconservancy.org>.


* Reporting bugs

When you think git does not behave as you expect, please do not stop
your bug report with just "git does not work".  "I used git in this
way, but it did not work" is not much better, neither is "I used git
in this way, and X happend, which is broken".  It often is that git is
correct to cause X happen in such a case, and it is your expectation
that is broken. People would not know what other result Y you expected
to see instead of X, if you left it unsaid.

Please remember to always state

 - what you wanted to achieve;

 - what you did (the version of git and the command sequence to reproduce
   the behavior);

 - what you saw happen (X above);

 - what you expected to see (Y above); and

 - how the last two are different.

See http://www.chiark.greenend.org.uk/~sgtatham/bugs.html for further
hints.

If you think you found a security-sensitive issue and want to disclose
it to us without announcing it to wider public, please contact us at
our security mailing list <git-security@googlegroups.com>.  This is
a closed list that is limited to people who need to know early about
vulnerabilities, including:

  - people triaging and fixing reported vulnerabilities
  - people operating major git hosting sites with many users
  - people packaging and distributing git to large numbers of people

where these issues are discussed without risk of the information
leaking out before we're ready to make public announcements.


* Repositories and documentation.

My public git.git repositories are at:

  git://git.kernel.org/pub/scm/git/git.git/
  https://kernel.googlesource.com/pub/scm/git/git
  git://repo.or.cz/alt-git.git/
  https://github.com/git/git/
  git://git.sourceforge.jp/gitroot/git-core/git.git/
  git://git-core.git.sourceforge.net/gitroot/git-core/git-core/

A few web interfaces are found at:

  http://git.kernel.org/cgit/git/git.git
  https://kernel.googlesource.com/pub/scm/git/git
  http://repo.or.cz/w/alt-git.git

Preformatted documentation from the tip of the "master" branch can be
found in:

  git://git.kernel.org/pub/scm/git/git-{htmldocs,manpages}.git/
  git://repo.or.cz/git-{htmldocs,manpages}.git/
  https://github.com/gitster/git-{htmldocs,manpages}.git/

The manual pages formatted in HTML for the tip of 'master' can be
viewed online at:

  https://git.github.io/htmldocs/git.html


* How various branches are used.

There are four branches in git.git repository that track the source tree
of git: "master", "maint", "next", and "pu".

The "master" branch is meant to contain what are very well tested and
ready to be used in a production setting.  Every now and then, a
"feature release" is cut from the tip of this branch.  They used to be
named with three dotted decimal digits (e.g. "1.8.5"), but recently we
switched the versioning scheme and "feature releases" are named with
three-dotted decimal digits that ends with ".0" (e.g. "1.9.0").

The last such release was 2.9 done on June 13th, 2016. You can expect
that the tip of the "master" branch is always more stable than any of
the released versions.

Whenever a feature release is made, "maint" branch is forked off from
"master" at that point.  Obvious and safe fixes after a feature
release are applied to this branch and maintenance releases are cut
from it.  Usually the fixes are merged to the "master" branch first,
several days before merged to the "maint" branch, to reduce the chance
of last-minute issues.  The maintenance releases used to be named with
four dotted decimal, named after the feature release they are updates
to (e.g. "1.8.5.1" was the first maintenance release for "1.8.5"
feature release).  These days, maintenance releases are named by
incrementing the last digit of three-dotted decimal name (e.g. "2.9.3"
is the third maintenance release for the "2.9" series).

New features never go to the 'maint' branch.  This branch is also
merged into "master" to propagate the fixes forward as needed.

A new development does not usually happen on "master". When you send a
series of patches, after review on the mailing list, a separate topic
branch is forked from the tip of "master" and your patches are queued
there, and kept out of "master" while people test it out. The quality of
topic branches are judged primarily by the mailing list discussions.

Topic branches that are in good shape are merged to the "next" branch. In
general, the "next" branch always contains the tip of "master".  It might
not be quite rock-solid, but is expected to work more or less without major
breakage. The "next" branch is where new and exciting things take place. A
topic that is in "next" is expected to be polished to perfection before it
is merged to "master".  Please help this process by building & using the
"next" branch for your daily work, and reporting any new bugs you find to
the mailing list, before the breakage is merged down to the "master".

The "pu" (proposed updates) branch bundles all the remaining topic
branches the maintainer happens to have seen.  There is no guarantee that
the maintainer has enough bandwidth to pick up any and all topics that
are remotely promising from the list traffic, so please do not read
too much into a topic being on (or not on) the "pu" branch.  This
branch is mainly to remind the maintainer that the topics in them may
turn out to be interesting when they are polished, nothing more.  The
topics on this branch aren't usually complete, well tested, or well
documented and they often need further work.  When a topic that was
in "pu" proves to be in a testable shape, it is merged to "next".

You can run "git log --first-parent master..pu" to see what topics are
currently in flight.  Sometimes, an idea that looked promising turns out
to be not so good and the topic can be dropped from "pu" in such a case.

The two branches "master" and "maint" are never rewound, and "next"
usually will not be either.  After a feature release is made from
"master", however, "next" will be rebuilt from the tip of "master"
using the topics that didn't make the cut in the feature release.

Note that being in "next" is not a guarantee to appear in the next
release, nor even in any future release.  There were cases that topics
needed reverting a few commits in them before graduating to "master",
or a topic that already was in "next" was reverted from "next" because
fatal flaws were found in it after it was merged to "next".


* Other people's trees.

Documentation/SubmittingPatches outlines to whom your proposed changes
should be sent.  As described in contrib/README, I would delegate fixes
and enhancements in contrib/ area to the primary contributors of them.

Although the following are included in git.git repository, they have their
own authoritative repository and maintainers:

 - git-gui/ comes from git-gui project, maintained by Pat Thoyts:

        git://repo.or.cz/git-gui.git

 - gitk-git/ comes from Paul Mackerras's gitk project:

        git://ozlabs.org/~paulus/gitk

 - po/ comes from the localization coordinator, Jiang Xin:

	https://github.com/git-l10n/git-po/

When sending proposed updates and fixes to these parts of the system,
please base your patches on these trees, not git.git (the former two
even have different directory structures).

Re: A note from the maintainer

[Eric Wong]

Junio C Hamano <gitster@pobox.com> wrote:
> For those who prefer to read it over NNTP:
> 
> 	nntp://news.gmane.org/gmane.comp.version-control.git
> 
> is still available.  An alternative
> 
>         nntp://news.public-inbox.org/inbox.comp.version-control.git
> 
> will become usable once it catches up with old messages.

Mostly caught up, I injected 33 more today which were
cross-posted (which tripped up some of my anti-spam rules) or
simply missed by gmane.

There may be more in some personal archives gmane doesn't
have...

I've also added NNTP links (including gmane) to the footer in
public-inbox.org/git

> message ID is often the most robust (if not very friendly) way to do
> so, like this:
> 
> 	http://public-inbox.org/git/Pine.LNX.4.58.0504150753440.7211@ppc970.osdl.org

Some of the generated links have %40 in them which is the URI
escape for '@'.  I'll make a change to keep the '@' unescaped to
lessen confusion.

Due to the use of SQLite as a stable store for NNTP article
numbers; public-inbox can also do partial matching (up to 100
results, currently) to help correct legitimate mistakes; but I
wouldn't rely on it too much:

	public-inbox.org/git/Pine.LNX.4.58.0504150753440

Re: A note from the maintainer

[Jeff King]

On Fri, Aug 12, 2016 at 10:42:55PM +0000, Eric Wong wrote:

> Junio C Hamano <gitster@pobox.com> wrote:
> > For those who prefer to read it over NNTP:
> > 
> > 	nntp://news.gmane.org/gmane.comp.version-control.git
> > 
> > is still available.  An alternative
> > 
> >         nntp://news.public-inbox.org/inbox.comp.version-control.git
> > 
> > will become usable once it catches up with old messages.
> 
> Mostly caught up, I injected 33 more today which were
> cross-posted (which tripped up some of my anti-spam rules) or
> simply missed by gmane.
> 
> There may be more in some personal archives gmane doesn't
> have...

Is there an easy way to get _just_ the list of message-ids you are
storing (I know I can download the whole archive, but it's big)?

Then I can cross-reference with my archive. I doubt I'll have anything
significant that you don't. My archive of the early days was pulled from
gmane, though I have been collecting steadily via mailing list delivery
since 2007 or so.

-Peff

Re: A note from the maintainer

[Eric Wong]

Jeff King <peff@peff.net> wrote:
> On Fri, Aug 12, 2016 at 10:42:55PM +0000, Eric Wong wrote:
> > Junio C Hamano <gitster@pobox.com> wrote:
> > > is still available.  An alternative
> > > 
> > >         nntp://news.public-inbox.org/inbox.comp.version-control.git
> > > 
> > > will become usable once it catches up with old messages.
> > 
> > Mostly caught up, I injected 33 more today which were
> > cross-posted (which tripped up some of my anti-spam rules) or
> > simply missed by gmane.
> > 
> > There may be more in some personal archives gmane doesn't
> > have...
> 
> Is there an easy way to get _just_ the list of message-ids you are
> storing (I know I can download the whole archive, but it's big)?

XHDR (or HDR) over NNTP should do it (that's how I checked
against gmane):
--------8<-----
use Net::NNTP;
my $nntp = Net::NNTP->new($ENV{NNTPSERVER} || 'news.public-inbox.org');
my ($num, $first, $last) = $nntp->group('inbox.comp.version-control.git');
my $batch = 10000;
my $i;
for ($i = $first; $i < $last; $i += $batch) {
	my $j = $i + $batch - 1;
	$j = $last if $j > $last;
	my $num2mid = $nntp->xhdr('Message-ID', "$i-$j");
	for my $n ($i..$j) {
		defined(my $mid = $num2mid->{$n}) or next;
		print "$mid\n";
	}
}

# and I forgot to optimize XHDR/HDR further in public-inbox-nntpd.
# Oh well, it seems to work, at least.

> Then I can cross-reference with my archive. I doubt I'll have anything
> significant that you don't. My archive of the early days was pulled from
> gmane, though I have been collecting steadily via mailing list delivery
> since 2007 or so.

What's odd is there's some messages with two Message-ID fields
from gmane from the old days, too.  I'll dig a bit another time.

Re: A note from the maintainer

[Jeff King]

On Sat, Aug 13, 2016 at 09:04:32AM +0000, Eric Wong wrote:

> > Is there an easy way to get _just_ the list of message-ids you are
> > storing (I know I can download the whole archive, but it's big)?
> 
> XHDR (or HDR) over NNTP should do it (that's how I checked
> against gmane):
> --------8<-----
> use Net::NNTP;
> my $nntp = Net::NNTP->new($ENV{NNTPSERVER} || 'news.public-inbox.org');
> my ($num, $first, $last) = $nntp->group('inbox.comp.version-control.git');
> my $batch = 10000;
> my $i;
> for ($i = $first; $i < $last; $i += $batch) {
> 	my $j = $i + $batch - 1;
> 	$j = $last if $j > $last;
> 	my $num2mid = $nntp->xhdr('Message-ID', "$i-$j");
> 	for my $n ($i..$j) {
> 		defined(my $mid = $num2mid->{$n}) or next;
> 		print "$mid\n";
> 	}
> }

Thanks, that's perfect.

I collected the message-ids from my archive. Interestingly, I had a
dozen or so that did not have message-ids at all. I think most of them
are from patches that put the "From " line in the body, like this one:

  http://public-inbox.org/git/20070311033833.GB10781@spearce.org/

and then they got corrupted on a round-trip through one of the bad mbox
formats (probably downloading from gmane, I'd guess; the export there
uses mbox, and I use maildir myself, so it probably got split badly
years ago). Anyway, public-inbox seems to get this case right, which is
good.

I had several hundred message ids that you didn't. About half of them
were spam or other junk. I weeded them out manually (mostly by picking
through the subjects, so possibly there's some error). The end result is
279 messages that I think are legitimate that you don't have.

I'll send them to you off-list, as the mbox is about 300K, which the
list will reject.

-Peff

Re: A note from the maintainer

[Eric Wong]

Jeff King <peff@peff.net> wrote:
> I collected the message-ids from my archive. Interestingly, I had a
> dozen or so that did not have message-ids at all. I think most of them
> are from patches that put the "From " line in the body, like this one:
> 
>   http://public-inbox.org/git/20070311033833.GB10781@spearce.org/
> 
> and then they got corrupted on a round-trip through one of the bad mbox
> formats (probably downloading from gmane, I'd guess; the export there
> uses mbox, and I use maildir myself, so it probably got split badly
> years ago). Anyway, public-inbox seems to get this case right, which is
> good.

Yes, I was somewhat careful to check for proper mboxes from gmane;
I just missed entire ranges :x

What's also interesting about the thread you highlighed is the
extra '<>' when you started that thread; and I have a bug where
I strip off an extra '>' which needs to be fixed...

I wonder if I should make "editorial" changes to fixup user bugs,
but then there's also bunch of messages which are replies to <y>
because git-send-email had usability problems back in the day...

> I had several hundred message ids that you didn't. About half of them
> were spam or other junk. I weeded them out manually (mostly by picking
> through the subjects, so possibly there's some error). The end result is
> 279 messages that I think are legitimate that you don't have.
> 
> I'll send them to you off-list, as the mbox is about 300K, which the
> list will reject.

Thanks, should all be imported.

The one which started the thread belonging to
<loom.20100716T103549-783@post.gmane.org> was really iffy,
but I kept it; as well as an "unsubscribe" one; I guess those
people are shamed for life :)


  git cat-file blob HEAD:b7/5bb577d76487bc9aebf0656d4e03eff22049f4

is totally legit, but doesn't seem to show up properly,
so there's another bug I need to fix.  For the moment, the
following also works:

	public-inbox.org/git/b75bb577d76487bc9aebf0656d4e03eff22049f4/
(but I guess it was reposted as <26299.4828321554$1213013668@news.gmane.org>

Re: A note from the maintainer

[Eric Wong]

Eric Wong <e@80x24.org> wrote:
> Thanks, should all be imported.

Oops, missed one which was missing X-Mailing-List (causing
it to not get imported) and had "X-No-Archive: yes" set;
which meant I couldn't get it from gmane this year.

Hmm... XNAY defeats the point of public-inbox (and probably the
point of public-to-all mailing lists); so I don't think it's
worth honoring.

Re: A note from the maintainer

[Jeff King]

On Sun, Aug 14, 2016 at 02:12:34AM +0000, Eric Wong wrote:

> Eric Wong <e@80x24.org> wrote:
> > Thanks, should all be imported.
> 
> Oops, missed one which was missing X-Mailing-List (causing
> it to not get imported) and had "X-No-Archive: yes" set;
> which meant I couldn't get it from gmane this year.
> 
> Hmm... XNAY defeats the point of public-inbox (and probably the
> point of public-to-all mailing lists); so I don't think it's
> worth honoring.

I didn't even think to look for that header. It looks like it's
basically all one guy. I would argue that it should not be honored for
the git dev list, if only because those emails are a record of the
provenance of patches. The Signed-off-by is a certification that the
patch is OK to submit, but it's presumably worth more with an audit
trail including the email headers.

(Also, I have always found it a little silly to post publicly with a
"please don't anybody record this!" header).

-Peff

Re: A note from the maintainer

[Jeff King]

On Sun, Aug 14, 2016 at 01:27:06AM +0000, Eric Wong wrote:

> What's also interesting about the thread you highlighed is the
> extra '<>' when you started that thread; and I have a bug where
> I strip off an extra '>' which needs to be fixed...

Oh, that's interesting. It's not in the message that started the thread;
the bug is in the in-reply-to headers of the patches themselves. I don't
remember what I was using to send patches back then. It might have been
send-email, and I suspect I did:

  git send-email --in-reply-to='<whatever>'

after cutting-and-pasting '<whatever>' from the cover letter.

> I wonder if I should make "editorial" changes to fixup user bugs,
> but then there's also bunch of messages which are replies to <y>
> because git-send-email had usability problems back in the day...

I wouldn't go too far in editorial changes. I made a few when skimming
the messages I just sent for spam, and dropped some empty messages, or
"unsubscribe me" ones. But it's not worth the human effort to go back
and scrub list archives from 10 years ago.

Fixing up an extra "<>" is easily done once in your parsing scripts,
though, and I'd be surprised if I'm the only one to have made that
mistake.

> The one which started the thread belonging to
> <loom.20100716T103549-783@post.gmane.org> was really iffy,

I think I exercised editorial control over similar "your software is now
listed in our archive!" messages in what I sent. But yeah, there's going
to be some spam and some cruft in the archive. It's just a fact of life.
The solution is good searching and organizing tools to find the signal
you're looking for, not to make sure the noise hits zero.

>   git cat-file blob HEAD:b7/5bb577d76487bc9aebf0656d4e03eff22049f4
> 
> is totally legit, but doesn't seem to show up properly,

Heh, yeah, I saw that one (and I think it broke some of my initial
scripting, which foolishly assumed nobody had message-ids with spaces in
them).

-Peff

Re: A note from the maintainer

[Philip Oakley]

From: "Eric Wong" <e@80x24.org>
>
> Yes, I was somewhat careful to check for proper mboxes from gmane;
> I just missed entire ranges :x
>

There were a number of messages that were listed by gmane as being in the 
various Git for Windows lists such as msysgit, especially when the messages 
went to both lists (as the issue had common cause) that failed to get onto 
the regualr gmane list.

Are these something that has been included?

Philip

A quick search on a possible message gave 
https://public-inbox.org/git/55BF6808.1000500@web.de/ which has no parent, 
but that parent actually only went to the msysgit list, so no real surprise 
there, but I do remember some other cases that were on list - I just can't 
find them at the moment :-(.

Re: A note from the maintainer

[Eric Wong]

Philip Oakley <philipoakley@iee.org> wrote:
> From: "Eric Wong" <e@80x24.org>
> >
> >Yes, I was somewhat careful to check for proper mboxes from gmane;
> >I just missed entire ranges :x
> >
> 
> There were a number of messages that were listed by gmane as being in the
> various Git for Windows lists such as msysgit, especially when the messages
> went to both lists (as the issue had common cause) that failed to get onto
> the regualr gmane list.
> 
> Are these something that has been included?

If they were on both lists, yes, gmane seems to miss some of
those messages, unfortunately.

> Philip
> 
> A quick search on a possible message gave
> https://public-inbox.org/git/55BF6808.1000500@web.de/ which has no parent,
> but that parent actually only went to the msysgit list, so no real surprise
> there, but I do remember some other cases that were on list - I just can't
> find them at the moment :-(.

If a message was only posted exclusively on other lists, it
should stay there and it's archives.  public-inbox provides a
way to lookup external messages by Message-ID for this reason.

Is there a way to lookup messages by Message-ID from the msysgit
archives?  I could add it to the existing list of alternate
Message-ID lookup services:

  https://public-inbox.org/meta/20160814054731.26194-1-e@80x24.org/

GoogleGroups doesn't seem usable without JavaScript at all,
unfortunately :<

I don't think the msysgit archives would be too large and I
wouldn't mind hosting them myself.  But, users on GoogleGroups
may not be used to our conventions and not appreciate having
their unobfuscated addresses exposed or reply-to-all...

I will probably add an option to support centralized lists to
public-inbox sometime, though.  I don't like centralization,
but completely inaccessible archives are worse.

A note from the maintainer

[Junio C Hamano]

Welcome to the Git development community.

This message is written by the maintainer and talks about how Git
project is managed, and how you can work with it.

* Mailing list and the community

The development is primarily done on the Git mailing list. Help
requests, feature proposals, bug reports and patches should be sent to
the list address <git@vger.kernel.org>.  You don't have to be
subscribed to send messages.  The convention on the list is to keep
everybody involved on Cc:, so it is unnecessary to say "Please Cc: me,
I am not subscribed".

Before sending patches, please read Documentation/SubmittingPatches
and Documentation/CodingGuidelines to familiarize yourself with the
project convention.

If you sent a patch and you did not hear any response from anybody for
several days, it could be that your patch was totally uninteresting,
but it also is possible that it was simply lost in the noise.  Please
do not hesitate to send a reminder message in such a case.  Messages
getting lost in the noise may be a sign that those who can evaluate
your patch don't have enough mental/time bandwidth to process them
right at the moment, and it often helps to wait until the list traffic
becomes calmer before sending such a reminder.

The list archive is available at a few public sites:

        http://news.gmane.org/gmane.comp.version-control.git/
        http://marc.info/?l=git
        http://www.spinics.net/lists/git/

For those who prefer to read it over NNTP:

        nntp://news.gmane.org/gmane.comp.version-control.git

When you point at a message in a mailing list archive, using
gmane is often the easiest to follow by readers, like this:

        http://thread.gmane.org/gmane.comp.version-control.git/27/focus=217

as it also allows people who subscribe to the mailing list as gmane
newsgroup to "jump to" the article.

Some members of the development community can sometimes be found on
the #git and #git-devel IRC channels on Freenode.  Their logs are
available at:

        http://colabti.org/irclogger/irclogger_log/git
        http://colabti.org/irclogger/irclogger_log/git-devel

There is a volunteer-run newsletter to serve our community ("Git Rev
News" http://git.github.io/rev_news/rev_news.html).

Git is a member project of software freedom conservancy, a non-profit
organization (https://sfconservancy.org/).  To reach a committee of
liaisons to the conservancy, contact them at <git@sfconservancy.org>.


* Reporting bugs

When you think git does not behave as you expect, please do not stop
your bug report with just "git does not work".  "I used git in this
way, but it did not work" is not much better, neither is "I used git
in this way, and X happend, which is broken".  It often is that git is
correct to cause X happen in such a case, and it is your expectation
that is broken. People would not know what other result Y you expected
to see instead of X, if you left it unsaid.

Please remember to always state

 - what you wanted to achieve;

 - what you did (the version of git and the command sequence to reproduce
   the behavior);

 - what you saw happen (X above);

 - what you expected to see (Y above); and

 - how the last two are different.

See http://www.chiark.greenend.org.uk/~sgtatham/bugs.html for further
hints.

If you think you found a security-sensitive issue and want to disclose
it to us without announcing it to wider public, please contact us at
our security mailing list <git-security@googlegroups.com>.  This is
a closed list that is limited to people who need to know early about
vulnerabilities, including:

  - people triaging and fixing reported vulnerabilities
  - people operating major git hosting sites with many users
  - people packaging and distributing git to large numbers of people

where these issues are discussed without risk of the information
leaking out before we're ready to make public announcements.


* Repositories and documentation.

My public git.git repositories are at:

  git://git.kernel.org/pub/scm/git/git.git/
  https://kernel.googlesource.com/pub/scm/git/git
  git://repo.or.cz/alt-git.git/
  https://github.com/git/git/
  git://git.sourceforge.jp/gitroot/git-core/git.git/
  git://git-core.git.sourceforge.net/gitroot/git-core/git-core/

A few web interfaces are found at:

  http://git.kernel.org/cgit/git/git.git
  https://kernel.googlesource.com/pub/scm/git/git
  http://repo.or.cz/w/alt-git.git

Preformatted documentation from the tip of the "master" branch can be
found in:

  git://git.kernel.org/pub/scm/git/git-{htmldocs,manpages}.git/
  git://repo.or.cz/git-{htmldocs,manpages}.git/
  https://github.com/gitster/git-{htmldocs,manpages}.git/

The manual pages formatted in HTML for the tip of 'master' can be
viewed online at:

  https://git.github.io/htmldocs/git.html


* How various branches are used.

There are four branches in git.git repository that track the source tree
of git: "master", "maint", "next", and "pu".

The "master" branch is meant to contain what are very well tested and
ready to be used in a production setting.  Every now and then, a
"feature release" is cut from the tip of this branch.  They used to be
named with three dotted decimal digits (e.g. "1.8.5"), but recently we
switched the versioning scheme and "feature releases" are named with
three-dotted decimal digits that ends with ".0" (e.g. "1.9.0").

The last such release was 2.9 done on June 13th, 2016. You can expect
that the tip of the "master" branch is always more stable than any of
the released versions.

Whenever a feature release is made, "maint" branch is forked off from
"master" at that point.  Obvious and safe fixes after a feature
release are applied to this branch and maintenance releases are cut
from it.  Usually the fixes are merged to the "master" branch first,
several days before merged to the "maint" branch, to reduce the chance
of last-minute issues.  The maintenance releases used to be named with
four dotted decimal, named after the feature release they are updates
to (e.g. "1.8.5.1" was the first maintenance release for "1.8.5"
feature release).  These days, maintenance releases are named by
incrementing the last digit of three-dotted decimal name (e.g. "2.8.3"
is the third maintenance release for the "2.8" series).

New features never go to the 'maint' branch.  This branch is also
merged into "master" to propagate the fixes forward as needed.

A new development does not usually happen on "master". When you send a
series of patches, after review on the mailing list, a separate topic
branch is forked from the tip of "master" and your patches are queued
there, and kept out of "master" while people test it out. The quality of
topic branches are judged primarily by the mailing list discussions.

Topic branches that are in good shape are merged to the "next" branch. In
general, the "next" branch always contains the tip of "master".  It might
not be quite rock-solid, but is expected to work more or less without major
breakage. The "next" branch is where new and exciting things take place. A
topic that is in "next" is expected to be polished to perfection before it
is merged to "master".  Please help this process by building & using the
"next" branch for your daily work, and reporting any new bugs you find to
the mailing list, before the breakage is merged down to the "master".

The "pu" (proposed updates) branch bundles all the remaining topic
branches the maintainer happens to have seen.  There is no guarantee that
the maintainer has enough bandwidth to pick up any and all topics that
are remotely promising from the list traffic, so please do not read
too much into a topic being on (or not on) the "pu" branch.  This
branch is mainly to remind the maintainer that the topics in them may
turn out to be interesting when they are polished, nothing more.  The
topics on this branch aren't usually complete, well tested, or well
documented and they often need further work.  When a topic that was
in "pu" proves to be in a testable shape, it is merged to "next".

You can run "git log --first-parent master..pu" to see what topics are
currently in flight.  Sometimes, an idea that looked promising turns out
to be not so good and the topic can be dropped from "pu" in such a case.

The two branches "master" and "maint" are never rewound, and "next"
usually will not be either.  After a feature release is made from
"master", however, "next" will be rebuilt from the tip of "master"
using the topics that didn't make the cut in the feature release.

Note that being in "next" is not a guarantee to appear in the next
release, nor even in any future release.  There were cases that topics
needed reverting a few commits in them before graduating to "master",
or a topic that already was in "next" was reverted from "next" because
fatal flaws were found in it after it was merged to "next".


* Other people's trees.

Documentation/SubmittingPatches outlines to whom your proposed changes
should be sent.  As described in contrib/README, I would delegate fixes
and enhancements in contrib/ area to the primary contributors of them.

Although the following are included in git.git repository, they have their
own authoritative repository and maintainers:

 - git-gui/ comes from git-gui project, maintained by Pat Thoyts:

        git://repo.or.cz/git-gui.git

 - gitk-git/ comes from Paul Mackerras's gitk project:

        git://ozlabs.org/~paulus/gitk

 - po/ comes from the localization coordinator, Jiang Xin:

	https://github.com/git-l10n/git-po/

When sending proposed updates and fixes to these parts of the system,
please base your patches on these trees, not git.git (the former two
even have different directory structures).

A note from the maintainer

[Junio C Hamano]

Welcome to the Git development community.

This message is written by the maintainer and talks about how Git
project is managed, and how you can work with it.

* Mailing list and the community

The development is primarily done on the Git mailing list. Help
requests, feature proposals, bug reports and patches should be sent to
the list address <git@vger.kernel.org>.  You don't have to be
subscribed to send messages.  The convention on the list is to keep
everybody involved on Cc:, so it is unnecessary to say "Please Cc: me,
I am not subscribed".

Before sending patches, please read Documentation/SubmittingPatches
and Documentation/CodingGuidelines to familiarize yourself with the
project convention.

If you sent a patch and you did not hear any response from anybody for
several days, it could be that your patch was totally uninteresting,
but it also is possible that it was simply lost in the noise.  Please
do not hesitate to send a reminder message in such a case.  Messages
getting lost in the noise may be a sign that those who can evaluate
your patch don't have enough mental/time bandwidth to process them
right at the moment, and it often helps to wait until the list traffic
becomes calmer before sending such a reminder.

The list archive is available at a few public sites:

        http://news.gmane.org/gmane.comp.version-control.git/
        http://marc.info/?l=git
        http://www.spinics.net/lists/git/

For those who prefer to read it over NNTP:

        nntp://news.gmane.org/gmane.comp.version-control.git

When you point at a message in a mailing list archive, using
gmane is often the easiest to follow by readers, like this:

        http://thread.gmane.org/gmane.comp.version-control.git/27/focus=217

as it also allows people who subscribe to the mailing list as gmane
newsgroup to "jump to" the article.

Some members of the development community can sometimes be found on
the #git and #git-devel IRC channels on Freenode.  Their logs are
available at:

        http://colabti.org/irclogger/irclogger_log/git
        http://colabti.org/irclogger/irclogger_log/git-devel

There is a volunteer-run newsletter to serve our community ("Git Rev
News" http://git.github.io/rev_news/rev_news.html).

Git is a member project of software freedom conservancy, a non-profit
organization (https://sfconservancy.org/).  To reach a committee of
liaisons to the conservancy, contact them at <git@sfconservancy.org>.


* Reporting bugs

When you think git does not behave as you expect, please do not stop
your bug report with just "git does not work".  "I used git in this
way, but it did not work" is not much better, neither is "I used git
in this way, and X happend, which is broken".  It often is that git is
correct to cause X happen in such a case, and it is your expectation
that is broken. People would not know what other result Y you expected
to see instead of X, if you left it unsaid.

Please remember to always state

 - what you wanted to achieve;

 - what you did (the version of git and the command sequence to reproduce
   the behavior);

 - what you saw happen (X above);

 - what you expected to see (Y above); and

 - how the last two are different.

See http://www.chiark.greenend.org.uk/~sgtatham/bugs.html for further
hints.

If you think you found a security-sensitive issue and want to disclose
it to us without announcing it to wider public, please contact us at
our security mailing list <git-security@googlegroups.com>.  This is
a closed list that is limited to people who need to know early about
vulnerabilities, including:

  - people triaging and fixing reported vulnerabilities
  - people operating major git hosting sites with many users
  - people packaging and distributing git to large numbers of people

where these issues are discussed without risk of the information
leaking out before we're ready to make public announcements.


* Repositories and documentation.

My public git.git repositories are at:

  git://git.kernel.org/pub/scm/git/git.git/
  https://kernel.googlesource.com/pub/scm/git/git
  git://repo.or.cz/alt-git.git/
  https://github.com/git/git/
  git://git.sourceforge.jp/gitroot/git-core/git.git/
  git://git-core.git.sourceforge.net/gitroot/git-core/git-core/

A few web interfaces are found at:

  http://git.kernel.org/cgit/git/git.git
  https://kernel.googlesource.com/pub/scm/git/git
  http://repo.or.cz/w/alt-git.git

Preformatted documentation from the tip of the "master" branch can be
found in:

  git://git.kernel.org/pub/scm/git/git-{htmldocs,manpages}.git/
  git://repo.or.cz/git-{htmldocs,manpages}.git/
  https://github.com/gitster/git-{htmldocs,manpages}.git/

and rendered in the browser if you visit this page:

  https://git.github.io/htmldocs/git.html

Also GitHub shows the manual pages formatted in HTML (with a
formatting backend different from the one that is used to create the
above) at:

  http://git-scm.com/docs/git

* How various branches are used.

There are four branches in git.git repository that track the source tree
of git: "master", "maint", "next", and "pu".

The "master" branch is meant to contain what are very well tested and
ready to be used in a production setting.  Every now and then, a
"feature release" is cut from the tip of this branch.  They used to be
named with three dotted decimal digits (e.g. "1.8.5"), but recently we
switched the versioning scheme and "feature releases" are named with
three-dotted decimal digits that ends with ".0" (e.g. "1.9.0").

The last such release was 2.9 done on June 13th, 2016. You can expect
that the tip of the "master" branch is always more stable than any of
the released versions.

Whenever a feature release is made, "maint" branch is forked off from
"master" at that point.  Obvious and safe fixes after a feature
release are applied to this branch and maintenance releases are cut
from it.  Usually the fixes are merged to the "master" branch first,
several days before merged to the "maint" branch, to reduce the chance
of last-minute issues.  The maintenance releases used to be named with
four dotted decimal, named after the feature release they are updates
to (e.g. "1.8.5.1" was the first maintenance release for "1.8.5"
feature release).  These days, maintenance releases are named by
incrementing the last digit of three-dotted decimal name (e.g. "2.8.3"
is the third maintenance release for the "2.8" series).

New features never go to the 'maint' branch.  This branch is also
merged into "master" to propagate the fixes forward as needed.

A new development does not usually happen on "master". When you send a
series of patches, after review on the mailing list, a separate topic
branch is forked from the tip of "master" and your patches are queued
there, and kept out of "master" while people test it out. The quality of
topic branches are judged primarily by the mailing list discussions.

Topic branches that are in good shape are merged to the "next" branch. In
general, the "next" branch always contains the tip of "master".  It might
not be quite rock-solid, but is expected to work more or less without major
breakage. The "next" branch is where new and exciting things take place. A
topic that is in "next" is expected to be polished to perfection before it
is merged to "master".  Please help this process by building & using the
"next" branch for your daily work, and reporting any new bugs you find to
the mailing list, before the breakage is merged down to the "master".

The "pu" (proposed updates) branch bundles all the remaining topic
branches the maintainer happens to have seen.  There is no guarantee that
the maintainer has enough bandwidth to pick up any and all topics that
are remotely promising from the list traffic, so please do not read
too much into a topic being on (or not on) the "pu" branch.  This
branch is mainly to remind the maintainer that the topics in them may
turn out to be interesting when they are polished, nothing more.  The
topics on this branch aren't usually complete, well tested, or well
documented and they often need further work.  When a topic that was
in "pu" proves to be in a testable shape, it is merged to "next".

You can run "git log --first-parent master..pu" to see what topics are
currently in flight.  Sometimes, an idea that looked promising turns out
to be not so good and the topic can be dropped from "pu" in such a case.

The two branches "master" and "maint" are never rewound, and "next"
usually will not be either.  After a feature release is made from
"master", however, "next" will be rebuilt from the tip of "master"
using the topics that didn't make the cut in the feature release.

Note that being in "next" is not a guarantee to appear in the next
release, nor even in any future release.  There were cases that topics
needed reverting a few commits in them before graduating to "master",
or a topic that already was in "next" was reverted from "next" because
fatal flaws were found in it after it was merged to "next".


* Other people's trees.

Documentation/SubmittingPatches outlines to whom your proposed changes
should be sent.  As described in contrib/README, I would delegate fixes
and enhancements in contrib/ area to the primary contributors of them.

Although the following are included in git.git repository, they have their
own authoritative repository and maintainers:

 - git-gui/ comes from git-gui project, maintained by Pat Thoyts:

        git://repo.or.cz/git-gui.git

 - gitk-git/ comes from Paul Mackerras's gitk project:

        git://ozlabs.org/~paulus/gitk

 - po/ comes from the localization coordinator, Jiang Xin:

	https://github.com/git-l10n/git-po/

When sending proposed updates and fixes to these parts of the system,
please base your patches on these trees, not git.git (the former two
even have different directory structures).

A note from the maintainer

[Junio C Hamano]

Welcome to the Git development community.

This message is written by the maintainer and talks about how Git
project is managed, and how you can work with it.

* Mailing list and the community

The development is primarily done on the Git mailing list. Help
requests, feature proposals, bug reports and patches should be sent to
the list address <git@vger.kernel.org>.  You don't have to be
subscribed to send messages.  The convention on the list is to keep
everybody involved on Cc:, so it is unnecessary to say "Please Cc: me,
I am not subscribed".

Before sending patches, please read Documentation/SubmittingPatches
and Documentation/CodingGuidelines to familiarize yourself with the
project convention.

If you sent a patch and you did not hear any response from anybody for
several days, it could be that your patch was totally uninteresting,
but it also is possible that it was simply lost in the noise.  Please
do not hesitate to send a reminder message in such a case.  Messages
getting lost in the noise may be a sign that those who can evaluate
your patch don't have enough mental/time bandwidth to process them
right at the moment, and it often helps to wait until the list traffic
becomes calmer before sending such a reminder.

The list archive is available at a few public sites:

        http://news.gmane.org/gmane.comp.version-control.git/
        http://marc.info/?l=git
        http://www.spinics.net/lists/git/

For those who prefer to read it over NNTP:

        nntp://news.gmane.org/gmane.comp.version-control.git

When you point at a message in a mailing list archive, using
gmane is often the easiest to follow by readers, like this:

        http://thread.gmane.org/gmane.comp.version-control.git/27/focus=217

as it also allows people who subscribe to the mailing list as gmane
newsgroup to "jump to" the article.

Some members of the development community can sometimes be found on
the #git and #git-devel IRC channels on Freenode.  Their logs are
available at:

        http://colabti.org/irclogger/irclogger_log/git
        http://colabti.org/irclogger/irclogger_log/git-devel

There is a volunteer-run newsletter to serve our community ("Git Rev
News" http://git.github.io/rev_news/rev_news.html).

Git is a member project of software freedom conservancy, a non-profit
organization (https://sfconservancy.org/).  To reach a committee of
liaisons to the conservancy, contact them at <git@sfconservancy.org>.


* Reporting bugs

When you think git does not behave as you expect, please do not stop
your bug report with just "git does not work".  "I used git in this
way, but it did not work" is not much better, neither is "I used git
in this way, and X happend, which is broken".  It often is that git is
correct to cause X happen in such a case, and it is your expectation
that is broken. People would not know what other result Y you expected
to see instead of X, if you left it unsaid.

Please remember to always state

 - what you wanted to achieve;

 - what you did (the version of git and the command sequence to reproduce
   the behavior);

 - what you saw happen (X above);

 - what you expected to see (Y above); and

 - how the last two are different.

See http://www.chiark.greenend.org.uk/~sgtatham/bugs.html for further
hints.

If you think you found a security-sensitive issue and want to disclose
it to us without announcing it to wider public, please contact us at
our security mailing list <git-security@googlegroups.com>.  This is
a closed list that is limited to people who need to know early about
vulnerabilities, including:

  - people triaging and fixing reported vulnerabilities
  - people operating major git hosting sites with many users
  - people packaging and distributing git to large numbers of people

where these issues are discussed without risk of the information
leaking out before we're ready to make public announcements.


* Repositories and documentation.

My public git.git repositories are at:

  git://git.kernel.org/pub/scm/git/git.git/
  https://kernel.googlesource.com/pub/scm/git/git
  git://repo.or.cz/alt-git.git/
  https://github.com/git/git/
  git://git.sourceforge.jp/gitroot/git-core/git.git/
  git://git-core.git.sourceforge.net/gitroot/git-core/git-core/

A few web interfaces are found at:

  http://git.kernel.org/cgit/git/git.git
  https://kernel.googlesource.com/pub/scm/git/git
  http://repo.or.cz/w/alt-git.git

Preformatted documentation from the tip of the "master" branch can be
found in:

  git://git.kernel.org/pub/scm/git/git-{htmldocs,manpages}.git/
  git://repo.or.cz/git-{htmldocs,manpages}.git/
  https://github.com/gitster/git-{htmldocs,manpages}.git/

Also GitHub shows the manual pages formatted in HTML (with a
formatting backend different from the one that is used to create the
above) at:

  http://git-scm.com/docs/git


* How various branches are used.

There are four branches in git.git repository that track the source tree
of git: "master", "maint", "next", and "pu".

The "master" branch is meant to contain what are very well tested and
ready to be used in a production setting.  Every now and then, a
"feature release" is cut from the tip of this branch.  They used to be
named with three dotted decimal digits (e.g. "1.8.5"), but recently we
switched the versioning scheme and "feature releases" are named with
three-dotted decimal digits that ends with ".0" (e.g. "1.9.0").

The last such release was 2.8.0 done on Mar 28th, 2016. You can expect
that the tip of the "master" branch is always more stable than any of
the released versions.

Whenever a feature release is made, "maint" branch is forked off from
"master" at that point.  Obvious and safe fixes after a feature
release are applied to this branch and maintenance releases are cut
from it.  Usually the fixes are merged to the "master" branch first,
several days before merged to the "maint" branch, to reduce the chance
of last-minute issues.  The maintenance releases used to be named with
four dotted decimal, named after the feature release they are updates
to (e.g. "1.8.5.1" was the first maintenance release for "1.8.5"
feature release).  These days, maintenance releases are named by
incrementing the last digit of three-dotted decimal name (e.g. "2.8.3"
is the third maintenance release for the "2.8" series).

New features never go to the 'maint' branch.  This branch is also
merged into "master" to propagate the fixes forward as needed.

A new development does not usually happen on "master". When you send a
series of patches, after review on the mailing list, a separate topic
branch is forked from the tip of "master" and your patches are queued
there, and kept out of "master" while people test it out. The quality of
topic branches are judged primarily by the mailing list discussions.

Topic branches that are in good shape are merged to the "next" branch. In
general, the "next" branch always contains the tip of "master".  It might
not be quite rock-solid, but is expected to work more or less without major
breakage. The "next" branch is where new and exciting things take place. A
topic that is in "next" is expected to be polished to perfection before it
is merged to "master".  Please help this process by building & using the
"next" branch for your daily work, and reporting any new bugs you find to
the mailing list, before the breakage is merged down to the "master".

The "pu" (proposed updates) branch bundles all the remaining topic
branches the maintainer happens to have seen.  There is no guarantee that
the maintainer has enough bandwidth to pick up any and all topics that
are remotely promising from the list traffic, so please do not read
too much into a topic being on (or not on) the "pu" branch.  This
branch is mainly to remind the maintainer that the topics in them may
turn out to be interesting when they are polished, nothing more.  The
topics on this branch aren't usually complete, well tested, or well
documented and they often need further work.  When a topic that was
in "pu" proves to be in a testable shape, it is merged to "next".

You can run "git log --first-parent master..pu" to see what topics are
currently in flight.  Sometimes, an idea that looked promising turns out
to be not so good and the topic can be dropped from "pu" in such a case.

The two branches "master" and "maint" are never rewound, and "next"
usually will not be either.  After a feature release is made from
"master", however, "next" will be rebuilt from the tip of "master"
using the topics that didn't make the cut in the feature release.

Note that being in "next" is not a guarantee to appear in the next
release, nor even in any future release.  There were cases that topics
needed reverting a few commits in them before graduating to "master",
or a topic that already was in "next" was reverted from "next" because
fatal flaws were found in it after it was merged to "next".


* Other people's trees.

Documentation/SubmittingPatches outlines to whom your proposed changes
should be sent.  As described in contrib/README, I would delegate fixes
and enhancements in contrib/ area to the primary contributors of them.

Although the following are included in git.git repository, they have their
own authoritative repository and maintainers:

 - git-gui/ comes from git-gui project, maintained by Pat Thoyts:

        git://repo.or.cz/git-gui.git

 - gitk-git/ comes from Paul Mackerras's gitk project:

        git://ozlabs.org/~paulus/gitk

 - po/ comes from the localization coordinator, Jiang Xin:

	https://github.com/git-l10n/git-po/

When sending proposed updates and fixes to these parts of the system,
please base your patches on these trees, not git.git (the former two
even have different directory structures).

A note from the maintainer

[Junio C Hamano]

Welcome to the Git development community.

This message is written by the maintainer and talks about how Git
project is managed, and how you can work with it.

* Mailing list and the community

The development is primarily done on the Git mailing list. Help
requests, feature proposals, bug reports and patches should be sent to
the list address <git@vger.kernel.org>.  You don't have to be
subscribed to send messages.  The convention on the list is to keep
everybody involved on Cc:, so it is unnecessary to say "Please Cc: me,
I am not subscribed".

Before sending patches, please read Documentation/SubmittingPatches
and Documentation/CodingGuidelines to familiarize yourself with the
project convention.

If you sent a patch and you did not hear any response from anybody for
several days, it could be that your patch was totally uninteresting,
but it also is possible that it was simply lost in the noise.  Please
do not hesitate to send a reminder message in such a case.  Messages
getting lost in the noise may be a sign that those who can evaluate
your patch don't have enough mental/time bandwidth to process them
right at the moment, and it often helps to wait until the list traffic
becomes calmer before sending such a reminder.

The list archive is available at a few public sites:

        http://news.gmane.org/gmane.comp.version-control.git/
        http://marc.info/?l=git
        http://www.spinics.net/lists/git/

For those who prefer to read it over NNTP:

        nntp://news.gmane.org/gmane.comp.version-control.git

When you point at a message in a mailing list archive, using
gmane is often the easiest to follow by readers, like this:

        http://thread.gmane.org/gmane.comp.version-control.git/27/focus=217

as it also allows people who subscribe to the mailing list as gmane
newsgroup to "jump to" the article.

Some members of the development community can sometimes be found on
the #git and #git-devel IRC channels on Freenode.  Their logs are
available at:

        http://colabti.org/irclogger/irclogger_log/git
        http://colabti.org/irclogger/irclogger_log/git-devel

There is a volunteer-run newsletter to serve our community ("Git Rev
News" http://git.github.io/rev_news/rev_news.html).

Git is a member project of software freedom conservancy, a non-profit
organization (https://sfconservancy.org/).  To reach a committee of
liaisons to the conservancy, contact them at <git@sfconservancy.org>.


* Reporting bugs

When you think git does not behave as you expect, please do not stop
your bug report with just "git does not work".  "I used git in this
way, but it did not work" is not much better, neither is "I used git
in this way, and X happend, which is broken".  It often is that git is
correct to cause X happen in such a case, and it is your expectation
that is broken. People would not know what other result Y you expected
to see instead of X, if you left it unsaid.

Please remember to always state

 - what you wanted to achieve;

 - what you did (the version of git and the command sequence to reproduce
   the behavior);

 - what you saw happen (X above);

 - what you expected to see (Y above); and

 - how the last two are different.

See http://www.chiark.greenend.org.uk/~sgtatham/bugs.html for further
hints.

If you think you found a security-sensitive issue and want to disclose
it to us without announcing it to wider public, please contact us at
our security mailing list <git-security@googlegroups.com>.  This is
a closed list that is limited to people who need to know early about
vulnerabilities, including:

  - people triaging and fixing reported vulnerabilities
  - people operating major git hosting sites with many users
  - people packaging and distributing git to large numbers of people

where these issues are discussed without risk of the information
leaking out before we're ready to make public announcements.


* Repositories and documentation.

My public git.git repositories are at:

  git://git.kernel.org/pub/scm/git/git.git/
  https://kernel.googlesource.com/pub/scm/git/git
  git://repo.or.cz/alt-git.git/
  https://github.com/git/git/
  git://git.sourceforge.jp/gitroot/git-core/git.git/
  git://git-core.git.sourceforge.net/gitroot/git-core/git-core/

A few web interfaces are found at:

  http://git.kernel.org/cgit/git/git.git
  https://kernel.googlesource.com/pub/scm/git/git
  http://repo.or.cz/w/alt-git.git

Preformatted documentation from the tip of the "master" branch can be
found in:

  git://git.kernel.org/pub/scm/git/git-{htmldocs,manpages}.git/
  git://repo.or.cz/git-{htmldocs,manpages}.git/
  https://github.com/gitster/git-{htmldocs,manpages}.git/

Also GitHub shows the manual pages formatted in HTML (with a
formatting backend different from the one that is used to create the
above) at:

  http://git-scm.com/docs/git


* How various branches are used.

There are four branches in git.git repository that track the source tree
of git: "master", "maint", "next", and "pu".

The "master" branch is meant to contain what are very well tested and
ready to be used in a production setting.  Every now and then, a
"feature release" is cut from the tip of this branch.  They used to be
named with three dotted decimal digits (e.g. "1.8.5"), but recently we
switched the versioning scheme and "feature releases" are named with
three-dotted decimal digits that ends with ".0" (e.g. "1.9.0").

The last such release was 2.8.0 done on Mar 28th, 2016. You can expect
that the tip of the "master" branch is always more stable than any of
the released versions.

Whenever a feature release is made, "maint" branch is forked off from
"master" at that point.  Obvious, safe and urgent fixes after a
feature release are applied to this branch and maintenance releases
are cut from it.  The maintenance releases used to be named with four
dotted decimal, named after the feature release they are updates to
(e.g. "1.8.5.1" was the first maintenance release for "1.8.5" feature
release).  These days, maintenance releases are named by incrementing
the last digit of three-dotted decimal name (e.g. "2.7.4" is the
fourth maintenance release for the "2.7" series).

New features never go to the 'maint' branch.  This branch is also
merged into "master" to propagate the fixes forward as needed.

A new development does not usually happen on "master". When you send a
series of patches, after review on the mailing list, a separate topic
branch is forked from the tip of "master" and your patches are queued
there, and kept out of "master" while people test it out. The quality of
topic branches are judged primarily by the mailing list discussions.

Topic branches that are in good shape are merged to the "next" branch. In
general, the "next" branch always contains the tip of "master".  It might
not be quite rock-solid, but is expected to work more or less without major
breakage. The "next" branch is where new and exciting things take place. A
topic that is in "next" is expected to be polished to perfection before it
is merged to "master".  Please help this process by building & using the
"next" branch for your daily work, and reporting any new bugs you find to
the mailing list, before the breakage is merged down to the "master".

The "pu" (proposed updates) branch bundles all the remaining topic
branches the maintainer happens to have seen.  There is no guarantee that
the maintainer has enough bandwidth to pick up any and all topics that
are remotely promising from the list traffic, so please do not read
too much into a topic being on (or not on) the "pu" branch.  This
branch is mainly to remind the maintainer that the topics in them may
turn out to be interesting when they are polished, nothing more.  The
topics on this branch aren't usually complete, well tested, or well
documented and they often need further work.  When a topic that was
in "pu" proves to be in a testable shape, it is merged to "next".

You can run "git log --first-parent master..pu" to see what topics are
currently in flight.  Sometimes, an idea that looked promising turns out
to be not so good and the topic can be dropped from "pu" in such a case.

The two branches "master" and "maint" are never rewound, and "next"
usually will not be either.  After a feature release is made from
"master", however, "next" will be rebuilt from the tip of "master"
using the topics that didn't make the cut in the feature release.

Note that being in "next" is not a guarantee to appear in the next
release, nor even in any future release.  There were cases that topics
needed reverting a few commits in them before graduating to "master",
or a topic that already was in "next" was reverted from "next" because
fatal flaws were found in it after it was merged to "next".


* Other people's trees.

Documentation/SubmittingPatches outlines to whom your proposed changes
should be sent.  As described in contrib/README, I would delegate fixes
and enhancements in contrib/ area to the primary contributors of them.

Although the following are included in git.git repository, they have their
own authoritative repository and maintainers:

 - git-gui/ comes from git-gui project, maintained by Pat Thoyts:

        git://repo.or.cz/git-gui.git

 - gitk-git/ comes from Paul Mackerras's gitk project:

        git://ozlabs.org/~paulus/gitk

 - po/ comes from the localization coordinator, Jiang Xin:

	https://github.com/git-l10n/git-po/

When sending proposed updates and fixes to these parts of the system,
please base your patches on these trees, not git.git (the former two
even have different directory structures).

A note from the maintainer

[Junio C Hamano]

Welcome to the Git development community.

This message is written by the maintainer and talks about how Git
project is managed, and how you can work with it.

* Mailing list and the community

The development is primarily done on the Git mailing list. Help
requests, feature proposals, bug reports and patches should be sent to
the list address <git@vger.kernel.org>.  You don't have to be
subscribed to send messages.  The convention on the list is to keep
everybody involved on Cc:, so it is unnecessary to say "Please Cc: me,
I am not subscribed".

Before sending patches, please read Documentation/SubmittingPatches
and Documentation/CodingGuidelines to familiarize yourself with the
project convention.

If you sent a patch and you did not hear any response from anybody for
several days, it could be that your patch was totally uninteresting,
but it also is possible that it was simply lost in the noise.  Please
do not hesitate to send a reminder message in such a case.  Messages
getting lost in the noise may be a sign that those who can evaluate
your patch don't have enough mental/time bandwidth to process them
right at the moment, and it often helps to wait until the list traffic
becomes calmer before sending such a reminder.

The list archive is available at a few public sites:

        http://news.gmane.org/gmane.comp.version-control.git/
        http://marc.info/?l=git
        http://www.spinics.net/lists/git/

For those who prefer to read it over NNTP:

        nntp://news.gmane.org/gmane.comp.version-control.git

When you point at a message in a mailing list archive, using
gmane is often the easiest to follow by readers, like this:

        http://thread.gmane.org/gmane.comp.version-control.git/27/focus=217

as it also allows people who subscribe to the mailing list as gmane
newsgroup to "jump to" the article.

Some members of the development community can sometimes be found on
the #git and #git-devel IRC channels on Freenode.  Their logs are
available at:

        http://colabti.org/irclogger/irclogger_log/git
        http://colabti.org/irclogger/irclogger_log/git-devel

There is a volunteer-run newsletter to serve our community ("Git Rev
News" http://git.github.io/rev_news/rev_news.html).

Git is a member project of software freedom conservancy, a non-profit
organization (https://sfconservancy.org/).  To reach a committee of
liaisons to the conservancy, contact them at <git@sfconservancy.org>.


* Reporting bugs

When you think git does not behave as you expect, please do not stop
your bug report with just "git does not work".  "I used git in this
way, but it did not work" is not much better, neither is "I used git
in this way, and X happend, which is broken".  It often is that git is
correct to cause X happen in such a case, and it is your expectation
that is broken. People would not know what other result Y you expected
to see instead of X, if you left it unsaid.

Please remember to always state

 - what you wanted to achieve;

 - what you did (the version of git and the command sequence to reproduce
   the behavior);

 - what you saw happen (X above);

 - what you expected to see (Y above); and

 - how the last two are different.

See http://www.chiark.greenend.org.uk/~sgtatham/bugs.html for further
hints.

If you think you found a security-sensitive issue and want to disclose
it to us without announcing it to wider public, please contact us at
our security mailing list <git-security@googlegroups.com>.


* Repositories and documentation.

My public git.git repositories are at:

  git://git.kernel.org/pub/scm/git/git.git/
  https://kernel.googlesource.com/pub/scm/git/git
  git://repo.or.cz/alt-git.git/
  https://github.com/git/git/
  git://git.sourceforge.jp/gitroot/git-core/git.git/
  git://git-core.git.sourceforge.net/gitroot/git-core/git-core/

A few web interfaces are found at:

  http://git.kernel.org/cgit/git/git.git
  https://kernel.googlesource.com/pub/scm/git/git
  http://repo.or.cz/w/alt-git.git

Preformatted documentation from the tip of the "master" branch can be
found in:

  git://git.kernel.org/pub/scm/git/git-{htmldocs,manpages}.git/
  git://repo.or.cz/git-{htmldocs,manpages}.git/
  https://github.com/gitster/git-{htmldocs,manpages}.git/

Also GitHub shows the manual pages formatted in HTML (with a
formatting backend different from the one that is used to create the
above) at:

  http://git-scm.com/docs/git


* How various branches are used.

There are four branches in git.git repository that track the source tree
of git: "master", "maint", "next", and "pu".

The "master" branch is meant to contain what are very well tested and
ready to be used in a production setting.  Every now and then, a
"feature release" is cut from the tip of this branch.  They used to be
named with three dotted decimal digits (e.g. "1.8.5"), but recently we
switched the versioning scheme and "feature releases" are named with
three-dotted decimal digits that ends with ".0" (e.g. "1.9.0").

The last such release was 2.8.0 done on Mar 28th, 2016. You can expect
that the tip of the "master" branch is always more stable than any of
the released versions.

Whenever a feature release is made, "maint" branch is forked off from
"master" at that point.  Obvious, safe and urgent fixes after a
feature release are applied to this branch and maintenance releases
are cut from it.  The maintenance releases used to be named with four
dotted decimal, named after the feature release they are updates to
(e.g. "1.8.5.1" was the first maintenance release for "1.8.5" feature
release).  These days, maintenance releases are named by incrementing
the last digit of three-dotted decimal name (e.g. "2.7.4" is the
fourth maintenance release for the "2.7" series).

New features never go to the 'maint' branch.  This branch is also
merged into "master" to propagate the fixes forward as needed.

A new development does not usually happen on "master". When you send a
series of patches, after review on the mailing list, a separate topic
branch is forked from the tip of "master" and your patches are queued
there, and kept out of "master" while people test it out. The quality of
topic branches are judged primarily by the mailing list discussions.

Topic branches that are in good shape are merged to the "next" branch. In
general, the "next" branch always contains the tip of "master".  It might
not be quite rock-solid, but is expected to work more or less without major
breakage. The "next" branch is where new and exciting things take place. A
topic that is in "next" is expected to be polished to perfection before it
is merged to "master".  Please help this process by building & using the
"next" branch for your daily work, and reporting any new bugs you find to
the mailing list, before the breakage is merged down to the "master".

The "pu" (proposed updates) branch bundles all the remaining topic
branches the maintainer happens to have seen.  There is no guarantee that
the maintainer has enough bandwidth to pick up any and all topics that
are remotely promising from the list traffic, so please do not read
too much into a topic being on (or not on) the "pu" branch.  This
branch is mainly to remind the maintainer that the topics in them may
turn out to be interesting when they are polished, nothing more.  The
topics on this branch aren't usually complete, well tested, or well
documented and they often need further work.  When a topic that was
in "pu" proves to be in a testable shape, it is merged to "next".

You can run "git log --first-parent master..pu" to see what topics are
currently in flight.  Sometimes, an idea that looked promising turns out
to be not so good and the topic can be dropped from "pu" in such a case.

The two branches "master" and "maint" are never rewound, and "next"
usually will not be either.  After a feature release is made from
"master", however, "next" will be rebuilt from the tip of "master"
using the topics that didn't make the cut in the feature release.

Note that being in "next" is not a guarantee to appear in the next
release, nor even in any future release.  There were cases that topics
needed reverting a few commits in them before graduating to "master",
or a topic that already was in "next" was reverted from "next" because
fatal flaws were found in it after it was merged to "next".


* Other people's trees.

Documentation/SubmittingPatches outlines to whom your proposed changes
should be sent.  As described in contrib/README, I would delegate fixes
and enhancements in contrib/ area to the primary contributors of them.

Although the following are included in git.git repository, they have their
own authoritative repository and maintainers:

 - git-gui/ comes from git-gui project, maintained by Pat Thoyts:

        git://repo.or.cz/git-gui.git

 - gitk-git/ comes from Paul Mackerras's gitk project:

        git://ozlabs.org/~paulus/gitk

 - po/ comes from the localization coordinator, Jiang Xin:

	https://github.com/git-l10n/git-po/

When sending proposed updates and fixes to these parts of the system,
please base your patches on these trees, not git.git (the former two
even have different directory structures).

A note from the maintainer

[Junio C Hamano]

Welcome to the Git development community.

This message is written by the maintainer and talks about how Git
project is managed, and how you can work with it.

* Mailing list and the community

The development is primarily done on the Git mailing list. Help
requests, feature proposals, bug reports and patches should be sent to
the list address <git@vger.kernel.org>.  You don't have to be
subscribed to send messages.  The convention on the list is to keep
everybody involved on Cc:, so it is unnecessary to say "Please Cc: me,
I am not subscribed".

Before sending patches, please read Documentation/SubmittingPatches
and Documentation/CodingGuidelines to familiarize yourself with the
project convention.

If you sent a patch and you did not hear any response from anybody for
several days, it could be that your patch was totally uninteresting,
but it also is possible that it was simply lost in the noise.  Please
do not hesitate to send a reminder message in such a case.  Messages
getting lost in the noise may be a sign that those who can evaluate
your patch don't have enough mental/time bandwidth to process them
right at the moment, and it often helps to wait until the list traffic
becomes calmer before sending such a reminder.

The list archive is available at a few public sites:

        http://news.gmane.org/gmane.comp.version-control.git/
        http://marc.info/?l=git
        http://www.spinics.net/lists/git/

For those who prefer to read it over NNTP:

        nntp://news.gmane.org/gmane.comp.version-control.git

When you point at a message in a mailing list archive, using
gmane is often the easiest to follow by readers, like this:

        http://thread.gmane.org/gmane.comp.version-control.git/27/focus=217

as it also allows people who subscribe to the mailing list as gmane
newsgroup to "jump to" the article.

Some members of the development community can sometimes be found on
the #git and #git-devel IRC channels on Freenode.  Their logs are
available at:

        http://colabti.org/irclogger/irclogger_log/git
        http://colabti.org/irclogger/irclogger_log/git-devel

There is a volunteer-run newsletter to serve our community ("Git Rev
News" http://git.github.io/rev_news/rev_news.html).

Git is a member project of software freedom conservancy, a non-profit
organization (https://sfconservancy.org/).  To reach a committee of
liaisons to the conservancy, contact them at <git@sfconservancy.org>.


* Reporting bugs

When you think git does not behave as you expect, please do not stop
your bug report with just "git does not work".  "I used git in this
way, but it did not work" is not much better, neither is "I used git
in this way, and X happend, which is broken".  It often is that git is
correct to cause X happen in such a case, and it is your expectation
that is broken. People would not know what other result Y you expected
to see instead of X, if you left it unsaid.

Please remember to always state

 - what you wanted to achieve;

 - what you did (the version of git and the command sequence to reproduce
   the behavior);

 - what you saw happen (X above);

 - what you expected to see (Y above); and

 - how the last two are different.

See http://www.chiark.greenend.org.uk/~sgtatham/bugs.html for further
hints.

If you think you found a security-sensitive issue and want to disclose
it to us without announcing it to wider public, please contact us at
our security mailing list <git-security@googlegroups.com>.


* Repositories and documentation.

My public git.git repositories are at:

  git://git.kernel.org/pub/scm/git/git.git/
  https://kernel.googlesource.com/pub/scm/git/git
  git://repo.or.cz/alt-git.git/
  https://github.com/git/git/
  git://git.sourceforge.jp/gitroot/git-core/git.git/
  git://git-core.git.sourceforge.net/gitroot/git-core/git-core/

A few web interfaces are found at:

  http://git.kernel.org/cgit/git/git.git
  https://kernel.googlesource.com/pub/scm/git/git
  http://repo.or.cz/w/alt-git.git

Preformatted documentation from the tip of the "master" branch can be
found in:

  git://git.kernel.org/pub/scm/git/git-{htmldocs,manpages}.git/
  git://repo.or.cz/git-{htmldocs,manpages}.git/
  https://github.com/gitster/git-{htmldocs,manpages}.git/

Also GitHub shows the manual pages formatted in HTML (with a
formatting backend different from the one that is used to create the
above) at:

  http://git-scm.com/docs/git


* How various branches are used.

There are four branches in git.git repository that track the source tree
of git: "master", "maint", "next", and "pu".

The "master" branch is meant to contain what are very well tested and
ready to be used in a production setting.  Every now and then, a
"feature release" is cut from the tip of this branch.  They used to be
named with three dotted decimal digits (e.g. "1.8.5"), but recently we
switched the versioning scheme and "feature releases" are named with
three-dotted decimal digits that ends with ".0" (e.g. "1.9.0").

The last such release was 2.7.0 done on Jan 4th, 2016. You can expect
that the tip of the "master" branch is always more stable than any of
the released versions.

Whenever a feature release is made, "maint" branch is forked off from
"master" at that point.  Obvious, safe and urgent fixes after a
feature release are applied to this branch and maintenance releases
are cut from it.  The maintenance releases used to be named with four
dotted decimal, named after the feature release they are updates to
(e.g. "1.8.5.1" was the first maintenance release for "1.8.5" feature
release).  These days, maintenance releases are named by incrementing
the last digit of three-dotted decimal name (e.g. "2.6.3" is the
third maintenance release for the "2.6" series).

New features never go to the 'maint' branch.  This branch is also
merged into "master" to propagate the fixes forward as needed.

A new development does not usually happen on "master". When you send a
series of patches, after review on the mailing list, a separate topic
branch is forked from the tip of "master" and your patches are queued
there, and kept out of "master" while people test it out. The quality of
topic branches are judged primarily by the mailing list discussions.

Topic branches that are in good shape are merged to the "next" branch. In
general, the "next" branch always contains the tip of "master".  It might
not be quite rock-solid, but is expected to work more or less without major
breakage. The "next" branch is where new and exciting things take place. A
topic that is in "next" is expected to be polished to perfection before it
is merged to "master".  Please help this process by building & using the
"next" branch for your daily work, and reporting any new bugs you find to
the mailing list, before the breakage is merged down to the "master".

The "pu" (proposed updates) branch bundles all the remaining topic
branches the maintainer happens to have seen.  There is no guarantee that
the maintainer has enough bandwidth to pick up any and all topics that
are remotely promising from the list traffic, so please do not read
too much into a topic being on (or not on) the "pu" branch.  This
branch is mainly to remind the maintainer that the topics in them may
turn out to be interesting when they are polished, nothing more.  The
topics on this branch aren't usually complete, well tested, or well
documented and they often need further work.  When a topic that was
in "pu" proves to be in a testable shape, it is merged to "next".

You can run "git log --first-parent master..pu" to see what topics are
currently in flight.  Sometimes, an idea that looked promising turns out
to be not so good and the topic can be dropped from "pu" in such a case.

The two branches "master" and "maint" are never rewound, and "next"
usually will not be either.  After a feature release is made from
"master", however, "next" will be rebuilt from the tip of "master"
using the topics that didn't make the cut in the feature release.

Note that being in "next" is not a guarantee to appear in the next
release, nor even in any future release.  There were cases that topics
needed reverting a few commits in them before graduating to "master",
or a topic that already was in "next" was reverted from "next" because
fatal flaws were found in it after it was merged to "next".


* Other people's trees.

Documentation/SubmittingPatches outlines to whom your proposed changes
should be sent.  As described in contrib/README, I would delegate fixes
and enhancements in contrib/ area to the primary contributors of them.

Although the following are included in git.git repository, they have their
own authoritative repository and maintainers:

 - git-gui/ comes from git-gui project, maintained by Pat Thoyts:

        git://repo.or.cz/git-gui.git

 - gitk-git/ comes from Paul Mackerras's gitk project:

        git://ozlabs.org/~paulus/gitk

 - po/ comes from the localization coordinator, Jiang Xin:

	https://github.com/git-l10n/git-po/

When sending proposed updates and fixes to these parts of the system,
please base your patches on these trees, not git.git (the former two
even have different directory structures).

A note from the maintainer

[Junio C Hamano]

Welcome to the Git development community.

This message is written by the maintainer and talks about how Git
project is managed, and how you can work with it.

* Mailing list and the community

The development is primarily done on the Git mailing list. Help
requests, feature proposals, bug reports and patches should be sent to
the list address <git@vger.kernel.org>.  You don't have to be
subscribed to send messages.  The convention on the list is to keep
everybody involved on Cc:, so it is unnecessary to say "Please Cc: me,
I am not subscribed".

Before sending patches, please read Documentation/SubmittingPatches
and Documentation/CodingGuidelines to familiarize yourself with the
project convention.

If you sent a patch and you did not hear any response from anybody for
several days, it could be that your patch was totally uninteresting,
but it also is possible that it was simply lost in the noise.  Please
do not hesitate to send a reminder message in such a case.  Messages
getting lost in the noise may be a sign that those who can evaluate
your patch don't have enough mental/time bandwidth to process them
right at the moment, and it often helps to wait until the list traffic
becomes calmer before sending such a reminder.

The list archive is available at a few public sites:

        http://news.gmane.org/gmane.comp.version-control.git/
        http://marc.theaimsgroup.com/?l=git
        http://www.spinics.net/lists/git/

For those who prefer to read it over NNTP:

        nntp://news.gmane.org/gmane.comp.version-control.git

When you point at a message in a mailing list archive, using
gmane is often the easiest to follow by readers, like this:

        http://thread.gmane.org/gmane.comp.version-control.git/27/focus=217

as it also allows people who subscribe to the mailing list as gmane
newsgroup to "jump to" the article.

Some members of the development community can sometimes be found on
the #git and #git-devel IRC channels on Freenode.  Their logs are
available at:

        http://colabti.org/irclogger/irclogger_log/git
        http://colabti.org/irclogger/irclogger_log/git-devel

There is a volunteer-run newsletter to serve our community ("Git Rev
News" http://git.github.io/rev_news/rev_news.html).

Git is a member project of software freedom conservancy, a non-profit
organization (https://sfconservancy.org/).  To reach a committee of
liaisons to the conservancy, contact them at <git@sfconservancy.org>.


* Reporting bugs

When you think git does not behave as you expect, please do not stop
your bug report with just "git does not work".  "I used git in this
way, but it did not work" is not much better, neither is "I used git
in this way, and X happend, which is broken".  It often is that git is
correct to cause X happen in such a case, and it is your expectation
that is broken. People would not know what other result Y you expected
to see instead of X, if you left it unsaid.

Please remember to always state

 - what you wanted to achieve;

 - what you did (the version of git and the command sequence to reproduce
   the behavior);

 - what you saw happen (X above);

 - what you expected to see (Y above); and

 - how the last two are different.

See http://www.chiark.greenend.org.uk/~sgtatham/bugs.html for further
hints.

If you think you found a security-sensitive issue and want to disclose
it to us without announcing it to wider public, please contact us at
our security mailing list <git-security@googlegroups.com>.


* Repositories, branches and documentation.

My public git.git repositories are at:

  git://git.kernel.org/pub/scm/git/git.git/
  https://kernel.googlesource.com/pub/scm/git/git
  git://repo.or.cz/alt-git.git/
  https://github.com/git/git/
  git://git.sourceforge.jp/gitroot/git-core/git.git/
  git://git-core.git.sourceforge.net/gitroot/git-core/git-core/

A few web interfaces are found at:

  http://git.kernel.org/cgit/git/git.git
  https://kernel.googlesource.com/pub/scm/git/git
  http://repo.or.cz/w/alt-git.git

Preformatted documentation from the tip of the "master" branch can be
found in:

  git://git.kernel.org/pub/scm/git/git-{htmldocs,manpages}.git/
  git://repo.or.cz/git-{htmldocs,manpages}.git/
  https://github.com/gitster/git-{htmldocs,manpages}.git/

Also GitHub shows the manual pages formatted in HTML (with a
formatting backend different from the one that is used to create the
above) at:

  http://git-scm.com/docs/git

There are four branches in git.git repository that track the source tree
of git: "master", "maint", "next", and "pu".

The "master" branch is meant to contain what are very well tested and
ready to be used in a production setting.  Every now and then, a
"feature release" is cut from the tip of this branch.  They used to be
named with three dotted decimal digits (e.g. "1.8.5"), but recently we
switched the versioning scheme and "feature releases" are named with
three-dotted decimal digits that ends with ".0" (e.g. "1.9.0").

The last such release was 2.6.0 done on Sep 28th, 2015. You can expect
that the tip of the "master" branch is always more stable than any of
the released versions.

Whenever a feature release is made, "maint" branch is forked off from
"master" at that point.  Obvious, safe and urgent fixes after a
feature release are applied to this branch and maintenance releases
are cut from it.  The maintenance releases used to be named with four
dotted decimal, named after the feature release they are updates to
(e.g. "1.8.5.1" was the first maintenance release for "1.8.5" feature
release).  These days, maintenance releases are named by incrementing
the last digit of three-dotted decimal name (e.g. "2.6.3" is the
third maintenance release for the "2.6" series).

New features never go to the 'maint' branch.  This branch is also
merged into "master" to propagate the fixes forward as needed.

A new development does not usually happen on "master". When you send a
series of patches, after review on the mailing list, a separate topic
branch is forked from the tip of "master" and your patches are queued
there, and kept out of "master" while people test it out. The quality of
topic branches are judged primarily by the mailing list discussions.

Topic branches that are in good shape are merged to the "next" branch. In
general, the "next" branch always contains the tip of "master".  It might
not be quite rock-solid, but is expected to work more or less without major
breakage. The "next" branch is where new and exciting things take place. A
topic that is in "next" is expected to be polished to perfection before it
is merged to "master".  Please help this process by building & using the
"next" branch for your daily work, and reporting any new bugs you find to
the mailing list, before the breakage is merged down to the "master".

The "pu" (proposed updates) branch bundles all the remaining topic
branches the maintainer happens to have seen.  There is no guarantee that
the maintainer has enough bandwidth to pick up any and all topics that
are remotely promising from the list traffic, so please do not read
too much into a topic being on (or not on) the "pu" branch.  This
branch is mainly to remind the maintainer that the topics in them may
turn out to be interesting when they are polished, nothing more.  The
topics on this branch aren't usually complete, well tested, or well
documented and they often need further work.  When a topic that was
in "pu" proves to be in a testable shape, it is merged to "next".

You can run "git log --first-parent master..pu" to see what topics are
currently in flight.  Sometimes, an idea that looked promising turns out
to be not so good and the topic can be dropped from "pu" in such a case.

The two branches "master" and "maint" are never rewound, and "next"
usually will not be either.  After a feature release is made from
"master", however, "next" will be rebuilt from the tip of "master"
using the topics that didn't make the cut in the feature release.

Note that being in "next" is not a guarantee to appear in the next
release, nor even in any future release.  There were cases that topics
needed reverting a few commits in them before graduating to "master",
or a topic that already was in "next" was reverted from "next" because
fatal flaws were found in it after it was merged to "next".


* Other people's trees.

Documentation/SubmittingPatches outlines to whom your proposed changes
should be sent.  As described in contrib/README, I would delegate fixes
and enhancements in contrib/ area to the primary contributors of them.

Although the following are included in git.git repository, they have their
own authoritative repository and maintainers:

 - git-gui/ comes from git-gui project, maintained by Pat Thoyts:

        git://repo.or.cz/git-gui.git

 - gitk-git/ comes from Paul Mackerras's gitk project:

        git://ozlabs.org/~paulus/gitk

 - po/ comes from the localization coordinator, Jiang Xin:

	https://github.com/git-l10n/git-po/

When sending proposed updates and fixes to these parts of the system,
please base your patches on these trees, not git.git (the former two
even have different directory structures).

Re: A note from the maintainer

[Xue Fuqiao]

Hi Junio,

Thanks for writing this note!  It is very helpful.

On Fri, Nov 6, 2015 at 7:14 AM, Junio C Hamano <gitster@pobox.com> wrote:
> The list archive is available at a few public sites:
>
>         http://news.gmane.org/gmane.comp.version-control.git/
>         http://marc.theaimsgroup.com/?l=git
>         http://www.spinics.net/lists/git/

The second link is broken.  The following link is the correct version
now:

https://marc.info/?l=git

Re: A note from the maintainer

[Junio C Hamano]

Thanks.  I've known about the URL moving to marc.info for a long
time, and I am kind of surprised that I had this stale one left
un-updated for so long.

Fixed.

A note from the maintainer

[Junio C Hamano]

Welcome to the Git development community.

This message is written by the maintainer and talks about how Git
project is managed, and how you can work with it.

* Mailing list and the community

The development is primarily done on the Git mailing list. Help
requests, feature proposals, bug reports and patches should be sent to
the list address <git@vger.kernel.org>.  You don't have to be
subscribed to send messages.  The convention on the list is to keep
everybody involved on Cc:, so it is unnecessary to say "Please Cc: me,
I am not subscribed".

Before sending patches, please read Documentation/SubmittingPatches
and Documentation/CodingGuidelines to familiarize yourself with the
project convention.

If you sent a patch and you did not hear any response from anybody for
several days, it could be that your patch was totally uninteresting,
but it also is possible that it was simply lost in the noise.  Please
do not hesitate to send a reminder message in such a case.  Messages
getting lost in the noise may be a sign that those who can evaluate
your patch don't have enough mental/time bandwidth to process them
right at the moment, and it often helps to wait until the list traffic
becomes calmer before sending such a reminder.

The list archive is available at a few public sites:

        http://news.gmane.org/gmane.comp.version-control.git/
        http://marc.theaimsgroup.com/?l=git
        http://www.spinics.net/lists/git/

For those who prefer to read it over NNTP:

        nntp://news.gmane.org/gmane.comp.version-control.git

When you point at a message in a mailing list archive, using
gmane is often the easiest to follow by readers, like this:

        http://thread.gmane.org/gmane.comp.version-control.git/27/focus=217

as it also allows people who subscribe to the mailing list as gmane
newsgroup to "jump to" the article.

Some members of the development community can sometimes be found on
the #git and #git-devel IRC channels on Freenode.  Their logs are
available at:

        http://colabti.org/irclogger/irclogger_log/git
        http://colabti.org/irclogger/irclogger_log/git-devel

There is a volunteer-run newsletter to serve our community ("Git Rev
News" http://git.github.io/rev_news/rev_news.html).

Git is a member project of software freedom conservancy, a non-profit
organization (https://sfconservancy.org/).  To reach a committee of
liaisons to the conservancy, contact them at <git@sfconservancy.org>.


* Reporting bugs

When you think git does not behave as you expect, please do not stop
your bug report with just "git does not work".  "I used git in this
way, but it did not work" is not much better, neither is "I used git
in this way, and X happend, which is broken".  It often is that git is
correct to cause X happen in such a case, and it is your expectation
that is broken. People would not know what other result Y you expected
to see instead of X, if you left it unsaid.

Please remember to always state

 - what you wanted to achieve;

 - what you did (the version of git and the command sequence to reproduce
   the behavior);

 - what you saw happen (X above);

 - what you expected to see (Y above); and

 - how the last two are different.

See http://www.chiark.greenend.org.uk/~sgtatham/bugs.html for further
hints.

If you think you found a security-sensitive issue and want to disclose
it to us without announcing it to wider public, please contact us at
our security mailing list <git-security@googlegroups.com>.


* Repositories, branches and documentation.

My public git.git repositories are at:

  git://git.kernel.org/pub/scm/git/git.git/
  https://kernel.googlesource.com/pub/scm/git/git
  git://repo.or.cz/alt-git.git/
  https://github.com/git/git/
  git://git.sourceforge.jp/gitroot/git-core/git.git/
  git://git-core.git.sourceforge.net/gitroot/git-core/git-core/

A few web interfaces are found at:

  http://git.kernel.org/cgit/git/git.git
  https://kernel.googlesource.com/pub/scm/git/git
  http://repo.or.cz/w/alt-git.git

Preformatted documentation from the tip of the "master" branch can be
found in:

  git://git.kernel.org/pub/scm/git/git-{htmldocs,manpages}.git/
  git://repo.or.cz/git-{htmldocs,manpages}.git/
  https://github.com/gitster/git-{htmldocs,manpages}.git/

Also GitHub shows the manual pages formatted in HTML (with a
formatting backend different from the one that is used to create the
above) at:

  http://git-scm.com/docs/git

There are four branches in git.git repository that track the source tree
of git: "master", "maint", "next", and "pu".

The "master" branch is meant to contain what are very well tested and
ready to be used in a production setting.  Every now and then, a
"feature release" is cut from the tip of this branch.  They used to be
named with three dotted decimal digits (e.g. "1.8.5"), but recently we
switched the versioning scheme and "feature releases" are named with
three-dotted decimal digits that ends with ".0" (e.g. "1.9.0").

The last such release was 2.6.0 done on Sep 28th, 2015. You can expect
that the tip of the "master" branch is always more stable than any of
the released versions.

Whenever a feature release is made, "maint" branch is forked off from
"master" at that point.  Obvious, safe and urgent fixes after a
feature release are applied to this branch and maintenance releases
are cut from it.  The maintenance releases used to be named with four
dotted decimal, named after the feature release they are updates to
(e.g. "1.8.5.1" was the first maintenance release for "1.8.5" feature
release).  These days, maintenance releases are named by incrementing
the last digit of three-dotted decimal name (e.g. "2.5.1" is the
fourth maintenance release for the "2.5" series).

New features never go to the 'maint' branch.  This branch is also
merged into "master" to propagate the fixes forward as needed.

A new development does not usually happen on "master". When you send a
series of patches, after review on the mailing list, a separate topic
branch is forked from the tip of "master" and your patches are queued
there, and kept out of "master" while people test it out. The quality of
topic branches are judged primarily by the mailing list discussions.

Topic branches that are in good shape are merged to the "next" branch. In
general, the "next" branch always contains the tip of "master".  It might
not be quite rock-solid, but is expected to work more or less without major
breakage. The "next" branch is where new and exciting things take place. A
topic that is in "next" is expected to be polished to perfection before it
is merged to "master".  Please help this process by building, using the
"next" branch for your daily work, and reporting any new bugs you find to
the mailing list, before the breakage is merged down to the "master".

The "pu" (proposed updates) branch bundles all the remaining topic
branches the maintainer happens to have.  There is no guarantee that
the maintainer has enough bandwidth to pick up any and all topics that
are remotely promising from the list traffic, so please do not read
too much into a topic being on (or not on) the "pu" branch.  This
branch is mainly to remind the maintainer that the topics in them may
turn out to be interesting when they are polished, nothing more.  The
topics on this branch aren't usually complete, well tested, or well
documented and they often need further work.  When a topic that was
in "pu" proves to be in a testable shape, it is merged to "next".

You can run "git log --first-parent master..pu" to see what topics are
currently in flight.  Sometimes, an idea that looked promising turns out
to be not so good and the topic can be dropped from "pu" in such a case.

The two branches "master" and "maint" are never rewound, and "next"
usually will not be either.  After a feature release is made from
"master", however, "next" will be rebuilt from the tip of "master"
using the topics that didn't make the cut in the feature release.

Note that being in "next" is not a guarantee to appear in the next
release, nor even in any future release.  There were cases that topics
needed reverting a few commits in them before graduating to "master",
or a topic that already was in "next" was reverted from "next" because
fatal flaws were found in it after it was merged to "next".


* Other people's trees, trusted lieutenants and credits.

Documentation/SubmittingPatches outlines to whom your proposed changes
should be sent.  As described in contrib/README, I would delegate fixes
and enhancements in contrib/ area to the primary contributors of them.

Although the following are included in git.git repository, they have their
own authoritative repository and maintainers:

 - git-gui/ comes from git-gui project, maintained by Pat Thoyts:

        git://repo.or.cz/git-gui.git

 - gitk-git/ comes from Paul Mackerras's gitk project:

        git://ozlabs.org/~paulus/gitk

 - po/ comes from the localization coordinator, Jiang Xin:

	https://github.com/git-l10n/git-po/

A note from the maintainer

[Junio C Hamano]

Welcome to the Git development community.

This message is written by the maintainer and talks about how Git
project is managed, and how you can work with it.

* Mailing list and the community

The development is primarily done on the Git mailing list. Help
requests, feature proposals, bug reports and patches should be sent to
the list address <git@vger.kernel.org>.  You don't have to be
subscribed to send messages.  The convention on the list is to keep
everybody involved on Cc:, so it is unnecessary to say "Please Cc: me,
I am not subscribed".

Before sending patches, please read Documentation/SubmittingPatches
and Documentation/CodingGuidelines to familiarize yourself with the
project convention.

If you sent a patch and you did not hear any response from anybody for
several days, it could be that your patch was totally uninteresting,
but it also is possible that it was simply lost in the noise.  Please
do not hesitate to send a reminder message in such a case.  Messages
getting lost in the noise may be a sign that those who can evaluate
your patch don't have enough mental/time bandwidth to process them
right at the moment, and it often helps to wait until the list traffic
becomes calmer before sending such a reminder.

The list archive is available at a few public sites:

        http://news.gmane.org/gmane.comp.version-control.git/
        http://marc.theaimsgroup.com/?l=git
        http://www.spinics.net/lists/git/

For those who prefer to read it over NNTP:

        nntp://news.gmane.org/gmane.comp.version-control.git

When you point at a message in a mailing list archive, using
gmane is often the easiest to follow by readers, like this:

        http://thread.gmane.org/gmane.comp.version-control.git/27/focus=217

as it also allows people who subscribe to the mailing list as gmane
newsgroup to "jump to" the article.

Some members of the development community can sometimes be found on
the #git and #git-devel IRC channels on Freenode.  Their logs are
available at:

        http://colabti.org/irclogger/irclogger_log/git
        http://colabti.org/irclogger/irclogger_log/git-devel

There is a volunteer-run newsletter to serve our community ("Git Rev
News" http://git.github.io/rev_news/rev_news.html).

Git is a member project of software freedom conservancy, a non-profit
organization (https://sfconservancy.org/).  To reach a committee of
liaisons to the conservancy, contact them at <git@sfconservancy.org>.


* Reporting bugs

When you think git does not behave as you expect, please do not stop
your bug report with just "git does not work".  "I used git in this
way, but it did not work" is not much better, neither is "I used git
in this way, and X happend, which is broken".  It often is that git is
correct to cause X happen in such a case, and it is your expectation
that is broken. People would not know what other result Y you expected
to see instead of X, if you left it unsaid.

Please remember to always state

 - what you wanted to achieve;

 - what you did (the version of git and the command sequence to reproduce
   the behavior);

 - what you saw happen (X above);

 - what you expected to see (Y above); and

 - how the last two are different.

See http://www.chiark.greenend.org.uk/~sgtatham/bugs.html for further
hints.

If you think you found a security-sensitive issue and want to disclose
it to us without announcing it to wider public, please contact us at
our security mailing list <git-security@googlegroups.com>.


* Repositories, branches and documentation.

My public git.git repositories are at:

  git://git.kernel.org/pub/scm/git/git.git/
  https://kernel.googlesource.com/pub/scm/git/git
  git://repo.or.cz/alt-git.git/
  https://github.com/git/git/
  git://git.sourceforge.jp/gitroot/git-core/git.git/
  git://git-core.git.sourceforge.net/gitroot/git-core/git-core/

A few web interfaces are found at:

  http://git.kernel.org/cgit/git/git.git
  https://kernel.googlesource.com/pub/scm/git/git
  http://repo.or.cz/w/alt-git.git

Preformatted documentation from the tip of the "master" branch can be
found in:

  git://git.kernel.org/pub/scm/git/git-{htmldocs,manpages}.git/
  git://repo.or.cz/git-{htmldocs,manpages}.git/
  https://github.com/gitster/git-{htmldocs,manpages}.git/

Also GitHub shows the manual pages formatted in HTML (with a
formatting backend different from the one that is used to create the
above) at:

  http://git-scm.com/docs/git

There are four branches in git.git repository that track the source tree
of git: "master", "maint", "next", and "pu".

The "master" branch is meant to contain what are very well tested and
ready to be used in a production setting.  Every now and then, a
"feature release" is cut from the tip of this branch.  They used to be
named with three dotted decimal digits (e.g. "1.8.5"), but recently we
switched the versioning scheme and "feature releases" are named with
three-dotted decimal digits that ends with ".0" (e.g. "1.9.0").

The last such release was 2.5.0 done on Jul 27th, 2015. You can expect
that the tip of the "master" branch is always more stable than any of
the released versions.

Whenever a feature release is made, "maint" branch is forked off from
"master" at that point.  Obvious, safe and urgent fixes after a
feature release are applied to this branch and maintenance releases
are cut from it.  The maintenance releases used to be named with four
dotted decimal, named after the feature release they are updates to
(e.g. "1.8.5.1" was the first maintenance release for "1.8.5" feature
release).  These days, maintenance releases are named by incrementing
the last digit of three-dotted decimal name (e.g. "2.5.1" is the
fourth maintenance release for the "2.5" series).

New features never go to the 'maint' branch.  This branch is also
merged into "master" to propagate the fixes forward as needed.

A new development does not usually happen on "master". When you send a
series of patches, after review on the mailing list, a separate topic
branch is forked from the tip of "master" and your patches are queued
there, and kept out of "master" while people test it out. The quality of
topic branches are judged primarily by the mailing list discussions.

Topic branches that are in good shape are merged to the "next" branch. In
general, the "next" branch always contains the tip of "master".  It might
not be quite rock-solid, but is expected to work more or less without major
breakage. The "next" branch is where new and exciting things take place. A
topic that is in "next" is expected to be polished to perfection before it
is merged to "master".  Please help this process by building, using the
"next" branch for your daily work, and reporting any new bugs you find to
the mailing list, before the breakage is merged down to the "master".

The "pu" (proposed updates) branch bundles all the remaining topic
branches the maintainer happens to have.  There is no guarantee that
the maintainer has enough bandwidth to pick up any and all topics that
are remotely promising from the list traffic, so please do not read
too much into a topic being on (or not on) the "pu" branch.  This
branch is mainly to remind the maintainer that the topics in them may
turn out to be interesting when they are polished, nothing more.  The
topics on this branch aren't usually complete, well tested, or well
documented and they often need further work.  When a topic that was
in "pu" proves to be in a testable shape, it is merged to "next".

You can run "git log --first-parent master..pu" to see what topics are
currently in flight.  Sometimes, an idea that looked promising turns out
to be not so good and the topic can be dropped from "pu" in such a case.

The two branches "master" and "maint" are never rewound, and "next"
usually will not be either.  After a feature release is made from
"master", however, "next" will be rebuilt from the tip of "master"
using the topics that didn't make the cut in the feature release.

Note that being in "next" is not a guarantee to appear in the next
release, nor even in any future release.  There were cases that topics
needed reverting a few commits in them before graduating to "master",
or a topic that already was in "next" was reverted from "next" because
fatal flaws were found in it after it was merged to "next".


* Other people's trees, trusted lieutenants and credits.

Documentation/SubmittingPatches outlines to whom your proposed changes
should be sent.  As described in contrib/README, I would delegate fixes
and enhancements in contrib/ area to the primary contributors of them.

Although the following are included in git.git repository, they have their
own authoritative repository and maintainers:

 - git-gui/ comes from git-gui project, maintained by Pat Thoyts:

        git://repo.or.cz/git-gui.git

 - gitk-git/ comes from Paul Mackerras's gitk project:

        git://ozlabs.org/~paulus/gitk

 - po/ comes from the localization coordinator, Jiang Xin:

	https://github.com/git-l10n/git-po/

A note from the maintainer

[Junio C Hamano]

Welcome to the Git development community.

This message is written by the maintainer and talks about how Git
project is managed, and how you can work with it.

* Mailing list and the community

The development is primarily done on the Git mailing list. Help
requests, feature proposals, bug reports and patches should be sent to
the list address <git@vger.kernel.org>.  You don't have to be
subscribed to send messages.  The convention on the list is to keep
everybody involved on Cc:, so it is unnecessary to say "Please Cc: me,
I am not subscribed".

Before sending patches, please read Documentation/SubmittingPatches
and Documentation/CodingGuidelines to familiarize yourself with the
project convention.

If you sent a patch and you did not hear any response from anybody for
several days, it could be that your patch was totally uninteresting,
but it also is possible that it was simply lost in the noise.  Please
do not hesitate to send a reminder message in such a case.  Messages
getting lost in the noise may be a sign that those who can evaluate
your patch don't have enough mental/time bandwidth to process them
right at the moment, and it often helps to wait until the list traffic
becomes calmer before sending such a reminder.

The list archive is available at a few public sites:

        http://news.gmane.org/gmane.comp.version-control.git/
        http://marc.theaimsgroup.com/?l=git
        http://www.spinics.net/lists/git/

For those who prefer to read it over NNTP:

        nntp://news.gmane.org/gmane.comp.version-control.git

When you point at a message in a mailing list archive, using
gmane is often the easiest to follow by readers, like this:

        http://thread.gmane.org/gmane.comp.version-control.git/27/focus=217

as it also allows people who subscribe to the mailing list as gmane
newsgroup to "jump to" the article.

Some members of the development community can sometimes be found on
the #git and #git-devel IRC channels on Freenode.  Their logs are
available at:

        http://colabti.org/irclogger/irclogger_log/git
        http://colabti.org/irclogger/irclogger_log/git-devel

There is a volunteer-run newsletter to serve our community ("Git Rev
News" http://git.github.io/rev_news/rev_news.html).

Git is a member project of software freedom conservancy, a non-profit
organization (https://sfconservancy.org/).  To reach a committee of
liaisons to the conservancy, contact them at <git@sfconservancy.org>.


* Reporting bugs

When you think git does not behave as you expect, please do not stop
your bug report with just "git does not work".  "I used git in this
way, but it did not work" is not much better, neither is "I used git
in this way, and X happend, which is broken".  It often is that git is
correct to cause X happen in such a case, and it is your expectation
that is broken. People would not know what other result Y you expected
to see instead of X, if you left it unsaid.

Please remember to always state

 - what you wanted to achieve;

 - what you did (the version of git and the command sequence to reproduce
   the behavior);

 - what you saw happen (X above);

 - what you expected to see (Y above); and

 - how the last two are different.

See http://www.chiark.greenend.org.uk/~sgtatham/bugs.html for further
hints.

If you think you found a security-sensitive issue and want to disclose
it to us without announcing it to wider public, please contact us at
our security mailing list <git-security@googlegroups.com>.


* Repositories, branches and documentation.

My public git.git repositories are at:

  git://git.kernel.org/pub/scm/git/git.git/
  https://kernel.googlesource.com/pub/scm/git/git
  git://repo.or.cz/alt-git.git/
  https://github.com/git/git/
  https://code.google.com/p/git-core/
  git://git.sourceforge.jp/gitroot/git-core/git.git/
  git://git-core.git.sourceforge.net/gitroot/git-core/git-core/

A few web interfaces are found at:

  http://git.kernel.org/cgit/git/git.git
  https://kernel.googlesource.com/pub/scm/git/git
  http://repo.or.cz/w/alt-git.git

Preformatted documentation from the tip of the "master" branch can be
found in:

  git://git.kernel.org/pub/scm/git/git-{htmldocs,manpages}.git/
  git://repo.or.cz/git-{htmldocs,manpages}.git/
  https://code.google.com/p/git-{htmldocs,manpages}.git/
  https://github.com/gitster/git-{htmldocs,manpages}.git/

Also GitHub shows the manual pages formatted in HTML (with a
formatting backend different from the one that is used to create the
above) at:

  http://git-scm.com/docs/git

There are four branches in git.git repository that track the source tree
of git: "master", "maint", "next", and "pu".

The "master" branch is meant to contain what are very well tested and
ready to be used in a production setting.  Every now and then, a
"feature release" is cut from the tip of this branch.  They used to be
named with three dotted decimal digits (e.g. "1.8.5"), but recently we
switched the versioning scheme and "feature releases" are named with
three-dotted decimal digits that ends with ".0" (e.g. "1.9.0").

The last such release was 2.4.0 done on Apr 30th, 2015. You can expect
that the tip of the "master" branch is always more stable than any of
the released versions.

Whenever a feature release is made, "maint" branch is forked off from
"master" at that point.  Obvious, safe and urgent fixes after a
feature release are applied to this branch and maintenance releases
are cut from it.  The maintenance releases used to be named with four
dotted decimal, named after the feature release they are updates to
(e.g. "1.8.5.1" was the first maintenance release for "1.8.5" feature
release).  These days, maintenance releases are named by incrementing
the last digit of three-dotted decimal name (e.g. "2.3.4" is the
fourth maintenance release for the "2.3" series).

New features never go to the 'maint' branch.  This branch is also
merged into "master" to propagate the fixes forward as needed.

A new development does not usually happen on "master". When you send a
series of patches, after review on the mailing list, a separate topic
branch is forked from the tip of "master" and your patches are queued
there, and kept out of "master" while people test it out. The quality of
topic branches are judged primarily by the mailing list discussions.

Topic branches that are in good shape are merged to the "next" branch. In
general, the "next" branch always contains the tip of "master".  It might
not be quite rock-solid, but is expected to work more or less without major
breakage. The "next" branch is where new and exciting things take place. A
topic that is in "next" is expected to be polished to perfection before it
is merged to "master".  Please help this process by building, using the
"next" branch for your daily work, and reporting any new bugs you find to
the mailing list, before the breakage is merged down to the "master".

The "pu" (proposed updates) branch bundles all the remaining topic
branches the maintainer happens to have.  There is no guarantee that
the maintainer has enough bandwidth to pick up any and all topics that
are remotely promising from the list traffic, so please do not read
too much into a topic being on (or not on) the "pu" branch.  This
branch is mainly to remind the maintainer that the topics in them may
turn out to be interesting when they are polished, nothing more.  The
topics on this branch aren't usually complete, well tested, or well
documented and they often need further work.  When a topic that was
in "pu" proves to be in a testable shape, it is merged to "next".

You can run "git log --first-parent master..pu" to see what topics are
currently in flight.  Sometimes, an idea that looked promising turns out
to be not so good and the topic can be dropped from "pu" in such a case.

The two branches "master" and "maint" are never rewound, and "next"
usually will not be either.  After a feature release is made from
"master", however, "next" will be rebuilt from the tip of "master"
using the topics that didn't make the cut in the feature release.

Note that being in "next" is not a guarantee to appear in the next
release, nor even in any future release.  There were cases that topics
needed reverting a few commits in them before graduating to "master",
or a topic that already was in "next" was reverted from "next" because
fatal flaws were found in it after it was merged to "next".


* Other people's trees, trusted lieutenants and credits.

Documentation/SubmittingPatches outlines to whom your proposed changes
should be sent.  As described in contrib/README, I would delegate fixes
and enhancements in contrib/ area to the primary contributors of them.

Although the following are included in git.git repository, they have their
own authoritative repository and maintainers:

 - git-gui/ comes from git-gui project, maintained by Pat Thoyts:

        git://repo.or.cz/git-gui.git

 - gitk-git/ comes from Paul Mackerras's gitk project:

        git://ozlabs.org/~paulus/gitk

 - po/ comes from the localization coordinator, Jiang Xin:

	https://github.com/git-l10n/git-po/

A note from the maintainer

[Junio C Hamano]

Welcome to the Git development community.

This message is written by the maintainer and talks about how Git
project is managed, and how you can work with it.

* Mailing list and the community

The development is primarily done on the Git mailing list. Help
requests, feature proposals, bug reports and patches should be sent to
the list address <git@vger.kernel.org>.  You don't have to be
subscribed to send messages.  The convention on the list is to keep
everybody involved on Cc:, so it is unnecessary to say "Please Cc: me,
I am not subscribed".

Before sending patches, please read Documentation/SubmittingPatches
and Documentation/CodingGuidelines to familiarize yourself with the
project convention.

If you sent a patch and you did not hear any response from anybody for
several days, it could be that your patch was totally uninteresting,
but it also is possible that it was simply lost in the noise.  Please
do not hesitate to send a reminder message in such a case.  Messages
getting lost in the noise may be a sign that those who can evaluate
your patch don't have enough mental/time bandwidth to process them
right at the moment, and it often helps to wait until the list traffic
becomes calmer before sending such a reminder.

The list archive is available at a few public sites:

        http://news.gmane.org/gmane.comp.version-control.git/
        http://marc.theaimsgroup.com/?l=git
        http://www.spinics.net/lists/git/

For those who prefer to read it over NNTP:

        nntp://news.gmane.org/gmane.comp.version-control.git

When you point at a message in a mailing list archive, using
gmane is often the easiest to follow by readers, like this:

        http://thread.gmane.org/gmane.comp.version-control.git/27/focus=217

as it also allows people who subscribe to the mailing list as gmane
newsgroup to "jump to" the article.

Some members of the development community can sometimes be found on
the #git and #git-devel IRC channels on Freenode.  Their logs are
available at:

        http://colabti.org/irclogger/irclogger_log/git
        http://colabti.org/irclogger/irclogger_log/git-devel

There is a volunteer-run newsletter to serve our community (visit
http://git.github.io/ to find "Git Rev News").  If you want to help
its publication, please contact Christian and/or Thomas.

Git is a member project of software freedom conservancy, a non-profit
organization (https://sfconservancy.org/).  To reach a committee of
liaisons to the conservancy, contact them at <git@sfconservancy.org>.


* Reporting bugs

When you think git does not behave as you expect, please do not stop
your bug report with just "git does not work".  "I used git in this
way, but it did not work" is not much better, neither is "I used git
in this way, and X happend, which is broken".  It often is that git is
correct to cause X happen in such a case, and it is your expectation
that is broken. People would not know what other result Y you expected
to see instead of X, if you left it unsaid.

Please remember to always state

 - what you wanted to achieve;

 - what you did (the version of git and the command sequence to reproduce
   the behavior);

 - what you saw happen (X above);

 - what you expected to see (Y above); and

 - how the last two are different.

See http://www.chiark.greenend.org.uk/~sgtatham/bugs.html for further
hints.

If you think you found a security-sensitive issue and want to disclose
it to us without announcing it to wider public, please contact us at
our security mailing list <git-security@googlegroups.com>.


* Repositories, branches and documentation.

My public git.git repositories are at:

        git://git.kernel.org/pub/scm/git/git.git/
	https://kernel.googlesource.com/pub/scm/git/git
	git://repo.or.cz/alt-git.git/
	https://github.com/git/git/
	https://code.google.com/p/git-core/
	git://git.sourceforge.jp/gitroot/git-core/git.git/
	git://git-core.git.sourceforge.net/gitroot/git-core/git-core/

A few web interfaces are found at:

        http://git.kernel.org/?p=git/git.git
	https://kernel.googlesource.com/pub/scm/git/git
        http://repo.or.cz/w/alt-git.git

Preformatted documentation from the tip of the "master" branch can be
found in:

        git://git.kernel.org/pub/scm/git/git-{htmldocs,manpages}.git/
        git://repo.or.cz/git-{htmldocs,manpages}.git/
        https://code.google.com/p/git-{htmldocs,manpages}.git/
        https://github.com/gitster/git-{htmldocs,manpages}.git/

Also GitHub shows the manual pages formatted in HTML (with a
formatting backend different from the one that is used to create the
above) at:

	http://git-scm.com/docs/git

There are four branches in git.git repository that track the source tree
of git: "master", "maint", "next", and "pu".

The "master" branch is meant to contain what are very well tested and
ready to be used in a production setting.  Every now and then, a
"feature release" is cut from the tip of this branch.  They used to be
named with three dotted decimal digits (e.g. "1.8.5"), but recently we
switched the versioning scheme and "feature releases" are named with
three-dotted decimal digits that ends with ".0" (e.g. "1.9.0").

The last such release was 2.4.0 done on Apr 30th, 2015. You can expect
that the tip of the "master" branch is always more stable than any of
the released versions.

Whenever a feature release is made, "maint" branch is forked off from
"master" at that point.  Obvious, safe and urgent fixes after a
feature release are applied to this branch and maintenance releases
are cut from it.  The maintenance releases used to be named with four
dotted decimal, named after the feature release they are updates to
(e.g. "1.8.5.1" was the first maintenance release for "1.8.5" feature
release).  These days, maintenance releases are named by incrementing
the last digit of three-dotted decimal name (e.g. "2.3.4" is the
fourth maintenance release for the "2.3" series).

New features never go to the 'maint' branch.  This branch is also
merged into "master" to propagate the fixes forward as needed.

A new development does not usually happen on "master". When you send a
series of patches, after review on the mailing list, a separate topic
branch is forked from the tip of "master" and your patches are queued
there, and kept out of "master" while people test it out. The quality of
topic branches are judged primarily by the mailing list discussions.

Topic branches that are in good shape are merged to the "next" branch. In
general, the "next" branch always contains the tip of "master".  It might
not be quite rock-solid, but is expected to work more or less without major
breakage. The "next" branch is where new and exciting things take place. A
topic that is in "next" is expected to be polished to perfection before it
is merged to "master".

The "pu" (proposed updates) branch bundles all the remaining topic
branches the maintainer happens to have.  There is no guarantee that
the maintainer has enough bandwidth to pick up any and all topics that
are remotely promising from the list traffic, so please do not read
too much into a topic being on (or not on) the "pu" branch.  This
branch is mainly to remind the maintainer that the topics in them may
turn out to be interesting when they are polished, nothing more.  The
topics on this branch aren't usually complete, well tested, or well
documented and they often need further work.  When a topic that was
in "pu" proves to be in a testable shape, it is merged to "next".

You can run "git log --first-parent master..pu" to see what topics are
currently in flight.  Sometimes, an idea that looked promising turns out
to be not so good and the topic can be dropped from "pu" in such a case.

The two branches "master" and "maint" are never rewound, and "next"
usually will not be either.  After a feature release is made from
"master", however, "next" will be rebuilt from the tip of "master"
using the topics that didn't make the cut in the feature release.

Note that being in "next" is not a guarantee to appear in the next
release, nor even in any future release.  There were cases that topics
needed reverting a few commits in them before graduating to "master",
or a topic that already was in "next" was reverted from "next" because
fatal flaws were found in it after it was merged to "next".


* Other people's trees, trusted lieutenants and credits.

Documentation/SubmittingPatches outlines to whom your proposed changes
should be sent.  As described in contrib/README, I would delegate fixes
and enhancements in contrib/ area to the primary contributors of them.

Although the following are included in git.git repository, they have their
own authoritative repository and maintainers:

 - git-gui/ comes from git-gui project, maintained by Pat Thoyts:

        git://repo.or.cz/git-gui.git

 - gitk-git/ comes from Paul Mackerras's gitk project:

        git://ozlabs.org/~paulus/gitk

 - po/ comes from the localization coordinator, Jiang Xin:

	https://github.com/git-l10n/git-po/

Re: A note from the maintainer

[Christian Couder]

Hi Junio,

On Thu, Apr 30, 2015 at 9:51 PM, Junio C Hamano <gitster@pobox.com> wrote:

[...]

> * Other people's trees, trusted lieutenants and credits.

It seems strange to me that the above section title still talks about
"trusted lieutenants and credits" ...

> Documentation/SubmittingPatches outlines to whom your proposed changes
> should be sent.  As described in contrib/README, I would delegate fixes
> and enhancements in contrib/ area to the primary contributors of them.
>
> Although the following are included in git.git repository, they have their
> own authoritative repository and maintainers:
>
>  - git-gui/ comes from git-gui project, maintained by Pat Thoyts:
>
>         git://repo.or.cz/git-gui.git
>
>  - gitk-git/ comes from Paul Mackerras's gitk project:
>
>         git://ozlabs.org/~paulus/gitk
>
>  - po/ comes from the localization coordinator, Jiang Xin:
>
>         https://github.com/git-l10n/git-po/

... but it looks like there is only the "Other people's trees" part of
the message compared to what used to be in this section.

I am still wondering if it has been truncated on purpose or not.

Thanks anyway,
Christian.

Re: A note from the maintainer

[Junio C Hamano]

Christian Couder <christian.couder@gmail.com> writes:

> I am still wondering if it has been truncated on purpose or not.

The document is already too large and people come and go over time.
Maintaining that list becomes time sink, absorbing time better spent
on reviewing and polishing their patches rather than their names in
that list.  Rather than keeping a stale list forever, at some point
I decided to trim and start afresh, perhaps mentioning very notable
contribution from people there if there were any around the time the
message goes out to the list, which hasn't happened.

And with Git Rev News, I probably do not have to worry about it too
much, I hope ;-)

A note from the maintainer

[Junio C Hamano]

[jc: I usually do this at the major release, but because we are
seeing many new folks due to GSoC, and also the newsletter is
getting closer to reality, so here is a special edition.]

Welcome to the Git development community.

This message is written by the maintainer and talks about how Git
project is managed, and how you can work with it.

* Mailing list and the community

The development is primarily done on the Git mailing list. Help
requests, feature proposals, bug reports and patches should be sent to
the list address <git@vger.kernel.org>.  You don't have to be
subscribed to send messages.  The convention on the list is to keep
everybody involved on Cc:, so it is unnecessary to say "Please Cc: me,
I am not subscribed".

Before sending patches, please read Documentation/SubmittingPatches
and Documentation/CodingGuidelines to familiarize yourself with the
project convention.

If you sent a patch and you did not hear any response from anybody for
several days, it could be that your patch was totally uninteresting,
but it also is possible that it was simply lost in the noise.  Please
do not hesitate to send a reminder message in such a case.  Messages
getting lost in the noise may be a sign that those who can evaluate
your patch don't have enough mental/time bandwidth to process them
right at the moment, and it often helps to wait until the list traffic
becomes calmer before sending such a reminder.

The list archive is available at a few public sites:

        http://news.gmane.org/gmane.comp.version-control.git/
        http://marc.theaimsgroup.com/?l=git
        http://www.spinics.net/lists/git/

For those who prefer to read it over NNTP:

        nntp://news.gmane.org/gmane.comp.version-control.git

When you point at a message in a mailing list archive, using
gmane is often the easiest to follow by readers, like this:

        http://thread.gmane.org/gmane.comp.version-control.git/27/focus=217

as it also allows people who subscribe to the mailing list as gmane
newsgroup to "jump to" the article.

Some members of the development community can sometimes be found on
the #git and #git-devel IRC channels on Freenode.  Their logs are
available at:

        http://colabti.org/irclogger/irclogger_log/git
        http://colabti.org/irclogger/irclogger_log/git-devel

We will soon have a volunteer-run newsletter to serve our community
(http://thread.gmane.org/gmane.comp.version-control.git/266066).  If
you want to help its publication, please contact Christian and/or
Thomas.

Git is a member project of software freedom conservancy, a non-profit
organization (https://sfconservancy.org/).  To reach a committee of
liaisons to the conservancy, contact them at <git@sfconservancy.org>.


* Reporting bugs

When you think git does not behave as you expect, please do not stop
your bug report with just "git does not work".  "I used git in this
way, but it did not work" is not much better, neither is "I used git
in this way, and X happend, which is broken".  It often is that git is
correct to cause X happen in such a case, and it is your expectation
that is broken. People would not know what other result Y you expected
to see instead of X, if you left it unsaid.

Please remember to always state

 - what you wanted to achieve;

 - what you did (the version of git and the command sequence to reproduce
   the behavior);

 - what you saw happen (X above);

 - what you expected to see (Y above); and

 - how the last two are different.

See http://www.chiark.greenend.org.uk/~sgtatham/bugs.html for further
hints.

If you think you found a security-sensitive issue and want to disclose
it to us without announcing it to wider public, please contact us at
our security mailing list <git-security@googlegroups.com>.


* Repositories, branches and documentation.

My public git.git repositories are at:

        git://git.kernel.org/pub/scm/git/git.git/
	https://kernel.googlesource.com/pub/scm/git/git
	git://repo.or.cz/alt-git.git/
	https://github.com/git/git/
	https://code.google.com/p/git-core/
	git://git.sourceforge.jp/gitroot/git-core/git.git/
	git://git-core.git.sourceforge.net/gitroot/git-core/git-core/

A few web interfaces are found at:

        http://git.kernel.org/?p=git/git.git
	https://kernel.googlesource.com/pub/scm/git/git
        http://repo.or.cz/w/alt-git.git

Preformatted documentation from the tip of the "master" branch can be
found in:

        git://git.kernel.org/pub/scm/git/git-{htmldocs,manpages}.git/
        git://repo.or.cz/git-{htmldocs,manpages}.git/
        https://code.google.com/p/git-{htmldocs,manpages}.git/
        https://github.com/gitster/git-{htmldocs,manpages}.git/

You can browse the HTML manual pages at:

	http://git-htmldocs.googlecode.com/git/git.html

There are four branches in git.git repository that track the source tree
of git: "master", "maint", "next", and "pu".

The "master" branch is meant to contain what are very well tested and
ready to be used in a production setting.  Every now and then, a
"feature release" is cut from the tip of this branch.  They used to be
named with three dotted decimal digits (e.g. "1.8.5"), but recently we
switched the versioning scheme and "feature releases" are named with
three-dotted decimal digits that ends with ".0" (e.g. "1.9.0").

The last such release was 2.3.0 done on Feb 5th, 2015. You can expect
that the tip of the "master" branch is always more stable than any of
the released versions.

Whenever a feature release is made, "maint" branch is forked off from
"master" at that point.  Obvious, safe and urgent fixes after a
feature release are applied to this branch and maintenance releases
are cut from it.  The maintenance releases used to be named with four
dotted decimal, named after the feature release they are updates to
(e.g. "1.8.5.1" was the first maintenance release for "1.8.5" feature
release).  These days, maintenance releases are named by incrementing
the last digit of three-dotted decimal name (e.g. "2.3.4" is the
fourth maintenance relaese for "2.3" series).

New features never go to the 'maint' branch.  This branch is also
merged into "master" to propagate the fixes forward as needed.

A new development does not usually happen on "master". When you send a
series of patches, after review on the mailing list, a separate topic
branch is forked from the tip of "master" and your patches are queued
there, and kept out of "master" while people test it out. The quality of
topic branches are judged primarily by the mailing list discussions.

Topic branches that are in good shape are merged to the "next" branch. In
general, the "next" branch always contains the tip of "master".  It might
not be quite rock-solid, but is expected to work more or less without major
breakage. The "next" branch is where new and exciting things take place. A
topic that is in "next" is expected to be polished to perfection before it
is merged to "master".

The "pu" (proposed updates) branch bundles all the remaining topic
branches the maintainer happens to have.  There is no guarantee that
the maintainer has enough bandwidth to pick up any and all topics that
are remotely promising from the list traffic, so please do not read
too much into a topic being on (or not on) the "pu" branch.  This
branch is mainly to remind the maintainer that the topics in them may
turn out to be interesting when they are polished, nothing more.  The
topics on this branch aren't usually complete, well tested, or well
documented and they often need further work.  When a topic that was
in "pu" proves to be in a testable shape, it is merged to "next".

You can run "git log --first-parent master..pu" to see what topics are
currently in flight.  Sometimes, an idea that looked promising turns out
to be not so good and the topic can be dropped from "pu" in such a case.

The two branches "master" and "maint" are never rewound, and "next"
usually will not be either.  After a feature release is made from
"master", however, "next" will be rebuilt from the tip of "master"
using the topics that didn't make the cut in the feature release.

Note that being in "next" is not a guarantee to appear in the next
release, nor even in any future release.  There were cases that topics
needed reverting a few commits in them before graduating to "master",
or a topic that already was in "next" was reverted from "next" because
fatal flaws were found in it after it was merged to "next".


* Other people's trees, trusted lieutenants and credits.

Documentation/SubmittingPatches outlines to whom your proposed changes
should be sent.  As described in contrib/README, I would delegate fixes
and enhancements in contrib/ area to the primary contributors of them.

Although the following are included in git.git repository, they have their
own authoritative repository and maintainers:

 - git-gui/ comes from git-gui project, maintained by Pat Thoyts:

        git://repo.or.cz/git-gui.git

 - gitk-git/ comes from Paul Mackerras's gitk project:

        git://ozlabs.org/~paulus/gitk

 - po/ comes from the localization coordinator, Jiang Xin:

	https://github.com/git-l10n/git-po/

A note from the maintainer

[Junio C Hamano]

[note to regular readers; there are a few updated paragraphs,
regarding our association with SFC and also our security mailing
list.]

Welcome to the Git development community.

This message is written by the maintainer and talks about how Git
project is managed, and how you can work with it.

* Mailing list and the community

The development is primarily done on the Git mailing list. Help
requests, feature proposals, bug reports and patches should be sent to
the list address <git@vger.kernel.org>.  You don't have to be
subscribed to send messages.  The convention on the list is to keep
everybody involved on Cc:, so it is unnecessary to say "Please Cc: me,
I am not subscribed".

Before sending patches, please read Documentation/SubmittingPatches
and Documentation/CodingGuidelines to familiarize yourself with the
project convention.

If you sent a patch and you did not hear any response from anybody for
several days, it could be that your patch was totally uninteresting,
but it also is possible that it was simply lost in the noise.  Please
do not hesitate to send a reminder message in such a case.  Messages
getting lost in the noise may be a sign that those who can evaluate
your patch don't have enough mental/time bandwidth to process them
right at the moment, and it often helps to wait until the list traffic
becomes calmer before sending such a reminder.

The list archive is available at a few public sites:

        http://news.gmane.org/gmane.comp.version-control.git/
        http://marc.theaimsgroup.com/?l=git
        http://www.spinics.net/lists/git/

For those who prefer to read it over NNTP:

        nntp://news.gmane.org/gmane.comp.version-control.git

When you point at a message in a mailing list archive, using
gmane is often the easiest to follow by readers, like this:

        http://thread.gmane.org/gmane.comp.version-control.git/27/focus=217

as it also allows people who subscribe to the mailing list as gmane
newsgroup to "jump to" the article.

Some members of the development community can sometimes be found on
the #git and #git-devel IRC channels on Freenode.  Their logs are
available at:

        http://colabti.org/irclogger/irclogger_log/git
        http://colabti.org/irclogger/irclogger_log/git-devel

Git is a member project of software freedom conservancy, a non-profit
organization (https://sfconservancy.org/).  To reach a committee of
liaisons to the conservancy, contact them at <git@sfconservancy.org>.


* Reporting bugs

When you think git does not behave as you expect, please do not stop
your bug report with just "git does not work".  "I used git in this
way, but it did not work" is not much better, neither is "I used git
in this way, and X happend, which is broken".  It often is that git is
correct to cause X happen in such a case, and it is your expectation
that is broken. People would not know what other result Y you expected
to see instead of X, if you left it unsaid.

Please remember to always state

 - what you wanted to achieve;

 - what you did (the version of git and the command sequence to reproduce
   the behavior);

 - what you saw happen (X above);

 - what you expected to see (Y above); and

 - how the last two are different.

See http://www.chiark.greenend.org.uk/~sgtatham/bugs.html for further
hints.

If you think you found a security-sensitive issue and want to disclose
it to us without announcing it to wider public, please contact us at
our security mailing list <git-security@googlegroups.com>.


* Repositories, branches and documentation.

My public git.git repositories are at:

        git://git.kernel.org/pub/scm/git/git.git/
	https://kernel.googlesource.com/pub/scm/git/git
	git://repo.or.cz/alt-git.git/
	https://github.com/git/git/
	https://code.google.com/p/git-core/
	git://git.sourceforge.jp/gitroot/git-core/git.git/
	git://git-core.git.sourceforge.net/gitroot/git-core/git-core/

A few web interfaces are found at:

        http://git.kernel.org/?p=git/git.git
	https://kernel.googlesource.com/pub/scm/git/git
        http://repo.or.cz/w/alt-git.git

Preformatted documentation from the tip of the "master" branch can be
found in:

        git://git.kernel.org/pub/scm/git/git-{htmldocs,manpages}.git/
        git://repo.or.cz/git-{htmldocs,manpages}.git/
        https://code.google.com/p/git-{htmldocs,manpages}.git/
        https://github.com/gitster/git-{htmldocs,manpages}.git/

You can browse the HTML manual pages at:

	http://git-htmldocs.googlecode.com/git/git.html

There are four branches in git.git repository that track the source tree
of git: "master", "maint", "next", and "pu".

The "master" branch is meant to contain what are very well tested and
ready to be used in a production setting.  Every now and then, a
"feature release" is cut from the tip of this branch.  They used to be
named with three dotted decimal digits (e.g. "1.8.5"), but recently we
switched the versioning scheme and "feature releases" are named with
three-dotted decimal digits that ends with ".0" (e.g. "1.9.0").

The last such release was 2.3.0 done on Feb 5th, 2015. You can expect
that the tip of the "master" branch is always more stable than any of
the released versions.

Whenever a feature release is made, "maint" branch is forked off from
"master" at that point.  Obvious, safe and urgent fixes after a
feature release are applied to this branch and maintenance releases
are cut from it.  The maintenance releases used to be named with four
dotted decimal, named after the feature release they are updates to
(e.g. "1.8.5.1" was the first maintenance release for "1.8.5" feature
release).  These days, maintenance releases are named by incrementing
the last digit of three-dotted decimal name (e.g. "2.3.2" is the
second maintenance relaese for "2.3" series).

New features never go to the 'maint' branch.  This branch is also
merged into "master" to propagate the fixes forward as needed.

A new development does not usually happen on "master". When you send a
series of patches, after review on the mailing list, a separate topic
branch is forked from the tip of "master" and your patches are queued
there, and kept out of "master" while people test it out. The quality of
topic branches are judged primarily by the mailing list discussions.

Topic branches that are in good shape are merged to the "next" branch. In
general, the "next" branch always contains the tip of "master".  It might
not be quite rock-solid, but is expected to work more or less without major
breakage. The "next" branch is where new and exciting things take place. A
topic that is in "next" is expected to be polished to perfection before it
is merged to "master".

The "pu" (proposed updates) branch bundles all the remaining topic
branches the maintainer happens to have.  There is no guarantee that
the maintainer has enough bandwidth to pick up any and all topics that
are remotely promising from the list traffic, so please do not read
too much into a topic being on (or not on) the "pu" branch.  This
branch is mainly to remind the maintainer that the topics in them may
turn out to be interesting when they are polished, nothing more.  The
topics on this branch aren't usually complete, well tested, or well
documented and they often need further work.  When a topic that was
in "pu" proves to be in a testable shape, it is merged to "next".

You can run "git log --first-parent master..pu" to see what topics are
currently in flight.  Sometimes, an idea that looked promising turns out
to be not so good and the topic can be dropped from "pu" in such a case.

The two branches "master" and "maint" are never rewound, and "next"
usually will not be either.  After a feature release is made from
"master", however, "next" will be rebuilt from the tip of "master"
using the topics that didn't make the cut in the feature release.

Note that being in "next" is not a guarantee to appear in the next
release, nor even in any future release.  There were cases that topics
needed reverting a few commits in them before graduating to "master",
or a topic that already was in "next" was reverted from "next" because
fatal flaws were found in it after it was merged to "next".


* Other people's trees, trusted lieutenants and credits.

Documentation/SubmittingPatches outlines to whom your proposed changes
should be sent.  As described in contrib/README, I would delegate fixes
and enhancements in contrib/ area to the primary contributors of them.

Although the following are included in git.git repository, they have their
own authoritative repository and maintainers:

 - git-gui/ comes from git-gui project, maintained by Pat Thoyts:

        git://repo.or.cz/git-gui.git

 - gitk-git/ comes from Paul Mackerras's gitk project:

        git://ozlabs.org/~paulus/gitk

 - po/ comes from the localization coordinator, Jiang Xin:

	https://github.com/git-l10n/git-po/

A note from the maintainer

[Junio C Hamano]

Welcome to the Git development community.

This message is written by the maintainer and talks about how Git
project is managed, and how you can work with it.

* Mailing list and the community

The development is primarily done on the Git mailing list. Help
requests, feature proposals, bug reports and patches should be sent to
the list address <git@vger.kernel.org>.  You don't have to be
subscribed to send messages.  The convention on the list is to keep
everybody involved on Cc:, so it is unnecessary to say "Please Cc: me,
I am not subscribed".

Before sending patches, please read Documentation/SubmittingPatches
and Documentation/CodingGuidelines to familiarize yourself with the
project convention.

If you sent a patch and you did not hear any response from anybody for
several days, it could be that your patch was totally uninteresting,
but it also is possible that it was simply lost in the noise.  Please
do not hesitate to send a reminder message in such a case.  Messages
getting lost in the noise may be a sign that those who can evaluate
your patch don't have enough mental/time bandwidth to process them
right at the moment, and it often helps to wait until the list traffic
becomes calmer before sending such a reminder.

The list archive is available at a few public sites:

        http://news.gmane.org/gmane.comp.version-control.git/
        http://marc.theaimsgroup.com/?l=git
        http://www.spinics.net/lists/git/

For those who prefer to read it over NNTP:

        nntp://news.gmane.org/gmane.comp.version-control.git

When you point at a message in a mailing list archive, using
gmane is often the easiest to follow by readers, like this:

        http://thread.gmane.org/gmane.comp.version-control.git/27/focus=217

as it also allows people who subscribe to the mailing list as gmane
newsgroup to "jump to" the article.

Some members of the development community can sometimes be found on
the #git and #git-devel IRC channels on Freenode.  Their logs are
available at:

        http://colabti.org/irclogger/irclogger_log/git
        http://colabti.org/irclogger/irclogger_log/git-devel

* Reporting bugs

When you think git does not behave as you expect, please do not stop
your bug report with just "git does not work".  "I used git in this
way, but it did not work" is not much better, neither is "I used git
in this way, and X happend, which is broken".  It often is that git is
correct to cause X happen in such a case, and it is your expectation
that is broken. People would not know what other result Y you expected
to see instead of X, if you left it unsaid.

Please remember to always state

 - what you wanted to achieve;

 - what you did (the version of git and the command sequence to reproduce
   the behavior);

 - what you saw happen (X above);

 - what you expected to see (Y above); and

 - how the last two are different.

See http://www.chiark.greenend.org.uk/~sgtatham/bugs.html for further
hints.

* Repositories, branches and documentation.

My public git.git repositories are at:

        git://git.kernel.org/pub/scm/git/git.git/
	https://kernel.googlesource.com/pub/scm/git/git
	git://repo.or.cz/alt-git.git/
	https://github.com/git/git/
	https://code.google.com/p/git-core/
	git://git.sourceforge.jp/gitroot/git-core/git.git/
	git://git-core.git.sourceforge.net/gitroot/git-core/git-core/

A few web interfaces are found at:

        http://git.kernel.org/?p=git/git.git
	https://kernel.googlesource.com/pub/scm/git/git
        http://repo.or.cz/w/alt-git.git

Preformatted documentation from the tip of the "master" branch can be
found in:

        git://git.kernel.org/pub/scm/git/git-{htmldocs,manpages}.git/
        git://repo.or.cz/git-{htmldocs,manpages}.git/
        https://code.google.com/p/git-{htmldocs,manpages}.git/
        https://github.com/gitster/git-{htmldocs,manpages}.git/

You can browse the HTML manual pages at:

	http://git-htmldocs.googlecode.com/git/git.html

There are four branches in git.git repository that track the source tree
of git: "master", "maint", "next", and "pu".

The "master" branch is meant to contain what are very well tested and
ready to be used in a production setting.  Every now and then, a
"feature release" is cut from the tip of this branch.  They used to be
named with three dotted decimal digits (e.g. "1.8.5"), but recently we
switched the versioning scheme and "feature releases" are named with
three-dotted decimal digits that ends with ".0" (e.g. "1.9.0").

The last such release was 2.3.0 done on Feb 5th, 2015. You can expect
that the tip of the "master" branch is always more stable than any of
the released versions.

Whenever a feature release is made, "maint" branch is forked off from
"master" at that point.  Obvious, safe and urgent fixes after a
feature release are applied to this branch and maintenance releases
are cut from it.  The maintenance releases used to be named with four
dotted decimal, named after the feature release they are updates to
(e.g. "1.8.5.1" was the first maintenance release for "1.8.5" feature
release).  These days, maintenance releases are named by incrementing
the last digit of three-dotted decimal name (e.g. "2.2.1" will be the
first maintenance relaese for "2.2" series).

New features never go to the 'maint' branch.  This branch is also
merged into "master" to propagate the fixes forward as needed.

A new development does not usually happen on "master". When you send a
series of patches, after review on the mailing list, a separate topic
branch is forked from the tip of "master" and your patches are queued
there, and kept out of "master" while people test it out. The quality of
topic branches are judged primarily by the mailing list discussions.

Topic branches that are in good shape are merged to the "next" branch. In
general, the "next" branch always contains the tip of "master".  It might
not be quite rock-solid, but is expected to work more or less without major
breakage. The "next" branch is where new and exciting things take place. A
topic that is in "next" is expected to be polished to perfection before it
is merged to "master".

The "pu" (proposed updates) branch bundles all the remaining topic
branches the maintainer happens to have.  There is no guarantee that
the maintainer has enough bandwidth to pick up any and all topics that
are remotely promising from the list traffic, so please do not read
too much into a topic being on (or not on) the "pu" branch.  This
branch is mainly to remind the maintainer that the topics in them may
turn out to be interesting when they are polished, nothing more.  The
topics on this branch aren't usually complete, well tested, or well
documented and they often need further work.  When a topic that was
in "pu" proves to be in a testable shape, it is merged to "next".

You can run "git log --first-parent master..pu" to see what topics are
currently in flight.  Sometimes, an idea that looked promising turns out
to be not so good and the topic can be dropped from "pu" in such a case.

The two branches "master" and "maint" are never rewound, and "next"
usually will not be either.  After a feature release is made from
"master", however, "next" will be rebuilt from the tip of "master"
using the topics that didn't make the cut in the feature release.

Note that being in "next" is not a guarantee to appear in the next
release, nor even in any future release.  There were cases that topics
needed reverting a few commits in them before graduating to "master",
or a topic that already was in "next" was reverted from "next" because
fatal flaws were found in it after it was merged to "next".


* Other people's trees, trusted lieutenants and credits.

Documentation/SubmittingPatches outlines to whom your proposed changes
should be sent.  As described in contrib/README, I would delegate fixes
and enhancements in contrib/ area to the primary contributors of them.

Although the following are included in git.git repository, they have their
own authoritative repository and maintainers:

 - git-gui/ comes from git-gui project, maintained by Pat Thoyts:

        git://repo.or.cz/git-gui.git

 - gitk-git/ comes from Paul Mackerras's gitk project:

        git://ozlabs.org/~paulus/gitk

 - po/ comes from the localization coordinator, Jiang Xin:

	https://github.com/git-l10n/git-po/

A note from the maintainer

[Junio C Hamano]

Welcome to the Git development community.

This message is written by the maintainer and talks about how Git
project is managed, and how you can work with it.

* Mailing list and the community

The development is primarily done on the Git mailing list. Help
requests, feature proposals, bug reports and patches should be sent to
the list address <git@vger.kernel.org>.  You don't have to be
subscribed to send messages.  The convention on the list is to keep
everybody involved on Cc:, so it is unnecessary to say "Please Cc: me,
I am not subscribed".

Before sending patches, please read Documentation/SubmittingPatches
and Documentation/CodingGuidelines to familiarize yourself with the
project convention.

If you sent a patch and you did not hear any response from anybody for
several days, it could be that your patch was totally uninteresting,
but it also is possible that it was simply lost in the noise.  Please
do not hesitate to send a reminder message in such a case.  Messages
getting lost in the noise may be a sign that those who can evaluate
your patch don't have enough mental/time bandwidth to process them
right at the moment, and it often helps to wait until the list traffic
becomes calmer before sending such a reminder.

The list archive is available at a few public sites:

        http://news.gmane.org/gmane.comp.version-control.git/
        http://marc.theaimsgroup.com/?l=git
        http://www.spinics.net/lists/git/

For those who prefer to read it over NNTP:

        nntp://news.gmane.org/gmane.comp.version-control.git

When you point at a message in a mailing list archive, using
gmane is often the easiest to follow by readers, like this:

        http://thread.gmane.org/gmane.comp.version-control.git/27/focus=217

as it also allows people who subscribe to the mailing list as gmane
newsgroup to "jump to" the article.

Some members of the development community can sometimes be found on
the #git and #git-devel IRC channels on Freenode.  Their logs are
available at:

        http://colabti.org/irclogger/irclogger_log/git
        http://colabti.org/irclogger/irclogger_log/git-devel

* Reporting bugs

When you think git does not behave as you expect, please do not stop
your bug report with just "git does not work".  "I used git in this
way, but it did not work" is not much better, neither is "I used git
in this way, and X happend, which is broken".  It often is that git is
correct to cause X happen in such a case, and it is your expectation
that is broken. People would not know what other result Y you expected
to see instead of X, if you left it unsaid.

Please remember to always state

 - what you wanted to achieve;

 - what you did (the version of git and the command sequence to reproduce
   the behavior);

 - what you saw happen (X above);

 - what you expected to see (Y above); and

 - how the last two are different.

See http://www.chiark.greenend.org.uk/~sgtatham/bugs.html for further
hints.

* Repositories, branches and documentation.

My public git.git repositories are at:

        git://git.kernel.org/pub/scm/git/git.git/
	https://kernel.googlesource.com/pub/scm/git/git
	git://repo.or.cz/alt-git.git/
	https://github.com/git/git/
	https://code.google.com/p/git-core/
	git://git.sourceforge.jp/gitroot/git-core/git.git/
	git://git-core.git.sourceforge.net/gitroot/git-core/git-core/

A few web interfaces are found at:

        http://git.kernel.org/?p=git/git.git
	https://kernel.googlesource.com/pub/scm/git/git
        http://repo.or.cz/w/alt-git.git

Preformatted documentation from the tip of the "master" branch can be
found in:

        git://git.kernel.org/pub/scm/git/git-{htmldocs,manpages}.git/
        git://repo.or.cz/git-{htmldocs,manpages}.git/
        https://code.google.com/p/git-{htmldocs,manpages}.git/
        https://github.com/gitster/git-{htmldocs,manpages}.git/

You can browse the HTML manual pages at:

	http://git-htmldocs.googlecode.com/git/git.html

There are four branches in git.git repository that track the source tree
of git: "master", "maint", "next", and "pu".

The "master" branch is meant to contain what are very well tested and
ready to be used in a production setting.  Every now and then, a
"feature release" is cut from the tip of this branch.  They used to be
named with three dotted decimal digits (e.g. "1.8.5"), but recently we
switched the versioning scheme and "feature releases" are named with
three-dotted decimal digits that ends with ".0" (e.g. "1.9.0").

The last such release was 2.2.0 done on Nov 26, 2014. You can expect
that the tip of the "master" branch is always more stable than any of
the released versions.

Whenever a feature release is made, "maint" branch is forked off from
"master" at that point.  Obvious, safe and urgent fixes after a
feature release are applied to this branch and maintenance releases
are cut from it.  The maintenance releases used to be named with four
dotted decimal, named after the feature release they are updates to
(e.g. "1.8.5.1" was the first maintenance release for "1.8.5" feature
release).  These days, maintenance releases are named by incrementing
the last digit of three-dotted decimal name (e.g. "2.2.1" will be the
first maintenance relaese for "2.2" series).

New features never go to the 'maint' branch.  This branch is also
merged into "master" to propagate the fixes forward as needed.

A new development does not usually happen on "master". When you send a
series of patches, after review on the mailing list, a separate topic
branch is forked from the tip of "master" and your patches are queued
there, and kept out of "master" while people test it out. The quality of
topic branches are judged primarily by the mailing list discussions.

Topic branches that are in good shape are merged to the "next" branch. In
general, the "next" branch always contains the tip of "master".  It might
not be quite rock-solid, but is expected to work more or less without major
breakage. The "next" branch is where new and exciting things take place. A
topic that is in "next" is expected to be polished to perfection before it
is merged to "master".

The "pu" (proposed updates) branch bundles all the remaining topic
branches the maintainer happens to have.  There is no guarantee that
the maintainer has enough bandwidth to pick up any and all topics that
are remotely promising from the list traffic, so please do not read
too much into a topic being on (or not on) the "pu" branch.  This
branch is mainly to remind the maintainer that the topics in them may
turn out to be interesting when they are polished, nothing more.  The
topics on this branch aren't usually complete, well tested, or well
documented and they often need further work.  When a topic that was
in "pu" proves to be in a testable shape, it is merged to "next".

You can run "git log --first-parent master..pu" to see what topics are
currently in flight.  Sometimes, an idea that looked promising turns out
to be not so good and the topic can be dropped from "pu" in such a case.

The two branches "master" and "maint" are never rewound, and "next"
usually will not be either.  After a feature release is made from
"master", however, "next" will be rebuilt from the tip of "master"
using the topics that didn't make the cut in the feature release.

Note that being in "next" is not a guarantee to appear in the next
release, nor even in any future release.  There were cases that topics
needed reverting a few commits in them before graduating to "master",
or a topic that already was in "next" was reverted from "next" because
fatal flaws were found in it after it was merged to "next".


* Other people's trees, trusted lieutenants and credits.

Documentation/SubmittingPatches outlines to whom your proposed changes
should be sent.  As described in contrib/README, I would delegate fixes
and enhancements in contrib/ area to the primary contributors of them.

Although the following are included in git.git repository, they have their
own authoritative repository and maintainers:

 - git-gui/ comes from git-gui project, maintained by Pat Thoyts:

        git://repo.or.cz/git-gui.git

 - gitk-git/ comes from Paul Mackerras's gitk project:

        git://ozlabs.org/~paulus/gitk

 - po/ comes from the localization coordinator, Jiang Xin:

	https://github.com/git-l10n/git-po/

A note from the maintainer

[Junio C Hamano]

Welcome to the Git development community.

This message is written by the maintainer and talks about how Git
project is managed, and how you can work with it.

* Mailing list and the community

The development is primarily done on the Git mailing list. Help
requests, feature proposals, bug reports and patches should be sent to
the list address <git@vger.kernel.org>.  You don't have to be
subscribed to send messages.  The convention on the list is to keep
everybody involved on Cc:, so it is unnecessary to say "Please Cc: me,
I am not subscribed".

Before sending patches, please read Documentation/SubmittingPatches
and Documentation/CodingGuidelines to familiarize yourself with the
project convention.

If you sent a patch and you did not hear any response from anybody for
several days, it could be that your patch was totally uninteresting,
but it also is possible that it was simply lost in the noise.  Please
do not hesitate to send a reminder message in such a case.  Messages
getting lost in the noise is a sign that people involved don't have
enough mental/time bandwidth to process them right at the moment, and
it often helps to wait until the list traffic becomes calmer before
sending such a reminder.

The list archive is available at a few public sites:

        http://news.gmane.org/gmane.comp.version-control.git/
        http://marc.theaimsgroup.com/?l=git
        http://www.spinics.net/lists/git/

For those who prefer to read it over NNTP (including the maintainer):

        nntp://news.gmane.org/gmane.comp.version-control.git

When you point at a message in a mailing list archive, using
gmane is often the easiest to follow by readers, like this:

        http://thread.gmane.org/gmane.comp.version-control.git/27/focus=217

as it also allows people who subscribe to the mailing list as gmane
newsgroup to "jump to" the article.

Some members of the development community can sometimes also be found
on the #git IRC channel on Freenode.  Its log is available at:

        http://colabti.org/irclogger/irclogger_log/git

* Reporting bugs

When you think git does not behave as you expect, please do not stop
your bug report with just "git does not work".  "I used git in this
way, but it did not work" is not much better, neither is "I used git
in this way, and X happend, which is broken".  It often is that git is
correct to cause X happen in such a case, and it is your expectation
that is broken. People would not know what other result Y you expected
to see instead of X, if you left it unsaid.

Please remember to always state

 - what you wanted to achieve;

 - what you did (the version of git and the command sequence to reproduce
   the behavior);

 - what you saw happen (X above);

 - what you expected to see (Y above); and

 - how the last two are different.

See http://www.chiark.greenend.org.uk/~sgtatham/bugs.html for further
hints.

* Repositories, branches and documentation.

My public git.git repositories are at:

        git://git.kernel.org/pub/scm/git/git.git/
	https://kernel.googlesource.com/pub/scm/git/git
	git://repo.or.cz/alt-git.git/
	https://github.com/git/git/
	https://code.google.com/p/git-core/
	git://git.sourceforge.jp/gitroot/git-core/git.git/
	git://git-core.git.sourceforge.net/gitroot/git-core/git-core/

A few web interfaces are found at:

        http://git.kernel.org/?p=git/git.git
	https://kernel.googlesource.com/pub/scm/git/git
        http://repo.or.cz/w/alt-git.git

Preformatted documentation from the tip of the "master" branch can be
found in:

        git://git.kernel.org/pub/scm/git/git-{htmldocs,manpages}.git/
        git://repo.or.cz/git-{htmldocs,manpages}.git/
        https://code.google.com/p/git-{htmldocs,manpages}.git/
        https://github.com/gitster/git-{htmldocs,manpages}.git/

You can browse the HTML manual pages at:

	http://git-htmldocs.googlecode.com/git/git.html

There are four branches in git.git repository that track the source tree
of git: "master", "maint", "next", and "pu".

The "master" branch is meant to contain what are very well tested and
ready to be used in a production setting.  Every now and then, a
"feature release" is cut from the tip of this branch and they
typically are named with three dotted decimal digits.  The last such
release was 1.8.2 done on Mar 13, 2013. You can expect that the tip of
the "master" branch is always more stable than any of the released
versions.

Whenever a feature release is made, "maint" branch is forked off from
"master" at that point.  Obvious, safe and urgent fixes after a feature
release are applied to this branch and maintenance releases are cut from
it.  The maintenance releases are named with four dotted decimal, named
after the feature release they are updates to; the last such release was
1.8.1.5.  New features never go to this branch.  This branch is also
merged into "master" to propagate the fixes forward as needed.

A new development does not usually happen on "master". When you send a
series of patches, after review on the mailing list, a separate topic
branch is forked from the tip of "master" and your patches are queued
there, and kept out of "master" while people test it out. The quality of
topic branches are judged primarily by the mailing list discussions.

Topic branches that are in good shape are merged to the "next" branch. In
general, the "next" branch always contains the tip of "master".  It might
not be quite rock-solid, but is expected to work more or less without major
breakage. The "next" branch is where new and exciting things take place. A
topic that is in "next" is expected to be polished to perfection before it
is merged to "master".

The "pu" (proposed updates) branch bundles all the remaining topic branches.
The topics on the branch are not complete, well tested, nor well documented
and need further work. When a topic that was in "pu" proves to be in a
testable shape, it is merged to "next".

You can run "git log --first-parent master..pu" to see what topics are
currently in flight.  Sometimes, an idea that looked promising turns out
to be not so good and the topic can be dropped from "pu" in such a case.

The two branches "master" and "maint" are never rewound, and "next"
usually will not be either.  After a feature release is made from
"master", however, "next" will be rebuilt from the tip of "master"
using the topics that didn't make the cut in the feature release.

Note that being in "next" is not a guarantee to appear in the next
release, nor even in any future release.  There were cases that topics
needed reverting a few commits in them before graduating to "master",
or a topic that already was in "next" was reverted from "next" because
fatal flaws were found in it after it was merged.


* Other people's trees, trusted lieutenants and credits.

Documentation/SubmittingPatches outlines to whom your proposed changes
should be sent.  As described in contrib/README, I would delegate fixes
and enhancements in contrib/ area to the primary contributors of them.

Although the following are included in git.git repository, they have their
own authoritative repository and maintainers:

 - git-gui/ comes from git-gui project, maintained by Pat Thoyts:

        git://repo.or.cz/git-gui.git

 - gitk-git/ comes from Paul Mackerras's gitk project:

        git://ozlabs.org/~paulus/gitk

 - po/ comes from the localization coordinator, Jiang Xin:

	https://github.com/git-l10n/git-po/

I would like to thank everybody who helped to raise git into the current
shape.  Especially I would like to thank the git list regulars whose help
I have relied on and expect to continue relying on heavily:

 - Linus Torvalds, Shawn Pearce, Johannes Schindelin, Nicolas Pitre,
   René Scharfe, Jeff King, Jonathan Nieder, Johan Herland, Johannes
   Sixt, Sverre Rabbelier, Michael J Gruber, Nguyễn Thái Ngọc Duy,
   Ævar Arnfjörð Bjarmason and Thomas Rast for helping with general
   design and implementation issues and reviews on the mailing list.

 - Shawn and Nicolas Pitre for helping with packfile design and
   implementation issues.

 - Martin Langhoff, Frank Lichtenheld and Ævar Arnfjörð Bjarmason for
   cvsserver and cvsimport.

 - Paul Mackerras for gitk.

 - Eric Wong, David D. Kilzer and Sam Vilain for git-svn.

 - Simon Hausmann, Pete Wyckoff and Luke Diamond for git-p4.

 - Jakub Narebski, John Hawley, Petr Baudis, Luben Tuikov, Giuseppe
   Bilotta for maintaining and enhancing gitweb.

 - Ævar Arnfjörð Bjarmason for kicking off the i18n effort, and Jiang
   Xin for volunteering to be the l10n coordinator.

 - Jens Lehmann, Heiko Voigt and Lars Hjemli for submodule related
   Porcelains.

 - J. Bruce Fields, Jonathan Nieder, Michael J Gruber and Thomas Rast for
   documentation (and countless others for proofreading and fixing).

 - Alexandre Julliard for Emacs integration.

 - David Aguilar and Charles Bailey for taking good care of git-mergetool
   (and Theodore Ts'o for creating it in the first place) and git-difftool.

 - Johannes Schindelin, Johannes Sixt, Erik Faye-Lund, Pat Thoyts and others
   for their effort to move things forward on the Windows front.

 - People on non-Linux platforms for keeping their eyes on portability;
   especially, Randal Schwartz, Theodore Ts'o, Jason Riedy, Thomas Glanzmann,
   Brandon Casey, Jeff King, Alex Riesen and countless others.

A note from the maintainer

[Junio C Hamano]

Welcome to the Git development community.

This message is written by the maintainer and talks about how Git
project is managed, and how you can work with it.

* Mailing list and the community

The development is primarily done on the Git mailing list. Help
requests, feature proposals, bug reports and patches should be sent to
the list address <git@vger.kernel.org>.  You don't have to be
subscribed to send messages.  The convention on the list is to keep
everybody involved on Cc:, so it is unnecessary to say "Please Cc: me,
I am not subscribed".

Before sending patches, please read Documentation/SubmittingPatches
and Documentation/CodingGuidelines to familiarize yourself with the
project convention.

If you sent a patch and you did not hear any response from anybody for
several days, it could be that your patch was totally uninteresting,
but it also is possible that it was simply lost in the noise.  Please
do not hesitate to send a reminder message in such a case.  Messages
getting lost in the noise is a sign that people involved don't have
enough mental/time bandwidth to process them right at the moment, and
it often helps to wait until the list traffic becomes calmer before
sending such a reminder.

The list archive is available at a few public sites:

        http://news.gmane.org/gmane.comp.version-control.git/
        http://marc.theaimsgroup.com/?l=git
        http://www.spinics.net/lists/git/

For those who prefer to read it over NNTP (including the maintainer):

        nntp://news.gmane.org/gmane.comp.version-control.git

When you point at a message in a mailing list archive, using
gmane is often the easiest to follow by readers, like this:

        http://thread.gmane.org/gmane.comp.version-control.git/27/focus=217

as it also allows people who subscribe to the mailing list as gmane
newsgroup to "jump to" the article.

Some members of the development community can sometimes also be found
on the #git IRC channel on Freenode.  Its log is available at:

        http://colabti.org/irclogger/irclogger_log/git

* Reporting bugs

When you think git does not behave as you expect, please do not stop
your bug report with just "git does not work".  "I used git in this
way, but it did not work" is not much better, neither is "I used git
in this way, and X happend, which is broken".  It often is that git is
correct to cause X happen in such a case, and it is your expectation
that is broken. People would not know what other result Y you expected
to see instead of X, if you left it unsaid.

Please remember to always state

 - what you wanted to achieve;

 - what you did (the version of git and the command sequence to reproduce
   the behavior);

 - what you saw happen (X above);

 - what you expected to see (Y above); and

 - how the last two are different.

See http://www.chiark.greenend.org.uk/~sgtatham/bugs.html for further
hints.

* Repositories, branches and documentation.

My public git.git repositories are at:

        git://git.kernel.org/pub/scm/git/git.git/
	git://repo.or.cz/alt-git.git/
	https://github.com/git/git/
	https://code.google.com/p/git-core/
	git://git.sourceforge.jp/gitroot/git-core/git.git/
	git://git-core.git.sourceforge.net/gitroot/git-core/git-core/

A few gitweb interfaces are found at:

        http://git.kernel.org/?p=git/git.git
        http://repo.or.cz/w/alt-git.git

Preformatted documentation from the tip of the "master" branch can be
found in:

        git://git.kernel.org/pub/scm/git/git-{htmldocs,manpages}.git/
        git://repo.or.cz/git-{htmldocs,manpages}.git/
        https://code.google.com/p/git-{htmldocs,manpages}.git/
        https://github.com/gitster/git-{htmldocs,manpages}.git/

You can browse the HTML manual pages at:

	http://git-htmldocs.googlecode.com/git/git.html

There are four branches in git.git repository that track the source tree
of git: "master", "maint", "next", and "pu".

The "master" branch is meant to contain what are very well tested and
ready to be used in a production setting.  Every now and then, a
"feature release" is cut from the tip of this branch and they
typically are named with three dotted decimal digits.  The last such
release was 1.8.1 done on Dec 31, 2012 (or Jan 1, 2013, depending on
where you were when it happened). You can expect that the tip of the
"master" branch is always more stable than any of the released
versions.

Whenever a feature release is made, "maint" branch is forked off from
"master" at that point.  Obvious, safe and urgent fixes after a feature
release are applied to this branch and maintenance releases are cut from
it.  The maintenance releases are named with four dotted decimal, named
after the feature release they are updates to; the last such release was
1.8.1.2.  New features never go to this branch.  This branch is also
merged into "master" to propagate the fixes forward as needed.

A new development does not usually happen on "master". When you send a
series of patches, after review on the mailing list, a separate topic
branch is forked from the tip of "master" and your patches are queued
there, and kept out of "master" while people test it out. The quality of
topic branches are judged primarily by the mailing list discussions.

Topic branches that are in good shape are merged to the "next" branch. In
general, the "next" branch always contains the tip of "master".  It might
not be quite rock-solid, but is expected to work more or less without major
breakage. The "next" branch is where new and exciting things take place. A
topic that is in "next" is expected to be polished to perfection before it
is merged to "master".

The "pu" (proposed updates) branch bundles all the remaining topic branches.
The topics on the branch are not complete, well tested, nor well documented
and need further work. When a topic that was in "pu" proves to be in a
testable shape, it is merged to "next".

You can run "git log --first-parent master..pu" to see what topics are
currently in flight.  Sometimes, an idea that looked promising turns out
to be not so good and the topic can be dropped from "pu" in such a case.

The two branches "master" and "maint" are never rewound, and "next"
usually will not be either.  After a feature release is made from
"master", however, "next" will be rebuilt from the tip of "master"
using the topics that didn't make the cut in the feature release.

Note that being in "next" is not a guarantee to appear in the next
release, nor even in any future release.  There were cases that topics
needed reverting a few commits in them before graduating to "master",
or a topic that already was in "next" was reverted from "next" because
fatal flaws were found in it after it was merged.


* Other people's trees, trusted lieutenants and credits.

Documentation/SubmittingPatches outlines to whom your proposed changes
should be sent.  As described in contrib/README, I would delegate fixes
and enhancements in contrib/ area to the primary contributors of them.

Although the following are included in git.git repository, they have their
own authoritative repository and maintainers:

 - git-gui/ comes from git-gui project, maintained by Pat Thoyts:

        git://repo.or.cz/git-gui.git

 - gitk-git/ comes from Paul Mackerras's gitk project:

        git://ozlabs.org/~paulus/gitk

 - po/ comes from the localization coordinator, Jiang Xin:

	https://github.com/git-l10n/git-po/

I would like to thank everybody who helped to raise git into the current
shape.  Especially I would like to thank the git list regulars whose help
I have relied on and expect to continue relying on heavily:

 - Linus Torvalds, Shawn Pearce, Johannes Schindelin, Nicolas Pitre,
   René Scharfe, Jeff King, Jonathan Nieder, Johan Herland, Johannes
   Sixt, Sverre Rabbelier, Michael J Gruber, Nguyễn Thái Ngọc Duy,
   Ævar Arnfjörð Bjarmason and Thomas Rast for helping with general
   design and implementation issues and reviews on the mailing list.

 - Shawn and Nicolas Pitre for helping with packfile design and
   implementation issues.

 - Martin Langhoff, Frank Lichtenheld and Ævar Arnfjörð Bjarmason for
   cvsserver and cvsimport.

 - Paul Mackerras for gitk.

 - Eric Wong, David D. Kilzer and Sam Vilain for git-svn.

 - Simon Hausmann, Pete Wyckoff and Luke Diamond for git-p4.

 - Jakub Narebski, John Hawley, Petr Baudis, Luben Tuikov, Giuseppe
   Bilotta for maintaining and enhancing gitweb.

 - Ævar Arnfjörð Bjarmason for kicking off the i18n effort, and Jiang
   Xin for volunteering to be the l10n coordinator.

 - Jens Lehmann, Heiko Voigt and Lars Hjemli for submodule related
   Porcelains.

 - J. Bruce Fields, Jonathan Nieder, Michael J Gruber and Thomas Rast for
   documentation (and countless others for proofreading and fixing).

 - Alexandre Julliard for Emacs integration.

 - David Aguilar and Charles Bailey for taking good care of git-mergetool
   (and Theodore Ts'o for creating it in the first place) and git-difftool.

 - Johannes Schindelin, Johannes Sixt, Erik Faye-Lund, Pat Thoyts and others
   for their effort to move things forward on the Windows front.

 - People on non-Linux platforms for keeping their eyes on portability;
   especially, Randal Schwartz, Theodore Ts'o, Jason Riedy, Thomas Glanzmann,
   Brandon Casey, Jeff King, Alex Riesen and countless others.

A note from the maintainer

[Junio C Hamano]

Welcome to the Git development community.

This message is written by the maintainer and talks about how Git
project is managed, and how you can work with it.

* Mailing list and the community

The development is primarily done on the Git mailing list. Help
requests, feature proposals, bug reports and patches should be sent to
the list address <git@vger.kernel.org>.  You don't have to be
subscribed to send messages.  The convention on the list is to keep
everybody involved on Cc:, so it is unnecessary to say "Please Cc: me,
I am not subscribed".

Before sending patches, please read Documentation/SubmittingPatches
and Documentation/CodingGuidelines to familiarize yourself with the
project convention.

If you sent a patch and you did not hear any response from anybody for
several days, it could be that your patch was totally uninteresting,
but it also is possible that it was simply lost in the noise.  Please
do not hesitate to send a reminder message in such a case.  Messages
getting lost in the noise is a sign that people involved don't have
enough mental/time bandwidth to process them right at the moment, and
it often helps to wait until the list traffic becomes calmer before
sending such a reminder.

The list archive is available at a few public sites:

        http://news.gmane.org/gmane.comp.version-control.git/
        http://marc.theaimsgroup.com/?l=git
        http://www.spinics.net/lists/git/

For those who prefer to read it over NNTP (including the maintainer):

        nntp://news.gmane.org/gmane.comp.version-control.git

When you point at a message in a mailing list archive, using
gmane is often the easiest to follow by readers, like this:

        http://thread.gmane.org/gmane.comp.version-control.git/27/focus=217

as it also allows people who subscribe to the mailing list as gmane
newsgroup to "jump to" the article.

Some members of the development community can sometimes also be found
on the #git IRC channel on Freenode.  Its log is available at:

        http://colabti.org/irclogger/irclogger_log/git

* Reporting bugs

When you think git does not behave as you expect, please do not stop
your bug report with just "git does not work".  "I used git in this
way, but it did not work" is not much better, neither is "I used git
in this way, and X happend, which is broken".  It often is that git is
correct to cause X happen in such a case, and it is your expectation
that is broken. People would not know what other result Y you expected
to see instead of X, if you left it unsaid.

Please remember to always state

 - what you wanted to achieve;

 - what you did (the version of git and the command sequence to reproduce
   the behavior);

 - what you saw happen (X above);

 - what you expected to see (Y above); and

 - how the last two are different.

See http://www.chiark.greenend.org.uk/~sgtatham/bugs.html for further
hints.

* Repositories, branches and documentation.

My public git.git repositories are at:

        git://git.kernel.org/pub/scm/git/git.git/
	git://repo.or.cz/alt-git.git/
	https://github.com/git/git/
	https://code.google.com/p/git-core/
	git://git.sourceforge.jp/gitroot/git-core/git.git/
	git://git-core.git.sourceforge.net/gitroot/git-core/git-core/

A few gitweb interfaces are found at:

        http://git.kernel.org/?p=git/git.git
        http://repo.or.cz/w/alt-git.git

Preformatted documentation from the tip of the "master" branch can be
found in:

        git://git.kernel.org/pub/scm/git/git-{htmldocs,manpages}.git/
        git://repo.or.cz/git-{htmldocs,manpages}.git/
        https://code.google.com/p/git-{htmldocs,manpages}.git/
        https://github.com/gitster/git-{htmldocs,manpages}.git/

You can browse the HTML manual pages at:

	http://git-htmldocs.googlecode.com/git/git.html

There are four branches in git.git repository that track the source tree
of git: "master", "maint", "next", and "pu".

The "master" branch is meant to contain what are very well tested and
ready to be used in a production setting.  Every now and then, a
"feature release" is cut from the tip of this branch and they
typically are named with three dotted decimal digits.  The last such
release was 1.8.1 done on Dec 31, 2012 (or Jan 1, 2013, depending on
where you were when it happened). You can expect that the tip of the
"master" branch is always more stable than any of the released
versions.

Whenever a feature release is made, "maint" branch is forked off from
"master" at that point.  Obvious, safe and urgent fixes after a feature
release are applied to this branch and maintenance releases are cut from
it.  The maintenance releases are named with four dotted decimal, named
after the feature release they are updates to; the last such release was
1.8.0.3.  New features never go to this branch.  This branch is also
merged into "master" to propagate the fixes forward as needed.

A new development does not usually happen on "master". When you send a
series of patches, after review on the mailing list, a separate topic
branch is forked from the tip of "master" and your patches are queued
there, and kept out of "master" while people test it out. The quality of
topic branches are judged primarily by the mailing list discussions.

Topic branches that are in good shape are merged to the "next" branch. In
general, the "next" branch always contains the tip of "master".  It might
not be quite rock-solid, but is expected to work more or less without major
breakage. The "next" branch is where new and exciting things take place. A
topic that is in "next" is expected to be polished to perfection before it
is merged to "master".

The "pu" (proposed updates) branch bundles all the remaining topic branches.
The topics on the branch are not complete, well tested, nor well documented
and need further work. When a topic that was in "pu" proves to be in a
testable shape, it is merged to "next".

You can run "git log --first-parent master..pu" to see what topics are
currently in flight.  Sometimes, an idea that looked promising turns out
to be not so good and the topic can be dropped from "pu" in such a case.

The two branches "master" and "maint" are never rewound, and "next"
usually will not be either.  After a feature release is made from
"master", however, "next" will be rebuilt from the tip of "master"
using the topics that didn't make the cut in the feature release.

Note that being in "next" is not a guarantee to appear in the next
release, nor even in any future release.  There were cases that topics
needed reverting a few commits in them before graduating to "master",
or a topic that already was in "next" was reverted from "next" because
fatal flaws were found in it after it was merged.


* Other people's trees, trusted lieutenants and credits.

Documentation/SubmittingPatches outlines to whom your proposed changes
should be sent.  As described in contrib/README, I would delegate fixes
and enhancements in contrib/ area to the primary contributors of them.

Although the following are included in git.git repository, they have their
own authoritative repository and maintainers:

 - git-gui/ comes from git-gui project, maintained by Pat Thoyts:

        git://repo.or.cz/git-gui.git

 - gitk-git/ comes from Paul Mackerras's gitk project:

        git://ozlabs.org/~paulus/gitk

 - po/ comes from the localization coordinator, Jiang Xin:

	https://github.com/git-l10n/git-po/

I would like to thank everybody who helped to raise git into the current
shape.  Especially I would like to thank the git list regulars whose help
I have relied on and expect to continue relying on heavily:

 - Linus Torvalds, Shawn Pearce, Johannes Schindelin, Nicolas Pitre,
   René Scharfe, Jeff King, Jonathan Nieder, Johan Herland, Johannes
   Sixt, Sverre Rabbelier, Michael J Gruber, Nguyễn Thái Ngọc Duy,
   Ævar Arnfjörð Bjarmason and Thomas Rast for helping with general
   design and implementation issues and reviews on the mailing list.

 - Shawn and Nicolas Pitre for helping with packfile design and
   implementation issues.

 - Martin Langhoff, Frank Lichtenheld and Ævar Arnfjörð Bjarmason for
   cvsserver and cvsimport.

 - Paul Mackerras for gitk.

 - Eric Wong, David D. Kilzer and Sam Vilain for git-svn.

 - Simon Hausmann, Pete Wyckoff and Luke Diamond for git-p4.

 - Jakub Narebski, John Hawley, Petr Baudis, Luben Tuikov, Giuseppe
   Bilotta for maintaining and enhancing gitweb.

 - Ævar Arnfjörð Bjarmason for kicking off the i18n effort, and Jiang
   Xin for volunteering to be the l10n coordinator.

 - Jens Lehmann, Heiko Voigt and Lars Hjemli for submodule related
   Porcelains.

 - J. Bruce Fields, Jonathan Nieder, Michael J Gruber and Thomas Rast for
   documentation (and countless others for proofreading and fixing).

 - Alexandre Julliard for Emacs integration.

 - David Aguilar and Charles Bailey for taking good care of git-mergetool
   (and Theodore Ts'o for creating it in the first place) and git-difftool.

 - Johannes Schindelin, Johannes Sixt, Erik Faye-Lund, Pat Thoyts and others
   for their effort to move things forward on the Windows front.

 - People on non-Linux platforms for keeping their eyes on portability;
   especially, Randal Schwartz, Theodore Ts'o, Jason Riedy, Thomas Glanzmann,
   Brandon Casey, Jeff King, Alex Riesen and countless others.

A note from the maintainer

[Junio C Hamano]

Welcome to the Git development community.

This message is written by the maintainer and talks about how Git
project is managed, and how you can work with it.

* Mailing list and the community

The development is primarily done on the Git mailing list. Help
requests, feature proposals, bug reports and patches should be sent to
the list address <git@vger.kernel.org>.  You don't have to be
subscribed to send messages.  The convention on the list is to keep
everybody involved on Cc:, so it is unnecessary to say "Please Cc: me,
I am not subscribed".

Before sending patches, please read Documentation/SubmittingPatches
and Documentation/CodingGuidelines to familiarize yourself with the
project convention.

If you sent a patch and you did not hear any response from anybody for
several days, it could be that your patch was totally uninteresting,
but it also is possible that it was simply lost in the noise.  Please
do not hesitate to send a reminder message in such a case.  Messages
getting lost in the noise is a sign that people involved don't have
enough mental/time bandwidth to process them right at the moment, and
it often helps to wait until the list traffic becomes calmer before
sending such a reminder.

The list archive is available at a few public sites:

        http://news.gmane.org/gmane.comp.version-control.git/
        http://marc.theaimsgroup.com/?l=git
        http://www.spinics.net/lists/git/

For those who prefer to read it over NNTP (including the maintainer):

        nntp://news.gmane.org/gmane.comp.version-control.git

When you point at a message in a mailing list archive, using
gmane is often the easiest to follow by readers, like this:

        http://thread.gmane.org/gmane.comp.version-control.git/27/focus=217

as it also allows people who subscribe to the mailing list as gmane
newsgroup to "jump to" the article.

Some members of the development community can sometimes also be found
on the #git IRC channel on Freenode.  Its log is available at:

        http://colabti.org/irclogger/irclogger_log/git

* Reporting bugs

When you think git does not behave as you expect, please do not stop
your bug report with just "git does not work".  "I used git in this
way, but it did not work" is not much better, neither is "I used git
in this way, and X happend, which is broken".  It often is that git is
correct to cause X happen in such a case, and it is your expectation
that is broken. People would not know what other result Y you expected
to see instead of X, if you left it unsaid.

Please remember to always state

 - what you wanted to achieve;

 - what you did (the version of git and the command sequence to reproduce
   the behavior);

 - what you saw happen (X above);

 - what you expected to see (Y above); and

 - how the last two are different.

See http://www.chiark.greenend.org.uk/~sgtatham/bugs.html for further
hints.

* Repositories, branches and documentation.

My public git.git repositories are at:

        git://git.kernel.org/pub/scm/git/git.git/
	git://repo.or.cz/alt-git.git/
	https://github.com/git/git/
	https://code.google.com/p/git-core/
	git://git.sourceforge.jp/gitroot/git-core/git.git/
	git://git-core.git.sourceforge.net/gitroot/git-core/git-core/

A few gitweb interfaces are found at:

        http://git.kernel.org/?p=git/git.git
        http://repo.or.cz/w/alt-git.git

Preformatted documentation from the tip of the "master" branch can be
found in:

        git://git.kernel.org/pub/scm/git/git-{htmldocs,manpages}.git/
        git://repo.or.cz/git-{htmldocs,manpages}.git/
        https://code.google.com/p/git-{htmldocs,manpages}.git/
        https://github.com/gitster/git-{htmldocs,manpages}.git/

You can browse the HTML manual pages at:

	http://git-htmldocs.googlecode.com/git/git.html

There are four branches in git.git repository that track the source tree
of git: "master", "maint", "next", and "pu".

The "master" branch is meant to contain what are very well tested and
ready to be used in a production setting.  Every now and then, a "feature
release" is cut from the tip of this branch and they typically are named
with three dotted decimal digits.  The last such release was 1.8.0 done on
Oct 21, 2012. You can expect that the tip of the "master" branch is always
more stable than any of the released versions.

Whenever a feature release is made, "maint" branch is forked off from
"master" at that point.  Obvious, safe and urgent fixes after a feature
release are applied to this branch and maintenance releases are cut from
it.  The maintenance releases are named with four dotted decimal, named
after the feature release they are updates to; the last such release was
1.8.0.2.  New features never go to this branch.  This branch is also
merged into "master" to propagate the fixes forward as needed.

A new development does not usually happen on "master". When you send a
series of patches, after review on the mailing list, a separate topic
branch is forked from the tip of "master" and your patches are queued
there, and kept out of "master" while people test it out. The quality of
topic branches are judged primarily by the mailing list discussions.

Topic branches that are in good shape are merged to the "next" branch. In
general, the "next" branch always contains the tip of "master".  It might
not be quite rock-solid, but is expected to work more or less without major
breakage. The "next" branch is where new and exciting things take place. A
topic that is in "next" is expected to be polished to perfection before it
is merged to "master".

The "pu" (proposed updates) branch bundles all the remaining topic branches.
The topics on the branch are not complete, well tested, nor well documented
and need further work. When a topic that was in "pu" proves to be in a
testable shape, it is merged to "next".

You can run "git log --first-parent master..pu" to see what topics are
currently in flight.  Sometimes, an idea that looked promising turns out
to be not so good and the topic can be dropped from "pu" in such a case.

The two branches "master" and "maint" are never rewound, and "next"
usually will not be either.  After a feature release is made from
"master", however, "next" will be rebuilt from the tip of "master"
using the topics that didn't make the cut in the feature release.

Note that being in "next" is not a guarantee to appear in the next
release, nor even in any future release.  There were cases that topics
needed reverting a few commits in them before graduating to "master",
or a topic that already was in "next" was reverted from "next" because
fatal flaws were found in it after it was merged.


* Other people's trees, trusted lieutenants and credits.

Documentation/SubmittingPatches outlines to whom your proposed changes
should be sent.  As described in contrib/README, I would delegate fixes
and enhancements in contrib/ area to the primary contributors of them.

Although the following are included in git.git repository, they have their
own authoritative repository and maintainers:

 - git-gui/ comes from git-gui project, maintained by Pat Thoyts:

        git://repo.or.cz/git-gui.git

 - gitk-git/ comes from Paul Mackerras's gitk project:

        git://ozlabs.org/~paulus/gitk

 - po/ comes from the localization coordinator, Jiang Xin:

	https://github.com/git-l10n/git-po/

I would like to thank everybody who helped to raise git into the current
shape.  Especially I would like to thank the git list regulars whose help
I have relied on and expect to continue relying on heavily:

 - Linus Torvalds, Shawn Pearce, Johannes Schindelin, Nicolas Pitre,
   René Scharfe, Jeff King, Jonathan Nieder, Johan Herland, Johannes
   Sixt, Sverre Rabbelier, Michael J Gruber, Nguyễn Thái Ngọc Duy,
   Ævar Arnfjörð Bjarmason and Thomas Rast for helping with general
   design and implementation issues and reviews on the mailing list.

 - Shawn and Nicolas Pitre for helping with packfile design and
   implementation issues.

 - Martin Langhoff, Frank Lichtenheld and Ævar Arnfjörð Bjarmason for
   cvsserver and cvsimport.

 - Paul Mackerras for gitk.

 - Eric Wong, David D. Kilzer and Sam Vilain for git-svn.

 - Simon Hausmann, Pete Wyckoff and Luke Diamond for git-p4.

 - Jakub Narebski, John Hawley, Petr Baudis, Luben Tuikov, Giuseppe
   Bilotta for maintaining and enhancing gitweb.

 - Ævar Arnfjörð Bjarmason for kicking off the i18n effort, and Jiang
   Xin for volunteering to be the l10n coordinator.

 - Jens Lehmann, Heiko Voigt and Lars Hjemli for submodule related
   Porcelains.

 - J. Bruce Fields, Jonathan Nieder, Michael J Gruber and Thomas Rast for
   documentation (and countless others for proofreading and fixing).

 - Alexandre Julliard for Emacs integration.

 - David Aguilar and Charles Bailey for taking good care of git-mergetool
   (and Theodore Ts'o for creating it in the first place) and git-difftool.

 - Johannes Schindelin, Johannes Sixt, Erik Faye-Lund, Pat Thoyts and others
   for their effort to move things forward on the Windows front.

 - People on non-Linux platforms for keeping their eyes on portability;
   especially, Randal Schwartz, Theodore Ts'o, Jason Riedy, Thomas Glanzmann,
   Brandon Casey, Jeff King, Alex Riesen and countless others.

A note from the maintainer

[Junio C Hamano]

Welcome to the Git development community.

This message is written by the maintainer and talks about how Git
project is managed, and how you can work with it.

* Mailing list and the community

The development is primarily done on the Git mailing list. Help
requests, feature proposals, bug reports and patches should be sent to
the list address <git@vger.kernel.org>.  You don't have to be
subscribed to send messages.  The convention on the list is to keep
everybody involved on Cc:, so it is unnecessary to say "Please Cc: me,
I am not subscribed".

Before sending patches, please read Documentation/SubmittingPatches
and Documentation/CodingGuidelines to familiarize yourself with the
project convention.

If you sent a patch and you did not hear any response from anybody for
several days, it could be that your patch was totally uninteresting,
but it also is possible that it was simply lost in the noise.  Please
do not hesitate to send a reminder message in such a case.  Messages
getting lost in the noise is a sign that people involved don't have
enough mental/time bandwidth to process them right at the moment, and
it often helps to wait until the list traffic becomes calmer before
sending such a reminder.

The list archive is available at a few public sites:

        http://news.gmane.org/gmane.comp.version-control.git/
        http://marc.theaimsgroup.com/?l=git
        http://www.spinics.net/lists/git/

For those who prefer to read it over NNTP (including the maintainer):

        nntp://news.gmane.org/gmane.comp.version-control.git

When you point at a message in a mailing list archive, using
gmane is often the easiest to follow by readers, like this:

        http://thread.gmane.org/gmane.comp.version-control.git/27/focus=217

as it also allows people who subscribe to the mailing list as gmane
newsgroup to "jump to" the article.

Some members of the development community can sometimes also be found
on the #git IRC channel on Freenode.  Its log is available at:

        http://colabti.org/irclogger/irclogger_log/git

* Reporting bugs

When you think git does not behave as you expect, please do not stop
your bug report with just "git does not work".  "I used git in this
way, but it did not work" is not much better, neither is "I used git
in this way, and X happend, which is broken".  It often is that git is
correct to cause X happen in such a case, and it is your expectation
that is broken. People would not know what other result Y you expected
to see instead of X, if you left it unsaid.

Please remember to always state

 - what you wanted to achieve;

 - what you did (the version of git and the command sequence to reproduce
   the behavior);

 - what you saw happen (X above);

 - what you expected to see (Y above); and

 - how the last two are different.

See http://www.chiark.greenend.org.uk/~sgtatham/bugs.html for further
hints.

* Repositories, branches and documentation.

My public git.git repositories are at:

        git://git.kernel.org/pub/scm/git/git.git/
	git://repo.or.cz/alt-git.git/
	https://github.com/git/git/
	https://code.google.com/p/git-core/
	git://git.sourceforge.jp/gitroot/git-core/git.git/
	git://git-core.git.sourceforge.net/gitroot/git-core/git-core/

A few gitweb interfaces are found at:

        http://git.kernel.org/?p=git/git.git
        http://repo.or.cz/w/alt-git.git

Preformatted documentation from the tip of the "master" branch can be
found in:

        git://git.kernel.org/pub/scm/git/git-{htmldocs,manpages}.git/
        git://repo.or.cz/git-{htmldocs,manpages}.git/
        https://code.google.com/p/git-{htmldocs,manpages}.git/
        https://github.com/gitster/git-{htmldocs,manpages}.git/

You can browse the HTML manual pages at:

	http://git-htmldocs.googlecode.com/git/git.html

There are four branches in git.git repository that track the source tree
of git: "master", "maint", "next", and "pu".

The "master" branch is meant to contain what are very well tested and
ready to be used in a production setting.  Every now and then, a "feature
release" is cut from the tip of this branch and they typically are named
with three dotted decimal digits.  The last such release was 1.8.0 done on
Oct 21, 2012. You can expect that the tip of the "master" branch is always
more stable than any of the released versions.

Whenever a feature release is made, "maint" branch is forked off from
"master" at that point.  Obvious, safe and urgent fixes after a feature
release are applied to this branch and maintenance releases are cut from
it.  The maintenance releases are named with four dotted decimal, named
after the feature release they are updates to; the last such release was
1.7.12.4.  New features never go to this branch.  This branch is also
merged into "master" to propagate the fixes forward as needed.

A new development does not usually happen on "master". When you send a
series of patches, after review on the mailing list, a separate topic
branch is forked from the tip of "master" and your patches are queued
there, and kept out of "master" while people test it out. The quality of
topic branches are judged primarily by the mailing list discussions.

Topic branches that are in good shape are merged to the "next" branch. In
general, the "next" branch always contains the tip of "master".  It might
not be quite rock-solid, but is expected to work more or less without major
breakage. The "next" branch is where new and exciting things take place. A
topic that is in "next" is expected to be polished to perfection before it
is merged to "master".

The "pu" (proposed updates) branch bundles all the remaining topic branches.
The topics on the branch are not complete, well tested, nor well documented
and need further work. When a topic that was in "pu" proves to be in a
testable shape, it is merged to "next".

You can run "git log --first-parent master..pu" to see what topics are
currently in flight.  Sometimes, an idea that looked promising turns out
to be not so good and the topic can be dropped from "pu" in such a case.

The two branches "master" and "maint" are never rewound, and "next"
usually will not be either.  After a feature release is made from
"master", however, "next" will be rebuilt from the tip of "master"
using the topics that didn't make the cut in the feature release.

Note that being in "next" is not a guarantee to appear in the next
release, nor even in any future release.  There were cases that topics
needed reverting a few commits in them before graduating to "master",
or a topic that already was in "next" was reverted from "next" because
fatal flaws were found in it after it was merged.


* Other people's trees, trusted lieutenants and credits.

Documentation/SubmittingPatches outlines to whom your proposed changes
should be sent.  As described in contrib/README, I would delegate fixes
and enhancements in contrib/ area to the primary contributors of them.

Although the following are included in git.git repository, they have their
own authoritative repository and maintainers:

 - git-gui/ comes from git-gui project, maintained by Pat Thoyts:

        git://repo.or.cz/git-gui.git

 - gitk-git/ comes from Paul Mackerras's gitk project:

        git://git.kernel.org/pub/scm/gitk/gitk.git

 - po/ comes from the localization coordinator, Jiang Xin:

	https://github.com/git-l10n/git-po/

I would like to thank everybody who helped to raise git into the current
shape.  Especially I would like to thank the git list regulars whose help
I have relied on and expect to continue relying on heavily:

 - Linus Torvalds, Shawn Pearce, Johannes Schindelin, Nicolas Pitre,
   René Scharfe, Jeff King, Jonathan Nieder, Johan Herland, Johannes
   Sixt, Sverre Rabbelier, Michael J Gruber, Nguyễn Thái Ngọc Duy,
   Ævar Arnfjörð Bjarmason and Thomas Rast for helping with general
   design and implementation issues and reviews on the mailing list.

 - Shawn and Nicolas Pitre for helping with packfile design and
   implementation issues.

 - Martin Langhoff, Frank Lichtenheld and Ævar Arnfjörð Bjarmason for
   cvsserver and cvsimport.

 - Paul Mackerras for gitk.

 - Eric Wong, David D. Kilzer and Sam Vilain for git-svn.

 - Simon Hausmann, Pete Wyckoff and Luke Diamond for git-p4.

 - Jakub Narebski, John Hawley, Petr Baudis, Luben Tuikov, Giuseppe
   Bilotta for maintaining and enhancing gitweb.

 - Ævar Arnfjörð Bjarmason for kicking off the i18n effort, and Jiang
   Xin for volunteering to be the l10n coordinator.

 - Jens Lehmann, Heiko Voigt and Lars Hjemli for submodule related
   Porcelains.

 - J. Bruce Fields, Jonathan Nieder, Michael J Gruber and Thomas Rast for
   documentation (and countless others for proofreading and fixing).

 - Alexandre Julliard for Emacs integration.

 - David Aguilar and Charles Bailey for taking good care of git-mergetool
   (and Theodore Ts'o for creating it in the first place) and git-difftool.

 - Johannes Schindelin, Johannes Sixt, Erik Faye-Lund, Pat Thoyts and others
   for their effort to move things forward on the Windows front.

 - People on non-Linux platforms for keeping their eyes on portability;
   especially, Randal Schwartz, Theodore Ts'o, Jason Riedy, Thomas Glanzmann,
   Brandon Casey, Jeff King, Alex Riesen and countless others.

A note from the maintainer

[Junio C Hamano]

Welcome to the Git development community.

This message is written by the maintainer and talks about how Git
project is managed, and how you can work with it.

* Mailing list and the community

The development is primarily done on the Git mailing list. Help
requests, feature proposals, bug reports and patches should be sent to
the list address <git@vger.kernel.org>.  You don't have to be
subscribed to send messages.  The convention on the list is to keep
everybody involved on Cc:, so it is unnecessary to say "Please Cc: me,
I am not subscribed".

Before sending patches, please read Documentation/SubmittingPatches
and Documentation/CodingGuidelines to familiarize yourself with the
project convention.

If you sent a patch and you did not hear any response from anybody for
several days, it could be that your patch was totally uninteresting,
but it also is possible that it was simply lost in the noise.  Please
do not hesitate to send a reminder message in such a case.  Messages
getting lost in the noise is a sign that people involved don't have
enough mental/time bandwidth to process them right at the moment, and
it often helps to wait until the list traffic becomes calmer before
sending such a reminder.

The list archive is available at a few public sites:

        http://news.gmane.org/gmane.comp.version-control.git/
        http://marc.theaimsgroup.com/?l=git
        http://www.spinics.net/lists/git/

For those who prefer to read it over NNTP (including the maintainer):

        nntp://news.gmane.org/gmane.comp.version-control.git

When you point at a message in a mailing list archive, using
gmane is often the easiest to follow by readers, like this:

        http://thread.gmane.org/gmane.comp.version-control.git/27/focus=217

as it also allows people who subscribe to the mailing list as gmane
newsgroup to "jump to" the article.

Some members of the development community can sometimes also be found
on the #git IRC channel on Freenode.  Its log is available at:

        http://colabti.org/irclogger/irclogger_log/git

* Reporting bugs

When you think git does not behave as you expect, please do not stop
your bug report with just "git does not work".  "I used git in this
way, but it did not work" is not much better, neither is "I used git
in this way, and X happend, which is broken".  It often is that git is
correct to cause X happen in such a case, and it is your expectation
that is broken. People would not know what other result Y you expected
to see instead of X, if you left it unsaid.

Please remember to always state

 - what you wanted to achieve;

 - what you did (the version of git and the command sequence to reproduce
   the behavior);

 - what you saw happen (X above);

 - what you expected to see (Y above); and

 - how the last two are different.

See http://www.chiark.greenend.org.uk/~sgtatham/bugs.html for further
hints.

* Repositories, branches and documentation.

My public git.git repositories are at:

        git://git.kernel.org/pub/scm/git/git.git/
	git://repo.or.cz/alt-git.git/
	https://github.com/git/git/
	https://code.google.com/p/git-core/
	git://git.sourceforge.jp/gitroot/git-core/git.git/
	git://git-core.git.sourceforge.net/gitroot/git-core/git-core/

A few gitweb interfaces are found at:

        http://git.kernel.org/?p=git/git.git
        http://repo.or.cz/w/alt-git.git

Preformatted documentation from the tip of the "master" branch can be
found in:

        git://git.kernel.org/pub/scm/git/git-{htmldocs,manpages}.git/
        git://repo.or.cz/git-{htmldocs,manpages}.git/
        https://code.google.com/p/git-{htmldocs,manpages}.git/
        https://github.com/gitster/git-{htmldocs,manpages}.git/

You can browse the HTML manual pages at:

	http://git-htmldocs.googlecode.com/git/git.html

There are four branches in git.git repository that track the source tree
of git: "master", "maint", "next", and "pu".

The "master" branch is meant to contain what are very well tested and
ready to be used in a production setting.  Every now and then, a "feature
release" is cut from the tip of this branch and they typically are named
with three dotted decimal digits.  The last such release was 1.7.12 done on
Aug 19, 2012. You can expect that the tip of the "master" branch is always
more stable than any of the released versions.

Whenever a feature release is made, "maint" branch is forked off from
"master" at that point.  Obvious, safe and urgent fixes after a feature
release are applied to this branch and maintenance releases are cut from
it.  The maintenance releases are named with four dotted decimal, named
after the feature release they are updates to; the last such release was
1.7.12.3.  New features never go to this branch.  This branch is also
merged into "master" to propagate the fixes forward.

A new development does not usually happen on "master". When you send a
series of patches, after review on the mailing list, a separate topic
branch is forked from the tip of "master" and your patches are queued
there, and kept out of "master" while people test it out. The quality of
topic branches are judged primarily by the mailing list discussions.

Topic branches that are in good shape are merged to the "next" branch. In
general, the "next" branch always contains the tip of "master".  It might
not be quite rock-solid, but is expected to work more or less without major
breakage. The "next" branch is where new and exciting things take place. A
topic that is in "next" is expected to be polished to perfection before it
is merged to "master".

The "pu" (proposed updates) branch bundles all the remaining topic
branches. The topics on the branch are not complete, well tested, nor well
documented and need further work. When a topic that was in "pu" proves to
be in testable shape, it is merged to "next".

You can run "git log --first-parent master..pu" to see what topics are
currently in flight.  Sometimes, an idea that looked promising turns out
to be not so good and the topic can be dropped from "pu" in such a case.

The two branches "master" and "maint" are never rewound, and "next"
usually will not be either.  After a feature release is made from
"master", however, "next" will be rebuilt from the tip of "master"
using the topics that didn't make the cut in the feature release.

Note that being in "next" is not a guarantee to appear in the next
release, nor even in any future release.  There were cases that topics
needed reverting a few commits in them before graduating to "master",
or a topic that already was in "next" was reverted from "next" because
fatal flaws were found in it after it was merged.


* Other people's trees, trusted lieutenants and credits.

Documentation/SubmittingPatches outlines to whom your proposed changes
should be sent.  As described in contrib/README, I would delegate fixes
and enhancements in contrib/ area to the primary contributors of them.

Although the following are included in git.git repository, they have their
own authoritative repository and maintainers:

 - git-gui/ comes from git-gui project, maintained by Pat Thoyts:

        git://repo.or.cz/git-gui.git

 - gitk-git/ comes from Paul Mackerras's gitk project:

        git://git.kernel.org/pub/scm/gitk/gitk.git

 - po/ comes from the localization coordinator, Jiang Xin:

	https://github.com/git-l10n/git-po/

I would like to thank everybody who helped to raise git into the current
shape.  Especially I would like to thank the git list regulars whose help
I have relied on and expect to continue relying on heavily:

 - Linus Torvalds, Shawn Pearce, Johannes Schindelin, Nicolas Pitre,
   René Scharfe, Jeff King, Jonathan Nieder, Johan Herland, Johannes
   Sixt, Sverre Rabbelier, Michael J Gruber, Nguyễn Thái Ngọc Duy,
   Ævar Arnfjörð Bjarmason and Thomas Rast for helping with general
   design and implementation issues and reviews on the mailing list.

 - Shawn and Nicolas Pitre for helping with packfile design and
   implementation issues.

 - Martin Langhoff, Frank Lichtenheld and Ævar Arnfjörð Bjarmason for
   cvsserver and cvsimport.

 - Paul Mackerras for gitk.

 - Eric Wong, David D. Kilzer and Sam Vilain for git-svn.

 - Simon Hausmann, Pete Wyckoff and Luke Diamond for git-p4.

 - Jakub Narebski, John Hawley, Petr Baudis, Luben Tuikov, Giuseppe
   Bilotta for maintaining and enhancing gitweb.

 - Ævar Arnfjörð Bjarmason for kicking off the i18n effort, and Jiang
   Xin for volunteering to be the l10n coordinator.

 - Jens Lehmann, Heiko Voigt and Lars Hjemli for submodule related
   Porcelains.

 - J. Bruce Fields, Jonathan Nieder, Michael J Gruber and Thomas Rast for
   documentation (and countless others for proofreading and fixing).

 - Alexandre Julliard for Emacs integration.

 - David Aguilar and Charles Bailey for taking good care of git-mergetool
   (and Theodore Ts'o for creating it in the first place) and git-difftool.

 - Johannes Schindelin, Johannes Sixt, Erik Faye-Lund, Pat Thoyts and others
   for their effort to move things forward on the Windows front.

 - People on non-Linux platforms for keeping their eyes on portability;
   especially, Randal Schwartz, Theodore Ts'o, Jason Riedy, Thomas Glanzmann,
   Brandon Casey, Jeff King, Alex Riesen and countless others.

A note from the maintainer

[Junio C Hamano]

Welcome to the Git development community.

This message is written by the maintainer and talks about how Git
project is managed, and how you can work with it.

* Mailing list and the community

The development is primarily done on the Git mailing list. Help
requests, feature proposals, bug reports and patches should be sent to
the list address <git@vger.kernel.org>.  You don't have to be
subscribed to send messages.  The convention on the list is to keep
everybody involved on Cc:, so it is unnecessary to say "Please Cc: me,
I am not subscribed".

Before sending patches, please read Documentation/SubmittingPatches
and Documentation/CodingGuidelines to familiarize yourself with the
project convention.

If you sent a patch and you did not hear any response from anybody for
several days, it could be that your patch was totally uninteresting,
but it also is possible that it was simply lost in the noise.  Please
do not hesitate to send a reminder message in such a case.  Messages
getting lost in the noise is a sign that people involved don't have
enough mental/time bandwidth to process them right at the moment, and
it often helps to wait until the list traffic becomes calmer before
sending such a reminder.

The list archive is available at a few public sites:

        http://news.gmane.org/gmane.comp.version-control.git/
        http://marc.theaimsgroup.com/?l=git
        http://www.spinics.net/lists/git/

For those who prefer to read it over NNTP (including the maintainer):

        nntp://news.gmane.org/gmane.comp.version-control.git

When you point at a message in a mailing list archive, using
gmane is often the easiest to follow by readers, like this:

        http://thread.gmane.org/gmane.comp.version-control.git/27/focus=217

as it also allows people who subscribe to the mailing list as gmane
newsgroup to "jump to" the article.

Some members of the development community can sometimes also be found
on the #git IRC channel on Freenode.  Its log is available at:

        http://colabti.org/irclogger/irclogger_log/git

* Reporting bugs

When you think git does not behave as you expect, please do not stop
your bug report with just "git does not work".  "I used git in this
way, but it did not work" is not much better, neither is "I used git
in this way, and X happend, which is broken".  It often is that git is
correct to cause X happen in such a case, and it is your expectation
that is broken. People would not know what other result Y you expected
to see instead of X, if you left it unsaid.

Please remember to always state

 - what you wanted to achieve;

 - what you did (the version of git and the command sequence to reproduce
   the behavior);

 - what you saw happen (X above);

 - what you expected to see (Y above); and

 - how the last two are different.

See http://www.chiark.greenend.org.uk/~sgtatham/bugs.html for further
hints.

* Repositories, branches and documentation.

My public git.git repositories are at:

        git://git.kernel.org/pub/scm/git/git.git/
	git://repo.or.cz/alt-git.git/
	https://github.com/git/git/
	https://code.google.com/p/git-core/
	git://git.sourceforge.jp/gitroot/git-core/git.git/
	git://git-core.git.sourceforge.net/gitroot/git-core/git-core/

A few gitweb interfaces are found at:

        http://git.kernel.org/?p=git/git.git
        http://repo.or.cz/w/alt-git.git

Preformatted documentation from the tip of the "master" branch can be
found in:

        git://git.kernel.org/pub/scm/git/git-{htmldocs,manpages}.git/
        git://repo.or.cz/git-{htmldocs,manpages}.git/
        https://code.google.com/p/git-{htmldocs,manpages}.git/
        https://github.com/gitster/git-{htmldocs,manpages}.git/

You can browse the HTML manual pages at:

	http://git-htmldocs.googlecode.com/git/git.html

There are four branches in git.git repository that track the source tree
of git: "master", "maint", "next", and "pu".

The "master" branch is meant to contain what are very well tested and
ready to be used in a production setting.  Every now and then, a "feature
release" is cut from the tip of this branch and they typically are named
with three dotted decimal digits.  The last such release was 1.7.12 done on
Aug 19, 2012. You can expect that the tip of the "master" branch is always
more stable than any of the released versions.

Whenever a feature release is made, "maint" branch is forked off from
"master" at that point.  Obvious, safe and urgent fixes after a feature
release are applied to this branch and maintenance releases are cut from
it.  The maintenance releases are named with four dotted decimal, named
after the feature release they are updates to; the last such release was
1.7.12.1.  New features never go to this branch.  This branch is also
merged into "master" to propagate the fixes forward.

A new development does not usually happen on "master". When you send a
series of patches, after review on the mailing list, a separate topic
branch is forked from the tip of "master" and your patches are queued
there, and kept out of "master" while people test it out. The quality of
topic branches are judged primarily by the mailing list discussions.

Topic branches that are in good shape are merged to the "next" branch. In
general, the "next" branch always contains the tip of "master".  It might
not be quite rock-solid, but is expected to work more or less without major
breakage. The "next" branch is where new and exciting things take place. A
topic that is in "next" is expected to be polished to perfection before it
is merged to "master".

The "pu" (proposed updates) branch bundles all the remaining topic
branches. The topics on the branch are not complete, well tested, nor well
documented and need further work. When a topic that was in "pu" proves to
be in testable shape, it is merged to "next".

You can run "git log --first-parent master..pu" to see what topics are
currently in flight.  Sometimes, an idea that looked promising turns out
to be not so good and the topic can be dropped from "pu" in such a case.

The two branches "master" and "maint" are never rewound, and "next"
usually will not be either.  After a feature release is made from
"master", however, "next" will be rebuilt from the tip of "master"
using the topics that didn't make the cut in the feature release.

Note that being in "next" is not a guarantee to appear in the next
release, nor even in any future release.  There were cases that topics
needed reverting a few commits in them before graduating to "master",
or a topic that already was in "next" was reverted from "next" because
fatal flaws were found in it after it was merged.


* Other people's trees, trusted lieutenants and credits.

Documentation/SubmittingPatches outlines to whom your proposed changes
should be sent.  As described in contrib/README, I would delegate fixes
and enhancements in contrib/ area to the primary contributors of them.

Although the following are included in git.git repository, they have their
own authoritative repository and maintainers:

 - git-gui/ comes from git-gui project, maintained by Pat Thoyts:

        git://repo.or.cz/git-gui.git

 - gitk-git/ comes from Paul Mackerras's gitk project:

        git://git.kernel.org/pub/scm/gitk/gitk.git

 - po/ comes from the localization coordinator, Jiang Xin:

	https://github.com/git-l10n/git-po/

I would like to thank everybody who helped to raise git into the current
shape.  Especially I would like to thank the git list regulars whose help
I have relied on and expect to continue relying on heavily:

 - Linus Torvalds, Shawn Pearce, Johannes Schindelin, Nicolas Pitre,
   René Scharfe, Jeff King, Jonathan Nieder, Johan Herland, Johannes
   Sixt, Sverre Rabbelier, Michael J Gruber, Nguyễn Thái Ngọc Duy,
   Ævar Arnfjörð Bjarmason and Thomas Rast for helping with general
   design and implementation issues and reviews on the mailing list.

 - Shawn and Nicolas Pitre for helping with packfile design and
   implementation issues.

 - Martin Langhoff, Frank Lichtenheld and Ævar Arnfjörð Bjarmason for
   cvsserver and cvsimport.

 - Paul Mackerras for gitk.

 - Eric Wong, David D. Kilzer and Sam Vilain for git-svn.

 - Simon Hausmann, Pete Wyckoff and Luke Diamond for git-p4.

 - Jakub Narebski, John Hawley, Petr Baudis, Luben Tuikov, Giuseppe
   Bilotta for maintaining and enhancing gitweb.

 - Ævar Arnfjörð Bjarmason for kicking off the i18n effort, and Jiang
   Xin for volunteering to be the l10n coordinator.

 - Jens Lehmann, Heiko Voigt and Lars Hjemli for submodule related
   Porcelains.

 - J. Bruce Fields, Jonathan Nieder, Michael J Gruber and Thomas Rast for
   documentation (and countless others for proofreading and fixing).

 - Alexandre Julliard for Emacs integration.

 - David Aguilar and Charles Bailey for taking good care of git-mergetool
   (and Theodore Ts'o for creating it in the first place) and git-difftool.

 - Johannes Schindelin, Johannes Sixt, Erik Faye-Lund, Pat Thoyts and others
   for their effort to move things forward on the Windows front.

 - People on non-Linux platforms for keeping their eyes on portability;
   especially, Randal Schwartz, Theodore Ts'o, Jason Riedy, Thomas Glanzmann,
   Brandon Casey, Jeff King, Alex Riesen and countless others.

A note from the maintainer

[Junio C Hamano]

Welcome to the Git development community.

This message is written by the maintainer and talks about how Git
project is managed, and how you can work with it.

* Mailing list and the community

The development is primarily done on the Git mailing list. Help
requests, feature proposals, bug reports and patches should be sent to
the list address <git@vger.kernel.org>.  You don't have to be
subscribed to send messages.  The convention on the list is to keep
everybody involved on Cc:, so it is unnecessary to say "Please Cc: me,
I am not subscribed".

Before sending patches, please read Documentation/SubmittingPatches
and Documentation/CodingGuidelines to familiarize yourself with the
project convention.

If you sent a patch and you did not hear any response from anybody for
several days, it could be that your patch was totally uninteresting,
but it also is possible that it was simply lost in the noise.  Please
do not hesitate to send a reminder message in such a case.  Messages
getting lost in the noise is a sign that people involved don't have
enough mental/time bandwidth to process them right at the moment, and
it often helps to wait until the list traffic becomes calmer before
sending such a reminder.

The list archive is available at a few public sites:

        http://news.gmane.org/gmane.comp.version-control.git/
        http://marc.theaimsgroup.com/?l=git
        http://www.spinics.net/lists/git/

For those who prefer to read it over NNTP (including the maintainer):

        nntp://news.gmane.org/gmane.comp.version-control.git

When you point at a message in a mailing list archive, using
gmane is often the easiest to follow by readers, like this:

        http://thread.gmane.org/gmane.comp.version-control.git/27/focus=217

as it also allows people who subscribe to the mailing list as gmane
newsgroup to "jump to" the article.

Some members of the development community can sometimes also be found
on the #git IRC channel on Freenode.  Its log is available at:

        http://colabti.org/irclogger/irclogger_log/git

* Reporting bugs

When you think git does not behave as you expect, please do not stop
your bug report with just "git does not work".  "I used git in this
way, but it did not work" is not much better, neither is "I used git
in this way, and X happend, which is broken".  It often is that git is
correct to cause X happen in such a case, and it is your expectation
that is broken. People would not know what other result Y you expected
to see instead of X, if you left it unsaid.

Please remember to always state

 - what you wanted to achieve;

 - what you did (the version of git and the command sequence to reproduce
   the behavior);

 - what you saw happen (X above);

 - what you expected to see (Y above); and

 - how the last two are different.

See http://www.chiark.greenend.org.uk/~sgtatham/bugs.html for further
hints.

* Repositories, branches and documentation.

My public git.git repositories are at:

        git://git.kernel.org/pub/scm/git/git.git/
	git://repo.or.cz/alt-git.git/
	https://github.com/git/git/
	https://code.google.com/p/git-core/
	git://git.sourceforge.jp/gitroot/git-core/git.git/
	git://git-core.git.sourceforge.net/gitroot/git-core/git-core/

A few gitweb interfaces are found at:

        http://git.kernel.org/?p=git/git.git
        http://repo.or.cz/w/alt-git.git

Preformatted documentation from the tip of the "master" branch can be
found in:

        git://git.kernel.org/pub/scm/git/git-{htmldocs,manpages}.git/
        git://repo.or.cz/git-{htmldocs,manpages}.git/
        https://code.google.com/p/git-{htmldocs,manpages}.git/
        https://github.com/gitster/git-{htmldocs,manpages}.git/

You can browse the HTML manual pages at:

	http://git-htmldocs.googlecode.com/git/git.html

There are four branches in git.git repository that track the source tree
of git: "master", "maint", "next", and "pu".

The "master" branch is meant to contain what are very well tested and
ready to be used in a production setting.  Every now and then, a "feature
release" is cut from the tip of this branch and they typically are named
with three dotted decimal digits.  The last such release was 1.7.12 done on
Aug 19, 2012. You can expect that the tip of the "master" branch is always
more stable than any of the released versions.

Whenever a feature release is made, "maint" branch is forked off from
"master" at that point.  Obvious, safe and urgent fixes after a feature
release are applied to this branch and maintenance releases are cut from
it.  The maintenance releases are named with four dotted decimal, named
after the feature release they are updates to; the last such release was
1.7.11.5.  New features never go to this branch.  This branch is also
merged into "master" to propagate the fixes forward.

A new development does not usually happen on "master". When you send a
series of patches, after review on the mailing list, a separate topic
branch is forked from the tip of "master" and your patches are queued
there, and kept out of "master" while people test it out. The quality of
topic branches are judged primarily by the mailing list discussions.

Topic branches that are in good shape are merged to the "next" branch. In
general, the "next" branch always contains the tip of "master".  It might
not be quite rock-solid, but is expected to work more or less without major
breakage. The "next" branch is where new and exciting things take place. A
topic that is in "next" is expected to be polished to perfection before it
is merged to "master".

The "pu" (proposed updates) branch bundles all the remaining topic
branches. The topics on the branch are not complete, well tested, nor well
documented and need further work. When a topic that was in "pu" proves to
be in testable shape, it is merged to "next".

You can run "git log --first-parent master..pu" to see what topics are
currently in flight.  Sometimes, an idea that looked promising turns out
to be not so good and the topic can be dropped from "pu" in such a case.

The two branches "master" and "maint" are never rewound, and "next"
usually will not be either.  After a feature release is made from
"master", however, "next" will be rebuilt from the tip of "master"
using the topics that didn't make the cut in the feature release.

Note that being in "next" is not a guarantee to appear in the next
release, nor even in any future release.  There were cases that topics
needed reverting a few commits in them before graduating to "master",
or a topic that already was in "next" was reverted from "next" because
fatal flaws were found in it after it was merged.


* Other people's trees, trusted lieutenants and credits.

Documentation/SubmittingPatches outlines to whom your proposed changes
should be sent.  As described in contrib/README, I would delegate fixes
and enhancements in contrib/ area to the primary contributors of them.

Although the following are included in git.git repository, they have their
own authoritative repository and maintainers:

 - git-gui/ comes from git-gui project, maintained by Pat Thoyts:

        git://repo.or.cz/git-gui.git

 - gitk-git/ comes from Paul Mackerras's gitk project:

        git://git.kernel.org/pub/scm/gitk/gitk.git

 - po/ comes from the localization coordinator, Jiang Xin:

	https://github.com/git-l10n/git-po/

I would like to thank everybody who helped to raise git into the current
shape.  Especially I would like to thank the git list regulars whose help
I have relied on and expect to continue relying on heavily:

 - Linus Torvalds, Shawn Pearce, Johannes Schindelin, Nicolas Pitre,
   René Scharfe, Jeff King, Jonathan Nieder, Johan Herland, Johannes
   Sixt, Sverre Rabbelier, Michael J Gruber, Nguyễn Thái Ngọc Duy,
   Ævar Arnfjörð Bjarmason and Thomas Rast for helping with general
   design and implementation issues and reviews on the mailing list.

 - Shawn and Nicolas Pitre for helping with packfile design and
   implementation issues.

 - Martin Langhoff, Frank Lichtenheld and Ævar Arnfjörð Bjarmason for
   cvsserver and cvsimport.

 - Paul Mackerras for gitk.

 - Eric Wong, David D. Kilzer and Sam Vilain for git-svn.

 - Simon Hausmann, Pete Wyckoff and Luke Diamond for git-p4.

 - Jakub Narebski, John Hawley, Petr Baudis, Luben Tuikov, Giuseppe
   Bilotta for maintaining and enhancing gitweb.

 - Ævar Arnfjörð Bjarmason for kicking off the i18n effort, and Jiang
   Xin for volunteering to be the l10n coordinator.

 - Jens Lehmann, Heiko Voigt and Lars Hjemli for submodule related
   Porcelains.

 - J. Bruce Fields, Jonathan Nieder, Michael J Gruber and Thomas Rast for
   documentation (and countless others for proofreading and fixing).

 - Alexandre Julliard for Emacs integration.

 - David Aguilar and Charles Bailey for taking good care of git-mergetool
   (and Theodore Ts'o for creating it in the first place) and git-difftool.

 - Johannes Schindelin, Johannes Sixt, Erik Faye-Lund, Pat Thoyts and others
   for their effort to move things forward on the Windows front.

 - People on non-Linux platforms for keeping their eyes on portability;
   especially, Randal Schwartz, Theodore Ts'o, Jason Riedy, Thomas Glanzmann,
   Brandon Casey, Jeff King, Alex Riesen and countless others.

A note from the maintainer

[Junio C Hamano]

Welcome to git development community.

This message is written by the maintainer and talks about how Git
project is managed, and how you can work with it.

* Mailing list and the community

The development is primarily done on the Git mailing list. Help
requests, feature proposals, bug reports and patches should be sent to
the list address <git@vger.kernel.org>.  You don't have to be
subscribed to send messages.  The convention on the list is to keep
everybody involved on Cc:, so it is unnecessary to say "Please Cc: me,
I am not subscribed".

Before sending patches, please read Documentation/SubmittingPatches
and Documentation/CodingGuidelines to familiarize yourself with the
project convention.

If you sent a patch and you did not hear any response from anybody for
several days, it could be that your patch was totally uninteresting,
but it also is possible that it was simply lost in the noise.  Please
do not hesitate to send a reminder message in such a case.  Messages
getting lost in the noise is a sign that people involved don't have
enough mental/time bandwidth to process them right at the moment, and
it often helps to wait until the list traffic becomes calmer before
sending such a reminder.

The list archive is available at a few public sites:

        http://news.gmane.org/gmane.comp.version-control.git/
        http://marc.theaimsgroup.com/?l=git
        http://www.spinics.net/lists/git/

For those who prefer to read it over NNTP (including the maintainer):

        nntp://news.gmane.org/gmane.comp.version-control.git

When you point at a message in a mailing list archive, using
gmane is often the easiest to follow by readers, like this:

        http://thread.gmane.org/gmane.comp.version-control.git/27/focus=217

as it also allows people who subscribe to the mailing list as gmane
newsgroup to "jump to" the article.

Some members of the development community can sometimes also be found
on the #git IRC channel on Freenode.  Its log is available at:

        http://colabti.org/irclogger/irclogger_log/git

* Reporting bugs

When you think git does not behave as you expect, please do not stop
your bug report with just "git does not work".  "I used git in this
way, but it did not work" is not much better, neither is "I used git
in this way, and X happend, which is broken".  It often is that git is
correct to cause X happen in such a case, and it is your expectation
that is broken. People would not know what other result Y you expected
to see instead of X, if you left it unsaid.

Please remember to always state

 - what you wanted to achieve;

 - what you did (the version of git and the command sequence to reproduce
   the behavior);

 - what you saw happen (X above);

 - what you expected to see (Y above); and

 - how the last two are different.

See http://www.chiark.greenend.org.uk/~sgtatham/bugs.html for further
hints.

* Repositories, branches and documentation.

My public git.git repositories are at:

        git://git.kernel.org/pub/scm/git/git.git/
	git://repo.or.cz/alt-git.git/
	https://github.com/git/git/
	https://code.google.com/p/git-core/
	git://git.sourceforge.jp/gitroot/git-core/git.git/
	git://git-core.git.sourceforge.net/gitroot/git-core/git-core/

A few gitweb interfaces are found at:

        http://git.kernel.org/?p=git/git.git
        http://repo.or.cz/w/alt-git.git

Preformatted documentation from the tip of the "master" branch can be
found in:

        git://git.kernel.org/pub/scm/git/git-{htmldocs,manpages}.git/
        git://repo.or.cz/git-{htmldocs,manpages}.git/
        https://code.google.com/p/git-{htmldocs,manpages}.git/
        https://github.com/gitster/git-{htmldocs,manpages}.git/

You can browse the HTML manual pages at:

	http://git-htmldocs.googlecode.com/git/git.html

There are four branches in git.git repository that track the source tree
of git: "master", "maint", "next", and "pu".

The "master" branch is meant to contain what are very well tested and
ready to be used in a production setting.  Every now and then, a "feature
release" is cut from the tip of this branch and they typically are named
with three dotted decimal digits.  The last such release was 1.7.11 done on
Jun 17, 2012. You can expect that the tip of the "master" branch is always
more stable than any of the released versions.

Whenever a feature release is made, "maint" branch is forked off from
"master" at that point.  Obvious, safe and urgent fixes after a feature
release are applied to this branch and maintenance releases are cut from
it.  The maintenance releases are named with four dotted decimal, named
after the feature release they are updates to; the last such release was
1.7.10.5.  New features never go to this branch.  This branch is also
merged into "master" to propagate the fixes forward.

A new development does not usually happen on "master". When you send a
series of patches, after review on the mailing list, a separate topic
branch is forked from the tip of "master" and your patches are queued
there, and kept out of "master" while people test it out. The quality of
topic branches are judged primarily by the mailing list discussions.

Topic branches that are in good shape are merged to the "next" branch. In
general, the "next" branch always contains the tip of "master".  It might
not be quite rock-solid, but is expected to work more or less without major
breakage. The "next" branch is where new and exciting things take place. A
topic that is in "next" is expected to be polished to perfection before it
is merged to "master".

The "pu" (proposed updates) branch bundles all the remaining topic
branches. The topics on the branch are not complete, well tested, nor well
documented and need further work. When a topic that was in "pu" proves to
be in testable shape, it is merged to "next".

You can run "git log --first-parent master..pu" to see what topics are
currently in flight.  Sometimes, an idea that looked promising turns out
to be not so good and the topic can be dropped from "pu" in such a case.

The two branches "master" and "maint" are never rewound, and "next"
usually will not be either.  After a feature release is made from
"master", however, "next" will be rebuilt from the tip of "master"
using the topics that didn't make the cut in the feature release.

Note that being in "next" is not a guarantee to appear in the next
release, nor even in any future release.  There were cases that topics
needed reverting a few commits in them before graduating to "master",
or a topic that already was in "next" was reverted from "next" because
fatal flaws were found in it after it was merged.


* Other people's trees, trusted lieutenants and credits.

Documentation/SubmittingPatches outlines to whom your proposed changes
should be sent.  As described in contrib/README, I would delegate fixes
and enhancements in contrib/ area to the primary contributors of them.

Although the following are included in git.git repository, they have their
own authoritative repository and maintainers:

 - git-gui/ comes from git-gui project, maintained by Pat Thoyts:

        git://repo.or.cz/git-gui.git

 - gitk-git/ comes from Paul Mackerras's gitk project:

        git://git.kernel.org/pub/scm/gitk/gitk.git

 - po/ comes from the localization coordinator, Jiang Xin:

	https://github.com/git-l10n/git-po/

I would like to thank everybody who helped to raise git into the current
shape.  Especially I would like to thank the git list regulars whose help
I have relied on and expect to continue relying on heavily:

 - Linus Torvalds, Shawn Pearce, Johannes Schindelin, Nicolas Pitre,
   René Scharfe, Jeff King, Jonathan Nieder, Johan Herland, Johannes
   Sixt, Sverre Rabbelier, Michael J Gruber, Nguyễn Thái Ngọc Duy,
   Ævar Arnfjörð Bjarmason and Thomas Rast for helping with general
   design and implementation issues and reviews on the mailing list.

 - Shawn and Nicolas Pitre for helping with packfile design and
   implementation issues.

 - Martin Langhoff, Frank Lichtenheld and Ævar Arnfjörð Bjarmason for
   cvsserver and cvsimport.

 - Paul Mackerras for gitk.

 - Eric Wong, David D. Kilzer and Sam Vilain for git-svn.

 - Simon Hausmann, Pete Wyckoff and Luke Diamond for git-p4.

 - Jakub Narebski, John Hawley, Petr Baudis, Luben Tuikov, Giuseppe
   Bilotta for maintaining and enhancing gitweb.

 - Ævar Arnfjörð Bjarmason for kicking off the i18n effort, and Jiang
   Xin for volunteering to be the l10n coordinator.

 - Jens Lehmann, Heiko Voigt and Lars Hjemli for submodule related
   Porcelains.

 - J. Bruce Fields, Jonathan Nieder, Michael J Gruber and Thomas Rast for
   documentation (and countless others for proofreading and fixing).

 - Alexandre Julliard for Emacs integration.

 - David Aguilar and Charles Bailey for taking good care of git-mergetool
   (and Theodore Ts'o for creating it in the first place) and git-difftool.

 - Johannes Schindelin, Johannes Sixt, Erik Faye-Lund, Pat Thoyts and others
   for their effort to move things forward on the Windows front.

 - People on non-Linux platforms for keeping their eyes on portability;
   especially, Randal Schwartz, Theodore Ts'o, Jason Riedy, Thomas Glanzmann,
   Brandon Casey, Jeff King, Alex Riesen and countless others.

A note from the maintainer

[Junio C Hamano]

Welcome to git development community.

This message is written by the maintainer and talks about how Git
project is managed, and how you can work with it.

* Mailing list and the community

The development is primarily done on the Git mailing list. Help
requests, feature proposals, bug reports and patches should be sent to
the list address <git@vger.kernel.org>.  You don't have to be
subscribed to send messages.  The convention on the list is to keep
everybody involved on Cc:, so it is unnecessary to say "Please Cc: me,
I am not subscribed".

Before sending patches, please read Documentation/SubmittingPatches
and Documentation/CodingGuidelines to familiarize yourself with the
project convention.

If you sent a patch and you did not hear any response from anybody for
several days, it could be that your patch was totally uninteresting,
but it also is possible that it was simply lost in the noise.  Please
do not hesitate to send a reminder message in such a case.  Messages
getting lost in the noise is a sign that people involved don't have
enough mental/time bandwidth to process them right at the moment, and
it often helps to wait until the list traffic becomes calmer before
sending such a reminder.

The list archive is available at a few public sites:

        http://news.gmane.org/gmane.comp.version-control.git/
        http://marc.theaimsgroup.com/?l=git
        http://www.spinics.net/lists/git/

For those who prefer to read it over NNTP (including the maintainer):

        nntp://news.gmane.org/gmane.comp.version-control.git

When you point at a message in a mailing list archive, using
gmane is often the easiest to follow by readers, like this:

        http://thread.gmane.org/gmane.comp.version-control.git/27/focus=217

as it also allows people who subscribe to the mailing list as gmane
newsgroup to "jump to" the article.

Some members of the development community can sometimes also be found
on the #git IRC channel on Freenode.  Its log is available at:

        http://colabti.org/irclogger/irclogger_log/git

* Reporting bugs

When you think git does not behave as you expect, please do not stop
your bug report with just "git does not work".  "I used git in this
way, but it did not work" is not much better, neither is "I used git
in this way, and X happend, which is broken".  It often is that git is
correct to cause X happen in such a case, and it is your expectation
that is broken. People would not know what other result Y you expected
to see instead of X, if you left it unsaid.

Please remember to always state

 - what you wanted to achieve;

 - what you did (the version of git and the command sequence to reproduce
   the behavior);

 - what you saw happen (X above);

 - what you expected to see (Y above); and

 - how the last two are different.

See http://www.chiark.greenend.org.uk/~sgtatham/bugs.html for further
hints.

* Repositories, branches and documentation.

My public git.git repositories are at:

        git://git.kernel.org/pub/scm/git/git.git/
	git://repo.or.cz/alt-git.git/
	https://github.com/git/git/
	https://code.google.com/p/git-core/
	git://git.sourceforge.jp/gitroot/git-core/git.git/
	git://git-core.git.sourceforge.net/gitroot/git-core/git-core/

A few gitweb interfaces are found at:

        http://git.kernel.org/?p=git/git.git
        http://repo.or.cz/w/alt-git.git

Preformatted documentation from the tip of the "master" branch can be
found in:

        git://git.kernel.org/pub/scm/git/git-{htmldocs,manpages}.git/
        git://repo.or.cz/git-{htmldocs,manpages}.git/
        https://code.google.com/p/git-{htmldocs,manpages}.git/
        https://github.com/gitster/git-{htmldocs,manpages}.git/

You can browse the HTML manual pages at:

	http://git-htmldocs.googlecode.com/git/git.html

There are four branches in git.git repository that track the source tree
of git: "master", "maint", "next", and "pu".

The "master" branch is meant to contain what are very well tested and
ready to be used in a production setting.  Every now and then, a "feature
release" is cut from the tip of this branch and they typically are named
with three dotted decimal digits.  The last such release was 1.7.9 done on
Jan 27, 2012. You can expect that the tip of the "master" branch is always
more stable than any of the released versions.

Whenever a feature release is made, "maint" branch is forked off from
"master" at that point.  Obvious, safe and urgent fixes after a feature
release are applied to this branch and maintenance releases are cut from
it.  The maintenance releases are named with four dotted decimal, named
after the feature release they are updates to; the last such release was
1.7.9.3.  New features never go to this branch.  This branch is also
merged into "master" to propagate the fixes forward.

A new development does not usually happen on "master". When you send a
series of patches, after review on the mailing list, a separate topic
branch is forked from the tip of "master" and your patches are queued
there, and kept out of "master" while people test it out. The quality of
topic branches are judged primarily by the mailing list discussions.

Topic branches that are in good shape are merged to the "next" branch. In
general, the "next" branch always contains the tip of "master".  It might
not be quite rock-solid, but is expected to work more or less without major
breakage. The "next" branch is where new and exciting things take place. A
topic that is in "next" is expected to be polished to perfection before it
is merged to "master".

The "pu" (proposed updates) branch bundles all the remaining topic
branches. The topics on the branch are not complete, well tested, nor well
documented and need further work. When a topic that was in "pu" proves to
be in testable shape, it is merged to "next".

You can run "git log --first-parent master..pu" to see what topics are
currently in flight.  Sometimes, an idea that looked promising turns out
to be not so good and the topic can be dropped from "pu" in such a case.

The two branches "master" and "maint" are never rewound, and "next"
usually will not be either.  After a feature release is made from
"master", however, "next" will be rebuilt from the tip of "master"
using the topics that didn't make the cut in the feature release.

Note that being in "next" is not a guarantee to appear in the next
release, nor even in any future release.  There were cases that topics
needed reverting a few commits in them before graduating to "master",
or a topic that already was in "next" was reverted from "next" because
fatal flaws were found in it after it was merged.


* Other people's trees, trusted lieutenants and credits.

Documentation/SubmittingPatches outlines to whom your proposed changes
should be sent.  As described in contrib/README, I would delegate fixes
and enhancements in contrib/ area to the primary contributors of them.

Although the following are included in git.git repository, they have their
own authoritative repository and maintainers:

 - git-gui/ comes from git-gui project, maintained by Pat Thoyts:

        git://repo.or.cz/git-gui.git

 - gitk-git/ comes from Paul Mackerras's gitk project:

        git://git.kernel.org/pub/scm/gitk/gitk.git

 - po/ comes from the localization coordinator, Jiang Xin:

	https://github.com/git-l10n/git-po/

I would like to thank everybody who helped to raise git into the current
shape.  Especially I would like to thank the git list regulars whose help
I have relied on and expect to continue relying on heavily:

 - Linus Torvalds, Shawn Pearce, Johannes Schindelin, Nicolas Pitre,
   René Scharfe, Jeff King, Jonathan Nieder, Johan Herland, Johannes
   Sixt, Sverre Rabbelier, Michael J Gruber, Nguyễn Thái Ngọc Duy,
   Ævar Arnfjörð Bjarmason and Thomas Rast for helping with general
   design and implementation issues and reviews on the mailing list.

 - Shawn and Nicolas Pitre for helping with packfile design and
   implementation issues.

 - Martin Langhoff, Frank Lichtenheld and Ævar Arnfjörð Bjarmason for
   cvsserver and cvsimport.

 - Paul Mackerras for gitk.

 - Eric Wong, David D. Kilzer and Sam Vilain for git-svn.

 - Simon Hausmann, Pete Wyckoff and Luke Diamond for git-p4.

 - Jakub Narebski, John Hawley, Petr Baudis, Luben Tuikov, Giuseppe
   Bilotta for maintaining and enhancing gitweb.

 - Ævar Arnfjörð Bjarmason for kicking off the i18n effort, and Jiang
   Xin for volunteering to be the l10n coordinator.

 - J. Bruce Fields, Jonathan Nieder, Michael J Gruber and Thomas Rast for
   documentation (and countless others for proofreading and fixing).

 - Alexandre Julliard for Emacs integration.

 - David Aguilar and Charles Bailey for taking good care of git-mergetool
   (and Theodore Ts'o for creating it in the first place) and git-difftool.

 - Johannes Schindelin, Johannes Sixt, Erik Faye-Lund, Pat Thoyts and others
   for their effort to move things forward on the Windows front.

 - People on non-Linux platforms for keeping their eyes on portability;
   especially, Randal Schwartz, Theodore Ts'o, Jason Riedy, Thomas Glanzmann,
   Brandon Casey, Jeff King, Alex Riesen and countless others.

[ANNOUNCE] Git 1.7.9

[Junio C Hamano]

The latest feature release Git 1.7.9 is now available at the usual
places.

The release tarballs are found at:

    http://code.google.com/p/git-core/downloads/list

and their SHA-1 checksums are:

ed51ef5ef250daaa6e98515cf2641820cd268d4c  git-1.7.9.tar.gz
c7b1fa20dc501beb2cb5091dd24dbfd2a0013a0c  git-htmldocs-1.7.9.tar.gz
1ca1fc430b2814f9e9cf82ec3bf7f2eaf5209b7a  git-manpages-1.7.9.tar.gz

Also the following public repositories all have a copy of the v1.7.9
tag and the master branch that the tag points at:

  url = git://repo.or.cz/alt-git.git
  url = https://code.google.com/p/git-core/
  url = git://git.sourceforge.jp/gitroot/git-core/git.git
  url = git://git-core.git.sourceforge.net/gitroot/git-core/git-core
  url = https://github.com/gitster/git

Have fun.


Git v1.7.9 Release Notes
========================

Updates since v1.7.8
--------------------

 * gitk updates accumulated since early 2011.

 * git-gui updated to 0.16.0.

 * git-p4 (in contrib/) updates.

 * Git uses gettext to translate its most common interface messages
   into the user's language if translations are available and the
   locale is appropriately set. Distributors can drop new PO files
   in po/ to add new translations.

 * The code to handle username/password for HTTP transactions used in
   "git push" & "git fetch" learned to talk "credential API" to
   external programs to cache or store them, to allow integration with
   platform native keychain mechanisms.

 * The input prompts in the terminal use our own getpass() replacement
   when possible. HTTP transactions used to ask for the username without
   echoing back what was typed, but with this change you will see it as
   you type.

 * The internals of "revert/cherry-pick" have been tweaked to prepare
   building more generic "sequencer" on top of the implementation that
   drives them.

 * "git rev-parse FETCH_HEAD" after "git fetch" without specifying
   what to fetch from the command line will now show the commit that
   would be merged if the command were "git pull".

 * "git add" learned to stream large files directly into a packfile
   instead of writing them into individual loose object files.

 * "git checkout -B <current branch> <elsewhere>" is a more intuitive
   way to spell "git reset --keep <elsewhere>".

 * "git checkout" and "git merge" learned "--no-overwrite-ignore" option
   to tell Git that untracked and ignored files are not expendable.

 * "git commit --amend" learned "--no-edit" option to say that the
   user is amending the tree being recorded, without updating the
   commit log message.

 * "git commit" and "git reset" re-learned the optimization to prime
   the cache-tree information in the index, which makes it faster to
   write a tree object out after the index entries are updated.

 * "git commit" detects and rejects an attempt to stuff NUL byte in
   the commit log message.

 * "git commit" learned "-S" to GPG-sign the commit; this can be shown
   with the "--show-signature" option to "git log".

 * fsck and prune are relatively lengthy operations that still go
   silent while making the end-user wait. They learned to give progress
   output like other slow operations.

 * The set of built-in function-header patterns for various languages
   knows MATLAB.

 * "git log --format='<format>'" learned new %g[nNeE] specifiers to
   show information from the reflog entries when walking the reflog
   (i.e. with "-g").

 * "git pull" can be used to fetch and merge an annotated/signed tag,
   instead of the tip of a topic branch. The GPG signature from the
   signed tag is recorded in the resulting merge commit for later
   auditing.

 * "git log" learned "--show-signature" option to show the signed tag
   that was merged that is embedded in the merge commit. It also can
   show the signature made on the commit with "git commit -S".

 * "git branch --edit-description" can be used to add descriptive text
   to explain what a topic branch is about.

 * "git fmt-merge-msg" learned to take the branch description into
   account when preparing a merge summary that "git merge" records
   when merging a local branch.

 * "git request-pull" has been updated to convey more information
   useful for integrators to decide if a topic is worth merging and
   what is pulled is indeed what the requestor asked to pull,
   including:

   - the tip of the branch being requested to be merged;
   - the branch description describing what the topic is about;
   - the contents of the annotated tag, when requesting to pull a tag.

 * "git pull" learned to notice 'pull.rebase' configuration variable,
   which serves as a global fallback for setting 'branch.<name>.rebase'
   configuration variable per branch.

 * "git tag" learned "--cleanup" option to control how the whitespaces
   and empty lines in tag message are cleaned up.

 * "gitweb" learned to show side-by-side diff.

Also contains minor documentation updates and code clean-ups.


Fixes since v1.7.8
------------------

Unless otherwise noted, all the fixes since v1.7.8 in the maintenance
releases are contained in this release (see release notes to them for
details).

A note from the maintainer

[Junio C Hamano]

Welcome to git development community.

This message is written by the maintainer and talks about how Git
project is managed, and how you can work with it.

* Mailing list and the community

The development is primarily done on the Git mailing list. Help
requests, feature proposals, bug reports and patches should be sent to
the list address <git@vger.kernel.org>.  You don't have to be
subscribed to send messages.  The convention on the list is to keep
everybody involved on Cc:, so it is unnecessary to say "Please Cc: me,
I am not subscribed".

Before sending patches, please read Documentation/SubmittingPatches
and Documentation/CodingGuidelines to familiarize yourself with the
project convention.

If you sent a patch and you did not hear any response from anybody for
several days, it could be that your patch was totally uninteresting,
but it also is possible that it was simply lost in the noise.  Please
do not hesitate to send a reminder message in such a case.  Messages
getting lost in the noise is a sign that people involved don't have
enough mental/time bandwidth to process them right at the moment, and
it often helps to wait until the list traffic becomes calmer before
sending such a reminder.

The list archive is available at a few public sites:

        http://news.gmane.org/gmane.comp.version-control.git/
        http://marc.theaimsgroup.com/?l=git
        http://www.spinics.net/lists/git/

Some people seem to prefer to read it over NNTP:

        nntp://news.gmane.org/gmane.comp.version-control.git

When you point at a message in a mailing list archive, using
gmane is often the easiest to follow by readers, like this:

        http://thread.gmane.org/gmane.comp.version-control.git/27/focus=217

as it also allows people who subscribe to the mailing list as gmane
newsgroup to "jump to" the article.

Some members of the development community can sometimes also be found
on the #git IRC channel on Freenode.  Its log is available at:

        http://colabti.org/irclogger/irclogger_log/git

* Reporting bugs

When you think git does not behave as you expect, please do not stop
your bug report with just "git does not work".  "I used git in this
way, but it did not work" is not much better, neither is "I used git
in this way, and X happend, which is broken".  It often is that git is
correct to cause X happen in such a case, and it is your expectation
that is broken. People would not know what other result Y you expected
to see instead of X, if you left it unsaid.

Please remember to always state

 - what you wanted to achieve;

 - what you did (the version of git and the command sequence to reproduce
   the behavior);

 - what you saw happen (X above);

 - what you expected to see (Y above); and

 - how the last two are different.

See http://www.chiark.greenend.org.uk/~sgtatham/bugs.html for further
hints.

* Repositories, branches and documentation.

My public git.git repositories are at:

        git://git.kernel.org/pub/scm/git/git.git/
	git://repo.or.cz/alt-git.git/
	https://github.com/git/git/
	https://code.google.com/p/git-core/
	git://git.sourceforge.jp/gitroot/git-core/git.git/
	git://git-core.git.sourceforge.net/gitroot/git-core/git-core/

A few gitweb interfaces are found at:

        http://git.kernel.org/?p=git/git.git
        http://repo.or.cz/w/alt-git.git

Preformatted documentation from the tip of the "master" branch can be
found in:

        git://git.kernel.org/pub/scm/git/git-{htmldocs,manpages}.git/
        git://repo.or.cz/git-{htmldocs,manpages}.git/
        https://code.google.com/p/git-{htmldocs,manpages}.git/
        https://github.com/gitster/git-{htmldocs,manpages}.git/

There are four branches in git.git repository that track the source tree
of git: "master", "maint", "next", and "pu".

The "master" branch is meant to contain what are very well tested and
ready to be used in a production setting.  Every now and then, a "feature
release" is cut from the tip of this branch and they typically are named
with three dotted decimal digits.  The last such release was 1.7.9 done on
Jan 27, 2012. You can expect that the tip of the "master" branch is always
more stable than any of the released versions.

Whenever a feature release is made, "maint" branch is forked off from
"master" at that point.  Obvious, safe and urgent fixes after a feature
release are applied to this branch and maintenance releases are cut from
it.  The maintenance releases are named with four dotted decimal, named
after the feature release they are updates to; the last such release was
1.7.8.4.  New features never go to this branch.  This branch is also
merged into "master" to propagate the fixes forward.

A new development does not usually happen on "master". When you send a
series of patches, after review on the mailing list, a separate topic
branch is forked from the tip of "master" and your patches are queued
there, and kept out of "master" while people test it out. The quality of
topic branches are judged primarily by the mailing list discussions.

Topic branches that are in good shape are merged to the "next" branch. In
general, the "next" branch always contains the tip of "master".  It might
not be quite rock-solid, but is expected to work more or less without major
breakage. The "next" branch is where new and exciting things take place. A
topic that is in "next" is expected to be polished to perfection before it
is merged to "master".

The "pu" (proposed updates) branch bundles all the remaining topic
branches. The topics on the branch are not complete, well tested, nor well
documented and need further work. When a topic that was in "pu" proves to
be in testable shape, it is merged to "next".

You can run "git log --first-parent master..pu" to see what topics are
currently in flight.  Sometimes, an idea that looked promising turns out
to be not so good and the topic can be dropped from "pu" in such a case.

The two branches "master" and "maint" are never rewound, and "next"
usually will not be either.  After a feature release is made from
"master", however, "next" will be rebuilt from the tip of "master"
using the topics that didn't make the cut in the feature release.

Note that being in "next" is not a guarantee to appear in the next
release, nor even in any future release.  There were cases that topics
needed reverting a few commits in them before graduating to "master",
or a topic that already was in "next" was reverted from "next" because
fatal flaws were found in it after it was merged.


* Other people's trees, trusted lieutenants and credits.

Documentation/SubmittingPatches outlines to whom your proposed changes
should be sent.  As described in contrib/README, I would delegate fixes
and enhancements in contrib/ area to the primary contributors of them.

Although the following are included in git.git repository, they have their
own authoritative repository and maintainers:

 - git-gui/ comes from git-gui project, maintained by Pat Thoyts:

        git://repo.or.cz/git-gui.git

 - gitk-git/ comes from Paul Mackerras's gitk project:

        git://git.kernel.org/pub/scm/gitk/gitk.git

I would like to thank everybody who helped to raise git into the current
shape.  Especially I would like to thank the git list regulars whose help
I have relied on and expect to continue relying on heavily:

 - Linus Torvalds, Shawn Pearce, Johannes Schindelin, Nicolas Pitre,
   René Scharfe, Jeff King, Jonathan Nieder, Johan Herland, Johannes
   Sixt, Sverre Rabbelier, Michael J Gruber, Nguyễn Thái Ngọc Duy,
   Ævar Arnfjörð Bjarmason and Thomas Rast on general design and
   implementation issues and reviews on the mailing list.

 - Shawn and Nicolas Pitre on pack issues.

 - Martin Langhoff, Frank Lichtenheld and Ævar Arnfjörð Bjarmason on
   cvsserver and cvsimport.

 - Paul Mackerras on gitk.

 - Eric Wong, David D. Kilzer and Sam Vilain on git-svn.

 - Simon Hausmann and Pete Wyckoff on git-p4.

 - Jakub Narebski, John Hawley, Petr Baudis, Luben Tuikov, Giuseppe Bilotta on
   gitweb.

 - J. Bruce Fields, Jonathan Nieder, Michael J Gruber and Thomas Rast on
   documentation (and countless others for proofreading and fixing).

 - Alexandre Julliard on Emacs integration.

 - David Aguilar and Charles Bailey for taking good care of git-mergetool
   (and Theodore Ts'o for creating it in the first place) and git-difftool.

 - Johannes Schindelin, Johannes Sixt, Erik Faye-Lund, Pat Thoyts and others
   for their effort to move things forward on the Windows front.

 - People on non-Linux platforms for keeping their eyes on portability;
   especially, Randal Schwartz, Theodore Ts'o, Jason Riedy, Thomas Glanzmann,
   Brandon Casey, Jeff King, Alex Riesen and countless others.

A note from the maintainer

[Junio C Hamano]

Welcome to git development community.

This message is written by the maintainer and talks about how Git
project is managed, and how you can work with it.

* Mailing list and the community

The development is primarily done on the Git mailing list. Help
requests, feature proposals, bug reports and patches should be sent to
the list address <git@vger.kernel.org>.  You don't have to be
subscribed to send messages.  The convention on the list is to keep
everybody involved on Cc:, so it is unnecessary to ask "Please Cc: me,
I am not subscribed".

Before sending patches, please read Documentation/SubmittingPatches
and Documentation/CodingGuidelines to familiarize yourself with the
project convention.

If you sent a patch and you did not hear any response from anybody for
several days, it could be that your patch was totally uninteresting,
but it also is possible that it was simply lost in the noise.  Please
do not hesitate to send a reminder message in such a case.  Messages
getting lost in the noise is a sign that people involved don't have
enough mental/time bandwidth to process them right at the moment, and
it often helps to wait until the list traffic becomes calmer before
sending such a reminder.

The list archive is available at a few public sites as well:

        http://news.gmane.org/gmane.comp.version-control.git/
        http://marc.theaimsgroup.com/?l=git
        http://www.spinics.net/lists/git/

and some people seem to prefer to read it over NNTP:

        nntp://news.gmane.org/gmane.comp.version-control.git

When you point at a message in a mailing list archive, using
gmane is often the easiest to follow by readers, like this:

        http://thread.gmane.org/gmane.comp.version-control.git/27/focus=217

as it also allows people who subscribe to the mailing list as gmane
newsgroup to "jump to" the article.

Some members of the development community can sometimes also be found
on the #git IRC channel on Freenode.  Its log is available at:

        http://colabti.org/irclogger/irclogger_log/git

* Reporting bugs

When you think git does not behave as you expect, please do not stop your
bug report with just "git does not work".  "I tried to do X but it did not
work" is not much better, neither is "I tried to do X and git did Y, which
is broken".  It often is that what you expect is _not_ what other people
expect, and chances are that what you expect is very different from what
people who have worked on git have expected (otherwise, the behavior
would have been changed to match that expectation long time ago).

Please remember to always state

 - what you wanted to do;

 - what you did (the version of git and the command sequence to reproduce
   the behavior);

 - what you saw happen;

 - what you expected to see; and

 - how the last two are different.

See http://www.chiark.greenend.org.uk/~sgtatham/bugs.html for further
hints.

* Repositories, branches and documentation.

My public git.git repository is at:

        git://git.kernel.org/pub/scm/git/git.git/
	git://repo.or.cz/alt-git.git
	https://github.com/git/git
	https://code.google.com/p/git-core/

Impatient people might have better luck with the latter two (there are a
few other mirrors I push into at sourceforge and github as well).

Their gitweb interfaces are found at:

        http://git.kernel.org/?p=git/git.git
        http://repo.or.cz/w/alt-git.git

There are three branches in git.git repository that are not about the
source tree of git: "html", "man", and "todo".

The "html" and "man" are preformatted documentation from the tip of
the "master" branch; the tip of "html" is visible at:

        http://www.kernel.org/pub/software/scm/git/docs/
	http://git-core.googlecode.com/git-history/html/git.html

The above URL is the top-level documentation page, and it may have
links to documentation of older releases.

The "todo" branch was originally meant to contain a TODO list for me,
but is mostly used to keep some helper scripts I use to maintain git.
For example, the script that was used to maintain the two documentation
branches are found there as dodoc.sh, which may be a good demonstration
of how to use a post-update hook to automate a task after pushing into a
repository.

There are four branches in git.git repository that track the source tree
of git: "master", "maint", "next", and "pu".

The "master" branch is meant to contain what are very well tested and
ready to be used in a production setting.  Every now and then, a "feature
release" is cut from the tip of this branch and they typically are named
with three dotted decimal digits.  The last such release was 1.7.7 done on
Sept 30, 2011. You can expect that the tip of the "master" branch is always
more stable than any of the released versions.

Whenever a feature release is made, "maint" branch is forked off from
"master" at that point.  Obvious, safe and urgent fixes after a feature
release are applied to this branch and maintenance releases are cut from
it.  The maintenance releases are named with four dotted decimal, named
after the feature release they are updates to; the last such release was
1.7.7.1.  New features never go to this branch.  This branch is also
merged into "master" to propagate the fixes forward.

A new development does not usually happen on "master". When you send a
series of patches, after review on the mailing list, a separate topic
branch is forked from the tip of "master" and your patches are queued
there, and kept out of "master" while people test it out.  The quality of
topic branches are judged primarily by the mailing list discussions.

Topic branches that are in good shape are merged to the "next" branch. In
general, the "next" branch always contains the tip of "master".  It might
not be quite rock-solid production ready, but is expected to work more or
less without major breakage. The "next" branch is where new and exciting
things take place. A topic that is in "next" is expected to be polished to
perfection before it is merged to "master" (that's why "master" can be
expected to stay more stable than any released version).

The "pu" (proposed updates) branch bundles all the remaining topic
branches. The topics on the branch are not complete, well tested, nor well
documented and need further work. When a topic that was in "pu" proves to
be in testable shape, it is merged to "next".

You can run "git log --first-parent master..pu" to see what topics are
currently in flight.  Sometimes, an idea that looked promising turns out
to be not so good and the topic can be dropped from "pu" in such a case.

The two branches "master" and "maint" are never rewound, and "next"
usually will not be either.  After a feature release is made from
"master", however, "next" will be rebuilt from the tip of "master"
using the topics that didn't make the cut in the feature release.

Note that being in "next" is not a guarantee to appear in the next
release, nor even in any future release.  There were cases that topics
needed reverting a few commits in them before graduating to "master",
or a topic that already was in "next" was reverted from "next" because
fatal flaws were found in it after it was merged.


* Other people's trees, trusted lieutenants and credits.

Documentation/SubmittingPatches outlines to whom your proposed changes
should be sent.  As described in contrib/README, I would delegate fixes
and enhancements in contrib/ area to the primary contributors of them.

Although the following are included in git.git repository, they have their
own authoritative repository and maintainers:

 - git-gui/ comes from git-gui project, maintained by Pat Thoyts:

        git://repo.or.cz/git-gui.git

 - gitk-git/ comes from Paul Mackerras's gitk project:

        git://git.kernel.org/pub/scm/gitk/gitk.git

I would like to thank everybody who helped to raise git into the current
shape.  Especially I would like to thank the git list regulars whose help
I have relied on and expect to continue relying on heavily:

 - Linus Torvalds, Shawn Pearce, Johannes Schindelin, Nicolas Pitre,
   René Scharfe, Jeff King, Jonathan Nieder, Johan Herland, Johannes
   Sixt, Sverre Rabbelier, Michael J Gruber, Nguyễn Thái Ngọc Duy,
   Ævar Arnfjörð Bjarmason and Thomas Rast on general design and
   implementation issues and reviews on the mailing list.

 - Shawn and Nicolas Pitre on pack issues.

 - Martin Langhoff, Frank Lichtenheld and Ævar Arnfjörð Bjarmason on
   cvsserver and cvsimport.

 - Paul Mackerras on gitk.

 - Eric Wong, David D. Kilzer and Sam Vilain on git-svn.

 - Simon Hausmann and Pete Wyckoff on git-p4.

 - Jakub Narebski, John Hawley, Petr Baudis, Luben Tuikov, Giuseppe Bilotta on
   gitweb.

 - J. Bruce Fields, Jonathan Nieder, Michael J Gruber and Thomas Rast on
   documentation (and countless others for proofreading and fixing).

 - Alexandre Julliard on Emacs integration.

 - David Aguilar and Charles Bailey for taking good care of git-mergetool
   (and Theodore Ts'o for creating it in the first place) and git-difftool.

 - Johannes Schindelin, Johannes Sixt, Erik Faye-Lund, Pat Thoyts and others
   for their effort to move things forward on the Windows front.

 - People on non-Linux platforms for keeping their eyes on portability;
   especially, Randal Schwartz, Theodore Ts'o, Jason Riedy, Thomas Glanzmann,
   Brandon Casey, Jeff King, Alex Riesen and countless others.

* This document

The latest copy of this document is found in git.git repository,
on 'todo' branch, as MaintNotes.

A note from the maintainer

[Junio C Hamano]

Welcome to git development community.

This message is written by the maintainer and talks about how Git
project is managed, and how you can work with it.

* Mailing list and the community

The development is primarily done on the Git mailing list. Help
requests, feature proposals, bug reports and patches should be sent to
the list address <git@vger.kernel.org>.  You don't have to be
subscribed to send messages.  The convention on the list is to keep
everybody involved on Cc:, so it is unnecessary to ask "Please Cc: me,
I am not subscribed".

Before sending patches, please read Documentation/SubmittingPatches
and Documentation/CodingGuidelines to familiarize yourself with the
project convention.

If you sent a patch and you did not hear any response from anybody for
several days, it could be that your patch was totally uninteresting,
but it also is possible that it was simply lost in the noise.  Please
do not hesitate to send a reminder message in such a case.  Messages
getting lost in the noise is a sign that people involved don't have
enough mental/time bandwidth to process them right at the moment, and
it often helps to wait until the list traffic becomes calmer before
sending such a reminder.

The list archive is available at a few public sites as well:

        http://news.gmane.org/gmane.comp.version-control.git/
        http://marc.theaimsgroup.com/?l=git
        http://www.spinics.net/lists/git/

and some people seem to prefer to read it over NNTP:

        nntp://news.gmane.org/gmane.comp.version-control.git

When you point at a message in a mailing list archive, using
gmane is often the easiest to follow by readers, like this:

        http://thread.gmane.org/gmane.comp.version-control.git/27/focus=217

as it also allows people who subscribe to the mailing list as gmane
newsgroup to "jump to" the article.

Some members of the development community can sometimes also be found
on the #git IRC channel on Freenode.  Its log is available at:

        http://colabti.org/irclogger/irclogger_log/git

* Reporting bugs

When you think git does not behave as you expect, please do not stop your
bug report with just "git does not work".  "I tried to do X but it did not
work" is not much better, neither is "I tried to do X and git did Y, which
is broken".  It often is that what you expect is _not_ what other people
expect, and chances are that what you expect is very different from what
people who have worked on git have expected (otherwise, the behavior
would have been changed to match that expectation long time ago).

Please remember to always state

 - what you wanted to do;

 - what you did (the version of git and the command sequence to reproduce
   the behavior);

 - what you saw happen;

 - what you expected to see; and

 - how the last two are different.

See http://www.chiark.greenend.org.uk/~sgtatham/bugs.html for further
hints.

* Repositories, branches and documentation.

My public git.git repository is at:

        git://git.kernel.org/pub/scm/git/git.git/
	git://repo.or.cz/alt-git.git
	https://github.com/git/git
	https://code.google.com/p/git-core/

Impatient people might have better luck with the latter two (there are a
few other mirrors I push into at sourceforge and github as well).

Their gitweb interfaces are found at:

        http://git.kernel.org/?p=git/git.git
        http://repo.or.cz/w/alt-git.git

There are three branches in git.git repository that are not about the
source tree of git: "html", "man", and "todo".

The "html" and "man" are preformatted documentation from the tip of
the "master" branch; the tip of "html" is visible at:

        http://www.kernel.org/pub/software/scm/git/docs/
	http://git-core.googlecode.com/git-history/html/git.html

The above URL is the top-level documentation page, and it may have
links to documentation of older releases.

The "todo" branch was originally meant to contain a TODO list for me,
but is mostly used to keep some helper scripts I use to maintain git.
For example, the script that was used to maintain the two documentation
branches are found there as dodoc.sh, which may be a good demonstration
of how to use a post-update hook to automate a task after pushing into a
repository.

There are four branches in git.git repository that track the source tree
of git: "master", "maint", "next", and "pu".

The "master" branch is meant to contain what are very well tested and
ready to be used in a production setting.  Every now and then, a "feature
release" is cut from the tip of this branch and they typically are named
with three dotted decimal digits.  The last such release was 1.7.7 done on
Sept 30, 2011. You can expect that the tip of the "master" branch is always
more stable than any of the released versions.

Whenever a feature release is made, "maint" branch is forked off from
"master" at that point.  Obvious, safe and urgent fixes after a feature
release are applied to this branch and maintenance releases are cut from
it.  The maintenance releases are named with four dotted decimal, named
after the feature release they are updates to; the last such release was
1.7.6.4.  New features never go to this branch.  This branch is also
merged into "master" to propagate the fixes forward.

A new development does not usually happen on "master". When you send a
series of patches, after review on the mailing list, a separate topic
branch is forked from the tip of "master" and your patches are queued
there, and kept out of "master" while people test it out.  The quality of
topic branches are judged primarily by the mailing list discussions.

Topic branches that are in good shape are merged to the "next" branch. In
general, the "next" branch always contains the tip of "master".  It might
not be quite rock-solid production ready, but is expected to work more or
less without major breakage. The "next" branch is where new and exciting
things take place. A topic that is in "next" is expected to be polished to
perfection before it is merged to "master" (that's why "master" can be
expected to stay more stable than any released version).

The "pu" (proposed updates) branch bundles all the remaining topic
branches. The topics on the branch are not complete, well tested, nor well
documented and need further work. When a topic that was in "pu" proves to
be in testable shape, it is merged to "next".

You can run "git log --first-parent master..pu" to see what topics are
currently in flight.  Sometimes, an idea that looked promising turns out
to be not so good and the topic can be dropped from "pu" in such a case.

The two branches "master" and "maint" are never rewound, and "next"
usually will not be either.  After a feature release is made from
"master", however, "next" will be rebuilt from the tip of "master"
using the topics that didn't make the cut in the feature release.

Note that being in "next" is not a guarantee to appear in the next
release, nor even in any future release.  There were cases that topics
needed reverting a few commits in them before graduating to "master",
or a topic that already was in "next" was reverted from "next" because
fatal flaws were found in it after it was merged.


* Other people's trees, trusted lieutenants and credits.

Documentation/SubmittingPatches outlines to whom your proposed changes
should be sent.  As described in contrib/README, I would delegate fixes
and enhancements in contrib/ area to the primary contributors of them.

Although the following are included in git.git repository, they have their
own authoritative repository and maintainers:

 - git-gui/ comes from git-gui project, maintained by Pat Thoyts:

        git://repo.or.cz/git-gui.git

 - gitk-git/ comes from Paul Mackerras's gitk project:

        git://git.kernel.org/pub/scm/gitk/gitk.git

I would like to thank everybody who helped to raise git into the current
shape.  Especially I would like to thank the git list regulars whose help
I have relied on and expect to continue relying on heavily:

 - Linus Torvalds, Shawn Pearce, Johannes Schindelin, Nicolas Pitre,
   René Scharfe, Jeff King, Jonathan Nieder, Johan Herland, Johannes
   Sixt, Sverre Rabbelier, Michael J Gruber, Nguyễn Thái Ngọc Duy,
   Ævar Arnfjörð Bjarmason and Thomas Rast on general design and
   implementation issues and reviews on the mailing list.

 - Shawn and Nicolas Pitre on pack issues.

 - Martin Langhoff, Frank Lichtenheld and Ævar Arnfjörð Bjarmason on
   cvsserver and cvsimport.

 - Paul Mackerras on gitk.

 - Eric Wong, David D. Kilzer and Sam Vilain on git-svn.

 - Simon Hausmann and Pete Wyckoff on git-p4.

 - Jakub Narebski, John Hawley, Petr Baudis, Luben Tuikov, Giuseppe Bilotta on
   gitweb.

 - J. Bruce Fields, Jonathan Nieder, Michael J Gruber and Thomas Rast on
   documentation (and countless others for proofreading and fixing).

 - Alexandre Julliard on Emacs integration.

 - David Aguilar and Charles Bailey for taking good care of git-mergetool
   (and Theodore Ts'o for creating it in the first place) and git-difftool.

 - Johannes Schindelin, Johannes Sixt, Erik Faye-Lund and others for their
   effort to move things forward on the Windows front.

 - People on non-Linux platforms for keeping their eyes on portability;
   especially, Randal Schwartz, Theodore Ts'o, Jason Riedy, Thomas Glanzmann,
   Brandon Casey, Jeff King, Alex Riesen and countless others.

* This document

The latest copy of this document is found in git.git repository,
on 'todo' branch, as MaintNotes.

Re: A note from the maintainer

[Martin von Zweigbergk]

On Tue, Oct 4, 2011 at 7:22 PM, Junio C Hamano <gitster@pobox.com> wrote:
>  - gitk-git/ comes from Paul Mackerras's gitk project:
>
>        git://git.kernel.org/pub/scm/gitk/gitk.git

I don't seem to be able to fetch from there. Is it still supposed to be there?

Martin

Re: A note from the maintainer

[Junio C Hamano]

Martin von Zweigbergk <martin.von.zweigbergk@gmail.com> writes:

> On Tue, Oct 4, 2011 at 7:22 PM, Junio C Hamano <gitster@pobox.com> wrote:
>>  - gitk-git/ comes from Paul Mackerras's gitk project:
>>
>>        git://git.kernel.org/pub/scm/gitk/gitk.git
>
> I don't seem to be able to fetch from there. Is it still supposed to be there?

Unfortunately k.org is _slowly_ coming back to life.

A note from the maintainer

[Junio C Hamano]

Welcome to the Git development community.

This message is written by the maintainer and talks about how Git
project is managed, and how you can work with it.

* Mailing list and the community

The development is primarily done on the Git mailing list. Help
requests, feature proposals, bug reports and patches should be sent to
the list address <git@vger.kernel.org>.  You don't have to be
subscribed to send messages.  The convention on the list is to keep
everybody involved on Cc:, so it is unnecessary to ask "Please Cc: me,
I am not subscribed".

Before sending patches, please read Documentation/SubmittingPatches
and Documentation/CodingGuidelines to familiarize yourself with the
project convention.

If you sent a patch and you did not hear any response from anybody for
several days, it could be that your patch was totally uninteresting,
but it also is possible that it was simply lost in the noise.  Please
do not hesitate to send a reminder message in such a case.  Messages
getting lost in the noise is a sign that people involved don't have
enough mental/time bandwidth to process them right at the moment, and
it often helps to wait until the list traffic becomes calmer before
sending such a reminder.

The list archive is available at a few public sites as well:

        http://news.gmane.org/gmane.comp.version-control.git/
        http://marc.theaimsgroup.com/?l=git
        http://www.spinics.net/lists/git/

and some people seem to prefer to read it over NNTP:

        nntp://news.gmane.org/gmane.comp.version-control.git

When you point at a message in a mailing list archive, using
gmane is often the easiest to follow by readers, like this:

        http://thread.gmane.org/gmane.comp.version-control.git/27/focus=217

as it also allows people who subscribe to the mailing list as gmane
newsgroup to "jump to" the article.

Some members of the development community can sometimes also be found
on the #git IRC channel on Freenode.  Its log is available at:

        http://colabti.org/irclogger/irclogger_log/git

* Reporting bugs

When you think git does not behave as you expect, please do not stop your
bug report with just "git does not work".  "I tried to do X but it did not
work" is not much better, neither is "I tried to do X and git did Y, which
is broken".  It often is that what you expect is _not_ what other people
expect, and chances are that what you expect is very different from what
people who have worked on git have expected (otherwise, the behavior
would have been changed to match that expectation long time ago).

Please remember to always state

 - what you wanted to do;

 - what you did (the version of git and the command sequence to reproduce
   the behavior);

 - what you saw happen;

 - what you expected to see; and

 - how the last two are different.

See http://www.chiark.greenend.org.uk/~sgtatham/bugs.html for further
hints.

* Repositories, branches and documentation.

My public git.git repository is at:

        git://git.kernel.org/pub/scm/git/git.git/

Immediately after I publish to the primary repository at kernel.org, I
also push into an alternate here:

        git://repo.or.cz/alt-git.git/

Impatient people might have better luck with the latter one (there are a
few other mirrors I push into at sourceforge and github as well).

Their gitweb interfaces are found at:

        http://git.kernel.org/?p=git/git.git
        http://repo.or.cz/w/alt-git.git

There are three branches in git.git repository that are not about the
source tree of git: "html", "man", and "todo".

The "html" and "man" are auto-generated documentation from the tip of
the "master" branch; the tip of "html" is extracted to be visible at
kernel.org at:

        http://www.kernel.org/pub/software/scm/git/docs/

The above URL is the top-level documentation page, and it has links to
documentation of older releases.

The "todo" branch was originally meant to contain a TODO list for me,
but is mostly used to keep some helper scripts I use to maintain git.
For example, the script to maintain the two documentation branches are
found there as dodoc.sh, which may be a good demonstration of how to
use a post-update hook to automate a task after pushing into a
repository.

There are four branches in git.git repository that track the source tree
of git: "master", "maint", "next", and "pu".

The "master" branch is meant to contain what are very well tested and
ready to be used in a production setting.  Every now and then, a "feature
release" is cut from the tip of this branch and they typically are named
with three dotted decimal digits.  The last such release was 1.7.6 done on
June 26, 2011.  You can expect that the tip of the "master" branch is
always more stable than any of the released versions.

Whenever a feature release is made, "maint" branch is forked off from
"master" at that point.  Obvious, safe and urgent fixes after a feature
release are applied to this branch and maintenance releases are cut from
it.  The maintenance releases are named with four dotted decimal, named
after the feature release they are updates to; the last such release was
1.7.6.1.  New features never go to this branch.  This branch is also
merged into "master" to propagate the fixes forward.

A new development does not usually happen on "master". When you send a
series of patches, after review on the mailing list, a separate topic
branch is forked from the tip of "master" and your patches are queued
there, and kept out of "master" while people test it out.  The quality of
topic branches are judged primarily by the mailing list discussions.

Topic branches that are in good shape are merged to the "next" branch. In
general, the "next" branch always contains the tip of "master".  It might
not be quite rock-solid production ready, but is expected to work more or
less without major breakage. The "next" branch is where new and exciting
things take place. A topic that is in "next" is expected to be polished to
perfection before it is merged to "master" (that's why "master" can be
expected to stay more stable than any released version).

The "pu" (proposed updates) branch bundles all the remaining topic
branches. The topics on the branch are not complete, well tested, nor well
documented and need further work. When a topic that was in "pu" proves to
be in testable shape, it is merged to "next".

You can run "git log --first-parent master..pu" to see what topics are
currently in flight.  Sometimes, an idea that looked promising turns out
to be not so good and the topic can be dropped from "pu" in such a case.

The two branches "master" and "maint" are never rewound, and "next"
usually will not be either.  After a feature release is made from
"master", however, "next" will be rebuilt from the tip of "master"
using the topics that didn't make the cut in the feature release.

Note that being in "next" is not a guarantee to appear in the next
release, nor even in any future release.  There were cases that topics
needed reverting a few commits in them before graduating to "master", or a
topic that already was in "next" was reverted from "next" because fatal
flaws were found in it after it was merged.


* Other people's trees, trusted lieutenants and credits.

Documentation/SubmittingPatches outlines to whom your proposed changes
should be sent.  As described in contrib/README, I would delegate fixes
and enhancements in contrib/ area to the primary contributors of them.

Although the following are included in git.git repository, they have their
own authoritative repository and maintainers:

 - git-gui/ comes from git-gui project, maintained by Pat Thoyts:

        git://repo.or.cz/git-gui.git

 - gitk-git/ comes from Paul Mackerras's gitk project:

        git://git.kernel.org/pub/scm/gitk/gitk.git

I would like to thank everybody who helped to raise git into the current
shape.  Especially I would like to thank the git list regulars whose help
I have relied on and expect to continue relying on heavily:

 - Linus Torvalds, Shawn Pearce, Johannes Schindelin, Nicolas Pitre,
   René Scharfe, Jeff King, Jonathan Nieder, Johan Herland, Johannes
   Sixt, Sverre Rabbelier, Michael J Gruber, Nguyễn Thái Ngọc Duy,
   Ævar Arnfjörð Bjarmason and Thomas Rast on general design and
   implementation issues and reviews on the mailing list.

 - Shawn and Nicolas Pitre on pack issues.

 - Martin Langhoff, Frank Lichtenheld and Ævar Arnfjörð Bjarmason on
   cvsserver and cvsimport.

 - Paul Mackerras on gitk.

 - Eric Wong, David D. Kilzer and Sam Vilain on git-svn.

 - Simon Hausmann and Pete Wyckoff on git-p4.

 - Jakub Narebski, John Hawley, Petr Baudis, Luben Tuikov, Giuseppe Bilotta on
   gitweb.

 - J. Bruce Fields, Jonathan Nieder, Michael J Gruber and Thomas Rast on
   documentation (and countless others for proofreading and fixing).

 - Alexandre Julliard on Emacs integration.

 - David Aguilar and Charles Bailey for taking good care of git-mergetool
   (and Theodore Ts'o for creating it in the first place) and git-difftool.

 - Johannes Schindelin, Johannes Sixt, Erik Faye-Lund and others for their
   effort to move things forward on the Windows front.

 - People on non-Linux platforms for keeping their eyes on portability;
   especially, Randal Schwartz, Theodore Ts'o, Jason Riedy, Thomas Glanzmann,
   Brandon Casey, Jeff King, Alex Riesen and countless others.

* This document

The latest copy of this document is found in git.git repository,
on 'todo' branch, as MaintNotes.

A Note from the Maintainer

[Junio C Hamano]

Welcome to git development community.

This message is written by the maintainer and talks about how Git
project is managed, and how you can work with it.

* Mailing list and the community

The development is primarily done on the Git mailing list. Help
requests, feature proposals, bug reports and patches should be sent to
the list address <git@vger.kernel.org>.  You don't have to be
subscribed to send messages.  The convention on the list is to keep
everybody involved on Cc:, so it is unnecessary to ask "Please Cc: me,
I am not subscribed".

Before sending patches, please read Documentation/SubmittingPatches
and Documentation/CodingGuidelines to familiarize yourself with the
project convention.

If you sent a patch and you did not hear any response from anybody for
several days, it could be that your patch was totally uninteresting,
but it also is possible that it was simply lost in the noise.  Please
do not hesitate to send a reminder message in such a case.  Messages
getting lost in the noise is a sign that people involved don't have
enough mental/time bandwidth to process them right at the moment, and
it often helps to wait until the list traffic becomes calmer before
sending such a reminder.

The list archive is available at a few public sites as well:

        http://news.gmane.org/gmane.comp.version-control.git/
        http://marc.theaimsgroup.com/?l=git
        http://www.spinics.net/lists/git/

and some people seem to prefer to read it over NNTP:

        nntp://news.gmane.org/gmane.comp.version-control.git

When you point at a message in a mailing list archive, using
gmane is often the easiest to follow by readers, like this:

        http://thread.gmane.org/gmane.comp.version-control.git/27/focus=217

as it also allows people who subscribe to the mailing list as gmane
newsgroup to "jump to" the article.

Some members of the development community can sometimes also be found
on the #git IRC channel on Freenode.  Its log is available at:

        http://colabti.org/irclogger/irclogger_log/git

* Reporting bugs

When you think git does not behave as you expect, please do not stop your
bug report with just "git does not work".  "I tried to do X but it did not
work" is not much better, neither is "I tried to do X and git did Y, which
is broken".  It often is that what you expect is _not_ what other people
expect, and chances are that what you expect is very different from what
people who have worked on git have expected (otherwise, the behavior
would have been changed to match that expectation long time ago).

Please remember to always state

 - what you wanted to do;

 - what you did (the version of git and the command sequence to reproduce
   the behavior);

 - what you saw happen;

 - what you expected to see; and

 - how the last two are different.

See http://www.chiark.greenend.org.uk/~sgtatham/bugs.html for further
hints.

* Repositories, branches and documentation.

My public git.git repository is at:

        git://git.kernel.org/pub/scm/git/git.git/

Immediately after I publish to the primary repository at kernel.org, I
also push into an alternate here:

        git://repo.or.cz/alt-git.git/

Impatient people might have better luck with the latter one (there are a
few other mirrors I push into at sourceforge and github as well).

Their gitweb interfaces are found at:

        http://git.kernel.org/?p=git/git.git
        http://repo.or.cz/w/alt-git.git

There are three branches in git.git repository that are not about the
source tree of git: "html", "man", and "todo".

The "html" and "man" are auto-generated documentation from the tip of
the "master" branch; the tip of "html" is extracted to be visible at
kernel.org at:

        http://www.kernel.org/pub/software/scm/git/docs/

The above URL is the top-level documentation page, and it has links to
documentation of older releases.

The "todo" branch was originally meant to contain a TODO list for me,
but is mostly used to keep some helper scripts I use to maintain git.
For example, the script to maintain the two documentation branches are
found there as dodoc.sh, which may be a good demonstration of how to
use a post-update hook to automate a task after pushing into a
repository.

There are four branches in git.git repository that track the source tree
of git: "master", "maint", "next", and "pu".

The "master" branch is meant to contain what are very well tested and
ready to be used in a production setting.  Every now and then, a "feature
release" is cut from the tip of this branch and they typically are named
with three dotted decimal digits.  The last such release was 1.7.5 done on
Apr 24, 2011.  You can expect that the tip of the "master" branch is
always more stable than any of the released versions.

Whenever a feature release is made, "maint" branch is forked off from
"master" at that point.  Obvious, safe and urgent fixes after a feature
release are applied to this branch and maintenance releases are cut from
it.  The maintenance releases are named with four dotted decimal, named
after the feature release they are updates to; the last such release was
1.7.4.5.  New features never go to this branch.  This branch is also
merged into "master" to propagate the fixes forward.

A new development does not usually happen on "master". When you send a
series of patches, after review on the mailing list, a separate topic
branch is forked from the tip of "master" and your patches are queued
there, and kept out of "master" while people test it out.  The quality of
topic branches are judged primarily by the mailing list discussions.

Topic branches that are in good shape are merged to the "next" branch. In
general, the "next" branch always contains the tip of "master".  It might
not be quite rock-solid production ready, but is expected to work more or
less without major breakage. The "next" branch is where new and exciting
things take place. A topic that is in "next" is expected to be polished to
perfection before it is merged to "master" (that's why "master" can be
expected to stay more stable than any released version).

The "pu" (proposed updates) branch bundles all the remaining topic
branches. The topics on the branch are not complete, well tested, nor well
documented and need further work. When a topic that was in "pu" proves to
be in testable shape, it is merged to "next".

You can run "git log --first-parent master..pu" to see what topics are
currently in flight.  Sometimes, an idea that looked promising turns out
to be not so good and the topic can be dropped from "pu" in such a case.

The two branches "master" and "maint" are never rewound, and "next"
usually will not be either.  After a feature release is made from
"master", however, "next" will be rebuilt from the tip of "master"
using the topics that didn't make the cut in the feature release.

Note that being in "next" is not a guarantee to appear in the next
release, nor even in any future release.  There were cases that topics
needed reverting a few commits in them before graduating to "master", or a
topic that already was in "next" was reverted from "next" because fatal
flaws were found in it after it was merged.


* Other people's trees, trusted lieutenants and credits.

Documentation/SubmittingPatches outlines to whom your proposed changes
should be sent.  As described in contrib/README, I would delegate fixes
and enhancements in contrib/ area to the primary contributors of them.

Although the following are included in git.git repository, they have their
own authoritative repository and maintainers:

 - git-gui/ comes from git-gui project, maintained by Pat Thoyts:

        git://repo.or.cz/git-gui.git

 - gitk-git/ comes from Paul Mackerras's gitk project:

        git://git.kernel.org/pub/scm/gitk/gitk.git

I would like to thank everybody who helped to raise git into the current
shape.  Especially I would like to thank the git list regulars whose help
I have relied on and expect to continue relying on heavily:

 - Linus Torvalds, Shawn Pearce, Johannes Schindelin, Nicolas Pitre,
   René Scharfe, Jeff King, Jonathan Nieder, Johan Herland, Johannes
   Sixt, Sverre Rabbelier, Michael J Gruber, Nguyễn Thái Ngọc Duy,
   Ævar Arnfjörð Bjarmason and Thomas Rast on general design and
   implementation issues and reviews on the mailing list.

 - Shawn and Nicolas Pitre on pack issues.

 - Martin Langhoff, Frank Lichtenheld and Ævar Arnfjörð Bjarmason on
   cvsserver and cvsimport.

 - Paul Mackerras on gitk.

 - Eric Wong, David D. Kilzer and Sam Vilain on git-svn.

 - Simon Hausmann and Pete Wyckoff on git-p4.

 - Jakub Narebski, John Hawley, Petr Baudis, Luben Tuikov, Giuseppe Bilotta on
   gitweb.

 - J. Bruce Fields, Jonathan Nieder, Michael J Gruber and Thomas Rast on
   documentation (and countless others for proofreading and fixing).

 - Alexandre Julliard on Emacs integration.

 - David Aguilar and Charles Bailey for taking good care of git-mergetool
   (and Theodore Ts'o for creating it in the first place) and git-difftool.

 - Johannes Schindelin, Johannes Sixt, Erik Faye-Lund and others for their
   effort to move things forward on the Windows front.

 - People on non-Linux platforms for keeping their eyes on portability;
   especially, Randal Schwartz, Theodore Ts'o, Jason Riedy, Thomas Glanzmann,
   Brandon Casey, Jeff King, Alex Riesen and countless others.

* This document

The latest copy of this document is found in git.git repository,
on 'todo' branch, as MaintNotes.

A note from the maintainer

[Junio C Hamano]

Welcome to git development community.

This message is written by the maintainer and talks about how Git
project is managed, and how you can work with it.

* IRC and Mailing list

Members of the development community can sometimes be found on #git
IRC channel on Freenode.  Its log is available at:

        http://colabti.org/irclogger/irclogger_log/git

The development is primarily done on the Git mailing list. If you have
patches, please send them to the list address (git@vger.kernel.org).
following Documentation/SubmittingPatches.  You don't have to be
subscribed to send messages there, and the convention is to Cc:
everybody involved, so you don't even have to say "Please Cc: me, I am
not subscribed".

If you sent a patch and you did not hear any response from anybody for
several days, it could be that your patch was totally uninteresting, but
it also is possible that it was simply lost in the noise.  Please do not
hesitate to send a reminder message politely in such a case.  Messages
getting lost in the noise is a sign that people involved don't have enough
mental/time bandwidth to process them right at the moment, and it often
helps to wait until the list traffic becomes calmer before sending such a
reminder.

The list archive is available at a few public sites as well:

        http://news.gmane.org/gmane.comp.version-control.git/
        http://marc.theaimsgroup.com/?l=git
        http://www.spinics.net/lists/git/

and some people seem to prefer to read it over NNTP:

        nntp://news.gmane.org/gmane.comp.version-control.git

When you point at a message in a mailing list archive, using
gmane is often the easiest to follow by readers, like this:

        http://thread.gmane.org/gmane.comp.version-control.git/27/focus=217

as it also allows people who subscribe to the mailing list as
gmane newsgroup to "jump to" the article.

* Repositories, branches and documentation.

My public git.git repository is at:

        git://git.kernel.org/pub/scm/git/git.git/

Immediately after I publish to the primary repository at kernel.org, I
also push into an alternate here:

        git://repo.or.cz/alt-git.git/

Impatient people might have better luck with the latter one (there are a
few other mirrors I push into at sourceforge and github as well).

Their gitweb interfaces are found at:

        http://git.kernel.org/?p=git/git.git
        http://repo.or.cz/w/alt-git.git

There are three branches in git.git repository that are not about the
source tree of git: "todo", "html" and "man".  The first one was meant to
contain TODO list for me, but I am not good at maintaining such a list and
it is in an abandoned state.  The branch mostly is used to keep some
helper scripts I use to maintain git and the regular "What's cooking"
messages these days.

The "html" and "man" are autogenerated documentation from the tip of the
"master" branch; the tip of "html" is extracted to be visible at
kernel.org at:

        http://www.kernel.org/pub/software/scm/git/docs/

The above URL is the top-level documentation page, and it has
links to documentation of older releases.

The script to maintain these two documentation branches are found in the
"todo" branch as dodoc.sh, if you are interested.  It is a demonstration
of how to use a post-update hook to automate a task after pushing into a
repository.

There are four branches in git.git repository that track the source tree
of git: "master", "maint", "next", and "pu".  I may add more maintenance
branches (e.g. "maint-1.6.3") if we have hugely backward incompatible
feature updates in the future to keep an older release alive; I may not,
but the distributed nature of git means any volunteer can run a
stable-tree like that herself.

The "master" branch is meant to contain what are very well tested and
ready to be used in a production setting.  There could occasionally be
minor breakages or brown paper bag bugs but they are not expected to be
anything major, and more importantly quickly and trivially fixable.  Every
now and then, a "feature release" is cut from the tip of this branch and
they typically are named with three dotted decimal digits.  The last such
release was 1.7.4 done on Jan 30, 2011.  You can expect that the tip of
the "master" branch is always more stable than any of the released
versions.

Whenever a feature release is made, "maint" branch is forked off from
"master" at that point.  Obvious, safe and urgent fixes after a feature
release are applied to this branch and maintenance releases are cut from
it.  The maintenance releases are named with four dotted decimal, named
after the feature release they are updates to; the last such release was
1.7.3.5.  New features never go to this branch.  This branch is also
merged into "master" to propagate the fixes forward.

A trivial and safe enhancement goes directly on top of "master".  A new
development, either initiated by myself or more often by somebody who
found his or her own itch to scratch, does not usually happen on "master",
however.  Instead, a separate topic branch is forked from the tip of
"master", and it first is tested in isolation; I may make minimum fixups
at this point.  Usually there are a handful such topic branches that are
running ahead of "master" in git.git repository.  I do not publish the tip
of these branches in my public repository, however, partly to keep the
number of branches that downstream developers need to worry about low, and
primarily because I am lazy.

The quality of topic branches are judged primarily by the mailing list
discussions.  Some of them start out as "good idea but obviously is broken
in some areas (e.g. breaks the existing testsuite)" and then with some
more work (either by the original contributor's effort or help from other
people on the list) becomes "more or less done and can now be tested by
wider audience".  Luckily, most of them start out in the latter, better
shape.

The "next" branch is to merge and test topic branches in the latter
category.  In general, the branch always contains the tip of "master".  It
might not be quite rock-solid production ready, but is expected to work
more or less without major breakage.  I usually use "next" version of git
for my own work, so it cannot be _that_ broken to prevent me from
integrating and pushing the changes out.  The "next" branch is where new
and exciting things take place.

The two branches "master" and "maint" are never rewound, and "next"
usually will not be either (this automatically means the topics that have
been merged into "next" are usually not rebased, and you can find the tip
of topic branches you are interested in from the output of "git log
next"). You should be able to safely build on top of them.

After a feature release is made from "master", however, "next" will be
rebuilt from the tip of "master" using the surviving topics.  The commit
that replaces the tip of the "next" will usually have the identical tree,
but it will have different ancestry from the tip of "master".

The "pu" (proposed updates) branch bundles all the remainder of topic
branches.  The "pu" branch, and topic branches that are only in "pu", are
subject to rebasing in general.  By the above definition of how "next"
works, you can tell that this branch will contain quite experimental and
obviously broken stuff.

When a topic that was in "pu" proves to be in testable shape, it graduates
to "next".  I do this with:

        git checkout next
        git merge that-topic-branch

Sometimes, an idea that looked promising turns out to be not so good and
the topic can be dropped from "pu" in such a case.

A topic that is in "next" is expected to be polished to perfection before
it is merged to "master" (that's why "master" can be expected to stay more
stable than any released version).  Similarly to the above, I do it with
this:

        git checkout master
        git merge that-topic-branch
        git branch -d that-topic-branch

Note that being in "next" is not a guarantee to appear in the next release
(being in "master" is such a guarantee, unless it is later found seriously
broken and reverted), nor even in any future release.  There even were
cases that topics needed reverting a few commits in them before graduating
to "master", or a topic that already was in "next" were entirely reverted
from "next" because fatal flaws were found in them later.


* Other people's trees, trusted lieutenants and credits.

Documentation/SubmittingPatches outlines to whom your proposed changes
should be sent.  As described in contrib/README, I would delegate fixes
and enhancements in contrib/ area to the primary contributors of them.

Although the following are included in git.git repository, they have their
own authoritative repository and maintainers:

 - git-gui/ comes from git-gui project, maintained by Pat Thoyts:

        git://repo.or.cz/git-gui.git

 - gitk-git/ comes from Paul Mackerras's gitk project:

        git://git.kernel.org/pub/scm/gitk/gitk.git

I would like to thank everybody who helped to raise git into the current
shape.  Especially I would like to thank the git list regulars whose help
I have relied on and expect to continue relying on heavily:

 - Linus on general design issues.

 - Linus, Shawn Pearce, Johannes Schindelin, Nicolas Pitre, René
   Scharfe, Jeff King, Jonathan Nieder, Johan Herland, Johannes Sixt,
   Sverre Rabbelier and Thomas Rast on general implementation issues
   and reviews on the mailing list.

 - Shawn and Nicolas Pitre on pack issues.

 - Martin Langhoff, Frank Lichtenheld and Ævar Arnfjörð Bjarmason on
   cvsserver and cvsimport.

 - Paul Mackerras on gitk.

 - Eric Wong, David D. Kilzer and Sam Vilain on git-svn.

 - Simon Hausmann and Pete Wyckoff on git-p4.

 - Jakub Narebski, John Hawley, Petr Baudis, Luben Tuikov, Giuseppe Bilotta on
   gitweb.

 - J. Bruce Fields, Jonathan Nieder, Michael J Gruber and Thomas Rast on
   documentation (and countless others for proofreading and fixing).

 - Alexandre Julliard on Emacs integration.

 - David Aguilar and Charles Bailey for taking good care of git-mergetool
   (and Theodore Ts'o for creating it in the first place) and git-difftool.

 - Johannes Schindelin, Johannes Sixt, Erik Faye-Lund and others for their
   effort to move things forward on the Windows front.

 - People on non-Linux platforms for keeping their eyes on portability;
   especially, Randal Schwartz, Theodore Ts'o, Jason Riedy, Thomas Glanzmann,
   Brandon Casey, Jeff King, Alex Riesen and countless others.

* This document

The latest copy of this document is found in git.git repository,
on 'todo' branch, as MaintNotes.

A note from the maintainer...

[Junio C Hamano]

Welcome to the git development community.

This message is written by the maintainer and talks about how Git
project is managed, and how you can work with it.

* IRC and Mailing list

Members of the development community can sometimes be found on #git
IRC channel on Freenode.  Its log is available at:

        http://colabti.org/irclogger/irclogger_log/git

The development is primarily done on the Git mailing list. If you have
patches, please send them to the list address (git@vger.kernel.org).
following Documentation/SubmittingPatches.  You don't have to be
subscribed to send messages there, and the convention is to Cc:
everybody involved, so you don't even have to say "Please Cc: me, I am
not subscribed".

If you sent a patch and you did not hear any response from anybody for
several days, it could be that your patch was totally uninteresting, but
it also is possible that it was simply lost in the noise.  Please do not
hesitate to send a reminder message politely in such a case.  Messages
getting lost in the noise is a sign that people involved don't have enough
mental/time bandwidth to process them right at the moment, and it often
helps to wait until the list traffic becomes calmer before sending such a
reminder.

The list archive is available at a few public sites as well:

        http://news.gmane.org/gmane.comp.version-control.git/
        http://marc.theaimsgroup.com/?l=git
        http://www.spinics.net/lists/git/

and some people seem to prefer to read it over NNTP:

        nntp://news.gmane.org/gmane.comp.version-control.git

When you point at a message in a mailing list archive, using
gmane is often the easiest to follow by readers, like this:

        http://thread.gmane.org/gmane.comp.version-control.git/27/focus=217

as it also allows people who subscribe to the mailing list as
gmane newsgroup to "jump to" the article.

* Repositories, branches and documentation.

My public git.git repository is at:

        git://git.kernel.org/pub/scm/git/git.git/

Immediately after I publish to the primary repository at kernel.org, I
also push into an alternate here:

        git://repo.or.cz/alt-git.git/

Impatient people might have better luck with the latter one.

Their gitweb interfaces are found at:

        http://git.kernel.org/?p=git/git.git
        http://repo.or.cz/w/alt-git.git

There are three branches in git.git repository that are not about the
source tree of git: "todo", "html" and "man".  The first one was meant to
contain TODO list for me, but I am not good at maintaining such a list and
it is in an abandoned state.  The branch mostly is used to keep some
helper scripts I use to maintain git and the regular "What's cooking"
messages these days.

The "html" and "man" are autogenerated documentation from the tip of the
"master" branch; the tip of "html" is extracted to be visible at
kernel.org at:

        http://www.kernel.org/pub/software/scm/git/docs/

The above URL is the top-level documentation page, and it has
links to documentation of older releases.

The script to maintain these two documentation branches are found in the
"todo" branch as dodoc.sh, if you are interested.  It is a demonstration
of how to use a post-update hook to automate a task after pushing into a
repository.

There are four branches in git.git repository that track the source tree
of git: "master", "maint", "next", and "pu".  I may add more maintenance
branches (e.g. "maint-1.6.3") if we have hugely backward incompatible
feature updates in the future to keep an older release alive; I may not,
but the distributed nature of git means any volunteer can run a
stable-tree like that herself.

The "master" branch is meant to contain what are very well tested and
ready to be used in a production setting.  There could occasionally be
minor breakages or brown paper bag bugs but they are not expected to be
anything major, and more importantly quickly and trivially fixable.  Every
now and then, a "feature release" is cut from the tip of this branch and
they typically are named with three dotted decimal digits.  The last such
release was 1.7.3 done on Sep 18/19, 2010.  You can expect that the tip of
the "master" branch is always more stable than any of the released
versions.

Whenever a feature release is made, "maint" branch is forked off from
"master" at that point.  Obvious, safe and urgent fixes after a feature
release are applied to this branch and maintenance releases are cut from
it.  The maintenance releases are named with four dotted decimal, named
after the feature release they are updates to; the last such release was
1.7.2.3.  New features never go to this branch.  This branch is also
merged into "master" to propagate the fixes forward.

A trivial and safe enhancement goes directly on top of "master".  A new
development, either initiated by myself or more often by somebody who
found his or her own itch to scratch, does not usually happen on "master",
however.  Instead, a separate topic branch is forked from the tip of
"master", and it first is tested in isolation; I may make minimum fixups
at this point.  Usually there are a handful such topic branches that are
running ahead of "master" in git.git repository.  I do not publish the tip
of these branches in my public repository, however, partly to keep the
number of branches that downstream developers need to worry about low, and
primarily because I am lazy.

The quality of topic branches are judged primarily by the mailing list
discussions.  Some of them start out as "good idea but obviously is broken
in some areas (e.g. breaks the existing testsuite)" and then with some
more work (either by the original contributor's effort or help from other
people on the list) becomes "more or less done and can now be tested by
wider audience".  Luckily, most of them start out in the latter, better
shape.

The "next" branch is to merge and test topic branches in the latter
category.  In general, the branch always contains the tip of "master".  It
might not be quite rock-solid production ready, but is expected to work
more or less without major breakage.  I usually use "next" version of git
for my own work, so it cannot be _that_ broken to prevent me from
integrating and pushing the changes out.  The "next" branch is where new
and exciting things take place.

The two branches "master" and "maint" are never rewound, and "next"
usually will not be either (this automatically means the topics that have
been merged into "next" are usually not rebased, and you can find the tip
of topic branches you are interested in from the output of "git log
next"). You should be able to safely build on top of them.

After a feature release is made from "master", however, "next" will be
rebuilt from the tip of "master" using the surviving topics.  The commit
that replaces the tip of the "next" will usually have the identical tree,
but it will have different ancestry from the tip of "master".

The "pu" (proposed updates) branch bundles all the remainder of topic
branches.  The "pu" branch, and topic branches that are only in "pu", are
subject to rebasing in general.  By the above definition of how "next"
works, you can tell that this branch will contain quite experimental and
obviously broken stuff.

When a topic that was in "pu" proves to be in testable shape, it graduates
to "next".  I do this with:

        git checkout next
        git merge that-topic-branch

Sometimes, an idea that looked promising turns out to be not so good and
the topic can be dropped from "pu" in such a case.

A topic that is in "next" is expected to be polished to perfection before
it is merged to "master" (that's why "master" can be expected to stay more
stable than any released version).  Similarly to the above, I do it with
this:

        git checkout master
        git merge that-topic-branch
        git branch -d that-topic-branch

Note that being in "next" is not a guarantee to appear in the next release
(being in "master" is such a guarantee, unless it is later found seriously
broken and reverted), nor even in any future release.  There even were
cases that topics needed reverting a few commits in them before graduating
to "master", or a topic that already was in "next" were entirely reverted
from "next" because fatal flaws were found in them later.


* Other people's trees, trusted lieutenants and credits.

Documentation/SubmittingPatches outlines to whom your proposed changes
should be sent.  As described in contrib/README, I would delegate fixes
and enhancements in contrib/ area to the primary contributors of them.

Although the following are included in git.git repository, they have their
own authoritative repository and maintainers:

 - git-gui/ comes from Shawn Pearce's git-gui project:

        git://repo.or.cz/git-gui.git

 - gitk-git/ comes from Paul Mackerras's gitk project:

        git://git.kernel.org/pub/scm/gitk/gitk.git

I would like to thank everybody who helped to raise git into the current
shape.  Especially I would like to thank the git list regulars whose help
I have relied on and expect to continue relying on heavily:

 - Linus on general design issues.

 - Linus, Shawn Pearce, Johannes Schindelin, Nicolas Pitre, Ren辿
   Scharfe, Jeff King, Jonathan Nieder, Johan Herland, Johannes Sixt,
   and Sverre Rabbelier on general implementation issues and reviews
   on the mailing list.

 - Shawn and Nicolas Pitre on pack issues.

 - Martin Langhoff and Frank Lichtenheld on cvsserver and cvsimport.

 - Paul Mackerras on gitk.

 - Eric Wong on git-svn.

 - Simon Hausmann on git-p4.

 - Jakub Narebski, Petr Baudis, Luben Tuikov, Giuseppe Bilotta on
   gitweb.

 - J. Bruce Fields on documentation (and countless others for
   proofreading and fixing).

 - Alexandre Julliard on Emacs integration.

 - Charles Bailey for taking good care of git-mergetool (and Theodore
   Ts'o for creating it in the first place).

 - David Aguilar for git-difftool.

 - Johannes Schindelin, Johannes Sixt and others for their effort to
   move things forward on the Windows front.

 - People on non-Linux platforms for keeping their eyes on
   portability; especially, Randal Schwartz, Theodore Ts'o, Jason
   Riedy, Thomas Glanzmann, Brandon Casey, Jeff King, Alex Riesen and
   countless others.

* This document

The latest copy of this document is found in git.git repository,
on 'todo' branch, as MaintNotes.

A note from the maintainer

[Junio C Hamano]

Welcome to git development community.

This message is written by the maintainer and talks about how Git
project is managed, and how you can work with it.

* IRC and Mailing list

Members of the development community can sometimes be found on #git
IRC channel on Freenode.  Its log is available at:

        http://colabti.org/irclogger/irclogger_log/git

The development is primarily done on the Git mailing list If you have
patches, please send them to the list address (git@vger.kernel.org).
following Documentation/SubmittingPatches.  You don't have to be
subscribed to send messages there, and the convention is to Cc:
everybody involved, so you don't even have to say "Please Cc: me, I am
not subscribed".

If you sent a patch and you did not hear any response from anybody for
several days, it could be that your patch was totally uninteresting, but
it also is possible that it was simply lost in the noise.  Please do not
hesitate to send a reminder message politely in such a case.  Messages
getting lost in the noise is a sign that people involved don't have enough
mental/time bandwidth to process them right at the moment, and it often
helps to wait until the list traffic becomes calmer before sending such a
reminder.

The list archive is available at a few public sites as well:

        http://news.gmane.org/gmane.comp.version-control.git/
        http://marc.theaimsgroup.com/?l=git
        http://www.spinics.net/lists/git/

and some people seem to prefer to read it over NNTP:

        nntp://news.gmane.org/gmane.comp.version-control.git

When you point at a message in a mailing list archive, using
gmane is often the easiest to follow by readers, like this:

        http://thread.gmane.org/gmane.comp.version-control.git/27/focus=217

as it also allows people who subscribe to the mailing list as
gmane newsgroup to "jump to" the article.

* Repositories, branches and documentation.

My public git.git repository is at:

        git://git.kernel.org/pub/scm/git/git.git/

Immediately after I publish to the primary repository at kernel.org, I
also push into an alternate here:

        git://repo.or.cz/alt-git.git/

Impatient people might have better luck with the latter one.

Their gitweb interfaces are found at:

        http://git.kernel.org/?p=git/git.git
        http://repo.or.cz/w/alt-git.git

There are three branches in git.git repository that are not about the
source tree of git: "todo", "html" and "man".  The first one was meant to
contain TODO list for me, but I am not good at maintaining such a list and
it is in an abandoned state.  The branch mostly is used to keep some
helper scripts I use to maintain git and the regular "What's cooking"
messages these days.

The "html" and "man" are autogenerated documentation from the tip of the
"master" branch; the tip of "html" is extracted to be visible at
kernel.org at:

        http://www.kernel.org/pub/software/scm/git/docs/

The above URL is the top-level documentation page, and it has
links to documentation of older releases.

The script to maintain these two documentation branches are found in the
"todo" branch as dodoc.sh, if you are interested.  It is a demonstration
of how to use a post-update hook to automate a task after pushing into a
repository.

There are four branches in git.git repository that track the source tree
of git: "master", "maint", "next", and "pu".  I may add more maintenance
branches (e.g. "maint-1.6.3") if we have hugely backward incompatible
feature updates in the future to keep an older release alive; I may not,
but the distributed nature of git means any volunteer can run a
stable-tree like that herself.

The "master" branch is meant to contain what are very well tested and
ready to be used in a production setting.  There could occasionally be
minor breakages or brown paper bag bugs but they are not expected to be
anything major, and more importantly quickly and trivially fixable.  Every
now and then, a "feature release" is cut from the tip of this branch and
they typically are named with three dotted decimal digits.  The last such
release was 1.7.2 done on Jul 21, 2010.  You can expect that the tip of
the "master" branch is always more stable than any of the released
versions.

Whenever a feature release is made, "maint" branch is forked off from
"master" at that point.  Obvious, safe and urgent fixes after a feature
release are applied to this branch and maintenance releases are cut from
it.  The maintenance releases are named with four dotted decimal, named
after the feature release they are updates to; the last such release was
1.7.1.1.  New features never go to this branch.  This branch is also
merged into "master" to propagate the fixes forward.

A trivial and safe enhancement goes directly on top of "master".  A new
development, either initiated by myself or more often by somebody who
found his or her own itch to scratch, does not usually happen on "master",
however.  Instead, a separate topic branch is forked from the tip of
"master", and it first is tested in isolation; I may make minimum fixups
at this point.  Usually there are a handful such topic branches that are
running ahead of "master" in git.git repository.  I do not publish the tip
of these branches in my public repository, however, partly to keep the
number of branches that downstream developers need to worry about low, and
primarily because I am lazy.

The quality of topic branches are judged primarily by the mailing list
discussions.  Some of them start out as "good idea but obviously is broken
in some areas (e.g. breaks the existing testsuite)" and then with some
more work (either by the original contributor's effort or help from other
people on the list) becomes "more or less done and can now be tested by
wider audience".  Luckily, most of them start out in the latter, better
shape.

The "next" branch is to merge and test topic branches in the latter
category.  In general, the branch always contains the tip of "master".  It
might not be quite rock-solid production ready, but is expected to work
more or less without major breakage.  I usually use "next" version of git
for my own work, so it cannot be _that_ broken to prevent me from
integrating and pushing the changes out.  The "next" branch is where new
and exciting things take place.

The two branches "master" and "maint" are never rewound, and "next"
usually will not be either (this automatically means the topics that have
been merged into "next" are usually not rebased, and you can find the tip
of topic branches you are interested in from the output of "git log
next"). You should be able to safely build on top of them.

After a feature release is made from "master", however, "next" will be
rebuilt from the tip of "master" using the surviving topics.  The commit
that replaces the tip of the "next" will usually have the identical tree,
but it will have different ancestry from the tip of "master".

The "pu" (proposed updates) branch bundles all the remainder of topic
branches.  The "pu" branch, and topic branches that are only in "pu", are
subject to rebasing in general.  By the above definition of how "next"
works, you can tell that this branch will contain quite experimental and
obviously broken stuff.

When a topic that was in "pu" proves to be in testable shape, it graduates
to "next".  I do this with:

        git checkout next
        git merge that-topic-branch

Sometimes, an idea that looked promising turns out to be not so good and
the topic can be dropped from "pu" in such a case.

A topic that is in "next" is expected to be polished to perfection before
it is merged to "master" (that's why "master" can be expected to stay more
stable than any released version).  Similarly to the above, I do it with
this:

        git checkout master
        git merge that-topic-branch
        git branch -d that-topic-branch

Note that being in "next" is not a guarantee to appear in the next release
(being in "master" is such a guarantee, unless it is later found seriously
broken and reverted), nor even in any future release.  There even were
cases that topics needed reverting a few commits in them before graduating
to "master", or a topic that already was in "next" were entirely reverted
from "next" because fatal flaws were found in them later.


* Other people's trees, trusted lieutenants and credits.

Documentation/SubmittingPatches outlines to whom your proposed changes
should be sent.  As described in contrib/README, I would delegate fixes
and enhancements in contrib/ area to the primary contributors of them.

Although the following are included in git.git repository, they have their
own authoritative repository and maintainers:

 - git-gui/ comes from Shawn Pearce's git-gui project:

        git://repo.or.cz/git-gui.git

 - gitk-git/ comes from Paul Mackerras's gitk project:

        git://git.kernel.org/pub/scm/gitk/gitk.git

I would like to thank everybody who helped to raise git into the current
shape.  Especially I would like to thank the git list regulars whose help
I have relied on and expect to continue relying on heavily:

 - Linus on general design issues.

 - Linus, Shawn Pearce, Johannes Schindelin, Nicolas Pitre, Ren辿
   Scharfe, Jeff King, Jonathan Nieder, Johan Herland, Johannes Sixt,
   and Sverre Rabbelier on general implementation issues and reviews
   on the mailing list.

 - Shawn and Nicolas Pitre on pack issues.

 - Martin Langhoff and Frank Lichtenheld on cvsserver and cvsimport.

 - Paul Mackerras on gitk.

 - Eric Wong on git-svn.

 - Simon Hausmann on git-p4.

 - Jakub Narebski, Petr Baudis, Luben Tuikov, Giuseppe Bilotta on
   gitweb.

 - J. Bruce Fields on documentation (and countless others for
   proofreading and fixing).

 - Alexandre Julliard on Emacs integration.

 - Charles Bailey for taking good care of git-mergetool (and Theodore
   Ts'o for creating it in the first place).

 - David Aguilar for git-difftool.

 - Johannes Schindelin, Johannes Sixt and others for their effort to
   move things forward on the Windows front.

 - People on non-Linux platforms for keeping their eyes on
   portability; especially, Randal Schwartz, Theodore Ts'o, Jason
   Riedy, Thomas Glanzmann, Brandon Casey, Jeff King, Alex Riesen and
   countless others.

* This document

The latest copy of this document is found in git.git repository,
on 'todo' branch, as MaintNotes.

A note from the maintainer

[Junio C Hamano]

Welcome to git development community.

This message is written by the maintainer and talks about how Git
project is managed, and how you can work with it.

* IRC and Mailing list

Members of the development community can sometimes be found on #git
IRC channel on Freenode.  Its log is available at:

        http://colabti.org/irclogger/irclogger_log/git

The development is primarily done on the Git mailing list If you have
patches, please send them to the list address (git@vger.kernel.org).
following Documentation/SubmittingPatches.  You don't have to be
subscribed to send messages there, and the convention is to Cc:
everybody involved, so you don't even have to say "Please Cc: me, I am
not subscribed".

If you sent a patch and you did not hear any response from anybody for
several days, it could be that your patch was totally uninteresting, but
it also is possible that it was simply lost in the noise.  Please do not
hesitate to send a reminder message politely in such a case.  Messages
getting lost in the noise is a sign that people involved don't have enough
mental/time bandwidth to process them right at the moment, and it often
helps to wait until the list traffic becomes calmer before sending such a
reminder.

The list archive is available at a few public sites as well:

        http://news.gmane.org/gmane.comp.version-control.git/
        http://marc.theaimsgroup.com/?l=git
        http://www.spinics.net/lists/git/

and some people seem to prefer to read it over NNTP:

        nntp://news.gmane.org/gmane.comp.version-control.git

When you point at a message in a mailing list archive, using
gmane is often the easiest to follow by readers, like this:

        http://thread.gmane.org/gmane.comp.version-control.git/27/focus=217

as it also allows people who subscribe to the mailing list as
gmane newsgroup to "jump to" the article.

* Repositories, branches and documentation.

My public git.git repository is at:

        git://git.kernel.org/pub/scm/git/git.git/

Immediately after I publish to the primary repository at kernel.org, I
also push into an alternate here:

        git://repo.or.cz/alt-git.git/

Impatient people might have better luck with the latter one.

Their gitweb interfaces are found at:

        http://git.kernel.org/?p=git/git.git
        http://repo.or.cz/w/alt-git.git

There are three branches in git.git repository that are not about the
source tree of git: "todo", "html" and "man".  The first one was meant to
contain TODO list for me, but I am not good at maintaining such a list and
it is in an abandoned state.  The branch mostly is used to keep some
helper scripts I use to maintain git and the regular "What's cooking"
messages these days.

The "html" and "man" are autogenerated documentation from the tip of the
"master" branch; the tip of "html" is extracted to be visible at
kernel.org at:

        http://www.kernel.org/pub/software/scm/git/docs/

The above URL is the top-level documentation page, and it has
links to documentation of older releases.

The script to maintain these two documentation branches are found in the
"todo" branch as dodoc.sh, if you are interested.  It is a demonstration
of how to use a post-update hook to automate a task after pushing into a
repository.

There are four branches in git.git repository that track the source tree
of git: "master", "maint", "next", and "pu".  I may add more maintenance
branches (e.g. "maint-1.6.3") if we have hugely backward incompatible
feature updates in the future to keep an older release alive; I may not,
but the distributed nature of git means any volunteer can run a
stable-tree like that herself.

The "master" branch is meant to contain what are very well tested and
ready to be used in a production setting.  There could occasionally be
minor breakages or brown paper bag bugs but they are not expected to be
anything major, and more importantly quickly and trivially fixable.  Every
now and then, a "feature release" is cut from the tip of this branch and
they typically are named with three dotted decimal digits.  The last such
release was 1.7.0 done on Feb 12, 2010.  You can expect that the tip of
the "master" branch is always more stable than any of the released
versions.

Whenever a feature release is made, "maint" branch is forked off from
"master" at that point.  Obvious, safe and urgent fixes after a feature
release are applied to this branch and maintenance releases are cut from
it.  The maintenance releases are named with four dotted decimal, named
after the feature release they are updates to; the last such release was
1.6.6.2.  New features never go to this branch.  This branch is also
merged into "master" to propagate the fixes forward.

A trivial and safe enhancement goes directly on top of "master".  A new
development, either initiated by myself or more often by somebody who
found his or her own itch to scratch, does not usually happen on "master",
however.  Instead, a separate topic branch is forked from the tip of
"master", and it first is tested in isolation; I may make minimum fixups
at this point.  Usually there are a handful such topic branches that are
running ahead of "master" in git.git repository.  I do not publish the tip
of these branches in my public repository, however, partly to keep the
number of branches that downstream developers need to worry about low, and
primarily because I am lazy.

The quality of topic branches are judged primarily by the mailing list
discussions.  Some of them start out as "good idea but obviously is broken
in some areas (e.g. breaks the existing testsuite)" and then with some
more work (either by the original contributor's effort or help from other
people on the list) becomes "more or less done and can now be tested by
wider audience".  Luckily, most of them start out in the latter, better
shape.

The "next" branch is to merge and test topic branches in the latter
category.  In general, the branch always contains the tip of "master".  It
might not be quite rock-solid production ready, but is expected to work
more or less without major breakage.  I usually use "next" version of git
for my own work, so it cannot be _that_ broken to prevent me from
integrating and pushing the changes out.  The "next" branch is where new
and exciting things take place.

The two branches "master" and "maint" are never rewound, and "next"
usually will not be either (this automatically means the topics that have
been merged into "next" are usually not rebased, and you can find the tip
of topic branches you are interested in from the output of "git log
next"). You should be able to safely build on top of them.

After a feature release is made from "master", however, "next" will be
rebuilt from the tip of "master" using the surviving topics.  The commit
that replaces the tip of the "next" will usually have the identical tree,
but it will have different ancestry from the tip of "master".

The "pu" (proposed updates) branch bundles all the remainder of topic
branches.  The "pu" branch, and topic branches that are only in "pu", are
subject to rebasing in general.  By the above definition of how "next"
works, you can tell that this branch will contain quite experimental and
obviously broken stuff.

When a topic that was in "pu" proves to be in testable shape, it graduates
to "next".  I do this with:

        git checkout next
        git merge that-topic-branch

Sometimes, an idea that looked promising turns out to be not so good and
the topic can be dropped from "pu" in such a case.

A topic that is in "next" is expected to be polished to perfection before
it is merged to "master" (that's why "master" can be expected to stay more
stable than any released version).  Similarly to the above, I do it with
this:

        git checkout master
        git merge that-topic-branch
        git branch -d that-topic-branch

Note that being in "next" is not a guarantee to appear in the next release
(being in "master" is such a guarantee, unless it is later found seriously
broken and reverted), nor even in any future release.  There even were
cases that topics needed reverting a few commits in them before graduating
to "master", or a topic that already was in "next" were entirely reverted
from "next" because fatal flaws were found in them later.


* Other people's trees, trusted lieutenants and credits.

Documentation/SubmittingPatches outlines to whom your proposed changes
should be sent.  As described in contrib/README, I would delegate fixes
and enhancements in contrib/ area to the primary contributors of them.

Although the following are included in git.git repository, they have their
own authoritative repository and maintainers:

 - git-gui/ comes from Shawn Pearce's git-gui project:

        git://repo.or.cz/git-gui.git

 - gitk-git/ comes from Paul Mackerras's gitk project:

        git://git.kernel.org/pub/scm/gitk/gitk.git

I would like to thank everybody who helped to raise git into the current
shape.  Especially I would like to thank the git list regulars whose help
I have relied on and expect to continue relying on heavily:

 - Linus on general design issues.

 - Linus, Shawn Pearce, Johannes Schindelin, Nicolas Pitre, Ren辿
   Scharfe, Jeff King and Johannes Sixt on general implementation
   issues.

 - Shawn and Nicolas Pitre on pack issues.

 - Martin Langhoff and Frank Lichtenheld on cvsserver and cvsimport.

 - Paul Mackerras on gitk.

 - Eric Wong on git-svn.

 - Simon Hausmann on git-p4.

 - Jakub Narebski, Petr Baudis, Luben Tuikov, Giuseppe Bilotta on
   gitweb.

 - J. Bruce Fields on documentation (and countless others for
   proofreading and fixing).

 - Alexandre Julliard on Emacs integration.

 - Charles Bailey for taking good care of git-mergetool (and Theodore
   Ts'o for creating it in the first place).

 - David Aguilar for git-difftool.

 - Johannes Schindelin, Johannes Sixt and others for their effort to
   move things forward on the Windows front.

 - People on non-Linux platforms for keeping their eyes on
   portability; especially, Randal Schwartz, Theodore Ts'o, Jason
   Riedy, Thomas Glanzmann, Brandon Casey, Jeff King, Alex Riesen and
   countless others.

* This document

The latest copy of this document is found in git.git repository,
on 'todo' branch, as MaintNotes.

A note from the maintainer

[Junio C Hamano]

Welcome to git development community.

This message is written by the maintainer and talks about how Git
project is managed, and how you can work with it.

* IRC and Mailing list

Members of the development community can sometimes be found on #git
IRC channel on Freenode.  Its log is available at:

        http://colabti.org/irclogger/irclogger_log/git

The development is primarily done on the Git mailing list If you have
patches, please send them to the list address (git@vger.kernel.org).
following Documentation/SubmittingPatches.  You don't have to be
subscribed to send messages there, and the convention is to Cc:
everybody involved, so you don't even have to say "Please Cc: me, I am
not subscribed".

If you sent a patch and you did not hear any response from anybody for
several days, it could be that your patch was totally uninteresting, but
it also is possible that it was simply lost in the noise.  Please do not
hesitate to send a reminder message politely in such a case.  Messages
getting lost in the noise is a sign that people involved don't have enough
mental/time bandwidth to process them right at the moment, and it often
helps to wait until the list traffic becomes calmer before sending such a
reminder.

The list archive is available at a few public sites as well:

        http://news.gmane.org/gmane.comp.version-control.git/
        http://marc.theaimsgroup.com/?l=git
        http://www.spinics.net/lists/git/

and some people seem to prefer to read it over NNTP:

        nntp://news.gmane.org/gmane.comp.version-control.git

When you point at a message in a mailing list archive, using
gmane is often the easiest to follow by readers, like this:

        http://thread.gmane.org/gmane.comp.version-control.git/27/focus=217

as it also allows people who subscribe to the mailing list as
gmane newsgroup to "jump to" the article.

* Repositories, branches and documentation.

My public git.git repository is at:

        git://git.kernel.org/pub/scm/git/git.git/

Immediately after I publish to the primary repository at kernel.org, I
also push into an alternate here:

        git://repo.or.cz/alt-git.git/

Impatient people might have better luck with the latter one.

Their gitweb interfaces are found at:

        http://git.kernel.org/?p=git/git.git
        http://repo.or.cz/w/alt-git.git

There are three branches in git.git repository that are not about the
source tree of git: "todo", "html" and "man".  The first one was meant to
contain TODO list for me, but I am not good at maintaining such a list and
it is in an abandoned state.  The branch mostly is used to keep some
helper scripts I use to maintain git and the regular "What's cooking"
messages these days.

The "html" and "man" are autogenerated documentation from the tip of the
"master" branch; the tip of "html" is extracted to be visible at
kernel.org at:

        http://www.kernel.org/pub/software/scm/git/docs/

The above URL is the top-level documentation page, and it has
links to documentation of older releases.

The script to maintain these two documentation branches are found in the
"todo" branch as dodoc.sh, if you are interested.  It is a demonstration
of how to use a post-update hook to automate a task after pushing into a
repository.

There are four branches in git.git repository that track the source tree
of git: "master", "maint", "next", and "pu".  I may add more maintenance
branches (e.g. "maint-1.6.3") if we have hugely backward incompatible
feature updates in the future to keep an older release alive; I may not,
but the distributed nature of git means any volunteer can run a
stable-tree like that herself.

The "master" branch is meant to contain what are very well tested and
ready to be used in a production setting.  There could occasionally be
minor breakages or brown paper bag bugs but they are not expected to be
anything major, and more importantly quickly and trivially fixable.  Every
now and then, a "feature release" is cut from the tip of this branch and
they typically are named with three dotted decimal digits.  The last such
release was 1.6.6 done on Dec 23rd 2009.  You can expect that the tip of
the "master" branch is always more stable than any of the released
versions.

Whenever a feature release is made, "maint" branch is forked off from
"master" at that point.  Obvious, safe and urgent fixes after a feature
release are applied to this branch and maintenance releases are cut from
it.  The maintenance releases are named with four dotted decimal, named
after the feature release they are updates to; the last such release was
1.6.5.7.  New features never go to this branch.  This branch is also
merged into "master" to propagate the fixes forward.

A trivial and safe enhancement goes directly on top of "master".  A new
development, either initiated by myself or more often by somebody who
found his or her own itch to scratch, does not usually happen on "master",
however.  Instead, a separate topic branch is forked from the tip of
"master", and it first is tested in isolation; I may make minimum fixups
at this point.  Usually there are a handful such topic branches that are
running ahead of "master" in git.git repository.  I do not publish the tip
of these branches in my public repository, however, partly to keep the
number of branches that downstream developers need to worry about low, and
primarily because I am lazy.

The quality of topic branches are judged primarily by the mailing list
discussions.  Some of them start out as "good idea but obviously is broken
in some areas (e.g. breaks the existing testsuite)" and then with some
more work (either by the original contributor's effort or help from other
people on the list) becomes "more or less done and can now be tested by
wider audience".  Luckily, most of them start out in the latter, better
shape.

The "next" branch is to merge and test topic branches in the latter
category.  In general, the branch always contains the tip of "master".  It
might not be quite rock-solid production ready, but is expected to work
more or less without major breakage.  I usually use "next" version of git
for my own work, so it cannot be _that_ broken to prevent me from
integrating and pushing the changes out.  The "next" branch is where new
and exciting things take place.

The two branches "master" and "maint" are never rewound, and "next"
usually will not be either (this automatically means the topics that have
been merged into "next" are usually not rebased, and you can find the tip
of topic branches you are interested in from the output of "git log
next"). You should be able to safely build on top of them.

After a feature release is made from "master", however, "next" will be
rebuilt from the tip of "master" using the surviving topics.  The commit
that replaces the tip of the "next" will usually have the identical tree,
but it will have different ancestry from the tip of "master".

The "pu" (proposed updates) branch bundles all the remainder of topic
branches.  The "pu" branch, and topic branches that are only in "pu", are
subject to rebasing in general.  By the above definition of how "next"
works, you can tell that this branch will contain quite experimental and
obviously broken stuff.

When a topic that was in "pu" proves to be in testable shape, it graduates
to "next".  I do this with:

        git checkout next
        git merge that-topic-branch

Sometimes, an idea that looked promising turns out to be not so good and
the topic can be dropped from "pu" in such a case.

A topic that is in "next" is expected to be polished to perfection before
it is merged to "master" (that's why "master" can be expected to stay more
stable than any released version).  Similarly to the above, I do it with
this:

        git checkout master
        git merge that-topic-branch
        git branch -d that-topic-branch

Note that being in "next" is not a guarantee to appear in the next release
(being in "master" is such a guarantee, unless it is later found seriously
broken and reverted), nor even in any future release.  There even were
cases that topics needed reverting a few commits in them before graduating
to "master", or a topic that already was in "next" were entirely reverted
from "next" because fatal flaws were found in them later.


* Other people's trees, trusted lieutenants and credits.

Documentation/SubmittingPatches outlines to whom your proposed changes
should be sent.  As described in contrib/README, I would delegate fixes
and enhancements in contrib/ area to the primary contributors of them.

Although the following are included in git.git repository, they have their
own authoritative repository and maintainers:

 - git-gui/ comes from Shawn Pearce's git-gui project:

        git://repo.or.cz/git-gui.git

 - gitk-git/ comes from Paul Mackerras's gitk project:

        git://git.kernel.org/pub/scm/gitk/gitk.git

I would like to thank everybody who helped to raise git into the current
shape.  Especially I would like to thank the git list regulars whose help
I have relied on and expect to continue relying on heavily:

 - Linus on general design issues.

 - Linus, Shawn Pearce, Johannes Schindelin, Nicolas Pitre, Ren辿
   Scharfe, Jeff King and Johannes Sixt on general implementation
   issues.

 - Shawn and Nicolas Pitre on pack issues.

 - Martin Langhoff and Frank Lichtenheld on cvsserver and cvsimport.

 - Paul Mackerras on gitk.

 - Eric Wong on git-svn.

 - Simon Hausmann on git-p4.

 - Jakub Narebski, Petr Baudis, Luben Tuikov, Giuseppe Bilotta on
   gitweb.

 - J. Bruce Fields on documentation (and countless others for
   proofreading and fixing).

 - Alexandre Julliard on Emacs integration.

 - Charles Bailey for taking good care of git-mergetool (and Theodore
   Ts'o for creating it in the first place).

 - David Aguilar for git-difftool.

 - Johannes Schindelin, Johannes Sixt and others for their effort to
   move things forward on the Windows front.

 - People on non-Linux platforms for keeping their eyes on
   portability; especially, Randal Schwartz, Theodore Ts'o, Jason
   Riedy, Thomas Glanzmann, Brandon Casey, Jeff King, Alex Riesen and
   countless others.

* This document

The latest copy of this document is found in git.git repository,
on 'todo' branch, as MaintNotes.

A note from the maintainer

[Junio C Hamano]

Welcome to git community.

This message talks about how git.git is managed, and how you can work
with it.

* IRC and Mailing list

Many active members of development community hang around on #git
IRC channel on Freenode.  Its log is available at:

        http://colabti.org/irclogger/irclogger_log/git

The development however is primarily done on the git mailing list
(git@vger.kernel.org).  If you have patches, please send them to the
list, following Documentation/SubmittingPatches.

I usually try to read all patches posted to the list, and follow
almost all the discussions on the list, unless the topic is about an
obscure corner that I do not personally use.  But I am obviously not
perfect.  If you sent a patch that you did not hear from anybody for
three days, that is a very good indication that it was dropped on the
floor --- please do not hesitate to remind me.

The list archive is available at a few public sites as well:

        http://news.gmane.org/gmane.comp.version-control.git/
        http://marc.theaimsgroup.com/?l=git
        http://www.spinics.net/lists/git/

and some people seem to prefer to read it over NNTP:

        nntp://news.gmane.org/gmane.comp.version-control.git

When you point at a message in a mailing list archive, using
gmane is often the easiest to follow by readers, like this:

        http://thread.gmane.org/gmane.comp.version-control.git/27/focus=217

as it also allows people who subscribe to the mailing list as
gmane newsgroup to "jump to" the article.

* Repositories, branches and documentation.

My public git.git repository is at:

        git://git.kernel.org/pub/scm/git/git.git/

Immediately after I publish to the primary repository at kernel.org, I
also push into an alternate here:

        git://repo.or.cz/alt-git.git/

Impatient people might have better luck with the latter one.

Their gitweb interfaces are found at:

        http://git.kernel.org/?p=git/git.git
        http://repo.or.cz/w/alt-git.git

There are three branches in git.git repository that are not about the
source tree of git: "todo", "html" and "man".  The first one was meant
to contain TODO list for me, but I am not good at maintaining such a
list and it is in an abandoned state.  The branch mostly is used to
keep some helper scripts I use to maintain git and the regular "What's
in/cooking" messages these days.

The "html" and "man" are autogenerated documentation from the
tip of the "master" branch; the tip of "html" is extracted to be
visible at kernel.org at:

        http://www.kernel.org/pub/software/scm/git/docs/

The above URL is the top-level documentation page, and it has
links to documentation of older releases.

The script to maintain these two documentation branches are
found in "todo" branch as dodoc.sh, if you are interested.  It
is a good demonstration of how to use a post-update hook to
automate a task.

There are four branches in git.git repository that track the
source tree of git: "master", "maint", "next", and "pu".  I may
add more maintenance branches (e.g. "maint-1.6.3") if we have
hugely backward incompatible feature updates in the future to keep
an older release alive; I may not, but the distributed nature of
git means any volunteer can run a stable-tree like that herself.

The "master" branch is meant to contain what are very well
tested and ready to be used in a production setting.  There
could occasionally be minor breakages or brown paper bag bugs
but they are not expected to be anything major, and more
importantly quickly and trivially fixable.  Every now and
then, a "feature release" is cut from the tip of this branch and
they typically are named with three dotted decimal digits.  The
last such release was 1.6.4 done on Jul 29th 2009.  You
can expect that the tip of the "master" branch is always more
stable than any of the released versions.

Whenever a feature release is made, "maint" branch is forked off
from "master" at that point.  Obvious, safe and urgent fixes
after a feature release are applied to this branch and
maintenance releases are cut from it.  The maintenance releases
are named with four dotted decimal, named after the feature
release they are updates to; the last such release was 1.6.3.4.
New features never go to this branch.  This branch is also
merged into "master" to propagate the fixes forward.

A trivial and safe enhancement goes directly on top of "master".
A new development, either initiated by myself or more often by
somebody who found his or her own itch to scratch, does not
usually happen on "master", however.  Instead, a separate topic
branch is forked from the tip of "master", and it first is
tested in isolation; I may make minimum fixups at this point.
Usually there are a handful such topic branches that are running
ahead of "master" in git.git repository.  I do not publish the
tip of these branches in my public repository, however, partly
to keep the number of branches that downstream developers need
to worry about low, and primarily because I am lazy.

The quality of topic branches are judged primarily by the mailing list
discussions.  Some of them start out as "good idea but obviously is
broken in some areas (e.g. breaks the existing testsuite)" and then
with some more work (either by the original contributor's effort or
help from other people on the list) becomes "more or less done and can
now be tested by wider audience".  Luckily, most of them start out in
the latter, better shape.

The "next" branch is to merge and test topic branches in the
latter category.  In general, the branch always contains the tip
of "master".  It might not be quite rock-solid production ready,
but is expected to work more or less without major breakage.  I
usually use "next" version of git for my own work, so it cannot
be _that_ broken to prevent me from pushing the changes out.
The "next" branch is where new and exciting things take place.

The two branches "master" and "maint" are never rewound, and
"next" usually will not be either (this automatically means the
topics that have been merged into "next" are usually not
rebased, and you can find the tip of topic branches you are
interested in from the output of "git log next"). You should be
able to safely track them.

After a feature release is made from "master", however, "next"
will be rebuilt from the tip of "master" using the surviving
topics.  The commit that replaces the tip of the "next" will
usually have the identical tree, but it will have different ancestry
from the tip of "master".  An announcement will be made to warn
people about such a rebasing.

The "pu" (proposed updates) branch bundles all the remainder of
topic branches.  The "pu" branch, and topic branches that are
only in "pu", are subject to rebasing in general.  By the above
definition of how "next" works, you can tell that this branch
will contain quite experimental and obviously broken stuff.

When a topic that was in "pu" proves to be in testable shape, it
graduates to "next".  I do this with:

        git checkout next
        git merge that-topic-branch

Sometimes, an idea that looked promising turns out to be not so
good and the topic can be dropped from "pu" in such a case.

A topic that is in "next" is expected to be tweaked and fixed to
perfection before it is merged to "master" (that's why "master"
can be expected to stay very stable).  Similarly to the above, I
do it with this:

        git checkout master
        git merge that-topic-branch
        git branch -d that-topic-branch

Note that being in "next" is not a guarantee to appear in the
next release (being in "master" is such a guarantee, unless it
is later found seriously broken and reverted), nor even in any
future release.  There even were cases that topics needed
reverting a few commits in them before graduating to "master",
or a topic that already was in "next" were entirely reverted
from "next" because fatal flaws were found in them later.


* Other people's trees, trusted lieutenants and credits.

Documentation/SubmittingPatches outlines to whom your proposed
changes should be sent.  As described in contrib/README, I would
delegate fixes and enhancements in contrib/ area to the primary
contributors of them.

Although the following are included in git.git repository, they
have their own authoritative repository and maintainers:

 - git-gui/ comes from Shawn Pearce's git-gui project:

        git://repo.or.cz/git-gui.git

 - gitk-git/ comes from Paul Mackerras's gitk project:

        git://git.kernel.org/pub/scm/gitk/gitk.git

I would like to thank everybody who helped to raise git into the
current shape.  Especially I would like to thank the git list
regulars whose help I have relied on and expect to continue
relying on heavily:

 - Linus on general design issues.

 - Linus, Shawn Pearce, Johannes Schindelin, Nicolas Pitre,
   Ren辿 Scharfe, Jeff King and Johannes Sixt on general
   implementation issues.

 - Shawn and Nicolas Pitre on pack issues.

 - Martin Langhoff and Frank Lichtenheld on cvsserver and cvsimport.

 - Paul Mackerras on gitk.

 - Eric Wong on git-svn.

 - Simon Hausmann on git-p4.

 - Jakub Narebski, Petr Baudis, Luben Tuikov, Giuseppe Bilotta
   on gitweb.

 - J. Bruce Fields on documentation (and countless others for
   proofreading and fixing).

 - Alexandre Julliard on Emacs integration.

 - Charles Bailey for taking good care of git-mergetool (and Theodore
   Ts'o for creating it in the first place).

 - David Aguilar for git-difftool.

 - Johannes Schindelin, Johannes Sixt and others for their effort
   to move things forward on the Windows front.

 - People on non-Linux platforms for keeping their eyes on
   portability; especially, Randal Schwartz, Theodore Ts'o,
   Jason Riedy, Thomas Glanzmann, Brandon Casey, Jeff King,
   Alex Riesen and countless others.

* This document

The latest copy of this document is found in git.git repository,
on 'todo' branch, as MaintNotes.

A note from the maintainer

[Junio C Hamano]

Welcome to git community.

This message talks about how git.git is managed, and how you can work
with it.

* IRC and Mailing list

Many active members of development community hang around on #git
IRC channel on Freenode.  Its log is available at:

        http://colabti.org/irclogger/irclogger_log/git

The development however is primarily done on the git mailing list
(git@vger.kernel.org).  If you have patches, please send them to the
list, following Documentation/SubmittingPatches.

I usually try to read all patches posted to the list, and follow
almost all the discussions on the list, unless the topic is about an
obscure corner that I do not personally use.  But I am obviously not
perfect.  If you sent a patch that you did not hear from anybody for
three days, that is a very good indication that it was dropped on the
floor --- please do not hesitate to remind me.

The list archive is available at a few public sites as well:

        http://news.gmane.org/gmane.comp.version-control.git/
        http://marc.theaimsgroup.com/?l=git
        http://www.spinics.net/lists/git/

and some people seem to prefer to read it over NNTP:

        nntp://news.gmane.org/gmane.comp.version-control.git

When you point at a message in a mailing list archive, using
gmane is often the easiest to follow by readers, like this:

        http://thread.gmane.org/gmane.comp.version-control.git/27/focus=217

as it also allows people who subscribe to the mailing list as
gmane newsgroup to "jump to" the article.

* Repositories, branches and documentation.

My public git.git repository is at:

        git://git.kernel.org/pub/scm/git/git.git/

Immediately after I publish to the primary repository at kernel.org, I
also push into an alternate here:

        git://repo.or.cz/alt-git.git/

Impatient people might have better luck with the latter one.

Their gitweb interfaces are found at:

        http://git.kernel.org/?p=git/git.git
        http://repo.or.cz/w/alt-git.git

There are three branches in git.git repository that are not about the
source tree of git: "todo", "html" and "man".  The first one was meant
to contain TODO list for me, but I am not good at maintaining such a
list and it is in an abandoned state.  The branch mostly is used to
keep some helper scripts I use to maintain git and the regular "What's
in/cooking" messages these days.

The "html" and "man" are autogenerated documentation from the
tip of the "master" branch; the tip of "html" is extracted to be
visible at kernel.org at:

        http://www.kernel.org/pub/software/scm/git/docs/

The above URL is the top-level documentation page, and it has
links to documentation of older releases.

The script to maintain these two documentation branches are
found in "todo" branch as dodoc.sh, if you are interested.  It
is a good demonstration of how to use a post-update hook to
automate a task.

There are four branches in git.git repository that track the
source tree of git: "master", "maint", "next", and "pu".  I may
add more maintenance branches (e.g. "maint-1.5.4") if we have
hugely backward incompatible feature updates in the future to keep
an older release alive; I may not, but the distributed nature of
git means any volunteer can run a stable-tree like that herself.

The "master" branch is meant to contain what are very well
tested and ready to be used in a production setting.  There
could occasionally be minor breakages or brown paper bag bugs
but they are not expected to be anything major, and more
importantly quickly and trivially fixable.  Every now and
then, a "feature release" is cut from the tip of this branch and
they typically are named with three dotted decimal digits.  The
last such release was 1.6.3 done on May 6th 2009.  You
can expect that the tip of the "master" branch is always more
stable than any of the released versions.

Whenever a feature release is made, "maint" branch is forked off
from "master" at that point.  Obvious, safe and urgent fixes
after a feature release are applied to this branch and
maintenance releases are cut from it.  The maintenance releases
are named with four dotted decimal, named after the feature
release they are updates to; the last such release was 1.6.2.5.
New features never go to this branch.  This branch is also
merged into "master" to propagate the fixes forward.

A trivial and safe enhancement goes directly on top of "master".
A new development, either initiated by myself or more often by
somebody who found his or her own itch to scratch, does not
usually happen on "master", however.  Instead, a separate topic
branch is forked from the tip of "master", and it first is
tested in isolation; I may make minimum fixups at this point.
Usually there are a handful such topic branches that are running
ahead of "master" in git.git repository.  I do not publish the
tip of these branches in my public repository, however, partly
to keep the number of branches that downstream developers need
to worry about low, and primarily because I am lazy.

The quality of topic branches are judged primarily by the mailing list
discussions.  Some of them start out as "good idea but obviously is
broken in some areas (e.g. breaks the existing testsuite)" and then
with some more work (either by the original contributor's effort or
help from other people on the list) becomes "more or less done and can
now be tested by wider audience".  Luckily, most of them start out in
the latter, better shape.

The "next" branch is to merge and test topic branches in the
latter category.  In general, the branch always contains the tip
of "master".  It might not be quite rock-solid production ready,
but is expected to work more or less without major breakage.  I
usually use "next" version of git for my own work, so it cannot
be _that_ broken to prevent me from pushing the changes out.
The "next" branch is where new and exciting things take place.

The two branches "master" and "maint" are never rewound, and
"next" usually will not be either (this automatically means the
topics that have been merged into "next" are usually not
rebased, and you can find the tip of topic branches you are
interested in from the output of "git log next"). You should be
able to safely track them.

After a feature release is made from "master", however, "next"
will be rebuilt from the tip of "master" using the surviving
topics.  The commit that replaces the tip of the "next" will
usually have the identical tree, but it will have different ancestry
from the tip of "master".  An announcement will be made to warn
people about such a rebasing.

The "pu" (proposed updates) branch bundles all the remainder of
topic branches.  The "pu" branch, and topic branches that are
only in "pu", are subject to rebasing in general.  By the above
definition of how "next" works, you can tell that this branch
will contain quite experimental and obviously broken stuff.

When a topic that was in "pu" proves to be in testable shape, it
graduates to "next".  I do this with:

        git checkout next
        git merge that-topic-branch

Sometimes, an idea that looked promising turns out to be not so
good and the topic can be dropped from "pu" in such a case.

A topic that is in "next" is expected to be tweaked and fixed to
perfection before it is merged to "master" (that's why "master"
can be expected to stay very stable).  Similarly to the above, I
do it with this:

        git checkout master
        git merge that-topic-branch
        git branch -d that-topic-branch

Note that being in "next" is not a guarantee to appear in the
next release (being in "master" is such a guarantee, unless it
is later found seriously broken and reverted), nor even in any
future release.  There even were cases that topics needed
reverting a few commits in them before graduating to "master",
or a topic that already was in "next" were entirely reverted
from "next" because fatal flaws were found in them later.


* Other people's trees, trusted lieutenants and credits.

Documentation/SubmittingPatches outlines to whom your proposed
changes should be sent.  As described in contrib/README, I would
delegate fixes and enhancements in contrib/ area to the primary
contributors of them.

Although the following are included in git.git repository, they
have their own authoritative repository and maintainers:

 - git-gui/ comes from Shawn Pearce's git-gui project:

        git://repo.or.cz/git-gui.git

 - gitk-git/ comes from Paul Mackerras's gitk project:

        git://git.kernel.org/pub/scm/gitk/gitk.git

I would like to thank everybody who helped to raise git into the
current shape.  Especially I would like to thank the git list
regulars whose help I have relied on and expect to continue
relying on heavily:

 - Linus on general design issues.

 - Linus, Shawn Pearce, Johannes Schindelin, Nicolas Pitre,
   Ren辿 Scharfe, Jeff King and Johannes Sixt on general
   implementation issues.

 - Shawn and Nicolas Pitre on pack issues.

 - Martin Langhoff and Frank Lichtenheld on cvsserver and cvsimport.

 - Paul Mackerras on gitk.

 - Eric Wong on git-svn.

 - Simon Hausmann on git-p4.

 - Jakub Narebski, Petr Baudis, Luben Tuikov, Giuseppe Bilotta
   on gitweb.

 - J. Bruce Fields on documentation (and countless others for
   proofreading and fixing).

 - Alexandre Julliard on Emacs integration.

 - Charles Bailey for taking good care of git-mergetool (and Theodore
   Ts'o for creating it in the first place).

 - David Aguilar for git-difftool.

 - Johannes Schindelin, Johannes Sixt and others for their effort
   to move things forward on the Windows front.

 - People on non-Linux platforms for keeping their eyes on
   portability; especially, Randal Schwartz, Theodore Ts'o,
   Jason Riedy, Thomas Glanzmann, Brandon Casey, Jeff King,
   Alex Riesen and countless others.

* This document

The latest copy of this document is found in git.git repository,
on 'todo' branch, as MaintNotes.

Re: A note from the maintainer

[Baz]

Apologies for not quoting the mail I'm replying to, but gmail would
just make the character encoding issues worse.

Junio, Rene Scharfe's name appears incorrectly in the MaintNotes
message - the mail was sent as iso-2022-jp. Previous editions of this
mail (like the one on 4th March) were in utf-8. Maybe a consequence of
the recent change you made to your emacs setup?

http://article.gmane.org/gmane.comp.version-control.git/115746

Just mentioning it in case it causes problems with patch mails down the line.

Cheers,
Baz

Re: A note from the maintainer

[Junio C Hamano]

Baz <brian.ewins@gmail.com> writes:

> Junio, Rene Scharfe's name appears incorrectly in the MaintNotes
> message - the mail was sent as iso-2022-jp. Previous editions of this
> mail (like the one on 4th March) were in utf-8. Maybe a consequence of
> the recent change you made to your emacs setup?

Thanks for not just complaining but giving me a clue where to look into.
I very much appreciate it.  Will find time to look into it before sending
any more message with a non-ascii character.

A note from the maintainer

[Junio C Hamano]

Welcome to git community.

This message talks about how git.git is managed, and how you can work
with it.

* IRC and Mailing list

Many active members of development community hang around on #git
IRC channel on Freenode.  Its log is available at:

        http://colabti.org/irclogger/irclogger_log/git

The development however is primarily done on the git mailing list
(git@vger.kernel.org).  If you have patches, please send them to the
list, following Documentation/SubmittingPatches.

I usually try to read all patches posted to the list, and follow
almost all the discussions on the list, unless the topic is about an
obscure corner that I do not personally use.  But I am obviously not
perfect.  If you sent a patch that you did not hear from anybody for
three days, that is a very good indication that it was dropped on the
floor --- please do not hesitate to remind me.

The list archive is available at a few public sites as well:

        http://news.gmane.org/gmane.comp.version-control.git/
        http://marc.theaimsgroup.com/?l=git
        http://www.spinics.net/lists/git/

and some people seem to prefer to read it over NNTP:

        nntp://news.gmane.org/gmane.comp.version-control.git

When you point at a message in a mailing list archive, using
gmane is often the easiest to follow by readers, like this:

        http://thread.gmane.org/gmane.comp.version-control.git/27/focus=217

as it also allows people who subscribe to the mailing list as
gmane newsgroup to "jump to" the article.

* Repositories, branches and documentation.

My public git.git repository is at:

        git://git.kernel.org/pub/scm/git/git.git/

Immediately after I publish to the primary repository at kernel.org, I
also push into an alternate here:

        git://repo.or.cz/alt-git.git/

Impatient people might have better luck with the latter one.

Their gitweb interfaces are found at:

        http://git.kernel.org/?p=git/git.git
        http://repo.or.cz/w/alt-git.git

There are three branches in git.git repository that are not about the
source tree of git: "todo", "html" and "man".  The first one was meant
to contain TODO list for me, but I am not good at maintaining such a
list and it is in an abandoned state.  The branch mostly is used to
keep some helper scripts I use to maintain git and the regular "What's
in/cooking" messages these days.

The "html" and "man" are autogenerated documentation from the
tip of the "master" branch; the tip of "html" is extracted to be
visible at kernel.org at:

        http://www.kernel.org/pub/software/scm/git/docs/

The above URL is the top-level documentation page, and it has
links to documentation of older releases.

The script to maintain these two documentation branches are
found in "todo" branch as dodoc.sh, if you are interested.  It
is a good demonstration of how to use a post-update hook to
automate a task.

There are four branches in git.git repository that track the
source tree of git: "master", "maint", "next", and "pu".  I may
add more maintenance branches (e.g. "maint-1.5.4") if we have
hugely backward incompatible feature updates in the future to keep
an older release alive; I may not, but the distributed nature of
git means any volunteer can run a stable-tree like that herself.

The "master" branch is meant to contain what are very well
tested and ready to be used in a production setting.  There
could occasionally be minor breakages or brown paper bag bugs
but they are not expected to be anything major, and more
importantly quickly and trivially fixable.  Every now and
then, a "feature release" is cut from the tip of this branch and
they typically are named with three dotted decimal digits.  The
last such release was 1.6.2 done on Mar 3rd 2009.  You
can expect that the tip of the "master" branch is always more
stable than any of the released versions.

Whenever a feature release is made, "maint" branch is forked off
from "master" at that point.  Obvious, safe and urgent fixes
after a feature release are applied to this branch and
maintenance releases are cut from it.  The maintenance releases
are named with four dotted decimal, named after the feature
release they are updates to; the last such release was 1.6.1.3.
New features never go to this branch.  This branch is also
merged into "master" to propagate the fixes forward.

A trivial and safe enhancement goes directly on top of "master".
A new development, either initiated by myself or more often by
somebody who found his or her own itch to scratch, does not
usually happen on "master", however.  Instead, a separate topic
branch is forked from the tip of "master", and it first is
tested in isolation; I may make minimum fixups at this point.
Usually there are a handful such topic branches that are running
ahead of "master" in git.git repository.  I do not publish the
tip of these branches in my public repository, however, partly
to keep the number of branches that downstream developers need
to worry about low, and primarily because I am lazy.

The quality of topic branches are judged primarily by the mailing list
discussions.  Some of them start out as "good idea but obviously is
broken in some areas (e.g. breaks the existing testsuite)" and then
with some more work (either by the original contributor's effort or
help from other people on the list) becomes "more or less done and can
now be tested by wider audience".  Luckily, most of them start out in
the latter, better shape.

The "next" branch is to merge and test topic branches in the
latter category.  In general, the branch always contains the tip
of "master".  It might not be quite rock-solid production ready,
but is expected to work more or less without major breakage.  I
usually use "next" version of git for my own work, so it cannot
be _that_ broken to prevent me from pushing the changes out.
The "next" branch is where new and exciting things take place.

The two branches "master" and "maint" are never rewound, and
"next" usually will not be either (this automatically means the
topics that have been merged into "next" are usually not
rebased, and you can find the tip of topic branches you are
interested in from the output of "git log next"). You should be
able to safely track them.

After a feature release is made from "master", however, "next"
will be rebuilt from the tip of "master" using the surviving
topics.  The commit that replaces the tip of the "next" will
usually have the identical tree, but it will have different ancestry
from the tip of "master".  An announcement will be made to warn
people about such a rebasing.

The "pu" (proposed updates) branch bundles all the remainder of
topic branches.  The "pu" branch, and topic branches that are
only in "pu", are subject to rebasing in general.  By the above
definition of how "next" works, you can tell that this branch
will contain quite experimental and obviously broken stuff.

When a topic that was in "pu" proves to be in testable shape, it
graduates to "next".  I do this with:

        git checkout next
        git merge that-topic-branch

Sometimes, an idea that looked promising turns out to be not so
good and the topic can be dropped from "pu" in such a case.

A topic that is in "next" is expected to be tweaked and fixed to
perfection before it is merged to "master" (that's why "master"
can be expected to stay very stable).  Similarly to the above, I
do it with this:

        git checkout master
        git merge that-topic-branch
        git branch -d that-topic-branch

Note that being in "next" is not a guarantee to appear in the
next release (being in "master" is such a guarantee, unless it
is later found seriously broken and reverted), nor even in any
future release.  There even were cases that topics needed
reverting a few commits in them before graduating to "master",
or a topic that already was in "next" were entirely reverted
from "next" because fatal flaws were found in them later.


* Other people's trees, trusted lieutenants and credits.

Documentation/SubmittingPatches outlines to whom your proposed
changes should be sent.  As described in contrib/README, I would
delegate fixes and enhancements in contrib/ area to the primary
contributors of them.

Although the following are included in git.git repository, they
have their own authoritative repository and maintainers:

 - git-gui/ comes from Shawn Pearce's git-gui project:

        git://repo.or.cz/git-gui.git

 - gitk-git/ comes from Paul Mackerras's gitk project:

        git://git.kernel.org/pub/scm/gitk/gitk.git

I would like to thank everybody who helped to raise git into the
current shape.  Especially I would like to thank the git list
regulars whose help I have relied on and expect to continue
relying on heavily:

 - Linus on general design issues.

 - Linus, Shawn Pearce, Johannes Schindelin, Nicolas Pitre,
   René Scharfe, Jeff King and Johannes Sixt on general
   implementation issues.

 - Shawn and Nicolas Pitre on pack issues.

 - Martin Langhoff and Frank Lichtenheld on cvsserver and cvsimport.

 - Paul Mackerras on gitk.

 - Eric Wong on git-svn.

 - Simon Hausmann on git-p4.

 - Jakub Narebski, Petr Baudis, Luben Tuikov, Giuseppe Bilotta
   on gitweb.

 - J. Bruce Fields on documentation (and countless others for
   proofreading and fixing).

 - Alexandre Julliard on Emacs integration.

 - Charles Bailey for git-mergetool (and Theodore Ts'o for creating
   the tool).

 - Johannes Schindelin, Johannes Sixt and others for their effort
   to move things forward on the Windows front.

 - People on non-Linux platforms for keeping their eyes on
   portability; especially, Randal Schwartz, Theodore Ts'o,
   Jason Riedy, Thomas Glanzmann, Brandon Casey, but countless
   others as well.

* This document

The latest copy of this document is found in git.git repository,
on 'todo' branch, as MaintNotes.

A note from the maintainer

[Junio C Hamano]

Welcome to git community.

This message talks about how git.git is managed, and how you can work
with it.

* IRC and Mailing list

Many active members of development community hang around on #git
IRC channel on Freenode.  Its log is available at:

        http://colabti.org/irclogger/irclogger_log/git

The development however is primarily done on the git mailing list
(git@vger.kernel.org).  If you have patches, please send them to the
list, following Documentation/SubmittingPatches.

I usually try to read all patches posted to the list, and follow
almost all the discussions on the list, unless the topic is about an
obscure corner that I do not personally use.  But I am obviously not
perfect.  If you sent a patch that you did not hear from anybody for
three days, that is a very good indication that it was dropped on the
floor --- please do not hesitate to remind me.

The list archive is available at a few public sites as well:

        http://news.gmane.org/gmane.comp.version-control.git/
        http://marc.theaimsgroup.com/?l=git
        http://www.spinics.net/lists/git/

and some people seem to prefer to read it over NNTP:

        nntp://news.gmane.org/gmane.comp.version-control.git

When you point at a message in a mailing list archive, using
gmane is often the easiest to follow by readers, like this:

        http://thread.gmane.org/gmane.comp.version-control.git/27/focus=217

as it also allows people who subscribe to the mailing list as
gmane newsgroup to "jump to" the article.

* Repositories, branches and documentation.

My public git.git repository is at:

        git://git.kernel.org/pub/scm/git/git.git/

Immediately after I publish to the primary repository at kernel.org, I
also push into an alternate here:

        git://repo.or.cz/alt-git.git/

Impatient people might have better luck with the latter one.

Their gitweb interfaces are found at:

        http://git.kernel.org/?p=git/git.git
        http://repo.or.cz/w/alt-git.git

There are three branches in git.git repository that are not
about the source tree of git: "todo", "html" and "man".  The
first one was meant to contain TODO list for me, but I am not
good at maintaining such a list and it is not as often updated as
it could/should be.  It also contains some helper scripts I use
to maintain git.

The "html" and "man" are autogenerated documentation from the
tip of the "master" branch; the tip of "html" is extracted to be
visible at kernel.org at:

        http://www.kernel.org/pub/software/scm/git/docs/

The above URL is the top-level documentation page, and it has
links to documentation of older releases.

The script to maintain these two documentation branches are
found in "todo" branch as dodoc.sh, if you are interested.  It
is a good demonstration of how to use an update hook to automate
a task.

There are four branches in git.git repository that track the
source tree of git: "master", "maint", "next", and "pu".  I may
add more maintenance branches (e.g. "maint-1.5.4") if we have
hugely backward incompatible feature updates in the future to keep
an older release alive; I may not, but the distributed nature of
git means any volunteer can run a stable-tree like that herself.

The "master" branch is meant to contain what are very well
tested and ready to be used in a production setting.  There
could occasionally be minor breakages or brown paper bag bugs
but they are not expected to be anything major, and more
importantly quickly and trivially fixable.  Every now and
then, a "feature release" is cut from the tip of this branch and
they typically are named with three dotted decimal digits.  The
last such release was 1.6.1 done on Dec 24th 2008.  You
can expect that the tip of the "master" branch is always more
stable than any of the released versions.

Whenever a feature release is made, "maint" branch is forked off
from "master" at that point.  Obvious, safe and urgent fixes
after a feature release are applied to this branch and
maintenance releases are cut from it.  The maintenance releases
are named with four dotted decimal, named after the feature
release they are updates to; the last such release was 1.6.0.6.
New features never go to this branch.  This branch is also
merged into "master" to propagate the fixes forward.

A trivial and safe enhancement goes directly on top of "master".
A new development, either initiated by myself or more often by
somebody who found his or her own itch to scratch, does not
usually happen on "master", however.  Instead, a separate topic
branch is forked from the tip of "master", and it first is
tested in isolation; I may make minimum fixups at this point.
Usually there are a handful such topic branches that are running
ahead of "master" in git.git repository.  I do not publish the
tip of these branches in my public repository, however, partly
to keep the number of branches that downstream developers need
to worry about low, and primarily because I am lazy.

The quality of topic branches are judged primarily by the mailing list
discussions.  Some of them start out as "good idea but obviously is
broken in some areas (e.g. breaks the existing testsuite)" and then
with some more work (either by the original contributor's effort or
help from other people on the list) becomes "more or less done and can
now be tested by wider audience".  Luckily, most of them start out in
the latter, better shape.

The "next" branch is to merge and test topic branches in the
latter category.  In general, the branch always contains the tip
of "master".  It might not be quite rock-solid production ready,
but is expected to work more or less without major breakage.  I
usually use "next" version of git for my own work, so it cannot
be _that_ broken to prevent me from pushing the changes out.
The "next" branch is where new and exciting things take place.

The two branches "master" and "maint" are never rewound, and
"next" usually will not be either (this automatically means the
topics that have been merged into "next" are usually not
rebased, and you can find the tip of topic branches you are
interested in from the output of "git log next"). You should be
able to safely track them.

After a feature release is made from "master", however, "next"
will be rebuilt from the tip of "master" using the surviving
topics.  The commit that replaces the tip of the "next" will
have the identical tree, but it will have different ancestry
from the tip of "master".  An announcement will be made to warn
people about such a rebasing.

The "pu" (proposed updates) branch bundles all the remainder of
topic branches.  The "pu" branch, and topic branches that are
only in "pu", are subject to rebasing in general.  By the above
definition of how "next" works, you can tell that this branch
will contain quite experimental and obviously broken stuff.

When a topic that was in "pu" proves to be in testable shape, it
graduates to "next".  I do this with:

        git checkout next
        git merge that-topic-branch

Sometimes, an idea that looked promising turns out to be not so
good and the topic can be dropped from "pu" in such a case.

A topic that is in "next" is expected to be tweaked and fixed to
perfection before it is merged to "master" (that's why "master"
can be expected to stay very stable).  Similarly to the above, I
do it with this:

        git checkout master
        git merge that-topic-branch
        git branch -d that-topic-branch

Note that being in "next" is not a guarantee to appear in the
next release (being in "master" is such a guarantee, unless it
is later found seriously broken and reverted), or even in any
future release.  There even were cases that topics needed
reverting a few commits in them before graduating to "master",
or a topic that already was in "next" were entirely reverted
from "next" because fatal flaws were found in them later.

Starting from v1.5.0, "master" and "maint" have release notes
for the next release in Documentation/RelNotes-* files, so that
I do not have to run around summarizing what happened just
before the release.


* Other people's trees, trusted lieutenants and credits.

Documentation/SubmittingPatches outlines who your changes should
be sent to.  As described in contrib/README, I would delegate
fixes and enhancements in contrib/ area to primary contributors
of them.

Although the following are included in git.git repository, they
have their own authoritative repository and maintainers:

 - git-gui/ comes from Shawn Pearce's git-gui project:

        git://repo.or.cz/git-gui.git

 - gitk-git/ comes from Paul Mackerras's gitk project:

        git://git.kernel.org/pub/scm/gitk/gitk.git

I would like to thank everybody who helped to raise git into the
current shape.  Especially I would like to thank the git list
regulars whose help I have relied on and expect to continue
relying on heavily:

 - Linus on general design issues.

 - Linus, Shawn Pearce, Johannes Schindelin, Nicolas Pitre,
   René Scharfe and Jeff King on general implementation issues.

 - Shawn and Nicolas Pitre on pack issues.

 - Martin Langhoff and Frank Lichtenheld on cvsserver and cvsimport.

 - Paul Mackerras on gitk.

 - Eric Wong on git-svn.

 - Simon Hausmann on git-p4.

 - Jakub Narebski, Petr Baudis, and Luben Tuikov on gitweb.

 - J. Bruce Fields on documentaton issues.

 - Johannes Schindelin, Johannes Sixt and others for their effort
   to move things forward on the Windows front.  Most of the fruits
   from their porting efforts have been merged to the mainline git.git
   repository in 1.6.0 release.

 - People on non-Linux platforms for keeping their eyes on
   portability; especially, Randal Schwartz, Theodore Ts'o,
   Jason Riedy, Thomas Glanzmann, but countless others as well.

* This document

The latest copy of this document is found in git.git repository,
on 'todo' branch, as MaintNotes.

I also keep a copy of it at http://members.cox.net/junkio/

[ANNOUNCE] GIT 1.6.0

[Junio C Hamano]

The latest feature release GIT 1.6.0 is available at the usual
places:

  http://www.kernel.org/pub/software/scm/git/

  git-1.6.0.tar.{gz,bz2}			(source tarball)
  git-htmldocs-1.6.0.tar.{gz,bz2}		(preformatted docs)
  git-manpages-1.6.0.tar.{gz,bz2}		(preformatted docs)

The RPM binary packages for a few architectures are also provided
as courtesy.

  RPMS/$arch/*-1.6.0-1.fc9.$arch.rpm		(RPM)

GIT v1.6.0 Release Notes
========================

User visible changes
--------------------

With the default Makefile settings, most of the programs are now
installed outside your $PATH, except for "git", "gitk" and
some server side programs that need to be accessible for technical
reasons.  Invoking a git subcommand as "git-xyzzy" from the command
line has been deprecated since early 2006 (and officially announced in
1.5.4 release notes); use of them from your scripts after adding
output from "git --exec-path" to the $PATH is still supported in this
release, but users are again strongly encouraged to adjust their
scripts to use "git xyzzy" form, as we will stop installing
"git-xyzzy" hardlinks for built-in commands in later releases.

An earlier change to page "git status" output was overwhelmingly unpopular
and has been reverted.

Source changes needed for porting to MinGW environment are now all in the
main git.git codebase.

By default, packfiles created with this version uses delta-base-offset
encoding introduced in v1.4.4.  Pack idx files are using version 2 that
allows larger packs and added robustness thanks to its CRC checking,
introduced in v1.5.2 and v1.4.4.5.  If you want to keep your repositories
backwards compatible past these versions, set repack.useDeltaBaseOffset
to false or pack.indexVersion to 1, respectively.

We used to prevent sample hook scripts shipped in templates/ from
triggering by default by relying on the fact that we install them as
unexecutable, but on some filesystems, this approach does not work.
They are now shipped with ".sample" suffix.  If you want to activate
any of these samples as-is, rename them to drop the ".sample" suffix,
instead of running "chmod +x" on them.  For example, you can rename
hooks/post-update.sample to hooks/post-update to enable the sample
hook that runs update-server-info, in order to make repositories
friendly to dumb protocols (i.e. HTTP).

GIT_CONFIG, which was only documented as affecting "git config", but
actually affected all git commands, now only affects "git config".
GIT_LOCAL_CONFIG, also only documented as affecting "git config" and
not different from GIT_CONFIG in a useful way, is removed.

The ".dotest" temporary area "git am" and "git rebase" use is now moved
inside the $GIT_DIR, to avoid mistakes of adding it to the project by
accident.

An ancient merge strategy "stupid" has been removed.


Updates since v1.5.6
--------------------

(subsystems)

* git-p4 in contrib learned "allowSubmit" configuration to control on
  which branch to allow "submit" subcommand.

* git-gui learned to stage changes per-line.

(portability)

* Changes for MinGW port have been merged, thanks to Johannes Sixt and
  gangs.

* Sample hook scripts shipped in templates/ are now suffixed with
  *.sample.

* perl's in-place edit (-i) does not work well without backup files on Windows;
  some tests are rewritten to cope with this.

(documentation)

* Updated howto/update-hook-example

* Got rid of usage of "git-foo" from the tutorial and made typography
  more consistent.

* Disambiguating "--" between revs and paths is finally documented.

(performance, robustness, sanity etc.)

* index-pack used too much memory when dealing with a deep delta chain.
  This has been optimized.

* reduced excessive inlining to shrink size of the "git" binary.

* verify-pack checks the object CRC when using version 2 idx files.

* When an object is corrupt in a pack, the object became unusable even
  when the same object is available in a loose form,  We now try harder to
  fall back to these redundant objects when able.  In particular, "git
  repack -a -f" can be used to fix such a corruption as long as necessary
  objects are available.

* Performance of "git-blame -C -C" operation is vastly improved.

* git-clone does not create refs in loose form anymore (it behaves as
  if you immediately ran git-pack-refs after cloning).  This will help
  repositories with insanely large number of refs.

* core.fsyncobjectfiles configuration can be used to ensure that the loose
  objects created will be fsync'ed (this is only useful on filesystems
  that does not order data writes properly).

* "git commit-tree" plumbing can make Octopus with more than 16 parents.
  "git commit" has been capable of this for quite some time.

(usability, bells and whistles)

* even more documentation pages are now accessible via "man" and "git help".

* A new environment variable GIT_CEILING_DIRECTORIES can be used to stop
  the discovery process of the toplevel of working tree; this may be useful
  when you are working in a slow network disk and are outside any working tree,
  as bash-completion and "git help" may still need to run in these places.

* By default, stash entries never expire.  Set reflogexpire in [gc
  "refs/stash"] to a reasonable value to get traditional auto-expiration
  behaviour back

* Longstanding latency issue with bash completion script has been
  addressed.  This will need to be backmerged to 'maint' later.

* pager.<cmd> configuration variable can be used to enable/disable the
  default paging behaviour per command.

* "git-add -i" has a new action 'e/dit' to allow you edit the patch hunk
  manually.

* git-am records the original tip of the branch in ORIG_HEAD before it
  starts applying patches.

* git-apply can handle a patch that touches the same path more than once
  much better than before.

* git-apply can be told not to trust the line counts recorded in the input
  patch but recount, with the new --recount option.

* git-apply can be told to apply a patch to a path deeper than what the
  patch records with --directory option.

* git-archive can be told to omit certain paths from its output using
  export-ignore attributes.

* git-archive uses the zlib default compression level when creating
  zip archive.

* git-archive's command line options --exec and --remote can take their
  parameters as separate command line arguments, similar to other commands.
  IOW, both "--exec=path" and "--exec path" are now supported.

* With -v option, git-branch describes the remote tracking statistics
  similar to the way git-checkout reports by how many commits your branch
  is ahead/behind.

* git-branch's --contains option used to always require a commit parameter
  to limit the branches with; it now defaults to list branches that
  contains HEAD if this parameter is omitted.

* git-branch's --merged and --no-merged option used to always limit the
  branches relative to the HEAD, but they can now take an optional commit
  argument that is used in place of HEAD.

* git-bundle can read the revision arguments from the standard input.

* git-cherry-pick can replay a root commit now.

* git-clone can clone from a remote whose URL would be rewritten by
  configuration stored in $HOME/.gitconfig now.

* "git-clone --mirror" is a handy way to set up a bare mirror repository.

* git-cvsserver learned to respond to "cvs co -c".

* git-diff --check now checks leftover merge conflict markers.

* "git-diff -p" learned to grab a better hunk header lines in
  BibTex, Pascal/Delphi, and Ruby files and also pays attention to
  chapter and part boundary in TeX documents.

* When remote side used to have branch 'foo' and git-fetch finds that now
  it has branch 'foo/bar', it refuses to lose the existing remote tracking
  branch and its reflog.  The error message has been improved to suggest
  pruning the remote if the user wants to proceed and get the latest set
  of branches from the remote, including such 'foo/bar'.

* fast-export learned to export and import marks file; this can be used to
  interface with fast-import incrementally.

* fast-import and fast-export learned to export and import gitlinks.

* "gitk" left background process behind after being asked to dig very deep
  history and the user killed the UI; the process is killed when the UI goes
  away now.

* git-rebase records the original tip of branch in ORIG_HEAD before it is
  rewound.

* "git rerere" can be told to update the index with auto-reused resolution
  with rerere.autoupdate configuration variable.

* git-rev-parse learned $commit^! and $commit^@ notations used in "log"
  family.  These notations are available in gitk as well, because the gitk
  command internally uses rev-parse to interpret its arguments.

* git-rev-list learned --children option to show child commits it
  encountered during the traversal, instead of showing parent commits.

* git-send-mail can talk not just over SSL but over TLS now.

* git-shortlog honors custom output format specified with "--pretty=format:".

* "git-stash save" learned --keep-index option.  This lets you stash away the
  local changes and bring the changes staged in the index to your working
  tree for examination and testing.

* git-stash also learned branch subcommand to create a new branch out of
  stashed changes.

* git-status gives the remote tracking statistics similar to the way
  git-checkout reports by how many commits your branch is ahead/behind.

* "git-svn dcommit" is now aware of auto-props setting the subversion user
  has.

* You can tell "git status -u" to even more aggressively omit checking
  untracked files with --untracked-files=no.

* Original SHA-1 value for "update-ref -d" is optional now.

* Error codes from gitweb are made more descriptive where possible, rather
  than "403 forbidden" as we used to issue everywhere.

(internal)

* git-merge has been reimplemented in C.


Fixes since v1.5.6
------------------

All of the fixes in v1.5.6 maintenance series are included in
this release, unless otherwise noted.

 * git-clone ignored its -u option; the fix needs to be backported to
   'maint';

 * git-mv used to lose the distinction between changes that are staged
   and that are only in the working tree, by staging both in the index
   after moving such a path.

 * "git-rebase -i -p" rewrote the parents to wrong ones when amending
   (either edit or squash) was involved, and did not work correctly
   when fast forwarding.



----------------------------------------------------------------

Changes since v1.5.6 are as follows:

Abhijit Menon-Sen (13):
      git-gui: Move on to the next filename after staging/unstaging a change
      git-gui: Don't select the wrong file if the last listed file is staged.
      Implement "git stash branch <newbranch> <stash>"
      Add a test for "git stash branch"
      git-gui: Look for gitk in $PATH, not $LIBEXEC/git-core
      Clarify that "git log x.c y.h" lists commits that touch either file
      `git submodule add` now requires a <path>
      Make it clear that push can take multiple refspecs
      Make the DESCRIPTION match <x>... items in the SYNOPSIS
      Git.pm: localise $? in command_close_bidi_pipe()
      Fix hash slice syntax error
      Fix typo in perl/Git.pm
      Fix typos in INSTALL

Adam Brewster (2):
      Move read_revisions_from_stdin from builtin-rev-list.c to revision.c
      Teach git-bundle to read revision arguments from stdin like git-rev-list.

Alex Riesen (5):
      Fix use of "perl -i" on Windows
      git-clone: remove leftover debugging fprintf().
      Allow pager of diff command be enabled/disabled
      Make use of stat.ctime configurable
      Fix t3700 on filesystems which do not support question marks in names

Alexander Gavrilov (18):
      Fix quadratic performance in rewrite_one.
      Avoid rescanning unchanged entries in search for copies.
      Do not try to detect move/copy for entries below threshold.
      Fix pre-commit hooks under MinGW/MSYS
      Add options to control the search for copies in blame.
      Kill the blame back-end on window close.
      Add a menu item to invoke full copy detection in blame.
      Support gitlinks in fast-import.
      git-gui: Fix the Remote menu separator.
      git-gui: Preserve scroll position on reshow_diff.
      Support copy and rename detection in fast-export.
      gitk: Kill back-end processes on window close
      gitk: Arrange to kill diff-files & diff-index on quit
      gitk: On Windows, use a Cygwin-specific flag for kill
      gitk: Fixed broken exception handling in diff
      gitk: Fixed automatic row selection during load
      gitk: Fallback to selecting the head commit upon load
      gitk: Allow safely calling nukefile from a run queue handler

Anand Kumria (14):
      Create a specific version of the read_pipe_lines command for p4 invocations
      Utilise the new 'p4_read_pipe_lines' command
      Have a command that specifically invokes 'p4' (via system)
      Utilise the new 'p4_system' function.
      Add a single command that will be used to construct the 'p4' command
      If we are in verbose mode, output what we are about to run (or return)
      Switch to using 'p4_build_cmd'
      If the user has configured various parameters, use them.
      Consistently use 'git-p4' for the configuration entries
      Move git-p4.syncFromOrigin into a configuration parameters section
      Put some documentation in about the parameters that have been added
      Put in the two other configuration elements found in the source
      Add p4 read_pipe and write_pipe wrappers
      Utilise our new p4_read_pipe and p4_write_pipe wrappers

Anders Melchiorsen (5):
      Documentation: fix diff.external example
      Advertise the ability to abort a commit
      Documentation: fix diff.external example
      Flush output in start_async
      Add output flushing before fork()

Avery Pennarun (4):
      git-svn: avoid filling up the disk with temp files.
      Reword "your branch has diverged..." lines to reduce line length
      Teach "git diff -p" Pascal/Delphi funcname pattern
      git-svn: Abort with an error if 'fetch' parameter is invalid.

Björn Steinbrink (3):
      git cat-file: Fix memory leak in batch mode
      index-pack.c: correctly initialize appended objects
      rev-parse: Add support for the ^! and ^@ syntax

Brad King (1):
      git-svn: teach dcommit about svn auto-props

Brandon Casey (17):
      git-merge.sh: fix typo in usage message: sucesses --> succeeds
      t7502-commit.sh: test_must_fail doesn't work with inline environment variables
      t7701-repack-unpack-unreachable.sh: check timestamp of unpacked objects
      t/: Replace diff [-u|-U0] with test_cmp to allow compilation with old diff
      t4116-apply-reverse.sh: use $TAR rather than tar
      t3200,t7201: replace '!' with test_must_fail
      t7502-commit.sh: rearrange test to make more portable
      t/t4202-log.sh: add newline at end of file
      Teach fsck and prune about the new location of temporary objects
      perl/Makefile: update NO_PERL_MAKEMAKER section
      t/t4202-log.sh: add newline at end of file
      Teach fsck and prune that tmp_obj_ file names may not be 14 bytes long
      perl/Makefile: handle paths with spaces in the NO_PERL_MAKEMAKER section
      Makefile: set SHELL to value of SHELL_PATH
      Makefile: add a target which will abort compilation with ancient shells
      test-parse-options: use appropriate cast in length_callback
      t5304-prune: adjust file mtime based on system time rather than file mtime

Brian Gernhardt (5):
      Fix t4017-diff-retval for white-space from wc
      Add test results directory to t/.gitignore
      Documentation: Point to gitcli(7) from git(1)
      Documentation: mention ORIG_HEAD in am, merge, and rebase
      Documentation: Remove mentions of git-svnimport.

Brian Hetro (5):
      builtin-log.c: Use 'git_config_string' to get 'format.subjectprefix' and 'format.suffix'
      convert.c: Use 'git_config_string' to get 'smudge' and 'clean'
      diff.c: Use 'git_config_string' to get 'diff.external'
      http.c: Use 'git_config_string' to clean up SSL config.
      builtin-commit.c: Use 'git_config_string' to get 'commit.template'

Cesar Eduardo Barros (2):
      Documentation/git-submodule.txt: fix doubled word
      Documentation/git-rev-parse.txt: update for new git-describe output format

Christian Couder (5):
      help: check early if we have a command, if not try a documentation topic
      Fix "config_error_nonbool" used with value instead of key
      Fix "config_error_nonbool" used with value instead of key
      merge-base: die with an error message if not passed a commit ref
      documentation: user-manual: update "using-bisect" section

Christian Stimming (2):
      git-gui: Update German translation
      gitk: Updated German translation

Ciaran McCreesh (2):
      Make git-add -i accept ranges like 7-
      Make git-add -i accept ranges like 7-

Cristian Peraferrer (1):
      Print errno upon failure to open the COMMIT_EDITMSG file

Dan McGee (1):
      completion: add --graph to log command completion

Daniel Barkalow (2):
      Only use GIT_CONFIG in "git config", not other programs
      In perforce, RCS keywords are case-sensitive

David D. Kilzer (1):
      Fix race condition in t9119-git-svn-info.sh

David Reiss (4):
      Implement normalize_absolute_path
      Fold test-absolute-path into test-path-utils
      Add support for GIT_CEILING_DIRECTORIES
      Eliminate an unnecessary chdir("..")

Dmitry Kakurin (1):
      Fixed text file auto-detection: treat EOF character 032 at the end of file as printable

Dmitry Potapov (9):
      fix update-hook-example to work with packed tag references
      update-hook-example: optionally allow non-fast-forward
      shrink git-shell by avoiding redundant dependencies
      completion.bash: add 'skip' and 'run' to git-bisect
      Fix buffer overflow in git-grep
      Fix buffer overflow in git diff
      Fix buffer overflow in prepare_attr_stack
      git-svn: fix git svn info to work without arguments
      correct access right for git-svn-dcommit test

Don Zickus (1):
      git-apply: handle a patch that touches the same path more than once better

Eric Blake (1):
      Makefile: building git in cygwin 1.7.0

Eric Hanchrow (2):
      user-manual: typo and grammar fixes
      Documentation: fix broken "linkgit" links

Eric Raible (4):
      Documentation: tweak use case in "git stash save --keep-index"
      completion: add branch options --contains --merged --no-merged
      Teach lookup_prog not to select directories
      bash completion: 'git apply' should use 'fix' not 'strip'

Eric Wong (6):
      git-svn: don't sanitize remote names in config
      t/lib-git-svn: fix SVN_HTTPD tests to work with "trash directory"
      git-svn: properly set path for "info" command
      t9119: conditionally re-enable test depending on svn(1) version
      git-svn: add ability to specify --commit-url for dcommit
      git-svn: wrap long lines in a few places

Fabian Emmes (2):
      Testsuite: Unset CVS_SERVER
      testsuite for cvs co -c

Francis Moreau (1):
      git-bisect: fix wrong usage of read(1)

Frederik Schwarzer (1):
      git-svn: typofix

Gerrit Pape (1):
      git-svn.perl: workaround assertions in svn library 1.5.0

Giuseppe Bilotta (2):
      diff: add ruby funcname pattern
      diff: chapter and part in funcname for tex

Gustaf Hendeby (2):
      gitattributes: Document built in hunk header patterns
      Teach git diff about BibTeX head hunk patterns

Ian Katz (1):
      tutorial: use prompt with user names in example, to clarify who is doing what

Ivan Stankovic (1):
      Documentation: fix invalid reference to 'mybranch' in user manual

Jakub Narebski (5):
      gitweb: Separate filling list of projects info
      gitweb: Separate generating 'sort by' table header
      t/README: Add 'Skipping Tests' section below 'Running Tests'
      gitweb: Describe projects_index format in more detail
      gitweb: More about how gitweb gets 'owner' of repository

Jan Krüger (2):
      Documentation: fix formatting in git-svn
      git-svn: make rebuild respect rewriteRoot option

Jeff King (18):
      fix whitespace violations in test scripts
      mask necessary whitespace policy violations in test scripts
      avoid whitespace on empty line in automatic usage message
      avoid trailing whitespace in zero-change diffstat lines
      enable whitespace checking of test scripts
      clone: create intermediate directories of destination repo
      for-each-ref: implement missing tag values
      clone: create intermediate directories of destination repo
      improve for-each-ref test script
      fetch: report local storage errors in status table
      doc/rev-parse: clarify reflog vs --until for specifying revisions
      fetch: give a hint to the user when local refs fail to update
      Allow per-command pager config
      make deleting a missing ref more quiet
      avoid null SHA1 in oldest reflog
      init: handle empty "template" parameter
      Compact commit template message
      init: handle empty "template" parameter

Jim Meyering (1):
      git-cvsimport.perl: Print "UNKNOWN LINE..." on stderr, not stdout.

Jing Xue (1):
      Add 'git-p4.allowSubmit' to git-p4

Jochen Voss (1):
      avoid off-by-one error in run_upload_archive

Joey Hess (1):
      fix git config example syntax

Johan Herland (4):
      Incorporate fetched packs in future object traversal
      Move pack_refs() and friends into libgit
      Prepare testsuite for a "git clone" that packs refs
      Teach "git clone" to pack refs

Johannes Schindelin (31):
      Windows: always chmod(, 0666) before unlink().
      clone: respect url.insteadOf setting in global configs
      commit-tree: lift completely arbitrary limit of 16 parents
      Allow git-apply to recount the lines in a hunk (AKA recountdiff)
      clone: respect the settings in $HOME/.gitconfig and /etc/gitconfig
      Add another fast-import example, this time for .zip files
      Teach "git apply" to prepend a prefix with "--root=<root>"
      git fetch-pack: do not complain about "no common commits" in an empty repo
      git daemon: avoid calling syslog() from a signal handler
      run_command(): respect GIT_TRACE
      Allow cherry-picking root commits
      Convert CR/LF to LF in tag signatures
      Add pretty format %aN which gives the author name, respecting .mailmap
      Move MERGE_RR from .git/rr-cache/ into .git/
      git-gui: MERGE_RR lives in .git/ directly with newer Git versions
      shortlog: support --pretty=format: option
      Rename ".dotest/" to ".git/rebase" and ".dotest-merge" to "rebase-merge"
      git fetch-pack: do not complain about "no common commits" in an empty repo
      Rename .git/rebase to .git/rebase-apply
      Rename path_list to string_list
      Fix two leftovers from path_list->string_list
      Ignore dirty submodule states in "git pull --rebase"
      Add test to show that show-branch misses out the 8th column
      sort_in_topological_order(): avoid setting a commit flag
      builtin-commit: Two trivial style-cleanups
      git daemon: avoid waking up too often
      Avoid chdir() in list_commands_in_dir()
      sort_in_topological_order(): avoid setting a commit flag
      clone: Add an option to set up a mirror
      clone --bare: Add ".git" suffix to the directory name to clone into
      clone --mirror: avoid storing repeated tags

Johannes Sixt (52):
      Add compat/regex.[ch] and compat/fnmatch.[ch].
      Compile some programs only conditionally.
      Add target architecture MinGW.
      Windows: Use the Windows style PATH separator ';'.
      setup.c: Prepare for Windows directory separators.
      Windows: Treat Windows style path names.
      Windows: Handle absolute paths in safe_create_leading_directories().
      Windows: Strip ".exe" from the program name.
      Windows: Implement a wrapper of the open() function.
      Windows: A minimal implemention of getpwuid().
      Windows: Work around misbehaved rename().
      Make my_mktime() public and rename it to tm_to_time_t()
      Windows: Implement gettimeofday().
      Windows: Fix PRIuMAX definition.
      Windows: Implement setitimer() and sigaction().
      Windows: Wrap execve so that shell scripts can be invoked.
      Windows: A pipe() replacement whose ends are not inherited to children.
      Windows: Implement start_command().
      Windows: A rudimentary poll() emulation.
      Windows: Disambiguate DOS style paths from SSH URLs.
      Windows: Implement asynchronous functions as threads.
      Windows: Work around incompatible sort and find.
      Windows: Implement wrappers for gethostbyname(), socket(), and connect().
      Windows: Implement a custom spawnve().
      Windows: Add a custom implementation for utime().
      Windows: Use a customized struct stat that also has the st_blocks member.
      Turn builtin_exec_path into a function.
      Windows: Compute the fallback for exec_path from the program invocation.
      Windows: Use a relative default template_dir and ETC_GITCONFIG
      When installing, be prepared that template_dir may be relative.
      Windows: Make the pager work.
      Windows: Work around an oddity when a pipe with no reader is written to.
      Windows: Make 'git help -a' work.
      Windows: TMP and TEMP environment variables specify a temporary directory.
      git-gui: Implement "Stage/Unstage Line"
      t4127-apply-same-fn: Avoid sed -i
      Provide fallback definitions of PRIu32 and PRIx32
      t7600-merge: Use test_expect_failure to test option parsing
      builtin-clone: rewrite guess_dir_name()
      rebase -i: When an 'edit' stops, mention the commit
      Makefile: Do not install a copy of 'git' in $(gitexecdir)
      Makefile: Normalize $(bindir) and $(gitexecdir) before comparing
      Record the command invocation path early
      Fix relative built-in paths to be relative to the command invocation
      Allow the built-in exec path to be relative to the command invocation path
      Allow add_path() to add non-existent directories to the path
      Windows: Make $(gitexecdir) relative
      Windows: Make sure argv[0] has a path
      Windows: Do not compile git-shell
      git-gui: Fix "Stage/Unstage Line" with one line of context.
      git-gui: "Stage Line": Treat independent changes in adjacent lines better
      git-gui: Adapt discovery of oguilib to execdir 'libexec/git-core'

Jon Jensen (1):
      Fix reference to Everyday Git, which is an HTML document and not a man page.

Jonathan Nieder (29):
      Documentation: don't assume git-sh-setup and git-parse-remote are in PATH
      Documentation: fix links to tutorials and other new manual pages
      whitespace fix in Documentation/git-repack.txt
      Documentation: complicate example of "man git-command"
      git-daemon(1): don't assume git-daemon is in /usr/bin
      Documentation: prepare to be consistent about "git-" versus "git "
      Documentation: be consistent about "git-" versus "git "
      Documentation formatting and cleanup
      git-format-patch(1): fix stray \ in output
      Documentation: fix gitlinks
      manpages: fix bogus whitespace
      git(1): add comma
      git-commit(1): depersonalize description
      Documentation: rewrap to prepare for "git-" vs "git " change
      Documentation: more "git-" versus "git " changes
      gitdiffcore(7): fix awkward wording
      manpages: italicize command names in synopses
      manpages: italicize command names
      manpages: italicize git command names (which were in teletype font)
      manpages: italicize gitk's name (where it was in teletype font)
      manpages: italicize nongit command names (if they are in teletype font)
      manpages: italicize git subcommand names (which were in teletype font)
      manpages: use teletype font for sample command lines
      fix usage string for git grep
      git-diff(1): "--c" -> "--cc" typo fix
      document that git-tag can tag more than heads
      t6030 (bisect): work around Mac OS X "ls"
      git-diff(1): "--c" -> "--cc" typo fix
      Documentation: user-manual: "git commit -a" doesn't motivate .gitignore

João Abecasis (1):
      git-svn: find-rev and rebase for SVN::Mirror repositories

Junio C Hamano (131):
      revision traversal: --children option
      rev-list --children
      builtin-blame.c: move prepare_final() into a separate function.
      builtin-blame.c: allow more than 16 parents
      git-blame --reverse
      diff -c/--cc: do not include uninteresting deletion before leading context
      rerere: rerere_created_at() and has_resolution() abstraction
      git-rerere: detect unparsable conflicts
      rerere: remove dubious "tail_optimization"
      t4200: fix rerere test
      rerere.autoupdate
      git-shell: accept "git foo" form
      Prepare execv_git_cmd() for removal of builtins from the filesystem
      pre-rebase hook update
      Ship sample hooks with .sample suffix
      Keep some git-* programs in $(bindir)
      GIT 1.5.6.1
      Allow "git-reset path" when unambiguous
      Start draft release notes for 1.6.0
      diff --check: do not discard error status upon seeing a good line
      git-shell: accept "git foo" form
      GIT 1.5.4.6
      GIT 1.5.5.5
      diff --check: explain why we do not care whether old side is binary
      check_and_emit_line(): rename and refactor
      checkdiff: pass diff_options to the callback
      Teach "diff --check" about new blank lines at end
      diff --check: detect leftover conflict markers
      Update sample pre-commit hook to use "diff --check"
      Document the double-dash "rev -- path" disambiguator
      Per-ref reflog expiry configuration
      Make default expiration period of reflog used for stash infinite
      t9700: skip when Test::More is not available
      Update draft release notes for 1.6.0
      Introduce get_merge_bases_many()
      Introduce reduce_heads()
      Start draft release notes for 1.5.6.2
      Update draft release notes for 1.6.0
      apply --root: thinkofix.
      Refactor "tracking statistics" code used by "git checkout"
      git-status: show the remote tracking statistics
      git-branch -v: show the remote tracking statistics
      fast-export --export-marks: fix off by one error
      stat_tracking_info(): clear object flags used during counting
      Work around gcc warnings from curl headers
      Fix executable bits in t/ scripts
      GIT 1.5.6.2
      attribute documentation: keep EXAMPLE at end
      clone -q: honor "quiet" option over native transports.
      branch -r -v: do not spit out garbage
      git-apply --directory: make --root more similar to GNU diff
      mailinfo: feed the correct line length to decode_transfer_encoding()
      Update draft release notes for 1.6.0
      Teach "am" and "rebase" to mark the original position with ORIG_HEAD
      Tone down warning about GNU Interactive Tools
      Documentation: update sections on naming revisions and revision ranges
      Start preparing release notes for 1.5.6.3
      branch --contains: default to HEAD
      branch --merged/--no-merged: allow specifying arbitrary commit
      apply: fix copy/rename breakage
      Teach merge.log to "git-merge" again
      t0004: fix timing bug
      GIT 1.5.6.3
      Update draft release notes for 1.6.0
      reduce_heads(): protect from duplicate input
      git-rebase: report checkout failure
      tutorial: clarify "pull" is "fetch + merge"
      Update draft release notes to 1.6.0
      t/aggregate-results: whitespace fix
      Start preparing 1.5.6.4 release notes
      Update draft release notes for 1.6.0
      read-cache.c: typofix
      mailinfo: off-by-one fix for [PATCH (foobar)] removal from Subject: line
      rerere.autoupdate: change the message when autoupdate is in effect
      builtin-remote.c: fix earlier "skip_prefix()" conversion
      rev-list: honor --quiet option
      http-fetch: do not SEGV after fetching a bad pack idx file
      GIT 1.5.6.4
      t9001 (send-email): Do not use hardcoded /bin/sh in test
      .mailmap update
      Getting closer to 1.6.0-rc0
      builtin-add.c: restructure the code for maintainability
      git-add --all: add all files
      git-add --all: tests
      git-add --all: documentation
      refresh-index: fix bitmask assignment
      Link shell with compat layer functions
      Move read_in_full() and write_in_full() to wrapper.c
      "needs update" considered harmful
      Update my e-mail address
      Revert "make git-status use a pager"
      tests: do not rely on external "patch"
      stash save: fix parameter handling
      builtin-branch.c: remove unused code in append_ref() callback function
      builtin-branch.c: optimize --merged and --no-merged
      Documentation: clarify diff --cc
      ignore non-existent refs in dwim_log()
      tests: propagate $(TAR) down from the toplevel Makefile
      Makefile: fix shell quoting
      Documentation: clarify how to disable elements in core.whitespace
      make sure parsed wildcard refspec ends with slash
      GIT 1.6.0-rc1
      Allow building without any git installed
      Allow installing in the traditional way
      ls-tree documentation: enhance notes on subdirectory and pathspec behaviour
      Documentation: clarify what is shown in "git-ls-files -s" output
      t7001: fix "git mv" test
      Teach gitlinks to ie_modified() and ce_modified_check_fs()
      Fix merge name generation in "merge in C"
      Fix test-parse-options "integer" test
      Teach --find-copies-harder to "git blame"
      make sure parsed wildcard refspec ends with slash
      Documentation: clarify diff --cc
      Update my e-mail address
      Start 1.5.6.5 RelNotes to describe accumulated fixes
      builtin-name-rev.c: split deeply nested part from the main function
      RelNotes 1.5.6.5 updates
      fix diff-tree --stdin documentation
      Files given on the command line are relative to $cwd
      GIT 1.5.6.5
      GIT 1.6.0-rc2
      asciidoc markup fixes
      GIT-VERSION-GEN: mark the version 'dirty' only if there are modified files
      mailinfo: fix MIME multi-part message boundary handling
      Update draft RelNotes for 1.6.0
      Fix deleting reflog entries from HEAD reflog
      Re-fix rev-list-options documentation
      diff --check: do not unconditionally complain about trailing empty lines
      Do not talk about "diff" in rev-list documentation.
      GIT 1.6.0-rc3
      GIT 1.6.0

Karl Hasselström (2):
      Clean up builtin-update-ref's option parsing
      Make old sha1 optional with git update-ref -d

Kevin Ballard (3):
      git-send-email: Accept fifos as well as files
      format-patch: Produce better output with --inline or --attach
      Fix escaping of glob special characters in pathspecs

Lars Hjemli (3):
      builtin-branch: remove duplicated code
      builtin-branch: factor out merge_filter matching
      builtin-branch: fix -v for --[no-]merged

Lars Noschinski (4):
      git-cvsserver: fix call to nonexistant cleanupWorkDir()
      cvsserver: Add support for packed refs
      cvsserver: Add cvs co -c support
      cvsserver: Add testsuite for packed refs

Lea Wiemann (6):
      test-lib.sh: add --long-tests option
      t/test-lib.sh: add test_external and test_external_without_stderr
      Git.pm: add test suite
      gitweb: standarize HTTP status codes
      test-lib.sh: show git init output when in verbose mode
      GIT-VERSION-GEN: do not fail if a 'HEAD' file exists in the working copy

Lee Marlow (15):
      bash completion: Add long options for 'git rm'
      bash completion: Add completion for 'git help'
      bash completion: remove unused function _git_diff_tree
      bash completion: Add more long options for 'git log'
      bash completion: Add completion for 'git grep'
      bash completion: Add completion for 'git clone'
      bash completion: Add completion for 'git clean'
      bash completion: Add completion for 'git init'
      bash completion: Add completion for 'git revert'
      bash completion: More completions for 'git stash'
      bash completion: Add completion for 'git archive'
      bash completion: Add completion for 'git ls-files'
      bash completion: Add completion for 'git mv'
      bash completion: Add completion for 'git mergetool'
      bash completion: Add '--merge' long option for 'git log'

Linus Torvalds (8):
      Split up default "core" config parsing into helper routine
      Split up default "user" config parsing into helper routine
      Split up default "i18n" and "branch" config parsing into helper routines
      Add config option to enable 'fsync()' of object files
      racy-git: an empty blob has a fixed object name
      Make git_dir a path relative to work_tree in setup_work_tree()
      Shrink the git binary a bit by avoiding unnecessary inline functions
      diff.renamelimit is a basic diff configuration

Lukas Sandström (6):
      Add a helper script to send patches with Mozilla Thunderbird
      git-mailinfo: document the -n option
      Make some strbuf_*() struct strbuf arguments const.
      Add some useful functions for strbuf manipulation.
      git-mailinfo: Fix getting the subject from the in-body [PATCH] line
      git-mailinfo: use strbuf's instead of fixed buffers

Marcus Griep (7):
      Fix multi-glob assertion in git-svn
      git-svn: Allow deep branch names by supporting multi-globs
      Git.pm: Add faculties to allow temp files to be cached
      git-svn: Make it incrementally faster by minimizing temp files
      git-svn: Reduce temp file usage when dealing with non-links
      bash-completion: Add non-command git help files to bash-completion
      Git.pm: Make File::Spec and File::Temp requirement lazy

Marius Storm-Olsen (4):
      Add an optional <mode> argument to commit/status -u|--untracked-files option
      Add argument 'no' commit/status option -u|--untracked-files
      Add configuration option for default untracked files mode
      Windows: Add a new lstat and fstat implementation based on Win32 API.

Mark Levedahl (4):
      install-doc-quick - use git --exec-path to find git-sh-setup
      git-submodule - Fix bugs in adding an existing repo as a module
      git-submodule - make "submodule add" more strict, and document it
      git-submodule - register submodule URL if adding in place

Matt McCutchen (1):
      git format-patch documentation: clarify what --cover-letter does

Matthew Ogilvie (1):
      Documentation cvs: Clarify when a bare repository is needed

Michele Ballabio (6):
      parse-options.c: fix documentation syntax of optional arguments
      t9301-fast-export.sh: Remove debug line
      builtin-merge.c: Fix option parsing
      builtin-push.c: Cleanup - use OPT_BIT() and remove some variables
      git-gui: update po/it.po
      git-gui: add a part about format strings in po/README

Mikael Magnusson (3):
      Fix grammar in git-rev-parse(1).
      git-gui: Update swedish translation.
      gitk: Update swedish translation.

Mike Hommey (4):
      Catch failures from t5540-http-push
      Fix http-push test
      Skip t5540-http-push test when USE_CURL_MULTI is undefined
      Avoid apache complaining about lack of server's FQDN

Mike Pape (1):
      We need to check for msys as well as Windows in add--interactive.

Mike Ralphson (2):
      Documentation: typos / spelling fixes in older RelNotes
      Documentation: typos / spelling fixes

Miklos Vajna (31):
      A simple script to parse the results from the testcases
      Move split_cmdline() to alias.c
      Move commit_list_count() to commit.c
      Move parse-options's skip_prefix() to git-compat-util.h
      Add new test to ensure git-merge handles pull.twohead and pull.octopus
      Move read_cache_unmerged() to read-cache.c
      git-fmt-merge-msg: make it usable from other builtins
      Introduce get_octopus_merge_bases() in commit.c
      Add new test to ensure git-merge handles more than 25 refs.
      Add new test case to ensure git-merge reduces octopus parents when possible
      Retire 'stupid' merge strategy
      INSTALL: Update section about git-frotz form.
      hg-to-git: avoid raising a string exception
      hg-to-git: abort if the project directory is not a hg repo
      hg-to-git: rewrite "git-frotz" to "git frotz"
      hg-to-git: use git init instead of git init-db
      Add new test case to ensure git-merge prepends the custom merge message
      git-commit-tree: make it usable from other builtins
      Fix t7601-merge-pull-config.sh on AIX
      Build in merge
      t0001-init.sh: change confusing directory name
      t1007-hash-object.sh: use quotes for the test description
      git-bisect: use dash-less form on git bisect log
      make remove-dashes: apply to scripts and programs as well, not just to builtins
      t6021: add a new test for git-merge-resolve
      Add a new test for git-merge-resolve
      Teach 'git merge' that some merge strategies no longer exist
      builtin-merge: give a proper error message for invalid strategies in config
      t7601: extend the 'merge picks up the best result' test
      Documentation: document the pager.* configuration setting
      t9300: replace '!' with test_must_fail

Nanako Shiraishi (8):
      environment.c: remove unused function
      config.c: make git_env_bool() static
      gitcli: Document meaning of --cached and --index
      cache-tree.c: make cache_tree_find() static
      builtin-describe.c: make a global variable "pattern" static
      parse-options.c: make check_typos() static
      git am --abort
      git-gui: update Japanese translation

Nguyễn Thái Ngọc Duy (2):
      Move all dashed-form commands to libexecdir
      Fix typo in comments of longest_ancestor_length()

Nicolas Pitre (11):
      call init_pack_revindex() lazily
      implement some resilience against pack corruptions
      test case for pack resilience against corruptions
      refactor pack structure allocation
      optimize verify-pack a bit
      move show_pack_info() where it belongs
      verify-pack: check packed object CRC when using index version 2
      verify-pack: test for detection of index v2 object CRC mismatch
      repack.usedeltabaseoffset config option now defaults to "true"
      pack.indexversion config option now defaults to 2
      restore legacy behavior for read_sha1_file()

Nikolaj Schumacher (1):
      Don't cut off last character of commit descriptions.

Nikolaus Schulz (1):
      Documentation: be precise about which date --pretty uses

Olivier Marin (9):
      Documentation: remove {show,whatchanged}.difftree config options
      show_stats(): fix stats width calculation
      builtin-rerere: more carefully find conflict markers
      builtin-rm: fix index lock file path
      git-am: remove dash from help message
      parse-options: fix segmentation fault when a required value is missing
      git am --skip: clean the index while preserving local changes
      update test case to protect am --skip behaviour
      builtin-verify-tag: fix -v option parsing

P. Christeas (1):
      svnimport: newer libsvn wants us to ask for the root with "", not "/"

Patrick Higgins (2):
      Remove the use of '--' in merge program invocation
      Workaround for AIX mkstemp()

Pavel Roskin (1):
      t9600: allow testing with cvsps 2.2, including beta versions

Peter Harris (1):
      Add ANSI control code emulation for the Windows console

Peter Valdemar Mørch (1):
      send-email: find body-encoding correctly

Petr Baudis (14):
      Git.pm: Add remote_refs() git-ls-remote frontend
      Fix backwards-incompatible handling of core.sharedRepository
      Documentation/git-cherry-pick.txt et al.: Fix misleading -n description
      Documentation/git-submodule.txt: Add Description section
      Documentation/RelNotes-1.6.0.txt: Expand on the incompatible packfiles
      Documentation/git-submodule.txt: Further clarify the description
      Documentation: How to ignore local changes in tracked files
      Documentation/git-merge.txt: Partial rewrite of How Merge Works
      git-filter-branch.sh: Allow running in bare repositories
      Documentation/git-filter-branch: teach "rm" instead of "update-index --remove"
      git-mv: Remove dead code branch
      git-mv: Keep moved index entries inact
      Fail properly when cloning from invalid HTTP URL
      Adjust for the new way of enabling the default post-update hook

Philippe Bruhat (1):
      mailinfo: better parse email adresses containg parentheses

Pierre Habouzit (19):
      parse-opt: have parse_options_{start,end}.
      parse-opt: Export a non NORETURN usage dumper.
      parse-opt: create parse_options_step.
      parse-opt: do not print errors on unknown options, return -2 intead.
      parse-opt: fake short strings for callers to believe in.
      parse-opt: add PARSE_OPT_KEEP_ARGV0 parser option.
      revisions: split handle_revision_opt() from setup_revisions()
      git-blame: migrate to incremental parse-option [1/2]
      git-blame: migrate to incremental parse-option [2/2]
      parse-options: add PARSE_OPT_LASTARG_DEFAULT flag
      git-blame: fix lapsus
      git-shortlog: migrate to parse-options partially.
      revisions: refactor handle_revision_opt into parse_revision_opt.
      builtin-merge: add missing structure initialization
      git-submodule: move ill placed shift.
      git-checkout: fix command line parsing.
      git-checkout: improve error messages, detect ambiguities.
      Allow "non-option" revision options in parse_option-enabled commands
      git-submodule: move ill placed shift.

Pieter de Bie (4):
      builtin-fast-export: Add importing and exporting of revision marks
      git-name-rev: allow --name-only in combination with --stdin
      builtin-rm: Add a --force flag
      reflog test: add more tests for 'reflog delete'

Rafael Garcia-Suarez (1):
      gitweb: remove git_blame and rename git_blame2 to git_blame

Ramsay Allan Jones (4):
      Fix some warnings (on cygwin) to allow -Werror
      t9113-*.sh: provide user feedback when test skipped
      t9100-git-svn-basic.sh: Fix determination of utf-8 locale
      git-request-pull: replace call to deprecated peek-remote

René Scharfe (16):
      Teach new attribute 'export-ignore' to git-archive
      archive: remove args member from struct archiver
      add context pointer to read_tree_recursive()
      archive: add baselen member to struct archiver_args
      archive: centralize archive entry writing
      archive: unify file attribute handling
      archive: remove extra arguments parsing code
      archive: make zip compression level independent from core git
      archive: remove unused headers
      archive: add write_archive()
      archive: move parameter parsing code to archive.c
      archive: define MAX_ARGS where it's needed
      archive: declare struct archiver where it's needed
      archive: allow --exec and --remote without equal sign
      archive: allow --exec and --remote without equal sign
      git-name-rev: don't use printf without format

Richard Quirk (1):
      git-gui: Fix accidental staged state toggle when clicking top pixel row

Robert Blum (1):
      git-p4: chdir now properly sets PWD environment variable in msysGit

Robert Shearman (1):
      git-send-email: Fix authenticating on some servers when using TLS.

SZEDER Gábor (5):
      stash: introduce 'stash save --keep-index' option
      bash: offer only paths after '--'
      checkout: mention '--' in the docs
      bash: offer only paths after '--' for 'git checkout'
      bash: remove redundant check for 'git stash apply' options

Shawn O. Pearce (18):
      Correct documentation for git-push --mirror
      Fix describe --tags --long so it does not segfault
      Remove unnecessary pack-*.keep file after successful git-clone
      Correct pack memory leak causing git gc to try to exceed ulimit
      bash completion: Improve responsiveness of git-log completion
      bash completion: Don't offer "a.." as a completion for "a."
      bash completion: Append space after file names have been completed
      bash completion: Resolve git show ref:path<tab> losing ref: portion
      bash completion: Remove dashed command completion support
      index-pack: Refactor base arguments of resolve_delta into a struct
      index-pack: Chain the struct base_data on the stack for traversal
      index-pack: Track the object_entry that creates each base_data
      index-pack: Honor core.deltaBaseCacheLimit when resolving deltas
      git-gui: Correct 'Visualize Branches' on Mac OS X to start gitk
      fsck: Don't require tmp_obj_ file names are 14 bytes in length
      git-gui: Fix gitk search in $PATH to work on Windows
      git-gui: Update git-gui.pot for 0.11 nearing release
      git-gui 0.11

Soeren Finster (1):
      git-gui: Exit shortcut in MacOSX repaired

Steffen Prohaska (11):
      Windows: Fix ntohl() related warnings about printf formatting
      compat/pread.c: Add a forward declaration to fix a warning
      Move code interpreting path relative to exec-dir to new function system_path()
      help.c: Add support for htmldir relative to git_exec_path()
      help (Windows): Display HTML in default browser using Windows' shell API
      Refactor, adding prepare_git_cmd(const char **argv)
      run-command (Windows): Run dashless "git <cmd>"
      git-gui: Correct installation of library to be $prefix/share
      git-gui (Windows): Switch to relative discovery of oguilib
      git-gui (Windows): Change wrapper to execdir 'libexec/git-core'
      Modify mingw_main() workaround to avoid link errors

Stephan Beyer (28):
      api-builtin.txt: update and fix typo
      t3404: stricter tests for git-rebase--interactive
      git-rebase.sh: Add check if rebase is in progress
      api-builtin.txt: update and fix typo
      api-parse-options.txt: Introduce documentation for parse options API
      Extend parse-options test suite
      rerere: Separate libgit and builtin functions
      git-am: Do not exit silently if committer is unset
      t/test-lib.sh: exit with small negagive int is ok with test_must_fail
      t/: Use "test_must_fail git" instead of "! git"
      Make usage strings dash-less
      git-am/git-mailsplit: correct synopsis for reading from stdin
      t3404: test two "preserve merges with -p" cases
      Make rebase--interactive use OPTIONS_SPEC
      rebase-i: keep old parents when preserving merges
      api-run-command.txt: typofix
      Link git-shell only to a subset of libgit.a
      git-am: Add colon before the subject that is printed out as being applied
      am --abort: Add to bash-completion and mention in git-rerere documentation
      Make non-static functions, that may be static, static
      Move launch_editor() from builtin-tag.c to editor.c
      editor.c: Libify launch_editor()
      git-am: Mention --abort in usage string part of OPTIONS_SPEC
      git-reset: Let -q hush "locally modified" messages
      builtin-revert.c: typofix
      git-am: ignore --binary option
      git-stash: improve synopsis in help and manual page
      Improve error output of git-rebase

Stephen R. van den Berg (1):
      git-daemon: SysV needs the signal handler reinstated.

Steve Haslam (3):
      Propagate -u/--upload-pack option of "git clone" to transport.
      Remove references to git-fetch-pack from "git clone" documentation.
      Propagate -u/--upload-pack option of "git clone" to transport.

Steven Grimm (1):
      Optimize sha1_object_info for loose objects, not concurrent repacks

SungHyun Nam (1):
      t/Makefile: use specified shell when running aggregation script

Sverre Hvammen Johansen (1):
      reduce_heads(): thinkofix

Sverre Rabbelier (2):
      Modify test-lib.sh to output stats to t/test-results/*
      Hook up the result aggregation in the test makefile.

Ted Percival (1):
      Don't use dash commands (git-foo) in tutorial-2

Teemu Likonen (3):
      bash: Add more option completions for 'git log'
      Add target "install-html" the the top level Makefile
      bash: Add long option completion for 'git send-email'

Thomas Rast (18):
      git-send-email: add support for TLS via Net::SMTP::SSL
      git-send-email: prevent undefined variable warnings if no encryption is set
      Fix 'git show' on signed tag of signed tag of commit
      git-add--interactive: replace hunk recounting with apply --recount
      git-add--interactive: remove hunk coalescing
      git-add--interactive: manual hunk editing mode
      git-send-email: Do not attempt to STARTTLS more than once
      Fix apply --recount handling of no-EOL line
      git-completion.bash: provide completion for 'show-branch'
      bash completion: Add long options for 'git describe'
      Documentation: commit-tree: remove 16 parents restriction
      Documentation: filter-branch: document how to filter all refs
      filter-branch: be more helpful when an annotated tag changes
      Documentation: rev-list-options: Fix -g paragraph formatting
      Documentation: rev-list-options: Fix a typo
      Documentation: rev-list-options: Rewrite simplification descriptions for clarity
      rebase -i -p: handle index and workdir correctly
      rebase -i -p: fix parent rewriting

Todd Zullinger (1):
      Replace uses of "git-var" with "git var"

A note from the maintainer

[Junio C Hamano]

Welcome to git community.

This message talks about how git.git is managed, and how you can work
with it.

* IRC and Mailing list

Many active members of development community hang around on #git
IRC channel on Freenode.  Its log is available at:

        http://colabti.org/irclogger/irclogger_log/git

The development however is primarily done on the git mailing list
(git@vger.kernel.org).  If you have patches, please send them to the
list, following Documentation/SubmittingPatches.

I usually try to read all patches posted to the list, and follow
almost all the discussions on the list, unless the topic is about an
obscure corner that I do not personally use.  But I am obviously not
perfect.  If you sent a patch that you did not hear from anybody for
three days, that is a very good indication that it was dropped on the
floor --- please do not hesitate to remind me.

The list archive is available at a few public sites as well:

        http://news.gmane.org/gmane.comp.version-control.git/
        http://marc.theaimsgroup.com/?l=git
        http://www.spinics.net/lists/git/

and some people seem to prefer to read it over NNTP:

        nntp://news.gmane.org/gmane.comp.version-control.git

When you point at a message in a mailing list archive, using
gmane is often the easiest to follow by readers, like this:

        http://thread.gmane.org/gmane.comp.version-control.git/27/focus=217

as it also allows people who subscribe to the mailing list as
gmane newsgroup to "jump to" the article.

* Repositories, branches and documentation.

My public git.git repository is at:

        git://git.kernel.org/pub/scm/git/git.git/

Immediately after I publish to the primary repository at kernel.org, I
also push into an alternate here:

        git://repo.or.cz/alt-git.git/

Impatient people might have better luck with the latter one.

Their gitweb interfaces are found at:

        http://git.kernel.org/?p=git/git.git
        http://repo.or.cz/w/alt-git.git

There are three branches in git.git repository that are not
about the source tree of git: "todo", "html" and "man".  The
first one was meant to contain TODO list for me, but I am not
good at maintaining such a list and it is not as often updated as
it could/should be.  It also contains some helper scripts I use
to maintain git.

The "html" and "man" are autogenerated documentation from the
tip of the "master" branch; the tip of "html" is extracted to be
visible at kernel.org at:

        http://www.kernel.org/pub/software/scm/git/docs/

The above URL is the top-level documentation page, and it has
links to documentation of older releases.

The script to maintain these two documentation branches are
found in "todo" branch as dodoc.sh, if you are interested.  It
is a good demonstration of how to use an update hook to automate
a task.

There are four branches in git.git repository that track the
source tree of git: "master", "maint", "next", and "pu".  I may
add more maintenance branches (e.g. "maint-1.5.4") if we have
hugely backward incompatible feature updates in the future to keep
an older release alive; I may not, but the distributed nature of
git means any volunteer can run a stable-tree like that herself.

The "master" branch is meant to contain what are very well
tested and ready to be used in a production setting.  There
could occasionally be minor breakages or brown paper bag bugs
but they are not expected to be anything major, and more
importantly quickly and trivially fixable.  Every now and
then, a "feature release" is cut from the tip of this branch and
they typically are named with three dotted decimal digits.  The
last such release was 1.6.0 done on Aug 17th 2008.  You
can expect that the tip of the "master" branch is always more
stable than any of the released versions.

Whenever a feature release is made, "maint" branch is forked off
from "master" at that point.  Obvious, safe and urgent fixes
after a feature release are applied to this branch and
maintenance releases are cut from it.  The maintenance releases
are named with four dotted decimal, named after the feature
release they are updates to; the last such release was 1.5.6.5.
New features never go to this branch.  This branch is also
merged into "master" to propagate the fixes forward.

A trivial and safe enhancement goes directly on top of "master".
A new development, either initiated by myself or more often by
somebody who found his or her own itch to scratch, does not
usually happen on "master", however.  Instead, a separate topic
branch is forked from the tip of "master", and it first is
tested in isolation; I may make minimum fixups at this point.
Usually there are a handful such topic branches that are running
ahead of "master" in git.git repository.  I do not publish the
tip of these branches in my public repository, however, partly
to keep the number of branches that downstream developers need
to worry about low, and primarily because I am lazy.

The quality of topic branches are judged primarily by the mailing list
discussions.  Some of them start out as "good idea but obviously is
broken in some areas (e.g. breaks the existing testsuite)" and then
with some more work (either by the original contributor's effort or
help from other people on the list) becomes "more or less done and can
now be tested by wider audience".  Luckily, most of them start out in
the latter, better shape.

The "next" branch is to merge and test topic branches in the
latter category.  In general, the branch always contains the tip
of "master".  It might not be quite rock-solid production ready,
but is expected to work more or less without major breakage.  I
usually use "next" version of git for my own work, so it cannot
be _that_ broken to prevent me from pushing the changes out.
The "next" branch is where new and exciting things take place.

The two branches "master" and "maint" are never rewound, and
"next" usually will not be either (this automatically means the
topics that have been merged into "next" are usually not
rebased, and you can find the tip of topic branches you are
interested in from the output of "git log next"). You should be
able to safely track them.

After a feature release is made from "master", however, "next"
will be rebuilt from the tip of "master" using the surviving
topics.  The commit that replaces the tip of the "next" will
have the identical tree, but it will have different ancestry
from the tip of "master".  An announcement will be made to warn
people about such a rebasing.

The "pu" (proposed updates) branch bundles all the remainder of
topic branches.  The "pu" branch, and topic branches that are
only in "pu", are subject to rebasing in general.  By the above
definition of how "next" works, you can tell that this branch
will contain quite experimental and obviously broken stuff.

When a topic that was in "pu" proves to be in testable shape, it
graduates to "next".  I do this with:

        git checkout next
        git merge that-topic-branch

Sometimes, an idea that looked promising turns out to be not so
good and the topic can be dropped from "pu" in such a case.

A topic that is in "next" is expected to be tweaked and fixed to
perfection before it is merged to "master" (that's why "master"
can be expected to stay very stable).  Similarly to the above, I
do it with this:

        git checkout master
        git merge that-topic-branch
        git branch -d that-topic-branch

Note that being in "next" is not a guarantee to appear in the
next release (being in "master" is such a guarantee, unless it
is later found seriously broken and reverted), or even in any
future release.  There even were cases that topics needed
reverting a few commits in them before graduating to "master",
or a topic that already was in "next" were entirely reverted
from "next" because fatal flaws were found in them later.

Starting from v1.5.0, "master" and "maint" have release notes
for the next release in Documentation/RelNotes-* files, so that
I do not have to run around summarizing what happened just
before the release.


* Other people's trees, trusted lieutenants and credits.

Documentation/SubmittingPatches outlines who your changes should
be sent to.  As described in contrib/README, I would delegate
fixes and enhancements in contrib/ area to primary contributors
of them.

Although the following are included in git.git repository, they
have their own authoritative repository and maintainers:

 - git-gui/ comes from Shawn Pearce's git-gui project:

        git://repo.or.cz/git-gui.git

 - gitk-git/ comes from Paul Mackerras's gitk project:

        git://git.kernel.org/pub/scm/gitk/gitk.git

I would like to thank everybody who helped to raise git into the
current shape.  Especially I would like to thank the git list
regulars whose help I have relied on and expect to continue
relying on heavily:

 - Linus on general design issues.

 - Linus, Shawn Pearce, Johannes Schindelin, Nicolas Pitre,
   René Scharfe and Jeff King on general implementation issues.

 - Shawn and Nicolas Pitre on pack issues.

 - Martin Langhoff and Frank Lichtenheld on cvsserver and cvsimport.

 - Paul Mackerras on gitk.

 - Eric Wong on git-svn.

 - Simon Hausmann on git-p4.

 - Jakub Narebski, Petr Baudis, and Luben Tuikov on gitweb.

 - J. Bruce Fields on documentaton issues.

 - Johannes Schindelin, Johannes Sixt and others for their effort
   to move things forward on the Windows front.  Most of the fruits
   from their porting efforts have been merged to the mainline git.git
   repository in 1.6.0 release.

 - People on non-Linux platforms for keeping their eyes on
   portability; especially, Randal Schwartz, Theodore Ts'o,
   Jason Riedy, Thomas Glanzmann, but countless others as well.

* This document

The latest copy of this document is found in git.git repository,
on 'todo' branch, as MaintNotes.

[ANNOUNCE] GIT 1.5.6

[Junio C Hamano]

The latest feature release GIT 1.5.6 is available at the usual
places:

  http://www.kernel.org/pub/software/scm/git/

  git-1.5.6.tar.{gz,bz2}			(tarball)
  git-htmldocs-1.5.6.tar.{gz,bz2}		(preformatted docs)
  git-manpages-1.5.6.tar.{gz,bz2}		(preformatted docs)
  RPMS/$arch/git-*-1.5.6-1.$arch.rpm	(RPM)

As promised, this cycle was short and the release is with only relatively
small impact changes.

----------------------------------------------------------------
GIT v1.5.6 Release Notes
========================

Updates since v1.5.5
--------------------

(subsystems)

* Comes with updated gitk and git-gui.

(portability)

* git will build on AIX better than before now.

* core.ignorecase configuration variable can be used to work better on
  filesystems that are not case sensitive.

* "git init" now autodetects the case sensitivity of the filesystem and
  sets core.ignorecase accordingly.

* cpio is no longer used; neither "curl" binary (libcurl is still used).

(documentation)

* Many freestanding documentation pages have been converted and made
  available to "git help" (aka "man git<something>") as section 7 of
  the manual pages. This means bookmarks to some HTML documentation
  files may need to be updated (eg "tutorial.html" became
  "gittutorial.html").

(performance)

* "git clone" was rewritten in C.  This will hopefully help cloning a
  repository with insane number of refs.

* "git rebase --onto $there $from $branch" used to switch to the tip of
  $branch only to immediately reset back to $from, smudging work tree
  files unnecessarily.  This has been optimized.

* Object creation codepath in "git-svn" has been optimized by enhancing
  plumbing commands git-cat-file and git-hash-object.

(usability, bells and whistles)

* "git add -p" (and the "patch" subcommand of "git add -i") can choose to
  apply (or not apply) mode changes independently from contents changes.

* "git bisect help" gives longer and more helpful usage information.

* "git bisect" does not use a special branch "bisect" anymore; instead, it
  does its work on a detached HEAD.

* "git branch" (and "git checkout -b") can be told to set up
  branch.<name>.rebase automatically, so that later you can say "git pull"
  and magically cause "git pull --rebase" to happen.

* "git branch --merged" and "git branch --no-merged" can be used to list
  branches that have already been merged (or not yet merged) to the
  current branch.

* "git cherry-pick" and "git revert" can add a sign-off.

* "git commit" mentions the author identity when you are committing
  somebody else's changes.

* "git diff/log --dirstat" output is consistent between binary and textual
  changes.

* "git filter-branch" rewrites signed tags by demoting them to annotated.

* "git format-patch --no-binary" can produce a patch that lack binary
  changes (i.e. cannot be used to propagate the whole changes) meant only
  for reviewing.

* "git init --bare" is a synonym for "git --bare init" now.

* "git gc --auto" honors a new pre-auto-gc hook to temporarily disable it.

* "git log --pretty=tformat:<custom format>" gives a LF after each entry,
  instead of giving a LF between each pair of entries which is how
  "git log --pretty=format:<custom format>" works.

* "git log" and friends learned the "--graph" option to show the ancestry
  graph at the left margin of the output.

* "git log" and friends can be told to use date format that is different
  from the default via 'log.date' configuration variable.

* "git send-email" now can send out messages outside a git repository.

* "git send-email --compose" was made aware of rfc2047 quoting.

* "git status" can optionally include output from "git submodule
  summary".

* "git svn" learned --add-author-from option to propagate the authorship
  by munging the commit log message.

* new object creation and looking up in "git svn" has been optimized.

* "gitweb" can read from a system-wide configuration file.

(internal)

* "git unpack-objects" and "git receive-pack" is now more strict about
  detecting breakage in the objects they receive over the wire.


Fixes since v1.5.5
------------------

All of the fixes in v1.5.5 maintenance series are included in
this release, unless otherwise noted.

And there are too numerous small fixes to otherwise note here ;-)


----------------------------------------------------------------

Changes since v1.5.5 are as follows:

A Large Angry SCM (1):
      git-repack: re-enable parsing of -n command line option

Adam Roben (11):
      Add tests for git cat-file
      git-cat-file: Small refactor of cmd_cat_file
      git-cat-file: Make option parsing a little more flexible
      git-cat-file: Add --batch-check option
      git-cat-file: Add --batch option
      Move git-hash-object tests from t5303 to t1007
      Add more tests for git hash-object
      git-hash-object: Add --stdin-paths option
      Git.pm: Add command_bidi_pipe and command_close_bidi_pipe
      Git.pm: Add hash_and_insert_object and cat_blob
      git-svn: Speed up fetch

Adam Simpkins (15):
      Remove dead code: show_log() sep argument and diff_options.msg_sep
      log: print log entry terminator even if the message is empty
      revision API: split parent rewriting and parent printing options
      Add history graph API
      log and rev-list: add --graph option
      graph API: eliminate unnecessary indentation
      graph API: fix graph mis-alignment after uninteresting commits
      graph API: don't print branch lines for uninteresting merge parents
      log --graph --left-right: show left/right information in place of '*'
      Fix output of "git log --graph --boundary"
      get_revision(): honor the topo_order flag for boundary commits
      graph API: improve display of merge commits
      graph API: avoid printing unnecessary padding before some octopus merges
      graph API: fix "git log --graph --first-parent"
      git log --graph: print '*' for all commits, including merges

Alberto Bertogli (1):
      builtin-apply: Show a more descriptive error on failure when opening a patch

Alejandro Mery (1):
      git-am: head -1 is obsolete and doesn't work on some new systems

Alex Riesen (13):
      Use "=" instead of "==" in condition as it is more portable
      Fix use after free() in builtin-fetch
      Use the modern syntax of git-diff-files in t2002-checkout-cache-u.sh
      Improve reporting of errors in config file routines
      Make the exit code of add_file_to_index actually useful
      Extend interface of add_files_to_cache to allow ignore indexing errors
      Add --ignore-errors to git-add to allow it to skip files with read errors
      Add a test for git-add --ignore-errors
      Add a config option to ignore errors for git-add
      Ensure that a test is run in the trash directory
      Fix t6031 on filesystems without working exec bit
      Fix t3701 if core.filemode disabled
      Fix t5516 on cygwin: it does not like double slashes at the beginning of a path

Anders Waldenborg (1):
      gitweb: Convert string to internal form before chopping in chop_str

Andy Parkins (1):
      post-receive-email: fix accidental removal of a trailing space in signature line

Ariel Badichi (2):
      copy.c: copy_fd - correctly report write errors
      archive.c: format_subst - fixed bogus argument to memchr

Ask Bjørn Hansen (2):
      gitweb setup instruction: rewrite HEAD and root as well
      send-email: Allow the envelope sender to be set via configuration

Avery Pennarun (5):
      git-svn: add documentation for --use-log-author option.
      git-svn: Add --add-author-from option.
      git-svn: add documentation for --add-author-from option.
      git-svn: don't append extra newlines at the end of commit messages.
      git-svn: test that extra blank lines aren't inserted in commit messages.

Bart Trojanowski (1):
      make git-status use a pager

Björn Steinbrink (2):
      Fix section about backdating tags in the git-tag docs
      name-rev: Fix segmentation fault when using --all

Boyd Lynn Gerber (2):
      progress.c: avoid use of dynamic-sized array
      Port to 12 other Platforms.

Brandon Casey (8):
      filter-branch.sh: support nearly proper tag name filtering
      git-clone.txt: Adjust note to --shared for new pruning behavior of git-gc
      compat/fopen.c: avoid clobbering the system defined fopen macro
      repack: modify behavior of -A option to leave unreferenced objects unpacked
      git-gc: always use -A when manually repacking
      builtin-gc.c: deprecate --prune, it now really has no effect
      builtin-clone.c: Need to closedir() in copy_or_link_directory()
      t/Makefile: "trash" directory was renamed recently

Bryan Donlan (10):
      git-rebase.sh: Fix --merge --abort failures when path contains whitespace
      config.c: Escape backslashes in section names properly
      git-send-email.perl: Handle shell metacharacters in $EDITOR properly
      test-lib.sh: Add a test_set_editor function to safely set $VISUAL
      Use test_set_editor in t9001-send-email.sh
      test-lib.sh: Fix some missing path quoting
      lib-git-svn.sh: Fix quoting issues with paths containing shell metacharacters
      Don't use the 'export NAME=value' in the test scripts.
      Fix tests breaking when checkout path contains shell metacharacters
      Rename the test trash directory to contain spaces.

Caio Marcelo de Oliveira Filho (1):
      git-format-patch: add --no-binary to omit binary changes in the patch.

Carlos Rica (2):
      Fix documentation syntax of optional arguments in short options.
      core-tutorial.txt: Fix showing the current behaviour.

Chris Frey (2):
      Documentation/git-prune.txt: document unpacked logic
      Documentation/git-repack.txt: document new -A behaviour

Chris Parsons (1):
      Updated status to show 'Not currently on any branch' in red

Chris Ridd (1):
      Improve sed portability

Christian Couder (32):
      bisect: add "git bisect help" subcommand to get a long usage string
      bisect: fix bad rev checking in "git bisect good"
      bisect: report bad rev better
      bisect: squelch "fatal: ref HEAD not a symref" misleading message
      git-bisect: make "start", "good" and "skip" succeed or fail atomically
      help: use man viewer path from "man.<tool>.path" config var
      documentation: help: add "man.<tool>.path" config variable
      help: use "man.<tool>.cmd" as custom man viewer command
      documentation: help: add info about "man.<tool>.cmd" config var
      documentation: web--browse: add a note about konqueror
      rev-parse: teach "--verify" to be quiet when using "-q" or "--quiet"
      rev-parse: fix --verify to error out when passed junk after a good rev
      Documentation: hooks: fix missing verb in pre-applypatch description
      Documentation: rename "hooks.txt" to "githooks.txt" and make it a man page
      Documentation: improve "add", "pull" and "format-patch" examples
      Documentation: bisect: add a few "git bisect run" examples
      bisect: print an error message when "git rev-list --bisect-vars" fails
      rev-parse: add test script for "--verify"
      rev-parse: fix using "--default" with "--verify"
      rev-parse --verify: do not output anything on error
      Documentation: rev-parse: add a few "--verify" and "--default" examples
      bisect: add test cases to check that "git bisect start" is atomic
      bisect: fix left over "BISECT_START" file when starting with junk rev
      bisect: trap critical errors in "bisect_start"
      bisect: use a detached HEAD to bisect
      Documentation: convert tutorials to man pages
      bisect: use "$GIT_DIR/BISECT_START" to check if we are bisecting
      Documentation: convert "glossary" and "core-tutorial" to man pages
      documentation: convert "diffcore" and "repository-layout" to man pages
      documentation: move git(7) to git(1)
      documentation: bisect: remove bits talking about a bisection branch
      Documentation: RelNotes-1.5.6: talk about renamed HTML files

Christian Engwer (1):
      git-svn fails in prop_walk if $self->{path} is not empty

Christian Stimming (3):
      git-gui: Update German translation
      gitk: Update German translation
      gitk: German translation again updated

Clemens Buchacher (2):
      Reset the signal being handled
      http-push: remove remote locks on exit signals

Clifford Caoile (2):
      Docs gitk: Explicitly mention the files that gitk uses (~/.gitk)
      git.el: Set process-environment instead of invoking env

Dan McGee (4):
      completion: allow 'git remote' subcommand completion
      completion: remove use of dashed git commands
      Allow cherry-pick (and revert) to add signoff line
      Remove 'header' from --signoff option description

Daniel Barkalow (14):
      Fix config key miscount in url.*.insteadOf
      Make walker.fetch_ref() take a struct ref.
      Make ls-remote http://... list HEAD, like for git://...
      Mark the list of refs to fetch as const
      Add a lockfile function to append to a file
      Add a library function to add an alternate to the alternates file
      Have a constant extern refspec for "--tags"
      Allow for having for_each_ref() list extra refs
      Add a function to set a non-default work tree
      Provide API access to init_db()
      Build in clone
      clone: fall back to copying if hardlinking fails
      Test that --reference actually suppresses fetching referenced objects
      Use nonrelative paths instead of absolute paths for cloned repositories

Dirk Suesserott (2):
      Documentation/git-request-pull: Fixed a typo ("send" -> "end")
      Documentation/git-mailsplit: Enhanced description of -o option

Dmitry Potapov (2):
      git-gc --prune is deprecated
      git-init: autodetect core.ignorecase

Dmitry V. Levin (1):
      builtin-fetch.c (store_updated_refs): Honor update_local_ref() return value

Dustin Sallings (3):
      Documentation/config.txt: Mention branch.<name>.rebase applies to "git pull"
      Allow tracking branches to set up rebase by default.
      Allow tracking branches to set up rebase by default.

Eric Wong (1):
      git-svn: fix cloning of HTTP URLs with '+' in their path

Flavio Poletti (1):
      git-instaweb: improve auto-discovery of httpd and call conventions.

Florian Ragwitz (1):
      filter-branch: Documentation fix.

Frank Lichtenheld (4):
      var: Don't require to be in a git repository.
      Git.pm: Don't require a repository instance for config
      Git.pm: Don't require repository instance for ident
      send-email: Don't require to be called in a repository

Fred Maranhão (1):
      fix typo in tutorial

Geoffrey Irving (1):
      doc: adding gitman.info and *.texi to .gitignore

Gerrit Pape (7):
      gitweb: fallback to system-wide config file if default config does not exist
      gitweb: fallback to system-wide config file (fixup)
      diff-options.txt: document the new "--dirstat" option
      gitk: Makefile/install: force permissions when installing files and dirs
      git-bisect.sh: don't accidentally override existing branch "bisect"
      Documentation/git-bundle.txt: fix synopsis
      commit --interactive: properly update the index before commiting

Govind Salinas (1):
      pretty.c: add %x00 format specifier.

Gustaf Hendeby (6):
      git-svn: Make create-ignore use git add -f
      Documentation: Add create-ignore to git svn manual
      Documentation/config.txt: Add git-gui options
      Documentation: Add missing git svn commands
      Documentation: Fix skipped section level
      Make git add -n and git -u -n output consistent

Heikki Orsila (8):
      Make core.sharedRepository more generic
      Document functions xmemdupz(), xread() and xwrite()
      Die for an early EOF in a file reading loop
      Make read_in_full() and write_in_full() consistent with xread() and xwrite()
      Cleanup xread() loops to use read_in_full()
      Add missing "short" alternative to --date in rev-list-options.txt
      Add log.date config variable
      Remove redundant code, eliminate one static variable

Horst H. von Brand (1):
      Fix recipient santitization

Ian Hilt (1):
      Documentation/git-describe.txt: make description more readable

Imran M Yousuf (1):
      Use '-f' option to point to the .gitmodules file

Jakub Narebski (7):
      gitweb: Fix 'history' view for deleted files with history
      gitweb: Use feed link according to current view
      gitweb: Remove gitweb/test/ directory
      gitweb: Fix "next" link on bottom of page
      gitweb: Add charset info to "raw" output of 'text/plain' blobs
      gitweb: Make it work with $GIT containing spaces
      Use 'trash directory' thoroughly in t/test-lib.sh

Jamis Buck (1):
      git-reset: honor -q and do not show progress message

Jeff King (30):
      add--interactive: ignore mode change in 'p'atch command
      add--interactive: allow user to choose mode update
      git-fetch: fix status output when not storing tracking ref
      git-fetch: always show status of non-tracking-ref fetches
      git-remote: show all remotes with "git remote show"
      Don't force imap.host to be set when imap.tunnel is set
      t5516: remove ambiguity test (1)
      doc/git-gc: add a note about what is collected
      push: allow unqualified dest refspecs to DWIM
      remote: create fetch config lines with '+'
      fix reflog approxidate parsing bug
      cvsimport: always pass user data to "system" as a list
      Documentation: point git-prune users to git-gc
      add merge.renamelimit config option
      bump rename limit defaults
      diff: make "too many files" rename warning optional
      checkout: don't rfc2047-encode oneline on detached HEAD
      doc: clarify definition of "update" for git-add -u
      fix bsd shell negation
      t5000: tar portability fix
      clone: bsd shell portability fix
      filter-branch: fix variable export logic
      doc/git-daemon: s/uploadarchive/uploadarch/
      git-am: fix typo in usage message
      send-email: specify content-type of --compose body
      send-email: rfc2047-quote subject lines with non-ascii characters
      clone: make sure we support the transport type
      Fix "git clone http://$URL" to check out the worktree when asked
      document --pretty=tformat: option
      clean up error conventions of remote.c:match_explicit

Johan Herland (5):
      Add a test for another combination of --reference
      Add test for cloning with "--reference" repo being a subset of source repo
      cpio is no longer used by git-clone
      Consistency: Use "libcurl" instead of "cURL library" and "curl"
      The "curl" executable is no longer required

Johannes Schindelin (12):
      Provide git_config with a callback-data parameter
      builtin-clone: fix initial checkout
      cvsexportcommit: chomp only removes trailing whitespace
      diff options: Introduce --ignore-submodules
      Teach update-index about --ignore-submodules
      Ignore dirty submodule states during rebase and stash
      cvsexportcommit: introduce -W for shared working trees (between Git and CVS)
      submodule update: add convenience option --init
      pull --rebase: exit early when the working directory is dirty
      mailsplit and mailinfo: gracefully handle NUL characters
      hg-to-git: add --verbose option
      merge-recursive: respect core.autocrlf when writing out the result

Johannes Sixt (11):
      Document option --only of git commit
      builtin-commit.c: Remove a redundant assignment.
      git-gui: Report less precise object estimates for database compression
      compat-util: avoid macro redefinition warning
      wt-status.h: declare global variables as extern
      rev-parse --symbolic-full-name: don't print '^' if SHA1 is not a ref
      t5700-clone-reference: Quote $U
      Revert "filter-branch: subdirectory filter needs --full-history"
      rebase --interactive: Compute upstream SHA1 before switching branches
      make_nonrelative_path: Use is_absolute_path()
      Remove exec bit from builtin-fast-export.c

John J. Franey (1):
      Clarify description of <repository> argument to pull/fetch for naming remotes.

Jon Loeliger (4):
      Clarify and fix English in "git-rm" documentation
      Add otherwise missing --strict option to unpack-objects summary.
      git-filter-branch: Clarify file removal example.
      git-show.txt: Not very stubby these days.

Jonas Fonseca (1):
      git-remote: reject adding remotes with invalid names

Junio C Hamano (80):
      Optimize rename detection for a huge diff
      t5300: add test for "unpack-objects --strict"
      unpack-objects: fix --strict handling
      rebase [--onto O] A B: omit needless checkout
      sha1-lookup: more memory efficient search in sorted list of SHA-1
      diff: make --dirstat binary-file safe
      sha1-lookup: make selection of 'middle' less aggressive
      log: teach "terminator" vs "separator" mode to "--pretty=format"
      Document -w option to shortlog
      Documentation/git-submodule: typofix
      git_config_bool_or_int()
      t7401: squelch garbage output
      write_index(): optimize ce_smudge_racily_clean_entry() calls with CE_UPTODATE
      diff-files: mark an index entry we know is up-to-date as such
      Fix git_config_bool_or_int
      rebase: do not munge commit log message
      git-am: minor cleanup
      am: POSIX portability fix
      GIT 1.5.5.1
      First batch of post 1.5.5 updates
      write-tree: properly detect failure to write tree objects
      clone: detect and fail on excess parameters
      fetch-pack: brown paper bag fix
      diff: a submodule not checked out is not modified
      diff-lib.c: rename check_work_tree_entity()
      is_racy_timestamp(): do not check timestamp for gitlinks
      git-svn: add test for --add-author-from and --use-log-author
      builtin-apply: typofix
      builtin-apply: accept patch to an empty file
      builtin-apply: do not declare patch is creation when we do not know it
      unpack-trees: allow Porcelain to give different error messages
      "git-add -n -u" should not add but just report
      tests: do not use implicit "git diff --no-index"
      diff-files: do not play --no-index games
      "git diff": do not ignore index without --no-index
      mailinfo: apply the same fix not to lose NULs in BASE64 and QP codepaths
      mailsplit: minor clean-up in read_line_with_nul()
      Update draft release notes for 1.5.6
      log --graph: do not accept log --graphbogus
      log --pretty: do not accept bogus "--prettyshort"
      Release Notes for 1.5.5.2
      Documentation/git.txt: link to 1.5.5.2 documentation.
      Makefile: fix dependency on wt-status.h
      show-branch --current: do not barf on detached HEAD
      git-diff: allow  --no-index semantics a bit more
      git diff --no-index: default to page like other diff frontends
      GIT 1.5.5.3
      t5100: Avoid filename "nul"
      Git::cat_blob: allow using an empty blob to fix git-svn breakage
      fix sha1_pack_index_name()
      Manual subsection to refer to other pages is SEE ALSO
      Documentation: git-cherry uses git-patch-id
      "git checkout -- paths..." should error out when paths cannot be written
      checkout: make reset_clean_to_new() not die by itself
      checkout: consolidate reset_{to_new,clean_to_new}()
      unpack_trees(): allow callers to differentiate worktree errors from merge errors
      checkout: "best effort" checkout
      commit: drop duplicated parents
      GIT v1.5.6-rc1
      t7502: do not globally unset GIT_COMMITTER_* environment variables
      t7502: tighten loosely written test sequence
      Documentation: git-log cannot use rev-list specific options
      t7502: honor SHELL_PATH
      GIT 1.5.5.4
      GIT 1.5.6-rc2
      http-push.c: remove duplicated code
      "remote prune": be quiet when there is nothing to prune
      Documentation/git-pull.txt: Use more standard [NOTE] markup
      Documentation: exclude @pxref{[REMOTES]} from texinfo intermediate output
      user-manual: describe how higher stages are set during a merge
      t4126: fix test that happened to work due to timing
      sha1_file.c: dead code removal
      GIT 1.5.6-rc3
      Makefile: update check-docs target
      Update RPM spec to drop curl executable requirement
      diff.c: fix emit_line() again not to add extra line
      create_tempfile: make sure that leading directories can be accessible by peers
      sha1_file.c: simplify parse_pack_index()
      builtin-rerere: fix a small leak
      GIT 1.5.6

Jörg Sommer (1):
      post-merge: Add it's not executed if merge failed.

Karl Hasselström (3):
      Add some tests for git update-ref -d
      Fix path duplication in git svn commit-diff
      Revert "git.el: Set process-environment instead of invoking env"

Kevin Ballard (1):
      Documentation/git-filter-branch.txt: Fix description of --commit-filter

Krzysztof Kowalczyk (1):
      alloc_ref_from_str(): factor out a common pattern of alloc_ref from string

Lars Hjemli (8):
      Add platform-independent .git "symlink"
      Teach resolve_gitlink_ref() about the .git file
      Teach git-submodule.sh about the .git file
      Teach GIT-VERSION-GEN about the .git file
      git-branch: add support for --merged and --no-merged
      git-branch.txt: compare --contains, --merged and --no-merged
      Add tests for `branch --[no-]merged`
      revision.c: really honor --first-parent

Lea Wiemann (13):
      gitweb: only display "next" links in logs if there is a next page
      t/test-lib.sh: resolve symlinks in working directory, for pathname comparisons
      Git.pm: fix documentation of hash_object
      glossary: improve a few links
      Git.pm: fix return value of config method
      cat-file --batch: flush stdout also when objects are missing
      git-for-each-ref.txt: minor improvements
      t1006-cat-file.sh: typo
      cat-file --batch / --batch-check: do not exit if hashes are missing
      Documentation/git-cat-file.txt: add missing line break
      t/.gitattributes: only ignore whitespace errors in test files
      gitweb: quote commands properly when calling the shell
      gitweb: remove unused parse_ref method

Linus Torvalds (22):
      Make unpack_trees_options bit flags actual bitfields
      Move name hashing functions into a file of its own
      Make "index_name_exists()" return the cache_entry it found
      Make hash_name_lookup able to do case-independent lookups
      Add 'core.ignorecase' option
      Make branch merging aware of underlying case-insensitive filsystems
      Make unpack-tree update removed files before any updated files
      When adding files to the index, add support for case-independent matches
      Make git-add behave more sensibly in a case-insensitive environment
      Ignore leading empty lines while summarizing merges
      git-am: cope better with an empty Subject: line
      Optimize match_pathspec() to avoid fnmatch()
      fetch-pack: do not stop traversing an already parsed commit
      Avoid some unnecessary lstat() calls
      Optimize symlink/directory detection
      Make pack creation always fsync() the result
      Remove now unnecessary 'sync()' calls
      Consolidate SHA1 object file close
      Avoid cross-directory renames and linking on object creation
      Make loose object file reading more careful
      Simplify and rename find_sha1_file()
      write_loose_object: don't bother trying to read an old object

Liu Yubao (1):
      Documentation on --git-dir and --work-tree

Luciano Rocha (1):
      git-init: accept --bare option

Marcel Koeppen (2):
      Replace in-place sed in t7502-commit
      Fix prepare-commit-msg hook and replace in-place sed

Marius Storm-Olsen (3):
      Clearify the documentation for core.ignoreStat
      Add shortcut in refresh_cache_ent() for marked entries.
      Add testcase for merging in a CRLF repo

Mark Hills (1):
      Be more careful with objects directory permissions on clone

Mark Levedahl (2):
      git-submodule - possibly use branch name to describe a module
      git-submodule - Fix errors regarding resolve_relative_url

Martin Koegler (3):
      unpack-objects: prevent writing of inconsistent objects
      receive-pack: allow using --strict mode for unpacking objects
      t5300: add test for "index-pack --strict"

Matt Graham (1):
      Linked glossary from cvs-migration page

Matthew Ogilvie (4):
      gitattributes: Fix subdirectory attributes specified from root directory
      git-cvsserver: add mechanism for managing working tree and current directory
      implement gitcvs.usecrlfattr
      git-cvsserver: add ability to guess -kb from contents

Matthias Kestenholz (1):
      Use color.ui variable in scripts too

Matthieu Moy (2):
      Document that WebDAV doesn't need git on the server, and works over SSL
      git-svn: detect and fail gracefully when dcommitting to a void

Michael Dressel (1):
      describe: match pattern for lightweight tags too

Michael Weber (1):
      svn-git: Use binmode for reading/writing binary rev maps

Michele Ballabio (6):
      revision.c: make --date-order overriddable
      gitk: Disable "Reset %s branch to here" when on a detached head
      gitk: Move es.po where it belongs
      builtin-cat-file.c: use parse_options()
      change quoting in test t1006-cat-file.sh
      Documentation: fix graph in git-rev-parse.txt

Mikael Magnusson (1):
      Typo in RelNotes.

Mike Hommey (1):
      Don't allocate too much memory in quote_ref_url

Mike Ralphson (1):
      Makefile: update the default build options for AIX

Miklos Vajna (19):
      git-gc --auto: add pre-auto-gc hook
      Documentation/hooks: add pre-auto-gc hook
      contrib/hooks: add an example pre-auto-gc hook
      diff options documentation: refer to --diff-filter in --name-status
      git checkout: add -t alias for --track
      git-format-patch: add a new format.cc configuration variable
      git-send-email: add a new sendemail.cc configuration variable
      Add tests for sendemail.cc configuration variable
      INSTALL: add a note about GNU interactive tools has been renamed
      git-fast-import: rename cmd_*() functions to parse_*()
      git-merge: exclude unnecessary options from OPTIONS_SPEC
      CodingGuidelines: Add a note to avoid assignments inside if()
      Revision walking documentation: document most important functions
      Strbuf documentation: document most functions
      Remove unused code in parse_commit_buffer()
      git-rebase -i: mention the short command aliases in the todo list
      git-read-tree: document -v option.
      run-command documentation: fix "memset()" parameter
      path-list documentation: document all functions and data structures

Nicolas Pitre (10):
      pack-objects: small cleanup
      pack-objects: remove some double negative logic
      pack-objects: simplify the condition associated with --all-progress
      pack-objects: clean up write_object() a bit
      pack-objects: move compression code in a separate function
      pack-objects: allow for early delta deflating
      pack-objects: fix early eviction for max depth delta objects
      add a force_object_loose() function
      let pack-objects do the writing of unreachable objects as loose objects
      make verify-pack a bit more useful with bad packs

Olivier Marin (5):
      remote show: fix the -n option
      builtin-remote: split show_or_prune() in two separate functions
      remote prune: print the list of pruned branches
      remote show: list tracked remote branches with -n
      Fix approxidate("never") to always return 0

Paolo Bonzini (3):
      Add a remote.*.mirror configuration option
      add special "matching refs" refspec
      rollback lock files on more signals than just SIGINT

Paul Mackerras (41):
      gitk: Use git log without --topo-order and reorganize the commits ourselves
      gitk: Fix bug in assigning row numbers to arcs
      gitk: Fix bug in parsing multiple revision arguments
      gitk: Compute row numbers and order tokens lazily
      gitk: Fix a couple of bugs
      gitk: Fix more bugs resulting in Tcl "no such element in array" errors
      gitk: More bug fixes and cleanups
      gitk: Implement date mode in the new framework
      gitk: Fix another collection of bugs
      gitk: Don't try to show local changes from a head that isn't shown
      gitk: Keep the same commits visible as other commits come in
      gitk: Fix some corner cases in the targetid/targetrow stuff
      gitk: Fix a couple of bugs in the find function
      gitk: Fix potential bug with fake commit IDs in renumbervarc
      gitk: Index [fnvr]highlights by id rather than row
      gitk: Fix handling of flag arguments
      gitk: Fix a bug in make_disporder
      gitk: Select head of current branch by default
      gitk: Select something appropriate on cherry-pick, branch reset and checkout
      gitk: Fix bug where editing an existing view would cause an infinite loop
      gitk: Fix bug causing Tcl error when no commits are selected
      gitk: Fix cherry-picking to insert a real row not a fake row
      gitk: Cope better with getting commits that we have already seen
      gitk: Fix bug where arcs could get lost
      gitk: Handle updating with path limiting better
      gitk: Fix problems with target row stuff
      gitk: Don't filter view arguments through git rev-parse
      gitk: Correct a few strings and comments to say "git log"
      gitk: Fix some corner cases in computing vrowmod and displayorder
      gitk: Avoid a crash in selectline if commitinfo($id) isn't set
      gitk: Fix problem with target row not being in scroll region
      gitk: Reorganize processing of arguments for git log
      gitk: Fix handling of tree file list with special chars in names
      gitk: Make updates go faster
      gitk: Synchronize highlighting in file view for 'f' and 'b' commands
      gitk: Show current row number and total number of rows
      gitk: Add a progress bar for checking out a head
      gitk: Fix "wrong # coordinates" error on reload
      gitk: Fix bug where current row number display stops working
      gitk: Fix bug introduced by "gitk: Fix "wrong # coordinates" error on reload"
      gitk: Handle detached heads better

Paul Oliver (1):
      Make git-cvsimport remove ['s from tags, as bad_ref_char doesn't allow them.

Pedro Melo (1):
      Force the medium pretty format on calls to git log

Peter Karlsson (1):
      gitk: Initial Swedish translation.

Philippe Bruhat (BooK) (1):
      git-cvsimport: do not fail when CVSROOT is /

Pierre Habouzit (1):
      Make git reflog expire honour core.sharedRepository.

Pieter de Bie (2):
      builtin-fast-export: Only output a single parent per line
      git-send-email: allow whitespace in addressee list

Ping Yin (6):
      git-submodule: Avoid 'fatal: cannot describe' message
      git-submodule summary: --for-status option
      builtin-status: submodule summary support
      builtin-status: Add tests for submodule summary
      t4027: test diff for submodule with empty directory
      Add t7506 to test submodule related functions for git-status

Rafael Garcia-Suarez (1):
      Spelling fixes in the gitweb documentation

René Scharfe (2):
      git-archive: ignore prefix when checking file attribute
      Ignore .gitattributes in bare repositories

Richard Quirk (2):
      bash: Add completion for gitk --merge
      Documentation gitk: Describe what --merge does

SZEDER Gábor (8):
      doc: moved merge.* config variables into separate merge-config.txt
      merge, pull: introduce '--(no-)stat' option
      add 'merge.stat' config variable
      fmt-merge-msg: add '--(no-)log' options and 'merge.log' config variable
      merge, pull: add '--(no-)log' command line option
      git add: add long equivalents of '-u' and '-f' options
      completion: add more 'git add' options
      diff: reset color before printing newline

Sam Vilain (1):
      Amend git-push refspec documentation

Santi Béjar (3):
      Preparation to call determine_author_info from prepare_to_commit
      commit: Show author if different from committer
      commit: Show committer if automatic

Santiago Gala (1):
      gitk: Spanish translation of gitk

Scott Collins (1):
      Clarify documentation of git-cvsserver, particularly in relation to git-shell

Sebastian Schuberth (1):
      mergetool: Make ECMerge use the settings as specified by the user in the GUI

Seth Falcon (1):
      Add a --dry-run option to git-svn rebase

Shawn Bohrer (2):
      git clean: Don't automatically remove directories when run within subdirectory
      git clean: Add test to verify directories aren't removed with a prefix

Shawn O. Pearce (13):
      git-gui: Don't use '$$cr master' with aspell earlier than 0.60
      git-gui: Setup branch.remote,merge for shorthand git-pull
      git-gui: Delete branches with 'git branch -D' to clear config
      git-gui: Add a --trace command line option
      git-gui: Handle workdir detection when CYGWIN=nowinsymlinks
      Clarify repack -n documentation
      Don't diff empty tree on branch creation in paranoid update hook
      Don't load missing ACL files in paranoid update hook
      Ignore no-op changes in paranoid update hook
      Remove unused remote_prefix member in builtin-remote
      Make "git-remote prune" delete refs according to fetch specs
      Make "git-remote rm" delete refs acccording to fetch specs
      fast-export: Correctly generate initial commits with no parents

Sitaram Chamarty (1):
      builtin-commit.c: add -u as short name for --untracked-files

Steffen Prohaska (4):
      t0050: Test autodetect core.ignorecase
      t0050: Set core.ignorecase case to activate case insensitivity
      t0050: Add test for case insensitive add
      t0050: Fix merge test on case sensitive file systems

Stephan Beyer (9):
      builtin-apply.c: use git_config_string() to get apply_default_whitespace
      Add test cases for git-am
      Merge t4150-am-subdir.sh and t4151-am.sh into t4150-am.sh
      git-commit.txt: Correct option alternatives
      git-commit.txt: Add missing long/short options
      Docs: Use "-l::\n--long\n" format in OPTIONS sections
      Docs: add some long/short options
      git-describe.txt: document --always
      git-name-rev.txt: document --no-undefined and --always

Stephen R. van den Berg (2):
      Simplify and fix --first-parent implementation
      git-svn: Same default as cvsimport when using --use-log-author

Steven Grimm (1):
      Add svn-compatible "blame" output format to git-svn

Teemu Likonen (3):
      bash: Add completion for git diff --base --ours --theirs
      Documentation/git-web--browse.txt: fix small typo
      Print info about "git help COMMAND" on git's main usage pages

Thomas Arcila (1):
      gitk: Allow users to view diffs in external diff viewer

Thomas Guyot-Sionnest (1):
      git-svn bug with blank commits and author file

Trent Piepho (1):
      cvsexportcommit: Create config option for CVS dir

Twiinz (1):
      git-gui: Vertically align textboxes with labels

martin f. krafft (2):
      Escape project name in regexp
      Escape project names before creating pathinfo URLs

A note from the maintainer

[Junio C Hamano]

Welcome to git community.

This message talks about how git.git is managed, and how you can work
with it.

* IRC and Mailing list

Many active members of development community hang around on #git
IRC channel on Freenode.  Its log is available at:

        http://colabti.org/irclogger/irclogger_log/git

The development however is primarily done on the git mailing list
(git@vger.kernel.org).  If you have patches, please send them to the
list, following Documentation/SubmittingPatches.

I usually try to read all patches posted to the list, and follow
almost all the discussions on the list, unless the topic is about an
obscure corner that I do not personally use.  But I am obviously not
perfect.  If you sent a patch that you did not hear from anybody for
three days, that is a very good indication that it was dropped on the
floor --- please do not hesitate to remind me.

The list archive is available at a few public sites as well:

        http://news.gmane.org/gmane.comp.version-control.git/
        http://marc.theaimsgroup.com/?l=git
        http://www.spinics.net/lists/git/

and some people seem to prefer to read it over NNTP:

        nntp://news.gmane.org/gmane.comp.version-control.git

When you point at a message in a mailing list archive, using
gmane is often the easiest to follow by readers, like this:

        http://thread.gmane.org/gmane.comp.version-control.git/27/focus=217

as it also allows people who subscribe to the mailing list as
gmane newsgroup to "jump to" the article.

* Repositories, branches and documentation.

My public git.git repository is at:

        git://git.kernel.org/pub/scm/git/git.git/

Immediately after I publish to the primary repository at kernel.org, I
also push into an alternate here:

        git://repo.or.cz/alt-git.git/

Impatient people might have better luck with the latter one.

Their gitweb interfaces are found at:

        http://git.kernel.org/?p=git/git.git
        http://repo.or.cz/w/alt-git.git

There are three branches in git.git repository that are not
about the source tree of git: "todo", "html" and "man".  The
first one was meant to contain TODO list for me, but I am not
good at maintaining such a list and it is not as often updated as
it could/should be.  It also contains some helper scripts I use
to maintain git.

The "html" and "man" are autogenerated documentation from the
tip of the "master" branch; the tip of "html" is extracted to be
visible at kernel.org at:

        http://www.kernel.org/pub/software/scm/git/docs/

The above URL is the top-level documentation page, and it has
links to documentation of older releases.

The script to maintain these two documentation branches are
found in "todo" branch as dodoc.sh, if you are interested.  It
is a good demonstration of how to use an update hook to automate
a task.

There are four branches in git.git repository that track the
source tree of git: "master", "maint", "next", and "pu".  I may
add more maintenance branches (e.g. "maint-1.5.4") if we have
hugely backward incompatible feature updates in the future to keep
an older release alive; I may not, but the distributed nature of
git means any volunteer can run a stable-tree like that herself.

The "master" branch is meant to contain what are very well
tested and ready to be used in a production setting.  There
could occasionally be minor breakages or brown paper bag bugs
but they are not expected to be anything major, and more
importantly quickly and trivially fixable.  Every now and
then, a "feature release" is cut from the tip of this branch and
they typically are named with three dotted decimal digits.  The
last such release was 1.5.6 done on Jun 18th this year.  You
can expect that the tip of the "master" branch is always more
stable than any of the released versions.

Whenever a feature release is made, "maint" branch is forked off
from "master" at that point.  Obvious, safe and urgent fixes
after a feature release are applied to this branch and
maintenance releases are cut from it.  The maintenance releases
are named with four dotted decimal, named after the feature
release they are updates to; the last such release was 1.5.5.4.
New features never go to this branch.  This branch is also
merged into "master" to propagate the fixes forward.

A trivial and safe enhancement goes directly on top of "master".
A new development, either initiated by myself or more often by
somebody who found his or her own itch to scratch, does not
usually happen on "master", however.  Instead, a separate topic
branch is forked from the tip of "master", and it first is
tested in isolation; I may make minimum fixups at this point.
Usually there are a handful such topic branches that are running
ahead of "master" in git.git repository.  I do not publish the
tip of these branches in my public repository, however, partly
to keep the number of branches that downstream developers need
to worry about low, and primarily because I am lazy.

The quality of topic branches are judged primarily by the mailing list
discussions.  Some of them start out as "good idea but obviously is
broken in some areas (e.g. breaks the existing testsuite)" and then
with some more work (either by the original contributor's effort or
help from other people on the list) becomes "more or less done and can
now be tested by wider audience".  Luckily, most of them start out in
the latter, better shape.

The "next" branch is to merge and test topic branches in the
latter category.  In general, the branch always contains the tip
of "master".  It might not be quite rock-solid production ready,
but is expected to work more or less without major breakage.  I
usually use "next" version of git for my own work, so it cannot
be _that_ broken to prevent me from pushing the changes out.
The "next" branch is where new and exciting things take place.

The two branches "master" and "maint" are never rewound, and
"next" usually will not be either (this automatically means the
topics that have been merged into "next" are usually not
rebased, and you can find the tip of topic branches you are
interested in from the output of "git log next"). You should be
able to safely track them.

After a feature release is made from "master", however, "next"
will be rebuilt from the tip of "master" using the surviving
topics.  The commit that replaces the tip of the "next" will
have the identical tree, but it will have different ancestry
from the tip of "master".  An announcement will be made to warn
people about such a rebasing.

The "pu" (proposed updates) branch bundles all the remainder of
topic branches.  The "pu" branch, and topic branches that are
only in "pu", are subject to rebasing in general.  By the above
definition of how "next" works, you can tell that this branch
will contain quite experimental and obviously broken stuff.

When a topic that was in "pu" proves to be in testable shape, it
graduates to "next".  I do this with:

        git checkout next
        git merge that-topic-branch

Sometimes, an idea that looked promising turns out to be not so
good and the topic can be dropped from "pu" in such a case.

A topic that is in "next" is expected to be tweaked and fixed to
perfection before it is merged to "master" (that's why "master"
can be expected to stay very stable).  Similarly to the above, I
do it with this:

        git checkout master
        git merge that-topic-branch
        git branch -d that-topic-branch

Note that being in "next" is not a guarantee to appear in the
next release (being in "master" is such a guarantee, unless it
is later found seriously broken and reverted), or even in any
future release.  There even were cases that topics needed
reverting a few commits in them before graduating to "master",
or a topic that already was in "next" were entirely reverted
from "next" because fatal flaws were found in them later.

Starting from v1.5.0, "master" and "maint" have release notes
for the next release in Documentation/RelNotes-* files, so that
I do not have to run around summarizing what happened just
before the release.


* Other people's trees, trusted lieutenants and credits.

Documentation/SubmittingPatches outlines who your changes should
be sent to.  As described in contrib/README, I would delegate
fixes and enhancements in contrib/ area to primary contributors
of them.

Although the following are included in git.git repository, they
have their own authoritative repository and maintainers:

 - git-gui/ comes from Shawn Pearce's git-gui project:

        git://repo.or.cz/git-gui.git

 - gitk-git/ comes from Paul Mackerras's gitk project:

        git://git.kernel.org/pub/scm/gitk/gitk.git

I would like to thank everybody who helped to raise git into the
current shape.  Especially I would like to thank the git list
regulars whose help I have relied on and expect to continue
relying on heavily:

 - Linus on general design issues.

 - Linus, Shawn Pearce, Johannes Schindelin, Nicolas Pitre,
   René Scharfe and Jeff King on general implementation issues.

 - Shawn and Nicolas Pitre on pack issues.

 - Martin Langhoff and Frank Lichtenheld on cvsserver and cvsimport.

 - Paul Mackerras on gitk.

 - Eric Wong on git-svn.

 - Simon Hausmann on git-p4.

 - Jakub Narebski, Petr Baudis, and Luben Tuikov on gitweb.

 - J. Bruce Fields on documentaton issues.

 - Johannes Schindelin, Johannes Sixt and others for their effort
   to move things forward on the Windows front.  Although my
   repository does not have much from the effort of MinGW team,
   I expect a merge into mainline will happen so that everybody
   can work from the same codebase.

 - People on non-Linux platforms for keeping their eyes on
   portability; especially, Randal Schwartz, Theodore Ts'o,
   Jason Riedy, Thomas Glanzmann, but countless others as well.

* This document

The latest copy of this document is found in git.git repository,
on 'todo' branch, as MaintNotes.

A note from the maintainer

[Junio C Hamano]

Welcome to git community.

This message talks about how git.git is managed, and how you can work
with it.

* IRC and Mailing list

Many active members of development community hang around on #git
IRC channel on Freenode.  Its log is available at:

        http://colabti.org/irclogger/irclogger_log/git

The development however is primarily done on the git mailing list
(git@vger.kernel.org).  If you have patches, please send them to the
list, following Documentation/SubmittingPatches.

I usually try to read all patches posted to the list, and follow
almost all the discussions on the list, unless the topic is about an
obscure corner that I do not personally use.  But I am obviously not
perfect.  If you sent a patch that you did not hear from anybody for
three days, that is a very good indication that it was dropped on the
floor --- please do not hesitate to remind me.

The list archive is available at a few public sites as well:

        http://news.gmane.org/gmane.comp.version-control.git/
        http://marc.theaimsgroup.com/?l=git
        http://www.spinics.net/lists/git/

and some people seem to prefer to read it over NNTP:

        nntp://news.gmane.org/gmane.comp.version-control.git

When you point at a message in a mailing list archive, using
gmane is often the easiest to follow by readers, like this:

        http://thread.gmane.org/gmane.comp.version-control.git/27/focus=217

as it also allows people who subscribe to the mailing list as
gmane newsgroup to "jump to" the article.

* Repositories, branches and documentation.

My public git.git repository is at:

        git://git.kernel.org/pub/scm/git/git.git/

Immediately after I publish to the primary repository at kernel.org, I
also push into an alternate here:

        git://repo.or.cz/alt-git.git/

Impatient people might have better luck with the latter one.

Their gitweb interfaces are found at:

        http://git.kernel.org/?p=git/git.git
        http://repo.or.cz/w/alt-git.git

There are three branches in git.git repository that are not
about the source tree of git: "todo", "html" and "man".  The
first one was meant to contain TODO list for me, but I am not
good at maintaining such a list and it is not as often updated as
it could/should be.  It also contains some helper scripts I use
to maintain git.

The "html" and "man" are autogenerated documentation from the
tip of the "master" branch; the tip of "html" is extracted to be
visible at kernel.org at:

        http://www.kernel.org/pub/software/scm/git/docs/

The above URL is the top-level documentation page, and it has
links to documentation of older releases.

The script to maintain these two documentation branches are
found in "todo" branch as dodoc.sh, if you are interested.  It
is a good demonstration of how to use an update hook to automate
a task.

There are four branches in git.git repository that track the
source tree of git: "master", "maint", "next", and "pu".  I may
add more maintenance branches (e.g. "maint-1.5.4") if we have
hugely backward incompatible feature updates in the future to keep
an older release alive; I may not, but the distributed nature of
git means any volunteer can run a stable-tree like that herself.

The "master" branch is meant to contain what are very well
tested and ready to be used in a production setting.  There
could occasionally be minor breakages or brown paper bag bugs
but they are not expected to be anything major, and more
importantly quickly and trivially fixable.  Every now and
then, a "feature release" is cut from the tip of this branch and
they typically are named with three dotted decimal digits.  The
last such release was 1.5.6 done on Jun 18th this year.  You
can expect that the tip of the "master" branch is always more
stable than any of the released versions.

Whenever a feature release is made, "maint" branch is forked off
from "master" at that point.  Obvious, safe and urgent fixes
after a feature release are applied to this branch and
maintenance releases are cut from it.  The maintenance releases
are named with four dotted decimal, named after the feature
release they are updates to; the last such release was 1.5.6.3.
New features never go to this branch.  This branch is also
merged into "master" to propagate the fixes forward.

A trivial and safe enhancement goes directly on top of "master".
A new development, either initiated by myself or more often by
somebody who found his or her own itch to scratch, does not
usually happen on "master", however.  Instead, a separate topic
branch is forked from the tip of "master", and it first is
tested in isolation; I may make minimum fixups at this point.
Usually there are a handful such topic branches that are running
ahead of "master" in git.git repository.  I do not publish the
tip of these branches in my public repository, however, partly
to keep the number of branches that downstream developers need
to worry about low, and primarily because I am lazy.

The quality of topic branches are judged primarily by the mailing list
discussions.  Some of them start out as "good idea but obviously is
broken in some areas (e.g. breaks the existing testsuite)" and then
with some more work (either by the original contributor's effort or
help from other people on the list) becomes "more or less done and can
now be tested by wider audience".  Luckily, most of them start out in
the latter, better shape.

The "next" branch is to merge and test topic branches in the
latter category.  In general, the branch always contains the tip
of "master".  It might not be quite rock-solid production ready,
but is expected to work more or less without major breakage.  I
usually use "next" version of git for my own work, so it cannot
be _that_ broken to prevent me from pushing the changes out.
The "next" branch is where new and exciting things take place.

The two branches "master" and "maint" are never rewound, and
"next" usually will not be either (this automatically means the
topics that have been merged into "next" are usually not
rebased, and you can find the tip of topic branches you are
interested in from the output of "git log next"). You should be
able to safely track them.

After a feature release is made from "master", however, "next"
will be rebuilt from the tip of "master" using the surviving
topics.  The commit that replaces the tip of the "next" will
have the identical tree, but it will have different ancestry
from the tip of "master".  An announcement will be made to warn
people about such a rebasing.

The "pu" (proposed updates) branch bundles all the remainder of
topic branches.  The "pu" branch, and topic branches that are
only in "pu", are subject to rebasing in general.  By the above
definition of how "next" works, you can tell that this branch
will contain quite experimental and obviously broken stuff.

When a topic that was in "pu" proves to be in testable shape, it
graduates to "next".  I do this with:

        git checkout next
        git merge that-topic-branch

Sometimes, an idea that looked promising turns out to be not so
good and the topic can be dropped from "pu" in such a case.

A topic that is in "next" is expected to be tweaked and fixed to
perfection before it is merged to "master" (that's why "master"
can be expected to stay very stable).  Similarly to the above, I
do it with this:

        git checkout master
        git merge that-topic-branch
        git branch -d that-topic-branch

Note that being in "next" is not a guarantee to appear in the
next release (being in "master" is such a guarantee, unless it
is later found seriously broken and reverted), or even in any
future release.  There even were cases that topics needed
reverting a few commits in them before graduating to "master",
or a topic that already was in "next" were entirely reverted
from "next" because fatal flaws were found in them later.

Starting from v1.5.0, "master" and "maint" have release notes
for the next release in Documentation/RelNotes-* files, so that
I do not have to run around summarizing what happened just
before the release.


* Other people's trees, trusted lieutenants and credits.

Documentation/SubmittingPatches outlines who your changes should
be sent to.  As described in contrib/README, I would delegate
fixes and enhancements in contrib/ area to primary contributors
of them.

Although the following are included in git.git repository, they
have their own authoritative repository and maintainers:

 - git-gui/ comes from Shawn Pearce's git-gui project:

        git://repo.or.cz/git-gui.git

 - gitk-git/ comes from Paul Mackerras's gitk project:

        git://git.kernel.org/pub/scm/gitk/gitk.git

I would like to thank everybody who helped to raise git into the
current shape.  Especially I would like to thank the git list
regulars whose help I have relied on and expect to continue
relying on heavily:

 - Linus on general design issues.

 - Linus, Shawn Pearce, Johannes Schindelin, Nicolas Pitre,
   René Scharfe and Jeff King on general implementation issues.

 - Shawn and Nicolas Pitre on pack issues.

 - Martin Langhoff and Frank Lichtenheld on cvsserver and cvsimport.

 - Paul Mackerras on gitk.

 - Eric Wong on git-svn.

 - Simon Hausmann on git-p4.

 - Jakub Narebski, Petr Baudis, and Luben Tuikov on gitweb.

 - J. Bruce Fields on documentaton issues.

 - Johannes Schindelin, Johannes Sixt and others for their effort
   to move things forward on the Windows front.  Most of the fruits
   from their porting efforts have been merged to the mainline git.git
   repository in 1.6.0 release.

 - People on non-Linux platforms for keeping their eyes on
   portability; especially, Randal Schwartz, Theodore Ts'o,
   Jason Riedy, Thomas Glanzmann, but countless others as well.

* This document

The latest copy of this document is found in git.git repository,
on 'todo' branch, as MaintNotes.

A note from the maintainer

[Junio C Hamano]

Welcome to git community.

This message talks about how git.git is managed, and how you can work
with it.

* IRC and Mailing list

Many active members of development community hang around on #git
IRC channel on Freenode.  Its log is available at:

        http://colabti.org/irclogger/irclogger_log/git

The development however is primarily done on the git mailing list
(git@vger.kernel.org).  If you have patches, please send them to the
list, following Documentation/SubmittingPatches.

I usually try to read all patches posted to the list, and follow
almost all the discussions on the list, unless the topic is about an
obscure corner that I do not personally use.  But I am obviously not
perfect.  If you sent a patch that you did not hear from anybody for
three days, that is a very good indication that it was dropped on the
floor --- please do not hesitate to remind me.

The list archive is available at a few public sites as well:

        http://news.gmane.org/gmane.comp.version-control.git/
        http://marc.theaimsgroup.com/?l=git
        http://www.spinics.net/lists/git/

and some people seem to prefer to read it over NNTP:

        nntp://news.gmane.org/gmane.comp.version-control.git

When you point at a message in a mailing list archive, using
gmane is often the easiest to follow by readers, like this:

        http://thread.gmane.org/gmane.comp.version-control.git/27/focus=217

as it also allows people who subscribe to the mailing list as
gmane newsgroup to "jump to" the article.

* Repositories, branches and documentation.

My public git.git repository is at:

        git://git.kernel.org/pub/scm/git/git.git/

Immediately after I publish to the primary repository at kernel.org, I
also push into an alternate here:

        git://repo.or.cz/alt-git.git/

Impatient people might have better luck with the latter one.

Their gitweb interfaces are found at:

        http://git.kernel.org/?p=git/git.git
        http://repo.or.cz/w/alt-git.git

There are three branches in git.git repository that are not
about the source tree of git: "todo", "html" and "man".  The
first one was meant to contain TODO list for me, but I am not
good at maintaining such a list and it is not as often updated as
it could/should be.  It also contains some helper scripts I use
to maintain git.

The "html" and "man" are autogenerated documentation from the
tip of the "master" branch; the tip of "html" is extracted to be
visible at kernel.org at:

        http://www.kernel.org/pub/software/scm/git/docs/

The above URL is the top-level documentation page, and it has
links to documentation of older releases.

The script to maintain these two documentation branches are
found in "todo" branch as dodoc.sh, if you are interested.  It
is a good demonstration of how to use an update hook to automate
a task.

There are four branches in git.git repository that track the
source tree of git: "master", "maint", "next", and "pu".  I may
add more maintenance branches (e.g. "maint-1.5.4") if we have
hugely backward incompatible feature updates in the future to keep
an older release alive; I may not, but the distributed nature of
git means any volunteer can run a stable-tree like that herself.

The "master" branch is meant to contain what are very well
tested and ready to be used in a production setting.  There
could occasionally be minor breakages or brown paper bag bugs
but they are not expected to be anything major, and more
importantly quickly and trivially fixable.  Every now and
then, a "feature release" is cut from the tip of this branch and
they typically are named with three dotted decimal digits.  The
last such release was 1.5.5 done on Apr 7th this year.  You
can expect that the tip of the "master" branch is always more
stable than any of the released versions.

Whenever a feature release is made, "maint" branch is forked off
from "master" at that point.  Obvious, safe and urgent fixes
after a feature release are applied to this branch and
maintenance releases are cut from it.  The maintenance releases
are named with four dotted decimal, named after the feature
release they are updates to; the last such release was 1.5.4.5.
New features never go to this branch.  This branch is also
merged into "master" to propagate the fixes forward.

A trivial and safe enhancement goes directly on top of "master".
A new development, either initiated by myself or more often by
somebody who found his or her own itch to scratch, does not
usually happen on "master", however.  Instead, a separate topic
branch is forked from the tip of "master", and it first is
tested in isolation; I may make minimum fixups at this point.
Usually there are a handful such topic branches that are running
ahead of "master" in git.git repository.  I do not publish the
tip of these branches in my public repository, however, partly
to keep the number of branches that downstream developers need
to worry about low, and primarily because I am lazy.

The quality of topic branches are judged primarily by the mailing list
discussions.  Some of them start out as "good idea but obviously is
broken in some areas (e.g. breaks the existing testsuite)" and then
with some more work (either by the original contributor's effort or
help from other people on the list) becomes "more or less done and can
now be tested by wider audience".  Luckily, most of them start out in
the latter, better shape.

The "next" branch is to merge and test topic branches in the
latter category.  In general, the branch always contains the tip
of "master".  It might not be quite rock-solid production ready,
but is expected to work more or less without major breakage.  I
usually use "next" version of git for my own work, so it cannot
be _that_ broken to prevent me from pushing the changes out.
The "next" branch is where new and exciting things take place.

The two branches "master" and "maint" are never rewound, and
"next" usually will not be either (this automatically means the
topics that have been merged into "next" are usually not
rebased, and you can find the tip of topic branches you are
interested in from the output of "git log next"). You should be
able to safely track them.

After a feature release is made from "master", however, "next"
will be rebuilt from the tip of "master" using the surviving
topics.  The commit that replaces the tip of the "next" will
have the identical tree, but it will have different ancestry
from the tip of "master".  An announcement will be made to warn
people about such a rebasing.

The "pu" (proposed updates) branch bundles all the remainder of
topic branches.  The "pu" branch, and topic branches that are
only in "pu", are subject to rebasing in general.  By the above
definition of how "next" works, you can tell that this branch
will contain quite experimental and obviously broken stuff.

When a topic that was in "pu" proves to be in testable shape, it
graduates to "next".  I do this with:

        git checkout next
        git merge that-topic-branch

Sometimes, an idea that looked promising turns out to be not so
good and the topic can be dropped from "pu" in such a case.

A topic that is in "next" is expected to be tweaked and fixed to
perfection before it is merged to "master" (that's why "master"
can be expected to stay very stable).  Similarly to the above, I
do it with this:

        git checkout master
        git merge that-topic-branch
        git branch -d that-topic-branch

Note that being in "next" is not a guarantee to appear in the
next release (being in "master" is such a guarantee, unless it
is later found seriously broken and reverted), or even in any
future release.  There even were cases that topics needed
reverting a few commits in them before graduating to "master",
or a topic that already was in "next" were entirely reverted
from "next" because fatal flaws were found in them later.

Starting from v1.5.0, "master" and "maint" have release notes
for the next release in Documentation/RelNotes-* files, so that
I do not have to run around summarizing what happened just
before the release.


* Other people's trees, trusted lieutenants and credits.

Documentation/SubmittingPatches outlines who your changes should
be sent to.  As described in contrib/README, I would delegate
fixes and enhancements in contrib/ area to primary contributors
of them.

Although the following are included in git.git repository, they
have their own authoritative repository and maintainers:

 - git-gui/ comes from Shawn Pearce's git-gui project:

        git://repo.or.cz/git-gui.git

 - gitk-git/ comes from Paul Mackerras's gitk project:

        git://git.kernel.org/pub/scm/gitk/gitk.git

I would like to thank everybody who helped to raise git into the
current shape.  Especially I would like to thank the git list
regulars whose help I have relied on and expect to continue
relying on heavily:

 - Linus on general design issues.

 - Linus, Shawn Pearce, Johannes Schindelin, Nicolas Pitre,
   René Scharfe and Jeff King on general implementation issues.

 - Shawn and Nicolas Pitre on pack issues.

 - Martin Langhoff and Frank Lichtenheld on cvsserver and cvsimport.

 - Paul Mackerras on gitk.

 - Eric Wong on git-svn.

 - Simon Hausmann on git-p4.

 - Jakub Narebski, Petr Baudis, and Luben Tuikov on gitweb.

 - J. Bruce Fields on documentaton issues.

 - Johannes Schindelin, Johannes Sixt and others for their effort
   to move things forward on the Windows front.  Although my
   repository does not have much from the effort of MinGW team,
   I expect a merge into mainline will happen so that everybody
   can work from the same codebase.

 - People on non-Linux platforms for keeping their eyes on
   portability; especially, Randal Schwartz, Theodore Ts'o,
   Jason Riedy, Thomas Glanzmann, but countless others as well.

* This document

The latest copy of this document is found in git.git repository,
on 'todo' branch, as MaintNotes.

A note from the maintainer

[Junio C Hamano]

Welcome to git community.

This message talks about how git.git is managed, and how you can work
with it.

* IRC and Mailing list

Many active members of development community hang around on #git
IRC channel on Freenode.  Its log is available at:

        http://colabti.de/irclogger/irclogger_log/git

The development however is primarily done on the git mailing list
(git@vger.kernel.org).  If you have patches, please send them to the
list, following Documentation/SubmittingPatches.

I usually try to read all patches posted to the list, and follow
almost all the discussions on the list, unless the topic is about an
obscure corner that I do not personally use.  But I am obviously not
perfect.  If you sent a patch that you did not hear from anybody for
three days, that is a very good indication that it was dropped on the
floor --- please do not hesitate to remind me.

The list archive is available at a few public sites as well:

        http://news.gmane.org/gmane.comp.version-control.git/
        http://marc.theaimsgroup.com/?l=git
        http://www.spinics.net/lists/git/

and some people seem to prefer to read it over NNTP:

        nntp://news.gmane.org/gmane.comp.version-control.git

When you point at a message in a mailing list archive, using
gmane is often the easiest to follow by readers, like this:

        http://thread.gmane.org/gmane.comp.version-control.git/27/focus=217

as it also allows people who subscribe to the mailing list as
gmane newsgroup to "jump to" the article.

* Repositories, branches and documentation.

My public git.git repository is at:

        git://git.kernel.org/pub/scm/git/git.git/

Immediately after I publish to the primary repository at kernel.org, I
also push into an alternate here:

        git://repo.or.cz/alt-git.git/

Impatient people might have better luck with the latter one.

Their gitweb interfaces are found at:

        http://git.kernel.org/?p=git/git.git
        http://repo.or.cz/w/alt-git.git

There are three branches in git.git repository that are not
about the source tree of git: "todo", "html" and "man".  The
first one was meant to contain TODO list for me, but I am not
good at maintaining such a list and it is not as often updated as
it could/should be.  It also contains some helper scripts I use
to maintain git.

The "html" and "man" are autogenerated documentation from the
tip of the "master" branch; the tip of "html" is extracted to be
visible at kernel.org at:

        http://www.kernel.org/pub/software/scm/git/docs/

The above URL is the top-level documentation page, and it has
links to documentation of older releases.

The script to maintain these two documentation branches are
found in "todo" branch as dodoc.sh, if you are interested.  It
is a good demonstration of how to use an update hook to automate
a task.

There are four branches in git.git repository that track the
source tree of git: "master", "maint", "next", and "pu".  I may
add more maintenance branches (e.g. "maint-1.5.3") if we have
hugely backward incompatible feature updates in the future to keep
an older release alive; I may not, but the distributed nature of
git means any volunteer can run a stable-tree like that herself.

The "master" branch is meant to contain what are very well
tested and ready to be used in a production setting.  There
could occasionally be minor breakages or brown paper bag bugs
but they are not expected to be anything major, and more
importantly quickly and trivially fixable.  Every now and
then, a "feature release" is cut from the tip of this branch and
they typically are named with three dotted decimal digits.  The
last such release was 1.5.4 done on Feb 2nd this year.  You
can expect that the tip of the "master" branch is always more
stable than any of the released versions.

Whenever a feature release is made, "maint" branch is forked off
from "master" at that point.  Obvious, safe and urgent fixes
after a feature release are applied to this branch and
maintenance releases are cut from it.  The maintenance releases
are named with four dotted decimal, named after the feature
release they are updates to; the last such release was 1.5.4.2.
New features never go to this branch.  This branch is also
merged into "master" to propagate the fixes forward.

A trivial and safe enhancement goes directly on top of "master".
A new development, either initiated by myself or more often by
somebody who found his or her own itch to scratch, does not
usually happen on "master", however.  Instead, a separate topic
branch is forked from the tip of "master", and it first is
tested in isolation; I may make minimum fixups at this point.
Usually there are a handful such topic branches that are running
ahead of "master" in git.git repository.  I do not publish the
tip of these branches in my public repository, however, partly
to keep the number of branches that downstream developers need
to worry about low, and primarily because I am lazy.

The quality of topic branches are judged primarily by the mailing list
discussions.  Some of them start out as "good idea but obviously is
broken in some areas (e.g. breaks the existing testsuite)" and then
with some more work (either by the original contributor's effort or
help from other people on the list) becomes "more or less done and can
now be tested by wider audience".  Luckily, most of them start out in
the latter, better shape.

The "next" branch is to merge and test topic branches in the
latter category.  In general, the branch always contains the tip
of "master".  It might not be quite rock-solid production ready,
but is expected to work more or less without major breakage.  I
usually use "next" version of git for my own work, so it cannot
be _that_ broken to prevent me from pushing the changes out.
The "next" branch is where new and exciting things take place.

The two branches "master" and "maint" are never rewound, and
"next" usually will not be either (this automatically means the
topics that have been merged into "next" are usually not
rebased, and you can find the tip of topic branches you are
interested in from the output of "git log next"). You should be
able to safely track them.

After a feature release is made from "master", however, "next"
will be rebuilt from the tip of "master" using the surviving
topics.  The commit that replaces the tip of the "next" will
have the identical tree, but it will have different ancestry
from the tip of "master".  An announcement will be made to warn
people about such a rebasing.

The "pu" (proposed updates) branch bundles all the remainder of
topic branches.  The "pu" branch, and topic branches that are
only in "pu", are subject to rebasing in general.  By the above
definition of how "next" works, you can tell that this branch
will contain quite experimental and obviously broken stuff.

When a topic that was in "pu" proves to be in testable shape, it
graduates to "next".  I do this with:

        git checkout next
        git merge that-topic-branch

Sometimes, an idea that looked promising turns out to be not so
good and the topic can be dropped from "pu" in such a case.

A topic that is in "next" is expected to be tweaked and fixed to
perfection before it is merged to "master" (that's why "master"
can be expected to stay very stable).  Similarly to the above, I
do it with this:

        git checkout master
        git merge that-topic-branch
        git branch -d that-topic-branch

Note that being in "next" is not a guarantee to appear in the
next release (being in "master" is such a guarantee, unless it
is later found seriously broken and reverted), or even in any
future release.  There even were cases that topics needed
reverting a few commits in them before graduating to "master",
or a topic that already was in "next" were entirely reverted
from "next" because fatal flaws were found in them later.

Starting from v1.5.0, "master" and "maint" have release notes
for the next release in Documentation/RelNotes-* files, so that
I do not have to run around summarizing what happened just
before the release.


* Other people's trees, trusted lieutenants and credits.

Documentation/SubmittingPatches outlines who your changes should
be sent to.  As described in contrib/README, I would delegate
fixes and enhancements in contrib/ area to primary contributors
of them.

Although the following are included in git.git repository, they
have their own authoritative repository and maintainers:

 - git-gui/ comes from Shawn Pearce's git-gui project:

        git://repo.or.cz/git-gui.git

 - gitk-git/ comes from Paul Mackerras's gitk project:

        git://git.kernel.org/pub/scm/gitk/gitk.git

I would like to thank everybody who helped to raise git into the
current shape.  Especially I would like to thank the git list
regulars whose help I have relied on and expect to continue
relying on heavily:

 - Linus on general design issues.

 - Linus, Shawn Pearce, Johannes Schindelin, Nicolas Pitre,
   René Scharfe and Jeff King on general implementation issues.

 - Shawn and Nicolas Pitre on pack issues.

 - Martin Langhoff and Frank Lichtenheld on cvsserver and cvsimport.

 - Paul Mackerras on gitk.

 - Eric Wong on git-svn.

 - Simon Hausmann on git-p4.

 - Jakub Narebski, Petr Baudis, and Luben Tuikov on gitweb.

 - J. Bruce Fields on documentaton issues.

 - Johannes Schindelin, Johannes Sixt and others for their effort
   to move things forward on the Windows front.  Although my
   repository does not have much from the effort of MinGW team,
   I expect a merge into mainline will happen so that everybody
   can work from the same codebase.

 - People on non-Linux platforms for keeping their eyes on
   portability; especially, Randal Schwartz, Theodore Ts'o,
   Jason Riedy, Thomas Glanzmann, but countless others as well.

* This document

The latest copy of this document is found in git.git repository,
on 'todo' branch, as MaintNotes.

A note from the maintainer

[Junio C Hamano]

Welcome to git community.

This message talks about how git.git is managed, and how you can work
with it.

* IRC and Mailing list

Many active members of development community hang around on #git
IRC channel on Freenode.  Its log is available at:

        http://colabti.de/irclogger/irclogger_log/git

The development however is primarily done on the git mailing list
(git@vger.kernel.org).  If you have patches, please send them to the
list, following Documentation/SubmittingPatches.

I usually try to read all patches posted to the list, and follow
almost all the discussions on the list, unless the topic is about an
obscure corner that I do not personally use.  But I am obviously not
perfect.  If you sent a patch that you did not hear from anybody for
three days, that is a very good indication that it was dropped on the
floor --- please do not hesitate to remind me.

The list archive is available at a few public sites as well:

        http://news.gmane.org/gmane.comp.version-control.git/
        http://marc.theaimsgroup.com/?l=git
        http://www.spinics.net/lists/git/

and some people seem to prefer to read it over NNTP:

        nntp://news.gmane.org/gmane.comp.version-control.git

When you point at a message in a mailing list archive, using
gmane is often the easiest to follow by readers, like this:

        http://thread.gmane.org/gmane.comp.version-control.git/27/focus=217

as it also allows people who subscribe to the mailing list as
gmane newsgroup to "jump to" the article.

* Repositories, branches and documentation.

My public git.git repository is at:

        git://git.kernel.org/pub/scm/git/git.git/

Immediately after I publish to the primary repository at kernel.org, I
also push into an alternate here:

        git://repo.or.cz/alt-git.git/

Impatient people might have better luck with the latter one.

Their gitweb interfaces are found at:

        http://git.kernel.org/?p=git/git.git
        http://repo.or.cz/w/alt-git.git

There are three branches in git.git repository that are not
about the source tree of git: "todo", "html" and "man".  The
first one was meant to contain TODO list for me, but I am not
good at maintaining such a list and it is not as often updated as
it could/should be.  It also contains some helper scripts I use
to maintain git.

The "html" and "man" are autogenerated documentation from the
tip of the "master" branch; the tip of "html" is extracted to be
visible at kernel.org at:

        http://www.kernel.org/pub/software/scm/git/docs/

The above URL is the top-level documentation page, and it has
links to documentation of older releases.

The script to maintain these two documentation branches are
found in "todo" branch as dodoc.sh, if you are interested.  It
is a good demonstration of how to use an update hook to automate
a task.

There are four branches in git.git repository that track the
source tree of git: "master", "maint", "next", and "pu".  I may
add more maintenance branches (e.g. "maint-1.5.3") if we have
hugely backward incompatible feature updates in the future to keep
an older release alive; I may not, but the distributed nature of
git means any volunteer can run a stable-tree like that herself.

The "master" branch is meant to contain what are very well
tested and ready to be used in a production setting.  There
could occasionally be minor breakages or brown paper bag bugs
but they are not expected to be anything major, and more
importantly quickly and trivially fixable.  Every now and
then, a "feature release" is cut from the tip of this branch and
they typically are named with three dotted decimal digits.  The
last such release was 1.5.4 done on Feb 2nd this year.  You
can expect that the tip of the "master" branch is always more
stable than any of the released versions.

Whenever a feature release is made, "maint" branch is forked off
from "master" at that point.  Obvious, safe and urgent fixes
after a feature release are applied to this branch and
maintenance releases are cut from it.  The maintenance releases
are named with four dotted decimal, named after the feature
release they are updates to; the last such release was 1.5.4.4.
New features never go to this branch.  This branch is also
merged into "master" to propagate the fixes forward.

A trivial and safe enhancement goes directly on top of "master".
A new development, either initiated by myself or more often by
somebody who found his or her own itch to scratch, does not
usually happen on "master", however.  Instead, a separate topic
branch is forked from the tip of "master", and it first is
tested in isolation; I may make minimum fixups at this point.
Usually there are a handful such topic branches that are running
ahead of "master" in git.git repository.  I do not publish the
tip of these branches in my public repository, however, partly
to keep the number of branches that downstream developers need
to worry about low, and primarily because I am lazy.

The quality of topic branches are judged primarily by the mailing list
discussions.  Some of them start out as "good idea but obviously is
broken in some areas (e.g. breaks the existing testsuite)" and then
with some more work (either by the original contributor's effort or
help from other people on the list) becomes "more or less done and can
now be tested by wider audience".  Luckily, most of them start out in
the latter, better shape.

The "next" branch is to merge and test topic branches in the
latter category.  In general, the branch always contains the tip
of "master".  It might not be quite rock-solid production ready,
but is expected to work more or less without major breakage.  I
usually use "next" version of git for my own work, so it cannot
be _that_ broken to prevent me from pushing the changes out.
The "next" branch is where new and exciting things take place.

The two branches "master" and "maint" are never rewound, and
"next" usually will not be either (this automatically means the
topics that have been merged into "next" are usually not
rebased, and you can find the tip of topic branches you are
interested in from the output of "git log next"). You should be
able to safely track them.

After a feature release is made from "master", however, "next"
will be rebuilt from the tip of "master" using the surviving
topics.  The commit that replaces the tip of the "next" will
have the identical tree, but it will have different ancestry
from the tip of "master".  An announcement will be made to warn
people about such a rebasing.

The "pu" (proposed updates) branch bundles all the remainder of
topic branches.  The "pu" branch, and topic branches that are
only in "pu", are subject to rebasing in general.  By the above
definition of how "next" works, you can tell that this branch
will contain quite experimental and obviously broken stuff.

When a topic that was in "pu" proves to be in testable shape, it
graduates to "next".  I do this with:

        git checkout next
        git merge that-topic-branch

Sometimes, an idea that looked promising turns out to be not so
good and the topic can be dropped from "pu" in such a case.

A topic that is in "next" is expected to be tweaked and fixed to
perfection before it is merged to "master" (that's why "master"
can be expected to stay very stable).  Similarly to the above, I
do it with this:

        git checkout master
        git merge that-topic-branch
        git branch -d that-topic-branch

Note that being in "next" is not a guarantee to appear in the
next release (being in "master" is such a guarantee, unless it
is later found seriously broken and reverted), or even in any
future release.  There even were cases that topics needed
reverting a few commits in them before graduating to "master",
or a topic that already was in "next" were entirely reverted
from "next" because fatal flaws were found in them later.

Starting from v1.5.0, "master" and "maint" have release notes
for the next release in Documentation/RelNotes-* files, so that
I do not have to run around summarizing what happened just
before the release.


* Other people's trees, trusted lieutenants and credits.

Documentation/SubmittingPatches outlines who your changes should
be sent to.  As described in contrib/README, I would delegate
fixes and enhancements in contrib/ area to primary contributors
of them.

Although the following are included in git.git repository, they
have their own authoritative repository and maintainers:

 - git-gui/ comes from Shawn Pearce's git-gui project:

        git://repo.or.cz/git-gui.git

 - gitk-git/ comes from Paul Mackerras's gitk project:

        git://git.kernel.org/pub/scm/gitk/gitk.git

I would like to thank everybody who helped to raise git into the
current shape.  Especially I would like to thank the git list
regulars whose help I have relied on and expect to continue
relying on heavily:

 - Linus on general design issues.

 - Linus, Shawn Pearce, Johannes Schindelin, Nicolas Pitre,
   René Scharfe and Jeff King on general implementation issues.

 - Shawn and Nicolas Pitre on pack issues.

 - Martin Langhoff and Frank Lichtenheld on cvsserver and cvsimport.

 - Paul Mackerras on gitk.

 - Eric Wong on git-svn.

 - Simon Hausmann on git-p4.

 - Jakub Narebski, Petr Baudis, and Luben Tuikov on gitweb.

 - J. Bruce Fields on documentaton issues.

 - Johannes Schindelin, Johannes Sixt and others for their effort
   to move things forward on the Windows front.  Although my
   repository does not have much from the effort of MinGW team,
   I expect a merge into mainline will happen so that everybody
   can work from the same codebase.

 - People on non-Linux platforms for keeping their eyes on
   portability; especially, Randal Schwartz, Theodore Ts'o,
   Jason Riedy, Thomas Glanzmann, but countless others as well.

* This document

The latest copy of this document is found in git.git repository,
on 'todo' branch, as MaintNotes.

A note from the maintainer

[Junio C Hamano]

Now a new feature release is out, it's a good time to welcome new
people to the list.  This message talks about how git.git is managed,
and how you can work with it.

* IRC and Mailing list

Many active members of development community hang around on #git
IRC channel on Freenode.  Its log is available at:

        http://colabti.de/irclogger/irclogger_log/git

The development however is primarily done on this mailing list
you are reading right now.  If you have patches, please send
them to the list, following Documentation/SubmittingPatches.

I usually try to read all patches posted to the list, and follow
almost all the discussions on the list, unless the topic is about an
obscure corner that I do not personally use.  But I am obviously not
perfect.  If you sent a patch that you did not hear from anybody for
three days, that is a very good indication that it was dropped on the
floor --- please do not hesitate to remind me.

The list archive is available at a few public sites as well:

        http://news.gmane.org/gmane.comp.version-control.git/
        http://marc.theaimsgroup.com/?l=git
        http://www.spinics.net/lists/git/

and some people seem to prefer to read it over NNTP:

        nntp://news.gmane.org/gmane.comp.version-control.git

When you point at a message in a mailing list archive, using
gmane is often the easiest to follow by readers, like this:

        http://thread.gmane.org/gmane.comp.version-control.git/27/focus=217

as it also allows people who subscribe to the mailing list as
gmane newsgroup to "jump to" the article.

* Repositories, branches and documentation.

My public git.git repository is at:

        git://git.kernel.org/pub/scm/git/git.git/

Immediately after I publish to the primary repository at kernel.org, I
also push into an alternate here:

        git://repo.or.cz/alt-git.git/

Impatient people might have better luck with the latter one.

Their gitweb interfaces are found at:

        http://git.kernel.org/?p=git/git.git
        http://repo.or.cz/w/alt-git.git

There are three branches in git.git repository that are not
about the source tree of git: "todo", "html" and "man".  The
first one was meant to contain TODO list for me, but I am not
good at maintaining such a list so it is not as often updated as
it could/should be.  It also contains some helper scripts I use
to maintain git.

The "html" and "man" are autogenerated documentation from the
tip of the "master" branch; the tip of "html" is extracted to be
visible at kernel.org at:

        http://www.kernel.org/pub/software/scm/git/docs/

The above URL is the top-level documentation page, and it has
links to documentation of older releases.

The script to maintain these two documentation branches are
found in "todo" branch as dodoc.sh, if you are interested.  It
is a good demonstration of how to use an update hook to automate
a task.

There are four branches in git.git repository that track the
source tree of git: "master", "maint", "next", and "pu".  I may
add more maintenance branches (e.g. "maint-1.5.1") if we have
hugely backward incompatible feature updates in the future to keep
an older release alive; I may not, but the distributed nature of
git means any volunteer can run a stable-tree like that himself.

The "master" branch is meant to contain what are very well
tested and ready to be used in a production setting.  There
could occasionally be minor breakages or brown paper bag bugs
but they are not expected to be anything major, and more
importantly quickly and trivially fixable.  Every now and
then, a "feature release" is cut from the tip of this branch and
they typically are named with three dotted decimal digits.  The
last such release was v1.5.4 done on Feb 2nd this year.  You
can expect that the tip of the "master" branch is always more
stable than any of the released versions.

Whenever a feature release is made, "maint" branch is forked off
from "master" at that point.  Obvious, safe and urgent fixes
after a feature release are applied to this branch and
maintenance releases are cut from it.  The maintenance releases
are named with four dotted decimal, named after the feature
release they are updates to; the last such release was v1.5.3.8.
New features never go to this branch.  This branch is also
merged into "master" to propagate the fixes forward.

A trivial and safe enhancement goes directly on top of "master".
A new development, either initiated by myself or more often by
somebody who found his or her own itch to scratch, does not
usually happen on "master", however.  Instead, a separate topic
branch is forked from the tip of "master", and it first is
tested in isolation; I may make minimum fixups at this point.
Usually there are a handful such topic branches that are running
ahead of "master" in git.git repository.  I do not publish the
tip of these branches in my public repository, however, partly
to keep the number of branches that downstream developers need
to worry about low, and primarily because I am lazy.

I judge the quality of topic branches, taking advices from the
mailing list discussions.  Some of them start out as "good idea
but obviously is broken in some areas (e.g. breaks the existing
testsuite)" and then with some more work (either by the original
contributor or help from other people on the list) becomes "more
or less done and can now be tested by wider audience".  Luckily,
most of them start out in the latter, better shape.

The "next" branch is to merge and test topic branches in the
latter category.  In general, the branch always contains the tip
of "master".  It might not be quite rock-solid production ready,
but is expected to work more or less without major breakage.  I
usually use "next" version of git for my own work, so it cannot
be _that_ broken to prevent me from pushing the changes out.
The "next" branch is where new and exciting things take place.

The above three branches, "master", "maint" and "next" are never
rewound, so you should be able to safely track them (this
automatically means the topics that have been merged into "next"
are never rebased, and you can find the tip of topic branches you
are interested in from the output of "git log next").

The "pu" (proposed updates) branch bundles all the remainder of
topic branches.  The "pu" branch, and topic branches that are
only in "pu", are subject to rebasing in general.  By the above
definition of how "next" works, you can tell that this branch
will contain quite experimental and obviously broken stuff.

When a topic that was in "pu" proves to be in testable shape, it
graduates to "next".  I do this with:

        git checkout next
        git merge that-topic-branch

Sometimes, an idea that looked promising turns out to be not so
good and the topic can be dropped from "pu" in such a case.

A topic that is in "next" is expected to be tweaked and fixed to
perfection before it is merged to "master" (that's why "master"
can be expected to stay very stable).  Similarly to the above, I
do it with this:

        git checkout master
        git merge that-topic-branch
        git branch -d that-topic-branch

Note that being in "next" is not a guarantee to appear in the
next release (being in "master" is such a guarantee, unless it
is later found seriously broken and reverted), or even in any
future release.  There even were cases that topics needed
reverting a few commits in them before graduating to "master",
or a topic that already was in "next" were entirely reverted
from "next" because fatal flaws were found in them later.

Starting from v1.5.0, "master" and "maint" have release notes
for the next release in Documentation/RelNotes-* files, so that
I do not have to run around summarizing what happened just
before the release.


* Other people's trees, trusted lieutenants and credits.

Documentation/SubmittingPatches outlines who your changes should
be sent to.  As described in contrib/README, I would delegate
fixes and enhancements in contrib/ area to primary contributors
of them.

Although the following are included in git.git repository, they
have their own authoritative repository and maintainers:

 git-gui/ -- this subdirectory comes from Shawn Pearce's git-gui
             project, which is found at:

             git://repo.or.cz/git-gui.git

 gitk     -- this file is maintained by Paul Mackerras, at:

             git://git.kernel.org/pub/scm/gitk/gitk.git

I would like to thank everybody who helped to raise git into the
current shape.  Especially I would like to thank the git list
regulars whose help I have relied on and expect to continue
relying on heavily:

 - Linus on general design issues.

 - Linus, Shawn Pearce, Johannes Schindelin, Nicolas Pitre,
   Réne Scharfe and Jeff King on general implementation issues.

 - Shawn and Nicolas Pitre on pack issues.

 - Martin Langhoff and Frank Lichtenheld on cvsserver and cvsimport.

 - Paul Mackerras on gitk.

 - Eric Wong on git-svn.

 - Jakub Narebski, Petr Baudis, and Luben Tuikov on gitweb.

 - J. Bruce Fields on documentaton issues.

 - Johannes Schindelin and Johannes Sixt for their effort to
   move things forward on the Windows front.  Although my
   repository does not have much from the effort of MinGW team,
   I expect a merge into mainline will happen so that everybody
   can work from the same codebase.

 - People on non-Linux platforms for keeping their eyes on
   portability; especially, Randal Schwartz, Theodore Ts'o,
   Jason Riedy, Thomas Glanzmann, but countless others as well.

* This document

The latest copy of this document is found in git.git repository,
on 'todo' branch, as MaintNotes.

Re: A note from the maintainer

[Jakub Narebski]

Junio C Hamano <gitster@pobox.com> writes:

> Now a new feature release is out, it's a good time to welcome new
> people to the list.  This message talks about how git.git is managed,
> and how you can work with it.

> There are four branches in git.git repository that track the
> source tree of git: "master", "maint", "next", and "pu".

Actually there are five: you didn't mention "offcuts" branch,
nor wrote what this branch is about (for example how it differs
from "pu").

>  gitk     -- this file is maintained by Paul Mackerras, at:
> 
>              git://git.kernel.org/pub/scm/gitk/gitk.git

It is gitk-git/ subdirectory now (why not simply gitk/ ?).

-- 
Jakub Narebski
Poland
ShadeHawk on #git

A note from the maintainer

[Junio C Hamano]

Now a new maitenance release is out and we are reasonably in a
good shape to expect smooth progress toward the next feature
release, it's a good time to welcome new people to the list.
This message talks about how git.git is managed, and how you can
work with it.

* IRC and Mailing list

Many active members of development community hang around on #git
IRC channel on Freenode.  Its log is available at:

        http://colabti.de/irclogger/irclogger_log/git

The development however is primarily done on this mailing list
you are reading right now.  If you have patches, please send
them to the list, following Documentation/SubmittingPatches.

I usually try to read all patches posted to the list, and follow
almost all the discussions on the list, unless the topic is about an
obscure corner that I do not personally use.  But I am obviously not
perfect.  If you sent a patch that you did not hear from anybody for
three days, that is a very good indication that it was dropped on the
floor --- please do not hesitate to remind me.

The list archive is available at a few public sites as well:

        http://news.gmane.org/gmane.comp.version-control.git/
        http://marc.theaimsgroup.com/?l=git
        http://www.spinics.net/lists/git/

and some people seem to prefer to read it over NNTP:

        nntp://news.gmane.org/gmane.comp.version-control.git

When you point at a message in a mailing list archive, using
gmane is often the easiest to follow by readers, like this:

        http://thread.gmane.org/gmane.comp.version-control.git/27/focus=217

as it also allows people who subscribe to the mailing list as
gmane newsgroup to "jump to" the article.

* Repositories, branches and documentation.

My public git.git repository is at:

        git://git.kernel.org/pub/scm/git/git.git/

Immediately after I publish to the primary repository at kernel.org, I
also push into an alternate here:

        git://repo.or.cz/alt-git.git/

Impatient people might have better luck with the latter one.

Their gitweb interfaces are found at:

        http://git.kernel.org/?p=git/git.git
        http://repo.or.cz/w/alt-git.git

There are three branches in git.git repository that are not
about the source tree of git: "todo", "html" and "man".  The
first one was meant to contain TODO list for me, but I am not
good at maintaining such a list so it is not as often updated as
it could/should be.  It also contains some helper scripts I use
to maintain git.

The "html" and "man" are autogenerated documentation from the
tip of the "master" branch; the tip of "html" is extracted to be
visible at kernel.org at:

        http://www.kernel.org/pub/software/scm/git/docs/

The above URL is the top-level documentation page, and it has
links to documentation of older releases.

The script to maintain these two documentation branches are
found in "todo" branch as dodoc.sh, if you are interested.  It
is a good demonstration of how to use an update hook to automate
a task.

There are four branches in git.git repository that track the
source tree of git: "master", "maint", "next", and "pu".  I may
add more maintenance branches (e.g. "maint-1.5.3") if we have
hugely backward incompatible feature updates in the future to keep
an older release alive; I may not, but the distributed nature of
git means any volunteer can run a stable-tree like that himself.

The "master" branch is meant to contain what are very well
tested and ready to be used in a production setting.  There
could occasionally be minor breakages or brown paper bag bugs
but they are not expected to be anything major, and more
importantly quickly and trivially fixable.  Every now and
then, a "feature release" is cut from the tip of this branch and
they typically are named with three dotted decimal digits.  The
last such release was v1.5.3 done on Sep 2nd last year.  You
can expect that the tip of the "master" branch is always more
stable than any of the released versions.

Whenever a feature release is made, "maint" branch is forked off
from "master" at that point.  Obvious, safe and urgent fixes
after a feature release are applied to this branch and
maintenance releases are cut from it.  The maintenance releases
are named with four dotted decimal, named after the feature
release they are updates to; the last such release was v1.5.3.8,
made tonight.  New features never go to this branch.  This
branch is also merged into "master" to propagate the fixes forward.

A trivial and safe enhancement goes directly on top of "master".
A new development, either initiated by myself or more often by
somebody who found his or her own itch to scratch, does not
usually happen on "master", however.  Instead, a separate topic
branch is forked from the tip of "master", and it first is
tested in isolation; I may make minimum fixups at this point.
Usually there are a handful such topic branches that are running
ahead of "master" in git.git repository.  I do not publish the
tip of these branches in my public repository, however, partly
to keep the number of branches that downstream developers need
to worry about low, and primarily because I am lazy.

I judge the quality of topic branches, taking advices from the
mailing list discussions.  Some of them start out as "good idea
but obviously is broken in some areas (e.g. breaks the existing
testsuite)" and then with some more work (either by the original
contributor or help from other people on the list) becomes "more
or less done and can now be tested by wider audience".  Luckily,
most of them start out in the latter, better shape.

The "next" branch is to merge and test topic branches in the
latter category.  In general, the branch always contains the tip
of "master".  It might not be quite rock-solid production ready,
but is expected to work more or less without major breakage.  I
usually use "next" version of git for my own work, so it cannot
be _that_ broken to prevent me from pushing the changes out.
The "next" branch is where new and exciting things take place.

The above three branches, "master", "maint" and "next" are never
rewound, so you should be able to safely track them (this
automatically means the topics that have been merged into "next"
are never rebased, and you can find the tip of topic branches you
are interested in from the output of "git log next").

The "pu" (proposed updates) branch bundles all the remainder of
topic branches.  The "pu" branch, and topic branches that are
only in "pu", are subject to rebasing in general.  By the above
definition of how "next" works, you can tell that this branch
will contain quite experimental and obviously broken stuff.

When a topic that was in "pu" proves to be in testable shape, it
graduates to "next".  I do this with:

        git checkout next
        git merge that-topic-branch

Sometimes, an idea that looked promising turns out to be not so
good and the topic can be dropped from "pu" in such a case.

A topic that is in "next" is expected to be tweaked and fixed to
perfection before it is merged to "master" (that's why "master"
can be expected to stay very stable).  Similarly to the above, I
do it with this:

        git checkout master
        git merge that-topic-branch
        git branch -d that-topic-branch

Note that being in "next" is not a guarantee to appear in the
next release (being in "master" is such a guarantee, unless it
is later found seriously broken and reverted), or even in any
future release.  There even were cases that topics needed
reverting a few commits in them before graduating to "master",
or a topic that already was in "next" were entirely reverted
from "next" because fatal flaws were found in them later.

Starting from v1.5.0, "master" and "maint" have release notes
for the next release in Documentation/RelNotes-* files, so that
I do not have to run around summarizing what happened just
before the release.


* Other people's trees, trusted lieutenants and credits.

Documentation/SubmittingPatches outlines who your changes should
be sent to.  As described in contrib/README, I would delegate
fixes and enhancements in contrib/ area to primary contributors
of them.

Although the following are included in git.git repository, they
have their own authoritative repository and maintainers:

 git-gui/ -- this subdirectory comes from Shawn Pearce's git-gui
             project, which is found at:

             git://repo.or.cz/git-gui.git

 gitk     -- this file is maintained by Paul Mackerras, at:

             git://git.kernel.org/pub/scm/gitk/gitk.git

I would like to thank everybody who helped to raise git into the
current shape.  Especially I would like to thank the git list
regulars whose help I have relied on and expect to continue
relying on heavily:

 - Linus on general design issues.

 - Linus, Shawn Pearce, Johannes Schindelin, Nicolas Pitre,
   Réne Scharfe and Jeff King on general implementation issues.

 - Shawn and Nicolas Pitre on pack issues.

 - Martin Langhoff and Frank Lichtenheld on cvsserver and cvsimport.

 - Paul Mackerras on gitk.

 - Eric Wong on git-svn.

 - Jakub Narebski, Petr Baudis, and Luben Tuikov on gitweb.

 - J. Bruce Fields on documentaton issues.

 - Johannes Schindelin and Johannes Sixt for their effort to
   move things forward on the Windows front.  Although my
   repository does not have much from the effort of MinGW team,
   I expect a merge into mainline will happen so that everybody
   can work from the same codebase.

 - People on non-Linux platforms for keeping their eyes on
   portability; especially, Randal Schwartz, Theodore Ts'o,
   Jason Riedy, Thomas Glanzmann, but countless others as well.

* This document

The latest copy of this document is found in git.git repository,
on 'todo' branch, as MaintNotes.

Re: A note from the maintainer

[Jakub Narebski]

Junio C Hamano <gitster@pobox.com> writes:

> * IRC and Mailing list
 
> When you point at a message in a mailing list archive, using
> gmane is often the easiest to follow by readers, like this:
> 
>         http://thread.gmane.org/gmane.comp.version-control.git/27/focus=217
> 
> as it also allows people who subscribe to the mailing list as
> gmane newsgroup to "jump to" the article.

Isn't it better to give Message-ID (perhaps with addition to
some archive URLs)? This way one can search his/her own mail
archive; also (I think) all git mail archives support finding
article with given Message-ID (e.g. http://mid.gmane.org/<msg-id>
for GMane).
 
> * Repositories, branches and documentation.

> There are four branches in git.git repository that track the
> source tree of git: "master", "maint", "next", and "pu".  I may
> add more maintenance branches (e.g. "maint-1.5.3") if we have
> hugely backward incompatible feature updates in the future to keep
> an older release alive; I may not, but the distributed nature of
> git means any volunteer can run a stable-tree like that himself.

What about "offcuts" branch?

-- 
Jakub Narebski
Poland
ShadeHawk on #git

Re: A note from the maintainer

[Junio C Hamano]

Jakub Narebski <jnareb@gmail.com> writes:

> Junio C Hamano <gitster@pobox.com> writes:
>
>> * IRC and Mailing list
>  
>> When you point at a message in a mailing list archive, using
>> gmane is often the easiest to follow by readers, like this:
>> 
>>         http://thread.gmane.org/gmane.comp.version-control.git/27/focus=217
>> 
>> as it also allows people who subscribe to the mailing list as
>> gmane newsgroup to "jump to" the article.
>
> Isn't it better to give Message-ID (perhaps with addition to
> some archive URLs)?

Then please do so.  I have no problem with that.

But I am talking about practices of people who give pointer to
list archives as URL in this section, and I am just sick and
tired of seeing references to marc.info that does not give you
useful threaded interface.

> What about "offcuts" branch?

What about it?  It is not that relevant to people new to the
community.

[ANNOUNCE] GIT 1.5.3

[Junio C Hamano]

The latest feature release GIT 1.5.3 is available at the usual
places:

  http://www.kernel.org/pub/software/scm/git/

  git-1.5.3.tar.{gz,bz2}			(tarball)
  git-htmldocs-1.5.3.tar.{gz,bz2}		(preformatted docs)
  git-manpages-1.5.3.tar.{gz,bz2}		(preformatted docs)
  RPMS/$arch/git-*-1.5.3-1.$arch.rpm	(RPM)

GIT v1.5.3 Release Notes
========================

Updates since v1.5.2
--------------------

* The commit walkers other than http are officially deprecated,
  but still supported for now.

* The submodule support has Porcelain layer.

  Note that the current submodule support is minimal and this is
  deliberately so.  A design decision we made is that operations
  at the supermodule level do not recurse into submodules by
  default.  The expectation is that later we would add a
  mechanism to tell git which submodules the user is interested
  in, and this information might be used to determine the
  recursive behaviour of certain commands (e.g. "git checkout"
  and "git diff"), but currently we haven't agreed on what that
  mechanism should look like.  Therefore, if you use submodules,
  you would probably need "git submodule update" on the
  submodules you care about after running a "git checkout" at
  the supermodule level.

* There are a handful pack-objects changes to help you cope better
  with repositories with pathologically large blobs in them.

* For people who need to import from Perforce, a front-end for
  fast-import is in contrib/fast-import/.

* Comes with git-gui 0.8.2.

* Comes with updated gitk.

* New commands and options.

  - "git log --date=<format>" can use more formats: iso8601, rfc2822.

  - The hunk header output from "git diff" family can be customized
    with the attributes mechanism.  See gitattributes(5) for details.

  - "git stash" allows you to quickly save away your work in
    progress and replay it later on an updated state.

  - "git rebase" learned an "interactive" mode that let you
    pick and reorder which commits to rebuild.

  - "git fsck" can save its findings in $GIT_DIR/lost-found, without a
    separate invocation of "git lost-found" command.  The blobs stored by
    lost-found are stored in plain format to allow you to grep in them.

  - $GIT_WORK_TREE environment variable can be used together with
    $GIT_DIR to work in a subdirectory of a working tree that is
    not located at "$GIT_DIR/..".

  - Giving "--file=<file>" option to "git config" is the same as
    running the command with GIT_CONFIG=<file> environment.

  - "git log" learned a new option "--follow", to follow
    renaming history of a single file.

  - "git filter-branch" lets you rewrite the revision history of
    specified branches. You can specify a number of filters to
    modify the commits, files and trees.

  - "git cvsserver" learned new options (--base-path, --export-all,
    --strict-paths) inspired by "git daemon".

  - "git daemon --base-path-relaxed" can help migrating a repository URL
    that did not use to use --base-path to use --base-path.

  - "git commit" can use "-t templatefile" option and commit.template
    configuration variable to prime the commit message given to you in the
    editor.

  - "git submodule" command helps you manage the projects from
    the superproject that contain them.

  - In addition to core.compression configuration option,
    core.loosecompression and pack.compression options can
    independently tweak zlib compression levels used for loose
    and packed objects.

  - "git ls-tree -l" shows size of blobs pointed at by the
    tree entries, similar to "/bin/ls -l".

  - "git rev-list" learned --regexp-ignore-case and
    --extended-regexp options to tweak its matching logic used
    for --grep fitering.

  - "git describe --contains" is a handier way to call more
    obscure command "git name-rev --tags".

  - "git gc --aggressive" tells the command to spend more cycles
    to optimize the repository harder.

  - "git repack" learned a "window-memory" limit which
    dynamically reduces the window size to stay within the
    specified memory usage.

  - "git repack" can be told to split resulting packs to avoid
    exceeding limit specified with "--max-pack-size".

  - "git fsck" gained --verbose option.  This is really really
    verbose but it might help you identify exact commit that is
    corrupt in your repository.

  - "git format-patch" learned --numbered-files option.  This
    may be useful for MH users.

  - "git format-patch" learned format.subjectprefix configuration
    variable, which serves the same purpose as "--subject-prefix"
    option.

  - "git tag -n -l" shows tag annotations while listing tags.

  - "git cvsimport" can optionally use the separate-remote layout.

  - "git blame" can be told to see through commits that change
    whitespaces and indentation levels with "-w" option.

  - "git send-email" can be told not to thread the messages when
    sending out more than one patches.

  - "git send-email" can also be told how to find whom to cc the
    message to for each message via --cc-cmd.

  - "git config" learned NUL terminated output format via -z to
    help scripts.

  - "git add" learned "--refresh <paths>..." option to selectively refresh
    the cached stat information.

  - "git init -q" makes the command quieter.

  - "git -p command" now has a cousin of opposite sex, "git --no-pager
    command".

* Updated behavior of existing commands.

  - "gitweb" can offer multiple snapshot formats.

    ***NOTE*** Unfortunately, this changes the format of the
    $feature{snapshot}{default} entry in the per-site
    configuration file 'gitweb_config.perl'.  It used to be a
    three-element tuple that describe a single format; with the
    new configuration item format, you only have to say the name
    of the format ('tgz', 'tbz2' or 'zip').  Please update the
    your configuration file accordingly.

  - "git clone" uses -l (hardlink files under .git) by default when
    cloning locally.

  - URL used for "git clone" and friends can specify nonstandard SSH port
    by using sh://host:port/path/to/repo syntax.

  - "git bundle create" can now create a bundle without negative refs,
    i.e. "everything since the beginning up to certain points".

  - "git diff" (but not the plumbing level "git diff-tree") now
    recursively descends into trees by default.

  - "git diff" does not show differences that come only from
    stat-dirtiness in the form of "diff --git" header anymore.
    It runs "update-index --refresh" silently as needed.

  - "git tag -l" used to match tags by globbing its parameter as if it
    has wildcard '*' on both ends, which made "git tag -l gui" to match
    tag 'gitgui-0.7.0'; this was very annoying.  You now have to add
    asterisk on the sides you want to wildcard yourself.

  - The editor to use with many interactive commands can be
    overridden with GIT_EDITOR environment variable, or if it
    does not exist, with core.editor configuration variable.  As
    before, if you have neither, environment variables VISUAL
    and EDITOR are consulted in this order, and then finally we
    fall back on "vi".

  - "git rm --cached" does not complain when removing a newly
    added file from the index anymore.

  - Options to "git log" to affect how --grep/--author options look for
    given strings now have shorter abbreviations.  -i is for ignore case,
    and -E is for extended regexp.

  - "git log" learned --log-size to show the number of bytes in
    the log message part of the output to help qgit.

  - "git log --name-status" does not require you to give "-r" anymore.
    As a general rule, Porcelain commands should recurse when showing
    diff.

  - "git format-patch --root A" can be used to format everything
    since the beginning up to A.  This was supported with
    "git format-patch --root A A" for a long time, but was not
    properly documented.

  - "git svn dcommit" retains local merge information.

  - "git svnimport" allows an empty string to be specified as the
    trunk/ directory.  This is necessary to suck data from a SVN
    repository that doe not have trunk/ branches/ and tags/ organization
    at all.

  - "git config" to set values also honors type flags like --bool
    and --int.

  - core.quotepath configuration can be used to make textual git
    output to emit most of the characters in the path literally.

  - "git mergetool" chooses its backend more wisely, taking
    notice of its environment such as use of X, Gnome/KDE, etc.

  - "gitweb" shows merge commits a lot nicer than before.  The
    default view uses more compact --cc format, while the UI
    allows to choose normal diff with any parent.

  - snapshot files "gitweb" creates from a repository at
    $path/$project/.git are more useful.  We use $project part
    in the filename, which we used to discard.

  - "git cvsimport" creates lightweight tags; there is no
    interesting information we can record in an annotated tag,
    and the handcrafted ones the old code created was not
    properly formed anyway.

  - "git push" pretends that you immediately fetched back from
    the remote by updating corresponding remote tracking
    branches if you have any.

  - The diffstat given after a merge (or a pull) honors the
    color.diff configuration.

  - "git commit --amend" is now compatible with various message source
    options such as -m/-C/-c/-F.

  - "git apply --whitespace=strip" removes blank lines added at
    the end of the file.

  - "git fetch" over git native protocols with "-v" option shows
    connection status, and the IP address of the other end, to
    help diagnosing problems.

  - We used to have core.legacyheaders configuration, when
    set to false, allowed git to write loose objects in a format
    that mimicks the format used by objects stored in packs.  It
    turns out that this was not so useful.  Although we will
    continue to read objects written in that format, we do not
    honor that configuration anymore and create loose objects in
    the legacy/traditional format.

  - "--find-copies-harder" option to diff family can now be
    spelled as "-C -C" for brevity.

  - "git mailsplit" (hence "git am") can read from Maildir
    formatted mailboxes.

  - "git cvsserver" does not barf upon seeing "cvs login"
    request.

  - "pack-objects" honors "delta" attribute set in
    .gitattributes.  It does not attempt to deltify blobs that
    come from paths with delta attribute set to false.

  - "new-workdir" script (in contrib) can now be used with a
    bare repository.

  - "git mergetool" learned to use gvimdiff.

  - "gitview" (in contrib) has a better blame interface.

  - "git log" and friends did not handle a commit log message
    that is larger than 16kB; they do now.

  - "--pretty=oneline" output format for "git log" and friends
    deals with "malformed" commit log messages that have more
    than one lines in the first paragraph better.  We used to
    show the first line, cutting the title at mid-sentence; we
    concatenate them into a single line and treat the result as
    "oneline".

  - "git p4import" has been demoted to contrib status.  For
    a superior option, checkout the "git p4" front end to
    "git fast-import" (also in contrib).  The man page and p4
    rpm have been removed as well.

  - "git mailinfo" (hence "am") now tries to see if the message
    is in utf-8 first, instead of assuming iso-8859-1, if
    incoming e-mail does not say what encoding it is in.

* Builds

  - old-style function definitions (most notably, a function
    without parameter defined with "func()", not "func(void)")
    have been eradicated.

  - "git tag" and "git verify-tag" have been rewritten in C.

* Performance Tweaks

  - "git pack-objects" avoids re-deltification cost by caching
    small enough delta results it creates while looking for the
    best delta candidates.

  - "git pack-objects" learned a new heuristcs to prefer delta
    that is shallower in depth over the smallest delta
    possible.  This improves both overall packfile access
    performance and packfile density.

  - diff-delta code that is used for packing has been improved
    to work better on big files.

  - when there are more than one pack files in the repository,
    the runtime used to try finding an object always from the
    newest packfile; it now tries the same packfile as we found
    the object requested the last time, which exploits the
    locality of references.

  - verifying pack contents done by "git fsck --full" got boost
    by carefully choosing the order to verify objects in them.

  - "git read-tree -m" to read into an already populated index
    has been optimized vastly.  The effect of this can be seen
    when switching branches that have differences in only a
    handful paths.

  - "git add paths..." and "git commit paths..." has also been
    heavily optimized.

Fixes since v1.5.2
------------------

All of the fixes in v1.5.2 maintenance series are included in
this release, unless otherwise noted.

* Bugfixes

  - "gitweb" had trouble handling non UTF-8 text with older
    Encode.pm Perl module.

  - "git svn" misparsed the data from the commits in the repository when
    the user had "color.diff = true" in the configuration.  This has been
    fixed.

  - There was a case where "git svn dcommit" clobbered changes made on the
    SVN side while committing multiple changes.

  - "git-write-tree" had a bad interaction with racy-git avoidance and
    gitattributes mechanisms.

  - "git --bare command" overrode existing GIT_DIR setting and always
    made it treat the current working directory as GIT_DIR.

  - "git ls-files --error-unmatch" does not complain if you give the
    same path pattern twice by mistake.

  - "git init" autodetected core.filemode but not core.symlinks, which
    made a new directory created automatically by "git clone" cumbersome
    to use on filesystems that require these configurations to be set.

  - "git log" family of commands behaved differently when run as "git
    log" (no pathspec) and as "git log --" (again, no pathspec).  This
    inconsistency was introduced somewhere in v1.3.0 series but now has
    been corrected.

  - "git rebase -m" incorrectly displayed commits that were skipped.

----------------------------------------------------------------

Shortlog since v1.5.2.5 is too long, so I'll list just the names
of contributors here and thank everybody.

Adam Roben: 5
Alberto Bertogli: 1
Alecs King: 1
Alexandre Julliard: 9
Alexandre Vassalotti: 1
Alex Riesen: 27
Andrew Ruder: 2
Andy Whitcroft: 3
Aneesh Kumar K.V: 2
Arjen Laarhoven: 2
Benjamin Sergeant: 1
Bradford C. Smith: 2
Brian Downing: 13
Brian Gernhardt: 5
Brian Hetro: 5
Carlos Rica: 13
Christian Stimming: 1
CJ van den Berg: 1
Dana L. How: 8
Daniel Barkalow: 8
Dan McGee: 1
Dave O'Neill: 1
Dave Watson: 1
David Kågedal: 1
David Kastrup: 16
David Soria Parra: 1
David Symonds: 1
Elvis Pranskevichus: 1
Emil Medve: 2
Eric Wong: 11
Fernando J. Pereda: 1
Francis Moreau: 1
Frank Lichtenheld: 12
Geert Bosch: 1
Gerrit Pape: 5
Giuseppe Bilotta: 2
Greg KH: 1
Han-Wen Nienhuys: 30
Ismail Dönmez: 1
Jakub Narebski: 27
James Bowes: 3
Jari Aalto: 1
J. Bruce Fields: 9
Jeff King: 14
Jeffrey C. Ollie: 2
Jens Axboe: 1
Jim Meyering: 6
Joe Perches: 1
Johan Herland: 1
Johannes Schindelin: 77
Johannes Sixt: 14
Jonas Fonseca: 3
Jon Loeliger: 1
Josh Triplett: 2
Julian Phillips: 3
Junio C Hamano: 160
Jyotirmoy Bhattacharya: 1
Kevin Green: 1
Kristian Høgsberg: 1
Kumar Gala: 1
Lars Hjemli: 12
Linus Torvalds: 21
Luben Tuikov: 1
Luiz Fernando N. Capitulino: 3
Lukas Sandström: 1
Marco Costalba: 3
Marcus Fritzsch: 1
Marius Storm-Olsen: 8
Mark Levedahl: 13
martin f. krafft: 2
Martin Koegler: 5
Martin Waitz: 1
Matthias Lederhofer: 21
Matthieu Moy: 2
Matthijs Melchior: 1
Matt Kraai: 3
Matt McCutchen: 4
Michael Ellerman: 2
Michael Hendricks: 2
Michael Krelin: 1
Michael S. Tsirkin: 1
Mike Hommey: 2
Miklos Vajna: 2
Miles Bader: 1
Nanako Shiraishi: 5
Nguyễn Thái Ngọc Duy: 1
Nicolas Pitre: 14
Paul Mackerras: 37
Peter Hagervall: 1
Petr Baudis: 6
Pierre Habouzit: 3
Quy Tonthat: 2
Randal L. Schwartz: 2
Reece H. Dunn: 1
René Scharfe: 10
Richard MUSIL: 1
Robert Ewald: 1
Robert Schiele: 2
Robin Rosenberg: 5
Sam Vilain: 3
Scott Lamb: 2
Sean Estabrooks: 6
Seth Falcon: 1
Shawn O. Pearce: 140
Simon Hausmann: 231
Stefan Sperling: 1
Steffen Prohaska: 3
Stephen Rothwell: 1
Steve Hoelzer: 3
Steven Grimm: 4
Steven Walter: 1
Sven Verdoolaege: 7
Theodore Ts'o: 4
Thomas Schwinge: 2
Tom Clarke: 1
Uwe Kleine-König: 5
Väinö Järvelä: 1

A note from the maintainer

[Junio C Hamano]

Now a new feature release is out, it's a good time to welcome new
people to the list.  This message talks about how git.git is managed,
and how you can work with it.

* IRC and Mailing list

Many active members of development community hang around on #git
IRC channel on Freenode.  Its log is available at:

        http://colabti.de/irclogger/irclogger_log/git

The development however is primarily done on this mailing list
you are reading right now.  If you have patches, please send
them to the list, following Documentation/SubmittingPatches.

I usually try to read all patches posted to the list, and follow
almost all the discussions on the list, unless the topic is about an
obscure corner that I do not personally use.  But I am obviously not
perfect.  If you sent a patch that you did not hear from anybody for
three days, that is a very good indication that it was dropped on the
floor --- please do not hesitate to remind me.

The list archive is available at a few public sites as well:

        http://marc.theaimsgroup.com/?l=git
        http://news.gmane.org/gmane.comp.version-control.git
	http://www.spinics.net/lists/git/

and some people seem to prefer to read it over NNTP:

        nntp://news.gmane.org/gmane.comp.version-control.git

* Repositories, branches and documentation.

My public git.git repository is at:

        git://git.kernel.org/pub/scm/git/git.git/

Immediately after I publish to the primary repository at kernel.org, I
also push into an alternate here:

        git://repo.or.cz/alt-git.git/

Impatient people might have better luck with the latter one.

Their gitweb interfaces are found at:

	http://git.kernel.org/?p=git/git.git
	http://repo.or.cz/w/alt-git.git

There are three branches in git.git repository that are not
about the source tree of git: "todo", "html" and "man".  The
first one was meant to contain TODO list for me, but I am not
good at maintaining such a list so it is not as often updated as
it could/should be.  It also contains some helper scripts I use
to maintain git.

The "html" and "man" are autogenerated documentation from the
tip of the "master" branch; the tip of "html" is extracted to be
visible at kernel.org at:

        http://www.kernel.org/pub/software/scm/git/docs/

The above URL is the top-level documentation page, and it has
links to documentation of older releases.

The script to maintain these two documentation branches are
found in "todo" branch as dodoc.sh, if you are interested.  It
is a good demonstration of how to use an update hook to automate
a task.

There are four branches in git.git repository that track the
source tree of git: "master", "maint", "next", and "pu".  I may
add more maintenance branches (e.g. "maint-1.5.1") if we have
huge backward incompatible feature updates in the future to keep
an older release alive; I may not, but the distributed nature of
git means any volunteer can run a stable-tree like that himself.

The "master" branch is meant to contain what are very well
tested and ready to be used in a production setting.  There
could occasionally be minor breakages or brown paper bag bugs
but they are not expected to be anything major.  Every now and
then, a "feature release" is cut from the tip of this branch and
they typically are named with three dotted decimal digits.  The
last such release was v1.5.3 done on Sep 2nd this year.  You
can expect that the tip of the "master" branch is always as
stable as any of the released versions, if not more stable.

Whenever a feature release is made, "maint" branch is forked off
from "master" at that point.  Obvious, safe and urgent fixes
after a feature release are applied to this branch and
maintenance releases are cut from it.  The maintenance releases
are named with four dotted decimal, named after the feature
release they are updates to; the last such release was v1.5.2.5.
New features never go to this branch.  This branch is also
merged into "master" to propagate the fixes forward.

A trivial and safe enhancement goes directly on top of "master".
A new development, either initiated by myself or more often by
somebody who found his or her own itch to scratch, does not
usually happen on "master", however.  Instead, a separate topic
branch is forked from the tip of "master", and it first is
tested in isolation; I may make minimum fixups at this point.
Usually there are a handful such topic branches that are running
ahead of "master" in git.git repository.  I do not publish the
tip of these branches in my public repository, however, partly
to keep the number of branches that downstream developers need
to worry about low, and primarily because I am lazy.

I judge the quality of topic branches, taking advices from the
mailing list discussions.  Some of them start out as "good idea
but obviously is broken in some areas (e.g. breaks the existing
testsuite)" and then with some more work (either by the original
contributor or help from other people on the list) becomes "more
or less done and can now be tested by wider audience".  Luckily,
most of them start out in the latter, better shape.

The "next" branch is to merge and test topic branches in the
latter category.  In general, the branch always contains the tip
of "master".  It might not be quite rock-solid production ready,
but is expected to work more or less without major breakage.  I
usually use "next" version of git for my own work, so it cannot
be _that_ broken to prevent me from pushing the changes out.
The "next" branch is where new and exciting things take place.
Note that being in "next" does not mean the change will be in
the next feature release.

The above three branches, "master", "maint" and "next" are never
rewound, so you should be able to safely track them (this
automatically means the topics that have been merged into "next"
are not rebased, and you can find the tip of topic branches you
are interested in from the output of "git log next").

The "pu" (proposed updates) branch bundles all the remainder of
topic branches.  The "pu" branch, and topic branches that are
only in "pu", are subject to rebasing in general.  By the above
definition of how "next" works, you can tell that this branch
will contain quite experimental and obviously broken stuff.

When a topic that was in "pu" proves to be in testable shape, it
graduates to "next".  I do this with:

        git checkout next
        git merge that-topic-branch

Sometimes, an idea that looked promising turns out to be not so
good and the topic can be dropped from "pu" in such a case.

A topic that is in "next" is expected to be tweaked and fixed to
perfection before it is merged to "master" (that's why "master"
can be expected to stay very stable).  Similarly to the above, I
do it with this:

        git checkout master
        git merge that-topic-branch
        git branch -d that-topic-branch

However, being in "next" is not a guarantee to appear in the
next release (being in "master" is such a guarantee, unless it
is later found seriously broken and reverted), or even in any
future release.  There even were cases that topics needed
reverting a few commits in them before graduating to "master",
or a topic that already was in "next" were entirely reverted
from "next" because fatal flaws were found in them later.

Starting from v1.5.0, "master" and "maint" have release notes
for the next release in Documentation/RelNotes-* files, so that
I do not have to run around summarizing what happened just
before the release.


* Other people's trees, trusted lieutenants and credits.

Documentation/SubmittingPatches outlines who your changes should
be sent to.  As described in contrib/README, I would delegate
fixes and enhancements in contrib/ area to primary contributors
of them.

Although the following are included in git.git repository, they
have their own authoritative repository and maintainers:

 git-gui/ -- this subdirectory comes from Shawn Pearce's git-gui
             project, which is found at:

             git://repo.or.cz/git-gui.git

 gitk     -- this file is maintained by Paul Mackerras, at:

             git://git.kernel.org/pub/scm/gitk/gitk.git

I would like to thank everybody who helped to raise git into the
current shape.  Especially I would like to thank the git list
regulars whose help I have relied on and expect to continue
relying on heavily:

 - Linus on general design issues.

 - Linus, Shawn Pearce, Johannes Schindelin, Nicolas Pitre, and
   Rene Scharfe on general implementation issues.

 - Shawn and Nicolas Pitre on pack issues.

 - Martin Langhoff and Frank Lichtenheld on cvsserver and cvsimport.

 - Paul Mackerras on gitk.

 - Eric Wong on git-svn.

 - Jakub Narebski, Petr Baudis, and Luben Tuikov on gitweb.

 - J. Bruce Fields on documentaton issues.

 - Johannes Schindelin and Johannes Sixt for their effort to
   move things forward on the Windows front.  Although my
   repository does not have much from the effort of MinGW team,
   I expect a merge into mainline will happen so that everybody
   can work from the same codebase.

 - People on non-Linux platforms for keeping their eyes on
   portability; especially, Randal Schwartz, Theodore Ts'o,
   Jason Riedy, Thomas Glanzmann, but countless others as well.

* This document

The latest copy of this document is found in git.git repository,
on 'todo' branch, as MaintNotes.

[ANNOUNCE] GIT 1.5.1

[Junio C Hamano]

The latest feature release GIT 1.5.1 is available at the usual
places:

  http://www.kernel.org/pub/software/scm/git/

  git-1.5.1.tar.{gz,bz2}			(tarball)
  git-htmldocs-1.5.1.tar.{gz,bz2}		(preformatted docs)
  git-manpages-1.5.1.tar.{gz,bz2}		(preformatted docs)
  RPMS/$arch/git-*-1.5.1-1.$arch.rpm	(RPM)

----------------------------------------------------------------
GIT v1.5.1 Release Notes
========================

Updates since v1.5.0
--------------------

* Deprecated commands and options.

  - git-diff-stages and git-resolve have been removed.

* New commands and options.

  - "git log" and friends take --reverse, which instructs them
    to give their output in the order opposite from their usual.
    They typically output from new to old, but with this option
    their output would read from old to new.  "git shortlog"
    usually lists older commits first, but with this option,
    they are shown from new to old.

  - "git log --pretty=format:<string>" to allow more flexible
    custom log output.

  - "git diff" learned --ignore-space-at-eol.  This is a weaker
    form of --ignore-space-change.

  - "git diff --no-index pathA pathB" can be used as diff
    replacement with git specific enhancements.

  - "git diff --no-index" can read from '-' (standard input).

  - "git diff" also learned --exit-code to exit with non-zero
    status when it found differences.  In the future we might
    want to make this the default but that would be a rather big
    backward incompatible change; it will stay as an option for
    now.

  - "git diff --quiet" is --exit-code with output turned off,
    meant for scripted use to quickly determine if there is any
    tree-level difference.

  - Textual patch generation with "git diff" without -w/-b
    option has been significantly optimized.  "git blame" got
    faster because of the same change.

  - "git log" and "git rev-list" has been optimized
    significantly when they are used with pathspecs.

  - "git branch --track" can be used to set up configuration
    variables to help it easier to base your work on branches
    you track from a remote site.

  - "git format-patch --attach" now emits attachments.  Use
    --inline to get an inlined multipart/mixed.

  - "git name-rev" learned --refs=<pattern>, to limit the tags
    used for naming the given revisions only to the ones
    matching the given pattern.

  - "git remote update" is to run "git fetch" for defined remotes
    to update tracking branches.

  - "git cvsimport" can now take '-d' to talk with a CVS
    repository different from what are recorded in CVS/Root
    (overriding it with environment CVSROOT does not work).

  - "git bundle" can help sneaker-netting your changes between
    repositories.

  - "git mergetool" can help 3-way file-level conflict
    resolution with your favorite graphical merge tools.

  - A new configuration "core.symlinks" can be used to disable
    symlinks on filesystems that do not support them; they are
    checked out as regular files instead.

  - You can name a commit object with its first line of the
    message.  The syntax to use is ':/message text'.  E.g.

    $ git show ":/object name: introduce ':/<oneline prefix>' notation"

    means the same thing as:

    $ git show 28a4d940443806412effa246ecc7768a21553ec7

  - "git bisect" learned a new command "run" that takes a script
    to run after each revision is checked out to determine if it
    is good or bad, to automate the bisection process.

  - "git log" family learned a new traversal option --first-parent,
    which does what the name suggests.


* Updated behavior of existing commands.

  - "git-merge-recursive" used to barf when there are more than
    one common ancestors for the merge, and merging them had a
    rename/rename conflict.  This has been fixed.

  - "git fsck" does not barf on corrupt loose objects.

  - "git rm" does not remove newly added files without -f.

  - "git archimport" allows remapping when coming up with git
    branch names from arch names.

  - git-svn got almost a rewrite.

  - core.autocrlf configuration, when set to 'true', makes git
    to convert CRLF at the end of lines in text files to LF when
    reading from the filesystem, and convert in reverse when
    writing to the filesystem.  The variable can be set to
    'input', in which case the conversion happens only while
    reading from the filesystem but files are written out with
    LF at the end of lines.  Currently, which paths to consider
    'text' (i.e. be subjected to the autocrlf mechanism) is
    decided purely based on the contents, but the plan is to
    allow users to explicitly override this heuristic based on
    paths.

  - The behavior of 'git-apply', when run in a subdirectory,
    without --index nor --cached were inconsistent with that of
    the command with these options.  This was fixed to match the
    behavior with --index.  A patch that is meant to be applied
    with -p1 from the toplevel of the project tree can be
    applied with any custom -p<n> option.  A patch that is not
    relative to the toplevel needs to be applied with -p<n>
    option with or without --index (or --cached).

  - "git diff" outputs a trailing HT when pathnames have embedded
    SP on +++/--- header lines, in order to help "GNU patch" to
    parse its output.  "git apply" was already updated to accept
    this modified output format since ce74618d (Sep 22, 2006).

  - "git cvsserver" runs hooks/update and honors its exit status.

  - "git cvsserver" can be told to send everything with -kb.

  - "git diff --check" also honors the --color output option.

  - "git name-rev" used to stress the fact that a ref is a tag too
    much, by saying something like "v1.2.3^0~22".  It now says
    "v1.2.3~22" in such a case (it still says "v1.2.3^0" if it does
    not talk about an ancestor of the commit that is tagged, which
    makes sense).

  - "git rev-list --boundary" now shows boundary markers for the
    commits omitted by --max-age and --max-count condition.

  - The configuration mechanism now reads $(prefix)/etc/gitconfig.

  - "git apply --verbose" shows what preimage lines were wanted
    when it couldn't find them.

  - "git status" in a read-only repository got a bit saner.

  - "git fetch" (hence "git clone" and "git pull") are less
    noisy when the output does not go to tty.

  - "git fetch" between repositories with many refs were slow
    even when there are not many changes that needed
    transferring.  This has been sped up by partially rewriting
    the heaviest parts in C.

  - "git mailinfo" which splits an e-mail into a patch and the
    meta-information was rewritten, thanks to Don Zickus.  It
    handles nested multipart better.  The command was broken for
    a brief period on 'master' branch since 1.5.0 but the
    breakage is fixed now.

  - send-email learned configurable bcc and chain-reply-to.

  - "git remote show $remote" also talks about branches that
    would be pushed if you run "git push remote".

  - Using objects from packs is now seriously optimized by clever
    use of a cache.  This should be most noticeable in git-log
    family of commands that involve reading many tree objects.
    In addition, traversing revisions while filtering changes
    with pathspecs is made faster by terminating the comparison
    between the trees as early as possible.


* Hooks

  - The part to send out notification e-mails was removed from
    the sample update hook, as it was not an appropriate place
    to do so.  The proper place to do this is the new post-receive
    hook.  An example hook has been added to contrib/hooks/.


* Others

  - git-revert, git-gc and git-cherry-pick are now built-ins.

Fixes since v1.5.0
------------------

These are all in v1.5.0.x series.

* Documentation updates

  - Clarifications and corrections to 1.5.0 release notes.

  - The main documentation did not link to git-remote documentation.

  - Clarified introductory text of git-rebase documentation.

  - Converted remaining mentions of update-index on Porcelain
    documents to git-add/git-rm.

  - Some i18n.* configuration variables were incorrectly
    described as core.*; fixed.

  - added and clarified core.bare, core.legacyheaders configurations.

  - updated "git-clone --depth" documentation.

  - user-manual updates.

  - Options to 'git remote add' were described insufficiently.

  - Configuration format.suffix was not documented.

  - Other formatting and spelling fixes.

  - user-manual has better cross references.

  - gitweb installation/deployment procedure is now documented.


* Bugfixes

  - git-upload-pack closes unused pipe ends; earlier this caused
    many zombies to hang around.

  - git-rerere was recording the contents of earlier hunks
    duplicated in later hunks.  This prevented resolving the same
    conflict when performing the same merge the other way around.

  - git-add and git-update-index on a filesystem on which
    executable bits are unreliable incorrectly reused st_mode
    bits even when the path changed between symlink and regular
    file.

  - git-daemon marks the listening sockets with FD_CLOEXEC so
    that it won't be leaked into the children.

  - segfault from git-blame when the mandatory pathname
    parameter was missing was fixed; usage() message is given
    instead.

  - git-rev-list did not read $GIT_DIR/config file, which means
    that did not honor i18n.logoutputencoding correctly.

  - Automated merge conflict handling when changes to symbolic
    links conflicted were completely broken.  The merge-resolve
    strategy created a regular file with conflict markers in it
    in place of the symbolic link.  The default strategy,
    merge-recursive was even more broken.  It removed the path
    that was pointed at by the symbolic link.  Both of these
    problems have been fixed.

  - 'git diff maint master next' did not correctly give combined
    diff across three trees.

  - 'git fast-import' portability fix for Solaris.

  - 'git show-ref --verify' without arguments did not error out
    but segfaulted.

  - 'git diff :tracked-file `pwd`/an-untracked-file' gave an extra
    slashes after a/ and b/.

  - 'git format-patch' produced too long filenames if the commit
    message had too long line at the beginning.

  - Running 'make all' and then without changing anything
    running 'make install' still rebuilt some files.  This
    was inconvenient when building as yourself and then
    installing as root (especially problematic when the source
    directory is on NFS and root is mapped to nobody).

  - 'git-rerere' failed to deal with two unconflicted paths that
    sorted next to each other.

  - 'git-rerere' attempted to open(2) a symlink and failed if
    there was a conflict.  Since a conflicting change to a
    symlink would not benefit from rerere anyway, the command
    now ignores conflicting changes to symlinks.

  - 'git-repack' did not like to pass more than 64 arguments
    internally to underlying 'rev-list' logic, which made it
    impossible to repack after accumulating many (small) packs
    in the repository.

  - 'git-diff' to review the combined diff during a conflicted
    merge were not reading the working tree version correctly
    when changes to a symbolic link conflicted.  It should have
    read the data using readlink(2) but read from the regular
    file the symbolic link pointed at.

  - 'git-remote' did not like period in a remote's name.

  - 'git.el' honors the commit coding system from the configuration.

  - 'blameview' in contrib/ correctly digs deeper when a line is
    clicked.

  - 'http-push' correctly makes sure the remote side has leading
    path.  Earlier it started in the middle of the path, and
    incorrectly.

  - 'git-merge' did not exit with non-zero status when the
    working tree was dirty and cannot fast forward.  It does
    now.

  - 'cvsexportcommit' does not lose yet-to-be-used message file.

  - int-vs-size_t typefix when running combined diff on files
    over 2GB long.

  - 'git apply --whitespace=strip' should not touch unmodified
    lines.

  - 'git-mailinfo' choke when a logical header line was too long.

  - 'git show A..B' did not error out.  Negative ref ("not A" in
    this example) does not make sense for the purpose of the
    command, so now it errors out.

  - 'git fmt-merge-msg --file' without file parameter did not
    correctly error out.

  - 'git archimport' barfed upon encountering a commit without
    summary.

  - 'git index-pack' did not protect itself from getting a short
    read out of pread(2).

  - 'git http-push' had a few buffer overruns.

  - Build dependency fixes to rebuild fetch.o when other headers
    change.

  - git.el does not add duplicate sign-off lines.

  - git-commit shows the full stat of the resulting commit, not
    just about the files in the current directory, when run from
    a subdirectory.

  - "git-checkout -m '@{8 hours ago}'" had a funny failure from
    eval; fixed.

  - git-merge (hence git-pull) did not refuse fast-forwarding
    when the working tree had local changes that would have
    conflicted with it.

  - a handful small fixes to gitweb.

  - build procedure for user-manual is fixed not to require locally
    installed stylesheets.

  - "git commit $paths" on paths whose earlier contents were
    already updated in the index were failing out.


* Tweaks

  - sliding mmap() inefficiently mmaped the same region of a
    packfile with an access pattern that used objects in the
    reverse order.  This has been made more efficient.

A note from the maintainer

[Junio C Hamano]

Now a new feature release is out, it's time to welcome new
people to the list.  This message talks about how git.git is
managed, and how you can work with it.

* IRC and Mailing list

Many active members of development community hang around on #git
IRC channel.  Its log is available at:

	http://colabti.de/irclogger/irclogger_log/git

The development however is primarily done on this mailing list
you are reading right now.  If you have patches, please send
them to the list, following Documentation/SubmittingPatches.

I usually read all patches posted to the list, and follow almost
all the discussions on the list, unless the topic is about an
obscure corner that I do not personally use.  But I am obviously
not perfect.  If you sent a patch that you did not hear from
anybody for three days, that is a very good indication that it
was dropped on the floor --- please do not hesitate to remind
me.

The list archive is available at a few public sites as well:

	http://marc.theaimsgroup.com/?l=git
	http://news.gmane.org/gmane.comp.version-control.git

and some people seem to prefer to read it over NNTP:

	nntp://news.gmane.org/gmane.comp.version-control.git


* Repositories, branches and documentation.

My public git.git repository is at:

	git://git.kernel.org/pub/scm/git/git.git/

This is mirrored at Pasky's site at

	git://repo.or.cz/git.git/

but the first has a few hours mirroring delay after I publish
updates, and the latter, being a mirror of former, lags behind
it further.  Immediately after I publish to the primary
repository at kernel.org, I also push into an alternate here:

	git://repo.or.cz/alt-git.git/

Impatient people would have better luck with the last one (but
the last repository does not have "html", "man" and "todo"
branches, described next).

There are three branches in git.git repository that are not
about the source tree of git: "todo", "html" and "man".  The
first one was meant to contain TODO list for me, but I am not
good at maintaining such a list so it is not as often updated as
it could/should be.  It also contains some helper scripts I use
to maintain git.

The "html" and "man" are autogenerated documentation from the
tip of the "master" branch; the tip of "html" is extracted to be
visible at kernel.org at:

	http://www.kernel.org/pub/software/scm/git/docs/

The above URL is the top-level documentation page, and it has
links to documentation of older releases.

The script to maintain these two documentation branches are
found in "todo" branch as dodoc.sh, if you are interested.  It
is a good demonstration of how to use an update hook to automate
a task.

There are four branches in git.git repository that track the
source tree of git: "master", "maint", "next", and "pu".

The "master" branch is meant to contain what are very well
tested and ready to be used in a production setting.  There
could occasionally be minor breakages or brown paper bag bugs
but they are not expected to be anything major.  Every now and
then, a "feature release" is cut from the tip of this branch and
they typically are named with three dotted decimal digits.  The
last such release was v1.5.1 done on April 4th this year.

Whenever a feature release is made, "maint" branch is forked off
from "master" at that point.  Obvious, safe and urgent fixes
after a feature release are applied to this branch and
maintenance releases are cut from it.  The maintenance releases
are named with four dotted decimal, named after the feature
release they are updates to; the last such release was v1.5.0.7.
New features never goes to this branch.  This branch is also
merged into "master" to propagate the fixes forward.

A trivial and safe enhancement goes directly on top of "master".
A new development, either initiated by myself or more often by
somebody who found his or her own itch to scratch, does not
usually happen on "master", however.  Instead, a separate topic
branch is forked from the tip of "master", and it first is
tested in isolation; I may make minimum fixups at this point.
Usually there are a handful such topic branches that are running
ahead of "master" in git.git repository.  I do not publish the
tip of these branches in my public repository, however, partly
to keep the number of branches that downstream developers need
to worry about low, and primarily because I am lazy.

I judge the quality of topic branches, taking advices from the
mailing list discussions.  Some of them start out as "good idea
but obviously is broken in some areas (e.g. breaks the existing
testsuite)" and then with some more work (either by the original
contributor or help from other people on the list) becomes "more
or less done and can now be tested by wider audience".  Luckily,
most of them start out in the latter, better shape.

The "next" branch is to merge and test topic branches in the
latter category.  In general, the branch always contains the tip
of "master".  It might not be quite rock-solid production ready,
but is expected to work more or less without major breakage.  I
usually use "next" version of git for my own work, so it cannot
be _that_ broken to prevent me from pushing the changes out.
The "next" branch is where new and exciting things take place.

The above three branches, "master", "maint" and "next" are never
rewound, so you should be able to safely track them (this
automatically means the topics that have been merged into "next"
are not rebased, and you can find the tip of topic branches you
are interested in out of "git log next" output).

The "pu" (proposed updates) branch bundles all the remainder of
topic branches.  The "pu" branch, and topic branches that are
only in "pu", are subject to rebasing in general.

When a topic that was in "pu" proves to be in testable shape, it
graduates to "next".  I do this with:

	git checkout next
        git merge that-topic-branch

Sometimes, an idea that looked promising turns out to be not so
hot and the topic can be dropped from "pu" in such a case.

A topic that is in "next" is expected to be tweaked and fixed to
perfection before it is merged to "master".  Similarly to the
above I do it with this:

	git checkout master
        git merge that-topic-branch
        git branch -d that-topic-branch

However, being in "next" is not a guarantee to appear in the
next release (being in "master" is such a guarantee, unless it
is later found seriously broken and reverted), or even in any
future release.  There even were cases that topics needed a few
reverting before graduating to "master", or a topic that already
was in "next" were reverted from "next" because fatal flaws were
found in them later.

Starting from v1.5.0, "master" and "maint" have release notes
for the next release in Documentation/RelNotes-* files, so that
I do not have to run around summarizing what happened just
before the release.


* Other people's trees, trusted lieutenants and credits.

Documentation/SubmittingPatches outlines who your changes should
be sent to.  As described in contrib/README, I would delegate
fixes and enhancements in contrib/ area to primary contributors
of them.

Although the following are included in git.git repository, they
have their own authoritative repository and maintainers:

 git-gui/ -- this subdirectory comes from Shawn Pearce's git-gui
             project, which is found at:

             git://repo.or.cz/git-gui.git

 gitk     -- this file is maintained by Paul Packerras, at:

	     git://git.kernel.org/pub/scm/gitk/gitk.git

I would like to thank everybody who helped to raise git into the
current shape.  Especially I would like to thank the git list
regulars whose help I have relied on and expect to continue
relying on heavily:

 - Linus on general design issues.

 - Linus, Shawn Pearce, Johannes Schindelin, Nicolas Pitre, and
   Rene Scharfe on general implementation issues.

 - Shawn and Nicolas Pitre on pack issues.

 - Martin Langhoff on cvsserver and cvsimport.

 - Paul Packerras on gitk.

 - Eric Wong on git-svn.

 - Jakub Narebski and Luben Tuikov on gitweb.

 - J. Bruce Fields on documentaton issues.

A note from the maintainer

[Junio C Hamano]

Now a new feature release is out, it's a good time to welcome new
people to the list.  This message talks about how git.git is managed,
and how you can work with it.

* IRC and Mailing list

Many active members of development community hang around on #git
IRC channel.  Its log is available at:

        http://colabti.de/irclogger/irclogger_log/git

The development however is primarily done on this mailing list
you are reading right now.  If you have patches, please send
them to the list, following Documentation/SubmittingPatches.

I usually try to read all patches posted to the list, and follow
almost all the discussions on the list, unless the topic is about an
obscure corner that I do not personally use.  But I am obviously not
perfect.  If you sent a patch that you did not hear from anybody for
three days, that is a very good indication that it was dropped on the
floor --- please do not hesitate to remind me.

The list archive is available at a few public sites as well:

        http://marc.theaimsgroup.com/?l=git
        http://news.gmane.org/gmane.comp.version-control.git
	http://www.spinics.net/lists/git/

and some people seem to prefer to read it over NNTP:

        nntp://news.gmane.org/gmane.comp.version-control.git

* Repositories, branches and documentation.

My public git.git repository is at:

        git://git.kernel.org/pub/scm/git/git.git/

Immediately after I publish to the primary repository at kernel.org, I
also push into an alternate here:

        git://repo.or.cz/alt-git.git/

Impatient people would have better luck with the latter one, but it
does not have "html" and "man" branches (described below).

There are three branches in git.git repository that are not
about the source tree of git: "todo", "html" and "man".  The
first one was meant to contain TODO list for me, but I am not
good at maintaining such a list so it is not as often updated as
it could/should be.  It also contains some helper scripts I use
to maintain git.

The "html" and "man" are autogenerated documentation from the
tip of the "master" branch; the tip of "html" is extracted to be
visible at kernel.org at:

        http://www.kernel.org/pub/software/scm/git/docs/

The above URL is the top-level documentation page, and it has
links to documentation of older releases.

The script to maintain these two documentation branches are
found in "todo" branch as dodoc.sh, if you are interested.  It
is a good demonstration of how to use an update hook to automate
a task.

There are four branches in git.git repository that track the
source tree of git: "master", "maint", "next", and "pu".  I may
add more maintenance branches (e.g. "maint-1.5.1") if we have
huge backward incompatible feature updates in the future to keep
an older release alive; I may not, but the distributed nature of
git means any volunteer can run a stable-tree like that himself.

The "master" branch is meant to contain what are very well
tested and ready to be used in a production setting.  There
could occasionally be minor breakages or brown paper bag bugs
but they are not expected to be anything major.  Every now and
then, a "feature release" is cut from the tip of this branch and
they typically are named with three dotted decimal digits.  The
last such release was v1.5.2 done on May 20th this year.

Whenever a feature release is made, "maint" branch is forked off
from "master" at that point.  Obvious, safe and urgent fixes
after a feature release are applied to this branch and
maintenance releases are cut from it.  The maintenance releases
are named with four dotted decimal, named after the feature
release they are updates to; the last such release was v1.5.1.6.
New features never go to this branch.  This branch is also
merged into "master" to propagate the fixes forward.

A trivial and safe enhancement goes directly on top of "master".
A new development, either initiated by myself or more often by
somebody who found his or her own itch to scratch, does not
usually happen on "master", however.  Instead, a separate topic
branch is forked from the tip of "master", and it first is
tested in isolation; I may make minimum fixups at this point.
Usually there are a handful such topic branches that are running
ahead of "master" in git.git repository.  I do not publish the
tip of these branches in my public repository, however, partly
to keep the number of branches that downstream developers need
to worry about low, and primarily because I am lazy.

I judge the quality of topic branches, taking advices from the
mailing list discussions.  Some of them start out as "good idea
but obviously is broken in some areas (e.g. breaks the existing
testsuite)" and then with some more work (either by the original
contributor or help from other people on the list) becomes "more
or less done and can now be tested by wider audience".  Luckily,
most of them start out in the latter, better shape.

The "next" branch is to merge and test topic branches in the
latter category.  In general, the branch always contains the tip
of "master".  It might not be quite rock-solid production ready,
but is expected to work more or less without major breakage.  I
usually use "next" version of git for my own work, so it cannot
be _that_ broken to prevent me from pushing the changes out.
The "next" branch is where new and exciting things take place.

The above three branches, "master", "maint" and "next" are never
rewound, so you should be able to safely track them (this
automatically means the topics that have been merged into "next"
are not rebased, and you can find the tip of topic branches you
are interested in from the output of "git log next").

The "pu" (proposed updates) branch bundles all the remainder of
topic branches.  The "pu" branch, and topic branches that are
only in "pu", are subject to rebasing in general.

When a topic that was in "pu" proves to be in testable shape, it
graduates to "next".  I do this with:

        git checkout next
        git merge that-topic-branch

Sometimes, an idea that looked promising turns out to be not so
hot and the topic can be dropped from "pu" in such a case.

A topic that is in "next" is expected to be tweaked and fixed to
perfection before it is merged to "master" (that's why "master"
can be expected to stay very stable).  Similarly to the above I
do it with this:

        git checkout master
        git merge that-topic-branch
        git branch -d that-topic-branch

However, being in "next" is not a guarantee to appear in the
next release (being in "master" is such a guarantee, unless it
is later found seriously broken and reverted), or even in any
future release.  There even were cases that topics needed
reverting a few commits in them before graduating to "master",
or a topic that already was in "next" were entirely reverted
from "next" because fatal flaws were found in them later.

Starting from v1.5.0, "master" and "maint" have release notes
for the next release in Documentation/RelNotes-* files, so that
I do not have to run around summarizing what happened just
before the release.


* Other people's trees, trusted lieutenants and credits.

Documentation/SubmittingPatches outlines who your changes should
be sent to.  As described in contrib/README, I would delegate
fixes and enhancements in contrib/ area to primary contributors
of them.

Although the following are included in git.git repository, they
have their own authoritative repository and maintainers:

 git-gui/ -- this subdirectory comes from Shawn Pearce's git-gui
             project, which is found at:

             git://repo.or.cz/git-gui.git

 gitk     -- this file is maintained by Paul Mackerras, at:

             git://git.kernel.org/pub/scm/gitk/gitk.git

I would like to thank everybody who helped to raise git into the
current shape.  Especially I would like to thank the git list
regulars whose help I have relied on and expect to continue
relying on heavily:

 - Linus on general design issues.

 - Linus, Shawn Pearce, Johannes Schindelin, Nicolas Pitre, and
   Rene Scharfe on general implementation issues.

 - Shawn and Nicolas Pitre on pack issues.

 - Martin Langhoff and Frank Lichtenheld on cvsserver and cvsimport.

 - Paul Mackerras on gitk.

 - Eric Wong on git-svn.

 - Jakub Narebski, Peter Baudis, and Luben Tuikov on gitweb.

 - J. Bruce Fields on documentaton issues.


* This document

The latest copy of this document is found in git.git repository,
on 'todo' branch, as MaintNotes.

[ANNOUNCE] GIT 1.5.0

[Junio C Hamano]

The latest feature release GIT 1.5.0 is available at the usual places:

  http://www.kernel.org/pub/software/scm/git/

  git-1.5.0.tar.{gz,bz2}			(tarball)
  git-htmldocs-1.5.0.tar.{gz,bz2}		(preformatted docs)
  git-manpages-1.5.0.tar.{gz,bz2}		(preformatted docs)
  RPMS/$arch/git-*-1.5.0-1.$arch.rpm	(RPM)

----------------------------------------------------------------

GIT v1.5.0 Release Notes
========================

Old news
--------

This section is for people who are upgrading from ancient
versions of git.  Although all of the changes in this section
happened before the current v1.4.4 release, they are summarized
here in the v1.5.0 release notes for people who skipped earlier
versions.

As of git v1.5.0 there are some optional features that changes
the repository to allow data to be stored and transferred more
efficiently.  These features are not enabled by default, as they
will make the repository unusable with older versions of git.
Specifically, the available options are:

 - There is a configuration variable core.legacyheaders that
   changes the format of loose objects so that they are more
   efficient to pack and to send out of the repository over git
   native protocol, since v1.4.2.  However, loose objects
   written in the new format cannot be read by git older than
   that version; people fetching from your repository using
   older clients over dumb transports (e.g. http) using older
   versions of git will also be affected.

 - Since v1.4.3, configuration repack.usedeltabaseoffset allows
   packfile to be created in more space efficient format, which
   cannot be read by git older than that version.

The above two are not enabled by default and you explicitly have
to ask for them, because these two features make repositories
unreadable by older versions of git, and in v1.5.0 we still do
not enable them by default for the same reason.  We will change
this default probably 1 year after 1.4.2's release, when it is
reasonable to expect everybody to have new enough version of
git.

 - 'git pack-refs' appeared in v1.4.4; this command allows tags
   to be accessed much more efficiently than the traditional
   'one-file-per-tag' format.  Older git-native clients can
   still fetch from a repository that packed and pruned refs
   (the server side needs to run the up-to-date version of git),
   but older dumb transports cannot.  Packing of refs is done by
   an explicit user action, either by use of "git pack-refs
   --prune" command or by use of "git gc" command.

 - 'git -p' to paginate anything -- many commands do pagination
   by default on a tty.  Introduced between v1.4.1 and v1.4.2;
   this may surprise old timers.

 - 'git archive' superseded 'git tar-tree' in v1.4.3;

 - 'git cvsserver' was new invention in v1.3.0;

 - 'git repo-config', 'git grep', 'git rebase' and 'gitk' were
   seriously enhanced during v1.4.0 timeperiod.

 - 'gitweb' became part of git.git during v1.4.0 timeperiod and
   seriously modified since then.

 - reflog is an v1.4.0 invention.  This allows you to name a
   revision that a branch used to be at (e.g. "git diff
   master@{yesterday} master" allows you to see changes since
   yesterday's tip of the branch).


Updates in v1.5.0 since v1.4.4 series
-------------------------------------

* Index manipulation

 - git-add is to add contents to the index (aka "staging area"
   for the next commit), whether the file the contents happen to
   be is an existing one or a newly created one.

 - git-add without any argument does not add everything
   anymore.  Use 'git-add .' instead.  Also you can add
   otherwise ignored files with an -f option.

 - git-add tries to be more friendly to users by offering an
   interactive mode ("git-add -i").

 - git-commit <path> used to refuse to commit if <path> was
   different between HEAD and the index (i.e. update-index was
   used on it earlier).  This check was removed.

 - git-rm is much saner and safer.  It is used to remove paths
   from both the index file and the working tree, and makes sure
   you are not losing any local modification before doing so.

 - git-reset <tree> <paths>... can be used to revert index
   entries for selected paths.

 - git-update-index is much less visible.  Many suggestions to
  use the command in git output and documentation have now been
  replaced by simpler commands such as "git add" or "git rm".


* Repository layout and objects transfer

 - The data for origin repository is stored in the configuration
   file $GIT_DIR/config, not in $GIT_DIR/remotes/, for newly
   created clones.  The latter is still supported and there is
   no need to convert your existing repository if you are
   already comfortable with your workflow with the layout.

 - git-clone always uses what is known as "separate remote"
   layout for a newly created repository with a working tree.

   A repository with the separate remote layout starts with only
   one default branch, 'master', to be used for your own
   development.  Unlike the traditional layout that copied all
   the upstream branches into your branch namespace (while
   renaming their 'master' to your 'origin'), the new layout
   puts upstream branches into local "remote-tracking branches"
   with their own namespace. These can be referenced with names
   such as "origin/$upstream_branch_name" and are stored in
   .git/refs/remotes rather than .git/refs/heads where normal
   branches are stored.

   This layout keeps your own branch namespace less cluttered,
   avoids name collision with your upstream, makes it possible
   to automatically track new branches created at the remote
   after you clone from it, and makes it easier to interact with
   more than one remote repository (you can use "git remote" to
   add other repositories to track).  There might be some
   surprises:

   * 'git branch' does not show the remote tracking branches.
     It only lists your own branches.  Use '-r' option to view
     the tracking branches.

   * If you are forking off of a branch obtained from the
     upstream, you would have done something like 'git branch
     my-next next', because traditional layout dropped the
     tracking branch 'next' into your own branch namespace.
     With the separate remote layout, you say 'git branch next
     origin/next', which allows you to use the matching name
     'next' for your own branch.  It also allows you to track a
     remote other than 'origin' (i.e. where you initially cloned
     from) and fork off of a branch from there the same way
     (e.g. "git branch mingw j6t/master").

   Repositories initialized with the traditional layout continue
   to work.

 - New branches that appear on the origin side after a clone is
   made are also tracked automatically.  This is done with an
   wildcard refspec "refs/heads/*:refs/remotes/origin/*", which
   older git does not understand, so if you clone with 1.5.0,
   you would need to downgrade remote.*.fetch in the
   configuration file to specify each branch you are interested
   in individually if you plan to fetch into the repository with
   older versions of git (but why would you?).

 - Similarly, wildcard refspec "refs/heads/*:refs/remotes/me/*"
   can be given to "git-push" command to update the tracking
   branches that is used to track the repository you are pushing
   from on the remote side.

 - git-branch and git-show-branch know remote tracking branches
   (use the command line switch "-r" to list only tracked branches).

 - git-push can now be used to delete a remote branch or a tag.
   This requires the updated git on the remote side (use "git
   push <remote> :refs/heads/<branch>" to delete "branch").

 - git-push more aggressively keeps the transferred objects
   packed.  Earlier we recommended to monitor amount of loose
   objects and repack regularly, but you should repack when you
   accumulated too many small packs this way as well.  Updated
   git-count-objects helps you with this.

 - git-fetch also more aggressively keeps the transferred objects
   packed.  This behavior of git-push and git-fetch can be
   tweaked with a single configuration transfer.unpacklimit (but
   usually there should not be any need for a user to tweak it).

 - A new command, git-remote, can help you manage your remote
   tracking branch definitions.

 - You may need to specify explicit paths for upload-pack and/or
   receive-pack due to your ssh daemon configuration on the
   other end.  This can now be done via remote.*.uploadpack and
   remote.*.receivepack configuration.


* Bare repositories

 - Certain commands change their behavior in a bare repository
   (i.e. a repository without associated working tree).  We use
   a fairly conservative heuristic (if $GIT_DIR is ".git", or
   ends with "/.git", the repository is not bare) to decide if a
   repository is bare, but "core.bare" configuration variable
   can be used to override the heuristic when it misidentifies
   your repository.

 - git-fetch used to complain updating the current branch but
   this is now allowed for a bare repository.  So is the use of
   'git-branch -f' to update the current branch.

 - Porcelain-ish commands that require a working tree refuses to
   work in a bare repository.


* Reflog

 - Reflog records the history from the view point of the local
   repository. In other words, regardless of the real history,
   the reflog shows the history as seen by one particular
   repository (this enables you to ask "what was the current
   revision in _this_ repository, yesterday at 1pm?").  This
   facility is enabled by default for repositories with working
   trees, and can be accessed with the "branch@{time}" and
   "branch@{Nth}" notation.

 - "git show-branch" learned showing the reflog data with the
   new -g option.  "git log" has -s option to view reflog
   entries in a more verbose manner.

 - git-branch knows how to rename branches and moves existing
   reflog data from the old branch to the new one.

 - In addition to the reflog support in v1.4.4 series, HEAD
   reference maintains its own log.  "HEAD@{5.minutes.ago}"
   means the commit you were at 5 minutes ago, which takes
   branch switching into account.  If you want to know where the
   tip of your current branch was at 5 minutes ago, you need to
   explicitly say its name (e.g. "master@{5.minutes.ago}") or
   omit the refname altogether i.e. "@{5.minutes.ago}".

 - The commits referred to by reflog entries are now protected
   against pruning.  The new command "git reflog expire" can be
   used to truncate older reflog entries and entries that refer
   to commits that have been pruned away previously with older
   versions of git.

   Existing repositories that have been using reflog may get
   complaints from fsck-objects and may not be able to run
   git-repack, if you had run git-prune from older git; please
   run "git reflog expire --stale-fix --all" first to remove
   reflog entries that refer to commits that are no longer in
   the repository when that happens.


* Crufts removal

 - We used to say "old commits are retrievable using reflog and
   'master@{yesterday}' syntax as long as you haven't run
   git-prune".  We no longer have to say the latter half of the
   above sentence, as git-prune does not remove things reachable
   from reflog entries.

 - 'git-prune' by default does not remove _everything_
   unreachable, as there is a one-day grace period built-in.

 - There is a toplevel garbage collector script, 'git-gc', that
   runs periodic cleanup functions, including 'git-repack -a -d',
   'git-reflog expire', 'git-pack-refs --prune', and 'git-rerere
   gc'.

 - The output from fsck ("fsck-objects" is called just "fsck"
   now, but the old name continues to work) was needlessly
   alarming in that it warned missing objects that are reachable
   only from dangling objects.  This has been corrected and the
   output is much more useful.


* Detached HEAD

 - You can use 'git-checkout' to check out an arbitrary revision
   or a tag as well, instead of named branches.  This will
   dissociate your HEAD from the branch you are currently on.

   A typical use of this feature is to "look around".  E.g.

	$ git checkout v2.6.16
	... compile, test, etc.
	$ git checkout v2.6.17
	... compile, test, etc.

 - After detaching your HEAD, you can go back to an existing
   branch with usual "git checkout $branch".  Also you can
   start a new branch using "git checkout -b $newbranch" to
   start a new branch at that commit.

 - You can even pull from other repositories, make merges and
   commits while your HEAD is detached.  Also you can use "git
   reset" to jump to arbitrary commit, while still keeping your
   HEAD detached.

   Going back to attached state (i.e. on a particular branch) by
   "git checkout $branch" can lose the current stat you arrived
   in these ways, and "git checkout" refuses when the detached
   HEAD is not pointed by any existing ref (an existing branch,
   a remote tracking branch or a tag).  This safety can be
   overridden with "git checkout -f $branch".


* Packed refs

 - Repositories with hundreds of tags have been paying large
   overhead, both in storage and in runtime, due to the
   traditional one-ref-per-file format.  A new command,
   git-pack-refs, can be used to "pack" them in more efficient
   representation (you can let git-gc do this for you).

 - Clones and fetches over dumb transports are now aware of
   packed refs and can download from repositories that use
   them.


* Configuration

 - configuration related to color setting are consolidated under
   color.* namespace (older diff.color.*, status.color.* are
   still supported).

 - 'git-repo-config' command is accessible as 'git-config' now.


* Updated features

 - git-describe uses better criteria to pick a base ref.  It
   used to pick the one with the newest timestamp, but now it
   picks the one that is topologically the closest (that is,
   among ancestors of commit C, the ref T that has the shortest
   output from "git-rev-list T..C" is chosen).

 - git-describe gives the number of commits since the base ref
   between the refname and the hash suffix.  E.g. the commit one
   before v2.6.20-rc6 in the kernel repository is:

	v2.6.20-rc5-306-ga21b069

   which tells you that its object name begins with a21b069,
   v2.6.20-rc5 is an ancestor of it (meaning, the commit
   contains everything -rc5 has), and there are 306 commits
   since v2.6.20-rc5.

 - git-describe with --abbrev=0 can be used to show only the
   name of the base ref.

 - git-blame learned a new option, --incremental, that tells it
   to output the blames as they are assigned.  A sample script
   to use it is also included as contrib/blameview.

 - git-blame starts annotating from the working tree by default.


* Less external dependency

 - We no longer require the "merge" program from the RCS suite.
   All 3-way file-level merges are now done internally.

 - The original implementation of git-merge-recursive which was
   in Python has been removed; we have a C implementation of it
   now.

 - git-shortlog is no longer a Perl script.  It no longer
   requires output piped from git-log; it can accept revision
   parameters directly on the command line.


* I18n

 - We have always encouraged the commit message to be encoded in
   UTF-8, but the users are allowed to use legacy encoding as
   appropriate for their projects.  This will continue to be the
   case.  However, a non UTF-8 commit encoding _must_ be
   explicitly set with i18n.commitencoding in the repository
   where a commit is made; otherwise git-commit-tree will
   complain if the log message does not look like a valid UTF-8
   string.

 - The value of i18n.commitencoding in the originating
   repository is recorded in the commit object on the "encoding"
   header, if it is not UTF-8.  git-log and friends notice this,
   and reencodes the message to the log output encoding when
   displaying, if they are different.  The log output encoding
   is determined by "git log --encoding=<encoding>",
   i18n.logoutputencoding configuration, or i18n.commitencoding
   configuration, in the decreasing order of preference, and
   defaults to UTF-8.

 - Tools for e-mailed patch application now default to -u
   behavior; i.e. it always re-codes from the e-mailed encoding
   to the encoding specified with i18n.commitencoding.  This
   unfortunately forces projects that have happily been using a
   legacy encoding without setting i18n.commitencoding to set
   the configuration, but taken with other improvement, please
   excuse us for this very minor one-time inconvenience.


* e-mailed patches

 - See the above I18n section.

 - git-format-patch now enables --binary without being asked.
   git-am does _not_ default to it, as sending binary patch via
   e-mail is unusual and is harder to review than textual
   patches and it is prudent to require the person who is
   applying the patch to explicitly ask for it.

 - The default suffix for git-format-patch output is now ".patch",
   not ".txt".  This can be changed with --suffix=.txt option,
   or setting the config variable "format.suffix" to ".txt".


* Foreign SCM interfaces

  - git-svn now requires the Perl SVN:: libraries, the
    command-line backend was too slow and limited.

  - the 'commit' subcommand of git-svn has been renamed to
    'set-tree', and 'dcommit' is the recommended replacement for
    day-to-day work.

  - git fast-import backend.


* User support

 - Quite a lot of documentation updates.

 - Bash completion scripts have been updated heavily.

 - Better error messages for often used Porcelainish commands.

 - Git GUI.  This is a simple Tk based graphical interface for
   common Git operations.


* Sliding mmap

 - We used to assume that we can mmap the whole packfile while
   in use, but with a large project this consumes huge virtual
   memory space and truly huge ones would not fit in the
   userland address space on 32-bit platforms.  We now mmap huge
   packfile in pieces to avoid this problem.


* Shallow clones

 - There is a partial support for 'shallow' repositories that
   keeps only recent history.  A 'shallow clone' is created by
   specifying how deep that truncated history should be
   (e.g. "git clone --depth=5 git://some.where/repo.git").

   Currently a shallow repository has number of limitations:

   - Cloning and fetching _from_ a shallow clone are not
     supported (nor tested -- so they might work by accident but
     they are not expected to).

   - Pushing from nor into a shallow clone are not expected to
     work.

   - Merging inside a shallow repository would work as long as a
     merge base is found in the recent history, but otherwise it
     will be like merging unrelated histories and may result in
     huge conflicts.

   but this would be more than adequate for people who want to
   look at near the tip of a big project with a deep history and
   send patches in e-mail format.

A note from the maintainer

[Junio C Hamano]

It has been a while since I sent this message out the last time,
so it may be a good time to send it with updates again.  There
seem to be some new people on the git list, especially now the
big release is out.

This message talks about how git.git is managed, and how you can
work with it.


* IRC and Mailing list

Many active members of development community hang around on #git
IRC channel.  Its log is available at:

	http://colabti.de/irclogger/irclogger_logs/git

[jc: Does anybody know a shortcut for "Today's" page on this
 site?  It irritates me having to click the latest link on this
 page to get to the latest.]


The development however is primarily done on this mailing list
you are reading right now.  If you have patches, please send
them to the list, following Documentation/SubmittingPatches.

I usually read all patches posted to the list, and follow almost
all the discussions on the list, unless the topic is about an
obscure corner that I do not personally use.  But I am obviously
not perfect.  If you sent a patch that you did not hear from
anybody for three days, that is a very good indication that it
was dropped on the floor --- please do not hesitate to remind
me.

The list archive is available at a few public sites as well:

	http://marc.theaimsgroup.com/?l=git
	http://news.gmane.org/gmane.comp.version-control.git

and some people seem to prefer to read it over NNTP:

	nntp://news.gmane.org/gmane.comp.version-control.git


* Repositories, branches and documentation.

My public git.git repository is at:

	git://git.kernel.org/pub/scm/git/git.git/

This is mirrored at Pasky's site at

	git://repo.or.cz/git.git/

but the first has a few hours mirroring delay after I publish
updates, and the latter, being a mirror of former, lags behind
it further.  Immediately after I publish to the primary
repository at kernel.org, I also push into an alternate here:

	git://repo.or.cz/alt-git.git/

Impatient people would have better lack with the last one (but
the last repository does not have "html", "man" and "todo"
branches, described next).


There are three branches in git.git repository that are not
about the source tree of git: "todo", "html" and "man".  The
first one was meant to contain TODO list for me, but I am not
good at maintaining such a list so it is not as often updated as
it could/should be.  It also contains some helper scripts I use
to maintain git.

The "html" and "man" are autogenerated documentation from the
tip of the "master" branch; the tip of "html" is extracted to be
visible at kernel.org at:

	http://www.kernel.org/pub/software/scm/git/docs/

Starting from 1.5.0, the top-level documentation page has links
to documentation of older releases.

The script to maintain these two documentation branches are
found in "todo" branch as dodoc.sh, if you are interested.  It
is a good demonstration of how to use an update hook to automate
a task.

There are four branches in git.git repository that track the
source tree of git: "master", "maint", "next", and "pu".

The "master" branch is meant to contain what are reasonably
tested and ready to be used in a production setting.  There
could occasionally be minor breakages or brown paper bag bugs
but they are not expected to be anything major.  Every now and
then, a "feature release" is cut from the tip of this branch and
they typically are named with three dotted decimal digits.  The
last such release was v1.5.0 done on Feb 14th this year.  The
codename for that release is not "snog".

Whenever a feature release is made, "maint" branch is forked off
from "master" at that point.  Obvious, safe and urgent fixes
after a feature release are applied to this branch and
maintenance releases are cut from it.  The maintenance releases
are typically named with four dotted decimal, named after the
feature release they are updates to; the last such release was
v1.4.4.4, and I am expecting to cut v1.5.0.1 sometime soon.
Usually new development will never go to this branch.  This
branch is also merged into "master" to propagate the fixes
forward.

A trivial and safe enhancement goes directly on top of "master".
A new development, either initiated by myself or more often by
somebody who found his or her own itch to scratch, does not
usually happen on "master", however.  Instead, it is forked into
a separate topic branch from the tip of "master", and first
tested in isolation; I may make minimum fixups at this point.
Usually there are a handful such topic branches that are running
ahead of "master" in git.git repository.  I do not publish the
tip of these branches in my public repository, however, partly
to keep the number of branches that downstream developers need
to worry about and primarily because I am lazy.

I judge the quality of topic branches, taking advices from the
mailing list discussions.  Some of them start out as "good idea
but obviously is broken in some areas (e.g. breaks the existing
testsuite)" and then with some more work (either by the original
contributor or help from other people on the list) becomes "more
or less done and can now be tested by wider audience".  Luckily,
most of them start out in the latter, better shape.

The "next" branch is to merge and test topic branches in the
latter category.  In general it should always contain the tip of
"master".  They might not be quite production ready, but are
expected to work more or less without major breakage.  I usually
use "next" version of git for my own work, so it cannot be
_that_ broken to prevent me from pushing the changes out.
The "next" branch is where new and exciting things take place.

The above three branches, "master", "maint" and "next" are never
rewound, so you should be able to safely track them (that means
the topics that have been merged into "next" are not rebased).

The "pu" (proposed updates) branch bundles all the remainder of
topic branches.  The "pu" branch, and topic branches that are
only in "pu", are subject to rebasing in general.

When a topic that was in "pu" proves to be in testable shape, it
graduates to "next".  I do this with:

	git checkout next
        git merge that-topic-branch

Sometimes, an idea that looked promising turns out to be not so
hot and the topic can be dropped from "pu" in such a case.

A topic that is in "next" is expected to be tweaked and fixed to
perfection before it is merged to "master".  However, being in
"next" is not a guarantee to appear in the next release (being
in "master" is such a guarantee, unless it is later found
seriously broken and reverted), or even in any future release.
There even were cases that topics needed a few reverting before
graduating to "master", or a topic that already was in "next"
were reverted from "next" because fatal flaws were found in them
later.

Starting from v1.5.0, "master" and "maint" have release notes
for the next release in Documentation/RelNotes-* files, so that
I do not have to run around summarizing what happened just
before the release.


* Other people's trees, trusted lieutenants and credits.

Documentation/SubmittingPatches outlines who your changes should
be sent to.  As described in contrib/README, I would delegate
fixes and enhancements in contrib/ area to primary contributors
of them.

Although the following are included in git.git repository, they
have their own authoritative repository and maintainers:

 git-gui/ -- this subdirectory comes from Shawn Pearce's git-gui
             project, which is found at:

             git://repo.or.cz/git-gui.git

 gitk     -- this file is maintained by Paul Packerras, at:

	     git://git.kernel.org/pub/scm/gitk/gitk.git

I would like to thank everybody who helped to raise git into the
current shape.  Especially I would like to thank the git list
regulars whose help I have relied on and expect to continue
relying on heavily:

 - Linus on general design issues.

 - Linus, Shawn Pearce, Johannes Schindelin, Nicolas Pitre, and
   Rene Scharfe on general implementation issues.

 - Shawn and Nicolas Pitre on pack issues.

 - Martin Langhoff on cvsserver and cvsimport.

 - Paul Packerras on gitk.

 - Eric Wong on git-svn.

 - Jakub Narebski and Luben Tuikov on gitweb.

 - J. Bruce Fields on documentaton issues.

Re: A note from the maintainer

[Johannes Schindelin]

Hi,

On Fri, 16 Feb 2007, Junio C Hamano wrote:

> Many active members of development community hang around on #git
> IRC channel.  Its log is available at:
> 
> 	http://colabti.de/irclogger/irclogger_logs/git
> 
> [jc: Does anybody know a shortcut for "Today's" page on this
>  site?  It irritates me having to click the latest link on this
>  page to get to the latest.]

[jes: just stumbled over it: 
http://colabti.de/irclogger/irclogger_log/git?date=]

Ciao,
Dscho

Re: A note from the maintainer

[Junio C Hamano]

Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:

> Hi,
>
> On Fri, 16 Feb 2007, Junio C Hamano wrote:
>
>> Many active members of development community hang around on #git
>> IRC channel.  Its log is available at:
>> 
>> 	http://colabti.de/irclogger/irclogger_logs/git
>> 
>> [jc: Does anybody know a shortcut for "Today's" page on this
>>  site?  It irritates me having to click the latest link on this
>>  page to get to the latest.]
>
> [jes: just stumbled over it: 
> http://colabti.de/irclogger/irclogger_log/git?date=]

This (or its variant, just removing "?date=" at the end) seems
to work most of the time, except for close to day boundary.  I
do not know why.

A note from the maintainer

[Junio C Hamano]

It has been a while since I sent this message out the last time,
and there seem to be some new people on the git list.

This message talks about how git.git is managed, and how you can
work with it.


* IRC and Mailing list

Many active members of development community hang around on #git
IRC channel.  Its log is available at:

	http://colabti.de/irclogger/irclogger_logs/git

[jc: Does anybody know a shortcut for "Today's" page on this
 site?  It irritates me having to click the latest link on this
 page to get to the latest]


The development however is primarily done on this mailing list
you are reading right now.  If you have patches, please send
them to the list, following Documentation/SubmittingPatches.

I usually read all patches posted to the list, and follow almost
all the discussions on the list, unless the topic is about an
obscure corner that I do not personally use.  But I am obviously
not perfect.  If you sent a patch that you did not hear from
anybody for three days, that is a very good indication that it
was dropped on the floor --- please do not hesitate to remind
me.


The list from time to time gets messages that either

 - state something incorrect, with a certain authoritative tone,
   without doing minimum homework.

 - try to rehash issues that have been ruled some time ago
   without bringing anything new to the table,

I used to try responding to such messages quickly with pointers
to archived list messages and/or the name of the commit object
that settled the issue, in order to save other readers from
wasting time on them, but that has been a huge timesink for me,
so I'll stop doing so and simply ignore them.

This does not apply to messages from new people (the definition
of new is rather subjective --- if I cannot connect your name
with a specific contribution you made to the git community, you
are still new); I would welcome questions and comments from new
people on the list.  They are good sources for us to learn which
parts of git's concepts are harder to learn and which
documentation can be improved.


The list is available at a few public sites as well:

	http://marc.theaimsgroup.com/?l=git
	http://news.gmane.org/gmane.comp.version-control.git
	nntp://news.gmane.org/gmane.comp.version-control.git


* Repositories and branches.

My public git.git repository is at:

	git://git.kernel.org/pub/scm/git/git.git/

It is mirrored at Pasky's repo.or.cz as well.

There are three branches in git.git repository that are not
about the source tree of git: "todo", "html" and "man".  The
first one is meant to contain TODO list for me, but I am not
good at maintaining such a list so it is not as often updated as
I would have liked.  It also contains some helper scripts I
use to maintain it.

The "html" and "man" are autogenerated documentation from the
tip of the "master" branch; the tip of "html" is extracted to be
visible at kernel.org at:

	http://www.kernel.org/pub/software/scm/git/docs/

The script to auto-maintain these two documentation branches are
found in "todo" branch as dodoc.sh script, if you are interested.

There are four branches in git.git repository that track the
source tree of git: "master", "maint", "next", and "pu".

The "master" branch is meant to contain what are reasonably
tested and ready to be used in a production setting.  There
could occasionally be minor breakages or brown paper bag bugs
but they are not expected to be anything major.  Every now and
then, a "feature release" is cut from the tip of this branch and
they typically are named with three dotted decimal digits.  The
last such release was v1.4.4 done on Nov 14th last year.

Whenever a feature release is made, "maint" branch is forked off
from "master" at that point.  Obvious, safe and urgent fixes
after a feature release are applied to this branch and
maintenance releases are cut from it.  The maintenance releases
are typically named with four dotted decimal, named after the
feature release they are updates to; the last such release was
v1.4.4.3.  Usually new development will never go to this branch.
This branch is also pulled into "master" to propagate the fixes
forward.

A trivial and safe enhancement goes directly on top of "master".
A new development, either initiated by myself or more often by
somebody found his or her own itch to scratch, does not usually
happen on "master", however.  Instead, it is forked into a
separate topic branch from the tip of "master", and first tested
in isolation; I may make minimum fixups at this point.  Usually
there are a handful such topic branches that are running ahead
of "master" in git.git repository.  I do not publish the tip of
these branches in my public repository, however, partly to keep
the number of branches that downstream developers need to worry
about and primarily because I am lazy.

I judge the quality of topic branches, taking advices from the
mailing list discussions.  Some of them start out as "good idea
but obviously is broken in some areas (e.g. breaks the existing
testsuite)" and then with some more work (either by the original
contributor or help from other people on the list) becomes "more
or less done and can now be tested by wider audience".  Luckily,
most of them start out in the latter, better shape.

The "next" branch is to merge and test topic branches in the
latter category with "master".  In general it should always
contain the tip of "master".  They may not be quite production
ready, but are expected to work more or less without major
breakage.  I usually use "next" version of git for my own work.
"next" is where new and exciting things take place.

The above three branches, "master", "maint" and "next" are never
rewound, so you should be able to safely track them (that means
the topics that have been merged into "next" are not rebased).

The "pu" (proposed updates) branch bundles all the remaining
topic branches.  The topic branches and "pu" are subject to
rebasing in general.  Especially "pu" is almost always rewound
to the tip of "next" and reconstructed to contain the remaining
topic branches.

When a topic that was in "pu" proves to be in testable shape, it
graduates to "next".  I do this with:

	git checkout next
        git merge that-topic-branch

Sometimes, an idea that looked promising turns out to be not so
hot and the topic can be dropped from "pu" in such a case.

A topic that is in "next" is _expected_ to be tweaked and fixed
to perfection before it is merged to "master".  I do this with:

	git checkout master
        git merge that-topic-branch
        git branch -d that-topic-branch

However, being in "next" is not a guarantee to appear in the
next release (being in "master" is such a guarantee, unless it
is later found seriously broken and reverted), or even in _any_
future release.  There even was a case that a topic needed a few
reverting before graduating to "master".

Re: A note from the maintainer

[Shawn O. Pearce]

Junio C Hamano <junkio@cox.net> wrote:
> I usually read all patches posted to the list, and follow almost
> all the discussions on the list, unless the topic is about an
> obscure corner that I do not personally use.  But I am obviously
> not perfect.  If you sent a patch that you did not hear from
> anybody for three days, that is a very good indication that it
> was dropped on the floor --- please do not hesitate to remind
> me.

Though a contributor should probably check the `maint`, `master`,
`next` or `pu` branches of git.git before sending a reminder.

Often we find that you have accepted a patch without comment (as
the patch is obviously correct and nobody else had a reason to
comment on it).  In this case the patch will just appear in one of
the git.git branches, with no email indicating that.

-- 
Shawn.

A note from the maintainer

[Junio C Hamano]

Since there seem to be many new people on the git list, I
thought it might be worthwhile to talk about how git.git is
managed, and how you can work with it.

* Mailing list.

The development is primarily done on this mailing list you are
reading right now.

If you have patches, please send them to the list, following
Documentation/SubmittingPatches.

The list is available at various public sites as well:

	http://news.gmane.org/gmane.comp.version-control.git
	http://marc.theaimsgroup.com/?l=git

Many active members of development community hang around on #git
IRC channel as well.  Its log is available at:

	http://colabti.de/irclogger/irclogger_logs/git

[jc: Does anybody know a shortcut for "Today's" page on this
 site?  It irritates me having to click the latest link on this
 page to get to the latest]


* Repositories and branches.

My public git.git repository is at:

	git://git.kernel.org/pub/scm/git/git.git/

It is mirrored at Pasky's repo.or.cz as well.

There are three branches in git.git repository that are not
about the source tree of git: "todo", "html" and "man".  The
first one is meant to contain TODO list for me, but I am not
good at maintaining such a list so it is not as often updated as
I would have liked.  It also contains some helper scripts I
use to maintain it.

The "html" and "man" are autogenerated documentation from the
tip of the "master" branch; the tip of "html" is extracted to be
visible at kernel.org at:

	http://www.kernel.org/pub/software/scm/git/docs/

The script to auto-maintain these two documentation branches are
found in "todo" branch as dodoc.sh script, if you are interested.

There are four branches in git.git repository that track the
source tree of git: "master", "maint", "next", and "pu".

The "master" branch is meant to contain what are reasonably
tested and ready to be used in a production setting.  There
could occasionally be minor breakages or brown paper bag bugs
but they are not expected to be anything major.  Every now and
then, a "feature release" is cut from the tip of this branch and
they typically are named with three dotted decimal digits.  The
last such release was v1.4.3 done on Oct 18th.

Whenever a feature release is made, "maint" branch is forked off
from "master" at that point.  Obvious, safe and urgent fixes
after a feature release are applied to this branch and
maintenance releases are cut from it.  The maintenance releases
are typically named with four dotted decimal, named after the
feature release they are updates to; the last such release was
v1.4.3.2 was done tonight.  Usually new development will never
go to this branch.  This branch is also pulled into "master" to
propagate the fixes forward.

A trivial and safe enhancement goes directly on top of "master".
A new development, either initiated by myself or more often you
found your own itch to scratch, does not usually happen on
"master", however.  Instead, it is forked into a separate topic
branch from the tip of "master", and first tested in isolation;
I may make minimum fixups at this point.  Usually there are a
handful such topic branches that are running ahead of "master"
in git.git repository.  I do not publish the tip of these
branches in my public repository, however, partly to keep the
number of branches that downstream developers need to worry
about and primarily because I am lazy.

I judge the quality of topic branches, taking advices from the
mailing list discussions.  Some of them start out as "good idea
but obviously is broken in some areas (e.g. breaks the existing
testsuite)" and then with some more work (either by the original
contributor or help from other people on the list) becomes "more
or less done and can now be tested by wider audience".  Luckily,
most of them start out in the latter, better shape.

The "next" branch is to merge and test topic branches in the
latter category with "master".  In general it should always
contain the tip of "master".  They may not be quite production
ready, but are expected to work more or less without major
breakage.  I usually use "next" version of git for my own work.
"next" is where new and exciting things take place.

The above three branches, "master", "maint" and "next" are never
rewound, so you should be able to safely track them (that means
the topics that have been merged into "next" are not rebased).

The "pu" (proposed updates) branch bundles all the remaining
topic branches.  The topic branches and "pu" are subject to
rebasing in general.  Especially "pu" is almost always rewound
to the tip of "next" and reconstructed to contain the remaining
topic branches.  What this means is that immediately after
cloning from git.git, it is advisable to mark "pu" in your
remotes/origin that it does not necessarily fast-forwards, like
this:

	$ cat .git/remotes/origin
        URL: git://git.kernel.org/pub/scm/git/git.git
        Pull: refs/heads/master:refs/heads/origin
        Pull: refs/heads/maint:refs/heads/maint
        Pull: refs/heads/next:refs/heads/next
        Pull: +refs/heads/pu:refs/heads/pu

When a topic that was in "pu" proves to be in testable shape, it
graduates to "next".  This is done by:

	git checkout next
        git pull . that-topic-branch

Sometimes, an idea that looked promising turns out to be not so
hot and the topic can be dropped from "pu" in such a case.

A topic that is in "next" is _expected_ to be tweaked and fixed
to perfection before it is merged to "master".  It is done by:

	git checkout master
        git pull . that-topic-branch
        git branch -d that-topic-branch

However, being in "next" is not a guarantee to appear in the
next release (being in "master" _is_ such a guarantee), or even
in _any_ future release.  There even was a case that a topic
needed a few reverting before graduating to "master".

Re: A note from the maintainer

[Jakub Narebski]

Junio C Hamano wrote:

> * Mailing list.
> 
> The development is primarily done on this mailing list you are
> reading right now.
> 
> If you have patches, please send them to the list, following
> Documentation/SubmittingPatches.
> 
> The list is available at various public sites as well:
> 
>         http://news.gmane.org/gmane.comp.version-control.git
>         http://marc.theaimsgroup.com/?l=git

It is also available via GMane NNTP (mail to news) interface as

  nntp://news.gmane.org/gmane.comp.version-control.git

so you can read it using your favourite news reader, without need
to be subscribed to mailing list.

It is better to send patches via email, not via news as 1.) news reader are
more likely to munge whitespace, 2) mail<->news gateway might munge
whitespace on it's own, though.
-- 
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git