* Re: Anybody home?
From: Joshua Stoutenburg @ 2011-09-15 9:01 UTC (permalink / raw)
To: Johannes Sixt; +Cc: Git List
In-Reply-To: <4E71A5FF.5040807@viscovery.net>
> Reading your exchanges elsewhere in this thread, I think you missed that
> you don't need a git server at all just to *use* git.
>
> Even when you want to exchange your commits between two or three machines,
> all you need is ssh access. There is no *git server* necessary. git is not
> svn. ;-)
>
> I thought I'd just mention this to help you streamline your search.
>
> -- Hannes
>
I read the first four and a half chapters from the Pro Git book pdf.
So I think I understood that much.
But in my situation, I do need a server so that other developers can
access anytime over the internet.
I should have mentioned that.
^ permalink raw reply
* Re: git gc exit with out of memory, malloc failed error
From: Carlos Martín Nieto @ 2011-09-15 9:16 UTC (permalink / raw)
To: Brandon Casey; +Cc: git, Alexander Kostikov
In-Reply-To: <CA+sFfMdXLkSE_RXB28TSx0JpPVjwe1Rf+03TkiT2YJjYH7m9MQ@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 994 bytes --]
On Wed, 2011-09-14 at 21:29 -0500, Brandon Casey wrote:
> [resend since gmail's Rich formatting was enabled]
>
> On Wed, Sep 14, 2011 at 8:33 PM, Alexander Kostikov
> <alex.kostikov@gmail.com> wrote:
> >
> > I'm new to git and I'm getting the following out of memory error on git gc:
> >
> > $ git gc
> > Counting objects: 80818, done.
> > Delta compression using up to 8 threads.
> > fatal: Out of memory, malloc failed (tried to allocate 24359675 bytes)
> > error: failed to run repack
>
> Try reducing the number of threads that are used. You must have some
> pretty large objects if you have 24GB and ran out of memory. The
IIRC the 32-bit Windows builds limit each user process to 2GB. If
msysgit is built in 32-bit mode, it's possible (probable even, in order
to remain backwards-compatible) that it's hitting this limit, rather
than the physical limit of the machine. If it's using 8 threads, it
means that there are 256MB available for each thread.
cmn
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 490 bytes --]
^ permalink raw reply
* Re: Anybody home?
From: Joshua Stoutenburg @ 2011-09-15 9:42 UTC (permalink / raw)
To: Joshua Stoutenburg; +Cc: Johannes Sixt, Git List
In-Reply-To: <201109150948.09040.trast@student.ethz.ch>
On Thu, Sep 15, 2011 at 12:48 AM, Thomas Rast <trast@student.ethz.ch> wrote:
> Johannes Sixt wrote:
>> Even when you want to exchange your commits between two or three machines,
>> all you need is ssh access. There is no *git server* necessary. git is not
>> svn. ;-)
>
> I'd even put this somewhat more bluntly. My two-step advice on
> switching from svn to git is:
>
> 1) forget *everything* you know from SVN
> 2) learn git as usual
>
> I don't hang out on IRC as much any more, so maybe it got better. But
> 90%[*] of SVN convert's problems seem to stem from some preconceived
> notions they carried over from SVN.
>
> Such as, "HEAD is the newest commit". Or the whole centralized
> vs. distributed you mentioned.
>
>
>
> [*] 78% of all statistics were made up on the spot
>
> --
> Thomas Rast
> trast@{inf,student}.ethz.ch
>
How can I "learn git as usual"?
I don't think I was on Subversion long enough to permanently damage my
brain. Only a few months (actually . . . that's probably enough). I
never used it's branching, tagging or merging features. Commit and
revert were the only that I used. Regardless, I'm happy to forget
everything I know about Subversion.
I've watched Linus Torvalds tech talk on git:
http://www.youtube.com/watch?v=4XpnKHJAok8
I also read four and a half chapters of Pro Git pdf:
http://progit.org/ebook/progit.pdf
I read and understood git for computer scientists:
http://eagain.net/articles/git-for-computer-scientists/
So I have a pretty good understanding why git is THE superior source
code management choice. And I have a basic understanding of how git
works. I know how to install a *nix server and can survive on the
CLI.
Here's where I think I'm having some troubles, and maybe you can help
me identify any others:
I got confused in Chapter 5 of the Pro Git pdf book, trying to discern
what needs to be done on the server, and what needs to be done on the
work station. The chapter seems to jump around a bit, and doesn't
follow a linear pattern. Maybe I need to read it more carefully?
Also, I'm not clear on the best way to manage large numbers of git
users (like 12-24), who also may have permissions to other services as
well (ftp, databases, email, etc). I have some hesitancy creating
each one manually on the CLI.
Finally, I'm not sure how to "learn git as usual". Point me in the
right direction, please.
^ permalink raw reply
* Re: Anybody home?
From: Carlos Martín Nieto @ 2011-09-15 9:43 UTC (permalink / raw)
To: Joshua Stoutenburg; +Cc: Johannes Sixt, Git List
In-Reply-To: <CAOZxsTqGt=gYr3t7e5Ma4z6W9wt_JxrgsNSGFGVbtk2rc3LZ9w@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 1158 bytes --]
On Thu, 2011-09-15 at 02:01 -0700, Joshua Stoutenburg wrote:
> > Reading your exchanges elsewhere in this thread, I think you missed that
> > you don't need a git server at all just to *use* git.
> >
> > Even when you want to exchange your commits between two or three machines,
> > all you need is ssh access. There is no *git server* necessary. git is not
> > svn. ;-)
> >
> > I thought I'd just mention this to help you streamline your search.
> >
> > -- Hannes
> >
>
> I read the first four and a half chapters from the Pro Git book pdf.
> So I think I understood that much.
>
> But in my situation, I do need a server so that other developers can
> access anytime over the internet.
If the code shouldn't be made public, then you should take a look at
gitolite[0]. Otherwise, you can just host it on gitorious.org or
github.com
[0] https://github.com/sitaramc/gitolite
cmn
>
> I should have mentioned that.
> --
> To unsubscribe from this list: send the line "unsubscribe git" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 490 bytes --]
^ permalink raw reply
* Problems with format-patch UTF-8 and a missing second empty line
From: Ingo Ruhnke @ 2011-09-15 9:45 UTC (permalink / raw)
To: git
Creating a patch of a commit including UTF-8 and no empty second line,
like this:
mkdir foobar
cd foobar
git init
echo "Hello World" > file
git add file
git commit -m "ÄÖÜ
ÄÖÜ" file
git format-patch --root HEAD --stdout
Results in this:
From f4f889bad560c479a70fbf5f70a4239576001262 Mon Sep 17 00:00:00 2001
From: Ingo Ruhnke <grumbel@gmail.com>
Date: Thu, 15 Sep 2011 11:25:11 +0200
Subject: [PATCH] =?UTF-8?q?=C3=84=C3=96=C3=9C
=20=C3=84=C3=96=C3=9C?=
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
...
Trying to apply the patch then results in this:
$ git am /tmp/foobar/0001-.patch
Applying: =?UTF-8?q?=C3=84=C3=96=C3=9C
applying to an empty history
$ git log
commit 6f27fc51a8c52fdb595131a934d8d56c9df3b5c0
Author: Ingo Ruhnke <grumbel@gmail.com>
Date: Thu Sep 15 11:27:47 2011 +0200
=?UTF-8?q?=C3=84=C3=96=C3=9C
=20=C3=84=C3=96=C3=9C?=
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
The UTF-8 stuff doesn't get decoded and the log message ends up broken.
The problem seems to already start with just the lack of an empty second line:
mkdir foobar
cd foobar
git init
echo "Hello World" > file
git add file
git commit -m "ABC
ABC" file
git format-patch --root HEAD --stdout
From 3abc0e59abc4c9343d22e79575e02910073d1013 Mon Sep 17 00:00:00 2001
From: Ingo Ruhnke <grumbel@gmail.com>
Date: Thu, 15 Sep 2011 11:31:03 +0200
Subject: [PATCH] ABC
ABC
$ git am /tmp/foobar/0001-ABC.patch
Applying: ABC ABC
applying to an empty history
ingo@duo:/tmp/5/bar$ git log | cat
commit eb8a9e9a1421ae6d930d99bfb8f2eab47349c387
Author: Ingo Ruhnke <grumbel@gmail.com>
Date: Thu Sep 15 11:31:03 2011 +0200
ABC ABC
Here the newline between ABC\nABC gets stripped out and replaced with
a space when transferring the commit with format-patch from one
repository to another.
Inserting an empty second line in the commit message makes both
problems go away.
Another small issue is that the filename of the patch will strip out
any UTF-8 characters, Thus a commit message of "123Äöü456" will result
in "0001-123-456.patch".
The problems happen with git version 1.7.4.1 (4b5eac7f0) on Ubuntu 11.04.
--
Blog: http://grumbel.blogspot.com/
JabberID: xmpp:grumbel@jabber.org
ICQ: 59461927
^ permalink raw reply
* Re: Anybody home?
From: Joshua Stoutenburg @ 2011-09-15 9:51 UTC (permalink / raw)
To: Carlos Martín Nieto; +Cc: Johannes Sixt, Git List
In-Reply-To: <1316079837.2019.18.camel@bee.lab.cmartin.tk>
On Thu, Sep 15, 2011 at 2:43 AM, Carlos Martín Nieto <carlos@cmartin.tk> wrote:
> If the code shouldn't be made public, then you should take a look at
> gitolite[0]. Otherwise, you can just host it on gitorious.org or
> github.com
>
> [0] https://github.com/sitaramc/gitolite
>
> cmn
>
Thank you.
This looks very useful.
^ permalink raw reply
* Re: Fwd: vcs-svn and friends
From: Jonathan Nieder @ 2011-09-15 10:01 UTC (permalink / raw)
To: David Michael Barr; +Cc: Junio C Hamano, Dmitry Ivankov, git
In-Reply-To: <CAFfmPPOBZ6cXG51mDHbj2VRDzjvH46Q7=_LvUWeMq0SGR40S1g@mail.gmail.com>
David Michael Barr wrote:
> Thanks to the work of Dmitry, we now have a simple front-end
> that exercises the yet unmerged changes to vcs-svn that Jonathan
> and I authored a few months ago. I think there's still some work
> to be done before we can bless an integrated branch for inclusion.
> I'd like to bring attention to just how far we have diverged; see the
> email below.
Quick thoughts:
- everything up to c5bcbcdc looks good to me (as you might expect)
- later patches seem to be missing your sign-off. Is this deliberate
(as in: "withholding sign-off as a hint that these haven't received
their final review yet") or an oversight?
- f4472ae61 ("fast-import: be saner with temporary trees"): when I
looked it over in $gmane/178043, I acked the patch, but not the
change description. Re-reading the patch, I've completely forgotten
what it does and the commit message doesn't help. What user-visible
effect would the patch have, if any?
Reading over $gmane/178043, I learn:
- new_tree_entry() returns a tree entry from a stack of trees used
as temporaries. Initializing them before use is indeed the
caller's responsibility.
- parse_ls() uses the following idiom to retrieve content named by
a tree-ish and path within it:
struct tree_entry result = {0};
struct tree_entry *root;
root = new_tree_entry();
hashcpy(root->versions[1].sha1, treeish_name);
load_tree(root);
tree_content_get(root, path, &result);
release_tree_entry(root);
This method that populates "root" only to free it moments later
is somewhat wasteful --- it would be nicer to stop parsing each
tree when the appropriate entry is found, which would speed up
commands in the input stream like
ls 78a7c87aabc78acb7887c89a98c87ca87ca8ca89 a/a/a/a/a/a/a
when the relevant trees have many entries. Oh well.
This patch is about a detail in that sequence --- the temporary
tree entry "root" just mentioned has uninitialized fields, such
as versions[0].sha1. Nobody accesses them, though, and the result
from tree_content_get() which is the important thing has no
uninitialized fields. So this patch is about futureproofing or
code clarity rather than an actual functional change.
Would it be possible to suggest a new change description that
clarifies that?
- 3bba32e9 ("fast-import: allow top directory as an argument for some
commands"): I'm not sure what the motivation is --- is this just
about the principle of least surprise, or did it come up in practice
somewhere?
The change description could use some examples and a reference to
the earlier related work it seems to be inspired by ("fast-import:
Allow filemodify to set the root"). It would also be nice to
update the manpage to document the change at the same time.
- e9e480e7 ("vcs-svn,svn-fe: convert REPORT_FILENO to an option") has
nested quote marks in the test.
The motivating comment "Moreover it may require noticeable effort
to setup this descriptor, if number 3 is already taken for example"
is unjustified --- system("foo 3>wherever") or { fork();
dup2(wherever, 3); execlp("foo", ...) } does not look noticeably
difficult to me, though maybe there is some unexplained detail that
makes this require more effort in some circumstance.
Ok, I notice I am starting to nitpick. Better to make a global
comment: the change descriptions do not currently motivate each change
in a straightforward way. I'd be glad to help with that by providing
feedback and examples where appropriate if help is needed. I believe
that fixing this can make other pieces that need fixing easier to find
when they exist.
Thanks for your help,
Jonathan
^ permalink raw reply
* Re: git credential helper design [
From: Ted Zlatanov @ 2011-09-15 10:47 UTC (permalink / raw)
To: git
In-Reply-To: <CAEBDL5UGhanJboiT2SppeXa6UaKbE1MOpajf9wSaQCkR9EdRYw@mail.gmail.com>
On Tue, 13 Sep 2011 04:29:30 -0400 John Szakmeister <john@szakmeister.net> wrote:
JS> On Sat, Sep 10, 2011 at 2:53 AM, Jeff King <peff@peff.net> wrote:
>> On Fri, Sep 09, 2011 at 05:55:38AM -0400, John Szakmeister wrote:
>>
>>> A little feedback here: I do look into my keychain on Mac OS X. I
>>> tend to keep most of my credentials in a separate keychain that gets
>>> whenever my computer sleeps or the screen saver kicks on. So that
>>> blob ends up being user-visible to some degree. Could I munge it into
>>> something else? Sure. But I do wonder if it might be better to make
>>> it something closer to what the user expects to see.
>>
>> Sure, I agree. I guess my question is: what does the user expect to see?
JS> Originally I was going to use SecKeychainFindGenericPassword(), and
JS> the token would have been the "serviceName". However,
JS> SecKeychainFindInternetPassword() is clearly the better fit, which
JS> means busting out the individual bits.
I would make it work like Safari, period.
JS> [snip]
>> Perhaps it's worth providing the information in two forms: parsed and
>> broken out by individual pieces, and as a more opaque blob. Then systems
>> which care can use the pieces, and systems which are trying to be as
>> simple as possible can use the blob.
JS> That would be useful. Right now, it looks like I'll be parsing the token.
>> That still leaves the question of how the user specifies policy about
>> which parts of the blob are relevant. That is, how do they say that only
>> the "domain" portion of the hostname is relevant? Or that the path is or
>> is not relevant?
>>
>> I was really hoping for the user to be able to specify this at the git
>> level, to give each storage helper roughly the same feature set.
JS> Ooh... yeah, I'm not sure. :-(
I posted a simple proposal for auth domains, which would introduce an
extra abstraction layer between the URL and the credential helper. I
think that would help.
>> Maybe it would be enough to do something like:
>>
>> 1. Assemble all of the parts (protocol, username (if any), hostname,
>> path) into a canonicalized URL representing the authentication
>> context.
>>
>> 2. Look for git config matching the context URL, and allow
>> transformations (e.g., match and replace the whole thing, or even
>> regexp-style substitution).
JS> That seems burdensome. There is a method in HTTP/HTTPS for saying
JS> "use this set of credentials". You'd do that via the security domain.
JS> That doesn't necessarily apply to other urls (ssh, for example), but
JS> it would allow a storage backend to cache it for a specific path, but
JS> fallback to looking up the credential using the security domain.
The HTTP security domain is set by the remote, not the Git user, and so
is neither customizable nor reliable, unfortunately. Also as you
mentioned it won't work for non-HTTP URLs, and it is determined late in
the process, perhaps too late for some helpers.
Ted
^ permalink raw reply
* Re: Anybody home?
From: Miles Bader @ 2011-09-15 10:54 UTC (permalink / raw)
To: Carlos Martín Nieto; +Cc: Joshua Stoutenburg, Johannes Sixt, Git List
In-Reply-To: <1316079837.2019.18.camel@bee.lab.cmartin.tk>
Carlos Martín Nieto <carlos@cmartin.tk> writes:
> If the code shouldn't be made public, then you should take a look at
> gitolite[0]. Otherwise, you can just host it on gitorious.org or
> github.com
Hmm, of course if you're willing to pay, github will also host private
code (maybe useful if your devs love teh shiny......).
-miles
--
One of the lessons of history is that nothing is often a good thing to
do, and always a clever thing to say. -- Will Durant
^ permalink raw reply
* Re: Branching strategies
From: Jakub Narebski @ 2011-09-15 11:07 UTC (permalink / raw)
To: robert mena; +Cc: git
In-Reply-To: <CAAZ43xaFzJWzPsqhP0QDRTP0Ea-dMpCpr1vDiujFFn94j+SRCQ@mail.gmail.com>
robert mena <robert.mena@gmail.com> writes:
> I have a project where I have to do a continuous integration, adding
> features/making changes on a daily basis. Some changes are one liners
> with no functionality just, for example, textual changes or a new
> button. Some are actual features or bug fixes.
>
> So today my developers do their business and publish the changes in a
> beta site where the customer or the qa takes a look. The problem is
> a standard one. Sometimes features stay already developed (waiting
> for review) for a long time and other changes/features get approved
> first.
>
> Since some of those can touch the same files how can I make this a
> little bit better (manageable)?
>
> I am considering doing feature branches. The customer requests to
> add feature A I open a bug tracking issue and create a branch 1276
> corresponding to the bug id.
>
> In my simply view I'd have a master/live branch and every time I need
> to create a new branch I do it from here. When the developer is happy
> he merges his branch with a beta branch where the Q&A/customer review
> is done.
>
> When this review gets an OK he merges his feature branch with the live
> one, redo the tests and publish.
>
> I'd really appreciate feedback for this specially for the weak points
> and known problems of my approach with alternatives :)
The "Version Control by Example" by Eric Sink, http://www.ericsink.com/vcbe/
contains chapter about workflows, including feature branch workflow.
Junio Hamano blog (the old version) included a few articles about
using feature-branch workflow too.
HTH.
--
Jakub Narębski
^ permalink raw reply
* Re: Anybody home?
From: Jakub Narebski @ 2011-09-15 11:04 UTC (permalink / raw)
To: Joshua Stoutenburg; +Cc: Michael Witten, Git List
In-Reply-To: <CAOZxsTrsi5mNdm8OgvfXyYwj1T4Vw3HfQGN-5Dsb+QnX0nz4ag@mail.gmail.com>
Couldn't you pick up less descriptive subject ;-) ?
Joshua Stoutenburg <jehoshua02@gmail.com> writes:
> On Wed, Sep 14, 2011 at 9:48 PM, Michael Witten <mfwitten@gmail.com> wrote:
>> On Thu, Sep 15, 2011 at 04:24, Joshua Stoutenburg <jehoshua02@gmail.com> wrote:
>>> I'm having a hard time understanding clearly how to set up a git
>>> server and configure my local machine to pull and push to it.
> There seems to be a plethora of documentation on git from various sources.
>
> See what I mean:
> http://git-scm.com/documentation
> http://progit.org/book/
> http://gitref.org/
> http://www.kernel.org/pub/software/scm/git/docs/gittutorial.html
> http://www.kernel.org/pub/software/scm/git/docs/everyday.html
> http://git-scm.com/course/svn.html
> http://hoth.entp.com/output/git_for_designers.html
> http://eagain.net/articles/git-for-computer-scientists/
> http://www.kernel.org/pub/software/scm/git/docs/user-manual.html
> http://www-cs-students.stanford.edu/~blynn/gitmagic/
> http://help.github.com/
> http://www.kernel.org/pub/software/scm/git/docs/
> http://refcardz.dzone.com/refcardz/getting-started-git
>
> Which source makes the least amount of assumptions and offers all the
> juicy details for configuring git on the server, and git on the local
> machine, without any fluff?
>
> I'm looking for a solid guide. Not a novel. Not a pamphlet.
I think that either "Pro Git" book, or "The Git Community Book"
would be a best source to learn about setting-up git server.
I think the simplest solution for git hosting management would be to
use gitolite (there are other git repository management software:
Gitosis, SCM Manager, Gitblit).
If you want to host something like GitHub, there are open source
solutions too: Gitorious, InDefero, Girocco + gitweb,...
HTH
--
Jakub Narębski
^ permalink raw reply
* Re: Anybody home?
From: Carlos Martín Nieto @ 2011-09-15 11:34 UTC (permalink / raw)
To: Miles Bader; +Cc: Joshua Stoutenburg, Johannes Sixt, Git List
In-Reply-To: <buoty8e3wjq.fsf@dhlpc061.dev.necel.com>
[-- Attachment #1: Type: text/plain, Size: 563 bytes --]
On Thu, 2011-09-15 at 19:54 +0900, Miles Bader wrote:
> Carlos Martín Nieto <carlos@cmartin.tk> writes:
> > If the code shouldn't be made public, then you should take a look at
> > gitolite[0]. Otherwise, you can just host it on gitorious.org or
> > github.com
>
> Hmm, of course if you're willing to pay, github will also host private
Indeed, if you give them a bit of money they'll take care of everything
and you can have your private code there.
> code (maybe useful if your devs love teh shiny......).
Teh Shiny is powerful :)
cmn
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 490 bytes --]
^ permalink raw reply
* zealous git convert determined to set up git server
From: Joshua Stoutenburg @ 2011-09-15 11:38 UTC (permalink / raw)
To: Jakub Narebski; +Cc: Git List
Breaking away from previous conversation "Anybody home?"
2011/9/15 Jakub Narebski <jnareb@gmail.com>:
> I think that either "Pro Git" book, or "The Git Community Book"
> would be a best source to learn about setting-up git server.
>
> I think the simplest solution for git hosting management would be to
> use gitolite (there are other git repository management software:
> Gitosis, SCM Manager, Gitblit).
>
> If you want to host something like GitHub, there are open source
> solutions too: Gitorious, InDefero, Girocco + gitweb,...
>
> HTH
> --
> Jakub Narębski
>
>
I totally didn't see "The Git Community Book". There's no link for it
where I was looking: http://git-scm.com/documentation
As for setting up a work station, I found a pretty good guide at GitHub:
Windows: http://help.github.com/win-set-up-git/
Linux: http://help.github.com/linux-set-up-git/
Question 1: With both "Pro Git" and "The Git Community Book", has
anybody noticed any major discrepancies between the pdf and online
versions? I'd like to place the pdf versions on my mobile device for
travel reading.
Question 2: It seems gitolite is the popular choice for git user
management. Any reason why?
Question 3: So, Gitorious is more than just a repository hosting
website? It's also an open source repository hosting platform, which
powers the Gitorious website? That's pretty cool.
^ permalink raw reply
* Re: Anybody home?
From: Joshua Stoutenburg @ 2011-09-15 12:01 UTC (permalink / raw)
To: Carlos Martín Nieto; +Cc: Git List
In-Reply-To: <1316086486.2019.20.camel@bee.lab.cmartin.tk>
On Thu, Sep 15, 2011 at 4:34 AM, Carlos Martín Nieto <carlos@cmartin.tk> wrote:
> On Thu, 2011-09-15 at 19:54 +0900, Miles Bader wrote:
>> Carlos Martín Nieto <carlos@cmartin.tk> writes:
>> > If the code shouldn't be made public, then you should take a look at
>> > gitolite[0]. Otherwise, you can just host it on gitorious.org or
>> > github.com
>>
>> Hmm, of course if you're willing to pay, github will also host private
>
> Indeed, if you give them a bit of money they'll take care of everything
> and you can have your private code there.
>
>> code (maybe useful if your devs love teh shiny......).
>
> Teh Shiny is powerful :)
>
> cmn
>
>
Unfamiliar with the term "Teh Shiny". Had to look it up. Found this:
http://www.claassen.net/geek/blog/2009/09/teh-shiny.html
I think I have a tendency to avoid "Teh Shiny" because it ruins all the fun.
I think I could easily figure out how to host my own repos, save some
money, and have my own "Teh Shiny".
If I didn't care about saving money, and had a project that needed a
repo immediately, I'd probably give in and pay a little.
^ permalink raw reply
* [PATCH] Un-static gitmkstemps
From: Brian Gernhardt @ 2011-09-15 12:21 UTC (permalink / raw)
To: Git List; +Cc: Junio C Hamano
It may not be used in most builds, but it's used via a #ifdef in
git-compat-util.h Also, making it static makes a -Wall compile fail
since it's not used in the file without NO_MKSTEMPS.
Signed-off-by: Brian Gernhardt <brian@gernhardtsoftware.com>
---
Either this, or it should be removed from git-compat-util and wrapped in
an #ifdef. (The only current user is git_mkstemps), but since it's
referenced in a header file, I figured it shouldn't be static.
wrapper.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/wrapper.c b/wrapper.c
index 390a7ae..1c41488 100644
--- a/wrapper.c
+++ b/wrapper.c
@@ -310,7 +310,7 @@ int git_mkstemp_mode(char *pattern, int mode)
return git_mkstemps_mode(pattern, 0, mode);
}
-static int gitmkstemps(char *pattern, int suffix_len)
+int gitmkstemps(char *pattern, int suffix_len)
{
return git_mkstemps_mode(pattern, suffix_len, 0600);
}
--
1.7.7.rc0.309.g13ed2.dirty
^ permalink raw reply related
* Re: [PATCH] t6019: avoid refname collision on case-insensitive systems
From: Brad King @ 2011-09-15 12:45 UTC (permalink / raw)
To: Thomas Rast; +Cc: Junio C Hamano, git
In-Reply-To: <02451a2849fc8f1cab7983b6c8c629ebb6a1aaa9.1316075573.git.trast@student.ethz.ch>
On 9/15/2011 4:34 AM, Thomas Rast wrote:
> The criss-cross tests kept failing for me because of collisions of 'a'
> with 'A' etc. Prefix the lowercase refnames with an extra letter to
> disambiguate.
Thanks.
-Brad
^ permalink raw reply
* Re: Anybody home?
From: Ted Ts'o @ 2011-09-15 12:55 UTC (permalink / raw)
To: Joshua Stoutenburg; +Cc: Michael Witten, Git List
In-Reply-To: <CAOZxsTr+mC9cajGa21d1sqKBEB+sUhsBOHoTuVj1D+6uTFTL6g@mail.gmail.com>
On Wed, Sep 14, 2011 at 10:06:58PM -0700, Joshua Stoutenburg wrote:
> Also, I noticed the entire kernel.org website is down. Any idea how
> long it's been like that or when/if it will come back up? What's
> Linus up to?
It's down for maintenance after a security breach.
https://lwn.net/Articles/458099/
- Ted
^ permalink raw reply
* Re: Fwd: vcs-svn and friends
From: Dmitry Ivankov @ 2011-09-15 13:00 UTC (permalink / raw)
To: Jonathan Nieder; +Cc: David Michael Barr, Junio C Hamano, git
In-Reply-To: <20110915100106.GB2328@elie>
> - 3bba32e9 ("fast-import: allow top directory as an argument for some
> commands"): I'm not sure what the motivation is --- is this just
> about the principle of least surprise, or did it come up in practice
> somewhere?
(to ease one's reading, commands are ls, copy and move top directory)
Haven't seen them in practice. It seemed possible with svn import: if there were
no branches at start, and then someone did svn mv . trunk. But it
turns out that my
svn client doesn't allow such move. So more like a least surprise purpose.
^ permalink raw reply
* Re: Anybody home?
From: Martin Langhoff @ 2011-09-15 13:17 UTC (permalink / raw)
To: Joshua Stoutenburg; +Cc: Johannes Sixt, Git List
In-Reply-To: <CAOZxsTrxPZ1V+_W=trRpOTJ9emh8msreGOyAYm_1hs0zXaOd1w@mail.gmail.com>
On Thu, Sep 15, 2011 at 5:42 AM, Joshua Stoutenburg
<jehoshua02@gmail.com> wrote:
> I got confused in Chapter 5 of the Pro Git pdf book, trying to discern
> what needs to be done on the server, and what needs to be done on the
> work station
OK - some hints:
1 - For private code, or public code where you value the service, you
can use the commercial services out there, that's easy
2 - For public/foss code, with low/simple service expectations, you
can get free hosting
3 - For a private setup... the normal thing is to use git over ssh, so
the server should be reachable by your users, and your users need an
ssh account. You will want to setup a group ("gituser") and create a
directory ("/git") owned by that group, writable by the group, with
sticky group mode.
To create a new project repo, ssh into the server and say git
--git-dir /git/fooproject init --shared . It will be empty -- on a
user workstation create your first commit, and push it into the (so
far empty) repo with git push git+ssh://hostname/git/fooproject master
.
On the server you can add a gitweb or cgit install for browsability.
If you want to allow anonymous users to access your git repos in
readonly mode, you can setup the git "service", with xinetd. That
allows you to tell people "git clone git://hostname/fooproject" .
Careful when configuring network services if the host is public, you
don't want to serve git://host/etc/shadow :-)
This is what most "git servers" do -- it works in your company
network, it also works for a public FOSS project with anon readers and
a handful of ssh-authenticated committers.
(For a project using a more distributed model of
one-developer-one-repo, you follow the same setup but perhaps make
per-developer directories.)
4 - You _can_ do git over http, instead of ssh, but I suspect the
setup is more involved. In any case, others will have to fill in.
> Also, I'm not clear on the best way to manage large numbers of git
> users (like 12-24), who also may have permissions to other services as
> well (ftp, databases, email, etc). I have some hesitancy creating
> each one manually on the CLI.
CLI is generally fine :-) if you contract a hosting server that gives
you email/db/ftp and has a webbased admin UI, all you need
"additional" is to ensure you can manage ssh accounts with ease.
cheers,
m
--
martin.langhoff@gmail.com
martin@laptop.org -- Software Architect - OLPC
- ask interesting questions
- don't get distracted with shiny stuff - working code first
- http://wiki.laptop.org/go/User:Martinlanghoff
^ permalink raw reply
* Re: vcs-svn and friends
From: Stephen Bash @ 2011-09-15 14:06 UTC (permalink / raw)
To: David Michael Barr; +Cc: Jonathan Nieder, Dmitry Ivankov, git, Junio C Hamano
In-Reply-To: <CAFfmPPOBZ6cXG51mDHbj2VRDzjvH46Q7=_LvUWeMq0SGR40S1g@mail.gmail.com>
----- Original Message -----
> From: "David Michael Barr" <davidbarr@google.com>
> Sent: Wednesday, September 14, 2011 9:53:53 PM
> Subject: Fwd: vcs-svn and friends
>
> Thanks to the work of Dmitry, we now have a simple front-end
> that exercises the yet unmerged changes to vcs-svn that Jonathan
> and I authored a few months ago.
For those of us interested but out of the loop, does this mean you have a working example where I can point it at a SVN repo and see what happens? Having done our SVN to Git conversion last year, I know our repo has a lot of the common SVN screw cases (non-branching copies, partial merges, mis-merges, *lots* of retagging, changes committed to tags, etc.) so if it's relatively easy to setup a test I'm happy to run one.
Thanks,
Stephen
^ permalink raw reply
* Re: Anybody home?
From: Scott Chacon @ 2011-09-15 15:04 UTC (permalink / raw)
To: Joshua Stoutenburg; +Cc: Johannes Sixt, Git List
In-Reply-To: <CAOZxsTqGt=gYr3t7e5Ma4z6W9wt_JxrgsNSGFGVbtk2rc3LZ9w@mail.gmail.com>
Hey,
On Thu, Sep 15, 2011 at 2:01 AM, Joshua Stoutenburg
<jehoshua02@gmail.com> wrote:
>> Reading your exchanges elsewhere in this thread, I think you missed that
>> you don't need a git server at all just to *use* git.
>>
>> Even when you want to exchange your commits between two or three machines,
>> all you need is ssh access. There is no *git server* necessary. git is not
>> svn. ;-)
>>
>> I thought I'd just mention this to help you streamline your search.
>>
>> -- Hannes
>>
>
> I read the first four and a half chapters from the Pro Git book pdf.
> So I think I understood that much.
>
> But in my situation, I do need a server so that other developers can
> access anytime over the internet.
>
> I should have mentioned that.
I guess I'm confused. The fourth chapter of the Pro Git book is
entirely about setting up your own Git server, including basically
step by step instructions on Gitolite and Gitosis, in addition to
simply running your own ssh-based server plus gitweb. It is like 20
pages long - how is this not exactly what you're asking for?
Scott
^ permalink raw reply
* Re: [tig] Feeding specific revisions to tig
From: Jean-Baptiste Quenot @ 2011-09-15 15:10 UTC (permalink / raw)
To: Jonas Fonseca; +Cc: git
In-Reply-To: <2c6b72b30904270321t3d73e2c5o5e3ac8d4b627e5ab@mail.gmail.com>
2009/4/27 Jonas Fonseca <jonas.fonseca@gmail.com>:
> Sorry for the slow reply ...
>
> On Thu, Apr 23, 2009 at 16:55, Jean-Baptiste Quenot <jbq@caraldi.com> wrote:
>> Restarting this old thread again. Starting from 0.13 the
>> *tignowalk()* hack does not work anymore. What's the preferred way to
>> feed specific revisions using stdin now?
>
> I don't know if it is preferred, but it works. First add a git alias:
>
> [alias]
> tignowalk-helper = !git rev-list --pretty=raw --no-walk --stdin<
>
> Then modify tignowalk by replacing the line calling tig to say:
>
> TIG_MAIN_CMD="git tignowalk-helper $tmp" tig </dev/tty
>
> ... and it should work. Maybe more git alias functionality can
> simplify the hack.
Restarting this thread again... it seems like every new version of tig
breaks this usecase :-)
Any idea how to feed specific revisions to tig 0.18? The trick does
not work anymore, as support for TIG_MAIN_CMD was dropped.
--
Jean-Baptiste Quenot
^ permalink raw reply
* Re: Problems with format-patch UTF-8 and a missing second empty line
From: Jeff King @ 2011-09-15 15:17 UTC (permalink / raw)
To: Ingo Ruhnke; +Cc: git
In-Reply-To: <CAHz1FYgPuMHLC+f2mFqD73=NGXQSStRPDOsiCy-HtaWKbHu7NQ@mail.gmail.com>
On Thu, Sep 15, 2011 at 11:45:15AM +0200, Ingo Ruhnke wrote:
> Creating a patch of a commit including UTF-8 and no empty second line,
> like this:
> [...]
> Results in this:
> [...]
> Subject: [PATCH] =?UTF-8?q?=C3=84=C3=96=C3=9C
> =20=C3=84=C3=96=C3=9C?=
>[....]
> The problems happen with git version 1.7.4.1 (4b5eac7f0) on Ubuntu 11.04.
I'm pretty sure I fixed this in a1f6baa, which is in v1.7.4.4 and later.
-Peff
^ permalink raw reply
* Re: [PATCH 4/4] attr.c: respect core.ignorecase when matching attribute patterns
From: Brandon Casey @ 2011-09-15 15:38 UTC (permalink / raw)
To: Junio C Hamano; +Cc: peff, git, sunshine, bharrosh, trast, zapped
In-Reply-To: <7vobymqwjf.fsf@alter.siamese.dyndns.org>
On Wed, Sep 14, 2011 at 11:06 PM, Junio C Hamano <gitster@pobox.com> wrote:
>
> Junio C Hamano <gitster@pobox.com> writes:
> > An alternative approach may be to move reading of core.attributesfile to
> > default_config, and drop git_config() call from bootstrap_attr_stack(),
> > getting rid of git_attr_config callback altogether.
>
> That is, something like this on top of your patch.
Ok.
I'll send a reroll that slides this underneath my top patch, and
addresses Hanne's comment.
-Brandon
> attr.c | 15 ++-------------
> builtin/check-attr.c | 2 ++
> cache.h | 1 +
> config.c | 3 +++
> environment.c | 1 +
> 5 files changed, 9 insertions(+), 13 deletions(-)
^ permalink raw reply
* Re: [PATCH 2/4] cleanup: use internal memory allocation wrapper functions everywhere
From: Brandon Casey @ 2011-09-15 15:39 UTC (permalink / raw)
To: Johannes Sixt; +Cc: peff, git, gitster, sunshine, bharrosh, trast, zapped
In-Reply-To: <4E71A0C7.8080602@viscovery.net>
On Thu, Sep 15, 2011 at 1:52 AM, Johannes Sixt <j.sixt@viscovery.net> wrote:
> Am 9/15/2011 3:59, schrieb Brandon Casey:
>> The "x"-prefixed versions of strdup, malloc, etc. will check whether the
>> allocation was successful and terminate the process otherwise.
>>
>> A few uses of malloc were left alone since they already implemented a
>> graceful path of failure or were in a quasi external library like xdiff.
>>
>> Signed-off-by: Brandon Casey <drafnel@gmail.com>
>> ---
>> ...
>> compat/mingw.c | 2 +-
>> compat/qsort.c | 2 +-
>> compat/win32/syslog.c | 2 +-
>
> There is a danger that the high-level die() routine (which is used by the
> x-wrappers) uses one of the low-level compat/ routines. IOW, in the case
> of errors, recursion might occur. Therefore, I would prefer that the
> compat/ routines do their own error reporting (preferably via return
> values and errno).
Thanks. Will do.
-Brandon
^ 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