* Re: An idea: maybe Git should use a lock/unlock file mode for problematic files? [Was: Re: after first git clone of linux kernel repository there are changed files in working dir]
From: Daniel Barkalow @ 2009-01-21 0:03 UTC (permalink / raw)
To: Alex Riesen; +Cc: John Chapman, Hannu Koivisto, rdkrsr, git
In-Reply-To: <81b0412b0901201525w22513418p57acc19457908a3@mail.gmail.com>
On Wed, 21 Jan 2009, Alex Riesen wrote:
> 2009/1/20 Daniel Barkalow <barkalow@iabervon.org>:
> > My impression was that this didn't happen in practice, because teams
> > would tend to not have two people create the same file at the same time,
> > but with different cases, and people interacting with the same file at
> > different times would use whatever case it was introduced with.
>
> It will and does happen in practice (annoingly too often even). Not with Git
> yet (with Perforce), where people do "branching" by simply copying things
> in another directory (perforce world does not know real branches),
> renaming files randomly, and putting the new directory back in the
> system (or maybe it is the strange tools here which do that - often
> it is the first character of a directory or file which gets down- or up-cased).
How does the resulting code work at all? With a case-sensitive filesystem,
most of the files you're using don't have the expected names any more, and
most systems will therefore not actually build or run.
I have to assume it's your strange tools, because we never have this
problem at my work, where we also use Perforce. Perhaps it's that we
always use "p4 integrate //some/project/version/...
//some/other/project/version/..." which inherently preserves the case of
all of the filenames within the project.
> As Perforce itself is case sensitive (like Git), using of such branches
> is a nightmare: the files get overwritten in checkout order which is
> not always sorted in predictable order. Combined with case-stupidity
> of the file system the working directories sometimes cause "interesting
> time" for unlucky users.
> Luckily (sadly) it is all-opening-in-a-wall shop, so the problem with "fanthom"
> files is rare (it is hard to notice) for most. Which actually makes it more
> frustrating when the real shit happens.
>
> And it will happen to Git as well, especially if development go crossplatform.
> It is not that hard to accidentally rename a file on case-sensitive file system,
> "git add *" it and commit without thinking (that's how most of software
> development happens, come to think of it).
People can accidentally rename files? And still have things work when they
do it on a case-sensitive filesystem?
-Daniel
*This .sig left intentionally blank*
^ permalink raw reply
* Re: Newbie Query
From: Jeff King @ 2009-01-20 23:51 UTC (permalink / raw)
To: Nicolas Morey-Chaisemartin; +Cc: Boyd Stephen Smith Jr., git
In-Reply-To: <49764647.1080606@morey-chaisemartin.com>
On Tue, Jan 20, 2009 at 10:46:47PM +0100, Nicolas Morey-Chaisemartin wrote:
> Well I know there are solutions to convert it to a bare repo.
> I was just wondering if there was a "clean" one which really converts
> the repo to a bare one and not create a copy which is bare.
It has been a long time since I have done this. It used to be that you
could simply "mv foo/.git foo.git" and be done with it. These days I
think you would also need "git config core.bare true". But I haven't
actually tested it recently.
You may also want to tweak other config settings (e.g., bare
repositories do not generally have reflogs turned on, but non-bare do).
-Peff
^ permalink raw reply
* Re: [JGIT PATCH] Fix TreeWalk.idEqual when both trees are missing the path
From: Robin Rosenberg @ 2009-01-20 23:50 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: tomi.pakarinen, git
In-Reply-To: <1232387556-10289-1-git-send-email-spearce@spearce.org>
måndag 19 januari 2009 18:52:36 skrev Shawn O. Pearce:
> The Javadoc of idEqual() says its simply a faster form of
> getObjectId(nthA).equals(getObjectId(nthB)), but its code
> didn't match that definition when both trees didn't exist
> at the current path.
Great. I think we're almost ready for merge. First a few test
cases below. If you think they are ok, I'll add them after the
(simple) merge implementation, or maybe squash.
However there is a conflict with the CanonicalTreeParsers here and
in master. Shawn: Could you resolve that and resubmit patch 5 rebased on main?
-- robin
From 7e8fd54d304bac1fcf08e29c9b8a208c9d0be743 Mon Sep 17 00:00:00 2001
From: Robin Rosenberg <robin.rosenberg@dewire.com>
Date: Mon, 19 Jan 2009 23:09:09 +0100
Subject: [JGIT PATCH] Add a few simple merge test cases
Signed-off-by: Robin Rosenberg <robin.rosenberg@dewire.com>
---
.../spearce/jgit/test/resources/create-second-pack | 13 +++-
...ck-3280af9c07ee18a87705ef50b0cc4cd20266cf12.idx | Bin 0 -> 1296 bytes
...k-3280af9c07ee18a87705ef50b0cc4cd20266cf12.pack | Bin 0 -> 562 bytes
...ck-9fb5b411fe6dfa89cc2e6b89d2bd8e5de02b5745.idx | Bin 1088 -> 1100 bytes
...ck-df2982f284bbabb6bdb59ee3fcc6eb0983e20371.idx | Bin 2696 -> 2976 bytes
...k-df2982f284bbabb6bdb59ee3fcc6eb0983e20371.pack | Bin 5956 -> 5901 bytes
.../org/spearce/jgit/test/resources/packed-refs | 6 +-
.../org/spearce/jgit/lib/RepositoryTestCase.java | 3 +-
.../org/spearce/jgit/merge/SimpleMergeTest.java | 86 ++++++++++++++++++++
9 files changed, 103 insertions(+), 5 deletions(-)
create mode 100644 org.spearce.jgit.test/tst-rsrc/org/spearce/jgit/test/resources/pack-3280af9c07ee18a87705ef50b0cc4cd20266cf12.idx
create mode 100644 org.spearce.jgit.test/tst-rsrc/org/spearce/jgit/test/resources/pack-3280af9c07ee18a87705ef50b0cc4cd20266cf12.pack
create mode 100644 org.spearce.jgit.test/tst/org/spearce/jgit/merge/SimpleMergeTest.java
diff --git a/org.spearce.jgit.test/tst-rsrc/org/spearce/jgit/test/resources/create-second-pack b/org.spearce.jgit.test/tst-rsrc/org/spearce/jgit/test/resources/create-second-pack
index 052877d..5501a67 100755
--- a/org.spearce.jgit.test/tst-rsrc/org/spearce/jgit/test/resources/create-second-pack
+++ b/org.spearce.jgit.test/tst-rsrc/org/spearce/jgit/test/resources/create-second-pack
@@ -138,7 +138,18 @@ done
git repack -d
+git checkout -b f a
+mkdir f
+echo "an eff" >f/f
+git add f/f
+git commit -m "An eff"
+git checkout -b g a
+mkdir f
+echo "an F" >f/f
+git add f/f
+git commit -m "An F"
+git repack -d
git pack-refs --all
-qgit --all master
+gitk --all master
diff --git a/org.spearce.jgit.test/tst-rsrc/org/spearce/jgit/test/resources/pack-3280af9c07ee18a87705ef50b0cc4cd20266cf12.idx b/org.spearce.jgit.test/tst-rsrc/org/spearce/jgit/test/resources/pack-3280af9c07ee18a87705ef50b0cc4cd20266cf12.idx
new file mode 100644
index 0000000000000000000000000000000000000000..300c0cea48c6c4eda2b870b3631355c2137cebb0
GIT binary patch
literal 1296
zcmexg;-AdGz`z8=xBw$if)Wfen|Y98R-n6x!E8Wvw8HE_v#E_afM$;3(J&x74Y2LV
z)Q$1iT(-xv{o%d?ezP~d30WlO{o~}bSuv7YXEk0%y}!Bi+NY5F;<3>Ud#7h~`1YT>
zpf~%nNr$-eG+Xt8#O{s4dXa}k?k(2XVRih3k&*4s=J(gu+%LX=d`sY>$NY6y^vccL
zFK5=6yT6d|<2_P&W-sI8NG8+rIE_yi-_5-HB{Hf?{<GXKDS;Zn=f$-%{*{*K-dyoz
z&(nux&wt#UJNGfeC6_5O>cO{}3Ii^?mL8a&y=G5Sv+Zu7cmBCoC&;S-%NRy4AT9!?
z`vpMy1+YjH0J3?2>?R=nM4az|fajV^sv(TevSnRfJoL#bbLi`ut*5^~(=3sT{r8l`
LdIkBjci#j6ga?3q
literal 0
HcmV?d00001
diff --git a/org.spearce.jgit.test/tst-rsrc/org/spearce/jgit/test/resources/pack-3280af9c07ee18a87705ef50b0cc4cd20266cf12.pack b/org.spearce.jgit.test/tst-rsrc/org/spearce/jgit/test/resources/pack-3280af9c07ee18a87705ef50b0cc4cd20266cf12.pack
new file mode 100644
index 0000000000000000000000000000000000000000..fca3460ed2d263db153ef11a3e559aa47be9efa1
GIT binary patch
literal 562
zcmWG=boORoU|<4bj+wj_bLMu(avd@dV7p)3wYNd_w#iMsjvLl57%x5H=K9t?sp<Ik
zy-ohcJU(|Bgw!K{Gkv_Y)iV2yx4Bxy1{RN(o3pO*q+i>SxK8BLij_wrj#O`T2rS%|
zUidH}#Dz~P_m$6`*V#8S7O30$?L3y2f3D=Xx!-Gc->7BMhQ+Jj+_2mgvGJNrY1Q>E
z`!M4(EkS4a)5PtqUNAR^RLt3ZvSM!F_9Ysop$AQ_o=`fgan!){>Lnvp)w4&gTr#<6
zbJ0Ne><t4`-HQenFC4JBdBNan&7yZ)YUX+jzt0Q2UdLK7$Jmg8snw;eQ&#wAvg(}L
zl3h94ac_R_Q2Cq@G><bvueUMReOX@5{%4zP=e_0sF8g8j-j}{7l$@EFjfI6<?;LqF
z>59_cNnJv1%X-D5F2%7O*}gP)y~fA+sX;sDEEi;$xJmWcT1KEPCI$w^hJhZ*0-ygC
ze!96v!gK9rDgDLw?#EQU4L(uJFlPtvbn}Wi-e-b6e7zqtF>ux~X%pkRgJF9WHdZg*
z5cec;Vs*D^S%j>8VoFLzLPA>7q6xDjVkSi`2@eW9bYaU!C+}OQ8-8rt@>W#!-)0}K
z>7PxQ7@WVWFrc_@!{3{K{@t4O`{?)ne9o9JGxophirXp4u;mKxJX5gi3V?27nZf8F
Z&i6pTbIm2y5XNWOvMw(k`ec<k001O50^|Sy
literal 0
HcmV?d00001
diff --git a/org.spearce.jgit.test/tst-rsrc/org/spearce/jgit/test/resources/pack-9fb5b411fe6dfa89cc2e6b89d2bd8e5de02b5745.idx b/org.spearce.jgit.test/tst-rsrc/org/spearce/jgit/test/resources/pack-9fb5b411fe6dfa89cc2e6b89d2bd8e5de02b5745.idx
index cf58d5baa11824217bb0c5eab7444fb406219885..58b712f6c58e3b99abd536c17c306ef2c37c5238 100644
GIT binary patch
delta 89
zcmV-f0H*)I2+Rlw|8!4d00002kpW(@UZMj;7j}SvqA`rvo4QPkhl4}`;t5v+%)Fm1
v0000CGYgnnQ2?6FEimT$X76fU(jBSR$3y!oeS1unZtru#oQ%-R@OV6B4p%0y
literal 1088
zcmZQzpebMknm&q0!(cQG4Bj-rBVN|fu*k6I#_U}_-R;dTjE^|OnT@$;L<KU;I;(5&
j?04Gxtk_GkE3duSzFw<E`CW}`!gtH2lI+N+ZF^b)CtDqp
diff --git a/org.spearce.jgit.test/tst-rsrc/org/spearce/jgit/test/resources/pack-df2982f284bbabb6bdb59ee3fcc6eb0983e20371.idx b/org.spearce.jgit.test/tst-rsrc/org/spearce/jgit/test/resources/pack-df2982f284bbabb6bdb59ee3fcc6eb0983e20371.idx
index 2579301b8447e4d55480f65ae6c27fe1eb99bf4d..3ff542377406158d8155129ae66fc0b51cba76b8 100644
GIT binary patch
delta 1975
zcmWNSc{~(o9L8VczD?s85wmDmCU<REE7_%?a(yIa3Nhujj!cFI!x(prt4tc2lCznL
z1~tkN*3sk&Z76pK<xDp1`^WqFywCG~f6x28f4y`imWssBXy*$600c{ff@n4!@-K4*
zh&E+cMsP%Ib<EEyNg~_)<6Z=z@v&lR&4t^o{5zON$(63T8`MI*TJpp#7UthPAzfOc
zlyz+6vCLqF@J2mU$LOeTUUpuRf{5UCEp}(q*rmd}hnHb5?x{MYFmbx@5(WhVT^1(X
zog&=aI9Bs}ggMsT%6*iUi?KF(51%v80Z!80O5c~}T}7;?f9zY{pjX?po{6)4p}hSG
zlzCk0IJh3wY`JgCbeOr=uK9Z8%1+SCZoz?POdQGFPH=ox19Pu#;j#r@gY}e1-X<*8
ztg+3zu`%e}u|U$ulM|81z|3FJ^;VmwapsJJkGG1&aa+H3thG=i6+bmj_TbvrmCoc$
zc-yFT6Q)bDggm<Y)Qu}Sk;Arc{@X<mxt;$l9oOn`m^eDS&^agm4)w8xB*YDNdr2e5
zzr&jva1$*1^6a;>iUlNBQ@xh8XZX%<u1CTWMR>|Q75Q-VjND>ulSg@_&y*95g(;{K
znYx3VYzXiYJx$@;d$o8X3qJqlCvZA=6Z=cJTbNfw5c28!rt}-S^usHds;jwag@fn!
zS8qfuunGdNq*dwi%%<rm`)D7`ZQjV}p*eitQyKU7m+ezpO!oV6y>Cu*yRWo>jXdr3
z6wX<(v4{SC3u6eoBJPRHuJ1n~-?w~;6YU70RtZ?l`BxOJe3O$y<L@@*EOt2|nJBV)
zfUb#Gd^$1LmP{*L&3+x))b?@9<J$6el!VHmD5<jYKvqYXVhkqC6DdEi-lUDO3(+Wv
zysbq^*0ZSCE%sTX^|tid<ah2SO>QO4`c1`0C!9^A-bc4mTX$Bn+nyvFuTzbuMG0ln
zofVa_Xv*eWh7K>8D@Y+OxtymFACsb;Z<zmGDU+1EV@QgMDUI$>z_6s6KQMpGh*P2x
z%27#^OUM6a+4}cayIYGz&CXG&j&VP#_wMmIm3ncr?ixZkebb*h_{C1Gzo+d7PKBqZ
zXf?m=%uh@WYm=xCsjJ<8_qDSs*Wf{%&aMs(OYt`2mKrRmy(MQgoz`BBwidoe8+g%>
zkobcw40dFRR|4*|w|g382N~&qdC(MYDm!Y_IGz_ih))>Lb!k=_X1FK){^C8N1mI*<
zI91De^gMY2+U__m!<w|n|H=;R^b0F;_eB{RDW%8X8tu~MH^dlwwr3P&IE7SadfZK<
zluYB#KP`)?6rB5BK_Be<V`0qbm|;XcIsEe@mc?7i+m@1Q@!3n6mimLMn)DB}wZhkF
z?CCk#*}&Q`qbb8hw8X0W$m86h+N)Rpd`>^N<Dfs{NHR?zwsw44sTF9+i*3!martnz
z;^>#D&%cs&@7FU#JcGj8ZA-P)4464)EJ}Fs_D)k8g}UC>EMq;kV-$Q|gjM}DwV=5%
z_}I5Yp9^KKqfTxT?ZP>6k}Q7dUuITBA*)ICD8-dd`I_;E%+O~Mby*TAGD*r4w6g~S
zyexy8`t_fa%a#N#nxE>vw>QeLQ@PFre#!G>iugOlHc^LvgCdJg(<9gojkul{_bC+8
z69>F(>mSLu)wQ-0PS<?<onE#j+{Fc_$SwfBx=-c&b+<bLq$97^G`Pli=B_8pB8Jpi
zexE+1dB$g0Y|%t;idVb;@Q9Lv%z@S6Caz{T2wLNKuRiisi2WQ?nk7CKq+eIDvCy~q
z6`k1HRCDBH2Hk%`K4*Myu93VLnPN4C#S*;PS>JH8KcypkB@5ncRZU=}KH96_q#HEM
zxBm3rCok9UqU83-QUf&xGM<>MR`)V4C58qdSe8{266V7V(zoQctO_q`ni7>qgY|c;
zruth3kkWtR1%_Q7n&w~us~__9)|NEra+0;p|EDD5x~h#dgPA>b>D4-#;)Gq>2)Om;
zC2i5-Qs|itym7H^$-c$DtN9JvzN+O$Twg0&`nQv2$@&Auk>uq*xAD!f@qcim;RdFh
zLfeAS+><K!IQJf5?d=N<HM@@Ka>ZdA*u*!ZgK}+DCT0ksb@vC2=f<9yy(gNkYH3K)
zOziCCA8z3FEF;fH4z4*<GzffNE?M|!j(WY9r%R>R)XPK68OCKk!$nlyoMV??=#U*P
zd1l{D@BH-~wiLU_;hu2WOsS4@L5+XRsR#3Vt1mefM%%CO+Doafhws1rdP-CkQ&T<|
zc5i-n?*k?xbdKrk^XwQwPSfH68UVRT0Hn+SP`UzutS(#>4m8E#SF{O5J^%{-P@e-p
zSrhKn0g${7z@AX3O8^k1z&}d{o-4xzJ!!~`F#%9K0_`dQkj?;z%){^@s0{&-2!y$Z
zAR_`96!f3Lxp<iO9J0}n#R5PPAApBh@UjS4;2VT+0HAyUkS9Q04*gLG>%$>fQgIBn
zhYS+>NDat!0U(?M**mb<M_95O&SRkO0WX5(glYf~KM1ufe25Utqd_JFW;MW>$FQ8#
tIo)0Ce0{H4d`WoglAGiPUdBsD(Nnqf$%y01fxIk6k#j3%Ow8X>?tj#hbMOEF
delta 1424
zcmXAodpOg39LK-zhS}CORBqiywTvYvt=owdD#N2mgzBt@5IKe;vS>-U{M=6D3@eXI
zwN+-U$n|h4?YM<bxg?b9L8d%7UpxPPp6C1ezTfZ9=grgQ67$uSEdjtNDOOS2&*wP<
z#X22l#6LK^By6P^01bB(lW#e;PSHzLL5MFsS6EYh-&h0yQGl2$6OI9ZKBloRJmlyt
ze{7J*6yMO*Ws-V3^%|UaVwI)u%1Ddz=JW!~7IC7T8e?rc0NP}1uY1NtV?1EdM|xcy
zgI!z%v|#|0)+4e111pF>z6?7n@9SSOnEb{qIZ)#f`EwHh*c_ej;~>xNV#BVv(5gKK
zGHOTeXgvgSjNWxdEc$&~PT%n|m&~@bksg~d1VHB`B9#NNuB0%%<Zc$b^ZD@*9P8Ew
zy+^cpcK}e;WJ_dMg)B>rEZf>JD?t&)MIT!LSi>jR&k;TD^m-mx-|W?&ouuH_{8}FZ
z-y+5;tCm&xhlWNPKdTMk$0Te8p}))9gs9&J003I{)a}CPJ+D*kz9(f#+0Il`$?Qw0
zkY?Yw;CwJJR#~hg*2M(rebOEcuY~h7Bv=mAtZ=WkJ0)S@(kBj|l{)UaN7@kN5(t25
z?Wtft+>61=n|DpPyQhqcuO{EfXaj%{?!BetTj&TcofUDT*hIXupNqG<0{?GCUdn;E
zgtJ1=d%exBQxfnkb<^B+!D-d*r%<`(`LiS4iZ+?T<G(r&j^hR;(~&9-(3(a7r&!9%
z9sYY`n#GCso`HF7>tz81x*}NBRm<vkE>+fz$=p&VzlW;pT7_!l<+FJ3q2lR4LYQ$N
z1BYpytK4L46JVGfQn(Q+-x?EVYF)6L<ujY`O7iMJTI2Gyk20v-0r8OoiLyBJIgWY1
zidUXyV?j~4-uwq-vlwQQA19PvXMUl3Con76SDfxzUM|vt=d@-aZqbY#8kTdV0c*_D
zsQQ}wQ(`0$09+{|kOP$+IUI+`rIK}Pd``w+n17g}sC0AwJOFC5oVID3^>140mdLtd
zQvz*x(y2NYDyfeTtW$p!@UU#lgLh7Ah1;J*ZeHFD&#Wj-ZPl^1K|*U&d35X&UkNOt
znGwI-udioN;NhRU?MK-*{iHI8iteI_dQyYh?4x@Cz-K4ZtB4(l>$Sa2gNoUJjMfzt
zPr_owA#^zq-IVF-i#MYXZ~pd2*PkZU<zeQG`b6jeotfwuP;$%dL2P!vz4wc}up;T1
zA8_tlz-@cIf25mo)GYW>RM5mTp7jS5OkzL6lLLtue*b6m5UVVZ(q}fRr#|D_S&<AI
zrfE=i^{Q<x_srsvZJiEmYBaN^VSEY#yUU~-F{-km_w=u)3l2^9O>B)ac?{=n$g~`Y
zU#`3n!<nnA(%RR(Nb&bp=9T;#pAM_}v`XZEbiryOL+f|^iFu|?kRTGpgVz44&N;l3
z##Eqv)DI<0HDXG8p5|VHJs3j{s;_3Kvr-$C_eDxK8h`ksUZlm37dm-WXTuB`wQ(_O
z1B5!2Bmek?WV&;M`Q;)q%rL2?>2VDE`4M|`&Hgy@%xv9p#}r?<iwYz~4pb<W;vB?f
zRR2=*PY)P8>o9g>{$nm&vPZj-hfjy<sD<>TxNOVrP9j!o#|#A8c2o+Dnt|V}z;ouA
zFE)I_FDFS2R-c6Q%Yo?9Ud)}Ib;%TrY80)HMDp_FCoMoFI)y_knjx=H>F;I5y(En>
zJN<jy?d351@!^^kPXmnh8#>YD*&aiDH%NSL0i&2i%u$4cun_t(TE+z<DpRM+f7>Fh
z?~SAtr)g`O&$8&1U0h1vT~cU;GC=Re9<sOUyT0Rzlyn)1V7VEdU<8k4y$JXZTkul8
diff --git a/org.spearce.jgit.test/tst-rsrc/org/spearce/jgit/test/resources/pack-df2982f284bbabb6bdb59ee3fcc6eb0983e20371.pack b/org.spearce.jgit.test/tst-rsrc/org/spearce/jgit/test/resources/pack-df2982f284bbabb6bdb59ee3fcc6eb0983e20371.pack
index bb47c90d93b0b2276fc36b96bc8734085bde6007..ef56d7e941828561e9f6e2cbc46e2d6c9c8d76bf 100644
GIT binary patch
delta 55
zcmV-70LcHuE{!g*s{sV$1%N=4!2w$X;R0W?G6I+l180Cov)>O<2NYiZCg!fo8+@2=
Nzv)s5^+^m_Both>71IC!
delta 110
zcmV-!0FnQVF2pXds{t1D1;B8vj0l7bffm|^TP<Z-I%~PjDwD4PTNd#G&=E?wtTJn>
zFyp3IpgDDT#i6f=vkd~64Hb6+x-!#bo>2e-!WL1JYjAg}b^oces1H#G6hxtEG1~WN
Q{ggPWqc#a04LlG+NkNq^UjP6A
diff --git a/org.spearce.jgit.test/tst-rsrc/org/spearce/jgit/test/resources/packed-refs b/org.spearce.jgit.test/tst-rsrc/org/spearce/jgit/test/resources/packed-refs
index 746bd6b..fd735fe 100644
--- a/org.spearce.jgit.test/tst-rsrc/org/spearce/jgit/test/resources/packed-refs
+++ b/org.spearce.jgit.test/tst-rsrc/org/spearce/jgit/test/resources/packed-refs
@@ -4,8 +4,10 @@
6e1475206e57110fcef4b92320436c1e9872a322 refs/heads/c
f73b95671f326616d66b2afb3bdfcdbbce110b44 refs/heads/d
d0114ab8ac326bab30e3a657a0397578c5a1af88 refs/heads/e
-d86a2aada2f5e7ccf6f11880bfb9ab404e8a8864 refs/heads/pa
+47d3697c3747e8184e0dc479ccbd01e359023577 refs/heads/f
+175d5b80bd9768884d8fced02e9bd33488174396 refs/heads/g
49322bb17d3acc9146f98c97d078513228bbf3c0 refs/heads/master
+d86a2aada2f5e7ccf6f11880bfb9ab404e8a8864 refs/heads/pa
6db9c2ebf75590eef973081736730a9ea169a0c4 refs/tags/A
17768080a2318cd89bba4c8b87834401e2095703 refs/tags/B
^d86a2aada2f5e7ccf6f11880bfb9ab404e8a8864
@@ -27,5 +29,3 @@ bf5123bb77c7b5a379f7de9c1293558e3e24dfb8 refs/tags/B8th
^d86a2aada2f5e7ccf6f11880bfb9ab404e8a8864
dd144af286452bfd6a1ea02b0d3745bcdb555e9d refs/tags/B9th
^d86a2aada2f5e7ccf6f11880bfb9ab404e8a8864
-8bbde7aacf771a9afb6992434f1ae413e010c6d8 refs/tags/spearce-gpg-pub
-^fd608fbe625a2b456d9f15c2b1dc41f252057dd7
diff --git a/org.spearce.jgit.test/tst/org/spearce/jgit/lib/RepositoryTestCase.java b/org.spearce.jgit.test/tst/org/spearce/jgit/lib/RepositoryTestCase.java
index 9e48fde..20348f1 100644
--- a/org.spearce.jgit.test/tst/org/spearce/jgit/lib/RepositoryTestCase.java
+++ b/org.spearce.jgit.test/tst/org/spearce/jgit/lib/RepositoryTestCase.java
@@ -236,7 +236,8 @@ public void run() {
"pack-df2982f284bbabb6bdb59ee3fcc6eb0983e20371",
"pack-9fb5b411fe6dfa89cc2e6b89d2bd8e5de02b5745",
"pack-546ff360fe3488adb20860ce3436a2d6373d2796",
- "pack-e6d07037cbcf13376308a0a995d1fa48f8f76aaa"
+ "pack-e6d07037cbcf13376308a0a995d1fa48f8f76aaa",
+ "pack-3280af9c07ee18a87705ef50b0cc4cd20266cf12"
};
final File packDir = new File(db.getObjectsDirectory(), "pack");
for (int k = 0; k < packs.length; k++) {
diff --git a/org.spearce.jgit.test/tst/org/spearce/jgit/merge/SimpleMergeTest.java b/org.spearce.jgit.test/tst/org/spearce/jgit/merge/SimpleMergeTest.java
new file mode 100644
index 0000000..96064f5
--- /dev/null
+++ b/org.spearce.jgit.test/tst/org/spearce/jgit/merge/SimpleMergeTest.java
@@ -0,0 +1,86 @@
+/*
+ * Copyright (C) 2008, Robin Rosenberg
+ *
+ * All rights reserved.
+ *
+ * Redistribution and use in source and binary forms, with or
+ * without modification, are permitted provided that the following
+ * conditions are met:
+ *
+ * - Redistributions of source code must retain the above copyright
+ * notice, this list of conditions and the following disclaimer.
+ *
+ * - Redistributions in binary form must reproduce the above
+ * copyright notice, this list of conditions and the following
+ * disclaimer in the documentation and/or other materials provided
+ * with the distribution.
+ *
+ * - Neither the name of the Git Development Community nor the
+ * names of its contributors may be used to endorse or promote
+ * products derived from this software without specific prior
+ * written permission.
+ *
+ * THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND
+ * CONTRIBUTORS "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES,
+ * INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES
+ * OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
+ * ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT OWNER OR
+ * CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
+ * SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT
+ * NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES;
+ * LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER
+ * CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT,
+ * STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE)
+ * ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF
+ * ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
+ */
+package org.spearce.jgit.merge;
+
+import java.io.IOException;
+
+import org.spearce.jgit.lib.ObjectId;
+import org.spearce.jgit.lib.RepositoryTestCase;
+
+public class SimpleMergeTest extends RepositoryTestCase {
+
+ public void testOurs() throws IOException {
+ Merger ourMerger = MergeStrategy.OURS.newMerger(db);
+ boolean merge = ourMerger.merge(new ObjectId[] { db.resolve("a"), db.resolve("c") });
+ assertTrue(merge);
+ assertEquals(db.mapTree("a").getId(), ourMerger.getResultTreeId());
+ }
+
+ public void testTheirs() throws IOException {
+ Merger ourMerger = MergeStrategy.THEIRS.newMerger(db);
+ boolean merge = ourMerger.merge(new ObjectId[] { db.resolve("a"), db.resolve("c") });
+ assertTrue(merge);
+ assertEquals(db.mapTree("c").getId(), ourMerger.getResultTreeId());
+ }
+
+ public void testTrivialTwoWay() throws IOException {
+ Merger ourMerger = MergeStrategy.SIMPLE_TWO_WAY_IN_CORE.newMerger(db);
+ boolean merge = ourMerger.merge(new ObjectId[] { db.resolve("a"), db.resolve("c") });
+ assertTrue(merge);
+ assertEquals("02ba32d3649e510002c21651936b7077aa75ffa9",ourMerger.getResultTreeId().name());
+ }
+
+ public void testTrivialTwoWay_disjointhistories() throws IOException {
+ Merger ourMerger = MergeStrategy.SIMPLE_TWO_WAY_IN_CORE.newMerger(db);
+ boolean merge = ourMerger.merge(new ObjectId[] { db.resolve("a"), db.resolve("c~4") });
+ assertTrue(merge);
+ assertEquals("86265c33b19b2be71bdd7b8cb95823f2743d03a8",ourMerger.getResultTreeId().name());
+ }
+
+ public void testTrivialTwoWay_ok() throws IOException {
+ Merger ourMerger = MergeStrategy.SIMPLE_TWO_WAY_IN_CORE.newMerger(db);
+ boolean merge = ourMerger.merge(new ObjectId[] { db.resolve("a^0^0^0"), db.resolve("a^0^0^1") });
+ assertTrue(merge);
+ assertEquals(db.mapTree("a^0^0").getId(), ourMerger.getResultTreeId());
+ }
+
+ public void testTrivialTwoWay_conflict() throws IOException {
+ Merger ourMerger = MergeStrategy.SIMPLE_TWO_WAY_IN_CORE.newMerger(db);
+ boolean merge = ourMerger.merge(new ObjectId[] { db.resolve("f"), db.resolve("g") });
+ assertFalse(merge);
+ }
+}
--
1.6.1.rc3.56.gd0306
^ permalink raw reply related
* Re: An idea: maybe Git should use a lock/unlock file mode for problematic files? [Was: Re: after first git clone of linux kernel repository there are changed files in working dir]
From: Alex Riesen @ 2009-01-20 23:25 UTC (permalink / raw)
To: Daniel Barkalow; +Cc: John Chapman, Hannu Koivisto, rdkrsr, git
In-Reply-To: <alpine.LNX.1.00.0901201651050.19665@iabervon.org>
2009/1/20 Daniel Barkalow <barkalow@iabervon.org>:
> My impression was that this didn't happen in practice, because teams
> would tend to not have two people create the same file at the same time,
> but with different cases, and people interacting with the same file at
> different times would use whatever case it was introduced with.
It will and does happen in practice (annoingly too often even). Not with Git
yet (with Perforce), where people do "branching" by simply copying things
in another directory (perforce world does not know real branches),
renaming files randomly, and putting the new directory back in the
system (or maybe it is the strange tools here which do that - often
it is the first character of a directory or file which gets down- or up-cased).
As Perforce itself is case sensitive (like Git), using of such branches
is a nightmare: the files get overwritten in checkout order which is
not always sorted in predictable order. Combined with case-stupidity
of the file system the working directories sometimes cause "interesting
time" for unlucky users.
Luckily (sadly) it is all-opening-in-a-wall shop, so the problem with "fanthom"
files is rare (it is hard to notice) for most. Which actually makes it more
frustrating when the real shit happens.
And it will happen to Git as well, especially if development go crossplatform.
It is not that hard to accidentally rename a file on case-sensitive file system,
"git add *" it and commit without thinking (that's how most of software
development happens, come to think of it).
^ permalink raw reply
* Re: valgrind patches, was Re: What's cooking in git.git (Jan 2009, #04; Mon, 19)
From: Jeff King @ 2009-01-20 23:24 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Junio C Hamano, git
In-Reply-To: <alpine.DEB.1.00.0901201545570.5159@intel-tinevez-2-302>
On Tue, Jan 20, 2009 at 03:50:28PM +0100, Johannes Schindelin wrote:
> > How will you deal with race conditions between two simultaneously
> > running scripts? I.e., where are you going to put it?
>
> There are no race conditions, as for every git executable, a symbolic link
> is created, pointing to the valgrind.sh script [*1*].
Hmm. I suppose that would work, since every test run is trying to create
the same state.
> Besides, what with valgrind being a memory hog, you'd be nuts to call
> valgrinded scripts simultaneously.
I have to disagree there. I think there are two obvious usage patterns:
- run script $X specifically under valgrind to track down a bug
- run the whole test suite under valgrind occasionally to find
latent bugs that wouldn't otherwise show up
In the latter, you want a pretty beefy box. When I did the original
patches, I ran through the whole test suite under valgrind. It took
several hours on a 6GB quad-core box, using "-j4". I would hate for it
to have taken an entire day. :)
-Peff
^ permalink raw reply
* Re: Git rebase -i failing on cygwin -- git checkout-index says File Exists
From: Johannes Schindelin @ 2009-01-20 23:23 UTC (permalink / raw)
To: Ludvig Strigeus; +Cc: git
In-Reply-To: <4285cd450901201444g711626afm296bf372a100b999@mail.gmail.com>
Hi,
On Tue, 20 Jan 2009, Ludvig Strigeus wrote:
> On Tue, Jan 20, 2009 at 11:20 PM, Ludvig Strigeus <strigeus@gmail.com> wrote:
> >
> > Maybe this command log is useful. I got this while aborting the
> > rebase. Looks like some file creation race condition? Windows doesn't
> > allow files to be deleted while they're open.
>
> I believe I found the source of my problems with git rebase. I had an
> editor open that wanted to reload the files when changed, and this
> seemed to conflict with git's file manipulations. After closing the
> editor, I don't get the mysterious errors anymore.
Yep, that's a Windows issue. Once you keep a file open in an editor, it
cannot be overwritten/deleted.
Live with it, or upgrade to a real operating system :-)
Ciao,
Dscho
^ permalink raw reply
* Re: Git rebase -i failing on cygwin -- git checkout-index says File Exists
From: Ludvig Strigeus @ 2009-01-20 22:44 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git
In-Reply-To: <4285cd450901201420l8929dci25688dc9723c917a@mail.gmail.com>
On Tue, Jan 20, 2009 at 11:20 PM, Ludvig Strigeus <strigeus@gmail.com> wrote:
>
> Maybe this command log is useful. I got this while aborting the
> rebase. Looks like some file creation race condition? Windows doesn't
> allow files to be deleted while they're open.
I believe I found the source of my problems with git rebase. I had an
editor open that wanted to reload the files when changed, and this
seemed to conflict with git's file manipulations. After closing the
editor, I don't get the mysterious errors anymore.
/Ludde
^ permalink raw reply
* Re: An idea: maybe Git should use a lock/unlock file mode for problematic files? [Was: Re: after first git clone of linux kernel repository there are changed files in working dir]
From: John Chapman @ 2009-01-20 21:28 UTC (permalink / raw)
To: Daniel Barkalow; +Cc: Hannu Koivisto, rdkrsr, git
In-Reply-To: <alpine.LNX.1.00.0901201441480.19665@iabervon.org>
On Tue, 2009-01-20 at 15:11 -0500, Daniel Barkalow wrote:
<snip>
>
> The hard part is actually identifying what the user's filesystem has done.
> There's pretty good internal support for git knowing that, for a
> particular entry, the filesystem should not be consulted for information.
> I don't think anyone's come up with a suitably cross-platform and
> automatic way to figure out what's happened when git tries to write to a
> particular filename and the system decides it is the same as some other
> filename or it decides to use a different filename instead.
This would only need to interact with the git status command, wouldn't
it?
>
> Of course, it is reasonably likely that a project whose files can't all be
> checked out can't be dealt with anyway on that platform (IIRC, the Linux
> kernel build system assumes that it can create both .S and .s files, so it
> won't build on FAT). So nobody's been sufficiently motivated to try to
> implement a fix.
I doubt the kernel builds on windows, but this would allow a windows
user to modify such files, perhaps in preparation for a patch that does
allow the kernel to be built on windows?
(Of course, we're using the kernel here as an example, right? Nobody
would be insane as to want to use windows for that!)
See, a very annoying thing about windows is that it is quite simple for
a team to commit two files that differ by case alone to a git
repository.
Was just an idea, really.
^ permalink raw reply
* Re: [PATCH] Rename detection: Avoid repeated filespec population
From: Jeff King @ 2009-01-20 21:27 UTC (permalink / raw)
To: Björn Steinbrink; +Cc: Junio C Hamano, Linus Torvalds, git
In-Reply-To: <20090120155957.GA23237@atjola.homenet>
On Tue, Jan 20, 2009 at 04:59:57PM +0100, Björn Steinbrink wrote:
> In diffcore_rename, we assume that the blob contents in the filespec
> aren't required anymore after estimate_similarity has been called and thus
> we free it. But estimate_similarity might return early when the file sizes
> differ too much. In that case, cnt_data is never set and the next call to
> estimate_similarity will populate the filespec again, eventually rereading
> the same blob over and over again.
>
> To fix that, we first get the blob sizes and only when the blob contents
> are actually required, and when cnt_data will be set, the full filespec is
> populated, once.
I think this is a sane thing to do, and obviously your numbers show an
impressive improvement.
However, I found your explanation a little confusing. Yes, repeatedly
loading those blobs is a problem. But what this is really about is that
estimate_similarity has two levels of checks: cheap checks involving the
size, and expensive checks involving the content. What is happening now
is that we are doing extra work for the expensive checks, even if the
cheap checks are going to let us fail early.
And that's just stupid, and a waste of processing time even if we
_don't_ ever look at the same filespec again.
But what makes it even worse is that we have a system in place to cache
the expensive work, but because we only do part of it, we don't bother
to cache the result. And that's what your patch description is about.
So I think your patch is absolutely the right thing to do. But I think
from the commit message it isn't clear that it would not be equally
correct to follow through on generating cnt_data instead of an early
return (which _isn't_ right, because you might not need to generate
cnt_data at all).
> This actually affects the copy detection way more than the pure
> rename detection, due to the larger number of candidates, but it's the
> same code, and I only realized that when I reran the stuff to get some
> numbers to show off. ;-)
I have a pathological real-world rename test case from a long time ago.
It's so awful on rename because almost the whole repo was reorganized,
but almost every path got its content adjusted, too. I was hoping it
would be better with your patch, but it isn't: as it turns out, it is
_too_ uniform. The cheap size checks don't work because all of the files
are almost the same size (they're all jpgs from a camera).
But I think for non-pathological cases, your improvement makes sense.
-Peff
^ permalink raw reply
* Re: Newbie Query
From: Boyd Stephen Smith Jr. @ 2009-01-20 22:24 UTC (permalink / raw)
To: devel; +Cc: git
In-Reply-To: <49764647.1080606@morey-chaisemartin.com>
[-- Attachment #1: Type: text/plain, Size: 1801 bytes --]
On Tuesday 2009 January 20 15:46:47 Nicolas Morey-Chaisemartin wrote:
>Boyd Stephen Smith Jr. a écrit :
>> On Tuesday 2009 January 20 15:07:55 Nicolas Morey-Chaisemartin wrote:
>>> I did the rookie mistkae on the central server to create the main
>>> reposity in non-bare mode.
>>> Is there a cleaner way to convert a non-bare git repo into a bare repo
>>> than cloning it?
No.
>>> My repo have a lot of remote branch registered, and cloning them to a
>>> new bare repo mean I'll have to add all those remote branches again
>>> (except if there is another trick here I don't know about).
>>
>> Well, if you can make sure no one is pushing into the repo for a bit:
>> clone it and replace the original with a symlink to new, bare one. Your
>> clients will be able to use the same URL, so they should be happy. (I
>> haven't tried this, but it should work.)
>
>Well I know there are solutions to convert it to a bare repo.
>I was just wondering if there was a "clean" one which really converts
>the repo to a bare one and not create a copy which is bare.
The clone *is* a way to convert, with the added advantage of not trashing the
original during the conversion, by putting the results in a different
location. In fact, it's probably *cleaner* than any convert-in-place.
>I don't know how bare/non-bare is managed but I guess both types of repo
>are not differing by much, so it'd be great to have a function to
>convert from one to another.
I couldn't tell you all the differences, but I don't think there are many
either.
--
Boyd Stephen Smith Jr. ,= ,-_-. =.
bss@iguanasuicide.net ((_/)o o(\_))
ICQ: 514984 YM/AIM: DaTwinkDaddy `-'(. .)`-'
http://iguanasuicide.net/ \_/
[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Re: Git rebase -i failing on cygwin -- git checkout-index says File Exists
From: Ludvig Strigeus @ 2009-01-20 22:20 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git
In-Reply-To: <alpine.DEB.1.00.0901202212470.3586@pacific.mpi-cbg.de>
Hi!
On Tue, Jan 20, 2009 at 10:16 PM, Johannes Schindelin
<Johannes.Schindelin@gmx.de> wrote:
>
> Having said that, I often had that case with interactive rebase, because
> I had an untracked file lying around (in your case util/stringfuncs.cpp)
> that was tracked in the version I was trying to rebase onto, but it
> stopped right there, even on msysGit.
util/stringfuncs.cpp is not an untracked file, though. It's a part of
my repo. Also 'git status' shows that no files are modified. If it was
an untracked file, 'git status' would have said so.
>
> Hopefully you can investigate the scenario more, by "git rebase --abort",
> and then running the rebase -i again, but with GIT_TRACE=1.
>
Here is the trace output. Notice how it prints errors about two files this time.
$ GIT_TRACE=1 git rebase -i 4a1552c81b622f85b0e9170c6fd7a22b4a3e633c
trace: exec: 'git-rebase' '-i' '4a1552c81b622f85b0e9170c6fd7a22b4a3e633c'
trace: built-in: git 'rev-parse' '--git-dir'
trace: built-in: git 'rev-parse' '--is-inside-work-tree'
trace: built-in: git 'rev-parse' '--show-cdup'
trace: built-in: git 'rev-parse' '--parseopt' '--' '-i'
'4a1552c81b622f85b0e9170c6fd7a22b4a3e633c'
trace: built-in: git 'rev-parse' '--git-dir'
trace: built-in: git 'rev-parse' '--show-cdup'
trace: built-in: git 'rev-parse' '--is-inside-work-tree'
trace: exec: 'git-var' 'GIT_COMMITTER_IDENT'
trace: built-in: git 'rev-parse' '--verify' 'HEAD'
trace: built-in: git 'update-index' '--ignore-submodules' '--refresh'
trace: built-in: git 'diff-files' '--quiet' '--ignore-submodules'
trace: built-in: git 'diff-index' '--cached' '--quiet' 'HEAD'
'--ignore-submodules' '--'
trace: built-in: git 'rev-parse' '--verify'
'4a1552c81b622f85b0e9170c6fd7a22b4a3e633c'
trace: built-in: git 'rev-parse' '--verify' 'HEAD'
trace: built-in: git 'rev-parse' '--short'
'4a1552c81b622f85b0e9170c6fd7a22b4a3e633c'
trace: built-in: git 'rev-parse' '--short'
'7a70781d089d98f0de606515d1041230cef9b184'
trace: built-in: git 'rev-parse' '--short'
'4a1552c81b622f85b0e9170c6fd7a22b4a3e633c'
trace: built-in: git 'rev-list' '--no-merges' '--cherry-pick'
'--pretty=oneline' '--abbrev-commit' '--abbrev=7' '--rever
se' '--left-right' '--topo-order'
'4a1552c81b622f85b0e9170c6fd7a22b4a3e633c...7a70781d089d98f0de606515d1041230cef9b184'
trace: built-in: git 'update-ref' 'ORIG_HEAD'
'7a70781d089d98f0de606515d1041230cef9b184'
trace: built-in: git 'rev-parse' '--verify' '4965936^'
trace: built-in: git 'rev-parse' '--verify' 'HEAD'
trace: built-in: git 'reset' '--hard' '4965936'
trace: run_command: 'read-tree' '-v' '-u' '--reset'
'49659367ed932a691749fb4c6b93e38b2a85e9e1'
trace: exec: 'git' 'read-tree' '-v' '-u' '--reset'
'49659367ed932a691749fb4c6b93e38b2a85e9e1'
trace: built-in: git 'read-tree' '-v' '-u' '--reset'
'49659367ed932a691749fb4c6b93e38b2a85e9e1'
error: git checkout-index: unable to create file
util/boink_unittest.cpp (File exists)
error: git checkout-index: unable to create file util/stringfuncs.cpp
(File exists)
fatal: Could not reset index file to revision '4965936'.
trace: built-in: git 'rev-parse' '--short' '4965936'
trace: built-in: git 'rev-parse' '--verify' 'd9c7ac9^'
trace: built-in: git 'rev-parse' '--verify' 'HEAD'
trace: built-in: git 'cherry-pick' 'd9c7ac9'
error: Entry 'util/boink-py.cc' not uptodate. Cannot merge.
fatal: merging of trees 0c27b10e163f00655486976896d096302b0f5c21 and
7c7dfd93d678cfc564649738d45260e0b5d9f5a7 failed
trace: built-in: git 'rev-list' '--parents' '-1' 'd9c7ac9'
trace: built-in: git 'diff-tree' '-p' 'd9c7ac9^'\!''
trace: built-in: git 'cat-file' 'commit' 'd9c7ac9'
trace: built-in: git 'config' 'i18n.commitencoding'
trace: built-in: git 'show' '-s' '--pretty=raw' '--encoding=UTF-8'
'd9c7ac9' '--'
trace: built-in: git 'rerere'
Could not apply d9c7ac9... Various reorganizations.
It doesn't really tell me much.
Maybe this command log is useful. I got this while aborting the
rebase. Looks like some file creation race condition? Windows doesn't
allow files to be deleted while they're open.
$ git rebase --abort
error: git checkout-index: unable to create file
util/boink_unittest.cpp (File exists)
fatal: Could not reset index file to revision
'7a70781d089d98f0de606515d1041230cef9b184'.
$ git rebase --abort
error: git checkout-index: unable to create file util/stringfuncs.h
(File exists)
fatal: Could not reset index file to revision
'7a70781d089d98f0de606515d1041230cef9b184'.
$ git rebase --abort
error: git checkout-index: unable to create file
util/boink_unittest.cpp (File exists)
error: git checkout-index: unable to create file util/common.h
(Permission denied)
fatal: Could not reset index file to revision
'7a70781d089d98f0de606515d1041230cef9b184'.
$ git rebase --abort
(this time it worked)
Thanks,
Ludde
^ permalink raw reply
* Re: Git rebase -i failing on cygwin -- git checkout-index says File Exists
From: Johannes Schindelin @ 2009-01-20 21:16 UTC (permalink / raw)
To: Ludvig Strigeus; +Cc: git
In-Reply-To: <4285cd450901201209i792195dfmdec1fb14d627b25e@mail.gmail.com>
Hi,
On Tue, 20 Jan 2009, Ludvig Strigeus wrote:
> I'm having some weird problem with Git on Cygwin on Windows XP. I start
> with a totally clean repo, and then run interactive rebase to edit a
> historical commit. I exit the editor without doing anything (I get
> similar issues if I modify stuff inside the editor).
>
> $ git st
> # On branch master
> nothing to commit (working directory clean)
>
> $ git rebase -i 4a1552c81b622f85b0e9170c6fd7a22b4a3e633c
> error: git checkout-index: unable to create file util/stringfuncs.cpp
> (File exists)
This is the error that should stop the whole thing.
> fatal: Could not reset index file to revision '4965936'.
> error: Entry 'util/boink-py.cc' not uptodate. Cannot merge.
> fatal: merging of trees 0c27b10e163f00655486976896d096302b0f5c21 and
> 7c7dfd93d678cfc564649738d45260e0b5d9f5a7 failed
> Could not apply d9c7ac9... Various reorganizations.
But here, it should not have continued.
Having said that, I often had that case with interactive rebase, because
I had an untracked file lying around (in your case util/stringfuncs.cpp)
that was tracked in the version I was trying to rebase onto, but it
stopped right there, even on msysGit.
Hopefully you can investigate the scenario more, by "git rebase --abort",
and then running the rebase -i again, but with GIT_TRACE=1.
Ciao,
Dscho
^ permalink raw reply
* Re: Newbie Query
From: Boyd Stephen Smith Jr. @ 2009-01-20 21:34 UTC (permalink / raw)
To: devel; +Cc: git
In-Reply-To: <49763D2B.1000607@morey-chaisemartin.com>
[-- Attachment #1: Type: text/plain, Size: 1021 bytes --]
On Tuesday 2009 January 20 15:07:55 Nicolas Morey-Chaisemartin wrote:
>I did the rookie mistkae on the central server to create the main
>reposity in non-bare mode. So i need to checkout the HEAD revision each
>time I push.
>Is there a cleaner way to convert a non-bare git repo into a bare repo
>than cloning it?
>My repo have a lot of remote branch registered, and cloning them to a
>new bare repo mean I'll have to add all those remote branches again
>(except if there is another trick here I don't know about).
Well, if you can make sure no one is pushing into the repo for a bit: clone it
and replace the original with a symlink to new, bare one. Your clients will
be able to use the same URL, so they should be happy. (I haven't tried this,
but it should work.)
--
Boyd Stephen Smith Jr. ,= ,-_-. =.
bss@iguanasuicide.net ((_/)o o(\_))
ICQ: 514984 YM/AIM: DaTwinkDaddy `-'(. .)`-'
http://iguanasuicide.net/ \_/
[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Re: Newbie Query
From: Nicolas Morey-Chaisemartin @ 2009-01-20 21:46 UTC (permalink / raw)
To: Boyd Stephen Smith Jr.; +Cc: git
In-Reply-To: <200901201534.16571.bss@iguanasuicide.net>
Boyd Stephen Smith Jr. a écrit :
> On Tuesday 2009 January 20 15:07:55 Nicolas Morey-Chaisemartin wrote:
>
>> I did the rookie mistkae on the central server to create the main
>> reposity in non-bare mode. So i need to checkout the HEAD revision each
>> time I push.
>> Is there a cleaner way to convert a non-bare git repo into a bare repo
>> than cloning it?
>> My repo have a lot of remote branch registered, and cloning them to a
>> new bare repo mean I'll have to add all those remote branches again
>> (except if there is another trick here I don't know about).
>>
>
> Well, if you can make sure no one is pushing into the repo for a bit: clone it
> and replace the original with a symlink to new, bare one. Your clients will
> be able to use the same URL, so they should be happy. (I haven't tried this,
> but it should work.)
>
Well I know there are solutions to convert it to a bare repo.
I was just wondering if there was a "clean" one which really converts
the repo to a bare one and not create a copy which is bare.
I don't know how bare/non-bare is managed but I guess both types of repo
are not differing by much, so it'd be great to have a function to
convert from one to another.
^ permalink raw reply
* Re: [PATCH] Rename detection: Avoid repeated filespec population
From: Jeff King @ 2009-01-20 22:12 UTC (permalink / raw)
To: Björn Steinbrink; +Cc: Junio C Hamano, Linus Torvalds, git
In-Reply-To: <20090120212723.GA10967@coredump.intra.peff.net>
On Tue, Jan 20, 2009 at 04:27:23PM -0500, Jeff King wrote:
> I have a pathological real-world rename test case from a long time ago.
> It's so awful on rename because almost the whole repo was reorganized,
> but almost every path got its content adjusted, too. I was hoping it
> would be better with your patch, but it isn't: as it turns out, it is
> _too_ uniform. The cheap size checks don't work because all of the files
> are almost the same size (they're all jpgs from a camera).
Nevermind, I'm stupid. Your patch _does_ yield a significant improvement
for my test case. I was accidentally comparing your patch to some of my
previous optimization attempts, not to vanilla git.
Without your patch, I get:
$ time git show -l0 06d28867 >/dev/null
841.88user 146.95system 17:18.99elapsed 95%CPU (0avgtext+0avgdata 0maxresident)k
2476880inputs+0outputs (19372major+27092797minor)pagefaults 0swaps
With it, I get:
$ time git show -l0 06d28867 >/dev/null
100.51user 5.76system 2:31.07elapsed 70%CPU (0avgtext+0avgdata 0maxresident)k
2020176inputs+0outputs (15771major+836127minor)pagefaults 0swaps
So much much better.
-Peff
^ permalink raw reply
* Re: An idea: maybe Git should use a lock/unlock file mode for problematic files? [Was: Re: after first git clone of linux kernel repository there are changed files in working dir]
From: Daniel Barkalow @ 2009-01-20 22:08 UTC (permalink / raw)
To: John Chapman; +Cc: Hannu Koivisto, rdkrsr, git
In-Reply-To: <1232486929.4179.7.camel@therock.nsw.bigpond.net.au>
On Wed, 21 Jan 2009, John Chapman wrote:
> On Tue, 2009-01-20 at 15:11 -0500, Daniel Barkalow wrote:
> <snip>
> >
> > The hard part is actually identifying what the user's filesystem has done.
> > There's pretty good internal support for git knowing that, for a
> > particular entry, the filesystem should not be consulted for information.
> > I don't think anyone's come up with a suitably cross-platform and
> > automatic way to figure out what's happened when git tries to write to a
> > particular filename and the system decides it is the same as some other
> > filename or it decides to use a different filename instead.
>
> This would only need to interact with the git status command, wouldn't
> it?
The information is needed in a bunch of commands (diff and add, for
example), but I believe that's already taken care on. The problem is
getting it set automatically instead of having git not notice that the
filesystem isn't doing what it expects.
> > Of course, it is reasonably likely that a project whose files can't all be
> > checked out can't be dealt with anyway on that platform (IIRC, the Linux
> > kernel build system assumes that it can create both .S and .s files, so it
> > won't build on FAT). So nobody's been sufficiently motivated to try to
> > implement a fix.
>
> I doubt the kernel builds on windows, but this would allow a windows
> user to modify such files, perhaps in preparation for a patch that does
> allow the kernel to be built on windows?
> (Of course, we're using the kernel here as an example, right? Nobody
> would be insane as to want to use windows for that!)
>
> See, a very annoying thing about windows is that it is quite simple for
> a team to commit two files that differ by case alone to a git
> repository.
My impression was that this didn't happen in practice, because teams
would tend to not have two people create the same file at the same time,
but with different cases, and people interacting with the same file at
different times would use whatever case it was introduced with.
I think I'd only heard about problems for people who were using
filesystems with different properties than what the rest of the developers
on the project were using.
But I've only ever worked on projects that expect case-sensitivity, and
mostly on projects that have a standard style that prevents duplication.
-Daniel
*This .sig left intentionally blank*
^ permalink raw reply
* Re: gitk doesn't work w/o sudo.
From: Johannes Schindelin @ 2009-01-20 21:10 UTC (permalink / raw)
To: Dilip M; +Cc: Brian Foster, Reece Dunn, git list
In-Reply-To: <c94f8e120901201020g32fad692p214fdf1640a4796f@mail.gmail.com>
Hi,
On Tue, 20 Jan 2009, Dilip M wrote:
> On Tue, Jan 20, 2009 at 10:46 PM, Johannes Schindelin
> <Johannes.Schindelin@gmx.de> wrote:
> > 'd try running it with strace, and then search the output for stat()
> > calls involving <something>/.git.
>
> Seems like we are almost there....here is the log..
>
> dm-laptop:~/repos/atria> grep gitk /tmp/gitk_1.log
> execve("/usr/bin/gitk", ["/usr/bin/gitk"], [/* 37 vars */]) = 0
> open("/usr/bin/gitk", O_RDONLY) = 3
> execve("/usr/bin/wish8.4", ["/usr/bin/wish8.4", "/usr/bin/gitk",
> "--"], [/* 37 vars */]) = 0
> stat("/usr/bin/gitk", {st_mode=S_IFREG|0755, st_size=237778, ...}) = 0
> open("/usr/bin/gitk", O_RDONLY) = 6
> lstat("/usr/share/gitk", {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0
> lstat("/usr/share/gitk/lib", {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0
> lstat("/usr/share/gitk/lib/msgs", {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0
> access("/usr/share/gitk/lib/msgs/en_in.msg", F_OK) = -1 ENOENT (No
> such file or directory) <======
> lstat("/usr/share/gitk", {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0
> lstat("/usr/share/gitk/lib", {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0
> lstat("/usr/share/gitk/lib/msgs", {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0
> access("/usr/share/gitk/lib/msgs/en.msg", F_OK) = -1 ENOENT (No such
> file or directory) <======
> stat("/home/dm/.gitk", {st_mode=S_IFREG|0644, st_size=683, ...}) = 0
> open("/home/dm/.gitk", O_RDONLY) = 6
> writev(5, [{"\22\0\7\0\16\0@\3\'\0\0\0\37\0\0\0\10NG\0\4\0\0\0gitk\20"...,
> 48}], 1) = 48
> writev(5, [{"\22\0\7\0\16\0@\3(\1\0\0\37\1\0\0\10AME\4\0\0\0gitk\22"...,
> 112}], 1) = 112
>
> dm-laptop:~/repos/atria> ls -l /usr/share/gitk/lib/msgs/en_in.msg
> ls: cannot access /usr/share/gitk/lib/msgs/en_in.msg: No such file or directory
>
> But how is it working when I do 'sudo'..
Let's find out. You can run the strace with sudo, too.
I bet it uses another git.
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH] diff: Support diff.color-words config option
From: Johannes Schindelin @ 2009-01-20 21:08 UTC (permalink / raw)
To: Markus Heidelberg
Cc: Junio C Hamano, Boyd Stephen Smith Jr., Santi Béjar,
Thomas Rast, git, Teemu Likonen
In-Reply-To: <200901201842.24000.markus.heidelberg@web.de>
Hi,
On Tue, 20 Jan 2009, Markus Heidelberg wrote:
> Junio C Hamano, 20.01.2009:
> > "Boyd Stephen Smith Jr." <bss@iguanasuicide.net> writes:
> >
> > > When diff is invoked with --color-words (w/o =regex), use the regular
> > > expression the user has configured as diff.color-words.
> > >
> > > diff drivers configured via attributes take precedence over the
> > > diff.color-words setting. If the user wants to change them, they have
> > > their own configuration variables.
> >
> > This needs an entry in Documentation/config.txt
> >
> > None of the existing configuration variables defined use hyphens in
> > multi-word variable names.
>
> Except for diff.suppress-blank-empty
> Should it be converted or is it intention to reflect GNU diff's option?
Grumble. It's in v1.6.1-rc1~348, so we cannot just go ahead and fix it.
My preference would be to convert it _except_ that the old name should
still work. But it should not be advertized.
Ciao,
Dscho "who loves consistency, and knows new users appreciate it, too"
-- snipsnap --
[PATCH] Rename diff.suppress-blank-empty to diff.suppressBlankEmpty
All the other config variables use CamelCase. This config variable should
not be an exception.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
---
Documentation/config.txt | 2 +-
diff.c | 4 +++-
t/t4029-diff-trailing-space.sh | 8 ++++----
3 files changed, 8 insertions(+), 6 deletions(-)
diff --git a/Documentation/config.txt b/Documentation/config.txt
index c92e7e6..4f0a0b1 100644
--- a/Documentation/config.txt
+++ b/Documentation/config.txt
@@ -652,7 +652,7 @@ diff.renames::
will enable basic rename detection. If set to "copies" or
"copy", it will detect copies, as well.
-diff.suppress-blank-empty::
+diff.suppressBlankEmpty::
A boolean to inhibit the standard behavior of printing a space
before each empty output line. Defaults to false.
diff --git a/diff.c b/diff.c
index c6a992d..0100b59 100644
--- a/diff.c
+++ b/diff.c
@@ -118,7 +118,9 @@ int git_diff_basic_config(const char *var, const char *value, void *cb)
}
/* like GNU diff's --suppress-blank-empty option */
- if (!strcmp(var, "diff.suppress-blank-empty")) {
+ if (!strcmp(var, "diff.suppressblankempty") ||
+ /* for backwards compatibility */
+ !strcmp(var, "diff.suppress-blank-empty")) {
diff_suppress_blank_empty = git_config_bool(var, value);
return 0;
}
diff --git a/t/t4029-diff-trailing-space.sh b/t/t4029-diff-trailing-space.sh
index 4ca65e0..9ddbbcd 100755
--- a/t/t4029-diff-trailing-space.sh
+++ b/t/t4029-diff-trailing-space.sh
@@ -2,7 +2,7 @@
#
# Copyright (c) Jim Meyering
#
-test_description='diff honors config option, diff.suppress-blank-empty'
+test_description='diff honors config option, diff.suppressBlankEmpty'
. ./test-lib.sh
@@ -24,14 +24,14 @@ test_expect_success \
git add f &&
git commit -q -m. f &&
printf "\ny\n" > f &&
- git config --bool diff.suppress-blank-empty true &&
+ git config --bool diff.suppressBlankEmpty true &&
git diff f > actual &&
test_cmp exp actual &&
perl -i.bak -p -e "s/^\$/ /" exp &&
- git config --bool diff.suppress-blank-empty false &&
+ git config --bool diff.suppressBlankEmpty false &&
git diff f > actual &&
test_cmp exp actual &&
- git config --bool --unset diff.suppress-blank-empty &&
+ git config --bool --unset diff.suppressBlankEmpty &&
git diff f > actual &&
test_cmp exp actual
'
--
1.6.1.439.g22f77c
^ permalink raw reply related
* Re: Newbie Query
From: Nicolas Morey-Chaisemartin @ 2009-01-20 21:07 UTC (permalink / raw)
To: Reece Dunn; +Cc: Git List
In-Reply-To: <3f4fd2640901201217x22262655w115cc2a25e32865e@mail.gmail.com>
Reece Dunn a écrit :
>
> If you are committing the files to a shared public repository (e.g. a
> central repository, or build server repository), a pussible approach
> is to create that as a "bare" repository (one with just the contents
> of the .git folder - i.e. it does not have any files checked out). You
> can do this by running:
> git clone --bare source/git/path/project project.git
> you can then clone from this:
> git clone my/shared/project.git
> and push any changes to it as normal.
>
>
Hi,
I did the rookie mistkae on the central server to create the main
reposity in non-bare mode. So i need to checkout the HEAD revision each
time I push.
Is there a cleaner way to convert a non-bare git repo into a bare repo
than cloning it?
My repo have a lot of remote branch registered, and cloning them to a
new bare repo mean I'll have to add all those remote branches again
(except if there is another trick here I don't know about).
Regards
Nicolas
^ permalink raw reply
* Re: [PATCH] diff: Support diff.color-words config option
From: Johannes Schindelin @ 2009-01-20 21:02 UTC (permalink / raw)
To: Junio C Hamano
Cc: Boyd Stephen Smith Jr., Santi Béjar, Thomas Rast, git,
Teemu Likonen
In-Reply-To: <7vk58pk9k5.fsf@gitster.siamese.dyndns.org>
Hi,
On Tue, 20 Jan 2009, Junio C Hamano wrote:
> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
>
> >> By the way, wouldn't it make sense to optimize the precontext of that
> >> hunk by doing _something_ like:
> >>
> >> if (!o->word_regex && strcmp(one->path, two->path))
> >> o->word_regex = userdiff_word_regex(two);
> >>
> >> "Something like" comes from special cases like /dev/null for new/deleted
> >> files, etc.
> >
> > You mean to avoid the cost of initializing the regex in case one and the
> > same file is diffed against itself?
>
> No.
>
> What I meant is much simpler than that.
>
> If one and two are the same filename, and earlier gitattributes lookup for
> the path already failed to produce any when you checked one, isn't it very
> likely that the gitattributes lookup for two would fail the same way to
> produce any result?
Oh, I see!
Thanks,
Dscho
^ permalink raw reply
* Re: [TOY PATCH] git-resurrect: find traces of a branch name and resurrect it
From: Boyd Stephen Smith Jr. @ 2009-01-20 20:50 UTC (permalink / raw)
To: Thomas Rast; +Cc: git
In-Reply-To: <200901201057.18127.bss@iguanasuicide.net>
[-- Attachment #1: Type: text/plain, Size: 961 bytes --]
On Tuesday 2009 January 20 10:57:17 Boyd Stephen Smith Jr. wrote:
>On Tuesday 2009 January 20 03:01:50 Thomas Rast wrote:
>>It was really intended as a toy patch, but if people find it useful
>>(Boyd?) I can add the rest of the options so that all searches can be
>>chosen independently, and shape it as a "real" contrib patch.
>
>I'll test it out later today and get back to you.
In my particular case, it wasn't useful without the -m option, but I
understand why it is not the default.
I think it could be quite nice; "undelete"-type commands are generally
well-received by users and when run against reflogs alone, that's what the
command is.
It's useful enough to me that I'd love to see it mainlined.
--
Boyd Stephen Smith Jr. ,= ,-_-. =.
bss@iguanasuicide.net ((_/)o o(\_))
ICQ: 514984 YM/AIM: DaTwinkDaddy `-'(. .)`-'
http://iguanasuicide.net/ \_/
[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Re: Newbie Query
From: Tomas Carnecky @ 2009-01-20 20:00 UTC (permalink / raw)
To: Chris Willard; +Cc: Git List
In-Reply-To: <20090120191952.GA25322@uts.thewillards.local>
On 01/20/2009 08:19 PM, Chris Willard wrote:
> Hello All,
>
> I am having a go at using git and need a bit of help.
>
> I have git installed on my laptop and on my pc. I created some files
> on the pc then used git close via ssh to put them on my laptop - all
> OK so far!
>
> I then modified the files, added them, commited the changes and then
> used git push to put them on the PC - still no problems.
>
> Both systems show the commits but the PC does not have the latest
> version of the files. Git status on the PC shows the file as changed
> but commiting give an error when pushing from the laptop.
>
> I assume that I need to run a command on the PC to get both systems
> the same. Is it a reset or something else?
http://git.or.cz/gitwiki/GitFaq#non-bare
tom
^ permalink raw reply
* Re: git fast-import problem converting from CVS with git 1.6.1 and cvs2svn 2.2.0
From: Daniel Barkalow @ 2009-01-20 20:29 UTC (permalink / raw)
To: Kelly F. Hickel; +Cc: git
In-Reply-To: <63BEA5E623E09F4D92233FB12A9F794302BC6851@emailmn.mqsoftware.com>
On Tue, 20 Jan 2009, Kelly F. Hickel wrote:
> Hello all,
>
> Back in June I had done a test convert of our CVS repo using git 1.5.5.1
> and cvs2svn 2.2.0 that went reasonably well (although it takes nearly a
> week to finish!). Recently I wanted to try again with the latest
> versions of git and cvs2svn.
>
> When I get to the final stage (running git fast-import to build the
> converted repo), I get the following output:
> cat ../cvs2svn-tmp/git-blob.dat ../cvs2svn-tmp/git-dump.dat | git
> fast-import
> fatal: Unsupported command: '.
> fast-import: dumping crash report to .git/fast_import_crash_19097
>
> The crash is 18MB and I'd rather not post it, but the only bits that
> seem somewhat interesting are:
> fast-import crash report:
> fast-import process: 19097
> parent process : 19095
> at Mon Jan 19 11:44:42 2009
>
> fatal: Unsupported command: '.
>
> Most Recent Commands Before Crash
> ---------------------------------
> (...)
> reset refs/tags/T_9772
> from :1000007127
> reset refs/heads/TAG.FIXUP
>
> commit refs/heads/TAG.FIXUP
> mark :1000007128
> committer cvs2svn <cvs2svn> 1002043747 +0000
> data 88
> * '.
>
>
> Has anyone got any ideas how to resolve this?
Can you find that part of the input? I wouldn't be too surprised if
something were giving the wrong length in a data command, causing it to
either eat another data command and end up in the data or to use
not-quite-all of the data and end up near the end of the data.
-Daniel
*This .sig left intentionally blank*
^ permalink raw reply
* Re: [PATCH] diff: Support diff.color-words config option
From: Junio C Hamano @ 2009-01-20 20:27 UTC (permalink / raw)
To: Johannes Schindelin
Cc: Boyd Stephen Smith Jr., Santi Béjar, Thomas Rast, git,
Teemu Likonen
In-Reply-To: <alpine.DEB.1.00.0901201819490.5159@intel-tinevez-2-302>
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
>> By the way, wouldn't it make sense to optimize the precontext of that
>> hunk by doing _something_ like:
>>
>> if (!o->word_regex && strcmp(one->path, two->path))
>> o->word_regex = userdiff_word_regex(two);
>>
>> "Something like" comes from special cases like /dev/null for new/deleted
>> files, etc.
>
> You mean to avoid the cost of initializing the regex in case one and the
> same file is diffed against itself?
No.
What I meant is much simpler than that.
If one and two are the same filename, and earlier gitattributes lookup for
the path already failed to produce any when you checked one, isn't it very
likely that the gitattributes lookup for two would fail the same way to
produce any result?
^ permalink raw reply
* Re: Newbie Query
From: Reece Dunn @ 2009-01-20 20:17 UTC (permalink / raw)
To: Chris Willard; +Cc: Git List
In-Reply-To: <20090120191952.GA25322@uts.thewillards.local>
2009/1/20 Chris Willard <chris@thewillards.co.uk>:
> Hello All,
>
> I then modified the files, added them, commited the changes and then
> used git push to put them on the PC - still no problems.
>
> Both systems show the commits but the PC does not have the latest
> version of the files. Git status on the PC shows the file as changed
> but commiting give an error when pushing from the laptop.
>
> I assume that I need to run a command on the PC to get both systems
> the same. Is it a reset or something else?
So IIUC running 'git log' on the machine you pushed the changes to,
you can see the checkin you made on the machine you made the change
on? You need to run 'git checkout' on the machine you pushed to, to
tell git that you want these files. This is a safety feature, since
someone may be working on the files on that machine locally, and so
doesn't want them being overwritten by your push.
You may find the documentation (http://git-scm.com/documentation)
useful, especially
http://www.kernel.org/pub/software/scm/git/docs/everyday.html which
has your scenario under "Push into another repository. ".
If you want someone to take some changes you made, it is recommended
to let them know so that they can run 'git pull' or 'git fetch' to get
your changes (performing a merge or rebase as desired). This means
that they control when they get the updates and what they want to do
with them.
If you are committing the files to a shared public repository (e.g. a
central repository, or build server repository), a pussible approach
is to create that as a "bare" repository (one with just the contents
of the .git folder - i.e. it does not have any files checked out). You
can do this by running:
git clone --bare source/git/path/project project.git
you can then clone from this:
git clone my/shared/project.git
and push any changes to it as normal.
The build server can then do a 'git pull' to get the new changes from
that repository.
You can keep it setup like you currently have (assuming that where you
are pushing to is a shared repository), and do:
git checkout HEAD
before you run a build (assuming this is the repository that you are
using for your builds). The advantage of a bare repository is that it
will take up less space, and using a different (cloned) repository for
performing builds keeps the main repository clean.
One of the great things about git is that you can customise it to fit
different workflows.
HTH,
- Reece
^ 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