- 01 5月, 2012 1 次提交
-
-
由 Ævar Arnfjörð Bjarmason 提交于
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>
-
- 22 4月, 2012 1 次提交
-
-
由 Christian Couder 提交于
Signed-off-by: NChristian Couder <chriscool@tuxfamily.org> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
- 19 4月, 2012 2 次提交
-
-
由 Junio C Hamano 提交于
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>
-
由 Jeff King 提交于
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>
-
- 18 4月, 2012 3 次提交
-
-
由 Junio C Hamano 提交于
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>
-
由 Junio C Hamano 提交于
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>
-
由 Junio C Hamano 提交于
Instead pass it around starting from the toplevel cmd_merge() as an explicit parameter. Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
- 17 4月, 2012 2 次提交
-
-
由 Marc Branchaud 提交于
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>
-
由 Marc Branchaud 提交于
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>
-
- 16 4月, 2012 1 次提交
-
-
由 Clemens Buchacher 提交于
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>
-
- 15 4月, 2012 1 次提交
-
-
由 Jens Lehmann 提交于
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>
-
- 12 4月, 2012 5 次提交
-
-
由 Junio C Hamano 提交于
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>
-
由 Junio C Hamano 提交于
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>
-
由 Junio C Hamano 提交于
CHUNKSIZE is no longer used. Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
由 Junio C Hamano 提交于
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>
-
由 Jeff King 提交于
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>
-
- 11 4月, 2012 1 次提交
-
-
由 Ross Lagerwall 提交于
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>
-
- 10 4月, 2012 1 次提交
-
-
由 Michael Schubert 提交于
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>
-
- 06 4月, 2012 1 次提交
-
-
由 Junio C Hamano 提交于
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>
-
- 03 4月, 2012 1 次提交
-
-
由 Ivan Todoroski 提交于
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>
-
- 31 3月, 2012 3 次提交
-
-
由 Junio C Hamano 提交于
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>
-
由 Junio C Hamano 提交于
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>
-
由 Heiko Voigt 提交于
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>
-
- 29 3月, 2012 2 次提交
-
-
由 Junio C Hamano 提交于
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>
-
由 René Scharfe 提交于
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>
-
- 28 3月, 2012 4 次提交
-
-
由 Junio C Hamano 提交于
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>
-
由 Junio C Hamano 提交于
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>
-
由 Junio C Hamano 提交于
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>
-
由 Junio C Hamano 提交于
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>
-
- 27 3月, 2012 2 次提交
-
-
由 Jeff King 提交于
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>
-
由 Jeff King 提交于
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>
-
- 24 3月, 2012 1 次提交
-
-
由 Jeff King 提交于
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>
-
- 21 3月, 2012 1 次提交
-
-
由 Junio C Hamano 提交于
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>
-
- 20 3月, 2012 1 次提交
-
-
由 Christopher Tiwald 提交于
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>
-
- 14 3月, 2012 1 次提交
-
-
由 Junio C Hamano 提交于
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>
-
- 12 3月, 2012 1 次提交
-
-
由 Junio C Hamano 提交于
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>
-
- 09 3月, 2012 1 次提交
-
-
由 Alex Zepeda 提交于
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>
-
- 08 3月, 2012 3 次提交
-
-
由 Jared Hance 提交于
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>
-
由 Karsten Blees 提交于
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>
-
由 Nguyễn Thái Ngọc Duy 提交于
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>
-