* 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
* Re: [PATCH 1/9] Makefile: Do not install a copy of 'git' in $(gitexecdir)
From: A Large Angry SCM @ 2008-07-28 10:41 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Johannes Sixt, git
In-Reply-To: <7vabg2v83o.fsf@gitster.siamese.dyndns.org>
Junio C Hamano wrote:
> A Large Angry SCM <gitzilla@gmail.com> writes:
>
>> Johannes Sixt wrote:
>> [...]
>>> diff --git a/Makefile b/Makefile
>>> index 551bde9..cbab4f9 100644
>>> --- a/Makefile
>>> +++ b/Makefile
>>> @@ -1335,6 +1335,7 @@ endif
>>> '$(DESTDIR_SQ)$(gitexecdir_SQ)/git$X'; \
>>> fi
>>> $(foreach p,$(BUILT_INS), $(RM) '$(DESTDIR_SQ)$(gitexecdir_SQ)/$p' && ln '$(DESTDIR_SQ)$(gitexecdir_SQ)/git$X' '$(DESTDIR_SQ)$(gitexecdir_SQ)/$p' ;)
>>> + $(RM) '$(DESTDIR_SQ)$(gitexecdir_SQ)/git$X'
>>> ifneq (,$X)
>>> $(foreach p,$(patsubst %$X,%,$(filter %$X,$(ALL_PROGRAMS) $(BUILT_INS) git$X)), $(RM) '$(DESTDIR_SQ)$(gitexecdir_SQ)/$p';)
>>> endif
>> 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.
>
Well, I'm currently about a week behind on all things git so this is as
timely as I could make it. ;-)
^ permalink raw reply
* Re: GTP/0.1 terminology 101: commit reels and references
From: Sam Vilain @ 2008-07-28 10:03 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Joshua Roys, gittorrent, git, Jonas Fonseca
In-Reply-To: <7vk5f6tqsj.fsf@gitster.siamese.dyndns.org>
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?
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)
- 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)
- 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')
> > 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. 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.
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.
If a pack is already arranged to line up with the commit reel's
structure, then it's possible that the amount of work required to answer
a "play" request is as little as looking up in the reel index the local
on-disk location within the local pack, and copying that to the network.
I've certainly wondered how much baggage could be removed from this
whole thing, like replacing the "tracker" with a simple git-daemon
message that holds a register of mirrors/peers, possibly layering things
over git:// instead of the bittorrent-like protocol, dividing up blocks
by the commit graph and not all objects, etc. But I think that it would
be best to defer that kind of design change until the conclusion of this
prototype experiment.
That being said, anything which does shortcut the distance to the finish
line and can be agreed on wouldn't go amiss.
Sam
^ permalink raw reply
* Re: [PATCH 3/6] builtin-help: make it possible to exclude some commands in list_commands()
From: Johannes Schindelin @ 2008-07-28 9:58 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Miklos Vajna, git
In-Reply-To: <7vljzmwvww.fsf@gitster.siamese.dyndns.org>
Hi,
On Sun, 27 Jul 2008, Junio C Hamano wrote:
> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
>
> >> > +struct cmdnames {
> >> > + int alloc;
> >> > + int cnt;
> >> > + struct cmdname {
> >> > + size_t len;
> >> > + char name[1];
> >> > + } **names;
> >> > +};
> >>
> >> I thought we do this kind of thing using FLEX_ARRAY macro. Is there any
> >> reason its use is not appropriate here?
> >
> > I think that came up in the previous review round: the "name" member _is_
> > NUL-terminated, but could have a ".exe" suffix. The "len" member has the
> > length excluding ".exe".
>
> Sorry, but I do understand what you are trying to explain.
>
> Marking the flexible member at the end as "last_member[FLEX_ARRAY]" is
> about a tiny bit of abstracting out how the exact decl syntax should look
> like depending on the compiler.
Ah, sorry, I misunderstood. I thought your complaint was about something
else.
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH] Documentation/git-ls-tree.txt: Add a caveat about prefixing pathspec
From: Junio C Hamano @ 2008-07-28 9:23 UTC (permalink / raw)
To: Petr Baudis; +Cc: git
In-Reply-To: <7vvdyqx0i0.fsf@gitster.siamese.dyndns.org>
Junio C Hamano <gitster@pobox.com> writes:
> Petr Baudis <pasky@suse.cz> writes:
>
>>> We may throw a dice or go with your version, I don't care *that* much
>>> about this change, I just wouldn't make it personally.
>>
>> What is the status of this patch? :-) Dropped altogether?
>
> Left behind on the far side of oblivion; I do not offhand recall what this
> was about, sorry.
Ok, I now recall this bit:
You are right, now that I understand the issue better, there's no good
fix for this except perhaps introducing --no-prefix, which is not my
itch to scratch. Here's my original wording improvement:
Note that if you are within a subdirectory of your working copy,
'git ls-tree' will automatically prepend the subdirectory prefix
to the specified paths, and assume the prefix specified in case
no paths were given - no matter what the tree object is! Thus,
within a subdirectory, 'git ls-tree' behaves as expected only
when run on a root tree object.
Eventually somebody may write a Porcelain that benefits from --no-prefix,
but it is safe to defer the implementation until the need becomes real.
I'll add some explanatory message to the documentation.
^ permalink raw reply
* Re* [PATCH] git-merge -s theirs
From: Junio C Hamano @ 2008-07-28 9:18 UTC (permalink / raw)
To: Nanako Shiraishi; +Cc: git, Miklos Vajna
In-Reply-To: <7vhcak45ez.fsf@gitster.siamese.dyndns.org>
Junio C Hamano <gitster@pobox.com> writes:
> Nanako Shiraishi <nanako3@lavabit.com> writes:
> ...
> That is certainly cute, but I do not like it for two reasons:
>
> - This advertizes "theirs" as available when you ask "git merge -s whoa",
> and then the user is told "don't use this stupid, go away". That is
> not exactly a good diplomacy to earn friends.
>
> - The message gives a rather long hexdecimal string in its suggestion to
> run "git reset --hard". This is not exactly your fault, though. The
> original refname the user gave to "git-merge" is not available to your
> strategy.
This does not address the first point at all, but attempts to solve the
second issue. Strategies now get the remote in the symbolic form
originally used on the command line.
All strategies know that they need to expect that the refs can be given
with arbitrary SHA-1 expressions, so this change should be safe.
builtin-merge.c | 20 +++++++++++++++-----
1 files changed, 15 insertions(+), 5 deletions(-)
diff --git a/builtin-merge.c b/builtin-merge.c
index e78fa18..1a9850f 100644
--- a/builtin-merge.c
+++ b/builtin-merge.c
@@ -22,6 +22,7 @@
#include "log-tree.h"
#include "color.h"
#include "rerere.h"
+#include "decorate.h"
#define DEFAULT_TWOHEAD (1<<0)
#define DEFAULT_OCTOPUS (1<<1)
@@ -504,7 +505,7 @@ static void write_tree_trivial(unsigned char *sha1)
}
static int try_merge_strategy(const char *strategy, struct commit_list *common,
- const char *head_arg)
+ const char *head_arg, struct decoration *symbolic)
{
const char **args;
int i = 0, ret;
@@ -520,8 +521,12 @@ static int try_merge_strategy(const char *strategy, struct commit_list *common,
args[i++] = xstrdup(sha1_to_hex(j->item->object.sha1));
args[i++] = "--";
args[i++] = head_arg;
- for (j = remoteheads; j; j = j->next)
- args[i++] = xstrdup(sha1_to_hex(j->item->object.sha1));
+ for (j = remoteheads; j; j = j->next) {
+ char *name = lookup_decoration(symbolic, &j->item->object);
+ if (!name)
+ name = sha1_to_hex(j->item->object.sha1);
+ args[i++] = xstrdup(name);
+ }
args[i] = NULL;
ret = run_command_v_opt(args, RUN_GIT_CMD);
strbuf_release(&buf);
@@ -773,6 +778,7 @@ int cmd_merge(int argc, const char **argv, const char *prefix)
struct commit_list *common = NULL;
const char *best_strategy = NULL, *wt_strategy = NULL;
struct commit_list **remotes = &remoteheads;
+ struct decoration symbolic_remote_head;
setup_work_tree();
if (unmerged_cache())
@@ -870,6 +876,7 @@ int cmd_merge(int argc, const char **argv, const char *prefix)
strbuf_addf(&buf, " %s", argv[i]);
setenv("GIT_REFLOG_ACTION", buf.buf, 0);
strbuf_reset(&buf);
+ memset(&symbolic_remote_head, 0, sizeof(symbolic_remote_head));
for (i = 0; i < argc; i++) {
struct object *o;
@@ -877,6 +884,7 @@ int cmd_merge(int argc, const char **argv, const char *prefix)
o = peel_to_type(argv[i], 0, NULL, OBJ_COMMIT);
if (!o)
die("%s - not something we can merge", argv[i]);
+ add_decoration(&symbolic_remote_head, o, xstrdup(argv[i]));
remotes = &commit_list_insert(lookup_commit(o->sha1),
remotes)->next;
@@ -1041,7 +1049,8 @@ int cmd_merge(int argc, const char **argv, const char *prefix)
wt_strategy = use_strategies[i]->name;
ret = try_merge_strategy(use_strategies[i]->name,
- common, head_arg);
+ common, head_arg,
+ &symbolic_remote_head);
if (!option_commit && !ret) {
merge_was_ok = 1;
/*
@@ -1105,7 +1114,8 @@ int cmd_merge(int argc, const char **argv, const char *prefix)
restore_state();
printf("Using the %s to prepare resolving by hand.\n",
best_strategy);
- try_merge_strategy(best_strategy, common, head_arg);
+ try_merge_strategy(best_strategy, common, head_arg,
+ &symbolic_remote_head);
}
if (squash)
^ permalink raw reply related
* Re: [Fundamental problem with relative system paths] [PATCH 2/2] run-command (Windows): Run dashless "git <cmd>"
From: Junio C Hamano @ 2008-07-28 7:38 UTC (permalink / raw)
To: Steffen Prohaska; +Cc: Johannes Sixt, git, Johannes Schindelin, Shawn O. Pearce
In-Reply-To: <7vvdyqv9bf.fsf@gitster.siamese.dyndns.org>
Junio C Hamano <gitster@pobox.com> writes:
> Steffen Prohaska <prohaska@zib.de> writes:
>
>> ... It is either used as
>> 'bin/git' (1 directory) or as 'libexec/git-core/git-*'
>> (2 directories).
>
> I thought Hannes already fixed that one; we shouldn't have the latter.
Oops, I misread your message. You are worried about the builtins. Sorry.
^ permalink raw reply
* Re: Git's config core.pager doesn't respect color.pager
From: Jeff King @ 2008-07-28 7:25 UTC (permalink / raw)
To: Benjamin Kudria; +Cc: Junio C Hamano, git
In-Reply-To: <d129c0140807221910j37f40e72se9f411d6424077de@mail.gmail.com>
On Tue, Jul 22, 2008 at 10:10:17PM -0400, Benjamin Kudria wrote:
> [core]
> pager = tig
>
> [color]
> diff = auto
> pager = false
[...]
> So, with the above config, when I do:
>
> git diff | tig
>
> Everything works correctly - git sends no color codes, because of
> color.pager = false.
Actually, it works because of color.diff = auto. Stdout is not a tty,
therefore color does not kick in. The point of color.pager is to say
"since git started a pager on behalf of the user, the tty test is
pointless. What we really want to know is whether the pager can handle
colors."
> However, if I do just:
>
> git diff
>
> git uses core.pager to display the output, but still sends color
> codes, which is OK for, say, less, bit not so good for tig, which does
> it's own colorizing, and displays the color codes git sends as-is.
And this is a bug, but one that only affects "diff". It's an ordering
problem in looking at the config and starting the pager (diff is unlike
most other commands in that we cannot decide immediately if we want the
pager, in the case that --exit-code is used). So we make the color
decision before we have started the pager.
Unfortunately, it is not quite as simple as just flipping the order.
Starting the pager depends on knowing that we are using --exit-code,
which depends on doing the diff options parsing and setup, which depends
on reading the config, which then depends on the pager setup.
The patch below should fix it, but it really leaves a bad taste in my
mouth. However, breaking the dependency chain would require some pretty
major surgery, I think. It is a little worrisome to me that
git_config_colorbool depends on the value of pager_use_color, another
config variable, at all; that means that ordering in the config file
could change the outcome. It happens to work because we read the config
several times, and we pick up pager.color on a previous read. I think
the "right" solution would be refactoring the color stuff to make the
decision closer to the point of use. But that is definitely not -rc
material, so perhaps this should go in, ugly as it is.
---
builtin-diff.c | 15 +++++++++++++++
1 files changed, 15 insertions(+), 0 deletions(-)
diff --git a/builtin-diff.c b/builtin-diff.c
index 7ffea97..564984e 100644
--- a/builtin-diff.c
+++ b/builtin-diff.c
@@ -301,6 +301,21 @@ int cmd_diff(int argc, const char **argv, const char *prefix)
setup_pager();
/*
+ * Special case: we have already examined the config for
+ * color, but we didn't know at that point whether we were
+ * going to start a pager. The only case that we care about is
+ * when we turned on color, but shouldn't have (we will never
+ * "should have but didn't" because of the pager, since
+ * a lack of a pager implies either the tty is stdout, in
+ * which case we do turn on color, or it is not, in which
+ * case we don't start a pager).
+ */
+ if (DIFF_OPT_TST(&rev.diffopt, COLOR_DIFF) &&
+ pager_in_use() &&
+ !pager_use_color)
+ DIFF_OPT_CLR(&rev.diffopt, COLOR_DIFF);
+
+ /*
* Do we have --cached and not have a pending object, then
* default to HEAD by hand. Eek.
*/
--
1.6.0.rc1.155.gd3310.dirty
^ permalink raw reply related
* Re: GTP/0.1 terminology 101: commit reels and references
From: Junio C Hamano @ 2008-07-28 7:24 UTC (permalink / raw)
To: Sam Vilain; +Cc: Joshua Roys, gittorrent, git, Jonas Fonseca
In-Reply-To: <1217228570.6750.24.camel@maia.lan>
Sam Vilain <sam@vilain.net> writes:
>> 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?
> 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).
^ permalink raw reply
* [PATCH] Allow installing in the traditional way
From: Junio C Hamano @ 2008-07-28 7:09 UTC (permalink / raw)
To: Johannes Sixt; +Cc: git
In an earlier commit c70a8d9 (Makefile: Do not install a copy of 'git' in
$(gitexecdir), 2008-07-21), we tried to avoid installing two git, one in
/usr/bin/git and the other in /usr/libexec/git-core/git. It mistakenly
removed the only copy of git when gitexecdir and bindir are set to the
same directory, i.e. the traditional layout.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
---
Makefile | 5 ++++-
1 files changed, 4 insertions(+), 1 deletions(-)
diff --git a/Makefile b/Makefile
index 7e30b30..52c67c1 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:
--
1.6.0.rc1
^ 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