Instead of making translators translate "remote " and then using
"%sbranch" where "%s" is either "remote " or "" just split the two up
into separate messages. This makes the translation of this section of
git-branch much less confusing.
Signed-off-by: NÆvar Arnfjörð Bjarmason <avarab@gmail.com>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

Signed-off-by: NChristian Couder <chriscool@tuxfamily.org>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

This is used by "git pull" to construct a merge message from list of
remote refs.  When pulling redundant set of refs, however, it did not
filter them even though the merge itself discards them as unnecessary.

Teach the command to do the same for consistency.
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

git-gc executes many sub-commands. The argument list for
some of these is constant, but for others we add more
arguments at runtime. The latter is implemented by allocating
a constant extra number of NULLs, and either using a custom
append function, or just referencing unused slots by number.

As of commit 7e52f566, which added two new arguments, it is
possible to exceed the constant number of slots for "repack"
by running "git gc --aggressive", causing "git gc" to die.

This patch converts all of the static argv lists to use
argv-array. In addition to fixing the overflow caused by
7e52f566, it has a few advantages:

  1. We can drop the custom append function (which,
     incidentally, had an off-by-one error exacerbating the
     static limit).

  2. We can drop the ugly magic numbers used when adding
     arguments to "prune".

  3. Adding further arguments will be easier; you can just
     add new "push" calls without worrying about increasing
     any static limits.
Signed-off-by: NJeff King <peff@peff.net>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

Instead of waiting until we record the parents of resulting merge, reduce
redundant parents (including our HEAD) immediately after reading them.

The change to t7602 illustrates the essence of the effect of this change.
The octopus merge strategy used to be fed with redundant commits only to
discard them as "up-to-date", but we no longer feed such redundant commits
to it and the affected test degenerates to a regular two-head merge.

And obviously the known-to-be-broken test in t6028 is now fixed.
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

Move the code around to populate remoteheads list early in the process
before any decision regarding twohead vs octopus and fast-forwardness is
made.
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

Instead pass it around starting from the toplevel cmd_merge()
as an explicit parameter.
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

update_local_ref() used to say "[new branch]" when we stored a new ref
outside refs/tags/ hierarchy, but the message is more about what we
fetched, so use the refname at the origin to make that decision.

Also, only call a new ref a "branch" if it's under refs/heads/.
Signed-off-by: NMarc Branchaud <marcnarc@xiplink.com>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

This way, the function can look at the remote side to adjust the
informational message it gives.
Signed-off-by: NMarc Branchaud <marcnarc@xiplink.com>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

If a commit-ish passed to cherry-pick or revert happens to have a file
of the same name, git complains that the argument is ambiguous and
advises to use '--'. To make things worse, the '--' argument is removed
by parse_options, und so passing '--' has no effect.

Instead, always interpret cherry-pick/revert arguments as revisions.
Signed-off-by: NClemens Buchacher <drizzd@aon.at>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

Since 88a21979 (fetch/pull: recurse into submodules when necessary) all
fetched commits are examined if they contain submodule changes (unless
configuration or command line options inhibit that). If a newly recorded
submodule commit is not present in the submodule, a fetch is run inside
it to download that commit.

Checking new refs was done in an else branch where it wasn't executed for
tags. This normally isn't a problem because tags are only fetched with
the branches they live on, then checking the new commits in the fetched
branches for submodule commits will also process all tags. But when a
specific tag is fetched (or the refspec contains refs/tags/) commits only
reachable by tags won't be searched for submodule commits, which is a bug.

Fix that by moving the code outside the if/else construct to handle new
tags just like any other ref. The performance impact of adding tags that
most of the time lie on a branch which is checked anyway for new submodule
commit should be minimal, as since 6859de45 (fetch: avoid quadratic loop
checking for updated submodules) all ref-tips are collected first and then
fed to a single rev-list.
Spotted-by: NJeff King <peff@peff.net>
Signed-off-by: NJens Lehmann <Jens.Lehmann@web.de>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

In general, the private functions in this file were not very
much documented; even though what each of them do is reasonably
self explanatory, the ownership rules for various buffers and
data structures were not very obvious.
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

These point into a single line in the patch text we read from
the input, and they are not used to modify it.
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

CHUNKSIZE is no longer used.
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

Between v1.7.1 and v1.7.2, 582aa00b switched the default "diff"
invocation not to use XDF_NEED_MINIMAL, but this breaks "git blame"
rather badly.

Allow the command line option to ask for an extra careful matching.
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

When we pack everything into one big pack with "git repack
-Ad", any unreferenced objects in to-be-deleted packs are
exploded into loose objects, with the intent that they will
be examined and possibly cleaned up by the next run of "git
prune".

Since the exploded objects will receive the mtime of the
pack from which they come, if the source pack is old, those
loose objects will end up pruned immediately. In that case,
it is much more efficient to skip the exploding step
entirely for these objects.

This patch teaches pack-objects to receive the expiration
information and avoid writing these objects out. It also
teaches "git gc" to pass the value of gc.pruneexpire to
repack (which in turn learns to pass it along to
pack-objects) so that this optimization happens
automatically during "git gc" and "git gc --auto".
Signed-off-by: NJeff King <peff@peff.net>
Acked-by: NNicolas Pitre <nico@fluxnic.net>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

Print out a trailing newline when --show-prefix is run with cwd
at the top level of the tree which results in an empty prefix.
Behavior is now like --show-cdup.

Fixes an expected failure in t1501.
Signed-off-by: NRoss Lagerwall <rosslagerwall@gmail.com>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

Add missing options "--tags|--no-tags" and "--push".
Signed-off-by: NMichael Schubert <mschub@elegosoft.com>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

The user can say "git push" without specifying any refspec.  When using
the "upstream" semantics via the push.default configuration, the user
wants to update the "upstream" branch of the current branch, which is the
branch at a remote repository the current branch is set to integrate with,
with this command.

However, there are cases that such a "git push" that uses the "upstream"
semantics does not make sense:

 - The current branch does not have branch.$name.remote configured.  By
   definition, "git push" that does not name where to push to will not
   know where to push to.  The user may explicitly say "git push $there",
   but again, by definition, no branch at repository $there is set to
   integrate with the current branch in this case and we wouldn't know
   which remote branch to update.

 - The current branch does have branch.$name.remote configured, but it
   does not specify branch.$name.merge that names what branch at the
   remote this branch integrates with. "git push" knows where to push in
   this case (or the user may explicitly say "git push $remote" to tell us
   where to push), but we do not know which remote branch to update.

 - The current branch does have its remote and upstream branch configured,
   but the user said "git push $there", where $there is not the remote
   named by "branch.$name.remote".  By definition, no branch at repository
   $there is set to integrate with the current branch in this case, and
   this push is not meant to update any branch at the remote repository
   $there.

The first two cases were already checked correctly, but the third case was
not checked and we ended up updating the branch named branch.$name.merge
at repository $there, which was totally bogus.
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

If a remote repo has too many tags (or branches), cloning it over the
smart HTTP transport can fail because remote-curl.c puts all the refs
from the remote repo on the fetch-pack command line. This can make the
command line longer than the global OS command line limit, causing
fetch-pack to fail.

This is especially a problem on Windows where the command line limit is
orders of magnitude shorter than Linux. There are already real repos out
there that msysGit cannot clone over smart HTTP due to this problem.

Here is an easy way to trigger this problem:

	git init too-many-refs
	cd too-many-refs
	echo bla > bla.txt
	git add .
	git commit -m test
	sha=$(git rev-parse HEAD)
	tag=$(perl -e 'print "bla" x 30')
	for i in `seq 50000`; do
		echo $sha refs/tags/$tag-$i >> .git/packed-refs
	done

Then share this repo over the smart HTTP protocol and try cloning it:

	$ git clone http://localhost/.../too-many-refs/.git
	Cloning into 'too-many-refs'...
	fatal: cannot exec 'fetch-pack': Argument list too long

50k tags is obviously an absurd number, but it is required to
demonstrate the problem on Linux because it has a much more generous
command line limit. On Windows the clone fails with as little as 500
tags in the above loop, which is getting uncomfortably close to the
number of tags you might see in real long lived repos.

This is not just theoretical, msysGit is already failing to clone our
company repo due to this. It's a large repo converted from CVS, nearly
10 years of history.

Four possible solutions were discussed on the Git mailing list (in no
particular order):

1) Call fetch-pack multiple times with smaller batches of refs.

This was dismissed as inefficient and inelegant.

2) Add option --refs-fd=$n to pass a an fd from where to read the refs.

This was rejected because inheriting descriptors other than
stdin/stdout/stderr through exec() is apparently problematic on Windows,
plus it would require changes to the run-command API to open extra
pipes.

3) Add option --refs-from=$tmpfile to pass the refs using a temp file.

This was not favored because of the temp file requirement.

4) Add option --stdin to pass the refs on stdin, one per line.

In the end this option was chosen as the most efficient and most
desirable from scripting perspective.

There was however a small complication when using stdin to pass refs to
fetch-pack. The --stateless-rpc option to fetch-pack also uses stdin for
communication with the remote server.

If we are going to sneak refs on stdin line by line, it would have to be
done very carefully in the presence of --stateless-rpc, because when
reading refs line by line we might read ahead too much data into our
buffer and eat some of the remote protocol data which is also coming on
stdin.

One way to solve this would be to refactor get_remote_heads() in
fetch-pack.c to accept a residual buffer from our stdin line parsing
above, but this function is used in several places so other callers
would be burdened by this residual buffer interface even when most of
them don't need it.

In the end we settled on the following solution:

If --stdin is specified without --stateless-rpc, fetch-pack would read
the refs from stdin one per line, in a script friendly format.

However if --stdin is specified together with --stateless-rpc,
fetch-pack would read the refs from stdin in packetized format
(pkt-line) with a flush packet terminating the list of refs. This way we
can read the exact number of bytes that we need from stdin, and then
get_remote_heads() can continue reading from the same fd without losing
a single byte of remote protocol data.

This way the --stdin option only loses generality and scriptability when
used together with --stateless-rpc, which is not easily scriptable
anyway because it also uses pkt-line when talking to the remote server.
Signed-off-by: NIvan Todoroski <grnch@gmx.net>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

When the user exited editor without editing the commit log template given
by "git commit -t <template>", the commit was aborted (correct) with an
error message that said "due to empty commit message" (incorrect).

This was because the original template support was done by piggybacking on
the check to detect an empty log message.  Split the codepaths into two
independent checks to clarify the error.
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

When "-t template" and "-F msg" options are both given (or worse yet,
there is "commit.template" configuration but a message is given in some
other way), the documentation says that template is ignored.  However,
the "has the user edited the message?" check still used the contents of
the template file as the basis of the emptyness check.
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

When using this option git will search for all submodules that
have changed in the revisions to be send. It will then try to
push the currently checked out branch of each submodule.

This helps when a user has finished working on a change which
involves submodules and just wants to push everything in one go.
Signed-off-by: NFredrik Gustafsson <iveqy@iveqy.com>
Mentored-by: NJens Lehmann <Jens.Lehmann@web.de>
Mentored-by: NHeiko Voigt <hvoigt@hvoigt.net>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

We simply discarded the fragments that we are not going to use upon seeing
a patch to update the submodule commit bound at path that we have not
checked out.

Free these fragments, not to leak them.
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

v1.7.9-8-g270a3443 (config: stop using config_exclusive_filename) replaced
config_exclusive_filename with given_config_file.  In one case this
resulted in a self-assignment, which is reported by clang as a warning.
Remove the useless code.
Signed-off-by: NRene Scharfe <rene.scharfe@lsrfire.ath.cx>
Acked-by: NJeff King <peff@peff.net>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

This is by far the largest piece of data, much larger than the patch and
fragment structures or the three name fields in the patch structure.
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

The fn_table is used to record the result of earlier patch application in
case a hand-crafted input file contains multiple patches to the same file.
Both its string key (filename) and the contents are borrowed from "struct
patch" that represents the previous application in the same apply_patch()
call, and they do not leak, but the table itself was not freed properly.
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

These were all allocated in the heap by parsing the header parts of the
patch, but we did not bother to free them.  Some used to share the memory
(e.g. copying def_name to old_name) so this is not just the matter of
adding three calls to free().
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

As that is the only logical name for a function that walks a list
and frees each element on it.
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

There's currently no way to suppress the informational
"deleted branch..." or "set up tracking..." messages.  This
patch provides a "-q" option to do so.
Signed-off-by: NJeff King <peff@peff.net>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

Like the "switched to..." message (which is already
suppressed by "-q"), this message is purely informational.
Let's silence it if the user asked us to be quiet.

This patch is slightly more than a one-liner, because we
have to teach create_branch to propagate the flag all the
way down to install_branch_config.
Signed-off-by: NJeff King <peff@peff.net>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

This macro already evaluates to the correct type, as it
casts the string literal to "unsigned char *" itself
(and callers who want the literal can use the _LITERAL
form).
Signed-off-by: NJeff King <peff@peff.net>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

Even though 1.7.9.x series does not open the editor by default
when merging in general, it does do so in one occassion: when
merging an annotated tag. And worse yet, there is no good way
for older scripts to decline this.

Backport the support for GIT_MERGE_AUTOEDIT environment variable
from 1.7.10 track to help those stuck on 1.7.9.x maintenance
track.
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

Pushing a non-fast-forward update to a remote repository will result in
an error, but the hint text doesn't provide the correct resolution in
every case. Give better resolution advice in three push scenarios:

1) If you push your current branch and it triggers a non-fast-forward
error, you should merge remote changes with 'git pull' before pushing
again.

2) If you push to a shared repository others push to, and your local
tracking branches are not kept up to date, the 'matching refs' default
will generate non-fast-forward errors on outdated branches. If this is
your workflow, the 'matching refs' default is not for you. Consider
setting the 'push.default' configuration variable to 'current' or
'upstream' to ensure only your current branch is pushed.

3) If you explicitly specify a ref that is not your current branch or
push matching branches with ':', you will generate a non-fast-forward
error if any pushed branch tip is out of date. You should checkout the
offending branch and merge remote changes before pushing again.

Teach transport.c to recognize these scenarios and configure push.c
to hint for them. If 'git push's default behavior changes or we
discover more scenarios, extension is easy. Standardize on the
advice API and add three new advice variables, 'pushNonFFCurrent',
'pushNonFFDefault', and 'pushNonFFMatching'. Setting any of these
to 'false' will disable their affiliated advice. Setting
'pushNonFastForward' to false will disable all three, thus preserving the
config option for users who already set it, but guaranteeing new
users won't disable push advice accidentally.
Based-on-patch-by: NJunio C Hamano <gitster@pobox.com>
Signed-off-by: NChristopher Tiwald <christiwald@gmail.com>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

As we already walk the history of the branch that gets merged to
come up with a short log, let's label it with names of the primary
authors, so that the user who summarizes the merge can easily give
credit to them in the log message.

Also infer the names of "lieutents" to help integrators at higher
level of the food-chain to give credit to them, by counting:

 * The committer of the 'tip' commit that is merged
 * The committer of merge commits that are merged

Often the first one gives the owner of the history being pulled, but
his last pull from his sublieutenants may have been a fast-forward,
in which case the first one would not be.  The latter rule will
count the integrator of the history, so together it might be a
reasonable heuristics.

There are two special cases:

 - The "author" credit is omitted when the series is written solely
   by the same author who is making the merge. The name can be seen
   on the "Author" line of the "git log" output to view the log
   message anyway.

 - The "lieutenant" credit is omitted when there is only one key
   committer in the merged branch and it is the committer who is
   making the merge. Typically this applies to the case where the
   developer merges his own branch.
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

When lying the author name via GIT_AUTHOR_NAME environment variable
to "git commit", the hooks run by the command saw it and could act
on the name that will be recorded in the final commit. When the user
uses the "--author" option from the command line, the command should
give the same information to the hook, and back when "git command"
was a scripted Porcelain, it did set the environment variable and
hooks can learn the author name from it.

However, when the command was reimplemented in C, the rewritten code
was not very faithful to the original, and hooks stopped getting the
authorship information given with "--author".  Fix this by exporting
the necessary environment variables.
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

Modify verify-tag to load relevant GPG variables from the git
configuratio file.  This allows git tag -v to use an alternative
GPG binary in the same way that git tag -s does.
Signed-off-by: NAlex Zepeda <alex@inferiorhumanorgans.com>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

In the while loop inside apply_patch, patch and fragments are
dynamically allocated with a calloc. However, only unused patches
are actually freed and the rest are left to leak. Since a list is
actively built up consisting of the used patches, they can simply be
iterated and freed at the end of the function.

In addition, the text in fragments were not freed, primarily because
they mostly point into a patch text that is freed as a whole. But
there are some cases where new piece of memory is allocated and
pointed by a fragment (namely, when handling a binary patch).

Introduce a free_patch bitfield to mark each fragment if its text
needs to be freed, and free patches, fragments and fragment text
that need to be freed when we are done with the input.
Signed-off-by: NJared Hance <jaredhance@gmail.com>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

Both git-prune and git-repack (and thus, git-gc) try to rmdir while
holding a DIR* handle on the directory.  This can leave dangling
empty directories in the .git/objects on platforms where directory
cannot be removed while they are open.

First call closedir() and then rmdir(); that is more logical ordering.
Reported-by: NJohn Chen <john0312@gmail.com>
Reported-by: NStefan Naewe <stefan.naewe@gmail.com>
Signed-off-by: NKarsten Blees <blees@dcon.de>
Improved-and-Acked-by: NJohannes Sixt <j6t@kdbg.org>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

This command indirectly calls check_sha1_signature() (add_info_ref ->
deref_tag -> parse_object -> ..) , which may put whole blob in memory
if the blob's size is under core.bigfilethreshold. As config is not
read, the threshold is always 512MB. Respect user settings here.
Signed-off-by: NNguyễn Thái Ngọc Duy <pclouds@gmail.com>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>