* 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
* Re: [PATCHv4 08/12] Teach the notes lookup code to parse notes trees with various fanout schemes
From: Johannes Schindelin @ 2009-08-28 8:51 UTC (permalink / raw)
To: Johan Herland
Cc: git, Junio C Hamano, Shawn O. Pearce, trast, tavestbo, git,
chriscool
In-Reply-To: <200908280103.06015.johan@herland.net>
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?
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.
Ciao,
Dscho
^ 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 8:48 UTC (permalink / raw)
To: Junio C Hamano
Cc: Johan Herland, git, trast, tavestbo, git, chriscool, spearce
In-Reply-To: <7vprahq8iv.fsf@alter.siamese.dyndns.org>
Hi,
On Thu, 27 Aug 2009, Junio C Hamano wrote:
> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
>
> > I half-agree, the code should decide which fanout scheme to use, but
> > _only_ when producing new notes.
> >
> > I imagine that it could merge the existing notes, and try to make sure
> > that there are no more blobs in a given subtree than a certain
> > threshold; if that threshold is reached, it could fan-out using
> > 2-digit subtrees, merging what needs merging (by concatenation) along
> > the way.
> >
> > The natural precedence of shallower paths/longer basenames should cope
> > well with that (i.e. prefer to show abcd/... over ab/cd/...).
>
> Oh, if the plan for merging the trees is such that it takes care of
> "multiple notes pointing at the same commit" issues like you outline,
> then I can see it would work nicely.
>
> At that point, fan-out would become merely an implementation detail,
> something the end user never needs to worry about, just like what base
> object is chosen to represent another object in a packfile.
Oh, that's where you're coming from! Now I understand your concerns; it
never occurred to me that the user should be encouraged to add notes to
the tree herself. I was always under the impression that the fan-out is
an implementation detail best hidden from the user.
Ciao,
Dscho
^ permalink raw reply
* Re: Using git to track my PhD thesis, couple of questions
From: Matthieu Moy @ 2009-08-28 8:46 UTC (permalink / raw)
To: Paolo Bonzini; +Cc: seanh, git
In-Reply-To: <4A979690.1050601@gnu.org>
Paolo Bonzini <bonzini@gnu.org> writes:
> You can also merge from the master to your working branch after every
> merge --squash.
Yes, good point. I didn't think of this, but it works because ...
> ... work on local ...
> git commit
> ... work on local ...
> git commit
>
> git checkout master
> git merge --squash local; git commit -m'day 1'
... this should fast-forward, so get the same tree as in branch
'local' and ...
> git checkout local
> git merge master
... then this is a merge of two identical trees, so it's trivial.
--
Matthieu
^ permalink raw reply
* Re: [RFC] teamGIT bonjour support
From: Abhijit Bhopatkar @ 2009-08-28 8:39 UTC (permalink / raw)
To: John Tapsell; +Cc: git, teamgit
In-Reply-To: <43d8ce650908280105x70327db0p7fce1bd6575297d2@mail.gmail.com>
>> good. But it has its usual problems of forcing everyone to religiously
>> publish _AND_ keep rebasing on main branch every so often. Also my
>> major problem is that we discover conflicts only _after_ a developer
>> tries to rebase his work, typically (by design) after he has fully
>> coded and tested a feature.
>
> What sort of time frame are you talking about? How long are your
> sprints, or however you partition your work.
>
> I can't help but feel the problem should be solved elsewhere. Do you
> have daily scrums? Everyone should know, roughly, what everyone is
> doing. If you are using 2-3 week sprints (or however you partition
> the time) and everyone is roughly aware of what everyone else around
> them is doing, there shouldn't really be so much of a problem.
Well as i said in informal way we do shout out loud (managers: read as
'daily meetings') when we want to make changes that might conflict
with some one else and i have been blessed with a rather good dev team
who can spot this right, and it works well for now for these short
sprints. However see below for my itch.
>> The current way to get around this is shouting aloud before you start
>> working on a new feature/file/section.
>
> How do you allocate the features in the first place? At the start of
> a sprint? If so, it should be the person in charge of that that
> should see if there are going to be conflicts. If you don't have
> sprints, then how do you divide up tasks?
Yes as i said this generally works.
But and this is a big BUT, this essentially makes the developer the
point of failure (in reporting the conflict). And in my view (exactly
contrary to yours) the problem should be solved else where.
Also we are working on many porting projects which need changes to the
same file but not essentially logically conflicting, which if,
everyone is aware of at the moment the change is made (commited?) is
trivial to resolve.
However when you have 100 such changes at the end of a sprint thats a
problem. Yes git makes it extremely easy to merge i can't even begin
to think about the current style of development in svn deployment. And
we can resolve those conflicts fairly easy. Its just that I have to
depend then on individual's ability to persist through what seems like
million merge conflicts.
And no its not avoidable, we _have_ to do those conflicting changes in
order to keep the pace of development. Its just about reporting them
sanely and quickly which is ok to be done manually, but it pains me
that the info can be available with some tool as well with obvious
benifits of automation.
So the idea is sort of local linux-next style automation for small teams.
BAIN
> John
^ 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