* Re: git doc build failure on OS X 10.5.6 (Leopard) during xmlto phase
From: Alejandro Riveira @ 2009-03-11 20:12 UTC (permalink / raw)
To: git
In-Reply-To: <49B7E670.7060606@drmicha.warpmail.net>
El Wed, 11 Mar 2009 17:27:28 +0100, Michael J Gruber escribió:
> Jay Soffian venit, vidit, dixit 11.03.2009 16:49:
>>
>> j.
>
> FWIW: The effect you describe (which is different from the OP) occurs on
> Fedora 10 as well, and not only for git man pages, also for others. I've
> been meaning to look into this, just like I've been meaning to look into
> so much stuff...
>
"Me too" from a Ubuntu 8.10 Box
> Michael
^ permalink raw reply
* Re: Help understanding "rebase"
From: John Dlugosz @ 2009-03-11 20:04 UTC (permalink / raw)
To: git, casey
=== Re: ===
It may help those who know the internals of git-rebase if you supplied
the
commands you used and your git version.
So, you're saying you did
git checkout topic
git rebase dev
or the equivalent
git rebase dev topic
? Are you sure you didn't get the arguments to rebase reversed?
===end===
Sorry, I did not write down exactly what I typed. But the situation was
the latter:
git rebase dev topic
While looking at the man page to get the arguments right, with dev being
"upstream" and the branch to rewrite last. I suppose I _could_ have
gotten it backwards.
--John
(please excuse the footer)
TradeStation Group, Inc. is a publicly-traded holding company (NASDAQ GS: TRAD) of three operating subsidiaries, TradeStation Securities, Inc. (Member NYSE, FINRA, SIPC and NFA), TradeStation Technologies, Inc., a trading software and subscription company, and TradeStation Europe Limited, a United Kingdom, FSA-authorized introducing brokerage firm. None of these companies provides trading or investment advice, recommendations or endorsements of any kind. The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon, this information by persons or entities other than the intended recipient is prohibited.
If you received this in error, please contact the sender and delete the material from any computer.
^ permalink raw reply
* Re: Google Summer of Code 2009: GIT
From: saurabh gupta @ 2009-03-11 20:02 UTC (permalink / raw)
To: david; +Cc: Johannes Schindelin, git
In-Reply-To: <alpine.DEB.1.10.0903111223470.16753@asgard.lang.hm>
On Thu, Mar 12, 2009 at 12:59 AM, <david@lang.hm> wrote:
> On Wed, 11 Mar 2009, saurabh gupta wrote:
>
>> On Wed, Mar 11, 2009 at 10:02 PM, <david@lang.hm> wrote:
>>>
>>> On Wed, 11 Mar 2009, Johannes Schindelin wrote:
>>>
>>>> Hi,
>>>>
>>>> On Wed, 11 Mar 2009, saurabh gupta wrote:
>>>>
>>
>> In case of only a terminal, It would be very difficult to show an OO
>> document to represent the *diff* output in both text as well in GUI.
>> For example, to indicate the changes in an OO document, we will have
>> to change the underlying XML file appropriately to show the markers
>> signs and other things in the conflict file. Now, if this file is
>> opened in terminal, it would not be at all comprehensible to see the
>> differences.
>>
>> The main thing is that to create *diff* for different file formats, we
>> will have to write the parser code accordingly.
>
> correct, and in the case of an XML file, the meaningful diff can be
> substantially shorter than what a text diff of the two files would be
> (whitespace changes that don't matter, even some tag ordering changes may
> not matter)
>
> I'm just asking that you don't get so fixated on what can be done in a GUI
> that you provide no benifit to people who don't have the GUI
>
> there are a _lot_ of XML based formats out there, having a diff/merge
> capability to make dealing with them better than just treating them as text
> files would be a _very_ useful thing.
>
> going beyond that and creating the ability to do the markup in
> application-specific ways, and present it to the user in a nice GUI would
> also be nice, but these are a step up after having the basic XML handling
> that isn't specific to a particular application.
Yes, but the thing is that the underlying codes and method will be
different for GUI part and terminal part to make it readable and
understandable. Like for OO Documents, if we aim to show the *diff*
output in the Office tool, then we have to change the xml file
accordingly. But the same xml file when used with terminal only, the
*diff* output is not clear.
As Johannes said in above post that for OO documents, while showing
the *diff* result, no xml data should be shown.
--
Saurabh Gupta
Senior,
NSIT,New Delhi, India
^ permalink raw reply
* Re: Google Summer of Code 2009: GIT
From: Johannes Schindelin @ 2009-03-11 19:55 UTC (permalink / raw)
To: david; +Cc: saurabh gupta, git
In-Reply-To: <alpine.DEB.1.10.0903111229330.16753@asgard.lang.hm>
Hi,
On Wed, 11 Mar 2009, david@lang.hm wrote:
> On Wed, 11 Mar 2009, Johannes Schindelin wrote:
>
> > On Wed, 11 Mar 2009, david@lang.hm wrote:
> >
> > > On Wed, 11 Mar 2009, Johannes Schindelin wrote:
> > >
> > > > On Wed, 11 Mar 2009, saurabh gupta wrote:
> > > >
> > > > > What I think is to implement file formats other than text like
> > > > > that written on wiki i.e. latex, xml, or even any database file
> > > > > (db file). Another idea (although it can be weired also) is to
> > > > > implement the new file formats in the plug-in formats. For
> > > > > example, to incorporate the merger engine for a new file format,
> > > > > a plug-in is created and can be integrated with the present
> > > > > merger in the git. However, I am not sure how much valid is this
> > > > > idea to make the present merger in git to be compatible with the
> > > > > plug-ins for enabling newer file formats.
> > > >
> > > > I am not sure that a plugin structure is needed. Take, for
> > > > example, three different .xml based formats: OpenOffice documents,
> > > > .svg files and Ant build.xml files. They need very different user
> > > > interfaces.
> > > >
> > > > > I am thinking of using gtk+ libraries to implement the GUI part
> > > > > (I am quite comfortable with gtk+).
> > > >
> > > > I mentioned Tcl/Tk, because it is portable, but I'll also take
> > > > gtk-based stuff ;-)
> > > >
> > > > > However, I think in merging and notifying about the conflicts in
> > > > > the xml files, other things can also be put forward. Like the
> > > > > GUI will show the number of tags differing and what are the new
> > > > > tags added and even if any tag is renamed with the content
> > > > > unchanged. If possible, how about showing a tree like structure
> > > > > (just like DOM model) to compare (or diff) the two xml files.
> > > >
> > > > This is a little bit too low-level for my liking. Taking the
> > > > OpenOffice example again, the GUI should not expose XML at all...
> > >
> > > don't assume that you have a GUI just to handle a filetype. if you
> > > have one, good, make use of it. but have a fallback for how to deal
> > > with things if all you have is a text terminal.
> >
> > I do not think it makes sense to assume all you have at your hands is
> > a terminal when you try to resolve a merge conflict in an .svg file.
>
> I'm not saying that you assume that all you have is a terminal, I'm
> saying that you _support_ the case that all you have is a terminal.
Sorry, no, the GSoC idea was not about "merge helpers that run also in a
terminal". The idea was about "Domain specific merge helpers".
If I can choose, I'd rather have support for one more merge helper, even
if it is all graphical, than an enhancement to support also a terminal.
While I am dreaming: this is the list of domains _I_ would like to see
supported: LaTeX, OpenOffice documents, .svg files.
But that is not up to me to decide, just to suggest.
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH] Include log_config module in apache.conf
From: Johannes Schindelin @ 2009-03-11 19:45 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Daniel Barkalow, git
In-Reply-To: <7vab7r6g59.fsf@gitster.siamese.dyndns.org>
Hi,
On Wed, 11 Mar 2009, Junio C Hamano wrote:
> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
>
> > Sorry, no:
> >
> > -- snip --
> > apache2: Syntax error on line 7 of
> > /home/schindelin/git/t/lib-httpd/apache.conf: module log_config_module is
> > built-in and can't be loaded
> > -- snap --
>
> Sorry and thanks---I'll apply an interdiff and credit it to you.
Thanks...
Ciao,
Dscho
^ permalink raw reply
* Re: Google Summer of Code 2009: GIT
From: Junio C Hamano @ 2009-03-11 19:36 UTC (permalink / raw)
To: Saurabh Gupta; +Cc: git
In-Reply-To: <49B74373.3090609@gmail.com>
Saurabh Gupta <saurabhgupta1403@gmail.com> writes:
> *1) Domain specific merge helpers*
> Intelligence in the merger can be put which modifies the source file
> according the format. Different file formats can be put in the merger
> to support.
The way "merge" works is:
- A tree-level 3-way merge is done (either inside merge-recursive backend
or with "read-tree -m O A B" inside merge-resolve), and trivial merges
are resolved at the whole-file level without need for any helper.
Roughly speaking, the definition of "a trivially mergeable path" is a
path that only one side modified while the other side didn't, or both
sides modified identically.
- The remaining paths need to be merged at file level. The gitattributes
mechanism is used to decide what exact algorithm to use based on what
the merged file is; we have a plain-text "xdl" merge driver and "union"
merge driver built-in, in addition to "binary" merge driver (which
always says "the changes conflict; use ours as a tentative result).
When a merge driver is called, it is given three blobs: original, ours
and theirs (any one of them could be missing). It is the driver's
responsibility to come up with an automated merge result when the
changes do not overlap and report success, or leave an intermediate
"conflicted merge" and report conflicts. In either case, the driver is
expected to return _one_ single bytestream as its tentative result.
- Cleanly merged paths are updated in the index and their results are
written out to the work tree. For paths the merge drivers reported
conflicts, tentative results returned by the merge drivers are written
out to the work tree but the index entries for them are left in an
unmerged state.
- If all paths are cleanly merged, "git merge" and friends write the
index out as a tree and create a commit out of it (unless otherwise
instructed) and report success.
- When a merge left conflicts, the user can use external tools like "git
mergetool" to resolve the conflict in the work tree, starting from the
tentative result given by the merge driver, and "git add" to register
the resolution to the index.
When people say a "merge helper" in the context of git, I think they think
about at least two kinds, that work at very different layers. It is
unclear which one you are more interested in, or you are tackling both.
- A group of new merge drivers that handle various structured text
formats (e.g. XML based ones), on which the default plain-text merge is
not suitable, would be a good addition to the git suite. If you are
interested in doing this as your GSoC project, it would very much be
git specific.
- Amerge helper that takes three files (original, ours and theirs) as its
input and helps the end user (perhaps graphically) merge them can be
used at a backend to the "git-mergetool", by registering a filetype as
"binary" (so that the low-level merge driver won't even try merging the
contents at the file level), and letting "git-mergetool" invoke the
"helper" with these three files. The development of this kind of
"helper" would not be a git specific project.
Obviously it would help the users to have both, but which kind is more
important?
In a collaborative environment, people do not work in void without any
communication with each other, and they actively try not to step on each
other's toes. Even when changes are made from both sides of a merge to
the same file (in other words, a file level merge is required), in the
majority of cases, the changes do not overlap, and being able to resolve
such merges cleanly most of the time, without having to resort to an
external "git mergetool", is a huge win in productivity. I think a domain
specific "merge driver" project would benefit the git users a lot more
than a domain specific "merge helper" that can be used as a "git
mergetool" backend (and can also be used outside git).
Of course, you can do both.
But my point is it is unclear which one you meant when you said "merge
helper".
^ permalink raw reply
* Re: [PATCH] Include log_config module in apache.conf
From: Brian Gernhardt @ 2009-03-11 19:33 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Johannes Schindelin, Daniel Barkalow, git
In-Reply-To: <7vab7r6g59.fsf@gitster.siamese.dyndns.org>
On Mar 11, 2009, at 2:58 PM, Junio C Hamano wrote:
> diff --git a/t/lib-httpd/apache.conf b/t/lib-httpd/apache.conf
> index a0d4077..f460e40 100644
> --- a/t/lib-httpd/apache.conf
> +++ b/t/lib-httpd/apache.conf
> @@ -4,7 +4,9 @@ DocumentRoot www
> LogFormat "%h %l %u %t \"%r\" %>s %b" common
> CustomLog access.log common
> ErrorLog error.log
> -LoadModule log_config_module modules/mod_log_config.so
> +<IfModule !mod_log_config.c>
> + LoadModule log_config_module modules/mod_log_config.so
> +</IfModule>
>
> <IfDefine Darwin>
> LoadModule log_config_module modules/mod_log_config.so
Isn't this last line redundant now?
^ permalink raw reply
* Re: Google Summer of Code 2009: GIT
From: david @ 2009-03-11 19:30 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: saurabh gupta, git
In-Reply-To: <alpine.DEB.1.00.0903111800500.10498@intel-tinevez-2-302>
On Wed, 11 Mar 2009, Johannes Schindelin wrote:
> Hi,
>
> On Wed, 11 Mar 2009, david@lang.hm wrote:
>
>> On Wed, 11 Mar 2009, Johannes Schindelin wrote:
>>
>>> On Wed, 11 Mar 2009, saurabh gupta wrote:
>>>
>>>> What I think is to implement file formats other than text like that
>>>> written on wiki i.e. latex, xml, or even any database file (db file).
>>>> Another idea (although it can be weired also) is to implement the new
>>>> file formats in the plug-in formats. For example, to incorporate the
>>>> merger engine for a new file format, a plug-in is created and can be
>>>> integrated with the present merger in the git. However, I am not sure
>>>> how much valid is this idea to make the present merger in git to be
>>>> compatible with the plug-ins for enabling newer file formats.
>>>
>>> I am not sure that a plugin structure is needed. Take, for example, three
>>> different .xml based formats: OpenOffice documents, .svg files and Ant
>>> build.xml files. They need very different user interfaces.
>>>
>>>> I am thinking of using gtk+ libraries to implement the GUI part (I am
>>>> quite comfortable with gtk+).
>>>
>>> I mentioned Tcl/Tk, because it is portable, but I'll also take gtk-based
>>> stuff ;-)
>>>
>>>> However, I think in merging and notifying about the conflicts in the xml
>>>> files, other things can also be put forward. Like the GUI will show the
>>>> number of tags differing and what are the new tags added and even if any
>>>> tag is renamed with the content unchanged. If possible, how about
>>>> showing a tree like structure (just like DOM model) to compare (or diff)
>>>> the two xml files.
>>>
>>> This is a little bit too low-level for my liking. Taking the OpenOffice
>>> example again, the GUI should not expose XML at all...
>>
>> don't assume that you have a GUI just to handle a filetype. if you have one,
>> good, make use of it. but have a fallback for how to deal with things if all
>> you have is a text terminal.
>
> I do not think it makes sense to assume all you have at your hands is a
> terminal when you try to resolve a merge conflict in an .svg file.
I'm not saying that you assume that all you have is a terminal, I'm saying
that you _support_ the case that all you have is a terminal.
David Lang
^ permalink raw reply
* Re: Google Summer of Code 2009: GIT
From: david @ 2009-03-11 19:29 UTC (permalink / raw)
To: saurabh gupta; +Cc: Johannes Schindelin, git
In-Reply-To: <ab9fa62a0903111007w4772b234x8e6fd19cdc7fc595@mail.gmail.com>
On Wed, 11 Mar 2009, saurabh gupta wrote:
> On Wed, Mar 11, 2009 at 10:02 PM, <david@lang.hm> wrote:
>> On Wed, 11 Mar 2009, Johannes Schindelin wrote:
>>
>>> Hi,
>>>
>>> On Wed, 11 Mar 2009, saurabh gupta wrote:
>>>
>>>> What I think is to implement file formats other than text like that
>>>> written on wiki i.e. latex, xml, or even any database file (db file).
>>>> Another idea (although it can be weired also) is to implement the new
>>>> file formats in the plug-in formats. For example, to incorporate the
>>>> merger engine for a new file format, a plug-in is created and can be
>>>> integrated with the present merger in the git. However, I am not sure
>>>> how much valid is this idea to make the present merger in git to be
>>>> compatible with the plug-ins for enabling newer file formats.
>>>
>>> I am not sure that a plugin structure is needed. Take, for example, three
>>> different .xml based formats: OpenOffice documents, .svg files and Ant
>>> build.xml files. They need very different user interfaces.
>>>
>>>> I am thinking of using gtk+ libraries to implement the GUI part (I am
>>>> quite comfortable with gtk+).
>>>
>>> I mentioned Tcl/Tk, because it is portable, but I'll also take gtk-based
>>> stuff ;-)
>>>
>>>> However, I think in merging and notifying about the conflicts in the xml
>>>> files, other things can also be put forward. Like the GUI will show the
>>>> number of tags differing and what are the new tags added and even if any
>>>> tag is renamed with the content unchanged. If possible, how about
>>>> showing a tree like structure (just like DOM model) to compare (or diff)
>>>> the two xml files.
>>>
>>> This is a little bit too low-level for my liking. Taking the OpenOffice
>>> example again, the GUI should not expose XML at all...
>>
>> don't assume that you have a GUI just to handle a filetype. if you have one,
>> good, make use of it. but have a fallback for how to deal with things if all
>> you have is a text terminal.
>
> In case of only a terminal, It would be very difficult to show an OO
> document to represent the *diff* output in both text as well in GUI.
> For example, to indicate the changes in an OO document, we will have
> to change the underlying XML file appropriately to show the markers
> signs and other things in the conflict file. Now, if this file is
> opened in terminal, it would not be at all comprehensible to see the
> differences.
>
> The main thing is that to create *diff* for different file formats, we
> will have to write the parser code accordingly.
correct, and in the case of an XML file, the meaningful diff can be
substantially shorter than what a text diff of the two files would be
(whitespace changes that don't matter, even some tag ordering changes
may not matter)
I'm just asking that you don't get so fixated on what can be done in a GUI
that you provide no benifit to people who don't have the GUI
there are a _lot_ of XML based formats out there, having a diff/merge
capability to make dealing with them better than just treating them as
text files would be a _very_ useful thing.
going beyond that and creating the ability to do the markup in
application-specific ways, and present it to the user in a nice GUI would
also be nice, but these are a step up after having the basic XML handling
that isn't specific to a particular application.
David Lang
^ permalink raw reply
* Re: [PATCH] Include log_config module in apache.conf
From: Junio C Hamano @ 2009-03-11 18:58 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Daniel Barkalow, git
In-Reply-To: <alpine.DEB.1.00.0903111240150.10279@pacific.mpi-cbg.de>
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> Sorry, no:
>
> -- snip --
> apache2: Syntax error on line 7 of
> /home/schindelin/git/t/lib-httpd/apache.conf: module log_config_module is
> built-in and can't be loaded
> -- snap --
Sorry and thanks---I'll apply an interdiff and credit it to you.
-- >8 --
From: Johannes Schindelin <Johannes.Schindelin@gmx.de>
Date: Wed, 11 Mar 2009 12:47:06 +0100 (CET)
Subject: [PATCH] test: do not LoadModule log_config_module unconditionally
LoadModule directive for log_config_module will not work if the module is
built-in.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
---
t/lib-httpd/apache.conf | 4 +++-
1 files changed, 3 insertions(+), 1 deletions(-)
diff --git a/t/lib-httpd/apache.conf b/t/lib-httpd/apache.conf
index a0d4077..f460e40 100644
--- a/t/lib-httpd/apache.conf
+++ b/t/lib-httpd/apache.conf
@@ -4,7 +4,9 @@ DocumentRoot www
LogFormat "%h %l %u %t \"%r\" %>s %b" common
CustomLog access.log common
ErrorLog error.log
-LoadModule log_config_module modules/mod_log_config.so
+<IfModule !mod_log_config.c>
+ LoadModule log_config_module modules/mod_log_config.so
+</IfModule>
<IfDefine Darwin>
LoadModule log_config_module modules/mod_log_config.so
--
^ permalink raw reply related
* Re: After git svn clone master is tied to a branch in svn, howto set master to trunk
From: Svenn Are Bjerkem @ 2009-03-11 17:54 UTC (permalink / raw)
To: git
In-Reply-To: <f07e780b-621f-4d2d-83dd-363716f9d507@d19g2000yqb.googlegroups.com>
On Mar 11, 6:20 pm, Svenn Are Bjerkem <svenn.bjer...@googlemail.com>
wrote:
> On Mar 11, 5:32 pm, Michael J Gruber <g...@drmicha.warpmail.net>
> wrote:
>
>
>
> > Svenn Are Bjerkem venit, vidit, dixit 11.03.2009 16:17:
>
> > > Hi,
> > > after performing a
> > > $> git svn clonehttps://svnserver/svn/a/b/c-Ttrunk/current -t tags -
> > > b branches
> > > I find that the git master has been tied to one of the branches. It
> > > turns out that the highest svn revision number in the repository was
> > > tied to that branch.
>
> > > For historical reasons we have subdirectories in trunk/ on svn, but I
> > > inspected .git/config
> > > [svn-remote "svn"]
> > > url =https://svnserver/svn
> > > fetch = a/b/c/trunk/current:refs/remotes/trunk
> > > branches = a/b/c/branches/*:refs/remotes/*
> > > tags = a/b/c/tags/*:refs/remotes/tags/*
> > > And I assume it picked up the strange trunk correctly.
>
> > > I have been googling around for a while looking for instructions how
> > > to tell git that when I check out "master" it should be "trunk" from
> > > svn and not "branches/next_gen", or more precisely how to move master
> > > to trunk from branches/next_gen.
>
> > > I guess I could solve the problem by modifying a file in trunk on svn
> > > and commit so that the trunk will get the highest svn revision number
> > > again and redo the clone.
>
> > I'm not quite sure what you mean by master being "tied" to an svn
> > branch. You mean you want master to track the svn trunk? Then
>
> When doing a git svn info in master right after the clone was
> finished, before any work was done, URL washttps://...../branches/next_gen.
> When deleting the git repository, modifying and commiting a file in
> trunk on svn and rerun the exact same clone operation, URL in git svn
> info becamehttps://....../trunk/current. During the first clone,
> branches/next_gen had the highest overall svn revision number and got
> automatically "tied" to master, while in the second clone run trunk
> had the highest overall svn revision number and git chose that master
> should track svn trunk.
>
>
>
> > git branch -D master
> > git checkout --track -b master trunk
>
> > should do (assuming you haven't worked on master yet).
>
> I will take a note of this advice and perform a commit to force a
> different branch than next_gen to have overall highest svn revision
> number when I do a clone next time. Reading up in the manuals on your
> suggestion seems to be what I intended to acheive.
I now had the opportunity to check your suggestion, and this time I
first performed a commit in branches/old_gen so branches/old_gen got
the overall highest svn revision number. When performing exactly the
same git svn clone as before, master was set to track branches/
old_gen. Now I tried your suggestion, and except for the fact that I
cannot delete master as long as I am in master, it works as expected.
I had to do a git checkout -b next_gen next_gen to get into next_gen
branch to be allowed to git branch -D master, but that was not a
really big surprise. Then checkout --track does the job nicely.
Good to know, thanks for your help,
Svenn
^ permalink raw reply
* Re: After git svn clone master is tied to a branch in svn, howto set master to trunk
From: Svenn Are Bjerkem @ 2009-03-11 17:20 UTC (permalink / raw)
To: git
In-Reply-To: <49B7E7BB.2090803@drmicha.warpmail.net>
On Mar 11, 5:32 pm, Michael J Gruber <g...@drmicha.warpmail.net>
wrote:
> Svenn Are Bjerkem venit, vidit, dixit 11.03.2009 16:17:
>
>
>
> > Hi,
> > after performing a
> > $> git svn clonehttps://svnserver/svn/a/b/c-T trunk/current -t tags -
> > b branches
> > I find that the git master has been tied to one of the branches. It
> > turns out that the highest svn revision number in the repository was
> > tied to that branch.
>
> > For historical reasons we have subdirectories in trunk/ on svn, but I
> > inspected .git/config
> > [svn-remote "svn"]
> > url =https://svnserver/svn
> > fetch = a/b/c/trunk/current:refs/remotes/trunk
> > branches = a/b/c/branches/*:refs/remotes/*
> > tags = a/b/c/tags/*:refs/remotes/tags/*
> > And I assume it picked up the strange trunk correctly.
>
> > I have been googling around for a while looking for instructions how
> > to tell git that when I check out "master" it should be "trunk" from
> > svn and not "branches/next_gen", or more precisely how to move master
> > to trunk from branches/next_gen.
>
> > I guess I could solve the problem by modifying a file in trunk on svn
> > and commit so that the trunk will get the highest svn revision number
> > again and redo the clone.
>
> I'm not quite sure what you mean by master being "tied" to an svn
> branch. You mean you want master to track the svn trunk? Then
When doing a git svn info in master right after the clone was
finished, before any work was done, URL was https://...../branches/next_gen.
When deleting the git repository, modifying and commiting a file in
trunk on svn and rerun the exact same clone operation, URL in git svn
info became https://....../trunk/current. During the first clone,
branches/next_gen had the highest overall svn revision number and got
automatically "tied" to master, while in the second clone run trunk
had the highest overall svn revision number and git chose that master
should track svn trunk.
>
> git branch -D master
> git checkout --track -b master trunk
>
> should do (assuming you haven't worked on master yet).
I will take a note of this advice and perform a commit to force a
different branch than next_gen to have overall highest svn revision
number when I do a clone next time. Reading up in the manuals on your
suggestion seems to be what I intended to acheive.
Thanks,
--
Svenn
^ permalink raw reply
* Re: Google Summer of Code 2009: GIT
From: saurabh gupta @ 2009-03-11 17:07 UTC (permalink / raw)
To: david; +Cc: Johannes Schindelin, git
In-Reply-To: <alpine.DEB.1.10.0903110931070.13653@asgard.lang.hm>
On Wed, Mar 11, 2009 at 10:02 PM, <david@lang.hm> wrote:
> On Wed, 11 Mar 2009, Johannes Schindelin wrote:
>
>> Hi,
>>
>> On Wed, 11 Mar 2009, saurabh gupta wrote:
>>
>>> What I think is to implement file formats other than text like that
>>> written on wiki i.e. latex, xml, or even any database file (db file).
>>> Another idea (although it can be weired also) is to implement the new
>>> file formats in the plug-in formats. For example, to incorporate the
>>> merger engine for a new file format, a plug-in is created and can be
>>> integrated with the present merger in the git. However, I am not sure
>>> how much valid is this idea to make the present merger in git to be
>>> compatible with the plug-ins for enabling newer file formats.
>>
>> I am not sure that a plugin structure is needed. Take, for example, three
>> different .xml based formats: OpenOffice documents, .svg files and Ant
>> build.xml files. They need very different user interfaces.
>>
>>> I am thinking of using gtk+ libraries to implement the GUI part (I am
>>> quite comfortable with gtk+).
>>
>> I mentioned Tcl/Tk, because it is portable, but I'll also take gtk-based
>> stuff ;-)
>>
>>> However, I think in merging and notifying about the conflicts in the xml
>>> files, other things can also be put forward. Like the GUI will show the
>>> number of tags differing and what are the new tags added and even if any
>>> tag is renamed with the content unchanged. If possible, how about
>>> showing a tree like structure (just like DOM model) to compare (or diff)
>>> the two xml files.
>>
>> This is a little bit too low-level for my liking. Taking the OpenOffice
>> example again, the GUI should not expose XML at all...
>
> don't assume that you have a GUI just to handle a filetype. if you have one,
> good, make use of it. but have a fallback for how to deal with things if all
> you have is a text terminal.
In case of only a terminal, It would be very difficult to show an OO
document to represent the *diff* output in both text as well in GUI.
For example, to indicate the changes in an OO document, we will have
to change the underlying XML file appropriately to show the markers
signs and other things in the conflict file. Now, if this file is
opened in terminal, it would not be at all comprehensible to see the
differences.
The main thing is that to create *diff* for different file formats, we
will have to write the parser code accordingly.
> David Lang
>
--
Saurabh Gupta
Senior,
NSIT,New Delhi, India
^ permalink raw reply
* Re: [PATCH/RFD] builtin-revert.c: release index lock when cherry-picking an empty commit
From: Mike Ralphson @ 2009-03-11 17:02 UTC (permalink / raw)
To: Jeff King; +Cc: Chris Johnsen, Junio C Hamano, git, Miklos Vajna
In-Reply-To: <e2b179460903110408i4ab3c9cg3c863b89a2f57cba@mail.gmail.com>
2009/3/11 Mike Ralphson <mike.ralphson@gmail.com>
>
> 2009/3/11 Jeff King <peff@peff.net>:
> > OK, then nothing to worry about there. I have no idea which shell
> > OpenBSD and NetBSD use these days, and I don't have access to a box.
> > Anybody?
>
> OpenBSD uses pdksh in Bourne shell mode for non-root shells (ksh mode
> for root)
... and isn't broken in this instance (OpenBSD v4.1)
Weird test failures though, so now I'm looking at that 8-)
^ permalink raw reply
* Re: Google Summer of Code 2009: GIT
From: Johannes Schindelin @ 2009-03-11 17:01 UTC (permalink / raw)
To: david; +Cc: saurabh gupta, git
In-Reply-To: <alpine.DEB.1.10.0903110931070.13653@asgard.lang.hm>
Hi,
On Wed, 11 Mar 2009, david@lang.hm wrote:
> On Wed, 11 Mar 2009, Johannes Schindelin wrote:
>
> > On Wed, 11 Mar 2009, saurabh gupta wrote:
> >
> > > What I think is to implement file formats other than text like that
> > > written on wiki i.e. latex, xml, or even any database file (db file).
> > > Another idea (although it can be weired also) is to implement the new
> > > file formats in the plug-in formats. For example, to incorporate the
> > > merger engine for a new file format, a plug-in is created and can be
> > > integrated with the present merger in the git. However, I am not sure
> > > how much valid is this idea to make the present merger in git to be
> > > compatible with the plug-ins for enabling newer file formats.
> >
> > I am not sure that a plugin structure is needed. Take, for example, three
> > different .xml based formats: OpenOffice documents, .svg files and Ant
> > build.xml files. They need very different user interfaces.
> >
> > > I am thinking of using gtk+ libraries to implement the GUI part (I am
> > > quite comfortable with gtk+).
> >
> > I mentioned Tcl/Tk, because it is portable, but I'll also take gtk-based
> > stuff ;-)
> >
> > > However, I think in merging and notifying about the conflicts in the xml
> > > files, other things can also be put forward. Like the GUI will show the
> > > number of tags differing and what are the new tags added and even if any
> > > tag is renamed with the content unchanged. If possible, how about
> > > showing a tree like structure (just like DOM model) to compare (or diff)
> > > the two xml files.
> >
> > This is a little bit too low-level for my liking. Taking the OpenOffice
> > example again, the GUI should not expose XML at all...
>
> don't assume that you have a GUI just to handle a filetype. if you have one,
> good, make use of it. but have a fallback for how to deal with things if all
> you have is a text terminal.
I do not think it makes sense to assume all you have at your hands is a
terminal when you try to resolve a merge conflict in an .svg file.
Ciao,
Dscho
^ permalink raw reply
* Re: Google Summer of Code 2009: GIT
From: saurabh gupta @ 2009-03-11 16:58 UTC (permalink / raw)
To: Daniel Barkalow; +Cc: Johannes Schindelin, git
In-Reply-To: <alpine.LNX.1.00.0903111159530.19665@iabervon.org>
On Wed, Mar 11, 2009 at 9:59 PM, Daniel Barkalow <barkalow@iabervon.org> wrote:
> On Wed, 11 Mar 2009, saurabh gupta wrote:
>
>> On Wed, Mar 11, 2009 at 7:32 PM, Johannes Schindelin
>> <Johannes.Schindelin@gmx.de> wrote:
>> > Hi,
>> >
>> > On Wed, 11 Mar 2009, saurabh gupta wrote:
>> >
>> >> What I think is to implement file formats other than text like that
>> >> written on wiki i.e. latex, xml, or even any database file (db file).
>> >> Another idea (although it can be weired also) is to implement the new
>> >> file formats in the plug-in formats. For example, to incorporate the
>> >> merger engine for a new file format, a plug-in is created and can be
>> >> integrated with the present merger in the git. However, I am not sure
>> >> how much valid is this idea to make the present merger in git to be
>> >> compatible with the plug-ins for enabling newer file formats.
>> >
>> > I am not sure that a plugin structure is needed. Take, for example, three
>> > different .xml based formats: OpenOffice documents, .svg files and Ant
>> > build.xml files. They need very different user interfaces.
>>
>> okay. In that case, if they have a different user interfaces then
>> separate plug-in would be needed for each of these. May be this will
>> get more messy.
>
> One thing that I think would be good whenever possible is to have the
> merge program generate a file in the same format which is easily
> recognizable as having conflict markers. For example, I think it should be
> possible to show conflicts in the text of office documents by having
> styles for each side of the merge, and show each side's content in the
> appropriate style. Then the user opens the document with their choice of
> office software, finds the things in the conflict styles, and decides what
> the result should be.
Well, I think this is what which is done in case of normal text files
also. The conflicts put the markers in the file to indicate the
changes and the modification part. However, in the case of OO
documents, we have to change the content for the xml file and when it
is opened in the office software, the user will get the modified
contents.
> Of course, if the two sides conflict over something that isn't text, it
> gets harder.
>
> Also remember that, for a merge, there are two important cases: (1) the
> two sides changed things that aren't related at all; (2) the two sides
> changed things that might affect each other. In case (1), the tool should
> take care of everything automatically and report that it took care of it;
> in case (2), it should reliably determine that user assistance is
> required.
>
> -Daniel
> *This .sig left intentionally blank*
>
--
Saurabh Gupta
Senior,
Electronics and Communication Engg.
NSIT,New Delhi, India
^ permalink raw reply
* Re: Google Summer of Code 2009: GIT
From: Johannes Schindelin @ 2009-03-11 16:44 UTC (permalink / raw)
To: Daniel Barkalow; +Cc: saurabh gupta, git
In-Reply-To: <alpine.LNX.1.00.0903111159530.19665@iabervon.org>
Hi,
On Wed, 11 Mar 2009, Daniel Barkalow wrote:
> One thing that I think would be good whenever possible is to have the
> merge program generate a file in the same format which is easily
> recognizable as having conflict markers. For example, I think it should
> be possible to show conflicts in the text of office documents by having
> styles for each side of the merge, and show each side's content in the
> appropriate style. Then the user opens the document with their choice of
> office software, finds the things in the conflict styles, and decides
> what the result should be.
That's a very good idea! (Except for LaTeX, maybe...)
For SVG, you could add both versions of a modified object, for
example, maybe with some visual effect to show the version...
Ciao,
Dscho
^ permalink raw reply
* Re: setting up tracking on push
From: Jeff King @ 2009-03-11 16:40 UTC (permalink / raw)
To: Nanako Shiraishi
Cc: Junio C Hamano, Jay Soffian, Marc Branchaud, Miles Bader, git
In-Reply-To: <20090311190207.6117@nanako3.lavabit.com>
On Wed, Mar 11, 2009 at 07:02:07PM +0900, Nanako Shiraishi wrote:
> I'm sorry, but I don't understand why you want to keep the entries in
> the reflog that were made before you pushed your branch to make it
> public in this scenario.
>
> Especially because you are relinquishing the authority to the public
> repository by wishing to be able to "track" it, you can't rewind the
> branch beyond the point you initially pushed out any more. At that
> point, wouldn't it make more sense to drop the old reflog data and
> pretend as if the branch were fetched from the branch from your public
> repository it now follows, just like everybody else does?
That only means that you cannot rewind back to some spot in the reflog.
There is nothing to say that you cannot pull useful ideas from the
reflog that you thought were failed experiments, and apply them as
new commits.
-Peff
^ permalink raw reply
* Re: After git svn clone master is tied to a branch in svn, howto set master to trunk
From: Michael J Gruber @ 2009-03-11 16:32 UTC (permalink / raw)
To: Svenn Are Bjerkem; +Cc: git
In-Reply-To: <09fb20f5-3722-49d4-9565-95a5b41d15ac@c36g2000yqn.googlegroups.com>
Svenn Are Bjerkem venit, vidit, dixit 11.03.2009 16:17:
> Hi,
> after performing a
> $> git svn clone https://svnserver/svn/a/b/c -T trunk/current -t tags -
> b branches
> I find that the git master has been tied to one of the branches. It
> turns out that the highest svn revision number in the repository was
> tied to that branch.
>
> For historical reasons we have subdirectories in trunk/ on svn, but I
> inspected .git/config
> [svn-remote "svn"]
> url = https://svnserver/svn
> fetch = a/b/c/trunk/current:refs/remotes/trunk
> branches = a/b/c/branches/*:refs/remotes/*
> tags = a/b/c/tags/*:refs/remotes/tags/*
> And I assume it picked up the strange trunk correctly.
>
> I have been googling around for a while looking for instructions how
> to tell git that when I check out "master" it should be "trunk" from
> svn and not "branches/next_gen", or more precisely how to move master
> to trunk from branches/next_gen.
>
> I guess I could solve the problem by modifying a file in trunk on svn
> and commit so that the trunk will get the highest svn revision number
> again and redo the clone.
I'm not quite sure what you mean by master being "tied" to an svn
branch. You mean you want master to track the svn trunk? Then
git branch -D master
git checkout --track -b master trunk
should do (assuming you haven't worked on master yet).
Michael
^ permalink raw reply
* Re: Google Summer of Code 2009: GIT
From: david @ 2009-03-11 16:32 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: saurabh gupta, git
In-Reply-To: <alpine.DEB.1.00.0903111458340.10498@intel-tinevez-2-302>
On Wed, 11 Mar 2009, Johannes Schindelin wrote:
> Hi,
>
> On Wed, 11 Mar 2009, saurabh gupta wrote:
>
>> What I think is to implement file formats other than text like that
>> written on wiki i.e. latex, xml, or even any database file (db file).
>> Another idea (although it can be weired also) is to implement the new
>> file formats in the plug-in formats. For example, to incorporate the
>> merger engine for a new file format, a plug-in is created and can be
>> integrated with the present merger in the git. However, I am not sure
>> how much valid is this idea to make the present merger in git to be
>> compatible with the plug-ins for enabling newer file formats.
>
> I am not sure that a plugin structure is needed. Take, for example, three
> different .xml based formats: OpenOffice documents, .svg files and Ant
> build.xml files. They need very different user interfaces.
>
>> I am thinking of using gtk+ libraries to implement the GUI part (I am
>> quite comfortable with gtk+).
>
> I mentioned Tcl/Tk, because it is portable, but I'll also take gtk-based
> stuff ;-)
>
>> However, I think in merging and notifying about the conflicts in the xml
>> files, other things can also be put forward. Like the GUI will show the
>> number of tags differing and what are the new tags added and even if any
>> tag is renamed with the content unchanged. If possible, how about
>> showing a tree like structure (just like DOM model) to compare (or diff)
>> the two xml files.
>
> This is a little bit too low-level for my liking. Taking the OpenOffice
> example again, the GUI should not expose XML at all...
don't assume that you have a GUI just to handle a filetype. if you have
one, good, make use of it. but have a fallback for how to deal with things
if all you have is a text terminal.
David Lang
^ permalink raw reply
* Re: Google Summer of Code 2009: GIT
From: Daniel Barkalow @ 2009-03-11 16:29 UTC (permalink / raw)
To: saurabh gupta; +Cc: Johannes Schindelin, git
In-Reply-To: <ab9fa62a0903110713k2a21cefbj1e7cd3c126aca8f9@mail.gmail.com>
On Wed, 11 Mar 2009, saurabh gupta wrote:
> On Wed, Mar 11, 2009 at 7:32 PM, Johannes Schindelin
> <Johannes.Schindelin@gmx.de> wrote:
> > Hi,
> >
> > On Wed, 11 Mar 2009, saurabh gupta wrote:
> >
> >> What I think is to implement file formats other than text like that
> >> written on wiki i.e. latex, xml, or even any database file (db file).
> >> Another idea (although it can be weired also) is to implement the new
> >> file formats in the plug-in formats. For example, to incorporate the
> >> merger engine for a new file format, a plug-in is created and can be
> >> integrated with the present merger in the git. However, I am not sure
> >> how much valid is this idea to make the present merger in git to be
> >> compatible with the plug-ins for enabling newer file formats.
> >
> > I am not sure that a plugin structure is needed. Take, for example, three
> > different .xml based formats: OpenOffice documents, .svg files and Ant
> > build.xml files. They need very different user interfaces.
>
> okay. In that case, if they have a different user interfaces then
> separate plug-in would be needed for each of these. May be this will
> get more messy.
One thing that I think would be good whenever possible is to have the
merge program generate a file in the same format which is easily
recognizable as having conflict markers. For example, I think it should be
possible to show conflicts in the text of office documents by having
styles for each side of the merge, and show each side's content in the
appropriate style. Then the user opens the document with their choice of
office software, finds the things in the conflict styles, and decides what
the result should be.
Of course, if the two sides conflict over something that isn't text, it
gets harder.
Also remember that, for a merge, there are two important cases: (1) the
two sides changed things that aren't related at all; (2) the two sides
changed things that might affect each other. In case (1), the tool should
take care of everything automatically and report that it took care of it;
in case (2), it should reliably determine that user assistance is
required.
-Daniel
*This .sig left intentionally blank*
^ permalink raw reply
* Re: Google Summer of Code 2009: GIT
From: saurabh gupta @ 2009-03-11 16:29 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git
In-Reply-To: <alpine.DEB.1.00.0903111631310.10498@intel-tinevez-2-302>
On Wed, Mar 11, 2009 at 9:08 PM, Johannes Schindelin
<Johannes.Schindelin@gmx.de> wrote:
> Hi,
>
> On Wed, 11 Mar 2009, saurabh gupta wrote:
>
>> On Wed, Mar 11, 2009 at 7:32 PM, Johannes Schindelin
>> <Johannes.Schindelin@gmx.de> wrote:
>>
>> > On Wed, 11 Mar 2009, saurabh gupta wrote:
>> >
>> >> What I think is to implement file formats other than text like that
>> >> written on wiki i.e. latex, xml, or even any database file (db file).
>> >> Another idea (although it can be weired also) is to implement the new
>> >> file formats in the plug-in formats. For example, to incorporate the
>> >> merger engine for a new file format, a plug-in is created and can be
>> >> integrated with the present merger in the git. However, I am not sure
>> >> how much valid is this idea to make the present merger in git to be
>> >> compatible with the plug-ins for enabling newer file formats.
>> >
>> > I am not sure that a plugin structure is needed. Take, for example,
>> > three different .xml based formats: OpenOffice documents, .svg files
>> > and Ant build.xml files. They need very different user interfaces.
>>
>> okay. In that case, if they have a different user interfaces then
>> separate plug-in would be needed for each of these. May be this will get
>> more messy.
>
> The thing is: "plugin" is an architecture issue, which I think we will
> have plenty of time hashing out. "GUI" is the bigger problem, because if
> we cannot come up with something that is worth implementing, we can stop
> the project early.
We can decide for the GUI part. RIght now, I am going through the
background for Tcl/Tk. I am sure that using this tool will serve the
purpose in the better way and portability issue can also be kept in
mind.
>> >> However, I think in merging and notifying about the conflicts in the
>> >> xml files, other things can also be put forward. Like the GUI will
>> >> show the number of tags differing and what are the new tags added and
>> >> even if any tag is renamed with the content unchanged. If possible,
>> >> how about showing a tree like structure (just like DOM model) to
>> >> compare (or diff) the two xml files.
>> >
>> > This is a little bit too low-level for my liking. Taking the
>> > OpenOffice example again, the GUI should not expose XML at all...
>>
>> hmmmm.....I think I get your point somewhat. Let me do some research
>> over the formats and the background formats in which tools like
>> OpenOffice store the data in xml files. May be for docbooks by
>> OpenOffice, the best thing would be to give the *diff* output in terms
>> of lines.
>
> Actually, I think that the diff is not the issue. What is needed is a way
> that is both intuitive and versatile enough that all kinds of merge
> conflicts in OpenOffice documents can be resolved by a total computer
> illiterate.
>
> The same problem applies for SVG files, but the user interface would look
> completely different.
>
> As such, it might not be wise to have a common framework at all, but to
> make the first an extension for OpenOffice, and the second a modification
> of, say, inkscape.
>
> Of course, David will then come and say: "But that is more appropriate a
> project for OpenOffice and inkscape, then!".
>
> The good thing is that this is Open Source, and we'll just ask them to
> co-mentor this project.
All right. I agree with this and We can come up with a plan to
implement the thing in an organized way. I agree with you that one
common platform for these will not work because of the way they are
represented and is comfortable for a normal computer user.
>> I would also appreciate to know what you think and would like to see the
>> output in such case.
>
> That's the thing: I do not know yet how it should look like.
>
> Ciao,
> Dscho
>
>
--
Saurabh Gupta
Senior,
NSIT,New Delhi, India
^ permalink raw reply
* Re: git doc build failure on OS X 10.5.6 (Leopard) during xmlto phase
From: Michael J Gruber @ 2009-03-11 16:27 UTC (permalink / raw)
To: Jay Soffian; +Cc: Tom Holaday, git
In-Reply-To: <76718490903110849x2ef48a89j3f17706390991eda@mail.gmail.com>
Jay Soffian venit, vidit, dixit 11.03.2009 16:49:
> On Wed, Mar 11, 2009 at 11:39 AM, Jay Soffian <jaysoffian@gmail.com> wrote:
>> On Wed, Mar 11, 2009 at 11:12 AM, Jay Soffian <jaysoffian@gmail.com> wrote:
>>> And your man pages still won't be perfect. Preformatted text will look
>>> like this:
>>>
>>> .ft C
>>> ...
>>> .ft
> I must be losing my mind. This is suddenly working, though I can't
> track it down to any change in git. I just rebuilt my man pages and
> this no longer is occurring, even though I still have a terminal
> window open with the output of "git help help" _showing this problem_
> and that's from man pages I built/installed just a few days ago. (And
> I haven't upgraded MacPorts lately.)
>
> Oh well.
>
> j.
FWIW: The effect you describe (which is different from the OP) occurs on
Fedora 10 as well, and not only for git man pages, also for others. I've
been meaning to look into this, just like I've been meaning to look into
so much stuff...
Michael
^ permalink raw reply
* Re: Google Summer of Code 2009: GIT
From: saurabh gupta @ 2009-03-11 16:21 UTC (permalink / raw)
To: Rogan Dawes; +Cc: Johannes Schindelin, git
In-Reply-To: <49B7D84B.6080501@dawes.za.net>
On Wed, Mar 11, 2009 at 8:57 PM, Rogan Dawes <lists@dawes.za.net> wrote:
> saurabh gupta wrote:
>>>> However, I think in merging and notifying about the conflicts in the xml
>>>> files, other things can also be put forward. Like the GUI will show the
>>>> number of tags differing and what are the new tags added and even if any
>>>> tag is renamed with the content unchanged. If possible, how about
>>>> showing a tree like structure (just like DOM model) to compare (or diff)
>>>> the two xml files.
>>>
>>> This is a little bit too low-level for my liking. Taking the OpenOffice
>>> example again, the GUI should not expose XML at all...
>>
>> hmmmm.....I think I get your point somewhat. Let me do some research
>> over the formats and the background formats in which tools like
>> OpenOffice store the data in xml files. May be for docbooks by
>> OpenOffice, the best thing would be to give the *diff* output in terms
>> of lines.
>> I would also appreciate to know what you think and would like to see
>> the output in such case.
>
> I think that the implementation may make use of features inherent in the
> file format where possible. e.g. I suspect that OpenOffice has the
> ability to show "Tracked changes", and then allow the user to view the
> changes using the actual OpenOffice implementation.
>
> I suspect that that will get a lot more difficult with e.g. conflicts
> and merges, because I doubt that OOo has the ability to show changes
> from multiple versions.
>
> But I have to agree with Dscho, that the output would have to depend on
> the file type (OOo document), not just the data structure (e.g. XML)
> inside the file.
>
> A regular XML file diff could choose to ignore/collapse whitespace
> (pretty printing) when doing the comparison, to show things like moving
> a branch further down the tree.
>
> e.g.
>
> <i>text</i>
>
> vs
>
> <b><i>text</i></b>
>
> vs
>
> <b>
> <i>text</i>
> </b>
>
> For plain XML, a textual diff might choose to show it with each element
> un-indented, and a standard text diff output:
>
> + <b>
> <i>
> text
> </i>
> + </b>
>
> while a GUI diff might show the new element highlighted in a tree:
>
> #green#<b>#/green#
> <i>
> text
>
> I think that where reasonable that you should aim to have a text-only
> version that could be wrapped by a GUI. Obviously, this would be
> meaningless when diffing a JPG, for instance.
All right. I got what you mean to say.
>
> Ok, that was a bit rambling. I hope it helped more than it confused.
>
> Rogan
>
--
Saurabh Gupta
Senior,
Electronics and Communication Engg.
NSIT,New Delhi, India
^ permalink raw reply
* Re: After git svn clone master is tied to a branch in svn, howto set master to trunk
From: Svenn Are Bjerkem @ 2009-03-11 16:04 UTC (permalink / raw)
To: git
In-Reply-To: <09fb20f5-3722-49d4-9565-95a5b41d15ac@c36g2000yqn.googlegroups.com>
On Mar 11, 4:17 pm, Svenn Are Bjerkem <svenn.bjer...@googlemail.com>
wrote:
> Hi,
> after performing a
> $> git svn clone https://svnserver/svn/a/b/c-T trunk/current -t tags -
> b branches
> I find that the git master has been tied to one of the branches. It
> turns out that the highest svn revision number in the repository was
> tied to that branch.
[snip]
> I guess I could solve the problem by modifying a file in trunk on svn
> and commit so that the trunk will get the highest svn revision number
> again and redo the clone.
I just wanted to confirm this assumption: First I removed the complete
git-svn clone and modified a file in trunk and checked it into svn.
Then I re-performed the git svn clone as described above. The master
in the local git repository is now tied to the trunk of the svn
repository.
--
Svenn
^ 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