* Re: bzr to git syncing
From: Alex Bennee @ 2009-08-28 16:02 UTC (permalink / raw)
To: git, David Reitter
In-Reply-To: <F84D4C0F-1CEF-4853-84DB-B7927CBE62B3@gmail.com>
[-- Attachment #1: Type: text/plain, Size: 807 bytes --]
2009/6/29 David Reitter <david.reitter@gmail.com>:
> Does anyone have experience syncing a Bzr repository to git?
> I would ideally want two-way syncing, but even the bzr->git route would be a
> start.
I've a sneaking suspicion a breakage has been introduced to either the
git-bzr script or
the bzr fast-import module. I say this as I have successfully pulled
from a bzr repo into
git before but having need to do it today and I get a crash in fast-import.
A few quick questions:
* What versions of git/bzr are you using (me: git 1.6.4, bzr 1.17)?
* Which git-bzr script are you using (me:
http://github.com/mcepl/git-bzr/tree/master)?
I've attached the fast-import crash I'm seeing. Are you seeing the
same sort of failure?
--
Alex, homepage: http://www.bennee.com/~alex/
http://www.half-llama.co.uk
[-- Attachment #2: fast_import_crash_21774 --]
[-- Type: application/octet-stream, Size: 1094 bytes --]
fast-import crash report:
fast-import process: 21774
parent process : 21773
at Fri Aug 28 16:54:14 2009
fatal: Corrupt mode: M 040000 - content
Most Recent Commands Before Crash
---------------------------------
commit refs/heads/bzr/upstream
mark :1
committer Alexander Sack <asac@jwsdot.com> 1181743954 +0200
data 39
M 644 inline build.sh
data 3963
M 644 inline chrome.manifest
data 192
M 644 inline config_build.sh
data 170
* M 040000 - content
Active Branch LRU
-----------------
active_branches = 1 cur, 5 max
pos clock name
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
1) 0 refs/heads/bzr/upstream
Inactive Branches
-----------------
refs/heads/bzr/upstream:
status : active loaded dirty
tip commit : 0000000000000000000000000000000000000000
old tree : 0000000000000000000000000000000000000000
cur tree : 0000000000000000000000000000000000000000
commit clock: 0
last pack :
Marks
-----
exported to /export/src/debs/cbnlfox.git/.git/bzr-git/upstream-git-map
-------------------
END OF CRASH REPORT
^ permalink raw reply
* Re: Using git to track my PhD thesis, couple of questions
From: Paolo Bonzini @ 2009-08-28 15:50 UTC (permalink / raw)
To: seanh; +Cc: git
In-Reply-To: <20090828133708.GA11146@kisimul>
On 08/28/2009 03:37 PM, seanh wrote:
> In response to Matthieu and Paolo, I'm not sure I understand the git
> internals involved in the discussion around merge --squash, I had a
> feeling this would produce a 'merge' that git in some sense would 'not
> know about', since it sounds complex and I don't understand it I don't
> think I want to go there.
Yes, the problem is that git does not track what happens when you do
"git merge --squash", which makes it harder to do merges after some time
(because of conflicts).
The solution I gave (and Matthieu explained how it works, even though
it's very technical) is a way to "explain" git what you did. If you try
it on a fake example with gitk, you should understand it better.
mkdir test
cd test
# import
git init
echo a > test
git add a
git commit -m1
# some changes happen in your local "fine grained" branch
git checkout -b local
echo b > test
git commit -a -m2
echo c >> test
git commit -a -m3 ##<<<
# the magic incantation brings those commit to master
# (first two commands) and teaches git what happened (last two)
git checkout master
git merge --squash local; git commit -m'merge 1' ##<<<
git checkout local
git merge master ##<<<
# more local changes
sed -i s/b/d/ test
git commit -a -m4
echo z >> test
git commit -a -m5 ##<<<
# the magic incantation, again
git checkout master
git merge --squash local; git commit -m'merge 1' ##<<<
git checkout local
git merge master ##<<<
Use gitk at the points indicated with ##<<<
It is actually very similar to what you chose to do. My commits to
master, in practice, are your tags. You may want to see how gitk's
graphs looks in both scenarios, and choose the one that you prefer.
Hope this helps!
Paolo
^ permalink raw reply
* Re: Merging in Subversion 1.5 (was: Re: Using git to track my PhD thesis, couple of questions)
From: Matthias Andree @ 2009-08-28 15:44 UTC (permalink / raw)
To: Avery Pennarun, Jakub Narebski; +Cc: git, Matthieu Moy
In-Reply-To: <32541b130908280829s6fcebbe5ja84b10e649de1eb3@mail.gmail.com>
Am 28.08.2009, 17:29 Uhr, schrieb Avery Pennarun <apenwarr@gmail.com>:
> I think they probably meant that it's the client's responsibility to
> set the property correctly, not the server's, and if your client is
> too old any you do a merge, it'll forget to set svn:mergeinfo, causing
> confusion for everyone. There's discussion in the svn book
> (http://svnbook.red-bean.com/en/1.5/svn.branchmerge.advanced.html) but
> nothing implies that it's a non-replicated property. Indeed, I can
> see no particular reason that anyone would want it to be, for the
> reasons you specify.
It is replicated, and the common remedy against older clients is to refuse
commits from those clients that do not support mergeinfo. This is done by
defining a repository hook on the server side that validates this. AFAIR
such a hook example ships with SVN.
--
Matthias Andree
^ permalink raw reply
* Re: [PATCH] Fix overridable written with an extra 'e'
From: Johannes Schindelin @ 2009-08-28 15:31 UTC (permalink / raw)
To: Avery Pennarun; +Cc: Junio C Hamano, Todd Zullinger, Nanako Shiraishi, git
In-Reply-To: <32541b130908280815y78f95140re679c336fbd17443@mail.gmail.com>
[-- Attachment #1: Type: TEXT/PLAIN, Size: 1041 bytes --]
Hi,
On Fri, 28 Aug 2009, Avery Pennarun wrote:
> On Fri, Aug 28, 2009 at 4:53 AM, Junio C Hamano<gitster@pobox.com> wrote:
> > Hmph, I don't know. Googling "overrideable" suggests "Did you mean
> > overridable?" which is enough clue for me.
>
> Using a similar system, the Google hit count:
>
> overrideable: 26,900
> overridable: 339,000
> overridden: 2,280,000
But of course, "overidable" means "able to be overridden", not
"overridden".
> Which agrees with my intuition that you can get away with overridable,
> but it's much more common to just use overridden.
>
> "override" of course comes from "ride" (181,000,000). A horse can be
> ridden (10,500,000) if it's ridable (82,500).
>
> The bad news: rideable (201,000).
>
> http://www.merriam-webster.com/dictionary/ridable shows rideable as
> the preferred spelling, but accepts both.
Actually, I do not trust the bda speling of the many internet content
providers as much as Merriam Webster, so of all your analysis, I find this
the most important finding.
Ciao,
Dscho
^ permalink raw reply
* Re: Merging in Subversion 1.5 (was: Re: Using git to track my PhD thesis, couple of questions)
From: Avery Pennarun @ 2009-08-28 15:29 UTC (permalink / raw)
To: Jakub Narebski; +Cc: Matthias Andree, git, Matthieu Moy
In-Reply-To: <m3ocq0km5m.fsf_-_@localhost.localdomain>
On Fri, Aug 28, 2009 at 3:12 PM, Jakub Narebski<jnareb@gmail.com> wrote:
> From what I understand (from what I have read, and browsed, and
> lurged, and noticed) is that Subversion 1.5+ does merge tracking, but
> in very different way that in Git:
>
> * the svn:mergeinfo is client-side property; if I understand
> correctly this would help you in repeated merges, but not anyone
> other
I don't believe there is such a thing as a "client-side property" in
svn. I see someone said this on stackoverflow
(http://stackoverflow.com/questions/1156698/are-svn-merges-idempotent)
but I'm pretty sure they were either mistaken or using a different
definition of "client-side."
I think they probably meant that it's the client's responsibility to
set the property correctly, not the server's, and if your client is
too old any you do a merge, it'll forget to set svn:mergeinfo, causing
confusion for everyone. There's discussion in the svn book
(http://svnbook.red-bean.com/en/1.5/svn.branchmerge.advanced.html) but
nothing implies that it's a non-replicated property. Indeed, I can
see no particular reason that anyone would want it to be, for the
reasons you specify.
> * svn:mergeinfo contains _per-file_ merge info, so it is much, much
> more "chatty" than Git multiple parents. This might be more
> powerfull approach, in the same sense that more advanced merge
> strategies that 3-way merge were more powerfull -- but 3-way merge
> is best because it is simple (and either it is simple that 3-way
> merge is enough, or complicated so manual intervention is required).
svn people really love their cherry-picks and want to keep track of
which things get cherry picked from one branch to another. This is
nice (at least for informational purposes) although they go through
some probably-unnecessary contortions *after* doing this, including
splitting a merge from "maint" into "master" into two sequential
merges, if you've previously cherry-picked a commit from master into
maint. The above svn book link describes this in a bit more detail.
I don't think that behaviour would be much help in any situation I've
ever experienced, so I agree with your comment that 3-way merge is
generally better.
Tracking cherry picks in git would be really nice *sometimes*, but it
creates a tradeoff where you then have to slurp in huge amounts of
history that you might not want. In svn, this tradeoff doesn't exist,
since anything you cherry pick must have already existed on the server
anyway, and can never go away.
> * You have to explicitely enable using svn:mergeinfo in log and blame
Conversely, in git you can basically disable it using --first-parent,
which is sometimes handy. (It's handiest if your team has a policy of
always using --no-ff when merging into trunk, which makes git act a
bit more like svn's merge tracking. I realize this is a bit heretical
to suggest on the git list, but I appreciate that the option exists
despite its heresy :))
Have fun,
Avery
^ permalink raw reply
* Re: [PATCH] Fix overridable written with an extra 'e'
From: Avery Pennarun @ 2009-08-28 15:15 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Todd Zullinger, Nanako Shiraishi, git
In-Reply-To: <7v63c8a69a.fsf@alter.siamese.dyndns.org>
On Fri, Aug 28, 2009 at 4:53 AM, Junio C Hamano<gitster@pobox.com> wrote:
> Hmph, I don't know. Googling "overrideable" suggests "Did you mean
> overridable?" which is enough clue for me.
Using a similar system, the Google hit count:
overrideable: 26,900
overridable: 339,000
overridden: 2,280,000
Which agrees with my intuition that you can get away with overridable,
but it's much more common to just use overridden.
"override" of course comes from "ride" (181,000,000). A horse can be
ridden (10,500,000) if it's ridable (82,500).
The bad news: rideable (201,000).
http://www.merriam-webster.com/dictionary/ridable shows rideable as
the preferred spelling, but accepts both.
Have fun,
Avery
^ permalink raw reply
* Merging in Subversion 1.5 (was: Re: Using git to track my PhD thesis, couple of questions)
From: Jakub Narebski @ 2009-08-28 15:12 UTC (permalink / raw)
To: Matthias Andree; +Cc: git, Matthieu Moy
In-Reply-To: <4A97E1B1.7090107@gmx.de>
Matthias Andree <matthias.andree@gmx.de> writes:
> Matthieu Moy schrieb:
>> seanh <seanh.nospam@gmail.com> writes:
>>
>>> In response to Matthieu and Paolo, I'm not sure I understand the git
>>> internals involved in the discussion around merge --squash, I had a
>>> feeling this would produce a 'merge' that git in some sense would 'not
>>> know about',
>>
>> Yes, that's it. Git does a merge, and immediately forgets it was a
>> merge. The consequence is when you merge again later, Git will not be
>> able to use the merge information to be clever about merging. Somehow,
>> Git will be as bad as SVN for merging if you don't know what you're
>> doing ;-).
>
> To be fair, SVN versions 1.5 and newer can track merges. If the
> repository predates 1.5, it has to be updated on the server side
> (see the release notes for details). It just tracks which revisions
> have been merged and which not, for further details, see the svn
> book. (http://svnbook.red-bean.com/ IIRC)
>From what I understand (from what I have read, and browsed, and
lurged, and noticed) is that Subversion 1.5+ does merge tracking, but
in very different way that in Git:
* the svn:mergeinfo is client-side property; if I understand
correctly this would help you in repeated merges, but not anyone
other
* svn:mergeinfo contains _per-file_ merge info, so it is much, much
more "chatty" than Git multiple parents. This might be more
powerfull approach, in the same sense that more advanced merge
strategies that 3-way merge were more powerfull -- but 3-way merge
is best because it is simple (and either it is simple that 3-way
merge is enough, or complicated so manual intervention is required).
* You have to explicitely enable using svn:mergeinfo in log and blame
* The command to merge trunk into branch is different from command to
merge branch into trunk.
Also IIRC there is warning (well, at least there was in Subversion 1.5
release notes) that merge tracking doesn't work entirely correctly in
the face of criss-cross merges (multiple merge bases) and renaming
(although I do hope that they fixed problem with silent corruption if
there is rename during merge).
--
Jakub Narebski
Git User's Survey 2009: http://tinyurl.com/GitSurvey2009
^ permalink raw reply
* Re: [PATCH] Round-down years in "years+months" relative date view
From: Jeff King @ 2009-08-28 15:02 UTC (permalink / raw)
To: Alex Riesen; +Cc: David Reiss, git
In-Reply-To: <81b0412b0908280058i364bfb83nb04354d982abc053@mail.gmail.com>
On Fri, Aug 28, 2009 at 09:58:27AM +0200, Alex Riesen wrote:
> > I couldn't find any tests related to relative date processing, so it
> > would be really nice to have some. But I'm not sure of the best way to
> > do it without dealing with race conditions. Annoyingly, show_date calls
> > gettimeofday at a pretty low level, so there isn't a way of
> > instrumenting it short of LD_PRELOAD trickery (which is probably not
> > very portable).
>
> Maybe better prepare the _test_ so that it uses current time and time
> arithmetics then put yet another cludge in operational code? Especially
> when we already have a greate number of GIT_ environment variables,
> documented nowhere, with effects not immediately obvious:
But that's the point: you can't do that without a race condition. Your
test gets a sense of the current time, then runs git, which checks the
current time again. How many seconds elapsed between the two checks?
I guess it is good enough for testing large time spans, but I was hoping
for a comprehensive time test.
-Peff
^ permalink raw reply
* Re: [PATCHv4 08/12] Teach the notes lookup code to parse notes trees with various fanout schemes
From: Johan Herland @ 2009-08-28 14:15 UTC (permalink / raw)
To: Johannes Schindelin
Cc: git, Junio C Hamano, Shawn O. Pearce, trast, tavestbo, git,
chriscool
In-Reply-To: <alpine.DEB.1.00.0908281349270.7434@intel-tinevez-2-302>
On Friday 28 August 2009, Johannes Schindelin wrote:
> On Fri, 28 Aug 2009, Johan Herland wrote:
> > On Friday 28 August 2009, Johannes Schindelin wrote:
> > > And I can easily imagine a repository that has a daily note
> > > generated by an automatic build, and no other notes. The
> > > date-based fan-out just wastes our time here, and even hurts
> > > performance.
> >
> > What about a month-based fanout?
>
> Well, I hoped to convince you that the date-based approach is too
> rigid. You basically cannot adapt the optimal data layout to the
> available data.
>
> (I like to think of this issue as related to storing deltas: we let
> Git choose relatively freely what to delta against, and do not force
> a delta against the parent commit like others do; I think it is
> pretty obvious that our approach is more powerful.)
>
> So the simplest (yet powerful-enough) way I could imagine is to teach
> the reading part to accept any fan-out (but that fan-out is really
> only based on the object name, nothing else), and to adjust the
> writing/merging part such that it has a maximum bin size (i.e. it
> starts a new fan-out whenever a tree object contains more than a
> config-specifyable limit).
I agree with your points on flexibility and not nailing down a structure
that might prove too rigid in the future.
But it seems the date-based approach might offer wins that an
object-name-based approach (flexible or not) simply cannot hope to
match...
Also a rigid organization (with unique note locations) makes the
implementation simpler and faster: If you allow notes for a given
commit at several places in the notes tree (and require the result to
be the concatenation of those notes, which seems to be the saner
choice), the lookup procedure must keep looking even after it has found
the first match. This affects both runtime and memory consumption
negatively (more subtrees must be unpacked, etc.)
I guess I'll code up both alternatives so that we can get some actual
numbers...
...Johan
--
Johan Herland, <johan@herland.net>
www.herland.net
^ permalink raw reply
* Re: Using git to track my PhD thesis, couple of questions
From: Matthias Andree @ 2009-08-28 13:54 UTC (permalink / raw)
To: git
In-Reply-To: <vpqpragt5bo.fsf@bauges.imag.fr>
Matthieu Moy schrieb:
> seanh <seanh.nospam@gmail.com> writes:
>
>> In response to Matthieu and Paolo, I'm not sure I understand the git
>> internals involved in the discussion around merge --squash, I had a
>> feeling this would produce a 'merge' that git in some sense would 'not
>> know about',
>
> Yes, that's it. Git does a merge, and immediately forgets it was a
> merge. The consequence is when you merge again later, Git will not be
> able to use the merge information to be clever about merging. Somehow,
> Git will be as bad as SVN for merging if you don't know what you're
> doing ;-).
To be fair, SVN versions 1.5 and newer can track merges. If the repository
predates 1.5, it has to be updated on the server side (see the release notes for
details). It just tracks which revisions have been merged and which not, for
further details, see the svn book. (http://svnbook.red-bean.com/ IIRC)
^ permalink raw reply
* Re: Using git to track my PhD thesis, couple of questions
From: Matthieu Moy @ 2009-08-28 13:51 UTC (permalink / raw)
To: seanh; +Cc: git
In-Reply-To: <20090828133708.GA11146@kisimul>
seanh <seanh.nospam@gmail.com> writes:
> In response to Matthieu and Paolo, I'm not sure I understand the git
> internals involved in the discussion around merge --squash, I had a
> feeling this would produce a 'merge' that git in some sense would 'not
> know about',
Yes, that's it. Git does a merge, and immediately forgets it was a
merge. The consequence is when you merge again later, Git will not be
able to use the merge information to be clever about merging. Somehow,
Git will be as bad as SVN for merging if you don't know what you're
doing ;-).
> since it sounds complex and I don't understand it I don't think I
> want to go there.
Well, it's fun also to learn Git notions in more details ;-).
--
Matthieu
^ permalink raw reply
* Re: Using git to track my PhD thesis, couple of questions
From: seanh @ 2009-08-28 13:37 UTC (permalink / raw)
To: git
In-Reply-To: <20090827203402.GC7168@kisimul>
Wow, really helpful responses, thanks a lot.
I think having read all this that I'll do it manually. I'll still use
git to track my latex source and will commit to it as often as I like
and not worry about commit granularity. Whenever I've finished a
significant chunk I'll add a PDF of it to a manually edited web page
along with a description of what changed since the last time I added a
PDF. I can use git log etc to help write the manual changelog. My
supervisors can just look at this manually constructed page and if it
gets too big I'll just archive the oldest PDFs. I can tag the git repo
at the points where I add a PDF to the web page. I guess this is pretty
close to what software projects do with version releases and their
public website.
On Thu, Aug 27, 2009 at 01:41:04PM -0700, Sverre Rabbelier wrote:
> If they only care about the pdf anyway, why not have a separate branch
> to which you commit the pdf's instead?
Well I was thinking they'd look at the changelogs with the diffs showing
exactly what changed in the latex source files, which should be pretty
self-explanatory, but then when they wanted to read a whole chapter and
add comments to it they'd want the PDF not the latex.
I don't really understand the script Junio posted (not literate in sh)
but I think it might have something to do with copying changelogs over
from the source repo to a PDFs repo.
On Fri, Aug 28, 2009 at 12:21:42AM +0200, demerphq wrote:
> As you can generate the PDF's from the latex then just hack gitweb to
> let them download it from there.
Unfortunately gitweb is written in Perl. But I know what you mean, it
should in theory be possible for them to click on a 'Get PDF' link for a
particular revision that causes the PDF to be built and returned to
their browser.
In response to Matthieu and Paolo, I'm not sure I understand the git
internals involved in the discussion around merge --squash, I had a
feeling this would produce a 'merge' that git in some sense would 'not
know about', since it sounds complex and I don't understand it I don't
think I want to go there.
Thanks all
^ permalink raw reply
* Re: Question regarding git fetch
From: Tom Lambda @ 2009-08-28 13:24 UTC (permalink / raw)
To: git
In-Reply-To: <1251387045053-3527289.post@n2.nabble.com>
Thank you all for your answers and the interesting following discussion.
>From a user perspective (I do not know how git works internally), the
approach proposed by Juno looks very intuitive to me. Now I understand there
are other cases and users to take into account, which make the
implementation complex. I hope this will be part of git 1.7.0.
--Tom
--
View this message in context: http://n2.nabble.com/Question-regarding-git-fetch-tp3527289p3534609.html
Sent from the git mailing list archive at Nabble.com.
^ permalink raw reply
* Re: [RFC] teamGIT bonjour support
From: Abhijit Bhopatkar @ 2009-08-28 13:07 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git, teamgit
In-Reply-To: <m3skfckzk1.fsf@localhost.localdomain>
2009/8/28 Jakub Narebski <jnareb@gmail.com>:
> Abhijit Bhopatkar <bain@devslashzero.com> writes:
>
>> So I ask you people, is there a solution already cooking someplace?
>> may be something i can integrate with teamGIT? (e.g. bonjour plugin
>> for git dameon)
>
> There is gitjour:
> http://rubyforge.org/projects/gitjour
> http://github.com/chad/gitjour
Hmm... almost perfect, except i don't want to depend on ruby to be
installed on the target machine.
Sigh!
BAIN
^ permalink raw reply
* inotify-commit, was Re: git guidance
From: Johannes Schindelin @ 2009-08-28 12:30 UTC (permalink / raw)
To: Björn Steinbrink; +Cc: git
In-Reply-To: <20071207220025.GD2001@atjola.homenet>
[-- Attachment #1: Type: TEXT/PLAIN, Size: 2440 bytes --]
Hi,
[long Cc: list culled, as they probably forgot about this thread]
On Fri, 7 Dec 2007, Björn Steinbrink wrote:
> That said, out of pure curiousness I came up with the attached script
> which just uses inotifywait to watch a directory and issue git commands
> on certain events. It is extremely stupid, but seems to work. And at
> least it hasn't got the drawbacks of a real gitfs regarding the need to
> have a "separate" non-versioned storage area for the working directory,
> because it simply uses the existing working directory wherever that
> might be stored. It doesn't use GIT_DIR/WORK_DIR yet, but hey, should be
> easy to add...
>
> Feel free to mess with that thing, hey, maybe you even like it and
> extend it to match your proposed workflow even more. I for sure won't
> use or even extend it, so you're likely on your own there.
>
> Side-note: Writing that script probably took less time than writing this
> email and probably less time than was wasted on this topic. Makes me
> want to use today's preferred "Code talks, b...s... walks" statement,
> but I'll refrain from that... Just because I lack the credibility to say
> that, and the script attached is quite crappy ;-)
I could not agree more with the statement.
As it happens, I have a very delicate setup that we tested in a test
environment as much as possible, but now we have to deploy it and I want
to be able to rewind very quickly to a known-good state.
So I adjusted your script a little. It now reads like this:
-- snip --
#!/bin/sh
# Originally by Bjoern Steinbrink, simplified by Johannes Schindelin
inotifywait -m -r --exclude ^\./\.git/.* \
-e close_write -e move -e create -e delete . 2>/dev/null |
while read FILE_PATH EVENT FILE_NAME
do
FILE_NAME="$FILE_PATH$FILE_NAME"
FILE_NAME=${FILE_NAME#./}
# git doesn't care about directories
test -d "$FILE_NAME" && continue
case "$EVENT" in
*MOVED_TO*|*CREATE*)
git add "$FILE_NAME"
git commit -m "$FILE_NAME created"
;;
*CLOSE_WRITE*|*MODIFY*)
git add "$FILE_NAME"
git commit -m "$FILE_NAME changed"
;;
*DELETE*|*MOVED_FROM*)
git rm --cached "$FILE_NAME"
git commit -m "$FILE_NAME removed"
;;
esac
done
-- snap --
Thanks for your original script!
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH] Add option -b/--branch to clone for select a new HEAD
From: Julian Phillips @ 2009-08-28 12:10 UTC (permalink / raw)
To: Martin Langhoff
Cc: Tor Arne Vestbø, Kirill A. Korinskiy, gitster, git, peff,
B.Steinbrink
In-Reply-To: <46a038f90908280405o1e86bf4fo60eb07957ce9158a@mail.gmail.com>
On Fri, 28 Aug 2009, Martin Langhoff wrote:
> On Fri, Aug 28, 2009 at 12:31 PM, Tor Arne Vestb?<torarnv@gmail.com> wrote:
>> Glad to see this topic being revised. Here's the original discussion for
>> reference:
>
> ISTR that early git supported this -- maybe just on the HTTP
> implementation? I sure remember writing
>
> git clone http://host/foo.git#branchname
>
> and getting a cloned repo where 'branchname' was tracking
> 'origin/branchname', and was checked out as HEAD.
Did you use cogito perhaps? That had #branch syntax IIRC ...
> It would have been dropped by the switch to C builtins :-/
>
> cheers,
>
>
>
> m
>
--
Julian
---
"What duck?"
-- (Terry Pratchett, Soul Music)
^ permalink raw reply
* Re: [PATCHv4 08/12] Teach the notes lookup code to parse notes trees with various fanout schemes
From: Johannes Schindelin @ 2009-08-28 11:56 UTC (permalink / raw)
To: Johan Herland
Cc: git, Junio C Hamano, Shawn O. Pearce, trast, tavestbo, git,
chriscool
In-Reply-To: <200908281240.13311.johan@herland.net>
Hi,
On Fri, 28 Aug 2009, Johan Herland wrote:
> On Friday 28 August 2009, Johannes Schindelin wrote:
>
> > And I can easily imagine a repository that has a daily note generated
> > by an automatic build, and no other notes. The date-based fan-out
> > just wastes our time here, and even hurts performance.
>
> What about a month-based fanout?
Well, I hoped to convince you that the date-based approach is too rigid.
You basically cannot adapt the optimal data layout to the available data.
(I like to think of this issue as related to storing deltas: we let Git
choose relatively freely what to delta against, and do not force a delta
against the parent commit like others do; I think it is pretty obvious
that our approach is more powerful.)
So the simplest (yet powerful-enough) way I could imagine is to teach the
reading part to accept any fan-out (but that fan-out is really only based
on the object name, nothing else), and to adjust the writing/merging part
such that it has a maximum bin size (i.e. it starts a new fan-out whenever
a tree object contains more than a config-specifyable limit).
I was certainly not thinking of something as complicated as Huffman.
Ciao,
Dscho
^ permalink raw reply
* [BUG] git stash refuses to save after "add -N"
From: Yann Dirson @ 2009-08-28 11:02 UTC (permalink / raw)
To: git
$ echo foo > bar
$ git add -N bar
$ ./git --exec-path=$PWD stash save
bar: not added yet
fatal: git-write-tree: error building trees
Cannot save the current index state
Maybe it would require some magic in git-stash to detect/save/restore that
particular state, or "just" to cause "add -N" to insert an empty file
instead ?
I suspect that second solution would not be particularly popular, but I
don't find the 1st one very appealing, it just looks like breaking the
whole idea behind git-stash :)
^ permalink raw reply
* Re: [PATCH] Add option -b/--branch to clone for select a new HEAD
From: Martin Langhoff @ 2009-08-28 11:05 UTC (permalink / raw)
To: Tor Arne Vestbø
Cc: Kirill A. Korinskiy, gitster, git, peff, B.Steinbrink
In-Reply-To: <4A97B1F3.5060408@gmail.com>
On Fri, Aug 28, 2009 at 12:31 PM, Tor Arne Vestbø<torarnv@gmail.com> wrote:
> Glad to see this topic being revised. Here's the original discussion for
> reference:
ISTR that early git supported this -- maybe just on the HTTP
implementation? I sure remember writing
git clone http://host/foo.git#branchname
and getting a cloned repo where 'branchname' was tracking
'origin/branchname', and was checked out as HEAD.
It would have been dropped by the switch to C builtins :-/
cheers,
m
--
martin.langhoff@gmail.com
martin@laptop.org -- School Server Architect
- ask interesting questions
- don't get distracted with shiny stuff - working code first
- http://wiki.laptop.org/go/User:Martinlanghoff
^ permalink raw reply
* Re: [PATCHv4 08/12] Teach the notes lookup code to parse notes trees with various fanout schemes
From: Johan Herland @ 2009-08-28 10:40 UTC (permalink / raw)
To: Johannes Schindelin
Cc: git, Junio C Hamano, Shawn O. Pearce, trast, tavestbo, git,
chriscool
In-Reply-To: <alpine.DEB.1.00.0908281048320.7434@intel-tinevez-2-302>
On Friday 28 August 2009, Johannes Schindelin wrote:
> Hi,
>
> On Fri, 28 Aug 2009, Johan Herland wrote:
> > On Thursday 27 August 2009, Junio C Hamano wrote:
> > > "Shawn O. Pearce" <spearce@spearce.org> writes:
> > > > Yea, it was me. I still think it might be a useful idea, since
> > > > it allows you better density of loading notes when parsing the
> > > > recent commits. In theory the last 256 commits can easly be in
> > > > each of the 2/ fanout buckets, making 2/38 pointless for
> > > > reducing the search space. Commit date on the other hand can
> > > > probably force all of them into the same bucket, making it easy
> > > > to have the last 256 commits in cache, from a single bucket.
> > > >
> > > > But I thought you shot it down, by saying that we also wanted
> > > > to support notes on blobs. I happen to see no value in a note
> > > > on a blob, a blob alone doesn't make much sense without at
> > > > least an annotated tag or commit to provide it some named
> > > > context, and the latter two have dates.
> > >
> > > Yeah, and in this thread everybody seems to be talking about
> > > commits so I think it is fine to limit notes only to commits.
> >
> > Agreed. I'm starting to come around to the idea of storing them in
> > subtrees based on commit dates. For one, you don't have multiple
> > notes for one commit in the same notes tree. Also, the common-case
> > access pattern seems tempting.
> >
> > Dscho: Were there other problems with the date-based approach other
> > than not supporting notes on trees and blobs?
>
> It emphasized an implementation detail too much for my liking.
>
> And I would rather have some flexibility in the code as to _when_ it
> fans out and when not.
>
> So I can easily imagine a full repository which has only, say, 5
> notes. Why not have a single tree for all of those?
Yes, if you only have a handful of notes, the date-based approach is
definitely overkill. On the other hand, if you only have a handful of
notes, performance is not going to be a problem in the first place, no
matter which notes structure you use...
> And I can easily imagine a repository that has a daily note generated
> by an automatic build, and no other notes. The date-based fan-out
> just wastes our time here, and even hurts performance.
What about a month-based fanout? Looking at the kernel repo with
git log --all --date=iso --format="%ad" |
cut -c1-7 | sort | uniq -c | sort -n
I find that commits are spread across 66 months, and the most active
month (2008-07) has 5661 commits. If we assume the one-note-per-commit
worst case, that gives up to 5661 notes per month-based subdir. Is that
too much?
Doing
for subdir in $(find . -type d); do
echo "$(ls -1 $subdir | wc -l) $subdir"
done | sort -n
shows me that the currently largest tree in the kernel has 985 entries
(include/linux), so a 5661-entry tree is probably larger than what git
is used to...
...just thinking that we shold make things as simple as possible (but no
simpler), and if a month-based fanout works adequately in all practical
cases, then we should go with that...
...Johan
--
Johan Herland, <johan@herland.net>
www.herland.net
^ permalink raw reply
* Re: [PATCH] Add option -b/--branch to clone for select a new HEAD
From: Tor Arne Vestbø @ 2009-08-28 10:31 UTC (permalink / raw)
To: Kirill A. Korinskiy; +Cc: gitster, git, peff, B.Steinbrink
In-Reply-To: <1251228341-29434-1-git-send-email-catap@catap.ru>
On 8/25/09 9:25 PM, Kirill A. Korinskiy wrote:
> Sometimes (especially on production systems) we need to use only one
> remote branch for building software. It really annoying to clone
> origin and then swith branch by hand everytime. So this patch provide
> functionality to clone remote branch with one command without using
> checkout after clone.
Glad to see this topic being revised. Here's the original discussion for
reference:
http://thread.gmane.org/gmane.comp.version-control.git/114919/
Tor Arne
^ permalink raw reply
* Re: [RFC] teamGIT bonjour support
From: Jakub Narebski @ 2009-08-28 10:22 UTC (permalink / raw)
To: Abhijit Bhopatkar; +Cc: git, teamgit
In-Reply-To: <2fcfa6df0908280002y221a22e6md27db56865472144@mail.gmail.com>
Abhijit Bhopatkar <bain@devslashzero.com> writes:
> So I ask you people, is there a solution already cooking someplace?
> may be something i can integrate with teamGIT? (e.g. bonjour plugin
> for git dameon)
There is gitjour:
http://rubyforge.org/projects/gitjour
http://github.com/chad/gitjour
--
Jakub Narebski
Poland
ShadeHawk on #git
^ permalink raw reply
* Re: [RFC] teamGIT bonjour support
From: Ben Hoskings @ 2009-08-28 10:17 UTC (permalink / raw)
To: Abhijit Bhopatkar; +Cc: git, teamgit
In-Reply-To: <47ECFDB7-4189-4573-BC27-685603780F27@hoskings.net>
On 28/08/2009, at 8:06 PM, Ben Hoskings wrote:
> You should check out bananajour, it sounds like it might fight the
> bill quite nicely:
I mean, _fit_ the bill. My fingers got stuck in the '*ight' rhythm, I
guess. :)
Ben
^ permalink raw reply
* git error : Unable to write new index file
From: Keshetti Mahesh @ 2009-08-28 10:06 UTC (permalink / raw)
To: git
Hello all,
I have just started using git for a small project. I have
created empty repository using "git init" and it worked fine.
But after that when I have tried to add a file to the repository
using "git add <file_name>", I am getting the below error.
> fatal: Unable to write new index file
The same error appears not only when adding files but also
whenever I add something (file, branch etc. ) to git repository.
I am using git on windows using cygwin and I have all permissions
(rwx) in the directory where I am running this command. Can anyone
please help me in resolving this issue ?
Thanks,
Mahesh
^ permalink raw reply
* Re: [RFC] teamGIT bonjour support
From: Ben Hoskings @ 2009-08-28 10:06 UTC (permalink / raw)
To: Abhijit Bhopatkar; +Cc: git, teamgit
In-Reply-To: <2fcfa6df0908280002y221a22e6md27db56865472144@mail.gmail.com>
On 28/08/2009, at 5:02 PM, Abhijit Bhopatkar wrote:
> I plan to do this on LAN using bonjour service discovery, and rest
> completely being handled inside teamGIT running as a daemon(may be in
> widely abused systray?). (Git will handle actual fetch/conflict
> checking etc.)
> On a side note i also plan to generate daily reports and configurable
> notifications.
>
> So I ask you people, is there a solution already cooking someplace?
> may be something i can integrate with teamGIT? (e.g. bonjour plugin
> for git dameon)
You should check out bananajour, it sounds like it might fight the
bill quite nicely:
http://github.com/toolmantim/bananajour
Written by Tim Lucas, and hacked on by a bunch of us at the Gold
Coast, Australia Railscamp in May:
http://railscamps.com/
The idea is that for each repo you want to publish, bananajour creates
and looks after a locally stored remote, that you push to ("git push
banana master") to publish your work over bonjour.
There's also a web interface at your-machine.local:9331 which shows
the other bananas that were found (via bonjour) on the network.
['9331' is for 'peel' :) ]
I'm not sure what the state of Linux support is, since most of us run
OS X, but I'm pretty sure someone was working on Linux/zeroconf support.
Cheers
Ben Hoskings
^ 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