* Re: Teach git status to do "git diff --name-status HEAD"
From: Michael J Gruber @ 2008-09-17 11:26 UTC (permalink / raw)
To: Jakub Narebski; +Cc: Martin Langhoff, Git Mailing List
In-Reply-To: <m3ej3jm3ux.fsf@localhost.localdomain>
Jakub Narebski venit, vidit, dixit 17.09.2008 13:04:
> Michael J Gruber <git@drmicha.warpmail.net> writes:
>
>> Martin Langhoff venit, vidit, dixit 17.09.2008 08:40:
>>> I just did
>>>
>>> $ git checkout -b mdl19-offlinetony
>>> A README.offline
>>> M lib/javascript.php
>>> (...)
>>> A lib/offline/offlinemoodle.user.js
>>>
>>> I *like* this "brief status" style - takes me back to my cvs days :-).
>>> Perusing the source I found show_local_changes() which in turn led me
>>> to trying `git diff --name-status HEAD`. Now, including 'HEAD' in an
>>> alias defined in git config is going to lead to trouble... :-/
> [...]
>>> I might still make an alias to `git diff --name-status`. This would be
>>> a great thing to have as git status "--brief" IMHO... :-)
>> git status also shows untracked files. I don't know how to tell diff to
>> show untracked files as well. --diff-filter=X doesn't do it.
>
> git-ls-files?
Yes, "git ls-files -t -d -m -o --directory" does something like
"otherscmyouknowwho status". But it's plumbing, and the most obvious
porcelain place for such functionality is "git status", followed by "git
diff".
I do understand that "git status" is mostly "git commit --dry-run". But
shouldn't we have something like Martin suggested readily available
(including, optionally, untracked or ignored files).
Michael
^ permalink raw reply
* [PATCH/RFC 2/2] git-gui: Do not automatically stage file after merge tool finishes
From: Johannes Sixt @ 2008-09-17 11:40 UTC (permalink / raw)
To: Alexander Gavrilov; +Cc: Shawn O. Pearce, git, Johannes Sixt
In-Reply-To: <1221651652-3712-2-git-send-email-johannes.sixt@telecom.at>
If a merge tool was invoked on a conflicted file and the tool completed,
then the conflicted file was staged automatically. However, the fact that
the user closed the merge tool cannot be understood as the unequivocal
sign that the conflict was completely resolved. For example, the user
could have decided to postpone the resolution of the conflict, or could
have accidentally closed the tool. We better leave the file unstaged and
let the user stage it explicitly.
Signed-off-by: Johannes Sixt <johannes.sixt@telecom.at>
---
lib/mergetool.tcl | 2 --
1 files changed, 0 insertions(+), 2 deletions(-)
diff --git a/lib/mergetool.tcl b/lib/mergetool.tcl
index 965cfe4..1a96189 100644
--- a/lib/mergetool.tcl
+++ b/lib/mergetool.tcl
@@ -367,7 +367,5 @@ proc merge_tool_finish {fd} {
}
delete_temp_files $mtool_tmpfiles
-
- merge_add_resolution $mtool_target
}
}
--
1.6.0.1.1210.gb7ffe
^ permalink raw reply related
* [PATCH/RFC 0/2] git-gui: issues with merge tool series
From: Johannes Sixt @ 2008-09-17 11:40 UTC (permalink / raw)
To: Alexander Gavrilov; +Cc: Shawn O. Pearce, git, Johannes Sixt
In-Reply-To: <200808310052.21595.angavrilov@gmail.com>
I've now worked a while with the latest git-gui that includes the
capability to run a merge tool, and I must say that there is room
for improvement.
I greatly appreciate that a merge tool can be invoked. This is really
helpful.
But... I've nevertheless two *big* issues with that:
1. The inability to stage a conflicted file by clicking the icon is
*very* disruptive. The new menu entry "Stage Working Copy" is
really only a workaround, and it shows.
2. The fact that a file was automatically staged after the merge
tool was exited has caused headaches that the merge tool should
actually cure. Because of this behavior, I could not postpone a
conflict resolution once I have started the merge tool, nor can
I re-run the tool if I forgot to resolve a conflict.
This patch series addresses these issues.
Furthermore, the operations "Use local version" and "Use remote
version" could be much more useful. They could serve as "merge
shortcuts": These operations should only use the "local" or "remote"
part inside the conflict markers, and not also reset the part that
is not visible. In the current form I found them useful only in the
modify/delete conflict cases, where I picked the "delete" part.
HTH,
-- Hannes
^ permalink raw reply
* [PATCH/RFC 1/2] Revert "git-gui: Don't allow staging files with conflicts."
From: Johannes Sixt @ 2008-09-17 11:40 UTC (permalink / raw)
To: Alexander Gavrilov; +Cc: Shawn O. Pearce, git, Johannes Sixt
In-Reply-To: <1221651652-3712-1-git-send-email-johannes.sixt@telecom.at>
This reverts commits 617ceee653bd7377f662bfc6d3085f321efab7e4 (Don't allow
staging files with conflicts) and 2fe5b2ee42897a3acc78e5ddaace3775eb2713ca
(Restore ability to Stage Working Copy for conflicts).
The inability to use the icon in front of the file name to stage a file,
even a conflicted one, is too disruptive for the workflow. It was intended
as a safety valve against accidentally staging the conflicted file, which
would remove the conflict stages from the index and inhibit the use of
the merge tool. The new menu item "Stage Working Copy" that the second
reverted commit introduced helped a bit, but it clearly was just a
workaround.
Signed-off-by: Johannes Sixt <johannes.sixt@telecom.at>
---
git-gui.sh | 10 ----------
lib/mergetool.tcl | 6 ------
2 files changed, 0 insertions(+), 16 deletions(-)
diff --git a/git-gui.sh b/git-gui.sh
index 1044ab9..3b1532c 100755
--- a/git-gui.sh
+++ b/git-gui.sh
@@ -1954,17 +1954,12 @@ proc toggle_or_diff {w x y} {
$ui_index tag remove in_sel 0.0 end
$ui_workdir tag remove in_sel 0.0 end
- # Do not stage files with conflicts
if {[info exists file_states($path)]} {
set state [lindex $file_states($path) 0]
} else {
set state {__}
}
- if {[string first {U} $state] >= 0} {
- set col 1
- }
-
# Restage the file, or simply show the diff
if {$col == 0 && $y > 1} {
if {[string index $state 1] eq {O}} {
@@ -2902,11 +2897,6 @@ $ctxmmg add command \
-command {merge_resolve_one 1}
lappend diff_actions [list $ctxmmg entryconf [$ctxmmg index last] -state]
$ctxmmg add separator
-$ctxmmg add command \
- -label [mc "Stage Working Copy"] \
- -command {merge_resolve_one 0}
-lappend diff_actions [list $ctxmmg entryconf [$ctxmmg index last] -state]
-$ctxmmg add separator
create_common_diff_popup $ctxmmg
proc popup_diff_menu {ctxm ctxmmg x y X Y} {
diff --git a/lib/mergetool.tcl b/lib/mergetool.tcl
index a44a725..965cfe4 100644
--- a/lib/mergetool.tcl
+++ b/lib/mergetool.tcl
@@ -5,12 +5,6 @@ proc merge_resolve_one {stage} {
global current_diff_path
switch -- $stage {
- 0 { # Stage without confirmation, to minimize
- # disruption of the rerere workflow
- merge_add_resolution $current_diff_path
- return
- }
-
1 { set targetquestion [mc "Force resolution to the base version?"] }
2 { set targetquestion [mc "Force resolution to this branch?"] }
3 { set targetquestion [mc "Force resolution to the other branch?"] }
--
1.6.0.1.1210.gb7ffe
^ permalink raw reply related
* Re: [StGit PATCH] Convert "sink" to the new infrastructure
From: Catalin Marinas @ 2008-09-17 11:55 UTC (permalink / raw)
To: Karl Hasselström; +Cc: git
In-Reply-To: <20080916193647.GA12513@diana.vm.bytemark.co.uk>
[-- Attachment #1: Type: text/plain, Size: 2116 bytes --]
2008/9/16 Karl Hasselström <kha@treskal.com>:
> On 2008-09-16 15:59:31 +0100, Catalin Marinas wrote:
>> I think we could merge your experimental branch into master. I gave
>> it a try and seems OK. The only issue I had was that I had an older
>> version of Git and it failed in really weird ways (stg pop still
>> busy-looping after 4 minutes and in another case it failed with
>> broken pipe). Once I pulled the latest Git, it was fine but we
>> should try to be compatible at least with the Git version in the
>> Debian testing distribution. It might be the patch at the top with
>> diff-ing several trees at once but I haven't checked.
>
> There are two patches that depend on new git versions. One needs git
> 1.5.6, which is in testing so I'll be pushing that to you;
OK.
> the other
> needs Junio's master branch, and i won't even consider asking you to
> take it until it's in a released git.
Correct :-)
> I hope to push it out to you tonight or tomorrow, but I have a small
> pet patch I'd like to finish first, so I might be late.
OK, no problem. I won't have much time before the weekend anyway.
>> BTW, I ran some benchmarks on stable/master/kha-experimental
>> branches with 300 patches from the 2.6.27-rc5-mm1 kernel. See
>> attached for the results. Since performance was my worry with the
>> stack log stuff, it turns out that there isn't a big difference with
>> real patches. I think pushing can be made even faster by trying a
>> git-apply first and taking the diff from the saved blobs in the log.
>
> When benchmarking recent StGits, you'll want to try goto as well,
> since push and pop are not yet new-infrastructure-ized (meaning
> they're getting slowdowns from the stack log, but no speedups (if any)
> from the new infrastructure).
Indeed, goto is faster even than the stable branch. I attached the new
figures. I think it could go even faster if pushing attempts a "git
apply" first before the index merge. With the stack log, the patch
diff should be saved already so no need for a "git diff" (as in the
stable branch).
--
Catalin
[-- Attachment #2: stack-log-benchmarks.txt --]
[-- Type: text/plain, Size: 1474 bytes --]
CPU: Intel Pentium 4 @ 2.5GHz
Memory: 1GB
2.6.27-rc5-mm1 kernel, 300 patches uncommitted
pop/push ran a few times to heat the caches before running the
benchmarks.
Stable stgit (v0.14.3 + some fixes)
$ time stg pop -a
real 0m1.775s
user 0m0.956s
sys 0m0.724s
$ time stg push -a (fast-forward)
real 0m5.001s
user 0m1.844s
sys 0m2.860s
$ time stg push -a (no fast-forward)
real 1m27.133s
user 0m36.998s
sys 0m34.894s
$ time stg goto top-patch (fast-forward)
real 0m5.314s
user 0m1.920s
sys 0m2.768s
$ time stg goto top-patch (no fast-forward)
real 1m39.040s
user 0m37.022s
sys 0m35.666s
Current stgit master (no stack log):
$ time stg pop -a
real 0m1.621s
user 0m0.820s
sys 0m0.688s
$ time stg push -a (fast-forward)
real 0m27.205s
user 0m8.741s
sys 0m16.849s
$ time stg push -a (no fast-forward)
real 2m8.209s
user 0m46.031s
sys 0m57.260s
$ time stg goto top-patch (fast-forward)
real 0m10.437s
user 0m2.160s
sys 0m2.464s
$ time stg goto top-patch (no fast-forward)
real 1m23.244s
user 0m38.158s
sys 0m36.086s
kha/experimantal stgit (with stack log):
$ time stg pop -a
real 0m2.419s
user 0m1.144s
sys 0m1.132s
$ time stg push -a (fast-forward)
real 0m29.594s
user 0m9.217s
sys 0m17.145s
$ time stg push -a (no fast-forward)
real 2m10.270s
user 0m50.919s
sys 1m2.088s
$ time stg goto top-patch (fast-forward)
real 0m2.170s
user 0m1.084s
sys 0m0.460s
$ time stg goto top-patch (no fast-forward)
real 1m18.271s
user 0m39.026s
sys 0m31.938s
^ permalink raw reply
* Re: [PATCH/RFC 2/2] git-gui: Do not automatically stage file after merge tool finishes
From: Alexander Gavrilov @ 2008-09-17 12:25 UTC (permalink / raw)
To: Johannes Sixt; +Cc: Shawn O. Pearce, git
In-Reply-To: <1221651652-3712-3-git-send-email-johannes.sixt@telecom.at>
On Wed, Sep 17, 2008 at 3:40 PM, Johannes Sixt <johannes.sixt@telecom.at> wrote:
> If a merge tool was invoked on a conflicted file and the tool completed,
> then the conflicted file was staged automatically. However, the fact that
> the user closed the merge tool cannot be understood as the unequivocal
> sign that the conflict was completely resolved. For example, the user
> could have decided to postpone the resolution of the conflict, or could
> have accidentally closed the tool. We better leave the file unstaged and
> let the user stage it explicitly.
It completely reproduces the logic that git-mergetool uses. Namely, if
the file is unchanged, it asks explicitly, and if the tool returns a
non-zero exit code, it does not stage at all.
You also cannot simply remove merge_add_resolution, because then it
would leave the diff view stale.
^ permalink raw reply
* Re: GIT presentation
From: Pekka Kaitaniemi @ 2008-09-17 12:25 UTC (permalink / raw)
To: Paolo Ciarrocchi; +Cc: Git Mailing List
In-Reply-To: <4d8e3fd30809170208t3730cde1t4cbcdb1e609d6be6@mail.gmail.com>
Hi,
On Wed, Sep 17, 2008 at 11:08 AM, Paolo Ciarrocchi
<paolo.ciarrocchi@gmail.com> wrote:
> Hi all,
> some friend part of a LUG asked me to do a quick
> presentation/introduction to GIT
> to a group of people probably completely unaware of it.
I did a short talk in our research group meeting about Git. The
audience consisted of particle physicists who were previously familiar
with basic CVS usage. Some of these people now actually use Git to
manage their analysis software project.
> Is there any available presentation that I can as a base for my presentation?
My slides are available in both PDF and LaTeX source formats. The URL
of the PDF file is:
http://www.cs.helsinki.fi/u/kaitanie/gittalk.pdf
And the LaTeX source can be found and cloned/forked from GitHub:
http://github.com/kaitanie/gittalk
If you are willing to use LaTeX and Beamer macro package you are free
to use my slides as a basis for your own.
> I'm of course, more then willing to publish the work a let everybody
> to use/modify it.
If you choose to take my slides and improve them I would like to
see/merge them back to my presentation source tree so patches are, as
always, welcome...
-- Pekka
> Thanks.
>
> Ciao,
> --
> Paolo
> http://paolo.ciarrocchi.googlepages.com/
> --
> To unsubscribe from this list: send the line "unsubscribe git" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
^ permalink raw reply
* Re: [PATCH] Teach git diff about Objective-C syntax
From: Jonathan del Strother @ 2008-09-17 12:26 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git, vmiklos
In-Reply-To: <alpine.DEB.1.00.0809171205430.14329@racer>
On Wed, Sep 17, 2008 at 12:06 PM, Johannes Schindelin
<Johannes.Schindelin@gmx.de> wrote:
> Hi,
>
> On Wed, 17 Sep 2008, Jonathan del Strother wrote:
>
>> - "^[ ]*\\(\\([ ]*"
>> + "^[ \t]*\\(\\([ \t]*"
>
> Why?
>
>> "[A-Za-z_][A-Za-z_0-9]*\\)\\{2,\\}"
>> - "[ ]*([^;]*\\)$" },
>> + "[ \t]*([^;]*\\)$" },
>> +
>> + { "objc", "![ \t]*\\(do\\|for\\|if\\|else\\|return\\|switch\\|while\\)\n" /* Negate C statements that can look like functions */
>> + "^[ \t]*\\([-+][ \t]*([ \t]*[A-Za-z_][A-Za-z_0-9]*.*).*\\)$" /* Objective-C methods */
>
> I see you still have these awfully long lines.
I was hoping I'd get away with it since the overlong parts are just comments...
You'd prefer something like
{ "objc",
/* Negate C statements that can look like functions */
"![ \t]*\\(do\\|for\\|if\\|else\\|return\\|switch\\|while\\)\n"
/* Objective-C methods */
"^[ \t]*\\([-+][ \t]*([ \t]*[A-Za-z_][A-Za-z_0-9]*.*).*\\)$"
"\\|"
/* C functions */
"^[ \t]*\\(\\([ \t]*[A-Za-z_][A-Za-z_0-9]*\\)\\{2,\\}[ \t]*([^;]*\\)$"
"\\|"
/* Objective-C class/protocol definitions */
"^@\\(implementation\\|interface\\|protocol\\).*"},
?
^ permalink raw reply
* keep a subversion mirror in sync
From: Gaspard Bucher @ 2008-09-17 11:58 UTC (permalink / raw)
To: git
Hi !
I have been trying different strategies to keep subversion repository
in sync with a git repository (on github).
Some details with pictures can be found here: http://zenadmin.org/en/documentation/page439.html
.
I have tried to use a single database to pull/push from github and
dcommit to the old subversion repository but I get lots of conflicts
and duplicates (see link above).
I have then tried to create a "pull" only clone to dcommit, but it
looses the commit messages and replaces then with a merge message. At
least this solution keeps the github repository clean.
What is the canonical way to do this ?
Many thanks for your help.
Gaspard
^ permalink raw reply
* Re: [StGit PATCH] Convert "sink" to the new infrastructure
From: Karl Hasselström @ 2008-09-17 13:04 UTC (permalink / raw)
To: Catalin Marinas; +Cc: git
In-Reply-To: <b0943d9e0809170455m53eaf677t87e9ade3f001d044@mail.gmail.com>
On 2008-09-17 12:55:39 +0100, Catalin Marinas wrote:
> 2008/9/16 Karl Hasselström <kha@treskal.com>:
>
> > When benchmarking recent StGits, you'll want to try goto as well,
> > since push and pop are not yet new-infrastructure-ized (meaning
> > they're getting slowdowns from the stack log, but no speedups (if
> > any) from the new infrastructure).
>
> Indeed, goto is faster even than the stable branch.
When push+pop are converted to the new infrastructure, their
performance should be identical to goto's.
> I attached the new figures. I think it could go even faster if
> pushing attempts a "git apply" first before the index merge. With
> the stack log, the patch diff should be saved already so no need for
> a "git diff" (as in the stable branch).
Actually, the new infrastructure already uses apply (with fall-back to
merge-recursive). It doesn't use the saved diff, though.
> 2.6.27-rc5-mm1 kernel, 300 patches uncommitted
>
> pop/push ran a few times to heat the caches before running the
> benchmarks.
Have you tried the benchmarks I committed a while back?
--
Karl Hasselström, kha@treskal.com
www.treskal.com/kalle
^ permalink raw reply
* Re: [StGit PATCH] Convert "sink" to the new infrastructure
From: Karl Hasselström @ 2008-09-17 13:09 UTC (permalink / raw)
To: Catalin Marinas; +Cc: git
In-Reply-To: <20080917130432.GA26365@diana.vm.bytemark.co.uk>
On 2008-09-17 15:04:32 +0200, Karl Hasselström wrote:
> Actually, the new infrastructure already uses apply (with fall-back
> to merge-recursive).
Specifically, since
bc1ecd0b (Do simple in-index merge with diff+apply instead of
read-tree)
and
afa3f9b9 (Reuse the same temp index in a transaction)
--
Karl Hasselström, kha@treskal.com
www.treskal.com/kalle
^ permalink raw reply
* Re: [PATCH/RFC 0/2] git-gui: issues with merge tool series
From: Alexander Gavrilov @ 2008-09-17 12:50 UTC (permalink / raw)
To: Johannes Sixt; +Cc: Shawn O. Pearce, git
In-Reply-To: <1221651652-3712-1-git-send-email-johannes.sixt@telecom.at>
On Wed, Sep 17, 2008 at 3:40 PM, Johannes Sixt <johannes.sixt@telecom.at> wrote:
> 1. The inability to stage a conflicted file by clicking the icon is
> *very* disruptive. The new menu entry "Stage Working Copy" is
> really only a workaround, and it shows.
I can see two ways to fix it:
1) Allow that icon to work only if the diff is currently displayed,
and also ask for confirmation if there are any conflict markers
present.
Problem: What should it do with modify/delete conflicts, which
don't have any conflict markers?
2) Much harder: implement complete one-click undo. This involves
saving information from the index somewhere, and forcing such items to
remain in the 'staged' list, even if the index isn't different from
the tree version any more.
By the way, is there a simple way to re-create a conflict file from
the saved multistage index entries?
Probably the best fix is some combination of these two.
> Furthermore, the operations "Use local version" and "Use remote
> version" could be much more useful. They could serve as "merge
> shortcuts": These operations should only use the "local" or "remote"
> part inside the conflict markers, and not also reset the part that
> is not visible. In the current form I found them useful only in the
> modify/delete conflict cases, where I picked the "delete" part.
That was simply a reimplementation of git-mergetool with proper GUI.
It cannot do per-hunk resolution either...
Alexander
^ permalink raw reply
* Re: Getting correct tree layout when importing svn repo into git
From: Michael Kerrisk @ 2008-09-17 12:53 UTC (permalink / raw)
To: Björn Steinbrink
Cc: Andreas Ericsson, Michael Kerrisk, Dmitry Potapov, git,
michael.kerrisk, Michael J Gruber
In-Reply-To: <20080917105620.GA13144@atjola.homenet>
Björn,
On Wed, Sep 17, 2008 at 3:56 AM, Björn Steinbrink <B.Steinbrink@gmx.de> wrote:
> On 2008.09.17 03:28:46 -0700, Michael Kerrisk wrote:
>> Hi Andreas,
>>
>> On Tue, Sep 16, 2008 at 11:56 PM, Andreas Ericsson <ae@op5.se> wrote:
>> > Michael Kerrisk wrote:
>> >>
>> >> Hi Dimitry,
>> >>
>> >> On Tue, Sep 16, 2008 at 6:18 PM, Dmitry Potapov <dpotapov@gmail.com>
>> >> wrote:
>> >>>
>> >>> On Wed, Sep 17, 2008 at 01:40:36AM +0200, Michael Kerrisk wrote:
>> >>>>
>> >>>> $ git svn init file:///home/mtk/man-pages-rep/ -t tags -T trunk -b
>> >>>> branches
>> >>>>
>> >>>> takes about half an hour to run, the other command (which I already
>> >>>> started yesterday) seems to be taking (far) more than a day!
>> >>>
>> >>> What version of Git do you use?
>> >>
>> >> 1.5.4.5, on Linux.
>> >>
>> >
>> > An upgrade would do you good.
>>
>> But, is it going to make this much difference to the run time? By
>> now, the import using
>
> It should.
>
>> $ git svn init file:///home/mtk/man-pages-rep/ -t tags -T
>> trunk/man-pages -b branches
>>
>> has been running for over 2 days (and I still don't know if it will
>> give the layout I want), and seems to be slowing down exponentially as
>> it gets further along in the import process, so at this rate it looks
>> like it would take several more days to complete, whereas
>>
>> $ git svn init file:///home/mtk/man-pages-rep/ -t tags -T trunk -b branches
>>
>> which doesn't give the layout I want, takes less than an hour. We're
>> talking about a factor of at least 100 x in the speed difference for
>> the two imports.
>
> I guess your old import doesn't see any relations between the trunk and
> the tags/branches, right? Then the huge increase in runtime would be, at
> least in part, explained by git-svn searching for ancestry. That you see
> those tags/1.2.3@123 things also means that the 1.2.3 tags got deleted
> and recreated, or at least git-svn thinks so. Maybe the ancestry
> detection goes nuts, hard to tell.
The above sounds very plausible as an explanation of what I'm seeing.
> Is that svn repo available anywhere?
It's local. If someone felt the need to look at it to see if there is
something that could be improved in git (and maybe already is by the
current release), then I could put a copy somewhere.
Anyway, it looks like I have a fix that works from someone else in the
thread -- see my reply there.
Thanks!
Michael
--
Michael Kerrisk
Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/
man-pages online: http://www.kernel.org/doc/man-pages/online_pages.html
Found a bug? http://www.kernel.org/doc/man-pages/reporting_bugs.html
^ permalink raw reply
* Re: Getting correct tree layout when importing svn repo into git
From: Michael Kerrisk @ 2008-09-17 12:57 UTC (permalink / raw)
To: Björn Steinbrink; +Cc: Michael J Gruber, git, michael.kerrisk
In-Reply-To: <20080917110510.GB13144@atjola.homenet>
Hi Björn,
D'oh -- the fix was from you too ;-). See below.
On Wed, Sep 17, 2008 at 4:05 AM, Björn Steinbrink <B.Steinbrink@gmx.de> wrote:
> On 2008.09.17 03:38:12 -0700, Michael Kerrisk wrote:
>> $ svn list file:///home/mtk/man-pages-rep/tags
>> man-pages-2.00
>> man-pages-2.01
>> man-pages-2.02
>> man-pages-2.03
>> ...
>> $ svn list file:///home/mtk/man-pages-rep/tags/man-pages-2.00
>> man-pages
>> $ svn list file:///home/mtk/man-pages-rep/tags/man-pages-2.01
>> man-pages
>> [and so on]
>> $ svn list file:///home/mtk/man-pages-rep/branches
>> $
>> (i.e., no branches, since this has been a linear svn repo.)
>
> That means that you also need to pass the "man-pages" suffix for the
> tags and branches.
>
> git svn clone file:///path/to/repo \
> -T trunk/man-pages \
> -b branches/*/man-pages \
> -t tags/*/man-pages
>
> Might require a more recent git-svn version, not sure about that.
Using my current git version, this seems to produce the right result.
Thank you! (I guess Michael's solution is essentially equivalent, but
I tried yours first.)
Thanks everyone!
Cheers,
Michael
--
Michael Kerrisk
Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/
man-pages online: http://www.kernel.org/doc/man-pages/online_pages.html
Found a bug? http://www.kernel.org/doc/man-pages/reporting_bugs.html
^ permalink raw reply
* Re: Getting correct tree layout when importing svn repo into git
From: Michael Kerrisk @ 2008-09-17 13:00 UTC (permalink / raw)
To: Michael J Gruber; +Cc: git, michael.kerrisk, Björn Steinbrink
In-Reply-To: <48D0E6A3.4040703@drmicha.warpmail.net>
Michael,
On Wed, Sep 17, 2008 at 4:14 AM, Michael J Gruber
<git@drmicha.warpmail.net> wrote:
> Michael Kerrisk venit, vidit, dixit 17.09.2008 12:38:
>> Hello Michael,
>>
>> On Wed, Sep 17, 2008 at 1:25 AM, Michael J Gruber
>> <git@drmicha.warpmail.net> wrote:
>>> Michael Kerrisk venit, vidit, dixit 17.09.2008 00:05:
>>>> Hello,
>>>>
>>>> I'm currently trying to import an svn repository, along with its tags,
>>>> into git, and everything seems okay except that after the import I
>>>> expect to have the following structure to my checked out repository:
>>>>
>>>> [root-dir]
>>>> .git
>>>> <checked-out-files>
>>>>
>>>> But instead I end up with
>>>>
>>>> [root-dir]
>>>> .git
>>>> man-pages <-- name of my svn project
>>>> <checked-out-files>
>>>>
>>>> I've tried out a few different command-line flag settings but so far I
>>>> haven't managed to get the desired layout. I guess that I'm missing
>>>> something trivial, but I haven't worked out what it is so far.
>>>>
>>>> The commands I'm using to do the import are:
>>>>
>>>> $ git svn init file:///home/mtk/man-pages-rep/ -t tags -T trunk -b branches
>>>> $ git svn fetch
>>>>
>>>> The svn tags are getting imported okay, since:
>>>>
>>>> git branch -a | head
>>>> tags/man-pages-2.00
>>>> tags/man-pages-2.01
>>>> ...
>>>> tags/man-pages-3.08
>>>> tags/man-pages-3.09
>>>> trunk
>>>>
>>>> The following commands show the layout of my svn repo, which is pretty
>>>> much standard:
>>>>
>>>> $ svn list file:///home/mtk/man-pages-rep
>>>> branches/
>>>> tags/
>>>> trunk/
>>>> $ svn list file:///home/mtk/man-pages-rep/trunk
>>>> man-pages/
>>> That's the part that says that your layout is non-standard. What do your
>>> branches and tags look like? Do they have that superfluous "man-pages"
>>> part as well?
>>
>> $ svn list file:///home/mtk/man-pages-rep/tags
>> man-pages-2.00
>> man-pages-2.01
>> man-pages-2.02
>> man-pages-2.03
>> ...
>> $ svn list file:///home/mtk/man-pages-rep/tags/man-pages-2.00
>> man-pages
>> $ svn list file:///home/mtk/man-pages-rep/tags/man-pages-2.01
>> man-pages
>> [and so on]
>
> Bingo!
>
>> $ svn list file:///home/mtk/man-pages-rep/branches
>> $
>> (i.e., no branches, since this has been a linear svn repo.)
>
> git-svn converts svn tags into git branches (because they can change).
> So you will get a git repo with lots of branches which are subsets (HEAD
> commit is in master/trunk) of master/trunk.
>
>>>> $ svn list file:///home/mtk/man-pages-rep/trunk/man-pages
>>>> Changes
>>>> Changes.old
>>>> Makefile
>>>> README
>>>> man-pages-3.09.Announce
>>>> ...
>>>> man7/
>>>> man8/
>>>> scripts/
>>>> $ svn list file:///home/mtk/man-pages-rep/tags
>>>> man-pages-2.00/
>>>> man-pages-2.01/
>>>> ...
>>>> man-pages-3.08/
>>>> man-pages-3.09/
>>>>
>>>> What 'git svn init' command do I need to get the layout that I want
>>>> for my imported git repo?
>>> It depends on the structure of your branches and tags. My guess would be
>>> that you have something like tags/man-pages-2.00/man-pages/ etc., in
>>> which case you would need a special configuration if you want to get rid
>>> of the "man-pages" part. Tells us your structure, we'll tell you the
>>> config ;)
>>
>> Do you now have enough info above?
>
> Yes, thanks. If you use git-svn init -s (which is equivalent to -T trunk
> -t tags -b branches) you get an "exact" clone of your svn repo in
> reasonable time, as you already noticed.
>
> In order to get rid of the "man-pages" path component you can either:
>
> - remove it after the fact using git filter-branch
>
> or
>
> - remove it during the conversion process
>
> For the latter, do the following:
>
> git svn init -s file:///home/mtk/man-pages-rep/
>
> as usual. Then, before the first fetch, make sure your .git/config svn
> section looks as follows:
>
> [svn-remote "svn"]
> url = file:///home/mtk/man-pages-rep/
> fetch = trunk/man-pages:refs/remotes/trunk
> branches = branches/*/man-pages:refs/remotes/*
> tags = tags/*/man-pages:refs/remotes/tags/*
I guess your solution here was equivalent to Björn's, since after I
tried his suggestion, I ended up with an [svn-remote "svn"] that looks
just as you describe.
Thanks,
Michael
> That is, if you used "git svn init -s" you only have to add "/man-pages"
> three times on the left hand side of the refspecs. You can also do this
> using "git config", of course, if you watch out for the shell quoting.
>
> Cheers,
> Michael
>
--
Michael Kerrisk
Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/
man-pages online: http://www.kernel.org/doc/man-pages/online_pages.html
Found a bug? http://www.kernel.org/doc/man-pages/reporting_bugs.html
^ permalink raw reply
* Re: Getting correct tree layout when importing svn repo into git
From: Michael J Gruber @ 2008-09-17 13:04 UTC (permalink / raw)
To: mtk.manpages; +Cc: git, michael.kerrisk, Björn Steinbrink
In-Reply-To: <cfd18e0f0809170600r79d883d3t96abb49e827d3178@mail.gmail.com>
Michael Kerrisk venit, vidit, dixit 17.09.2008 15:00:
> Michael,
>
> On Wed, Sep 17, 2008 at 4:14 AM, Michael J Gruber
> <git@drmicha.warpmail.net> wrote:
>> Michael Kerrisk venit, vidit, dixit 17.09.2008 12:38:
>>> Hello Michael,
>>>
>>> On Wed, Sep 17, 2008 at 1:25 AM, Michael J Gruber
>>> <git@drmicha.warpmail.net> wrote:
>>>> Michael Kerrisk venit, vidit, dixit 17.09.2008 00:05:
>>>>> Hello,
>>>>>
>>>>> I'm currently trying to import an svn repository, along with its tags,
>>>>> into git, and everything seems okay except that after the import I
>>>>> expect to have the following structure to my checked out repository:
>>>>>
>>>>> [root-dir]
>>>>> .git
>>>>> <checked-out-files>
>>>>>
>>>>> But instead I end up with
>>>>>
>>>>> [root-dir]
>>>>> .git
>>>>> man-pages <-- name of my svn project
>>>>> <checked-out-files>
>>>>>
>>>>> I've tried out a few different command-line flag settings but so far I
>>>>> haven't managed to get the desired layout. I guess that I'm missing
>>>>> something trivial, but I haven't worked out what it is so far.
>>>>>
>>>>> The commands I'm using to do the import are:
>>>>>
>>>>> $ git svn init file:///home/mtk/man-pages-rep/ -t tags -T trunk -b branches
>>>>> $ git svn fetch
>>>>>
>>>>> The svn tags are getting imported okay, since:
>>>>>
>>>>> git branch -a | head
>>>>> tags/man-pages-2.00
>>>>> tags/man-pages-2.01
>>>>> ...
>>>>> tags/man-pages-3.08
>>>>> tags/man-pages-3.09
>>>>> trunk
>>>>>
>>>>> The following commands show the layout of my svn repo, which is pretty
>>>>> much standard:
>>>>>
>>>>> $ svn list file:///home/mtk/man-pages-rep
>>>>> branches/
>>>>> tags/
>>>>> trunk/
>>>>> $ svn list file:///home/mtk/man-pages-rep/trunk
>>>>> man-pages/
>>>> That's the part that says that your layout is non-standard. What do your
>>>> branches and tags look like? Do they have that superfluous "man-pages"
>>>> part as well?
>>> $ svn list file:///home/mtk/man-pages-rep/tags
>>> man-pages-2.00
>>> man-pages-2.01
>>> man-pages-2.02
>>> man-pages-2.03
>>> ...
>>> $ svn list file:///home/mtk/man-pages-rep/tags/man-pages-2.00
>>> man-pages
>>> $ svn list file:///home/mtk/man-pages-rep/tags/man-pages-2.01
>>> man-pages
>>> [and so on]
>> Bingo!
>>
>>> $ svn list file:///home/mtk/man-pages-rep/branches
>>> $
>>> (i.e., no branches, since this has been a linear svn repo.)
>> git-svn converts svn tags into git branches (because they can change).
>> So you will get a git repo with lots of branches which are subsets (HEAD
>> commit is in master/trunk) of master/trunk.
>>
>>>>> $ svn list file:///home/mtk/man-pages-rep/trunk/man-pages
>>>>> Changes
>>>>> Changes.old
>>>>> Makefile
>>>>> README
>>>>> man-pages-3.09.Announce
>>>>> ...
>>>>> man7/
>>>>> man8/
>>>>> scripts/
>>>>> $ svn list file:///home/mtk/man-pages-rep/tags
>>>>> man-pages-2.00/
>>>>> man-pages-2.01/
>>>>> ...
>>>>> man-pages-3.08/
>>>>> man-pages-3.09/
>>>>>
>>>>> What 'git svn init' command do I need to get the layout that I want
>>>>> for my imported git repo?
>>>> It depends on the structure of your branches and tags. My guess would be
>>>> that you have something like tags/man-pages-2.00/man-pages/ etc., in
>>>> which case you would need a special configuration if you want to get rid
>>>> of the "man-pages" part. Tells us your structure, we'll tell you the
>>>> config ;)
>>> Do you now have enough info above?
>> Yes, thanks. If you use git-svn init -s (which is equivalent to -T trunk
>> -t tags -b branches) you get an "exact" clone of your svn repo in
>> reasonable time, as you already noticed.
>>
>> In order to get rid of the "man-pages" path component you can either:
>>
>> - remove it after the fact using git filter-branch
>>
>> or
>>
>> - remove it during the conversion process
>>
>> For the latter, do the following:
>>
>> git svn init -s file:///home/mtk/man-pages-rep/
>>
>> as usual. Then, before the first fetch, make sure your .git/config svn
>> section looks as follows:
>>
>> [svn-remote "svn"]
>> url = file:///home/mtk/man-pages-rep/
>> fetch = trunk/man-pages:refs/remotes/trunk
>> branches = branches/*/man-pages:refs/remotes/*
>> tags = tags/*/man-pages:refs/remotes/tags/*
>
> I guess your solution here was equivalent to Björn's, since after I
> tried his suggestion, I ended up with an [svn-remote "svn"] that looks
> just as you describe.
>
> Thanks,
>
> Michael
Yes. You mentioned you used an old version. Newer ones accept the
parameters in the way Björn described. Older ones accepted the same
config, just not as parameters.
That kind of config is well-suited for splitting large svn-repos which
consist of well-separated subprojects.
So, welcome among the happy svn->git converts ;)
Michael
>> That is, if you used "git svn init -s" you only have to add "/man-pages"
>> three times on the left hand side of the refspecs. You can also do this
>> using "git config", of course, if you watch out for the shell quoting.
>>
>> Cheers,
>> Michael
>>
>
>
>
^ permalink raw reply
* [PATCH] Teach git diff about Objective-C syntax
From: Jonathan del Strother @ 2008-09-17 13:29 UTC (permalink / raw)
To: git; +Cc: vmiklos, Johannes.Schindelin, Jonathan del Strother
In-Reply-To: <57518fd10809170526i5c1e7dadgc38bb00e8073ba55@mail.gmail.com>
Add support for recognition of Objective-C class & instance methods, C functions, and class implementation/interfaces.
Signed-off-by: Jonathan del Strother <jon.delStrother@bestbefore.tv>
---
This version anchors the negated match to the beginning of the line, and shuffles the comments around to avoid the excessively long lines. Better?
Documentation/gitattributes.txt | 2 ++
diff.c | 24 +++++++++++++++++++-----
2 files changed, 21 insertions(+), 5 deletions(-)
diff --git a/Documentation/gitattributes.txt b/Documentation/gitattributes.txt
index 6f3551d..c1f13e2 100644
--- a/Documentation/gitattributes.txt
+++ b/Documentation/gitattributes.txt
@@ -315,6 +315,8 @@ patterns are available:
- `java` suitable for source code in the Java language.
+- `objc` suitable for source code in the Objective-C language.
+
- `pascal` suitable for source code in the Pascal/Delphi language.
- `php` suitable for source code in the PHP language.
diff --git a/diff.c b/diff.c
index 998dcaa..e5ec503 100644
--- a/diff.c
+++ b/diff.c
@@ -1398,17 +1398,31 @@ static struct builtin_funcname_pattern {
} builtin_funcname_pattern[] = {
{ "bibtex", "\\(@[a-zA-Z]\\{1,\\}[ \t]*{\\{0,1\\}[ \t]*[^ \t\"@',\\#}{~%]*\\).*$" },
{ "html", "^\\s*\\(<[Hh][1-6]\\s.*>.*\\)$" },
- { "java", "!^[ ]*\\(catch\\|do\\|for\\|if\\|instanceof\\|"
+
+ { "java", "!^[ \t]*\\(catch\\|do\\|for\\|if\\|instanceof\\|"
"new\\|return\\|switch\\|throw\\|while\\)\n"
- "^[ ]*\\(\\([ ]*"
+ "^[ \t]*\\(\\([ \t]*"
"[A-Za-z_][A-Za-z_0-9]*\\)\\{2,\\}"
- "[ ]*([^;]*\\)$" },
+ "[ \t]*([^;]*\\)$" },
+
+ { "objc",
+ /* Negate C statements that can look like functions */
+ "!^[ \t]*\\(do\\|for\\|if\\|else\\|return\\|switch\\|while\\)\n"
+ /* Objective-C methods */
+ "^[ \t]*\\([-+][ \t]*([ \t]*[A-Za-z_][A-Za-z_0-9]*.*).*\\)$"
+ "\\|"
+ /* C functions */
+ "^[ \t]*\\(\\([ \t]*[A-Za-z_][A-Za-z_0-9]*\\)\\{2,\\}[ \t]*([^;]*\\)$"
+ "\\|"
+ /* Objective-C class/protocol definitions */
+ "^@\\(implementation\\|interface\\|protocol\\).*"},
+
{ "pascal", "^\\(\\(procedure\\|function\\|constructor\\|"
"destructor\\|interface\\|implementation\\|"
"initialization\\|finalization\\)[ \t]*.*\\)$"
"\\|"
- "^\\(.*=[ \t]*\\(class\\|record\\).*\\)$"
- },
+ "^\\(.*=[ \t]*\\(class\\|record\\).*\\)$"},
+
{ "php", "^[\t ]*\\(\\(function\\|class\\).*\\)" },
{ "python", "^\\s*\\(\\(class\\|def\\)\\s.*\\)$" },
{ "ruby", "^\\s*\\(\\(class\\|module\\|def\\)\\s.*\\)$" },
--
1.6.0.2.250.ge7a3b.dirty
^ permalink raw reply related
* Re: GIT presentation
From: Randal L. Schwartz @ 2008-09-17 13:36 UTC (permalink / raw)
To: Johan Herland; +Cc: Paolo Ciarrocchi, git
In-Reply-To: <200809171132.07492.johan@herland.net>
>>>>> "Johan" == Johan Herland <johan@herland.net> writes:
Johan> Randal Schwartz, Google Tech Talk:
Johan> http://video.google.com/videoplay?docid=-3999952944619245780
Johan> (can't seem to find the slides from this one...)
If you want the Keynote slides, I can make them available.
--
Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095
<merlyn@stonehenge.com> <URL:http://www.stonehenge.com/merlyn/>
Smalltalk/Perl/Unix consulting, Technical writing, Comedy, etc. etc.
See http://methodsandmessages.vox.com/ for Smalltalk and Seaside discussion
^ permalink raw reply
* Re: [PATCH] Teach git diff about Objective-C syntax
From: Jonathan del Strother @ 2008-09-17 13:37 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git, vmiklos
In-Reply-To: <alpine.DEB.1.00.0809171205430.14329@racer>
On Wed, Sep 17, 2008 at 12:06 PM, Johannes Schindelin
<Johannes.Schindelin@gmx.de> wrote:
> Hi,
>
> On Wed, 17 Sep 2008, Jonathan del Strother wrote:
>
>> - "^[ ]*\\(\\([ ]*"
>> + "^[ \t]*\\(\\([ \t]*"
>
> Why?
Sorry - missed that in the original reply. You really prefer having
an invisible tab character to an explicit \t ?
^ permalink raw reply
* Project organisation and structure
From: k wayne @ 2008-09-17 13:49 UTC (permalink / raw)
To: git
Hello,
I'm new to git, and I hope this is the right mailinglist for what I'm
going to ask; it was the only one I found on http://git.or.cz. Sorry
if it's not or my question is remarkably stupid. I've read the git
documentation, of course, but it wasn't always easy to wrap my head
around all the concepts, so I might have missed an obvious solution to
my problem.
Currently, I've got a tree of self-written C++ source code for which I
don't use any SCM, and I'd like to start using git on it. However,
I've run into issues with my directory layout I cannot resolve on my
own.
I have a collection of libraries and programs, which aren't coupled
too much, but aren't really independent either; for example, library X
depends on Y, program Z on lib A and so forth. Since all of these libs
and programs are logically connected to each other in some way, I
would like to have them all in one central repository.
So I heard that I could create kind of a "meta-repository" for the
whole project, and have submodules for each library or program, which
sounds exactly like what I want. However, I've been told that my
current directory layout will not work this way with git.
This is how my project root directory (say it's ~) looks like:
~/build - Build files which apply for the whole project, like doxygen
build files.
~/include/$submodule - Each library/program has an own directory here,
in which all header files go.
~/projects/$submodule - Files related to an individual project, like
makefiles etc.
~/src/$submodule - Like the above two, but for source files.
~/test/$submodule - Again, a directory for each library/program,
containing files for (unit)tests.
~/doc - Documentation files for the project as a whole.
~/doc/$submodule - Documentation files for individual libraries/programs.
These are the directories I would like git to track for me. There are
some other dirs not listed here (e.g. for object files,) but I can
easily add them to .gitignore.
So, the git structure as I imagine it would look like this: ~/.git
contains the "meta-repository," in which all the submodules reside.
Each submodule would have its .git directory in ~/projects/$submodule.
Alternatively, ~/.git for the meta-repo and ~/.git-$subproject or
something like this would be okay too.
However, I have been told I cannot go to ~/projects/$submodule and do
a "git add ../../{include,src,test,doc}/$submodule" there. I could add
symlinks in ~/projects/$submodule to each of these dirs and add that
link, but this would not work with windows, I guess (would it work
with git, anyway?)
So, how can I manage my code without having to restructure my tree?
I'd like to keep it that way, because it is convenient to have only
one directory to pass to the compiler as an additional include dir,
and can include my header files as "submodule/someheader.hpp" which
is, in my opinion, helpful in organizing the code.
If there should be no way I can keep my directory setup the way it is
with the current git, would a feature request be a good idea (and
possibly implemented), or does my directory tree have a serious flaw I
haven't stumbled across yet, which makes it unusable anyways?
Thank you in advance.
^ permalink raw reply
* Re: [PATCH 15/16] checkout: add new options to support narrow checkout
From: Nguyen Thai Ngoc Duy @ 2008-09-17 13:49 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git
In-Reply-To: <200809171107.35826.jnareb@gmail.com>
On 9/17/08, Jakub Narebski <jnareb@gmail.com> wrote:
> >> You have decided then on the term 'narrow checkout', and not
> >> 'partial checkout' or 'sparse checkout', then?
> >
> > Not yet. I tend to prefer partial/sparse checkout. Probably should
> > have a look at how other SCMs do and what term they use. If Git's
> > functionality is so different, a different term might notice people
> > about that.
>
>
> Perhaps whip up a survey? Just kidding (or not).
Well I've been asking about the name on this list long enough. I'm
going with 'sparse checkout' as svn' sparse directories does not look
too different from git's.
> >>> When you apply new narrow spec to your working directory using either
> >>> --path, --add-path or --remove-path, it will update "checkout" status
> >>> in index accordingly. Moreover, if a file is marked "no-checkout" and
> >>> is present in working directory, it will be removed. If a file is
> >>> turned from "no-checkout" to "checkout", then it will be added again
> >>> to working directory. Modified and unmerged entries can't bear
> >>> "no-checkout" status, if narrow spec applies to them, "git checkout"
> >>> will refuse to update working directory.
> >>
> >>
> >> Do I understand correctly, that if one uses --path=<colon separated list>
> >> _only_ filenames matching one of patterns specified would be checked out,
> >> --add-path=<path> would additionally checkout given path and mark "wanted",
> >> and --remove-path=<path> would additionally mark "no-checkout" and remove
> >> path?
> >
> > --add-path/--remove-path also use narrow spec, which could be more
> > than one pattern.
>
>
> What is the difference then between --add-path and --path? The fact
> that --add-path can be incremental, and --path starts always from
> an empty set?
--path clears out all no-checkout bits and set again based on the
given spec. --add-path adds more checkout entries based on the given
spec, think of widening checkout area. --remove-path does narrow the
checkout area. They are like '=', '+=' and '-=' operators
respectively.
>
> >> What --add-path starts from, i.e. does
> >>
> >> $ git checkout --add-path=.gitignore
> >>
> >> starts from empty set if --add-path is first, or from full set as without
> >> --add-path?
> >
> > I'm not sure I understand this.
>
>
> Well, what I wanted to ask is if --remove-path starts from fully
> checked out repository, for example if
>
> $ git checkout --remove-path=some_large_file
>
> would checkout all files _except_ 'some_large_file'.
No, there is no negative spec. Like I said above, --remove-path is to
remove some files based on the given spec.
>
> >> And is <pathspec> matched against full pathname, or like .gitignore
> >> rules, i.e. as full pathname if it has at least one '/' in it?
> >
> > like shell wildcard, full pathname must match. On my way back home, I
> > thought I should have removed mention of "pathspec", which behaves a
> > little bit different.
> >
> > Also those specs are relative to working directory though, so if you
> > are in b/c and want to match d, you only need to type --add-path=d
> > instead of --add-path=b/c/d. Will add this to doc.
>
>
> I would have thought that you follow the same rules (perhaps with
> exception of !path excluding rule) like for gitignore and gitattributes.
>
Um.. never thought of gitignores/gitattributes rules before. It's a
good idea all narrowspec/gitignore/gitattributes using the same rules.
Thanks.
--
Duy
^ permalink raw reply
* Re: Help using Git(-svn) for specific use case
From: Pico Geyer @ 2008-09-17 14:09 UTC (permalink / raw)
To: Dmitry Potapov; +Cc: git
In-Reply-To: <37fcd2780809151255q278b1786ub4caec9022d7b082@mail.gmail.com>
Hi Dmitry
I'm going to give example commands to confirm my understanding of the
git-svn workflow you described.
Any comments or corrections are welcome.
On the local server, get a clone of the repository:
srvA# git svn clone http://server.com/repo/proj/trunk proj
srvA# cd proj
Create a local branch, where developers will push to
srvA# git branch integration
Now a developer clones the repository on the server, and makes a local
branch for developement:
dev1# git clone ssh://svrA/path/to/repo
dev1# git checkout -b new_featureX
(Developer makes some changes and commits to the new_featureX branch)
Developer now pushes the changes to the integration branch
dev1# git push origin new_featureX:integration
The merge master now rebases the changes on to the master branch:
srvA# git rebase integration
Now push the changes to the upstream subversion server:
srvA# git svn dcommit
At some stage svn users will commit to the subversion repository, and
we will need to pull changes into srvA:
srvA# git svn rebase
Now the integration branch does not include the changes in master, so
rebase the changes to integration:
srvA# git rebase master integration
Finally the developer needs those changes too, so on his master branch:
dev1# git rebase origin
Is this the process that you were trying to describe?
Any additional steps that need to be added?
And how do I make sure that when developers push to the server that it
results in a fast-forward merge? Do I do that with commit hooks?
Thanks again for the advice.
Pico
On Mon, Sep 15, 2008 at 9:55 PM, Dmitry Potapov <dpotapov@gmail.com> wrote:
> On Mon, Sep 15, 2008 at 4:50 PM, Pico Geyer <picogeyer@gmail.com> wrote:
>>
>> At the head office, we are (still) using a Subversion server to host
>> our source code.
>> At the branch office, we would like to do the following:
>> * Fetch the latest code from the subversion server.
>> * Push changes that we have made at the remote office back to upstream
>> SVN server.
>> * Be able to share source code changes locally (at the branch office)
>> between developers.
>
> I used Git in somewhat similar situation where almost all development
> was done in Git mirror of SVN, and then the work was propagated to SVN.
> There are some limitations with this approach. The most important is
> that SVN does not support merges, so you have to linerialize all history
> that you want to commit in SVN. That means that you are going to use git
> rebase a lot to rewrite history, which is a PITA. Another problem with
> this approach is that the author is not preserved. In SVN, all commits will
> look like all changes are done by the person who run "git svn dcommit".
>
> Yet, despite of all these limitations caused by using SVN as backend,
> it was far more pleasant to work with Git than with SVN (you can save
> your work in progress, you can easily organize the review process,
> and many other features such as "git bisect" or "git log -S" just to
> name a few...).
>
>>
>> The solution that I imagined is that we would setup a server (lets
>> call it A) at the branch office with a Git repository, that all the
>> developers can access.
>> Developers would then clone the server repository A, make mods and
>> then push changes back to A.
>> It would be nice if git users could commit to a subversion branch.
>> A merge master would then (as necessary) use svn dcommit to push the
>> changes up to the svn server.
>> Is this scenario possible?
>
> Each user has its own copy of the whole repository and they always
> commit to their _local_ branches. Then they can push their changes to
> the Git repo on your server, but it is a bad idea to push changes to
> a local branch of a non-bare repository especially if that branch is
> checked out, because push does not (and should not!) update the working
> tree and that leads to the situation where all pushed changes are
> looked undo in the working tree of that repository. Therefore, you
> will probably have a separately integration branch to which users
> will push. Oftentimes, users will have to rebase their work on top the
> integration branch to be able to push on it (only fast-forward push
> should be allowed).
>
> The merge master will merge this branch to the local branch assotiated
> with subversion (it will be fast-forward, not a real merge) and then
> run git svn dcommit to propagate to subversion.
>
> If there were some conflicting changes in subversion repo, the merge
> master will have to resolve them. After that update the merge base
> should be updated (using git branch -f) to point out to the top of
> the subversion branch.
>
> If users have some changes that were based on the old integration
> branches they will have to rebase them to the new position of the
> integration branch. As I said above, git rebase is going to be very
> often operation in this workflow.
>
> NOTE: branches in git differs from what they are in subversion. In
> essence, they are no more than pointers to where to add the next
> commit. When I learned Git, I found very useful the article called
> "Git for computer scientists" to understand basic ideas of how Git
> works: http://eagain.net/articles/git-for-computer-scientists/
>
>>
>> From the git-svn man page: "git-clone does not clone branches under
>> the refs/remotes/ hierarchy or any git-svn metadata, or config. So
>> repositories created and managed with using git-svn should use rsync
>> for cloning, if cloning is to be done at all."
>> Does that mean that one should not push changes to a repository that
>> was created with "git svn clone ..."?
>
> No, what the above description says is that SVN specific information is
> not cloned when you clone a repo created by svn. It means that users who
> cloned from you will not be able to use git-svn to push their changes in
> the original subversion repository. Yet, they can push to your repository
> as to any other Git repository.
>
> Dmitry
>
^ permalink raw reply
* Re: [PATCH] Teach git diff about Objective-C syntax
From: Johannes Schindelin @ 2008-09-17 14:28 UTC (permalink / raw)
To: Jonathan del Strother; +Cc: git, vmiklos
In-Reply-To: <57518fd10809170637n585afacbs94fdddc5b8bb61b6@mail.gmail.com>
Hi,
On Wed, 17 Sep 2008, Jonathan del Strother wrote:
> On Wed, Sep 17, 2008 at 12:06 PM, Johannes Schindelin
> <Johannes.Schindelin@gmx.de> wrote:
> > Hi,
> >
> > On Wed, 17 Sep 2008, Jonathan del Strother wrote:
> >
> >> - "^[ ]*\\(\\([ ]*"
> >> + "^[ \t]*\\(\\([ \t]*"
> >
> > Why?
>
> Sorry - missed that in the original reply. You really prefer having
> an invisible tab character to an explicit \t ?
No. But I prefer clear-cut commits, not sneaked-in changes. This is a
change in the java part FYI.
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH] Teach git diff about Objective-C syntax
From: Jonathan del Strother @ 2008-09-17 14:32 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git, vmiklos
In-Reply-To: <alpine.DEB.1.00.0809171528120.14329@racer>
On Wed, Sep 17, 2008 at 3:28 PM, Johannes Schindelin
<Johannes.Schindelin@gmx.de> wrote:
> Hi,
>
> On Wed, 17 Sep 2008, Jonathan del Strother wrote:
>
>> On Wed, Sep 17, 2008 at 12:06 PM, Johannes Schindelin
>> <Johannes.Schindelin@gmx.de> wrote:
>> > Hi,
>> >
>> > On Wed, 17 Sep 2008, Jonathan del Strother wrote:
>> >
>> >> - "^[ ]*\\(\\([ ]*"
>> >> + "^[ \t]*\\(\\([ \t]*"
>> >
>> > Why?
>>
>> Sorry - missed that in the original reply. You really prefer having
>> an invisible tab character to an explicit \t ?
>
> No. But I prefer clear-cut commits, not sneaked-in changes. This is a
> change in the java part FYI.
>
Sorry, I considered it to be a formatting change & didn't think it
would matter. I'll separate them out & repost later
^ permalink raw reply
* Re: [RFC/PATCH] Use compatibility regex library for OSX/Darwin
From: Boyd Lynn Gerber @ 2008-09-17 14:48 UTC (permalink / raw)
To: Brandon Casey
Cc: Jeff King, Arjen Laarhoven, git, Mike Ralphson, Johannes Sixt,
Junio C Hamano
In-Reply-To: <_MhavOIoKmx4_xVm-blejLMi-eFa1T8Huv94Uz9PxwJ3DyOMzuyUeg@cipher.nrlssc.navy.mil>
On Tue, 16 Sep 2008, Brandon Casey wrote:
> Boyd Lynn Gerber wrote:
>> So with path set so my /usr/gnu/bin/ is before any others this is what I
>> get as the next failure. After a long run...
>>
>> * FAIL 5: alternation in pattern
>>
>> git config diff.java.funcname "^[
>> ]*\(\(public\|static\).*\)$"
>> git diff --no-index Beer.java Beer-correct.java |
>> grep "^@@.*@@ public static void main("
>>
>>
>> * failed 1 among 5 test(s)
>> gmake[1]: *** [t4018-diff-funcname.sh] Error 1
>> gmake[1]: Leaving directory `/home/zenez/build/osr6/git-1.6.0.2/t'
>> gmake: *** [test] Error 2
>
> That's the one, thanks.
>
> And just so you know, this isn't a regression. It's just a new test that
> was designed to reveal a shortcoming that no one knew existed before Arjen
> discovered it.
Six of the 12 all have the same problem. I would say all 12 have it as my
experience has shown that if these have it then all have it. The fixes I
did were so generic that once I got these first 6 working the others just
worked. So I would say they all need the patch or fix. Sorry I did not
follow the whole thread. I read it from the archive what I could. It
seems the archive is about 2 days behind.
Good Luck,
--
Boyd Gerber <gerberb@zenez.com>
ZENEZ 1042 East Fort Union #135, Midvale Utah 84047
^ 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