* Re: [PATCH] git-svn: Make following parents atomic
From: Deskin Miller @ 2008-12-07 22:24 UTC (permalink / raw)
To: git; +Cc: normalperson, gitster
In-Reply-To: <1228665970-21204-1-git-send-email-deskinm@umich.edu>
On Sun, Dec 07, 2008 at 11:06:10AM -0500, Deskin Miller wrote:
> [...]
>
> To fix this, when we initialise the Git::SVN object $gs to search for
> and perhaps fetch history, we check if there are any commits in SVN in
> the range between the current revision $gs is at, and the top revision
> for which we were asked to fill history. If there are commits we're
> missing in that range, we continue the fetch from the current revision
> to the top, properly getting all history before using it as the parent
> for the branch we're trying to create.
On looking at the patch again, I think I might have introduced a bug:
it'll take the most commit on the parent branch, even if it was branched
from an earlier point. I'll spend more time looking at it and should
have a v2 in a day at most if I'm rigth, hopefully more like a few
hours.
Deskin Miller
^ permalink raw reply
* Re: How to clone git repository with git-svn meta-data included?
From: Grzegorz Kossakowski @ 2008-12-07 22:02 UTC (permalink / raw)
To: Peter Harris, git
In-Reply-To: <eaa105840812071230l5e8d54bcg21b36019711bc3cd@mail.gmail.com>
Peter Harris pisze:
> After the git clone, I do the following:
> git svn init -s svn://repo/sitory
> git svn rebase
>
> No data is transferred[1], although 'git svn rebase' does spend a
> minute or so reading the commit messages to rebuild its index.
I've tried this method with Cocoon repository
(http://jukka.zitting.name/git/?p=cocoon.git;a=summary) and got this error:
git clone git://jukka.zitting.name/cocoon.git
git svn init -s https://svn.eu.apache.org/repos/asf/cocoon/
git svn rebase
Unable to determine upstream SVN information from working tree history
git --version
git version 1.6.0.2
Any idea what's wrong here?
> This could all be in a common script you distribute to your users.
Good suggestion.
> "git help svn" mentions the rebuild only in passing. I'm not sure if
> it is described in better detail elsewhere.
Ah, I didn't spot this earlier. Thanks.
> If something is in A's tree, it is coming from A. Either A has
> authority, or A has received authority from someone else, or A is
> bringing the legal problem down on himself. When A says "Please Pull"
> (or when A pushes) A is effectively saying "These changes are legally
> mine to give you".
>
> The Developer's Certificate of Origin 1.0 was designed to address this
> issue; see also "Signed-off-by"
>
> Of course, if it's a legal issue, make sure you consult your own lawyer.
I see. Thanks for insightful comments.
>>> You could maybe use signed tags ("git help tag")...
>> The question is why Git doesn't sign all commits by default but only tags? Creating tags all the
>> time is rather tedious process and seems to have no sense, right?
>
> Typing in your GPG passphrase for every single little commit would be
> even more tedious, IMHO.
Yep, that's true.
>> Does it mean that with current Git design it's the best to not use advanced features of Git like
>> tree merging but simply go with posting e-mails with patches instead if contributors cannot be trusted?
>
> That would be my policy. At the very least, I would have a human
> review the tree before merging it.
Agreed.
> Note that git was designed around a "git am" workflow, so it is very
> efficient at dealing with large numbers of patches at a time.
>
> Note also that you can do tree merging with an email-patch based
> workflow, since git format-patch preserves parent information,
> although it does take a little bit more work. See also: "git help am"
> under --3way.
Thanks for all your valuable information. As soon as I resolve problem with git svn rebase I'll
start reading on how git am --3way works.
--
Best regards,
Grzegorz Kossakowski
^ permalink raw reply
* Re: missing "commit | commitdiff | tree | snapshot" within we web git page
From: Jakub Narebski @ 2008-12-07 21:30 UTC (permalink / raw)
To: Toralf Förster; +Cc: git
In-Reply-To: <200812072155.52456.toralf.foerster@gmx.de>
Toralf Förster <toralf.foerster@gmx.de> writes:
> While watching this
> http://git.kernel.org/?p=linux/kernel/git/stable/linux-2.6.27.y.git;a=shortlog
> I'm wondering why the last line doesn't contain sth. like
> "commit | commitdiff | tree | snapshot"
It contains it?
Unless you are talking about line with the 'next' link...
--
Jakub Narebski
Poland
ShadeHawk on #git
^ permalink raw reply
* Re: What's cooking in git.git (Nov 2008, #06; Wed, 26)
From: Daniel Barkalow @ 2008-12-07 21:26 UTC (permalink / raw)
To: Nguyen Thai Ngoc Duy
Cc: Junio C Hamano, Shawn O. Pearce, Johannes Schindelin, git
In-Reply-To: <fcaeb9bf0812070427s64438216s41bf1294aa6398a3@mail.gmail.com>
On Sun, 7 Dec 2008, Nguyen Thai Ngoc Duy wrote:
> On 12/7/08, Daniel Barkalow <barkalow@iabervon.org> wrote:
> > > There is not much work for CE_NO_CHECKOUT on plumbling level except
> > > some fixes. The last half of the series, for porcelain level, you will
> > > see more.
> >
> >
> > For the porcelain level, do we need the difference to be in the index? If
> > the porcelain knows the sparse checkout area and can instruct the plumbing
> > appropriately, the information shouldn't need to be stored in the index
>
> This was discussed since the beginning of this feature. I recall that
> the index reflects worktree, and because we mark CE_NO_CHECKOUT on
> file basis, it's best to save the information there, not separately.
> We do save high level information to form the checkout area (sparse
> patterns) in the last half, but basically you should be able to live
> without that.
We need to mark in the index the information that reflects the worktree.
If, however, we take CE_VALID to be the flag for "ignore the worktree
entirely at this path; act as it if contains what the index contains" (and
use this to cause that aspect of no-checkout), and we then entirely ignore
the worktree, including not caring whether there are files there or not
(except, of course, that in the transition from caring to not caring for
no-checkout, we make the worktree empty, while in the case for
"stat-is-expensive", we bring it into agreement with the index), then
there is no additional information that needs to be conveyed in the index.
> > unless it's ever important to remember whether an entry is CE_VALID due to
> > having been outside the checkout when the index was written, even though
> > the checkout area now includes it. I don't have a good intuition as to
> > what ought to happen if the user manually changes what's specified for
> > checkout without actually updating the index and working tree.
>
> So if a user changes worktree without updating index, they will have
> the same results as they do now: files are shown as modified if they
> don't have CE_NO_CHECKOUT set. If those files do, they are considered
> 'orphaned' or staled and are recommended to be removed/updated to
> avoid unexpected consequences (not availble this this first half
> series because that belongs to "git status").
I was actually thinking that there would be a file for "this is what the
user wants to have checked out" (as opposed to the index, which must
contain "this is what is checked out"), and the porcelain would instruct
the plumbing as to what to do with the worktree (that the plumbing with
then ignore, due to the index bit) based on this information.
The index obviously can't contain the user's full instructions for what
should be checked out, because the user will want to say "I don't care
about anything in Documentation/" and have this apply to
Documentation/some-file-not-in-the-index, so that if this file is in the
worktree, the user gets a warning.
I think you're doing this with core.defaultsparse, although you seem to
allow the index to diverge from this easily.
The question, then, is what happens when the index and core.defaultsparse
disagree, either because the porcelain supports causing it or because the
user has simply editting the config file or used plumbing to modify the
index. That is, (1) we have index entries that say that the worktree is
ignored, and the rules don't say they're outside the sparse checkout; do
we care whether we expect the worktree to be empty or match the index?
And, (2) we have index entries that say we do care about them, but the
rules say they're outside the sparse checkout; what happens with these?
Case (1) is where we would need to know, in the index, whether we expect
the worktree to actually match the index (traditional CE_VALID) or whether
we expect the worktree to be empty (CE_NO_CHECKOUT), if our behavior
should actually differ. My vague feeling is that we don't want it to
differ, and these paths are unexpectional "interesting to the user, but
the worktree is ignored" until reading a tree into the index again. (But
note that we will have to check on the worktree when reading into the
index if this changes the index from "blobA, CE_VALID" to
"blobA, !CE_VALID", since the worktree could differ in a way that we don't
want to retain. And I think we want it to be an error to have the worktree
be something other than blobA or nothing before, but "nothing" is fine and
we just write it out. (This means that users of CE_VALID who remove files
behind git's back may lose their removal work; but this is a pretty
trivial danger).
-Daniel
*This .sig left intentionally blank*
^ permalink raw reply
* missing "commit | commitdiff | tree | snapshot" within we web git page
From: Toralf Förster @ 2008-12-07 20:55 UTC (permalink / raw)
To: git
[-- Attachment #1: Type: text/plain, Size: 314 bytes --]
While watching this
http://git.kernel.org/?p=linux/kernel/git/stable/linux-2.6.27.y.git;a=shortlog
I'm wondering why the last line doesn't contain sth. like
"commit | commitdiff | tree | snapshot"
--
MfG/Sincerely
Toralf Förster
pgp finger print: 7B1A 07F4 EC82 0F90 D4C2 8936 872A E508 7DB6 9DA3
[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Re: How to clone git repository with git-svn meta-data included?
From: Peter Harris @ 2008-12-07 20:30 UTC (permalink / raw)
To: Grzegorz Kossakowski; +Cc: git
In-Reply-To: <493C1F36.7050504@tuffmail.com>
On Sun, Dec 7, 2008 at 2:08 PM, Grzegorz Kossakowski wrote:
> Peter Harris pisze:
>> Make sure you don't use the --no-metadata flag when setting up
>> git-svn. This will embed the metadata into commit messages, so git-svn
>> can rebuild it from scratch whenever it needs to. (You probably also
>> want git 1.6.1rc for incremental rebuild support). This also has the
>> advantage that you can see the svn revision number when looking at a
>> commit message.
>
> Not sure what you exactly mean here. Do you mean that if metadata is included in commit messages
> then there is an easy way to initialize git-svn after cloning the repo?
Yes.
> By easy I mean:
> a) it does not require to much of interactive actions to be performed
> b) it does not pull too much from svn server
>
> Point b) is important because we usually have quite large repositories.
To set up the remotes to mirror the remote svn-remotes, I do the clone manually:
git init
git remote add origin git://svn/mirror
git config --add remote.origin.fetch +refs/remotes/*:refs/remotes/*
git fetch
git reset --hard trunk
After the git clone, I do the following:
git svn init -s svn://repo/sitory
git svn rebase
No data is transferred[1], although 'git svn rebase' does spend a
minute or so reading the commit messages to rebuild its index.
This could all be in a common script you distribute to your users.
> Also, could you point me to a place where this rebuild support is described? I would like to know
> what our committer has to do after cloning from Jukka's server.
"git help svn" mentions the rebuild only in passing. I'm not sure if
it is described in better detail elsewhere.
>> In terms of re-pulling from the git-svn mirror, git-svn will create
>> the same commits (with the same sha1s) from svn every time, so there
>> will be no conflicts there.
>
> Just to make sure: so if one person pulls from git-svn mirror and another one pulls using git svn
> rebase they result in the same tree right?
Yes[2].
>> If C doesn't trust A, C should not pull from A. C should pull only
>> from (trusted) B. Presumably B knows who (of A and B) did which work,
>> and B's repository can be trusted?
>>
>> If neither of A or B can be trusted, then you have problems that a
>> computer cannot solve for you.
>
> Yep, I was having in mind the case when both A and B are untrusted. I don't want my computer to
> check if something coming from A or B is safe or not I just want to know which bits are coming from
> A and which from B.
>
> This is really important for us because of legal reasons.
If something is in A's tree, it is coming from A. Either A has
authority, or A has received authority from someone else, or A is
bringing the legal problem down on himself. When A says "Please Pull"
(or when A pushes) A is effectively saying "These changes are legally
mine to give you".
The Developer's Certificate of Origin 1.0 was designed to address this
issue; see also "Signed-off-by"
Of course, if it's a legal issue, make sure you consult your own lawyer.
>> You could maybe use signed tags ("git help tag")...
>
> The question is why Git doesn't sign all commits by default but only tags? Creating tags all the
> time is rather tedious process and seems to have no sense, right?
Typing in your GPG passphrase for every single little commit would be
even more tedious, IMHO.
> Does it mean that with current Git design it's the best to not use advanced features of Git like
> tree merging but simply go with posting e-mails with patches instead if contributors cannot be trusted?
That would be my policy. At the very least, I would have a human
review the tree before merging it.
Note that git was designed around a "git am" workflow, so it is very
efficient at dealing with large numbers of patches at a time.
Note also that you can do tree merging with an email-patch based
workflow, since git format-patch preserves parent information,
although it does take a little bit more work. See also: "git help am"
under --3way.
Peter Harris
[1] Not strictly true. git-svn does contact the svn server to see if
there are any revisions newer than the latest present in the git repo,
and will transfer those revisions (if any).
[2] Unless (a) someone edited the svn:log (or other) revprop in
between, or (b) you triggered the bug I saw reported (and fixed?) on
this list today. I've never personally triggered (b), but I have seen
(a).
^ permalink raw reply
* Re: How to clone git repository with git-svn meta-data included?
From: Grzegorz Kossakowski @ 2008-12-07 19:08 UTC (permalink / raw)
To: Peter Harris; +Cc: git
In-Reply-To: <eaa105840812070857i27f8e920keaba3f92f5260b38@mail.gmail.com>
Peter Harris pisze:
> Make sure you don't use the --no-metadata flag when setting up
> git-svn. This will embed the metadata into commit messages, so git-svn
> can rebuild it from scratch whenever it needs to. (You probably also
> want git 1.6.1rc for incremental rebuild support). This also has the
> advantage that you can see the svn revision number when looking at a
> commit message.
Not sure what you exactly mean here. Do you mean that if metadata is included in commit messages
then there is an easy way to initialize git-svn after cloning the repo?
By easy I mean:
a) it does not require to much of interactive actions to be performed
b) it does not pull too much from svn server
Point b) is important because we usually have quite large repositories.
Also, could you point me to a place where this rebuild support is described? I would like to know
what our committer has to do after cloning from Jukka's server.
> svn doesn't really know what a merge is (not even 1.5). You MUST
> rebase in order to commit to svn. This is a limitation of svn, not
> git.
Yep, I'm aware of the fact that history has to be flattened but I was more worried about the point
you address below.
> In terms of re-pulling from the git-svn mirror, git-svn will create
> the same commits (with the same sha1s) from svn every time, so there
> will be no conflicts there.
Just to make sure: so if one person pulls from git-svn mirror and another one pulls using git svn
rebase they result in the same tree right?
>> Is it possible with Git right now?
>
> Yes, but it might not be possible with svn, depending on which part of
> the above "it" is.
It referred mostly to cloning from git svn mirror and then being able to use git svn dcommit to push
changes back to svn. Since git svn data is not being cloned the question is how to recreate it.
>> What if A was not fair and has rewritten a few commits coming from B so they contain malicious code?
>> How we can detect something like that and how C be sure that what he merges is really work
>> attributed by correct names?
>
> If C doesn't trust A, C should not pull from A. C should pull only
> from (trusted) B. Presumably B knows who (of A and B) did which work,
> and B's repository can be trusted?
>
> If neither of A or B can be trusted, then you have problems that a
> computer cannot solve for you.
Yep, I was having in mind the case when both A and B are untrusted. I don't want my computer to
check if something coming from A or B is safe or not I just want to know which bits are coming from
A and which from B.
This is really important for us because of legal reasons.
> You could maybe use signed tags ("git help tag") - each contributor
> could sign a certain tree state, and if you see commits attributed to
> the other contributor after their last tag, you know something is
> fishy. But that might be more effort than either you or your
> contributors want to go through. And while it might help with
> attribution problems, it still doesn't help with all the other
> problems you might have with untrusted contributors.
The question is why Git doesn't sign all commits by default but only tags? Creating tags all the
time is rather tedious process and seems to have no sense, right?
Does it mean that with current Git design it's the best to not use advanced features of Git like
tree merging but simply go with posting e-mails with patches instead if contributors cannot be trusted?
Thanks for your reply.
--
Best regards,
Grzegorz Kossakowski
^ permalink raw reply
* help needed: Splitting a git repository after subversion migration
From: Thomas Jarosch @ 2008-12-07 17:41 UTC (permalink / raw)
To: git
Hello together,
I've successfully imported a large subversion repository into git.
The tree contains source code and binary data ("releases"),
the resulting .git directory is about 11GB.
After the import I recreated the tags/branches by converting the refs
to the subversion tags using a small shell script from the web:
for branch in `git branch -r`; do
...
version=`basename $branch`
git tag -s -f -m "$subject" "$version" "$branch^"
git branch -d -r $branch
done
Ok, so far everything went really smooth. I wanted to split this repository
into two repositories, one for the source code and one for the binary data.
The current tree layout is like this:
sources/c++_xyz
releases/large_binary_data
...
The original tree was imported from CVS to subversion and the layout
of the trunk was once reorganized/moved later. Here's the command
I used to split out the "source" tree:
git filter-branch --index-filter 'git rm --cached --ignore-unmatch -r -f
CVSROOT Attic source/Attic develpkg/Attic
source/packages/Attic releases update_pkg' -- --all
After that I ran these commands to reclaim the space:
- git clone --no-hardlinks filtered_tree final_output
- cd final_output
- git gc
- git prune
- git repack -a -d --depth=250 --window=250
Unfortunately the .git directory of the "source" tree is still 7.5GB big.
When I just imported the "trunk" from subversion without any tags
and then ran "git filter-branch --subdirectory-filter source" + git gc,
the .git directory was about 1.5GB afterwards.
How can I find out where those other 6GB go to?
I already looked at the tags with gitk,
there's no sign of the releases/* stuff left.
The "--all" switch for "git filter-branch"
doesn't seem documented in git 1.6.0.4?
I just learned about it from the example usage.
"git filter-branch" also had trouble converting the tags
and suggested I should add "--tag-name-filter cat", which I did.
Maybe that's something for the examples, too?
I also tried running "git filter-branch --tag-name-filter cat
--subdirectory-filter source -- --all", but that commands aborts
with these messages:
WARNING: 'refs/tags/v5-0-8' was rewritten into multiple commits:
ee180f6117597b60ee237e9da92047946dfdeec5
fd7824d1926ce9e4c89b685583eb9a9c2f2537af
WARNING: Ref 'refs/tags/v5-0-8' points to the first one now.
error: Ref refs/tags/v5-0-8 is at 4ea78238cfd6ee259c4e8bde7be4a90bc86295b0
but expected 06c60261502acfb7b2bbe44c2e2ec371bea65827
fatal: Cannot lock the ref 'refs/tags/v5-0-8'.
Could not rewrite refs/tags/v5-0-8
Besides that git really rocks :-)
Thanks in advance,
Thomas
^ permalink raw reply
* Re: Git.pm
From: nadim khemir @ 2008-12-07 17:39 UTC (permalink / raw)
To: git
In-Reply-To: <200811232058.11321.nadim@khemir.net>
On Sunday 23 November 2008 20.58.11 nadim khemir wrote:
> On Thursday 20 November 2008 09.34.46 you wrote:
> My current plan is to:
> ...
> - tell my fellow perl developers about this (done, so far very good
> response) - confer with the people having git related modules (a few)
> - gather ideas for what nededs to be changed (not much this far)
> ...
This http://perlbuzz.com/2008/12/moving-forward-with-git-and-perl.html should
take care of waking up the perl community (they are not really sleeping just
concentrating on their own perlish world).
In a few days, I'll mail all the developers having git related modules and try
to get a common strategy (wish us luck with that).
Cheers, Nadim.
^ permalink raw reply
* Re: How to clone git repository with git-svn meta-data included?
From: Peter Harris @ 2008-12-07 16:57 UTC (permalink / raw)
To: Grzegorz Kossakowski; +Cc: git
In-Reply-To: <493A6CEC.4060601@tuffmail.com>
On Sat, Dec 6, 2008 at 7:15 AM, Grzegorz Kossakowski wrote:
>
> Some folks at Apache are experimenting with Git and we are currently seeking for the git-svn
> integration that fits our needs and infrastructure.
>
> After some evaluation we decided that our setup could be described using following points:
> a) our svn repository remains our main, official server where every committer is obligated to push
> their changes to at some time.
> b) we set up clone of svn repository using git-svn. One of our members, Jukka Zitting, maintains
> such a service here[1]. Such repositories should be usable both for our committers (that have rights
> to push to svn) and our contributors that want to contribute random patches
> c) we want carefully track who committed/contributed what
>
> Basically, a) implies b) and point b) looks little bit problematic right now.
> Jukka has set up his hosting using method described in his e-mail[2] which basically makes use of
> git svn. The major problem is that if one clones Jukka's repository then git svn information is not
> being cloned so committers have no means to push their changes to main, svn server.
Make sure you don't use the --no-metadata flag when setting up
git-svn. This will embed the metadata into commit messages, so git-svn
can rebuild it from scratch whenever it needs to. (You probably also
want git 1.6.1rc for incremental rebuild support). This also has the
advantage that you can see the svn revision number when looking at a
commit message.
> I've tried to play a little bit around with this issue and I tried to copy information from .git
> directory found on Jukka's server. This made me able to push my changes but git svn insisted on
> rebasing my repository using commits found in svn which is wrong. Basically we want such a setup
> that uses git repository (Jukka's clone) for pulling changes and local git svn for pushing changes.
> Git svn should never try to rebase local repository because this will lead to two different trees on
> two different machines so we won't be able to exchange and merge changesets.
svn doesn't really know what a merge is (not even 1.5). You MUST
rebase in order to commit to svn. This is a limitation of svn, not
git.
In terms of re-pulling from the git-svn mirror, git-svn will create
the same commits (with the same sha1s) from svn every time, so there
will be no conflicts there.
> Is it possible with Git right now?
Yes, but it might not be possible with svn, depending on which part of
the above "it" is.
> What if A was not fair and has rewritten a few commits coming from B so they contain malicious code?
> How we can detect something like that and how C be sure that what he merges is really work
> attributed by correct names?
If C doesn't trust A, C should not pull from A. C should pull only
from (trusted) B. Presumably B knows who (of A and B) did which work,
and B's repository can be trusted?
If neither of A or B can be trusted, then you have problems that a
computer cannot solve for you.
You could maybe use signed tags ("git help tag") - each contributor
could sign a certain tree state, and if you see commits attributed to
the other contributor after their last tag, you know something is
fishy. But that might be more effort than either you or your
contributors want to go through. And while it might help with
attribution problems, it still doesn't help with all the other
problems you might have with untrusted contributors.
Peter Harris
^ permalink raw reply
* [ANNOUNCE] git-svn-bugfix script (Re: [PATCH] git-svn: Make following parents atomic)
From: Deskin Miller @ 2008-12-07 16:10 UTC (permalink / raw)
To: git
In-Reply-To: <1228665970-21204-1-git-send-email-deskinm@umich.edu>
git-svn has some bugs where it won't create identical commits in
different git-svn copies of the same svn history, despite all relevant
configuration being identical; oftentimes, the copies will diverge from
each other at some point. My theory for a long time was that
interrupting git svn fetch could cause this, and it turns out I was
right in one case, but since it's not something I could easily interrupt
my normal workflow with to do forensics when it occurred, I ended up
writing a script to repeatedly fetch from a certain svn repository, and
compare refs to a supposedly pristine fetch until the refs diverged or
one fetched all the svn history; then, rinse and repeat the process from
the beginning. It's available at
git://git.deskinm.fdns.net/git-svn-bugfix.git
Using this script, r3924 of SVN's svn repository flagged one bug
repeatedly, for which I've posted a patch. I'm posting the repo because
there are other places where history diverges that I've not had a chance
to debug yet, so others should feel free to use the script to find and
fix them. If anyone feels inclined, I'll gladly take patches to the
script, but I don't really care to handle data or bug reports you
generate with it (at least not at this point); I can generate plenty of
data myself.
Deskin Miller
^ permalink raw reply
* [PATCH] git-svn: Make following parents atomic
From: Deskin Miller @ 2008-12-07 16:06 UTC (permalink / raw)
To: git; +Cc: normalperson, gitster, Deskin Miller
find_parent_branch generates branch@rev type branches when one has to
look back through SVN history to properly get the history for a branch
copied from somewhere not already being tracked by git-svn. If in the
process of fetching this history, git-svn is interrupted, then when one
fetches again, it will use whatever was last fetched as the parent
commit and fail to fetch any more history which it didn't get to before
being terminated. This is especially troubling in that different
git-svn copies of the same SVN repository can end up with different
commit sha1s, incorrectly showing the history as divergent and
precluding easy collaboration using git push and fetch.
To fix this, when we initialise the Git::SVN object $gs to search for
and perhaps fetch history, we check if there are any commits in SVN in
the range between the current revision $gs is at, and the top revision
for which we were asked to fill history. If there are commits we're
missing in that range, we continue the fetch from the current revision
to the top, properly getting all history before using it as the parent
for the branch we're trying to create.
Signed-off-by: Deskin Miller <deskinm@umich.edu>
---
Patch is based on maint.
This was a nasty bug that took some work to figure out; I knew two
git-svn copies had diverged, but though I could look at the commits
where they diverged there was no good way to figure out what git-svn had
been doing at that point. I ended up writing a script to automate the
process and save information for me to analyse later; I'll be posting an
announcement with further explanation, but the repository is available
at
git://git.deskinm.fdns.net/git-svn-bugfix.git
Deskin Miller
git-svn.perl | 14 +++++++++++---
t/t9104-git-svn-follow-parent.sh | 33 +++++++++++++++++++++++++++++++++
2 files changed, 44 insertions(+), 3 deletions(-)
diff --git a/git-svn.perl b/git-svn.perl
index 56238da..c53d864 100755
--- a/git-svn.perl
+++ b/git-svn.perl
@@ -2318,9 +2318,17 @@ sub find_parent_branch {
$gs = Git::SVN->init($u, $p, $repo_id, $ref_id, 1);
}
my ($r0, $parent) = $gs->find_rev_before($r, 1);
- if (!defined $r0 || !defined $parent) {
- my ($base, $head) = parse_revision_argument(0, $r);
- if ($base <= $r) {
+ {
+ my ($base, $head);
+ if (!defined $r0 || !defined $parent) {
+ ($base, $head) = parse_revision_argument(0, $r);
+ } else {
+ if ($r0 < $r) {
+ $gs->ra->get_log([$gs->{path}], $r0 + 1, $r, 1,
+ 0, 1, sub { $base = $_[1] - 1 });
+ }
+ }
+ if (defined $base && $base <= $r) {
$gs->fetch($base, $r);
}
($r0, $parent) = $gs->last_rev_commit;
diff --git a/t/t9104-git-svn-follow-parent.sh b/t/t9104-git-svn-follow-parent.sh
index 4d964e2..8e7b95b 100755
--- a/t/t9104-git-svn-follow-parent.sh
+++ b/t/t9104-git-svn-follow-parent.sh
@@ -149,6 +149,39 @@ test_expect_success "track initial change if it was only made to parent" '
"`git rev-parse r9270-d~1`"
'
+test_expect_success "follow-parent is atomic" '
+ cd wc &&
+ svn up &&
+ svn mkdir stunk &&
+ cd stunk &&
+ echo "trunk stunk" > readme &&
+ svn add readme &&
+ cd .. &&
+ svn ci -m "trunk stunk" &&
+ echo "stunk like junk" >> stunk/readme &&
+ svn ci -m "really stunk" &&
+ cd .. &&
+ svn copy -m "stunk flunked" "$svnrepo"/stunk "$svnrepo"/flunk &&
+ git svn init --minimize-url -i stunk "$svnrepo"/stunk &&
+ git svn fetch -i stunk &&
+ git update-ref refs/remotes/flunk@17 refs/remotes/stunk~1 &&
+ git update-ref -d refs/remotes/stunk &&
+ git config --unset svn-remote.svn.fetch stunk &&
+ mkdir -p "$GIT_DIR"/svn/flunk@17 &&
+ rev_map=$(cd "$GIT_DIR"/svn/stunk && ls .rev_map*) &&
+ dd if="$GIT_DIR"/svn/stunk/$rev_map \
+ of="$GIT_DIR"/svn/flunk@17/$rev_map bs=24 count=1 &&
+ rm -rf "$GIT_DIR"/svn/stunk &&
+ git svn init --minimize-url -i flunk "$svnrepo"/flunk &&
+ git svn fetch -i flunk &&
+ git svn init --minimize-url -i stunk "$svnrepo"/stunk &&
+ git svn fetch -i stunk &&
+ test "`git rev-parse --verify refs/remotes/flunk@17`" \
+ = "`git rev-parse --verify refs/remotes/stunk`" &&
+ test "`git rev-parse --verify refs/remotes/flunk~1`" \
+ = "`git rev-parse --verify refs/remotes/stunk`"
+ '
+
test_expect_success "track multi-parent paths" '
svn cp -m "resurrect /glob" "$svnrepo"/r9270 "$svnrepo"/glob &&
git-svn multi-fetch &&
--
1.6.1.rc1.45.g123ed
^ permalink raw reply related
* Re: What's cooking in git.git (Nov 2008, #06; Wed, 26)
From: Nguyen Thai Ngoc Duy @ 2008-12-07 12:27 UTC (permalink / raw)
To: Daniel Barkalow; +Cc: Junio C Hamano, Shawn O. Pearce, Johannes Schindelin, git
In-Reply-To: <alpine.LNX.1.00.0812061238260.19665@iabervon.org>
On 12/7/08, Daniel Barkalow <barkalow@iabervon.org> wrote:
> > There is not much work for CE_NO_CHECKOUT on plumbling level except
> > some fixes. The last half of the series, for porcelain level, you will
> > see more.
>
>
> For the porcelain level, do we need the difference to be in the index? If
> the porcelain knows the sparse checkout area and can instruct the plumbing
> appropriately, the information shouldn't need to be stored in the index
This was discussed since the beginning of this feature. I recall that
the index reflects worktree, and because we mark CE_NO_CHECKOUT on
file basis, it's best to save the information there, not separately.
We do save high level information to form the checkout area (sparse
patterns) in the last half, but basically you should be able to live
without that.
> unless it's ever important to remember whether an entry is CE_VALID due to
> having been outside the checkout when the index was written, even though
> the checkout area now includes it. I don't have a good intuition as to
> what ought to happen if the user manually changes what's specified for
> checkout without actually updating the index and working tree.
So if a user changes worktree without updating index, they will have
the same results as they do now: files are shown as modified if they
don't have CE_NO_CHECKOUT set. If those files do, they are considered
'orphaned' or staled and are recommended to be removed/updated to
avoid unexpected consequences (not availble this this first half
series because that belongs to "git status").
--
Duy
^ permalink raw reply
* Re: git fast-export | git fast-import doesn't work
From: Alexander Gavrilov @ 2008-12-07 11:25 UTC (permalink / raw)
To: Johannes Schindelin
Cc: Michael J Gruber, Ondrej Certik, Git Mailing List, Fabian Seoane
In-Reply-To: <alpine.DEB.1.00.0811261804550.30769@pacific.mpi-cbg.de>
[-- Attachment #1: Type: text/plain, Size: 3026 bytes --]
On Wednesday 26 November 2008 20:08:54 Johannes Schindelin wrote:
> On Wed, 26 Nov 2008, Michael J Gruber wrote:
> > Looking at the source I suspect that fast-export fails to denote
> > parenthood in the case of yet unmarked parents (last for-loop of
> > handle_commit() in builtin_fast_export.c). But I don't really know that
> > code at all.
>
> I strongly doubt so. Noticed the use of has_unshown_parent(commit) in
> both cases before calling handle_commit()?
>
> In any case, here is a script that I wrote _long_ time ago, to be able to
> reconstruct history from the output of "git rev-list --all --parents".
> Maybe this helps you in reconstructing something that is handled
> incorrectly by fast-export | fast-import, but is lighter than a full-blown
> repository.
Today I had time to investigate this problem, and found:
1) The root of the problem is that fast-export really wants to walk
revisions in topological order, but actually receives them in date
order. While it is usually a good guess at topology, this repository
contains some children that are older than their parent commits,
e.g. see dd22c7d51a4debf18a3b2e35c61a1fec0175e4e0
2) It tries to fix minor deviations by checking the SHOWN flag.
However, it still breaks in two ways:
a) SHOWN is apparently set by simply walking the commits, so
if the parent was earlier encountered on a different branch of
the DAG, it will be handled as already shown. Basically, this
check is only good to determine if we reached the end of the
chain, and should start to backtrack.
b) If I modify the code to use a completely separate flag, it still
doesn't work, because the commits are placed on the stack in
the wrong order, so handle_tail gets stuck, and fails to unwind
it completely.
So, apparently, the only way to fix it is to require topological order:
diff --git a/builtin-fast-export.c b/builtin-fast-export.c
index 7d5d57a..d9261fa 100644
--- a/builtin-fast-export.c
+++ b/builtin-fast-export.c
@@ -490,6 +490,7 @@ int cmd_fast_export(int argc, const char **argv, const char *prefix)
git_config(git_default_config, NULL);
init_revisions(&revs, prefix);
+ revs.topo_order = 1; /* force topological ordering */
argc = setup_revisions(argc, argv, &revs, NULL);
argc = parse_options(argc, argv, options, fast_export_usage, 0);
if (argc > 1)
(It is also possible to specify --topo-order on the command line)
As for the failure to import the output of fast-export with copy detection,
it is a natural consequence of a messed up order of commits, because
copy and move commands depend on the original file being there.
The attachment contains a (proper) export of a simplified sample of the
structure around dd22c7d51a4d, which clearly reproduces the problem
because all of the timestamps were made identical as a side effect of
simplification. By crafting timestamps it is probably possible to minimize
it even further.
Alexander
[-- Attachment #2: patchesx3b --]
[-- Type: text/plain, Size: 6707 bytes --]
blob
mark :1
data 5
2696
reset refs/heads/test
commit refs/heads/test
mark :2
author Alexander Gavrilov <angavrilov@gmail.com> 1228639325 +0300
committer Alexander Gavrilov <angavrilov@gmail.com> 1228639325 +0300
data 46
e4644a29ab6cb1993fc0dab55c320b7f2076e17b 2696
M 100644 :1 foo/a1
blob
mark :3
data 5
2697
commit refs/heads/test
mark :4
author Alexander Gavrilov <angavrilov@gmail.com> 1228639325 +0300
committer Alexander Gavrilov <angavrilov@gmail.com> 1228639325 +0300
data 46
d558c3feba34d69e8accc990267d60c3a11644c1 2697
from :2
M 100644 :3 foo/a1
blob
mark :5
data 5
2698
commit refs/heads/test
mark :6
author Alexander Gavrilov <angavrilov@gmail.com> 1228639325 +0300
committer Alexander Gavrilov <angavrilov@gmail.com> 1228639325 +0300
data 46
2e24b35039e9253a9089162f40113e28069cce56 2698
from :4
M 100644 :5 foo/a1
blob
mark :7
data 5
2699
commit refs/heads/test
mark :8
author Alexander Gavrilov <angavrilov@gmail.com> 1228639325 +0300
committer Alexander Gavrilov <angavrilov@gmail.com> 1228639325 +0300
data 46
0f78bea330e3a3b32f9204dfbdb9ca466ef78962 2699
from :6
M 100644 :7 foo/a1
blob
mark :9
data 5
2700
commit refs/heads/test
mark :10
author Alexander Gavrilov <angavrilov@gmail.com> 1228639325 +0300
committer Alexander Gavrilov <angavrilov@gmail.com> 1228639325 +0300
data 46
681ea67a40527f192bf279ea6346004120c64702 2700
from :8
M 100644 :9 foo/a1
blob
mark :11
data 5
2701
commit refs/heads/test
mark :12
author Alexander Gavrilov <angavrilov@gmail.com> 1228639325 +0300
committer Alexander Gavrilov <angavrilov@gmail.com> 1228639325 +0300
data 46
7faf0e5fb3c060385859caead8692d37c9700e55 2701
from :10
M 100644 :11 foo/a1
blob
mark :13
data 5
2702
commit refs/heads/test
mark :14
author Alexander Gavrilov <angavrilov@gmail.com> 1228639325 +0300
committer Alexander Gavrilov <angavrilov@gmail.com> 1228639325 +0300
data 46
d6ea85387203d59a9cddda6746bd3266598dc91d 2702
from :12
M 100644 :13 foo/a1
blob
mark :15
data 5
2703
commit refs/heads/test
mark :16
author Alexander Gavrilov <angavrilov@gmail.com> 1228639325 +0300
committer Alexander Gavrilov <angavrilov@gmail.com> 1228639325 +0300
data 46
fa22fab1d6d4cc192e288696fcb8947ebfd9e4a1 2703
from :14
M 100644 :15 foo/a1
blob
mark :17
data 5
2704
commit refs/heads/test
mark :18
author Alexander Gavrilov <angavrilov@gmail.com> 1228639325 +0300
committer Alexander Gavrilov <angavrilov@gmail.com> 1228639325 +0300
data 46
dd22c7d51a4debf18a3b2e35c61a1fec0175e4e0 2704
from :16
M 100644 :17 foo/a1
blob
mark :19
data 5
2705
commit refs/heads/test
mark :20
author Alexander Gavrilov <angavrilov@gmail.com> 1228639325 +0300
committer Alexander Gavrilov <angavrilov@gmail.com> 1228639325 +0300
data 46
84e2addc90ccf17d1cfcf657c241cf6cda5d46c1 2705
from :18
M 100644 :19 foo/a1
blob
mark :21
data 5
2706
commit refs/heads/test
mark :22
author Alexander Gavrilov <angavrilov@gmail.com> 1228639325 +0300
committer Alexander Gavrilov <angavrilov@gmail.com> 1228639325 +0300
data 46
6584b0f9e720d3035739a33e5a24d3b4e3129127 2706
from :20
M 100644 :21 foo/a1
blob
mark :23
data 5
2707
commit refs/heads/test
mark :24
author Alexander Gavrilov <angavrilov@gmail.com> 1228639325 +0300
committer Alexander Gavrilov <angavrilov@gmail.com> 1228639325 +0300
data 46
75e46ad7079a9841332731e4701b911b73b5be23 2707
from :22
M 100644 :23 foo/a1
blob
mark :25
data 5
2708
commit refs/heads/test
mark :26
author Alexander Gavrilov <angavrilov@gmail.com> 1228639325 +0300
committer Alexander Gavrilov <angavrilov@gmail.com> 1228639325 +0300
data 46
52d087c1e3aba5c1d158e6fb35fea9c40602ac11 2708
from :24
M 100644 :25 foo/a1
blob
mark :27
data 5
2709
commit refs/heads/test
mark :28
author Alexander Gavrilov <angavrilov@gmail.com> 1228639325 +0300
committer Alexander Gavrilov <angavrilov@gmail.com> 1228639325 +0300
data 46
384679f01372baa92ce6e43475b44e2eb607ce67 2709
from :26
M 100644 :27 foo/a1
blob
mark :29
data 5
2710
commit refs/heads/test
mark :30
author Alexander Gavrilov <angavrilov@gmail.com> 1228639325 +0300
committer Alexander Gavrilov <angavrilov@gmail.com> 1228639325 +0300
data 46
98def8453c487d7f54ff01d92268a0aa2c68f872 2710
from :28
M 100644 :29 foo/a1
blob
mark :31
data 5
2711
commit refs/heads/test
mark :32
author Alexander Gavrilov <angavrilov@gmail.com> 1228639325 +0300
committer Alexander Gavrilov <angavrilov@gmail.com> 1228639325 +0300
data 46
529c626be804ea6201d53856f9d4a30d62b75248 2711
from :30
M 100644 :31 foo/a1
blob
mark :33
data 5
2712
commit refs/heads/test
mark :34
author Alexander Gavrilov <angavrilov@gmail.com> 1228639325 +0300
committer Alexander Gavrilov <angavrilov@gmail.com> 1228639325 +0300
data 46
c75ea627851e93d6fcbc3d45db1aff00832a403e 2712
from :32
merge :10
M 100644 :33 foo/a1
blob
mark :35
data 5
2713
commit refs/heads/test
mark :36
author Alexander Gavrilov <angavrilov@gmail.com> 1228639325 +0300
committer Alexander Gavrilov <angavrilov@gmail.com> 1228639325 +0300
data 46
8c436c18ab0922c71fa2a111632d2fc9e1783342 2713
from :34
M 100644 :35 foo/a1
blob
mark :37
data 5
2714
commit refs/heads/test
mark :38
author Alexander Gavrilov <angavrilov@gmail.com> 1228639325 +0300
committer Alexander Gavrilov <angavrilov@gmail.com> 1228639325 +0300
data 46
c71f0c84d5b812445f1857e23c8737eeb886ae3e 2714
from :36
merge :12
M 100644 :37 foo/a1
blob
mark :39
data 5
2715
commit refs/heads/test
mark :40
author Alexander Gavrilov <angavrilov@gmail.com> 1228639325 +0300
committer Alexander Gavrilov <angavrilov@gmail.com> 1228639325 +0300
data 46
1086e78f66e10ca873e75d245442f8001f7893cf 2715
from :38
merge :14
M 100644 :39 foo/a1
blob
mark :41
data 5
2716
commit refs/heads/test
mark :42
author Alexander Gavrilov <angavrilov@gmail.com> 1228639325 +0300
committer Alexander Gavrilov <angavrilov@gmail.com> 1228639325 +0300
data 46
8c3e2e17eb6892069c32696784795c737fb703dd 2716
from :40
merge :16
M 100644 :41 foo/a1
blob
mark :43
data 5
2717
commit refs/heads/test
mark :44
author Alexander Gavrilov <angavrilov@gmail.com> 1228639325 +0300
committer Alexander Gavrilov <angavrilov@gmail.com> 1228639325 +0300
data 46
c9d47e2b0166eb0d3ff8af2cb65e315b96d02af8 2717
from :42
M 100644 :43 foo/a1
blob
mark :45
data 5
2718
commit refs/heads/test
mark :46
author Alexander Gavrilov <angavrilov@gmail.com> 1228639325 +0300
committer Alexander Gavrilov <angavrilov@gmail.com> 1228639325 +0300
data 46
537dfcc8c4d15b6a1774e8b37e2ac808972c0cb5 2718
from :44
M 100644 :45 foo/a1
blob
mark :47
data 5
2719
commit refs/heads/test
mark :48
author Alexander Gavrilov <angavrilov@gmail.com> 1228639325 +0300
committer Alexander Gavrilov <angavrilov@gmail.com> 1228639325 +0300
data 46
594b654469e74362bf7e77872e5bc802a03fbf01 2719
from :46
M 100644 :47 foo/a1
^ permalink raw reply related
* Re: [PATCH] gitweb: Make project specific override for 'grep' feature work
From: Jakub Narebski @ 2008-12-07 11:16 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Matt Kraai
In-Reply-To: <7vljuscl4v.fsf@gitster.siamese.dyndns.org>
On Sun, 7 Dec 2008, Junio C Hamano wrote:
> Thanks, both. This should go to maint, right?
>
Yes, I think so.
--
Jakub Narebski
Poland
^ permalink raw reply
* Re: [PATCH] gitweb: Make project specific override for 'grep' feature work
From: Junio C Hamano @ 2008-12-07 10:52 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git, Matt Kraai
In-Reply-To: <20081207093447.25785.41811.stgit@localhost.localdomain>
Thanks, both. This should go to maint, right?
^ permalink raw reply
* Re: checking action of git-pull
From: Junio C Hamano @ 2008-12-07 10:51 UTC (permalink / raw)
To: Mark Ryden; +Cc: git
In-Reply-To: <dac45060812070023h7f6a6c86ve2e4ba9f1773f03f@mail.gmail.com>
"Mark Ryden" <markryde@gmail.com> writes:
> Hello,
> I am working against a git repository which is updated at non regular
> intervals; sometimes it takes a day and sometimes a week or two.
>
> I have a script in crontab which runs daily which tries "git pull" of
> this repository.
>
> I want write a bash script which echoes yhe result of this git pull
> to a log file in such
> a way that in case that any files were pulled, a short message
> saying "files were pulled at date ddmmyyyy" will be added to a log file.
> In case that there there were no changes, a message saying
> "Already up-to-date (ddmmyyyy) will be added to a log file.
>
> How can it be done ?
> can I test somehow the return value of git pull in a bash script for
> these two different
> cases?
You know that a no-op pull does not update HEAD and a successful pull
does. So your script would do something like:
#!/bin/sh
original_head=$(git rev-parse HEAD) || exit
git pull origin || exit
updated_head=$(git rev-parse HEAD) || exit
if test "$updated_head" = "$original_head"
then
echo Upstream is idling
else
echo These new commits were brought in
git shortlog $original_head..$updated_head
fi
^ permalink raw reply
* Re: [RFCv4 1/3] gitweb: add patch view
From: Giuseppe Bilotta @ 2008-12-07 9:52 UTC (permalink / raw)
To: Matt Kraai; +Cc: git
In-Reply-To: <20081207060430.GE4357@ftbfs.org>
On Sun, Dec 7, 2008 at 7:04 AM, Matt Kraai <kraai@ftbfs.org> wrote:
> Howdy,
>
> Why do you check $patch_max at the start of git_commitdiff instead of
> at the start of hunk which opens git-format-patch? It seems like it
> would be clearer to check it later, at some small loss of efficiency.
Subsequent patches use the check to add a link to the nav bar, so it
reduces code shift from patch to patch 8-)
--
Giuseppe "Oblomov" Bilotta
^ permalink raw reply
* [PATCH] gitweb: Make project specific override for 'grep' feature work
From: Jakub Narebski @ 2008-12-07 9:36 UTC (permalink / raw)
To: git; +Cc: Matt Kraai
In-Reply-To: <20081207052230.GD4357@ftbfs.org>
The 'grep' feature was marked in the comments as having project
specific config, but it lacked 'sub' key required for it to work.
Kind-of-Noticed-by: Matt Kraai <kraai@ftbfs.org>
Signed-off-by: Jakub Narebski <jnareb@gmail.com>
---
Matt Kraai wrote:
> A feature_grep subroutine is defined in gitweb.perl, but unlike the
> other feature_* subroutines there, it doesn't appear to be used
> anywhere. Should it be removed?
No, it was oversight; it should be used in setting up 'grep' %feature
configuration, see below.
Thanks for catching this.
gitweb/gitweb.perl | 1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl
index 95988fb..9517392 100755
--- a/gitweb/gitweb.perl
+++ b/gitweb/gitweb.perl
@@ -241,6 +241,7 @@ our %feature = (
# $feature{'grep'}{'override'} = 1;
# and in project config gitweb.grep = 0|1;
'grep' => {
+ 'sub' => \&feature_grep,
'override' => 0,
'default' => [1]},
^ permalink raw reply related
* Re: How to clone git repository with git-svn meta-data included?
From: Jacob Helwig @ 2008-12-07 8:43 UTC (permalink / raw)
To: Grzegorz Kossakowski; +Cc: git
In-Reply-To: <493A6CEC.4060601@tuffmail.com>
On Sat, Dec 6, 2008 at 04:15, Grzegorz Kossakowski <grek@tuffmail.com> wrote:
> Hello,
>
> Some folks at Apache are experimenting with Git and we are currently seeking for the git-svn
> integration that fits our needs and infrastructure.
>
> After some evaluation we decided that our setup could be described using following points:
> a) our svn repository remains our main, official server where every committer is obligated to push
> their changes to at some time.
> b) we set up clone of svn repository using git-svn. One of our members, Jukka Zitting, maintains
> such a service here[1]. Such repositories should be usable both for our committers (that have rights
> to push to svn) and our contributors that want to contribute random patches
> c) we want carefully track who committed/contributed what
>
> Basically, a) implies b) and point b) looks little bit problematic right now.
> Jukka has set up his hosting using method described in his e-mail[2] which basically makes use of
> git svn. The major problem is that if one clones Jukka's repository then git svn information is not
> being cloned so committers have no means to push their changes to main, svn server.
>
> I've tried to play a little bit around with this issue and I tried to copy information from .git
> directory found on Jukka's server. This made me able to push my changes but git svn insisted on
> rebasing my repository using commits found in svn which is wrong. Basically we want such a setup
> that uses git repository (Jukka's clone) for pulling changes and local git svn for pushing changes.
> Git svn should never try to rebase local repository because this will lead to two different trees on
> two different machines so we won't be able to exchange and merge changesets.
>
> Is it possible with Git right now?
>
>
> Another point (c) which seems to be brought a couple of times but never a definitive answer has been
> given, AFAIK. Let's imagine we have committer C and two contributors A and B.
>
> A and B start to work on some feature and C agreed to help A and B and once their work is finished
> to merge their changes into his repository and eventually push them to main, svn repository. Now A
> and B work on implementation and from time to time their merge changes from each other. Once they
> are finished A asks C to merge their work into C's repository. Everything is fine provided we can
> trust both A and B.
>
> What if A was not fair and has rewritten a few commits coming from B so they contain malicious code?
> How we can detect something like that and how C be sure that what he merges is really work
> attributed by correct names?
>
> Thanks for your answers.
>
> [1] http://jukka.zitting.name/git/
> [2] http://markmail.org/message/fzzy7nepk7olx5fl
>
>
> --
> Best regards,
> Grzegorz Kossakowski
> --
> To unsubscribe from this list: send the line "unsubscribe git" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
Grzegorz,
I use git-svn quite a bit at $work, but I haven't seen a way to clone
a git repo, and have it Just Work(TM) with git-svn in the new clone,
unfortunately.
I have been able to use clone to significantly cut down on the setup
time for working with git-svn, however. I was following the
directions at http://subtlegradient.com/articles/2008/04/22/cloning-a-git-svn-clone
(Clone the git-svn clone, then re-do the git svn init, and fetch to
re-sync.)
Not sure how much this will actually help you with the first part of
your problem.
-Jacob
^ permalink raw reply
* checking action of git-pull
From: Mark Ryden @ 2008-12-07 8:23 UTC (permalink / raw)
To: git
Hello,
I am working against a git repository which is updated at non regular
intervals; sometimes it takes a day and sometimes a week or two.
I have a script in crontab which runs daily which tries "git pull" of
this repository.
I want write a bash script which echoes yhe result of this git pull
to a log file in such
a way that in case that any files were pulled, a short message
saying "files were pulled at date ddmmyyyy" will be added to a log file.
In case that there there were no changes, a message saying
"Already up-to-date (ddmmyyyy) will be added to a log file.
How can it be done ?
can I test somehow the return value of git pull in a bash script for
these two different
cases?
Regards,
Mark
^ permalink raw reply
* Remove feature_grep in gitweb?
From: Matt Kraai @ 2008-12-07 5:22 UTC (permalink / raw)
To: git
Howdy,
A feature_grep subroutine is defined in gitweb.perl, but unlike the
other feature_* subroutines there, it doesn't appear to be used
anywhere. Should it be removed?
--
Matt http://ftbfs.org/
^ permalink raw reply
* Re: What's cooking in git.git (Nov 2008, #06; Wed, 26)
From: Junio C Hamano @ 2008-12-07 3:45 UTC (permalink / raw)
To: Daniel Barkalow
Cc: Nguyen Thai Ngoc Duy, Shawn O. Pearce, Johannes Schindelin, git
In-Reply-To: <alpine.LNX.1.00.0811301509070.19665@iabervon.org>
Daniel Barkalow <barkalow@iabervon.org> writes:
>> As I said, CE_VALID implies all files are present.
>
> My first question is whether this actually should be true.
If the user says "Please pretend that I have never touched this file",
which is what "assume unchanged" is all about, I think we should not
notice if the user removes one of such files from the working tree, just
like we don't notice (rather, pretend not to notice) if the user modified
it.
I am inclined to think that we should rather treat that as a bug.
^ permalink raw reply
* [PATCH] http.c: use 'git_config_string' to get 'curl_http_proxy'
From: Miklos Vajna @ 2008-12-07 0:45 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
Signed-off-by: Miklos Vajna <vmiklos@frugalware.org>
---
http.c | 11 ++++-------
1 files changed, 4 insertions(+), 7 deletions(-)
diff --git a/http.c b/http.c
index ed59b79..ee58799 100644
--- a/http.c
+++ b/http.c
@@ -24,7 +24,7 @@ static const char *ssl_cainfo = NULL;
static long curl_low_speed_limit = -1;
static long curl_low_speed_time = -1;
static int curl_ftp_no_epsv = 0;
-static char *curl_http_proxy = NULL;
+static const char *curl_http_proxy = NULL;
static struct curl_slist *pragma_header;
@@ -149,11 +149,8 @@ static int http_options(const char *var, const char *value, void *cb)
return 0;
}
if (!strcmp("http.proxy", var)) {
- if (curl_http_proxy == NULL) {
- if (!value)
- return config_error_nonbool(var);
- curl_http_proxy = xstrdup(value);
- }
+ if (curl_http_proxy == NULL)
+ return git_config_string(&curl_http_proxy, var, value);
return 0;
}
@@ -309,7 +306,7 @@ void http_cleanup(void)
pragma_header = NULL;
if (curl_http_proxy) {
- free(curl_http_proxy);
+ free((void *)curl_http_proxy);
curl_http_proxy = NULL;
}
}
--
1.6.1.rc1.35.gae26e.dirty
^ permalink raw reply related
* Re: Git Books
From: Deskin Miller @ 2008-12-06 23:48 UTC (permalink / raw)
To: Scott Chacon; +Cc: git list
In-Reply-To: <20081206194515.GA4721@atjola.homenet>
On 2008.12.06 03:58:28 -0800, Scott Chacon wrote:
> So, since I'm near the beginning of this process, I was wondering if
> the group had any feedback as to what might be super helpful to
> include. I mean, I have a pretty good layout and all, but if you
> wanted to point me to some threads that tend to crop up in the mailing
> list and IRC channel from relative newcomers that I might be able to
> nip in the bud, I would like to. I'm addressing the stuff that _I_
> hear a lot, and I'm scanning the IRC logs and list for topics, but I
> figured many of you must answer the same questions all the time, too.
I agree with pretty much all of the other suggestions made thus far.
One I'd vote for is to explain why pushing to a non-bare repository
doesn't magically update the working tree as well; I'd say it's easily
one of the most repeated questions on #git.
I also vote for addressing workflows heavily. Also, I think a reference
section akin to Tv's 'Git for Computer Scientists' page[1] would be
handy; I find understanding how git represents the project to inform
almost every interesting question about how to accomplish one's goals in
a particular situation.
Deskin Miller
[1] http://eagain.net/articles/git-for-computer-scientists/
^ 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