Re: [RFC] Add basic syntax check on shell scripts
On 2012/12/04 20:39 , Junio C Hamano wrote: A few more things in addition to what Torsten's script attempts to catch that we would want to catch are: [...] > * Do not write ERE with backslashes and expect "grep" to grok them; > that's GNUism. e.g. > >grep "^\(author\|committer\) " > > is bad. Use egrep (or "grep -E") if you want to use ERE. Yet more thing that is probably worth catching, although not related to bashism: Avoid the use of "which" in favor of e.g. "type". In any case, having this check as a local pre-commit hook would be great! -- Sebastian Schuberth -- 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
Exploiting SHA1's "XOR weakness" allows for faster hash calculation
Hi, to say it in advance: I do not want to trigger any bogus security discussion here. Instead, I believe the findings from [1] allow for an up to 20% faster SHA1 calculation, if my brief reading of the presentation is correct. Any opinions on integration this optimization into Git? [1] https://hashcat.net/p12/js-sha1exp_169.pdf -- Sebastian Schuberth -- 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: Exploiting SHA1's "XOR weakness" allows for faster hash calculation
On Wed, Dec 5, 2012 at 11:19 AM, Sebastian Schuberth wrote: > to say it in advance: I do not want to trigger any bogus security discussion > here. Instead, I believe the findings from [1] allow for an up to 20% faster > SHA1 calculation, if my brief reading of the presentation is correct. Any > opinions on integration this optimization into Git? > > [1] https://hashcat.net/p12/js-sha1exp_169.pdf Pretty cool find. Although it's not actual cryptographic weakness, it does show some gaps in designers thinking - as there are simple optimizations available to crackers but not users. It does seem unusable for real implementation - the 20% win is available only after the data is processed properly once. Then after changing the data a little, you can calculate next hash faster. There still small possibility that there is way to optimize W calculation for the first run, but it does seem really hard, and even impossible while trying to keep the cache usage small. -- marko -- 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/4] git-svn: Document branches with at-sign(@).
git svn sometimes creates branches with an at-sign in the name (branchname@revision). These branches confuse many users and it is a FAQ why they are created. Document when git svn creates them. Signed-off-by: Sebastian Leske --- Documentation/git-svn.txt | 47 + 1 file changed, 47 insertions(+) diff --git a/Documentation/git-svn.txt b/Documentation/git-svn.txt index 8b0d3ad..55bed53 100644 --- a/Documentation/git-svn.txt +++ b/Documentation/git-svn.txt @@ -830,6 +830,53 @@ inside git back upstream to SVN users. Therefore it is advised that users keep history as linear as possible inside git to ease compatibility with SVN (see the CAVEATS section below). +HANDLING OF SVN BRANCHES + +If 'git svn' is configured to fetch branches (and --follow-branches +is in effect), it will sometimes create multiple git branches for one +SVN branch, where the addtional branches have names of the form +'branchname@nnn' (with nnn an SVN revision number). These additional +branches are created if 'git svn' cannot find a parent commit for the +first commit in an SVN branch, to connect the branch to the history of +the other branches. + +Normally, the first commit in an SVN branch consists +of a copy operation. 'git svn' will read this commit to get the SVN +revision the branch was created (copied) from. It will then try to find the +git commit that corresponds to this SVN revision, and use that as the +parent of the branch. However, it is possible that there is no suitable +git commit to serve as parent. This will happen, among other reasons, +if the SVN branch is a copy of a revision that was not fetched by 'git +svn' (e.g. because it is an old revision that was skipped with +'--revision'), or if in SVN a directory was copied that is not tracked +by 'git svn' (such as a branch that is not tracked at all, or a +subdirectory of a tracked branch). In these cases, 'git svn' will still +create a git branch, but instead of using an existing git commit as the +parent of the branch, it will read the SVN history of the directory the +branch was copied from and create appropriate git commits (this is +indicated by the message "Initializing parent: "). + +Additionally, it will create a special branch named +'@', where is the SVN revision +number the branch was copied from. This branch will point to the newly +created parent commit of the branch. If in SVN the branch was deleted +and later recreated from a different version, there will be multiple +such branches with an '@'. + +Note that this may mean that multiple git commits are created for a +single SVN revision. + +An example: In an SVN repository with a standard +trunk/tags/branches layout, a directory trunk/sub is created in r.100. +In r.200, trunk/sub is branched by copying it to branches/. 'git svn +clone -s' will then create a branch 'sub'. It will also create new git +commits for r.100 through r.199 and use these as the history of branch +'sub'. Thus there will be two git commits for each revision from r.100 +to r.199 (one containing trunk/, one containing trunk/sub/). Finally, +it will create a branch 'sub@200' pointing to the new parent commit of +branch 'sub' (i.e. the commit for r.200 and trunk/sub/). + CAVEATS --- -- 1.7.10.4 -- 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/4] git-svn: More docs for branch handling
Updated version of my documentation patch for git-svn. Thanks to Junio C Hamano for pointing out improvements. Sebastian Leske (4): git-svn: Document branches with at-sign(@). git-svn: Recommend use of structure options. git-svn: Expand documentation for --follow-parent git-svn: Note about tags. Documentation/git-svn.txt | 92 ++--- 1 file changed, 86 insertions(+), 6 deletions(-) -- 1.7.10.4 -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v3 2/4] git-svn: Recommend use of structure options.
Document that when using git svn, one should usually either use the directory structure options to import branches as branches, or only import one subdirectory. The default behaviour of cloning all branches and tags as subdirectories in the working copy is usually not what the user wants. Signed-off-by: Sebastian Leske --- Documentation/git-svn.txt | 24 +--- 1 file changed, 21 insertions(+), 3 deletions(-) diff --git a/Documentation/git-svn.txt b/Documentation/git-svn.txt index 55bed53..d8e5082 100644 --- a/Documentation/git-svn.txt +++ b/Documentation/git-svn.txt @@ -739,7 +739,8 @@ for rewriteRoot and rewriteUUID which can be used together. BASIC EXAMPLES -- -Tracking and contributing to the trunk of a Subversion-managed project: +Tracking and contributing to the trunk of a Subversion-managed project +(ignoring tags and branches): # Clone a repo (like git clone): @@ -764,8 +765,10 @@ Tracking and contributing to an entire Subversion-managed project (complete with a trunk, tags and branches): -# Clone a repo (like git clone): - git svn clone http://svn.example.com/project -T trunk -b branches -t tags +# Clone a repo with standard SVN directory layout (like git clone): + git svn clone http://svn.example.com/project --stdlayout +# Or, if the repo uses a non-standard directory layout: + git svn clone http://svn.example.com/project -T tr -b branch -t tag # View all branches and tags you have cloned: git branch -r # Create a new branch in SVN @@ -918,6 +921,21 @@ already dcommitted. It is considered bad practice to --amend commits you've already pushed to a remote repository for other users, and dcommit with SVN is analogous to that. +When cloning an SVN repository, if none of the options for describing +the repository layout is used (--trunk, --tags, --branches, +--stdlayout), 'git svn clone' will create a git repository with +completely linear history, where branches and tags appear as separate +directories in the working copy. While this is the easiest way to get a +copy of a complete repository, for projects with many branches it will +lead to a working copy many times larger than just the trunk. Thus for +projects using the standard directory structure (trunk/branches/tags), +it is recommended to clone with option '--stdlayout'. If the project +uses a non-standard structure, and/or if branches and tags are not +required, it is easiest to only clone one directory (typically trunk), +without giving any repository layout options. If the full history with +branches and tags is required, the options '--trunk' / '--branches' / +'--tags' must be used. + When using multiple --branches or --tags, 'git svn' does not automatically handle name collisions (for example, if two branches from different paths have the same name, or if a branch and a tag have the same name). In these cases, -- 1.7.10.4 -- 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 3/4] git-svn: Expand documentation for --follow-parent
Describe what the option --follow-parent does, and what happens if it is set or unset. Signed-off-by: Sebastian Leske --- Documentation/git-svn.txt | 15 --- 1 file changed, 12 insertions(+), 3 deletions(-) diff --git a/Documentation/git-svn.txt b/Documentation/git-svn.txt index d8e5082..021fb0e 100644 --- a/Documentation/git-svn.txt +++ b/Documentation/git-svn.txt @@ -628,10 +628,19 @@ ADVANCED OPTIONS Default: "svn" --follow-parent:: + This option is only relevant if we are tracking branches (using + one of the repository layout options --trunk, --tags, + --branches, --stdlayout). For each tracked branch, try to find + out where its revision was copied from, and set + a suitable parent in the first git commit for the branch. This is especially helpful when we're tracking a directory - that has been moved around within the repository, or if we - started tracking a branch and never tracked the trunk it was - descended from. This feature is enabled by default, use + that has been moved around within the repository. If this + feature is disabled, the branches created by 'git svn' will all + be linear and not share any history, meaning that there will be + no information on where branches were branched off or merged. + However, following long/convoluted histories can take a long + time, so disabling this feature may speed up the cloning + process. This feature is enabled by default, use --no-follow-parent to disable it. + [verse] -- 1.7.10.4 -- 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/4] git-svn: Note about tags.
Document that 'git svn' will import SVN tags as branches. Signed-off-by: Sebastian Leske --- Documentation/git-svn.txt |6 ++ 1 file changed, 6 insertions(+) diff --git a/Documentation/git-svn.txt b/Documentation/git-svn.txt index 021fb0e..445b033 100644 --- a/Documentation/git-svn.txt +++ b/Documentation/git-svn.txt @@ -968,6 +968,12 @@ the possible corner cases (git doesn't do it, either). Committing renamed and copied files is fully supported if they're similar enough for git to detect them. +In SVN, it is possible (though discouraged) to commit changes to a tag +(because a tag is just a directory copy, thus technically the same as a +branch). When cloning an SVN repository, 'git svn' cannot know if such a +commit to a tag will happen in the future. Thus it acts conservatively +and imports all SVN tags as branches, prefixing the tag name with 'tags/'. + CONFIGURATION - -- 1.7.10.4 -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC/PATCH 1/2] reset: learn to reset to tree
On Tue, Dec 4, 2012 at 9:46 PM, Junio C Hamano wrote: > Martin von Zweigbergk writes: > >> More importantly, when is it desirable not to delete deleted entries? > > When I am trying to check out contents of Documentation/ directory > as of an older edition because we made mistakes updating the files > in recent versions, with "git checkout v1.9.0 Documentation/", for > example. Perhaps somebody had this bright idea of reformatting our > docs with "= Newer Style =" section headers, replacing the underline > style, and we found our toolchain depend on the underline style, or > something. The new files in the same directory added since v1.9.0 > may share the same mistake as the files whose recent such changes I > am nuking with this operation, but that does not mean I want to > retype the contents of them from scratch; I'd rather keep them > around so that I can fix them up by hand. I think I follow, but why, then, would you not have the save problem with hunks *within* files that have been added in the new version? Or is the only change to Documentation/ since the "broken" commit that a new file has been added? That seems like a rather narrow use case in that case? "git checkout -p" seems more generally useful (whether that command deleted deleted files or not). It feels like I'm missing something... > I would have to say that it is more common; I do not recall a time I > wanted to replace everything in a directory (and only there without > touching other parts of the tree) with an old version, removing new > ones. It has happened a few times for me. I think this usually happens when I realize that I had a better solution for some subsystem (under some path) in some other branch (perhaps from a previous attempt at the same problem) or an in older commit. Knowing that "git checkout $rev $path" doesn't do what I expect and that "git reset --hard $rev $path" is not allowed, I think I would usually do "git reset $rev $path && git checkout $path". -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: remote-testsvn: Hangs at revision
On Wednesday, 5 December 2012 at 5:20 PM, Ramkumar Ramachandra wrote: > Hi, > > I tried out the testsvn remote helper on a simple Subversion > repository, but it seems to hang at Revision 8 indefinitely without > any indication of progress. I'm currently digging in to see what went > wrong. The repository I'm cloning is: > > $ git clone testsvn::http://python-lastfm.googlecode.com/svn/trunk/ I attempted to clone the same repository and was able to fetch 152 revisions. So the issue Ram saw might have been temporal. I did however receive a warning at the end of the clone: warning: remote HEAD refers to nonexistent ref, unable to checkout. -- David Michael Barr -- 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] mingw_rmdir: do not prompt for retry when non-empty
Sorry for a late reply.
On Tue, Dec 4, 2012 at 5:35 PM, Johannes Schindelin
wrote:
> Hi kusma,
>
> On Tue, 4 Dec 2012, Erik Faye-Lund wrote:
>
>> in ab1a11be ("mingw_rmdir: set errno=ENOTEMPTY when appropriate"),
>> a check was added to prevent us from retrying to delete a directory
>> that is both in use and non-empty.
>>
>> However, this logic was slightly flawed; since we didn't return
>> immediately, we end up falling out of the retry-loop, but right into
>> the prompting loop.
>>
>> Fix this by simply returning from the function instead of breaking
>> the loop.
>>
>> While we're at it, change the second break to a return as well; we
>> already know that we won't enter the prompting-loop, beacuse
>> is_file_in_use_error(GetLastError()) already evaluated to false.
>
> I usually prefer to break from the loop, to be able to add whatever
> cleanup code we might need in the future after the loop.
>
> So does this fix the problem for you?
>
> -- snipsnap --
> diff --git a/compat/mingw.c b/compat/mingw.c
> index 04af3dc..504495a 100644
> --- a/compat/mingw.c
> +++ b/compat/mingw.c
> @@ -259,7 +259,8 @@ int mingw_rmdir(const char *pathname)
> return -1;
>
> while ((ret = _wrmdir(wpathname)) == -1 && tries < ARRAY_SIZE(delay))
> {
> - if (!is_file_in_use_error(GetLastError()))
> + errno = err_win_to_posix(GetLastError());
> + if (errno != EACCESS)
> break;
> if (!is_dir_empty(wpathname)) {
> errno = ENOTEMPTY;
> @@ -275,7 +276,7 @@ int mingw_rmdir(const char *pathname)
> Sleep(delay[tries]);
> tries++;
> }
> - while (ret == -1 && is_file_in_use_error(GetLastError()) &&
> + while (ret == -1 && errno == EACCESS &&
>ask_yes_no_if_possible("Deletion of directory '%s' failed. "
> "Should I try again?", pathname))
>ret = _wrmdir(wpathname);
Yes, as long as you do s/EACCESS/EACCES/ first. I don't mind such a
version instead.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2] gitk: read and write a repository specific configuration file
On 12-12-04 07:49 PM, Łukasz Stelmach wrote: > Enable gitk read and write repository specific configuration > file: ".git/k" if the file exists. To make gitk use the local > file simply create one, e.g. with the touch(1) command. > > This is very useful if one uses different views for different > repositories. Now there is no need to store all of them in > ~/.gitk and make the views list needlesly long. s/needlesly/needlessly/ M. -- 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] mingw_rmdir: do not prompt for retry when non-empty
Hi kusma,
On Wed, 5 Dec 2012, Erik Faye-Lund wrote:
> Sorry for a late reply.
Yeah, sorry, my replies tend to be delayed a lot. For the record: your
reply was not at all late.
> On Tue, Dec 4, 2012 at 5:35 PM, Johannes Schindelin
> wrote:
> >
> > On Tue, 4 Dec 2012, Erik Faye-Lund wrote:
> >
> >> in ab1a11be ("mingw_rmdir: set errno=ENOTEMPTY when appropriate"), a
> >> check was added to prevent us from retrying to delete a directory
> >> that is both in use and non-empty.
> >>
> >> However, this logic was slightly flawed; since we didn't return
> >> immediately, we end up falling out of the retry-loop, but right into
> >> the prompting loop.
> >>
> >> Fix this by simply returning from the function instead of breaking
> >> the loop.
> >>
> >> While we're at it, change the second break to a return as well; we
> >> already know that we won't enter the prompting-loop, beacuse
> >> is_file_in_use_error(GetLastError()) already evaluated to false.
> >
> > I usually prefer to break from the loop, to be able to add whatever
> > cleanup code we might need in the future after the loop.
> >
> > So does this fix the problem for you?
> >
> > -- snipsnap --
> > diff --git a/compat/mingw.c b/compat/mingw.c
> > index 04af3dc..504495a 100644
> > --- a/compat/mingw.c
> > +++ b/compat/mingw.c
> > @@ -259,7 +259,8 @@ int mingw_rmdir(const char *pathname)
> > return -1;
> >
> > while ((ret = _wrmdir(wpathname)) == -1 && tries <
> > ARRAY_SIZE(delay)) {
> > - if (!is_file_in_use_error(GetLastError()))
> > + errno = err_win_to_posix(GetLastError());
> > + if (errno != EACCESS)
> > break;
> > if (!is_dir_empty(wpathname)) {
> > errno = ENOTEMPTY;
> > @@ -275,7 +276,7 @@ int mingw_rmdir(const char *pathname)
> > Sleep(delay[tries]);
> > tries++;
> > }
> > - while (ret == -1 && is_file_in_use_error(GetLastError()) &&
> > + while (ret == -1 && errno == EACCESS &&
> >ask_yes_no_if_possible("Deletion of directory '%s' failed. "
> > "Should I try again?", pathname))
> >ret = _wrmdir(wpathname);
>
> Yes, as long as you do s/EACCESS/EACCES/ first. I don't mind such a
> version instead.
As you probably suspected, I did not have a way to test-compile it before
sending.
The reason I was suggesting my version of the patch was to unify the error
handling: rather than relying on both errno and GetLastError() (but for
different error conditions), I would like to rely on only one: errno. That
way, they cannot contradict each other (as they did in your case).
However, I have no strong opinion on this, so please apply the version you
like better.
Ciao,
Dscho
--
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] Add basic syntax check on shell scripts
Jeff King writes: > You would want a "check shell script portability" script, and you would > probably want to run it: > > - on the regular built scripts; possibly during build time (I have done > this before with "perl -c" for perl scripts and it is reasonably > successful). Or in a test script, as added in his patch (though I > note it does not seem to pass as posted, getting confused by trying > to grep "git-gui"). > > - on the test scripts themselves via test-lint > > I think as long as such a script erred on the side of false negatives, > it would be OK (because false positives are a giant headache, and > ultimately the real test is people exercising the code itself on their > shells; this is just an early check to help contributors who do not have > such shells). Yeah, you have a good point that we should cover the scripts outside tests and test-lint is not a good match for them. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] mingw_rmdir: do not prompt for retry when non-empty
On Wed, Dec 5, 2012 at 5:02 PM, Johannes Schindelin
wrote:
> Hi kusma,
>
> On Wed, 5 Dec 2012, Erik Faye-Lund wrote:
>
>> Sorry for a late reply.
>
> Yeah, sorry, my replies tend to be delayed a lot. For the record: your
> reply was not at all late.
>
>> On Tue, Dec 4, 2012 at 5:35 PM, Johannes Schindelin
>> wrote:
>> >
>> > On Tue, 4 Dec 2012, Erik Faye-Lund wrote:
>> >
>> >> in ab1a11be ("mingw_rmdir: set errno=ENOTEMPTY when appropriate"), a
>> >> check was added to prevent us from retrying to delete a directory
>> >> that is both in use and non-empty.
>> >>
>> >> However, this logic was slightly flawed; since we didn't return
>> >> immediately, we end up falling out of the retry-loop, but right into
>> >> the prompting loop.
>> >>
>> >> Fix this by simply returning from the function instead of breaking
>> >> the loop.
>> >>
>> >> While we're at it, change the second break to a return as well; we
>> >> already know that we won't enter the prompting-loop, beacuse
>> >> is_file_in_use_error(GetLastError()) already evaluated to false.
>> >
>> > I usually prefer to break from the loop, to be able to add whatever
>> > cleanup code we might need in the future after the loop.
>> >
>> > So does this fix the problem for you?
>> >
>> > -- snipsnap --
>> > diff --git a/compat/mingw.c b/compat/mingw.c
>> > index 04af3dc..504495a 100644
>> > --- a/compat/mingw.c
>> > +++ b/compat/mingw.c
>> > @@ -259,7 +259,8 @@ int mingw_rmdir(const char *pathname)
>> > return -1;
>> >
>> > while ((ret = _wrmdir(wpathname)) == -1 && tries <
>> > ARRAY_SIZE(delay)) {
>> > - if (!is_file_in_use_error(GetLastError()))
>> > + errno = err_win_to_posix(GetLastError());
>> > + if (errno != EACCESS)
>> > break;
>> > if (!is_dir_empty(wpathname)) {
>> > errno = ENOTEMPTY;
>> > @@ -275,7 +276,7 @@ int mingw_rmdir(const char *pathname)
>> > Sleep(delay[tries]);
>> > tries++;
>> > }
>> > - while (ret == -1 && is_file_in_use_error(GetLastError()) &&
>> > + while (ret == -1 && errno == EACCESS &&
>> >ask_yes_no_if_possible("Deletion of directory '%s' failed. "
>> > "Should I try again?", pathname))
>> >ret = _wrmdir(wpathname);
>>
>> Yes, as long as you do s/EACCESS/EACCES/ first. I don't mind such a
>> version instead.
>
> As you probably suspected, I did not have a way to test-compile it before
> sending.
>
> The reason I was suggesting my version of the patch was to unify the error
> handling: rather than relying on both errno and GetLastError() (but for
> different error conditions), I would like to rely on only one: errno. That
> way, they cannot contradict each other (as they did in your case).
>
Since we're justifying the approaches, I'd like to explain why I
preferred the return approach: it performs less tests. While this
might sound like premature optimizations, performance is not why I
think it's a good idea. It makes the fix easier to verify; you don't
need to validate that the conditions of the second loop won't happen,
because the code exits quickly.
If we added something that required cleanup, we could change the
return to a goto with a cleanup-label, and it would still be
relatively easy to see what's going on.
> However, I have no strong opinion on this, so please apply the version you
> like better.
Since the issue is present in mainline Git as well, I'd prefer if
Junio merged whatever he prefers. I can produce a proper patch out of
your suggesting, if 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: git-svn with non-standard repository layout
On Tue, Dec 4, 2012 at 10:19 PM, Carsten Fuchs wrote: > Hi Piotr, > > Am 2012-12-04 18:29, schrieb Piotr Krukowiecki: > >> Is there a way to handle svn repository with following layout? >> >> repo/trunk >> repo/branches/branch1 >> repo/branches/branch2 >> repo/branches/work/developer1/branch3 >> repo/branches/work/developer1/branch4 >> repo/branches/work/developer2/branch5 > > see my post at > http://www.cafu.de/forum/viewtopic.php?f=14&t=1092 > heading "Branches outside branches/". > > You may need something like > git config --add svn-remote.svn.fetch > "path.../branchX:refs/remotes/branchX" > for each of your branches. Thanks, that works :) Although not an ideal solution - I have to manually configure all branches + update them as they are created -- Piotr Krukowiecki -- 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-svn with non-standard repository layout
- Original Message - > From: "Piotr Krukowiecki" > Sent: Wednesday, December 5, 2012 11:26:54 AM > Subject: Re: git-svn with non-standard repository layout > > On Tue, Dec 4, 2012 at 10:19 PM, Carsten Fuchs > wrote: > > Hi Piotr, > > > > Am 2012-12-04 18:29, schrieb Piotr Krukowiecki: > > > >> Is there a way to handle svn repository with following layout? > >> > >> repo/trunk > >> repo/branches/branch1 > >> repo/branches/branch2 > >> repo/branches/work/developer1/branch3 > >> repo/branches/work/developer1/branch4 > >> repo/branches/work/developer2/branch5 > > > > see my post at > > http://www.cafu.de/forum/viewtopic.php?f=14&t=1092 > > heading "Branches outside branches/". > > > > You may need something like > > git config --add svn-remote.svn.fetch > > "path.../branchX:refs/remotes/branchX" > > for each of your branches. > > that works :) > > Although not an ideal solution - I have to manually configure all > branches + update them as they are created It's not a 100% solution, but you can use a limited glob-like syntax in the branches and tags lines of the svn-remote config block. You still need to do some manual work (one entry for each developer), but the wildcards eliminate a lot of the grunt work as individual branches are created. See the very end of the git-svn manpage for examples (section titled CONFIGURATION). I use that technique to track a subdirectory of the Slimdevices SVN repo [1], which has a similarly complex layout: repo/7.1/trunk repo/7.1/branches/branchA repo/7.1/branches/branchB repo/7.1/tags/tag1 repo/7.2/trunk repo/7.2/branches/branchC ... HTH, Stephen -- 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] mingw_rmdir: do not prompt for retry when non-empty
Erik Faye-Lund writes: > On Wed, Dec 5, 2012 at 5:02 PM, Johannes Schindelin > wrote: > ... > Since we're justifying the approaches, I'd like to explain why I > preferred the return approach: it performs less tests. While this > might sound like premature optimizations, performance is not why I > think it's a good idea. It makes the fix easier to verify; you don't > need to validate that the conditions of the second loop won't happen, > because the code exits quickly. > > If we added something that required cleanup, we could change the > return to a goto with a cleanup-label, and it would still be > relatively easy to see what's going on. > >> However, I have no strong opinion on this, so please apply the version you >> like better. > > Since the issue is present in mainline Git as well, I'd prefer if > Junio merged whatever he prefers. I can produce a proper patch out of > your suggesting, if needed. Thanks; what you and Dscho agreed in this discussion sounds good to me, too. -- 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: Exploiting SHA1's "XOR weakness" allows for faster hash calculation
On Wed, Dec 05, 2012 at 10:19:43AM +0100, Sebastian Schuberth wrote: > > to say it in advance: I do not want to trigger any bogus security > discussion here. Instead, I believe the findings from [1] allow for > an up to 20% faster SHA1 calculation, if my brief reading of the > presentation is correct. Any opinions on integration this > optimization into Git? > > [1] https://hashcat.net/p12/js-sha1exp_169.pdf It's only useful if you are trying to do brute-force password cracking, where the password is being hashed in a very specific way. (If for example the password was replicated N times in the input buffer for SHA-1, instead of keeping the padding constant in the rest of theinput buffer, this particular optimization would't apply.) In any case, it's not at all applicable for general purpose checksum calculations, and hence wouldn't apply to git. Regards, - Ted -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [ANNOUNCE] Git v1.8.1-rc0
Junio C Hamano wrote:
> A release candidate preview, Git v1.8.1-rc0, is now available for
> testing at the usual places.
>
> This cycle has been a bit slow (perhaps because it had a major US
> holiday to slow people down) but we seem to have managed to apply
> reasonably large number of usability improvement changes, with a
> handful of new features. There are several new and large-ish topics
> that are cooking in 'next', but I think we would better keep them
> cooking there without merging them to 'master' before the upcoming
> release to happen before the year end. So as far as features goes,
> this preview release is pretty much *it*.
>
> The release tarballs are found at:
>
> http://code.google.com/p/git-core/downloads/list
>
> and their SHA-1 checksums are:
>
> 39faaa15bc71f8eb52048e77ea564cecf78c7adf git-1.8.1.rc0.tar.gz
> 2eeba24488337de02b58dc442258d58b79e2b8f4 git-htmldocs-1.8.1.rc0.tar.gz
> b28d1f8e8b9268b712b33fbdfb67dd6f14afb499 git-manpages-1.8.1.rc0.tar.gz
>
> Also the following public repositories all have a copy of the v1.8.1-rc0
> tag and the master branch that the tag points at:
>
> url = git://repo.or.cz/alt-git.git
> url = https://code.google.com/p/git-core/
> url = git://git.sourceforge.jp/gitroot/git-core/git.git
> url = git://git-core.git.sourceforge.net/gitroot/git-core/git-core
> url = https://github.com/gitster/git
>
I fetch git from 'git://git.kernel.org/pub/scm/git/git.git' which has
commit ee26a6e2 ("Git 1.8.1-rc0", 03-12-2012), but is missing the v1.8.1-rc0
tag. Is this just an oversight (the above list suggests not), or should I not
be using kernel.org?
ATB,
Ramsay Jones
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [ANNOUNCE] Git v1.8.1-rc0
Ramsay Jones writes:
> I fetch git from 'git://git.kernel.org/pub/scm/git/git.git' which has
> commit ee26a6e2 ("Git 1.8.1-rc0", 03-12-2012), but is missing the v1.8.1-rc0
> tag. Is this just an oversight ...
Thanks for letting me know; forgot to push out the tag.
--
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 1/4] git-svn: Document branches with at-sign(@).
Sebastian Leske writes: > git svn sometimes creates branches with an at-sign in the name > (branchname@revision). These branches confuse many users and it is a FAQ > why they are created. Document when git svn creates them. > > Signed-off-by: Sebastian Leske > --- > Documentation/git-svn.txt | 47 > + > 1 file changed, 47 insertions(+) Thanks. Your hunk header says that there should be 53 lines in the postimage, but there actually are only 52. I'll hand-tweak the message and apply. > diff --git a/Documentation/git-svn.txt b/Documentation/git-svn.txt > index 8b0d3ad..55bed53 100644 > --- a/Documentation/git-svn.txt > +++ b/Documentation/git-svn.txt > @@ -830,6 +830,53 @@ inside git back upstream to SVN users. Therefore it is > advised that > users keep history as linear as possible inside git to ease > compatibility with SVN (see the CAVEATS section below). > > +HANDLING OF SVN BRANCHES > + > +If 'git svn' is configured to fetch branches (and --follow-branches > +is in effect), it will sometimes create multiple git branches for one > +SVN branch, where the addtional branches have names of the form > +'branchname@nnn' (with nnn an SVN revision number). These additional > +branches are created if 'git svn' cannot find a parent commit for the > +first commit in an SVN branch, to connect the branch to the history of > +the other branches. > + > +Normally, the first commit in an SVN branch consists > +of a copy operation. 'git svn' will read this commit to get the SVN > +revision the branch was created (copied) from. It will then try to find the > +git commit that corresponds to this SVN revision, and use that as the > +parent of the branch. However, it is possible that there is no suitable > +git commit to serve as parent. This will happen, among other reasons, > +if the SVN branch is a copy of a revision that was not fetched by 'git > +svn' (e.g. because it is an old revision that was skipped with > +'--revision'), or if in SVN a directory was copied that is not tracked > +by 'git svn' (such as a branch that is not tracked at all, or a > +subdirectory of a tracked branch). In these cases, 'git svn' will still > +create a git branch, but instead of using an existing git commit as the > +parent of the branch, it will read the SVN history of the directory the > +branch was copied from and create appropriate git commits (this is > +indicated by the message "Initializing parent: "). > + > +Additionally, it will create a special branch named > +'@', where is the SVN revision > +number the branch was copied from. This branch will point to the newly > +created parent commit of the branch. If in SVN the branch was deleted > +and later recreated from a different version, there will be multiple > +such branches with an '@'. > + > +Note that this may mean that multiple git commits are created for a > +single SVN revision. > + > +An example: In an SVN repository with a standard > +trunk/tags/branches layout, a directory trunk/sub is created in r.100. > +In r.200, trunk/sub is branched by copying it to branches/. 'git svn > +clone -s' will then create a branch 'sub'. It will also create new git > +commits for r.100 through r.199 and use these as the history of branch > +'sub'. Thus there will be two git commits for each revision from r.100 > +to r.199 (one containing trunk/, one containing trunk/sub/). Finally, > +it will create a branch 'sub@200' pointing to the new parent commit of > +branch 'sub' (i.e. the commit for r.200 and trunk/sub/). > + > CAVEATS > --- -- 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] Perform minimal stat comparison when some stat fields are not set
At least JGit does sets uid, gid, ctime, ino and dev fields to zero
on update. To Git this looks like the stat data does not match and
a full file compare will be forced even it size and mtime match. This
is in practice unnecessary. Sense JGit's presence by checking if ino
and dev is zero.
Signed-off-by: Robin Rosenberg
---
read-cache.c | 21 +
1 file changed, 13 insertions(+), 8 deletions(-)
diff --git a/read-cache.c b/read-cache.c
index fda78bc..6f13a22 100644
--- a/read-cache.c
+++ b/read-cache.c
@@ -197,21 +197,26 @@ static int ce_match_stat_basic(struct cache_entry *ce,
struct stat *st)
}
if (ce->ce_mtime.sec != (unsigned int)st->st_mtime)
changed |= MTIME_CHANGED;
- if (trust_ctime && ce->ce_ctime.sec != (unsigned int)st->st_ctime)
+
+ int minimal_stat = (ce->ce_ino == 0 && ce->ce_dev == 0);
+
+ if (trust_ctime && !minimal_stat && ce->ce_ctime.sec != (unsigned
int)st->st_ctime)
changed |= CTIME_CHANGED;
#ifdef USE_NSEC
if (ce->ce_mtime.nsec != ST_MTIME_NSEC(*st))
changed |= MTIME_CHANGED;
- if (trust_ctime && ce->ce_ctime.nsec != ST_CTIME_NSEC(*st))
+ if (trust_ctime && !minimal_stat && ce->ce_ctime.nsec !=
ST_CTIME_NSEC(*st))
changed |= CTIME_CHANGED;
#endif
- if (ce->ce_uid != (unsigned int) st->st_uid ||
- ce->ce_gid != (unsigned int) st->st_gid)
- changed |= OWNER_CHANGED;
- if (ce->ce_ino != (unsigned int) st->st_ino)
- changed |= INODE_CHANGED;
+ if (!minimal_stat) {
+ if (ce->ce_uid != (unsigned int) st->st_uid ||
+ ce->ce_gid != (unsigned int) st->st_gid)
+ changed |= OWNER_CHANGED;
+ if (ce->ce_ino != 0 && ce->ce_ino != (unsigned int) st->st_ino)
+ changed |= INODE_CHANGED;
+ }
#ifdef USE_STDEV
/*
@@ -219,7 +224,7 @@ static int ce_match_stat_basic(struct cache_entry *ce,
struct stat *st)
* clients will have different views of what "device"
* the filesystem is on
*/
- if (ce->ce_dev != (unsigned int) st->st_dev)
+ if (!minimal_stat && ce->ce_dev != (unsigned int) st->st_dev)
changed |= INODE_CHANGED;
#endif
--
1.8.0.msysgit.0.dirty
--
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 1/4] git-svn: Document branches with at-sign(@).
Junio C Hamano wrote: > Sebastian Leske writes: > > --- > > Documentation/git-svn.txt | 47 > > + > > 1 file changed, 47 insertions(+) > > Thanks. Your hunk header says that there should be 53 lines in the > postimage, but there actually are only 52. I'll hand-tweak the > message and apply. Thanks all, this series Acked-by: Eric Wong -- 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] Add directory pattern matching to attributes
The manpage of gitattributes says: "The rules how the pattern
matches paths are the same as in .gitignore files" and the gitignore
pattern rules has a pattern ending with / for directory matching.
This rule is specifically relevant for the 'export-ignore' rule used
for git archive.
Signed-off-by: Jean-Noel Avila
---
archive.c |2 +-
attr.c | 47 -
attr.h |4 ++--
builtin/check-attr.c|7 --
builtin/pack-objects.c |2 +-
convert.c |2 +-
ll-merge.c |4 ++--
t/t5002-archive-attr-pattern.sh | 49 +++
userdiff.c |2 +-
ws.c|2 +-
10 files changed, 94 insertions(+), 27 deletions(-)
create mode 100644 t/t5002-archive-attr-pattern.sh
diff --git a/archive.c b/archive.c
index 4666404..b8ff14f 100644
--- a/archive.c
+++ b/archive.c
@@ -123,7 +123,7 @@ static int write_archive_entry(const unsigned char *sha1,
const char *base,
path_without_prefix = path.buf + args->baselen;
setup_archive_check(check);
- if (!git_check_attr(path_without_prefix, ARRAY_SIZE(check), check)) {
+ if (!git_check_attr(path_without_prefix, mode, ARRAY_SIZE(check),
check)) {
if (ATTR_TRUE(check[0].value))
return 0;
args->convert = ATTR_TRUE(check[1].value);
diff --git a/attr.c b/attr.c
index 887a9ae..da386f2 100644
--- a/attr.c
+++ b/attr.c
@@ -548,7 +548,7 @@ static void bootstrap_attr_stack(void)
attr_stack = elem;
}
-static void prepare_attr_stack(const char *path)
+static void prepare_attr_stack(const char *path, unsigned mode)
{
struct attr_stack *elem, *info;
int dirlen, len;
@@ -645,28 +645,43 @@ static void prepare_attr_stack(const char *path)
}
static int path_matches(const char *pathname, int pathlen,
- const char *pattern,
+ const unsigned mode, char *pattern,
const char *base, int baselen)
{
- if (!strchr(pattern, '/')) {
+ size_t len;
+ char buf[PATH_MAX];
+ char * lpattern = buf;
+ len = strlen(pattern);
+ if (PATH_MAX <= len)
+ return 0;
+ strncpy(buf,pattern,len);
+ buf[len] ='\0';
+ if (len && lpattern[len - 1] == '/') {
+ if (S_ISDIR(mode))
+ lpattern[len - 1] = '\0';
+ else
+ return 0;
+ }
+
+ if (!strchr(lpattern, '/')) {
/* match basename */
const char *basename = strrchr(pathname, '/');
basename = basename ? basename + 1 : pathname;
- return (fnmatch_icase(pattern, basename, 0) == 0);
+ return (fnmatch_icase(lpattern, basename, 0) == 0);
}
/*
* match with FNM_PATHNAME; the pattern has base implicitly
* in front of it.
*/
- if (*pattern == '/')
- pattern++;
+ if (*lpattern == '/')
+ lpattern++;
if (pathlen < baselen ||
(baselen && pathname[baselen] != '/') ||
strncmp(pathname, base, baselen))
return 0;
if (baselen != 0)
baselen++;
- return fnmatch_icase(pattern, pathname + baselen, FNM_PATHNAME) == 0;
+ return fnmatch_icase(lpattern, pathname + baselen, FNM_PATHNAME) == 0;
}
static int macroexpand_one(int attr_nr, int rem);
@@ -693,7 +708,7 @@ static int fill_one(const char *what, struct match_attr *a,
int rem)
return rem;
}
-static int fill(const char *path, int pathlen, struct attr_stack *stk, int rem)
+static int fill(const char *path, int pathlen, unsigned mode, struct
attr_stack *stk, int rem)
{
int i;
const char *base = stk->origin ? stk->origin : "";
@@ -702,7 +717,7 @@ static int fill(const char *path, int pathlen, struct
attr_stack *stk, int rem)
struct match_attr *a = stk->attrs[i];
if (a->is_macro)
continue;
- if (path_matches(path, pathlen,
+ if (path_matches(path, pathlen, mode,
a->u.pattern, base, strlen(base)))
rem = fill_one("fill", a, rem);
}
@@ -737,26 +752,26 @@ static int macroexpand_one(int attr_nr, int rem)
* Collect all attributes for path into the array pointed to by
* check_all_attr.
*/
-static void collect_all_attrs(const char *path)
+static void collect_all_attrs(const char *path, unsigned mode)
{
struct attr_stack *stk;
int i, pathlen, rem;
- prepare_attr_stack(path);
+ prepare_attr_stack(path, mode);
for (i = 0; i < attr_nr; i++)
check_all_attr[i].value = ATTR__UNKNOWN;
pathl
[PATCH] Add directory pattern matching to attributes
The manpage of gitattributes says: "The rules how the pattern
matches paths are the same as in .gitignore files" and the gitignore
pattern rules has a pattern ending with / for directory matching.
This rule is specifically relevant for the 'export-ignore' rule used
for git archive.
Signed-off-by: Jean-Noel Avila
---
archive.c |2 +-
attr.c | 47 -
attr.h |4 ++--
builtin/check-attr.c|7 --
builtin/pack-objects.c |2 +-
convert.c |2 +-
ll-merge.c |4 ++--
t/t5002-archive-attr-pattern.sh | 49 +++
userdiff.c |2 +-
ws.c|2 +-
10 files changed, 94 insertions(+), 27 deletions(-)
create mode 100644 t/t5002-archive-attr-pattern.sh
diff --git a/archive.c b/archive.c
index 4666404..b8ff14f 100644
--- a/archive.c
+++ b/archive.c
@@ -123,7 +123,7 @@ static int write_archive_entry(const unsigned char *sha1,
const char *base,
path_without_prefix = path.buf + args->baselen;
setup_archive_check(check);
- if (!git_check_attr(path_without_prefix, ARRAY_SIZE(check), check)) {
+ if (!git_check_attr(path_without_prefix, mode, ARRAY_SIZE(check),
check)) {
if (ATTR_TRUE(check[0].value))
return 0;
args->convert = ATTR_TRUE(check[1].value);
diff --git a/attr.c b/attr.c
index 887a9ae..da386f2 100644
--- a/attr.c
+++ b/attr.c
@@ -548,7 +548,7 @@ static void bootstrap_attr_stack(void)
attr_stack = elem;
}
-static void prepare_attr_stack(const char *path)
+static void prepare_attr_stack(const char *path, unsigned mode)
{
struct attr_stack *elem, *info;
int dirlen, len;
@@ -645,28 +645,43 @@ static void prepare_attr_stack(const char *path)
}
static int path_matches(const char *pathname, int pathlen,
- const char *pattern,
+ const unsigned mode, char *pattern,
const char *base, int baselen)
{
- if (!strchr(pattern, '/')) {
+ size_t len;
+ char buf[PATH_MAX];
+ char * lpattern = buf;
+ len = strlen(pattern);
+ if (PATH_MAX <= len)
+ return 0;
+ strncpy(buf,pattern,len);
+ buf[len] ='\0';
+ if (len && lpattern[len - 1] == '/') {
+ if (S_ISDIR(mode))
+ lpattern[len - 1] = '\0';
+ else
+ return 0;
+ }
+
+ if (!strchr(lpattern, '/')) {
/* match basename */
const char *basename = strrchr(pathname, '/');
basename = basename ? basename + 1 : pathname;
- return (fnmatch_icase(pattern, basename, 0) == 0);
+ return (fnmatch_icase(lpattern, basename, 0) == 0);
}
/*
* match with FNM_PATHNAME; the pattern has base implicitly
* in front of it.
*/
- if (*pattern == '/')
- pattern++;
+ if (*lpattern == '/')
+ lpattern++;
if (pathlen < baselen ||
(baselen && pathname[baselen] != '/') ||
strncmp(pathname, base, baselen))
return 0;
if (baselen != 0)
baselen++;
- return fnmatch_icase(pattern, pathname + baselen, FNM_PATHNAME) == 0;
+ return fnmatch_icase(lpattern, pathname + baselen, FNM_PATHNAME) == 0;
}
static int macroexpand_one(int attr_nr, int rem);
@@ -693,7 +708,7 @@ static int fill_one(const char *what, struct match_attr *a,
int rem)
return rem;
}
-static int fill(const char *path, int pathlen, struct attr_stack *stk, int rem)
+static int fill(const char *path, int pathlen, unsigned mode, struct
attr_stack *stk, int rem)
{
int i;
const char *base = stk->origin ? stk->origin : "";
@@ -702,7 +717,7 @@ static int fill(const char *path, int pathlen, struct
attr_stack *stk, int rem)
struct match_attr *a = stk->attrs[i];
if (a->is_macro)
continue;
- if (path_matches(path, pathlen,
+ if (path_matches(path, pathlen, mode,
a->u.pattern, base, strlen(base)))
rem = fill_one("fill", a, rem);
}
@@ -737,26 +752,26 @@ static int macroexpand_one(int attr_nr, int rem)
* Collect all attributes for path into the array pointed to by
* check_all_attr.
*/
-static void collect_all_attrs(const char *path)
+static void collect_all_attrs(const char *path, unsigned mode)
{
struct attr_stack *stk;
int i, pathlen, rem;
- prepare_attr_stack(path);
+ prepare_attr_stack(path, mode);
for (i = 0; i < attr_nr; i++)
check_all_attr[i].value = ATTR__UNKNOWN;
pathl
Re: git-svn with non-standard repository layout
On Wed, Dec 5, 2012 at 5:44 PM, Stephen Bash wrote:
> - Original Message -
>> From: "Piotr Krukowiecki"
>> Sent: Wednesday, December 5, 2012 11:26:54 AM
>> Subject: Re: git-svn with non-standard repository layout
>>
>> On Tue, Dec 4, 2012 at 10:19 PM, Carsten Fuchs
>> wrote:
>> > Hi Piotr,
>> >
>> > Am 2012-12-04 18:29, schrieb Piotr Krukowiecki:
>> >
>> >> Is there a way to handle svn repository with following layout?
>> >>
>> >> repo/trunk
>> >> repo/branches/branch1
>> >> repo/branches/branch2
>> >> repo/branches/work/developer1/branch3
>> >> repo/branches/work/developer1/branch4
>> >> repo/branches/work/developer2/branch5
>> >
>> > see my post at
>> > http://www.cafu.de/forum/viewtopic.php?f=14&t=1092
>> > heading "Branches outside branches/".
>> >
>> > You may need something like
>> > git config --add svn-remote.svn.fetch
>> > "path.../branchX:refs/remotes/branchX"
>> > for each of your branches.
>>
>> that works :)
>>
>> Although not an ideal solution - I have to manually configure all
>> branches + update them as they are created
>
> It's not a 100% solution, but you can use a limited glob-like syntax in the
> branches and tags lines of the svn-remote config block. You still need to do
> some manual work (one entry for each developer), but the wildcards eliminate
> a lot of the grunt work as individual branches are created. See the very end
> of the git-svn manpage for examples (section titled CONFIGURATION). I use
> that technique to track a subdirectory of the Slimdevices SVN repo [1], which
> has a similarly complex layout:
>
> repo/7.1/trunk
> repo/7.1/branches/branchA
> repo/7.1/branches/branchB
> repo/7.1/tags/tag1
> repo/7.2/trunk
> repo/7.2/branches/branchC
Do you mean something like
branches = branches/work/*/*:refs/remotes/work/*
branches = branches/{branch1,branch2}:refs/remotes/branches/*
instead of (currently used)
branches = branches/work/*/*:refs/remotes/work/*
fetch = branches/branch1:refs/remotes/branches/branch1
fetch = branches/branch2:refs/remotes/branches/branch2
I will try that tomorrow.
BTW what's the difference between "fetch" and "branches" keys? I could
only find one: "fetch" does not support glob arguments and "branches"
do.
--
Piotr Krukowiecki
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] RFC Optionally handle symbolic links as copies
If core.symlinks is set to copy then symbolic links in a git repository
will be checked out as copies of the file it points to. This allows repos
containing symbolic links to not only be checked out, but also that the
linked content may be used on OS:es and filesystems that do not support
symbolic links.
Plain files will be copied as hard links, directories will be replicated
with files as hard links. Stale links will not be copied and will appear
as missing files.
A git-ln utility whose usage is similar to the standard ln utilty. It will
create symbolic links unless core.symlinks is set to copy.
This patch still contains debug statements and open issues:
- git rm link-to-dir - remove without force or compare
- git status - when do we report a diff.
- After checkout we should probably not
- if the "linked" files change?
- if a change in the copied directory chsnges
- if a file in the copied diretory is added/removed
- update, should we update the copied structure automatically
when the link target changes
- git add - just ignore the stat diff for links
- git xxx -- gotchas
- ugly code
- debug statements
- few test cases
---
.gitignore | 1 +
Makefile| 10 +-
builtin/checkout-index.c| 1 +
builtin/checkout.c | 2 +
builtin/rm.c| 17 ++-
cache.h | 3 +
command-list.txt| 1 +
config.c| 8 +-
entry.c | 238 +++-
environment.c | 1 +
git-ln.sh | 132
read-cache.c| 60 +
t/t2401-checkout-symlink-as-copy.sh | 142 +
unpack-trees.c | 11 ++
wrapper.c | 19 ++-
15 files changed, 611 insertions(+), 35 deletions(-)
create mode 100755 git-ln.sh
create mode 100755 t/t2401-checkout-symlink-as-copy.sh
diff --git a/.gitignore b/.gitignore
index 5778ce1..0c82778 100644
--- a/.gitignore
+++ b/.gitignore
@@ -72,6 +72,7 @@
/git-init
/git-init-db
/git-instaweb
+/git-ln
/git-log
/git-lost-found
/git-ls-files
diff --git a/Makefile b/Makefile
index 1cff01e..3660597 100644
--- a/Makefile
+++ b/Makefile
@@ -341,10 +341,15 @@ endif
# CFLAGS and LDFLAGS are for the users to override from the command line.
-CFLAGS = -g -O2 -Wall -Werror \
+CFLAGS = -g -Wall -Werror \
-Wno-pointer-to-int-cast \
-Wold-style-definition \
- -Wdeclaration-after-statement
+ -Wdeclaration-after-statement \
+ -Wno-deprecated-declarations \
+ -Wstrict-prototypes \
+ -Wdeclaration-after-statement \
+ -Wno-pointer-to-int-cast \
+
LDFLAGS =
ALL_CFLAGS = $(CPPFLAGS) $(CFLAGS)
ALL_LDFLAGS = $(LDFLAGS)
@@ -442,6 +447,7 @@ SCRIPT_SH += git-bisect.sh
SCRIPT_SH += git-difftool--helper.sh
SCRIPT_SH += git-filter-branch.sh
SCRIPT_SH += git-lost-found.sh
+SCRIPT_SH += git-ln.sh
SCRIPT_SH += git-merge-octopus.sh
SCRIPT_SH += git-merge-one-file.sh
SCRIPT_SH += git-merge-resolve.sh
diff --git a/builtin/checkout-index.c b/builtin/checkout-index.c
index b1feda7..aa840b7 100644
--- a/builtin/checkout-index.c
+++ b/builtin/checkout-index.c
@@ -113,6 +113,7 @@ static void checkout_all(const char *prefix, int
prefix_length)
errs++;
last_ce = ce;
}
+ checkout_remaining_link_copies();
if (last_ce && to_tempfile)
write_tempfile_record(last_ce->name, prefix_length);
if (errs)
diff --git a/builtin/checkout.c b/builtin/checkout.c
index 781295b..eafd3d5 100644
--- a/builtin/checkout.c
+++ b/builtin/checkout.c
@@ -328,6 +328,8 @@ static int checkout_paths(const struct checkout_opts *opts,
}
}
+ checkout_remaining_link_copies();
+
if (write_cache(newfd, active_cache, active_nr) ||
commit_locked_index(lock_file))
die(_("unable to write new index file"));
diff --git a/builtin/rm.c b/builtin/rm.c
index b384c4c..14fb399 100644
--- a/builtin/rm.c
+++ b/builtin/rm.c
@@ -17,6 +17,8 @@ static const char * const builtin_rm_usage[] = {
static struct {
int nr, alloc;
+ int nrmode, allocmode;
+ int *mode;
const char **name;
} list;
@@ -174,7 +176,10 @@ int cmd_rm(int argc, const char **argv, const char *prefix)
if (!match_pathspec(pathspec, ce->name, ce_namelen(ce), 0,
seen))
continue;
ALLOC_GROW(list.name, list.nr + 1, list.alloc);
- list.name[list.nr++] = ce->name;
+ ALLOC_GROW(list.mode, list.nrmode + 1, list.allocmode); // ugly
+ list.name[list.nr] = ce->name;
+ list.mode[list.nr] = ce->ce_mode;
+ list.nr++;
}
if (pathsp
Re: [PATCH] Add directory pattern matching to attributes
"Jean-Noël AVILA" writes:
> -static void prepare_attr_stack(const char *path)
> +static void prepare_attr_stack(const char *path, unsigned mode)
> {
> struct attr_stack *elem, *info;
> int dirlen, len;
> @@ -645,28 +645,43 @@ static void prepare_attr_stack(const char *path)
> }
Why?
The new "mode" parameter does not seem to be used in this function
at all.
> static int path_matches(const char *pathname, int pathlen,
> - const char *pattern,
> + const unsigned mode, char *pattern,
> const char *base, int baselen)
> {
> - if (!strchr(pattern, '/')) {
> + size_t len;
> + char buf[PATH_MAX];
> + char * lpattern = buf;
> + len = strlen(pattern);
> + if (PATH_MAX <= len)
> + return 0;
> + strncpy(buf,pattern,len);
> + buf[len] ='\0';
> + if (len && lpattern[len - 1] == '/') {
> + if (S_ISDIR(mode))
> + lpattern[len - 1] = '\0';
> + else
> + return 0;
> + }
> + if (!strchr(lpattern, '/')) {
> /* match basename */
> const char *basename = strrchr(pathname, '/');
> basename = basename ? basename + 1 : pathname;
> - return (fnmatch_icase(pattern, basename, 0) == 0);
> + return (fnmatch_icase(lpattern, basename, 0) == 0);
> }
> /*
>* match with FNM_PATHNAME; the pattern has base implicitly
>* in front of it.
>*/
> - if (*pattern == '/')
> - pattern++;
> + if (*lpattern == '/')
> + lpattern++;
> if (pathlen < baselen ||
> (baselen && pathname[baselen] != '/') ||
> strncmp(pathname, base, baselen))
> return 0;
> if (baselen != 0)
> baselen++;
> - return fnmatch_icase(pattern, pathname + baselen, FNM_PATHNAME) == 0;
> + return fnmatch_icase(lpattern, pathname + baselen, FNM_PATHNAME) == 0;
> }
It appears to me that you are forcing the caller to tell this
function if the path is a directory, but in the attribute system,
the caller does not necessarily know if the path it is passing is
meant to be a directory or a regular file. "check-attr" is meant to
be usable against a path that does not even exist on the working
tree, so using stat() or lstat() in it is not a solution. In other
words, it is unfair (read: unworkable) to force it to append a
trailing slash after the path it calls this function with.
If you are interested in export-subst, all is not lost, though:
$ git init
$ mkdir a
$ >a/b
$ echo a export-ignore >.gitattributes
$ git add a/b .gitattributes
$ git commit -m initial
$ git archive HEAD | tar tf -
.gitattributes
$ exit
You could change the "echo" to
$ echo "a/*" export-ignore >.gitattributes
as well, but it seems to create an useless empty directory "a/" in
the output, which I think is an unrelated bug in "git archive".
This patch seems to be based on a stale codebase. I do not think
I'd be opposed to change the sementics to allow the callers that
know that a path is a directory to optionally pass mode parameter by
ending the pathname with slash (in other words, have "git
check-attr" ask about a directory 'a' by saying "git check-attr
export-subst a/", and lose the "mode" argument in this patch), or
keep the "mode" parameter and instead allow "git check-attr" to ask
about a directory that does not exist in the working tree by a more
explicit "git check-attr --directory export-ignore a" or something.
Such an enhancement should be done on top of the current codebase.
Thanks.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] Perform minimal stat comparison when some stat fields are not set
Robin Rosenberg writes: > At least JGit does sets uid, gid, ctime, ino and dev fields to zero > on update. To Git this looks like the stat data does not match and > a full file compare will be forced even it size and mtime match. This > is in practice unnecessary. Sense JGit's presence by checking if ino > and dev is zero. > > Signed-off-by: Robin Rosenberg > --- > read-cache.c | 21 + > 1 file changed, 13 insertions(+), 8 deletions(-) > > diff --git a/read-cache.c b/read-cache.c > index fda78bc..6f13a22 100644 > --- a/read-cache.c > +++ b/read-cache.c > @@ -197,21 +197,26 @@ static int ce_match_stat_basic(struct cache_entry *ce, > struct stat *st) > } > if (ce->ce_mtime.sec != (unsigned int)st->st_mtime) > changed |= MTIME_CHANGED; > - if (trust_ctime && ce->ce_ctime.sec != (unsigned int)st->st_ctime) > + > + int minimal_stat = (ce->ce_ino == 0 && ce->ce_dev == 0); decl-after-stmt. Besides, is it sane to do this unconditionally to affect people who do not use JGit? -- 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: Millisecond precision in timestamps?
- Ursprungligt meddelande - > On Tue, Nov 27, 2012 at 11:58 PM, Eric S. Raymond > wrote: > > Junio C Hamano : > >> Roundtrip conversions may benefit from sub-second timestamps, but > >> personally I think negative timestamps are more interesting and of > >> practical use. > > > > You mean, as in times before the Unix epoch 1970-01-01T00:00:00Z? > > > > Interesting. I hadn't thought of that. I've never seen a software > > project under version control with bits that old, which is > > significant > > because I've probably done more digging into ancient software than > > anybody other than a specialist historian or two. > > One example I've heard is someone wanting to throw the history > of a country's laws into git so they can diff them. Not sure any laws were passed on Feb 30th 1712 in sweden, but perhaps you can define new time zones to handle that, but I doubt it is practically doable when you get to countries and regions with less precise boundaries. Seconds-since as a representation for dates is a dangerous and very messy game. Java gets it wrong somewhere in 1910 and my guess is others get it wrong too. There is change in time zones which triggers the bug. -- robin -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] RFC Optionally handle symbolic links as copies
Robin Rosenberg writes: > If core.symlinks is set to copy then symbolic links in a git repository > will be checked out as copies of the file it points to. That all sounds nice on surface when the primary thing you care about is to fetch and check out other people's code and extract it to the working tree, but how well would that work on the checkin side? What happens if I check out a symlink that points at a file (either in-tree or out-of-tree), make some changes that do not involve the symlink, and before I make the commit, an unrelated change is made to the file the symlink is pointing at? > - git status - when do we report a diff. > - After checkout we should probably not > - if the "linked" files change? Yeah, exactly. > - if a change in the copied directory chsnges That, too. > - if a file in the copied diretory is added/removed > - update, should we update the copied structure automatically > when the link target changes I personally do not think this is worth it. It would be very useful on the export/checkout side, so it may make sense to add it to "git archive", 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: git-svn with non-standard repository layout
- Original Message -
> From: "Piotr Krukowiecki"
> Sent: Wednesday, December 5, 2012 5:19:44 PM
> Subject: Re: git-svn with non-standard repository layout
>
> Do you mean something like
>
>branches = branches/work/*/*:refs/remotes/work/*
>branches = branches/{branch1,branch2}:refs/remotes/branches/*
>
> instead of (currently used)
>
>branches = branches/work/*/*:refs/remotes/work/*
>fetch = branches/branch1:refs/remotes/branches/branch1
>fetch = branches/branch2:refs/remotes/branches/branch2
Essentially yes. But I guess since you have branches at the same level as the
work directory, you either have to add to the glob for each new branch or add
another fetch line... Doesn't seem like a big win to me. Jumping on a
tangent, I thought there could only be one wildcard on the left side of the ':'
(and the '*' on the right). If your work/*/* is actually working, that's quite
interesting.
> BTW what's the difference between "fetch" and "branches" keys? I could
> only find one: "fetch" does not support glob arguments and "branches"
> do.
That's the only difference I've discovered, though someone more familiar with
the code might be able to say more.
Here's my config for the Slimdevices repo I mentioned:
[svn-remote "svn"]
url = http://svn.slimdevices.com/repos/slim
fetch = trunk/server:refs/remotes/trunk
fetch = 7.5/trunk/server:refs/remotes/7.5/trunk
fetch = 7.6/trunk/server:refs/remotes/7.6/trunk
fetch = 7.7/trunk/server:refs/remotes/7.7/trunk
fetch = 7.8/trunk/server:refs/remotes/7.8/trunk
branches = branches/*/server:refs/remotes/pre7/*
branches = 7.5/branches/*/server:refs/remotes/7.5/*
branches = 7.6/branches/*/server:refs/remotes/7.6/*
branches = 7.7/branches/*/server:refs/remotes/7.7/*
branches = 7.8/branches/*/server:refs/remotes/7.8/*
tags = 7.5/tags/*/server:refs/remotes/7.5/tags/*
tags = 7.6/tags/*/server:refs/remotes/7.6/tags/*
tags = 7.7/tags/*/server:refs/remotes/7.7/tags/*
tags = 7.8/tags/*/server:refs/remotes/7.8/tags/*
Lots of repetition, but now that I look at it this repo doesn't have the
branches/work clash yours does, which simplifies the config.
HTH,
Stephen
--
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: Stitching histories of several repositories
- Ursprungligt meddelande - > Hi, > > I've written a tool to stitch the first-parent histories of several > git repositories. To illustrate, consider that we have a toplevel > git > repository inside which the other repositories reside. > [...] > > I'd like to know whether the tool would be useful to a wider > audience, > before I polish it and consider submitting it for inclusion in > contrib/. I think the tool is especially useful for running bisect > and tracking bugs that occur in large projects that consist of many > git repositories. Will a unified log showing commits in different > submodules be useful? I think it is useful. I did something like that creating a super-repo for performing a bisect over EGit and JGit over a period over a year. I don't think I restricted myself to the first parent, which was probably a mistake. The solution isn't perfect, but provided that is well-known you can live with that. A problem I found was that many stiches versions weren't even compilable so one might want to have the option of matching commits using a window of some sort to identify compilable combinations and have the ability to use only those for bisect. I'm not sure it's practical though. -- robin -- 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
Thioth gnu phone log
Data calls texts from 901-948-3388 sent to 901-270-6223 screen shots Sent from my iPhone Robin Chiodo -- 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] Perform minimal stat comparison when some stat fields are not set
- Ursprungligt meddelande - > Robin Rosenberg writes: > > > At least JGit does sets uid, gid, ctime, ino and dev fields to zero > > on update. To Git this looks like the stat data does not match and > > a full file compare will be forced even it size and mtime match. > > This > > is in practice unnecessary. Sense JGit's presence by checking if > > ino > > and dev is zero. > > > > Signed-off-by: Robin Rosenberg > > --- > > read-cache.c | 21 + > > 1 file changed, 13 insertions(+), 8 deletions(-) > > > > diff --git a/read-cache.c b/read-cache.c > > index fda78bc..6f13a22 100644 > > --- a/read-cache.c > > +++ b/read-cache.c > > @@ -197,21 +197,26 @@ static int ce_match_stat_basic(struct > > cache_entry *ce, struct stat *st) > > } > > if (ce->ce_mtime.sec != (unsigned int)st->st_mtime) > > changed |= MTIME_CHANGED; > > - if (trust_ctime && ce->ce_ctime.sec != (unsigned > > int)st->st_ctime) > > + > > + int minimal_stat = (ce->ce_ino == 0 && ce->ce_dev == 0); > > decl-after-stmt. Ok, btw. Which C version do we adhere to? C99 is quite old by now. > Besides, is it sane to do this unconditionally to affect people who > do not use JGit? > Would a config option like core.minstat be better? The name would imply no dynamic detection. - robin -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] RFC Optionally handle symbolic links as copies
- Ursprungligt meddelande - > Robin Rosenberg writes: > > > If core.symlinks is set to copy then symbolic links in a git > > repository > > will be checked out as copies of the file it points to. > > That all sounds nice on surface when the primary thing you care > about is to fetch and check out other people's code and extract it > to the working tree, but how well would that work on the checkin > side? What happens if I check out a symlink that points at a file > (either in-tree or out-of-tree), make some changes that do not > involve the symlink, and before I make the commit, an unrelated > change is made to the file the symlink is pointing at? > > > - git status - when do we report a diff. > > - After checkout we should probably not > > - if the "linked" files change? > > Yeah, exactly. > > > - if a change in the copied directory chsnges > > That, too. > > > - if a file in the copied diretory is added/removed > > - update, should we update the copied structure automatically > > when the link target changes Some of the questions have proposals in the includes test script. A little more dangerous than having real symlinks ofcourse, but regardless of what one does with or without copied symlinks one can make mistakes and I feel letting Git do the copying is way better than having real copies in the git repository. Another crappy scm which the users are converting from does this and it works. A difference to git is that it (ok clearcase) makes all files read-only so there are fewer mays of making mistakes with the copies. > I personally do not think this is worth it. It would be very useful > on the export/checkout side, so it may make sense to add it to "git > archive", though. It makes sense, but it does not solve the problem at hand. -- robin -- 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 l10n updates for 1.8.1 round 2
Hi, Junio The following changes since commit f94c3251e1400c3cf349f7f84fea4db66b540113: Update draft release notes to 1.8.1 (2012-11-29 13:57:09 -0800) are available in the git repository at: git://github.com/git-l10n/git-po master for you to fetch changes up to 77cc392d6d60c5d22930174904adae182502b8a9: l10n: vi.po: update to git-v1.8.0.1-347-gf94c3 (2012-11-30 13:43:11 +0700) Jiang Xin (1): l10n: Update git.pot (5 new, 1 removed messages) Tran Ngoc Quan (1): l10n: vi.po: update to git-v1.8.0.1-347-gf94c3 po/git.pot | 46 +++-- po/vi.po | 63 ++ 2 files changed, 75 insertions(+), 34 deletions(-) -- Jiang Xin -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] RFC Optionally handle symbolic links as copies
Am 12/5/2012 23:46, schrieb Robin Rosenberg: > - git status - when do we report a diff. > - After checkout we should probably not Are you saying that it should be ignored that the index records a symbolic link, but the worktree contains a regular file and that the regular file does not even contain the value of the symbolic link (like it would in the core.symlinks=false case)? -- Hannes -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] Perform minimal stat comparison when some stat fields are not set
Am 12/6/2012 2:09, schrieb Robin Rosenberg: >> Robin Rosenberg writes: >>> At least JGit does sets uid, gid, ctime, ino and dev fields to zero >>> on update. To Git this looks like the stat data does not match and >>> a full file compare will be forced even it size and mtime match. >>> This >>> is in practice unnecessary. Sense JGit's presence by checking if >>> ino >>> and dev is zero. Is this meant to better support C git and JGit working on the same repository? MinGW git sets these two stat fields to zero as well. But we have less of an interoparability problem between different git implementations in practice on Windows, I think. >> Besides, is it sane to do this unconditionally to affect people who >> do not use JGit? > > Would a config option like core.minstat be better? The name would imply no > dynamic detection. A configuration option is the way to go. We already have core.trustctime, core.symlinks, core.filemode, core.ignoreCygwinFSTricks. But your new mode is not "minimal". In some implementations or on some filesystems, even more bits of stat information could be meaningless (think of atime, rdev, nlink, uid, gid). Perhaps core.trustdevandino? Or an enumeration core.ignoreCacheStat=ctime,dev,ino? -- 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
