* Re: [PATCH] Round-down years in "years+months" relative date view
From: Jeff King @ 2009-08-28 6:05 UTC (permalink / raw)
To: David Reiss; +Cc: git
In-Reply-To: <4A97193A.8090502@facebook.com>
On Thu, Aug 27, 2009 at 04:39:38PM -0700, David Reiss wrote:
> Previously, a commit from 1 year and 7 months ago would display as
> "2 years, 7 months ago".
Wow, embarrassing.
Acked-by: Jeff King <peff@peff.net>
> Here's my test script. Let me know if you'd rather have it as part
> of the test suite.
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).
But maybe a patch like this is worth doing, which would allow us to test
in a repeatable fashion:
---
diff --git a/date.c b/date.c
index e848d96..db2f831 100644
--- a/date.c
+++ b/date.c
@@ -86,6 +86,33 @@ static int local_tzoffset(unsigned long time)
return offset * eastwest;
}
+static int current_time(struct timeval *now)
+{
+ static struct timeval fake_time;
+ static int use_fake_time = -1;
+
+ if (use_fake_time == -1) {
+ const char *x = getenv("GIT_FAKE_TIME");
+ if (x) {
+ char buf[50];
+ if (parse_date(x, buf, sizeof(buf)) <= 0)
+ die("unable to parse GIT_FAKE_TIME");
+ fake_time.tv_sec = strtoul(buf, NULL, 10);
+ fake_time.tv_usec = 0;
+ use_fake_time = 1;
+ }
+ else
+ use_fake_time = 0;
+ }
+
+ if (use_fake_time == 1) {
+ memcpy(now, &fake_time, sizeof(*now));
+ return 0;
+ }
+
+ return gettimeofday(now, NULL);
+}
+
const char *show_date(unsigned long time, int tz, enum date_mode mode)
{
struct tm *tm;
@@ -99,7 +126,7 @@ const char *show_date(unsigned long time, int tz, enum date_mode mode)
if (mode == DATE_RELATIVE) {
unsigned long diff;
struct timeval now;
- gettimeofday(&now, NULL);
+ current_time(&now);
if (now.tv_sec < time)
return "in the future";
diff = now.tv_sec - time;
@@ -929,7 +956,7 @@ unsigned long approxidate(const char *date)
if (parse_date(date, buffer, sizeof(buffer)) > 0)
return strtoul(buffer, NULL, 10);
- gettimeofday(&tv, NULL);
+ current_time(&tv);
time_sec = tv.tv_sec;
localtime_r(&time_sec, &tm);
now = tm;
^ permalink raw reply related
* Re: [PATCH v4 04/15] sequencer: add "reset_almost_hard()" and related functions
From: Eric Raible @ 2009-08-28 6:08 UTC (permalink / raw)
To: git
In-Reply-To: <20090828044746.4307.88742.chriscool@tuxfamily.org>
Christian Couder <chriscool <at> tuxfamily.org> writes:
> "reset_almost_hard()" can be used to do a "git reset --hard". It
> should be faster as it calls "unpack_trees()" directly, and it can
> optionnaly preserve changes in the work tree if the "allow_dirty"
> global is set. Preserving changes in the work tree can be usefull
> if for example you want to get rid of the last commit but keep
> your current not yet commited work.
s/optionnaly/optionally/
s/usefull/useful/
^ permalink raw reply
* Re: git-svn intermittent issues with absent_file
From: Matthias Andree @ 2009-08-28 6:58 UTC (permalink / raw)
To: Eric Wong; +Cc: git
In-Reply-To: <20090827191902.GA3185@dcvr.yhbt.net>
Am 27.08.2009, 21:19 Uhr, schrieb Eric Wong <normalperson@yhbt.net>:
> Matthias Andree <matthias.andree@uni-paderborn.de> wrote:
>> Greetings,
>>
>> we seem to have issues with checking out files from an SVN server via
>> https://. The problem is hard to reproduce, and shows as "absent_file"
>> warnings, i. e. files that are in the SVN checkout don't make it to the
>> Git checkin.
>>
>> Perhaps this rings a bell with someone or there are similar reports that
>> relate to our issues...
>
> Hi Matthias,
>
> I don't recall any issues with the "absent_file" callback ever being
> reported to me. I don't think I've ever touched a repo that triggered
> it, either...
Hi Eric,
thank you for the prompt reply.
>> ## ISSUE ## Once in a while, a git-svn clone or rebase fails with files
>> missing from commits, as mentioned above. We haven't been able to figure
>> out under what circumstances this happens. If we try to reproduce this
>> (i. e. kill the directory completely and re-run the git svn clone),
>> another revision (for instance 170) might show this, or the clone may
>> succeed.
>> This was observed with Git 1.6.0.4 under Ubuntu Linux Jaunty Jackalope
>> (9.04) and on a different computer with Git 1.6.4.1.196.g31f0b (from the
>> master branch) under a fully updated Cygwin 1.5.
>
> I assume this happens with the latest git under Ubuntu Linux, too; but
> can you give that a try just in case?
The latest git was on Cygwin, but we'll see to trying it on Linux.
> There have been a few odd bugs fixed since 1.6.0.4, but nothing rings a
> bell here. This doesn't seem to be a Cygwin/Win32-related issue, but
> I'd like to minimize the number of variables since I can't support
> Cygwin/Win32 directly.
The other question is how many arcane APR or Subversion binding issues we
hit here. Subversion 1.6 + bindings surely is rather picky on Cygwin 1.5,
as discussed earlier on this list.
>> Questions:
>>
>> 1. What causes these absent_file issues? How can we assist with
>> debugging
>> this?
>
> Permissions would be my first (and only) guess as I have no experience
> with this condition...
Hm. In that case: who writes the file that goes missing, and why isn't the
error logged then? Is there a way to have the SVN bindings or the
interfacing code in Git-SVN log file creation/write errors with decoded
errno? That might help a big deal already.
> Are you using anything weird in ~/.subversion/config by any chance?
Not to my knowledge.
> And you're sure you're using the same user/account in all cases?
Yes indeed. All under the same account.
> Are the files you're hitting absent_file on unusually large and
> hitting some limit on the server side?
The files aren't, the whole changeset might. We haven't yet observed this
on small (as in one .tex file) commits.
>> 2. What does "Delta source ended unexpectedly" mean? (the line number is
>> bogus, it's just the finish_report call)
>
> Sometimes the server can just shut down/drop connections. Do you have
> access to the server logs? How many simultaneous connections can
> it accept? Which version of the Subversion server is running?
The server doesn't permit user logins, so we need to ask the support
staff. Answer times are unpredictable.
> How reliable is your network connection to the server?
> Anything weird with the network configuration? Mismatched MTU, odd
> firewall rules, non-standard TCP stack configuration, VPN, proxies...
Uncritical. Company network, "direct connection" (through switches).
>> 3. Is this or a similar issue known? Is this an issue with the SVN
>> server, the SVN bindings, or the git svn adaptor?
>
> The "Incomplete data: Delta source ended unexpectedly" happens
> from time to time on a few odd servers, but I've never found it
> reproducible and retrying "git svn fetch" always fixes it.
> This is more than likely the fault of the network or server.
Seems plausible, but...
> The "absent_file" issue I've never seen...
...in such a case, some part of the overall system (I'm not saying it's
git-svn though) must ignore an error and continue.
>> We're happy to test patches.
>
> Cool. I don't have any ideas for patches right now, but does this
> problem happen with other SVN clients? Even svk/svm could be
> worth a shot for testing...
I can try svk, but what's svm?
--
Matthias Andree
^ permalink raw reply
* [RFC] teamGIT bonjour support
From: Abhijit Bhopatkar @ 2009-08-28 7:02 UTC (permalink / raw)
To: git, teamgit
Hi,
After a long pause in the development, i am back to drawing boards for teamGit.
Ever since i adopted git as my preferred version control system for my
teams, I had this tough time keeping up with every one. Of course this
is a GoodThing(TM) since this means pace of development is rather
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.
The current way to get around this is shouting aloud before you start
working on a new feature/file/section.
However a. this is not scalable
b. pron to human errors
c. pron to inhumane erros and after fights ;).
So in this regards, I have on my drawing boards a rough design to
1. Publish the current selected topic trees info on local lan.
2. Keep track of interesting topic branches and add alerts when
conflicts bet. selected trees reach alarming levels.
3. Possibly later add authentication mechanism to restrict access.
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)
Any thoughts or comment?
Am i just too stupid to not manage it with documented company wide policies?
BAIN
^ permalink raw reply
* Re: [PATCH] Round-down years in "years+months" relative date view
From: Alex Riesen @ 2009-08-28 7:58 UTC (permalink / raw)
To: Jeff King; +Cc: David Reiss, git
In-Reply-To: <20090828060538.GA22416@coredump.intra.peff.net>
On Fri, Aug 28, 2009 at 08:05, Jeff King<peff@peff.net> wrote:
> On Thu, Aug 27, 2009 at 04:39:38PM -0700, David Reiss wrote:
>
>> Previously, a commit from 1 year and 7 months ago would display as
>> "2 years, 7 months ago".
>
> Wow, embarrassing.
>
> Acked-by: Jeff King <peff@peff.net>
>
>> Here's my test script. Let me know if you'd rather have it as part
>> of the test suite.
>
> 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:
$ git grep -n '"GIT_'| perl -ne '/"(GIT_\w+)/ && print "$1\n"' |
sort |uniq | wc -l
49
$ git grep -n '"GIT_'|grep ^Documentation
$
GIT_FLUSH? GIT_SEND_EMAIL_NOTTY?! GIT_CHERRY_PICK_HELP?!!
^ permalink raw reply
* Re: [RFC] teamGIT bonjour support
From: John Tapsell @ 2009-08-28 8:05 UTC (permalink / raw)
To: git, teamgit
In-Reply-To: <2fcfa6df0908280002y221a22e6md27db56865472144@mail.gmail.com>
2009/8/28 Abhijit Bhopatkar <bain@devslashzero.com>:
> Hi,
>
> After a long pause in the development, i am back to drawing boards for teamGit.
>
> Ever since i adopted git as my preferred version control system for my
> teams, I had this tough time keeping up with every one. Of course this
> is a GoodThing(TM) since this means pace of development is rather
> 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.
> 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?
John
^ permalink raw reply
* Re: git-svn intermittent issues with absent_file
From: Matthias Andree @ 2009-08-28 8:14 UTC (permalink / raw)
To: Eric Wong; +Cc: git
In-Reply-To: <op.uzc1njug3myrm3@merlin.emma.line.org>
Am 28.08.2009, 08:58 Uhr, schrieb Matthias Andree
<matthias.andree@uni-paderborn.de>:
> The other question is how many arcane APR or Subversion binding issues we
> hit here. Subversion 1.6 + bindings surely is rather picky on Cygwin 1.5,
> as discussed earlier on this list.
As an update, Git-SVN 1.6.4.0 and 1.6.4.1 haven't seen such problems last
night when run on Ubuntu Linux.
So, the common idea set is apparently down to (a) intermittent server
issues (I've asked for the relevant log excerpts) and (b) Cygwin issues,
and we should keep in mind (c) git-svn, or svn bindings/libraries, losing
the causes error conditions from (a) or (b) and git-svn just reporting
later symptoms (absent files). More on the other experiments once I get
around to them.
Thanks
Matthias
^ permalink raw reply
* Re: [PATCH 08/14] Test for WIN32 instead of __MINGW32_
From: Paolo Bonzini @ 2009-08-28 8:15 UTC (permalink / raw)
To: Marius Storm-Olsen; +Cc: Johannes.Schindelin, msysgit, git, lznuaa
In-Reply-To: <1e623b19b2df001919c83418fef89ef04d7b8dfe.1250860247.git.mstormo@gmail.com>
Since you are doing this, you may as well change patch 3 from
+#if (defined(__MINGW32__) && defined(__GNUC__) && __GNUC__ < 4) ||
defined(_MSC_VER)
to this:
#if defined WIN32 && (!defined (__GNUC__) || __GNUC__ < 4))
Paolo
^ permalink raw reply
* Re: Using git to track my PhD thesis, couple of questions
From: Paolo Bonzini @ 2009-08-28 8:34 UTC (permalink / raw)
To: Matthieu Moy; +Cc: seanh, git
In-Reply-To: <vpqk50pasek.fsf@bauges.imag.fr>
On 08/27/2009 10:55 PM, Matthieu Moy wrote:
> seanh<seanh.nospam@gmail.com> writes:
>
>> I'm planning to use git to track my PhD thesis as I work on it and to
>> let my supervisors track it. I've setup a git repository and a gitweb
>> instance showing it. There are a couple of specific requirements.
>>
>> 1. My supervisors don't want to see all the little commits that I make
>> day by day.
>
> I'm not sure I understand why you want that. From what you say, your
> supervisors won't be looking at the LaTeX source, so they won't read
> the diffs for the commits. Instead, they will be looking at regular
> snapshots in PDF. So, how is that disturbing to keep the intermediate
> commits ?
>
>> So I'll commit to a dev branch, then whenever I've made
>> significant progress will merge it into a trunk branch. I want the trunk
>> branch to get all the changes but as one big commit, not inherit all the
>> little commits like a normal merge would do. I think this is a `git
>> merge --squash`.
>
> It is, but this also means _you_ will somehow lose your intermediate
> commits. Well, you may not really lose them, but after a merge
> --squash, you have two options to continue working: work on top of the
> squashed commit (and then your ancestry doesn't contain the small
> ones), or work on top of your previous branches (and then, you don't
> have a proper merge tracking, and you'll get spurious conflicts if you
> try another merge --squash).
You can also merge from the master to your working branch after every
merge --squash.
... work on local ...
git commit
... work on local ...
git commit
git checkout master
git merge --squash local; git commit -m'day 1'
git checkout local
git merge master
> I also used a revision control system to write my Ph.D (Git was born
> after I started writting, so it wasn't Git yet), and my reviewing
> system has been all the more simple: when a chapter is done, send an
> email with the PDF attached, and "Hi, chapter $n is done, can you have
> a look?". That just works.
That's the same I did. I used git, but only locally. I never published
the repository for my supervisor, she didn't care.
>> Normally I wouldn't commit the PDF files into the repo because
>> they're compiled files not source files, but it seems that just
>> building a PDF and committing it along with each commit to trunk
>> would be by far the easiest way to achieve this. But will git store
>> the PDFs efficiently, or will the repo start to get really big?
>
> Git will do delta-compression as it can, but I don't think PDFs will
> delta-compress very well, so your repository may grow rather quickly,
> yes. If possible, commit the PDFs on a separate branch so that you can
> easily keep your clean history small in disk space, and discard the
> PDFs if needed.
That's a good advice. Remember to delete the branch reflog too if you
want to clean the history.
You can also try \pdfcompresslevel=0, which would probably make
delta-compression behave better at the expense of distributing bigger
files to your supervisor. If you use hyperref, see this:
http://www.tug.org/pipermail/pdftex/2003-August/004402.html
Best of all would be to have filters doing/undoing the PDF compression,
but I know of no free program doing this.
Paolo
^ 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
* 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: [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: [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: [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
* 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: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
* 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: [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: [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: 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
* [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: [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
* 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
* 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: [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
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