* gitwiki/EclipsePlugin
From: M @ 2008-06-25 16:34 UTC (permalink / raw)
To: git
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Hi list,
I felt quite helpless when trying to get egit running as neither
http://git.or.cz/gitwiki/EclipsePlugin nor the README/INSTALL aren't
overly verbose.
I put the idiot-proof recipe on
http://wiki.jcurl.org/index.php5?title=GitSvn#Eclipse_Plugin - maybe you
can weave it into either wiki or INSTALL?
Greetings,
M
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iEYEARECAAYFAkhic34ACgkQO26gbdBiJqZiCwCeMFLgBKVR1Gl6U7WDDMHr/ogN
H3YAnApFMSrY56+9bT4bJOb99kjZuv0P
=Xz9D
-----END PGP SIGNATURE-----
^ permalink raw reply
* Re: how to list all files that will be comitted
From: Ian Hilt @ 2008-06-25 16:24 UTC (permalink / raw)
To: Rhodes, Kate; +Cc: git
In-Reply-To: <17C0F998-66C0-4DFC-90EB-B85FF6E07844@gmail.com>
On Wed, 25 Jun 2008 at 12:01pm -0400, Rhodes, Kate wrote:
> yeah, but i was hoping for plumbing, not porcelain, that showed just what i
> wanted so that i didn't have to parse status' output.
I wasn't able to make "git ls-files" do what you want. However, "git
diff --name-only --cached" did. It's still porcelain, but it does what
you want :)
--
Ian Hilt
Ian.Hilt (at) gmx.com
GnuPG key: 0x4AFC1EE3
^ permalink raw reply
* Re: [PATCH 12/13] Build in merge
From: Olivier Marin @ 2008-06-25 16:22 UTC (permalink / raw)
To: Miklos Vajna; +Cc: Junio C Hamano, git
In-Reply-To: <d5d80c5a068c76810edfa9c0c68de500f02780a0.1214066799.git.vmiklos@frugalware.org>
Hi,
I did not read your patches yet but I noticed the two following bugs while testing
current pu.
Miklos Vajna a écrit :
>
> +static void finish(const unsigned char *new_head, const char *msg)
> +{
[...]
> + if (new_head && show_diffstat) {
> + diff_setup(&opts);
> + opts.output_format |=
> + DIFF_FORMAT_SUMMARY | DIFF_FORMAT_DIFFSTAT;
> + opts.detect_rename = DIFF_DETECT_RENAME;
You probably want to add DIFF_OPT_SET(&opts, COLOR_DIFF) to have a nice colored diff
like the original script.
> + diff_tree_sha1(head, new_head, "", &opts);
> + diffcore_std(&opts);
> + diff_flush(&opts);
> + }
[...]
> +int cmd_merge(int argc, const char **argv, const char *prefix)
> +{
[...]
> + } else if (allow_fast_forward && !remoteheads->next &&
> + !hashcmp(common->item->object.sha1, head)) {
> + /* Again the most common case of merging one remote. */
> + struct strbuf msg;
> + struct object *o;
> +
> + printf("Updating %s..%s\n",
> + find_unique_abbrev(head, DEFAULT_ABBREV),
> + find_unique_abbrev(remoteheads->item->object.sha1,
> + DEFAULT_ABBREV));
Here, the second call to find_unique_abbrev() will overwrite the previous returned
value because this function return a pointer to a static buffer.
Olivier.
^ permalink raw reply
* Re: how to list all files that will be comitted
From: Michael J Gruber @ 2008-06-25 16:19 UTC (permalink / raw)
To: git
In-Reply-To: <644094BE-2835-41EF-B1B4-615B8A4BD509@gmail.com>
Rhodes, Kate venit, vidit, dixit 25.06.2008 17:31:
> I know ls-files is the tool I need but I haven't been able to figure
> out what combination of options will give me the files that have been
> added to the index.
I don't think git ls-files does that, but
git diff --cached --name-only
will.
Cheers,
Michael
^ permalink raw reply
* Re: how to list all files that will be comitted
From: Rhodes, Kate @ 2008-06-25 16:16 UTC (permalink / raw)
To: Karl Hasselström; +Cc: Ian Hilt, git
In-Reply-To: <20080625161439.GA1794@diana.vm.bytemark.co.uk>
Perfect, exactly what I wanted. Thanks.
-Kate
On Jun 25, 2008, at 12:14 PM, Karl Hasselström wrote:
> On 2008-06-25 12:01:49 -0400, Rhodes, Kate wrote:
>
>> yeah, but i was hoping for plumbing, not porcelain, that showed just
>> what i wanted so that i didn't have to parse status' output.
>
> Unless you want a listing of all the files in the index, you probably
> want to call diff-index.
>
> git diff-index --cached <tree-ish>
>
> gives you the diff between the index and a tree-ish. With the
> --name-only option, you get only the filenames and not all the modes,
> blob sha1s, etc.
>
> --
> Karl Hasselström, kha@treskal.com
> www.treskal.com/kalle
^ permalink raw reply
* Re: how to list all files that will be comitted
From: Karl Hasselström @ 2008-06-25 16:14 UTC (permalink / raw)
To: Rhodes, Kate; +Cc: Ian Hilt, git
In-Reply-To: <17C0F998-66C0-4DFC-90EB-B85FF6E07844@gmail.com>
On 2008-06-25 12:01:49 -0400, Rhodes, Kate wrote:
> yeah, but i was hoping for plumbing, not porcelain, that showed just
> what i wanted so that i didn't have to parse status' output.
Unless you want a listing of all the files in the index, you probably
want to call diff-index.
git diff-index --cached <tree-ish>
gives you the diff between the index and a tree-ish. With the
--name-only option, you get only the filenames and not all the modes,
blob sha1s, etc.
--
Karl Hasselström, kha@treskal.com
www.treskal.com/kalle
^ permalink raw reply
* Re: how to list all files that will be comitted
From: Reece Dunn @ 2008-06-25 16:14 UTC (permalink / raw)
To: Rhodes, Kate; +Cc: git
In-Reply-To: <644094BE-2835-41EF-B1B4-615B8A4BD509@gmail.com>
2008/6/25 Rhodes, Kate <masukomi@gmail.com>:
> I know ls-files is the tool I need but I haven't been able to figure out
> what combination of options will give me the files that have been added to
> the index.
>
> -Kate
`git status` will do this, unless you need to do additional processing
on the results.
HTH,
- Reece
^ permalink raw reply
* Re: [Bug] for-each-ref: %(object) and %(type) unimplemented
From: Jeff King @ 2008-06-25 16:14 UTC (permalink / raw)
To: Lea Wiemann; +Cc: Junio C Hamano, Git Mailing List
In-Reply-To: <20080625160814.GA3321@sigill.intra.peff.net>
On Wed, Jun 25, 2008 at 12:08:15PM -0400, Jeff King wrote:
> Since you seem to be testing for-each-ref, maybe it would make sense to
> put together a test script that exercises each of the atoms?
Hmm. Actually, there is a test in t6300 that runs with each atom name.
Unfortunately, it doesn't bother actually checking the output for
sanity, so the fact that these atoms returned the empty string was
missed.
-Peff
^ permalink raw reply
* Re: [Bug] for-each-ref: %(object) and %(type) unimplemented
From: Jeff King @ 2008-06-25 16:08 UTC (permalink / raw)
To: Lea Wiemann; +Cc: Junio C Hamano, Git Mailing List
In-Reply-To: <48625DAD.5040404@gmail.com>
On Wed, Jun 25, 2008 at 05:01:01PM +0200, Lea Wiemann wrote:
> Try the following on a repository with tag objects in it:
>
> git for-each-ref --format='%(object)'
> git for-each-ref --format='%(type)'
>
> Each command prints only newlines. The %(type) and %(object) options are
> not rejected with an error message (like "%(doesnotexist)"), but they
> don't seem to be implemented. "%(tag)" works though.
>
> Anyone care to implement the missing options? Or should they rather be
> removed from the documentation?
Looks like they were part of the original set of atoms, but they just
never ended up implemented. Clearly nobody has actually cared in the
intervening time, but it is easy enough to add them. See below.
Since you seem to be testing for-each-ref, maybe it would make sense to
put together a test script that exercises each of the atoms?
-- >8 --
for-each-ref: implement missing tag values
The "type" and "object" fields for tags were accepted as
valid atoms, but never implemented. Consequently, they
simply returned the empty string, even for valid tags.
Noticed by Lea Wiemann.
Signed-off-by: Jeff King <peff@peff.net>
---
builtin-for-each-ref.c | 7 +++++++
1 files changed, 7 insertions(+), 0 deletions(-)
diff --git a/builtin-for-each-ref.c b/builtin-for-each-ref.c
index 07d9c57..fef93d7 100644
--- a/builtin-for-each-ref.c
+++ b/builtin-for-each-ref.c
@@ -234,6 +234,13 @@ static void grab_tag_values(struct atom_value *val, int deref, struct object *ob
name++;
if (!strcmp(name, "tag"))
v->s = tag->tag;
+ else if (!strcmp(name, "type") && tag->tagged)
+ v->s = typename(tag->tagged->type);
+ else if (!strcmp(name, "object") && tag->tagged) {
+ char *s = xmalloc(41);
+ strcpy(s, sha1_to_hex(tag->tagged->sha1));
+ v->s = s;
+ }
}
}
--
1.5.6.129.g8dea5.dirty
^ permalink raw reply related
* Re: how to list all files that will be comitted
From: Rhodes, Kate @ 2008-06-25 16:01 UTC (permalink / raw)
To: Ian Hilt; +Cc: git
In-Reply-To: <alpine.LFD.1.10.0806251154180.5755@sys-0.hiltweb.site>
yeah, but i was hoping for plumbing, not porcelain, that showed just
what i wanted so that i didn't have to parse status' output.
-Kate
On Jun 25, 2008, at 11:57 AM, Ian Hilt wrote:
> Have you tried "git status" ? It will output something similar to the
> following:
^ permalink raw reply
* Re: how to list all files that will be comitted
From: Ian Hilt @ 2008-06-25 15:57 UTC (permalink / raw)
To: Rhodes, Kate; +Cc: git
In-Reply-To: <644094BE-2835-41EF-B1B4-615B8A4BD509@gmail.com>
On Wed, 25 Jun 2008 at 11:31am -0400, Rhodes, Kate wrote:
> I know ls-files is the tool I need but I haven't been able to figure out what
> combination of options will give me the files that have been added to the
> index.
>
> -Kate
Have you tried "git status" ? It will output something similar to the
following:
# On branch master
# Changes to be committed:
# (use "git reset HEAD <file>..." to unstage)
#
# modified: somefile
#
# Changed but not updated:
# (use "git add <file>..." to update what will be committed)
#
# modified: anotherfile
#
--
Ian Hilt
Ian.Hilt (at) gmx.com
GnuPG key: 0x4AFC1EE3
^ permalink raw reply
* Re: Where does gitweb take the owner name from?
From: Michael J Gruber @ 2008-06-25 15:50 UTC (permalink / raw)
To: git
In-Reply-To: <ce513bcc0806250741q3821e925uf8b6439b12062ba2@mail.gmail.com>
Erez Zilber venit, vidit, dixit 25.06.2008 16:41:
> Hi,
>
> On the main page of gitweb (the one that lists all projects), there's
> an "Owner" column. On my gitweb, it is empty for all projects. Where
> is this information taken from?
>
> Here is how it looks on the server when I run 'ls -l':
>
> drwxr-xr-x 7 erez.zilber linux 4096 Jun 25 17:36 my_test.git
>
> Thanks,
> Erez
Sources considered by gitweb are:
1. projectlist file
2. owner key in .git/config ("gitweb.owner")
3. file owner of the git dir
It's funny this results in an empty owner in your case: What does
"finger erez.silber" say?
Michael
Use the source, Luke ;)
sub git_get_project_owner {
my $project = shift;
my $owner;
return undef unless $project;
$git_dir = "$projectroot/$project";
if (!defined $gitweb_project_owner) {
git_get_project_list_from_file();
}
if (exists $gitweb_project_owner->{$project}) {
$owner = $gitweb_project_owner->{$project};
}
if (!defined $owner){
$owner = git_get_project_config('owner');
}
if (!defined $owner) {
$owner = get_file_owner("$git_dir");
}
return $owner;
}
^ permalink raw reply
* how to list all files that will be comitted
From: Rhodes, Kate @ 2008-06-25 15:31 UTC (permalink / raw)
To: git
I know ls-files is the tool I need but I haven't been able to figure
out what combination of options will give me the files that have been
added to the index.
-Kate
^ permalink raw reply
* Re: git svn clone a non-standard repository
From: Michael J Gruber @ 2008-06-25 15:25 UTC (permalink / raw)
To: git
In-Reply-To: <48613DC5.2000506@freelock.com>
John Locke venit, vidit, dixit 24.06.2008 20:32:
> Hi,
>
> I'm trying to create a git repo of the Dojo Toolkit, which has a quite
> non-standard layout. There are 4 modules to the current Dojo project
> that I care about (and some others in the repo that I'm not interested
> in). The problem is, the trunk code is split out into
> <modulename>/trunk, while tags are in tags/<tagname>/<modulename> and
> branches are in branches/<branchname>/<modulename>. e.g:
>
> moduleA/trunk <- contains trunk development of moduleA
> moduleA/tags <- empty
> moduleA/branches <- empty
> moduleB/trunk
> moduleB/tags
> moduleB/branches
> moduleC/trunk
> moduleC/tags
> moduleC/branches
> moduleD/trunk
> moduleD/tags
> moduleD/branches
All of those module?/{tags,branches} are empty, right? I assume branches
follow the pattern below for tags.
> moduleE/trunk <- I don't care about this one...
> trunk/ <- contains ancient version, not actual trunk
> tags/1.0.0/moduleA <- contains tagged version of moduleA
> tags/1.0.0/moduleB <- contains tagged version of moduleB
> tags/1.0.0/moduleC <- contains tagged version of moduleC
> tags/1.0.0/moduleD <- contains tagged version of moduleD
> tags/1.0.1/moduleA
> tags/1.0.1/moduleB
> ...
>
> So I'd like to set up a git repo that tracks this SVN repository, and
> allows me to see:
> moduleA/
> moduleB/
> moduleC/
> moduleD/
> ... in my checkout, whether I'm on trunk or a tag.
So you want one git repo, reflecting the modules simply by different
subdirs? I'm afraid that raises similar problems like those I asked
about in my (yet unanswered) post
http://permalink.gmane.org/gmane.comp.version-control.git/85861
> I've started with "git svn clone http://path/to/svn -T moduleA/trunk -t
> tags -b branches", and it's been sucking down branches for a couple days
This should give you all "modules" (as subsdirs) for all branches and
tags already. svn branch "branchname" becomes git remote branch
"branchname", svn tag "tagname" becomes git remote branch "tags/tagname".
Note that your new git branch trunk will contain the contents of
"moduleA" only.
> now, still not done. Can I set up moduleB/moduleC/moduleD as additional
> remotes in this same repository, and end up with the desired result? Was
> thinking I would add additional svn sections to .git/config, and then
> git svn fetch -- will this work, or is there a better way?
If I understand your layout (and "desires") correctly then trunk will be
your only problem: you want to map "module?/trunk" to subdir "module?"
of branch "trunk". This is more or less the problem I'm facing. Regular
expressions (other than the ones for branches and tags) in git svn
config would solve this.
Michael
^ permalink raw reply
* Re: [PATCH] cmd_reset: don't trash uncommitted changes unless toldto
From: Anton Gladkov @ 2008-06-25 15:18 UTC (permalink / raw)
To: Craig L. Ching
Cc: Matthias Kestenholz, Johannes Schindelin, Boaz Harrosh,
Junio C Hamano, Steven Walter, git@vger.kernel.org,
jeske@google.com
In-Reply-To: <63BEA5E623E09F4D92233FB12A9F794302389C2C@emailmn.mqsoftware.com>
On Wed, Jun 25, 2008 at 06:49:16PM +0400, Craig L. Ching wrote:
> > Because 'checkout' in other SCMs like CVS or SVN means 'get
> > latest data from repo', i.e. it acts like 'pull' or 'fetch' in git.
> > And 'branch' means branch manipulation: creating, deleting,
> > switching...
> >
> Checkout, for me and a lot of people I work with, never meant "get
> latest data from repo", it always meant "get me a workspace". Anyway,
> just sharing a dissenting opinion, I don't agree that the checkout verb
> is used incorrectly in git.
Craig,
I'm not trying to say that git incorrectly uses 'checkout' word :)
--
Best regards,
Anton
mailto:agladkov@parallels.com
^ permalink raw reply
* Re: [PATCH 5/7] parse-opt: fake short strings for callers to believe in.
From: Andreas Ericsson @ 2008-06-25 15:07 UTC (permalink / raw)
To: Pierre Habouzit, Linus Torvalds, git, gitster, peff,
Johannes.Schindelin
In-Reply-To: <20080624192634.GA9189@artemis.madism.org>
Pierre Habouzit wrote:
> On Tue, Jun 24, 2008 at 05:20:28PM +0000, Linus Torvalds wrote:
>>
>> On Tue, 24 Jun 2008, Pierre Habouzit wrote:
>>> If we begin to parse -abc and that the parser knew about -a and -b, it
>>> will fake a -c switch for the caller to deal with.
>>>
>>> Of course in the case of -acb (supposing -c is not taking an argument) the
>>> caller will have to be especially clever to do the same thing. We could
>>> think about exposing an API to do so if it's really needed, but oh well...
>> Well, if the other parser is _also_ parse_options() (ie you just cascade
>> them incrementally in a loop), then the other parser should get it right
>> automatically. No?
>
> Exactly. There are minor glitches wrt the help generation to deal
> with, but for pure parsing issues yes, it will work.
>
Why not just provide some api-functions to return a strbuf of the short
and long options each?
parse_opt_short_help(strbuf *sb, options...);
parse_opt_long_help(strbuf *sb_long, options...);
That way multi-parseopt programs can get their help-texts done right
with very little extra work.
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
^ permalink raw reply
* Re: [PATCH/RFC] git-svn: sanitize_remote_name should accept underscores.
From: Avery Pennarun @ 2008-06-25 15:01 UTC (permalink / raw)
To: Eric Wong; +Cc: Junio C Hamano, git
In-Reply-To: <20080625074548.GA8984@hand.yhbt.net>
On 6/25/08, Eric Wong <normalperson@yhbt.net> wrote:
> No, nothing to do with DNS hostnames in the remote names. I think I
> just looked at remotes2config.sh one day and used it as a reference :x
>
> It's late and I've had a rough few days, but shouldn't
> sanitize_remote_name() just escape . and "? Right now it's converting
> stuff to . which has me very confused...
I think there might be higher-level problems here: what is it
sanitizing anyway, and why? If it found my D2007_Win32 svn-remote
entry in the config (as it seems to have done when trying to locate
its parent branch during fetch), and *then* it sanitized it to
D2007.Win32, that doesn't even make any sense. Clearly something
straight from the config file doesn't need to be sanitized.
However, I don't understand the code well enough to be able to say a)
whether that's exactly what happened, or b) other places where
sanitize_remote_name() *is* important, or c) whether
sanitize_remote_name() is even correct.
Have fun,
Avery
^ permalink raw reply
* [Bug] for-each-ref: %(object) and %(type) unimplemented
From: Lea Wiemann @ 2008-06-25 15:01 UTC (permalink / raw)
To: Git Mailing List
Try the following on a repository with tag objects in it:
git for-each-ref --format='%(object)'
git for-each-ref --format='%(type)'
Each command prints only newlines. The %(type) and %(object) options
are not rejected with an error message (like "%(doesnotexist)"), but
they don't seem to be implemented. "%(tag)" works though.
Anyone care to implement the missing options? Or should they rather be
removed from the documentation?
-- Lea
^ permalink raw reply
* RE: [PATCH] cmd_reset: don't trash uncommitted changes unless toldto
From: Craig L. Ching @ 2008-06-25 14:49 UTC (permalink / raw)
To: Anton Gladkov, Matthias Kestenholz
Cc: Johannes Schindelin, Boaz Harrosh, Junio C Hamano, Steven Walter,
git, jeske
In-Reply-To: <20080625104605.GA10322@atn.sw.ru>
> -----Original Message-----
> From: git-owner@vger.kernel.org
> [mailto:git-owner@vger.kernel.org] On Behalf Of Anton Gladkov
> Sent: Wednesday, June 25, 2008 5:46 AM
> To: Matthias Kestenholz
> Cc: Johannes Schindelin; Boaz Harrosh; Junio C Hamano; Steven
> Walter; git@vger.kernel.org; jeske@google.com
> Subject: Re: [PATCH] cmd_reset: don't trash uncommitted
> changes unless toldto
>
> Because 'checkout' in other SCMs like CVS or SVN means 'get
> latest data from repo', i.e. it acts like 'pull' or 'fetch' in git.
> And 'branch' means branch manipulation: creating, deleting,
> switching...
>
Checkout, for me and a lot of people I work with, never meant "get
latest data from repo", it always meant "get me a workspace". Anyway,
just sharing a dissenting opinion, I don't agree that the checkout verb
is used incorrectly in git.
> --
> Best regards,
> Anton
> mailto:agladkov@parallels.com
> --
Cheers,
Craig
^ permalink raw reply
* Re: exit status 141 from git-svn
From: Michael J Gruber @ 2008-06-25 14:47 UTC (permalink / raw)
To: git
In-Reply-To: <loom.20080624T192256-150@post.gmane.org>
Frederik Hohlfeld venit, vidit, dixit 24.06.2008 21:24:
> Frederik Hohlfeld <frederik.hohlfeld <at> gmail.com> writes:
>
>> I have init'ed a git repository with git svn init.
>>
>> Now I'm using git svn fetch, but it stops after just a few files/revisions. The
>> exit status is 141.
>>
>> What does this 141 want to tell me?
>
> No one?
>
> Both git svn clone and git svn fetch stop after just a dozen or so revisions and
> only continue after calling the command again. For yet another few revisions.
>
> I'd like to get a clue what's happening. A git problem? A svn problem?
>
> Current Git Windows version.
That seems to be the first piece of information you're giving regarding
your environment and setup. Giving more may result in getting more
answers. (I grepped for 141 in the source after your first posting)
Maybe you can cut'n'paste the actual output of git svn fetch? What's the
command line you're using, where's the svn repo?
Michael
^ permalink raw reply
* Where does gitweb take the owner name from?
From: Erez Zilber @ 2008-06-25 14:41 UTC (permalink / raw)
To: git@vger.kernel.org
Hi,
On the main page of gitweb (the one that lists all projects), there's
an "Owner" column. On my gitweb, it is empty for all projects. Where
is this information taken from?
Here is how it looks on the server when I run 'ls -l':
drwxr-xr-x 7 erez.zilber linux 4096 Jun 25 17:36 my_test.git
Thanks,
Erez
^ permalink raw reply
* Re: Errors building git-1.5.6 from source on Mac OS X 10.4.11
From: Johannes Gilger @ 2008-06-25 14:38 UTC (permalink / raw)
To: Ifejinelo Onyiah; +Cc: git
In-Reply-To: <2eb980790806250620t73ae0ff7heedb65780a66ad00@mail.gmail.com>
On 25/06/08 14:20, Ifejinelo Onyiah wrote:
> I have made several attempts to build Git (version 1.5.6) on my Mac OS
> X 10.4.11 (Tiger) but have had little luck. At the time of my last try
> (2008-06-25 11:08) there were no pre-built binaries for Tiger on the
> Git home page. I downloaded the source file from home page and issued
> the following commands:
Hi,
I just followed your exact instructions (even using the same prefix in
configure) and ran the whole test-suite (and after that the offending
test t2004 by itself again). It worked without a flaw here, though that
probably does not help you much.
I too am using Mac OS 10.4.11 with GCC 4.0.1. Just wanted to let you
know.
Regards,
Jojo
--
git version 1.5.6.12.g73f03
^ permalink raw reply
* Re: policy and mechanism for less-connected clients
From: Petr Baudis @ 2008-06-25 14:03 UTC (permalink / raw)
To: David Jeske; +Cc: git
Hi,
On Wed, Jun 25, 2008 at 12:36:03AM -0000, David Jeske wrote:
> The purpose of this mechanism is to host a distributed source repository in a
> world where most most developer contributors are behind firewalls and do not
> have access to, or do not want to configure a unix server, ftp, or ssh to
> possibly contribute to a project. The model of allowing less-authoritative
> developers to make their changes available for more-authoritative users to pull
> is accepted as superior. However, no users are assumed to be authoritative over
> each-other, or an entire tree, and many users should have authority only to
> supply new deltas to their own branches. The ability to handle emailed patches
> is an asset, but is deemed too manual for this need.
BTW, have you read about git-bundle(1)?
> design assumptions:
>
> - all developers are firewalled and can not be "pulled" from directly.
> - there can be one or more well-connected servers which all users can access.
> - .. but which they cannot have ssh, ftp, or other dangerous access to
> - .. and whose protocol should be layered on http(s)
Please note that we support pushing using the HTTP DAV extensions. It
seems to be only rarely used in practice though, since developers seem
to either work at sane companies, are tunneling through the firewalls or
the firewalls are adjusted if this is required for development of their
day-job applications. There are some cases where this is useful, but I
don't tihnk they are very numerous (in practicular, I've had more
requests (about three?) for git-cvsserver than for HTTP DAV (zero to
one?) at repo.or.cz). Do _you_ have any real large-scale scenario where
this is an actual issue?
> - there is a shared namespace for branches, and tags
> - .. users are not-trusted to change the branches or tags of other users
> - .. only certain users are trusted to change the shared origin branches
> - .. also allow directory ACLS on shared branch commits
> - all their DAGs should be in a single repository for space efficiency
> - users generally want to follow well-named branches
> - .. will be free to follow any branch, and pull changes from any branch
Of course, if pushing through the DAV extensions this can get hairy;
if you allow push access for users, you better trust them since they can
touch the objects database. If you don't care about possible DoS attack
vectors, I assume you could configure refs permissions for various users
using some fancy Apache configuration.
As previously noted though, I believe the space efficiency is not an
issue in real world. Are you familiar with Git's alternates? In a Git
repository, you can specify alternate locations for searching objects,
so you can create a "sub-repository" for each user, where an alternate
is set up pointing to the object database of the main project
repository. Then, the bulk of the objects will be in the main repository
and the sub-repositories will carry only tiny amount of objects specific
to the local development of the given person.
This is exactly how (and large reason of why) the repo.or.cz forks are
set up, by the way.
--
Petr "Pasky" Baudis
The last good thing written in C++ was the Pachelbel Canon. -- J. Olson
^ permalink raw reply
* Re: [PATCH] cmd_reset: don't trash uncommitted changes unless told to
From: Theodore Tso @ 2008-06-25 13:51 UTC (permalink / raw)
To: Johannes Schindelin
Cc: Johannes Sixt, Boaz Harrosh, Junio C Hamano, Steven Walter, git,
jeske
In-Reply-To: <alpine.DEB.1.00.0806251334060.9925@racer>
On Wed, Jun 25, 2008 at 01:38:30PM +0100, Johannes Schindelin wrote:
> > $ git config alias.switch checkout
> > $ git switch topic
> >
> > Hm? Notice that the command even reports back:
> >
> > Switched to branch "topic"
> > ^^^^^^^^
>
> Nice. And now my friend says "why does this braindamaged Git not have
> that command by _default_? Hmm? It is _just as braindamaged_ as CVS!"
I agree that "git switch" would be a great alias to have for "git
checkout". It is much more intuitive; traditionally, the issue has
always been that it's not so intuitive for existing git users, who
have gotten used to the existing quirks, and it people won't want to
break things for the existing users. (There are analogues to this is
the English language --- why is it that "though", "through", "plough",
"cough", "hough", or "tough" don't rhyme[1]?)
[1] http://www.mipmip.org/tidbits/pronunciation.shtml
> And I would not have anything reasonable for my defense.
Neither does the English language; but just try changing it!
"Historical reasons" is for better or for worse a very strong
argument.
> Because Git _should_ have an intuitive command to switch branches by
> default. "git checkout" just does not fly, especially given that it can
> be used to revert single files (which "git revert" should know how to, but
> does not, see
> http://mid.gmane.org/7vlk8wshii.fsf@gitster.siamese.dyndns.org).
I used to argue for this, but gave up, because no one seemed to agree
with me. So now I just have the following in
/home/tytso/bin/git-revert-file and I am very happy:
#!/bin/sh
#
prefix=$(git rev-parse --show-prefix)
for i in $*
do
git show HEAD:$prefix$i > $i
done
It makes "git revert-file <file1> <file2> <file3>" do the right thing.
Yeah, it doesn't do enough error checking, and it doesn't handle
filenames with spaces, and there are probably other corner cases it
doesn't get right, but it's been enough to keep me happy. :-)
If someone wants to take the above and turn it into git-rename.sh and
try to submit it to the git tree --- they are welcome to do it. Or
heck, if Junio is willing to commit that it that with the appropriate
cleanups it would be accepted, I'd be willing to do the work. I just
got tired of arguing that the concept of "git revert-file" was in fact
useful, and so its existence could be justified, which IIRC was
disputed the last time we went around this topic. I know I wanted it,
though, so I implemented it for myself.
> I _do_ see a cause of confusion here, _even_ if I know Git pretty well.
As do I.... I think the expert git users have just leared how to work
around it, either by learning the non-linearities in the UI, or by our
own private hacks or aliases.
- Ted
^ permalink raw reply
* Re: policy and mechanism for less-connected clients
From: Theodore Tso @ 2008-06-25 13:34 UTC (permalink / raw)
To: David Jeske; +Cc: git
On Wed, Jun 25, 2008 at 05:20:49AM -0000, David Jeske wrote:
> The other big one is ACLs in 'well named' repositories, so multiple
> people can safely be allowed to add changes to them, without giving
> them ability to blow away the repository. I can see this isn't the
> way all git users work, but at least a few users working this way
> now with shared push repositories. This is just making it
> 'safer'. Also seems pretty easy to do.
So this isn't true security, since someone determined (or an ingenious
enough fool) can always blow away repository if you allow them to add
changes; they could just add a change which rm's all of the files,
yes? You just want to prevent something stupid.
Well, as long as they don't do non-fast forward updates (i.e., they
never do something like: "git push publish +head:head", or any other
incantation involving a leading '+' in the refspec), they should be
pretty safe. I don't see how they would do any damage just due to
user confusion. So I think git is pretty safe as-is.
> > This is also easy; you just establish remote tracking branches. I
> > have a single shell scripted command, git-get-all, which pulls from
> > all of the repositories I am interested in into various remote
> > tracking branches so while I am disconnected, I can see what other
> > folks have done on their trees.
>
> Yes, so I'd have the same thing, except instead of a remote
> repository, it would be a pattern of the branch namespace, such as
> /origin/users/jeske/*.
And the advantage of using branch namespaces instead of separate
remote repositories is.... ? I don't see any....
> Think about using CVS. user does "cvs up; hack hack hack; cvs commit
> (to server)". In git, this workflow is "git pull; hack; commit;
> hack; commit; git push (to server)". I want those interum "commits"
> to share the changes with the server. I want to change this to "git
> pull; hack; commit-and-share; hack; commit-and-share; git-push (to
> shared branch tag)"
OK, so *why* is it a good idea to ask people to share their
in-progress work? What's the upside? Maybe if the idea is as backup
if people are working from their laptops, and they're about to travel
internationally or some such, but in general, sharing in-progress work
is highly overrated.
The other thing is in your design assumption is that remote
repositories are somehow expensive, when in fact they are very cheap;
use either repo.or.cz or github; they support repo sharing so there
isn't major cost to letting each developer having their own repository
to push to.
So the way I would do things is to simply encourage people to do start
their work by branching off of an up-to-date master branch, but *not*
do any git pulls or git pushes. They can use git commit as necessary
to save interim work, and they do all of this work on a private
branch. When they are done doing their work, they should review the
git commit points and make sure they make sense; in some cases they
may be better off squashing the commits down to a single commit, or
possibly refactoring their work so that each individual commit is
free-standing, so that their series of commits is git-bisectable
(i.e., after each commit the tree will fully compile and fully pass
the project regression test suite).
Once they have done *that*, they make sure the master branch has been
fully updated, and then do a git-rebase on their feature branch so
that it is up-to-date with respect to master, and then they do a full
build and regression test. Then they switch back to the master
branch, and do a "git push publish" --- where <publish> is defined in
.git/config to be something like this:
[remote "publish"]
url = ssh://master.kernel.org/pub/scm/linux/kernel/git/tytso/ext4.git
push = refs/heads/master:refs/heads/master
This will *only* push the master branch (and not any of the feature
branches), and it will not allow non-fast forward merges. Hence, if
the user screwed up and accidentally made changes to the master branch
(say, an accidental git-rebase while on the master branch, or
something else bone-headed), the git push will fail. This gives you
the safety you desire about not accidentally screwing up the master branch.
And you're done. The only reason why you need a per-user repository
if you want some safety in terms of backups in case the work being
done on the laptop gets destroyed, but you can get that pretty much
for free via git.or.cz or github. I really don't buy the sharing
argument, because if you are in the middle of implementing a feature,
it's generally not useful for others to look at your in-progress work.
> I know that all of what I wrote above seems strange if you don't buy into the
> design assumptions. That it's critical to share a single server-repository,
> that it's critical to have a shared 'well known' branch that only trusts
> clients to add new changes to, etc.. However, these are important.
Yep. And you still haven't justified why it's critical to share a
single server repository. ***Why*** is that important?
And when you have shared push repositories, as long as users don't use
the '+', in practice they can only add new changes. And if you don't
trust them not to use the '+' character in refspecs, are you really
going to trust them not to introduce either bone-headed mistakes into
the code? Or to "git rm" the wrong files, git commit them, and then
merge that into the repository? If all you care about is avoiding the
accidentally stupid user mistakes, then putting in a convenience
default so that "git push publish" always does what you want should be
good enough.
So fundamentally, yeah, I think your primary problem is with the
design assumptions, which haven't been justified at all.
- Ted
^ 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