Re: Test failures in t4034
Brian Gernhardt br...@gernhardtsoftware.com writes:
I've been getting a couple of test failures and finally had the time to track
them down.
t4034-diff-words fails tests 22 diff driver 'bibtex' and 26
diff driver 'html'. Bisecting shows that the file started giving
me errors in commit 8d96e72 t4034: bulk verify builtin word regex
sanity, which appears to introduce those tests. I don't see
anything obviously wrong with the tests and I'm not familiar with
the diff-words code, so I'm not sure what's wrong.
I am running on OS X 10.8, with Xcode 4.4.1 (llvm-gcc 4.2.1).
Test results follow:
-- 8 --
expecting success:
cp $TEST_DIRECTORY/t4034/bibtex/pre \
$TEST_DIRECTORY/t4034/bibtex/post \
$TEST_DIRECTORY/t4034/bibtex/expect .
echo * diff=bibtex .gitattributes
word_diff --color-words
--- expect2012-08-18 05:54:29.0 +
+++ output.decrypted 2012-08-18 05:54:29.0 +
@@ -8,8 +8,8 @@
author={Aldous, REDD.RESETGREENDavidRESET},
journal={Information Theory, IEEE Transactions on},RESET
volume={RED33RESETGREENBogus.RESET},
- number={RED2RESETGREEN4RESET},
+ number={4},
pages={219--223},RESET
- year=GREEN1987,RESET
-GREEN note={This is in fact a rather funny read since ethernet works well
in practice. TheRESET {RED1987RESETGREEN\em pre} reference is the
right one, however.RESET}RED,RESET
+ year=RED{1987},RESETGREEN1987,RESET
+ note={This is in fact a rather funny read since ethernet works well in
practice. The {\em pre} reference is the right one, however.}
}RESET
not ok - 22 diff driver 'bibtex'
Thanks for a report. Off the top of my head, there may be three
possibilities.
(1) The compiled binary of Git is broken on your platform and not
formatting the escape sequence correctly. I somehow think it
is very unlikely, as the code to do so is pretty much platform
agonistic (color.c does not use anything fancy from system
libraries).
(2) The test script, the part that converts the escape sequence to
human readable form, is broken---not written in a portable awk.
(3) The implementation of awk on your platform was broken by your
supplier, with the same infinite wisdom they broke the UTF-8
pathnames on their filesystem implementation with ;-)
Can you help isolating the issue first to see if it is (1) or one of
the other two?
Run cd t sh t4034-diff-words -i to force stop the test upon the
first breakage, and inspect the output before the awk script
test_decode_color munges it. Does it show a red number 2 and green
number 4 on the line that begins with number= (or if you have an
access to a box on which this test passes, grab the raw output from
it by running this test, and make byte-for-byte comparison)?
--
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/RFC v4 01/16] GSOC remote-svn
Junio C Hamano gits...@pobox.com writes: Florian Achleitner florian.achleitner.2.6...@gmail.com writes: On Friday 17 August 2012 21:16:59 Junio C Hamano wrote: Comments from mentors and people interested in remote helpers? I did minimum line wrapping, typofix and small compilation fixes and queued these on 'pu'; I think I saw one commit whose message I didn't quite get what it was trying to say, and another that was missing S-o-b (I left them untouched). Should I provide a better version? I found the commit that I forgot to sign- off, but I'm not sure which message you mean. There was a one with E.g: followed by an incomplete sentence that did not parse for me. Can you fetch 'pu', run format-patch on your topic and compare the output with what you sent to the list? Just to show how, here is what I did just now. (0) Store your 16-patch series and 5-patch series in a mbox; (1) Check where the tip of fa/vcs-svn topic is at. $ git log --oneline --first-parent master..pu | grep fa/ 2ce959b Merge branch 'fa/vcs-svn' into pu 574ffe1 Merge branch 'fa/remote-svn' into pu (2) Check where the topic was based on. $ git log --oneline --first-parent master..2ce959b^2 ... 1385a48 Implement a remote helper for svn in C (3) Detach at the same base and apply the mbox from step (0). $ git checkout 1385a48^ $ git am --whitespace=nowarn mbox (4) Format them (i.e. as the way you sent them, without my fixup) $ git format-patch --stdout master ./+fa-0 (5) Format with my fixup $ git format-patch --stdout master..2ce959b^2 ./+fa-1 (6) Compare them. The differences are my fixups. $ diff -u ./+fa-0 ./+fa-1 | less Patch #17 vcs-svn: Add sha1 calculation to fast_export ... was the one with a sentence whose purpose was unclear to me. By the time you see this message, the tip of pu may have been updated with further updates, so please do not trust 2ce959b above. 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
What's cooking in git.git (Aug 2012, #05; Sat, 18)
Here are the topics that have been cooking. Commits prefixed with '-' are only in 'pu' (proposed updates) while commits prefixed with '+' are in 'next'. I'll be tagging the v1.7.12 final sometime tomorrow, and following the tradition the next branch will be rebuilt on top of 'master' after a few days. We would also eject some topics in 'next' that turned out to be mistakes when that rebuilding happens, but I do not think we have any such topics right now. And then, post 1.7.12 cycle opens. I think the next cycle should start the transition of that much waited push default change topic and perhaps we may want to even call it 1.8.0 release. I haven't decided yet. You can find the changes described here in the integration branches of the repositories listed at http://git-blame.blogspot.com/p/git-public-repositories.html -- [New Topics] * hv/coding-guidelines (2012-08-15) 1 commit (merged to 'next' on 2012-08-18 at 5a78f2c) + Documentation/CodingGuidelines: spell out more shell guidelines In earlier days, imitate the style in the neibouring code was sufficient to keep the coherent style, but over time some parts of the codebase have drifted enough to make it ineffective. * jc/daemon-access-hook (2012-08-15) 1 commit - daemon: --access-hook option Allow an external command to tell git-daemon to decline service based on the client address, repository path, etc. * jc/send-email-reconfirm (2012-08-14) 1 commit - send-email: validate reconfirm interactive responses Validate interactive input to git send-email to avoid common mistakes such as saying yRETURN to sender mail address whose prompt is given with a correctly guessed default. * pw/p4-submit-conflicts (2012-08-16) 12 commits - git p4: add submit --prepare-p4-only option - git p4: add submit --dry-run option - git p4: accept -v for --verbose - git p4: revert deleted files after submit cancel - git p4: rearrange submit template construction - git p4: test clean-up after failed submit, fix added files - git p4: standardize submit cancel due to unchanged template - git p4: move conflict prompt into run, use [c]ontinue and [q]uit - git p4: remove submit failure options [a]pply and [w]rite - git p4: gracefully fail if some commits could not be applied - git p4 test: use p4d -L option to suppress log messages - git p4 test: remove bash-ism of combined export/assignment * tx/relative-in-the-future (2012-08-16) 2 commits - date: show relative dates in the future - date: refactor the relative date logic from presentation * ef/win32-cred-helper (2012-08-16) 1 commit - contrib: add win32 credential-helper * jc/maint-abbrev-option-cli (2012-08-16) 1 commit (merged to 'next' on 2012-08-18 at e002006) + gitcli: describe abbreviation of long options We did not document that many commands take unique prefix abbreviations of long options (e.g. --option may be the only flag that the command accepts that begin with --opt, in which case you can give --opt) anywhere easy to find for new people. * mv/pull-r-for-rebase (2012-08-17) 1 commit (merged to 'next' on 2012-08-18 at e7d885b) + man: git pull -r is a short for --rebase Minor documentation update. * rr/precompose-utf8-cleanup (2012-08-17) 1 commit - cleanup precompose_utf8 A style and code cleanup. * jc/doc-git-updates (2012-08-17) 1 commit (merged to 'next' on 2012-08-18 at f24913b) + Documentation: update the introductory section * fa/remote-svn (2012-08-17) 16 commits - Add a test script for remote-svn - remote-svn: add marks-file regeneration - Add a svnrdump-simulator replaying a dump file for testing - remote-svn: add incremental import - remote-svn: Activate import/export-marks for fast-import - Create a note for every imported commit containing svn metadata - vcs-svn: add fast_export_note to create notes - Allow reading svn dumps from files via file:// urls - remote-svn, vcs-svn: Enable fetching to private refs - When debug==1, start fast-import with --stats instead of --quiet - Add documentation for the 'bidi-import' capability of remote-helpers - Connect fast-import to the remote-helper via pipe, adding 'bidi-import' capability - Add argv_array_detach and argv_array_free_detached - Add svndump_init_fd to allow reading dumps from arbitrary FDs - Integrate remote-svn into svn-fe/Makefile - Implement a remote helper for svn in C (this branch is used by fa/vcs-svn.) * fa/vcs-svn (2012-08-18) 7 commits - fixup: add missing cast to vcs-svn/fast_export.c - fixup - no old style defn - vcs-svn: remove repo_tree - vcs-svn/svndump: rewrite handle_node(), begin|end_revision() - vcs-svn/svndump: restructure node_ctx, rev_ctx handling - svndump: move struct definitions to .h - vcs-svn: Add sha1 calculation to fast_export and line_buffer (this branch uses fa/remote-svn.) * mh/maint-config-doc-proxy-command (2012-08-18) 2 commits - git-config doc: unconfuse an example - git-config.txt: fix
Re: [RFC 0/3] Reflogs for deleted refs: fix breakage and suggest namespace change
On 19 Aug 2012, at 02:02, Junio C Hamano wrote: Alexey Muranov alexey.mura...@gmail.com writes: I hope my opinion might be useful because i do not know anything about the actual implementation of Git,... That sounds like contradiction. I think that the implementation (the code), the model, and the interface are independent. On the top level, for example, one does not need to know how commit storage is optimized, it is enough to understand that each commit is a snapshot of a subtree in a file directory. To just give a quick idea of my ideas, i thought that 'fetching' in Git was an inevitable evil that stands apart from other operations and is necessary only because the computer communication on Earth is not sufficiently developed to keep all Git repositories constantly in sync,... It is a feature, not a symptom of an insufficiently developed technology, that I do not have to know what random tweaks and experiments are done in repositories of 47 thousands people who clone from me, and I can sync with any one of them only when I know there is something worth looking at when I say git fetch. Currently, one of the main functions of 'fetch', apart from changing the remote tracking branches, is downloading the remote objects. This is necessary because of an insufficiently developed technology. The other main function is changing the local copies of remote branches (changing the remote tracking branches), this is what i described as taking a snapshot. I did not understand what you meant by I do not have to know what random tweaks and experiments are done in repositories of 47 thousands people who clone from me, and I can sync with any one of them only when I know there is something worth looking at when I say git fetch. How is it possible to know and not to know what is going on in the remote repository in the same time? -Alexey.-- 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: [RFC 0/3] Reflogs for deleted refs: fix breakage and suggest namespace change
On 19 Aug 2012, at 02:02, Junio C Hamano wrote: Alexey Muranov alexey.mura...@gmail.com writes: I hope my opinion might be useful because i do not know anything about the actual implementation of Git,... That sounds like contradiction. I meant that i am psychologically not attached to the current behavior, and may provide a naïve view point, if you like. -Alexey.-- 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: Porting git to HP NonStop
From: Shawn Pearce [mailto:spea...@spearce.org]
Sent: Friday, August 10, 2012 7:38 PM
To: Joachim Schmitz
Cc: git@vger.kernel.org; rsbec...@nexbridge.com
Subject: Re: Porting git to HP NonStop
On Fri, Aug 10, 2012 at 10:32 AM, Joachim Schmitz
j...@schmitz-digital.de
wrote:
then use `git init --bare` in a new directory to copy in the
templates,
and see if
its the template copying code that is making an incorrect copy.
git init --bare gives the same error. It isn't copying any of the
subdirectories, only the file 'description'
Time to start debugging copy_templates_1 in builtin/init-db.c. :-(
Found the problem: our mkdir(dir,flags) fails with ENOENT when dir ends with
a '/'.
Not sure whether this us a bug on out platform or just allowed by POSIX and
as such a wrong assumption in git though?
[shortly after]
A bit of googleing revealed that there is a GNUlib solution for this, which
claims that at least NetBSD 1.5.2 has the same problem.
(http://www.opensource.apple.com/source/gpatch/gpatch-2/patch/mkdir.c)
And apparently this has been discussed on the git mailing list too, 2 years
ago:
http://lists-archives.com/git/728359-git-s-use-of-mkdir-2.html, there's a
patch too.
For now I've fixed it like this:
/usr/local/bin/diff -EBbu ./builtin/init-db.c.orig ./builtin/init-db.c
--- ./builtin/init-db.c.orig2012-08-19 03:55:50 -0500
+++ ./builtin/init-db.c 2012-08-19 03:39:57 -0500
@@ -25,7 +25,16 @@
static void safe_create_dir(const char *dir, int share)
{
+#ifdef __TANDEM /* our mkdir() can't cope with a trailing '/' */
+ char mydir[PATH_MAX];
+
+ strcpy(mydir,dir);
+ if (dir[strlen(dir)-1] == '/')
+ mydir[strlen(dir)-1] = '\0';
+ if (mkdir(mydir, 0777) 0) {
+#else
if (mkdir(dir, 0777) 0) {
+#endif
if (errno != EEXIST) {
perror(dir);
exit(1);
Bye, Jojo
--
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 1/2] git-config.txt: properly escape quotation marks in example
On 08/19/2012 01:39 AM, Junio C Hamano wrote: Junio C Hamano gits...@pobox.com writes: The bigger question is whether this example is improved by including quotation marks, or whether they are just a distraction from the main point. I abstain. Thanks for spelling that bigger question out. Given that the example is showing distinction between X vs X for Y, I would say quotation is a distraction. [...] I think the answer is no, there is no way to specify anything other than a path to the command for gitproxy. So I think we should do this instead: [...] ACK. Thanks. Michael -- 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: [RFC 0/2] svn-fetch|push - an alternate approach
On 18-08-2012 14:39, James R. McKaskill wrote: As a twist the code does not use the svn library, but rather talks the svn protocol directly. I actually found it much easier to go this route then trying to bend everything to how the svn library understands things. It also has the advantage of not depending on libsvn. A number of distributions currently distribute the svn specific parts of git seperately to avoid this dependency. It is a bit of a pain to work with libsvn, but I think it is worth using it, not only due to protocol support, but also due to ready-to-use support for SVN deltas and dumps. Pipelining could be implemented by maintaining a set of connections (svn_ra_session_t structures) and manually distributing work between them. -- 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: [RFC 0/3] Reflogs for deleted refs: fix breakage and suggest namespace change
On 19 Aug 2012, at 02:02, Junio C Hamano wrote: Alexey Muranov alexey.mura...@gmail.com writes: Excuse me if i miss something again, but i might be willing to discuss the ultimate destination. Could you possibly state in simple terms what the problem with determining the ultimate destination is? Decide if it makes sense to break backward compatibility of loose ref representation merely to support having a branch next and another branch next/foo in the same repository, and if it does, what the new loose ref representation looks like. I looked again through this thread and tried to understand better the issues. 1. I vote for moving dead reflogs to logs/graveyard (or to logs/deadlogs). 2. I think that allowing both next and next/foo complicates the mapping from branch names to file paths, and it does not seem necessary if dead reflogs are moved away to graveyard anyway. 3. There remains the question what to do with dead reflogs for different branches having the same name. Maybe, keep the death date and time under the graveyard directory and not allow the user to delete 2 times in less than 1 second? /logs/graveyard/-mm-dd-hhmmss/refs/heads/next/foo In a sense this is similar to the git storage model: an atomic destructive operation creates a timestamped commit in logs/graveyard directory.-- 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: FW: Git
On Thu, 2012-08-16 at 12:47 -0600, Jean Tappan wrote: I am looking for a tool that will control not only versioning for software, but also the software's associated user and support manuals. I haven't been able to find anything that addresses this particular topic. Can you tell me about this or reference a site or page that discusses it? Jean, If you take a close look at the git.git repo itself you will notice that several different (and at times totally non-overlapping) branches are available. The same option is available for other projects as well. -- -Drew Northup As opposed to vegetable or mineral error? -John Pescatore, SANS NewsBites Vol. 12 Num. 59 -- 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: [RFC 0/3] Reflogs for deleted refs: fix breakage and suggest namespace change
On 08/18/2012 10:39 PM, Junio C Hamano wrote:
mhag...@alum.mit.edu writes:
Given that a flag day would anyway be required to add a d/f-tolerant
system, I could live with a separate graveyard namespace as
originally proposed by Jeff.
However, I still think that as long as we are making a jump, we could
try to land closer to the ultimate destination.
Do we _know_ already what the ultimate destination looks like?
No; we can only guess. I just wanted to submit some code so that the
existence/absence of code would not prejudice the decision.
If the answer is yes, then I agree, but otherwise, I doubt it is a
good idea to introduce unnecessary complexity to the system that may
have to be ripped out and redone.
I didn't get the impression that we know the ultimate destination
from the previous discussion, especially if we discount the tangent
around having next and next/foo at the same time which was on
nobody's wish, but I may be misremembering things.
It's been a wish of mine, but it's pretty low priority. I've also
brainstormed about some other changes that could be connected with a new
repo format:
* Allow deleted loose references (for example denoted by value 0{40})
that override packed references with the same name. This would remove
the need to rewrite the packed-refs file when a reference is deleted.
(A prerequisite for this change would be to allow next and next/foo at
the same time.)
* Push HEAD and its friends down out of $GIT_DIR into a
reference-specific directory.
* Rename lock files to look less like reference names (e.g., something
like refs/foo~lock instead of refs/foo.lock).
* Somehow munge reference names in a way to avoid other filesystem
limitations -- e.g., case insensitivity, filenames like com and prn
or with multiple dots under Windows.
* ...or maybe a packed-refs file that can (usually) be updated in-place,
and get rid of loose references entirely.
Michael
--
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: [PATCH] test: some testcases failed if cwd is on a symlink
On 08/18/2012 10:36 PM, Junio C Hamano wrote: Michael Haggerty mhag...@alum.mit.edu writes: I can work around the problem by using --root=/run/shm. I do not necessarily think it is a work around. http://en.wiktionary.org/wiki/workaround: 2. (computing) A procedure or a temporary fix that bypasses a problem and allows the user to continue working until a better solution can be provided; a kluge. For me that is exactly what it was. A low-impact approach may be to update the part that parses --root option to do root=$(...) root=$( cd $root /bin/pwd ) or something. I just verified that the combination of your two suggestions (i.e., the patch below) fixes the problem for me. Nevertheless, I'm not sure that this is the best solution. The test failures that occur without this change suggest to me that GIT_CEILING_DIRECTORIES is implemented in a fragile way. Michael diff --git a/t/test-lib.sh b/t/test-lib.sh index bb4f886..c7f320f 100644 --- a/t/test-lib.sh +++ b/t/test-lib.sh @@ -15,6 +15,8 @@ # You should have received a copy of the GNU General Public License # along with this program. If not, see http://www.gnu.org/licenses/ . +cd $(pwd -P) + # if --tee was passed, write the output not only to the terminal, but # additionally to the file test-results/$BASENAME.out, too. case $GIT_TEST_TEE_STARTED, $* in @@ -166,6 +168,7 @@ do shift ;; # was handled already --root=*) root=$(expr z$1 : 'z[^=]*=\(.*\)') + root=$(cd $root /bin/pwd) shift ;; *) echo error: unknown test option '$1' 2; exit 1 ;; -- 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: git on HP NonStop
On Tuesday 2012-08-14 17:52, Joachim Schmitz wrote: @@ -98,6 +99,11 @@ #include stdlib.h #include stdarg.h #include string.h +#ifdef __TANDEM +# include strings.h /* for strcasecmp() */ + typedef int intptr_t; /* not int * ?!? */ + typedef unsigned int uintptr_t; /* not unsigned int * ?!? */ Of course not. intptr_t is an integral value capable of holding a pointer; it is not a pointer to int (because that would really be redundant to int*.) -- 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: [RFC 0/3] Reflogs for deleted refs: fix breakage and suggest namespace change
Michael Haggerty mhag...@alum.mit.edu writes:
It's been a wish of mine, but it's pretty low priority. I've also
brainstormed about some other changes that could be connected with a new
repo format:
* Allow deleted loose references (for example denoted by value 0{40})
that override packed references with the same name. This would remove
the need to rewrite the packed-refs file when a reference is deleted.
(A prerequisite for this change would be to allow next and next/foo at
the same time.)
We would need to think the performance implications through of the
approach; it tempts us to accumulate the loose removed markers in
the hope that it would be an improvement than having to rewrite the
packed-refs over and over, and without numbers to back that theory
up, we may be worsening the system without knowing.
Having said that, it is an interesting idea. I wouldn't use 0{40} as
the sentinel value but rather use letters outside [0-9a-f], though.
* Push HEAD and its friends down out of $GIT_DIR into a
reference-specific directory.
Not going to happen for several years, I am afraid, as I think many
casual tools do an equivalent of test -f $DIR/HEAD to see if $DIR
is a repository; even our own gitweb does so.
We should advertise an easy way for scripted Porcelains to directly
ask is_git_directory().
* Rename lock files to look less like reference names (e.g., something
like refs/foo~lock instead of refs/foo.lock).
If you do the ~d/~f thing, foo.lock becomes a non-issue, no?
* Somehow munge reference names in a way to avoid other filesystem
limitations -- e.g., case insensitivity, filenames like com and prn
or with multiple dots under Windows.
Very interesting. I however am afraid that the users and the
projects will learn to avoid the problematic names a lot sooner than
such a change will be implemented to make the issue go away (or they
have already learned long time ago), and the end result may end up
solving a non-issue only to make the output from find .git/refs
even more unreadable.
* ...or maybe a packed-refs file that can (usually) be updated in-place,
and get rid of loose references entirely.
I find this equally intriguing as your deleted one above.
--
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: Test failures in t4034
Brian Gernhardt mister.r...@gmail.com writes:
I wonder if there is something non-portable about the bibtex
filter? (The HTML filter as well, since that errors on my machine
too.)
Yeah, that I didn't think of, but is a possibility (part of (1)
above).
The HTML one is [^= \t]+ and
the Bibtex one is [={}\]|[^={}\ \t]+
and both will be used with |[^[:space:]]|[\xc0-\xff][\x80-\xbf]+
appended and given to regcomp with REG_EXTENDED|REG_NEWLINE.
Nothing jumps at me that is common to these two but not shared by
other patterns.
--
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] cleanup precompose_utf8
On 17.08.12 19:30, Junio C Hamano wrote: Robin Rosenberg robin.rosenb...@dewire.com writes: Remove extraneous parentheses and braces Remove redundant NUL-termination Check result of unlink when probing for decomposed file names Signed-off-by: Robin Rosenberg robin.rosenb...@dewire.com --- Thanks. I've found and fixed a bit more style violations while we are at it. (I was offline for a couple of days) Thanks to all, and ACK from my side. /Torsten -- 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: Porting git to HP NonStop
Joachim Schmitz j...@schmitz-digital.de writes:
Found the problem: our mkdir(dir,flags) fails with ENOENT when dir ends with
a '/'.
Not sure whether this us a bug on out platform or just allowed by POSIX and
as such a wrong assumption in git though?
[shortly after]
A bit of googleing revealed that there is a GNUlib solution for this, which
claims that at least NetBSD 1.5.2 has the same problem.
(http://www.opensource.apple.com/source/gpatch/gpatch-2/patch/mkdir.c)
And apparently this has been discussed on the git mailing list too, 2 years
ago:
http://lists-archives.com/git/728359-git-s-use-of-mkdir-2.html, there's a
patch too.
Given that newer BSDs have fixed libc to accept directory name with
a trailing slash, and that we use mkdir(2) in many places, I think
the right way to do so is still what I suggested in that old thread
in the last paragraph of my message
http://thread.gmane.org/gmane.comp.version-control.git/155812/focus=155876
That is, have compat/tandem.c and define a replacement mkdir(2) in a
way similar to how MinGW does so.
For now I've fixed it like this:
/usr/local/bin/diff -EBbu ./builtin/init-db.c.orig ./builtin/init-db.c
--- ./builtin/init-db.c.orig2012-08-19 03:55:50 -0500
+++ ./builtin/init-db.c 2012-08-19 03:39:57 -0500
@@ -25,7 +25,16 @@
static void safe_create_dir(const char *dir, int share)
{
+#ifdef __TANDEM /* our mkdir() can't cope with a trailing '/' */
+ char mydir[PATH_MAX];
+
+ strcpy(mydir,dir);
+ if (dir[strlen(dir)-1] == '/')
+ mydir[strlen(dir)-1] = '\0';
+ if (mkdir(mydir, 0777) 0) {
+#else
if (mkdir(dir, 0777) 0) {
+#endif
Move that part inside #ifdef __TANDEM to define
int tandem_mkdir(const char *dir, mode_t mode)
{
...
}
in your new file compat/tandem.c, add
#ifdef __TANDEM
#define mkdir(a,b) tandem_mkdir((a), (b))
#endif
to git-compat-util.h and then add compat/tandem.o to COMPAT_OBJS in
the top-level Makefile.
That way we do not have to keep an ugly platform specific ifdef in
the very generic codepath.
if (errno != EEXIST) {
perror(dir);
exit(1);
Bye, Jojo
--
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: [RFC 0/3] Reflogs for deleted refs: fix breakage and suggest namespace change
Alexey Muranov alexey.mura...@gmail.com writes: 2. I think that allowing both next and next/foo complicates the mapping from branch names to file paths, and it does not seem necessary if dead reflogs are moved away to graveyard anyway. It is unclear why the first two lines above leads to the conclusion it does not seem necessary (but honestly, I do not particularly care). 3. There remains the question what to do with dead reflogs for different branches having the same name. Maybe, keep the death date and time under the graveyard directory and not allow the user to delete 2 times in less than 1 second? /logs/graveyard/-mm-dd-hhmmss/refs/heads/next/foo How would that help us in what way? When I ask git log -g next/foo for the next/foo branch that currently exists, I want to see the update history of its tip since I created it for the last time, and then an entry that says I created it at such and such time. If I used to have the branch before but deleted, then the output should be followed by another entry that says I deleted it at such and such time, followed by the history of the tip updates. -- 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
read-cache-v5.c: compiler warnings
Hi Thomas, Just an FYI; two out of the three gcc compilers I use (Linux, cygwin but not MingW), issue the following warnings: CC read-cache-v5.o read-cache-v5.c: In function `write_index_v5': read-cache-v5.c:1011: warning: 'dir' might be used uninitialized in this function read-cache-v5.c:1012: warning: 'search' might be used uninitialized in this function read-cache-v5.c:1012: warning: 'found' might be used uninitialized in this function [commit d2537158 (Write index-v5, 16-08-2012)] Normally I would take a look and offer a patch, but I haven't found time to do so in the last 10 days. So, I'm just giving you a heads up ... ;-P HTH ATB, Ramsay Jones -- 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 v3 2/2] git-svn.perl: keep processing all commits in parents_exclude
Steven Walter stevenrwal...@gmail.com wrote: On Sat, Aug 18, 2012 at 3:51 PM, Sam Vilain s...@vilain.net wrote: On 08/11/2012 10:14 AM, Steven Walter wrote: --- git-svn.perl |1 - t/t9164-git-svn-fetch-merge-branch-of-branch2.sh | 53 ++ Thanks all. Steven: This doesn't apply cleanly to master since git-svn.perl is split into separate files (git-svn.perl - perl/Git/SVN*) Can you rebase against Junio's current master? Thanks again. -- 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: [RFC PATCH 1/2] rm: don't fail when removing populated submodules
Am 17.08.2012 20:11, schrieb Phil Hord: On Fri, Aug 17, 2012 at 12:44 PM, Jens Lehmann jens.lehm...@web.de wrote: I'm almost there. The only thing left is to check if a nested submodule is using a git directory. In that case I expect rm to fail even when -f is used to protect the submodule's history. I still need to find a suitable command for recursing the submodules and doing that check. I suppose the style of this is wrong, but this seems to work for me. git submodule foreach --recursive '! test -f .git' Thanks! I was looking for something less expensive, but given that I don't expect removing submodules to be a performance critical operation this test should just work fine. -- 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: Test failures in t4034
Am 19.08.2012 16:50, schrieb Ramsay Jones: Brian Gernhardt wrote: I've been getting a couple of test failures and finally had the time to track them down. t4034-diff-words fails tests 22 diff driver 'bibtex' and 26 diff driver 'html'. Bisecting shows that the file started giving me errors in commit 8d96e72 t4034: bulk verify builtin word regex sanity, which appears to introduce those tests. I don't see anything obviously wrong with the tests and I'm not familiar with the diff-words code, so I'm not sure what's wrong. I am running on OS X 10.8, with Xcode 4.4.1 (llvm-gcc 4.2.1). I had the same problem (or at least it *looks* like the same problem) on Linux last year (May 2011), which turned out to be a bug in the regex routines in an old version of glibc. I also had the same problem, but did not remember why I don't have it anymore. Now that you mention it: It was the same situation and I came to the same conclusion (old glibc, bogus regex implementation). I worked it around with NO_REGEX=YesPlease in config.mak. -- 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 1/2] t6300: test sort with multiple keys
Documentation of git-for-each-ref says that --sort=key option can be used multiple times, in which case the last key becomes the primary key. However this functionality was never checked in test suite and is currently broken. This commit adds appropriate test in preparation for fix. Signed-off-by: Kacper Kornet drae...@pld-linux.org --- t/t6300-for-each-ref.sh | 33 - 1 file changed, 32 insertions(+), 1 deletion(-) diff --git a/t/t6300-for-each-ref.sh b/t/t6300-for-each-ref.sh index 1721784..3d59bfc 100755 --- a/t/t6300-for-each-ref.sh +++ b/t/t6300-for-each-ref.sh @@ -242,7 +242,32 @@ test_expect_success 'Verify descending sort' ' test_cmp expected actual ' +test_expect_success 'Create branches to test sort with multiple keys' ' + git checkout -b Branch1 + echo foo one + git commit -a -m Branch1 commit + git checkout -b Branch2 + echo foo one + git commit -a -m Branch2 commit +' + +test_atom refs/heads/Branch1 objectname 32fca05e9f638021a123a84226acf17756acc18b +test_atom refs/heads/Branch2 objectname 194a5b89ac661a114566ba4374bc06c2797539f3 + cat expected \EOF +67a36f10722846e891fbada1ba48ed035de75581 commitrefs/heads/master +194a5b89ac661a114566ba4374bc06c2797539f3 commitrefs/heads/Branch2 +32fca05e9f638021a123a84226acf17756acc18b commitrefs/heads/Branch1 +EOF + +test_expect_failure 'Verify sort with multiple keys' ' + git for-each-ref --sort=objectname --sort=committerdate refs/heads actual + test_cmp expected actual +' + +cat expected \EOF +'refs/heads/Branch1' +'refs/heads/Branch2' 'refs/heads/master' 'refs/remotes/origin/master' 'refs/tags/testtag' @@ -264,6 +289,8 @@ test_expect_success 'Quoting style: python' ' ' cat expected \EOF +refs/heads/Branch1 +refs/heads/Branch2 refs/heads/master refs/remotes/origin/master refs/tags/testtag @@ -285,6 +312,8 @@ for i in --perl --shell -s --python --python --tcl --tcl --perl; do done cat expected \EOF +Branch1 +Branch2 master testtag EOF @@ -296,6 +325,8 @@ test_expect_success 'Check short refname format' ' ' cat expected EOF + + origin/master EOF @@ -309,7 +340,7 @@ cat expected EOF EOF test_expect_success 'Check short objectname format' ' - git for-each-ref --format=%(objectname:short) refs/heads actual + git for-each-ref --format=%(objectname:short) refs/heads/master actual test_cmp expected actual ' -- 1.7.12.rc3 -- 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 2/2] for-each-ref: Fix sort with multiple keys
The linked list describing sort options was not correctly set up in
opt_parse_sort. In the result, contrary to the documentation. only the
last of multiple --sort options to git-for-each-ref was taken into
account. This commit fixes it.
Signed-off-by: Kacper Kornet drae...@pld-linux.org
---
builtin/for-each-ref.c | 4 +++-
t/t6300-for-each-ref.sh | 2 +-
2 files changed, 4 insertions(+), 2 deletions(-)
diff --git a/builtin/for-each-ref.c b/builtin/for-each-ref.c
index b01d76a..0c5294e 100644
--- a/builtin/for-each-ref.c
+++ b/builtin/for-each-ref.c
@@ -962,7 +962,9 @@ static int opt_parse_sort(const struct option *opt, const
char *arg, int unset)
if (!arg) /* should --no-sort void the list ? */
return -1;
- *sort_tail = s = xcalloc(1, sizeof(*s));
+ s = xcalloc(1, sizeof(*s));
+ s-next = *sort_tail;
+ *sort_tail = s;
if (*arg == '-') {
s-reverse = 1;
diff --git a/t/t6300-for-each-ref.sh b/t/t6300-for-each-ref.sh
index 3d59bfc..4c5d8ba 100755
--- a/t/t6300-for-each-ref.sh
+++ b/t/t6300-for-each-ref.sh
@@ -260,7 +260,7 @@ cat expected \EOF
32fca05e9f638021a123a84226acf17756acc18b commitrefs/heads/Branch1
EOF
-test_expect_failure 'Verify sort with multiple keys' '
+test_expect_success 'Verify sort with multiple keys' '
git for-each-ref --sort=objectname --sort=committerdate refs/heads
actual
test_cmp expected actual
'
--
1.7.12.rc3
--
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: [RFC 0/3] Reflogs for deleted refs: fix breakage and suggest namespace change
On 19 Aug 2012, at 19:38, Junio C Hamano wrote: Alexey Muranov alexey.mura...@gmail.com writes: 2. I think that allowing both next and next/foo complicates the mapping from branch names to file paths, and it does not seem necessary if dead reflogs are moved away to graveyard anyway. It is unclear why the first two lines above leads to the conclusion it does not seem necessary (but honestly, I do not particularly care). I thought that the first reason that allowing next and next/foo seemed necessary was avoiding conflicts with dead reflogs or between dead reflogs. If dead reflog for next/foo is moved away, it will not conflict with a new one for next. There remains a problem with a conflict between dead next/foo and dead next. This can be solved as Jeff suggested by adding special escape symbols, or as i suggested below, by keeping reflogs deleted on different occasions in different timestamp directories. 3. There remains the question what to do with dead reflogs for different branches having the same name. Maybe, keep the death date and time under the graveyard directory and not allow the user to delete 2 times in less than 1 second? /logs/graveyard/-mm-dd-hhmmss/refs/heads/next/foo How would that help us in what way? When I ask git log -g next/foo for the next/foo branch that currently exists, I want to see the update history of its tip since I created it for the last time, and then an entry that says I created it at such and such time. If I used to have the branch before but deleted, then the output should be followed by another entry that says I deleted it at such and such time, followed by the history of the tip updates. I only suggested how to resolve conflicts between dead reflogs in graveyard if next and next/foo cannot coexist. For example, if first next/foo was created and deleted, and then next was created and deleted. It also seems nice to me to have dead reflogs for different identically named branches (created and deleted independently) in separate files. It is possible to collect the information for git log -g next/foo by looking through all timestamp subdirectories in graveyard. -Alexey.-- 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/RFC] git svn: handle errors and concurrent commits in dcommit
Eric Wong wrote: Hi, Junio C Hamano gits...@pobox.com wrote: I should have asked this yesterday, but do you mean you want to have your maint in the upcoming 1.7.12? This does look like a useful thing to do, but does not seem like a regression fix to me. Yeah, I wasn't sure what to name it since my master is still carrying Michael's larger SVN 1.7 changes. Perhaps I should've named my maint for-git-master in this case... While working on my next patch, I've accidentally discovered that bash gives the following errors in the test file introduced in my commit : ./t9164-git-svn-dcommit-concrrent.sh: line 65: $hook: ambiguous redirect ./t9164-git-svn-dcommit-concrrent.sh: line 66: $hook: ambiguous redirect (The test succeeds, even though assignments of the PATH and svnconf variables is missing; is seems svn treats an empty value of --config-dir as the current dir.) Sorry about not noticing this before, dash is used as default /bin/sh on my system. A simple patch for this issue is included below. There is also a typo in the test file name: `concrrent' instead of `concurrent', but it most probably doesn't make any sense to make a patch for it. 8---8---8---8---8---8---8---8---8---8---8---8---8 Subject: [PATCH] Add missing quotes in test t9164 This fixes `ambiguous redirect' error given by bash. --- t/t9164-git-svn-dcommit-concrrent.sh |4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/t/t9164-git-svn-dcommit-concrrent.sh b/t/t9164-git-svn-dcommit-concrrent.sh index aac2dda..676ef00 100755 --- a/t/t9164-git-svn-dcommit-concrrent.sh +++ b/t/t9164-git-svn-dcommit-concrrent.sh @@ -62,8 +62,8 @@ EOF1 if [ $hook_type = pre-commit ]; then echo echo 'commit disallowed' 2; exit 1 $hook else - echo PATH=\$PATH\; export PATH $hook - echo svnconf=\$svnconf\ $hook + echo PATH=\$PATH\; export PATH $hook + echo svnconf=\$svnconf\ $hook cat $hook - 'EOF2' cd work-auto-commits.svn svn up --config-dir $svnconf -- 1.7.10.4 8---8---8---8---8---8---8---8---8---8---8---8---8 Regards, robert -- 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/RFC] git svn: optionally trim imported log messages
Introduce a `--trim-svn-log' option and svn.trimsvnlog boolean
configuration key for git svn commands.
When enabled while retrieving commits from svn, git svn will strip any
white spaces from beginnings and endings of SVN commit messages and will
skip adding an extra new line character before `git-svn-id:' line in case
the commit message already ends with a pseudo-headers section (a section
starting with an empty line followed by one or more pseudo-headers like
`From: ', `Signed-off-by: ', or `Change-Id: ').
Additionally, while creating new commits in svn when the new option is
enabled and `--add-author-from' is in effect, git svn will not add
a new line character before the `From: ' pseudo-header if the commit
message already ends with a pseudo-headers section.
The new option allows one to use gerrit code review system on
git-svn-managed repositories. gerrit expects its `Change-Id:' header
to appear in the last paragraph of commit message and the standard
behaviour of preceding `git-svn-id:' line with a new line character
was breaking this expectation.
---
Documentation/git-svn.txt | 16 ++
git-svn.perl |8 +-
perl/Git/SVN.pm| 19 +-
t/t9165-git-svn-import-messages.sh | 387
4 files changed, 427 insertions(+), 3 deletions(-)
create mode 100755 t/t9165-git-svn-import-messages.sh
diff --git a/Documentation/git-svn.txt b/Documentation/git-svn.txt
index cfe8d2b..79c21ee 100644
--- a/Documentation/git-svn.txt
+++ b/Documentation/git-svn.txt
@@ -603,6 +603,22 @@ creating the branch or tag.
git commit's author string. If you use this, then `--use-log-author`
will retrieve a valid author string for all commits.
+--trim-svn-log::
+ When retrieving svn commits into git (as part of 'fetch', 'rebase',
+ or 'dcommit') trim the whitespaces from beginnings and endings
+ of the svn log messages and avoid preceding `git-svn-id:` line with
+ a new line character in case the log message already ends with a
+ pseudo-headers section (i.e. section starting with an empty line
+ followed by one or more lines like `Signed-off-by: `, `From: `,
+ or `Change-Id: `).
++
+When committing to svn from git (as part of 'commit-diff', 'set-tree'
+or 'dcommit') and '--add-author-from' is in effect, a new line character
+is not added before the `From: ` line if the log message ends with
+a pseudo-headers section.
++
+[verse]
+config key: svn.trimsvnlog
ADVANCED OPTIONS
diff --git a/git-svn.perl b/git-svn.perl
index 828b8f0..3740835 100755
--- a/git-svn.perl
+++ b/git-svn.perl
@@ -133,6 +133,7 @@ my %fc_opts = ( 'follow-parent|follow!' =
\$Git::SVN::_follow_parent,
\$Git::SVN::_repack_flags,
'use-log-author' = \$Git::SVN::_use_log_author,
'add-author-from' = \$Git::SVN::_add_author_from,
+ 'trim-svn-log' = \$Git::SVN::_trim_svn_log,
'localtime' = \$Git::SVN::_localtime,
%remote_opts );
@@ -500,6 +501,8 @@ sub cmd_clone {
cmd_init($url, $path);
command_oneline('config', 'svn.authorsfile', $authors_absolute)
if $_authors;
+ command_oneline('config', 'svn.trimsvnlog', 'true')
+ if $Git::SVN::_trim_svn_log;
Git::SVN::fetch_all($Git::SVN::default_repo_id);
}
@@ -1782,7 +1785,10 @@ sub get_commit_entry {
$msgbuf =~ s/\s+$//s;
if ($Git::SVN::_add_author_from defined($author)
!$saw_from) {
- $msgbuf .= \n\nFrom: $author;
+ $msgbuf .= \n;
+ $msgbuf .= \n
+ unless Git::SVN::avoid_extra_new_line($msgbuf);
+ $msgbuf .= From: $author;
}
print $log_fh $msgbuf or croak $!;
command_close_pipe($msg_fh, $ctx);
diff --git a/perl/Git/SVN.pm b/perl/Git/SVN.pm
index 8478d0c..9604667 100644
--- a/perl/Git/SVN.pm
+++ b/perl/Git/SVN.pm
@@ -5,7 +5,7 @@ use Fcntl qw/:DEFAULT :seek/;
use constant rev_map_fmt = 'NH40';
use vars qw/$_no_metadata
$_repack $_repack_flags $_use_svm_props $_head
-$_use_svnsync_props $no_reuse_existing
+$_use_svnsync_props $no_reuse_existing $_trim_svn_log
$_use_log_author $_add_author_from $_localtime/;
use Carp qw/croak/;
use File::Path qw/mkpath/;
@@ -978,6 +978,17 @@ sub gc {
command_noisy('gc', '--auto');
};
+# An utility function which returns true if both trimming svn log messages
+# is enabled, and passed log entry ends with a pseudo-headers section (i.e.
+# section starting with empty line followed by one or more pseudo-headers
+# like 'From: ' or 'Change-Id: ' etc.)
+sub avoid_extra_new_line {
+ return 0 unless $_trim_svn_log;
+
+ my $log_entry = shift;
+ return ($log_entry =~ m/\n\n([\w-]+:\s.*\n)+$/);
Re: [PATCH/RFC] git svn: optionally trim imported log messages
Robert Luberda rob...@debian.org writes: Introduce a `--trim-svn-log' option and svn.trimsvnlog boolean configuration key for git svn commands. When enabled while retrieving commits from svn, git svn will strip any white spaces from beginnings and endings of SVN commit messages and will skip adding an extra new line character before `git-svn-id:' line in case the commit message already ends with a pseudo-headers section (a section starting with an empty line followed by one or more pseudo-headers like `From: ', `Signed-off-by: ', or `Change-Id: '). Additionally, while creating new commits in svn when the new option is enabled and `--add-author-from' is in effect, git svn will not add a new line character before the `From: ' pseudo-header if the commit message already ends with a pseudo-headers section. The new option allows one to use gerrit code review system on git-svn-managed repositories. gerrit expects its `Change-Id:' header to appear in the last paragraph of commit message and the standard behaviour of preceding `git-svn-id:' line with a new line character was breaking this expectation. --- Sign-off? Documentation/git-svn.txt | 16 ++ git-svn.perl |8 +- perl/Git/SVN.pm| 19 +- t/t9165-git-svn-import-messages.sh | 387 4 files changed, 427 insertions(+), 3 deletions(-) create mode 100755 t/t9165-git-svn-import-messages.sh diff --git a/Documentation/git-svn.txt b/Documentation/git-svn.txt index cfe8d2b..79c21ee 100644 --- a/Documentation/git-svn.txt +++ b/Documentation/git-svn.txt @@ -603,6 +603,22 @@ creating the branch or tag. git commit's author string. If you use this, then `--use-log-author` will retrieve a valid author string for all commits. +--trim-svn-log:: + When retrieving svn commits into git (as part of 'fetch', 'rebase', + or 'dcommit') trim the whitespaces from beginnings and endings + of the svn log messages and avoid preceding `git-svn-id:` line with + a new line character in case the log message already ends with a + pseudo-headers section (i.e. section starting with an empty line + followed by one or more lines like `Signed-off-by: `, `From: `, + or `Change-Id: `). ++ +When committing to svn from git (as part of 'commit-diff', 'set-tree' +or 'dcommit') and '--add-author-from' is in effect, a new line character +is not added before the `From: ` line if the log message ends with +a pseudo-headers section. I think it would be saner to call them trailers to avoid confusion. I've seen S-o-b, Cc and Change-Id there, but does anybody actually put From: there? There needs an explanation to the reader why this is an optional feature. --- /dev/null +++ b/t/t9165-git-svn-import-messages.sh @@ -0,0 +1,387 @@ +#!/bin/sh +# +# Copyright (c) 2012 Robert Luberda +# + +test_description='checks behaviour of --trim-svn-log option of git svn' +. ./lib-git-svn.sh + +# The test cases in this file check if the --trim-svn-log option +# of git svn works as expected. +# +# Basically the test cases use two git repositories: +# * work-TRIM.git, created by git svn clone with the option enabled, +# * work-NOTR.git, created with the option disabled. +# +# Each test case (except for the first two) does the following: +# 1. commit a change to svn with either svn commit, or git svn dcommit +#(what is important is the commit log message, not the changed file) +# 2. git svn rebase the work-NOTR.git repository and check its most recent +#log message against some expected output +# 3. git svn rebase the work-TRIM.git repository and similarly check the +#latest log message +# +# The following two prerequisites are defined mostly for debugging purposes +# to make it possible to skip test cases or parts of the test cases that +# operate on one of the two git repositories. For example to ignore checking The prerequisite mechanism is to allow some tests in an environment where they cannot be run (e.g. no SVN available on the platform); any code that uses set_prereq unconditionally looks extremely strange. It is OK while the patch is in RFC stage under active debugging, but they would want to go away before the polishing is done. +# of log messages imported when --trim-svn-log is enabled, one needs to comment +# out the PRQ_TRIM pre-requisite (this makes it possible to run the test with +# a version of git svn that does not support the option yet). Similarly +# commenting out the PRQ_NOTR pre-requisite will check only the effects of the +# svn log trimming option. +# Please note that a whole test case must be marked as requiring one of +# those pre-requisites if and only if it uses `git svn dcommit' for committing +# changes to svn. +test_set_prereq PRQ_TRIM +test_set_prereq PRQ_NOTR +N=0 +NL=# for better readability only, e.g.: + # $NL $NL is
Re: [RFC 0/3] Reflogs for deleted refs: fix breakage and suggest namespace change
Alexey Muranov alexey.mura...@gmail.com writes: I only suggested how to resolve conflicts between dead reflogs in graveyard if next and next/foo cannot coexist. But Jeff's patch series already has the support for a case where you delete next (graveyard gets 'next'), create next/foo and then delete that (graveyard gets 'next/foo', too) anyway (check the list archive before posting). It is a solved problem. It is possible to collect the information for git log -g next/foo by looking through all timestamp subdirectories in graveyard. It is possible if you wrote a new file every time you add one entry to reflog, or if you created a directory with timestamp in its name and wrote a new file there, too. We are not particularly interested in it is possible when many implementations can all trivially allow it to be possible; the question is what a sensible solution is among them, and I didn't find a directory with timestamp in its name a particularly sensible way to go. Either Jeff's refname $name's log goes to logs/graveyard/$name~ or Michael's append ~d to each directory component, append ~f to the leaf component that are already proposed will keep one file per name property to allow us to open once and efficiently read the file through. Why would we want to see an inferiour alternative added to the discussion? -- 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 2/2] for-each-ref: Fix sort with multiple keys
Kacper Kornet drae...@pld-linux.org writes: The linked list describing sort options was not correctly set up in opt_parse_sort. In the result, contrary to the documentation. only the last of multiple --sort options to git-for-each-ref was taken into account. This commit fixes it. Signed-off-by: Kacper Kornet drae...@pld-linux.org --- builtin/for-each-ref.c | 4 +++- t/t6300-for-each-ref.sh | 2 +- 2 files changed, 4 insertions(+), 2 deletions(-) diff --git a/builtin/for-each-ref.c b/builtin/for-each-ref.c index b01d76a..0c5294e 100644 --- a/builtin/for-each-ref.c +++ b/builtin/for-each-ref.c @@ -962,7 +962,9 @@ static int opt_parse_sort(const struct option *opt, const char *arg, int unset) if (!arg) /* should --no-sort void the list ? */ return -1; - *sort_tail = s = xcalloc(1, sizeof(*s)); + s = xcalloc(1, sizeof(*s)); + s-next = *sort_tail; + *sort_tail = s; This fix looks correct. -- 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: [RFC 0/3] Reflogs for deleted refs: fix breakage and suggest namespace change
Junio C Hamano gits...@pobox.com writes: Either Jeff's refname $name's log goes to logs/graveyard/$name~ or Michael's append ~d to each directory component, append ~f to the leaf component that are already proposed will keep one file per name property to allow us to open once and efficiently read the file through. Why would we want to see an inferiour alternative added to the discussion? Note that there may be some other advantage I am not seeing in the directory with timestamp in its name; if it is a big enough advantage over what have already been proposed, then that would be a valid reason why we may want to see it as an alternative (and at that point, it is no longer inferior). That is the reason why I asked How would that help us in what way? -- 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 1/2] git-svn.perl: consider all ranges for a given merge, instead of only tip-by-tip
Consider the case where you have trunk, branch1 of trunk, and branch2 of
branch1. trunk is merged back into branch2, and then branch2 is
reintegrated into trunk. The merge of branch2 into trunk will have
svn:mergeinfo property references to both branch1 and branch2. When
git-svn fetches the commit that merges branch2 (check_cherry_pick),
it is necessary to eliminate the merged contents of branch1 as well as
branch2, or else the merge will be incorrectly ignored as a cherry-pick.
Signed-off-by: Steven Walter stevenrwal...@gmail.com
---
perl/Git/SVN.pm |8 ++-
t/t9165-git-svn-fetch-merge-branch-of-branch.sh | 60 +++
2 files changed, 63 insertions(+), 5 deletions(-)
create mode 100755 t/t9165-git-svn-fetch-merge-branch-of-branch.sh
diff --git a/perl/Git/SVN.pm b/perl/Git/SVN.pm
index 8478d0c..2707003 100644
--- a/perl/Git/SVN.pm
+++ b/perl/Git/SVN.pm
@@ -1695,14 +1695,14 @@ sub find_extra_svn_parents {
my @merge_tips;
my $url = $self-{url};
my $uuid = $self-ra_uuid;
- my %ranges;
+ my @all_ranges;
for my $merge ( @merges ) {
my ($tip_commit, @ranges) =
lookup_svn_merge( $uuid, $url, $merge );
unless (!$tip_commit or
grep { $_ eq $tip_commit } @$parents ) {
push @merge_tips, $tip_commit;
- $ranges{$tip_commit} = \@ranges;
+ push @all_ranges, @ranges;
} else {
push @merge_tips, undef;
}
@@ -1717,8 +1717,6 @@ sub find_extra_svn_parents {
my $spec = shift @merges;
next unless $merge_tip and $excluded{$merge_tip};
- my $ranges = $ranges{$merge_tip};
-
# check out 'new' tips
my $merge_base;
eval {
@@ -1740,7 +1738,7 @@ sub find_extra_svn_parents {
my (@incomplete) = check_cherry_pick(
$merge_base, $merge_tip,
$parents,
- @$ranges,
+ @all_ranges,
);
if ( @incomplete ) {
diff --git a/t/t9165-git-svn-fetch-merge-branch-of-branch.sh
b/t/t9165-git-svn-fetch-merge-branch-of-branch.sh
new file mode 100755
index 000..13ae7e3
--- /dev/null
+++ b/t/t9165-git-svn-fetch-merge-branch-of-branch.sh
@@ -0,0 +1,60 @@
+#!/bin/sh
+#
+# Copyright (c) 2012 Steven Walter
+#
+
+test_description='git svn merge detection'
+. ./lib-git-svn.sh
+
+svn_ver=$(svn --version --quiet)
+case $svn_ver in
+0.* | 1.[0-4].*)
+ skip_all=skipping git-svn test - SVN too old ($svn_ver)
+ test_done
+ ;;
+esac
+
+test_expect_success 'initialize source svn repo' '
+ svn_cmd mkdir -m x $svnrepo/trunk
+ svn_cmd mkdir -m x $svnrepo/branches
+ svn_cmd co $svnrepo/trunk $SVN_TREE
+ (
+ cd $SVN_TREE
+ touch foo
+ svn_cmd add foo
+ svn_cmd commit -m initial commit
+ svn_cmd cp -m branch $svnrepo/trunk
$svnrepo/branches/branch1
+ svn_cmd switch $svnrepo/branches/branch1
+ touch bar
+ svn_cmd add bar
+ svn_cmd commit -m branch1
+ svn_cmd cp -m branch $svnrepo/branches/branch1
$svnrepo/branches/branch2
+ svn_cmd switch $svnrepo/branches/branch2
+ touch baz
+ svn_cmd add baz
+ svn_cmd commit -m branch2
+ svn_cmd switch $svnrepo/trunk
+ touch bar2
+ svn_cmd add bar2
+ svn_cmd commit -m trunk
+ svn_cmd switch $svnrepo/branches/branch2
+ svn_cmd merge $svnrepo/trunk
+ svn_cmd commit -m merge trunk
+ svn_cmd switch $svnrepo/trunk
+ svn_cmd merge --reintegrate $svnrepo/branches/branch2
+ svn_cmd commit -m merge branch2
+ )
+ rm -rf $SVN_TREE
+'
+
+test_expect_success 'clone svn repo' '
+ git svn init -s $svnrepo
+ git svn fetch
+'
+
+test_expect_success 'verify merge commit' 'x=$(git rev-parse HEAD^2)
+ y=$(git rev-parse branch2)
+ test x$x = x$y
+'
+
+test_done
--
1.7.9.5
--
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 2/2] git-svn.perl: keep processing all commits in parents_exclude
This fixes a bug where git finds the incorrect merge parent. Consider a
repository with trunk, branch1 of trunk, and branch2 of branch1.
Without this change, git interprets a merge of branch2 into trunk as a
merge of branch1 into trunk.
Signed-off-by: Steven Walter stevenrwal...@gmail.com
---
perl/Git/SVN.pm |1 -
t/t9166-git-svn-fetch-merge-branch-of-branch2.sh | 53 ++
2 files changed, 53 insertions(+), 1 deletion(-)
create mode 100755 t/t9166-git-svn-fetch-merge-branch-of-branch2.sh
diff --git a/perl/Git/SVN.pm b/perl/Git/SVN.pm
index 2707003..e48ba46 100644
--- a/perl/Git/SVN.pm
+++ b/perl/Git/SVN.pm
@@ -1661,7 +1661,6 @@ sub parents_exclude {
if ( $commit eq $excluded ) {
push @excluded, $commit;
$found++;
- last;
}
else {
push @new, $commit;
diff --git a/t/t9166-git-svn-fetch-merge-branch-of-branch2.sh
b/t/t9166-git-svn-fetch-merge-branch-of-branch2.sh
new file mode 100755
index 000..af0ec0e
--- /dev/null
+++ b/t/t9166-git-svn-fetch-merge-branch-of-branch2.sh
@@ -0,0 +1,53 @@
+#!/bin/sh
+#
+# Copyright (c) 2012 Steven Walter
+#
+
+test_description='git svn merge detection'
+. ./lib-git-svn.sh
+
+svn_ver=$(svn --version --quiet)
+case $svn_ver in
+0.* | 1.[0-4].*)
+ skip_all=skipping git-svn test - SVN too old ($svn_ver)
+ test_done
+ ;;
+esac
+
+test_expect_success 'initialize source svn repo' '
+ svn_cmd mkdir -m x $svnrepo/trunk
+ svn_cmd mkdir -m x $svnrepo/branches
+ svn_cmd co $svnrepo/trunk $SVN_TREE
+ (
+ cd $SVN_TREE
+ touch foo
+ svn_cmd add foo
+ svn_cmd commit -m initial commit
+ svn_cmd cp -m branch $svnrepo/trunk
$svnrepo/branches/branch1
+ svn_cmd switch $svnrepo/branches/branch1
+ touch bar
+ svn_cmd add bar
+ svn_cmd commit -m branch1
+ svn_cmd cp -m branch $svnrepo/branches/branch1
$svnrepo/branches/branch2
+ svn_cmd switch $svnrepo/branches/branch2
+ touch baz
+ svn_cmd add baz
+ svn_cmd commit -m branch2
+ svn_cmd switch $svnrepo/trunk
+ svn_cmd merge --reintegrate $svnrepo/branches/branch2
+ svn_cmd commit -m merge branch2
+ )
+ rm -rf $SVN_TREE
+'
+
+test_expect_success 'clone svn repo' '
+ git svn init -s $svnrepo
+ git svn fetch
+'
+
+test_expect_success 'verify merge commit' 'x=$(git rev-parse HEAD^2)
+ y=$(git rev-parse branch2)
+ test x$x = x$y
+'
+
+test_done
--
1.7.9.5
--
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
[ANNOUNCE] Git v1.7.12
The latest feature release Git v1.7.12 is now available at the usual places. The release tarballs are found at: http://code.google.com/p/git-core/downloads/list and their SHA-1 checksums are: 42ec1037f1ee5bfeb405710c83b73c0515ad26e6 git-1.7.12.tar.gz 50bbfeba77af9a411cc1a1e41220782cf3fd9b5e git-htmldocs-1.7.12.tar.gz fb572729ca5c60161dc651564a50d4378507e20f git-manpages-1.7.12.tar.gz Also the following public repositories all have a copy of the v1.7.12 tag and the master branch that the tag points at: url = git://repo.or.cz/alt-git.git url = https://code.google.com/p/git-core/ url = git://git.sourceforge.jp/gitroot/git-core/git.git url = git://git-core.git.sourceforge.net/gitroot/git-core/git-core url = https://github.com/gitster/git Git v1.7.12 Release Notes = Updates since v1.7.11 - UI, Workflows Features * Git can be told to normalize pathnames it read from readdir(3) and all arguments it got from the command line into precomposed UTF-8 (assuming that they come as decomposed UTF-8), in order to work around issues on Mac OS. I think there still are other places that need conversion (e.g. paths that are read from stdin for some commands), but this should be a good first step in the right direction. * Per-user $HOME/.gitconfig file can optionally be stored in $HOME/.config/git/config instead, which is in line with XDG. * The value of core.attributesfile and core.excludesfile default to $HOME/.config/git/attributes and $HOME/.config/git/ignore respectively when these files exist. * Logic to disambiguate abbreviated object names have been taught to take advantage of object types that are expected in the context, e.g. XX in the git describe output v1.2.3-gXX must be a commit object, not a blob nor a tree. This will help us prolong the lifetime of abbreviated object names. * git apply learned to wiggle the base version and perform three-way merge when a patch does not exactly apply to the version you have. * Scripted Porcelain writers now have access to the credential API via the git credential plumbing command. * git help used to always default to man format even on platforms where man viewer is not widely available. * git clone --local $path started its life as an experiment to optionally use link/copy when cloning a repository on the disk, but we didn't deprecate it after we made the option a no-op to always use the optimization. The command learned --no-local option to turn this off, as a more explicit alternative over use of file:// URL. * git fetch and friends used to say remote side hung up unexpectedly when they failed to get response they expect from the other side, but one common reason why they don't get expected response is that the remote repository does not exist or cannot be read. The error message in this case was updated to give better hints to the user. * git help -w $cmd can show HTML version of documentation for git-$cmd by setting help.htmlpath to somewhere other than the default location where the build procedure installs them locally; the variable can even point at a http:// URL. * git rebase [-i] --root $tip can now be used to rewrite all the history leading to $tip down to the root commit. * git rebase -i learned -x cmd to insert exec cmd after each commit in the resulting history. * git status gives finer classification to various states of paths in conflicted state and offer advice messages in its output. * git submodule learned to deal with nested submodule structure where a module is contained within a module whose origin is specified as a relative URL to its superproject's origin. * A rather heavy-ish git completion script has been split to create a separate git prompting script, to help lazy-autoloading of the completion part while making prompting part always available. * gitweb pays attention to various forms of credits that are similar to Signed-off-by: lines in the commit objects and highlights them accordingly. Foreign Interface * mediawiki remote helper (in contrib/) learned to handle file attachments. * git p4 now uses Jobs: and p4 move when appropriate. * vcs-svn has been updated to clean-up compilation, lift 32-bit limitations, etc. Performance, Internal Implementation, etc. (please report possible regressions) * Some tests showed false failures caused by a bug in ecryptofs. * We no longer use AsciiDoc7 syntax in our documentation and favor a more modern style. * git am --rebasing codepath was taught to grab authorship, log message and the patch text directly out of existing commits. This will help rebasing commits that have confusing diff output in their log messages. * git index-pack and git pack-objects use streaming API to read from the object store to avoid having to hold a large blob object in-core
A note from the maintainer
Welcome to the Git development community.
This message is written by the maintainer and talks about how Git
project is managed, and how you can work with it.
* Mailing list and the community
The development is primarily done on the Git mailing list. Help
requests, feature proposals, bug reports and patches should be sent to
the list address git@vger.kernel.org. You don't have to be
subscribed to send messages. The convention on the list is to keep
everybody involved on Cc:, so it is unnecessary to say Please Cc: me,
I am not subscribed.
Before sending patches, please read Documentation/SubmittingPatches
and Documentation/CodingGuidelines to familiarize yourself with the
project convention.
If you sent a patch and you did not hear any response from anybody for
several days, it could be that your patch was totally uninteresting,
but it also is possible that it was simply lost in the noise. Please
do not hesitate to send a reminder message in such a case. Messages
getting lost in the noise is a sign that people involved don't have
enough mental/time bandwidth to process them right at the moment, and
it often helps to wait until the list traffic becomes calmer before
sending such a reminder.
The list archive is available at a few public sites:
http://news.gmane.org/gmane.comp.version-control.git/
http://marc.theaimsgroup.com/?l=git
http://www.spinics.net/lists/git/
For those who prefer to read it over NNTP (including the maintainer):
nntp://news.gmane.org/gmane.comp.version-control.git
When you point at a message in a mailing list archive, using
gmane is often the easiest to follow by readers, like this:
http://thread.gmane.org/gmane.comp.version-control.git/27/focus=217
as it also allows people who subscribe to the mailing list as gmane
newsgroup to jump to the article.
Some members of the development community can sometimes also be found
on the #git IRC channel on Freenode. Its log is available at:
http://colabti.org/irclogger/irclogger_log/git
* Reporting bugs
When you think git does not behave as you expect, please do not stop
your bug report with just git does not work. I used git in this
way, but it did not work is not much better, neither is I used git
in this way, and X happend, which is broken. It often is that git is
correct to cause X happen in such a case, and it is your expectation
that is broken. People would not know what other result Y you expected
to see instead of X, if you left it unsaid.
Please remember to always state
- what you wanted to achieve;
- what you did (the version of git and the command sequence to reproduce
the behavior);
- what you saw happen (X above);
- what you expected to see (Y above); and
- how the last two are different.
See http://www.chiark.greenend.org.uk/~sgtatham/bugs.html for further
hints.
* Repositories, branches and documentation.
My public git.git repositories are at:
git://git.kernel.org/pub/scm/git/git.git/
git://repo.or.cz/alt-git.git/
https://github.com/git/git/
https://code.google.com/p/git-core/
git://git.sourceforge.jp/gitroot/git-core/git.git/
git://git-core.git.sourceforge.net/gitroot/git-core/git-core/
A few gitweb interfaces are found at:
http://git.kernel.org/?p=git/git.git
http://repo.or.cz/w/alt-git.git
Preformatted documentation from the tip of the master branch can be
found in:
git://git.kernel.org/pub/scm/git/git-{htmldocs,manpages}.git/
git://repo.or.cz/git-{htmldocs,manpages}.git/
https://code.google.com/p/git-{htmldocs,manpages}.git/
https://github.com/gitster/git-{htmldocs,manpages}.git/
You can browse the HTML manual pages at:
http://git-htmldocs.googlecode.com/git/git.html
There are four branches in git.git repository that track the source tree
of git: master, maint, next, and pu.
The master branch is meant to contain what are very well tested and
ready to be used in a production setting. Every now and then, a feature
release is cut from the tip of this branch and they typically are named
with three dotted decimal digits. The last such release was 1.7.12 done on
Aug 19, 2012. You can expect that the tip of the master branch is always
more stable than any of the released versions.
Whenever a feature release is made, maint branch is forked off from
master at that point. Obvious, safe and urgent fixes after a feature
release are applied to this branch and maintenance releases are cut from
it. The maintenance releases are named with four dotted decimal, named
after the feature release they are updates to; the last such release was
1.7.11.5. New features never go to this branch. This branch is also
merged into master to propagate the fixes forward.
A new development does not usually happen on master. When you send a
series of patches, after review on the mailing list, a separate topic
branch is forked from the tip of master and your
BUG Report. Why GIT commit need 30GB of memory for a commit?
I have a big repository, around 80GB git --version #git version 1.7.12 git init . #Initialized empty Git repository in /reponame/.git/ git add -A . git commmit -m Backup 2012-08-19 03:43:44 #fatal: Out of memory, malloc failed (tried to allocate 32220431361 bytes) #[master (root-commit) 8053f0d] Backup 2012-08-19 03:43:44 Why GIT need 30GB of memory for a commit? This is not in accordance with the first paragraph of the homepage of main page of GIT: Git is a free and open source distributed version control system designed to handle everything from small to very large projects with speed and efficiency. Greetings, José Nobile -- 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 1/2] t6300: test sort with multiple keys
On Sun, Aug 19, 2012 at 05:38:29PM -0700, Junio C Hamano wrote: Kacper Kornet drae...@pld-linux.org writes: Documentation of git-for-each-ref says that --sort=key option can be used multiple times, in which case the last key becomes the primary key. However this functionality was never checked in test suite and is currently broken. This commit adds appropriate test in preparation for fix. Signed-off-by: Kacper Kornet drae...@pld-linux.org --- Thanks. +test_expect_success 'Create branches to test sort with multiple keys' ' + git checkout -b Branch1 + echo foo one + git commit -a -m Branch1 commit + git checkout -b Branch2 + echo foo one + git commit -a -m Branch2 commit +' + +test_atom refs/heads/Branch1 objectname 32fca05e9f638021a123a84226acf17756acc18b +test_atom refs/heads/Branch2 objectname 194a5b89ac661a114566ba4374bc06c2797539f3 Do these need to be Branch[12], not branch[12] for the code to exhibit the bug? If not, please don't be creative in names like these. On case corrupting filesystems you may write Branch1 and they may come back as branch1, but that is not what we are testing here. Branches names can be lowercased. Only the commit messages should be preserved as they produce the test depends on the lexicographical order of created SHA1s. @@ -296,6 +325,8 @@ test_expect_success 'Check short refname format' ' ' cat expected EOF + + origin/master What are these blank line outputs? The upstreams of Branch1 and Branch2. EOF @@ -309,7 +340,7 @@ cat expected EOF EOF test_expect_success 'Check short objectname format' ' - git for-each-ref --format=%(objectname:short) refs/heads actual + git for-each-ref --format=%(objectname:short) refs/heads/master actual test_cmp expected actual ' All in all, I have to wonder if you can limit the updates to other unrelated tests if you added a new test near the end. Also doesn't the existing test already create enough refs to let you sort with multiple keys and demonstrate the breakage already, without adding new refs and objects? My intention was to group all tests to sort in one place. But if the preferred place for a new one is at the end, then it is possible to find the adequate refs among existing ones. -- Kacper Kornet -- 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
