* Re: git-svn with non-standard repository layout
From: Stephen Bash @ 2012-12-05 16:44 UTC (permalink / raw)
To: Piotr Krukowiecki; +Cc: Git Mailing List
In-Reply-To: <CAA01Csoam7pXqPKnjvJB46T_sdjcW2S1oXdQT3HbUdfN4TK0kw@mail.gmail.com>
----- Original Message -----
> From: "Piotr Krukowiecki" <piotr.krukowiecki@gmail.com>
> 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
> <carsten.fuchs@cafu.de> 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
^ permalink raw reply
* Re: git-svn with non-standard repository layout
From: Piotr Krukowiecki @ 2012-12-05 16:26 UTC (permalink / raw)
To: Carsten Fuchs, Git Mailing List
In-Reply-To: <50BE68C9.7070100@cafu.de>
On Tue, Dec 4, 2012 at 10:19 PM, Carsten Fuchs <carsten.fuchs@cafu.de> 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
^ permalink raw reply
* Re: [PATCH] mingw_rmdir: do not prompt for retry when non-empty
From: Erik Faye-Lund @ 2012-12-05 16:23 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git, msysgit, Junio C Hamano
In-Reply-To: <alpine.DEB.1.00.1212051657131.31987@s15462909.onlinehome-server.info>
On Wed, Dec 5, 2012 at 5:02 PM, Johannes Schindelin
<Johannes.Schindelin@gmx.de> 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
>> <Johannes.Schindelin@gmx.de> 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.
--
*** Please reply-to-all at all times ***
*** (do not pretend to know who is subscribed and who is not) ***
*** Please avoid top-posting. ***
The msysGit Wiki is here: https://github.com/msysgit/msysgit/wiki - Github accounts are free.
You received this message because you are subscribed to the Google
Groups "msysGit" group.
To post to this group, send email to msysgit@googlegroups.com
To unsubscribe from this group, send email to
msysgit+unsubscribe@googlegroups.com
For more options, and view previous threads, visit this group at
http://groups.google.com/group/msysgit?hl=en_US?hl=en
^ permalink raw reply
* Re: [RFC] Add basic syntax check on shell scripts
From: Junio C Hamano @ 2012-12-05 16:12 UTC (permalink / raw)
To: Jeff King; +Cc: Nguyen Thai Ngoc Duy, Torsten Bögershausen, git
In-Reply-To: <20121205075401.GB5776@sigill.intra.peff.net>
Jeff King <peff@peff.net> 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.
^ permalink raw reply
* Re: [PATCH] mingw_rmdir: do not prompt for retry when non-empty
From: Johannes Schindelin @ 2012-12-05 16:02 UTC (permalink / raw)
To: Erik Faye-Lund; +Cc: git, msysgit
In-Reply-To: <CABPQNSbcSEKApDBWWt7z67DvV6=JwTGebdk6hjgR1OppPyOQwg@mail.gmail.com>
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
> <Johannes.Schindelin@gmx.de> 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
--
*** Please reply-to-all at all times ***
*** (do not pretend to know who is subscribed and who is not) ***
*** Please avoid top-posting. ***
The msysGit Wiki is here: https://github.com/msysgit/msysgit/wiki - Github accounts are free.
You received this message because you are subscribed to the Google
Groups "msysGit" group.
To post to this group, send email to msysgit@googlegroups.com
To unsubscribe from this group, send email to
msysgit+unsubscribe@googlegroups.com
For more options, and view previous threads, visit this group at
http://groups.google.com/group/msysgit?hl=en_US?hl=en
^ permalink raw reply
* Re: [PATCH v2] gitk: read and write a repository specific configuration file
From: Marc Branchaud @ 2012-12-05 15:20 UTC (permalink / raw)
To: Łukasz Stelmach; +Cc: git, paulus, gitster
In-Reply-To: <1354668583-4893-1-git-send-email-stlman@poczta.fm>
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.
^ permalink raw reply
* Re: [PATCH] mingw_rmdir: do not prompt for retry when non-empty
From: Erik Faye-Lund @ 2012-12-05 15:18 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git, msysgit
In-Reply-To: <alpine.DEB.1.00.1212041728210.31987@s15462909.onlinehome-server.info>
Sorry for a late reply.
On Tue, Dec 4, 2012 at 5:35 PM, Johannes Schindelin
<Johannes.Schindelin@gmx.de> 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.
^ permalink raw reply
* Re: remote-testsvn: Hangs at revision
From: Ramkumar Ramachandra @ 2012-12-05 13:57 UTC (permalink / raw)
To: David Michael Barr; +Cc: Git List, Florian Achleitner
In-Reply-To: <D435D46EAB6F419CA0608075751C351C@rr-dav.id.au>
David Michael Barr wrote:
> On Wednesday, 5 December 2012 at 5:20 PM, Ramkumar Ramachandra wrote:
>> $ 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.
Nope, I'm able to reproduce it everytime. I wonder what's going on.
Ram
^ permalink raw reply
* Re: remote-testsvn: Hangs at revision
From: David Michael Barr @ 2012-12-05 13:28 UTC (permalink / raw)
To: Ramkumar Ramachandra; +Cc: Git List, Florian Achleitner
In-Reply-To: <CALkWK0meveeKQe81hHyojPX0GH_WRrv7ob9-NA1Q7-TuKso+1w@mail.gmail.com>
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
^ permalink raw reply
* Re: [RFC/PATCH 1/2] reset: learn to reset to tree
From: Martin von Zweigbergk @ 2012-12-05 12:58 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vtxs1kq4z.fsf@alter.siamese.dyndns.org>
On Tue, Dec 4, 2012 at 9:46 PM, Junio C Hamano <gitster@pobox.com> wrote:
> Martin von Zweigbergk <martinvonz@gmail.com> 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".
^ permalink raw reply
* [PATCH v3 4/4] git-svn: Note about tags.
From: Sebastian Leske @ 2012-11-23 7:29 UTC (permalink / raw)
To: git; +Cc: Eric Wong, Junio C Hamano
In-Reply-To: <cover.1354693001.git.Sebastian.Leske@sleske.name>
Document that 'git svn' will import SVN tags as branches.
Signed-off-by: Sebastian Leske <sebastian.leske@sleske.name>
---
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
^ permalink raw reply related
* [PATCH v3 3/4] git-svn: Expand documentation for --follow-parent
From: Sebastian Leske @ 2012-11-30 7:16 UTC (permalink / raw)
To: git; +Cc: Eric Wong, Junio C Hamano
In-Reply-To: <cover.1354693001.git.Sebastian.Leske@sleske.name>
Describe what the option --follow-parent does, and what happens if it is
set or unset.
Signed-off-by: Sebastian Leske <sebastian.leske@sleske.name>
---
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
^ permalink raw reply related
* [PATCH v3 2/4] git-svn: Recommend use of structure options.
From: Sebastian Leske @ 2012-11-30 7:16 UTC (permalink / raw)
To: git; +Cc: Eric Wong, Junio C Hamano
In-Reply-To: <cover.1354693001.git.Sebastian.Leske@sleske.name>
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 <sebastian.leske@sleske.name>
---
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
^ permalink raw reply related
* [PATCH v3 0/4] git-svn: More docs for branch handling
From: Sebastian Leske @ 2012-12-05 7:36 UTC (permalink / raw)
To: git; +Cc: Eric Wong, Junio C Hamano
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
^ permalink raw reply
* [PATCH v3 1/4] git-svn: Document branches with at-sign(@).
From: Sebastian Leske @ 2012-11-30 7:16 UTC (permalink / raw)
To: git; +Cc: Eric Wong, Junio C Hamano
In-Reply-To: <cover.1354693001.git.Sebastian.Leske@sleske.name>
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 <sebastian.leske@sleske.name>
---
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: <branchname>").
+
+Additionally, it will create a special branch named
+'<branchname>@<SVN-Revision>', where <SVN-Revision> 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
^ permalink raw reply related
* Re: Exploiting SHA1's "XOR weakness" allows for faster hash calculation
From: Marko Kreen @ 2012-12-05 12:26 UTC (permalink / raw)
To: Sebastian Schuberth; +Cc: git
In-Reply-To: <k9n3jd$akg$1@ger.gmane.org>
On Wed, Dec 5, 2012 at 11:19 AM, Sebastian Schuberth
<sschuberth@gmail.com> 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
^ permalink raw reply
* Exploiting SHA1's "XOR weakness" allows for faster hash calculation
From: Sebastian Schuberth @ 2012-12-05 9:19 UTC (permalink / raw)
To: git
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
^ permalink raw reply
* Re: [RFC] Add basic syntax check on shell scripts
From: Sebastian Schuberth @ 2012-12-05 9:11 UTC (permalink / raw)
To: git; +Cc: Junio C Hamano, Nguyen Thai Ngoc Duy, git
In-Reply-To: <7vobi9mwt4.fsf@alter.siamese.dyndns.org>
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
^ permalink raw reply
* Re: [RFC] Add basic syntax check on shell scripts
From: Jeff King @ 2012-12-05 7:54 UTC (permalink / raw)
To: Nguyen Thai Ngoc Duy; +Cc: Junio C Hamano, Torsten Bögershausen, git
In-Reply-To: <20121205073055.GA5776@sigill.intra.peff.net>
On Wed, Dec 05, 2012 at 02:30:56AM -0500, Jeff King wrote:
> Anyway, I do think a "shell portability lint" would be a great addition
> to "test-lint", but I am slightly skeptical that it will be easy to
> write a good one that does not have false positives. Still, there may be
> some low-hanging fruit. I have not looked carefully at Torsten's patch
> yet.
Hrm. I had the impression initially that Torsten's patch was about
testing the test scripts themselves. But it is really about testing the
installed shell scripts. In that sense, test-lint is not the right
place.
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).
-Peff
PS Debian developers use a checkbashisms script to find some portability
problems. It might be worth looking at, though I notice it generates
a lot of bogus "unterminated string" results for our t/t*.sh scripts.
^ permalink raw reply
* Re: [RFC] Add basic syntax check on shell scripts
From: Jeff King @ 2012-12-05 7:30 UTC (permalink / raw)
To: Nguyen Thai Ngoc Duy; +Cc: Junio C Hamano, Torsten Bögershausen, git
In-Reply-To: <CACsJy8BtX9fMkGDoVGKzgz7SSinbt0561B1ZKHu6fs+n8ewKGg@mail.gmail.com>
On Wed, Dec 05, 2012 at 12:43:30PM +0700, Nguyen Thai Ngoc Duy wrote:
> On Wed, Dec 5, 2012 at 2:39 AM, Junio C Hamano <gitster@pobox.com> wrote:
> >> Or a project commit hook?
> >
> > Surely. It is OK to have "cd t && make test-lint" in your
> > pre-commit hook.
>
> No, what I meant is a shared pre-commit script that all git devs are
> encouraged (or forced) to install so bugs are found locally rather
> than after patches are sent to you. The hook content does not really
> matter.
I think that is orthogonal. You would want to implement the guts of such
a hook outside the hook itself, so that it could be run at arbitrary
times. So even if we want such a hook, the development should probably
look like:
1. Implement checks in t/Makefile, triggered by "make test-lint" or
similar.
2. Run "make test-lint" in a hook.
I do not use such a hook myself, but I do run "test-lint" as part of my
"make test", and I "make test" each series I send (and if the series has
non-trivial refactoring, each individual patch of the series to catch
breakages that come and go during refactoring). But I decide when to run
those checks, not a hook.
Anyway, I do think a "shell portability lint" would be a great addition
to "test-lint", but I am slightly skeptical that it will be easy to
write a good one that does not have false positives. Still, there may be
some low-hanging fruit. I have not looked carefully at Torsten's patch
yet.
-Peff
^ permalink raw reply
* remote-testsvn: Hangs at revision
From: Ramkumar Ramachandra @ 2012-12-05 6:20 UTC (permalink / raw)
To: Git List; +Cc: Florian Achleitner, David Barr
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/
Thanks.
Ram
^ permalink raw reply
* Re: [RFC] Add basic syntax check on shell scripts
From: Junio C Hamano @ 2012-12-05 6:02 UTC (permalink / raw)
To: Nguyen Thai Ngoc Duy; +Cc: Torsten Bögershausen, git
In-Reply-To: <CACsJy8BtX9fMkGDoVGKzgz7SSinbt0561B1ZKHu6fs+n8ewKGg@mail.gmail.com>
Nguyen Thai Ngoc Duy <pclouds@gmail.com> writes:
> On Wed, Dec 5, 2012 at 2:39 AM, Junio C Hamano <gitster@pobox.com> wrote:
>>> Or a project commit hook?
>>
>> Surely. It is OK to have "cd t && make test-lint" in your
>> pre-commit hook.
>
> No, what I meant is a shared pre-commit script that all git devs are
> encouraged (or forced) to install so bugs are found locally rather
> than after patches are sent to you. The hook content does not really
> matter.
Honestly, I do not really care (yet); what you are talkng about is
merely an addition to Documentation/SubmittingPatches, which is
trivial.
The content of the hook is much more important.
If it has too many false positives, it is not worth even encouraging
its use to less experienced ones, as they will have hard time to
figure out which errors matter and which erros can be ignored. It
will make contributing to the project harder, not easier.
As I do not think (1) we would be able to do a good job reducing
false positives without writing a full POSIX shell parser, and (2)
we would want to be in the business of writing POSIX shell parser
[*1*], I am somewhat skeptical.
And if we cannot come up with a reliable hook in the first place,
there isn't much point in discussing a policy to encourage such a
hook, is it?
[Footnote]
*1* Is there a free one that is portable, perhaps written in either
Perl or Python, to which we can easily plug our own logic? In order
to catch basic errors, I think it is sufficient to tokenize the
script into independent series of simple commands, even ignoring
variable substitutions and evals, and just have a bunch of "we do
not allow option X to command Y" rules (e.g. "no -i to sed", "the
first argument must be 'git' for "test_must_fail").
^ permalink raw reply
* Re: [RFC/PATCH 1/2] reset: learn to reset to tree
From: Junio C Hamano @ 2012-12-05 5:46 UTC (permalink / raw)
To: Martin von Zweigbergk; +Cc: git
In-Reply-To: <CANiSa6iMxzQGM8mZYdfR-drPGgydwVpM5JsQ-8oO09MX5XDH+g@mail.gmail.com>
Martin von Zweigbergk <martinvonz@gmail.com> 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 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. "git checkout [$commit] $paths" is still an operation to help
me build new history forward starting from HEAD, and is not about
start building on top of the old $commit. Losing the work I've done
to the files that did not exist in $commit:$paths is almost always
*not* what I would expect to happen with the command.
^ permalink raw reply
* Re: [RFC] Add basic syntax check on shell scripts
From: Nguyen Thai Ngoc Duy @ 2012-12-05 5:43 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Torsten Bögershausen, git
In-Reply-To: <7vobi9mwt4.fsf@alter.siamese.dyndns.org>
On Wed, Dec 5, 2012 at 2:39 AM, Junio C Hamano <gitster@pobox.com> wrote:
>> Or a project commit hook?
>
> Surely. It is OK to have "cd t && make test-lint" in your
> pre-commit hook.
No, what I meant is a shared pre-commit script that all git devs are
encouraged (or forced) to install so bugs are found locally rather
than after patches are sent to you. The hook content does not really
matter.
--
Duy
^ permalink raw reply
* Re: [RFC/PATCH 1/2] reset: learn to reset to tree
From: Martin von Zweigbergk @ 2012-12-05 3:45 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vd2yunn0e.fsf@alter.siamese.dyndns.org>
On Sat, Dec 1, 2012 at 1:24 AM, Junio C Hamano <gitster@pobox.com> wrote:
> Martin von Zweigbergk <martinvonz@gmail.com> writes:
>
>> On Thu, Nov 29, 2012 at 2:00 PM, Martin von Zweigbergk
>> <martinvonz@gmail.com> wrote:
>>> Slightly off topic, but another difference (or somehow another aspect
>>> of the same difference?) that has tripped me up a few times is that
>>> "git checkout $rev ." only affects added and modified files...
>
> "checkout $commit pathspec" has always been about ...
I suppose the "has always been" is meant to say that it's hard to
change at this point, not that it's more intuitive the way it works..?
> ...checking out the
> contents stored in the paths that match the pathspec from the named
> commit to the index and also o the working tree.
I think I have always thought that "git checkout $commit $pathspec"
would replace the section(s) of the tree defined by $pathspec. (I'm
using "tree" in the more general sense here, as I'm understood the
index is not stored as a tree.)
> When pathspec is "dir/", it does not match the directory whose name
> is "dir". The pathspec matches the paths that store blobs under
> that directory.
Ah, right. Unlike "git reset dir/", IIUC.
More importantly, when is it desirable not to delete deleted entries?
I find it much easier to imagine uses a "git checkout $commit
$pathspec" that does delete deleted entries. It seems like this must
have been discussed in depth before, so feel free to point me to an
old thread.
If it doesn't seem too strange to you and others if I make "git reset
--hard [$commit] $pathspec" work just like had expected "git checkout
$commit $pathspec", I might look into that when I get some time.
> ...The "please
> remove everything in dir/" part is not the job of "checkout"; of
> course, you can do it as a separate step (e.g. "rm -fr dir/").
"rm -rf dir/" would of course delete everything in there, including
e.g. build artifacts....
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox