- 31 3月, 2012 1 次提交
-
-
由 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>
-
- 13 1月, 2012 1 次提交
-
-
由 Jeff King 提交于
When creating a pack using objects that reside in existing packs, we try to avoid recomputing futile delta between an object (trg) and a candidate for its base object (src) if they are stored in the same packfile, and trg is not recorded as a delta already. This heuristics makes sense because it is likely that we tried to express trg as a delta based on src but it did not produce a good delta when we created the existing pack. As the pack heuristics prefer producing delta to remove data, and Linus's law dictates that the size of a file grows over time, we tend to record the newest version of the file as inflated, and older ones as delta against it. When creating a thin-pack to transfer recent history, it is likely that we will try to send an object that is recorded in full, as it is newer. But the heuristics to avoid recomputing futile delta effectively forbids us from attempting to express such an object as a delta based on another object. Sending an object in full is often more expensive than sending a suboptimal delta based on other objects, and it is even more so if we could use an object we know the receiving end already has (i.e. preferred base object) as the delta base. Tweak the recomputation avoidance logic, so that we do not punt on computing delta against a preferred base object. The effect of this change can be seen on two simulated upload-pack workloads. The first is based on 44 reflog entries from my git.git origin/master reflog, and represents the packs that kernel.org sent me git updates for the past month or two. The second workload represents much larger fetches, going from git's v1.0.0 tag to v1.1.0, then v1.1.0 to v1.2.0, and so on. The table below shows the average generated pack size and the average CPU time consumed for each dataset, both before and after the patch: dataset | reflog | tags --------------------------------- before | 53358 | 2750977 size after | 32398 | 2668479 change | -39% | -3% --------------------------------- before | 0.18 | 1.12 CPU after | 0.18 | 1.15 change | +0% | +3% This patch makes a much bigger difference for packs with a shorter slice of history (since its effect is seen at the boundaries of the pack) though it has some benefit even for larger packs. Signed-off-by: NJeff King <peff@peff.net> Acked-by: NNicolas Pitre <nico@fluxnic.net> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
- 07 1月, 2012 3 次提交
-
-
由 Michael Haggerty 提交于
The old code basically did: generate array of SHA1s for alternate refs for each unique SHA1 in array: add_extra_ref(".have", sha1) for each ref (including real refs and extra refs): show_ref(refname, sha1) But there is no need to stuff the alternate refs in extra_refs; we can call show_ref() directly when iterating over the array, then handle real refs separately. So change the code to: generate array of SHA1s for alternate refs for each unique SHA1 in array: show_ref(".have", sha1) for each ref (this now only includes real refs): show_ref(refname, sha1) Signed-off-by: NMichael Haggerty <mhagger@alum.mit.edu> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
由 Michael Haggerty 提交于
The function is not used as a callback, so it doesn't need these arguments. Also change its return type to void. Signed-off-by: NMichael Haggerty <mhagger@alum.mit.edu> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
由 Michael Haggerty 提交于
Move some more code from the calling site into write_head_info(), and inline add_alternate_refs() there. (Some more simplification is coming, and it is easier if all this code is in the same place.) Move some helper functions to avoid the need for forward declarations. Signed-off-by: NMichael Haggerty <mhagger@alum.mit.edu> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
- 06 1月, 2012 1 次提交
-
-
由 Junio C Hamano 提交于
Any existing commit signature was made against the contents of the old commit, including its committer date that is about to change, and will become invalid by amending it. Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
- 04 1月, 2012 1 次提交
-
-
由 Joey Hess 提交于
The FETCH_HEAD refname is supposed to refer to the ref that was fetched and should be merged. However all fetched refs are written to .git/FETCH_HEAD in an arbitrary order, and resolve_ref_unsafe simply takes the first ref as the FETCH_HEAD, which is often the wrong one, when other branches were also fetched. The solution is to write the for-merge ref(s) to FETCH_HEAD first. Then, unless --append is used, the FETCH_HEAD refname behaves as intended. If the user uses --append, they presumably are doing so in order to preserve the old FETCH_HEAD. While we are at it, update an old example in the read-tree documentation that implied that each entry in FETCH_HEAD only has the object name, which is not true for quite a while. [jc: adjusted tests] Signed-off-by: NJoey Hess <joey@kitenet.net> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
- 28 12月, 2011 1 次提交
-
-
由 Jelmer Vernooij 提交于
Signed-off-by: NJelmer Vernooij <jelmer@samba.org> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
- 22 12月, 2011 4 次提交
-
-
由 Carlos Martín Nieto 提交于
It is to give an alternate <name> instead of "origin" to the remote we are cloning from. Signed-off-by: NCarlos Martín Nieto <cmn@elego.de> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
由 Michael Schubert 提交于
"abbrev" and "commit_format" in struct rev_info get initialized in init_revisions - no need to reinit in cmd_log_init_defaults. Signed-off-by: NMichael Schubert <mschub@elegosoft.com> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
由 Ævar Arnfjörð Bjarmason 提交于
On Solaris the system headers define the "tmpfile" name, which'll cause Git compiled with Sun Studio 12 Update 1 to whine about us redefining the name: "pack-write.c", line 76: warning: name redefined by pragma redefine_extname declared static: tmpfile (E_PRAGMA_REDEFINE_STATIC) "sha1_file.c", line 2455: warning: name redefined by pragma redefine_extname declared static: tmpfile (E_PRAGMA_REDEFINE_STATIC) "fast-import.c", line 858: warning: name redefined by pragma redefine_extname declared static: tmpfile (E_PRAGMA_REDEFINE_STATIC) "builtin/index-pack.c", line 175: warning: name redefined by pragma redefine_extname declared static: tmpfile (E_PRAGMA_REDEFINE_STATIC) Just renaming the "tmpfile" variable to "tmp_file" in the relevant places is the easiest way to fix this. Signed-off-by: NÆvar Arnfjörð Bjarmason <avarab@gmail.com> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
由 Ævar Arnfjörð Bjarmason 提交于
In builtin/fast-export.c we'd assign to variables of the tag_of_filtered_mode enum type with constants defined for the signed_tag_mode enum. We'd get the intended value since both the value we were assigning with and the one we actually wanted had the same positional within their respective enums, but doing it this way makes no sense. This issue was spotted by Sun Studio 12 Update 1: "builtin/fast-export.c", line 54: warning: enum type mismatch: op "=" (E_ENUM_TYPE_MISMATCH_OP) Signed-off-by: NÆvar Arnfjörð Bjarmason <avarab@gmail.com> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
- 21 12月, 2011 2 次提交
-
-
由 Ævar Arnfjörð Bjarmason 提交于
On Solaris systems we'd warn about an implicit cast of mode_t when we printed things out with the %d format. We'd get this warning under GCC 4.6.0 with Solaris headers: builtin/init-db.c: In function ‘separate_git_dir’: builtin/init-db.c:354:4: warning: format ‘%d’ expects argument of type ‘int’, but argument 2 has type ‘mode_t’ [-Wformat] We've been doing this ever since v1.7.4.1-296-gb57fb80a. Just work around this by adding an explicit cast. Signed-off-by: NÆvar Arnfjörð Bjarmason <avarab@gmail.com> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
由 Junio C Hamano 提交于
The earlier ed7a42a0 (commit: teach --amend to carry forward extra headers, 2011-11-08) broke "git merge/pull; edit to fix conflict; git commit" workflow by forgetting that commit_tree_extended() takes the whole extra header list. Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
- 18 12月, 2011 1 次提交
-
-
由 René Scharfe 提交于
Maintaining an array of hashes is easier using sha1_array than open-coding it. This patch also fixes a leak of the SHA1 array in diff_tree_combined_merge(). Signed-off-by: NRené Scharfe <rene.scharfe@lsrfire.ath.cx> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
- 17 12月, 2011 2 次提交
-
-
由 Thomas Rast 提交于
Measurements by various people have shown that grepping in parallel is not beneficial when the object store is involved. For example, with a simple regex: Threads | --cached case | worktree case ---------------------------------------------------------------- 8 (default) | 2.88u 0.21s 0:02.94real | 0.19u 0.32s 0:00.16real 4 | 2.89u 0.29s 0:02.99real | 0.16u 0.34s 0:00.17real 2 | 2.83u 0.36s 0:02.87real | 0.18u 0.32s 0:00.26real NO_PTHREADS | 2.16u 0.08s 0:02.25real | 0.12u 0.17s 0:00.31real This happens because all the threads contend on read_sha1_mutex almost all of the time. A more complex regex allows the threads to do more work in parallel, but as Jeff King found out, the "super boost" (much higher clock when only one core is active) feature of recent CPUs still causes the unthreaded case to win by a large margin. So until the pack machinery allows unthreaded access, we disable grep's threading in all but the worktree case. Helped-by: NRené Scharfe <rene.scharfe@lsrfire.ath.cx> Helped-by: NJeff King <peff@peff.net> Signed-off-by: NThomas Rast <trast@student.ethz.ch> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
由 Thomas Rast 提交于
Lazily load the userdiff attributes in match_funcname(). Use a separate mutex around this loading to protect the (not thread-safe) attributes machinery. This lets us re-enable threading with -p and -W while reducing the overhead caused by looking up attributes. Signed-off-by: NThomas Rast <trast@student.ethz.ch> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
- 16 12月, 2011 7 次提交
-
-
由 Ramkumar Ramachandra 提交于
format_todo() calls get_message(), but uses only the subject line of the commit message. As a minor optimization, save work and unnecessary memory allocations by using find_commit_subject() instead. Also, remove the unnecessary check on cur->item->buffer: the lookup_commit_reference() call in parse_insn_line() has already made sure of this. Suggested-by: NJonathan Nieder <jrnieder@gmail.com> Helped-by: NJunio C Hamano <gitster@pobox.com> Signed-off-by: NRamkumar Ramachandra <artagnon@gmail.com> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
由 Ramkumar Ramachandra 提交于
Tolerate extra spaces and tabs as part of the the field separator in '.git/sequencer/todo', for people with fat fingers. Suggested-by: NJunio C Hamano <gitster@pobox.com> Signed-off-by: NRamkumar Ramachandra <artagnon@gmail.com> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
由 Ramkumar Ramachandra 提交于
Change the instruction sheet format subtly so that the subject of the commit message that follows the object name is optional. As a result, an instruction sheet like this is now perfectly valid: pick 35b0426 pick fbd5bbcbc2e pick 7362160f While at it, also fix a bug introduced by 5a5d80f4 (revert: Introduce --continue to continue the operation, 2011-08-04) that failed to read lines that are too long to fit on the commit-id-shaped buffer we currently use; eliminate the need for the buffer altogether. In addition to literal SHA-1 hexes, you can now safely use expressions like the following in the instruction sheet: featurebranch~4 rr/revert-cherry-pick-continue^2~12@{12 days ago} [jc: simplify parsing] Suggested-by: NJonathan Nieder <jrnieder@gmail.com> Helped-by: NJunio C Hamano <gitster@pobox.com> Signed-off-by: NRamkumar Ramachandra <artagnon@gmail.com> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
由 Ramkumar Ramachandra 提交于
Memory allocated to the fields of msg by get_message() isn't freed. This is potentially a big leak, because fresh memory is allocated to store the commit message for each commit. Fix this using free_message(). Reported-by: NJonathan Nieder <jrnieder@gmail.com> Signed-off-by: NRamkumar Ramachandra <artagnon@gmail.com> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
由 Nguyễn Thái Ngọc Duy 提交于
There wan't a way for commit_tree() to notice if the message the caller prepared contained a NUL byte, as it did not take the length of the message as a parameter. Use a pointer to a strbuf instead, so that we can either choose to allow low-level plumbing commands to make commits that contain NUL byte in its message, or forbid NUL everywhere by adding the check in commit_tree(), in later patches. Signed-off-by: NNguyễn Thái Ngọc Duy <pclouds@gmail.com> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
由 Nguyễn Thái Ngọc Duy 提交于
Signed-off-by: NNguyễn Thái Ngọc Duy <pclouds@gmail.com> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
由 Junio C Hamano 提交于
gcc 4.6.2 (there may be others) does not realize that the variable "mode" can never be used uninitialized in this function and issues a false warning under -Wuninitialized option. Squelch it with an unnecessary initialization; it is not like a single assignment matters to the performance in this codepath that writes out to the filesystem with checkout_entry() anyway. Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
- 14 12月, 2011 5 次提交
-
-
由 Jeff King 提交于
When showing the raw timestamp, we format the numeric seconds-since-epoch into a buffer, followed by the timezone string. This string has come straight from the commit object. A well-formed object should have a timezone string of only a few bytes, but we could be operating on data pushed by a malicious user. Signed-off-by: NJeff King <peff@peff.net> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
由 Jeff King 提交于
When we are determining the list of refs to fetch via fetch-pack, we have two sets of refs to compare: those on the remote side, and a "match" list of things we want to fetch. We iterate through the remote refs alphabetically, seeing if each one is wanted by the "match" list. Since def88e9a (Commit first cut at "git-fetch-pack", 2005-07-04), we have used the "path_match" function to do a suffix match, where a remote ref is considered wanted if any of the "match" elements is a suffix of the remote refname. This enables callers of fetch-pack to specify unqualified refs and have them matched up with remote refs (e.g., ask for "A" and get remote's "refs/heads/A"). However, if you provide a fully qualified ref, then there are corner cases where we provide the wrong answer. For example, given a remote with two refs: refs/foo/refs/heads/master refs/heads/master asking for "refs/heads/master" will first match "refs/foo/refs/heads/master" by the suffix rule, and we will erroneously fetch it instead of refs/heads/master. As it turns out, all callers of fetch_pack do provide fully-qualified refs for the match list. There are two ways fetch_pack can get match lists: 1. Through the transport code (i.e., via git-fetch) 2. On the command-line of git-fetch-pack In the first case, we will always be providing the names of fully-qualified refs from "struct ref" objects. We will have pre-matched those ref objects already (since we have to handle more advanced matching, like wildcard refspecs), and are just providing a list of the refs whose objects we need. In the second case, users could in theory be providing non-qualified refs on the command-line. However, the fetch-pack documentation claims that refs should be fully qualified (and has always done so since it was written in 2005). Let's change this path_match call to simply check for string equality, matching what the callers of fetch_pack are expecting. Signed-off-by: NJeff King <peff@peff.net> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
由 Jeff King 提交于
The get_remote_heads function reads the list of remote refs during git protocol session. It dates all the way back to def88e9a (Commit first cut at "git-fetch-pack", 2005-07-04). At that time, the idea was to come up with a list of refs we were interested in, and then filter the list as we got it from the remote side. Later, 1baaae5e (Make maximal use of the remote refs, 2005-10-28) stopped filtering at the get_remote_heads layer, letting us use the non-matching refs to find common history. As a result, all callers now simply pass an empty match list (and any future callers will want to do the same). So let's drop these now-useless parameters. Signed-off-by: NJeff King <peff@peff.net> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
由 Nguyễn Thái Ngọc Duy 提交于
resolve_ref() may return a pointer to a shared buffer and can be overwritten by the next resolve_ref() calls. Callers need to pay attention, not to keep the pointer when the next call happens. Rename with "_unsafe" suffix to warn developers (or reviewers) before introducing new call sites. This patch is generated using the following command git grep -l 'resolve_ref(' -- '*.[ch]'|xargs sed -i 's/resolve_ref(/resolve_ref_unsafe(/g' Signed-off-by: NNguyễn Thái Ngọc Duy <pclouds@gmail.com> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
由 Nguyễn Thái Ngọc Duy 提交于
Signed-off-by: NNguyễn Thái Ngọc Duy <pclouds@gmail.com> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
- 13 12月, 2011 11 次提交
-
-
由 Conrad Irwin 提交于
Tell the user what this command is intended for, and expand the description of what it does. Signed-off-by: NConrad Irwin <conrad.irwin@gmail.com> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
由 Jeff King 提交于
When a user asks us to force a mv and overwrite the destination, we print a warning. However, since a typical use would be: $ git mv one two fatal: destination exists, source=one, destination=two $ git mv -f one two warning: overwriting 'two' this warning is just noise. We already know we're overwriting; that's why we gave -f! This patch silences the warning unless "--verbose" is given. Signed-off-by: NJeff King <peff@peff.net> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
由 Jeff King 提交于
When we try to "git mv" over an existing file, the error message is fairly informative: $ git mv one two fatal: destination exists, source=one, destination=two When the user forces the overwrite, we give a warning: $ git mv -f one two warning: destination exists; will overwrite! This is less informative, but still sufficient in the simple rename case, as there is only one rename happening. But when moving files from one directory to another, it becomes useless: $ mkdir three $ touch one two three/one $ git add . $ git mv one two three fatal: destination exists, source=one, destination=three/one $ git mv -f one two three warning: destination exists; will overwrite! The first message is helpful, but the second one gives us no clue about what was overwritten. Let's mention the name of the destination file: $ git mv -f one two three warning: overwriting 'three/one' Signed-off-by: NJeff King <peff@peff.net> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
由 Jonathan Nieder 提交于
Now that "git reset" no longer implicitly removes .git/sequencer that the operator may or may not have wanted to keep, the logic to write a backup copy of .git/sequencer and remove it when stale is not needed any more. Simplify the sequencer API and repository layout by dropping it. Signed-off-by: NJonathan Nieder <jrnieder@gmail.com> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
由 Jonathan Nieder 提交于
As v1.7.8-rc0~141^2~4 (2011-08-04) explains, git cherry-pick removes the sequencer state just before applying the final patch. In the single-pick case, that was a good thing, since --abort and --continue work fine without access to such state and removing it provides a signal that git should not complain about the need to clobber it ("a cherry-pick or revert is already in progress") in sequences like the following: git cherry-pick foo git read-tree -m -u HEAD; # forget that; let's try a different one git cherry-pick bar After the recent patch "allow single-pick in the middle of cherry-pick sequence" we don't need that hack any more. In the new regime, a traditional "git cherry-pick <commit>" command never looks at .git/sequencer, so we do not need to cripple "git cherry-pick <commit>..<commit>" for it any more. So now you can run "git cherry-pick --abort" near the end of a multi-pick sequence and it will abort the entire sequence, instead of misbehaving and aborting just the final commit. Signed-off-by: NJonathan Nieder <jrnieder@gmail.com> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
由 Jonathan Nieder 提交于
After messing up a difficult conflict resolution in the middle of a cherry-pick sequence, it can be useful to be able to git checkout HEAD . && git cherry-pick that-one-commit to restart the conflict resolution. The current code however errors out saying that another cherry-pick is already in progress. Suggested-by: NJohannes Sixt <j6t@kdbg.org> Signed-off-by: NJonathan Nieder <jrnieder@gmail.com> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
由 Jonathan Nieder 提交于
Since 7e2bfd3f (revert: allow cherry-picking more than one commit, 2010-07-02), the pick/revert machinery has kept track of the set of commits to be cherry-picked or reverted using commit_argc and commit_argv variables, storing the corresponding command-line parameters. Future callers as other commands are built in (am, rebase, sequencer) may find it easier to pass rev-list options to this machinery in already-parsed form. Teach cmd_cherry_pick and cmd_revert to parse the rev-list arguments in advance and pass the commit set to pick_revisions() as a rev_info structure. Original patch by Jonathan, tweaks and test from Ram. Signed-off-by: NJonathan Nieder <jrnieder@gmail.com> Improved-by: NRamkumar Ramachandra <artagnon@gmail.com> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
由 Jonathan Nieder 提交于
When "git cherry-pick ..bar" encounters conflicts, permit the operator to use cherry-pick --continue after resolving them as a shortcut for "git commit && git cherry-pick --continue" to record the resolution and carry on with the rest of the sequence. This improves the analogy with "git rebase" (in olden days --continue was the way to preserve authorship when a rebase encountered conflicts) and fits well with a general UI goal of making "git cmd --continue" save humans the trouble of deciding what to do next. Example: after encountering a conflict from running "git cherry-pick foo bar baz": CONFLICT (content): Merge conflict in main.c error: could not apply f78a8d98c... bar! hint: after resolving the conflicts, mark the corrected paths hint: with 'git add <paths>' or 'git rm <paths>' hint: and commit the result with 'git commit' We edit main.c to resolve the conflict, mark it acceptable with "git add main.c", and can run "cherry-pick --continue" to resume the sequence. $ git cherry-pick --continue [editor opens to confirm commit message] [master 78c8a8c98] bar! 1 files changed, 1 insertions(+), 1 deletions(-) [master 87ca8798c] baz! 1 files changed, 1 insertions(+), 1 deletions(-) This is done for both codepaths to pick multiple commits and a single commit. Signed-off-by: NJonathan Nieder <jrnieder@gmail.com> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
由 Jonathan Nieder 提交于
This makes pick_revisions() a little shorter and easier to read straight through. Signed-off-by: NJonathan Nieder <jrnieder@gmail.com> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
由 Jeff King 提交于
If you try to "git mv" multiple files onto another non-directory file, you confusingly get the "usage" message: $ touch one two three $ git add . $ git mv one two three usage: git mv [options] <source>... <destination> [...] From the user's perspective, that makes no sense. They just gave parameters that exactly match that usage! This behavior dates back to the original C version of "git mv", which had a usage message like: usage: git mv (<source> <destination> | <source>... <destination>) This was slightly less confusing, because it at least mentions that there are two ways to invoke (but it still isn't clear why what the user provided doesn't work). Instead, let's show an error message like: $ git mv one two three fatal: destination 'three' is not a directory We could leave the usage message in place, too, but it doesn't actually help here. It contains no hints that there are two forms, nor that multi-file form requires that the endpoint be a directory. So it just becomes useless noise that distracts from the real error. Signed-off-by: NJeff King <peff@peff.net> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
由 Jeff King 提交于
The code for a verbose flag has been here since "git mv" was converted to C many years ago, but actually getting the "-v" flag from the command line was accidentally lost in the transition. Signed-off-by: NJeff King <peff@peff.net> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-