* Re: CGit and repository list
From: Lars Hjemli @ 2008-09-12 15:10 UTC (permalink / raw)
To: Petr Baudis; +Cc: Jakub Narebski, git, Kristian Høgsberg
In-Reply-To: <20080912145804.GF10544@machine.or.cz>
On Fri, Sep 12, 2008 at 4:58 PM, Petr Baudis <pasky@suse.cz> wrote:
> it seems that cgit
> requires all the repositories explicitly listed in the config file.
> Do you plan to remove this limitation in the future?
Not really, I'd rather add another command (or a commandline option)
to generate an include-file for cgitrc by scanning directory-trees for
git repos. I've CC'd Kristian since I believe he's got such a script
running for freedesktop.org; if so, maybe it could be included/used as
basis for something similar in cgit?
--
larsh
^ permalink raw reply
* Re: [RFC] origin link for cherry-pick and revert
From: Paolo Bonzini @ 2008-09-12 15:05 UTC (permalink / raw)
To: Theodore Tso
Cc: Stephen R. van den Berg, Linus Torvalds, Sam Vilain,
Jakub Narebski, git
In-Reply-To: <20080912145802.GV5082@mit.edu>
Theodore Tso wrote:
> On Fri, Sep 12, 2008 at 07:47:39AM +0200, Stephen R. van den Berg wrote:
>>> You could add it as a
>>> Original-patch-id: <sha1>
>> That will probably work fine when operating locally on (short) temporary
>> branches.
>>
>> It would probably become computationally prohibitive to use it between
>> long lived permanent branches. In that case it would need to be
>> augmented by the sha1 of the originating commit.
>
> Nope, as Sam suggested in his original message (but which got clipped
> by Linus when he was replying) all you have to do is to have a
> separate local database which ties commits and patch-id's together as
> a cache/index.
Yeah, I must admit I am okay with *this* cache.
Paolo
^ permalink raw reply
* Re: [RFC] origin link for cherry-pick and revert
From: Theodore Tso @ 2008-09-12 14:58 UTC (permalink / raw)
To: Stephen R. van den Berg
Cc: Linus Torvalds, Sam Vilain, Jakub Narebski, Paolo Bonzini, git
In-Reply-To: <20080912054739.GB22228@cuci.nl>
On Fri, Sep 12, 2008 at 07:47:39AM +0200, Stephen R. van den Berg wrote:
> >You could add it as a
>
> > Original-patch-id: <sha1>
>
> That will probably work fine when operating locally on (short) temporary
> branches.
>
> It would probably become computationally prohibitive to use it between
> long lived permanent branches. In that case it would need to be
> augmented by the sha1 of the originating commit.
Nope, as Sam suggested in his original message (but which got clipped
by Linus when he was replying) all you have to do is to have a
separate local database which ties commits and patch-id's together as
a cache/index.
I know you seem to be resistent to caches, but caches are **good**
because they are local information, which by definition can be
implementation-dependent; you can always generate the cache from the
git repository if for some reason you need to extend it. It also
means that if it turns out you need to index reationships a different
way, you can do that without having to make fundamental (incompatible)
changes in the git object.
It's much like SQL databases; you have your database tables, where
making changes to the database schema is painful --- and indexes,
which can be added and dropped with much less effort. Think of these
local caches are database indexes. Just because you need an index in
a particular direction to optimize a query or loopup operation does
***not*** imply that you need to make a fundamental, globally visible,
database schema change or git object layout which breaks compatibility
for everybody.
- Ted
^ permalink raw reply
* CGit and repository list
From: Petr Baudis @ 2008-09-12 14:58 UTC (permalink / raw)
To: Lars Hjemli; +Cc: Jakub Narebski, git
In-Reply-To: <8c5c35580809120736x4170b2dbq3438bd619326ae00@mail.gmail.com>
Hi,
On Fri, Sep 12, 2008 at 04:36:11PM +0200, Lars Hjemli wrote:
> <plug>
> Current cgit also allows cloning over http using the same url as for
> browsing the repo, i.e. you may
>
> $ git clone http://hjemli.net/git/cgit
>
> This has one advantage over just publishing the repo; you don't have
> to run `git-update-server-info` (thanks to the work done by Shawn O.
> Pearce on git-http-backend, which is shamelessly reimplemented in
> cgit).
> </plug>
this finally tripped me over and I wanted to quickly add cgit as an
alternate viewing interface at repo.or.cz. But it seems that cgit
requires all the repositories explicitly listed in the config file.
Do you plan to remove this limitation in the future?
Thanks,
Petr "Pasky" Baudis
^ permalink raw reply
* Re: Git on server
From: Benjamin Sergeant @ 2008-09-12 14:55 UTC (permalink / raw)
To: delux; +Cc: git
In-Reply-To: <19440690.post@talk.nabble.com>
On Thu, Sep 11, 2008 at 10:57 AM, delux <jared@2ndnaturestudio.com> wrote:
>
> I work in a studio and we have many projects that we work on. We want to
> start using git, but we seem to be having some problems. I need to be able
> to pull the files from the server on to the local machines or have user
> repositories where the employees can pull the files to their repositories
> work on them then push the back to the main repository. I have tried to
> create a main repository and user repositories to try and push and pull
> between them and had no luck, git is installed on a Linux server and we have
> Mac and Windows machines. Any help is greatly appreciated and if more info
> is needed please let me know. Thanks in advance!
> --
http://www.kernel.org/pub/software/scm/git/docs/everyday.html
Look for
""" CVS-style shared repository. """
> View this message in context: http://www.nabble.com/Git-on-server-tp19440690p19440690.html
> Sent from the git mailing list archive at Nabble.com.
>
> --
> 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
>
^ permalink raw reply
* Re: [JGIT PATCH] Configure the maven surefire plugin to specifically include all tests
From: Shawn O. Pearce @ 2008-09-12 14:47 UTC (permalink / raw)
To: Jonas Fonseca; +Cc: Imran M Yousuf, Robin Rosenberg, git, Imran M Yousuf
In-Reply-To: <20080912084030.GA4964@diku.dk>
Jonas Fonseca <fonseca@diku.dk> wrote:
> By default, the test cases named T000* were not included. With this
> patch maven reports that 508 tests have been run.
Thanks. 508 is the correct current number of tests.
> + <plugin>
> + <artifactId>maven-surefire-plugin</artifactId>
> + <version>2.4.2</version>
> + <configuration>
> + <includes>
> + <include>**/*Test.java</include>
> + <include>**/*TestCase.java</include>
> + <include>**/T000*.java</include>
> + </includes>
> + </configuration>
> + </plugin>
--
Shawn.
^ permalink raw reply
* Re: configuring git public repository
From: Lars Hjemli @ 2008-09-12 14:36 UTC (permalink / raw)
To: Jakub Narebski; +Cc: Ciprian Dorin Craciun, sagi4, git
In-Reply-To: <m3vdx1o72x.fsf@localhost.localdomain>
On Fri, Sep 12, 2008 at 2:57 PM, Jakub Narebski <jnareb@gmail.com> wrote:
>
> "Ciprian Dorin Craciun" <ciprian.craciun@gmail.com> writes:
>
> > On Fri, Sep 12, 2008 at 7:47 AM, sagi4 <geetha@angleritech.com> wrote:
> > >
> > > Hi all,
> > >
> > > I am new git..
> > >
> > > I would like to configure git as a public repository for my rails
> > > application..
>
> > -- by using gitweb? and serving it as http://...;
>
> Gitweb (and cgit, and git-php) is _web interface_ to repository, which
> means that you can check the state of repository, view current version
> and the log of changes, and many other things from a web browser.
<plug>
Current cgit also allows cloning over http using the same url as for
browsing the repo, i.e. you may
$ git clone http://hjemli.net/git/cgit
This has one advantage over just publishing the repo; you don't have
to run `git-update-server-info` (thanks to the work done by Shawn O.
Pearce on git-http-backend, which is shamelessly reimplemented in
cgit).
</plug>
--
larsh
^ permalink raw reply
* Re: [StGit PATCH] add option to import series directly from a tar archive
From: Samuel Tardieu @ 2008-09-12 13:59 UTC (permalink / raw)
To: Clark Williams; +Cc: Karl Hasselström, git
In-Reply-To: <48CA674B.9080900@gmail.com>
>>>>> "Clark" == Clark Williams <clark.williams@gmail.com> writes:
Clark> Zowie, I thought I only had to worry about folks sending
Clark> patches with incomplete information. So you get patches to the
Clark> ada compiler that are rooted in gcc/ada (e.g. patch in tarball
Clark> says "./ChangeLog", instead of gcc/ada/ChangeLog) rather than
Clark> at a top level? Only way I could see to deal with that would be
Clark> to try and pass in the appropriate prefix from the command
Clark> line.
Yes, passing the prefix and strip levels would be fine.
Sam
--
Samuel Tardieu -- sam@rfc1149.net -- http://www.rfc1149.net/
^ permalink raw reply
* Re: Gitweb
From: Jakub Narebski @ 2008-09-12 13:27 UTC (permalink / raw)
To: delux; +Cc: git
In-Reply-To: <19455112.post@talk.nabble.com>
delux <jared@2ndnaturestudio.com> writes:
> I posted on another subject before and thanks to all who replied to
> that, Now I want to put gitweb on my server and have read everything
> to do it but cant seem to find the files. I know that it is supposed
> to be bundled with git but I am not the one who installed git, so is
> there anywhere I can get the gitweb files?
First, what operating system, and in the case of Linux what
distribution do you use? For example both Fedora Core and Debian (so
also all Debian-derived distributions like Ubuntu) have gitweb*
package; so it should be very simple to install this.
Because installing CGI script (or legacy mod_perl script) differs from
distribution to distribution, therefore stock RPMS from kernel.org
doesn't create gitweb package. So you would have to either download
source tarball, or clone git repository, read gitweb/INSTALL and then
run
$ make gitweb/gitweb.cgi <options>
or
$ make configure && ./configure && make gitweb/gitweb.cgi
and simply copy the files (there is no install target for gitweb) as
described, ensuring that web server is configured to run CGI scripts
(or mod_perl scripts).
You can see gitweb at work at http://git.debian.org, and modified
gitweb at http://git.kernel.org and http://repo.or.cz.
--
Jakub Narebski
Poland
ShadeHawk on #git
^ permalink raw reply
* Re: [ANNOUNCE] TopGit v0.3
From: Petr Baudis @ 2008-09-12 13:15 UTC (permalink / raw)
To: Jan Nieuwenhuizen; +Cc: git
In-Reply-To: <1221222433.29747.8.camel@heerbeest>
On Fri, Sep 12, 2008 at 02:27:13PM +0200, Jan Nieuwenhuizen wrote:
> On vr, 2008-09-12 at 13:00 +0200, Petr Baudis wrote:
>
> > But this is rewriting history, isn't it?
>
> No (that would be useless), see
>
> http://kerneltrap.org/mailarchive/git/2008/8/13/2925144 #first tg redepend idea
Huh. I can't see how that could ever work.
> $ git checkout -b P' P
> $ git rebase --onto B' B
> $ git checkout P
> $ git merge --no-ff --no-commit B' (*)
> $ git read-tree -u P'
> $ git commit
> $ git branch -D P'
The read-tree step is broken, you can't do that. The dependencies
content will be gone from your base, but not from the actual head -
what's the point of removing them at all?
Actually, tg patch will then show diff not only of your patch, but the
removed dependencies as well!
There's plenty of other problems with this approach as well. And I can't
see how readding a removed dependency would work at all either.
> I've just implemented the second idea
>
> http://kerneltrap.org/mailarchive/git/2008/8/15/2954214
>
> but haven't got any time to test it yet. Then there's also
>
> http://kerneltrap.org/mailarchive/git/2008/8/15/2952004
>
> to consider.
That's good point, indirect dependencies problem did not occur to me
before. That's troublesome...
I'm beginning to wonder if it is worth the trouble to support changing
dependencies in existing branches at all, except in the case the
dependency got merged to upstream (then we don't hit any of these
troubles). I'm stopping to see any way how to sanely support dependency
removal without history rewriting, since we rely on Git for our all
changes propagation.
> > Currently, I'm thinking that something like .topundeps (or !-prefixing
> > dependencies in .topdeps) is the only way to implement this...
>
> Yeah, i've been thinking that too. It would be nice if we could
> hack around that. It seems that the two redepend ideas get around
> it at the expense of creating the whole list of dependencies,
> which is much too expensive for my taste.
Actually, you would have to do this here as well for what we could call
"the evil Jonathan scenario":
> Make a topic branch t/foo depending on master.
> Change the dependency of t/foo to the older version maint.
> Make a new topic branch t/bar depending on t/foo and master.
When creating t/bar, you _need_ to look in t/foo dependencies to figure
out that you really do need the master stuff merged.
Even worse, these dependency removals act dominantly through merges.
Consider t/xyzzy and t/qux both depending on master. If you remove
master dependency from t/xyzzy and then merge them together, you'll lose
master from the result, even though t/qux needs it, because of the
dependency removal commit!
More and more worms turn up in the can.
--
Petr "Pasky" Baudis
The next generation of interesting software will be done
on the Macintosh, not the IBM PC. -- Bill Gates
^ permalink raw reply
* Re: [StGit PATCH] add option to import series directly from a tar archive
From: Clark Williams @ 2008-09-12 12:57 UTC (permalink / raw)
To: Samuel Tardieu; +Cc: Karl Hasselström, git
In-Reply-To: <2008-09-12-14-21-13+trackit+sam@rfc1149.net>
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Samuel Tardieu wrote:
>>>>>> "Clark" == Clark Williams <clark.williams@gmail.com> writes:
>
> Clark> [...] is to see if I can ease StGit's patch
> Clark> import rules a bit, since quilt accepts pretty much anything as
> Clark> long as there's a diff in there somewhere. I bomb out regularly
> Clark> importing the -rt series using StGit, because some people don't
> Clark> put complete email addresses in their patches.
>
> Two things that would be great would be:
>
> - to be able to import patches with "-p0" (people not using git
> often sends such patches)
I'm not sure how easy this is going to be. It looks like the patch is applied with
'git --apply' from the file stgit/git.py:apply_patch(). The default '-p' value is 1,
so we'd have to figure out how to pass the 0 along and then get it into the
apply_patch() function.
>
> - to be able to find where the patch should be applied; I sometimes
> receive patches for GCC directory "gcc/ada/", diffed from there,
> and if StGit could see that the patch only makes sense there and
> not at the top-level it would be great as well
>
Zowie, I thought I only had to worry about folks sending patches with incomplete
information. So you get patches to the ada compiler that are rooted in gcc/ada (e.g.
patch in tarball says "./ChangeLog", instead of gcc/ada/ChangeLog) rather than at a
top level? Only way I could see to deal with that would be to try and pass in the
appropriate prefix from the command line.
My current plans are to clean up the first cut at the tarfile logic, then write a
test to keep Karl happy, then try to come up with a way to deal with importing
patches that don't have complete email addresses, no descriptions, etc. Once I get
through that, I'll see if we can deal with weirdly rooted patch series.
Clark
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org
iEYEARECAAYFAkjKZ0sACgkQqA4JVb61b9eg2ACffDv+FXsL1NifMvxr1tbO2c3s
Hc4AoJPb/RZJrpqT6QybeZrj8rNFJg1y
=ccj/
-----END PGP SIGNATURE-----
^ permalink raw reply
* Re: configuring git public repository
From: Jakub Narebski @ 2008-09-12 12:57 UTC (permalink / raw)
To: Ciprian Dorin Craciun; +Cc: sagi4, git
In-Reply-To: <8e04b5820809120533o1e7da548l6868660767a5435d@mail.gmail.com>
"Ciprian Dorin Craciun" <ciprian.craciun@gmail.com> writes:
> On Fri, Sep 12, 2008 at 7:47 AM, sagi4 <geetha@angleritech.com> wrote:
> >
> > Hi all,
> >
> > I am new git..
> >
> > I would like to configure git as a public repository for my rails
> > application..
> >
> > Please help me..
First, I think you can find required information in many documentation
avaliable online, like "Git User's Manual" (distributed with Git), or
Got Community Book from http://git-scm.com
> If I'm correct, you have two major options:
> -- install your own git infrastructure:
> -- by using git-daemon and serving the git repository throught
> git://...;
Note that git:// protocol is meant only for _fetching_ (although you
can configure it for pushing, it is a good option only in very narrow
set of circumstances). And you would have ensure that your firewall
allows git traffic.
> -- by using gitweb? and serving it as http://...;
Gitweb (and cgit, and git-php) is _web interface_ to repository, which
means that you can check the state of repository, view current version
and the log of changes, and many other things from a web browser. All
of those require installing either as CGI module, or some other module
for web server having installed.
To have read-only HTTP access you only need to put your repository in
a place where your web server will see it. Well, that and ensure that
git-update-server-info is run, for clients to be able to know latest
state of the repository. Usually it is done using 'update' hook; it
should be enough to enable example hook (if you use bare repository as
published repository).
To be able to push via HTTP you have to set WebDAV and appropriate
permissions on web server. See the documentation.
> -- by using ssh and serving it as ssh://... (this is
> appropriate mostly for private repositories);
Usually you would want to restrict access by using git-shell, and
perhaps ease configuring permissions using either Gitosis (see also
BlogPosts on git wiki) or ssh_acl.
> -- using an existing Git hosting service like:
> -- (of course) http://repo.or.cz/
> -- http://github.org/
> -- http://gitorious.org/
> -- see also http://git.or.cz/gitwiki/GitHosting
>
> For open-source / public repositories I would opt for using an
> existing hosting service.
For Rails application I would check what other Ruby on Rails people
use. I would guess that it would be either Rubyforge or GitHub.
HTH.
--
Jakub Narebski
Poland
ShadeHawk on #git
^ permalink raw reply
* Gitweb
From: delux @ 2008-09-12 12:48 UTC (permalink / raw)
To: git
I posted on another subject before and thanks to all who replied to that, Now
I want to put gitweb on my server and have read everything to do it but cant
seem to find the files. I know that it is supposed to be bundled with git
but I am not the one who installed git, so is there anywhere I can get the
gitweb files?
--
View this message in context: http://www.nabble.com/Gitweb-tp19455112p19455112.html
Sent from the git mailing list archive at Nabble.com.
^ permalink raw reply
* Re: [StGit PATCH] add option to import series directly from a tar archive
From: Karl Hasselström @ 2008-09-12 13:08 UTC (permalink / raw)
To: Samuel Tardieu; +Cc: Clark Williams, git
In-Reply-To: <20080912130703.GA31240@diana.vm.bytemark.co.uk>
On 2008-09-12 15:07:03 +0200, Karl Hasselström wrote:
> On 2008-09-12 14:21:13 +0200, Samuel Tardieu wrote:
>
> > - to be able to find where the patch should be applied; I
> > sometimes receive patches for GCC directory "gcc/ada/", diffed
> > from there, and if StGit could see that the patch only makes
> > sense there and not at the top-level it would be great as well
>
> I don't believe git-apply can do this (please correct me if I'm
> wrong)
It does have a --directory flag, but that requires the user to specify
the path manually.
--
Karl Hasselström, kha@treskal.com
www.treskal.com/kalle
^ permalink raw reply
* Re: [StGit PATCH] add option to import series directly from a tar archive
From: Karl Hasselström @ 2008-09-12 13:07 UTC (permalink / raw)
To: Samuel Tardieu; +Cc: Clark Williams, git
In-Reply-To: <2008-09-12-14-21-13+trackit+sam@rfc1149.net>
On 2008-09-12 14:21:13 +0200, Samuel Tardieu wrote:
> Two things that would be great would be:
>
> - to be able to import patches with "-p0" (people not using git
> often sends such patches)
This should be trivial to implement, since git-apply (pardon the dash)
has a -p flag with precisely this meaning.
> - to be able to find where the patch should be applied; I
> sometimes receive patches for GCC directory "gcc/ada/", diffed
> from there, and if StGit could see that the patch only makes
> sense there and not at the top-level it would be great as well
I don't believe git-apply can do this (please correct me if I'm
wrong), and the right way to teach StGit to do it would arguably be to
teach it to git-apply and then make StGit use it. It'd be _possible_
to do it directly in StGit, but it wouldn't be quite the right level,
and git users wouldn't benefit.
--
Karl Hasselström, kha@treskal.com
www.treskal.com/kalle
^ permalink raw reply
* Re: StGit question
From: Clark Williams @ 2008-09-12 12:41 UTC (permalink / raw)
To: Karl Hasselström; +Cc: git, Catalin Marinas
In-Reply-To: <20080912075116.GA26685@diana.vm.bytemark.co.uk>
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Karl Hasselström wrote:
> On 2008-09-11 12:04:06 -0500, Clark Williams wrote:
>
>> Are there any guidelines or best-practices for sharing StGit trees?
>
> See below. ;-)
>
>> I'm working with the Linux -rt patchset and I need to be able to
>> share my tree with other people. What I'd *like* to do is push git
>> tree's up to a git server, let other people fetch them and have them
>> be able to 'stg uncommit' to get back to my stack state. The problem
>> is that when someone uncommits, you lose the patch names. If you're
>> trying to create an RPM out of a stack, this causes problems :).
>>
>> Is there something I can do or something that we can do to StGit to
>> make it possible for an 'uncommit' to restore the original patch
>> name? It looks like I could modify the commit message, so that the
>> first line is the patch name, but that's not very nice for people
>> scanning commits.
>>
>> Or am I missing something completely trivial that will make my life
>> easier?
>
> You've probably already found this and dismissed it, but
>
> $ stg uncommit foo bar baz woo wee aaahh
>
> will uncommit six patches and give them those names. So if you just
> share the output of
>
> $ stg series --applied --noprefix
>
> along with your branch, the other end will be able to recreate a
> series with the same names. (In not-quite-bleeding-edge stg's, "series
> --applied" is spelled "applied".)
Ahhhh, no I hadn't found this. Cool! I wonder if I could save the series in the
branch, so that someone could just checkout the branch and do:
$ stg uncommit $(cat stg-series)
Or, maybe I'll look at adding a --series or --file option to uncommit?
I suspect some chicken-and-egg problems here, but this is workable. And when you're
talking >500 patches, anything you can do to automate is a wonderful thing :).
>
> As for merging your work once both of you have made changes to the
> series, the current solution is "stg sync", which you'll have to ask
> Catalin about. The patch stack log in my experimental branch is
> designed to allow for true 3-way merging of patch series, so that
> you'd be able to get your colleague's latest modifications with a
> simple "stg merge" command, but that merge currently exists only in a
> couple of mails to this list -- there isn't even a prototype
> implementation -- so I expect you'll have more luck with "stg sync"
> right now ...
>
Most of the time it's not more than one or two patches difference, so I think that it
can be handled manually for now. I'll definitely keep an eye on sync and merge though...
Thanks,
Clark
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org
iEYEARECAAYFAkjKY2cACgkQqA4JVb61b9cVYgCfZE8//UgP11+D3AKMCsDGN8Qs
KpsAni8gLlZn088lQr/1nbzQf4uKHxn/
=A6MK
-----END PGP SIGNATURE-----
^ permalink raw reply
* Re: configuring git public repository
From: Ciprian Dorin Craciun @ 2008-09-12 12:33 UTC (permalink / raw)
To: sagi4; +Cc: git
In-Reply-To: <19449377.post@talk.nabble.com>
Hello!
If I'm correct, you have two major options:
-- install your own git infrastructure:
-- by using git-daemon and serving the git repository throught
git://...;
-- by using gitweb? and serving it as http://...;
-- by using ssh and serving it as ssh://... (this is
appropriate mostly for private repositories);
-- using an existing Git hosting service like:
-- (of course) http://repo.or.cz/
-- http://github.org/
-- http://gitorious.org/
-- see also http://git.or.cz/gitwiki/GitHosting
For open-source / public repositories I would opt for using an
existing hosting service.
Hope it's useful for you,
Ciprian Dorin Craciun.
On Fri, Sep 12, 2008 at 7:47 AM, sagi4 <geetha@angleritech.com> wrote:
>
> Hi all,
>
> I am new git..
>
> I would like to configure git as a public repository for my rails
> application..
>
> Please help me..
>
> Thanks
> Sg..
> --
> View this message in context: http://www.nabble.com/configuring-git-public-repository-tp19449377p19449377.html
> Sent from the git mailing list archive at Nabble.com.
^ permalink raw reply
* Re: [StGit PATCH] add option to import series directly from a tar archive
From: Samuel Tardieu @ 2008-09-12 12:21 UTC (permalink / raw)
To: Clark Williams; +Cc: Karl Hasselström, git
In-Reply-To: <48C56AD9.6040007@gmail.com>
>>>>> "Clark" == Clark Williams <clark.williams@gmail.com> writes:
Clark> [...] is to see if I can ease StGit's patch
Clark> import rules a bit, since quilt accepts pretty much anything as
Clark> long as there's a diff in there somewhere. I bomb out regularly
Clark> importing the -rt series using StGit, because some people don't
Clark> put complete email addresses in their patches.
Two things that would be great would be:
- to be able to import patches with "-p0" (people not using git
often sends such patches)
- to be able to find where the patch should be applied; I sometimes
receive patches for GCC directory "gcc/ada/", diffed from there,
and if StGit could see that the patch only makes sense there and
not at the top-level it would be great as well
Sam
--
Samuel Tardieu -- sam@rfc1149.net -- http://www.rfc1149.net/
^ permalink raw reply
* Re: [ANNOUNCE] TopGit v0.3
From: Jan Nieuwenhuizen @ 2008-09-12 12:27 UTC (permalink / raw)
To: Petr Baudis; +Cc: git
In-Reply-To: <20080912110017.GW10360@machine.or.cz>
On vr, 2008-09-12 at 13:00 +0200, Petr Baudis wrote:
> But this is rewriting history, isn't it?
No (that would be useless), see
http://kerneltrap.org/mailarchive/git/2008/8/13/2925144 #first tg redepend idea
I've just implemented the second idea
http://kerneltrap.org/mailarchive/git/2008/8/15/2954214
but haven't got any time to test it yet. Then there's also
http://kerneltrap.org/mailarchive/git/2008/8/15/2952004
to consider.
> Currently, I'm thinking that something like .topundeps (or !-prefixing
> dependencies in .topdeps) is the only way to implement this...
Yeah, i've been thinking that too. It would be nice if we could
hack around that. It seems that the two redepend ideas get around
it at the expense of creating the whole list of dependencies,
which is much too expensive for my taste.
Greetings,
Jan.
--
Jan Nieuwenhuizen <janneke@gnu.org> | GNU LilyPond - The music typesetter
http://www.xs4all.nl/~jantien | http://www.lilypond.org
^ permalink raw reply
* Re: Git on server
From: Petr Baudis @ 2008-09-12 12:15 UTC (permalink / raw)
To: delux; +Cc: git
In-Reply-To: <19440690.post@talk.nabble.com>
Hi,
On Thu, Sep 11, 2008 at 10:57:49AM -0700, delux wrote:
> I work in a studio and we have many projects that we work on. We want to
> start using git, but we seem to be having some problems. I need to be able
> to pull the files from the server on to the local machines or have user
> repositories where the employees can pull the files to their repositories
> work on them then push the back to the main repository. I have tried to
> create a main repository and user repositories to try and push and pull
> between them and had no luck, git is installed on a Linux server and we have
> Mac and Windows machines. Any help is greatly appreciated and if more info
> is needed please let me know. Thanks in advance!
I'm afraid you will have to elaborate on "had no luck".
Kind regards,
Petr "Pasky" Baudis
^ permalink raw reply
* Re: [PATCH/RFC 2/6] convert doc links for server type programmes from linkgit to gitlink
From: Michael J Gruber @ 2008-09-12 11:32 UTC (permalink / raw)
To: git; +Cc: Michael J Gruber
In-Reply-To: <1221216926-20435-3-git-send-email-git@drmicha.warpmail.net>
Heck, please ignore this one, sorry. This is what happens when you
rebase to change the subject but forget to clean out 00*. It's identical
with the other 2/6 otherwise.
Michael
^ permalink raw reply
* Re: Git User's Survey 2008 partial summary, part 5 - other SCM
From: dhruva @ 2008-09-12 11:11 UTC (permalink / raw)
To: Jakub Narebski, David Lang; +Cc: git
Hello,
----- Original Message ----
> From: Jakub Narebski <jnareb@gmail.com>
> To: David Lang <david@lang.hm>
> Cc: git@vger.kernel.org
> Sent: Friday, 12 September, 2008 4:14:58 PM
> Subject: Re: Git User's Survey 2008 partial summary, part 5 - other SCM
>
> On Fri, 12 Sep 2008 00:51, david@lang.hm wrote:
> > On Thu, 11 Sep 2008, Jakub Narebski wrote:
> >
> > > A bit suprising for me is high place of Perforce. Another strange
> > > thing (and a bit alarming) is that MS Visual SourceSafe has higher
> > > place than Monotone; but that might be caused by different design and
> > > different target groups of Monotone and Git, which might have caused
> > > that the communities have almost no overlap; people choose either Git
> > > or Monotone, one or the other. BitKeeper has also a very low number
> > > of active users among Git users... but that is not that strange,
> > > considering history.
> >
> > I think you are making the wrong assumption here.
> >
> > Someone may use CVS becouse they contribute to a project that is only
> > availabe via CVS
> >
> > Someone may use Perforce becouse that is the VCS that their company uses
I am in that situation...
> True, I have forgot that "I use this SCM" (or "I used this SCM") doesn't
> necessarily mean that one _choose_ this SCM. One can use some SCM
> because it is SCM project uses, or because their company requires it;
> but not necessary, as git-svn and git-p4 show one can use Git, and
> make it interact with respectively Subversion and Perforce, and trying
> to make it look like one uses this other SCM.
Since we cannot change management to decide on using git instead of whatever they are using overnight. Best is to have tools like git-p4/git-svn which allows interoperability. Once people gain confidence, they can replace that whatever SCM with git. That is the path I am planning at my place of work.
-dhruva
Get an email ID as yourname@ymail.com or yourname@rocketmail.com. Click here http://in.promos.yahoo.com/address
^ permalink raw reply
* Re: [ANNOUNCE] TopGit v0.3
From: Petr Baudis @ 2008-09-12 11:01 UTC (permalink / raw)
To: Bert Wesarg; +Cc: git
In-Reply-To: <36ca99e90809100118m4c2c0904q5f3effb301b0d779@mail.gmail.com>
Hi,
On Wed, Sep 10, 2008 at 10:18:08AM +0200, Bert Wesarg wrote:
> On Wed, Sep 10, 2008 at 01:10, Petr Baudis <pasky@suse.cz> wrote:
> > Hi!
> Hi,
>
> Thanks for the release. I have some notes:
>
> 1. .gitignore is not up-to-date
thanks, fixed.
> 2. tg tells me v0.2
This works for me.
> What do I need to publish my TopGit controlled branches, is it enough
> to push with:
>
> push = refs/heads/t/*:refs/heads/t/*
> push = refs/top-bases/t/*:refs/top-bases/t/*
Yes, if you keep all of your TopGit-controlled branches in t/*.
Or just call 'tg remote' on the publishing remote and it will set up
this stuff for you.
--
Petr "Pasky" Baudis
The next generation of interesting software will be done
on the Macintosh, not the IBM PC. -- Bill Gates
^ permalink raw reply
* Re: [ANNOUNCE] TopGit v0.3
From: Petr Baudis @ 2008-09-12 11:00 UTC (permalink / raw)
To: Jan Nieuwenhuizen; +Cc: git
In-Reply-To: <1221120192.8962.7.camel@heerbeest>
On Thu, Sep 11, 2008 at 10:03:12AM +0200, Jan Nieuwenhuizen wrote:
> The last implementation would just recreate a branch with all new
> dependencies, which is quite inefficient when you're just removing
> or adding one (and the list of dependencies is long, say ~100).
But this is rewriting history, isn't it? This would make your work
completely different from others' and that violates one of main TopGit's
design goals. Or am I missing something obvious?
Currently, I'm thinking that something like .topundeps (or !-prefixing
dependencies in .topdeps) is the only way to implement this...
--
Petr "Pasky" Baudis
The next generation of interesting software will be done
on the Macintosh, not the IBM PC. -- Bill Gates
^ permalink raw reply
* Re: [ANNOUNCE] TopGit v0.3
From: Petr Baudis @ 2008-09-12 10:58 UTC (permalink / raw)
To: Mike Hommey; +Cc: git
In-Reply-To: <20080911054030.GA6602@glandium.org>
Hi,
On Thu, Sep 11, 2008 at 07:40:30AM +0200, Mike Hommey wrote:
> I just saw Martin Krafft's talk at debconf 8, showing TopGit, and I
> wonder why TopGit needs to keep top-bases/* references ? Isn't
> git merge-base enough for this ?
the top-bases/ references are to determine what to base the patch
against. Consider patch structure like:
.---- A ----.
vanilla < > C
`---- B ----'
Then, top-bases/C will consist of branches A and B, merging updates in
these branches over time, and you can get the current image of C's patch
by diffing top-bases/C and heads/C. There is no way how to get this by
using git merge-base, since that gives you only kind of "multi-way
diff" - I'm not even sure what would you call merge-base on in this
example.
--
Petr "Pasky" Baudis
The next generation of interesting software will be done
on the Macintosh, not the IBM PC. -- Bill Gates
^ 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