* Re: Split a subversion repo into several git repos
From: Patrick Doyle @ 2007-10-11 13:24 UTC (permalink / raw)
To: Eivind LM; +Cc: git
In-Reply-To: <op.tz09zaizjwclfx@ichi>
If you look through the Subversion FAQ or the book (I forget where
I've seen it -- but I know I've seen it), you can export/filter out a
tree from a subversion repository and load it into a new repository.
Then you can import from that new repository.
This presumes you have direct access to the subversion repository and
can run commands like svnadmin --dump.
--wpd
On 10/11/07, Eivind LM <eivliste@online.no> wrote:
> Hi,
> I would like to convert a subversion repository to Git. The subversion
> repository used to track development of several projects (only slightly
> related), and I would like to divide the repository into several smaller
> git repositories.
>
> For example, I want to convert one subversion repository which contains
> the folders:
> trunk/projectA
> trunk/projectB
>
> into two git repositories:
> projectA.git
> projectB.git
>
> As far as I have understood, the way to do this is to
> 1) Convert the entire subversion repository to git with git-svn.
> 2) Make two copies of the whole new git-repository (projectA.git and
> projectB.git).
> 3) Use git-rm to remove projectB from projectA.git, and projectA from
> projectB.git.
>
> This works fine, but both git-repositories now carries the history for
> both projects. If possible, I would like to "clean" the history in the
> repositories, so that I don't see history information for projectA when I
> am browsing logs in projectB.git. Has anyone been in the same situation?
> Do you have suggestions on how it can be solved?
>
> Any help will be greatly appreciated.
>
> Thanks,
> Eivind
> -
> 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
>
^ permalink raw reply
* Re: Split a subversion repo into several git repos
From: Jonathan del Strother @ 2007-10-11 13:46 UTC (permalink / raw)
To: Eivind LM; +Cc: git
In-Reply-To: <op.tz09zaizjwclfx@ichi>
On 11 Oct 2007, at 13:51, Eivind LM wrote:
> Hi,
> I would like to convert a subversion repository to Git. The
> subversion repository used to track development of several projects
> (only slightly related), and I would like to divide the repository
> into several smaller git repositories.
>
> For example, I want to convert one subversion repository which
> contains the folders:
> trunk/projectA
> trunk/projectB
>
> into two git repositories:
> projectA.git
> projectB.git
I have a slightly different layout to you -
projectA/trunk
projectA/branches
projectA/tags
projectB/trunk
projectB/branches
projectB/tags
etc
- but I've been creating separate git repos from that with (for
example) :
git-svn init -t tags -b branches -T trunk http://svn.host.com/projectA
git-svn fetch
Or will git-svn not work with your sort of layout?
^ permalink raw reply
* Re: Split a subversion repo into several git repos
From: Patrick Doyle @ 2007-10-11 14:02 UTC (permalink / raw)
To: Jonathan del Strother; +Cc: Eivind LM, git
In-Reply-To: <27DDC599-C7A0-4660-B5C6-7DFCEB137C14@steelskies.com>
On 10/11/07, Jonathan del Strother <maillist@steelskies.com> wrote:
> I have a slightly different layout to you -
>
> projectA/trunk
> projectA/branches
> projectA/tags
> projectB/trunk
> projectB/branches
> projectB/tags
> etc
>
> - but I've been creating separate git repos from that with (for
> example) :
>
> git-svn init -t tags -b branches -T trunk http://svn.host.com/projectA
> git-svn fetch
>
Just be aware that, if you follow this approach, the commit logs
created by git-svn will be rewritten (relative to the original SVN
logs) with the SVN repository revision and ID information. I believe
you can disable this behavior by passing the --no-metadata option to
"git-svn init", but I haven't tried this yet.
I also believe that this approach will leave your git repository in
such as state as to recognize that there is a remote repository from
which this repository was fetched. I have no idea what implications
and long term repercussions (if any) this has. It just dawned on me
as I was rereading the git-svn man page to look for the --no-metdata
option and read that it will "Set the noMetadata option in the
[svn-remote] config". Most of that is still Greek to me.
--wpd
^ permalink raw reply
* yet another workflow question...
From: Patrick Doyle @ 2007-10-11 14:11 UTC (permalink / raw)
To: git
Sorry for cluttering up the list with yet another very basic workflow
question, but I'm still struggling with finding an answer to the
burning question, "What can git do for me?" (So far, I have come to
the conclusion that, for my simple, single developer, branchless,
linear projects, there's not much that git can do for me that any
other SCM could do for me. It appears to have been designed to solve
problems for which I have absolutely no appreciation whatsoever. :-))
Anyway, on to basic newbie quesion #107...
I've been working on my project and I realize that I have 3-4 files
modified with two orthogonal sets of changes. (I didn't realize this
until I said to myself -- "Self, I should really check in these files
before I go too much further down this path".) So I start "git
diff"-ing the files and I find that most files have differences
related to only one change or the other, but one file has differences
related to both changes.
What do others do in this situation?
a) Not allow themselves to get into this situation in the first place
by careful planning?
b) Copy the file to "file.bothchanges", edit out one set of changes,
commit that with one log message, edit back in the other set of
changes, edit in the other set of changes, commit that with another
log message?
c) Use some sort of automation to do option (b) for them?
d) Something else?
--wpd
^ permalink raw reply
* Re: yet another workflow question...
From: David Kastrup @ 2007-10-11 14:18 UTC (permalink / raw)
To: git
In-Reply-To: <e2a1d0aa0710110711m77ca967bmd1d5ffd5d3099aab@mail.gmail.com>
"Patrick Doyle" <wpdster@gmail.com> writes:
> Sorry for cluttering up the list with yet another very basic workflow
> question, but I'm still struggling with finding an answer to the
> burning question, "What can git do for me?" (So far, I have come to
> the conclusion that, for my simple, single developer, branchless,
> linear projects, there's not much that git can do for me that any
> other SCM could do for me. It appears to have been designed to solve
> problems for which I have absolutely no appreciation whatsoever. :-))
>
> Anyway, on to basic newbie quesion #107...
>
> I've been working on my project and I realize that I have 3-4 files
> modified with two orthogonal sets of changes. (I didn't realize this
> until I said to myself -- "Self, I should really check in these files
> before I go too much further down this path".) So I start "git
> diff"-ing the files and I find that most files have differences
> related to only one change or the other, but one file has differences
> related to both changes.
>
> What do others do in this situation?
> a) Not allow themselves to get into this situation in the first place
> by careful planning?
>
> b) Copy the file to "file.bothchanges", edit out one set of changes,
> commit that with one log message, edit back in the other set of
> changes, edit in the other set of changes, commit that with another
> log message?
>
> c) Use some sort of automation to do option (b) for them?
>
> d) Something else?
git-add -i
--
David Kastrup
^ permalink raw reply
* Re: yet another workflow question...
From: Johannes Sixt @ 2007-10-11 14:37 UTC (permalink / raw)
To: Patrick Doyle; +Cc: git
In-Reply-To: <e2a1d0aa0710110711m77ca967bmd1d5ffd5d3099aab@mail.gmail.com>
Patrick Doyle schrieb:
> I've been working on my project and I realize that I have 3-4 files
> modified with two orthogonal sets of changes. (I didn't realize this
> until I said to myself -- "Self, I should really check in these files
> before I go too much further down this path".) So I start "git
> diff"-ing the files and I find that most files have differences
> related to only one change or the other, but one file has differences
> related to both changes.
>
> What do others do in this situation?
> a) Not allow themselves to get into this situation in the first place
> by careful planning?
>
> b) Copy the file to "file.bothchanges", edit out one set of changes,
> commit that with one log message, edit back in the other set of
> changes, edit in the other set of changes, commit that with another
> log message?
>
> c) Use some sort of automation to do option (b) for them?
>
> d) Something else?
Use git-gui.
Stage the files relevant for the first change. In the file where you have an
overlap with the second change, you can right-click in the diff pane and
select "Stage Hunk for Commit" on the hunk relevant for the first change.[*]
Commit with a message.
Stage the remaining changes and commit again.
At this point, I usually check out HEAD~1, i.e. the state *without* the
second change, and compile and test to make sure I have a bisectable history.
[*] Of course, this works only if the changes are not in the same hunk. If
there are at least 3 unmodified lines between the changes, you can choose
"Less context" until they are in separate hunks.
-- Hannes
^ permalink raw reply
* Re: yet another workflow question...
From: Wincent Colaiuta @ 2007-10-11 14:39 UTC (permalink / raw)
To: Patrick Doyle; +Cc: git
In-Reply-To: <e2a1d0aa0710110711m77ca967bmd1d5ffd5d3099aab@mail.gmail.com>
El 11/10/2007, a las 16:11, Patrick Doyle escribió:
> Sorry for cluttering up the list with yet another very basic workflow
> question, but I'm still struggling with finding an answer to the
> burning question, "What can git do for me?" (So far, I have come to
> the conclusion that, for my simple, single developer, branchless,
> linear projects, there's not much that git can do for me that any
> other SCM could do for me. It appears to have been designed to solve
> problems for which I have absolutely no appreciation whatsoever. :-))
Even with the workflow you describe, Git brings some nice benefits:
1. Faster than anything else out there
2. You can work offline (even if you have an "always on" net
connection, think about the times when it goes down)
3. You can easily amend mistakes in your last commit (git-commit --
amend)
4. You can easily stash away work in progress and go off on a tangent
(git-stash)
5. You get nice colorized diff and log output for free
6. Great visualization tools included for free (gitk, git-gui etc)
And those are just a few off the top of my head. The more you work
with Git, the more benefits you will discover, even if you're not
trying to do anything fancy with it. And although you are currently
using branchless development, you may find with time that you start
using things like topic branches simply because Git makes it so darn
easy to do so, and the benefit is that you'll keep your history much
cleaner and easier to understand when you go back to look at it later
on.
Cheers,
Wincent
^ permalink raw reply
* Re: yet another workflow question...
From: Steffen Prohaska @ 2007-10-11 14:44 UTC (permalink / raw)
To: David Kastrup; +Cc: git
In-Reply-To: <86lka9spjq.fsf@lola.quinscape.zz>
On Oct 11, 2007, at 4:18 PM, David Kastrup wrote:
> "Patrick Doyle" <wpdster@gmail.com> writes:
>
>> Sorry for cluttering up the list with yet another very basic workflow
>> question, but I'm still struggling with finding an answer to the
>> burning question, "What can git do for me?" (So far, I have come to
>> the conclusion that, for my simple, single developer, branchless,
>> linear projects, there's not much that git can do for me that any
>> other SCM could do for me. It appears to have been designed to solve
>> problems for which I have absolutely no appreciation whatsoever. :-))
>>
>> Anyway, on to basic newbie quesion #107...
>>
>> I've been working on my project and I realize that I have 3-4 files
>> modified with two orthogonal sets of changes. (I didn't realize this
>> until I said to myself -- "Self, I should really check in these files
>> before I go too much further down this path".) So I start "git
>> diff"-ing the files and I find that most files have differences
>> related to only one change or the other, but one file has differences
>> related to both changes.
>>
>> What do others do in this situation?
>> a) Not allow themselves to get into this situation in the first place
>> by careful planning?
>>
>> b) Copy the file to "file.bothchanges", edit out one set of changes,
>> commit that with one log message, edit back in the other set of
>> changes, edit in the other set of changes, commit that with another
>> log message?
>>
>> c) Use some sort of automation to do option (b) for them?
>>
>> d) Something else?
>
> git-add -i
git-gui, right click on change.
From the user manual:
"""
You can also use git-gui(1) to create commits, view changes in the
index and the working tree files, and individually select diff hunks
for inclusion in the index (by right-clicking on the diff hunk and
choosing "Stage Hunk For Commit").
"""
Steffen
^ permalink raw reply
* RCS keyword expansion
From: Peter Karlsson @ 2007-10-11 14:47 UTC (permalink / raw)
To: git
Hi!
I've looked and looked, but cannot figure out how to do RCS/CVS style
keyword expansion with Git. The FAQ on the Wiki is quite cryptic on the
subject, and my googling skills fail short.
I mainly want to have $Date$ expand in RCS/CVS manner, i.e to when the
file was last changed. Possibly even have an $Id$ that gives me
something useful (name and commit hash, perhaps?). Is it possible to do
this? Can it be done through git-cvsserver?
I currently have my personal website in CVS and am using $Date$ to
include a datestamp on the pages. I am considering converting the
repository to Git, but only after I can get $Date$ expansion to work.
I am considering having the website host believe it still is a cvs
repository by using git-cvsserver, thus my question about expanding
$Date$ through it.
--
\\// Peter - http://www.softwolves.pp.se/
^ permalink raw reply
* Re: Split a subversion repo into several git repos
From: Karl Hasselström @ 2007-10-11 14:50 UTC (permalink / raw)
To: Patrick Doyle; +Cc: Jonathan del Strother, Eivind LM, git
In-Reply-To: <e2a1d0aa0710110702o359d6cd9yaa213be6a43924e4@mail.gmail.com>
On 2007-10-11 10:02:21 -0400, Patrick Doyle wrote:
> Just be aware that, if you follow this approach, the commit logs
> created by git-svn will be rewritten (relative to the original SVN
> logs) with the SVN repository revision and ID information. I believe
> you can disable this behavior by passing the --no-metadata option to
> "git-svn init", but I haven't tried this yet.
Just to clarify: this is true for all git-svn use, and has nothing to
do with this particular case.
> I also believe that this approach will leave your git repository in
> such as state as to recognize that there is a remote repository from
> which this repository was fetched. I have no idea what implications
> and long term repercussions (if any) this has. It just dawned on me
> as I was rereading the git-svn man page to look for the --no-metdata
> option and read that it will "Set the noMetadata option in the
> [svn-remote] config". Most of that is still Greek to me.
Apart from the metadata appended to the commit messages (which you can
turn off with --no-metadata), all the extra data saved by git-svn is
purely local. Meaning that you can always get rid of it by cloning the
repository, if you can't think of a cleverer way to do it.
--
Karl Hasselström, kha@treskal.com
www.treskal.com/kalle
^ permalink raw reply
* Re: RCS keyword expansion
From: Johannes Sixt @ 2007-10-11 15:02 UTC (permalink / raw)
To: Peter Karlsson; +Cc: git
In-Reply-To: <Pine.LNX.4.64.0710111542420.23849@ds9.cixit.se>
Peter Karlsson schrieb:
> I've looked and looked, but cannot figure out how to do RCS/CVS style
> keyword expansion with Git. The FAQ on the Wiki is quite cryptic on the
> subject, and my googling skills fail short.
Cryptic?
Q: Does git have keyword expansion?
A: No.
To me this is crystal clear.
:-)
-- Hannes
^ permalink raw reply
* Re: RCS keyword expansion
From: Randal L. Schwartz @ 2007-10-11 15:09 UTC (permalink / raw)
To: Peter Karlsson; +Cc: git
In-Reply-To: <Pine.LNX.4.64.0710111542420.23849@ds9.cixit.se>
>>>>> "Peter" == Peter Karlsson <peter@softwolves.pp.se> writes:
Peter> I mainly want to have $Date$ expand in RCS/CVS manner, i.e to when the
Peter> file was last changed. Possibly even have an $Id$ that gives me
Peter> something useful (name and commit hash, perhaps?). Is it possible to do
Peter> this? Can it be done through git-cvsserver?
That's not a job for a source code manager to do. It's a job for your
build/install tool. See how "git --version" gets created in the core distro,
and follow that example.
--
Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095
<merlyn@stonehenge.com> <URL:http://www.stonehenge.com/merlyn/>
Perl/Unix/security consulting, Technical writing, Comedy, etc. etc.
See PerlTraining.Stonehenge.com for onsite and open-enrollment Perl training!
^ permalink raw reply
* Re: yet another workflow question...
From: Andy Parkins @ 2007-10-11 15:10 UTC (permalink / raw)
To: git; +Cc: Patrick Doyle
In-Reply-To: <e2a1d0aa0710110711m77ca967bmd1d5ffd5d3099aab@mail.gmail.com>
On Thursday 2007 October 11, Patrick Doyle wrote:
> burning question, "What can git do for me?" (So far, I have come to
> the conclusion that, for my simple, single developer, branchless,
> linear projects, there's not much that git can do for me that any
> other SCM could do for me. It appears to have been designed to solve
Here's a few things that are relevant to a simple, single, branchless, linear
developer:
- Fast. Git wipes the floor with everything else, so much so that the SCM
becomes a tool in itself, not just a recorder of history. I keep my own
simple projects in git just as much as my complicated, branchy, team-based
projects just to get the following tools fast:
git-diff
git-status
git-commit
git-log
- Small. In every project I've converted from SVN to git, the diskspace
usage has gone down. SVN peppers the working tree with .svn directories,
each of which contains a pristine copy of the last checked in version of
all the working files. On top of that is the repository disk space itself.
Git on the other hand keeps one .git directory at the top of the tree and
that stores the _entire_ repository. It is, in my experience, smaller than
the working tree. That means that git uses less diskspace than svn does
for a single checkout to store everything it needs.
- Useful. The following are so good, that even if you weren't doing any
revision tracking you'd still want to use them:
git-grep
git-diff
- Backup. Backing up subversion repositories requires that you write
yourself a script that uses svnadmin dump. With git I just write a couple
of lines in my .git/config and then git-push produces a highly compact
backup whenever I want. Even better, if a disaster happens it's easy to
pull stuff out of that backup without any additional operations.
- Mobility. This one is a bit distributed, but I hope you'll let me have it.
I often do work on my desktop at home, my desktop at work and my laptop.
By setting my remotes up correctly in git it's really easy to walk to
another system and pick up exactly where I left off from the other
computer. More importantly though, when you accidentally make changes in
two places, there is no danger of data loss.
Even if you aren't doing complicated stuff, git is the way to go. I can't
count the number of ways it's made me more productive and enhanced the code I
write and the documentation of its development. If I never worked on another
group project again I would still use git all day every day.
Andy
--
Dr Andy Parkins, M Eng (hons), MIET
andyparkins@gmail.com
^ permalink raw reply
* Re: git branch performance problem?
From: Linus Torvalds @ 2007-10-11 15:16 UTC (permalink / raw)
To: hanwen; +Cc: Lars Hjemli, git
In-Reply-To: <f329bf540710101926vedf8b19p52e3eeb193203d03@mail.gmail.com>
On Wed, 10 Oct 2007, Han-Wen Nienhuys wrote:
>
> I recall reading a few months ago that it was "clone -l" that gave you
> the jeebies, rather than "clone -s".
Yes, "clone -l" gives me the jeebies, because I'm a totally anal person
when it comes to disk corruption and a worry-wart. I've just had it happen
too many times (usually because a disk simply goes bad), and "git clone
-l" basically means that if one repository gets corrupted, then so does
the other one.
But clone -s gives me even *more* jeebies, although I think it's in some
respect also more useful. The alternates thing is really useful for
servers in particular, where you basically want to have multiple
"branches" maintained by lots of people, but all based on some expected
base version.
So if you think of alternates as a "kernel.org" or "repo.or.cz" thing,
where you might have a hundred different repositories all based on the
same "standard" version, then I think you basically have the right model.
In that situation, "git clone -l" doesn't work that well, since the
repositories just start out sharing data, but don't do it long term.
So "git clone -l" (which is the default now - my jeebies really are my
personal psychological problem) is really useful for latency reasons for a
local clone, and has basically no real downsides. It's not useful for
*backups*, but it's useful for development.
> > So the rule really is: never *ever* do anything but fast-forward in a repo
> >[..]
>
> Methinks this is all too difficult. I will use clone -l henceforth. Is
> there any reason to prefer -s over -l?
Good. And no, for actual *development* there is no reason to prefer -s
over -l (and as mentioned, '-l' is the default in modern versions).
For a git *server* setup, -s is better, since it's more long-term. But in
that situation, it also requires that the server maintainer have some
rules (ie only use "-s" for stable base trees and/or use extra care when
repacking the base).
> Given your lengthy exposition on the dangers of alternates, I would say
> this is a features that deserves to be buried or at least deemphasized
> in the documentation.
I do agree. We should make the dangers very clear.
> For cherrypicking convenience, I would still appreciate it if there
> was a mechanism similar to alternates that would allow me to view
> objects from an alternate repo; objects found through this mechanism
> should never be assumed to be present in the database, of course.
Well, the way that really should work is that you "git fetch remote" and
work on the end result in a "remote branch".
That *will* make the objects present in the database, but not in your
actual branches (until you cherry-pick), but there really are no real
downsides. If the remote is truly related to your local tree, it all
delta's so well that the disk space issues should basically be none.
Linus
^ permalink raw reply
* Suggestion for mailing lists... split [PATCH]-es into own list
From: Thomas Harning Jr. @ 2007-10-11 15:57 UTC (permalink / raw)
To: git
I use gmail as my mail client and it doesn't grok 'PATCH' filters
(primarily the case of the word).
Are there any of you using Gmail that has managed to get around this issue....?
Perhaps we should have a separate mailing list for patches vs discussion.
--
Thomas Harning Jr.
^ permalink raw reply
* Re: Suggestion for mailing lists... split [PATCH]-es into own list
From: Johannes Schindelin @ 2007-10-11 16:07 UTC (permalink / raw)
To: Thomas Harning Jr.; +Cc: git
In-Reply-To: <e47324780710110857s472bf099u3e350d17a2c29f78@mail.gmail.com>
Hi,
On Thu, 11 Oct 2007, Thomas Harning Jr. wrote:
> I use gmail as my mail client and it doesn't grok 'PATCH' filters
> (primarily the case of the word).
That's just another bug in gmail.
> Are there any of you using Gmail that has managed to get around this
> issue....?
We did not even find a way to post patches via gmail's web interface, not
without severely damaging the patches. So I guess no, most of us avoid
the web interface (unless absolutely necessary, in which case we resort to
the less than brilliant solution to attach the patches).
> Perhaps we should have a separate mailing list for patches vs
> discussion.
I, for one, am totally opposed to this split. All too often valuable
_user_ discussions turn into _technical_ discussions, and thence into a
throwing back and forth patches.
Ciao,
Dscho
^ permalink raw reply
* [PATCH] cvsserver: added support for update -p
From: Frank Lichtenheld @ 2007-10-11 16:36 UTC (permalink / raw)
To: Git Mailing List; +Cc: Junio C Hamano, Jan Wielemaker, Frank Lichtenheld
In-Reply-To: <200710101316.03633.jan@swi-prolog.org>
Based on a patch by Jan Wielemaker <jan@swi-prolog.org>.
Signed-off-by: Frank Lichtenheld <frank@lichtenheld.de>
---
git-cvsserver.perl | 23 +++++++++++++++++++++++
t/t9400-git-cvsserver-server.sh | 32 ++++++++++++++++++++++++++++++++
2 files changed, 55 insertions(+), 0 deletions(-)
Test cases added and fixed behaviour for non-existant files.
diff --git a/git-cvsserver.perl b/git-cvsserver.perl
index 2e112fa..7374875 100755
--- a/git-cvsserver.perl
+++ b/git-cvsserver.perl
@@ -973,6 +973,29 @@ sub req_update
$meta = $updater->getmeta($filename);
}
+ # if we have a -p we should just send the file
+ if ( exists ( $state->{opt}{p} ) )
+ {
+ if (! defined $meta)
+ {
+ # non-existant files are ignored
+ print "E cvs update: nothing known about `$filename'\n";
+ next;
+ }
+ if ( open my $fh, '-|', "git-cat-file", "blob", $meta->{filehash} )
+ {
+ while ( <$fh> )
+ {
+ print "M $_";
+ }
+ close $fh or die ("Couldn't close filehandle: $!");
+ } else {
+ die("Couldn't execute git-cat-file");
+ }
+
+ next;
+ }
+
if ( ! defined $meta )
{
$meta = {
diff --git a/t/t9400-git-cvsserver-server.sh b/t/t9400-git-cvsserver-server.sh
index ee58c0f..4f45578 100755
--- a/t/t9400-git-cvsserver-server.sh
+++ b/t/t9400-git-cvsserver-server.sh
@@ -446,6 +446,38 @@ test_expect_success 'cvs update (merge no-op)' \
diff -q merge ../merge'
cd "$WORKDIR"
+test_expect_success 'cvs update (-p)' \
+ 'cd cvswork &&
+ GIT_CONFIG="$git_config" cvs -Q update -p merge non-existant testfile1 empty >log &&
+ cat merge testfile1 empty >../expected &&
+ diff -q log ../expected'
+
+cd "$WORKDIR"
+test_expect_success 'cvs update (-p -r)' \
+ 'echo testfile1 >expected &&
+ for i in 1 2 3 4 5 6 7
+ do
+ echo Line $i >>expected
+ done &&
+ echo >>expected &&
+ cd cvswork &&
+ GIT_CONFIG="$git_config" cvs -Q update -p -r1.1 testfile1 merge empty >log &&
+ diff -q log ../expected'
+
+cd "$WORKDIR"
+test_expect_success 'cvs update (-p unclean and out-of-date)' \
+ 'echo testfile2 >testfile2 &&
+ echo Line 10 >>merge &&
+ git add testfile2 merge &&
+ git commit -q -m "update -p" &&
+ git push gitcvs.git >/dev/null &&
+ cat testfile2 merge >expected &&
+ cd cvswork &&
+ echo "Line 10 workdir" >>merge
+ GIT_CONFIG="$git_config" cvs -Q update -p testfile2 merge >log &&
+ diff -q log ../expected'
+
+cd "$WORKDIR"
cat <<EOF >list-modules-cmd
Root $SERVERDIR
Valid-responses ok error Valid-requests Force-gzip Referrer Redirect Checked-in New-entry Checksum Copy-file Updated Created Update-existing Merged Patched Rcs-diff Mode Mod-time Removed Remove-entry Set-static-directory Clear-static-directory Set-sticky Clear-sticky Edit-file Template Clear-template Notified Module-expansion Wrapper-rcsOption M Mbinary E F MT
--
1.5.3.4
^ permalink raw reply related
* Re: [PATCH] cvsserver: added support for update -p
From: Jan Wielemaker @ 2007-10-11 16:52 UTC (permalink / raw)
To: Frank Lichtenheld; +Cc: Git Mailing List, Junio C Hamano, Jan Wielemaker
In-Reply-To: <1192120573-16765-1-git-send-email-frank@lichtenheld.de>
On Thursday 11 October 2007 18:36, Frank Lichtenheld wrote:
> Based on a patch by Jan Wielemaker <jan@swi-prolog.org>.
>
> Signed-off-by: Frank Lichtenheld <frank@lichtenheld.de>
Thanks. You are a bigger Perl programmer than I :-) Are you also
interested in one that makes "cvs diff -c" work? It works, but it
does not handle things like "cvs diff -C 5" and I'm a bit lost in
Perl-space ... If someone knowing more about the server wants to
have a look, I'm happy to post the part I have.
Cheers --- Jan
^ permalink raw reply
* Re: RCS keyword expansion
From: Oliver Kullmann @ 2007-10-11 15:59 UTC (permalink / raw)
To: git
In-Reply-To: <86fy0hvgbh.fsf@blue.stonehenge.com>
On Thu, Oct 11, 2007 at 08:09:22AM -0700, Randal L. Schwartz wrote:
> >>>>> "Peter" == Peter Karlsson <peter@softwolves.pp.se> writes:
>
> Peter> I mainly want to have $Date$ expand in RCS/CVS manner, i.e to when the
> Peter> file was last changed. Possibly even have an $Id$ that gives me
> Peter> something useful (name and commit hash, perhaps?). Is it possible to do
> Peter> this? Can it be done through git-cvsserver?
>
> That's not a job for a source code manager to do. It's a job for your
> build/install tool. See how "git --version" gets created in the core distro,
> and follow that example.
>
This looks like a misunderstanding of what $Date$ is used for:
It has not much to do with a version number (such things are decisions
by the developers), but it is an identification stamp, typically
used to identify exactly which piece of code is involved in a
given executable.
Our group also needs a replacement for the keyword-expansion mechanism
(we are using a nice little system, which allows for each executable produced
to query it about the source-code-files involved in it, which is especially
useful for testing and development, where many versions of many files
float around (and perhaps some shouldn't)).
The principle solution seems quite clear to me: Adapt the pre-commit hook,
so that files are scanned for the keyword, and apply the keyword expansion
then before the actual commit.
Better than just the date, it would be greatest to be able to put also
the SHA1-ID of the commit into the file, alas this is a bit complicated,
since it's a pre-commit hook; However it seems necessary to have in
the repository really the actual file content, not "modulo some modification",
due to the distributed character of Git repositories (everybody should have
the same file-timestamp), and so a post-commit hook shouldn't be used.
So well, using the previous SHA1-ID should be a reasonable approximation.
Oliver
^ permalink raw reply
* Is it possible for git to support binary differencing for binary files?
From: 银平 @ 2007-10-11 16:37 UTC (permalink / raw)
To: git
In-Reply-To: <Pine.LNX.4.64.0710111704570.4174@racer.site>
Hi.
Storing binary files as deltas is helpful to keep source and binary files
together and in sync So is it possible for git to do that as svn. This is
my only pain when using git.
^ permalink raw reply
* Re: yet another workflow question...
From: Andreas Ericsson @ 2007-10-11 17:28 UTC (permalink / raw)
To: Andy Parkins; +Cc: git, Patrick Doyle
In-Reply-To: <200710111610.55364.andyparkins@gmail.com>
Andy Parkins wrote:
> On Thursday 2007 October 11, Patrick Doyle wrote:
>
>> burning question, "What can git do for me?" (So far, I have come to
>> the conclusion that, for my simple, single developer, branchless,
>> linear projects, there's not much that git can do for me that any
>> other SCM could do for me. It appears to have been designed to solve
>
> Here's a few things that are relevant to a simple, single, branchless, linear
> developer:
>
> - Fast. Git wipes the floor with everything else, so much so that the SCM
> becomes a tool in itself, not just a recorder of history. I keep my own
> simple projects in git just as much as my complicated, branchy, team-based
> projects just to get the following tools fast:
> git-diff
> git-status
> git-commit
> git-log
>
> - Small. In every project I've converted from SVN to git, the diskspace
> usage has gone down. SVN peppers the working tree with .svn directories,
> each of which contains a pristine copy of the last checked in version of
> all the working files. On top of that is the repository disk space itself.
>
> Git on the other hand keeps one .git directory at the top of the tree and
> that stores the _entire_ repository. It is, in my experience, smaller than
> the working tree. That means that git uses less diskspace than svn does
> for a single checkout to store everything it needs.
>
> - Useful. The following are so good, that even if you weren't doing any
> revision tracking you'd still want to use them:
> git-grep
> git-diff
>
> - Backup. Backing up subversion repositories requires that you write
> yourself a script that uses svnadmin dump. With git I just write a couple
> of lines in my .git/config and then git-push produces a highly compact
> backup whenever I want. Even better, if a disaster happens it's easy to
> pull stuff out of that backup without any additional operations.
>
> - Mobility. This one is a bit distributed, but I hope you'll let me have it.
> I often do work on my desktop at home, my desktop at work and my laptop.
> By setting my remotes up correctly in git it's really easy to walk to
> another system and pick up exactly where I left off from the other
> computer. More importantly though, when you accidentally make changes in
> two places, there is no danger of data loss.
>
> Even if you aren't doing complicated stuff, git is the way to go. I can't
> count the number of ways it's made me more productive and enhanced the code I
> write and the documentation of its development. If I never worked on another
> group project again I would still use git all day every day.
>
I'm amazed nobody has mentioned git-bisect yet. Recently, I had an enormous amount
of benefit from it, so I'll just add it here as a success-story in case any OSS
support company comes along and wants to peddle git.
As it happens, I have a daemon that does some fairly clever scheduling. Somewhere
in a recent change, I had introduced a very subtle bug that made the latency times
for when the actions were actually happening diverge from 0s. I know I get a
latency spike just when I fire the daemon up, but it's supposed to normalize after
10 or so minutes and converge on zero-latency. Instead it was slowly increasing,
but the effects weren't really visible until after about 2 hours.
git bisect to the rescue. Since I didn't feel terribly inclined to walk over to
my computer every two hours to recompile, wipe logs and start the daemon all over
again, I hacked up a script to do it for me. The script also checked the latency
figures and re-ran git-bisect as necessary.
22 hours (or 7 bisects) later, git had, with a little help from my script, shown
me exactly the commit that introduced the latency issue. During the time, I was
enjoying a walk in the sun, dinner with my girlfriend and a good nights sleep.
Life is good when you have the proper tools.
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
^ permalink raw reply
* Re: [PATCH] cvsserver: added support for update -p
From: Frank Lichtenheld @ 2007-10-11 17:29 UTC (permalink / raw)
To: Jan Wielemaker; +Cc: Git Mailing List, Jan Wielemaker
In-Reply-To: <200710111852.32740.wielemak@science.uva.nl>
On Thu, Oct 11, 2007 at 06:52:32PM +0200, Jan Wielemaker wrote:
> On Thursday 11 October 2007 18:36, Frank Lichtenheld wrote:
> > Based on a patch by Jan Wielemaker <jan@swi-prolog.org>.
> >
> > Signed-off-by: Frank Lichtenheld <frank@lichtenheld.de>
>
> Thanks. You are a bigger Perl programmer than I :-) Are you also
> interested in one that makes "cvs diff -c" work? It works, but it
> does not handle things like "cvs diff -C 5" and I'm a bit lost in
> Perl-space ... If someone knowing more about the server wants to
> have a look, I'm happy to post the part I have.
Hmm, the more half-patches you submit the more I'd rather prefer you
learning Perl ;) Or at least write your own testcases.
diff -c doesn't really interest me at all. So I'd really prefer you
doing the bulk of the work...
Gruesse,
--
Frank Lichtenheld <frank@lichtenheld.de>
www: http://www.djpig.de/
^ permalink raw reply
* Re: Is it possible for git to support binary differencing for binary files?
From: Jean-Luc Herren @ 2007-10-11 17:54 UTC (permalink / raw)
To: 银平; +Cc: git
In-Reply-To: <20071011163746.DEB147E6F@mail.kooxoo.com>
银平 wrote:
> Hi.
> Storing binary files as deltas is helpful [...] So is it
> possible for git to do that as svn. This is my only pain when
> using git.
Yes, and git does this already in pack files. Maybe you're not
seeing it because you haven't packed anything yet. Try to run
'git gc'.
jlh
^ permalink raw reply
* Re: Suggestion for mailing lists... split [PATCH]-es into own list
From: Steven Grimm @ 2007-10-11 18:00 UTC (permalink / raw)
To: Thomas Harning Jr.; +Cc: git
In-Reply-To: <e47324780710110857s472bf099u3e350d17a2c29f78@mail.gmail.com>
Thomas Harning Jr. wrote:
> Perhaps we should have a separate mailing list for patches vs discussion.
>
This list is somewhat unusual in that the two are not really distinct.
Most of the discussion (or at least a huge percentage of it) is in
response to patches or results in patches somewhere along the line, with
updated versions of those patches intermingled with feedback. Having to
bounce back and forth between two mailing lists for all that would
seriously impair the flow of ideas / improvements here.
-Steve
^ permalink raw reply
* Re: RCS keyword expansion
From: Alex Riesen @ 2007-10-11 18:09 UTC (permalink / raw)
To: Oliver Kullmann; +Cc: git
In-Reply-To: <20071011155956.GC11693@cs-wsok.swansea.ac.uk>
Oliver Kullmann, Thu, Oct 11, 2007 17:59:56 +0200:
> Better than just the date, it would be greatest to be able to put also
> the SHA1-ID of the commit into the file, alas this is a bit complicated,
actually, it is quite simple: just (re)generate a file which you can
compile and link to your executable. That is how gits version work:
$ git version
git version 1.5.3.4.229.ga321c1
this ga321c1 is the commit (no one knows what the "g" stands for, but
the rest is plain value of HEAD at the moment of compilation).
Put the generated string in your image in a greppable/identable form
and you are set: the commit identifies uniquely the whole build tree
(assuming your build tree _can_ be identified. It not given for most
commercial projects I am familiar with).
^ 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