What can cause empty GIT_AUTHOR_NAME for 'git filter-branch --tree-filter' on Solaris?
The filter-branch command, the contents of ~/.gitconfig and the tree are the same. The command succeeds on cygwin, but fails on Solaris due to unset GIT_AUTHOR_NAME and GIT_COMMITTER_NAME : $ git filter-branch --tree-filter "env | grep GIT_ ; $CMD" b416b9bfc5e71531f2f05af4c396bb0ba7560741..HEAD Rewrite 214efc6eec82b015aefe23b2280979f05b351396 (1/16)GIT_DIR=/home/tester/.ilya/builds/makepkg.rap_0.1-1_sparc.XX/src/rap/.git GIT_INDEX_FILE=/home/tester/.ilya/builds/makepkg.rap_0.1-1_sparc.XX/src/rap/.git-rewrite/t/../index GIT_WORK_TREE=. GIT_AUTHOR_NAME= GIT_COMMITTER_NAME= GIT_COMMIT=214efc6eec82b015aefe23b2280979f05b351396 fatal: empty ident not allowed could not write rewritten commit If I explicitly set these 2 variables, filter-branch succeeds, but other commit attributes like commit date aren't preserved. I use git 1.7.6, from sunfreeware. I hope there is some simple thing that needs to be configured. -- 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
Jeff King wrote: >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). It is sometimes scary how we end up saying identical things independently :-) -- 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
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=:: @@ -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[=]:: 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
Re: [PATCH v4] git-cvsimport: allow author-specific timezones
Chris Rorvick 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 > --- > > 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 :: > 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 > - spawn=Simon Pawn > + spawn=Simon Pawn 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 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("+
Re: [PATCH] notes: mention --notes in more places
Eric Blake 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 > --- > 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=", 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 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 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 ():" (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." 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: git rebase -p and patch equivalent commits
On Tue, Oct 16, 2012 at 12:58 PM, Damien Robert 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
[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 --- 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 :: 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 - spawn=Simon Pawn + spawn=Simon Pawn 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 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 () { } $state=3; } elsif ($state == 3 and s/^Author:\s+//) { + $author_tz = "UTC"; s/\s+$//; if (/^(.*?)\s+<(.*)>/) { ($author_name, $author_email) = ($1, $2); } elsif ($conv_author_name{$_})
[PATCH] notes: mention --notes in more places
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. * 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. Signed-off-by: Eric Blake --- 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[] + CONFIGURATION - You can specify extra mail header lines to be added to each message, 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 ():" (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." configuration for a way to carry notes across commands that rewrite commits. 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`. The header of the email is configurable by command line options. If not specified on the command line, the user will be prompted with a ReadLine -- 1.7.11.7 -- 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
Re: feature request
On 17 October 2012 04:27, Angelo Borsotti 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
Re: feature request
On Tue, Oct 16, 2012 at 10:57 PM, Angelo Borsotti 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
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: Merge option suggestion (dictator, humble)
On 17 October 2012 04:23, Junio C Hamano wrote: > 乙酸鋰 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
Re: [Patch v3 0/8] Create single PDF for all HTML files
Thomas Ackermann 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: [PATCH 3/3] Change colors to be based on git status -sb in color mode
Junio C Hamano writes: > Simon Oosthoek 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 1>&2 > - 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
Simon Oosthoek 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 1>&2 - 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: error: git-fast-import died of signal 11
On Tue, Oct 16, 2012 at 3:41 PM, Uri Moszkowicz 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 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: When Will We See Collisions for SHA-1? (An interesting analysis by Bruce Schneier)
Jeff King 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
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: [RFC/PATCH 3/4v2] test-lib: provide lazy TIME_COMMAND prereq
Johannes Sixt 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
[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 --- 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 1>&2 + 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 opti
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 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
Re: [PATCH 00/20] git-cvsserver: add support for cvs "-r" refs
Matthew Ogilvie 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: [RFC/PATCH 3/4v2] test-lib: provide lazy TIME_COMMAND prereq
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). -- 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: push race
Jeff King writes: > 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. :) Yup. -- 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: 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: [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: [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 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: When Will We See Collisions for SHA-1? (An interesting analysis by Bruce Schneier)
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. > 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. I'm not sure exactly what you mean. Extended parent pointers make sense, but I don't see what you mean in your first sentence. It sounds like we are SHA-2/3 hashing something internal to the object, but that doesn't help. If the pointers are sha1, then I can always replace the whole object with a colliding one, even if that object is internally consistent with respect to sha-2. > 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. Right. The point of having the SHA-3 contest was that we thought SHA-1's breakage meant that SHA-2 was going to fall next. But Schneier's comments before the winners were announced were basically "it turns out that SHA-2 is not broken like we thought, so there's no reason to ditch it, and the fact that it is well-studied and well-deployed may mean it's a good choice". So I could go either way. This is not a decision we should make today, though, so we can wait and see which direction the world goes before picking an algorithm. -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
[PATCH] Cache stat_tracking_info() for faster status and branch -v
stat_tracking_info() is used to calculated how many commits ahead or behind for a branch. Rev walking can be slow especially when the branch is way behind its remote end. By caching the results, we won't have to rev walk every time we need these information. stat_tracking_info() cost can be greatly reduced this way. This makes sure "git status" instant no matter how far behind HEAD is, except the first time after HEAD changes. This also makes "branch -v" usable (for me) as it's now also instant versus 3.5 seconds in non-cache case on my machine. Signed-off-by: Nguyễn Thái Ngọc Duy --- I wanted guaranteed-fast status for another reason, but it turns out "branch -v" benefits even more. Recent commit walking is not efficiently optimized even with Shawn's pack bitmaps. This may be useful some people, I guess. remote.c | 42 ++ 1 file changed, 42 insertions(+) diff --git a/remote.c b/remote.c index 04fd9ea..db825b8 100644 --- a/remote.c +++ b/remote.c @@ -1549,6 +1549,7 @@ int stat_tracking_info(struct branch *branch, int *num_ours, int *num_theirs) struct rev_info revs; const char *rev_argv[10], *base; int rev_argc; + int fd; /* * Nothing to report unless we are marked to build on top of @@ -1579,6 +1580,33 @@ int stat_tracking_info(struct branch *branch, int *num_ours, int *num_theirs) if (theirs == ours) return 0; + if (!access(git_path("stat_tracking_cache/%s", +branch->refname), R_OK)) { + struct strbuf sb = STRBUF_INIT; + unsigned char sha1_ours[20], sha1_theirs[20]; + int n1, n2; + if ((fd = open(git_path("stat_tracking_cache/%s", + branch->refname), + O_RDONLY)) != -1 && + strbuf_read(&sb, fd, 0) != -1 && + sb.len > (40 + 1) * 2 && + !get_sha1_hex(sb.buf, sha1_ours) && + sb.buf[40] == '\n' && + !get_sha1_hex(sb.buf + 41, sha1_theirs) && + sb.buf[81] == '\n' && + !hashcmp(sha1_ours, ours->object.sha1) && + !hashcmp(sha1_theirs, theirs->object.sha1) && + sscanf(sb.buf + 82, "%d\n%d\n", &n1, &n2) == 2) { + *num_ours = n1; + *num_theirs = n2; + close(fd); + strbuf_release(&sb); + return 1; + } + close(fd); + strbuf_release(&sb); + } + /* Run "rev-list --left-right ours...theirs" internally... */ rev_argc = 0; rev_argv[rev_argc++] = NULL; @@ -1608,6 +1636,20 @@ int stat_tracking_info(struct branch *branch, int *num_ours, int *num_theirs) (*num_theirs)++; } + if (!safe_create_leading_directories(git_path("stat_tracking_cache/%s", + branch->refname)) && + (fd = open(git_path("stat_tracking_cache/%s", + branch->refname), + O_CREAT | O_TRUNC | O_RDWR, 0644)) != -1) { + struct strbuf sb = STRBUF_INIT; + strbuf_addf(&sb, "%s\n", sha1_to_hex(ours->object.sha1)); + strbuf_addf(&sb, "%s\n", sha1_to_hex(theirs->object.sha1)); + strbuf_addf(&sb, "%d\n%d\n", *num_ours, *num_theirs); + write(fd, sb.buf, sb.len); + strbuf_release(&sb); + close(fd); + } + /* clear object flags smudged by the above traversal */ clear_commit_marks(ours, ALL_REV_FLAGS); clear_commit_marks(theirs, ALL_REV_FLAGS); -- 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: 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
[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 --- 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 uns
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 7/8] Create pdf from all html files
- use wkhtmltopdf ("patched QT" version) to combine all html files into a single pdf file "git-doc.pdf" - insert page breaks to separate major sections Signed-off-by: Thomas Ackermann --- Documentation/.gitignore | 1 + Documentation/footerend.txt | 4 Documentation/footerstart.txt | 7 ++ Documentation/makedocpdf.sh | 53 +++ Documentation/pagebreak.txt | 1 + 5 files changed, 66 insertions(+) create mode 100644 Documentation/footerend.txt create mode 100644 Documentation/footerstart.txt create mode 100755 Documentation/makedocpdf.sh create mode 100644 Documentation/pagebreak.txt diff --git a/Documentation/.gitignore b/Documentation/.gitignore index d62aebd..fba4730 100644 --- a/Documentation/.gitignore +++ b/Documentation/.gitignore @@ -10,3 +10,4 @@ howto-index.txt doc.dep cmds-*.txt manpage-base-url.xsl +docfiles.txt diff --git a/Documentation/footerend.txt b/Documentation/footerend.txt new file mode 100644 index 000..ed16923 --- /dev/null +++ b/Documentation/footerend.txt @@ -0,0 +1,4 @@ + + + + diff --git a/Documentation/footerstart.txt b/Documentation/footerstart.txt new file mode 100644 index 000..a2746ef --- /dev/null +++ b/Documentation/footerstart.txt @@ -0,0 +1,7 @@ + + + + + + + diff --git a/Documentation/makedocpdf.sh b/Documentation/makedocpdf.sh new file mode 100755 index 000..5f1a2c1 --- /dev/null +++ b/Documentation/makedocpdf.sh @@ -0,0 +1,53 @@ +#!/bin/sh + +rm -f git-doc.pdf + +cat pagebreak.txt >pagebreak.html + +cat /dev/null >docfiles.txt + +ls gittutorial.html>>docfiles.txt +ls gittutorial-2.html >>docfiles.txt +ls everyday.html >>docfiles.txt +ls gitworkflows.html >>docfiles.txt + +ls pagebreak.html >>docfiles.txt +ls git.html>>docfiles.txt +ls git-a*.html >>docfiles.txt +ls git-bisect.html >>docfiles.txt +ls git-b[j-z]*.html>>docfiles.txt +ls git-[c-s]*.html >>docfiles.txt +ls git-ta*.html>>docfiles.txt +ls gitk.html >>docfiles.txt +ls git-[u-z]*.html >>docfiles.txt + +ls pagebreak.html >>docfiles.txt +ls gita*.html >>docfiles.txt +ls git-bisect-lk2009.html >>docfiles.txt +ls git[cdghimnr]*.html >>docfiles.txt +ls git-tools.html >>docfiles.txt +ls gitweb*.html>>docfiles.txt + +ls pagebreak.html >>docfiles.txt +ls howto-index.html>>docfiles.txt +ls howto/*.html>>docfiles.txt + +ls pagebreak.html >>docfiles.txt +ls technical/[b-z]*.html >>docfiles.txt + +ls pagebreak.html >>docfiles.txt +ls technical/api-index.html>>docfiles.txt +ls technical/api-[a-h]*.html >>docfiles.txt +ls technical/api-in-*.html >>docfiles.txt +ls technical/api-[j-z]*.html >>docfiles.txt + +ls pagebreak.html >>docfiles.txt +ls RelNotes/*.html >>docfiles.txt + +cat /dev/null >footer.html + +cat footerstart.txt>>footer.html +cat ../GIT-VERSION-FILE>>footer.html +cat footerend.txt >>footer.html + +cat docfiles.txt | xargs cat | wkhtmltopdf --book --footer-html footer.html --disable-external-links - git-doc.pdf diff --git a/Documentation/pagebreak.txt b/Documentation/pagebreak.txt new file mode 100644 index 000..fdaffd1 --- /dev/null +++ b/Documentation/pagebreak.txt @@ -0,0 +1 @@ + -- 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
[Patch v3 6/8] Prerequisites for creating nice html for all files in Documentation/RelNotes
- remove left-over shell-script fragments from some files Signed-off-by: Thomas Ackermann --- Documentation/RelNotes/1.5.2.1.txt | 6 -- Documentation/RelNotes/1.6.0.2.txt | 6 -- Documentation/RelNotes/1.6.1.3.txt | 4 Documentation/RelNotes/1.6.1.4.txt | 3 --- Documentation/RelNotes/1.6.1.txt | 6 -- 5 files changed, 25 deletions(-) diff --git a/Documentation/RelNotes/1.5.2.1.txt b/Documentation/RelNotes/1.5.2.1.txt index ebf20e2..d41984d 100644 --- a/Documentation/RelNotes/1.5.2.1.txt +++ b/Documentation/RelNotes/1.5.2.1.txt @@ -45,9 +45,3 @@ Fixes since v1.5.2 - git-fastimport --import-marks was broken; fixed. - A lot of documentation updates, clarifications and fixes. - --- -exec >/var/tmp/1 -O=v1.5.2-65-g996e2d6 -echo O=`git describe refs/heads/maint` -git shortlog --no-merges $O..refs/heads/maint diff --git a/Documentation/RelNotes/1.6.0.2.txt b/Documentation/RelNotes/1.6.0.2.txt index e1e24b3..7d8fb85 100644 --- a/Documentation/RelNotes/1.6.0.2.txt +++ b/Documentation/RelNotes/1.6.0.2.txt @@ -79,9 +79,3 @@ Fixes since v1.6.0.1 packfile. Also contains many documentation updates. - --- -exec >/var/tmp/1 -O=v1.6.0.1-78-g3632cfc -echo O=$(git describe maint) -git shortlog --no-merges $O..maint diff --git a/Documentation/RelNotes/1.6.1.3.txt b/Documentation/RelNotes/1.6.1.3.txt index 6f0bde1..cd08d81 100644 --- a/Documentation/RelNotes/1.6.1.3.txt +++ b/Documentation/RelNotes/1.6.1.3.txt @@ -26,7 +26,3 @@ Fixes since v1.6.1.2 * RPM binary package installed the html manpages in a wrong place. Also includes minor documentation fixes and updates. - - --- -git shortlog --no-merges v1.6.1.2-33-gc789350.. diff --git a/Documentation/RelNotes/1.6.1.4.txt b/Documentation/RelNotes/1.6.1.4.txt index 0ce6316..ccbad79 100644 --- a/Documentation/RelNotes/1.6.1.4.txt +++ b/Documentation/RelNotes/1.6.1.4.txt @@ -39,6 +39,3 @@ Fixes since v1.6.1.3 This fix was first merged to 1.6.2.3. Also includes minor documentation fixes and updates. - --- -git shortlog --no-merges v1.6.1.3.. diff --git a/Documentation/RelNotes/1.6.1.txt b/Documentation/RelNotes/1.6.1.txt index adb7cca..7b152a6 100644 --- a/Documentation/RelNotes/1.6.1.txt +++ b/Documentation/RelNotes/1.6.1.txt @@ -278,9 +278,3 @@ release, unless otherwise noted. * "gitweb" did not mark non-ASCII characters imported from external HTML fragments correctly. - --- -exec >/var/tmp/1 -O=v1.6.1-rc3-74-gf66bc5f -echo O=$(git describe master) -git shortlog --no-merges $O..master ^maint -- 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
[Patch v3 5/8] Prerequisites for creating nice html for all files in Documentation/howto
- create headlines with asciidoc markup - asciidoc box markup for mail replies in recover-corrupted-blob-object.txt - pretty-print shell script in update-hook-example.txt - correct indendation for allowed-users example in update-hook-example.txt - headline of every howto document starts with "How to ..." - add "Content-type: text/asciidoc" in new files (used in howto-index.sh) Signed-off-by: Thomas Ackermann --- Documentation/howto/maintain-git.txt | 4 ++ .../howto/rebase-from-internal-branch.txt | 11 ++--- Documentation/howto/rebuild-from-update-hook.txt | 4 ++ .../howto/recover-corrupted-blob-object.txt| 10 + Documentation/howto/revert-a-faulty-merge.txt | 4 ++ Documentation/howto/revert-branch-rebase.txt | 4 +- Documentation/howto/separating-topic-branches.txt | 4 ++ Documentation/howto/setup-git-server-over-http.txt | 4 ++ Documentation/howto/update-hook-example.txt| 50 +++--- Documentation/howto/use-git-daemon.txt | 3 ++ .../howto/using-signed-tag-in-pull-request.txt | 4 +- 11 files changed, 68 insertions(+), 34 deletions(-) diff --git a/Documentation/howto/maintain-git.txt b/Documentation/howto/maintain-git.txt index 8823a37..ea6e4a5 100644 --- a/Documentation/howto/maintain-git.txt +++ b/Documentation/howto/maintain-git.txt @@ -5,6 +5,10 @@ Abstract: Imagine that git development is racing along as usual, when our friend neighborhood maintainer is struck down by a wayward bus. Out of the hordes of suckers (loyal developers), you have been tricked (chosen) to step up as the new maintainer. This howto will show you "how to" do it. +Content-type: text/asciidoc + +How to maintain Git +=== The maintainer's git time is spent on three activities. diff --git a/Documentation/howto/rebase-from-internal-branch.txt b/Documentation/howto/rebase-from-internal-branch.txt index 74a1c0c..4627ee4 100644 --- a/Documentation/howto/rebase-from-internal-branch.txt +++ b/Documentation/howto/rebase-from-internal-branch.txt @@ -8,7 +8,12 @@ Abstract: In this article, JC talks about how he rebases the the "master" branch, and how "rebase" works. Also discussed is how this applies to individual developers who sends patches upstream. +Content-type: text/asciidoc +How to rebase from an internal branch += + +-- Petr Baudis writes: > Dear diary, on Sun, Aug 14, 2005 at 09:57:13AM CEST, I got a letter @@ -19,6 +24,7 @@ Petr Baudis writes: >> > branch to the real branches. >> > Actually, wouldn't this be also precisely for what StGIT is intended to? +-- Exactly my feeling. I was sort of waiting for Catalin to speak up. With its basing philosophical ancestry on quilt, this is @@ -156,8 +162,3 @@ you continue on starting from the new "master" head, which is the #1' commit. -jc - -- -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 diff --git a/Documentation/howto/rebuild-from-update-hook.txt b/Documentation/howto/rebuild-from-update-hook.txt index 48c6756..00c1b45 100644 --- a/Documentation/howto/rebuild-from-update-hook.txt +++ b/Documentation/howto/rebuild-from-update-hook.txt @@ -5,6 +5,10 @@ Date: Fri, 26 Aug 2005 18:19:10 -0700 Abstract: In this how-to article, JC talks about how he uses the post-update hook to automate git documentation page shown at http://www.kernel.org/pub/software/scm/git/docs/. +Content-type: text/asciidoc + +How to rebuild from update hook +=== The pages under http://www.kernel.org/pub/software/scm/git/docs/ are built from Documentation/ directory of the git.git project diff --git a/Documentation/howto/recover-corrupted-blob-object.txt b/Documentation/howto/recover-corrupted-blob-object.txt index 323b513..7484735 100644 --- a/Documentation/howto/recover-corrupted-blob-object.txt +++ b/Documentation/howto/recover-corrupted-blob-object.txt @@ -3,11 +3,17 @@ From: Linus Torvalds Subject: corrupt object on git-gc Abstract: Some tricks to reconstruct blob objects in order to fix a corrupted repository. +Content-type: text/asciidoc +How to recover a corrupted blob object +== + +--- On Fri, 9 Nov 2007, Yossi Leybovich wrote: > > Did not help still the repository look for this object? > Any one know how can I track this object and understand which file is it +--- So exactly *because* the SHA1 hash is cryptographically secure, the hash itself doesn't actually tell you anything, in order to fix a corrupt @@ -31,19 +37,23 @@ original object, so right now the corrupt object is useless, but it's very interesti
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
[Patch v3 4/8] Prerequisites for creating nice html for all files in Documentation/technical
- fix wrong asciidoc sectioning markup in index-format.txt, pack-format.txt and pack-protocol.txt - split an over-long line in pack-protocol.txt into several lines - add a markup box for definition part in shallow.txt - fix table markup in trivial-merge.txt Signed-off-by: Thomas Ackermann --- Documentation/technical/index-format.txt | 2 +- Documentation/technical/pack-format.txt | 8 +++ Documentation/technical/pack-protocol.txt | 7 +++--- Documentation/technical/shallow.txt | 8 ++- Documentation/technical/trivial-merge.txt | 36 +++ 5 files changed, 34 insertions(+), 27 deletions(-) diff --git a/Documentation/technical/index-format.txt b/Documentation/technical/index-format.txt index 9d25b30..57d6f91 100644 --- a/Documentation/technical/index-format.txt +++ b/Documentation/technical/index-format.txt @@ -1,7 +1,7 @@ GIT index format -= The git index file has the following format +== The git index file has the following format All binary numbers are in network byte order. Version 2 is described here unless stated otherwise. diff --git a/Documentation/technical/pack-format.txt b/Documentation/technical/pack-format.txt index 1803e64..a7871fb 100644 --- a/Documentation/technical/pack-format.txt +++ b/Documentation/technical/pack-format.txt @@ -1,7 +1,7 @@ GIT pack format === -= pack-*.pack files have the following format: +== pack-*.pack files have the following format: - A header appears at the beginning and consists of the following: @@ -34,7 +34,7 @@ GIT pack format - The trailer records 20-byte SHA1 checksum of all of the above. -= Original (version 1) pack-*.idx files have the following format: +== Original (version 1) pack-*.idx files have the following format: - The header consists of 256 4-byte network byte order integers. N-th entry of this table records the number of @@ -123,8 +123,8 @@ Pack file entry: <+ -= Version 2 pack-*.idx files support packs larger than 4 GiB, and - have some other reorganizations. They have the format: +== Version 2 pack-*.idx files support packs larger than 4 GiB, and + have some other reorganizations. They have the format: - A 4-byte magic number '\377tOc' which is an unreasonable fanout[0] value. diff --git a/Documentation/technical/pack-protocol.txt b/Documentation/technical/pack-protocol.txt index d51e20f..25e1fbe 100644 --- a/Documentation/technical/pack-protocol.txt +++ b/Documentation/technical/pack-protocol.txt @@ -117,7 +117,7 @@ A few things to remember here: - The repository path is always quoted with single quotes. Fetching Data From a Server -=== +--- When one Git repository wants to get data that a second repository has, the first can 'fetch' from the second. This operation determines @@ -134,7 +134,8 @@ with the object name that each reference currently points to. $ echo -e -n "0039git-upload-pack /schacon/gitbook.git\0host=example.com\0" | nc -v example.com 9418 - 00887217a7c7e582c46cec22a130adf4b9d7d950fba0 HEAD\0multi_ack thin-pack side-band side-band-64k ofs-delta shallow no-progress include-tag + 00887217a7c7e582c46cec22a130adf4b9d7d950fba0 HEAD\0multi_ack thin-pack +side-band side-band-64k ofs-delta shallow no-progress include-tag 00441d3fcd5ced445d1abc402225c0b8a1299641f497 refs/heads/integration 003f7217a7c7e582c46cec22a130adf4b9d7d950fba0 refs/heads/master 003cb88d2441cac0977faf98efc80305012112238d9d refs/tags/v0.9 @@ -421,7 +422,7 @@ entire packfile without multiplexing. Pushing Data To a Server - + Pushing data to a server will invoke the 'receive-pack' process on the server, which will allow the client to tell it which references it should diff --git a/Documentation/technical/shallow.txt b/Documentation/technical/shallow.txt index 559263a..0502a54 100644 --- a/Documentation/technical/shallow.txt +++ b/Documentation/technical/shallow.txt @@ -1,6 +1,12 @@ -Def.: Shallow commits do have parents, but not in the shallow +Shallow commits +=== + +.Definition +* +Shallow commits do have parents, but not in the shallow repo, and therefore grafts are introduced pretending that these commits have no parents. +* The basic idea is to write the SHA1s of shallow commits into $GIT_DIR/shallow, and handle its contents like the contents diff --git a/Documentation/technical/trivial-merge.txt b/Documentation/technical/trivial-merge.txt index 24c8410..c79d4a7 100644 --- a/Documentation/technical/trivial-merge.txt +++ b/Documentation/technical/trivial-merge.txt @@ -74,24 +74,24 @@ For multiple ancestors, a '+' means that this case applies even if only one ancestor or remote fits; a '^' means all of the ancestors must be the s
[Patch v3 3/8] Change headline of technical/send-pack-pipeline.txt to not confuse its content with content from git-send-pack.txt
Signed-off-by: Thomas Ackermann --- Documentation/technical/send-pack-pipeline.txt | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/Documentation/technical/send-pack-pipeline.txt b/Documentation/technical/send-pack-pipeline.txt index 681efe4..9b5a0bc 100644 --- a/Documentation/technical/send-pack-pipeline.txt +++ b/Documentation/technical/send-pack-pipeline.txt @@ -1,5 +1,5 @@ -git-send-pack -= +Git-send-pack internals +=== Overall operation - -- 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: Merge option suggestion (dictator, humble)
乙酸鋰 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: [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 --- 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) +
[Patch v3 2/8] Shorten two over-long lines in git-bisect-lk2009.txt by abbreviating some sha1
Signed-off-by: Thomas Ackermann --- 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: push race
Nguyen Thai Ngoc Duy writes: > On Tue, Oct 16, 2012 at 12:37 PM, Jeff King 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 1/8] Split over-long synopsis in git-fetch-pack.txt into several lines
Signed-off-by: Thomas Ackermann --- 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=] [--depth=] [--no-progress] [-v] [:] [...] +'git fetch-pack' [--all] [--quiet|-q] [--keep|-k] [--thin] [--include-tag] + [--upload-pack=] + [--depth=] [--no-progress] + [-v] [:] [...] 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
[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
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 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
Re: [PATCH 0/5] Fixing problem with deleting symrefs
Johan Herland 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 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: [RFC/PATCH 3/4] test-lib: provide lazy TIME_COMMAND prereq
Michael J Gruber 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 1/4] t3419-rebase-patch-id: heed USR_BIN_TIME prereq
Michael J Gruber 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 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/4v2] test-lib: provide lazy TIME_COMMAND prereq
Michael J Gruber 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
[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 --- 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[]:: --untracked-files[=]:: 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: [PATCH 2/4] test-lib: allow variable export from lazy prereq tests
Michael J Gruber 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
Re: [PATCH 12/12] Add git-check-ignore sub-command
Adam Spiers writes: > On Mon, Oct 15, 2012 at 3:31 PM, Junio C Hamano wrote: >> Nguyễn Thái Ngọc Duy 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: BUG when trying to delete symbolic refs
René Scharfe 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 3/3] Change colors to be based on git status -sb in color mode
Simon Oosthoek writes: > this patch is an additional patch to the previous series of two. > @@ -325,35 +323,45 @@ __git_ps1 () > > local f="$w$i$s$u" > if [ $pcmode = yes ]; then > + if [ -n "${GIT_PS1_SHOWCOLORHINTS-}" ]; then > local c_red='\e[31m' > local c_green='\e[32m' > local c_lblue='\e[1;34m' > local c_clear='\e[0m' > local branchstring="$c${b##refs/heads/}" > + local branch_color="$c_clear" > + local flags_color="$c_lblue" > > + case "$b" in > + \(*\)) branch_color="$c_red" > + ;; > + *) local branch_color="$c_green" > + ;; > + esac Why "local" only on one side and not the other? Also switching on "$b" and relying on how it happens to be formatted inside parentheses when detached (which can very well change in the future) looks like a fragile bug waiting to be triggered. > # Setting PS1 directly with \[ and \] around > colors > # is necessary to prevent wrapping issues! > + 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\[$c_red\]$w" > + fi > + if [ -n "$i" ]; then > + PS1="$PS1\[$c_green\]$i" > + fi You gave nice symbolic names to branch_color and flags_color, but these two use hardcoded colors? -- 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: [PATCH] git-cvsimport: allow author-specific timezones
Jeff King writes: > On Mon, Oct 15, 2012 at 08:50:21PM -0700, Junio C Hamano wrote: > >> Chris Rorvick 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
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 > >> --- > >> 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 12/12] Add git-check-ignore sub-command
On Tue, Oct 16, 2012 at 9:09 PM, Adam Spiers 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
[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 --- 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: [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 >> --- >> 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). >> 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
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 > --- > 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
Re: [PATCH 12/12] Add git-check-ignore sub-command
On Mon, Oct 15, 2012 at 3:31 PM, Junio C Hamano wrote: > Nguyễn Thái Ngọc Duy 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: >> + >> + >> + >> + is the path of a file being queried, is the >> +matching pattern, is the pattern's source file, and >> +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. 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: [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 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
[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 --- 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
[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 --- 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 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 --- 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 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 --- 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 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 --- 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 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 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
Re: feature request
Am Tue, 16 Oct 2012 13:36:04 +0200 schrieb Angelo Borsotti : > 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
Re: [PATCH] Add --unannotate option to git-subtree
On Tue, Oct 9, 2012 at 4:26 PM, James Nylen 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 > --- 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=:: > + This option is only valid for the split command. > + > + When generating synthetic history, try to remove the prefix > +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 > + whenever you split, or you may run into problems. > + > -b :: > --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
[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 --- 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 2>&1 " - 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
[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 --- 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 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 --- 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
[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 --- 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 2>&1 " - 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 0/4] Allow different time commands
This mini series enables the use of the lazy prereq framework for tests which need a (non-builtin) time command. 1/4 is a bugfix 2/4 allows lazy prereq test scripts to set variables for later use 3/4 implements the prereq 4/4 uses it This should solve the problem reported by Joachim Schmitz. 3/4 could be done in various different ways, see the comments there. Michael J Gruber (4): t3419-rebase-patch-id: heed USR_BIN_TIME prereq test-lib: allow variable export from lazy prereq tests test-lib: provide lazy TIME_COMMAND prereq t3302,t3419: use the TIME_COMMAND prereq t/t3302-notes-index-expensive.sh | 5 ++--- t/t3419-rebase-patch-id.sh | 7 +++ t/test-lib-functions.sh | 6 -- t/test-lib.sh| 7 +++ 4 files changed, 16 insertions(+), 9 deletions(-) -- 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: 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 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
Re: [PATCH UI experiment] diffstat: annotate/highlight new or removed files
On Tue, Oct 16, 2012 at 4:03 AM, Junio C Hamano wrote: >> Coloring is to me an improvement over --summary. Probably the main >> point. Without it, perhaps it's not worth putting extra text to >> diffstat. > > It is kind of surprising that you did not choose to paint new in > green and gone in red, and rather paint everything in yellow. The colors of line addition and deletion? Nice. I just wanted to make sure these stand out, or at least not easily mistaken as part of path names. > I personally think the above in monochrome is fairly easy to read; > with coloring, it might become too distracting, though. Hmm.. maybe. I'm probably too excited to see the distraction just yet. I will try it out for longer time, see if I change my mind. > Just a nit, "new mode" is too similar to "new". Everything is "new" > in the sense that they have "new contents"; it may be better phrased > without saying "new" but giving a stress on "changed". I think "new mode" should be replaced by the actual mode change (e.g. "+x", "-x", or "mode +x", "mode -x"). Not too long and quite clear what it does. -- 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: [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 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
[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 --- 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: 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
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 wrote: >> Michael J Gruber 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: 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