* Re: Spam: Re: git branch performance problem?
From: Johannes Schindelin @ 2007-10-11 10:58 UTC (permalink / raw)
To: Mike Ralphson; +Cc: Brandon Casey, Lars Hjemli, J. Bruce Fields, hanwen, git
In-Reply-To: <e2b179460710110241i445bc61ep8ae60e421c19c0f0@mail.gmail.com>
Hi,
On Thu, 11 Oct 2007, Mike Ralphson wrote:
> It's not something I've really looked into, but there seems to be a
> reflogs mechanism which can temporarily pin an otherwise unreferenced
> object so it doesn't get deleted. Would it be possible to populate the
> remote's view of referenced objects into this, at the point of clone,
> push or pull, which would seem to be the points at which this might be
> changing.
>
> Obviously this is of no use if you're 'anonymously' poncing off a
> third repo to save clone time, but if you're in control of both repo's
> it might be useful.
I cannot really allege that I understood what you were trying to say, but
I guess you want to use clone to get rid of objects you just threw out by
either filter-branch or deleting a branch.
The answer is that the file:// as well as the git:// protocol will do
that. For local clones, they are not the default, since they are slower
than hardlinking.
Hth,
Dscho
^ permalink raw reply
* Re: [PATCH] fetch: if not fetching from default remote, ignore default merge
From: Johannes Schindelin @ 2007-10-11 11:34 UTC (permalink / raw)
To: Johannes Sixt; +Cc: git, hjemli, gitster
In-Reply-To: <470DC53A.4050707@viscovery.net>
Hi,
On Thu, 11 Oct 2007, Johannes Sixt wrote:
> Johannes Schindelin schrieb:
> > +test_expect_success 'fetch with a non-applying branch.<name>.merge' '
> > + git config branch.master.remote yeti &&
> > + git config branch.master.merge refs/heads/bigfoot &&
> > + git config remote.blub.url one &&
> > + git config remote.blub.fetch 'refs/heads/*:refs/remotes/one/*' &&
>
> Better use double-quotes around the refspecs.
Hehe, "oops!".
Although in this case we could even use the string unquoted (which I
indeed did!), since there is no chance that there is a matching file in
t/trash/.
Ciao,
Dscho
^ permalink raw reply
* [PATCH v2] fetch: if not fetching from default remote, ignore default merge
From: Johannes Schindelin @ 2007-10-11 11:35 UTC (permalink / raw)
To: Johannes Sixt; +Cc: git, hjemli, gitster
In-Reply-To: <470DC53A.4050707@viscovery.net>
When doing "git fetch <remote>" on a remote that does not have the
branch referenced in branch.<current-branch>.merge, git fetch failed.
It failed because it tried to add the "merge" ref to the refs to be
fetched.
Fix that. And add a test case.
Incidentally, this unconvered a bug in our own test suite, where
"git pull <some-path>" was expected to merge the ref given in the
defaults, even if not pulling from the default remote.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
---
builtin-fetch.c | 8 +++++++-
t/t5510-fetch.sh | 8 ++++++++
t/t5700-clone-reference.sh | 4 ++--
3 files changed, 17 insertions(+), 3 deletions(-)
diff --git a/builtin-fetch.c b/builtin-fetch.c
index cf7498b..ca4de9f 100644
--- a/builtin-fetch.c
+++ b/builtin-fetch.c
@@ -105,7 +105,13 @@ static struct ref *get_ref_map(struct transport *transport,
!remote->fetch[0].pattern)
ref_map->merge = 1;
}
- if (has_merge)
+ /*
+ * if the remote we're fetching from is the same
+ * as given in branch.<name>.remote, we add the
+ * ref given in branch.<name>.merge, too.
+ */
+ if (has_merge && !strcmp(branch->remote_name,
+ remote->name))
add_merge_config(&ref_map, remote_refs, branch, &tail);
} else {
ref_map = get_remote_ref(remote_refs, "HEAD");
diff --git a/t/t5510-fetch.sh b/t/t5510-fetch.sh
index 73a4e3c..1f398bc 100755
--- a/t/t5510-fetch.sh
+++ b/t/t5510-fetch.sh
@@ -188,4 +188,12 @@ test_expect_success 'push via rsync' '
'
}
+test_expect_success 'fetch with a non-applying branch.<name>.merge' '
+ git config branch.master.remote yeti &&
+ git config branch.master.merge refs/heads/bigfoot &&
+ git config remote.blub.url one &&
+ git config remote.blub.fetch "refs/heads/*:refs/remotes/one/*" &&
+ git fetch blub
+'
+
test_done
diff --git a/t/t5700-clone-reference.sh b/t/t5700-clone-reference.sh
index 4e93aaa..b6a5486 100755
--- a/t/t5700-clone-reference.sh
+++ b/t/t5700-clone-reference.sh
@@ -38,7 +38,7 @@ cd "$base_dir"
test_expect_success 'pulling from reference' \
'cd C &&
-git pull ../B'
+git pull ../B master'
cd "$base_dir"
@@ -61,7 +61,7 @@ test_expect_success 'existence of info/alternates' \
cd "$base_dir"
test_expect_success 'pulling from reference' \
-'cd D && git pull ../B'
+'cd D && git pull ../B master'
cd "$base_dir"
--
1.5.3.4.1174.gcd0d6-dirty
^ permalink raw reply related
* Re: git branch performance problem?
From: Han-Wen Nienhuys @ 2007-10-11 13:11 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Linus Torvalds, Lars Hjemli, git
In-Reply-To: <Pine.LNX.4.64.0710111145090.4174@racer.site>
2007/10/11, Johannes Schindelin <Johannes.Schindelin@gmx.de>:
> > 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.
>
> Silly question: why don't you just
>
> git remote add -f other <url>
>
> and then review the changes with "git log", "git diff" and "git show"?
Thank for the tip; I'll look into it.
--
Han-Wen Nienhuys - hanwen@xs4all.nl - http://www.xs4all.nl/~hanwen
^ permalink raw reply
* Split a subversion repo into several git repos
From: Eivind LM @ 2007-10-11 12:51 UTC (permalink / raw)
To: git
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
^ permalink raw reply
* 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
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