* Re: [PATCH] Documentation: add a planning document for the next CLI revamp
From: Jeff King @ 2008-11-02 3:42 UTC (permalink / raw)
To: Johannes Schindelin
Cc: Sam Vilain, git, Scott Chacon, Tom Preston-Werner, J.H.,
Christian Couder, Kai Blin
In-Reply-To: <alpine.DEB.1.00.0810311745030.22125@pacific.mpi-cbg.de.mpi-cbg.de>
On Fri, Oct 31, 2008 at 05:46:35PM +0100, Johannes Schindelin wrote:
> > > + * 'git branch --switch' : alternative to checkout
> >
> > Blech. I think switching branches is the one thing that checkout does
> > unconfusedly. And this is much more typing. Not to mention that So I
> > would rather see "git switch" if checkout is somehow unpalatable.
>
> You know, I asked for this because a _user_ told me "Guess how long it
> took me to find out how to check out a branch!".
>
> I think if you are not confused by CVS/SVN, the name "checkout" is utterly
> unintuitive.
OK. I am not opposed to such a change as long as:
- this is not just _a_ user, but a _common_ user confusion. IOW, I
don't recall this complaint coming up a lot (or at least not nearly
as often as other ones do). But maybe you have more data.
- it is done consistently.
My initial "blech" was a little premature, as I was thinking "instead
of checkout", though it does clearly say "alternative" there.
However, (and somebody else in the thread very cleverly came up with
this analysis, not me), this is basically going from "verb the noun"
to "noun --verb". And that's reasonable, if users think in terms of
nouns. But we should be consistent in applying that transformation,
and make it available for other nouns that match that verb. In other
words, "git tag --switch". And however one might manipulate remote
tracking branches ("git branch -r --switch", I guess).
Personally I find it somewhat backwards, but I think CVS rotted my
brain long ago.
-Peff
^ permalink raw reply
* [PATCH] t7700: demonstrate mishandling of objects in packs with a .keep file
From: drafnel @ 2008-11-02 3:35 UTC (permalink / raw)
To: git; +Cc: gitster, nico, Brandon Casey
In-Reply-To: <1S3xpaVP1Cy1Rei_ODwlXsBdu64BGiPve-lj_4fN6cA@cipher.nrlssc.navy.mil>
From: Brandon Casey <drafnel@gmail.com>
Objects residing in pack files that have an associated .keep file are not
supposed to be repacked into new pack files, but they are.
Signed-off-by: Brandon Casey <drafnel@gmail.com>
---
t/t7700-repack.sh | 38 ++++++++++++++++++++++++++++++++++++++
1 files changed, 38 insertions(+), 0 deletions(-)
create mode 100755 t/t7700-repack.sh
diff --git a/t/t7700-repack.sh b/t/t7700-repack.sh
new file mode 100755
index 0000000..1489e68
--- /dev/null
+++ b/t/t7700-repack.sh
@@ -0,0 +1,38 @@
+#!/bin/sh
+
+test_description='git repack works correctly'
+
+. ./test-lib.sh
+
+test_expect_failure 'objects in packs marked .keep are not repacked' '
+ echo content1 > file1 &&
+ echo content2 > file2 &&
+ git add . &&
+ git commit -m initial_commit &&
+ # Create two packs
+ # The first pack will contain all of the objects except one
+ git rev-list --objects --all | head -n -1 |
+ git pack-objects pack > /dev/null &&
+ # The second pack will contain the excluded object
+ packsha1=$(git rev-list --objects --all | tail -n 1 |
+ git pack-objects pack) &&
+ touch -r pack-$packsha1.pack pack-$packsha1.keep &&
+ objsha1=$(git verify-pack -v pack-$packsha1.idx | head -n 1 |
+ sed -e "s/^\([0-9a-f]\{40\}\).*/\1/") &&
+ mv pack-* .git/objects/pack/ &&
+ git repack -A -d -l &&
+ git prune-packed &&
+ for p in .git/objects/pack/*.idx; do
+ idx=$(basename $p)
+ test "pack-$packsha1.idx" = "$idx" && continue
+ if git verify-pack -v $p | egrep "^$objsha1"; then
+ found_duplicate_object=1
+ echo "DUPLICATE OBJECT FOUND"
+ break
+ fi
+ done &&
+ test -z "$found_duplicate_object"
+'
+
+test_done
+
--
1.6.0.2.588.g3102
^ permalink raw reply related
* Re: [PATCH] Documentation: add a planning document for the next CLI revamp
From: Jeff King @ 2008-11-02 3:53 UTC (permalink / raw)
To: Tom Preston-Werner; +Cc: git
In-Reply-To: <20081031003154.GA5745@sigill.intra.peff.net>
On Thu, Oct 30, 2008 at 08:31:54PM -0400, Jeff King wrote:
> So think of us as having three "spots": the HEAD (H), the "stage"[1] (S),
> and the working tree (W). And we want commands for moving content
Re-reading this, I realized I forgot to fill in my footnote. But it was
going to be:
[1] Actually, the term "the stage" is growing on me.
-Peff
^ permalink raw reply
* Re: [RFC/PATCH 1/2] bisect: add "git bisect replace" subcommand
From: Johannes Schindelin @ 2008-11-02 4:16 UTC (permalink / raw)
To: Christian Couder; +Cc: Junio C Hamano, git
In-Reply-To: <20081102021910.fef1532e.chriscool@tuxfamily.org>
Hi,
On Sun, 2 Nov 2008, Christian Couder wrote:
> This new subcommand should be used when you have a branch or a part of a
> branch that isn't easily bisectable because at some point, say A, a bug
> as been introduced. The bug has been fixed latter at another point, say
> B, but between these points the code is not easily testable because of
> the bug, so it's not easy to bisect between these points.
Would it not be more intuitive to have support for
git bisect skip A..B
?
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH] Documentation: add a planning document for the next CLI revamp
From: Jeff King @ 2008-11-02 4:18 UTC (permalink / raw)
To: Sam Vilain
Cc: Sam Vilain, git, Johannes Schindelin, Scott Chacon,
Tom Preston-Werner, J.H., Christian Couder, Kai Blin
In-Reply-To: <1225435238.20883.18.camel@maia.lan>
On Thu, Oct 30, 2008 at 11:40:38PM -0700, Sam Vilain wrote:
> > I notice the commit template message getting longer and longer. Maybe it
> > is time for status.verbosetemplate (which could default to true, I just
> > want to be able to turn it off).
> Right. We'll have to work through that when we look at how 'git status'
> output is displayed. There may be some people who parse the existing
> output, but they should get to read the release notes about the proper
> ways to do that. I think the whole output could do with a shake-up.
Maybe I am wrong, but I thought at some point we decided that parsing
the output of "git status" was insane and wrong, since it's porcelain.
OTOH, it is also an easy way for editors to see what is happening in a
commit whose message you are editing (and to do, for example, syntax
highlighting on it). So it may be that it is getting parsed anyway.
> [moving content from HEAD or index to working tree]
> I still think it's OK to use 'git revert-files' for this; it just seems
> so long. Switches could specify where to and from.
Yeah, revert-files is pretty painful to type. And I'm not looking
forward to fielding UI questions about "why isn't it just revert?" :)
Somebody suggested "clobber", which I think is a bit _too_ intense.
I guess something like "retrieve" is too ambiguous. You really need
something that implies movement of content, and something that implies
the working directory. "Checkout" is actually not a bad name; if only we
had "git switch" instead of "git checkout" for switching branches, it
would be perfect.
So I am a bit stumped. Maybe "clobber" is not so bad. ;)
> Again interesting, you could look at the stash as a whole bunch of
> staged commits yet to happen. Of course, adding a file when the version
> in HEAD doesn't match the version in the base of the stash is a bit
> insane, so should probably be an error.
>
> I'll have a ponder over this and whether there is a simple word for this
> all.
Whether or not we come up with a simple word, I think it makes sense to
expose this through "git stash -i" (since, after all, we are just
putting stuff into an index there).
> You're right with all that. I don't think that it is necessarily wrong
> to have two ways to get at functionality, depending on whether you start
> with the noun or the verb first; so long as it doesn't introduce
> confusion. And if anything, I think --switch is wrong; --checkout is
> probably more consistent.
Agreed on --checkout. I think your "noun or verb" comment hits the nail
right on the head. I wonder if there are other places where
functionality can be exposed in either direction (I think we already
have some in "git fetch <remote>" versus "git remote update").
> > There was a thread between me and Junio some months ago that touched on
> > this. I don't remember all of the arguments, but it was resolved to keep
> > the current behavior. Any proposal along these lines should at least
> > revisit and respond to those arguments.
>
> Right. So, before round 2, I'll read and attempt to summarise that
> thread - assuming I can find it! :)
I think it was "Minor annoyance with git push" from this past February.
Quite a long thread, but there is some in this subthread:
http://thread.gmane.org/gmane.comp.version-control.git/73038/focus=73208
> Another command people often want is 'git info' to tell them stuff like
> they might get from 'git status' or 'git remote' but without all the
> file details...
Yeah, I don't know if you have followed the other threads in the past
month or so, but I think there is some desire for a "new" status with
a nicer format.
And I think it might be nice to structure it as a long list of things it
_can_ report on, and then let you tweak those with command-line options
and config settings. E.g., I might set info.currentbranch, info.staged,
and info.untracked because that is what _I_ like to see to get a sense
of what is happening in the repo.
And I will get around to designing that after I clear the other 100
things off my todo list. ;)
> > > + * 'git tag -l' should show more information
> > I remember somebody talking about this, but not the details. Which
> > information?
> Oh, good point. Basically the same stuff that 'git branch -v' shows; in
> any case, its behaviour should be relatively consistent compared to 'git
> branch'.
OK, that makes sense to me. I think of "git tag -l" as plumbing-ish,
though, so we might be breaking people's scripts (yes, I know the "real"
plumbing for this is for-each-ref, but it really is a pain to parse the
tags out of that versus "for i in `git tag -l`").
-Peff
^ permalink raw reply
* Re: Using the --track option when creating a branch
From: Jeff King @ 2008-11-02 4:23 UTC (permalink / raw)
To: Samuel Tardieu; +Cc: Andreas Ericsson, Bill Lear, git
In-Reply-To: <2008-10-30-14-52-52+trackit+sam@rfc1149.net>
On Thu, Oct 30, 2008 at 02:52:52PM +0100, Samuel Tardieu wrote:
> The current behaviour made me remove the branches I was not actively
> on locally, because I would get errors from "git push" all the time
> saying that I was not up-to-date in those branches.
Not triggering an error on these branches has been discussed a few times
before, but I'm not sure we ever reached a conclusion of what the ideal
behavior would be.
Try this thread:
http://thread.gmane.org/gmane.comp.version-control.git/85469
which points to a few others. Comments welcome.
-Peff
^ permalink raw reply
* Re: [PATCH 1/3] git send-email: avoid leaking directory file descriptors.
From: Jeff King @ 2008-11-02 4:31 UTC (permalink / raw)
To: Pierre Habouzit; +Cc: git
In-Reply-To: <1225450632-7230-2-git-send-email-madcoder@debian.org>
On Fri, Oct 31, 2008 at 11:57:10AM +0100, Pierre Habouzit wrote:
> + closedir(DH);
Ugh. This is a great reason to use a scoped variable (like "my $dh),
which will close automatically. Once upon a time I think you _had_ to
use globs for this, but I think it has not been the case for some time
(and I think we only support back to perl 5.6 these days). Can any perl
gurus comment?
-Peff
^ permalink raw reply
* Re: [PATCH] git send-email: allow any rev-list option as an argument.
From: Jeff King @ 2008-11-02 4:35 UTC (permalink / raw)
To: Pierre Habouzit; +Cc: git
In-Reply-To: <1225471925-2750-1-git-send-email-madcoder@debian.org>
On Fri, Oct 31, 2008 at 05:52:05PM +0100, Pierre Habouzit wrote:
> Signed-off-by: Pierre Habouzit <madcoder@debian.org>
> ---
>
> One can consider to squash that on top of
> <1225450632-7230-3-git-send-email-madcoder@debian.org> to be able to pass
> all non path arguments before a possible '--' to git format-patch.
Personally, I think the other patch is not useful without this. I often
pull out funny subsets of patches if I know it is safe to do so (e.g., I
collect small, unrelated bugfixes directly onto a single branch, but I
send them separately).
With this patch, I might even find send-email usable. :)
-Peff
^ permalink raw reply
* Re: git reset --hard w/o touching every file
From: Edward Z. Yang @ 2008-11-02 4:36 UTC (permalink / raw)
To: git
In-Reply-To: <20081102033313.GB4936@coredump.intra.peff.net>
Jeff King wrote:
> Sorry, I don't quite understand. You want to check out some subset of
> files, but you don't know which subset?
Yeah, I should elaborate a little.
I'm using a script to automatically update a website with the contents
of a Git repository at a specified interval. While I could use git pull,
I've been told that it's safer to do a git fetch, and then a git reset
--hard remotes/master, because the former could trigger a merge and on a
live website that is NOT desirable.
Unfortunately, since Git touches all files on a reset --hard, it's
causing problems with the smart cache system, which checks whether or
not the cache file is older than the source file, and regenerating if it is.
Cheers,
Edward
^ permalink raw reply
* Re: [PATCH] Documentation: add a planning document for the next CLI revamp
From: Elijah Newren @ 2008-11-02 4:41 UTC (permalink / raw)
To: Theodore Tso; +Cc: Sam Vilain, git, Sam Vilain
In-Reply-To: <20081102010634.GF8134@mit.edu>
On Sat, Nov 1, 2008 at 7:06 PM, Theodore Tso <tytso@mit.edu> wrote:
> In my opinion, that is a Really Bad Idea from a usability and UI
> design point of view. Each command should do one and only one thing,
> and not do different things depending on what options you give it.
> Git violates this rules in a number of places already, What you call
> "revert-since" and "revert-in" are so different that using the same
> subcommand is just going to horribly confuse users.
>
> Better to have "git revert" print a message explining that it is
> deprecated, and to tell users that they probably want either "git
> cherry-pick --revert" or "git revert-file", depending on whether they
> are an experienced git user (in which case they probably want git
> cherry-pick --revert"), or if that person who is familiar svn or hg's
> "svn revert" or "hg revert", they probably want "git revert-file".
Yeah, good points. I guess I could just make --no-commit the default
in all cases to remove the "magic", but then it's too much typing for
the revert-in case ("eg revert --commit --in REVISION" vs. "git revert
REVISION"). Two separate commands may make more sense, but then
there's the naming issue (I had difficulty coming up with a different
name that I liked, and it appears others are having a little trouble
with the naming too). Tough nut to crack from any angle. :-(
^ permalink raw reply
* Re: [PATCH] prepare deprecation of git-revert
From: Jeff King @ 2008-11-02 4:41 UTC (permalink / raw)
To: Pierre Habouzit; +Cc: git
In-Reply-To: <1225468527-29694-1-git-send-email-madcoder@debian.org>
On Fri, Oct 31, 2008 at 04:55:27PM +0100, Pierre Habouzit wrote:
> I've not kept the auto-edit feature of git-revert for the git-cherry-pick -R
> case as I don't believe it makes a lot of sense. But if people are unhappy
> with that, I can easily "fix" it.
I disagree. I write a new commit message for every revert I do.
When you cherry-pick, you are pulling a good commit from somewhere else.
So its commit message should suffice to explain why you are making the
change (and infrequently, you might want to give more context or say
"and here is where this comes from").
But when you revert, you are saying "this other commit was bad, so let's
reverse it." So you can look at the other commit to see what it did, but
you still don't know _why_ it was bad. A revert should always give
information about what you know _now_ that you didn't know when you
made the commit originally.
-Peff
^ permalink raw reply
* Re: libgit2 - a true git library
From: David Brown @ 2008-11-02 5:09 UTC (permalink / raw)
To: Scott Chacon; +Cc: Shawn O. Pearce, Nicolas Pitre, Pierre Habouzit, david, git
In-Reply-To: <d411cc4a0811011807g229f8becs9f411d6e19fb6c12@mail.gmail.com>
On Sat, Nov 01, 2008 at 06:07:04PM -0700, Scott Chacon wrote:
>Think about trying to incorporate this into something proprietary,
>Shawn - how much of a pain is it going to be to get that license
>reviewed in Google? However, LGPL I'm sure there is already a
>reviewed policy. Now, since that may be a pain, time that Shawn could
>have been spending being paid to work on the library is lost because
>they can't use it, or it takes weeks/months to review it. That's my
>concern.
The gcc exception license should have been reviewed by anyone who has
ever build anything proprietary out of gcc.
GPL+link exception is a very common license. It's most common use is
for runtime libraries for various programming languages.
Lawyers I know are significantly less fearful of the GPL+exception
than the LGPL. The exception basically says that if you use it in a
certain way, then none of the GPL applies.
David
^ permalink raw reply
* Re: git reset --hard w/o touching every file
From: Jeff King @ 2008-11-02 5:52 UTC (permalink / raw)
To: Edward Z. Yang; +Cc: git
In-Reply-To: <gejanr$os$1@ger.gmane.org>
On Sun, Nov 02, 2008 at 12:36:09AM -0400, Edward Z. Yang wrote:
> I'm using a script to automatically update a website with the contents
> of a Git repository at a specified interval. While I could use git pull,
> I've been told that it's safer to do a git fetch, and then a git reset
> --hard remotes/master, because the former could trigger a merge and on a
> live website that is NOT desirable.
Well, there will never be a merge if you aren't making local changes
(and your upstream is not doing silly things like rewinding the history of
what it gives you). But if you aren't making local changes, then doing a
reset is "safe" in the sense that you will have nothing to throw away.
> Unfortunately, since Git touches all files on a reset --hard, it's
> causing problems with the smart cache system, which checks whether or
> not the cache file is older than the source file, and regenerating if
> it is.
Ah, OK. I see what you want.
Git usually tries very hard not to touch files that don't need to be
touched. So that sounds like a bug. However, I can't reproduce it with
this test case:
mkdir repo && cd repo && git init &&
touch a b && git add a b && git commit -m added &&
echo changes >a && git commit -a -m 'changed a' &&
touch -d 1979-10-12 a b && echo before reset && ls -l a b &&
git update-index --refresh &&
git reset --hard HEAD^ && echo after reset && ls -l a b
I end up with:
before reset
-rw-r--r-- 1 peff peff 8 1979-10-12 00:00 a
-rw-r--r-- 1 peff peff 0 1979-10-12 00:00 b
HEAD is now at d7fd84e added
after reset
-rw-r--r-- 1 peff peff 0 2008-11-02 01:46 a
-rw-r--r-- 1 peff peff 0 1979-10-12 00:00 b
which makes sense. The only tricky thing is the "update-index --refresh"
call, which basically tells git "update your cache with the new mtime
value", which is necessary because of the contrived use of "touch". But
if you are manipulating these files only through "git reset", it should
Just Work.
-Peff
^ permalink raw reply
* Re: [PATCH] Documentation: add a planning document for the next CLI revamp
From: Junio C Hamano @ 2008-11-02 6:08 UTC (permalink / raw)
To: Theodore Tso; +Cc: Pierre Habouzit, Sam Vilain, git, Sam Vilain
In-Reply-To: <20081030163056.GA8899@mit.edu>
Theodore Tso <tytso@mit.edu> writes:
> On Thu, Oct 30, 2008 at 03:43:21PM +0100, Pierre Habouzit wrote:
>>
>> git format-patch origin/next.. works already. I'm used to the asymetric
>> git format-patch origin/next syntax, and I would be sorry if it
>> disappeared though, and I see no really good reason to get rid of it.
>
> The reason why it annoys me is because I often what to cherry-pick a
> single patch to send to someone, and so while "git show 332d2e78"
> shows me the patch, but if I want to use git-send-email for that
> particular patch, "git format-patch 332d2e78" doesn't DTRT. I have to
> type "git format-patch 332d2e78^..332d2e78" instead.
> ...
> (And I get annoyed when I want to run git format-patch on a single
> patch not at the tip of the tree; but if it's just me, I can write a
> "git format-single-patch" wrapper script to get around it.)
Huh? I am so used to "git format-patch -1 HEAD" (or "332d2e78") that I am
very surprised.
^ permalink raw reply
* Re: [PATCH 1/3] git send-email: make the message file name more specific.
From: Junio C Hamano @ 2008-11-02 6:18 UTC (permalink / raw)
To: Pierre Habouzit; +Cc: git
In-Reply-To: <1225456609-694-2-git-send-email-madcoder@debian.org>
Pierre Habouzit <madcoder@debian.org> writes:
> This helps editors choosing their syntax hilighting properly.
Even though I agree this is the right direction to go, unfortunately this
can break people's existing setup.
Having said that, if we were to do this, let's do it the right way and put
these "temporary" files under $GIT_DIR.
>
> Signed-off-by: Pierre Habouzit <madcoder@debian.org>
> ---
> git-send-email.perl | 2 +-
> 1 files changed, 1 insertions(+), 1 deletions(-)
>
> diff --git a/git-send-email.perl b/git-send-email.perl
> index 65c254d..4ca571f 100755
> --- a/git-send-email.perl
> +++ b/git-send-email.perl
> @@ -127,7 +127,7 @@ sub unique_email_list(@);
> sub cleanup_compose_files();
>
> # Constants (essentially)
> -my $compose_filename = ".msg.$$";
> +my $compose_filename = ".gitsendemail.msg.$$";
>
> # Variables we fill in automatically, or via prompting:
> my (@to,@cc,@initial_cc,@bcclist,@xh,
> --
> 1.6.0.3.763.g0275.dirty
>
> --
> To unsubscribe from this list: send the line "unsubscribe git" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH 3/3] git send-email: add --annotate option
From: Junio C Hamano @ 2008-11-02 6:23 UTC (permalink / raw)
To: Pierre Habouzit; +Cc: git
In-Reply-To: <1225450632-7230-4-git-send-email-madcoder@debian.org>
Pierre Habouzit <madcoder@debian.org> writes:
> This allows to review every patch (and fix various aspects of them, or
> comment them) in an editor just before being sent. Combined to the fact
> that git send-email can now process revision lists, this makes git
> send-email and efficient way to review and send patches interactively.
Without your patches, you run format-patch (with or without cover), you
use the editor of your choice to massage them and feed the resulting files
to send-email.
Only because you wanted to allow format-patch parameters to be given to
send-email, you now need to also allow the messages to be massaged before
they are sent out.
Is it only me who finds that this series creates its own problem and then
has to solve it? What are we getting in return?
^ permalink raw reply
* Re: [PATCH 1/3] Fix error in diff_filepair::status documentation.
From: Junio C Hamano @ 2008-11-02 6:31 UTC (permalink / raw)
To: Yann Dirson; +Cc: git
In-Reply-To: <20081101220314.1116.79924.stgit@gandelf.nowhere.earth>
Yann Dirson <ydirson@altern.org> writes:
> Signed-off-by: Yann Dirson <ydirson@altern.org>
> ---
>
> diffcore.h | 2 +-
> 1 files changed, 1 insertions(+), 1 deletions(-)
>
> diff --git a/diffcore.h b/diffcore.h
> index 713cca7..05d0898 100644
> --- a/diffcore.h
> +++ b/diffcore.h
> @@ -62,7 +62,7 @@ struct diff_filepair {
> struct diff_filespec *one;
> struct diff_filespec *two;
> unsigned short int score;
> - char status; /* M C R N D U (see Documentation/diff-format.txt) */
> + char status; /* M C R A D U etc. (see DIFF_STATUS_* in diff.h) */
I think you spotted the right bug and fixed it in a wrong way. The status
letters are user visible, and "git grep status Documentation/*diff*"
mention it in handful places without listing its repertoire, which _is_
the bug.
^ permalink raw reply
* Re: [PATCH] autoconf: Add link tests to each AC_CHECK_FUNC() test
From: Junio C Hamano @ 2008-11-02 8:04 UTC (permalink / raw)
To: David M. Syzdek; +Cc: git, jnareb
In-Reply-To: <1225021939-11858-1-git-send-email-david.syzdek@acsalaska.net>
"David M. Syzdek" <david.syzdek@acsalaska.net> writes:
> Update configure.ac to test libraries for getaddrinfo, strcasestr, memmem,
> strlcpy, strtoumax, setenv, unsetenv, and mkdtemp. The default compilers
> on FreeBSD 4.9-SECURITY and FreeBSD 6.2-RELEASE-p4 do not generate warnings
> for missing prototypes unless `-Wall' is used. This behavior renders the
> results of AC_CHECK_FUNC() void on these platforms. The test AC_SEARCH_LIBS()
> verifies a function is valid by linking to symbol within the system libraries.
> diff --git a/configure.ac b/configure.ac
> index 7c2856e..d3b8bc3 100644
> --- a/configure.ac
> +++ b/configure.ac
> @@ -293,9 +293,11 @@ AC_SUBST(NO_SOCKADDR_STORAGE)
> #
> # Define NO_IPV6 if you lack IPv6 support and getaddrinfo().
> AC_CHECK_TYPE([struct addrinfo],[
> - AC_CHECK_FUNC([getaddrinfo],
> - [NO_IPV6=],
> - [NO_IPV6=YesPlease])
> + AC_CHECK_FUNC([getaddrinfo],[
> + AC_SEARCH_LIBS([getaddrinfo],,
> + [NO_IPV6=],
> + [NO_IPV6=YesPlease])
> + ],[NO_IPV6=YesPlease])
It's been a looong time since I did any sizeable autoconf/m4 hacking, but
the repetitititiveness of this patch loudly calls for a convenience macro
of a higher order, perhaps something like:
AC_DEFUN([GIT_CHECK_FUNC],[
AC_CHECK_FUNC([$1],[
AC_SEARCH_LIBS([$1},,
[$2],[$3])],
[$3])])
Then we can use it like:
GIT_CHECK_FUNC([getaddrinfo],[NO_IPV6=],[NO_IPV6=YesPlease])
Hmm?
-- >8 --
[PATCH] autoconf: use AC_CHECK_FUNC() with AC_SEARCH_LIBS() test
Update configure.ac to test libraries for getaddrinfo, strcasestr, memmem,
strlcpy, strtoumax, setenv, unsetenv, and mkdtemp. The default compilers
on FreeBSD 4.9-SECURITY and FreeBSD 6.2-RELEASE-p4 do not generate warnings
for missing prototypes unless `-Wall' is used. This behavior renders the
results of AC_CHECK_FUNC() void on these platforms. The test AC_SEARCH_LIBS()
verifies a function is valid by linking to symbol within the system libraries.
---
configure.ac | 28 +++++++++++++++++++---------
1 files changed, 19 insertions(+), 9 deletions(-)
diff --git c/configure.ac w/configure.ac
index 27bab00..ef544e8 100644
--- c/configure.ac
+++ w/configure.ac
@@ -65,7 +65,17 @@ else \
fi \
])# GIT_PARSE_WITH
-
+dnl
+dnl GIT_CHECK_FUNC(FUNCTION, IFTRUE, IFFALSE)
+dnl -----------------------------------------
+dnl Similar to AC_CHECK_FUNC, but on systems that do not generate
+dnl warnings for missing prototypes (e.g. FreeBSD when compiling without
+dnl -Wall), it does not work. By looking for function definition in
+dnl libraries, this problem can be worked around.
+AC_DEFUN([GIT_CHECK_FUNC],[AC_CHECK_FUNC([$1],[
+ AC_SEARCH_LIBS([$1],,
+ [$2],[$3])
+],[$3])])
## Site configuration related to programs (before tests)
## --with-PACKAGE[=ARG] and --without-PACKAGE
#
@@ -325,7 +335,7 @@ AC_SUBST(NO_SOCKADDR_STORAGE)
#
# Define NO_IPV6 if you lack IPv6 support and getaddrinfo().
AC_CHECK_TYPE([struct addrinfo],[
- AC_CHECK_FUNC([getaddrinfo],
+ GIT_CHECK_FUNC([getaddrinfo],
[NO_IPV6=],
[NO_IPV6=YesPlease])
],[NO_IPV6=YesPlease],[
@@ -419,43 +429,43 @@ AC_SUBST(SNPRINTF_RETURNS_BOGUS)
AC_MSG_NOTICE([CHECKS for library functions])
#
# Define NO_STRCASESTR if you don't have strcasestr.
-AC_CHECK_FUNC(strcasestr,
+GIT_CHECK_FUNC(strcasestr,
[NO_STRCASESTR=],
[NO_STRCASESTR=YesPlease])
AC_SUBST(NO_STRCASESTR)
#
# Define NO_MEMMEM if you don't have memmem.
-AC_CHECK_FUNC(memmem,
+GIT_CHECK_FUNC(memmem,
[NO_MEMMEM=],
[NO_MEMMEM=YesPlease])
AC_SUBST(NO_MEMMEM)
#
# Define NO_STRLCPY if you don't have strlcpy.
-AC_CHECK_FUNC(strlcpy,
+GIT_CHECK_FUNC(strlcpy,
[NO_STRLCPY=],
[NO_STRLCPY=YesPlease])
AC_SUBST(NO_STRLCPY)
#
# Define NO_STRTOUMAX if you don't have strtoumax in the C library.
-AC_CHECK_FUNC(strtoumax,
+GIT_CHECK_FUNC(strtoumax,
[NO_STRTOUMAX=],
[NO_STRTOUMAX=YesPlease])
AC_SUBST(NO_STRTOUMAX)
#
# Define NO_SETENV if you don't have setenv in the C library.
-AC_CHECK_FUNC(setenv,
+GIT_CHECK_FUNC(setenv,
[NO_SETENV=],
[NO_SETENV=YesPlease])
AC_SUBST(NO_SETENV)
#
# Define NO_UNSETENV if you don't have unsetenv in the C library.
-AC_CHECK_FUNC(unsetenv,
+GIT_CHECK_FUNC(unsetenv,
[NO_UNSETENV=],
[NO_UNSETENV=YesPlease])
AC_SUBST(NO_UNSETENV)
#
# Define NO_MKDTEMP if you don't have mkdtemp in the C library.
-AC_CHECK_FUNC(mkdtemp,
+GIT_CHECK_FUNC(mkdtemp,
[NO_MKDTEMP=],
[NO_MKDTEMP=YesPlease])
AC_SUBST(NO_MKDTEMP)
^ permalink raw reply related
* Re: [PATCH] git-diff: Add --staged as a synonym for --cached.
From: Junio C Hamano @ 2008-11-02 8:30 UTC (permalink / raw)
To: Jeff King; +Cc: Johannes Schindelin, David Symonds, git, gitster, Stephan Beyer
In-Reply-To: <20081029171122.GA12167@sigill.intra.peff.net>
Jeff King <peff@peff.net> writes:
> If we assume that we have only the word "stage" and variations
> available, then there aren't too many options.
>
> only the staging area:
> --stage-only, --staged-only
>
> both:
> --staged (as opposed to --staged-only) --stage-and-worktree (too
> long), --both (not descriptive enough), --stage-too (yuck)
A flag "--staged" that means "staged changes and changes in the work tree"
is no worse than the current "--index". If we were to shoot for clarity,
how about --staged-only (aka --cached) vs --staged-and-unstaged (aka --index)?
I am actually actively unhappy about the latter, but I like more
descriptive --staged-only for the former a lot better.
^ permalink raw reply
* Re: [PATHv2 8/8] gitweb: make the supported snapshot formats array global
From: Junio C Hamano @ 2008-11-02 8:50 UTC (permalink / raw)
To: Giuseppe Bilotta; +Cc: Jakub Narebski, git, Petr Baudis
In-Reply-To: <200811020255.01895.jnareb@gmail.com>
Jakub Narebski <jnareb@gmail.com> writes:
> Very good idea, although I'd prefer for this patch to come first;
> it is not controversial contrary to other patches in this (sub)series
> which IMHO needs some thought first.
>
> Acked-by: Jakub Narebski <jnareb@gmail.com>
I've dismissed the three patches 6-8 (without prejudice, as I lost track
of them); please resubmit and re-ack.
^ permalink raw reply
* Re: [PATCH] add instructions on how to send patches to the mailing list with Gmail
From: Pierre Habouzit @ 2008-11-02 9:10 UTC (permalink / raw)
To: Tom Preston-Werner; +Cc: Santi Béjar, git, Junio C Hamano
In-Reply-To: <b97024a40811011340s92a1c24jb81b75dfb25e43c5@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 2030 bytes --]
On Sat, Nov 01, 2008 at 08:40:27PM +0000, Tom Preston-Werner wrote:
> On Sat, Nov 1, 2008 at 3:00 AM, Santi Béjar <santi@agolina.net> wrote:
> > On Sat, Nov 1, 2008 at 8:28 AM, Tom Preston-Werner <tom@github.com> wrote:
> >> Gmail is one of the most popular email providers in the world. Now that Gmail
> >> supports IMAP, sending properly formatted patches via `git imap-send` is
> >> trivial. This section in SubmittingPatches explains how to do so.
> >>
> >> Signed-off-by: Tom Preston-Werner <tom@github.com>
> >> ---
> >> Documentation/SubmittingPatches | 27 +++++++++++++++++++++++++++
> >> 1 files changed, 27 insertions(+), 0 deletions(-)
> >>
> >> diff --git a/Documentation/SubmittingPatches b/Documentation/SubmittingPatches
> >> index a1e9100..f0295c6 100644
> >> --- a/Documentation/SubmittingPatches
> >> +++ b/Documentation/SubmittingPatches
> >> @@ -456,3 +456,30 @@ This should help you to submit patches inline using KMail.
> >>
> >> 5) Back in the compose window: add whatever other text you wish to the
> >> message, complete the addressing and subject fields, and press send.
> >> +
> >> +
> >> +Gmail
> >> +-----
> >> +
> >> +Submitting properly formatted patches via Gmail is simple now that
> >> +IMAP support is available. First, edit your ~/.gitconfig to specify your
> >> +account settings:
> >> +
> >> +[imap]
> >> + folder = "[Gmail]/Drafts"
> >> + host = imaps://imap.gmail.com
> >> + user = user@gmail.com
> >> + pass = p4ssw0rd
> >> + port = 993
> >> + sslverify = false
> >
> > Warning: It is not secure.
>
> It is true that the certificate is not verified, but since the patches
> are destined for a public mailing list, this does not represent a
> large problem.
What he means is that the password is cleartext ;)
(I think)
--
·O· Pierre Habouzit
··O madcoder@debian.org
OOO http://www.madism.org
[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Re: libgit2 - a true git library
From: Pierre Habouzit @ 2008-11-02 9:19 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: Andreas Ericsson, git, Scott Chacon
In-Reply-To: <20081101204259.GC15463@spearce.org>
[-- Attachment #1: Type: text/plain, Size: 2330 bytes --]
On Sat, Nov 01, 2008 at 08:42:59PM +0000, Shawn O. Pearce wrote:
> Andreas Ericsson <ae@op5.se> wrote:
> > Shawn O. Pearce wrote:
> >> During the GitTogether we were kicking around the idea of a ground-up
> >> implementation of a Git library.
> >
> > Having looked briefly at the code, I've got a couple of comments:
> > * GIT_EXTERN() does nothing. Ever. It's noise and should be removed.
>
> I feel the same way.
>
> But I was also under the impression that the brilliant engineers
> who work for Microsoft decided that on their platform special
> annotations have to be inserted on functions that a DLL wants to
> export to applications.
>
> Hence any cross-platform library that I have seen annotates their
> exported functions this way, with the macro being empty on POSIX
> and expanding to some magic keyword on Microsoft's OS. I think it
> goes between the return type and the function name too...
>
> > Instead it would be better to have GIT_PRIVATE(),
>
> I can see why you said this; needing GIT_PRIVATE() is a lot more
> rare than needing GIT_EXTERN(). Only a handful of cross-module,
> but private, functions are likely to exist, so it makes sense to
> mark the smaller subset. But see above. *sigh*
Not only there is the windows thing, but the *best* way to design a
library is to make _everything_ by default and only show what you mean
to.
GIT_EXTERN allow us to do just that with
__attribute__((visibility("default"))) on GNU-ld/GCC.
Of course we can achieve the same using nothing on public symbols and
__attribute__((visibility("hidden"))) on the private ones, but it's way
more cumbersome and there's always a chance to forget one. It's bad
design IMHO.
FWIW GIT_EXTERN(...) prototype(arguments); isn't unredable to me,
everyone does that, it doesn't break tags, it's _good_. And you can ask
doxygen to substitute this GIT_EXTERN(x) with x so that it doesn't shows
up in the documentation at all (it can include these kind of partially
preprocessed headers in the documentation) for the people who are really
annoyed with them.
But it's definitely a necessary evil.
--
·O· Pierre Habouzit
··O madcoder@debian.org
OOO http://www.madism.org
[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* [PATHv3 0/3] PATH_INFO snapshot formats
From: Giuseppe Bilotta @ 2008-11-02 9:21 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git, Petr Baudis, Junio C Hamano, Giuseppe Bilotta
The following three patches allow gitweb to read (and emit) PATH_INFO
URLs with embedded snapshot_format information. This eliminates one
for CGI parameter when PATH_INFO is enabled, and also offers a more
user-friendly URL for snapshots.
The first patch is actually rather independent from the other two: it
collects the definition (and calculation) of the array of allowed
snapshot into a global variable.
Giuseppe Bilotta (3):
gitweb: make the supported snapshot formats array global
gitweb: retrieve snapshot format from PATH_INFO
gitweb: embed snapshot format parameter in PATH_INFO
gitweb/gitweb.perl | 70 ++++++++++++++++++++++++++++++++++++++++++++++------
1 files changed, 62 insertions(+), 8 deletions(-)
^ permalink raw reply
* [PATHv3 1/3] gitweb: make the supported snapshot formats array global
From: Giuseppe Bilotta @ 2008-11-02 9:21 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git, Petr Baudis, Junio C Hamano, Giuseppe Bilotta
In-Reply-To: <1225617699-30004-1-git-send-email-giuseppe.bilotta@gmail.com>
The array of supported snapshot format is used and defined (with two
different names) in two routines, one of which (format_snapshot_links)
is often called multiple times per page.
Simplify code and speed up page generation by making the array global.
Signed-off-by: Giuseppe Bilotta <giuseppe.bilotta@gmail.com>
---
gitweb/gitweb.perl | 15 +++++++--------
1 files changed, 7 insertions(+), 8 deletions(-)
diff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl
index 9d1af7e..8441912 100755
--- a/gitweb/gitweb.perl
+++ b/gitweb/gitweb.perl
@@ -721,6 +721,10 @@ if (defined $searchtext) {
our $git_dir;
$git_dir = "$projectroot/$project" if $project;
+# list of supported snapshot formats
+our @snapshot_fmts = gitweb_check_feature('snapshot');
+@snapshot_fmts = filter_snapshot_fmts(@snapshot_fmts);
+
# dispatch
if (!defined $action) {
if (defined $hash) {
@@ -1647,8 +1651,6 @@ sub format_diff_line {
# linked. Pass the hash of the tree/commit to snapshot.
sub format_snapshot_links {
my ($hash) = @_;
- my @snapshot_fmts = gitweb_check_feature('snapshot');
- @snapshot_fmts = filter_snapshot_fmts(@snapshot_fmts);
my $num_fmts = @snapshot_fmts;
if ($num_fmts > 1) {
# A parenthesized list of links bearing format names.
@@ -4850,20 +4852,17 @@ sub git_tree {
}
sub git_snapshot {
- my @supported_fmts = gitweb_check_feature('snapshot');
- @supported_fmts = filter_snapshot_fmts(@supported_fmts);
-
my $format = $input_params{'snapshot_format'};
- if (!@supported_fmts) {
+ if (!@snapshot_fmts) {
die_error(403, "Snapshots not allowed");
}
# default to first supported snapshot format
- $format ||= $supported_fmts[0];
+ $format ||= $snapshot_fmts[0];
if ($format !~ m/^[a-z0-9]+$/) {
die_error(400, "Invalid snapshot format parameter");
} elsif (!exists($known_snapshot_formats{$format})) {
die_error(400, "Unknown snapshot format");
- } elsif (!grep($_ eq $format, @supported_fmts)) {
+ } elsif (!grep($_ eq $format, @snapshot_fmts)) {
die_error(403, "Unsupported snapshot format");
}
--
1.5.6.5
^ permalink raw reply related
* [PATHv3 3/3] gitweb: embed snapshot format parameter in PATH_INFO
From: Giuseppe Bilotta @ 2008-11-02 9:21 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git, Petr Baudis, Junio C Hamano, Giuseppe Bilotta
In-Reply-To: <1225617699-30004-3-git-send-email-giuseppe.bilotta@gmail.com>
When PATH_INFO is active, get rid of the sf CGI parameter by embedding
the snapshot format information in the PATH_INFO URL, in the form of an
appropriate extension.
Signed-off-by: Giuseppe Bilotta <giuseppe.bilotta@gmail.com>
---
gitweb/gitweb.perl | 17 +++++++++++++++++
1 files changed, 17 insertions(+), 0 deletions(-)
diff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl
index 0a41be5..d2484ab 100755
--- a/gitweb/gitweb.perl
+++ b/gitweb/gitweb.perl
@@ -810,6 +810,7 @@ sub href (%) {
# - action
# - hash_parent or hash_parent_base:/file_parent
# - hash or hash_base:/filename
+ # - the snapshot_format as an appropriate suffix
# When the script is the root DirectoryIndex for the domain,
# $href here would be something like http://gitweb.example.com/
@@ -821,6 +822,10 @@ sub href (%) {
$href .= "/".esc_url($params{'project'}) if defined $params{'project'};
delete $params{'project'};
+ # since we destructively absorb parameters, we keep this
+ # boolean that remembers if we're handling a snapshot
+ my $is_snapshot = $params{'action'} eq 'snapshot';
+
# Summary just uses the project path URL, any other action is
# added to the URL
if (defined $params{'action'}) {
@@ -860,6 +865,18 @@ sub href (%) {
$href .= esc_url($params{'hash'});
delete $params{'hash'};
}
+
+ # If the action was a snapshot, we can absorb the
+ # snapshot_format parameter too
+ if ($is_snapshot) {
+ my $fmt = $params{'snapshot_format'};
+ # snapshot_format should always be defined when href()
+ # is called, but just in case some code forgets, we
+ # fall back to the default
+ $fmt ||= $snapshot_fmts[0];
+ $href .= $known_snapshot_formats{$fmt}{'suffix'};
+ delete $params{'snapshot_format'};
+ }
}
# now encode the parameters explicitly
--
1.5.6.5
^ 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