Re: [PATCH] git-cvsimport: allow author-specific timezones
On Mon, Oct 15, 2012 at 08:50:21PM -0700, Junio C Hamano wrote: Chris Rorvick ch...@rorvick.com writes: It occurred to me that the success of the unit test depends on the host platform's zoneinfo database. I think this problem is inherent with this functionality. Should the unit test attempt to detect support for the used timezones and short circuit if this fails? Not sure exactly how I'd do this, but wondering if it's worth thinking about. Yeah, that did indeed cross my mind. You could say TZ=QST6QDT or something silly like that but that in turn has to assume your tzset() is POSIX.1 compliant anyway. We use EST5 in t0006 (it was originally just EST but IRIX complained). It's been in the test suite for two years without a problem, so it may be simple and safe enough to just use that. -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: push race
Hi Jeff, it would be worth to put your description as comments in the code for future reference. Thanks -Angelo -- 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 2/2] grep: stop looking at random places for .gitattributes
Am 10/15/2012 18:54, schrieb Junio C Hamano: Ideally, that earlier workaround should have done a logica equivalent of: ... and did so not in-line at the calling site but in a compat/ wrapper for fflush() to eliminate the need for the ifdef. Fair enough. But reverting the EINVAL check from write_or_die.c is out of question, because that handles a real case. Correction: I can't reproduce the error messages that this was working around anymore in a brief test. I'll revert the check locally and see what happens. -- 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: error: git-fast-import died of signal 11
On 10/15/2012 05:53 PM, Uri Moszkowicz wrote: I'm trying to convert a CVS repository to Git using cvs2git. I was able to generate the dump file without problem but am unable to get Git to fast-import it. The dump file is 328GB and I ran git fast-import on a machine with 512GB of RAM. fatal: Out of memory? mmap failed: Cannot allocate memory fast-import: dumping crash report to fast_import_crash_18192 error: git-fast-import died of signal 11 How can I import the repository? What versions of git and of cvs2git are you using? If not the current versions, please try with the current versions. What is the nature of your repository (i.e., why is it so big)? Does it consist of extremely large files? A very deep history? Extremely many branches/tags? Extremely many files? Did you check whether the RAM usage of git-fast-import process was growing gradually to fill RAM while it was running vs. whether the usage seemed reasonable until it suddenly crashed? There are a few obvious possibilities: 0. There is some reason that too little of your computer's RAM is available to git-fast-import (e.g., ulimit, other processes running at the same time, much RAM being used as a ramdisk, etc). 1. Your import is simply too big for git-fast-import to hold in memory the accumulated things that it has to remember. I'm not familiar with the internals of git-fast-import, but I believe that the main thing that it has to keep in RAM is the list of marks (references to git objects that can be referred to later in the import). From your crash file, it looks like there were about 350k marks loaded at the time of the crash. Supposing each mark is about 100 bytes, this would only amount to 35 Mb, which should not be a problem (*if* my assumptions are correct). 2. Your import contains a gigantic object which individually is so big that it overflows some component of the import. (I don't know whether large objects are handled streamily; they might be read into memory at some point.) But since your computer had so much RAM this is hardly imaginable. 3. git-fast-import has a memory leak and the accumulated memory leakage is exhausting your RAM. 4. git-fast-import has some other kind of a bug. 5. The contents of the dumpfile are corrupt in a way that is triggering the problem. This could either be invalid input (e.g., an object that is reported to be quaggabytes large), or some invalid input that triggers a bug in git-fast-import. If (1), then you either need a bigger machine or git-fast-import needs architectural changes. If (2), then you either need a bigger machine or git-fast-import and/or git needs architectural changes. If (3), then it would be good to get more information about the problem so that the leak can be fixed. If this is the case, it might be possible to work around the problem by splitting the dumpfile into several parts and loading them one after the other (outputting the marks from one run and loading them into the next). If (4) or (5), then it would be helpful to narrow down the problem. It might be possible to do so by following the instructions in the cvs2svn FAQ [1] for systematically shrinking a test case to smaller size using destroy_repository.py and shrink_test_case.py. If you can create a small repository that triggers the same problem, then there is a good chance that it is easy to fix. Michael (the cvs2git maintainer) [1] http://cvs2svn.tigris.org/faq.html#testcase -- 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: build deps
David Aguilar venit, vidit, dixit 16.10.2012 03:39: On Mon, Oct 15, 2012 at 1:53 PM, Junio C Hamano gits...@pobox.com wrote: Michael J Gruber g...@drmicha.warpmail.net writes: grep.c:451:16: warning: comparison of unsigned enum expression 0 is always false [-Wtautological-compare] if (p-field 0 || GREP_HEADER_FIELD_MAX = p-field) ^ ~ 1 warning generated. Right, that enum type starts at 0. Junio, you last touched this area. Can we just dump the first comparison or did you have something else in mind? I think it was a leftover from the very first implementation that defensively said this has to be one of these known ones, and tried to bound it from both sides of the range, regaredless of the actual type of the field (these GREP_HEADER_WHAT things may have been simple integers with #define'd values). Dropping the negative comparison is perfectly fine. This snippet of code came up before: http://thread.gmane.org/gmane.comp.version-control.git/184908/focus=185014 There seemed to be good reasons to keep the check at the time. Was this same snippet not also touched when Nguyen Thai Ngoc Duy worked on the even if I'm drunk patch?: http://thread.gmane.org/gmane.comp.version-control.git/206413/focus=206539 With the drunk patch then we wouldn't need the check at all, which is really nice. I hope that helps jog folks' memories. I'm not sure if the above discussions are relevant anymore, but I figured it'd be good to provide some more context. cheers, The drunk patch, cheers ;) That's very valuable context that you are giving. So it's either avoiding the warning and relying and enum unsignedness (or human/static analysis) or playing it safe and keeping the warning. How is if (/* p-field 0 || */ GREP_HEADER_FIELD_MAX = p-field) to remind any reader that the first condition should be granted? One could take this further and use a macro but that seems overkill. Michael -- 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 when trying to delete symbolic refs
Am 15.10.2012 10:50, schrieb Johan Herland:
Basically, there is a master branch, and an alias symref to
master. When we naively try to delete the symref with git branch -d
alias, it ends up:
- NOT deleting the alias symref
- DELETING the master loose ref
- NOT deleting the master packed ref
So, from the user perspective, git branch -d alias ends up resetting
master (and alias) back to the last time we happened to run git
gc. Needless to say, this is not quite what we had in mind...
AFAICS, there may be three possible acceptable outcomes when we run
git branch -d alias in the above scenario:
A. The symbolic ref is deleted. This is obviously what we expected...
Below is a patch to do that.
B. The command fails because alias is a symref. This would be
understandable if we don't want to teach branch -d about symrefs.
But then, the error message should ideally explain which command we
should use to remove the symref.
Renaming of symrefs with branch -m is disallowed because it's more
complicated than it looks at first; this was discussed here:
http://thread.gmane.org/gmane.comp.version-control.git/98825/focus=99206
I can't imagine why deletion should be prohibited as well, though.
C. The master ref (BOTH loose and packed versions of it) is
deleted. This would be less helpful for us, but Git would at least be
internally consistent (in that the symref would be resolved, and the
command would become git branch -d master).
Are there use cases for this behaviour?
While I don't use symrefs, I'd somehow expect them to behave like
symbolic links on Unix do, where rm removes a link, not its target.
But I wonder why most delete_ref() calls in the code actually don't use
the flag REF_NODEREF, thus deleting symref targets instead of the
symrefs themselves. I may be missing something important here.
---
builtin/branch.c | 2 +-
t/t3200-branch.sh | 10 ++
2 files changed, 11 insertions(+), 1 deletion(-)
diff --git a/builtin/branch.c b/builtin/branch.c
index ffd2684..31af114 100644
--- a/builtin/branch.c
+++ b/builtin/branch.c
@@ -221,7 +221,7 @@ static int delete_branches(int argc, const char **argv, int
force, int kinds,
continue;
}
- if (delete_ref(name, sha1, 0)) {
+ if (delete_ref(name, sha1, REF_NODEREF)) {
error(remote_branch
? _(Error deleting remote branch '%s')
: _(Error deleting branch '%s'),
diff --git a/t/t3200-branch.sh b/t/t3200-branch.sh
index 79c8d01..4b73406 100755
--- a/t/t3200-branch.sh
+++ b/t/t3200-branch.sh
@@ -262,6 +262,16 @@ test_expect_success 'config information was renamed, too' \
test $(git config branch.s.dummy) = Hello
test_must_fail git config branch.s/s/dummy
+test_expect_success 'deleting a symref' '
+ git branch target
+ git symbolic-ref refs/heads/symlink refs/heads/target
+
+ git branch -d symlink
+
+ test_path_is_file .git/refs/heads/target
+ test_path_is_missing .git/refs/heads/symlink
+'
+
test_expect_success 'renaming a symref is not allowed' \
'
git symbolic-ref refs/heads/master2 refs/heads/master
--
1.7.12
--
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] refs: lock symref that is to be deleted, not its target
When delete_ref is called on a symref then it locks its target and then
either deletes the target or the symref, depending on whether the flag
REF_NODEREF was set in the parameter delopt.
Instead, simply pass the flag to lock_ref_sha1_basic, which will then
either lock the target or the symref, and delete the locked ref.
This reimplements part of eca35a25 (Fix git branch -m for symrefs.).
Signed-off-by: Rene Scharfe rene.scha...@lsrfire.ath.cx
---
Independent patch, kind of related.
refs.c | 18 +-
1 file changed, 5 insertions(+), 13 deletions(-)
diff --git a/refs.c b/refs.c
index da74a2b..9d1685b 100644
--- a/refs.c
+++ b/refs.c
@@ -1753,26 +1753,18 @@ int delete_ref(const char *refname, const unsigned char
*sha1, int delopt)
struct ref_lock *lock;
int err, i = 0, ret = 0, flag = 0;
- lock = lock_ref_sha1_basic(refname, sha1, 0, flag);
+ lock = lock_ref_sha1_basic(refname, sha1, delopt, flag);
if (!lock)
return 1;
if (!(flag REF_ISPACKED) || flag REF_ISSYMREF) {
/* loose */
- const char *path;
-
- if (!(delopt REF_NODEREF)) {
- i = strlen(lock-lk-filename) - 5; /* .lock */
- lock-lk-filename[i] = 0;
- path = lock-lk-filename;
- } else {
- path = git_path(%s, refname);
- }
- err = unlink_or_warn(path);
+ i = strlen(lock-lk-filename) - 5; /* .lock */
+ lock-lk-filename[i] = 0;
+ err = unlink_or_warn(lock-lk-filename);
if (err errno != ENOENT)
ret = 1;
- if (!(delopt REF_NODEREF))
- lock-lk-filename[i] = '.';
+ lock-lk-filename[i] = '.';
}
/* removing the loose one could have resurrected an earlier
* packed one. Also, if it was not loose we need to repack
--
1.7.12
--
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 12/12] Add git-check-ignore sub-command
Adam, do you have time to continue this series? I can help polish it for inclusion, but I don't want to step in your way if you are quietly updating it. On Tue, Oct 16, 2012 at 5:31 AM, Junio C Hamano gits...@pobox.com wrote: + +If `-z` is specified, the output is a series of lines of the form: + Hmph... the remainder of the paragraph seems to have been chopped off. No, the last version [1] looks the same. I was worried there was a bug somewhere in the toolchain that chopped it off. [1] http://thread.gmane.org/gmane.comp.version-control.git/204661/focus=206085 +EXIT STATUS +--- + +0:: + One or more of the provided paths is ignored. -- Duy -- 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: When Will We See Collisions for SHA-1? (An interesting analysis by Bruce Schneier)
Am 15.10.2012 20:34, schrieb Jeff King:
On Mon, Oct 15, 2012 at 07:47:09PM +0200, Ævar Arnfjörð Bjarmason wrote:
On Mon, Oct 15, 2012 at 6:42 PM, Elia Pinto gitter.spi...@gmail.com wrote:
Very clear analysis. Well written. Perhaps is it the time to update
http://git-scm.com/book/ch6-1.html (A SHORT NOTE ABOUT SHA-1) ?
Hope useful
http://www.schneier.com/crypto-gram-1210.html
This would be concerning if the Git security model would break down if
someone found a SHA1 collision, but it really wouldn't.
It's one thing to find *a* collision, it's quite another to:
1. Find a collision for the sha1 of harmless.c which I know you use,
and replace it with evil.c.
2. Somehow make evil.c compile so that it actually does something
useful and nefarious, and doesn't just make the C compiler puke.
If finding one arbitrary collision costs $43K in 2021 dollars
getting past this point is going to take quite a large multiple of
$43K.
There are easier attacks than that if you can hide arbitrary bytes
inside a file. It's hard with C source code. The common one in hash
collision detection circles is to put invisible cruft into binary
document formats like PDF or Postscript. Git blobs themselves do not
have such an invisible place to put it, but you might be storing a
format that does.
But worse, git _commits_ have such an invisible portion. We calculate
the sha1 over the full commit, but we tend to show only the portion up
to the first NUL byte. I used that horrible trick in my choose your own
sha1 prefix patch. However, we could mitigate that by checking for
embedded NULs in git-fsck.
FWIW, I couldn't measure a performance difference for git log with and
without the following patch, which catches commits created with your
hash collision trick, but might be too strict:
diff --git a/commit.c b/commit.c
index 213bc98..4cd1e83 100644
--- a/commit.c
+++ b/commit.c
@@ -262,6 +262,12 @@ int parse_commit_buffer(struct commit *item, const void
*buffer, unsigned long s
if (item-object.parsed)
return 0;
item-object.parsed = 1;
+
+ if (memchr(buffer, '\0', size)) {
+ return error(bogus commit contains a NUL character: %s,
+sha1_to_hex(item-object.sha1));
+ }
+
tail += size;
if (tail = bufptr + 46 || memcmp(bufptr, tree , 5) || bufptr[45] !=
'\n')
return error(bogus commit object %s,
sha1_to_hex(item-object.sha1));
--
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/4] t3419-rebase-patch-id: heed USR_BIN_TIME prereq
t3419 sets the t3419-rebase-patch-id.sh prereq based on the availability of /usr/bin/time but calls the binary unconditionally (in debug mode). Make it run the timing only when the prereq is matched. Signed-off-by: Michael J Gruber g...@drmicha.warpmail.net --- t/t3419-rebase-patch-id.sh | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/t/t3419-rebase-patch-id.sh b/t/t3419-rebase-patch-id.sh index e70ac10..52af547 100755 --- a/t/t3419-rebase-patch-id.sh +++ b/t/t3419-rebase-patch-id.sh @@ -69,7 +69,7 @@ do_tests() git cherry-pick master /dev/null 21 - test_debug + test_have_prereq USR_BIN_TIME test_debug run git diff master^\! @@ -77,7 +77,7 @@ do_tests() echo 'file binary' .gitattributes - test_debug + test_have_prereq USR_BIN_TIME test_debug run git format-patch --stdout master run git format-patch --stdout --ignore-if-in-upstream master -- 1.8.0.rc2.304.g9f3ac5c -- 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/4] test-lib: allow variable export from lazy prereq tests
Currently, lazy prereq tests are run in a subshell which communicates
only the exit code to the outer world.
Run it as a subcommand so that variables can be exported to the test
environment.
Signed-off-by: Michael J Gruber g...@drmicha.warpmail.net
---
I don't think this has any adverse side effects, but I'm begging for
another set of eyeballs to have a look. (Test suite passes, of course.)
t/test-lib-functions.sh | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/t/test-lib-functions.sh b/t/test-lib-functions.sh
index 8889ba5..e587902 100644
--- a/t/test-lib-functions.sh
+++ b/t/test-lib-functions.sh
@@ -246,13 +246,15 @@ test_lazy_prereq () {
test_run_lazy_prereq_ () {
script='
mkdir -p $TRASH_DIRECTORY/prereq-test-dir
-(
+{
cd $TRASH_DIRECTORY/prereq-test-dir '$2'
-)'
+}'
say 3 checking prerequisite: $1
say 3 $script
+ orig_pwd=$(pwd)
test_eval_ $script
eval_ret=$?
+ cd $orig_pwd
rm -rf $TRASH_DIRECTORY/prereq-test-dir
if test $eval_ret = 0; then
say 3 prerequisite $1 ok
--
1.8.0.rc2.304.g9f3ac5c
--
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
[RFC/PATCH 3/4] test-lib: provide lazy TIME_COMMAND prereq
Some test want to use the time command (not the shell builtin) and test for its availability at /usr/bin/time. Provide a lazy prereq TIME_COMMAND which tests for /usr/bin/time and /bin/time. If any is found, set TEST_COMMAND_PATH to the first match. Signed-off-by: Michael J Gruber g...@drmicha.warpmail.net --- Rather than iterating over 2 or more hardcoded paths, one could use test -P time or allow a make variable TIME_COMMAND_PATH whose executability is checked by the prereq. I really don't know what's best. t/test-lib.sh | 7 +++ 1 file changed, 7 insertions(+) diff --git a/t/test-lib.sh b/t/test-lib.sh index 489bc80..7977c15 100644 --- a/t/test-lib.sh +++ b/t/test-lib.sh @@ -738,6 +738,13 @@ test_lazy_prereq UTF8_NFD_TO_NFC ' esac ' +test_lazy_prereq TIME_COMMAND ' + for command in /usr/bin/time /bin/time + do + test -x $command break + done TIME_COMMAND_PATH=$command +' + # When the tests are run as root, permission tests will report that # things are writable when they shouldn't be. test -w / || test_set_prereq SANITY -- 1.8.0.rc2.304.g9f3ac5c -- 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 4/4] t3302,t3419: use the TIME_COMMAND prereq
Use the TIME_COMMAND prereq in both tests so that time from several
paths can be used.
Signed-off-by: Michael J Gruber g...@drmicha.warpmail.net
---
t/t3302-notes-index-expensive.sh | 5 ++---
t/t3419-rebase-patch-id.sh | 7 +++
2 files changed, 5 insertions(+), 7 deletions(-)
diff --git a/t/t3302-notes-index-expensive.sh b/t/t3302-notes-index-expensive.sh
index e35d781..3d9f37e 100755
--- a/t/t3302-notes-index-expensive.sh
+++ b/t/t3302-notes-index-expensive.sh
@@ -9,7 +9,6 @@ test_description='Test commit notes index (expensive!)'
test_set_prereq NOT_EXPENSIVE
test -n $GIT_NOTES_TIMING_TESTS test_set_prereq EXPENSIVE
-test -x /usr/bin/time test_set_prereq USR_BIN_TIME
create_repo () {
number_of_commits=$1
@@ -96,7 +95,7 @@ time_notes () {
for mode in no-notes notes
do
echo $mode
- /usr/bin/time $SHELL_PATH ../time_notes $mode $1
+ $TIME_COMMAND_PATH $SHELL_PATH ../time_notes $mode $1
done
}
@@ -113,7 +112,7 @@ do_tests () {
test_expect_success $pr 'notes work' test_notes $count
- test_expect_success USR_BIN_TIME,$pr 'notes timing with /usr/bin/time'
time_notes 100
+ test_expect_success TIME_COMMAND,$pr 'notes timing with a time command'
time_notes 100
test_expect_success $pr 'teardown / cd ..' 'cd ..'
}
diff --git a/t/t3419-rebase-patch-id.sh b/t/t3419-rebase-patch-id.sh
index 52af547..c7d90a6 100755
--- a/t/t3419-rebase-patch-id.sh
+++ b/t/t3419-rebase-patch-id.sh
@@ -6,7 +6,6 @@ test_description='git rebase - test patch id computation'
test_set_prereq NOT_EXPENSIVE
test -n $GIT_PATCHID_TIMING_TESTS test_set_prereq EXPENSIVE
-test -x /usr/bin/time test_set_prereq USR_BIN_TIME
count()
{
@@ -35,7 +34,7 @@ scramble()
run()
{
echo \$ $@
- /usr/bin/time $@ /dev/null
+ $TIME_COMMAND_PATH $@ /dev/null
}
test_expect_success 'setup' '
@@ -69,7 +68,7 @@ do_tests()
git cherry-pick master /dev/null 21
- test_have_prereq USR_BIN_TIME test_debug
+ test_have_prereq TIME_COMMAND test_debug
run git diff master^\!
@@ -77,7 +76,7 @@ do_tests()
echo 'file binary' .gitattributes
- test_have_prereq USR_BIN_TIME test_debug
+ test_have_prereq TIME_COMMAND test_debug
run git format-patch --stdout master
run git format-patch --stdout --ignore-if-in-upstream master
--
1.8.0.rc2.304.g9f3ac5c
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] Add --unannotate option to git-subtree
On Tue, Oct 9, 2012 at 4:26 PM, James Nylen jny...@gmail.com wrote:
This new option does the reverse of --annotate, which is more useful
when contributing back to a library which is also included in the
repository for a larger project, and perhaps in other situations as
well.
Rather than adding a marker to each commit when splitting out the
commits back to the subproject, --unannotate removes the specified
string (or bash glob pattern) from the beginning of the first line of
the commit message. This enables the following workflow:
- Commit to a library included in a large project, with message:
Library: Make some amazing change
- Use `git-subtree split` to send this change to the library maintainer
- Pass ` --unannotate='Library: ' ` or ` --unannotate='*: ' `
- This will turn the commit message for the library project into:
Make some amazing change
This helps to keep the commit messages meaningful in both the large
project and the library project.
Signed-off-by: James Nylen jny...@gmail.com
---
Has anybody looked at this?
It has been very useful for me.
Let me know if gmail has munged this patch. You can also get at it
like this:
$ git remote add nylen git://github.com/nylen/git.git
$ git fetch nylen
$ git show nylen/subtree-unannotate
---
contrib/subtree/git-subtree.sh | 11 +--
contrib/subtree/git-subtree.txt | 15 +++
2 files changed, 24 insertions(+), 2 deletions(-)
diff --git a/contrib/subtree/git-subtree.sh b/contrib/subtree/git-subtree.sh
index 920c664..8d1ed05 100755
--- a/contrib/subtree/git-subtree.sh
+++ b/contrib/subtree/git-subtree.sh
@@ -21,6 +21,7 @@ P,prefix= the name of the subdir to split out
m,message=use the given message as the commit message for the merge
commit
options for 'split'
annotate= add a prefix to commit message of new commits
+unannotate= remove a prefix from new commit messages (supports bash
globbing)
b,branch= create a new branch from the split subtree
ignore-joins ignore prior --rejoin commits
onto= try connecting new tree to an existing one
@@ -43,6 +44,7 @@ onto=
rejoin=
ignore_joins=
annotate=
+unannotate=
squash=
message=
@@ -80,6 +82,8 @@ while [ $# -gt 0 ]; do
-d) debug=1 ;;
--annotate) annotate=$1; shift ;;
--no-annotate) annotate= ;;
+ --unannotate) unannotate=$1; shift ;;
+ --no-unannotate) unannotate= ;;
-b) branch=$1; shift ;;
-P) prefix=$1; shift ;;
-m) message=$1; shift ;;
@@ -310,8 +314,11 @@ copy_commit()
GIT_COMMITTER_NAME \
GIT_COMMITTER_EMAIL \
GIT_COMMITTER_DATE
- (echo -n $annotate; cat ) |
- git commit-tree $2 $3 # reads the rest of stdin
+ (
+ read FIRST_LINE
+ echo $annotate${FIRST_LINE#$unannotate}
+ cat # reads the rest of stdin
+ ) | git commit-tree $2 $3
) || die Can't copy commit $1
}
diff --git a/contrib/subtree/git-subtree.txt b/contrib/subtree/git-subtree.txt
index 0c44fda..ae420aa 100644
--- a/contrib/subtree/git-subtree.txt
+++ b/contrib/subtree/git-subtree.txt
@@ -198,6 +198,21 @@ OPTIONS FOR split
git subtree tries to make it work anyway, particularly
if you use --rejoin, but it may not always be effective.
+--unannotate=annotation::
+ This option is only valid for the split command.
+
+ When generating synthetic history, try to remove the prefix
+ annotation from each commit message (using bash's strip
+ shortest match from beginning command, which supports
+ globbing). This makes sense if you format library commits
+ like library: Change something or other when you're working
+ in your project's repository, but you want to remove this
+ prefix when pushing back to the library's upstream repository.
+ (In this case --unannotate='*: ' would work well.)
+
+ Like --annotate, you need to use the same annotation
+ whenever you split, or you may run into problems.
+
-b branch::
--branch=branch::
This option is only valid for the split command.
--
1.7.11.3
--
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: feature request
Am Tue, 16 Oct 2012 13:36:04 +0200 schrieb Angelo Borsotti angelo.borso...@gmail.com: Hello, some VCS, e.g. ClearCase, allow to control the fetching of files so as to warn, or disallow parallel changes to the same files. As of today, there is no way to implement the same kind of workflow with git because there are no fetch hooks. Would it be a good idea to provide them? I've actually implemented a 'git lock' command to lock pathnames from concurrent editing for a customer. Normally one would say this is a rather ill and ugly feature for git but there where some reasons to do it anyways (imagine robots crashing into each other on a production line because of bad (developer-)communication). The code is GPL and I can distribute it, but I didn't consider it ready for an open announcement yet. Noteworthy some problems with msys led to some ugly solution (the uniq command doesn't know the -z option there). I hope this might be useful to you. I'd also like to get contributions and fixes if there are any problems I am not aware of. Short into; the doc: http://git.pipapo.org/?p=git;a=blob_plain;f=Documentation/git-lock.txt;h=dcc7a5c34dea657ab5819e8def54e154d5d97219;hb=25ee09cf35daa03a7c2ef10537561a50db2d17b2 the code is available at git://git.pipapo.org/git in the 'ct/git-lock' branch. It is a bit fallen behind the current git version, I will update/merge it sometime next (to keep in par with msysgit, thats what is required here) Christian -Angelo Borsotti -- 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 -- 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 0/5] Fixing problem with deleting symrefs
I see that Rene Scharfe has also worked on the same issue, while I was preparing these patches... On Mon, Oct 15, 2012 at 11:29 AM, Junio C Hamano jch2...@gmail.com wrote: Even though update-ref deferences a symref when it updates one to point at a new object, I personally don't think update-ref -d that derefs makes any sense. I'd rather see it error out when given a symref, with or without --no-deref option. I'm not sure. We have multiple testcases that directly test deleting a ref through a symref (e.g. t1400), so supporting this seems like a concious decision. Erroring out when given a symref will break the following testcases: - t1400 (git update-ref -d) - t3310 t3311 (git notes merge --abort is broken) - t5505 (git remote set-head --delete and renaming a remote is broken) But even if it did, removing a ref pointed by a symref should really remove it, and forgetting to remove a leftover entry in packed-ref has no excuse bug. I'd say what you observed is a double bug. Patch #1 - #2 fixes the 2nd bug (removing through a symref should remove both loose and packed versions of the ref). Patch #3 fixes an associated problem where deleting a symref would remove the dereferenced ref's reflog instead of the symref's reflog. Patch #4 - #5 introduces solution A presented in my previous mail (i.e. 'git branch -d' never dereferences symrefs). Johan Herland (5): t1400-update-ref: Add test verifying bug with symrefs in delete_ref() delete_ref(): Fix deletion of refs through symbolic refs delete_ref(): Remove the correct reflog when deleting symrefs Add tests for using symbolic refs as branch name aliases. branch -d: Fix failure to remove branch aliases (symrefs) builtin/branch.c| 2 +- refs.c | 35 +++--- t/t1400-update-ref.sh | 18 +++ t/t3220-symbolic-ref-as-branch-alias.sh | 53 + 4 files changed, 90 insertions(+), 18 deletions(-) create mode 100755 t/t3220-symbolic-ref-as-branch-alias.sh -- 1.7.12.1.609.g5cd6968 -- 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/5] t1400-update-ref: Add test verifying bug with symrefs in delete_ref()
When deleting a ref through a symref (e.g. using 'git update-ref -d HEAD' to delete refs/heads/master), we currently fail to remove the packed version of that ref. This testcase demonstrates the bug. Signed-off-by: Johan Herland jo...@herland.net --- t/t1400-update-ref.sh | 18 ++ 1 file changed, 18 insertions(+) diff --git a/t/t1400-update-ref.sh b/t/t1400-update-ref.sh index 4fd83a6..f7ec203 100755 --- a/t/t1400-update-ref.sh +++ b/t/t1400-update-ref.sh @@ -74,6 +74,24 @@ test_expect_success delete $m (by HEAD) ' ' rm -f .git/$m +test_expect_success \ + create $m (by HEAD) \ + git update-ref HEAD $A +test $A' = $(cat .git/'$m')' +test_expect_success \ + pack refs \ + git pack-refs --all +test_expect_success \ + move $m (by HEAD) \ + git update-ref HEAD $B $A +test $B' = $(cat .git/'$m')' +test_expect_failure delete $m (by HEAD) should remove both packed and loose $m ' + git update-ref -d HEAD $B + ! grep $m .git/packed-refs + ! test -f .git/$m +' +rm -f .git/$m + cp -f .git/HEAD .git/HEAD.orig test_expect_success delete symref without dereference ' git update-ref --no-deref -d HEAD -- 1.7.12.1.609.g5cd6968 -- 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/5] delete_ref(): Fix deletion of refs through symbolic refs
When deleting a ref through a symref (e.g. using 'git update-ref -d HEAD'
to delete refs/heads/master), the packed version of that ref would not
be deleted, because delete_ref() would pass the symref name (as opposed
to the dereferenced ref name) to repack_without_ref().
This patch revamps the logic in delete_ref() to make it easier to read,
and to clarify how it operates when given a symref.
Signed-off-by: Johan Herland jo...@herland.net
---
refs.c| 33 +
t/t1400-update-ref.sh | 2 +-
2 files changed, 18 insertions(+), 17 deletions(-)
diff --git a/refs.c b/refs.c
index da74a2b..df4fe20 100644
--- a/refs.c
+++ b/refs.c
@@ -1751,34 +1751,35 @@ static int repack_without_ref(const char *refname)
int delete_ref(const char *refname, const unsigned char *sha1, int delopt)
{
struct ref_lock *lock;
- int err, i = 0, ret = 0, flag = 0;
+ int err, delete_symref, ret = 0, flag = 0;
lock = lock_ref_sha1_basic(refname, sha1, 0, flag);
if (!lock)
return 1;
- if (!(flag REF_ISPACKED) || flag REF_ISSYMREF) {
- /* loose */
- const char *path;
- if (!(delopt REF_NODEREF)) {
- i = strlen(lock-lk-filename) - 5; /* .lock */
- lock-lk-filename[i] = 0;
- path = lock-lk-filename;
- } else {
- path = git_path(%s, refname);
- }
- err = unlink_or_warn(path);
+ /* The following variables are at play here:
+* - refname may be a symref (in this case lock-orig_ref_name holds
+*the symref name, and lock-ref_name holds the dereferenced name)
+* - The dereferenced ref name (lock-ref_name) may be a loose ref, a
+*packed ref, or both.
+* - If REF_NODEREF is enabled - and refname is a symref, we should
+*delete the symref; otherwise delete the dereferenced ref.
+*/
+ delete_symref = (flag REF_ISSYMREF delopt REF_NODEREF);
+ refname = delete_symref ? lock-orig_ref_name : lock-ref_name;
+
+ if (!(flag REF_ISPACKED) || delete_symref) {
+ /* loose */
+ err = unlink_or_warn(git_path(%s, refname));
if (err errno != ENOENT)
ret = 1;
-
- if (!(delopt REF_NODEREF))
- lock-lk-filename[i] = '.';
}
/* removing the loose one could have resurrected an earlier
* packed one. Also, if it was not loose we need to repack
* without it.
*/
- ret |= repack_without_ref(refname);
+ if (!delete_symref)
+ ret |= repack_without_ref(refname);
unlink_or_warn(git_path(logs/%s, lock-ref_name));
invalidate_ref_cache(NULL);
diff --git a/t/t1400-update-ref.sh b/t/t1400-update-ref.sh
index f7ec203..e415ee0 100755
--- a/t/t1400-update-ref.sh
+++ b/t/t1400-update-ref.sh
@@ -85,7 +85,7 @@ test_expect_success \
move $m (by HEAD) \
git update-ref HEAD $B $A
test $B' = $(cat .git/'$m')'
-test_expect_failure delete $m (by HEAD) should remove both packed and loose
$m '
+test_expect_success delete $m (by HEAD) should remove both packed and loose
$m '
git update-ref -d HEAD $B
! grep $m .git/packed-refs
! test -f .git/$m
--
1.7.12.1.609.g5cd6968
--
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 4/5] Add tests for using symbolic refs as branch name aliases.
A branch name alias is an alternative name for a branch, that is in most respects equivalent to using the proper branch name. It is implemented as a symbolic ref from the alias to the proper branch name. Currently branch aliases work well up to the point where you try to delete them (with git branch -d), at which point they incorrectly delete the proper branch name instead of the alias. This is reflected in these tests, and will be fixed in a subsequent patch. Signed-off-by: Johan Herland jo...@herland.net --- t/t3220-symbolic-ref-as-branch-alias.sh | 53 + 1 file changed, 53 insertions(+) create mode 100755 t/t3220-symbolic-ref-as-branch-alias.sh diff --git a/t/t3220-symbolic-ref-as-branch-alias.sh b/t/t3220-symbolic-ref-as-branch-alias.sh new file mode 100755 index 000..39f3a33 --- /dev/null +++ b/t/t3220-symbolic-ref-as-branch-alias.sh @@ -0,0 +1,53 @@ +#!/bin/sh + +test_description='Using a symbolic ref as a branch name alias + +This test uses refs/heads/alias as a symbolic ref to refs/heads/master, and +verifies that it works as a branch name alias, namely: + - commits on master are automatically reflected on alias + - creating or deleting alias does not affect master + - the alias is not broken by git gc +' +. ./test-lib.sh + +test_expect_success 'prepare a trivial repository' ' + echo Hello A + git add A + git commit -m Hello + git rev-parse --verify HEAD expect +' + +test_expect_success 'create symref: refs/heads/alias - refs/heads/master' ' + git symbolic-ref refs/heads/alias refs/heads/master + git rev-parse --verify master master + git rev-parse --verify alias alias + test_cmp expect master + test_cmp expect alias +' + +test_expect_success 'git gc does not change alias symref' ' + git gc + git rev-parse --verify master master + git rev-parse --verify alias alias + test_cmp expect master + test_cmp expect alias +' + +test_expect_success 'commits are reflected through alias symref' ' + echo World A + git commit -am A + git rev-parse --verify HEAD expect + git rev-parse --verify master master + git rev-parse --verify alias alias + test_cmp expect master + test_cmp expect alias +' + +test_expect_failure 'branch -d deletes the alias symref' ' + git branch -d alias + git rev-parse --verify master master + test_must_fail git rev-parse --verify alias + test_cmp expect master +' + +test_done -- 1.7.12.1.609.g5cd6968 -- 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 5/5] branch -d: Fix failure to remove branch aliases (symrefs)
With refs/heads/alias set up as a symref to refs/heads/master,
'git branch -d alias' should remove refs/heads/alias and not
refs/heads/master.
Signed-off-by: Johan Herland jo...@herland.net
---
builtin/branch.c| 2 +-
t/t3220-symbolic-ref-as-branch-alias.sh | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/builtin/branch.c b/builtin/branch.c
index ffd2684..31af114 100644
--- a/builtin/branch.c
+++ b/builtin/branch.c
@@ -221,7 +221,7 @@ static int delete_branches(int argc, const char **argv, int
force, int kinds,
continue;
}
- if (delete_ref(name, sha1, 0)) {
+ if (delete_ref(name, sha1, REF_NODEREF)) {
error(remote_branch
? _(Error deleting remote branch '%s')
: _(Error deleting branch '%s'),
diff --git a/t/t3220-symbolic-ref-as-branch-alias.sh
b/t/t3220-symbolic-ref-as-branch-alias.sh
index 39f3a33..8ebec7a 100755
--- a/t/t3220-symbolic-ref-as-branch-alias.sh
+++ b/t/t3220-symbolic-ref-as-branch-alias.sh
@@ -43,7 +43,7 @@ test_expect_success 'commits are reflected through alias
symref' '
test_cmp expect alias
'
-test_expect_failure 'branch -d deletes the alias symref' '
+test_expect_success 'branch -d deletes the alias symref' '
git branch -d alias
git rev-parse --verify master master
test_must_fail git rev-parse --verify alias
--
1.7.12.1.609.g5cd6968
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 3/5] delete_ref(): Remove the correct reflog when deleting symrefs
When deleting a symref (e.g. HEAD), we would incorrectly remove the reflog of the dereferenced ref (e.g. .git/logs/refs/heads/master), insted of the symref's reflog (e.g. .git/logs/HEAD). This patch ensures that we remove the reflog that corresponds to the removed (sym)ref. Signed-off-by: Johan Herland jo...@herland.net --- refs.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/refs.c b/refs.c index df4fe20..f2508bf 100644 --- a/refs.c +++ b/refs.c @@ -1781,7 +1781,7 @@ int delete_ref(const char *refname, const unsigned char *sha1, int delopt) if (!delete_symref) ret |= repack_without_ref(refname); - unlink_or_warn(git_path(logs/%s, lock-ref_name)); + unlink_or_warn(git_path(logs/%s, refname)); invalidate_ref_cache(NULL); unlock_ref(lock); return ret; -- 1.7.12.1.609.g5cd6968 -- 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 12/12] Add git-check-ignore sub-command
Hi again, Firstly thanks very much for your recent work on this series! On Tue, Oct 16, 2012 at 4:08 AM, Nguyen Thai Ngoc Duy pclo...@gmail.com wrote: Adam, do you have time to continue this series? I can help polish it for inclusion, but I don't want to step in your way if you are quietly updating it. I was *intending* to finish it off soon, but I have been really busy with work and other commitments recently, which has prevented this. I don't currently have any unpublished changes which would conflict with your recent work, and I'm at a conference this week, so feel free to carry on polishing if you want. However I will probably have some responses on the discussion about current issues, so it would be good if I was given a chance to catch up on this discussion before the series makes its way to master. Thanks again! 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
Re: [PATCH 12/12] Add git-check-ignore sub-command
On Mon, Oct 15, 2012 at 3:31 PM, Junio C Hamano gits...@pobox.com wrote: Nguyễn Thái Ngọc Duy pclo...@gmail.com writes: +For each pathname given via the command-line or from a file via +`--stdin`, this command will list the first exclude pattern found (if +any) which explicitly excludes or includes that pathname. Note that +within any given exclude file, later patterns take precedence over +earlier ones, so any matching pattern which this command outputs may +not be the one you would immediately expect. The first exclude pattern is very misleading, isn't it? I don't think so, because of the second sentence. For example, with these in $GIT_DIR/info/exclude, I would get: $ cat -n .git/info/exclude 1 *~ 2 Makefile~ $ git check-ignore -v Makefile~ .git/info/exclude:2:Makefile~ Makefile~ which is the correct result (the last one in a single source decides the fate of the path), but it hardly is first one found and the matching pattern in the output would not be something unexpected for the users, either. The reason it is the first one found is because the implementation arranges the loop in such a way that it can stop early when it finds a match---it simply checks matches from the end of the source. But that is not visible to end-users, Correct; that's precisely why I wrote the second sentence which explicitly explains this. and they will find the above description just wrong, no? It's not wrong AFAICS, but suggestions for rewording this more clearly are of course welcome. Maybe s/immediately/intuitively/ ? +OUTPUT +-- + +By default, any of the given pathnames which match an ignore pattern +will be output, one per line. If no pattern matches a given path, +nothing will be output for that path; this means that path will not be +ignored. + +If `--verbose` is specified, the output is a series of lines of the form: + +source COLON linenum COLON pattern HT pathname + +pathname is the path of a file being queried, pattern is the +matching pattern, source is the pattern's source file, and linenum +is the line number of the pattern within that source. If the pattern +contained a `!` prefix or `/` suffix, it will be preserved in the +output. source will be an absolute path when referring to the file +configured by `core.excludesfile`, or relative to the repository root +when referring to `.git/info/exclude` or a per-directory exclude file. + +If `-z` is specified, the output is a series of lines of the form: + Hmph... the remainder of the paragraph seems to have been chopped off. Yes, an earlier review also caught this but I have not had time to fix it yet, sorry :-/ -- 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 3/4] test-lib: provide lazy TIME_COMMAND prereq
From: Michael J Gruber [mailto:g...@drmicha.warpmail.net] Sent: Tuesday, October 16, 2012 1:40 PM To: git@vger.kernel.org Cc: Joachim Schmitz; Junio C Hamano Subject: [RFC/PATCH 3/4] test-lib: provide lazy TIME_COMMAND prereq Some test want to use the time command (not the shell builtin) and test for its availability at /usr/bin/time. Provide a lazy prereq TIME_COMMAND which tests for /usr/bin/time and /bin/time. If any is found, set TEST_COMMAND_PATH to the first match. Signed-off-by: Michael J Gruber g...@drmicha.warpmail.net --- Rather than iterating over 2 or more hardcoded paths, one could use test -P time or allow a make variable TIME_COMMAND_PATH whose test -P time won't work for me: test -P: unary operator expected I do have another one in /usr/local/bin, maybe that could get added too? executability is checked by the prereq. I really don't know what's best. t/test-lib.sh | 7 +++ 1 file changed, 7 insertions(+) diff --git a/t/test-lib.sh b/t/test-lib.sh index 489bc80..7977c15 100644 --- a/t/test-lib.sh +++ b/t/test-lib.sh @@ -738,6 +738,13 @@ test_lazy_prereq UTF8_NFD_TO_NFC ' esac ' +test_lazy_prereq TIME_COMMAND ' + for command in /usr/bin/time /bin/time + do + test -x $command break + done TIME_COMMAND_PATH=$command +' + # When the tests are run as root, permission tests will report that # things are writable when they shouldn't be. test -w / || test_set_prereq SANITY -- 1.8.0.rc2.304.g9f3ac5c -- 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
[RFC/PATCH 3/4v2] test-lib: provide lazy TIME_COMMAND prereq
Some test want to use the time command (not the shell builtin) and test for its availability at /usr/bin/time. Provide a lazy prereq TIME_COMMAND which tests for $TEST_COMMAND_PATH, which can be set from config.mak. It defaults to /usr/bin/time. Signed-off-by: Michael J Gruber g...@drmicha.warpmail.net --- Here's what the make variable version could look like. 1/4 and 4/4 would stay as is, 2/4 could be dropped. t/Makefile| 5 +++-- t/test-lib.sh | 4 2 files changed, 7 insertions(+), 2 deletions(-) diff --git a/t/Makefile b/t/Makefile index 88e289f..52b4039 100644 --- a/t/Makefile +++ b/t/Makefile @@ -13,6 +13,7 @@ TAR ?= $(TAR) RM ?= rm -f PROVE ?= prove DEFAULT_TEST_TARGET ?= test +TIME_COMMAND_PATH ?= /usr/bin/time # Shell quote; SHELL_PATH_SQ = $(subst ','\'',$(SHELL_PATH)) @@ -27,11 +28,11 @@ test: pre-clean $(TEST_LINT) $(MAKE) aggregate-results-and-cleanup prove: pre-clean $(TEST_LINT) - @echo *** prove ***; GIT_CONFIG=.git/config $(PROVE) --exec '$(SHELL_PATH_SQ)' $(GIT_PROVE_OPTS) $(T) :: $(GIT_TEST_OPTS) + @echo *** prove ***; GIT_CONFIG=.git/config TIME_COMMAND_PATH=$(TIME_COMMAND_PATH) $(PROVE) --exec '$(SHELL_PATH_SQ)' $(GIT_PROVE_OPTS) $(T) :: $(GIT_TEST_OPTS) $(MAKE) clean-except-prove-cache $(T): - @echo *** $@ ***; GIT_CONFIG=.git/config '$(SHELL_PATH_SQ)' $@ $(GIT_TEST_OPTS) + @echo *** $@ ***; GIT_CONFIG=.git/config TIME_COMMAND_PATH=$(TIME_COMMAND_PATH) '$(SHELL_PATH_SQ)' $@ $(GIT_TEST_OPTS) pre-clean: $(RM) -r test-results diff --git a/t/test-lib.sh b/t/test-lib.sh index 489bc80..173eb13 100644 --- a/t/test-lib.sh +++ b/t/test-lib.sh @@ -738,6 +738,10 @@ test_lazy_prereq UTF8_NFD_TO_NFC ' esac ' +test_lazy_prereq TIME_COMMAND ' + test -x $TIME_COMMAND_PATH +' + # When the tests are run as root, permission tests will report that # things are writable when they shouldn't be. test -w / || test_set_prereq SANITY -- 1.8.0.rc2.304.g9f3ac5c -- 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 12/12] Add git-check-ignore sub-command
On Tue, Oct 16, 2012 at 9:09 PM, Adam Spiers g...@adamspiers.org wrote: I was *intending* to finish it off soon, but I have been really busy with work and other commitments recently, which has prevented this. I don't currently have any unpublished changes which would conflict with your recent work, and I'm at a conference this week, so feel free to carry on polishing if you want. However I will probably have some responses on the discussion about current issues, so it would be good if I was given a chance to catch up on this discussion before the series makes its way to master. No hurry. And thanks for your contribution. -- Duy -- 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 3/4] test-lib: provide lazy TIME_COMMAND prereq
From: Michael J Gruber [mailto:g...@drmicha.warpmail.net] Sent: Tuesday, October 16, 2012 5:07 PM To: Joachim Schmitz Cc: git@vger.kernel.org; 'Junio C Hamano' Subject: Re: [RFC/PATCH 3/4] test-lib: provide lazy TIME_COMMAND prereq Joachim Schmitz venit, vidit, dixit 16.10.2012 16:13: From: Michael J Gruber [mailto:g...@drmicha.warpmail.net] Sent: Tuesday, October 16, 2012 1:40 PM To: git@vger.kernel.org Cc: Joachim Schmitz; Junio C Hamano Subject: [RFC/PATCH 3/4] test-lib: provide lazy TIME_COMMAND prereq Some test want to use the time command (not the shell builtin) and test for its availability at /usr/bin/time. Provide a lazy prereq TIME_COMMAND which tests for /usr/bin/time and /bin/time. If any is found, set TEST_COMMAND_PATH to the first match. Signed-off-by: Michael J Gruber g...@drmicha.warpmail.net --- Rather than iterating over 2 or more hardcoded paths, one could use test -P time or allow a make variable TIME_COMMAND_PATH whose test -P time won't work for me: test -P: unary operator expected I do have another one in /usr/local/bin, maybe that could get added too? Yikes. If we introduce a make variable TIME_COMMAND_PATH we can even get rid of 2/4 (but have to change Makefile or t/Makefile). I don't mind too much. /usr/bin/time and /bin/time should be enough. -- 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] git-cvsimport: allow author-specific timezones
Jeff King p...@peff.net writes: On Mon, Oct 15, 2012 at 08:50:21PM -0700, Junio C Hamano wrote: Chris Rorvick ch...@rorvick.com writes: It occurred to me that the success of the unit test depends on the host platform's zoneinfo database. I think this problem is inherent with this functionality. Should the unit test attempt to detect support for the used timezones and short circuit if this fails? Not sure exactly how I'd do this, but wondering if it's worth thinking about. Yeah, that did indeed cross my mind. You could say TZ=QST6QDT or something silly like that but that in turn has to assume your tzset() is POSIX.1 compliant anyway. We use EST5 in t0006 (it was originally just EST but IRIX complained). It's been in the test suite for two years without a problem, so it may be simple and safe enough to just use that. Sounds good. As the test vector for the last piece seems to be designed to show that the dst conversion correctly works, we would need to use STD$nDST formats, though. -- 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
Merge option suggestion (dictator, humble)
Hi, I would like to suggest 2 merge options --dictator use all my changes --humble use all their changes These allows to produce a fast-forward commit, without resolving any conflicts. Sometimes, someone did something completely wrong, so the commit needs to be ignored. I cannot tell everyone in the world to run git fetch followed by git reset --hard. Regards, ch3cooli -- 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 when trying to delete symbolic refs
René Scharfe rene.scha...@lsrfire.ath.cx writes:
Am 15.10.2012 10:50, schrieb Johan Herland:
Basically, there is a master branch, and an alias symref to
master. When we naively try to delete the symref with git branch -d
alias, it ends up:
- NOT deleting the alias symref
- DELETING the master loose ref
- NOT deleting the master packed ref
So, from the user perspective, git branch -d alias ends up resetting
master (and alias) back to the last time we happened to run git
gc. Needless to say, this is not quite what we had in mind...
AFAICS, there may be three possible acceptable outcomes when we run
git branch -d alias in the above scenario:
A. The symbolic ref is deleted. This is obviously what we expected...
Below is a patch to do that.
B. The command fails because alias is a symref. This would be
understandable if we don't want to teach branch -d about symrefs.
But then, the error message should ideally explain which command we
should use to remove the symref.
Renaming of symrefs with branch -m is disallowed because it's more
complicated than it looks at first; this was discussed here:
http://thread.gmane.org/gmane.comp.version-control.git/98825/focus=99206
Thanks for a reminder.
I can't imagine why deletion should be prohibited as well, though.
I am not sure if it is a good idea to let update-ref -d work on a
symref, with or without --no-deref. There are cases where you want
to remove the pointer (symbolic-ref -d is there for that), and
there are cases where you want to remove the underlying ref (but of
course you can update-ref -d the underlying ref yourself). If
update-ref -d refused to work on a symref, we do not have to worry
about the confusion which one is removed---the pointer, or the
pointee?
But I wonder why most delete_ref() calls in the code actually don't use
the flag REF_NODEREF, thus deleting symref targets instead of the
symrefs themselves. I may be missing something important here.
I suspect that is primarily because using a symref to represent
anything other than $GIT_DIR/HEAD and $GIT_DIR/refs/remotes/*/HEAD
is outside the normally supported use case and in the may happen to
work territory.
Having said all that, I think your patch is going in the right
direction. If somebody had a symbolic ref in refs/heads/, the
removal should remove it, not the pointee, which may not even
exist. Does branch -d sym work correctly with your patch when
refs/heads/sym is pointing at something that does not exist?
---
builtin/branch.c | 2 +-
t/t3200-branch.sh | 10 ++
2 files changed, 11 insertions(+), 1 deletion(-)
diff --git a/builtin/branch.c b/builtin/branch.c
index ffd2684..31af114 100644
--- a/builtin/branch.c
+++ b/builtin/branch.c
@@ -221,7 +221,7 @@ static int delete_branches(int argc, const char **argv,
int force, int kinds,
continue;
}
- if (delete_ref(name, sha1, 0)) {
+ if (delete_ref(name, sha1, REF_NODEREF)) {
error(remote_branch
? _(Error deleting remote branch '%s')
: _(Error deleting branch '%s'),
diff --git a/t/t3200-branch.sh b/t/t3200-branch.sh
index 79c8d01..4b73406 100755
--- a/t/t3200-branch.sh
+++ b/t/t3200-branch.sh
@@ -262,6 +262,16 @@ test_expect_success 'config information was renamed,
too' \
test $(git config branch.s.dummy) = Hello
test_must_fail git config branch.s/s/dummy
+test_expect_success 'deleting a symref' '
+ git branch target
+ git symbolic-ref refs/heads/symlink refs/heads/target
+
+ git branch -d symlink
+
+ test_path_is_file .git/refs/heads/target
+ test_path_is_missing .git/refs/heads/symlink
+'
+
test_expect_success 'renaming a symref is not allowed' \
'
git symbolic-ref refs/heads/master2 refs/heads/master
--
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 12/12] Add git-check-ignore sub-command
Adam Spiers g...@adamspiers.org writes: On Mon, Oct 15, 2012 at 3:31 PM, Junio C Hamano gits...@pobox.com wrote: Nguyễn Thái Ngọc Duy pclo...@gmail.com writes: +For each pathname given via the command-line or from a file via +`--stdin`, this command will list the first exclude pattern found (if +any) which explicitly excludes or includes that pathname. Note that +within any given exclude file, later patterns take precedence over +earlier ones, so any matching pattern which this command outputs may +not be the one you would immediately expect. The first exclude pattern is very misleading, isn't it? I don't think so, because of the second sentence. For example, with these in $GIT_DIR/info/exclude, I would get: $ cat -n .git/info/exclude 1 *~ 2 Makefile~ $ git check-ignore -v Makefile~ .git/info/exclude:2:Makefile~ Makefile~ which is the correct result (the last one in a single source decides the fate of the path), but it hardly is first one found and the matching pattern in the output would not be something unexpected for the users, either. The reason it is the first one found is because the implementation arranges the loop in such a way that it can stop early when it finds a match---it simply checks matches from the end of the source. But that is not visible to end-users, Correct; that's precisely why I wrote the second sentence which explicitly explains this. and they will find the above description just wrong, no? It's not wrong AFAICS, but suggestions for rewording this more clearly are of course welcome. Maybe s/immediately/intuitively/ ? I think this is sufficient: For each pathname given via the command-line or from a file via `--stdin`, show the pattern from .gitignore (or other input files to the exclude mechanism) that decides if the pathname is excluded. and without Note that at all. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/4] test-lib: allow variable export from lazy prereq tests
Michael J Gruber g...@drmicha.warpmail.net writes:
I don't think this has any adverse side effects, but I'm begging for
another set of eyeballs to have a look. (Test suite passes, of course.)
The lazy prereqs are designed to be used lazily, in any test that he
who wrote lazy-prereq did not anticipate. It is run inside a subshell
to make it absolutely sure that whatever it does (like use of shell
variables, chdir around) will not be able to affect _any_ calling
context that is not anticipated by who writes lazy prerequisite.
Please don't do this.
t/test-lib-functions.sh | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/t/test-lib-functions.sh b/t/test-lib-functions.sh
index 8889ba5..e587902 100644
--- a/t/test-lib-functions.sh
+++ b/t/test-lib-functions.sh
@@ -246,13 +246,15 @@ test_lazy_prereq () {
test_run_lazy_prereq_ () {
script='
mkdir -p $TRASH_DIRECTORY/prereq-test-dir
-(
+{
cd $TRASH_DIRECTORY/prereq-test-dir '$2'
-)'
+}'
say 3 checking prerequisite: $1
say 3 $script
+ orig_pwd=$(pwd)
test_eval_ $script
eval_ret=$?
+ cd $orig_pwd
rm -rf $TRASH_DIRECTORY/prereq-test-dir
if test $eval_ret = 0; then
say 3 prerequisite $1 ok
--
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] status: add --long for default format
This could be useful when the user sets an alias to status --short
and wants to get back the default format temporarily.
Signed-off-by: Nguyễn Thái Ngọc Duy pclo...@gmail.com
---
Documentation/git-status.txt | 3 +++
builtin/commit.c | 2 ++
2 files changed, 5 insertions(+)
diff --git a/Documentation/git-status.txt b/Documentation/git-status.txt
index 67e5f53..9f1ef9a 100644
--- a/Documentation/git-status.txt
+++ b/Documentation/git-status.txt
@@ -38,6 +38,9 @@ OPTIONS
across git versions and regardless of user configuration. See
below for details.
+--long::
+ Give the output in the long-format. This is the default.
+
-u[mode]::
--untracked-files[=mode]::
Show untracked files.
diff --git a/builtin/commit.c b/builtin/commit.c
index a17a5df..5adab33 100644
--- a/builtin/commit.c
+++ b/builtin/commit.c
@@ -1159,6 +1159,8 @@ int cmd_status(int argc, const char **argv, const char
*prefix)
OPT_SET_INT(0, porcelain, status_format,
N_(machine-readable output),
STATUS_FORMAT_PORCELAIN),
+ OPT_SET_INT(0, long, status_format,
+ N_(show status in long format (default)),
STATUS_FORMAT_LONG),
OPT_BOOLEAN('z', null, s.null_termination,
N_(terminate entries with NUL)),
{ OPTION_STRING, 'u', untracked-files, untracked_files_arg,
--
1.8.0.rc2.21.g0695653
--
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 3/4v2] test-lib: provide lazy TIME_COMMAND prereq
Michael J Gruber g...@drmicha.warpmail.net writes: Some test want to use the time command (not the shell builtin) and test for its availability at /usr/bin/time. An alternative way to suppress the builtin meaning is to quote it, like \time. Andreas. -- Andreas Schwab, sch...@linux-m68k.org GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 And now for something completely different. -- 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/4] t3419-rebase-patch-id: heed USR_BIN_TIME prereq
Michael J Gruber g...@drmicha.warpmail.net writes:
t3419 sets the t3419-rebase-patch-id.sh prereq based on the availability
of /usr/bin/time but calls the binary unconditionally (in debug mode).
Make it run the timing only when the prereq is matched.
Signed-off-by: Michael J Gruber g...@drmicha.warpmail.net
I do not think we should ship our tests with too many test_debug in
the first place (it is something you as a developer who are trying
to figure out why your change broke tests can insert into tests).
It might be useful to be able to say sh ./t1234-*.sh -d and see
debug output that somebody else thought that it might be useful, so
I wouldn't say we should remove all existing test_debug, but at the
same time, if a developer finds existing test_debug does not work
for him (either what the debug output gives him is insufficient for
his needs, or what the debug command uses is not available on his
system), he should be willing to update (and capable of doing so) it
to suit his needs. Adding prereq in front of test_debug is simply
an act of insanity.
For this particular one, I think this should suffice. If the shell
does not have time built-in, then timeme can be set to even an
empty string, but that is left as an exercise to the readers.
t/t3419-rebase-patch-id.sh | 8 ++--
1 file changed, 6 insertions(+), 2 deletions(-)
diff --git i/t/t3419-rebase-patch-id.sh w/t/t3419-rebase-patch-id.sh
index e70ac10..bf2736a 100755
--- i/t/t3419-rebase-patch-id.sh
+++ w/t/t3419-rebase-patch-id.sh
@@ -6,7 +6,11 @@ test_description='git rebase - test patch id computation'
test_set_prereq NOT_EXPENSIVE
test -n $GIT_PATCHID_TIMING_TESTS test_set_prereq EXPENSIVE
-test -x /usr/bin/time test_set_prereq USR_BIN_TIME
+if test -x /usr/bin/time
+ timeme=/usr/bin/time
+else
+ timeme=time
+fi
count()
{
@@ -35,7 +39,7 @@ scramble()
run()
{
echo \$ $@
- /usr/bin/time $@ /dev/null
+ $timeme $@ /dev/null
}
test_expect_success 'setup' '
--
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 3/4] test-lib: provide lazy TIME_COMMAND prereq
Michael J Gruber g...@drmicha.warpmail.net writes: Some test want to use the time command (not the shell builtin) and test for its availability at /usr/bin/time. As we have t/perf these days, I suspect that we should aim to remove these uses of /usr/bin/time in the main testsuite instead. The one in 3419 was run this command, and while at it run it under 'time' but it is only inside test_debug and I do not think it gives anything more than curiosity values. The one in 3302 is used to compare two runs (one without and one with notes tree), so it has a little more value than just curiosity, but its value inside the main test suite is still highly dubious. It does not have any under this value the test passes criteria. When the performance of having to look up notes tree really matters, it shouldn't be done inside the main test suite that is designed to be runnable unattended and the only check the humans do is to see their ok/fail output. In short, what you would get out of /usr/bin/time simply is not a good match inside the context of these unit tests. -- 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 0/5] Fixing problem with deleting symrefs
Johan Herland jo...@herland.net writes: I see that Rene Scharfe has also worked on the same issue, while I was preparing these patches... On Mon, Oct 15, 2012 at 11:29 AM, Junio C Hamano jch2...@gmail.com wrote: Even though update-ref deferences a symref when it updates one to point at a new object, I personally don't think update-ref -d that derefs makes any sense. I'd rather see it error out when given a symref, with or without --no-deref option. I'm not sure. We have multiple testcases that directly test deleting a ref through a symref (e.g. t1400), so supporting this seems like a concious decision. Erroring out when given a symref will break the following testcases: - t1400 (git update-ref -d) - t3310 t3311 (git notes merge --abort is broken) - t5505 (git remote set-head --delete and renaming a remote is broken) Concious does not necessarily mean Sane, though. But this is water under the bridge. Too many people must have started relying on this crazy feature since mid 2008, and removing it would break them. - update-ref -d --no-deref SYMREF, even though it is a synonym for symbolic-ref -d SYMREF, makes sense. Removing it would only buy us breakage. - update-ref -d --no-deref SYMREF OLDSHA1 does not make *ANY* sense as a request, but again it would not hurt to keep it. - update-ref -d --deref SYMREF [OLDSHA1] is questionable. What is the use case? What is the next step after doing such an operation, now you have SYMREF that is dangling? But even if it did, removing a ref pointed by a symref should really remove it, and forgetting to remove a leftover entry in packed-ref has no excuse bug. I'd say what you observed is a double bug. Patch #1 - #2 fixes the 2nd bug (removing through a symref should remove both loose and packed versions of the ref). OK. That is surely needed. -- 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: push race
On Tue, Oct 16, 2012 at 05:45:12PM +0700, Nguyen Thai Ngoc Duy wrote: On Tue, Oct 16, 2012 at 12:37 PM, Jeff King p...@peff.net wrote: I suspect a site that is heavy on alternates is invoking the index-pack code path more frequently than necessary (e.g., history gets pushed to one forked repo, then when it goes to the next one, we may not share the ref that tells the client we already have the object and receive it a second time). I suppose we could do the way unpack-objects does: prefer present objects and drop the new identical ones, no memcmp. Objects that are not bases, or are ref-delta bases, can be safely dropped. ofs-delta bases may lead to rewriting the pack. Do-able but not sure it's worth the effort. Yeah, I think that complexity is why we don't do it currently. We are pretty alternates-heavy at GitHub, and we have not noticed a performance impact. So I think it is probably not worth worrying about. -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 v3 0/8] Create single PDF for all HTML files
Hi, this is v3 of my patch series for creating a single PDF for all git documentation files. There are only 2 changes since v2 (thanks to Junio for pointing me at these issues) : - The over-long lines in git-bisect-lk2009.txt where shortened by abbreviating the SHA1s. - Pretty-printing the shell script in update-hook-example.txt was fixed. To sum up, this patch series provides the following new features: - Make target html now creates HTML for ALL files in ./Documentation/howto and ./Documentation/technical - New make target fullpdf first creates HTML for all files in ./Documentation/RelNotes and then collates all HTML files in ./Documentation and its subdirs (except user-manual.html) in one single PDF file. This approach is of course not an optimal one but by using wkhtmltopdf it could be carried out easily. A more perfect approach would be to rework/redesign the whole doc tool chain and so perhaps arrive at additional output formats like e.g. epub. But this is the topic of a patch series yet to come ... A current version of git-doc.pdf is available in https://github.com/tacker66/git-docpdf.git. --- Thomas -- 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 v3 1/8] Split over-long synopsis in git-fetch-pack.txt into several lines
Signed-off-by: Thomas Ackermann th.ac...@arcor.de --- Documentation/git-fetch-pack.txt | 5 - 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/Documentation/git-fetch-pack.txt b/Documentation/git-fetch-pack.txt index 474fa30..12cd8a2 100644 --- a/Documentation/git-fetch-pack.txt +++ b/Documentation/git-fetch-pack.txt @@ -9,7 +9,10 @@ git-fetch-pack - Receive missing objects from another repository SYNOPSIS [verse] -'git fetch-pack' [--all] [--quiet|-q] [--keep|-k] [--thin] [--include-tag] [--upload-pack=git-upload-pack] [--depth=n] [--no-progress] [-v] [host:]directory [refs...] +'git fetch-pack' [--all] [--quiet|-q] [--keep|-k] [--thin] [--include-tag] + [--upload-pack=git-upload-pack] + [--depth=n] [--no-progress] + [-v] [host:]directory [refs...] DESCRIPTION --- -- 1.7.11.msysgit.1 --- Thomas -- 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: push race
Nguyen Thai Ngoc Duy pclo...@gmail.com writes: On Tue, Oct 16, 2012 at 12:37 PM, Jeff King p...@peff.net wrote: I suspect a site that is heavy on alternates is invoking the index-pack code path more frequently than necessary (e.g., history gets pushed to one forked repo, then when it goes to the next one, we may not share the ref that tells the client we already have the object and receive it a second time). I suppose we could do the way unpack-objects does: prefer present objects and drop the new identical ones, no memcmp. Objects that are not bases, or are ref-delta bases, can be safely dropped. ofs-delta bases may lead to rewriting the pack. Do-able but not sure it's worth the effort. Until you read all the incoming pack data, you won't know what objects are used as bases for others, so unless you are keeping everything in core, you would have to spool the incoming data to a file and then rewrite the final pack file to drop these can be safely dropped objects, with or without offset delta encoding. -- 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 v3 2/8] Shorten two over-long lines in git-bisect-lk2009.txt by abbreviating some sha1
Signed-off-by: Thomas Ackermann th.ac...@arcor.de --- Documentation/git-bisect-lk2009.txt | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/Documentation/git-bisect-lk2009.txt b/Documentation/git-bisect-lk2009.txt index 8a2ba37..ec4497e 100644 --- a/Documentation/git-bisect-lk2009.txt +++ b/Documentation/git-bisect-lk2009.txt @@ -257,7 +257,7 @@ Date: Sat May 3 11:59:44 2008 -0700 Linux 2.6.26-rc1 -:100644 100644 5cf8258195331a4dbdddff08b8d68642638eea57 4492984efc09ab72ff6219a7bc21fb6a957c4cd5 M Makefile +:100644 100644 5cf82581... 4492984e... M Makefile - At this point we can see what the commit does, check it out (if it's @@ -331,7 +331,7 @@ Date: Sat May 3 11:59:44 2008 -0700 Linux 2.6.26-rc1 -:100644 100644 5cf8258195331a4dbdddff08b8d68642638eea57 4492984efc09ab72ff6219a7bc21fb6a957c4cd5 M Makefile +:100644 100644 5cf82581... 4492984e... M Makefile bisect run success - -- 1.7.11.msysgit.1 --- Thomas -- 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] status: add --long for default format
On Tue, Oct 16, 2012 at 11:22:49PM +0700, Nguyen Thai Ngoc Duy wrote:
This could be useful when the user sets an alias to status --short
and wants to get back the default format temporarily.
Makes sense, but...
diff --git a/builtin/commit.c b/builtin/commit.c
index a17a5df..5adab33 100644
--- a/builtin/commit.c
+++ b/builtin/commit.c
@@ -1159,6 +1159,8 @@ int cmd_status(int argc, const char **argv, const char
*prefix)
OPT_SET_INT(0, porcelain, status_format,
N_(machine-readable output),
STATUS_FORMAT_PORCELAIN),
+ OPT_SET_INT(0, long, status_format,
+ N_(show status in long format (default)),
STATUS_FORMAT_LONG),
OPT_BOOLEAN('z', null, s.null_termination,
N_(terminate entries with NUL)),
{ OPTION_STRING, 'u', untracked-files, untracked_files_arg,
I'm pretty sure we use STATUS_FORMAT_LONG elsewhere as a synonym for
the user has not set anything.
Ah, here it is:
$ git grep -nA1 '== STATUS_FORMAT_LONG'
1073: if (s-null_termination status_format == STATUS_FORMAT_LONG)
1074- status_format = STATUS_FORMAT_PORCELAIN;
--
1201: if (s.null_termination status_format == STATUS_FORMAT_LONG)
1202- status_format = STATUS_FORMAT_PORCELAIN;
I think you would want something like this. I had originally intended to
make it a refactoring patch that would come before yours, but some of
the cleanups are tied to actually adding --long. So I think you would
want to squash it together with your patch and combine the commit
messages.
-- 8 --
Subject: [PATCH] status: refactor output format to represent default
When deciding which output format to use, we default an
internal enum to STATUS_FORMAT_LONG and modify it if
--porcelain or --short is given. If this enum is set to
LONG, then we know the user has not specified any format,
and we can kick in default behaviors. This works because
there is no --long which they could use to explicitly
specify LONG.
Let's expand the enum to have an explicit STATUS_FORMAT_NONE,
in preparation for adding --long. Then we can distinguish
between LONG and NONE when setting other defaults. There are
two such cases:
1. The user has asked for NUL termination. With NONE, we
currently default to turning on the porcelain mode.
With an explicit --long, we would in theory use NUL
termination with the long mode, but it does not support
it. So we can just complain and die.
2. When an output format is given to git commit, we
default to --dry-run. This behavior would now kick in
when --long is given, too.
Signed-off-by: Jeff King p...@peff.net
---
builtin/commit.c | 23 +--
1 file changed, 17 insertions(+), 6 deletions(-)
diff --git a/builtin/commit.c b/builtin/commit.c
index 00ac35b..ec299f4 100644
--- a/builtin/commit.c
+++ b/builtin/commit.c
@@ -112,10 +112,11 @@ static enum {
static struct strbuf message = STRBUF_INIT;
static enum {
+ STATUS_FORMAT_NONE = 0,
STATUS_FORMAT_LONG,
STATUS_FORMAT_SHORT,
STATUS_FORMAT_PORCELAIN
-} status_format = STATUS_FORMAT_LONG;
+} status_format;
static int mention_abandoned_message;
static void maybe_mention_abandoned_message(void)
@@ -464,6 +465,7 @@ static int run_status(FILE *fp, const char *index_file,
const char *prefix, int
case STATUS_FORMAT_PORCELAIN:
wt_porcelain_print(s);
break;
+ case STATUS_FORMAT_NONE:
case STATUS_FORMAT_LONG:
wt_status_print(s);
break;
@@ -1070,9 +1072,13 @@ static int parse_and_validate_options(int argc, const
char *argv[],
if (all argc 0)
die(_(Paths with -a does not make sense.));
- if (s-null_termination status_format == STATUS_FORMAT_LONG)
- status_format = STATUS_FORMAT_PORCELAIN;
- if (status_format != STATUS_FORMAT_LONG)
+ if (s-null_termination) {
+ if (status_format == STATUS_FORMAT_NONE)
+ status_format = STATUS_FORMAT_PORCELAIN;
+ else if (status_format == STATUS_FORMAT_LONG)
+ die(--long and -z are incompatible);
+ }
+ if (status_format != STATUS_FORMAT_NONE)
dry_run = 1;
return argc;
@@ -1198,8 +1204,12 @@ int cmd_status(int argc, const char **argv, const char
*prefix)
builtin_status_usage, 0);
finalize_colopts(s.colopts, -1);
- if (s.null_termination status_format == STATUS_FORMAT_LONG)
- status_format = STATUS_FORMAT_PORCELAIN;
+ if (s.null_termination) {
+ if (status_format == STATUS_FORMAT_NONE)
+ status_format = STATUS_FORMAT_PORCELAIN;
+ else if (status_format == STATUS_FORMAT_LONG)
+ die(--long and -z are incompatible);
+
Re: Merge option suggestion (dictator, humble)
乙酸鋰 ch3co...@gmail.com writes: I would like to suggest 2 merge options --dictator use all my changes --humble use all their changes These allows to produce a fast-forward commit, without resolving any conflicts. Sometimes, someone did something completely wrong, so the commit needs to be ignored. I cannot tell everyone in the world to run git fetch followed by git reset --hard. Then you cannot tell them to use pull --humble either, can you? Not seeing any merit in the proposal (yet). -- 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: push race
On Tue, Oct 16, 2012 at 10:21:02AM -0700, Junio C Hamano wrote: I suppose we could do the way unpack-objects does: prefer present objects and drop the new identical ones, no memcmp. Objects that are not bases, or are ref-delta bases, can be safely dropped. ofs-delta bases may lead to rewriting the pack. Do-able but not sure it's worth the effort. Until you read all the incoming pack data, you won't know what objects are used as bases for others, so unless you are keeping everything in core, you would have to spool the incoming data to a file and then rewrite the final pack file to drop these can be safely dropped objects, with or without offset delta encoding. By definition, you know that you have another copy of these objects (that is why you are dropping them). So you could treat later delta references to them the same as thin-pack references, and re-add your existing on-disk copy of the object to the end of the pack. But still...the complexity is ugly, and we do not even have a measured problem in the real world. This is not worth thinking about. :) -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: feature request
Hi Andrew, one nice thing is to warn a developer that wants to modify a source file, that there is somebody else changing it beforehand. It is nicer than discovering that at push time. Take into account that there are changes in files that may be incompatible to each other, or that can be amenable to be automatically merged producing wrong results. So, knowing it could help. -Angelo -- 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 v3 8/8] Wire everything into Makefile and Documentation/Makefile
- target html creates html for all files in Documentation/howto and Documentation/technical - new target relnoteshtml creates html for all release notes - new target fullpdf creates git-doc.pdf and uses targets html, relnoteshtml and pdf - html does not use relnoteshtml Signed-off-by: Thomas Ackermann th.ac...@arcor.de --- Documentation/Makefile | 43 +-- Makefile | 9 + 2 files changed, 50 insertions(+), 2 deletions(-) diff --git a/Documentation/Makefile b/Documentation/Makefile index 267dfe1..6710325 100644 --- a/Documentation/Makefile +++ b/Documentation/Makefile @@ -15,6 +15,9 @@ MAN_HTML=$(patsubst %.txt,%.html,$(MAN_TXT)) DOC_HTML=$(MAN_HTML) +RELNOTES_TXT = $(wildcard RelNotes/*.txt) +RELNOTES_HTML= $(patsubst %.txt,%.html,$(RELNOTES_TXT)) + ARTICLES = howto-index ARTICLES += everyday ARTICLES += git-tools @@ -24,8 +27,30 @@ SP_ARTICLES = user-manual SP_ARTICLES += howto/revert-branch-rebase SP_ARTICLES += howto/using-merge-subtree SP_ARTICLES += howto/using-signed-tag-in-pull-request +SP_ARTICLES += howto/use-git-daemon +SP_ARTICLES += howto/update-hook-example +SP_ARTICLES += howto/setup-git-server-over-http +SP_ARTICLES += howto/separating-topic-branches +SP_ARTICLES += howto/revert-a-faulty-merge +SP_ARTICLES += howto/recover-corrupted-blob-object +SP_ARTICLES += howto/rebuild-from-update-hook +SP_ARTICLES += howto/rebuild-from-update-hook +SP_ARTICLES += howto/rebase-from-internal-branch +SP_ARTICLES += howto/maintain-git API_DOCS = $(patsubst %.txt,%,$(filter-out technical/api-index-skel.txt technical/api-index.txt, $(wildcard technical/api-*.txt))) SP_ARTICLES += $(API_DOCS) + +TECH_DOCS += technical/index-format +TECH_DOCS += technical/pack-format +TECH_DOCS += technical/pack-heuristics +TECH_DOCS += technical/pack-protocol +TECH_DOCS += technical/protocol-capabilities +TECH_DOCS += technical/protocol-common +TECH_DOCS += technical/racy-git +TECH_DOCS += technical/send-pack-pipeline +TECH_DOCS += technical/shallow +TECH_DOCS += technical/trivial-merge +SP_ARTICLES += $(TECH_DOCS) SP_ARTICLES += technical/api-index DOC_HTML += $(patsubst %,%.html,$(ARTICLES) $(SP_ARTICLES)) @@ -156,6 +181,8 @@ all: html man html: $(DOC_HTML) +relnoteshtml: $(RELNOTES_HTML) + $(DOC_HTML) $(DOC_MAN1) $(DOC_MAN5) $(DOC_MAN7): asciidoc.conf man: man1 man5 man7 @@ -167,6 +194,9 @@ info: git.info gitman.info pdf: user-manual.pdf +fullpdf: pdf relnoteshtml html + ./makedocpdf.sh + install: install-man install-man: man @@ -191,6 +221,10 @@ install-pdf: pdf $(INSTALL) -d -m 755 $(DESTDIR)$(pdfdir) $(INSTALL) -m 644 user-manual.pdf $(DESTDIR)$(pdfdir) +install-fullpdf: fullpdf install-pdf + $(INSTALL) -d -m 755 $(DESTDIR)$(pdfdir) + $(INSTALL) -m 644 git-doc.pdf $(DESTDIR)$(pdfdir) + install-html: html '$(SHELL_PATH_SQ)' ./install-webdoc.sh $(DESTDIR)$(htmldir) @@ -230,8 +264,10 @@ clean: $(RM) *.xml *.xml+ *.html *.html+ *.1 *.5 *.7 $(RM) *.texi *.texi+ *.texi++ git.info gitman.info $(RM) *.pdf + $(RM) docfiles.txt + $(RM) RelNotes/*.html $(RM) howto-index.txt howto/*.html doc.dep - $(RM) technical/api-*.html technical/api-index.txt + $(RM) technical/*.html technical/api-index.txt $(RM) $(cmds_txt) *.made $(RM) manpage-base-url.xsl @@ -241,6 +277,9 @@ $(MAN_HTML): %.html : %.txt $(ASCIIDOC_EXTRA) -agit_version=$(GIT_VERSION) -o $@+ $ \ mv $@+ $@ +$(RELNOTES_HTML): %.html : %.txt + $(QUIET_ASCIIDOC)$(ASCIIDOC) $(ASCIIDOC_EXTRA) -b xhtml11 $*.txt + manpage-base-url.xsl: manpage-base-url.xsl.in sed s|@@MAN_BASE_URL@@|$(MAN_BASE_URL)| $ $@ @@ -264,7 +303,7 @@ technical/api-index.txt: technical/api-index-skel.txt \ $(QUIET_GEN)cd technical '$(SHELL_PATH_SQ)' ./api-index.sh technical/%.html: ASCIIDOC_EXTRA += -a git-relative-html-prefix=../ -$(patsubst %,%.html,$(API_DOCS) technical/api-index): %.html : %.txt +$(patsubst %,%.html,$(API_DOCS) technical/api-index $(TECH_DOCS)): %.html : %.txt $(QUIET_ASCIIDOC)$(ASCIIDOC) -b xhtml11 -f asciidoc.conf \ $(ASCIIDOC_EXTRA) -agit_version=$(GIT_VERSION) $*.txt diff --git a/Makefile b/Makefile index f69979e..075e98c 100644 --- a/Makefile +++ b/Makefile @@ -2479,12 +2479,18 @@ man: html: $(MAKE) -C Documentation html +relnoteshtml: + $(MAKE) -C Documentation relnoteshtml + info: $(MAKE) -C Documentation info pdf: $(MAKE) -C Documentation pdf +fullpdf: + $(MAKE) -C Documentation fullpdf + XGETTEXT_FLAGS = \ --force-po \ --add-comments \ @@ -2797,6 +2803,9 @@ install-info: install-pdf: $(MAKE) -C Documentation install-pdf +install-fullpdf: + $(MAKE) -C Documentation install-fullpdf + quick-install-doc: $(MAKE) -C Documentation quick-install -- 1.7.11.msysgit.1 --- Thomas -- To unsubscribe
Re: When Will We See Collisions for SHA-1? (An interesting analysis by Bruce Schneier)
On Tue, Oct 16, 2012 at 01:34:41PM +0200, René Scharfe wrote:
FWIW, I couldn't measure a performance difference for git log with and
without the following patch, which catches commits created with your
hash collision trick, but might be too strict:
diff --git a/commit.c b/commit.c
index 213bc98..4cd1e83 100644
--- a/commit.c
+++ b/commit.c
@@ -262,6 +262,12 @@ int parse_commit_buffer(struct commit *item, const void
*buffer, unsigned long s
if (item-object.parsed)
return 0;
item-object.parsed = 1;
+
+ if (memchr(buffer, '\0', size)) {
+ return error(bogus commit contains a NUL character: %s,
+ sha1_to_hex(item-object.sha1));
+ }
+
Hmm. Yeah, that should be relatively inexpensive, since we are about to
read through most of the bytes anyway (we probably have just zlib
inflated them all, so they would even be in cache). It might make more
of a difference for a raw traversal that is not even going to look at
below the header, like rev-list or merge-base. But I couldn't measure a
difference doing git rev-list HEAD /dev/null in either git.git or
linux-2.6.git.
So maybe it is worth doing preemptively. Even without security concerns,
we would be truncating the commit message, so it is probably better to
let the user know (a warning is probably more appropriate, though, just
in case somebody does have embedded NULs for historical reason).
-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: When Will We See Collisions for SHA-1? (An interesting analysis by Bruce Schneier)
I seem to recall that there was at least some discussion at one point about adding some extra fields to the commit object in a backwards compatible way by adding it after the trailing NUL. We didn't end up doing it, but I could see it being a useful thing nonetheless (for example, we could potentially put the backup SHA-2/SHA-3 pointer there). What if we explicitly allow a length plus SHA-2/3 hash of the commit plus the fields after the SHA-2/3 hash as an extension? This would allow a secure way of adding an extension, including perhaps adding backup SHA-2/3 parent pointers, which is something that would be useful to do from a security perspective if we really are worried about a catastrophic hash failure. The one reason why we *might* want to use SHA-3, BTW, is that it is a radically different design from SHA-1 and SHA-2. And if there is a crypto hash failure which is bad enough that the security of git would be affected, there's a chance that the same attack could significantly affect SHA-2 as well. The fact that SHA-3 is fundamentally different from a cryptographic design perspective means that an attack that impacts SHA-1/SHA-2 will not likely impact SHA-3, and vice versa. - Ted -- 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 3/4v2] test-lib: provide lazy TIME_COMMAND prereq
Hi Andreas. I hope you don't mind my nitpickiness, but ... On 10/16/2012 06:28 PM, Andreas Schwab wrote: Michael J Gruber g...@drmicha.warpmail.net writes: Some test want to use the time command (not the shell builtin) and test for its availability at /usr/bin/time. An alternative way to suppress the builtin meaning is to quote it, like \time. ... to be 100% precise, this quoting trick works because 'time' is a shell keyword, rather than a builtin: $ type time time is a shell keyword Regards, Stefano -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] status: add --long for default format
On Tue, Oct 16, 2012 at 01:22:04PM -0400, Jeff King wrote: 2. When an output format is given to git commit, we default to --dry-run. This behavior would now kick in when --long is given, too. I forgot to mention in my previous message: your patch should probably add --long to git-commit for consistency. -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: When Will We See Collisions for SHA-1? (An interesting analysis by Bruce Schneier)
On Tue, 16 Oct 2012, Jeff King wrote: On Tue, Oct 16, 2012 at 01:58:06PM -0400, Theodore Ts'o wrote: I seem to recall that there was at least some discussion at one point about adding some extra fields to the commit object in a backwards compatible way by adding it after the trailing NUL. We didn't end up doing it, but I could see it being a useful thing nonetheless (for example, we could potentially put the backup SHA-2/SHA-3 pointer there). I don't see much point in it. If we want to add new backup pointers to commit objects, it is very easy to do so by adding new header fields. A much bigger problem is the other places we reference sha1s. The obvious place is trees, which have no room for backup pointers (either in headers, or with a NUL trick). But it also means that any time you have a sha1 that you arrive at in some other way than traversal from a signature, you are vulnerable to attack. E.g., if I record a sha1 in an external system, today I can be sure that when I fetch the object for that sha1, it is valid (or I can check that it is valid by hashing it). With sha1 collisions, I am vulnerable to attack. If you have two hashes of the same contents (SHA1 and SHA3) and they both agree that the file has not been tampered with, you should still be in good shape just using the SHA1 as a reference. David Lang -- 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: When Will We See Collisions for SHA-1? (An interesting analysis by Bruce Schneier)
On Tue, Oct 16, 2012 at 11:32:38AM -0700, da...@lang.hm wrote: I don't see much point in it. If we want to add new backup pointers to commit objects, it is very easy to do so by adding new header fields. A much bigger problem is the other places we reference sha1s. The obvious place is trees, which have no room for backup pointers (either in headers, or with a NUL trick). But it also means that any time you have a sha1 that you arrive at in some other way than traversal from a signature, you are vulnerable to attack. E.g., if I record a sha1 in an external system, today I can be sure that when I fetch the object for that sha1, it is valid (or I can check that it is valid by hashing it). With sha1 collisions, I am vulnerable to attack. If you have two hashes of the same contents (SHA1 and SHA3) and they both agree that the file has not been tampered with, you should still be in good shape just using the SHA1 as a reference. But tampering is only part of it. We care about a chain of authenticity from some known point (either a gpg signature, or a sha1 that you know to be good because you recorded it from a trusted source). The references between objects are the links in that chain. Whether an internal hash would help you would depend on the exact details of the collision attack. Let's imagine you have a signed tag that points to commit sha1 X. The pointed-to commit contains a trailer that says btw, my sha-3 is Y. An attacker doing a brute-force birthday attack would do: 1. Generate some potential contents for the object (generally, take a good and malicious version of the object, and add some random bits at the end). 2. Generate the sha-3 trailer for each object and tack it on. 3. Generate the sha1 for object+trailer. 4. Remember the sha1 and contents of each object. If the sha1 matches something we generated before, we have a collision. Otherwise, goto step 1. So each object, good or malicious, remains consistent with respect to the sha-3 hash. We know it has not been tampered with since its generation, but do we not know if it is the same object that the tagger originally referenced. We had to compute the sha-3 as part of generating the object, but it was not actually part of the collision attack; it just makes it a little more expensive to compute each iteration. We still have to do only 2^80 iterations. But nobody is worried about this 2^80 brute force attack. The problem with sha-1 (as I understand it) is that there are tricks you can do when making the modifications in step 1 that will make the sha1 from step 3 more likely to find a collision with something you've already generated. The modifications you make in step 1 will affect the sha-3 hash in step 2, which ultimately impacts the sha1 hash in step 3. Whether and how that affects your attack would depend on the exact details of the tricks. I don't keep up on the state of the art in sha-1 cracking, so maybe the techniques happen in such a way that the extra hash would be a significant impediment. Even if it is sufficient to stop current (or whatever is current when sha1 is broken enough to worry about) attacks, it is a weak point for future attacks. -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 00/20] git-cvsserver: add support for cvs -r refs
Matthew Ogilvie mmogilvi_...@miniinfo.net writes: I don't actually intend to use any of this myself. I started it a few years ago under the theory that a more accurate emulation of CVS would make it easier to convince the team at $DAYJOB to switch to git, but we eventually switched without using git-cvsserver at all. Nice ;-) ... That said, perhaps some of the trivial cleanup patches could go in now? Not now now during the pre-release freeze, but the earlier patches (up to #11, arguably together with #12 and #13) do look like nice clean-ups to have. Thanks. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: error: git-fast-import died of signal 11
I'm using Git 1.8.0-rc2 and cvs2git version 2.5.0-dev (trunk). The repository is almost 20 years old and should consist of mostly smallish plain text files. We've been tagging every commit, in addition to for releases and development branches, so there's a lot of tags and branches. I didn't see the memory usage of the process before exiting but after ~3.5 hours in a subsequent run it seems to be using about 8.5GB of virtual memory with a resident size of only .5GB, which should have easily fit on the 512GB machine that I was using. I'm trying on a 1TB machine now but it doesn't look like it'll make a difference. There is no ram disk and I have exclusive access to the machine so only from the OS, which is trivial. The only significant limit from my environment would be on the stack: [umoszkow@mawhp5 ~] limit cputime unlimited filesize unlimited datasize unlimited stacksize8000 kbytes coredumpsize 0 kbytes memoryuseunlimited vmemoryuse unlimited descriptors 1024 memorylocked 32 kbytes maxproc 8388608 Would that result in an mmap error though? I'll try with unlimited stacksize and descriptors anyway. I don't think modifying the original repository or a clone of it is possible at this point but breaking up the import into a few steps may be - will try that next if this fails. On Tue, Oct 16, 2012 at 2:18 AM, Michael Haggerty mhag...@alum.mit.edu wrote: On 10/15/2012 05:53 PM, Uri Moszkowicz wrote: I'm trying to convert a CVS repository to Git using cvs2git. I was able to generate the dump file without problem but am unable to get Git to fast-import it. The dump file is 328GB and I ran git fast-import on a machine with 512GB of RAM. fatal: Out of memory? mmap failed: Cannot allocate memory fast-import: dumping crash report to fast_import_crash_18192 error: git-fast-import died of signal 11 How can I import the repository? What versions of git and of cvs2git are you using? If not the current versions, please try with the current versions. What is the nature of your repository (i.e., why is it so big)? Does it consist of extremely large files? A very deep history? Extremely many branches/tags? Extremely many files? Did you check whether the RAM usage of git-fast-import process was growing gradually to fill RAM while it was running vs. whether the usage seemed reasonable until it suddenly crashed? There are a few obvious possibilities: 0. There is some reason that too little of your computer's RAM is available to git-fast-import (e.g., ulimit, other processes running at the same time, much RAM being used as a ramdisk, etc). 1. Your import is simply too big for git-fast-import to hold in memory the accumulated things that it has to remember. I'm not familiar with the internals of git-fast-import, but I believe that the main thing that it has to keep in RAM is the list of marks (references to git objects that can be referred to later in the import). From your crash file, it looks like there were about 350k marks loaded at the time of the crash. Supposing each mark is about 100 bytes, this would only amount to 35 Mb, which should not be a problem (*if* my assumptions are correct). 2. Your import contains a gigantic object which individually is so big that it overflows some component of the import. (I don't know whether large objects are handled streamily; they might be read into memory at some point.) But since your computer had so much RAM this is hardly imaginable. 3. git-fast-import has a memory leak and the accumulated memory leakage is exhausting your RAM. 4. git-fast-import has some other kind of a bug. 5. The contents of the dumpfile are corrupt in a way that is triggering the problem. This could either be invalid input (e.g., an object that is reported to be quaggabytes large), or some invalid input that triggers a bug in git-fast-import. If (1), then you either need a bigger machine or git-fast-import needs architectural changes. If (2), then you either need a bigger machine or git-fast-import and/or git needs architectural changes. If (3), then it would be good to get more information about the problem so that the leak can be fixed. If this is the case, it might be possible to work around the problem by splitting the dumpfile into several parts and loading them one after the other (outputting the marks from one run and loading them into the next). If (4) or (5), then it would be helpful to narrow down the problem. It might be possible to do so by following the instructions in the cvs2svn FAQ [1] for systematically shrinking a test case to smaller size using destroy_repository.py and shrink_test_case.py. If you can create a small repository that triggers the same problem, then there is a good chance that it is easy to fix. Michael (the cvs2git maintainer) [1] http://cvs2svn.tigris.org/faq.html#testcase -- Michael Haggerty mhag...@alum.mit.edu http://softwareswirl.blogspot.com/ --
[PATCH 3/3] Change colors to be based on git status -sb in color mode
Hi
Fixed the mistakes of the last one, and I'm now using the symbolic names
ok_color and bad_color.
The test for headless state is now more direct, and I hope it is still correct.
/Simon
this patch is an additional patch to the previous series of two. It also
corrects the missing S and some minor details. The main point of this
one is changing the used colors to be more close to the color output of git
status -sb Mainly, the branchname stays green until it loses a HEAD, in
detached head state it becomes red.
The flags get their own color, either red or green for unstaged/staged and the
remaining flags get a different color or none at all.
Signed-off-by: Simon Oosthoek s.oosth...@xs4all.nl
---
contrib/completion/git-prompt.sh | 52 +++---
1 file changed, 31 insertions(+), 21 deletions(-)
diff --git a/contrib/completion/git-prompt.sh b/contrib/completion/git-prompt.sh
index 4fb998a..7dce319 100644
--- a/contrib/completion/git-prompt.sh
+++ b/contrib/completion/git-prompt.sh
@@ -55,11 +55,9 @@
# setting the bash.showUpstream config variable.
#
# If you would like a colored hint about the current dirty state, set
-# GIT_PS1_SHOWCOLORHINTS to a nonempty value. When tracked files are
-# modified, the branch name turns red, when all modifications are staged
-# the branch name turns yellow and when all changes are checked in, the
-# color changes to green. The colors are currently hardcoded in the function.
-
+# GIT_PS1_SHOWCOLORHINTS to a nonempty value. The colors are based on
+# the colored output of git status -sb.
+#
# __gitdir accepts 0 or 1 arguments (i.e., location)
# returns location of .git repo
__gitdir ()
@@ -325,35 +323,47 @@ __git_ps1 ()
local f=$w$i$s$u
if [ $pcmode = yes ]; then
- PS1=$ps1pc_start(
- if [ -n ${GIT_PS1_SHOWCOLORHINT-} ]; then
+ if [ -n ${GIT_PS1_SHOWCOLORHINTS-} ]; then
local c_red='\e[31m'
local c_green='\e[32m'
- local c_yellow='\e[33m'
local c_lblue='\e[1;34m'
- local c_purple='\e[35m'
- local c_cyan='\e[36m'
local c_clear='\e[0m'
+ local bad_color=$c_red
+ local ok_color=$c_green
+ local branch_color=$c_clear
+ local flags_color=$c_lblue
local branchstring=$c${b##refs/heads/}
- local branch_color=$c_green
- local flags_color=$c_cyan
- if [ $w = * ]; then
- branch_color=$c_red
- elif [ -n $i ]; then
- branch_color=$c_yellow
+ if git symbolic-ref HEAD 2/dev/null 12
+ then
+ branch_color=$ok_color
+ else
+ branch_color=$bad_color
fi
# Setting PS1 directly with \[ and \] around
colors
# is necessary to prevent wrapping issues!
-
PS1=$PS1\[$branch_color\]$branchstring\[$c_clear\]
- if [ -n $f ]; then
- PS1=$PS1
\[$flags_color\]$f\[$c_clear\]
+ PS1=$ps1pc_start
(\[$branch_color\]$branchstring\[$c_clear\]
+
+ if [ -n $w$i$s$u$r$p ]; then
+ PS1=$PS1
+ fi
+ if [ $w = * ]; then
+ PS1=$PS1\[$bad_color\]$w
+ fi
+ if [ -n $i ]; then
+ PS1=$PS1\[$ok_color\]$i
+ fi
+ if [ -n $s ]; then
+ PS1=$PS1\[$flags_color\]$s
+ fi
+ if [ -n $u ]; then
+ PS1=$PS1\[$bad_color\]$u
fi
+ PS1=$PS1\[$c_clear\]$r$p)$ps1pc_end
else
- PS1=$PS1$c${b##refs/heads/}${f:+ $f}$r$p
+ PS1=$ps1pc_start ($c${b##refs/heads/}${f:+
$f}$r$p)$ps1pc_end
fi
- PS1=$PS1)$ps1pc_end
else
# NO color option unless in PROMPT_COMMAND mode
Re: [RFC/PATCH 3/4v2] test-lib: provide lazy TIME_COMMAND prereq
Johannes Sixt j...@kdbg.org writes: Am 16.10.2012 17:07, schrieb Michael J Gruber: Some test want to use the time command (not the shell builtin) and test for its availability at /usr/bin/time. Provide a lazy prereq TIME_COMMAND which tests for $TEST_COMMAND_PATH, which can be set from config.mak. It defaults to /usr/bin/time. This avoids the builtin: command time $that_command It works for bash, ksh, zsh, and dash (where the latter doesn't have it as builtin). command time works but I think that is because it is not a built-in ;-) Here is what I read in bash(1): command [-pVv] command [arg ...] Run command with args suppressing the normal shell function lookup. Only builtin commands or commands found in the PATH are executed. Taken together with this from COMMAND EXECUTION: If the command name contains no slashes, the shell attempts to locate it. If there exists a shell function by that name, that function is invoked as described above in FUNCTIONS. If the name does not match a function, the shell searches for it in the list of shell builtins. If a match is found, that builtin is invoked. If the name is neither a shell function nor a builtin, and contains no slashes, bash searches each element of the PATH for a directory containing an executable file by that name. I suspect command printf 'a b c\n' would not use $HOME/bin/printf even when I have $HOME/bin early in my $PATH (nor /usr/bin/printf for that matter). -- 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
git rebase -p and patch equivalent commits
Hi all, I was wondering if you had any tips on the following workflow: I work on an experimental feature branch of a project. I have some patches that I implement in branch patch1 and patch2 on top of the feature branch. I test if they both work together by merging patch1 and patch2 into a build branch: mkdir build cd build git init echo a a git add a git commit -am a git branch feature git co -b patch1 echo b b git add b git commit -am b git co -b patch2 feature echo c c git add c git commit -am c git co -b build feature git merge --no-edit patch1 patch2 Now feature is rebased against master. How would you rebase the branches patch1, patch2 and build so that they keep the same layout? I tried to rebase patch1 and patch2, hoping that rebase -p build would use the rebased commits for the merge but it creates new commits (that are patch equivalents to patch1 and patch2) and merge them. So I can think of two ways to proceed: 1) only rebase patch1 and patch2, and then remerge them again in build. This start to get complicated if I have some commits in build after the merge, I will then need to rebase them on top of the new merge. And for a more complicated layout it will get pretty hard to recreate it automatically. 2) I can rebase -p the build branch first, and then reset --soft patch1 and patch2 so that they point to the right commits in the rebased branch. This way looks easier to do with more complicated layout, I just need to find a good way of finding where the rebased commits for patch1 and patch2 are, and I was thinking of using notes for that. So my question is: does it look like a sensible approach? Is there an easier way I am missing? Thanks! -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: When Will We See Collisions for SHA-1? (An interesting analysis by Bruce Schneier)
Jeff King p...@peff.net writes: A much bigger problem is the other places we reference sha1s. The obvious place is trees, which have no room for backup pointers (either in headers, or with a NUL trick). This is a tangent (as I do not have anything particularly worth adding on top of what have already been said around the exact SHA-[123] topic), but we probably would want to start thinking about the tree object format v2 at some point. Some random thoughts: - It is OK if existing versions of Git barfed when asked to read a tree object in the v2 format. The repository format version may need to be bumped up when writing such an object, and transfer protocols need to pay attention to it, to avoid transferring history with objects in newer representation to repositories with older repository format version. - We do not need a new tree v2 object type. Existing versions of Git will barf upon seeing such an object, but that won't be the only way to prevent existing versions of Git from misinterpreting a tree object recorded in the v2 format as if it were in the current format (e.g. a non-octal in the mode field of the first entry causes tree-walk.c::get_mode() to barf). - We do not mind two tree objects that encodes the same tree in the current and the enhanced formats to have different object names. In fact, we care more about the object names derived purely from the content of the object as an uninterpreted bytestream, so it is expected that they have different object names. This will make the path-limited traversal and diff to open more trees unnecessarily at the version bump boundary in the history, but that is normal (think of a project that used to record its text files with CRLF and one day decides to convert everything to LF; the trees before and after the conversion will record logically the same contents git show should give an emptyness, but the diff machinery needs to go into contents at the flag day boundary). As long as we do not let random extension of the day into the new format willy-nilly, the resulting history will still be useful and usable. From that point of view, no parts of the additional information we would record in the updated format that is not present in the current format should be optional (iow, once you decide to use the v2 format to record a certain tree, you will produce an identical and reproducible representation in v2, regardless of your implementation). All of the above are issues for Git 3.0 and beyond, though ;-). -- 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: error: git-fast-import died of signal 11
On Tue, Oct 16, 2012 at 3:41 PM, Uri Moszkowicz u...@4refs.com wrote: I can do that if it still fails tomorrow. How do I build a debug version of git? On Tue, Oct 16, 2012 at 2:35 PM, Andrew Wong andrew.k...@gmail.com wrote: Yea, it's a difficult problem to diagnose. It'd be really helpful if you can run a debug version of git and run the import process under a debugger. After getting git's source, you can simply run make, and it'll compile with debug info by default. When compiling is done, you will see all the binaries in the source's root folder. Then, from the source folder, you can start gdb by the command: gdb ./git-fast-import When you're inside gdb, put a breakpoint on die_nicely by entering: b die_nicely Then, you can finally run your import process by entering: r your_cvs_dump When fast-import crashes/dies, you can find the stacktrace by entering: bt And that should tell us where it crashed, and, hopefully, where the memory error happened. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 3/3] Change colors to be based on git status -sb in color mode
Simon Oosthoek s.oosth...@xs4all.nl writes:
Hi
Fixed the mistakes of the last one, and I'm now using the symbolic names
ok_color and bad_color.
The test for headless state is now more direct, and I hope it is still
correct.
/Simon
Will apply with a bit more readable log message.
I think it would be a good idea to squash something like the
attached into this patch, though.
contrib/completion/git-prompt.sh | 7 +++
1 file changed, 3 insertions(+), 4 deletions(-)
diff --git i/contrib/completion/git-prompt.sh w/contrib/completion/git-prompt.sh
index dced628..9f0b6bb 100644
--- i/contrib/completion/git-prompt.sh
+++ w/contrib/completion/git-prompt.sh
@@ -215,7 +215,7 @@ __git_ps1_show_upstream ()
__git_ps1 ()
{
local pcmode=no
- #defaults/examples:
+ local detached=no
local ps1pc_start='\u@\h:\w '
local ps1pc_end='\$ '
local printf_format=' (%s)'
@@ -264,7 +264,7 @@ __git_ps1 ()
fi
b=$(git symbolic-ref HEAD 2/dev/null) || {
-
+ detached=yes
b=$(
case ${GIT_PS1_DESCRIBE_STYLE-} in
(contains)
@@ -335,8 +335,7 @@ __git_ps1 ()
local flags_color=$c_lblue
local branchstring=$c${b##refs/heads/}
- if git symbolic-ref HEAD 2/dev/null 12
- then
+ if [ $detached = yes ]; then
branch_color=$ok_color
else
branch_color=$bad_color
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 3/3] Change colors to be based on git status -sb in color mode
Junio C Hamano gits...@pobox.com writes:
Simon Oosthoek s.oosth...@xs4all.nl writes:
Hi
Fixed the mistakes of the last one, and I'm now using the symbolic names
ok_color and bad_color.
The test for headless state is now more direct, and I hope it is still
correct.
/Simon
Will apply with a bit more readable log message.
I think it would be a good idea to squash something like the
attached into this patch, though.
The reason for this suggestion is not to avoid running symbolic-ref
twice (which is a good side effect, though). When you are in the
middle of bisection or multi-commit cherry-pick, for example, you
would conceptually be working on the original branch, but the HEAD
pointer may be detached. Earlier parts of the existing code in the
function makes this distinction, and the same distinction should be
carried over to the new code that decides the color to paint things
in.
contrib/completion/git-prompt.sh | 7 +++
1 file changed, 3 insertions(+), 4 deletions(-)
diff --git i/contrib/completion/git-prompt.sh
w/contrib/completion/git-prompt.sh
index dced628..9f0b6bb 100644
--- i/contrib/completion/git-prompt.sh
+++ w/contrib/completion/git-prompt.sh
@@ -215,7 +215,7 @@ __git_ps1_show_upstream ()
__git_ps1 ()
{
local pcmode=no
- #defaults/examples:
+ local detached=no
local ps1pc_start='\u@\h:\w '
local ps1pc_end='\$ '
local printf_format=' (%s)'
@@ -264,7 +264,7 @@ __git_ps1 ()
fi
b=$(git symbolic-ref HEAD 2/dev/null) || {
-
+ detached=yes
b=$(
case ${GIT_PS1_DESCRIBE_STYLE-} in
(contains)
@@ -335,8 +335,7 @@ __git_ps1 ()
local flags_color=$c_lblue
local branchstring=$c${b##refs/heads/}
- if git symbolic-ref HEAD 2/dev/null 12
- then
+ if [ $detached = yes ]; then
branch_color=$ok_color
else
branch_color=$bad_color
--
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 0/8] Create single PDF for all HTML files
Thomas Ackermann th.acke...@arcor.de writes: this is v3 of my patch series for creating a single PDF for all git documentation files. There are only 2 changes since v2 (thanks to Junio for pointing me at these issues) : - The over-long lines in git-bisect-lk2009.txt where shortened by abbreviating the SHA1s. - Pretty-printing the shell script in update-hook-example.txt was fixed. To sum up, this patch series provides the following new features: - Make target html now creates HTML for ALL files in ./Documentation/howto and ./Documentation/technical - New make target fullpdf first creates HTML for all files in ./Documentation/RelNotes and then collates all HTML files in ./Documentation and its subdirs (except user-manual.html) in one single PDF file. This approach is of course not an optimal one but by using wkhtmltopdf it could be carried out easily. I am not interested in adding a build target that requires (a patched version of) wkhtmltopdf at all, but the earlier parts of this series do look like good clean-ups and useful conversions to asciidoc, regardless of which tool we end up deciding to use to produce the final output. Thanks for working on this. I (and other people who wrote documentation, I suspect, as well) feel somewhat offended by the word fix here and there in the message in commits that turn files that so far have been plain text into asciidoc, though ;-). -- 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: Merge option suggestion (dictator, humble)
On 17 October 2012 04:23, Junio C Hamano gits...@pobox.com wrote: 乙酸鋰 ch3co...@gmail.com writes: I would like to suggest 2 merge options --dictator use all my changes --humble use all their changes These allows to produce a fast-forward commit, without resolving any conflicts. Sometimes, someone did something completely wrong, so the commit needs to be ignored. I cannot tell everyone in the world to run git fetch followed by git reset --hard. Then you cannot tell them to use pull --humble either, can you? Not seeing any merit in the proposal (yet). Would this allow setting up a project-default merge configuration for contributors that defaulted to --humble? Not sure if that is useful or not, but it at least seems safer than trying to default to doing reset --hard after every merge. Regards, Andrew Ardill -- 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
git submodule sync --recursive
I noticed that this is not supported: git submodule sync --recursive I do not see any discussion in the relevant commits about why it cannot or should not be supported. Is it just an itch no one has scratched? Phil -- 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: feature request
On Tue, Oct 16, 2012 at 10:57 PM, Angelo Borsotti angelo.borso...@gmail.com wrote: Hi Andrew, one nice thing is to warn a developer that wants to modify a source file, that there is somebody else changing it beforehand. It is nicer than discovering that at push time. Andrew: also see http://sitaramc.github.com/gitolite/locking.html for a way to do file locking (and enforce it) using gitolite. This does warn, as long as the user remembers to try to acquire a lock before working on a binary file. (You can't get around that requirement on a DVCS, sorry!) Take into account that there are changes in files that may be incompatible to each other, or that can be amenable to be automatically merged producing wrong results. So, knowing it could help. -Angelo -- 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 -- Sitaram -- 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: feature request
On 17 October 2012 04:27, Angelo Borsotti angelo.borso...@gmail.com wrote: Hi Andrew, one nice thing is to warn a developer that wants to modify a source file, that there is somebody else changing it beforehand. It is nicer than discovering that at push time. Take into account that there are changes in files that may be incompatible to each other, or that can be amenable to be automatically merged producing wrong results. So, knowing it could help. -Angelo If you simply want to know when a file has been changed by someone else, git already has this capability, but as you note it only occurs when you try to push. Unless you force push, you have to merge changes before committing to upstream. In a distributed situation you can only inform the user when they 'touch-base' with the server, and if that is what you want than one of the locking systems others have proposed might be a good choice. There are two concerns to deal with here. The first is when any conflicts at all will cause problems, as there is no way to merge them. This often happens with binary files, and is a good reason to use a locking system. The second concern is situations where a merge happens 'silently' (i.e. no conflicts) thus allowing potential logic bugs to be introduced even though semantically the merge was fine. For this situation the best option is to require whoever is merging to check the merge output for logical errors. This has to happen anyway, as it is possible for logical errors to be introduced across different files, although it's probably more common to see logic conflicts within the one file. To make it easier to discover such changes early in the process you could write a tool that did some (or all) of the following: 1. Automatically fetch changes from remote repositories at a regular interval. 2. Compare files changed in the working tree and index to changes fetched from remote repositories. This would need to find the merge base of the two and compare files touched since then. 3. Notify the user of the files that have been changed through some fashion. 4. Automatically push changes to a 'wip' branch so that others can see what you are modifying. Alternatively, automatically publish a list of changed files for the same purpose, though this seems a lot more hacky (though both options are surely hacky). 2 and 3 could be combined into a single tool run whenever the user wants to check for potential logic changes down the track. Automating it would allow for this information to be communicated a bit faster. Running it after each fetch would be a nice to have. Pushing the work in progress branch is something I am not sure is a good idea, but it would be the only way to know when someone else is working on something before they commit and push it manually. Pushing a single file with files being worked on is less invasive, but would require the other aspects of the tool to use it as well (hence forming a stronger coupling and reducing the usefulness of the other components as standalone tools). There is no way that I know of to force merge to stop every time the file is changed on both theirs and ours (regardless of whether or not it is an actual conflict or not). It could potentially be done with a pre-merge hook, but no such hook exists to my knowledge. If this were implemented, using it would make merging a potentially tiresome affair, however I could see its usefulness for people who were very concerned about introducing logic errors with merges on the same file. The best solution is in my opinion to check what is going to be merged before you merge it, but a tool to warn that someone else is modifying the same file would have its uses. Regards, Andrew Ardill -- 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
Please pull git-l10n updates for Swedish and Vietnamese
Hi, Junio The following changes since commit d25c58ce43f45734ef74595b1e6fba1199651699: Documentation/RelNotes: remove updated up to this revision markers (2012-10-16 15:35:00 -0700) are available in the git repository at: git://github.com/git-l10n/git-po master for you to fetch changes up to b408887045e3e4abe1551936d4877f6b942c1916: Merge branch 'master' of https://github.com/nafmo/git-l10n-sv (2012-10-17 09:38:30 +0800) Jiang Xin (2): Merge branch 'master' of git://github.com/vnwildman/git Merge branch 'master' of https://github.com/nafmo/git-l10n-sv Peter Krefting (1): l10n: Update Swedish translation (1964t0f0u) Tran Ngoc Quan (1): l10n: vi.po: update from v1.8.0-rc2-4-g42e55 po/sv.po | 879 +- po/vi.po | 948 --- 2 files changed, 913 insertions(+), 914 deletions(-) -- 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 v4] git-cvsimport: allow author-specific timezones
CVS patchsets are imported with timestamps having an offset of +
(UTC). The cvs-authors file is already used to translate the CVS
username to full name and email in the corresponding commit. Extend
this file to support an optional timezone for calculating a user-
specific timestamp offset.
Signed-off-by: Chris Rorvick ch...@rorvick.com
---
Use System V timezones in unit test per feedback from Junio and Peff.
Also, use timestamps from before the 2007 changes to DST--seems
reasonable that people may not have bothered patching their systems for
this in some parts of the world.
Is continuing to update the patch helpful at this point, or is this
just noise?
Documentation/git-cvsimport.txt| 8 +-
git-cvsimport.perl | 22 ++-
t/t9604-cvsimport-timestamps.sh| 71 ++
t/t9604/cvsroot/.gitattributes | 1 +
t/t9604/cvsroot/CVSROOT/.gitignore | 2 +
t/t9604/cvsroot/module/a,v | 265 +
6 files changed, 362 insertions(+), 7 deletions(-)
create mode 100755 t/t9604-cvsimport-timestamps.sh
create mode 100644 t/t9604/cvsroot/.gitattributes
create mode 100644 t/t9604/cvsroot/CVSROOT/.gitignore
create mode 100644 t/t9604/cvsroot/module/a,v
diff --git a/Documentation/git-cvsimport.txt b/Documentation/git-cvsimport.txt
index 6695ab3..9ea8bb5 100644
--- a/Documentation/git-cvsimport.txt
+++ b/Documentation/git-cvsimport.txt
@@ -137,17 +137,19 @@ This option can be used several times to provide several
detection regexes.
-A author-conv-file::
CVS by default uses the Unix username when writing its
commit logs. Using this option and an author-conv-file
- in this format
+ maps the name recorded in CVS to author name, e-mail and
+ and optional timezone:
+
-
exon=Andreas Ericsson a...@op5.se
- spawn=Simon Pawn sp...@frog-pond.org
+ spawn=Simon Pawn sp...@frog-pond.org America/Chicago
-
+
'git cvsimport' will make it appear as those authors had
their GIT_AUTHOR_NAME and GIT_AUTHOR_EMAIL set properly
-all along.
+all along. If a timezone is specified, GIT_AUTHOR_DATE will
+have the corresponding offset applied.
+
For convenience, this data is saved to `$GIT_DIR/cvs-authors`
each time the '-A' option is provided and read from that same
diff --git a/git-cvsimport.perl b/git-cvsimport.perl
index 8032f23..ceb119d 100755
--- a/git-cvsimport.perl
+++ b/git-cvsimport.perl
@@ -31,7 +31,7 @@ $SIG{'PIPE'}=IGNORE;
$ENV{'TZ'}=UTC;
our
($opt_h,$opt_o,$opt_v,$opt_k,$opt_u,$opt_d,$opt_p,$opt_C,$opt_z,$opt_i,$opt_P,
$opt_s,$opt_m,@opt_M,$opt_A,$opt_S,$opt_L, $opt_a, $opt_r, $opt_R);
-my (%conv_author_name, %conv_author_email);
+my (%conv_author_name, %conv_author_email, %conv_author_tz);
sub usage(;$) {
my $msg = shift;
@@ -59,6 +59,14 @@ sub read_author_info($) {
$conv_author_name{$user} = $2;
$conv_author_email{$user} = $3;
}
+ # or with an optional timezone:
+ # spawn=Simon Pawn sp...@frog-pond.org America/Chicago
+ elsif (m/^(\S+?)\s*=\s*(.+?)\s*(.+)\s*(\S+?)\s*$/) {
+ $user = $1;
+ $conv_author_name{$user} = $2;
+ $conv_author_email{$user} = $3;
+ $conv_author_tz{$user} = $4;
+ }
# However, we also read from CVSROOT/users format
# to ease migration.
elsif (/^(\w+):([']?)(.+?)\2\s*$/) {
@@ -84,7 +92,9 @@ sub write_author_info($) {
die(Failed to open $file for writing: $!);
foreach (keys %conv_author_name) {
- print $f $_=$conv_author_name{$_} $conv_author_email{$_}\n;
+ print $f $_=$conv_author_name{$_} $conv_author_email{$_};
+ print $f $conv_author_tz{$_} if ($conv_author_tz{$_});
+ print $f \n;
}
close ($f);
}
@@ -795,7 +805,7 @@ sub write_tree () {
return $tree;
}
-my ($patchset,$date,$author_name,$author_email,$branch,$ancestor,$tag,$logmsg);
+my
($patchset,$date,$author_name,$author_email,$author_tz,$branch,$ancestor,$tag,$logmsg);
my (@old,@new,@skipped,%ignorebranch,@commit_revisions);
# commits that cvsps cannot place anywhere...
@@ -844,7 +854,9 @@ sub commit {
}
}
- my $commit_date = strftime(+ %Y-%m-%d %H:%M:%S,gmtime($date));
+ $ENV{'TZ'}=$author_tz;
+ my $commit_date = strftime(%s %z, localtime($date));
+ $ENV{'TZ'}=UTC;
$ENV{GIT_AUTHOR_NAME} = $author_name;
$ENV{GIT_AUTHOR_EMAIL} = $author_email;
$ENV{GIT_AUTHOR_DATE} = $commit_date;
@@ -945,12 +957,14 @@ while (CVS) {
}
$state=3;
} elsif ($state == 3 and s/^Author:\s+//) {
+ $author_tz = UTC;
s/\s+$//;
if (/^(.*?)\s+(.*)/) {
($author_name,
Re: git rebase -p and patch equivalent commits
On Tue, Oct 16, 2012 at 12:58 PM, Damien Robert damien.olivier.robert+gm...@gmail.com wrote: Now feature is rebased against master. How would you rebase the branches patch1, patch2 and build so that they keep the same layout? I tried to rebase patch1 and patch2, hoping that rebase -p build would use the rebased commits for the merge but it creates new commits (that are patch equivalents to patch1 and patch2) and merge them. So I can think of two ways to proceed: 1) only rebase patch1 and patch2, and then remerge them again in build. If the build branch really is just a build branch, then I would probably choose this option. This start to get complicated if I have some commits in build after the merge What would such commits contain? Is it something related to your build system that you can automate? If not, should they perhaps rather have been included in one of the patch branches? Or are they related to interactions between the patch branches? If the latter, I would probably serialize the dependent branches (e.g. basing patch2 on patch1). 2) I can rebase -p the build branch first, and then reset --soft patch1 Did you mean --hard/--keep here? Or why would you use --soft? and patch2 so that they point to the right commits in the rebased branch. This way looks easier to do with more complicated layout, I just need to find a good way of finding where the rebased commits for patch1 and patch2 are, and I was thinking of using notes for that. I don't quite understand why you would want to do that if the build branch is just to make sure test pass on the merged result, but, yes, this method would probably be easier if you do need to keep both the build branch and the patchX branches up to date. Which branch do you actively work on at this point? Both the build branch and the patchX branches? Is it that you have sent patch1 and patch2 for review and you want to base your next topic on the merged result? I assume not, since you said it was a build branch. But if that was the case (i.e. somewhat active development on build, patch1 and patch2 (perhaps due to review comments)), I would probably still rebase one branch at a time, recreate the merge (possibly using rerere), and then rebase --onto new-merge old-merge build. -- 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] notes: mention --notes in more places
Eric Blake ebl...@redhat.com writes: * git-notes.txt: Mention that --notes option exists in many commands to override defaults. * git-format-patch.txt: Include pretty-options, for things like --notes. * git-send-email.txt: Mention that revision lists forwarded to format-patch can also include options. Overall I feel fairly negative on this one, even though there are good bits. Signed-off-by: Eric Blake ebl...@redhat.com --- Documentation/git-format-patch.txt | 2 ++ Documentation/git-notes.txt| 6 -- Documentation/git-send-email.txt | 3 ++- 3 files changed, 8 insertions(+), 3 deletions(-) diff --git a/Documentation/git-format-patch.txt b/Documentation/git-format-patch.txt index 6d43f56..a068f37 100644 --- a/Documentation/git-format-patch.txt +++ b/Documentation/git-format-patch.txt @@ -222,6 +222,8 @@ you can use `--suffix=-patch` to get `0001-description-of-my-change-patch`. range are always formatted as creation patches, independently of this flag. +include::pretty-options.txt[] In the context of format-patch, the inclusion of pretty-options probably causes more harm than being helpful, I am afraid. If you use --pretty=format, --format=format, or --oneline, the output will no longer be a proper mbox and is not suitable for asking somebody else to apply. At the very least, you would need to add something like: ifndef::git-format-patch[] ... enclose everything that should not be used with format-patch endif::git-format-patch[] to the included file, and then define the token before the inclusion, like this: :git-format-patch: 1 include::pretty-formats.txt[] to limit the damage. Even with such a change to include only --notes, I am not sure if the result is something we would want to recommend/advertise to our users. The output from format-patch with --notes shows the notes, after adding a blank line to the sign-off block, to look like this: From: A U Thor aut...@example.com Date: Tue, 16 Oct 2012 19:26:23 +0200 Subject: [PATCH] Gostak: distim the doshes correctly With the current code, the Gostak cannot correctly distim the doshes, because ... Signed-off-by: Junio C Hamano gits...@pobox.com Notes: This patch was inspired by Eric Blake --- diff --git a/gostak b/gostak ... I am not sure if this is suiable for sending to somebody and asking it to be applied. diff --git a/Documentation/git-notes.txt b/Documentation/git-notes.txt index b95aafa..be9e60f 100644 --- a/Documentation/git-notes.txt +++ b/Documentation/git-notes.txt @@ -39,8 +39,10 @@ message stored in the commit object, the notes are indented like the message, after an unindented line saying Notes (refname): (or Notes: for `refs/notes/commits`). -To change which notes are shown by 'git log', see the -notes.displayRef configuration in linkgit:git-log[1]. +To change which notes are shown by default in 'git log', see the +notes.displayRef configuration in linkgit:git-log[1]. Also, +many commands understand a `--notes` option to alter the set of +notes displayed (see linkgit:git-rev-list[1]). See the notes.rewrite.command configuration for a way to carry notes across commands that rewrite commits. OK. diff --git a/Documentation/git-send-email.txt b/Documentation/git-send-email.txt index eeb561c..450d975 100644 --- a/Documentation/git-send-email.txt +++ b/Documentation/git-send-email.txt @@ -18,7 +18,8 @@ Takes the patches given on the command line and emails them out. Patches can be specified as files, directories (which will send all files in the directory), or directly as a revision list. In the last case, any format accepted by linkgit:git-format-patch[1] can -be passed to git send-email. +be passed to git send-email, including additional command line +options such as `--cover-letter` or `--notes`. OK for --cover-letter, dubious on --notes. -- 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 v4] git-cvsimport: allow author-specific timezones
Chris Rorvick ch...@rorvick.com writes:
CVS patchsets are imported with timestamps having an offset of +
(UTC). The cvs-authors file is already used to translate the CVS
username to full name and email in the corresponding commit. Extend
this file to support an optional timezone for calculating a user-
specific timestamp offset.
Signed-off-by: Chris Rorvick ch...@rorvick.com
---
Use System V timezones in unit test per feedback from Junio and Peff.
Also, use timestamps from before the 2007 changes to DST--seems
reasonable that people may not have bothered patching their systems for
this in some parts of the world.
OK ;-)
Is continuing to update the patch helpful at this point, or is this
just noise?
A convention around here is to keep replacing until the series is
merged to 'next', and after that fix it up with incremental updates.
To make this process work well, a new series that is still under
active discussion is queued on 'pu' and after seeing rough consensus
on the list, it is merged to 'next'.
Will replace what has been queued on 'pu' with this version, after
fixing up an obvious typo in the documentation patch (and and).
Thanks.
Documentation/git-cvsimport.txt| 8 +-
git-cvsimport.perl | 22 ++-
t/t9604-cvsimport-timestamps.sh| 71 ++
t/t9604/cvsroot/.gitattributes | 1 +
t/t9604/cvsroot/CVSROOT/.gitignore | 2 +
t/t9604/cvsroot/module/a,v | 265
+
6 files changed, 362 insertions(+), 7 deletions(-)
create mode 100755 t/t9604-cvsimport-timestamps.sh
create mode 100644 t/t9604/cvsroot/.gitattributes
create mode 100644 t/t9604/cvsroot/CVSROOT/.gitignore
create mode 100644 t/t9604/cvsroot/module/a,v
diff --git a/Documentation/git-cvsimport.txt b/Documentation/git-cvsimport.txt
index 6695ab3..9ea8bb5 100644
--- a/Documentation/git-cvsimport.txt
+++ b/Documentation/git-cvsimport.txt
@@ -137,17 +137,19 @@ This option can be used several times to provide
several detection regexes.
-A author-conv-file::
CVS by default uses the Unix username when writing its
commit logs. Using this option and an author-conv-file
- in this format
+ maps the name recorded in CVS to author name, e-mail and
+ and optional timezone:
+
-
exon=Andreas Ericsson a...@op5.se
- spawn=Simon Pawn sp...@frog-pond.org
+ spawn=Simon Pawn sp...@frog-pond.org America/Chicago
-
+
'git cvsimport' will make it appear as those authors had
their GIT_AUTHOR_NAME and GIT_AUTHOR_EMAIL set properly
-all along.
+all along. If a timezone is specified, GIT_AUTHOR_DATE will
+have the corresponding offset applied.
+
For convenience, this data is saved to `$GIT_DIR/cvs-authors`
each time the '-A' option is provided and read from that same
diff --git a/git-cvsimport.perl b/git-cvsimport.perl
index 8032f23..ceb119d 100755
--- a/git-cvsimport.perl
+++ b/git-cvsimport.perl
@@ -31,7 +31,7 @@ $SIG{'PIPE'}=IGNORE;
$ENV{'TZ'}=UTC;
our
($opt_h,$opt_o,$opt_v,$opt_k,$opt_u,$opt_d,$opt_p,$opt_C,$opt_z,$opt_i,$opt_P,
$opt_s,$opt_m,@opt_M,$opt_A,$opt_S,$opt_L, $opt_a, $opt_r, $opt_R);
-my (%conv_author_name, %conv_author_email);
+my (%conv_author_name, %conv_author_email, %conv_author_tz);
sub usage(;$) {
my $msg = shift;
@@ -59,6 +59,14 @@ sub read_author_info($) {
$conv_author_name{$user} = $2;
$conv_author_email{$user} = $3;
}
+ # or with an optional timezone:
+ # spawn=Simon Pawn sp...@frog-pond.org America/Chicago
+ elsif (m/^(\S+?)\s*=\s*(.+?)\s*(.+)\s*(\S+?)\s*$/) {
+ $user = $1;
+ $conv_author_name{$user} = $2;
+ $conv_author_email{$user} = $3;
+ $conv_author_tz{$user} = $4;
+ }
# However, we also read from CVSROOT/users format
# to ease migration.
elsif (/^(\w+):([']?)(.+?)\2\s*$/) {
@@ -84,7 +92,9 @@ sub write_author_info($) {
die(Failed to open $file for writing: $!);
foreach (keys %conv_author_name) {
- print $f $_=$conv_author_name{$_} $conv_author_email{$_}\n;
+ print $f $_=$conv_author_name{$_} $conv_author_email{$_};
+ print $f $conv_author_tz{$_} if ($conv_author_tz{$_});
+ print $f \n;
}
close ($f);
}
@@ -795,7 +805,7 @@ sub write_tree () {
return $tree;
}
-my
($patchset,$date,$author_name,$author_email,$branch,$ancestor,$tag,$logmsg);
+my
($patchset,$date,$author_name,$author_email,$author_tz,$branch,$ancestor,$tag,$logmsg);
my (@old,@new,@skipped,%ignorebranch,@commit_revisions);
# commits that cvsps cannot place anywhere...
@@ -844,7 +854,9 @@ sub commit {
}
}
- my $commit_date = strftime(+ %Y-%m-%d
Re: [PATCH] notes: mention --notes in more places
On Tue, Oct 16, 2012 at 09:19:35PM -0600, Eric Blake wrote: Every so often, I search 'git send-email --help' to remember some option I've used in the past, only to discover that the option is documented instead in 'git format-patch --help'. Worse, even that command didn't document the option I was looking for today, which was how to include 'git notes' in the body of the commits I was mailing. Reading 'git notes --help' didn't mention this either, and I had to resort to searching the source code. It can't hurt to add some documentation to make this option less obscure. I think this is a good direction, but... * git-notes.txt: Mention that --notes option exists in many commands to override defaults. * git-format-patch.txt: Include pretty-options, for things like --notes. There are many things in pretty-options that would not be appropriate for format-patch. We should probably wrap them like this: diff --git a/Documentation/pretty-options.txt b/Documentation/pretty-options.txt index 5e49942..a0f1d15 100644 --- a/Documentation/pretty-options.txt +++ b/Documentation/pretty-options.txt @@ -1,3 +1,4 @@ +ifndef::git-format-patch[] --pretty[=format]:: --format=format:: @@ -27,6 +28,7 @@ people using 80-column terminals. --oneline:: This is a shorthand for --pretty=oneline --abbrev-commit used together. +endif::git-format-patch[] --encoding[=encoding]:: The commit objects record the encoding used for the log message It may also make sense to show notes differently when outputting the email format as format-patch does. E.g., using a triple-dash would keep them separate from the commit message when using git am. Like: your commit message Signed-off-by: You --- your notes go here We've talked about it several times, but it's never happened (probably because most people don't actually use notes). -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
