- 17 5月, 2013 11 次提交
-
-
由 Kevin Bracey 提交于
When simplifying an odd merge, such as one that used "-s ours", we may find ourselves TREESAME to apparently redundant parents. Prevent simplify_merges() from removing every TREESAME parent; if this would happen reinstate the first TREESAME parent - the one that the default log would have followed. This avoids producing a totally disjoint history from the default log when the default log is a better explanation of the end result, and aids visualisation of odd merges. Signed-off-by: NKevin Bracey <kevin@bracey.fi> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
由 Junio C Hamano 提交于
Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
由 Kevin Bracey 提交于
History simplification previously always treated merges as TREESAME if they were TREESAME to any parent. While this was consistent with the default behaviour, this could be extremely unhelpful when searching detailed history, and could not be overridden. For example, if a merge had ignored a change, as if by "-s ours", then: git log -m -p --full-history -Schange file would successfully locate "change"'s addition but would not locate the merge that resolved against it. Futher, simplify_merges could drop the actual parent that a commit was TREESAME to, leaving it as a normal commit marked TREESAME that isn't actually TREESAME to its remaining parent. Now redefine a commit's TREESAME flag to be true only if a commit is TREESAME to _all_ of its parents. This doesn't affect either the default simplify_history behaviour (because partially TREESAME merges are turned into normal commits), or full-history with parent rewriting (because all merges are output). But it does affect other modes. The clearest difference is that --full-history will show more merges - sufficient to ensure that -m -p --full-history log searches can really explain every change to the file, including those changes' ultimate fate in merges. Also modify simplify_merges to recalculate TREESAME after removing a parent. This is achieved by storing per-parent TREESAME flags on the initial scan, so the combined flag can be easily recomputed. This fixes some t6111 failures, but creates a couple of new ones - we are now showing some merges that don't need to be shown. Signed-off-by: NKevin Bracey <kevin@bracey.fi> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
由 Kevin Bracey 提交于
The documentation of --boundary uses the term "uninteresting", which is not used or defined anywhere else in the documentation. This is unhelpful and confusing to anyone who hasn't seen the UNINTERESTING flag in the source code. Change to use "excluded", as per revisions.txt. Signed-off-by: NKevin Bracey <kevin@bracey.fi> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
由 Kevin Bracey 提交于
In the example given, P is not TREESAME to E. This doesn't affect the current result, but it will matter when we change behaviour. Signed-off-by: NKevin Bracey <kevin@bracey.fi> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
由 Kevin Bracey 提交于
Signed-off-by: NKevin Bracey <kevin@bracey.fi> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
由 Junio C Hamano 提交于
Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
由 Kevin Bracey 提交于
Some side branching and odd merging to illustrate various flaws in revision list scans, particularly when limiting the list. Many expected failures, which will be gone by the end of the "history traversal refinements" series. Signed-off-by: NKevin Bracey <kevin@bracey.fi> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
由 Kevin Bracey 提交于
In preparation for upcoming TREESAME work, check the result for G.t, which is dropped in "-s ours" merge L. The default rev-list is empty, as expected - it follows the first parent path where it never existed. Unfortunately, --ancestry-path is also empty. Merges H J and L are all TREESAME to 1 parent, so are treated as TREESAME and not shown. This is clearly undesirable in the case of merge L, which dropped our G.t by taking the non-ancestry-path version. Document this as a known failure, and expect "H J L", the 3 merges along the path that had to chose G.t versions. Signed-off-by: NKevin Bracey <kevin@bracey.fi> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
由 Kevin Bracey 提交于
When growing the table, take the opportunity to "compact" it by removing entries with NULL decoration. Users may have "removed" decorations by passing NULL to insert_decoration. An object's table entry can't actually be removed during normal operation, as it would break the linear hash collision search. But we can remove NULL decoration entries when rebuilding the table. Signed-off-by: NKevin Bracey <kevin@bracey.fi> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
由 Kevin Bracey 提交于
The documentation assures users that "A...B" is defined as "A B --not $(git merge-base --all A B)". This wasn't in fact quite true, because the calculated merge bases were not sent to add_rev_cmdline(). The main effect of this was that although git rev-list --ancestry-path A B --not $(git merge-base --all A B) worked, the simpler form git rev-list --ancestry-path A...B failed with a "no bottom commits" error. Other potential users of bottom commits could also be affected by this problem, if they examine revs->cmdline_info; I came across the issue in my proposed history traversal refinements series. So ensure that the calculated merge bases are sent to add_rev_cmdline(), flagged with new 'whence' enum value REV_CMD_MERGE_BASE. Signed-off-by: NKevin Bracey <kevin@bracey.fi> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
- 14 5月, 2013 1 次提交
-
-
由 Kevin Bracey 提交于
Signed-off-by: NKevin Bracey <kevin@bracey.fi> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
- 12 5月, 2013 2 次提交
-
-
由 Torsten Bögershausen 提交于
Using sed -e '/[0-9]\+//' to find "one or more digits" is not portable. Use the Basic Regular Expression '/[0-9][0-9]*//' instead. Signed-off-by: NTorsten Bögershausen <tboegi@web.de> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
git://git.bogomips.org/git-svn由 Junio C Hamano 提交于
* git://git.bogomips.org/git-svn: git-svn: added an --include-path flag Git::SVN::*: add missing "NAME" section to perldoc git-svn: avoid self-referencing mergeinfo
-
- 10 5月, 2013 9 次提交
-
-
由 Junio C Hamano 提交于
* maint: Git 1.8.2.3 t5004: avoid using tar for checking emptiness of archive t5004: ignore pax global header file mergetools/kdiff3: do not use --auto when diffing transport-helper: trivial style cleanup
-
由 Junio C Hamano 提交于
Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
由 Junio C Hamano 提交于
Fix "git cherry-pick $annotated_tag", which was mistakenly rejected. * mv/sequencer-pick-error-diag: cherry-pick: picking a tag that resolves to a commit is OK
-
由 Junio C Hamano 提交于
Earlier, 21246dbb (cherry-pick: make sure all input objects are commits, 2013-04-11) tried to catch an unlikely "git cherry-pick $blob" as an error, but broke a more important use case to cherry-pick a tag that points at a commit. Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
由 Junio C Hamano 提交于
* tr/copy-revisions-from-stdin: read_revisions_from_stdin: make copies for handle_revision_arg
-
由 René Scharfe 提交于
Test 2 of t5004 checks if a supposedly empty tar archive really contains no files. 24676f02 (t5004: fix issue with empty archive test and bsdtar) removed our commit hash to make it work with bsdtar, but the test still fails on NetBSD and OpenBSD, which use their own tar that considers a tar file containing only NULs as broken. Here's what the different archivers do when asked to create a tar file without entries: $ uname -v NetBSD 6.0.1 (GENERIC) $ gtar --version | head -1 tar (GNU tar) 1.26 $ bsdtar --version bsdtar 2.8.4 - libarchive 2.8.4 $ : >zero.tar $ perl -e 'print "\0" x 10240' >tenk.tar $ sha1 zero.tar tenk.tar SHA1 (zero.tar) = da39a3ee5e6b4b0d3255bfef95601890afd80709 SHA1 (tenk.tar) = 34e163be8e43c5631d8b92e9c43ab0bf0fa62b9c $ : | tar cf - -T - | sha1 da39a3ee5e6b4b0d3255bfef95601890afd80709 $ : | gtar cf - -T - | sha1 34e163be8e43c5631d8b92e9c43ab0bf0fa62b9c $ : | bsdtar cf - -T - | sha1 34e163be8e43c5631d8b92e9c43ab0bf0fa62b9c So NetBSD's native tar creates an empty file, while GNU tar and bsdtar both give us 10KB of NULs -- just like git archive with an empty tree. Now let's see how the archivers handle these two kinds of empty tar files: $ tar tf zero.tar; echo $? tar: Unexpected EOF on archive file 1 $ gtar tf zero.tar; echo $? gtar: This does not look like a tar archive gtar: Exiting with failure status due to previous errors 2 $ bsdtar tf zero.tar; echo $? 0 $ tar tf tenk.tar; echo $? tar: Cannot identify format. Searching... tar: End of archive volume 1 reached tar: Sorry, unable to determine archive format. 1 $ gtar tf tenk.tar; echo $? 0 $ bsdtar tf tenk.tar; echo $? 0 NetBSD's tar complains about both, bsdtar happily accepts any of them and GNU tar doesn't like zero-length archive files. So the safest course of action is to stay with our block-of-NULs format which is compatible with GNU tar and bsdtar, as we can't make NetBSD's native tar happy anyway. We can simplify our test, however, by taking tar out of the picture. Instead of extracting the archive and checking for the non-presence of files, check if the file has a size of 10KB and contains only NULs. This makes t5004 pass on NetBSD and OpenBSD. Signed-off-by: NRene Scharfe <rene.scharfe@lsrfire.ath.cx> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
由 René Scharfe 提交于
Versions of tar that don't know pax headers -- like the ones in NetBSD 6 and OpenBSD 5.2 -- extract them as regular files. Explicitly ignore the file created for our global header when checking the list of extracted files, as this is normal and harmless fall-back behaviour. This fixes test 3 of t5004 on these platforms. Signed-off-by: NRene Scharfe <rene.scharfe@lsrfire.ath.cx> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
由 David Aguilar 提交于
The `kdiff3 --auto` help message is, "No GUI if all conflicts are auto- solvable." This flag was carried over from the original mergetool commands. diff_cmd() is for two-way comparisons only so remove the superfluous flag. Signed-off-by: NDavid Aguilar <davvid@gmail.com> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
由 Felipe Contreras 提交于
Signed-off-by: NFelipe Contreras <felipe.contreras@gmail.com> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
- 09 5月, 2013 3 次提交
-
-
由 Paul Walmsley 提交于
The SVN::Fetcher module is now able to filter for inclusion as well as exclusion (as used by --ignore-path). Also added tests, documentation changes and git completion script. If you have an SVN repository with many top level directories and you only want a git-svn clone of some of them then using --ignore-path is difficult as it requires a very long regexp. In this case it's much easier to filter for inclusion. [ew: remove trailing whitespace] Signed-off-by: NPaul Walmsley <pjwhams@gmail.com> Signed-off-by: NEric Wong <normalperson@yhbt.net>
-
由 Jonathan Nieder 提交于
lexgrog(1) relies on the NAME section to find a manpage's subject's name and description for easy access later using "man -k". Add the section it expects. Noticed using lintian. Signed-off-by: NJonathan Nieder <jrnieder@gmail.com> Signed-off-by: NEric Wong <normalperson@yhbt.net>
-
由 Michael Contreras 提交于
When svn.pushmergeinfo is set, the target branch is included in the mergeinfo if it was previously merged into one of the source branches. SVN does not do this. Remove merge target branch path from resulting mergeinfo when svn.pushmergeinfo is set to better match the behavior of SVN. Update the svn-mergeinfo-push test. [ew: 80 columns] Signed-off-by: NMichael Contreras <michael@inetric.com> Reported-by: NAvishay Lavie <avishay.lavie@gmail.com> Acked-by: NEric Wong <normalperson@yhbt.net>
-
- 08 5月, 2013 6 次提交
-
-
由 Junio C Hamano 提交于
Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
由 Felipe Contreras 提交于
The comment was copied from hg-fast-export, not used anymore. Signed-off-by: NFelipe Contreras <felipe.contreras@gmail.com> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
由 Felipe Contreras 提交于
It's possible that the previous tip goes away, we should not assume it's always present. Fortunately we are only using it to calculate the progress to display to the user, so only that needs to be fixed. Also, add a test that triggers this issue. Signed-off-by: NFelipe Contreras <felipe.contreras@gmail.com> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
git://github.com/git-l10n/git-po由 Junio C Hamano 提交于
* git://github.com/git-l10n/git-po: l10n: zh_CN.po: translate 44 messages (2080t0f0u) l10n: de.po: translate 44 new messages l10n: Update Vietnamese translation (2080t0f0u) l10n: Update Swedish translation (2080t0f0u) l10n: git.pot: v1.8.3 round 2 (44 new, 12 removed)
-
由 Jiang Xin 提交于
Translate 44 new messages came from git.pot update in c6bc7d43 (l10n: git.pot: v1.8.3 round 2 (44 new, 12 removed)) Signed-off-by: NJiang Xin <worldhello.net@gmail.com>
-
由 Ralf Thielow 提交于
Translate 44 new messages came from git.pot update in c6bc7d43 (l10n: git.pot: v1.8.3 round 2 (44 new, 12 removed)). Signed-off-by: NRalf Thielow <ralf.thielow@gmail.com> Acked-by: NThomas Rast <trast@inf.ethz.ch>
-
- 07 5月, 2013 5 次提交
-
-
由 Junio C Hamano 提交于
* jk/merge-tree-added-identically: merge-tree: handle directory/empty conflict correctly
-
由 John Keeping 提交于
git-merge-tree causes a null pointer dereference when a directory entry exists in only one or two of the three trees being compared with no corresponding entry in the other tree(s). When this happens, we want to handle the entry as a directory and not attempt to mark it as a file merge. Do this by setting the entries bit in the directory mask when the entry is missing or when it is a directory, only performing the file comparison when we know that a file entry exists. Reported-by: NAndreas Jacobsen <andreas@andreasjacobsen.com> Signed-off-by: NJohn Keeping <john@keeping.me.uk> Tested-by: NAndreas Jacobsen <andreas@andreasjacobsen.com> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
由 Junio C Hamano 提交于
* fc/remote-bzr: remote-bzr: avoid bad refs remote-bzr: convert all unicode keys to str remote-bzr: access branches only when needed remote-bzr: delay peer branch usage remote-bzr: iterate revisions properly remote-bzr: improve progress reporting remote-bzr: add option to specify branches remote-bzr: add custom method to find branches remote-bzr: improve author sanitazion remote-bzr: add support for shared repo remote-bzr: fix branch names remote-bzr: add support for bzr repos remote-bzr: use branch variable when appropriate remote-bzr: fix partially pushed merge remote-bzr: fixes for branch diverge remote-bzr: add support to push merges remote-bzr: always try to update the worktree remote-bzr: fix order of locking in CustomTree remote-bzr: delay blob fetching until the very end remote-bzr: cleanup CustomTree
-
由 Felipe Contreras 提交于
Versions of fast-export before v1.8.2 throws a bad 'reset' commands because of a behavior in transport-helper that is not even needed. We should ignore them, otherwise we will treat them as branches and fail. This was fixed in v1.8.2, but some people use this script in older versions of git. Also, check if the ref was a tag, and skip it for now. Signed-off-by: NFelipe Contreras <felipe.contreras@gmail.com> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
由 Felipe Contreras 提交于
Otherwise some versions of bazaar might barf. Signed-off-by: NFelipe Contreras <felipe.contreras@gmail.com> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
- 06 5月, 2013 2 次提交
-
-
由 Junio C Hamano 提交于
* fc/push-with-export-reporting-result: transport-helper: improve push messages
-
由 Felipe Contreras 提交于
If there's already a remote-helper tracking ref, we can fetch the SHA-1 to report proper push messages (as opposed to always reporting [new branch]). The remote-helper currently can specify the old SHA-1 to avoid this problem, but there's no point in forcing all remote-helpers to be aware of git commit ids; they should be able to be agnostic of them. Signed-off-by: NFelipe Contreras <felipe.contreras@gmail.com> Reviewed-by: NJeff King <peff@peff.net> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
- 04 5月, 2013 1 次提交
-
-
由 Junio C Hamano 提交于
Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-