* Re: Official Git Homepage change? Re: git-scm.com
From: Scott Chacon @ 2008-07-26 6:43 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Petr Baudis, git
In-Reply-To: <7v4p6dnv5k.fsf@gitster.siamese.dyndns.org>
On Fri, Jul 25, 2008 at 9:09 PM, Junio C Hamano <gitster@pobox.com> wrote:
> Petr Baudis <pasky@suse.cz> writes:
>
>> .... Of course, I would be transferring the control of the homepage
>> from my hands so I would like to poll the community about how do people
>> feel about this - opinion of core Git contributors would be especially
>> welcome...
>> ...
>> - The new site is affiliated with a commercial entity - GitHub.
>> The website maintainer also has commercial interest in some published
>> Git learning materials, which might generate certain conflict of
>> interests; we must trust them that they handle this well.
>> - Both GitHub and Scott seem to be rather distanced from the "core"
>> Git development community. This might or might not be an issue.
>
> These two are directly related. They might be friendly and well-meaning
> folks, but I agree that they haven't earned our trust yet.
>
> But I do not think it matters that much.
>
> The thing is, git.or.cz may have been the closest thing to the "official"
> homepage we have had, but that is not because Linus or I or Shawn declared
> the site is official and/or that the site is trustworthy. It was because
> you put efforts preparing the contents worthy to be one-stop shop for git
> related information, back when there was no such thing. And the members
> of the comminity found it a good site. And you have the wiki there, where
> there truly have been community participation to enhance the contents.
>
> For me personally, pages outside the wiki have never felt like "the
> official git homepage", not because the contents you prepared were
> inadequate, but because I did not see much community participation to help
> enrich it.
>
> So I wish the new site success, but the definition of success from my
> point of view is not how many random visitors it will attract, but how
> well the site makes the contributors (both to git software itself, and to
> the site's contents) feel welcomed. Maybe in time it will become
> successful enough by _my_ definition of success, and I may recommend
> kernel.org folks to point at it from http://git.kernel.org/ (link with
> text "overview") if/when that happens, and I may start mentioning them in
> the "Note". We'll see.
>
>> The negatives section writeup is longer, but in fact I think the
>> positives win here; I also have a bit of bad conscience about not giving
>> git.or.cz the amount of time it would deserve...
>
> Let me thank you for maintaining not just git.or.cz/ but also repo.or.cz/
> and the wiki. I personally never visited the "Homepage" but the
> repositories and the wiki are valuable services you gave back to the
> community.
>
> It's also somewhat interesting to observe that several people I have never
> heard of in the git circle are simultaneously doing new git books,
> apparently never asking for much technical advice from core git people, by
> the way.
>
To be honest, I have asked for a fair amount of technical advice from
many helpful people in the IRC channel over the past few years. In my
case, one of my best friends - the guy I've been working with for the
last 4 years - is Nick Hengeveld, who has something like 50 commits in
there - why email the list when I can yell a question over the cube
wall? I'm sure you all have more important things to do than review
my book for newbies - I asked Nick to do it.
If I could code C worth a lick, I'm sure I would have contributed more
to this list, but since I have nothing that I feel would be helpful to
you, I've passively followed the list. I'm sorry that you do not
consider me a "git community member" just because I don't code C, and
so I can't contribute helpfully to core.
However, I have evangelized Git in person to literally thousands of
people, and tens of thousands more online. GitHub hosts over 10,000
public git projects completely for free, and has contributed a ton
back to the community, both in code and proselytization efforts.
I hope these things can be taken as proof that we are not simply
friendly and well meaning, but that we have contributed meaningfully
to the adoption of Git and are just as committed to it's improvement
and success as nearly anyone on this list.
We want to help - help you with resources, help new people learn git
quickly and easily, and help the unconverted see the light. We highly
respect you guys and most of the time you don't hear from us because
we don't want to bother you and take your time away from improving our
favorite tool.
Feel free to contact or email me at any time with questions, or
suggestions for improvement - schacon on IRC, schacon at gmail, or
thescottchacon on AIM.
Scott
^ permalink raw reply
* Re: [PATCHv2] git-mv: Keep moved index entries inact
From: Junio C Hamano @ 2008-07-26 6:46 UTC (permalink / raw)
To: Petr Baudis; +Cc: git
In-Reply-To: <20080721002508.26773.92277.stgit@localhost>
Petr Baudis <pasky@suse.cz> writes:
> The rewrite of git-mv from a shell script to a builtin was perhaps
> a little too straightforward: the git add and git rm queues were
> emulated directly, which resulted in a rather complicated code and
> caused an inconsistent behaviour when moving dirty index entries;
> git mv would update the entry based on working tree state,
> except in case of overwrites, where the new entry would still have
> sha1 of the old file.
>
> This patch introduces rename_index_entry_at() into the index toolkit,
> which will rename an entry while removing any entries the new entry
> might render duplicate. This is then used in git mv instead
> of all the file queues, resulting in a major simplification
> of the code and an inevitable change in git mv -n output format.
> ...
Thanks. I think I've managed to fix the rename_index_entry_at() in a
satisfactory way, and also made builtin-mv to allow "mv -f symlink file"
and "mv -f file symlink".
I do not agree with the semantics of this test seems to want, though.
> +test_expect_failure 'git mv should follow symlink to a directory' '
> +
> + rm -fr .git &&
> + git init &&
> + echo 1 >moved &&
> + mkdir -p dir &&
> + touch dir/.keep &&
> + ln -s dir symlink &&
> + git add moved dir/.keep symlink &&
> + git mv moved symlink &&
> + [ ! -e moved ] &&
> + [ -f symlink/moved ] &&
> + [ $(cat symlink/moved) = 1 ] &&
> + [ "$(ls dir)" = "$(ls symlink)" ] &&
> + git diff-files --quiet
> +
> +'
A symlink to us is just a different kind of blob, and by definition a blob
is the leaf level of a tree structure that represents the working tree in
the index. There won't be anything hanging below it, and when adding
things to the index we should not dereference the symlink to see where it
leads to.
Traditionally we have been loose about this check, and the normal "git
add" and "git update-index" codepath is still forever broken, and we
allow:
$ mkdir dir
$ >dir/file
$ ln -s dir symlink
$ git add symlink/file
but some codepaths that matter more (because they do larger damage
unattended, as opposed to the above command sequence that can be avoided
by user education a bit more easily), such as "git apply" and "git
read-tree", have been corrected using has_symlink_leading_path() since mid
2007. We would need to follow through c40641b (Optimize symlink/directory
detection, 2008-05-09) and further fix "git add" and "git update-index"
codepaths to forbid the above command sequence.
So my take on the above test piece is that after:
>moved
mkdir dir
>dir/file
ln -s dir symlink
git add moved dir symlink
This should fail, as it is an overwrite:
git mv moved symlink
and with "-f", the command should simply remove symlink and replace it
with a regular file whose contents come from the original "moved".
IOW, what a symlink points at should not matter.
^ permalink raw reply
* Re: how about removing --exec-path?
From: Alex Riesen @ 2008-07-26 6:48 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git
In-Reply-To: <alpine.DEB.1.00.0807260448210.26810@eeepc-johanness>
Johannes Schindelin, Sat, Jul 26, 2008 04:49:06 +0200:
> On Fri, 25 Jul 2008, Alex Riesen wrote:
>
> > The thing has at least this problem: is not passed to upload-pack when
> > running fetch.
>
> It should be added to PATH, and so it is passed to upload-pack, amongst
> others, in a sense.
>
Yes, but next time upload-pack runs a program, it adds builtin exec
path to PATH (because --exec-path not given to transport's uploadpack
command). So it looks like this:
$GIT_EXEC_PATH:/usr/local/libexec/git-core:/orig/exec-path:\
$GIT_EXEC_PATH:/usr/local/libexec/git-core:$ORIG_USER_PATH
which kind of useless for debugging. So using GIT_EXEC_PATH is the
only way (and why did we need more? Working around something?)
^ permalink raw reply
* Re: Official Git Homepage change? Re: git-scm.com
From: Scott Chacon @ 2008-07-26 7:07 UTC (permalink / raw)
To: Petr Baudis; +Cc: git
In-Reply-To: <20080726015314.GU32184@machine.or.cz>
On Fri, Jul 25, 2008 at 6:53 PM, Petr Baudis <pasky@suse.cz> wrote:
> Hi,
>
> On Fri, Jul 25, 2008 at 10:35:43AM -0700, Scott Chacon wrote:
>> Anyhow, I'm discussing with Petr about where we want to go from here -
>> what changes he'd like to make, etc, but I obviously value your
>> opinion as well, so please let me know what you think. The content
>> has barely changed, it's really just a usability overhaul. I want to
>> make sure that whatever someone is looking for (especially someone
>> new), they can find in a few clicks and a few seconds.
>
> when the initial NIH reaction passes, I have to admit that I do rather
> like it - and it's not only because you keep mentioning how awesome I am
> in your blog post. ;-)
>
> I wonder if all the Git users find the heading rather funny as I did,
> instead of unprofessional - but maybe we don't care about users without
> a particular sense of humor. I'm also not overly fond of the color theme
> but I'm perhaps just too heavy of a blue fan.
>
> Plenty of minor fixes are available for pull at
>
> git://github.com/pasky/learn-github.git
> (http://github.com/pasky/learn-github/tree/master)
I've pulled in all this stuff and it should be live now.
>
> Other non-trivial nits:
>
> * I'm feeling a bit uneasy about listing so many projects using Git;
> I haven't heard about quite a few of these and I'm not sure on what
> merit should we list projects. "Prototype" or "Liftweb" and probably
> even "Rubinius", is that going to ring a bell for major part of visitors
> so that they say "oh, even _those_ guys are using Git"?
Based on a conversation in the other thread, I think we should have a
list that is suggested by the community and just have the 3 or 4 that
are really famous (Git, Linux, RoR...) and have the rest randomly
pulled from that list - changed every day or so.
> * Cut the contributors list at 4 or 5 commits? Below that, the list
> is getting fairly useless anyway and you have trouble with keeping the
> names reasonably well-formed.
Done and pushed.
> * Reusing captions from command manpages in the Documentation page
> shows nicely how awful they sometimes are. :-) This is probably something
> to fix upstream, though.
I saw you changed some of these, I can take another pass. I'm not
entirely sure how useful it is to have the commands on that page, to
tell the truth. This may go away as the documentation page evolves.
> * Is "Git for the lazy" really unique in some regard to deserve to be
> listed among the other resources? I think we should minimalize
> redundancy at the documentation page, the amount of material is already
> overwhelming and it should be obvious for the visitor which document to
> choose based on his needs. I have similar doubts about the 37signals
> resources.
>
> In other words, "let's keep the resources orthogonal!"
I agree - I would like to pull a lot of the information in those links
into one open-source book that is kept up by the community and hosted
at this page. The documentation page will change significantly as we
try to simplify and maximize the usefulness of the page.
> * There is no reference to the Wiki in the documentation, only to the
> [GitDocumentation] page; I think there should be a reference to the
> [GitFaq] page too - a lot of important points that are not obvious
> to newcomers are covered there. I'm just not sure where exactly to put
> the link.
>
> * I would go as far as put the link to the Wiki itself to the
> navigation bar, simply since it is such a crucial resource.
Perhaps I should just do this - would that cover the previous one as well?
> * A guide on maintaining third-party patches is currently missing.
>
> * The development page is not referenced anywhere; the missing
> information are mailing list details (how to subscribe) and a link to
> SubmittingPatches. Also, I have recently talked with Junio about adding
> a link to the Note from the Maintainer, but we didn't yet figure out
> where to stabilize the location of that page.
I would be happy to put the note somewhere, and I will work on getting
the other few pages from the original site put up and linked
somewhere.
> How does that compare with the Git user manual? Have you considered
> collaborating on that one, or what are your reasons not to? Or are you
> trying to do something different?
I would like to - I have personally found that invaluable in learning
Git, but I would like it to be more digestible and I would like to add
a lot of supporting media to it - screencasts and diagrams, to help
people that are more visual learners. Loading up a document where the
TOC is several pages long is intimidating and difficult to start and
stop with.
Scott
^ permalink raw reply
* Re: PATCH 6/6] archive: convert,to parse_options() [was: [PATCH 5/6] archive: allow --exec and --remote without equal sign]
From: René Scharfe @ 2008-07-26 7:09 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vmyk5pjsy.fsf@gitster.siamese.dyndns.org>
Junio C Hamano schrieb:
>> archive.c | 110 +++++++++++++++++++++++++++++++++++++-----------------------
>> 1 files changed, 68 insertions(+), 42 deletions(-)
>
> Hmph, somewhat dubious.
>
> The real point of parse-options was to make the code smaller, easier to
> maintain and command line handling more consistent. At least this patch
> seems to fail on the two out of three counts.
Well, if we hid away the compression level handling in a macro defined
in parse-options.h, we could save sixteen lines of code. The patch
makes the four modes of running archive more explicit, adding three
usage lines. Three empty lines are added -- they don't really increase
the code's size.
Handling --exec and --remote takes six lines; we didn't do that before
at this place, but have to now, since we want them to show up in the
usage. We have to handle --no-format and --no-prefix, which adds four
lines.
So I don't think the bigger size make this patch dubious, but of course
I'm biased. Disallowing --no-format (using a new OPT_STRING_NONEG?) and
adding an OPT__COMPRESSION helper might be a good idea (reducing line
count in archive.c by seventeen).
Having parse-options provide a way to make --exec and --remote appear in
the usage but to reject them (OPT_UNKNOWN?) is a bit too strange, though.
> All of the other patches made obvious sense to me and are queued for -rc1
> but I'd like to backburner this one.
Fair enough.
René
^ permalink raw reply
* Re: Official Git Homepage change? Re: git-scm.com
From: Junio C Hamano @ 2008-07-26 7:11 UTC (permalink / raw)
To: Scott Chacon; +Cc: Petr Baudis, git
In-Reply-To: <d411cc4a0807252343n2b9ade68veaebb68664f0a3d7@mail.gmail.com>
"Scott Chacon" <schacon@gmail.com> writes:
> On Fri, Jul 25, 2008 at 9:09 PM, Junio C Hamano <gitster@pobox.com> wrote:
>> ...
>> These two are directly related. They might be friendly and well-meaning
>> folks, but I agree that they haven't earned our trust yet.
>>
>> But I do not think it matters that much.
>> ...
>> It's also somewhat interesting to observe that several people I have never
>> heard of in the git circle are simultaneously doing new git books,
>> apparently never asking for much technical advice from core git people, by
>> the way.
>
> To be honest, I have asked for a fair amount of technical advice from
> many helpful people in the IRC channel over the past few years. In my
> case, one of my best friends - the guy I've been working with for the
> last 4 years - is Nick Hengeveld, who has something like 50 commits in
> there - why email the list when I can yell a question over the cube
> wall? I'm sure you all have more important things to do than review
> my book for newbies - I asked Nick to do it.
Ah, Nick. We haven't heard from him for quite some time. I've actually
been missed him from time to time whenever http related issues came up.
Please say hello to him for me ;-).
> If I could code C worth a lick, I'm sure I would have contributed more
> to this list, but since I have nothing that I feel would be helpful to
> you, I've passively followed the list. I'm sorry that you do not
> consider me a "git community member" just because I don't code C, and
> so I can't contribute helpfully to core.
I realize I may have sounded somewhat harsh, but that was not my
intention. And I do not think what you said is fair, either.
We have had quite a few end user questions on this list, but I do not seem
to recall any of the names of the book writers, whose books are presumably
aimed at these people, answering them. Granted, core coders may be busy
bunch of people, and the questions and comments from new people sometimes
tend to be lost in flurry of patch floods. I and other core coders would
have greatly appreciated if non-coder experts like yourself helped these
threads that have never panned out.
I am not complaining. This cuts both ways. The patch floods do tend to
discourage new people from asking basic questions, and lack of answers
even more so. But it is not healthy for people who design and code not to
hear end user feedback. I personally would want to see the list traffic
to be inclusive.
The people who design the new features and write code should have easy
access to the issues the users of all levels have with the software and
the documentation (and what they find useful as well). What I am most
afraid of is that both "We do not bother the coders" and "We are too busy
to answer every newbie question" mentalities would lead to a fractured
community.
^ permalink raw reply
* Re: git-scm.com
From: Martin Langhoff @ 2008-07-26 7:21 UTC (permalink / raw)
To: Scott Chacon; +Cc: Johannes Schindelin, Stephan Beyer, git
In-Reply-To: <d411cc4a0807252155o18083ca0yeae6ac43a5e83bec@mail.gmail.com>
On Sat, Jul 26, 2008 at 4:55 PM, Scott Chacon <schacon@gmail.com> wrote:
> I was a bit concerned about using the little guy too, but I've gotten
> overall very good feedback about him - people seem to like him. I
> think it's good to have a little bit of illustration on a page.
It's clearly an inside joke, but I like it. And let's have the
environmentalists-with-a-sense-of-humour with us. The others can use
something else :-)
m
--
martin.langhoff@gmail.com
martin@laptop.org -- School Server Architect
- ask interesting questions
- don't get distracted with shiny stuff - working code first
- http://wiki.laptop.org/go/User:Martinlanghoff
^ permalink raw reply
* Re: Official Git Homepage change? Re: git-scm.com
From: Scott Chacon @ 2008-07-26 7:27 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Petr Baudis, git
In-Reply-To: <7vtzedktmi.fsf@gitster.siamese.dyndns.org>
Perhaps it would be useful to split the mailing list into core/contrib
and support lists? I would be happy to help out answering questions -
a lot of them come directly to me anyhow because of the gitcasts site
and such.
Scott
On Sat, Jul 26, 2008 at 12:11 AM, Junio C Hamano <gitster@pobox.com> wrote:
> "Scott Chacon" <schacon@gmail.com> writes:
>
>> On Fri, Jul 25, 2008 at 9:09 PM, Junio C Hamano <gitster@pobox.com> wrote:
>>> ...
>>> These two are directly related. They might be friendly and well-meaning
>>> folks, but I agree that they haven't earned our trust yet.
>>>
>>> But I do not think it matters that much.
>>> ...
>>> It's also somewhat interesting to observe that several people I have never
>>> heard of in the git circle are simultaneously doing new git books,
>>> apparently never asking for much technical advice from core git people, by
>>> the way.
>>
>> To be honest, I have asked for a fair amount of technical advice from
>> many helpful people in the IRC channel over the past few years. In my
>> case, one of my best friends - the guy I've been working with for the
>> last 4 years - is Nick Hengeveld, who has something like 50 commits in
>> there - why email the list when I can yell a question over the cube
>> wall? I'm sure you all have more important things to do than review
>> my book for newbies - I asked Nick to do it.
>
> Ah, Nick. We haven't heard from him for quite some time. I've actually
> been missed him from time to time whenever http related issues came up.
> Please say hello to him for me ;-).
>
>> If I could code C worth a lick, I'm sure I would have contributed more
>> to this list, but since I have nothing that I feel would be helpful to
>> you, I've passively followed the list. I'm sorry that you do not
>> consider me a "git community member" just because I don't code C, and
>> so I can't contribute helpfully to core.
>
> I realize I may have sounded somewhat harsh, but that was not my
> intention. And I do not think what you said is fair, either.
>
> We have had quite a few end user questions on this list, but I do not seem
> to recall any of the names of the book writers, whose books are presumably
> aimed at these people, answering them. Granted, core coders may be busy
> bunch of people, and the questions and comments from new people sometimes
> tend to be lost in flurry of patch floods. I and other core coders would
> have greatly appreciated if non-coder experts like yourself helped these
> threads that have never panned out.
>
> I am not complaining. This cuts both ways. The patch floods do tend to
> discourage new people from asking basic questions, and lack of answers
> even more so. But it is not healthy for people who design and code not to
> hear end user feedback. I personally would want to see the list traffic
> to be inclusive.
>
> The people who design the new features and write code should have easy
> access to the issues the users of all levels have with the software and
> the documentation (and what they find useful as well). What I am most
> afraid of is that both "We do not bother the coders" and "We are too busy
> to answer every newbie question" mentalities would lead to a fractured
> community.
>
^ permalink raw reply
* What's cooking in git.git (Jul 2008, issue #10; Sat, 26)
From: Junio C Hamano @ 2008-07-26 7:35 UTC (permalink / raw)
To: git
Here are the topics that have been cooking. Commits prefixed
with '-' are only in 'pu' while commits prefixed with '+' are
in 'next'.
The topics list the commits in reverse chronological order. The topics
meant to be merged to the maintenance series have "maint-" in their names.
Due to increased activity level from people including GSoC students, I
expect 'next' to stay somewhat more active than previous rounds during the
1.6.0-rc cycle. The request for people who usually follow 'next' is the
same as usual, though. After -rc1 is tagged, please run 'master' for your
daily git use instead, in order to make sure 'master' does what it claims
to do without regression.
Tentative schedule, my wishful thinking:
- 1.6.0-rc1 (Jul 27)
- 1.6.0-rc2 (Aug 6)
- 1.6.0-rc3 (Aug 10)
----------------------------------------------------------------
[New Topics]
* cc/bisect (Tue Jul 22 08:16:18 2008 +0200) 2 commits
. bisect: only check merge bases when needed
. bisect: test merge base if good rev is not an ancestor of bad rev
* jc/add-addremove (Tue Jul 22 22:30:40 2008 -0700) 2 commits
+ builtin-add.c: optimize -A option and "git add ."
+ builtin-add.c: restructure the code for maintainability
* jk/pager-swap (Tue Jul 22 03:14:12 2008 -0400) 2 commits
+ spawn pager via run_command interface
+ run-command: add pre-exec callback
* ph/enable-threaded (Mon Jul 21 11:23:43 2008 +0200) 1 commit
+ Enable threaded delta search on *BSD and Linux.
----------------------------------------------------------------
[Cooking]
* pb/sane-mv (Mon Jul 21 02:25:56 2008 +0200) 2 commits
- git-mv: Keep moved index entries inact
- git-mv: Remove dead code branch
Running "git mv A B" when you have local changes to A automatically staged
it while moving it to B, which was a longstanding nonsense. This attempts
to fix it. Pasky has other plans to build on a more solidified foundation
to enhance the command to work with submodules better on top of this.
I think this is of 'next' quality already.
* rs/imap (Wed Jul 9 22:29:02 2008 +0100) 5 commits
+ Documentation: Improve documentation for git-imap-send(1)
+ imap-send.c: more style fixes
+ imap-send.c: style fixes
+ git-imap-send: Support SSL
+ git-imap-send: Allow the program to be run from subdirectories of
a git tree
Some people seem to prefer having this feature available also with gnutls.
Such an enhancement can be done in-tree on top of this series if they are
so inclined.
----------------------------------------------------------------
[On Hold]
* sg/merge-options (Sun Apr 6 03:23:47 2008 +0200) 1 commit
+ merge: remove deprecated summary and diffstat options and config
variables
This was previously in "will be in master soon" category, but it turns out
that the synonyms to the ones this one deletes are fairly new invention
that happend in 1.5.6 timeframe, and we cannot do this just yet. Perhaps
in 1.7.0.
* jc/dashless (Thu Jun 26 16:43:34 2008 -0700) 2 commits
+ Revert "Make clients ask for "git program" over ssh and local
transport"
+ Make clients ask for "git program" over ssh and local transport
This is the "botched" one. Will be resurrected during 1.7.0 or 1.8.0
timeframe.
* jk/renamelimit (Sat May 3 13:58:42 2008 -0700) 1 commit
. diff: enable "too large a rename" warning when -M/-C is explicitly
asked for
This would be the right thing to do for command line use, but gitk will be
hit due to tcl/tk's limitation, so I am holding this back for now.
----------------------------------------------------------------
[Dropped]
There are a handful topics that used to be in 'pu' but tentatively dropped
for now.
*^ cc/bisect (Tue Jul 22 08:16:18 2008 +0200) 2 commits
*^ gi/cherry-cache (Sat Jul 12 20:14:51 2008 -0700) 1 commit
*^ jc/grafts (Wed Jul 2 17:14:12 2008 -0700) 1 commit
*^ sb/sequencer (Tue Jul 1 04:38:34 2008 +0200) 4 commits
I still hold onto their tips and intend to update them with newer versions
and/or merge them back to 'pu' when I have time, but not right now.
^ permalink raw reply
* What's in git.git (Jul 2008, issue #08; Sat, 26)
From: Junio C Hamano @ 2008-07-26 7:36 UTC (permalink / raw)
To: git
There are quite a bunch of changes to 'master' but they are mostly fix-ups
to the new codepaths introduced recently; iow, exactly the kind of patches
we would want to see before and during the -rc period.
* The 'maint' branch has these fixes since the last announcement.
Björn Steinbrink (1):
index-pack.c: correctly initialize appended objects
Junio C Hamano (2):
tests: propagate $(TAR) down from the toplevel Makefile
Makefile: fix shell quoting
Peter Valdemar Mørch (1):
send-email: find body-encoding correctly
Pierre Habouzit (1):
git-checkout: fix command line parsing.
* The 'master' branch has these since the last announcement
in addition to the above.
Alex Riesen (1):
Allow pager of diff command be enabled/disabled
Brad King (1):
git-svn: teach dcommit about svn auto-props
Brandon Casey (7):
t/: Replace diff [-u|-U0] with test_cmp to allow compilation with old
diff
t4116-apply-reverse.sh: use $TAR rather than tar
t3200,t7201: replace '!' with test_must_fail
t7502-commit.sh: rearrange test to make more portable
t/t4202-log.sh: add newline at end of file
Teach fsck and prune about the new location of temporary objects
perl/Makefile: update NO_PERL_MAKEMAKER section
Daniel Barkalow (1):
In perforce, RCS keywords are case-sensitive
Johannes Schindelin (8):
Rename .git/rebase to .git/rebase-apply
Rename path_list to string_list
Fix two leftovers from path_list->string_list
Ignore dirty submodule states in "git pull --rebase"
Add test to show that show-branch misses out the 8th column
sort_in_topological_order(): avoid setting a commit flag
builtin-commit: Two trivial style-cleanups
git daemon: avoid waking up too often
Johannes Sixt (10):
rebase -i: When an 'edit' stops, mention the commit
Makefile: Do not install a copy of 'git' in $(gitexecdir)
Makefile: Normalize $(bindir) and $(gitexecdir) before comparing
Record the command invocation path early
Fix relative built-in paths to be relative to the command invocation
Allow the built-in exec path to be relative to the command invocation
path
Allow add_path() to add non-existent directories to the path
Windows: Make $(gitexecdir) relative
Windows: Make sure argv[0] has a path
Windows: Do not compile git-shell
Jonathan Nieder (2):
git-diff(1): "--c" -> "--cc" typo fix
document that git-tag can tag more than heads
Junio C Hamano (9):
Update my e-mail address
Revert "make git-status use a pager"
tests: do not rely on external "patch"
stash save: fix parameter handling
builtin-branch.c: remove unused code in append_ref() callback function
builtin-branch.c: optimize --merged and --no-merged
Documentation: clarify diff --cc
ignore non-existent refs in dwim_log()
Documentation: clarify how to disable elements in core.whitespace
Lee Marlow (1):
bash completion: Add long options for 'git rm'
Miklos Vajna (2):
builtin-merge: give a proper error message for invalid strategies in
config
t7601: extend the 'merge picks up the best result' test
Nikolaj Schumacher (1):
Don't cut off last character of commit descriptions.
Olivier Marin (4):
git-am: remove dash from help message
parse-options: fix segmentation fault when a required value is missing
git am --skip: clean the index while preserving local changes
update test case to protect am --skip behaviour
P. Christeas (1):
svnimport: newer libsvn wants us to ask for the root with "", not "/"
Petr Baudis (2):
git-filter-branch.sh: Allow running in bare repositories
Documentation/git-filter-branch: teach "rm" instead of "update-index
--remove"
Philippe Bruhat (1):
mailinfo: better parse email adresses containg parentheses
Pierre Habouzit (3):
builtin-merge: add missing structure initialization
git-submodule: move ill placed shift.
git-checkout: improve error messages, detect ambiguities.
René Scharfe (5):
archive: add write_archive()
archive: move parameter parsing code to archive.c
archive: define MAX_ARGS where it's needed
archive: declare struct archiver where it's needed
archive: allow --exec and --remote without equal sign
SZEDER Gábor (2):
checkout: mention '--' in the docs
bash: offer only paths after '--' for 'git checkout'
Stephan Beyer (7):
git-am: Add colon before the subject that is printed out as being applied
am --abort: Add to bash-completion and mention in git-rerere
documentation
Make non-static functions, that may be static, static
Move launch_editor() from builtin-tag.c to editor.c
editor.c: Libify launch_editor()
git-am: Mention --abort in usage string part of OPTIONS_SPEC
git-reset: Let -q hush "locally modified" messages
Steve Haslam (2):
Propagate -u/--upload-pack option of "git clone" to transport.
Remove references to git-fetch-pack from "git clone" documentation.
Thomas Rast (1):
git-completion.bash: provide completion for 'show-branch'
^ permalink raw reply
* Re: Official Git Homepage change? Re: git-scm.com
From: Sverre Rabbelier @ 2008-07-26 7:52 UTC (permalink / raw)
To: Scott Chacon; +Cc: Junio C Hamano, Petr Baudis, git
In-Reply-To: <d411cc4a0807260027t4b9c3b08x1f865ec75d976ef6@mail.gmail.com>
On Sat, Jul 26, 2008 at 09:27, Scott Chacon <schacon@gmail.com> wrote:
> Perhaps it would be useful to split the mailing list into core/contrib
> and support lists? I would be happy to help out answering questions -
> a lot of them come directly to me anyhow because of the gitcasts site
> and such.
>
> Scott "no_w_ top-posting" Chacon
There, fixed that for you.
--
Cheers,
Sverre Rabbelier
^ permalink raw reply
* Re: git-scm.com
From: Jakub Narebski @ 2008-07-26 8:03 UTC (permalink / raw)
To: Scott Chacon; +Cc: git
In-Reply-To: <d411cc4a0807251035i7aed2ec9wef7e8f1b3ae4c585@mail.gmail.com>
"Scott Chacon" <schacon@gmail.com> writes:
> A followup on the post I did a few days ago about Git documentation.
> I forked Petr's git.or.cz site and put up a version that I think is a
> bit more accessible and newbie-friendly at git-scm.com. I had meant
> to discuss this with Petr before posting it to you all, but I
> published a blog post that got a bit more attention than I expected,
> and I didn't want you all to think I didn't care about your opinion,
> as some have already accused me of.
On thing I am curious about: how do you plan to have current version
of Git in the download / last version section? Petr Baudis uses
custom script, which search git mailing list for "[ANNOUNCE]" posts,
and automatically updates download / last version links.
--
Jakub Narebski
Poland
ShadeHawk on #git
^ permalink raw reply
* Re: git-scm.com
From: Junio C Hamano @ 2008-07-26 8:06 UTC (permalink / raw)
To: Patrick Aljord; +Cc: git list, Scott Chacon
In-Reply-To: <6b6419750807252249u3c244b3fo65d9e1ee6e8b0ced@mail.gmail.com>
"Patrick Aljord" <patcito@gmail.com> writes:
> How about linking to the project web page or the official blog where
> the move was announced when available? I think that's how it's done on
> the mercurial page. And it explains people why the switch was done
> rather then linking to a source repository they might not care about
> and the link to the project page might give a hint about the
> importance of the given project for those that might not know it (such
> as prototype, mootools or liftweb).
You have to work harder to do the real research to find such key
historical documents than just linking to the toplevel of the current
repository, but I think this is an excellent idea. And most likely many
projects that have migrated from elsewhere (not the ones from scratch that
did not migrate from any existing codebase) could volunteer relevant links
if asked politely enough ;-)
^ permalink raw reply
* Re: [PATCH 2/5] Add git-sequencer documentation
From: Jakub Narebski @ 2008-07-26 8:16 UTC (permalink / raw)
To: git
In-Reply-To: <1217049644-8874-3-git-send-email-s-beyer@gmx.net>
Stephan Beyer wrote:
> +All characters after a `#` character will be ignored until the end of a line.
Probably should be 'are comments and' somewhere...
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
^ permalink raw reply
* fetch refspec foo/* matches foo*
From: Jeff King @ 2008-07-26 8:24 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Daniel Barkalow, git
In-Reply-To: <7v1w1hsmnc.fsf@gitster.siamese.dyndns.org>
On Fri, Jul 25, 2008 at 02:02:15PM -0700, Junio C Hamano wrote:
> BTW, has anybody taken a look at this one?
>
> Subject: BUG: fetch incorrect interpretation of globing patterns in refspecs
> Date: Thu, 24 Jul 2008 09:07:21 +0200
> Message-ID: <71295b5a0807240007k246973abj1897895d0d67bb6c@mail.gmail.com>
>
> If not, I think I probably need to take a look at this, reproducing and
> possibly fixing, before applying non-fix patches.
I have been meaning to look at it for days, so I finally took a peek. I
was able to reproduce the problem easily. I think it is (almost) as
simple as the patch below. In the refspec parsing, we already require
globs to come after '/', so this is the analagous check during match.
Unfortunately, this breaks t1020 (something about failing to clone HEAD
it looks like, so probably it is some boundary case for matching just
"*"). I don't have time to look further, and I will be out of touch
until probably Sunday evening, so hopefully somebody else can run with
it.
---
diff --git a/remote.c b/remote.c
index 0d6020b..3ae0431 100644
--- a/remote.c
+++ b/remote.c
@@ -1108,7 +1108,8 @@ static struct ref *get_expanded_map(const struct ref *remote_refs,
for (ref = remote_refs; ref; ref = ref->next) {
if (strchr(ref->name, '^'))
continue; /* a dereference item */
- if (!prefixcmp(ref->name, refspec->src)) {
+ if (!prefixcmp(ref->name, refspec->src)
+ && ref->name[remote_prefix_len] == '/') {
const char *match;
struct ref *cpy = copy_ref(ref);
match = ref->name + remote_prefix_len;
^ permalink raw reply related
* Re: [PATCH 2/5] Add git-sequencer documentation
From: Sverre Rabbelier @ 2008-07-26 8:26 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git
In-Reply-To: <g6emhb$p1a$1@ger.gmane.org>
On Sat, Jul 26, 2008 at 10:16, Jakub Narebski <jnareb@gmail.com> wrote:
> Stephan Beyer wrote:
>> +All characters after a `#` character will be ignored until the end of a line.
>
> Probably should be 'are comments and' somewhere...
s/ and$//
s/^/and /
--
Cheers,
Sverre Rabbelier
^ permalink raw reply
* Re: fetch refspec foo/* matches foo*
From: Jeff King @ 2008-07-26 8:33 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <20080726082405.GA10104@sigill.intra.peff.net>
On Sat, Jul 26, 2008 at 04:24:05AM -0400, Jeff King wrote:
> > If not, I think I probably need to take a look at this, reproducing and
> > possibly fixing, before applying non-fix patches.
>
> I have been meaning to look at it for days, so I finally took a peek. I
> was able to reproduce the problem easily. I think it is (almost) as
> simple as the patch below. In the refspec parsing, we already require
> globs to come after '/', so this is the analagous check during match.
Also, while I have your attention, Junio, here is another bug fix
that should go into 1.6.0. I posted the patch as a "how about this" deep
in a thread and got no response (which means no complaints, right?).
-- >8 --
init: handle empty "template" parameter
If a user passes "--template=", then our template parameter
is blank. Unfortunately, copy_templates() assumes it has at
least one character, and does all sorts of bad things like
reading from template[-1] and then proceeding to link all of
'/' into the .git directory.
This patch just checks for that condition in copy_templates
and aborts. As a side effect, this means that --template=
now has the meaning "don't copy any templates."
---
I don't really care about the "side effect" behavior, but it seems
reasonable. The other obvious option is to simply die(). Certainly
either is better than the current bug.
builtin-init-db.c | 2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/builtin-init-db.c b/builtin-init-db.c
index 38b4fcb..baf0d09 100644
--- a/builtin-init-db.c
+++ b/builtin-init-db.c
@@ -117,6 +117,8 @@ static void copy_templates(const char *template_dir)
template_dir = getenv(TEMPLATE_DIR_ENVIRONMENT);
if (!template_dir)
template_dir = system_path(DEFAULT_GIT_TEMPLATE_DIR);
+ if (!template_dir[0])
+ return;
strcpy(template_path, template_dir);
template_len = strlen(template_path);
if (template_path[template_len-1] != '/') {
--
1.6.0.rc0.233.gb3fd2
^ permalink raw reply related
* [PATCH] Modify mingw_main() workaround to avoid link errors
From: Steffen Prohaska @ 2008-07-26 9:41 UTC (permalink / raw)
To: Johannes Sixt; +Cc: git, Junio C Hamano, Steffen Prohaska
With MinGW's
gcc.exe (GCC) 3.4.5 (mingw special)
GNU ld version 2.17.50 20060824
the old define caused link errors:
git.o: In function `main':
C:/msysgit/git/git.c:500: undefined reference to `mingw_main'
collect2: ld returned 1 exit status
The modified define works.
Signed-off-by: Steffen Prohaska <prohaska@zib.de>
---
compat/mingw.h | 5 +++--
1 files changed, 3 insertions(+), 2 deletions(-)
diff --git a/compat/mingw.h b/compat/mingw.h
index 290a9e6..a52e657 100644
--- a/compat/mingw.h
+++ b/compat/mingw.h
@@ -228,9 +228,10 @@ char **env_setenv(char **env, const char *name);
* A replacement of main() that ensures that argv[0] has a path
*/
-#define main(c,v) main(int argc, const char **argv) \
+#define main(c,v) dummy_decl_mingw_main(); \
+static int mingw_main(); \
+int main(int argc, const char **argv) \
{ \
- static int mingw_main(); \
argv[0] = xstrdup(_pgmptr); \
return mingw_main(argc, argv); \
} \
--
1.6.0.rc0.42.g186458
^ permalink raw reply related
* Re: [PATCH] bash completion: Add long options for 'git describe'
From: Thomas Rast @ 2008-07-26 10:25 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: SZEDER GGGbor, git, gitster
In-Reply-To: <20080725162028.GB21117@spearce.org>
[-- Attachment #1: Type: text/plain, Size: 653 bytes --]
Shawn O. Pearce wrote:
> SZEDER GGGbor <szeder@ira.uka.de> wrote:
> > > _git_describe ()
> > > {
> > > + __git_has_doubledash && return
> > This line is superfluous, because 'git describe' does not have any path
> > arguments.
>
> Yup. Aside from the two items described above (mising SOB line
> and the unnecessary double dash test) this patch looks fine.
I suppose you're right. It does (empirically) attempt to parse
anything following a -- as a revision argument, but similar commands
like cherry-pick don't handle the -- specially either.
I'll resend a fixed version.
- Thomas
--
Thomas Rast
trast@student.ethz.ch
[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* [PATCH] bash completion: Add long options for 'git describe'
From: Thomas Rast @ 2008-07-26 10:26 UTC (permalink / raw)
To: git; +Cc: gitster, Shawn O. Pearce, SZEDER Gábor
In-Reply-To: <20080725162028.GB21117@spearce.org>
Signed-off-by: Thomas Rast <trast@student.ethz.ch>
---
contrib/completion/git-completion.bash | 9 +++++++++
1 files changed, 9 insertions(+), 0 deletions(-)
diff --git a/contrib/completion/git-completion.bash b/contrib/completion/git-completion.bash
index 3b04934..4ae8b36 100755
--- a/contrib/completion/git-completion.bash
+++ b/contrib/completion/git-completion.bash
@@ -665,6 +665,15 @@ _git_commit ()
_git_describe ()
{
+ local cur="${COMP_WORDS[COMP_CWORD]}"
+ case "$cur" in
+ --*)
+ __gitcomp "
+ --all --tags --contains --abbrev= --candidates=
+ --exact-match --debug --long --match --always
+ "
+ return
+ esac
__gitcomp "$(__git_refs)"
}
--
1.6.0.rc0.50.g6a66e
^ permalink raw reply related
* Re: Mailing lists, was Re: [RFC] Git User's Survey 2008
From: Jakub Narebski @ 2008-07-26 10:54 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: Junio C Hamano, Johannes Schindelin, Marek Zawirski, git
In-Reply-To: <20080725221331.GE23202@spearce.org>
On Sat, 26 July 2008, Shawn O. Pearce wrote:
> Junio C Hamano <gitster@pobox.com> wrote:
>>> Jakub Narebski <jnareb@gmail.com> wrote:
>>>
>>>> 27. Which of the following features do you use?
>>>> (zero or more: multiple choice)
>>>> - Integration with IDE/editor (Eclipse, Emacs, TextMate,...)
>>>> ...
>>>>
>>>> What question about egit/jgit would you like to have in the survey?
>>>
>>> I'm not certain what else I would want to ask that is egit/jgit
>>> specific.
>>
>> If you do not have any specific questions you would want to see answers
>> to, then my point was moot, which is fine.
>
> Actually I'd like the editor integration to be broken out (if
> it isn't already) so we can see which editors (and thus which
> integrations) are popular among users. I think it would help all
> of the integration authors, as well as make it clear to end-users
> where we have integration available/under development, in case they
> were not aware of it previously.
So you would like to see something like the following question in the
upcoming Git User's Survey?
xx. Which editors/IDEs/RADs do you use?
(zero or more; multiple choice with 'other')
- Emacs, Vim, Eclipse, KDevelop, Anjuta, TextMate, Notepad++,
Visual Studio, other
+ what choices should be in the list of editors and IDE;
or should perhaps this question be free-form?
--
Jakub Narebski
Poland
^ permalink raw reply
* [PATCH 2/3] builtin-branch: factor out merge_filter matching
From: Lars Hjemli @ 2008-07-26 10:27 UTC (permalink / raw)
To: git
In-Reply-To: <1217068045-3575-2-git-send-email-hjemli@gmail.com>
The logic for checking commits against merge_filter will be reused
when we recalculate the maxwidth of refnames.
Signed-off-by: Lars Hjemli <hjemli@gmail.com>
---
builtin-branch.c | 18 +++++++++++++-----
1 files changed, 13 insertions(+), 5 deletions(-)
diff --git a/builtin-branch.c b/builtin-branch.c
index 675a9b1..bff74cf 100644
--- a/builtin-branch.c
+++ b/builtin-branch.c
@@ -294,6 +294,17 @@ static void fill_tracking_info(char *stat, const char *branch_name)
sprintf(stat, "[ahead %d, behind %d] ", ours, theirs);
}
+static int matches_merge_filter(struct commit *commit)
+{
+ int is_merged;
+
+ if (merge_filter == NO_FILTER)
+ return 1;
+
+ is_merged = !!(commit->object.flags & UNINTERESTING);
+ return (is_merged == (merge_filter == SHOW_MERGED));
+}
+
static void print_ref_item(struct ref_item *item, int maxwidth, int verbose,
int abbrev, int current)
{
@@ -301,11 +312,8 @@ static void print_ref_item(struct ref_item *item, int maxwidth, int verbose,
int color;
struct commit *commit = item->commit;
- if (merge_filter != NO_FILTER) {
- int is_merged = !!(item->commit->object.flags & UNINTERESTING);
- if (is_merged != (merge_filter == SHOW_MERGED))
- return;
- }
+ if (!matches_merge_filter(commit))
+ return;
switch (item->kind) {
case REF_LOCAL_BRANCH:
--
1.6.0.rc0.79.gb0320
^ permalink raw reply related
* [PATCH 0/3] builtin-branch --[no-]merged post-optimization fixes
From: Lars Hjemli @ 2008-07-26 10:27 UTC (permalink / raw)
To: git
The optimization of --[no-]merged added some code duplication and a
possible "bug" for -v output which this series tries to rectify.
Lars Hjemli (3):
builtin-branch: remove duplicated code
builtin-branch: factor out merge_filter matching
builtin-branch: fix -v for --[no-]merged
builtin-branch.c | 42 ++++++++++++++++++++++++++++++------------
1 files changed, 30 insertions(+), 12 deletions(-)
^ permalink raw reply
* [PATCH 3/3] builtin-branch: fix -v for --[no-]merged
From: Lars Hjemli @ 2008-07-26 10:27 UTC (permalink / raw)
To: git
In-Reply-To: <1217068045-3575-3-git-send-email-hjemli@gmail.com>
After the optimization to --[no-]merged logic, the calculation of the
width of the longest refname to be shown might become inaccurate (since
the matching against merge_filter is performed after adding refs to
ref_list). This patch forces a recalculation of maxwidth when it might
be needed.
Signed-off-by: Lars Hjemli <hjemli@gmail.com>
---
builtin-branch.c | 15 +++++++++++++++
1 files changed, 15 insertions(+), 0 deletions(-)
diff --git a/builtin-branch.c b/builtin-branch.c
index bff74cf..fed6f5e 100644
--- a/builtin-branch.c
+++ b/builtin-branch.c
@@ -363,6 +363,19 @@ static void print_ref_item(struct ref_item *item, int maxwidth, int verbose,
}
}
+static int calc_maxwidth(struct ref_list *refs)
+{
+ int i, l, w = 0;
+ for (i = 0; i < refs->index; i++) {
+ if (!matches_merge_filter(refs->list[i].commit))
+ continue;
+ l = strlen(refs->list[i].name);
+ if (l > w)
+ w = l;
+ }
+ return w;
+}
+
static void print_ref_list(int kinds, int detached, int verbose, int abbrev, struct commit_list *with_commit)
{
int i;
@@ -383,6 +396,8 @@ static void print_ref_list(int kinds, int detached, int verbose, int abbrev, str
(struct object *) filter, "");
ref_list.revs.limited = 1;
prepare_revision_walk(&ref_list.revs);
+ if (verbose)
+ ref_list.maxwidth = calc_maxwidth(&ref_list);
}
qsort(ref_list.list, ref_list.index, sizeof(struct ref_item), ref_cmp);
--
1.6.0.rc0.79.gb0320
^ permalink raw reply related
* [PATCH 1/3] builtin-branch: remove duplicated code
From: Lars Hjemli @ 2008-07-26 10:27 UTC (permalink / raw)
To: git
In-Reply-To: <1217068045-3575-1-git-send-email-hjemli@gmail.com>
The previous optimization to --[no-]merged ended up with some duplicated
code which this patch removes.
Signed-off-by: Lars Hjemli <hjemli@gmail.com>
---
builtin-branch.c | 9 ++-------
1 files changed, 2 insertions(+), 7 deletions(-)
diff --git a/builtin-branch.c b/builtin-branch.c
index 5db8ad8..675a9b1 100644
--- a/builtin-branch.c
+++ b/builtin-branch.c
@@ -214,7 +214,6 @@ static int append_ref(const char *refname, const unsigned char *sha1, int flags,
struct commit *commit;
int kind;
int len;
- static struct commit_list branch;
/* Detect kind */
if (!prefixcmp(refname, "refs/heads/")) {
@@ -238,13 +237,9 @@ static int append_ref(const char *refname, const unsigned char *sha1, int flags,
if ((kind & ref_list->kinds) == 0)
return 0;
- if (merge_filter != NO_FILTER) {
- branch.item = lookup_commit_reference_gently(sha1, 1);
- if (!branch.item)
- die("Unable to lookup tip of branch %s", refname);
+ if (merge_filter != NO_FILTER)
add_pending_object(&ref_list->revs,
- (struct object *)branch.item, refname);
- }
+ (struct object *)commit, refname);
/* Resize buffer */
if (ref_list->index >= ref_list->alloc) {
--
1.6.0.rc0.79.gb0320
^ 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