* Re: Anyone running GIT on native Windows
From: A.S. Bradbury @ 2007-05-07 12:38 UTC (permalink / raw)
To: git
In-Reply-To: <463F14FF.F8DF11EB@eudaptics.com>
On 5/7/07, Johannes Sixt <J.Sixt@eudaptics.com> wrote:
> The next big thing to think about is an installer. Does anyone have a
> suggestion for a free installer tool? I only know about Microsoft's WiX
> (wix.sf.net), but it requires .NET (for the developer, not the user).
This is outside my normal realm of expertise, but I think NSIS
(http://nsis.sourceforge.net) is where it's at - notable users include
Firefox 2.0, OOo, VLC etc etc...
Alex
^ permalink raw reply
* Re: [FAQ?] Rationale for git's way to manage the index
From: David Kastrup @ 2007-05-07 12:36 UTC (permalink / raw)
To: git
In-Reply-To: <20070507121603.GA3255@diana.vm.bytemark.co.uk>
Karl Hasselström <kha@treskal.com> writes:
> On 2007-05-07 13:40:33 +0200, Guilhem Bonnefille wrote:
>
>> In order to improve my productivity with Git, and in order to avoid
>> traps around moving from SVN to Git, I often use the Git Emacs mode.
>> It is really usefull for beginners as it works similarly for CVS,
>> SVN and Git: synthetic view of all modifications, easy selection of
>> what will be commited... The biggest drawback of this "porcelain":
>> using it, you do not understand the Git's index philosophy.
>
> git-gui is a good tool here (so good, in fact, that this is the second
> time today I spam the list about it).
Please be sure to _always_ include a URL whenever you are spamming.
--
David Kastrup
^ permalink raw reply
* Re: FFmpeg considering GIT
From: Johan Herland @ 2007-05-07 12:50 UTC (permalink / raw)
To: Paul Mackerras
Cc: Linus Torvalds, Karl Hasselstr?m, Junio C Hamano, Carl Worth,
Michael Niedermayer, Git Mailing List
In-Reply-To: <17983.6136.147062.346626@cargo.ozlabs.ibm.com>
[-- Attachment #1: Type: text/plain, Size: 386 bytes --]
On Monday 07 May 2007, Paul Mackerras wrote:
> I don't want to go to C/Qt since that would make it hard to port to
> Windows and MacOS AFAIK.
Wrong. Qt is now GPL for Windows, Linux, Unix, and Mac OS X. See
http://www.trolltech.com/products/qt/licenses/licensing/opensource for more
info.
Have fun!
...Johan
--
Johan Herland, <johan@herland.net>
www.herland.net
[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: [FAQ?] Rationale for git's way to manage the index
From: Johannes Schindelin @ 2007-05-07 12:55 UTC (permalink / raw)
To: Guilhem Bonnefille; +Cc: git
In-Reply-To: <8b65902a0705070440t40889af0p1fb8dbf7e2a072e4@mail.gmail.com>
Hi,
On Mon, 7 May 2007, Guilhem Bonnefille wrote:
> As a newbie, I'm agree with Matthieu: the Git's index is surprising for
> people coming from CVS/SVN (mindless?) world. So a good documentation
> about this, even in tutorials, is really important.
So, you are not only a newbie, but you have to unlearn some CVS
braindamage.
I don't know how to make it even more prominent that CVS users should read
a special introduction first. AFAICT such a hint is in all the appropriate
places. (I mean, you would not expect to be able to fly a plane, just
because you have learnt to drive a car, wouldn't you?)
Ciao,
Dscho
^ permalink raw reply
* Re: FFmpeg considering GIT
From: Alex Riesen @ 2007-05-07 12:56 UTC (permalink / raw)
To: Paul Mackerras
Cc: Linus Torvalds, Karl Hasselstr?m, Junio C Hamano, Carl Worth,
Michael Niedermayer, Git Mailing List
In-Reply-To: <17983.6136.147062.346626@cargo.ozlabs.ibm.com>
On 5/7/07, Paul Mackerras <paulus@samba.org> wrote:
> I have thought about rewriting it in a different language, but I
> haven't found anything that really appeals. I don't want to go to
> C/GTK or C/Qt since that would make it hard to port to Windows and
> MacOS AFAIK. Python/Tk would be a possibility, but I have never
C++/Qt4 is ported to Windows.
> Any suggestions?
It(Qt4) wasn't a suggestion though. I still consider Tcl/Tk more portable.
^ permalink raw reply
* Re: Documentation Bugs
From: Uwe Kleine-König @ 2007-05-07 12:58 UTC (permalink / raw)
To: Git Mailing List
In-Reply-To: <20070506130921.GA3750@lala>
Hello,
> 2) rebase a merged tree:
>
> If I made a local commit and pulled from origin, I get:
>
> zeisberg@cassiopeia:~/gsrc/git$ git show
> commit 15386213004a20dfdf92c654c737795079202545
> Merge: 9d740f0... 9159afb...
> Author: Uwe Kleine-König <ukleinek@informatik.uni-freiburg.de>
> Date: Sun May 6 14:49:59 2007 +0200
>
> Merge branch 'master' of git://git.kernel.org/pub/scm/git/git
>
> zeisberg@cassiopeia:~/gsrc/git$ git rebase junio/master
> Current branch master is up to date.
>
> (where junio/master is the tracking branch for
> git://git.kernel.org/pub/scm/git/git) but git-rebase(1) states:
>
> All changes made by commits in the current branch but that are
> not in <upstream> are saved to a temporary area. This is the
> same set of commits that would be shown by git log
> <upstream>..HEAD.
>
> and git-log junio/master..HEAD is not empty.
After having thought about that one once more, here some more info: The
two patches I had in master were merged in the meantime. So it was
correct for git-rebase to state that master is up to date. Rereading
the documentation I realize there is no bug. I just missed that both
patches were already merged and format-patch generated a patch anyhow.
The first issue remains however.
Best regards
Uwe
--
Uwe Kleine-König
If a lawyer and an IRS agent were both drowning, and you could only save
one of them, would you go to lunch or read the paper?
^ permalink raw reply
* Re: Checkout fails when one branch contains a directory with the name of a file in the other branch
From: Johannes Schindelin @ 2007-05-07 13:00 UTC (permalink / raw)
To: Tom Koelman; +Cc: git
In-Reply-To: <463F0E5E.6000204@xs4all.nl>
Hi,
On Mon, 7 May 2007, Tom Koelman wrote:
> Johannes Schindelin wrote:
>
> > On Mon, 7 May 2007, Tom Koelman wrote:
> >
> > > I am not sure whether this is intentional or not. I am wondering why
> > > this scenario fails, and if it is by design, how I should handle this
> > > situation:
> > >
> > > [...]
> > >
> > > $ git checkout master
> > > fatal: Untracked working tree file 'aFile' would be overwritten by merge.
> >
> > I tried to reproduce this behaviour, but it worked here. What Git version
> > do you use? Mine says "git version 1.5.2.rc2.2435.ge5a9b".
> >
> > Hth,
> > Dscho
>
> I tried 1.5.1.3 under cygwin and 1.5.0.6 under Linux FC5.
I can confirm that it reproduces with 1.5.1.3. So, it has been fixed in
1.5.2.rc2.
Ciao,
Dscho
^ permalink raw reply
* Re: What's in git.git (stable)
From: Frank Lichtenheld @ 2007-05-07 13:33 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vejlucozk.fsf@assigned-by-dhcp.cox.net>
On Sun, May 06, 2007 at 01:53:19AM -0700, Junio C Hamano wrote:
> GIT v1.5.2 Release Notes (draft)
> ========================
[...]
> to be handled with caution (do not use it unless you
> understand the earlier mailing list discussion on keyward
> expansion).
I guess that should be "keyword"
Gruesse,
--
Frank Lichtenheld <frank@lichtenheld.de>
www: http://www.djpig.de/
^ permalink raw reply
* Re: Anyone running GIT on native Windows
From: Aaron Gray @ 2007-05-07 13:51 UTC (permalink / raw)
To: Johannes Sixt; +Cc: git
In-Reply-To: <463F14FF.F8DF11EB@eudaptics.com>
>> On 5/7/07, Johannes Sixt <J.Sixt@eudaptics.com> wrote:
>> > Aaron Gray wrote:
>> > > What I want is to be able to work in Windows CMD and envoke .sh
>> > > scripts by
>> > > association (unfortunately you have to add the .sh on the command
>> > > name
>> > > though).
>> >
>> > I run the mingw port exclusively from CMD without a .sh association. So
>> > exclusively that I don't even know whether any other way of using the
>> > tools even works. Of course, you have to get used to
>> >
>>
>> Is it public available?
>
> gitweb: http://repo.or.cz/w/git/mingw.git
> clone: git://repo.or.cz/git/mingw.git
>
> I only have either time to hack on mingw.git or a Windows installation,
> but not both at the same time. Therefore, the port is now a bit falling
> back (it's still at 1.5.1). I hope to be able to change this in a few
> weeks.
Great I will check this out when I get some time.
An .sh to c converter would be the best solution. I will be looking into how
hard this would be to do.
> The next big thing to think about is an installer. Does anyone have a
> suggestion for a free installer tool? I only know about Microsoft's WiX
> (wix.sf.net), but it requires .NET (for the developer, not the user).
I suggest Nullsoft :-
http://nsis.sourceforge.net/Main_Page
This is used by several open source projects.
Aaron
^ permalink raw reply
* Re: Anyone running GIT on native Windows
From: Johannes Schindelin @ 2007-05-07 14:24 UTC (permalink / raw)
To: Aaron Gray; +Cc: Johannes Sixt, git
In-Reply-To: <002801c790ae$d86a1a90$0200a8c0@AMD2500>
Hi,
On Mon, 7 May 2007, Aaron Gray wrote:
> > > On 5/7/07, Johannes Sixt <J.Sixt@eudaptics.com> wrote:
> > > > Aaron Gray wrote:
> > > > > What I want is to be able to work in Windows CMD and envoke .sh
> > > > > scripts by association (unfortunately you have to add the .sh on
> > > > > the command name though).
> > > >
> > > > I run the mingw port exclusively from CMD without a .sh
> > > > association. So exclusively that I don't even know whether any
> > > > other way of using the tools even works. Of course, you have to
> > > > get used to
> > >
> > > Is it public available?
> >
> > gitweb: http://repo.or.cz/w/git/mingw.git
> > clone: git://repo.or.cz/git/mingw.git
> >
> > I only have either time to hack on mingw.git or a Windows
> > installation, but not both at the same time. Therefore, the port is
> > now a bit falling back (it's still at 1.5.1). I hope to be able to
> > change this in a few weeks.
>
> Great I will check this out when I get some time.
>
> An .sh to c converter would be the best solution. I will be looking into
> how hard this would be to do.
NACK.
A stupid .sh to c converter will almost certainly result in slow and
hard-to-debug code.
If you had bothered to check, you'd know that there are ongoing efforts to
do the ports properly.
Ciao,
Dscho
^ permalink raw reply
* Re: Anyone running GIT on native Windows
From: Thomas Glanzmann @ 2007-05-07 15:10 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Aaron Gray, Johannes Sixt, git
In-Reply-To: <Pine.LNX.4.64.0705071624210.4167@racer.site>
Hello,
(thinkpad) [~/work/git] cat git*.sh | wc -l
6125
it should be possible to convert 6000 loc by hand. There is also a Google
Summer of Code Project targeting at that specific topic.
Thomas
^ permalink raw reply
* Re: Git benchmarks at OpenOffice.org wiki
From: Linus Torvalds @ 2007-05-07 15:22 UTC (permalink / raw)
To: Junio C Hamano
Cc: Jakub Narebski, Johannes Schindelin, git, dev, Jan Holesovsky
In-Reply-To: <7vk5vl6oum.fsf@assigned-by-dhcp.cox.net>
On Mon, 7 May 2007, Junio C Hamano wrote:
>
> Keeping fetched and updated refs in core and write a packed refs
> out in one go in git-fetch--tool (and later, git-fetch all in C)
> would be much simpler if we do not have to worry about existing
> refs (aka "git clone" special case); I am not sure if packing
> refs is desirable in general for incremental "git-fetch".
Fair enough. It's true that for the general case of "git fetch", it's much
less obvious how to keep things packed.
So maybe the right thing really *is* to just add the
git pack-refs --all --prune
to the git-clone wrapper.
Linus
^ permalink raw reply
* Re: [PATCH] submodule merge support
From: Linus Torvalds @ 2007-05-07 16:02 UTC (permalink / raw)
To: Johannes Sixt; +Cc: git
In-Reply-To: <463EFFC6.12A1B0A1@eudaptics.com>
On Mon, 7 May 2007, Johannes Sixt wrote:
>
> I think you missed Linus's point: If the supermodule's merge leads to a
> conflict in the submodule links, it is not appropriate to merge the
> submodule.
That is true, but no, that wasn't what I was trying to say.
What I was trying to say was really that the merge-base in the
super-module is simply totally irrelevant to the sub-module, and any merge
at all that thinks it is is obviously broken.
Now, for a _normal_ merge (with just a single merge-base), this is not an
issue, since the proposed submodule merger wouldn't care about the
supermodule merge base anyway.
But if you have multiple merge-bases and you do a recursive merge to
create a new *combined* merge-base, trying to do that for the submodule is
just pointless. You shouldn't. The merge-base for the submodule will be
irrelevant for the final merge *anyway* (since the submodule history comes
from itself), so in a recursive sub-merge, you shouldn't even *try* to
merge the submodule. The end result would never be used anyway, and the
only thing you can do is make for more complexity.
So not doing it in the low-level merger is right - because it is simply
irrelevant at that stage. The low-level merger might as well ignore
submodules.
I think.
Linus
^ permalink raw reply
* Re: [PATCH] submodule merge support
From: Martin Waitz @ 2007-05-07 16:37 UTC (permalink / raw)
To: Johannes Sixt; +Cc: git
In-Reply-To: <463EFFC6.12A1B0A1@eudaptics.com>
[-- Attachment #1: Type: text/plain, Size: 3480 bytes --]
hoi :)
On Mon, May 07, 2007 at 12:30:30PM +0200, Johannes Sixt wrote:
> Martin Waitz wrote:
> > On Sun, May 06, 2007 at 03:18:53PM -0700, Linus Torvalds wrote:
> > > On Mon, 7 May 2007, Alex Riesen wrote:
> > > > How about making all existing strategies just ignore submodules, and
> > > > move recursive merge in the merge driver (git-merge.sh)?
> > >
> > > Yes, I think that's the right thing to do.
> > >
> > > I think it's the right thing for another reason: in a true "recursive"
> > > merge, the submodules shouldn't be recursively merged anyway. *THEIR*
> > > merge will have its own history, and doing it based on some random history
> > > of the superproject is actually wrong anyway!
> >
> > Of course the submodule has to get its own history, it's not possible
> > to do otherwise. But you have to trigger the submodule merge when you
> > find a submodule-level conflict in the supermodule merge, just as
> > you trigger file-level three-way merges, too.
>
> I think you missed Linus's point: If the supermodule's merge leads to a
> conflict in the submodule links, it is not appropriate to merge the
> submodule.
why?
We do file-level merging, too.
A submodule is not that different, besides being much more complex ;-)
We should try to automatically merge the content if possible and leave
conflict markers if not.
> Say you are merging commits A and B in the supermodule, and A uses v1.0
> of the submodule and B uses v2.0 of submodule, then you can't just merge
> v1.0 and v2.0 - instead, you have to make a decision whether the
> supermodule's merge result is going to use v1.0 or v2.0 or even
> something different like v2.1. An automatic merge cannot make this
> decision for you (unless there was no conflict in the first place).
So when should we try to merge and when should we leave conflict
markers?
Let's look at submodule commits O, A, B which are the commits that are
used by the (supermodule-) merge base, our supermodule version and their
supermodule version.
The trivial cases are:
O,A -..- B O,B -..- A
Then there is the fast-forward case:
O -..- A -..- B O -..- B -..- A
All of those do not require to create any new submodule commit, just use
the one on the right side of the chain. I think they are not
controversial.
Now to the more complex parts:
/-..- A
O -..- X
\-..- B
and
/-..- A
X
\-..- O -..- B
Here we don't have any existing submodule commit that can be used.
In the second case an automatic merge cannot be done -- one supermodule
branch choose to rewind the submodule (e.g. by switching to another
branch in the submodule) and there really is no way to automatically
detect what should be done.
But when the submodule got branched after the supermodule merge-base
then an automatic submodule merge can be tried.
And it really makes sense to do so:
If you rely on submodule for your project, you will have people
submitting features which touch several submodules. They can simply
create a new supermodule version incorporating all their changes and
send it to their supermodule-upstream. After review,
supermodule-upstream wants all the new submodule versions merged into
her tree and it would be wrong to refuse to do that automatically.
The above behaviour is exactly what is implemented in the patch.
(OK, I could write a more elaborate commit message... ;-)
--
Martin Waitz
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: [PATCH] submodule merge support
From: Martin Waitz @ 2007-05-07 16:44 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Johannes Sixt, git
In-Reply-To: <alpine.LFD.0.98.0705070857100.3802@woody.linux-foundation.org>
[-- Attachment #1: Type: text/plain, Size: 682 bytes --]
hoi :)
On Mon, May 07, 2007 at 09:02:00AM -0700, Linus Torvalds wrote:
> But if you have multiple merge-bases and you do a recursive merge to
> create a new *combined* merge-base, trying to do that for the submodule is
> just pointless.
Ah, now I see your point.
And yes, you are right.
> So not doing it in the low-level merger is right - because it is simply
> irrelevant at that stage. The low-level merger might as well ignore
> submodules.
But where to do it then?
Do a first run which simply ignores dirlinks and then do another run
which looks for all unmerged index entries and processes all dirlinks
by merging the submodule?
--
Martin Waitz
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: Anyone running GIT on native Windows
From: Aaron Gray @ 2007-05-07 16:39 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Johannes Sixt, git
In-Reply-To: <Pine.LNX.4.64.0705071624210.4167@racer.site>
Hi,
>> An .sh to c converter would be the best solution. I will be looking into
>> how hard this would be to do.
>
> NACK.
>
> A stupid .sh to c converter will almost certainly result in slow and
> hard-to-debug code.
I had presumed you do not have to really look at the code if the tanslator
is sound.
> If you had bothered to check, you'd know that there are ongoing efforts to
> do the ports properly.
This is good. So the shell code is being migrated to C ?
Could you give me a link or refernce please ?
Aaron
^ permalink raw reply
* Re: Anyone running GIT on native Windows
From: Johannes Schindelin @ 2007-05-07 17:45 UTC (permalink / raw)
To: Aaron Gray; +Cc: Johannes Sixt, git
In-Reply-To: <00c701c790c6$512804d0$0200a8c0@AMD2500>
Hi,
On Mon, 7 May 2007, Aaron Gray wrote:
> > > An .sh to c converter would be the best solution. I will be looking
> > > into how hard this would be to do.
> >
> > NACK.
> >
> > A stupid .sh to c converter will almost certainly result in slow and
> > hard-to-debug code.
>
> I had presumed you do not have to really look at the code if the
> tanslator is sound.
IMHO no automatic shell->C converter can be sound. Besides, you are
missing that we are dealing with the opposite of POSIX here. After all,
your target platform is Windows, right? That makes a sensible sh->C
converter all the more difficult.
> > If you had bothered to check, you'd know that there are ongoing
> > efforts to do the ports properly.
>
> This is good. So the shell code is being migrated to C ?
>
> Could you give me a link or refernce please ?
You can see a lot in Git's history itself:
git log --grep="[Mmake].*builtin" --no-merges builtin.h
The Google Summer of Code projects' home page is
http://git.or.cz/gitwiki/SoC2007Projects
The ongoing progress for this particular project can be seen here:
http://repo.or.cz/w/git/builtin-gsoc.git
Hth,
Dscho
^ permalink raw reply
* Re: [PATCH] Use GIT_OBJECT_DIR for temporary files of pack-objects
From: Dana How @ 2007-05-07 17:51 UTC (permalink / raw)
To: Alex Riesen; +Cc: git, Junio C Hamano, danahow
In-Reply-To: <20070507173324.GA3436@steel.home>
On 5/7/07, Alex Riesen <raa.lkml@gmail.com> wrote:
> I'm not sure about fsck cleaning up after crashed/killed pack-objects:
> not sure I _can_ detect if the temp files really are just leftovers.
It looks like you create temp file in objects , not objects/pack .
So a rule could be : packs left in the former are crashed/killed,
and packs in the latter are complete?
You should also look at $PACKTMP in git-repack.sh .
In it $GIT_DIR should probably be $GIT_OBJECT_DIRECTORY ?
Junio:
This patch touches the same lines as the --max-pack-size patch.
What do you want to do with the latter?
Thanks,
--
Dana L. How danahow@gmail.com +1 650 804 5991 cell
^ permalink raw reply
* Re: importing multi-project svn repositories
From: Steven Grimm @ 2007-05-07 18:06 UTC (permalink / raw)
To: David Hanson; +Cc: git
In-Reply-To: <C05C5EF4-EC68-490B-946E-630117393F4E@drhanson.net>
David Hanson wrote:
> I'd like to import calc at the top level, put calc/tags/foo in git's
> tags/calc/foo and calc/branches/baz in git's heads/calc/baz. Ditto for
> calendar, spreadsheet, etc.
Try git-svn rather than git-svnimport. The latter, AFAIK, is no longer
really maintained. The former will do what you want pretty easily. You
just run it like
git svn clone --prefix=calc/ -T trunk -t tags -b branches \
http://svn/repo/url/calc gitrepo
and it'll create a git repository called "gitrepo" with the calc
project's trunk/tags/branches as git tags. Then do
git svn clone --prefix=spreadsheet/ -T trunk -t tags -b branches \
http://svn/repo/url/spreadsheet gitrepo
and it will add the spreadsheet branches to the same repo. The
"--prefix" option is needed to keep the branch namespaces from
overlapping. git-svn will make an attempt to figure out the correct
history of the branches and tags relative to the trunk so they look like
sane git branches.
If you want to be able to check out calc and spreadsheet simultaneously,
then you probably need to use git's submodule support, which is kind of
a work in progress at the moment.
-Steve
^ permalink raw reply
* Re: FFmpeg considering GIT
From: Jan Hudec @ 2007-05-07 17:52 UTC (permalink / raw)
To: Paul Mackerras
Cc: Linus Torvalds, Karl Hasselstr?m, Junio C Hamano, Carl Worth,
Michael Niedermayer, Git Mailing List
In-Reply-To: <17983.6136.147062.346626@cargo.ozlabs.ibm.com>
[-- Attachment #1: Type: text/plain, Size: 1363 bytes --]
On Mon, May 07, 2007 at 22:13:44 +1000, Paul Mackerras wrote:
> Linus Torvalds writes:
>
> > Finally, it realy _should_ check that the first 7 characters of the commit
> > log (the ones it ignores by just asking for substring 7..) are actually
> > the exact characters "commit ", but I'll blame my lack of comfort with the
> > language again.
>
> I have thought about rewriting it in a different language, but I
> haven't found anything that really appeals. I don't want to go to
> C/GTK or C/Qt since that would make it hard to port to Windows and
C/Gtk would be perfectly portable. As would C++/Gtk, Python/Gtk and Perl/Gtk.
C++/Qt4 would be perfectly portable as well, so choose whichever you find
easier to work with. For C/C++ they are on par, for Python/Perl/Ruby I think
Gtk has better bindings.
> MacOS AFAIK. Python/Tk would be a possibility, but I have never
> learnt python and I'm actually not all that comfortable with having to
> do things the object-oriented way.
I would actually recommend against Python/Tk, because (tried it) py2exe does
not work seem to work with it, so you couldn't wrap it to easy to install
binary for windows folks. I did not try Python/Gtk, but I expect you might
have better luck with it (it's the Tcl/Tk interpreter that causes problems).
--
Jan 'Bulb' Hudec <bulb@ucw.cz>
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* git-svn: importing branches later
From: Michael Hendricks @ 2007-05-07 19:07 UTC (permalink / raw)
To: git
I've cloned the trunk of a SVN repository using git-svn and now I want
to bring in just a couple of the branches from the same repository.
I've not been able to discover anything that works. Basically, I've
done this
$ git svn clone $URL -T trunk git-repo
Now I want to import the 'foo' branch from the same SVN repo without
grabbing all the branches. Any suggestions?
Thanks.
--
Michael
^ permalink raw reply
* Re: FFmpeg considering GIT
From: Junio C Hamano @ 2007-05-07 19:10 UTC (permalink / raw)
To: Paul Mackerras
Cc: Linus Torvalds, Karl Hasselstr?m, Carl Worth, Michael Niedermayer,
Git Mailing List
In-Reply-To: <17983.6136.147062.346626@cargo.ozlabs.ibm.com>
Paul Mackerras <paulus@samba.org> writes:
> Linus Torvalds writes:
>
>> Finally, it realy _should_ check that the first 7 characters of the commit
>> log (the ones it ignores by just asking for substring 7..) are actually
>> the exact characters "commit ", but I'll blame my lack of comfort with the
>> language again.
>
> I have thought about rewriting it in a different language, but I
> haven't found anything that really appeals. I don't want to go to
> C/GTK or C/Qt since that would make it hard to port to Windows and
> MacOS AFAIK. Python/Tk would be a possibility, but I have never
> learnt python and I'm actually not all that comfortable with having to
> do things the object-oriented way.
>
> Any suggestions?
I've looked at Perl and Python Tk integration in the past; they
take slightly different approaches. The Perl integration tries
to first libify Tk part to make it less dependent to the host
language, tcl, and then retargets it to a new host language,
Perl. Compared to that, Python integration was shallower;
calling from Python to Tk and callback from Tk to Python were
done using Tcl as intermediary. Which looked somewhat hacky but
at the same time cleaner. From scriptability point of view,
both were much more pleasant to use than tcl. You would have
object-orientation in the nature of data anyway (e.g. your
commitdata, commitlisted, commitidx and friends will not be
look-up tables keyed with commit object name, rather they will
become attributes to commit objects), so I would expect doing it
in Python+Tk would feel natural.
^ permalink raw reply
* Re: [PATCH 6/6] user-manual: stop deprecating the manual
From: Junio C Hamano @ 2007-05-07 19:19 UTC (permalink / raw)
To: J. Bruce Fields; +Cc: Johannes Schindelin, git
In-Reply-To: <Pine.LNX.4.64.0705071256030.4167@racer.site>
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> FWIW I am a fan of the user manual. It is much, much better than the
> tutorial/manpage combo, when you want to learn how to use Git.
Likewise. Thanks, JB.
^ permalink raw reply
* Re: [FAQ?] Rationale for git's way to manage the index
From: Junio C Hamano @ 2007-05-07 19:31 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Guilhem Bonnefille, git
In-Reply-To: <Pine.LNX.4.64.0705071453120.4167@racer.site>
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> On Mon, 7 May 2007, Guilhem Bonnefille wrote:
>
>> As a newbie, I'm agree with Matthieu: the Git's index is surprising for
>> people coming from CVS/SVN (mindless?) world. So a good documentation
>> about this, even in tutorials, is really important.
>
> So, you are not only a newbie, but you have to unlearn some CVS
> braindamage.
Well, people worried that documentation and command set before
1.5.0 exposed index too much, making learning curve too steep by
having one extra thing people need to learn before starting to
be productive with git. Now post 1.5.0 people are confused,
quite rightly, that they are not told about index early enough.
I am not sure where to strike the right balance should be.
> I don't know how to make it even more prominent that CVS users should read
> a special introduction first. AFAICT such a hint is in all the appropriate
> places. (I mean, you would not expect to be able to fly a plane, just
> because you have learnt to drive a car, wouldn't you?)
Let alone flying. Just taxiing straight was hard for me until I
shook the habit I picked up from driving a car.
^ permalink raw reply
* Re: [PATCH] submodule merge support
From: Martin Waitz @ 2007-05-07 19:33 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Johannes Sixt, git
In-Reply-To: <alpine.LFD.0.98.0705071015230.3802@woody.linux-foundation.org>
[-- Attachment #1: Type: text/plain, Size: 342 bytes --]
hoi :)
On Mon, May 07, 2007 at 10:17:11AM -0700, Linus Torvalds wrote:
> Oh, btw, you should also look out for the case where the superproject
> doesn't actually have the subprojects in question checked out. What
> happens then? Just leave them conflicted?
yes, I think that's the only sane thing one can do.
--
Martin Waitz
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ 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