* 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: 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: 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
* 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: 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
* 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: 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: 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
* 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: 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
* 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 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
* 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: 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
* [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: [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
* 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: git branch performance problem?
From: Johannes Schindelin @ 2007-10-11 10:46 UTC (permalink / raw)
To: hanwen; +Cc: Linus Torvalds, Lars Hjemli, git
In-Reply-To: <f329bf540710101926vedf8b19p52e3eeb193203d03@mail.gmail.com>
Hi,
On Wed, 10 Oct 2007, Han-Wen Nienhuys wrote:
> 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"?
Ciao,
Dscho
^ permalink raw reply
* Re: Spam: Re: git branch performance problem?
From: Mike Ralphson @ 2007-10-11 9:41 UTC (permalink / raw)
To: Brandon Casey; +Cc: Lars Hjemli, J. Bruce Fields, hanwen, git
In-Reply-To: <470D585D.1030808@nrlssc.navy.mil>
On 10/10/07, Brandon Casey <casey@nrlssc.navy.mil> wrote:
> No, this is not the case, unless something has changed very recently
> in git-gc or git-repack. Even git-gc with no arguments is unsafe if
> the repository being gc'ed is listed in another's alternates.
>
> git-gc calls repack with -a and -d. which causes a new pack to be
> created which only contains the objects required by the local repository.
> The other packs are then deleted. Objects contained in those packs and
> required by a "sharing" repository (one using the alternates mechanism)
> will be deleted if the local repository no longer references them.
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.
Mike
^ permalink raw reply
* Re: [FEATURE REQUEST] git clone, just clone selected branches?
From: Andreas Ericsson @ 2007-10-11 9:18 UTC (permalink / raw)
To: Joakim Tjernlund; +Cc: 'Linus Torvalds', git
In-Reply-To: <011c01c80b85$a0d8d560$04ac10ac@Jocke>
Joakim Tjernlund wrote:
>> -----Original Message-----
>> From: Linus Torvalds [mailto:torvalds@linux-foundation.org]
>> Sent: den 10 oktober 2007 21:38
>> To: Joakim Tjernlund
>> Cc: git@vger.kernel.org
>> Subject: Re: [FEATURE REQUEST] git clone, just clone selected
>> branches?
>>
>>
>>
>> On Wed, 10 Oct 2007, Joakim Tjernlund wrote:
>>> I know I can use git remote to do this, but it is a bit clumsy
>>> when starting a new repo.
>> How about just
>>
>> git init
>> .. set up remote tracking info in .git/config ..
>> git fetch remote
>>
>> which should do what you want.
>>
>> Linus
>
> From git remote man page:
> o Imitate git clone but track only selected branches
>
> $ mkdir project.git
> $ cd project.git
> $ git init
> $ git remote add -f -t master -m master origin git://example.com/git.git/
> $ git merge origin
>
> yes, this does the trick too but that is more to type so I thought
> it would be simpler if I could just tell git clone which branches I want.
> Now, this isn't a killer feature to me so if you don't like it, I good
> with that too.
>
Well, that's how git-clone should probably look, now that git-remote exists.
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
^ permalink raw reply
* Re: [PATCH] git-cvsserver: added support for update -p
From: Andreas Ericsson @ 2007-10-11 8:45 UTC (permalink / raw)
To: Frank Lichtenheld; +Cc: Jan Wielemaker, Git Mailing List
In-Reply-To: <20071010200029.GK31659@planck.djpig.de>
Frank Lichtenheld wrote:
> On Wed, Oct 10, 2007 at 01:16:03PM +0200, Jan Wielemaker wrote:
>> + # if we have a -p we should just send the file
>> + if ( exists ( $state->{opt}{p} ) )
>> + {
>> + if ( open my $fh, '-|', "git-cat-file", "blob", $meta->{filehash} )
>> + { while ( <$fh> )
>> + { print "M " . $_;
>> + }
>> + close $fh or die ("Couldn't close filehandle for transmitfile(): $!");
>> + } else
>> + { die("Couldn't execute git-cat-file");
>> + }
>> +
>> + next;
>> + }
>
>
> There seems to be inconsistent whitespace in the patch.
> And please never do that else\n{ again, it hurts my eye ;)
>
That cuddled opening brace hurts mine more.
{ while()\n{ print()...
It's usually a good idea to pick some indentation style that at least *some* tool
can create, and when contributing to a project it's usually considered good form
to stick to the style already used.
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
^ permalink raw reply
* Re: [PATCH 0/2] Add --dry-run option to git-push
From: Lars Hjemli @ 2007-10-11 7:57 UTC (permalink / raw)
To: Baz; +Cc: git, Junio C Hamano
In-Reply-To: <2faad3050710101634s5ed39bcbn723184810bc265d5@mail.gmail.com>
On 10/11/07, Baz <brian.ewins@gmail.com> wrote:
> there was discussion recently about the default behaviour of git-push
> having the potential to confuse, making it easy to push commits that
> are still cooking in other branches.
>
> Its also possible for newbies to make mistakes with refspecs, but
> there's no way to know if you've got the syntax right without actually
> pushing. Steffan suggested a dry-run flag, which I've always wanted
> too, so here's an attempt. Patches git-send-pack, git-push, their
> docs, and adds a test for git-push.
Maybe some of this description could be reused in the commit messages?
> first patch to the list and the mailer will
> probably mangle it (sigh)
Yeah, it did.
Would it be possible for you to resend with git-send-email after
adding proper commit messages? If git-send-email is not an option,
attaching the patches are preferable to the current mangling.
--
larsh
^ permalink raw reply
* Re: [PATCH] Fixing path quoting issues
From: Jonathan del Strother @ 2007-10-11 7:30 UTC (permalink / raw)
To: Johannes Sixt; +Cc: David Kastrup, git, Junio C Hamano
In-Reply-To: <470DCC76.7070809@viscovery.net>
On 11 Oct 2007, at 08:10, Johannes Sixt wrote:
> David Kastrup schrieb:
>> Johannes Sixt <j.sixt@viscovery.net> writes:
>>> IMHO, it's not too much of a burden for developers to require "sane"
>>> build directory paths.
>> For a normal user, the only writable directories might be of the
>> "C:\Programs and Data\User settings\Karl"
>> variety.
>
> I whole-heartedly agree about the part of the patch that fixes git-
> rebase.sh. This should be a separate patch.
>
> But the reset of the patch is about running the test suite, and it
> is much more difficult to fix because of the 'eval' that is going
> on. And, yes, I do think that we can expect that contributors,
> including this handful of people on Windows, have a "sane" build
> directory.
How are you going to test that git works on paths with spaces if the
test suite doesn't run there?
^ permalink raw reply
* Re: [PATCH] Fixing path quoting issues
From: Johannes Sixt @ 2007-10-11 7:41 UTC (permalink / raw)
To: Jonathan del Strother; +Cc: David Kastrup, git, Junio C Hamano
In-Reply-To: <81156EED-7AC0-4C8B-98B1-8338262459A6@bestbefore.tv>
Jonathan del Strother schrieb:
> How are you going to test that git works on paths with spaces if the
> test suite doesn't run there?
By writing a specific test?
-- Hannes
^ permalink raw reply
* Re: [PATCH] Fixing path quoting issues
From: Johannes Sixt @ 2007-10-11 7:10 UTC (permalink / raw)
To: David Kastrup; +Cc: Jonathan del Strother, git, Junio C Hamano
In-Reply-To: <854pgytafi.fsf@lola.goethe.zz>
David Kastrup schrieb:
> Johannes Sixt <j.sixt@viscovery.net> writes:
>> IMHO, it's not too much of a burden for developers to require "sane"
>> build directory paths.
>
> For a normal user, the only writable directories might be of the
> "C:\Programs and Data\User settings\Karl"
> variety.
I whole-heartedly agree about the part of the patch that fixes
git-rebase.sh. This should be a separate patch.
But the reset of the patch is about running the test suite, and it is much
more difficult to fix because of the 'eval' that is going on. And, yes, I do
think that we can expect that contributors, including this handful of people
on Windows, have a "sane" build directory.
-- Hannes
^ 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