* Branch renaming not updating the configuration correctly.
From: Jurko Gospodnetić @ 2008-07-28 13:36 UTC (permalink / raw)
To: git
Hi.
I noticed that the .git/config file is not updated completely in case
you create two branches aaa and bbb, set the repository up so it
automatically merges changes from bbb into aaa and then rename the branches:
Here is an exact list of commands and config file contents
illustrating the problem:
> git branch aaa
> git branch bbb
> git config --add branch.aaa.remote .
> git config --add branch.aaa.merge bbb
-- .git/config: --
[branch "aaa"]
remote = .
merge = bbb
------------------
> git branch -m aaa patched
> git branch -m bbb original
-- .git/config: --
[branch "patched"]
remote = .
merge = bbb
------------------
And as you can see above, the branch.patched.merge configuration
setting did not get updated and still holds the old branch name 'bbb'.
Hope this helps.
Best regards,
Jurko Gospodnetić
^ permalink raw reply
* Re: [PATCH 6/6] Add a new test for using a custom merge strategy
From: Johannes Schindelin @ 2008-07-28 13:12 UTC (permalink / raw)
To: Miklos Vajna; +Cc: git
In-Reply-To: <03fa2187a72957d98d63ab899b39e9adc2edfe99.1217207602.git.vmiklos@frugalware.org>
Hi,
On Mon, 28 Jul 2008, Miklos Vajna wrote:
> Testing is done by creating a simple git-merge-theirs strategy which is
> the opposite of ours. Using this in real merges is not recommended but
> it's perfect for our testing needs.
Note that what was asked for, and what Junio implemented before deciding
that it would do more harm than good in git.git, is not the same as what
you provide.
Your -theirs is a strict opposite of -ours, i.e. the tree after the
merge will be identical to the "merged" branch's tip's.
The -theirs which was asked for (and which I truly think is insane) wanted
to do a merge, and in case of merge conflicts take the "upstream" version
_only of the conflicting hunks_.
Just to make sure everyone grasps why this is bad:
- there is not only a real chance, but a high probability that a merge
conflict means that some related, unconflicting change relies on _one_
version of the conflicting hunk which might very well be "ours", and
- since we have a _recursive_ merge, the notion of "upstream" is
completely bogus when working on any merge that has more than one merge
base. This merge would succeed, but actively be wrong.
Just to make sure people do not have to ask for that version of
"-theirs" again,
Dscho
^ permalink raw reply
* Re: [PATCH 5/6] builtin-merge: avoid non-strategy git-merge commands in error message
From: Johannes Schindelin @ 2008-07-28 13:06 UTC (permalink / raw)
To: Miklos Vajna; +Cc: git
In-Reply-To: <42e8615f6cbd236e40b19f2a754807f08e4b85a6.1217207602.git.vmiklos@frugalware.org>
Hi,
On Mon, 28 Jul 2008, Miklos Vajna wrote:
> - list_commands("git-merge-", "strategies");
> + list_commands("git-merge-", "strategies", ¬_strategies);
The change in the signature of list_commands() is not part of this patch.
So at least one of your commits should result in an uncompileable
revision...
Ciao,
Dscho
^ permalink raw reply
* Re: New mailmap file for the kernel
From: Jon Smirl @ 2008-07-28 12:47 UTC (permalink / raw)
To: sverre, Linus Torvalds; +Cc: Johannes Schindelin, Git Mailing List
In-Reply-To: <bd6139dc0807280453rbfc28ffid8314e74cc19b7f7@mail.gmail.com>
On 7/28/08, Sverre Rabbelier <alturin@gmail.com> wrote:
> On Mon, Jul 28, 2008 at 13:23, Johannes Schindelin
>
> <Johannes.Schindelin@gmx.de> wrote:
>
> > And how exactly do you plan to make sure everybody has that hook
> > installed?
>
>
> It needn't be installed with everybody, only at the people that form
> 'upstream' (in the git case that'd be Junio, in the Linux case that'd
> be Linus and his lieutenants).
That's the idea. The lieutenants would have the hook and stop anything
that introduced new errors into the file. checkpatch.pl would get the
same hook. And we'd make it available to all developers too. Someone
want to help out are write the hook? My hands hurt from editing the
mailmap file for too long.
We really need a hook to start the validation process. Putting all of
the existing names in the file makes it easier to write the hook. I
was surprised that 12% of all names in the log had errors in them.
That's a terrible error rate.
Making sure nothing slips through is not that bad. Use git log to
extract all email addresses. Run a script to ensure that they are all
in the mail map file.Add the missing ones, there should only be a few.
If the commit validation process works there shouldn't be any.
It's not just statistics, what it we had to contact everyone because
of some licensing or patent mess? Mozilla has had to contact everyone
three times now.
Bottom line this is Linus' call. Does he want a validation mechanism
for names and email addresses in the log?
> > Also, it would be a major hassle, just for the benefits of statistics
> > (which, funnily enough, not everybody cares about).
>
>
> Hmmm, I'm not sure if it would be a major hassle once it's set up?
> Once everybody has their name correctly in the mailmap nobody will
> have to care?
>
>
> > But we are not truly distributed. Our community is small enough, and our
> > maintainer good enough, that we do have a single upstream essentially. We
> > do not even have lieutenants through which new developers could come (and
> > therefore would be old developers once they hit master).
>
>
> Ah, I did not realize that. Thanks for explaining.
>
> --
> Cheers,
>
>
> Sverre Rabbelier
>
--
Jon Smirl
jonsmirl@gmail.com
^ permalink raw reply
* Re: Adding custom hooks to a bare repository.
From: Thomas Adam @ 2008-07-28 12:40 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git mailing list
In-Reply-To: <alpine.DEB.1.00.0807281438220.2725@eeepc-johanness>
2008/7/28 Johannes Schindelin <Johannes.Schindelin@gmx.de>:
> For all those reasons, it is better to just commit an executable script in
> your <toplevel>/githooks/post-merge and ask your users to copy it to
> .git/hooks/.
Grand. Thank you very much. :)
-- Thomas Adam
^ permalink raw reply
* Re: [PATCH] Remove references to git-fetch-pack from "git clone" documentation.
From: Johannes Schindelin @ 2008-07-28 12:41 UTC (permalink / raw)
To: Steve Haslam; +Cc: git
In-Reply-To: <488DBC72.8040204@lastminute.com>
Hi,
On Mon, 28 Jul 2008, Steve Haslam wrote:
> I think that the documentation was perhaps too explicit and as a result
> stale: git-clone certainly does not work any more by creating a
> "--exec=..." argument to pass to the git-fetch-pack command even
> internally, it calls code in transport.c.
Ah, that is a valid concern which I missed.
Thanks,
Dscho
^ permalink raw reply
* Re: Adding custom hooks to a bare repository.
From: Johannes Schindelin @ 2008-07-28 12:40 UTC (permalink / raw)
To: Thomas Adam; +Cc: git mailing list
In-Reply-To: <18071eea0807280532l69d12e3ehb8377da9d24e035@mail.gmail.com>
Hi,
On Mon, 28 Jul 2008, Thomas Adam wrote:
> 2008/7/28 Johannes Schindelin <Johannes.Schindelin@gmx.de>:
>
> > Yes. Hooks, just as the config and reflogs, are supposed to be local
> > things. Rationale being: it is rude, and also insecure, to install
> > something that potentially calls other programs without the user
> > saying so.
>
> Oh absolutely, I agree with that.
>
> > All you can do is checking in a copy of the hook, and ask your
> > users/check in your build system that it is installed.
>
> Hmm -- perhaps I am being unintentionally dense, but I am assuming
> that when you say "checking in a copy" you mean anywhere other than
> .git/hooks/ since that isn't tracked by git. I have no problem with
> the rationale you've just described -- but it would be handy to add
> this post-merge hook script into hooks/ (exec bit removed) such that
> on a clone, all one would need to do is chmod +x it. If that's
> possible, I'm clearly missing the steps to enable this.
No, as you said, anything in .git/ is not meant to be tracked. Besides,
if a user would change the executable bit (as advised), Git would always
show this file as modified, making the tree permanently dirty (or worse,
it could be accidentally be committed as executable).
For all those reasons, it is better to just commit an executable script in
your <toplevel>/githooks/post-merge and ask your users to copy it to
.git/hooks/.
Hth,
Dscho
^ permalink raw reply
* Re: [PATCH] Remove references to git-fetch-pack from "git clone" documentation.
From: Steve Haslam @ 2008-07-28 12:32 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git
In-Reply-To: <alpine.DEB.1.00.0807260523520.26810@eeepc-johanness>
Johannes Schindelin wrote:
> Hi,
>
> On Fri, 25 Jul 2008, Steve Haslam wrote
>> "git clone" no longer calls "git-fetch-pack",
>>
>
> So it calls it internally, avoiding fork() and exec(). But the code is
> still git-fetch-pack's. The difference should be lost on the regular Git
> user.
>
Well, I would say that the git-clone command uses code that is also used
by the git-fetch-pack command; but as you indicate, this is a minor
implementation detail.
I think that the documentation was perhaps too explicit and as a result
stale: git-clone certainly does not work any more by creating a
"--exec=..." argument to pass to the git-fetch-pack command even
internally, it calls code in transport.c. As you say, the difference is
immaterial to most users, and a simplified version of the documentation
should be adequate (and possibly clearer).
SRH
^ permalink raw reply
* Re: Adding custom hooks to a bare repository.
From: Thomas Adam @ 2008-07-28 12:32 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git mailing list
In-Reply-To: <alpine.DEB.1.00.0807281324350.2725@eeepc-johanness>
2008/7/28 Johannes Schindelin <Johannes.Schindelin@gmx.de>:
> Yes. Hooks, just as the config and reflogs, are supposed to be local
> things. Rationale being: it is rude, and also insecure, to install
> something that potentially calls other programs without the user saying
> so.
Oh absolutely, I agree with that.
> All you can do is checking in a copy of the hook, and ask your users/check
> in your build system that it is installed.
Hmm -- perhaps I am being unintentionally dense, but I am assuming
that when you say "checking in a copy" you mean anywhere other than
.git/hooks/ since that isn't tracked by git. I have no problem with
the rationale you've just described -- but it would be handy to add
this post-merge hook script into hooks/ (exec bit removed) such that
on a clone, all one would need to do is chmod +x it. If that's
possible, I'm clearly missing the steps to enable this.
Thanks,
-- Thomas Adam
^ permalink raw reply
* Re: [PATCH] builtin-verify-tag: fix -v option parsing
From: Johannes Schindelin @ 2008-07-28 12:10 UTC (permalink / raw)
To: Olivier Marin; +Cc: Junio C Hamano, Michele Ballabio, git
In-Reply-To: <488DB0BD.2060406@free.fr>
[-- Attachment #1: Type: TEXT/PLAIN, Size: 637 bytes --]
Hi,
On Mon, 28 Jul 2008, Olivier Marin wrote:
> Johannes Schindelin a écrit :
> >>
> >> Since the C rewrite, "git verify-tag -v" just does nothing instead of
> >> printing the usage message with an error. This patch fix the
> >> regression.
> >
> > Maybe a better solution would be to convert (trivially) to
> > parse-options...
>
> I am very puzzled.
>
> You first asked me to do a separate commit with just the fix and now you
> seem to want the fix with the conversion...
Sorry. It was not obvious to myself when I asked for a separate patch
that the fix would fall out of the conversion to parse-options.
My fault,
Dscho
^ permalink raw reply
* Re: GTP/0.1 terminology 101: commit reels and references
From: Johannes Schindelin @ 2008-07-28 12:01 UTC (permalink / raw)
To: Sam Vilain; +Cc: Junio C Hamano, Joshua Roys, gittorrent, git, Jonas Fonseca
In-Reply-To: <1217239419.6750.73.camel@maia.lan>
Hi,
On Mon, 28 Jul 2008, Sam Vilain wrote:
> On Mon, 2008-07-28 at 00:24 -0700, Junio C Hamano wrote:
>
> >
> > >
> > >> Commit reels can also, and generally do, include the objects
> > >> required for a specific commit.
> > >
> > > Yes. The only times where they wouldn't contain all the objects
> > > required for the commits within the reel, is when those objects
> > > happened to be contained by a previous reel.
> >
> > What do you mean by "previous" reel? It is not quite defined in your
> > message but perhaps defined elsewhere?
> >
> > How is this different from a bundle? Does a reel, unlike a bundle,
> > contain the full tree for the bottom commits?
AFAICT no, the reel should not contain the full tree for the bottom
commit.
> They are almost identical, both being defined by a set of starting and
> ending refs. And now that you mention it, I feel slightly embarrassed
> for not spotting the connection before. I only really compared reels to
> packs, which is what the original specification tried to chop up bitwise
> and distribute chunk by chunk.
>
> The differences are:
>
> - the reel has a defined object order (which as I hoped to demonstrate
> in the test cases, is just a refinement of rev-list --date-order)
Do you mean that the commit reel is a list pointing to bundles that can be
sorted topologically by their contained commits?
> - deltas always point in one direction, to objects "earlier" on
> the reel, so that slices of the reel sent on the network can be made
> thin without resulting in unresolvable deltas (which should be
> possible to do on commit boundaries using rev-list --objects-edge)
That is exactly what bundles do. They are thin, as they assume that a few
"preconditions", i.e. refs, are present.
> - the behaviour at the beginning of the reel is precisely defined
> (although as I said, I think that the decision might be worth
> revisiting - perhaps getting just the latest reel is a useful
> 'shallow clone')
If you want to allow shallow clones, you must make the bundles non-thin.
That would be a major bandwidth penalty.
I'd rather not allow shallow clones with Gitorrent.
> > > This is one of the design decisions which I think may be a mistake;
> > > a less expensive to calculate definition of a reel would be *all*
> > > objects between the starting and ending Reference objects.
> >
> > Do you mean all such objects and nothing else? That would imply that
> > a reel is quite similar to a bundle (but neither rev-list
> > --objects-edge nor bundle guarantees that the result is minimal).
>
> It's the lack of guarantees which is the issue, really.
It should not be too difficult to provide a rev-list option (which is
inherited by git-bundle, then) to pay an extra time to make sure that the
bundle is minimal.
BTW this is a good example how communication on the Git mailing list can
help a GSoC project.
> In order to take the download work of the entire pack and distribute it
> over multiple peers, you need a way to carve the bundle up. This has to
> happen in such a way that the fragments that you get back will actually
> fit together at the end, and also in such a way that you don't lose the
> benefits of delta compression.
That should be relatively easy.
> The way I thought would be best to do that would be to line up all the
> objects in an exactly defined way - hence, the "reel" concept - and then
> chop that up.
What exactly is that exact definition?
Is it the output of "rev-list --all --objects", chopped into equal chunks
at commit boundaries? If so, it should probably be equal in terms of
size, right?
The tricky thing, of course, is to make that thing incremental, i.e.
replace only a minimal amount of items in the "commit reel" (if I
understood correctly, and the commit reel refers to a list of sets of
commits with their objects) when a branch was modified.
Hmm. Maybe it would be time for you to draw a tiny diagram for all the
people too lazy like me, which shows roughly how the communication between
the peers should look like, and how the reel fits in.
Ciao,
Dscho
^ permalink raw reply
* Re: New mailmap file for the kernel
From: Sverre Rabbelier @ 2008-07-28 11:53 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Jon Smirl, Git Mailing List
In-Reply-To: <alpine.DEB.1.00.0807281321540.2725@eeepc-johanness>
On Mon, Jul 28, 2008 at 13:23, Johannes Schindelin
<Johannes.Schindelin@gmx.de> wrote:
> And how exactly do you plan to make sure everybody has that hook
> installed?
It needn't be installed with everybody, only at the people that form
'upstream' (in the git case that'd be Junio, in the Linux case that'd
be Linus and his lieutenants).
> Also, it would be a major hassle, just for the benefits of statistics
> (which, funnily enough, not everybody cares about).
Hmmm, I'm not sure if it would be a major hassle once it's set up?
Once everybody has their name correctly in the mailmap nobody will
have to care?
> But we are not truly distributed. Our community is small enough, and our
> maintainer good enough, that we do have a single upstream essentially. We
> do not even have lieutenants through which new developers could come (and
> therefore would be old developers once they hit master).
Ah, I did not realize that. Thanks for explaining.
--
Cheers,
Sverre Rabbelier
^ permalink raw reply
* [PATCH] Updated the Documentation/config.txt core.autocrlf configuration setting documentation
From: Jurko Gospodnetić @ 2008-07-28 11:48 UTC (permalink / raw)
To: git
[-- Attachment #1: Type: text/plain, Size: 856 bytes --]
Hi all.
This is just a fix for something in the documentation that confused
me when playing around with git.
--- Comment: --------
Updated the Documentation/config.txt core.autocrlf configuration
setting documentation to note that this setting can be set at a
repository or file level by using the gitattributes configuration.
Signed-off-by: Jurko <jurko.gospodnetic@docte.hr>
---------------------
Diff is attached as a separate file.
Still have not figured out how to best send in patches (working on
Windows here) so this one is a manually sent mail and you will most
likely not be able to apply it automatically. :-(
I am also not sure whether there are perhaps any other documentation
copies that need to be updated for this. This was the only one I found
in the source tree.
Best regards,
Jurko Gospodnetić
[-- Attachment #2: config.txt.patch --]
[-- Type: text/plain, Size: 875 bytes --]
diff --git a/Documentation/config.txt b/Documentation/config.txt
index 1a13abc..d9c1401 100644
--- a/Documentation/config.txt
+++ b/Documentation/config.txt
@@ -135,9 +135,10 @@ core.autocrlf::
writing to the filesystem. The variable can be set to
'input', in which case the conversion happens only while
reading from the filesystem but files are written out with
- `LF` at the end of lines. Currently, which paths to consider
- "text" (i.e. be subjected to the autocrlf mechanism) is
- decided purely based on the contents.
+ `LF` at the end of lines. Which paths to consider "text" (i.e. be subjected
+ to the autocrlf mechanism) will be decided based on the contents but this
+ can be overruled on a per-repository or per-file level by using
+ linkgit:gitattributes[5].
core.safecrlf::
If true, makes git check if converting `CRLF` as controlled by
^ permalink raw reply related
* Re: [PATCH] builtin-verify-tag: fix -v option parsing
From: Olivier Marin @ 2008-07-28 11:42 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Junio C Hamano, Michele Ballabio, git
In-Reply-To: <alpine.DEB.1.00.0807281306090.2725@eeepc-johanness>
Johannes Schindelin a écrit :
>>
>> Since the C rewrite, "git verify-tag -v" just does nothing instead of
>> printing the usage message with an error. This patch fix the regression.
>
> Maybe a better solution would be to convert (trivially) to
> parse-options...
I am very puzzled.
You first asked me to do a separate commit with just the fix and now
you seem to want the fix with the conversion...
What do you mean by "trivially"?
Olivier.
^ permalink raw reply
* Re: [RFC/PATCH v3] merge-base: teach "git merge-base" to accept more than 2 arguments
From: Johannes Schindelin @ 2008-07-28 11:33 UTC (permalink / raw)
To: Christian Couder; +Cc: git, Junio C Hamano, Miklos Vajna, Jakub Narebski
In-Reply-To: <20080728065023.743930d6.chriscool@tuxfamily.org>
Hi,
On Mon, 28 Jul 2008, Christian Couder wrote:
> + rev = xmalloc((argc - 1) * sizeof(*rev));
> +
> + do {
> + struct commit *r = get_commit_reference(argv[1]);
> + if (!r)
> + return 1;
> + rev[rev_nr++] = r;
> + argc--; argv++;
> + } while (argc > 1);
> +
> + return show_merge_base(rev, rev_nr, show_all);
rev = xmalloc((argc - 1) * sizeof(*rev));
for (rev_nr = 0; rev_nr + 1 < argc; rev_nr++) {
rev[rev_nr] = get_commit_reference(argv[rev_nr + 1]);
if (!rev[rev_nr])
return !!error("Does not refer to a commit: '%s'",
argv[rev_nr + 1]);
}
return show_merge_base(rev, rev_nr, show_all);
I do not know about you, but I think this is not only shorter (in spite of
adding a helpful error message), but also simpler to understand (not using
convoluted do { } while logic), and therefore superior.
Your performance argument is weak IMHO, as this is not a big performance
hit, and command line parameter parsing is definitely not performance
critical.
Ciao,
Dscho
^ permalink raw reply
* Re: Adding custom hooks to a bare repository.
From: Johannes Schindelin @ 2008-07-28 11:26 UTC (permalink / raw)
To: Thomas Adam; +Cc: git mailing list
In-Reply-To: <18071eea0807280404w3365748cjcd11f536bf5d27eb@mail.gmail.com>
Hi,
On Mon, 28 Jul 2008, Thomas Adam wrote:
> I'm trying to add in "post-merge" as a valid hook file to an already
> created --bare repository. In adding it to the correct place and
> setting the correct permissions on it (the repository is a shared one),
> it doesn't seem to be pulled down with the other hook files already
> present when doing a "git clone".
>
> Any ideas why?
Yes. Hooks, just as the config and reflogs, are supposed to be local
things. Rationale being: it is rude, and also insecure, to install
something that potentially calls other programs without the user saying
so.
All you can do is checking in a copy of the hook, and ask your users/check
in your build system that it is installed.
Hth,
Dscho
^ permalink raw reply
* Re: New mailmap file for the kernel
From: Johannes Schindelin @ 2008-07-28 11:23 UTC (permalink / raw)
To: sverre; +Cc: Jon Smirl, Git Mailing List
In-Reply-To: <bd6139dc0807280411k3a283c5dr4b874342aab167dc@mail.gmail.com>
Hi,
On Mon, 28 Jul 2008, Sverre Rabbelier wrote:
> On Mon, Jul 28, 2008 at 12:53, Johannes Schindelin
> <Johannes.Schindelin@gmx.de> wrote:
> > Unless somebody forgets, right?
>
> Unless there is a pre-commit hook that prevents you from committing
> when you are not in the mailmap.
And how exactly do you plan to make sure everybody has that hook
installed?
Also, it would be a major hassle, just for the benefits of statistics
(which, funnily enough, not everybody cares about).
> > Also note that in a distributed world, you cannot properly speak of a
> > "new developer".
>
> Yet we do it all the time on git.git ;).
But we are not truly distributed. Our community is small enough, and our
maintainer good enough, that we do have a single upstream essentially. We
do not even have lieutenants through which new developers could come (and
therefore would be old developers once they hit master).
Ciao,
Dscho
^ permalink raw reply
* Re: [Fundamental problem with relative system paths] [PATCH 2/2] run-command (Windows): Run dashless "git <cmd>"
From: Johannes Schindelin @ 2008-07-28 11:13 UTC (permalink / raw)
To: Steffen Prohaska; +Cc: Johannes Sixt, git, Junio C Hamano, Shawn O. Pearce
In-Reply-To: <1217224228-31303-2-git-send-email-prohaska@zib.de>
Hi,
On Mon, 28 Jul 2008, Steffen Prohaska wrote:
> This might solve a fundamental problem we have with the computation of
> system directories based on relative paths in combination with the new
> gitexecpath 'libexec/git-core'. The problem is that the program 'git' is
> hardlinked to directories with different depth. It is either used as
> 'bin/git' (1 directory) or as 'libexec/git-core/git-*' (2 directories).
> Thus, using the same relative path in system_path() yields different
> results when starting from the two locations. I recognized the problem
> because /etc/gitconfig is no longer be read.
I seem to recall that I already suggested stripping
"/libexec/git-core/<name>" if it is found, and fall back to
stripping one directory level (catching "/bin/<name>").
IMHO system_path() should really be that intelligent.
(Of course, the way it is set up now, the _caller_ of git_set_argv0_path()
has to do the intelligent thing...)
Ciao,
Dscho
^ permalink raw reply
* Re: New mailmap file for the kernel
From: Sverre Rabbelier @ 2008-07-28 11:11 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Jon Smirl, Git Mailing List
In-Reply-To: <alpine.DEB.1.00.0807281251000.2725@eeepc-johanness>
On Mon, Jul 28, 2008 at 12:53, Johannes Schindelin
<Johannes.Schindelin@gmx.de> wrote:
> Unless somebody forgets, right?
Unless there is a pre-commit hook that prevents you from committing
when you are not in the mailmap. That should give enough incentive to
first make a commit that puts you in the mailmap before you start
sending in patches.
> Also note that in a distributed world, you cannot properly speak of a "new
> developer".
Yet we do it all the time on git.git ;).
--
Cheers,
Sverre Rabbelier
^ permalink raw reply
* Re: [PATCH] builtin-verify-tag: fix -v option parsing
From: Johannes Schindelin @ 2008-07-28 11:06 UTC (permalink / raw)
To: Olivier Marin; +Cc: Junio C Hamano, Michele Ballabio, git
In-Reply-To: <488DA40C.8020400@free.fr>
Hi,
On Mon, 28 Jul 2008, Olivier Marin wrote:
> From: Olivier Marin <dkr@freesurf.fr>
>
> Since the C rewrite, "git verify-tag -v" just does nothing instead of
> printing the usage message with an error. This patch fix the regression.
Maybe a better solution would be to convert (trivially) to
parse-options...
Ciao,
Dscho
^ permalink raw reply
* Adding custom hooks to a bare repository.
From: Thomas Adam @ 2008-07-28 11:04 UTC (permalink / raw)
To: git mailing list
Hello all,
I'm trying to add in "post-merge" as a valid hook file to an already
created --bare repository. In adding it to the correct place and
setting the correct permissions on it (the repository is a shared
one), it doesn't seem to be pulled down with the other hook files
already present when doing a "git clone".
Any ideas why?
Indeed, I also, as a test, added this post-merge hook to a repository
and created a --bare repository from that - thinking that perhaps the
hook file had to present at the time of creating a new repository, but
even then it wasn't copied over to the bare repository.
What am I doing wrong?
Thanks in advance,
-- Thomas Adam
^ permalink raw reply
* Re: New mailmap file for the kernel
From: Johannes Schindelin @ 2008-07-28 10:53 UTC (permalink / raw)
To: Jon Smirl; +Cc: Git Mailing List
In-Reply-To: <9e4733910807272145y5b67112er4b90cc36141663c1@mail.gmail.com>
Hi,
On Mon, 28 Jul 2008, Jon Smirl wrote:
> I made a new mailmap file for the kernel. I'll put it out on LKML
> tomorrow.
>
> It takes a new philosophy, there is an entry for every email address
> in the kernel git tree even if the name associated with it is correct.
Note that this makes maintaining the list much more tedious. Of course,
if you step up to maintain it, that is not an issue for others.
> As a result of this clean up the number of unique contributors to the
> kernel fell from 4,284 to 3,821. A total of 463 errors or about 12% of
> all name/email pairs. We clearly need to do some validation.
FWIW I think it is the responsibility of every contributor to quickly
check if their credentials are correct, and provide a patch if they are
not.
> Now that the file has every valid name/email in it is should be possible
> to validate the name/email in all new commits. When a new developer
> comes along we'll know it since they won't be in the file.
Unless somebody forgets, right?
Also note that in a distributed world, you cannot properly speak of a "new
developer".
> Maybe Linus will send them a welcome message.
Kidding?
Ciao,
Dscho
^ permalink raw reply
* Re: git-scm.com
From: Johannes Schindelin @ 2008-07-28 10:50 UTC (permalink / raw)
To: Tom Werner; +Cc: git
In-Reply-To: <530345950807272011o7c92fdaaw3116cc257dcbab7a@mail.gmail.com>
Hi,
On Sun, 27 Jul 2008, Tom Werner wrote:
> I find it a bit confusing that some here seem to have a strong dislike
> for GitHub. It's true that we haven't been active on the developer list
> or in the #git channel on freenode, but we are constantly in #github and
> have answered a *great* many questions from developers that are new to
> git.
Speaking for myself, I will probably direct some users from #git to
#github, then.
The deeper reasoning: if you really do help by that channel, by all means
I want to provide you with the opportunity to do so.
> As mentioned earlier in the thread, the Ruby-Git binding that Scott and
> I wrote has been open source from the beginning. While we did not
> announce it here, we have publicized it in the Ruby circle (where,
> presumably, people would most likely find it useful) and in fact there
> are currently 28 forks and 138 watchers of the project.
I find that limiting to the Ruby circle particularly unconvincing. Sure,
they might care much more than me. Much more, to be sure.
But when _I_ -- being around the Git list for a long time -- do not _know_
about something like a pretty well-working Ruby-Git binding, instead only
knowing a pretty stale effort on repo.or.cz by "corecode", then I think
communication channels are suboptimal. Way supoptimal.
Because at times _I_ am asked if there is some Git interface for Ruby, and
it feels awkward that I am pretty familiar with Git's internals and
community, yet I do not know about such an _important_ piece of software
being available!
> Perhaps it is the commercial aspect of GitHub that offends.
In my opinion you can be as commercial as you want. Nevertheless, I would
like to see some direct benefit for me, too, for obvious reasons. That
does not need to be money; like Junio said, watching out for user
questions on the Git list would already be very useful, in two respects:
- the core developers have more time for hacking on Git itself (which
would be good both for the developers as well as for you),
- if your advices can be enhanced (such as my gripe that "git show" is not
even so much as mentioned, in spite of being _the_ porcelain to inspect
objects in Git's object database, not cat-file, whose only role in
tutorials can be to shoo new users away) it will be early, which again
is a win-win situation for both core developers as well as for you, and
- just as in the past, I fully expect the main thrust of the major changes
in Git to be driven by user experience (just think of Git 1.5.0), and by
driving users away (and indeed, by driving yourself away, a bunch of
power-users), you would make that much more unlikely to happen in the
future. So, having you closer to the Git mailing list and #git would
again be a win-win situation.
> Having had to implement a git-daemon replacement that fit our needs, I
> have some ideas on how to improve git-daemon and fetch-pack with
> regards to error messages and logging.
I might mention here that I think you are committing one of the biggest
sins in Open Source: you do not reap the full power of the community.
I am sure, if you would have mentioned your needs first, possibly followed
by an early version of a patch, git-daemon would already be enhanced to
your liking, and these enhancements would be available to everyone
(including me, for example). But maybe that being available to everyone
is not in the best interest of a commercial outfit?
> We like to design from first principles, see how good we can do, and
> then get feedback from the users.
Maybe this is so contrary to Open Source that many are uncomfortable with
it.
Also note that one of the major gripe with you making money off of Git
could be the following: we have over 500 contributors, and most of them --
first and foremost of all, the two major contributors, Junio and Shawn --
cannot make money from Git. Envy is wrong, but it is real.
Do not get me wrong, I do not want to defend that behavior, but I think it
is a reality that you will have to cope with.
Ciao,
Dscho
^ permalink raw reply
* [PATCH] builtin-verify-tag: fix -v option parsing
From: Olivier Marin @ 2008-07-28 10:48 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Johannes Schindelin, Michele Ballabio, git
In-Reply-To: <4889EF22.6020604@free.fr>
From: Olivier Marin <dkr@freesurf.fr>
Since the C rewrite, "git verify-tag -v" just does nothing instead of
printing the usage message with an error. This patch fix the regression.
Signed-off-by: Olivier Marin <dkr@freesurf.fr>
---
builtin-verify-tag.c | 9 +++++----
1 files changed, 5 insertions(+), 4 deletions(-)
diff --git a/builtin-verify-tag.c b/builtin-verify-tag.c
index 7d837f0..729a159 100644
--- a/builtin-verify-tag.c
+++ b/builtin-verify-tag.c
@@ -92,14 +92,15 @@ int cmd_verify_tag(int argc, const char **argv, const char *prefix)
git_config(git_default_config, NULL);
- if (argc == 1)
- usage(builtin_verify_tag_usage);
-
- if (!strcmp(argv[i], "-v") || !strcmp(argv[i], "--verbose")) {
+ if (argc > 1 &&
+ (!strcmp(argv[i], "-v") || !strcmp(argv[i], "--verbose"))) {
verbose = 1;
i++;
}
+ if (argc <= i)
+ usage(builtin_verify_tag_usage);
+
/* sometimes the program was terminated because this signal
* was received in the process of writing the gpg input: */
signal(SIGPIPE, SIG_IGN);
--
1.6.0.rc0.79.gb0320
^ permalink raw reply related
* Re: [PATCH 1/9] Makefile: Do not install a copy of 'git' in $(gitexecdir)
From: A Large Angry SCM @ 2008-07-28 10:43 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Johannes Sixt, git
In-Reply-To: <7v63qqv7ex.fsf@gitster.siamese.dyndns.org>
Junio C Hamano wrote:
> Junio C Hamano <gitster@pobox.com> writes:
>
>>> This new action needs to be in a conditional to keep it from removing
>>> the ONLY git executable when bindir and execdir are the same dir.
>> Heh, I love bug reports that come immediately after I tag the tip of
>> 'master' as -rc1.
>
> This should do, but to be very honest, I really hate the output from the
> foreach that precedes this section.
>
> Makefile | 5 ++++-
> 1 files changed, 4 insertions(+), 1 deletions(-)
>
> diff --git a/Makefile b/Makefile
> index 798a2f2..92df61c 100644
> --- a/Makefile
> +++ b/Makefile
> @@ -1362,7 +1362,10 @@ endif
> cp "$$bindir/git$X" "$$execdir/git$X"; \
> fi && \
> { $(foreach p,$(BUILT_INS), $(RM) "$$execdir/$p" && ln "$$execdir/git$X" "$$execdir/$p" ;) } && \
> - $(RM) "$$execdir/git$X" && \
> + if test "z$$bindir" != "z$$execdir"; \
> + then \
> + $(RM) "$$execdir/git$X"; \
> + fi && \
> ./check_bindir "z$$bindir" "z$$execdir" "$$bindir/git-add$X"
>
> install-doc:
>
I'll test this this evening.
^ 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