Re: [BUG] two-way read-tree can write null sha1s into index
On Tue, Jan 01, 2013 at 02:24:46PM -0800, Junio C Hamano wrote: Jeff King p...@peff.net writes: So I think we need to update twoway_merge to recognize unmerged entries, which gives us two options: 1. Reject the merge. 2. Throw away the current unmerged entry in favor of the new entry (when old and new are the same, of course; otherwise we would reject). I think (2) is the right thing. As --reset in read-tree --reset -u A B is a way to say we know we are based on A and we want to go to B no matter what, I agree we should not reject the merge. With -m instead of --reset, I am not sure what the right semantics should be, though. Good point; I was just thinking about the --reset case. With -m, though, we could in theory carry over the unmerged entries (again, assuming that old and new are the same; otherwise it is an obvious reject). But those entries would be confused with any new unmerged entries we create. It seems we already protect against this, though: read-tree -m will not run at all if you have unmerged entries. Likewise, checkout seems to have similar protections. So I think it may be a non-issue. -Peff -- 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: git filter-branch doesn't dereference annotated tags
Am 03.01.2013 00:19, schrieb Junio C Hamano: Grégory Pakosz gpak...@visionobjects.com writes: So we have an annotated tag that points to a commit that is rewritten to nothing as the result of the filtering. What should happen? If the user asked to filter that tag itself, it may make sense to remove it, rather than keeping it pointing at the original commit, because the commit it used to point at no longer exists in the alternate history being created by filter-branch. IOW, if the command was something like git filter-branch ...filter options... -- v1.0 master ... and v1.0 is an annotated tag, then it is reasonable to expect v1.0 to be deleted if the commit it points to goes away. But if the commit did not go away, but was rewritten, then it is equally reasonable to expect that the tag is also rewritten. But I don't think that we currently do the latter. Therefore, IMO, a change that implements the former behavior should also implement the latter behavior. -- Hannes -- 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: git filter-branch doesn't dereference annotated tags
IOW, if the command was something like git filter-branch ...filter options... -- v1.0 master ... and v1.0 is an annotated tag, then it is reasonable to expect v1.0 to be deleted if the commit it points to goes away. But if the commit did not go away, but was rewritten, then it is equally reasonable to expect that the tag is also rewritten. But I don't think that we currently do the latter. When the commit doesn't go away, the tag is currently being rewritten properly. Therefore, IMO, a change that implements the former behavior should also implement the latter behavior. The patch in my latest email does both. (yet lacks unit tests for now) Gregory -- 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: [RFD] annnotating a pair of commit objects?
On 01/03/2013 08:03 AM, Junio C Hamano wrote: I'd like a datastore that maps a pair of commit object names to another object name, such that: * When looking at two commits A and B, efficiently query all data associated with a pair of commits X,Y where X is contained in the range A..B and not in B..A, and Y is contained in the range B..A and not in A..B. * When X,Y is registered in the datastore, and X is rewritten to X' and/or Y is rewritten to Y', the mapping is updated so that it can be queried with X',Y' as a new key, similar to the way a notes tree that maps object X can be updated to map object X' when such a rewrite happens. The intended use case is to go beyond rerere. Given a history of this shape: o---o---o---I mainline / O---o---X---o---Atopic A \ o---Y---o---o---B topic B If we ignore rewriting for a moment, the information that you want to record is essentially the merge M of X and Y, no? Namely, X and Y conflict logically with each other (though perhaps not textually) and you, the human, want to record how to reconcile them: o---o---o---I mainline / O---o---X---o---Atopic A \ \ \ M \ / o---Y---o---o---B topic B However, you don't necessarily want to go to the trouble to make a branch to point at M, nor to do the bookkeeping manually that would be required to take the information stored in M into account when merging A and B later. Suppose we had M; how could we make use of it in future merges? [...] and can create a merge J without semantic adjustment. o---o---o---I---J mainline / / O---o---X---o---Atopic A \ o---Y---o---o---B topic B That would become o---o---o---I---J mainline / / O---o---X---o---Atopic A \ \ \ M \ / o---Y---o---o---B topic B When I later merge topic B to the integration branch, however, [...] to notice that we need to be careful when creating the merge K: o---o---o---I---J---K mainline / / / O---o---X---o---A /topic A \ / o---Y---o---o---B topic B When doing this merge, I think your goal is equivalent to discovering that M includes part of the merge of J and B, and adding M as an (implicit or explicit) third parent to the merge: o---o---o---I---J---K mainline / /. / O---o---X---o---A. /topic A \ \ . / \ M. / \ / / o---Y---o---o---Btopic B How could M be stored? Assuming that these type of premerge merges are sparse, then Jeff's analysis seems good. Concretely, one could simply store pointers to M from both X and Y; e.g., * Add a note to X with the information when merging this commit with Y, use premerge M * Add a note to Y with the information when merging this commit with X, use premerge M Then, when merging, create the set J..B, scan all of the commits on B..J for these premerge notes (O(|B..J|)), and for each one, look in the set J..B to see if it is present. The effort should scale like O( |J..B| + |B..J| * lg(|J..B|) ) where, of course J and B could be exchanged for either aesthetic or performance reasons. (One would also need a mechanism for preventing M from being garbage-collected.) Incidentally, this is just the sort of thing I have been thinking about using to implement a kind of incremental merge; I've started writing up my thoughts on my blog [1,2,3] (including how to make pretty pictures of merge conflicts). Michael [1] http://softwareswirl.blogspot.de/2012/12/the-conflict-frontier-of-nightmare-merge.html [2] http://softwareswirl.blogspot.de/2012/12/mapping-merge-conflict-frontier.html [3] http://softwareswirl.blogspot.de/2012/12/real-world-conflict-diagrams.html -- Michael Haggerty mhag...@alum.mit.edu http://softwareswirl.blogspot.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: [RFD] annnotating a pair of commit objects?
Am 03.01.2013 08:03, schrieb Junio C Hamano: The intended use case is to go beyond rerere. Given a history of this shape: o---o---o---I mainline / O---o---X---o---Atopic A \ o---Y---o---o---B topic B Suppose in the original O we had a function distimmed_doshes() to tell if doshes are already distimmed, with some call sites. On the branch leading to A, at commit X, this function was renamed to doshes_are_distimmed(), and all existing call sites were adjusted. On the side branch leading to B, however, at commit Y, a new call site to the old function was added in a file that was not touched between O..A at all. When merging either the topic A or the topic B (but not both) to the integration branch that did not touch this function or use of it, no special care needs to be taken, but when merging the second topic after merging the other one, we need to resolve a semantic conflict. Namely, the callsite to distimmed_doshes() introduced by commit Y needs to be adjusted to call doshes_are_distimmed() instead. I guess this issue comes up when you rebuild pu. Perhaps you (and other integrators with a similar workflow) are sufficiently served with something that resembles rebase -p --first-parent, as proposed here: http://thread.gmane.org/gmane.comp.version-control.git/198125/focus=198483 (A proposal of the same idea appeared already years earlier: http://thread.gmane.org/gmane.comp.version-control.git/62782/focus=62794 but its implementation only re-did the merge, which would not help your case.) -- Hannes -- 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 v2 3/5] t4014: a few more tests on cover letter using branch description
Signed-off-by: Nguyễn Thái Ngọc Duy pclo...@gmail.com --- t/t4014-format-patch.sh | 21 + 1 file changed, 21 insertions(+) diff --git a/t/t4014-format-patch.sh b/t/t4014-format-patch.sh index 16a4ca1..ec9ef9e 100755 --- a/t/t4014-format-patch.sh +++ b/t/t4014-format-patch.sh @@ -963,4 +963,25 @@ test_expect_success 'format patch ignores color.ui' ' test_cmp expect actual ' +test_expect_success 'cover letter using branch description (1)' ' + git checkout rebuild-1 + test_config branch.rebuild-1.description hello + git format-patch --stdout --cover-letter master actual + grep hello actual /dev/null +' + +test_expect_success 'cover letter using branch description (2)' ' + git checkout rebuild-1 + test_config branch.rebuild-1.description hello + git format-patch --stdout --cover-letter rebuild-1~2..rebuild-1 actual + grep hello actual /dev/null +' + +test_expect_success 'cover letter using branch description (3)' ' + git checkout rebuild-1 + test_config branch.rebuild-1.description hello + git format-patch --stdout --cover-letter ^master rebuild-1 actual + grep hello actual /dev/null +' + test_done -- 1.8.0.rc2.23.g1fb49df -- 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] Replace git-cvsimport with a rewrite that fixes major bugs.
On 01/03/2013 04:22 PM, Junio C Hamano wrote:
Antoine Pelisse apeli...@gmail.com writes:
Doesn't Python come with a standard subprocess module that lets you
spawn external programs safely, similar to the way Perl's list form
open(), e.g. open($fh, -|, 'git', @args), works?
... and of course a more boring system('git', $subcmd, @args), as well.
Python's os.system() takes exactly one argument, which must be a string,
and executes it in a subshell. subprocess is indeed the way to go.
You mean something like this:
p1 = subprocess.Popen([backend.command()], stdout=subprocess.PIPE)
subprocess.Popen([git, fast-import, --quiet] + gitopts,
cwd=outdir, stdin=p1.stdout)
Assuming gitopts is a list rather than a string. (care must be taken
with backend.command() also)
Yes.
I vaguely recall that the subprocess module once used to be one
portability issue but that was between Python 2.3 and 2.4 or some
ancient history, and it should no longer be relevant.
subprocess was added in Python 2.4, and the above example should work
fine in any version = 2.4. But please note that other functions have
been added to the module since then, like check_call() (v2.5),
check_output (v2.7), and some methods were added to the Popen object in
v2.6.
Such things are documented pretty reliably in the Python library
documentation [1]; when in doubt, one can view older versions of the
library documentation, which are all available online [2].
Michael
[1] http://docs.python.org/2/library/
[2] http://www.python.org/doc/versions/
--
Michael Haggerty
mhag...@alum.mit.edu
http://softwareswirl.blogspot.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
Pretty pictures of git merge conflicts
Hi, I've been thinking lately about how to attack difficult git merge conflicts. The first step is to visualize them. I have written some articles [1,2,3] describing a way to atomize a complicated merge and efficiently compute diagrams that show which pairwise commits cause the merge to go awry. I hope you find them interesting; feedback would be very welcome. I am working on some more articles (including software) that I plan to grow into tools to help users perform git merges that would otherwise seem hopeless. Michael [1] http://softwareswirl.blogspot.de/2012/12/the-conflict-frontier-of-nightmare-merge.html [2] http://softwareswirl.blogspot.de/2012/12/mapping-merge-conflict-frontier.html [3] http://softwareswirl.blogspot.de/2012/12/real-world-conflict-diagrams.html -- Michael Haggerty mhag...@alum.mit.edu http://softwareswirl.blogspot.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: [RFH] NetBSD 6?
Junio C Hamano gits...@pobox.com writes: I forgot to mention that we also ship configure (and keep track of configure.ac) so that optionally people can let autoconf machinery to create config.mak.autogen to be included at the same place as handcrafted config.mak in their build process. I do not offhand know if we do for p in python python2.6 python2.7; do ... kind of thing, though. pkgsrc uses the configure method, but it seems not to output a PYTHON_PATH. It looks like automake's python.m4 is not used by git's configure.ac. But pkgsrc passes PYTHON_PATH in the environment to make, so it works out currently. It refers to the type of the second parameter to iconv(); OLD_ICONV makes it take const char *, as opposed to char *, the latter of which matches http://pubs.opengroup.org/onlinepubs/9699919799/functions/iconv.html Thanks - I now see our extra const and am looking into it. pgpgVxwiC7ZH_.pgp Description: PGP signature
[PATCH v2 0/2] DEFAULT_DOC_TARGET
This allows things like: $ DEFAULT_DOC_TARGET=html make doc $ DEFAULT_DOC_INSTALL_TARGET=html make install-doc on a platform that does not have manpage viewer. Which is not very useful, given that you can already say $ make install-html on such a platform, and these install-$format targets will not go away. The real motivation behind this was to let me say: $ git checkout $some_old_fork_point $ DEFAULT_DOC_TARGET=git-push.1 make doc while updating the sources to the documentation for the maintainance track, without having to format everything else that is different between the old fork point and the primary branch I usually work on. The first one was discussed some time ago on the list and all the fixes mentioned on the thread already squashed in. The second one is merely for completeness. For previous round, see: http://thread.gmane.org/gmane.comp.version-control.git/207193/focus=207201 Junio C Hamano (2): Allow generating a non-default set of documentation Allow installing a non-default set of documentation Documentation/Makefile | 10 -- Makefile | 13 - 2 files changed, 20 insertions(+), 3 deletions(-) -- 1.8.1.293.g4a210a9 -- 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: [BUG] two-way read-tree can write null sha1s into index
Jeff King p...@peff.net writes: Or are you suggesting that the three-way case should always be protected by checking that there are no unmerged entries before we start it? That seems sane to me, but I haven't confirmed that that is the case. I think the normal (and hopefully only) -m -u O A B use case of threeway is the bog-standard git merge, which requires even more: your index must exactly match HEAD, even though you are allowed to have local changes in the working tree. That requirement is not likely to change, as cleanly merged paths are automatically added to the index, so diff --cached should show only the changes from cleanly merged part, while diff should show paths that still needs user's help. If we allowed local modification to the index (let alone conflicted entries in it) before the merge begins, the users would not be able to tell which paths are in what state after a half-merge stops and asks for help. Updated paths may not have anything to do with the merge (i.e. earlier git add before the merge started), conflicting paths may not have anything to do with the merge (i.e. leftover conflicts before the merge started). -- 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: [BUG] two-way read-tree can write null sha1s into index
On Thu, Jan 03, 2013 at 12:34:27PM -0800, Junio C Hamano wrote: Jeff King p...@peff.net writes: Or are you suggesting that the three-way case should always be protected by checking that there are no unmerged entries before we start it? That seems sane to me, but I haven't confirmed that that is the case. I think the normal (and hopefully only) -m -u O A B use case of threeway is the bog-standard git merge, which requires even more: your index must exactly match HEAD, even though you are allowed to have local changes in the working tree. That requirement is not likely to change, as cleanly merged paths are automatically added to the index, so diff --cached should show only the changes from cleanly merged part, while diff should show paths that still needs user's help. If we allowed local modification to the index (let alone conflicted entries in it) before the merge begins, the users would not be able to tell which paths are in what state after a half-merge stops and asks for help. Updated paths may not have anything to do with the merge (i.e. earlier git add before the merge started), conflicting paths may not have anything to do with the merge (i.e. leftover conflicts before the merge started). Oh, I agree it's insane to try to carry through unmerged entries. I'm just concerned that not all code paths are careful enough to check. They probably are, though, as a null sha1 in your index would be the least of your worries, and somebody would have noticed in the last 7 years. -Peff -- 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 0/2] DEFAULT_DOC_TARGET
On Thu, Jan 03, 2013 at 03:32:22PM -0500, Jeff King wrote: On Thu, Jan 03, 2013 at 11:05:18AM -0800, Junio C Hamano wrote: This allows things like: $ DEFAULT_DOC_TARGET=html make doc $ DEFAULT_DOC_INSTALL_TARGET=html make install-doc on a platform that does not have manpage viewer. Which is not very useful, given that you can already say $ make install-html on such a platform, and these install-$format targets will not go away. I think the usefulness is that it can be set by default for a particular uname, so people on Windows can just type make install-doc without having to care about setting anything (though to be honest, I do not even know what they build by default; maybe they do build manpages). I also notice that we have DEFAULT_HELP_FORMAT (which is html on Windows). Wouldn't that be a sane default for DEFAULT_DOC_TARGET if it is set? I guess we can set all three independently for maximum flexibility, though, but it seems like a sane fallback. -Peff -- 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 v2] Documentation: update howto maintain git
The flow described in the document is still correct, but over time I have automated various parts of the workflow with tools and their use was not explained at all. Update it and outline the use of two key scripts from the 'todo' branch, Reintegrate and cook. Signed-off-by: Junio C Hamano gits...@pobox.com --- * I sent an incomplete preview some time ago; this is an update. The old one is at: http://thread.gmane.org/gmane.comp.version-control.git/210632 Antoine Cc'ed because this is a more detailed answer to his question in: http://thread.gmane.org/gmane.comp.version-control.git/212127/focus=212333 Documentation/howto/maintain-git.txt | 314 +-- 1 file changed, 225 insertions(+), 89 deletions(-) diff --git a/Documentation/howto/maintain-git.txt b/Documentation/howto/maintain-git.txt index 8823a37..a4ec3cb 100644 --- a/Documentation/howto/maintain-git.txt +++ b/Documentation/howto/maintain-git.txt @@ -8,20 +8,20 @@ Abstract: Imagine that git development is racing along as usual, when our friend The maintainer's git time is spent on three activities. - - Communication (60%) + - Communication (45%) Mailing list discussions on general design, fielding user questions, diagnosing bug reports; reviewing, commenting on, suggesting alternatives to, and rejecting patches. - - Integration (30%) + - Integration (50%) Applying new patches from the contributors while spotting and correcting minor mistakes, shuffling the integration and testing branches, pushing the results out, cutting the releases, and making announcements. - - Own development (10%) + - Own development (5%) Scratching my own itch and sending proposed patch series out. @@ -35,6 +35,9 @@ The policy. contain bugfixes and enhancements in any area, including functionality, performance and usability, without regression. + - One release cycle for a feature release is expected to last for + eight to ten weeks. + - Maintenance releases are numbered as vX.Y.Z.W and are meant to contain only bugfixes for the corresponding vX.Y.Z feature release and earlier maintenance releases vX.Y.Z.V (V W). @@ -58,12 +61,15 @@ The policy. - 'pu' branch is used to publish other proposed changes that do not yet pass the criteria set for 'next'. - - The tips of 'master', 'maint' and 'next' branches will always - fast-forward, to allow people to build their own - customization on top of them. + - The tips of 'master' and 'maint' branches will not be rewound to + allow people to build their own customization on top of them. + Early in a new development cycle, 'next' is rewound to the tip of + 'master' once, but otherwise it will not be rewound until the end + of the cycle. - - Usually 'master' contains all of 'maint', 'next' contains all - of 'master' and 'pu' contains all of 'next'. + - Usually 'master' contains all of 'maint' and 'next' contains all + of 'master'. 'pu' contains all the topics merged to 'next', but + is rebuilt directly on 'master'. - The tip of 'master' is meant to be more stable than any tagged releases, and the users are encouraged to follow it. @@ -76,11 +82,16 @@ The policy. A typical git day for the maintainer implements the above policy by doing the following: - - Scan mailing list and #git channel log. Respond with review - comments, suggestions etc. Kibitz. Collect potentially - usable patches from the mailing list. Patches about a single - topic go to one mailbox (I read my mail in Gnus, and type - \C-o to save/append messages in files in mbox format). + - Scan mailing list. Respond with review comments, suggestions + etc. Kibitz. Collect potentially usable patches from the + mailing list. Patches about a single topic go to one mailbox (I + read my mail in Gnus, and type \C-o to save/append messages in + files in mbox format). + + - Write his own patches to address issues raised on the list but + nobody has stepped up solving. Send it out just like other + contributors do, and pick them up just like patches from other + contributors (see above). - Review the patches in the saved mailboxes. Edit proposed log message for typofixes and clarifications, and add Acks @@ -96,40 +107,32 @@ by doing the following: - Obviously correct fixes that pertain to the tip of 'master' are directly applied to 'master'. + - Other topics are not handled in this step. + This step is done with git am. $ git checkout master;# or git checkout maint - $ git am -3 -s mailbox + $ git am -sc3 mailbox $ make test - - Merge downwards (maint-master): - - $ git checkout master - $ git merge maint - $ make test + In practice, almost no patch directly goes to 'master' or + 'maint'. - Review the last issue of What's cooking message, review the - topics scheduled for merging upwards (topic-master and -
Re: git filter-branch doesn't dereference annotated tags
On Thu, Jan 3, 2013 at 2:33 AM, Johannes Sixt j...@kdbg.org wrote: Am 03.01.2013 10:50, schrieb Grégory Pakosz: IOW, if the command was something like git filter-branch ...filter options... -- v1.0 master ... and v1.0 is an annotated tag, then it is reasonable to expect v1.0 to be deleted if the commit it points to goes away. But if the commit did not go away, but was rewritten, then it is equally reasonable to expect that the tag is also rewritten. But I don't think that we currently do the latter. When the commit doesn't go away, the tag is currently being rewritten properly. Indeed, but only if a --tag-name-filter was specified. Therefore, IMO, a change that implements the former behavior should also implement the latter behavior. The patch in my latest email does both. (yet lacks unit tests for now) If it deletes a tag only when --tag-name-filter was specified, than that should be fine. Hmm, if a tag name filter _other_ than 'cat' is supplied, I think a user will expect that the original tags will _not_ be touched, and especially not deleted. Rather than blindly deleting the original tag ref, maybe we should still call the user's tag name filter, and then attempt to delete the new name provided by the filter, if it exists. If the filter was 'cat', then the new and old names will be the same. -Brandon -- 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: cvsps, parsecvs, svn2git and the CVS exporter mess
Michael Haggerty mhag...@alum.mit.edu: There are two good reasons that the output is written to two separate files: Those are good reasons to write to a pair of tempfiles, and I was able to deduce in advance most of what your explanation would be from the bare fact that you did it that way. They are *not* good reasons for having an interface that exposes this implementation detail to the caller - that choice I consider a failure of interface-design judgment. But I know how to fix this in a simple and backward-compatible way, and will do so when I have time to write you a patch. Next week or the week after, most likely. Also, the cvs2git manual page is still rather half-baked and careless, with several fossil references to cvs2svn that shouldn't be there and obviously incomplete feature coverage. Fixing these bugs is also on my to-do list for sometime this month. I'd be willing to put in this work anyway, but it still in the back of my mind that if cvs2git wins the test-suite competition I might officially end-of-life both cvsps and parsecvs. One of the features of the new git-cvsimport is direct support for using cvs2git as a conversion engine. A potentially bigger problem is that if you want to handle such blob/dump output, you have to deal with git-fast-import format's blob command as opposed to only handling inline blobs. Not a problem. All of the main potential consumers for this output, including reposurgeon, handle the blob command just fine. cvs2git does not currently support incremental conversions; therefore, a cvsps-based option (if it would actually work, that is) would have at least one advantage over cvs2git. Yes. The reason I didn't ship the replacement patch Junio was expecting yesterday is that I don't have test coverage for the incremental case. I'm working on that now. cvs2svn has an extensive test suite which includes tests derived from bug reports that we have received over the years. I adapted a few of its test repositories to create the git test suite additions that I made in Feb 2009, but there are many more in our project. I've merged those into my tree. I think it would be great to have a way to test across tools, though please realize that the inference of the most plausible true CVS history is partly objective but also often a matter of heuristics and taste. Moreover, the choice of how to represent the inferred history in git, which has rather a different model than CVS/Subversion, is also non-obvious and somewhat controversial. I expect that there will be a number of simple CVS repositories for which we can all agree about the correct git output, but not far away will be a vast number for which the correct answer is unclear. Many of the interesting tests would fall into the latter category. I'm aware of the problem. One of the interesting questions is how much further into the weird cases everybody can agree on what correct translation looks like. We won't know until we push it. It's not clear what you want me to sign off on. If you're not willing to use the new suite, my spending the effort required to genericize it gets much less interesting. I needed Junio's agreement because I wanted to move the old git-cvsimport tests from the git tree to the new test suite; they're not really tests of the wrapper script at all but of the conversion engines. I guess you want to replace (or augment?) the cvs2svn test suite with one based on your framework? Augment, not replace - and just as importantly, commit to writing new tests into the new generic framework when they don't involve a tool-specific option. It would be silly and duplicative for us *not* to be sharing as many tests as we can. * We definitely want to continue testing the Subversion output of cvs2svn. A test suite that only tests the git output could at best be an addition to the current test suite, not a replacement for it. (That being said, the addition of good tests of the 2git output would be great.) Agreed. * A test suite that tests only the easy cases wouldn't really be interesting, because the difficult cases are where the potential problems lie. Yes, I know. I'm arguing that we should be doing that exploration jointly rather than separately. * It would be unfortunate if the cvs2svn test suite would grow another run-time dependency or if we would have to invest a lot of time synchronizing with another project, though if the gain were big enough we could consider it. I know how to keep the friction cost low. You'll see more about this when I split off the test suite and announce it. * The licenses obviously have to be compatible to the extent required by the level of coupling. I don't think this will be a problem. You own the copyright on your tests and I own it on mine, so we can relicense under whatever common license we choose. I'm not fussy about what we use; ASL 2.0 would be fine by
Suggested improvements to the git-p4 documentation (branch-related)
Hi, While struggling to get git-p4 to work properly with branches, I thought the documentation on http://git-scm.com/docs/git-p4 could use some improvements: 1. At the end of the Branch detection section, the following commands are provided (for when you want to explicitly provide branch mappings to git-p4): git config git-p4.branchList main:branch1 git p4 clone --detect-branches //depot@all The second command should end with a dot (.) because the first command only works if you are already in a git-initialized folder. Thus I would also suggest to add git init as first command to type. 2. Even though having a main branch is standard in Perforce, it would be worth mentioning what happens when you don't: there is a message Could not detect main branch. No checkout/master branch created output by the git p4 clone command. However, it will still work if you manually set the master branch (git checkout -b master remotes/p4/my_custom_main_branch). 3. I don't know what I missed for that one, but I haven't been able to get the example for the --branch option to work. It says that after git init, we can import a p4 branch with: git p4 sync --branch=refs/remotes/p4/proj2 //depot/proj2 However, after doing this, followed by git checkout -b proj2 remotes/p4/proj2, I am unable to properly use git p4 sync or git p4 submit from this branch, as git complains about a missing refs/remotes/p4/master. Maybe it only works if git clone has been used before? But then why have git init first? NB: it's quite possible some of my problems were caused by me not properly understanding the doc / how git/p4 works. My apologies if that's the case. -=- Olivier -- 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: Lockless Refs? (Was [PATCH] refs: do not use cached refs in repack_without_ref)
Any thoughts on this idea? Is it flawed? I am trying to write it up in a more formal generalized manner and was hoping to get at least one it seems sane before I do. Thanks, -Martin On Monday, December 31, 2012 03:30:53 am Martin Fick wrote: On Thursday, December 27, 2012 04:11:51 pm Martin Fick wrote: It concerns me that git uses any locking at all, even for refs since it has the potential to leave around stale locks. ... [a previous not so great attempt to fix this] ... I may have finally figured out a working loose ref update mechanism which I think can avoid stale locks. Unfortunately it requires atomic directory renames and universally unique identifiers (uuids). These may be no-go criteria? But I figure it is worth at least exploring this idea because of the potential benefits? The general approach is to setup a transaction and either commit or abort it. A transaction can be setup by renaming an appropriately setup directory to the ref.lock name. If the rename succeeds, the transaction is begun. Any actor can abort the transaction (up until it is committed) by simply deleting the ref.lock directory, so it is not at risk of going stale. However, once the actor who sets up the transaction commits it, deleting the ref.lock directory simply aids in cleaning it up for the next transaction (instead of aborting it). One important piece of the transaction is the use of uuids. The uuids provide a mechanism to tie the atomic commit pieces to the transactions and thus to prevent long sleeping process from inadvertently performing actions which could be out of date when they wake finally up. In each case, the atomic commit piece is the renaming of a file. For the create and update pieces, a file is renamed from the ref.lock dir to the ref file resulting in an update to the sha for the ref. However, in the delete case, the ref file is instead renamed to end up in the ref.lock directory resulting in a delete of the ref. This scheme does not affect the way refs are read today, To prepare for a transaction, an actor first generates a uuid (an exercise I will delay for now). Next, a tmp directory named after the uuid is generated in the parent directory for the ref to be updated, perhaps something like: .lock_uuid. In this directory is places either a file or a directory named after the uuid, something like: .lock_uuid/,uuid. In the case of a create or an update, the new sha is written to this file. In the case of a delete, it is a directory. Once the tmp directory is setup, the initiating actor attempts to start the transaction by renaming the tmp directory to ref.lock. If the rename fails, the update fails. If the rename succeeds, the actor can then attempt to commit the transaction (before another actor aborts it). In the case of a create, the actor verifies that ref does not currently exist, and then renames the now named ref.lock/uuid file to ref. On success, the ref was created. In the case of an update, the actor verifies that ref currently contains the old sha, and then also renames the now named ref.lock/uuid file to ref. On success, the ref was updated. In the case of a delete, the actor may verify that ref currently contains the sha to prune if it needs to, and then renames the ref file to ref.lock/uuid/delete. On success, the ref was deleted. Whether successful or not, the actor may now simply delete the ref.lock directory, clearing the way for a new transaction. Any other actor may delete this directory at any time also, likely either on conflict (if they are attempting to initiate a transaction), or after a grace period just to cleanup the FS. Any actor may also safely cleanup the tmp directories, preferably also after a grace period. One neat part about this scheme is that I believe it would be backwards compatible with the current locking mechanism since the transaction directory will simply appear to be a lock to older clients. And the old lock file should continue to lock out these newer transactions. Due to this backwards compatibility, I believe that this could be incrementally employed today without affecting very much. It could be deployed in place of any updates which only hold ref.locks to update the loose ref. So for example I think it could replace step 4a below from Michael Haggerty's description of today's loose ref pruning during ref packing: * Pack references: ... 4. prune_refs(): for each ref in the ref_to_prune list, call prune_ref(): a. Lock the reference using lock_ref_sha1(), verifying that the recorded SHA1 is still valid. If it is, unlink the loose reference file then free the lock; otherwise leave the loose reference file untouched. I think it would also therefore be able to replace the loose ref locking in Michael's new ref-packing scheme as well as the locking in Michael's new ref
Re: [PATCH 2/2] format-patch: give --reroll-count a short synonym -v
Philip Oakley philipoak...@iee.org writes: +test_expect_success 'reroll count (-v)' ' + rm -fr patches + git format-patch -o patches --cover-letter -v 4 master..side list Shouldn't this be using the sticked form -v4 as described in the commit message and gitcli? I personally do not care too deeply either way. Both styles seem to work, and if/when we break parse-options API implementation, this test will break and we will notice, which might be an added plus ;-) -- 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
Fwd: Git hangs after resolving deltas when using NTLM proxy on Windows
Hi, Git is authenticating to my corporate proxy correctly, but is hanging after resolving deltas. This is when cloning via HTTPS. Apologies for linking to a Gist, but I'm having difficulty getting this list to accept a log file attachment. See https://gist.github.com/4448684 for the curl log. Regards, Adam -- 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
