[PATCH 06/16] remote-hg: add support for tag objects
Signed-off-by: Felipe Contreras felipe.contre...@gmail.com
---
contrib/remote-helpers/git-remote-hg | 10 +++---
1 file changed, 7 insertions(+), 3 deletions(-)
diff --git a/contrib/remote-helpers/git-remote-hg
b/contrib/remote-helpers/git-remote-hg
index bd93f82..4a1c637 100755
--- a/contrib/remote-helpers/git-remote-hg
+++ b/contrib/remote-helpers/git-remote-hg
@@ -722,7 +722,7 @@ def parse_tag(parser):
data = parser.get_data()
parser.next()
-# nothing to do
+parsed_tags[name] = (tagger, data)
def do_export(parser):
global parsed_refs, bmarks, peer
@@ -758,9 +758,11 @@ def do_export(parser):
continue
elif ref.startswith('refs/tags/'):
tag = ref[len('refs/tags/'):]
+author, msg = parsed_tags.get(tag, (None, None))
if mode == 'git':
-msg = 'Added tag %s for changeset %s' % (tag, hghex(node[:6]));
-parser.repo.tag([tag], node, msg, False, None, {})
+if not msg:
+msg = 'Added tag %s for changeset %s' % (tag,
hghex(node[:6]));
+parser.repo.tag([tag], node, msg, False, author[0], {})
else:
parser.repo.tag([tag], node, None, True, None, {})
print ok %s % ref
@@ -815,6 +817,7 @@ def main(args):
global marks, blob_marks, parsed_refs
global peer, mode, bad_mail, bad_name
global track_branches, force_push, is_tmp
+global parsed_tags
alias = args[1]
url = args[2]
@@ -857,6 +860,7 @@ def main(args):
blob_marks = {}
parsed_refs = {}
marks = None
+parsed_tags = {}
repo = get_repo(url, alias)
prefix = 'refs/hg/%s' % alias
--
1.8.2.1.790.g4588561
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 07/16] remote-hg: custom method to write tags
The one from mercurial is meant for users, on top of the latest tip.
Signed-off-by: Felipe Contreras felipe.contre...@gmail.com
---
contrib/remote-helpers/git-remote-hg | 33 -
1 file changed, 32 insertions(+), 1 deletion(-)
diff --git a/contrib/remote-helpers/git-remote-hg
b/contrib/remote-helpers/git-remote-hg
index 4a1c637..f5e4ba7 100755
--- a/contrib/remote-helpers/git-remote-hg
+++ b/contrib/remote-helpers/git-remote-hg
@@ -724,6 +724,37 @@ def parse_tag(parser):
parsed_tags[name] = (tagger, data)
+def write_tag(repo, tag, node, msg, author):
+tip = repo['tip']
+
+def getfilectx(repo, memctx, f):
+try:
+fctx = tip.filectx(f)
+data = fctx.data()
+except error.ManifestLookupError:
+data =
+content = data + %s %s\n % (hghex(node), tag)
+return context.memfilectx(f, content, False, False, None)
+
+p1 = tip.hex()
+p2 = '\0' * 20
+if not author:
+author = (None, 0, 0)
+user, date, tz = author
+
+ctx = context.memctx(repo, (p1, p2), msg,
+['.hgtags'], getfilectx,
+user, (date, tz), {})
+
+tmp = encoding.encoding
+encoding.encoding = 'utf-8'
+
+tagnode = repo.commitctx(ctx)
+
+encoding.encoding = tmp
+
+return tagnode
+
def do_export(parser):
global parsed_refs, bmarks, peer
@@ -762,7 +793,7 @@ def do_export(parser):
if mode == 'git':
if not msg:
msg = 'Added tag %s for changeset %s' % (tag,
hghex(node[:6]));
-parser.repo.tag([tag], node, msg, False, author[0], {})
+write_tag(parser.repo, tag, node, msg, author)
else:
parser.repo.tag([tag], node, None, True, None, {})
print ok %s % ref
--
1.8.2.1.790.g4588561
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 08/16] remote-hg: write tags in the appropriate branch
Signed-off-by: Felipe Contreras felipe.contre...@gmail.com
---
contrib/remote-helpers/git-remote-hg | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/contrib/remote-helpers/git-remote-hg
b/contrib/remote-helpers/git-remote-hg
index f5e4ba7..f685990 100755
--- a/contrib/remote-helpers/git-remote-hg
+++ b/contrib/remote-helpers/git-remote-hg
@@ -725,7 +725,9 @@ def parse_tag(parser):
parsed_tags[name] = (tagger, data)
def write_tag(repo, tag, node, msg, author):
-tip = repo['tip']
+branch = repo[node].branch()
+tip = branch_tip(repo, branch)
+tip = repo[tip]
def getfilectx(repo, memctx, f):
try:
@@ -744,7 +746,7 @@ def write_tag(repo, tag, node, msg, author):
ctx = context.memctx(repo, (p1, p2), msg,
['.hgtags'], getfilectx,
-user, (date, tz), {})
+user, (date, tz), {'branch' : branch})
tmp = encoding.encoding
encoding.encoding = 'utf-8'
--
1.8.2.1.790.g4588561
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 09/16] remote-hg: add custom local tag write code
There's no point in calling the tag method for such simple action. Not
that we care much about the hg-git compat mode, it's mostly just for
comparison testing purposes.
Signed-off-by: Felipe Contreras felipe.contre...@gmail.com
---
contrib/remote-helpers/git-remote-hg | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/contrib/remote-helpers/git-remote-hg
b/contrib/remote-helpers/git-remote-hg
index f685990..3c6eeb7 100755
--- a/contrib/remote-helpers/git-remote-hg
+++ b/contrib/remote-helpers/git-remote-hg
@@ -797,7 +797,9 @@ def do_export(parser):
msg = 'Added tag %s for changeset %s' % (tag,
hghex(node[:6]));
write_tag(parser.repo, tag, node, msg, author)
else:
-parser.repo.tag([tag], node, None, True, None, {})
+fp = parser.repo.opener('localtags', 'a')
+fp.write('%s %s\n' % (hghex(node), tag))
+fp.close()
print ok %s % ref
else:
# transport-helper/fast-export bugs
--
1.8.2.1.790.g4588561
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 10/16] remote-hg: improve email sanitation
Signed-off-by: Felipe Contreras felipe.contre...@gmail.com
---
contrib/remote-helpers/git-remote-hg | 10 --
contrib/remote-helpers/test-hg.sh| 8
2 files changed, 12 insertions(+), 6 deletions(-)
diff --git a/contrib/remote-helpers/git-remote-hg
b/contrib/remote-helpers/git-remote-hg
index 3c6eeb7..0084709 100755
--- a/contrib/remote-helpers/git-remote-hg
+++ b/contrib/remote-helpers/git-remote-hg
@@ -51,6 +51,7 @@ import urlparse
NAME_RE = re.compile('^([^]+)')
AUTHOR_RE = re.compile('^([^]+?)? ?([^]*)$')
+EMAIL_RE = re.compile('^([^]+[^ \\\t])?\\b(?:[ \\t]*?)\\b([^ \\t]+@[^
\\t]+)')
AUTHOR_HG_RE = re.compile('^(.*?) ?(.*?)(?:(.+)?)?$')
RAW_AUTHOR_RE = re.compile('^(\w+) (?:(.+)? )?(.*) (\d+) ([+-]\d+)')
@@ -245,9 +246,14 @@ def fixup_user_git(user):
name = m.group(1)
mail = m.group(2).strip()
else:
-m = NAME_RE.match(user)
+m = EMAIL_RE.match(user)
if m:
-name = m.group(1).strip()
+name = m.group(1)
+mail = m.group(2)
+else:
+m = NAME_RE.match(user)
+if m:
+name = m.group(1).strip()
return (name, mail)
def fixup_user_hg(user):
diff --git a/contrib/remote-helpers/test-hg.sh
b/contrib/remote-helpers/test-hg.sh
index d5b8730..8de2aa7 100755
--- a/contrib/remote-helpers/test-hg.sh
+++ b/contrib/remote-helpers/test-hg.sh
@@ -137,15 +137,15 @@ test_expect_success 'authors' '
author_test alpha H G Wells we...@example.com
author_test beta test test unknown
- author_test beta test t...@example.com (comment) test unknown
+ author_test beta test t...@example.com (comment) test
t...@example.com
author_test gamma t...@example.com Unknown t...@example.com
author_test delta namet...@example.com name t...@example.com
- author_test epsilon name t...@example.com name unknown
+ author_test epsilon name t...@example.com name t...@example.com
author_test zeta test test unknown
author_test eta test t...@example.com test t...@example.com
- author_test theta test t...@example.com test unknown
+ author_test theta test t...@example.com test t...@example.com
author_test iota test test at example dot com test unknown
- author_test kappa t...@example.com t...@example.com unknown
+ author_test kappa t...@example.com Unknown t...@example.com
)
git clone hg::$PWD/hgrepo gitrepo
--
1.8.2.1.790.g4588561
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 11/16] remote-hg: add support for schemes extension
So that we can use shortened URLs, for example 'bb:://felipec/repo' (Bitbucket). Signed-off-by: Felipe Contreras felipe.contre...@gmail.com --- contrib/remote-helpers/git-remote-hg | 8 +++- 1 file changed, 7 insertions(+), 1 deletion(-) diff --git a/contrib/remote-helpers/git-remote-hg b/contrib/remote-helpers/git-remote-hg index 0084709..4f6c7b7 100755 --- a/contrib/remote-helpers/git-remote-hg +++ b/contrib/remote-helpers/git-remote-hg @@ -12,7 +12,7 @@ # For remote repositories a local clone is stored in # $GIT_DIR/hg/origin/clone/.hg/. -from mercurial import hg, ui, bookmarks, context, util, encoding, node, error +from mercurial import hg, ui, bookmarks, context, util, encoding, node, error, extensions import re import sys @@ -305,6 +305,12 @@ def get_repo(url, alias): except subprocess.CalledProcessError: pass +try: +mod = extensions.load(myui, 'hgext.schemes', None) +mod.extsetup(myui) +except ImportError: +pass + if hg.islocal(url): repo = hg.repository(myui, url) else: -- 1.8.2.1.790.g4588561 -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] t4202 (log): add failing test for log with subtree
Matthieu Moy matthieu@grenoble-inp.fr writes: Thomas Rast tr...@inf.ethz.ch writes: So how can we fix that? We could try to somehow figure out that M:sub/ refers to the same thing as M^2:/, by looking at them at the tree level. Let's provisionally call this --follow-tree-rename. There was a patch serie long ago that implemented directory rename detection: http://thread.gmane.org/gmane.comp.version-control.git/163328 I'm not sure why it hasn't been merged. I have forgotten about this topic (and its numerous iterations in the past), but it appears me that people mostly lost interest after v7 review cycle where the series looked like a solution that is looking for a problem. I took another quick look at it now, but it tells me that the series was a good platform to discuss the design and the goals but it was far from ready with comments like this // FIXME: leaks like sieve. As to the design (not the implementation), I find what are in the documentation updates in [v9 2/6] more or less reasonable, even though I still doubt that foo/ = bar/, when the constituent files are not moved a la mv foo/* bar/. is useful. The change in [v9 3/6] is distasteful and should just be killed. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 12/16] remote-hg: don't update bookmarks unnecessarily
Signed-off-by: Felipe Contreras felipe.contre...@gmail.com --- contrib/remote-helpers/git-remote-hg | 3 +++ 1 file changed, 3 insertions(+) diff --git a/contrib/remote-helpers/git-remote-hg b/contrib/remote-helpers/git-remote-hg index 4f6c7b7..dbb4091 100755 --- a/contrib/remote-helpers/git-remote-hg +++ b/contrib/remote-helpers/git-remote-hg @@ -830,6 +830,9 @@ def do_export(parser): else: old = '' +if old == new: +continue + if bmark == 'master' and 'master' not in parser.repo._bookmarks: # fake bookmark pass -- 1.8.2.1.790.g4588561 -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 13/16] remote-hg: allow refs with spaces
Mercurial supports them, Git doesn't.
Signed-off-by: Felipe Contreras felipe.contre...@gmail.com
---
contrib/remote-helpers/git-remote-hg | 25 +
1 file changed, 17 insertions(+), 8 deletions(-)
diff --git a/contrib/remote-helpers/git-remote-hg
b/contrib/remote-helpers/git-remote-hg
index dbb4091..6f4afd7 100755
--- a/contrib/remote-helpers/git-remote-hg
+++ b/contrib/remote-helpers/git-remote-hg
@@ -75,6 +75,12 @@ def hgmode(mode):
def hghex(node):
return hg.node.hex(node)
+def hgref(ref):
+return ref.replace('___', ' ')
+
+def gitref(ref):
+return ref.replace(' ', '___')
+
def get_config(config):
cmd = ['git', 'config', '--get', config]
process = subprocess.Popen(cmd, stdout=subprocess.PIPE)
@@ -437,10 +443,10 @@ def export_ref(repo, name, kind, head):
marks.set_tip(ename, rev)
def export_tag(repo, tag):
-export_ref(repo, tag, 'tags', repo[tag])
+export_ref(repo, tag, 'tags', repo[hgref(tag)])
def export_bookmark(repo, bmark):
-head = bmarks[bmark]
+head = bmarks[hgref(bmark)]
export_ref(repo, bmark, 'bookmarks', head)
def export_branch(repo, branch):
@@ -479,14 +485,14 @@ def branch_tip(repo, branch):
def get_branch_tip(repo, branch):
global branches
-heads = branches.get(branch, None)
+heads = branches.get(hgref(branch), None)
if not heads:
return None
# verify there's only one head
if (len(heads) 1):
warn(Branch '%s' has more than one head, consider merging % branch)
-return branch_tip(repo, branch)
+return branch_tip(repo, hgref(branch))
return heads[0]
@@ -508,6 +514,7 @@ def list_head(repo, cur):
head = 'master'
bmarks[head] = node
+head = gitref(head)
print @refs/heads/%s HEAD % head
g_head = (head, node)
@@ -529,15 +536,15 @@ def do_list(parser):
branches[branch] = heads
for branch in branches:
-print ? refs/heads/branches/%s % branch
+print ? refs/heads/branches/%s % gitref(branch)
for bmark in bmarks:
-print ? refs/heads/%s % bmark
+print ? refs/heads/%s % gitref(bmark)
for tag, node in repo.tagslist():
if tag == 'tip':
continue
-print ? refs/tags/%s % tag
+print ? refs/tags/%s % gitref(tag)
print
@@ -674,7 +681,8 @@ def parse_commit(parser):
# Check if the ref is supposed to be a named branch
if ref.startswith('refs/heads/branches/'):
-extra['branch'] = ref[len('refs/heads/branches/'):]
+branch = ref[len('refs/heads/branches/'):]
+extra['branch'] = hgref(branch)
if mode == 'hg':
i = data.find('\n--HG--\n')
@@ -803,6 +811,7 @@ def do_export(parser):
continue
elif ref.startswith('refs/tags/'):
tag = ref[len('refs/tags/'):]
+tag = hgref(tag)
author, msg = parsed_tags.get(tag, (None, None))
if mode == 'git':
if not msg:
--
1.8.2.1.790.g4588561
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 14/16] remote-hg: small performance improvement
Load previous manifest first as Mercurial does; for caching reasons. Signed-off-by: Felipe Contreras felipe.contre...@gmail.com --- contrib/remote-helpers/git-remote-hg | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/contrib/remote-helpers/git-remote-hg b/contrib/remote-helpers/git-remote-hg index 6f4afd7..f80236b 100755 --- a/contrib/remote-helpers/git-remote-hg +++ b/contrib/remote-helpers/git-remote-hg @@ -230,8 +230,9 @@ def get_filechanges(repo, ctx, parent): added = set() removed = set() -cur = ctx.manifest() +# load earliest manifest first for caching reasons prev = repo[parent].manifest().copy() +cur = ctx.manifest() for fn in cur: if fn in prev: -- 1.8.2.1.790.g4588561 -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 15/16] remote-hg: use marks instead of inlined files
So that we can find already exported ones. We can never be 100% sure
that we already exported such data, due to mercurial design, it at least
sometimes we should detect them, and so should give ups some performance
boost.
Signed-off-by: Felipe Contreras felipe.contre...@gmail.com
---
contrib/remote-helpers/git-remote-hg | 41 +---
1 file changed, 33 insertions(+), 8 deletions(-)
diff --git a/contrib/remote-helpers/git-remote-hg
b/contrib/remote-helpers/git-remote-hg
index f80236b..d0e552c 100755
--- a/contrib/remote-helpers/git-remote-hg
+++ b/contrib/remote-helpers/git-remote-hg
@@ -126,6 +126,10 @@ class Marks:
def to_rev(self, mark):
return self.rev_marks[mark]
+def next_mark(self):
+self.last_mark += 1
+return self.last_mark
+
def get_mark(self, rev):
self.last_mark += 1
self.marks[str(rev)] = self.last_mark
@@ -218,12 +222,29 @@ def fix_file_path(path):
return path
return os.path.relpath(path, '/')
-def export_file(fc):
-d = fc.data()
-path = fix_file_path(fc.path())
-print M %s inline %s % (gitmode(fc.flags()), path)
-print data %d % len(d)
-print d
+def export_files(files):
+global marks, filenodes
+
+final = []
+for f in files:
+fid = node.hex(f.filenode())
+
+if fid in filenodes:
+mark = filenodes[fid]
+else:
+mark = marks.next_mark()
+filenodes[fid] = mark
+d = f.data()
+
+print blob
+print mark :%u % mark
+print data %d % len(d)
+print d
+
+path = fix_file_path(f.path())
+final.append((gitmode(f.flags()), mark, path))
+
+return final
def get_filechanges(repo, ctx, parent):
modified = set()
@@ -413,6 +434,8 @@ def export_ref(repo, name, kind, head):
if len(parents) == 0 and rev:
print 'reset %s/%s' % (prefix, ename)
+modified_final = export_files(c.filectx(f) for f in modified)
+
print commit %s/%s % (prefix, ename)
print mark :%d % (marks.get_mark(rev))
print author %s % (author)
@@ -425,8 +448,8 @@ def export_ref(repo, name, kind, head):
if len(parents) 1:
print merge :%s % (rev_to_mark(parents[1]))
-for f in modified:
-export_file(c.filectx(f))
+for f in modified_final:
+print M %s :%u %s % f
for f in removed:
print D %s % (fix_file_path(f))
print
@@ -878,6 +901,7 @@ def main(args):
global peer, mode, bad_mail, bad_name
global track_branches, force_push, is_tmp
global parsed_tags
+global filenodes
alias = args[1]
url = args[2]
@@ -921,6 +945,7 @@ def main(args):
parsed_refs = {}
marks = None
parsed_tags = {}
+filenodes = {}
repo = get_repo(url, alias)
prefix = 'refs/hg/%s' % alias
--
1.8.2.1.790.g4588561
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 16/16] remote-hg: strip extra newline
There's no functional change since mercurial commit operation strips
that anyway, but that's no excuse for us not to do the right thing. So
let's be explicit about it.
Signed-off-by: Felipe Contreras felipe.contre...@gmail.com
---
contrib/remote-helpers/git-remote-hg | 4
1 file changed, 4 insertions(+)
diff --git a/contrib/remote-helpers/git-remote-hg
b/contrib/remote-helpers/git-remote-hg
index d0e552c..fda4199 100755
--- a/contrib/remote-helpers/git-remote-hg
+++ b/contrib/remote-helpers/git-remote-hg
@@ -652,6 +652,10 @@ def parse_commit(parser):
if parser.check('merge'):
die('octopus merges are not supported yet')
+# fast-export adds an extra newline
+if data[-1] == '\n':
+data = data[:-1]
+
files = {}
for line in parser:
--
1.8.2.1.790.g4588561
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] zlib: fix compilation failures with Sun C Compilaer
On 04/22/2013 11:41 PM, Eric Sunshine wrote: On Mon, Apr 22, 2013 at 12:18 PM, Stefano Lattarini stefano.lattar...@gmail.com wrote: zlib: fix compilation failures with Sun C Compilaer s/Compilaer/compiler/ Oops, well spotted. Junio, can you fix this locally? Thanks, and sorry for the stupid typo, Stefano -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] bisect: Store first bad commit as comment in log file
On Mon, Apr 22, 2013 at 14:13:00 -0700, Junio C Hamano wrote: Torstein Hegge he...@resisty.net writes: I took another look at this. I wasn't able to come up with anything useful for the The merge base $rev is bad case, but for the only skipped commits left to test case one could do something like this. We skipped them because we can gain _no_ information from testing these commits. They are not even possibly bad, but are unknown. So it feels to me that by definition listing them would not be useful. What am I missing? The information lies in that those commits are the only commits with an unknown state. So if the bisecter hands off the bisect log to someone else when they can't test further, the current status is recorded. I think part of the reason I started looking at this is that there are no good way to see what git said after the previous 'git bisect good/bad' if the terminal output is lost. And lost terminal output is fairly likely if you are bisecting something that requires reboots for each test. But I don't feel very strongly about this. It was based on Christian's idea, so unless he comes up with some compelling arguments I'll drop it. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 17/33] repack_without_ref(): silence errors for dangling packed refs
Michael Haggerty mhag...@alum.mit.edu writes:
Stop emitting an error message when deleting a packed reference if we
find another dangling packed reference that is overridden by a loose
reference. See the previous commit for a longer explanation of the
issue.
We have to be careful to make sure that the invalid packed reference
really *is* overridden by a loose reference; otherwise what we have
found is repository corruption, which we *should* report.
Please note that this approach is vulnerable to a race condition
similar to the race conditions already known to affect packed
references [1]:
* Process 1 tries to peel packed reference X as part of deleting
another packed reference. It discovers that X does not refer to a
valid object (because the object that it referred to has been
garbage collected).
* Process 2 tries to delete reference X. It starts by deleting the
loose reference X.
* Process 1 checks whether there is a loose reference X. There is not
(it has just been deleted by process 2), so process 1 reports a
spurious error X does not point to a valid object!
The worst case seems relatively harmless, and the fix is identical to
the fix that will be needed for the other race conditions (namely
holding a lock on the packed-refs file during *all* reference
deletions), so we leave the cleaning up of all of them as a future
project.
[1] http://thread.gmane.org/gmane.comp.version-control.git/211956
Signed-off-by: Michael Haggerty mhag...@alum.mit.edu
---
Clean and straight-forward implementation that is very well
explained. I like this much better than the previous round ;-).
Thanks, will re-queue.
refs.c | 37 +++--
t/t3210-pack-refs.sh | 2 +-
2 files changed, 36 insertions(+), 3 deletions(-)
diff --git a/refs.c b/refs.c
index ed54ed4..2957f6d 100644
--- a/refs.c
+++ b/refs.c
@@ -1901,8 +1901,41 @@ static int repack_without_ref_fn(struct ref_entry
*entry, void *cb_data)
if (!strcmp(data-refname, entry-name))
return 0;
- if (!ref_resolves_to_object(entry))
- return 0; /* Skip broken refs */
+ if (entry-flag REF_ISBROKEN) {
+ /* This shouldn't happen to packed refs. */
+ error(%s is broken!, entry-name);
+ return 0;
+ }
+ if (!has_sha1_file(entry-u.value.sha1)) {
+ unsigned char sha1[20];
+ int flags;
+
+ if (read_ref_full(entry-name, sha1, 0, flags))
+ /* We should at least have found the packed ref. */
+ die(Internal error);
+ if ((flags REF_ISSYMREF) || !(flags REF_ISPACKED))
+ /*
+ * This packed reference is overridden by a
+ * loose reference, so it is OK that its value
+ * is no longer valid; for example, it might
+ * refer to an object that has been garbage
+ * collected. For this purpose we don't even
+ * care whether the loose reference itself is
+ * invalid, broken, symbolic, etc. Silently
+ * omit the packed reference from the output.
+ */
+ return 0;
+ /*
+ * There is no overriding loose reference, so the fact
+ * that this reference doesn't refer to a valid object
+ * indicates some kind of repository corruption.
+ * Report the problem, then omit the reference from
+ * the output.
+ */
+ error(%s does not point to a valid object!, entry-name);
+ return 0;
+ }
+
len = snprintf(line, sizeof(line), %s %s\n,
sha1_to_hex(entry-u.value.sha1), entry-name);
/* this should not happen but just being defensive */
diff --git a/t/t3210-pack-refs.sh b/t/t3210-pack-refs.sh
index c032d88..559f602 100755
--- a/t/t3210-pack-refs.sh
+++ b/t/t3210-pack-refs.sh
@@ -142,7 +142,7 @@ test_expect_success 'delete ref with dangling packed
version' '
test_cmp /dev/null result
'
-test_expect_failure 'delete ref while another dangling packed ref' '
+test_expect_success 'delete ref while another dangling packed ref' '
git branch lamb
git commit --allow-empty -m future garbage
git pack-refs --all
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 00/33] Various cleanups around reference packing and peeling
Michael Haggerty mhag...@alum.mit.edu writes: For now I left the sleeps in t3210. Given that the problem will be solved by topic jc/prune-all, building a fancier workaround into this test for the old broken --expire behavior seems like a waste of time. I propose that the sleeps be removed when this patch series is merged with jc/prune-all. I wouldn't mind to queue this on top of the prune --expire=all topic at all, especially if that makes the tests easier. Overall looks very cleanly done (I only let my eyes coast over them, and need another round to read it over). Thanks. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 01/16] remote-helpers: avoid has_key
Felipe Contreras felipe.contre...@gmail.com writes: From: Dusty Phillips du...@linux.ca It is deprecated. [fc: do the same in remote-bzr] Signed-off-by: Felipe Contreras felipe.contre...@gmail.com --- No sign-off by the author? It does not matter for something so trivial like this that there is no other way to write, but it is a good habit you should encourage your contributors to acquire, so that you do not have to waste time with please sign off when their next contribution that is more substantial comes. contrib/remote-helpers/git-remote-bzr | 2 +- contrib/remote-helpers/git-remote-hg | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/contrib/remote-helpers/git-remote-bzr b/contrib/remote-helpers/git-remote-bzr index aa7bc97..cc6609b 100755 --- a/contrib/remote-helpers/git-remote-bzr +++ b/contrib/remote-helpers/git-remote-bzr @@ -94,7 +94,7 @@ class Marks: return self.last_mark def is_marked(self, rev): -return self.marks.has_key(rev) +return str(rev) in self.marks def new_mark(self, rev, mark): self.marks[rev] = mark diff --git a/contrib/remote-helpers/git-remote-hg b/contrib/remote-helpers/git-remote-hg index 5481331..2cd1996 100755 --- a/contrib/remote-helpers/git-remote-hg +++ b/contrib/remote-helpers/git-remote-hg @@ -129,7 +129,7 @@ class Marks: self.last_mark = mark def is_marked(self, rev): -return self.marks.has_key(str(rev)) +return str(rev) in self.marks def get_tip(self, branch): return self.tips.get(branch, 0) -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 15/16] remote-hg: use marks instead of inlined files
Felipe Contreras felipe.contre...@gmail.com writes:
So that we can find already exported ones. We can never be 100% sure
that we already exported such data, due to mercurial design, it at least
sometimes we should detect them, and so should give ups some performance
s/ups/us/ (will locally tweak).
boost.
Signed-off-by: Felipe Contreras felipe.contre...@gmail.com
---
contrib/remote-helpers/git-remote-hg | 41
+---
1 file changed, 33 insertions(+), 8 deletions(-)
diff --git a/contrib/remote-helpers/git-remote-hg
b/contrib/remote-helpers/git-remote-hg
index f80236b..d0e552c 100755
--- a/contrib/remote-helpers/git-remote-hg
+++ b/contrib/remote-helpers/git-remote-hg
@@ -126,6 +126,10 @@ class Marks:
def to_rev(self, mark):
return self.rev_marks[mark]
+def next_mark(self):
+self.last_mark += 1
+return self.last_mark
+
def get_mark(self, rev):
self.last_mark += 1
self.marks[str(rev)] = self.last_mark
@@ -218,12 +222,29 @@ def fix_file_path(path):
return path
return os.path.relpath(path, '/')
-def export_file(fc):
-d = fc.data()
-path = fix_file_path(fc.path())
-print M %s inline %s % (gitmode(fc.flags()), path)
-print data %d % len(d)
-print d
+def export_files(files):
+global marks, filenodes
+
+final = []
+for f in files:
+fid = node.hex(f.filenode())
+
+if fid in filenodes:
+mark = filenodes[fid]
+else:
+mark = marks.next_mark()
+filenodes[fid] = mark
+d = f.data()
+
+print blob
+print mark :%u % mark
+print data %d % len(d)
+print d
+
+path = fix_file_path(f.path())
+final.append((gitmode(f.flags()), mark, path))
+
+return final
def get_filechanges(repo, ctx, parent):
modified = set()
@@ -413,6 +434,8 @@ def export_ref(repo, name, kind, head):
if len(parents) == 0 and rev:
print 'reset %s/%s' % (prefix, ename)
+modified_final = export_files(c.filectx(f) for f in modified)
+
print commit %s/%s % (prefix, ename)
print mark :%d % (marks.get_mark(rev))
print author %s % (author)
@@ -425,8 +448,8 @@ def export_ref(repo, name, kind, head):
if len(parents) 1:
print merge :%s % (rev_to_mark(parents[1]))
-for f in modified:
-export_file(c.filectx(f))
+for f in modified_final:
+print M %s :%u %s % f
for f in removed:
print D %s % (fix_file_path(f))
print
@@ -878,6 +901,7 @@ def main(args):
global peer, mode, bad_mail, bad_name
global track_branches, force_push, is_tmp
global parsed_tags
+global filenodes
alias = args[1]
url = args[2]
@@ -921,6 +945,7 @@ def main(args):
parsed_refs = {}
marks = None
parsed_tags = {}
+filenodes = {}
repo = get_repo(url, alias)
prefix = 'refs/hg/%s' % alias
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 01/16] remote-helpers: avoid has_key
On Mon, Apr 22, 2013 at 5:28 PM, Junio C Hamano gits...@pobox.com wrote: Felipe Contreras felipe.contre...@gmail.com writes: From: Dusty Phillips du...@linux.ca It is deprecated. [fc: do the same in remote-bzr] Signed-off-by: Felipe Contreras felipe.contre...@gmail.com --- No sign-off by the author? It does not matter for something so trivial like this that there is no other way to write, but it is a good habit you should encourage your contributors to acquire, so that you do not have to waste time with please sign off when their next contribution that is more substantial comes. He is not a contributor, he sent a few patches, and then immediately started gitifyhg, I haven't heard a word from him. Still, he was the original author, so... -- Felipe Contreras -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] bisect: Store first bad commit as comment in log file
Torstein Hegge he...@resisty.net writes: On Mon, Apr 22, 2013 at 14:13:00 -0700, Junio C Hamano wrote: Torstein Hegge he...@resisty.net writes: I took another look at this. I wasn't able to come up with anything useful for the The merge base $rev is bad case, but for the only skipped commits left to test case one could do something like this. We skipped them because we can gain _no_ information from testing these commits. They are not even possibly bad, but are unknown. So it feels to me that by definition listing them would not be useful. What am I missing? The information lies in that those commits are the only commits with an unknown state. So if the bisecter hands off the bisect log to someone else when they can't test further, the current status is recorded. That is an interesting use case: I've narrowed it down somewhat, but there are a few commits I do not have proper hardware for to test them, could you take it over from here? -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 13/16] remote-hg: allow refs with spaces
On Mon, Apr 22, 2013 at 5:32 PM, Junio C Hamano gits...@pobox.com wrote: Felipe Contreras felipe.contre...@gmail.com writes: Mercurial supports them, Git doesn't. Another important thing to note is that you represent a SP with three underscores on our side, no? Probably, I don't think it's really important. Perhaps some users would benefit from this information, but they would be better served by a README, or a wiki, the commit message doesn't help them. -- Felipe Contreras -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 3/2] git add pathspec... defaults to -A
Make git add pathspec... notice paths that have been removed
from the working tree, i.e. a synonym to git add -A pathspec
Given that git add pathspec is to update the index with the
state of the named part of the working tree as a whole, it makes it
more intuitive, and also makes it possible to simplify the advice we
give while marking the paths the user finished resolving conflicts
with. We used to say to record removal as a resolution, remove the
path from the working tree and say 'git rm'; for all other cases,
edit the path in the working tree and say 'git add', but we can now
say update the path in the working tree and say 'git add' instead.
As promised, this merges the temporary update_files_in_cache() helper
function back to add_files_to_cache() function.
Signed-off-by: Junio C Hamano gits...@pobox.com
---
* This comes on top of the previous two meant for 1.8.3, but should
wait until Git 2.0. You can see that it still has conflicts with
Jonathan's jn/add-2.0-u-A-sans-pathspec topic, but there is a
resolution already prepared on 'pu'.
Documentation/git-add.txt | 18 +++---
builtin/add.c | 43 ---
2 files changed, 15 insertions(+), 46 deletions(-)
diff --git a/Documentation/git-add.txt b/Documentation/git-add.txt
index 48754cb..77ad391 100644
--- a/Documentation/git-add.txt
+++ b/Documentation/git-add.txt
@@ -53,8 +53,14 @@ OPTIONS
Files to add content from. Fileglobs (e.g. `*.c`) can
be given to add all matching files. Also a
leading directory name (e.g. `dir` to add `dir/file1`
- and `dir/file2`) can be given to add all files in the
- directory, recursively.
+ and `dir/file2`) can be given to update the index to
+ match the current state of the directory as a whole (e.g.
+ specifying `dir` will record not just a file `dir/file1`
+ modified in the working tree, a file `dir/file2` added to
+ the working tree, but also a file `dir/file3` removed from
+ the working tree. Note that older versions of Git used
+ to ignore removed files; use `--no-all` option if you want
+ to add modified or new files but ignore removed ones.
-n::
--dry-run::
@@ -129,11 +135,9 @@ of Git, hence the form without pathspec should not be
used.
files that have been removed from the working tree. This
option is a no-op when no pathspec is used.
+
-This option is primarily to help the current users of Git, whose
-git add pathspec... ignores removed files. In future versions
-of Git, git add pathspec... will be a synonym to git add -A
-pathspec... and git add --ignore-removal pathspec... will behave like
-today's git add pathspec..., ignoring removed files.
+This option is primarily to help users who are used to older
+versions of Git, whose git add pathspec... was a synonym
+to git add --no-all pathspec..., i.e. ignored removed files.
-N::
--intent-to-add::
diff --git a/builtin/add.c b/builtin/add.c
index c55615b..22c5ff5 100644
--- a/builtin/add.c
+++ b/builtin/add.c
@@ -28,9 +28,6 @@ struct update_callback_data {
int add_errors;
const char *implicit_dot;
size_t implicit_dot_len;
-
- /* only needed for 2.0 transition preparation */
- int warn_add_would_remove;
};
static const char *option_with_implicit_dot;
@@ -96,24 +93,6 @@ static int fix_unmerged_status(struct diff_filepair *p,
return DIFF_STATUS_MODIFIED;
}
-static const char *add_would_remove_warning = N_(
- You ran 'git add' with neither '-A (--all)' or '--ignore-removal',\n
-whose behaviour will change in Git 2.0 with respect to paths you removed.\n
-Paths like '%s' that are\n
-removed from your working tree are ignored with this version of Git.\n
-\n
-* 'git add --ignore-removal pathspec', which is the current default,\n
- ignores paths you removed from your working tree.\n
-\n
-* 'git add --all pathspec' will let you also record the removals.\n
-\n
-Run 'git status' to check the paths you removed from your working tree.\n);
-
-static void warn_add_would_remove(const char *path)
-{
- warning(_(add_would_remove_warning), path);
-}
-
static void update_callback(struct diff_queue_struct *q,
struct diff_options *opt, void *cbdata)
{
@@ -151,10 +130,6 @@ static void update_callback(struct diff_queue_struct *q,
}
break;
case DIFF_STATUS_DELETED:
- if (data-warn_add_would_remove) {
- warn_add_would_remove(path);
- data-warn_add_would_remove = 0;
- }
if (data-flags ADD_CACHE_IGNORE_REMOVAL)
break;
if (!(data-flags ADD_CACHE_PRETEND))
@@ -378,7 +353,7 @@ N_(The following paths are ignored by one of your
.gitignore files:\n);
static int
Re: [PATCH] t4202 (log): add failing test for log with subtree
Junio C Hamano wrote: I have forgotten about this topic (and its numerous iterations in the past), but it appears me that people mostly lost interest after v7 review cycle where the series looked like a solution that is looking for a problem. I agree. Over-generalizing the problem is going nowhere. I have some ideas in my head, but I think I'm at the brink of insanity again: We have a special type of merge commit that has 'bind' lines corresponding to the trees of the commits we just merged in: each line references a tree and a prefix. Then, a diff between the merge's tree and one of these trees can easily tell us what changes were introduced by each side. And here's the bomb: if we consider extending it to include a blob-like buffer, we can use it to store submodule-like information for each prefix. Everything would just work out of the box with a few minor adjustments: 1. We have to modify our packing algorithm to not reach out beyond ^1 of these special merge commits. This means object-store isolation (not $GITDIR isolation). And it means that submodules can be cloned and removed at will. 2. We have to maintain a symbolic ref for each prefix. A commit invoked from a special-commit referenced subdirectory will update this symref. Ofcourse, this means that we need to namespace our refs/ and refs/remotes sensibly. 3. Git commands will take into account $CWD very strongly, and just DTRT all the time. Whether you're looking from the submodule perspective or the superproject perspective. Am I making any sense? -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] t4202 (log): add failing test for log with subtree
Ramkumar Ramachandra wrote: [...] Oh, and I forgot the best part. True floating submodules when the bind line references a zeroed-out hex. Naturally, the diff'ing to figure out changes introduced by the submodule will be blocked. Also good for dropping in huge binary files at a particular path. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 13/16] remote-hg: allow refs with spaces
Felipe Contreras felipe.contre...@gmail.com writes: On Mon, Apr 22, 2013 at 5:32 PM, Junio C Hamano gits...@pobox.com wrote: Felipe Contreras felipe.contre...@gmail.com writes: Mercurial supports them, Git doesn't. Another important thing to note is that you represent a SP with three underscores on our side, no? Probably, I don't think it's really important. Perhaps some users would benefit from this information, but they would be better served by a README, or a wiki, the commit message doesn't help them. True, but it helps a reviewer to notice the missing documentation ;-) -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 01/16] remote-helpers: avoid has_key
On 04/22/2013 04:35 PM, Felipe Contreras wrote: On Mon, Apr 22, 2013 at 5:28 PM, Junio C Hamano gits...@pobox.com wrote: Felipe Contreras felipe.contre...@gmail.com writes: From: Dusty Phillips du...@linux.ca It is deprecated. [fc: do the same in remote-bzr] Signed-off-by: Felipe Contreras felipe.contre...@gmail.com --- No sign-off by the author? It does not matter for something so trivial like this that there is no other way to write, but it is a good habit you should encourage your contributors to acquire, so that you do not have to waste time with please sign off when their next contribution that is more substantial comes. He is not a contributor, he sent a few patches, and then immediately started gitifyhg, I haven't heard a word from him. Still, he was the original author, so... Acknowledged that I will not likely be contributing any more patches. I apologize for the lack of signoffs on the pull requests; I wasn't actually aware that they were going into git mainline already. I will state for the record that all patches I submitted to Felipe's github fork of git in November and December, 2012 were authored by me and only me and I submitted them with the understanding and expectation that they would be licensed under the GPL. Dusty -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] Add .gitconfig variable commit.gpg-sign
Joel Jacobson j...@trustly.com writes: Signed-off-by: Joel Jacobson j...@trustly.com --- builtin/commit.c | 4 +++- No docs? No tests? As to the design, any regular configuration variable settings must be overridable from the command line for a single invocation. Please design an escape hatch in, for somebody who has this configuration variable set, but does not want to sign this commit he is about to make. Also do we generally use dash in the configuration variable names? I thought the norm was section.CamelCase. + if (!strcmp(k, commit.gpg-sign)) + return git_config_string(sign_commit, k, v); if (!strcmp(k, commit.cleanup)) return git_config_string(cleanup_arg, k, v); -- --to=gits...@pobox.com -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] t4202 (log): add failing test for log with subtree
Ramkumar Ramachandra artag...@gmail.com writes: Am I making any sense? I dunno. Depends on the definition of sense. It sounds like you are repeating the same old let's record renames in the commit, and in a system (not Git) where recording renames may make sense, you may be making sense. But we will not record renames in the commit. Time to re-read $gmane/217, perhaps? A subtree merge that slurps everything from a side branch under a single directory, say gitk/, is not at all different from a normal merge with many renames. Imagine an alternate world where we had a small git.git project with 11 files totallying 1244 lines. Then Paul Mackerras forks that project, remove everything from the top-level directory and adds a Tck/Tk script gitk. Linus merges that history as-is, keeping all our files intact (i.e. ignoring his removal) but taking the addition of gitk from him. Then after I inherit the project, I rename gitk to gitk-git/git. Paul does not rename his. We keep developing in parallel and I occassionally merge from his tree, which has gitk at the top, while mine has it in a directory gitk-git. The ordinary rename detection kicks in and integrates his updates to gitk into my gitk-git/gitk. The only difference the above imaginary history has from the reality is Paul's history does not share that root, but everything else is the same. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] Add .gitconfig variable commit.gpg-sign
On Tue, Apr 23, 2013 at 12:43 AM, Junio C Hamano gits...@pobox.com wrote: No docs? No tests? Maybe simply adding this text to git-commit.txt, The default can be changed by the 'commit.gpg-sign' configuration variable (see linkgit:git-config[1]). after, -S[keyid]:: --gpg-sign[=keyid]:: GPG-sign commit. would be sufficient? Not sure what the proper way to test this, could you please suggest any other unit test I could look at for inspiration? As to the design, any regular configuration variable settings must be overridable from the command line for a single invocation. Please design an escape hatch in, for somebody who has this configuration variable set, but does not want to sign this commit he is about to make. Something like --no-gpg-sign? Also do we generally use dash in the configuration variable names? I thought the norm was section.CamelCase. Since the command line long option is gpg-sign, I thought it was best to use exactly the same term in the configuration variable name to avoid confusion. Is there any problem with dashes in variable names? -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 3/2] git add pathspec... defaults to -A
On Mon, Apr 22, 2013 at 6:41 PM, Junio C Hamano gits...@pobox.com wrote: diff --git a/Documentation/git-add.txt b/Documentation/git-add.txt index 48754cb..77ad391 100644 --- a/Documentation/git-add.txt +++ b/Documentation/git-add.txt @@ -53,8 +53,14 @@ OPTIONS Files to add content from. Fileglobs (e.g. `*.c`) can be given to add all matching files. Also a leading directory name (e.g. `dir` to add `dir/file1` - and `dir/file2`) can be given to add all files in the - directory, recursively. + and `dir/file2`) can be given to update the index to + match the current state of the directory as a whole (e.g. + specifying `dir` will record not just a file `dir/file1` + modified in the working tree, a file `dir/file2` added to + the working tree, but also a file `dir/file3` removed from + the working tree. Note that older versions of Git used s/of\s+Git/of Git/ + to ignore removed files; use `--no-all` option if you want + to add modified or new files but ignore removed ones. -n:: --dry-run:: @@ -129,11 +135,9 @@ of Git, hence the form without pathspec should not be used. files that have been removed from the working tree. This option is a no-op when no pathspec is used. + -This option is primarily to help the current users of Git, whose -git add pathspec... ignores removed files. In future versions -of Git, git add pathspec... will be a synonym to git add -A -pathspec... and git add --ignore-removal pathspec... will behave like -today's git add pathspec..., ignoring removed files. +This option is primarily to help users who are used to older +versions of Git, whose git add pathspec... was a synonym +to git add --no-all pathspec..., i.e. ignored removed files. s/to/for/ [or] s/to/of/ -N:: --intent-to-add:: -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
