* Re: [PATCH] Rearrange git-format-patch synopsis to improve clarity.
From: David Symonds @ 2007-11-05 22:32 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, David Symonds
In-Reply-To: <119421522591-git-send-email-dsymonds@gmail.com>
On 11/5/07, David Symonds <dsymonds@gmail.com> wrote:
> [-s | --signoff] [<common diff options>]
> - [--start-number <n>] [--numbered-files]
> + [-n | --numbered-files | -N | --no-numbered]
> + [--start-number <n>]
Now that I look at it again, it seems the long options look quite
inconsistent. I think it should be either
--numbered-files/--no-numbered-files or --numbered/--no-numbered. My
preference is with the latter (for brevity), but that breaks
backward-compatibility.
Would you accept a patch that changed --numbered-files to --numbered,
and kept the former as a synonym?
Dave.
^ permalink raw reply
* [Patch] Documentation: enhanced "git for CVS users" doc about shared repositories
From: Francesco Pretto @ 2007-11-05 22:32 UTC (permalink / raw)
To: git
More detailed instructions on how to set up shared repositories.
Added a reference to "git for CVS users" doc in git-init manual.
Signed-off-by: Francesco Pretto <ceztkoml@gmail.com>
---
Documentation/cvs-migration.txt | 72 ++++++++++++++++++++++++++++++--------
Documentation/git-init.txt | 7 ++++
2 files changed, 64 insertions(+), 15 deletions(-)
diff --git a/Documentation/cvs-migration.txt b/Documentation/cvs-migration.txt
index 3b6b494..c92ed49 100644
--- a/Documentation/cvs-migration.txt
+++ b/Documentation/cvs-migration.txt
@@ -13,12 +13,12 @@ link:tutorial.html[tutorial introduction to git] should be sufficient.
Developing against a shared repository
--------------------------------------
-Suppose a shared repository is set up in /pub/repo.git on the host
+Suppose a shared repository is set up in /pub/scm/repo.git on the host
foo.com. Then as an individual committer you can clone the shared
repository over ssh with:
------------------------------------------------
-$ git clone foo.com:/pub/repo.git/ my-project
+$ git clone foo.com:/pub/scm/repo.git/ my-project
$ cd my-project
------------------------------------------------
@@ -68,37 +68,79 @@ other than `master`.
Setting Up a Shared Repository
------------------------------
-We assume you have already created a git repository for your project,
-possibly created from scratch or from a tarball (see the
-link:tutorial.html[tutorial]), or imported from an already existing CVS
-repository (see the next section).
+We assume you have admin privilege on the remote machine. Moreover, we assume
+you have already created a git repository for your project, possibly created
+from scratch or from a tarball (see the link:tutorial.html[tutorial]),or
+imported from an already existing CVS repository (see the next section).
-Assume your existing repo is at /home/alice/myproject. Create a new "bare"
-repository (a repository without a working tree) and fetch your project into
-it:
+First, let's create a common directory for all the projects you'll want to
+track with git:
+
+-----------------------------------------------
+$ mkdir -p /pub/scm
+-----------------------------------------------
+
+It's recommended, but not necessary, to create a specific group of commiters
+for every project/repository. With root credentials launch:
+
+------------------------------------------------
+$ groupadd $group
+------------------------------------------------
+
+Assume your existing repository is at /home/alice/myproject. Create a new
+"bare" repository (a repository without a working tree) and fetch your project
+into it:
------------------------------------------------
-$ mkdir /pub/my-repo.git
+$ mkdir /pub/scm/my-repo.git
$ cd /pub/my-repo.git
$ git --bare init --shared
$ git --bare fetch /home/alice/myproject master:master
------------------------------------------------
+Now, set the group ownership of the git repository you've just created to the
+same group of the commiters:
+
+------------------------------------------------
+$ chgrp -R $group /pub/scm/my-repo.git
+------------------------------------------------
+
Next, give every team member read/write access to this repository. One
easy way to do this is to give all the team members ssh access to the
machine where the repository is hosted. If you don't want to give them a
full shell on the machine, there is a restricted shell which only allows
users to do git pushes and pulls; see gitlink:git-shell[1].
-Put all the committers in the same group, and make the repository
-writable by that group:
+First, enable it putting on the trusted shells list of the system:
+
+------------------------------------------------
+$ echo `which git-shell` >> /etc/shells
+------------------------------------------------
+
+Ensure users will not have write permission on /pub/scm. Now, let's create
+them with the following command launched with root credentials:
------------------------------------------------
-$ chgrp -R $group /pub/my-repo.git
+$ useradd -g $group -d /pub/scm -s `which git-shell` $username
------------------------------------------------
-Make sure committers have a umask of at most 027, so that the directories
-they create are writable and searchable by other group members.
+They will be enabled to push on repositories owned by the group $group.
+Later, you can give users access to other projects simply by adding them to
+other groups.
+
+[NOTE]
+================================
+With previous versions of git, it could be necessary to set umask variable of
+all commiters with values like 002 or 007. If you still need to support them,
+you can do it in the following way; assuming that all users have their home
+positionated at /pub/scm, like in the previous example, launch the command:
+
+------------------------------------------------
+$ echo "umask 022" >> /pub/scm/.profile
+------------------------------------------------
+
+At the next login, users will have their umask variable automatically set.
+================================
Importing a CVS archive
-----------------------
diff --git a/Documentation/git-init.txt b/Documentation/git-init.txt
index 07484a4..f5f363d 100644
--- a/Documentation/git-init.txt
+++ b/Documentation/git-init.txt
@@ -101,6 +101,13 @@ $ git-add . <2>
<2> add all existing file to the index
+SHARED REPOSITORIES
+-------------------
+
+Please refer to link:cvs-migration.html[git for CVS users], section "Setting Up
+a Shared Repository", for details on how to set up shared repositories.
+
+
Author
------
Written by Linus Torvalds <torvalds@osdl.org>
^ permalink raw reply related
* Re: [PATCH] Rearrange git-format-patch synopsis to improve clarity.
From: Andreas Ericsson @ 2007-11-05 22:48 UTC (permalink / raw)
To: David Symonds; +Cc: Junio C Hamano, git
In-Reply-To: <ee77f5c20711051432w284cf22dx71192c145d25dced@mail.gmail.com>
David Symonds wrote:
> On 11/5/07, David Symonds <dsymonds@gmail.com> wrote:
>> [-s | --signoff] [<common diff options>]
>> - [--start-number <n>] [--numbered-files]
>> + [-n | --numbered-files | -N | --no-numbered]
>> + [--start-number <n>]
>
> Now that I look at it again, it seems the long options look quite
> inconsistent. I think it should be either
> --numbered-files/--no-numbered-files or --numbered/--no-numbered. My
> preference is with the latter (for brevity), but that breaks
> backward-compatibility.
>
> Would you accept a patch that changed --numbered-files to --numbered,
> and kept the former as a synonym?
>
I thought files were always numbered, but the [PATCH m/n] wasn't. Have I
missed something?
If your --numbered-files is supposed to affect only file-numbering, I'd
suggest *not* using --numbered, as it's ambiguous with "number-subject".
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
^ permalink raw reply
* Re: git pull opinion
From: Alex Riesen @ 2007-11-05 22:49 UTC (permalink / raw)
To: Aghiles; +Cc: git
In-Reply-To: <3abd05a90711051352t2f6be00bsa862585abd370fb1@mail.gmail.com>
Aghiles, Mon, Nov 05, 2007 22:52:12 +0100:
> ps; if someone is interested to hear what is the general opinion
> on switching to git from svn in our company, I could elaborate.
Yes, please. And how did you manage to convince them to switch, if possible:
there are still some suckers here trying to do the same to their colleagues.
^ permalink raw reply
* Re: [PATCH] git-mailsplit: with maildirs try to process new/ if cur/ is empty
From: Alex Riesen @ 2007-11-05 22:52 UTC (permalink / raw)
To: Gerrit Pape; +Cc: Fernando J. Pereda, git, Junio C Hamano
In-Reply-To: <20071105124920.17726.qmail@746e9cce42b49f.315fe32.mid.smarden.org>
Gerrit Pape, Mon, Nov 05, 2007 13:49:20 +0100:
> + for (i = 0; i < 2; ++i) {
> + snprintf(name, sizeof(name), "%s/%s", path, sub[i]);
> + if ((dir = opendir(name)) == NULL) {
> + error("cannot opendir %s (%s)", name, strerror(errno));
> + return -1;
> + }
Why is missing "cur" (or "new", for that matter) a fatal error?
Why is it error at all? How about just ignoring the fact?
^ permalink raw reply
* Re: [bug in next ?] git-fetch/git-push issue
From: Jeff King @ 2007-11-05 22:55 UTC (permalink / raw)
To: Daniel Barkalow; +Cc: Pierre Habouzit, Nicolas Pitre, Git ML
In-Reply-To: <Pine.LNX.4.64.0711051620230.7357@iabervon.org>
On Mon, Nov 05, 2007 at 04:41:37PM -0500, Daniel Barkalow wrote:
> > Nope, that's not the problem. We _only_ update any tracking refs at all
> > if ret == 0, and if we fail to push, then we are setting ret to -2.
>
> That's an odd combination of behavior: we update some of the refs, leave
> the ones that didn't work alone, report success on the ones that worked,
> but then we forget that some things worked?
I think the current behavior is more odd. We mark some errors, and then
if there were any possible pushes, we replace the marked errors with the
status of the actual push, forgetting about the previous errors. Thus
the behavior where if 'next' needs pushing, then we don't mark any errors
at all (even though we spewed an error to stderr), but if it doesn't,
then we return an error.
I don't mind being conservative with updating tracking refs; they really
are just an optimization to avoid an extra git-fetch. But the most
sensible behavior would be to mark errors for _each_ ref individually,
try to push or update tracking branches where appropriate, and then
return an error status based on all refs (whether they had an error in
prep time or at push time).
Which I guess is what you were trying to accomplish by removing the
peer_ref, though I think that doesn't distinguish between "didn't match
a remote ref" and "had an error." Perhaps we just need an error flag in
the ref struct?
> If we're going to refuse to update local tracking refs, whose state
> doesn't matter much, we should certainly refuse to update the remote refs,
> which are probably public and extremely important. If we just pushed and
I would also be fine with that: if your intended push has _any_
problems, then abort the push.
> we fetch, we should see exclusively changes that somebody else (including
> hooks remotely) did, not anything that we ourselves did.
I don't necessarily agree, just because the notion of "we" and "somebody
else" is sort of pointless in a distributed system. I consider local
tracking ref updates to be a "best guess" attempt to optimize and avoid
a fetch (but one that will always be overwritten by the _actual_
contents when you do fetch).
> I'd guess -2 is supposed to indicate that there were some errors but some
> things may have worked. If pack_objects() or receive_status() fails, we
In that case, I think the simple fix is:
diff --git a/builtin-send-pack.c b/builtin-send-pack.c
index 947c42b..f773dc8 100644
--- a/builtin-send-pack.c
+++ b/builtin-send-pack.c
@@ -338,7 +338,7 @@ static int do_send_pack(int in, int out, struct remote *remote, int nr_refspec,
packet_flush(out);
if (new_refs && !args.dry_run)
- ret = pack_objects(out, remote_refs);
+ ret |= pack_objects(out, remote_refs);
close(out);
if (expect_status_report) {
and then we accept that we don't know _which_ refs shouldn't have their
tracking branches updated (and we don't update any). But at least we
don't forget that the error occured.
And the better solution is an error flag (or bitfield) in struct ref.
-Peff
^ permalink raw reply related
* Re: [PATCH] Rearrange git-format-patch synopsis to improve clarity.
From: David Symonds @ 2007-11-05 22:56 UTC (permalink / raw)
To: Andreas Ericsson; +Cc: Junio C Hamano, git
In-Reply-To: <472F9DC6.8020607@op5.se>
On 11/6/07, Andreas Ericsson <ae@op5.se> wrote:
> David Symonds wrote:
> > On 11/5/07, David Symonds <dsymonds@gmail.com> wrote:
> >> [-s | --signoff] [<common diff options>]
> >> - [--start-number <n>] [--numbered-files]
> >> + [-n | --numbered-files | -N | --no-numbered]
> >> + [--start-number <n>]
> >
> > Now that I look at it again, it seems the long options look quite
> > inconsistent. I think it should be either
> > --numbered-files/--no-numbered-files or --numbered/--no-numbered. My
> > preference is with the latter (for brevity), but that breaks
> > backward-compatibility.
> >
> > Would you accept a patch that changed --numbered-files to --numbered,
> > and kept the former as a synonym?
> >
>
> I thought files were always numbered, but the [PATCH m/n] wasn't. Have I
> missed something?
>
> If your --numbered-files is supposed to affect only file-numbering, I'd
> suggest *not* using --numbered, as it's ambiguous with "number-subject".
You're right. There's both --numbered ([PATCH n/m] stuff) and
--numbered-files (0001.patch instead of 0001-subject-line.patch). I'll
revise my patch to clarify this.
Dave.
^ permalink raw reply
* [REPLACEMENT PATCH] Rearrange git-format-patch synopsis to improve clarity.
From: David Symonds @ 2007-11-05 23:04 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Andreas Ericsson, David Symonds
Signed-off-by: David Symonds <dsymonds@gmail.com>
---
Documentation/git-format-patch.txt | 3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/Documentation/git-format-patch.txt b/Documentation/git-format-patch.txt
index 92c0ab6..9d4bae2 100644
--- a/Documentation/git-format-patch.txt
+++ b/Documentation/git-format-patch.txt
@@ -9,9 +9,10 @@ git-format-patch - Prepare patches for e-mail submission
SYNOPSIS
--------
[verse]
-'git-format-patch' [-n | -N | -k] [-o <dir> | --stdout] [--thread]
+'git-format-patch' [-k] [-o <dir> | --stdout] [--thread]
[--attach[=<boundary>] | --inline[=<boundary>]]
[-s | --signoff] [<common diff options>]
+ [-n | --numbered | -N | --no-numbered]
[--start-number <n>] [--numbered-files]
[--in-reply-to=Message-Id] [--suffix=.<sfx>]
[--ignore-if-in-upstream]
--
1.5.3.1
^ permalink raw reply related
* Re: [PATCH] gc: use parse_options
From: Brandon Casey @ 2007-11-05 23:08 UTC (permalink / raw)
To: Junio C Hamano; +Cc: James Bowes, git
In-Reply-To: <7vhck579pm.fsf@gitster.siamese.dyndns.org>
Junio C Hamano wrote:
> James Bowes <jbowes@dangerouslyinc.com> writes:
>
>> + struct option builtin_gc_options[] = {
>> + OPT_BOOLEAN(0, "prune", &prune, "prune unused objects"),
>
> I would write "unreferenced loose" instead of "unused" here...
It is not just "loose" objects here, but also unreferenced objects in packs,
since the "-a" option to repack is now only used when --prune is specified.
Without --prune, "-A" is supplied to repack instead.
So maybe the message should just be "prune unreferenced objects"
-brandon
^ permalink raw reply
* Re: [PATCH 4/4] Implement git commit and status as a builtin commands.
From: Johannes Schindelin @ 2007-11-05 23:18 UTC (permalink / raw)
To: Björn Steinbrink; +Cc: Kristian Høgsberg, Junio C Hamano, git
In-Reply-To: <20071105192347.GA29997@atjola.homenet>
Hi,
On Mon, 5 Nov 2007, Bj?rn Steinbrink wrote:
> On 2007.11.05 13:57:53 -0500, Kristian H?gsberg wrote:
>
> > The shell script just has
> >
> > case "$all,$interactive,$also,$#" in
> > *t,*t,*)
> > die "Cannot use -a, --interactive or -i at the same time." ;;
> >
> > which doesn't seem to care about the value of $also. As far as I
> > understand git commit, it doesn't make sense to pass any of -a, -i, -o
> > or --interactive at the same time so I guess I could join the checks
>
> Note that there are only two commas. The asterisks catch everything and
> $# won't be "t", so that catches anything with at least two t's.
So shouldn't it be
if (!!all + !!interactive + !!also > 1)
Hmm?
Ciao,
Dscho
^ permalink raw reply
* Re: [bug in next ?] git-fetch/git-push issue
From: Junio C Hamano @ 2007-11-05 23:22 UTC (permalink / raw)
To: Jeff King; +Cc: Daniel Barkalow, Pierre Habouzit, Nicolas Pitre, Git ML
In-Reply-To: <20071105225540.GA10988@sigill.intra.peff.net>
Jeff King <peff@peff.net> writes:
> Which I guess is what you were trying to accomplish by removing the
> peer_ref, though I think that doesn't distinguish between "didn't match
> a remote ref" and "had an error." Perhaps we just need an error flag in
> the ref struct?
I agree that makes the most sense.
As Steffen has been advocating on another thread, depending on
your workflow, you do not care about some classes of push errors
per pushed refs. The update of the remote and local tracking
refs should be done in sync (i.e. if the remote wasn't updated,
never update the corresponding local), but it can depend on the
nature of the failure if a failure to update a remote ref should
result in the non-zero exit status from git-push as a whole.
And to implement that, per-ref error flag would be a good way to
go, methinks.
^ permalink raw reply
* Re: git pull opinion
From: Junio C Hamano @ 2007-11-05 23:33 UTC (permalink / raw)
To: Aghiles; +Cc: git
In-Reply-To: <3abd05a90711051352t2f6be00bsa862585abd370fb1@mail.gmail.com>
Aghiles <aghilesk@gmail.com> writes:
> Is there an "easier" way to pull into a dirty directory ? I am
> asking this to make sure I understand the problem and not
> because I find it annoying to type those 4 commands to perform
> a pull (although some of my colleagues do find that annoying :).
You need to switch your mindset from centralized SVN workflow.
The beauty of distributedness is that it redefines the meaning
of "to commit". In distributed systems, the act of committing
is purely checkpointing and it is not associated with publishing
the result to others as centralized systems force you to.
Stop thinking like "I need to integrate the changes from
upstream into my WIP to keep up to date." You first finish what
you are currently doing, at least to the point that it is
stable, make a commit to mark that state, and then start
thinking about what other people did. You may most likely do a
"git fetch" followed by "git rebase" to update your WIP on top
of the updated work by others.
Once you get used to that, you would not have "a dirty
directory" problem.
^ permalink raw reply
* Re: git pull opinion
From: Miklos Vajna @ 2007-11-05 23:40 UTC (permalink / raw)
To: Aghiles; +Cc: git
In-Reply-To: <3abd05a90711051352t2f6be00bsa862585abd370fb1@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 176 bytes --]
On Mon, Nov 05, 2007 at 04:52:12PM -0500, Aghiles <aghilesk@gmail.com> wrote:
> git stash
> git pull
> git stash apply
who will run git stash clear? :)
- VMiklos
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: [PATCH] git-revert is one of the most misunderstood command in git, help users out.
From: Johannes Schindelin @ 2007-11-05 23:40 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Steven Grimm, Pierre Habouzit, git
In-Reply-To: <7vlk9cmiyq.fsf@gitster.siamese.dyndns.org>
Hi,
On Mon, 5 Nov 2007, Junio C Hamano wrote:
> Steven Grimm <koreth@midwinter.com> writes:
>
> > But that suggested command is not going to convince anyone they were
> > wrong about git being hard to learn. I wonder if instead of saying, "I
> > know what you meant, but I'm going to make you type a different
> > command," we should make git revert just do what the user meant.
> >
> > There is already precedent for that kind of mixed-mode UI:
> >
> > git checkout my-branch
> > vs.
> > git checkout my/source/file.c
>
> That's an example of mixed-mode UI, but what you are suggesting is quite
> different, isn't it?
>
> There is no other officially supported single-command-way to
> checkout paths out of the index.
Okay, let's step back a bit.
We taught "git show" to show other objects than commits, by doing the
obvious things. So there _is_ a precendent to changing a commands
behaviour to accept more than just commits. And there was already another
command for the same purpose, cat-file, which was never meant as
porcelain however.
Now, what does "revert" _mean_? At the moment, it wants a commit, and
will undo the changes that commit introduced, _and commits it_ (asking
for a message).
What would I expect "git revert -- file" to do? It would undo the changes
to that file -- and since no commit was specified, I would expect it to
look at the changes against the index. (IOW exactly what Steven
proposed.)
To continue the analogy, it would have to commit the undoing of the
change. But since that change never was committed, I think it is more
natural to _not_ commit it.
In the same way, I would expect "git revert <commit> -- file" to undo the
changes in that commit to _that_ file (something like "git merge-file
file <commit>:file <commit>^:file"), but this time commit it, since it
was committed at one stage.
IMHO this would be a consistent behaviour _and_ help new git users.
After all, we are not Python, supposedly narrowing users down to
one-way-to-do-things only.
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH] git-revert is one of the most misunderstood command in git, help users out.
From: Alejandro Martinez Ruiz @ 2007-11-05 23:41 UTC (permalink / raw)
To: David Kastrup; +Cc: Steven Grimm, Pierre Habouzit, Junio C Hamano, git
In-Reply-To: <85sl3kny8u.fsf@lola.goethe.zz>
On Mon 05 Nov 2007, 23:06, David Kastrup wrote:
> Alejandro Martinez Ruiz <alex@flawedcode.org> writes:
> > On Mon 05 Nov 2007, 11:28, Steven Grimm wrote:
> >
> >> There is already precedent for that kind of mixed-mode UI:
> >>
> >> git checkout my-branch
> >> vs.
> >> git checkout my/source/file.c
> >
> > This is a different case: you're basically performing the same
> > operation, with the second line applying just to a subset of files.
>
> Huh? The first one moves HEAD. The second one doesn't.
That's why I wrote "basically". Anyway, the point is that this doesn't
seem to be a valid precedent.
- Alex
^ permalink raw reply
* Re: [bug in next ?] git-fetch/git-push issue
From: Daniel Barkalow @ 2007-11-05 23:46 UTC (permalink / raw)
To: Jeff King; +Cc: Pierre Habouzit, Nicolas Pitre, Git ML
In-Reply-To: <20071105225540.GA10988@sigill.intra.peff.net>
On Mon, 5 Nov 2007, Jeff King wrote:
> On Mon, Nov 05, 2007 at 04:41:37PM -0500, Daniel Barkalow wrote:
>
> > > Nope, that's not the problem. We _only_ update any tracking refs at all
> > > if ret == 0, and if we fail to push, then we are setting ret to -2.
> >
> > That's an odd combination of behavior: we update some of the refs, leave
> > the ones that didn't work alone, report success on the ones that worked,
> > but then we forget that some things worked?
>
> I think the current behavior is more odd. We mark some errors, and then
> if there were any possible pushes, we replace the marked errors with the
> status of the actual push, forgetting about the previous errors. Thus
> the behavior where if 'next' needs pushing, then we don't mark any errors
> at all (even though we spewed an error to stderr), but if it doesn't,
> then we return an error.
>
> I don't mind being conservative with updating tracking refs; they really
> are just an optimization to avoid an extra git-fetch. But the most
> sensible behavior would be to mark errors for _each_ ref individually,
> try to push or update tracking branches where appropriate, and then
> return an error status based on all refs (whether they had an error in
> prep time or at push time).
>
> Which I guess is what you were trying to accomplish by removing the
> peer_ref, though I think that doesn't distinguish between "didn't match
> a remote ref" and "had an error." Perhaps we just need an error flag in
> the ref struct?
That's possible, but I think we currently only care about per-ref stuff
for whether we actually did a push to that ref, and we care about whether
we had a failure that affects all refs, and we care (for the return value)
whether we have any errors at all.
> > If we're going to refuse to update local tracking refs, whose state
> > doesn't matter much, we should certainly refuse to update the remote refs,
> > which are probably public and extremely important. If we just pushed and
>
> I would also be fine with that: if your intended push has _any_
> problems, then abort the push.
>
> > we fetch, we should see exclusively changes that somebody else (including
> > hooks remotely) did, not anything that we ourselves did.
>
> I don't necessarily agree, just because the notion of "we" and "somebody
> else" is sort of pointless in a distributed system. I consider local
> tracking ref updates to be a "best guess" attempt to optimize and avoid
> a fetch (but one that will always be overwritten by the _actual_
> contents when you do fetch).
I think it's actually very significant what commits made locally have
or haven't been made public.
> > I'd guess -2 is supposed to indicate that there were some errors but some
> > things may have worked. If pack_objects() or receive_status() fails, we
>
> In that case, I think the simple fix is:
>
> diff --git a/builtin-send-pack.c b/builtin-send-pack.c
> index 947c42b..f773dc8 100644
> --- a/builtin-send-pack.c
> +++ b/builtin-send-pack.c
> @@ -338,7 +338,7 @@ static int do_send_pack(int in, int out, struct remote *remote, int nr_refspec,
>
> packet_flush(out);
> if (new_refs && !args.dry_run)
> - ret = pack_objects(out, remote_refs);
> + ret |= pack_objects(out, remote_refs);
> close(out);
>
> if (expect_status_report) {
>
> and then we accept that we don't know _which_ refs shouldn't have their
> tracking branches updated (and we don't update any). But at least we
> don't forget that the error occured.
>
> And the better solution is an error flag (or bitfield) in struct ref.
How about this, in addition to my previous dropping peer_ref:
diff --git a/builtin-send-pack.c b/builtin-send-pack.c
index 947c42b..1b7206c 100644
--- a/builtin-send-pack.c
+++ b/builtin-send-pack.c
@@ -337,8 +343,10 @@ static int do_send_pack(int in, int out, struct remote *remote, int nr_refspec,
}
packet_flush(out);
- if (new_refs && !args.dry_run)
- ret = pack_objects(out, remote_refs);
+ if (new_refs && !args.dry_run) {
+ if (pack_objects(out, remote_refs))
+ ret = -4;
+ }
close(out);
if (expect_status_report) {
@@ -346,7 +354,7 @@ static int do_send_pack(int in, int out, struct remote *remote, int nr_refspec,
ret = -4;
}
- if (!args.dry_run && remote && ret == 0) {
+ if (!args.dry_run && remote && ret != -4) {
for (ref = remote_refs; ref; ref = ref->next)
update_tracking_ref(remote, ref);
}
That is, -2 means that we've done less than was asked, but nothing blew
up; -4 means something blew up. When we skip something, we drop peer_ref
from it, so there's nothing to update (and it's dropped from the set of
mappings, in case we cared further about it with respect to reporting the
actions we actually took). Then we update all refs that were acted on if
ret isn't -4, and we return non-zero if ret is either -2 or -4.
-Daniel
*This .sig left intentionally blank*
^ permalink raw reply related
* Re: [Patch] Documentation: enhanced "git for CVS users" doc about shared repositories
From: Junio C Hamano @ 2007-11-05 23:52 UTC (permalink / raw)
To: Francesco Pretto; +Cc: git
In-Reply-To: <472F99F8.4010904@gmail.com>
Francesco Pretto <ceztkoml@gmail.com> writes:
> More detailed instructions on how to set up shared repositories.
> Added a reference to "git for CVS users" doc in git-init manual.
>
> Signed-off-by: Francesco Pretto <ceztkoml@gmail.com>
> ---
> Documentation/cvs-migration.txt | 72 ++++++++++++++++++++++++++++++--------
> Documentation/git-init.txt | 7 ++++
> 2 files changed, 64 insertions(+), 15 deletions(-)
>
> diff --git a/Documentation/cvs-migration.txt b/Documentation/cvs-migration.txt
> index 3b6b494..c92ed49 100644
> --- a/Documentation/cvs-migration.txt
> +++ b/Documentation/cvs-migration.txt
> @@ -13,12 +13,12 @@ link:tutorial.html[tutorial introduction to git] should be sufficient.
> Developing against a shared repository
> --------------------------------------
>
> -Suppose a shared repository is set up in /pub/repo.git on the host
> +Suppose a shared repository is set up in /pub/scm/repo.git on the host
> foo.com. Then as an individual committer you can clone the shared
> repository over ssh with:
>
> ------------------------------------------------
> -$ git clone foo.com:/pub/repo.git/ my-project
> +$ git clone foo.com:/pub/scm/repo.git/ my-project
> $ cd my-project
> ------------------------------------------------
This part seems an unnecessary change.
> @@ -68,37 +68,79 @@ other than `master`.
> Setting Up a Shared Repository
> ------------------------------
>
> -We assume you have already created a git repository for your project,
> -possibly created from scratch or from a tarball (see the
> -link:tutorial.html[tutorial]), or imported from an already existing CVS
> -repository (see the next section).
> +We assume you have admin privilege on the remote machine. Moreover, we assume
> +you have already created a git repository for your project, possibly created
> +from scratch or from a tarball (see the link:tutorial.html[tutorial]),or
> +imported from an already existing CVS repository (see the next section).
Don't assume the "admin privilege" part, as you do not have to.
You are newly hired to work on project-X, and the sysadm throws
you into projectx group. Thesysadm further prepares a directory
'/pub/project-X' and makes it mode 2775 (aka ug=rwx,o=rx,g+s).
Do you want to create a new repository for projext-X group's
use? You do:
$ cd /pub/project-X
$ GIT_DIR=mine.git git init --shared
and you now have a usable /pub/project-X/mine.git repository for
project members. I do not think you would need any chmod/chgrp
after this step.
> +First, let's create a common directory for all the projects you'll want to
> +track with git:
> +
> +-----------------------------------------------
> +$ mkdir -p /pub/scm
> +-----------------------------------------------
An organization may use different SCM depending on the projects'
needs, and there is no reason members of projects A and B should
be in the same group 'git' while having members of project C in
group 'hg' only because A and B happen to use git. It would
make more sense to either (1) make members of all three projects
belong to 'src' group, or (2) make three groups, one for each
project.
IOW, I do not think the above is a good suggestion.
Also with the "create new --shared repository for the project in
a group's directory that has mode 2755" approach, I do not think
there is any need to muck with umask either.
^ permalink raw reply
* [BUG] git grep broken on master - won't work when merging
From: Martin Langhoff @ 2007-11-05 23:53 UTC (permalink / raw)
To: git list
Strange behaviour of git grep on one of the projects I hack on...
$ git --version
git version 1.5.3.5.561.g140d
$ git grep LOB lib
fatal: insanely many options to grep
After a bit of head-scratching I realised I was in the middle of a
merge, with some unresolved paths in the lib directory. A bit of
testing shows that the unresolved index is probably the problem:
$ git grep LOB lib
fatal: insanely many options to grep
# an unresolved file
$ git grep LOB lib/accesslib.php
fatal: insanely many options to grep
$ git grep --cached LOB lib
(... expected grep output...)
$ git reset --hard
$ git grep LOB lib
(... expected grep output...)
... not sure what the correct behaviour should be -- I guess the most
reasonable action would be to grep the files on disk for those
unresolved paths. In any case, the error message is insanely many
confusing to user! ;-)
Probably whitespace damaged...
diff --git a/builtin-grep.c b/builtin-grep.c
index c7b45c4..1831ef0 100644
--- a/builtin-grep.c
+++ b/builtin-grep.c
@@ -213,7 +213,7 @@ static int flush_grep(struct grep_opt *opt,
* arguments even for the call in the main loop.
*/
if (kept)
- die("insanely many options to grep");
+ die("Unresolved index or too many options to grep");
/*
* If we have two or more paths, we do not have to do
cheers,
martin
^ permalink raw reply related
* Re: [ANNOUNCE] cgit v0.7
From: Lars Hjemli @ 2007-11-05 23:53 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git list
In-Reply-To: <1194222569-13948-1-git-send-email-jnareb@gmail.com>
On Nov 5, 2007 1:29 AM, Jakub Narebski <jnareb@gmail.com> wrote:
> * I'm not sure if it wouln't be beter to provide -n/+m lines changed
> instead of nn likes changed column.
Agreed, and fixed.
--
larsh
^ permalink raw reply
* Re: [PATCH 3/3] pretty=format: Avoid some expensive calculations when not needed
From: Johannes Schindelin @ 2007-11-05 23:53 UTC (permalink / raw)
To: René Scharfe; +Cc: Junio C Hamano, git
In-Reply-To: <472F7B2F.4050608@lsrfire.ath.cx>
Hi,
On Mon, 5 Nov 2007, Ren? Scharfe wrote:
> Junio C Hamano schrieb:
> > Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> >
> >> Unfortunately, we cannot reuse the result of that function, which
> >> would be cleaner: there are more users than just git log. Most
> >> notably, git-archive with "$Format:...$" substitution.
> >
> > That makes sense.
> >
> >
> >> diff --git a/pretty.c b/pretty.c
> >> index 490cede..241e91c 100644
> >> --- a/pretty.c
> >> +++ b/pretty.c
> >> @@ -393,6 +393,7 @@ void format_commit_message(const struct commit *commit,
> >> int i;
> >> enum { HEADER, SUBJECT, BODY } state;
> >> const char *msg = commit->buffer;
> >> + char *active = interp_find_active(format, table, ARRAY_SIZE(table));
> >> ...
> >> + if (active[IHASH])
> >> + interp_set_entry(table, IHASH,
> >> + sha1_to_hex(commit->object.sha1));
> >> + if (active[IHASH_ABBREV])
> >> + interp_set_entry(table, IHASH_ABBREV,
> >> find_unique_abbrev(commit->object.sha1,
> >> DEFAULT_ABBREV));
> >
> > Instead of allocating a separate array and freeing at the end,
> > wouldn't it make more sense to have a bitfield that records what
> > is used by the format string inside the array elements?
>
> How about (ab)using the value field? Let interp_find_active() mark
> unneeded entries with NULL, and the rest with some cookie. All table
> entries with non-NULL values need to be initialized. interp_set_entry()
> needs to be aware of this cookie, as it mustn't free() it. The cookie
> could be the address of a static char* in interpolate.c.
Yeah, something like this on top of my earlier patch (and obviously the
corresponding change from "if (active[IHASH])" to
"if (table[IHASH].value)"):
---
interpolate.c | 10 ++++------
interpolate.h | 2 +-
2 files changed, 5 insertions(+), 7 deletions(-)
diff --git a/interpolate.c b/interpolate.c
index 80eeb36..05a22e1 100644
--- a/interpolate.c
+++ b/interpolate.c
@@ -5,13 +5,14 @@
#include "git-compat-util.h"
#include "interpolate.h"
+static const char *empty_value = "";
void interp_set_entry(struct interp *table, int slot, const char *value)
{
char *oldval = table[slot].value;
char *newval = NULL;
- if (oldval)
+ if (oldval && oldval != empty_value)
free(oldval);
if (value)
@@ -103,10 +104,9 @@ unsigned long interpolate(char *result, unsigned long reslen,
return newlen;
}
-char *interp_find_active(const char *orig,
+void interp_find_active(const char *orig,
const struct interp *interps, int ninterps)
{
- char *result = xcalloc(1, ninterps);
char c;
int i;
@@ -115,10 +115,8 @@ char *interp_find_active(const char *orig,
/* Try to match an interpolation string. */
for (i = 0; i < ninterps; i++)
if (!prefixcmp(orig, interps[i].name + 1)) {
- result[i] = 1;
+ interps[i].value = empty_value;
orig += strlen(interps[i].name + 1);
break;
}
-
- return result;
}
diff --git a/interpolate.h b/interpolate.h
index 2d197c5..19b7ebe 100644
--- a/interpolate.h
+++ b/interpolate.h
@@ -22,7 +22,7 @@ extern void interp_clear_table(struct interp *table, int ninterps);
extern unsigned long interpolate(char *result, unsigned long reslen,
const char *orig,
const struct interp *interps, int ninterps);
-extern char *interp_find_active(const char *orig,
+extern void interp_find_active(const char *orig,
const struct interp *interps, int ninterps);
#endif /* INTERPOLATE_H */
Hmm?
Ciao,
Dscho
^ permalink raw reply related
* Re: [PATCH] Make git-clean a builtin
From: Junio C Hamano @ 2007-11-05 23:54 UTC (permalink / raw)
To: Carlos Rica; +Cc: Junio C Hamano, Shawn Bohrer, git
In-Reply-To: <1b46aba20711051410h370072e7he9cbebb54a789dac@mail.gmail.com>
"Carlos Rica" <jasampler@gmail.com> writes:
> 2007/11/5, Junio C Hamano <gitster@pobox.com>:
>> Shawn Bohrer <shawn.bohrer@gmail.com> writes:
>>
>> > +static int show_only = 0;
>> > +static int remove_directories = 0;
>> > +static int quiet = 0;
>> > +static int ignored = 0;
>> > +static int ignored_only = 0;
>>
>> Please do not explicitly initialize static variables to zero.
>
> Is it really needed to declare those variables outside of a function
> in this case?
I do not think so --- I suspect that this is a simple cut &
paste from the standalone ls-files implementation.
^ permalink raw reply
* Re: [bug in next ?] git-fetch/git-push issue
From: Daniel Barkalow @ 2007-11-05 23:59 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Jeff King, Pierre Habouzit, Nicolas Pitre, Git ML
In-Reply-To: <7vhck0mg5y.fsf@gitster.siamese.dyndns.org>
On Mon, 5 Nov 2007, Junio C Hamano wrote:
> Jeff King <peff@peff.net> writes:
>
> > Which I guess is what you were trying to accomplish by removing the
> > peer_ref, though I think that doesn't distinguish between "didn't match
> > a remote ref" and "had an error." Perhaps we just need an error flag in
> > the ref struct?
>
> I agree that makes the most sense.
>
> As Steffen has been advocating on another thread, depending on
> your workflow, you do not care about some classes of push errors
> per pushed refs. The update of the remote and local tracking
> refs should be done in sync (i.e. if the remote wasn't updated,
> never update the corresponding local), but it can depend on the
> nature of the failure if a failure to update a remote ref should
> result in the non-zero exit status from git-push as a whole.
>
> And to implement that, per-ref error flag would be a good way to
> go, methinks.
I think dropping peer_ref may be the clearest semantics. If push decides
not to actually perform a push, we can just remove it from the list of
operations we're performing. Independant of this, we can decide whether to
signal an error, and whether an error means that the remote end will have
done nothing at all (in which case, we must not update tracking refs).
That is, on top of my changes in other email, Steffan would have the
strictly behind case just not have the "ret = -2" and everything else
would be fine.
-Daniel
*This .sig left intentionally blank*
^ permalink raw reply
* Re: [PATCH] git-revert is one of the most misunderstood command in git, help users out.
From: Pierre Habouzit @ 2007-11-06 0:08 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Junio C Hamano, Steven Grimm, git
In-Reply-To: <Pine.LNX.4.64.0711052325090.4362@racer.site>
[-- Attachment #1: Type: text/plain, Size: 2950 bytes --]
On Mon, Nov 05, 2007 at 11:40:46PM +0000, Johannes Schindelin wrote:
> Hi,
>
> On Mon, 5 Nov 2007, Junio C Hamano wrote:
>
> > Steven Grimm <koreth@midwinter.com> writes:
> >
> > > But that suggested command is not going to convince anyone they were
> > > wrong about git being hard to learn. I wonder if instead of saying, "I
> > > know what you meant, but I'm going to make you type a different
> > > command," we should make git revert just do what the user meant.
> > >
> > > There is already precedent for that kind of mixed-mode UI:
> > >
> > > git checkout my-branch
> > > vs.
> > > git checkout my/source/file.c
> >
> > That's an example of mixed-mode UI, but what you are suggesting is quite
> > different, isn't it?
> >
> > There is no other officially supported single-command-way to
> > checkout paths out of the index.
>
> Okay, let's step back a bit.
>
> We taught "git show" to show other objects than commits, by doing the
> obvious things. So there _is_ a precendent to changing a commands
> behaviour to accept more than just commits. And there was already another
> command for the same purpose, cat-file, which was never meant as
> porcelain however.
>
> Now, what does "revert" _mean_? At the moment, it wants a commit, and
> will undo the changes that commit introduced, _and commits it_ (asking
> for a message).
>
> What would I expect "git revert -- file" to do? It would undo the changes
> to that file -- and since no commit was specified, I would expect it to
> look at the changes against the index. (IOW exactly what Steven
> proposed.)
>
> To continue the analogy, it would have to commit the undoing of the
> change. But since that change never was committed, I think it is more
> natural to _not_ commit it.
>
> In the same way, I would expect "git revert <commit> -- file" to undo the
> changes in that commit to _that_ file (something like "git merge-file
> file <commit>:file <commit>^:file"), but this time commit it, since it
> was committed at one stage.
I agree that this is something that really makes sense to me, and does
not looks like a perversion of the UI, and quite a nice extension in
fact. And it would _finally_ solve the issue that for _ANYTHING_ on the
planet that I've used for more than 10 seconds, $SCM revert path/to/file
reverts local changes :)
When you look at how git-revert is implemented, you'll see that it
uses the very same code as git cherry-pick does, and in fact, I've
wanted a git cherry-pick <commit> -- path1 path2 path3 for a _very_ long
time, and your proposal would just gracefully give it as a bonus I
believe (of course uncommited changes have no sense for a cherry-pick).
I like it a lot.
--
·O· Pierre Habouzit
··O madcoder@debian.org
OOO http://www.madism.org
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: git pull opinion
From: Johannes Schindelin @ 2007-11-06 0:08 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git
In-Reply-To: <fgo5dt$avh$1@ger.gmane.org>
Hi,
On Mon, 5 Nov 2007, Jakub Narebski wrote:
> Aghiles wrote:
>
> > I am not sure this is the best place to write about this. Anyway,
> > we just switched a couple of repositories to git (from svn) here
> > at work and one thing people find annoying is a pull into
> > a dirty directory. Before the "stash" feature it was even worse
> > but now we can type:
> >
> > ? ? git stash
> > ? ? git pull
> > ? ? git stash apply
> >
> > But isn't that something we should be able to specify to the "pull"
> > command ?
>
> If I remember correctly there is/was some preliminary work (at most 'pu'
> stages) about adding --dirty option to git-merge, git-pull and git-rebase.
There was, but AFAICT these are dead now.
The consense was that you are much better off committing first, then
pulling. And if the work you are doing really is not committable, but you
_have_ to pull _now_, you use stash. Although you are quite likely to
revert the pull when it succeeds, and _then_ unstash.
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH] t5530-upload-pack-error: Check more carefully for failures.
From: Junio C Hamano @ 2007-11-06 0:22 UTC (permalink / raw)
To: Johannes Sixt; +Cc: git
In-Reply-To: <200711052240.12822.johannes.sixt@telecom.at>
Johannes Sixt <johannes.sixt@telecom.at> writes:
> On Monday 05 November 2007 21:05, Junio C Hamano wrote:
> > > The test case checks for failures in rev-list (a missing
> > > object). Any hints how to trigger a failure in pack-objects
> > > that does not also trigger in rev-list would be welcome.
> >
> > How about removing a blob from the test repository to corrupt
> > it? rev-list --objects I think would happily list the blob
> > because it sees its name in its containing tree without checking
> > its existence.
>
> That does it. This goes on top of my previous patch.
Thanks. Will squash with further changes attached for readability.
---
t/t5530-upload-pack-error.sh | 11 +++++++++--
1 files changed, 9 insertions(+), 2 deletions(-)
diff --git a/t/t5530-upload-pack-error.sh b/t/t5530-upload-pack-error.sh
index 70d4f86..cc8949e 100755
--- a/t/t5530-upload-pack-error.sh
+++ b/t/t5530-upload-pack-error.sh
@@ -6,6 +6,13 @@ test_description='errors in upload-pack'
D=`pwd`
+corrupt_repo () {
+ object_sha1=$(git rev-parse "$1") &&
+ ob=$(expr "$object_sha1" : "\(..\)") &&
+ ject=$(expr "$object_sha1" : "..\(..*\)") &&
+ rm -f ".git/objects/$ob/$ject"
+}
+
test_expect_success 'setup and corrupt repository' '
echo file >file &&
@@ -15,7 +22,7 @@ test_expect_success 'setup and corrupt repository' '
test_tick &&
echo changed >file &&
git commit -a -m changed &&
- rm -f .git/objects/5e/a2ed416fbd4a4cbe227b75fe255dd7fa6bd4d6
+ corrupt_repo HEAD:file
'
@@ -35,7 +42,7 @@ test_expect_success 'upload-pack fails due to error in pack-objects' '
test_expect_success 'corrupt repo differently' '
git hash-object -w file &&
- rm -f .git/objects/be/c63e37d08c454ad3a60cde90b70f3f7d077852
+ corrupt_repo HEAD^^{tree}
'
^ permalink raw reply related
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