* Re: [PATCH 2/3] mergetool-lib: specialize xxdiff options when in diff mode
From: Markus Heidelberg @ 2009-04-02 21:20 UTC (permalink / raw)
To: David Aguilar; +Cc: gitster, git
In-Reply-To: <1238668246-762-2-git-send-email-davvid@gmail.com>
David Aguilar, 02.04.2009:
> We don't need '-merged-file', 'save as', and the merge-status exit
> code when in diff mode
I guess the same as for xxdiff and kdiff3 also applies to opendiff,
ecmerge and emerge. But since I don't have them installed, I'm not
entirely sure not to break something.
On the other hand it should be save, since they were just copied from
git-mergetool without adjustment for diff use.
Markus
^ permalink raw reply
* Re: [PATCH] mailmap: resurrect lower-casing of email addresses
From: A Large Angry SCM @ 2009-04-02 22:22 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git, gitster, Marius Storm-Olsen
In-Reply-To: <f182fb1700e8dea15459fd02ced2a6e5797bec99.1238458535u.git.johannes.schindelin@gmx.de>
{I may be late to this change since I'm trying to catch up on the ML.]
Johannes Schindelin wrote:
> Commit 0925ce4(Add map_user() and clear_mailmap() to mailmap) broke the
> lower-casing of email addresses. This mostly did not matter if your
> .mailmap has only lower-case email addresses; However, we did not
> require .mailmap to contain lowercase-only email addresses.
What part of the email address is this going to lowercase? Only the
domain name is case agnostic.
>
> Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
> ---
> lezzee how that goes
> mailmap.c | 9 +++++++++
> 1 files changed, 9 insertions(+), 0 deletions(-)
>
> diff --git a/mailmap.c b/mailmap.c
> index f12bb45..6be91b6 100644
> --- a/mailmap.c
> +++ b/mailmap.c
> @@ -50,6 +50,15 @@ static void add_mapping(struct string_list *map,
> {
> struct mailmap_entry *me;
> int index;
> + char *p;
> +
> + if (old_email)
> + for (p = old_email; *p; p++)
> + *p = tolower(*p);
> + if (new_email)
> + for (p = new_email; *p; p++)
> + *p = tolower(*p);
> +
> if (old_email == NULL) {
> old_email = new_email;
> new_email = NULL;
^ permalink raw reply
* [ANNOUNCE] GIT 1.6.2.2
From: Junio C Hamano @ 2009-04-02 22:36 UTC (permalink / raw)
To: git
The latest maintenance release GIT 1.6.2.2 is available at the
usual places:
http://www.kernel.org/pub/software/scm/git/
git-1.6.2.2.tar.{gz,bz2} (source tarball)
git-htmldocs-1.6.2.2.tar.{gz,bz2} (preformatted docs)
git-manpages-1.6.2.2.tar.{gz,bz2} (preformatted docs)
The RPM binary packages for a few architectures are found in:
RPMS/$arch/git-*-1.6.2.2-1.fc9.$arch.rpm (RPM)
Mostly documentation updates with a few bugfixes.
----------------------------------------------------------------
GIT v1.6.2.2 Release Notes
==========================
Fixes since v1.6.2.1
--------------------
* A longstanding confusing description of what --pickaxe option of
git-diff does has been clarified in the documentation.
* "git-blame -S" did not quite work near the commits that were given
on the command line correctly.
* "git diff --pickaxe-regexp" did not count overlapping matches
correctly.
* "git diff" did not feed files in work-tree representation to external
diff and textconv.
* "git-fetch" in a repository that was not cloned from anywhere said
it cannot find 'origin', which was hard to understand for new people.
* "git-format-patch --numbered-files --stdout" did not have to die of
incompatible options; it now simply ignores --numbered-files as no files
are produced anyway.
* "git-ls-files --deleted" did not work well with GIT_DIR&GIT_WORK_TREE.
* "git-read-tree A B C..." without -m option has been broken for a long
time.
* git-send-email ignored --in-reply-to when --no-thread was given.
* 'git-submodule add' did not tolerate extra slashes and ./ in the path it
accepted from the command line; it now is more lenient.
* git-svn misbehaved when the project contained a path that began with
two dashes.
* import-zips script (in contrib) did not compute the common directory
prefix correctly.
* miscompilation of negated enum constants by old gcc (2.9) affected the
codepaths to spawn subprocesses.
Many small documentation updates are included as well.
----------------------------------------------------------------
Changes since v1.6.2.1 are as follows:
Allan Caffee (1):
Documentation: update graph api example.
Brandon Casey (1):
git-branch: display "was sha1" on branch deletion rather than just "sha1"
Carlo Marcelo Arenas Belon (1):
documentation: update cvsimport description of "-r" for recent clone
Daniel Barkalow (1):
Give error when no remote is configured
Daniel Cheng (aka SDiZ) (1):
Fix bash completion in path with spaces
David Aguilar (1):
everyday: use the dashless form of git-init
David J. Mellor (12):
Documentation: minor grammatical fixes in git-archive.txt.
Documentation: reword the "Description" section of git-bisect.txt.
Documentation: minor grammatical fixes in git-blame.txt.
Documentation: minor grammatical fixes in git-branch.txt.
Documentation: reworded the "Description" section of git-bisect.txt.
Documentation: reword example text in git-bisect.txt.
Documentation: remove some uses of the passive voice in git-bisect.txt
Documentation: minor grammatical fixes and rewording in git-bundle.txt
Documentation: minor grammatical fixes in git-cat-file.txt
Documentation: minor grammatical fixes in git-check-attr.txt
Documentation: minor grammatical fix in git-check-ref-format.txt
Documentation: Remove spurious uses of "you" in git-bisect.txt.
Emil Sit (1):
test-lib: Clean up comments and Makefile.
Eric Wong (1):
git-svn: fix ls-tree usage with dash-prefixed paths
Holger Weiß (1):
Documentation: Remove an odd "instead"
Jeff King (3):
doc: clarify how -S works
ls-files: require worktree when --deleted is given
fix portability problem with IS_RUN_COMMAND_ERR
Johannes Schindelin (4):
rsync transport: allow local paths, and fix tests
Smudge the files fed to external diff and textconv
import-zips: fix thinko
mailmap: resurrect lower-casing of email addresses
Johannes Sixt (2):
Propagate --exec-path setting to external commands via GIT_EXEC_PATH
diff --no-index: Do not generate patch output if other output is requested
Junio C Hamano (6):
read-tree A B C: do not create a bogus index and do not segfault
Remove total confusion from git-fetch and git-push
blame: read custom grafts given by -S before calling setup_revisions()
Update draft release notes to 1.6.2.2
Update draft release notes to 1.6.2.2
GIT 1.6.2.2
Linus Torvalds (1):
close_sha1_file(): make it easier to diagnose errors
Michael J Gruber (2):
git submodule: Add test cases for git submodule add
git submodule: Fix adding of submodules at paths with ./, .. and //
Nico -telmich- Schottelius (1):
git-tag(1): add hint about commit messages
Nicolas Pitre (1):
avoid possible overflow in delta size filtering computation
René Scharfe (3):
diffcore-pickaxe: use memmem()
optimize compat/ memmem()
pickaxe: count regex matches only once
Shawn O. Pearce (1):
Increase the size of the die/warning buffer to avoid truncation
Stephen Boyd (1):
format-patch: --numbered-files and --stdout aren't mutually exclusive
Thomas Rast (4):
send-email: respect in-reply-to regardless of threading
send-email: test --no-thread --in-reply-to combination
Documentation: format-patch --root clarifications
bash completion: only show 'log --merge' if merging
^ permalink raw reply
* Re: [PATCH] mailmap: resurrect lower-casing of email addresses
From: Johannes Schindelin @ 2009-04-02 22:39 UTC (permalink / raw)
To: A Large Angry SCM; +Cc: git, gitster, Marius Storm-Olsen
In-Reply-To: <49D53ABF.80706@gmail.com>
Hi,
On Thu, 2 Apr 2009, A Large Angry SCM wrote:
> {I may be late to this change since I'm trying to catch up on the ML.]
> Johannes Schindelin wrote:
> > Commit 0925ce4(Add map_user() and clear_mailmap() to mailmap) broke the
> > lower-casing of email addresses. This mostly did not matter if your
> > .mailmap has only lower-case email addresses; However, we did not
> > require .mailmap to contain lowercase-only email addresses.
>
> What part of the email address is this going to lowercase? Only the domain
> name is case agnostic.
If that were true, I would get 10% emails less.
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH] mailmap: resurrect lower-casing of email addresses
From: Junio C Hamano @ 2009-04-02 22:42 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: A Large Angry SCM, git
In-Reply-To: <alpine.DEB.1.00.0904030039290.10279@pacific.mpi-cbg.de>
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
>> What part of the email address is this going to lowercase? Only the domain
>> name is case agnostic.
That is my understanding of RFC, too. Let's see where this mail goes to
find out how much more lenient the real world is ;-).
^ permalink raw reply
* Re: [PATCH] mailmap: resurrect lower-casing of email addresses
From: A Large Angry SCM @ 2009-04-02 22:58 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Johannes Schindelin, git
In-Reply-To: <7v63hmekyv.fsf@gitster.siamese.dyndns.org>
Junio C Hamano wrote:
> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
>
>>> What part of the email address is this going to lowercase? Only the domain
>>> name is case agnostic.
>
> That is my understanding of RFC, too. Let's see where this mail goes to
> find out how much more lenient the real world is ;-).
>
>
Many email providers/servers are lenient when it comes to case in the
local part of an email address (after all, they control the
interpretation) but not every provider/server is and the RFC is VERY
clear on this issue.
^ permalink raw reply
* Re: [PATCH] mailmap: resurrect lower-casing of email addresses
From: Johannes Schindelin @ 2009-04-02 23:08 UTC (permalink / raw)
To: A Large Angry SCM; +Cc: Junio C Hamano, git
In-Reply-To: <49D542FA.3070304@gmail.com>
Hi,
On Thu, 2 Apr 2009, A Large Angry SCM wrote:
> Junio C Hamano wrote:
> > Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> >
> > > > What part of the email address is this going to lowercase? Only the
> > > > domain
> > > > name is case agnostic.
> >
> > That is my understanding of RFC, too. Let's see where this mail goes to
> > find out how much more lenient the real world is ;-).
> >
> >
>
> Many email providers/servers are lenient when it comes to case in the
> local part of an email address (after all, they control the
> interpretation) but not every provider/server is and the RFC is VERY
> clear on this issue.
And in one of my projects it is _very_ clear that this strict
interpretation of the RFC, which does not matter in reality, _actively_
_hurts_.
In the alternative, can I ask you to adjust my .mailmap in your free time?
Thankyouverymuch,
Dscho
^ permalink raw reply
* Re: [PATCH] mailmap: resurrect lower-casing of email addresses
From: A Large Angry SCM @ 2009-04-02 23:17 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Junio C Hamano, git
In-Reply-To: <alpine.DEB.1.00.0904030107320.10279@pacific.mpi-cbg.de>
Johannes Schindelin wrote:
> Hi,
>
> On Thu, 2 Apr 2009, A Large Angry SCM wrote:
>
>> Junio C Hamano wrote:
>>> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
>>>
>>>>> What part of the email address is this going to lowercase? Only the
>>>>> domain
>>>>> name is case agnostic.
>>> That is my understanding of RFC, too. Let's see where this mail goes to
>>> find out how much more lenient the real world is ;-).
>>>
>>>
>> Many email providers/servers are lenient when it comes to case in the
>> local part of an email address (after all, they control the
>> interpretation) but not every provider/server is and the RFC is VERY
>> clear on this issue.
>
> And in one of my projects it is _very_ clear that this strict
> interpretation of the RFC, which does not matter in reality, _actively_
> _hurts_.
Care to provide actual justification for that statement.
> In the alternative, can I ask you to adjust my .mailmap in your free time?
_Your_ .mailmap file is your issue.
So which standards do you choose to follow and which do you choose to
ignore?
^ permalink raw reply
* Re: [PATCH] Allow setting default diff options via diff.defaultOptions
From: Keith Cascio @ 2009-04-03 0:04 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Jeff King, Junio C Hamano, git
In-Reply-To: <alpine.DEB.1.00.0903210415110.10279@pacific.mpi-cbg.de>
Johannes,
On Sat, 21 Mar 2009, Johannes Schindelin wrote:
> The idea is from Keith Cascio.
>
> Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
> ---
> I do not particularly like what this patch does, but I like
> the non-intrusiveness and conciseness of it.
Your patch does not provide a command line opt_out flag. Let me describe a
workflow situation and ask you how to handle it if the user were running your
patch. Let diff.defaultOptions = "-b". The user is getting closer to
submitting his patch and he wants to see patch output identical to what `git format-patch`
will produce. What command should he use?
`git format-patch --stdout master` ?
-- Keith
^ permalink raw reply
* Re: [PATCH 10/10] mergetool: use run_mergetool from git-mergetool-lib
From: David Aguilar @ 2009-04-03 1:54 UTC (permalink / raw)
To: Markus Heidelberg; +Cc: Charles Bailey, gitster, git
In-Reply-To: <200904022213.15173.markus.heidelberg@web.de>
On 0, Markus Heidelberg <markus.heidelberg@web.de> wrote:
> Charles Bailey, 02.04.2009:
> >
> > I think that it would be better if $status stayed as local as
> > possible. If run_mergetool returned the value of $status as its exit
> > code then the function will properly return whether the merge
> > succeeded or not.
> >
> > This way run_mergetool's clients can just use its exit code, without
> > having to know about a magic $status global variable.
>
> And shouldn't also check_unchanged() move from git-mergetool.sh to
> git-mergetool--lib.sh, since it is only used there?
> Huh, it seems as if some editors for difftool cannot work correctly
> currently, because this function is used, but defined in
> git-mergetool.sh.
Sounds good.
A patch is on the way:
- moves check_unchanged into mergetool--lib
- returns $status in run_mergetool
- updates mergetool to not rely on the global $status
--
David
^ permalink raw reply
* Re: [PATCH 2/3] mergetool-lib: specialize xxdiff options when in diff mode
From: David Aguilar @ 2009-04-03 1:56 UTC (permalink / raw)
To: Markus Heidelberg; +Cc: gitster, git
In-Reply-To: <200904022320.55334.markus.heidelberg@web.de>
On 0, Markus Heidelberg <markus.heidelberg@web.de> wrote:
> David Aguilar, 02.04.2009:
> > We don't need '-merged-file', 'save as', and the merge-status exit
> > code when in diff mode
>
> I guess the same as for xxdiff and kdiff3 also applies to opendiff,
> ecmerge and emerge. But since I don't have them installed, I'm not
> entirely sure not to break something.
> On the other hand it should be save, since they were just copied from
> git-mergetool without adjustment for diff use.
>
> Markus
>
I have opendiff on a mac at work so I'll give it a test there
and send a patch once it's working.
--
David
^ permalink raw reply
* [PATCH] mergetool-lib: refactor run_mergetool and check_unchanged
From: David Aguilar @ 2009-04-03 2:10 UTC (permalink / raw)
To: gitster; +Cc: charles, markus.heidelberg, git, David Aguilar
This moves run_mergetool and check_unchanged into mergetool--lib.
git-mergetool no longer uses the global $status variable and instead
checks the return value of run_mergetool.
Signed-off-by: David Aguilar <davvid@gmail.com>
---
git-mergetool--lib.sh | 21 +++++++++++++++++++--
git-mergetool.sh | 20 +-------------------
2 files changed, 20 insertions(+), 21 deletions(-)
diff --git a/git-mergetool--lib.sh b/git-mergetool--lib.sh
index 91d5453..06d261a 100644
--- a/git-mergetool--lib.sh
+++ b/git-mergetool--lib.sh
@@ -22,9 +22,25 @@ get_merge_tool_path () {
echo "$path"
}
-# Overridden in git-mergetool
check_unchanged () {
- true
+ if merge_mode; then
+ if test "$MERGED" -nt "$BACKUP"; then
+ status=0
+ else
+ while true; do
+ echo "$MERGED seems unchanged."
+ printf "Was the merge successful? [y/n] "
+ read answer < /dev/tty
+ case "$answer" in
+ y*|Y*) status=0; break ;;
+ n*|N*) status=1; break ;;
+ esac
+ done
+ fi
+ else
+ status=0
+ fi
+ return $status
}
valid_tool () {
@@ -213,4 +229,5 @@ run_mergetool () {
fi
;;
esac
+ return $status
}
diff --git a/git-mergetool.sh b/git-mergetool.sh
index 401c107..298b0a1 100755
--- a/git-mergetool.sh
+++ b/git-mergetool.sh
@@ -112,22 +112,6 @@ resolve_deleted_merge () {
done
}
-check_unchanged () {
- if test "$MERGED" -nt "$BACKUP" ; then
- status=0;
- else
- while true; do
- echo "$MERGED seems unchanged."
- printf "Was the merge successful? [y/n] "
- read answer < /dev/tty
- case "$answer" in
- y*|Y*) status=0; break ;;
- n*|N*) status=1; break ;;
- esac
- done
- fi
-}
-
checkout_staged_file () {
tmpfile=$(expr "$(git checkout-index --temp --stage="$1" "$2")" : '\([^ ]*\) ')
@@ -194,9 +178,7 @@ merge_file () {
base_present &&
present=true
- run_mergetool "$merge_tool" "$present"
-
- if test "$status" -ne 0; then
+ if ! run_mergetool "$merge_tool" "$present"; then
echo "merge of $MERGED failed" 1>&2
mv -- "$BACKUP" "$MERGED"
--
1.6.1.3
^ permalink raw reply related
* Re: Whitespace options
From: Joshua Juran @ 2009-04-03 2:15 UTC (permalink / raw)
To: git
In-Reply-To: <3C72F4A7-9B7A-44D0-B13D-FD534EB02C27@bitart.com>
On Apr 2, 2009, at 12:18 PM, Gerd Knops wrote:
> I think there should be a whitespace option that ignores lines that
> consists completely of whitespace vs lines with actual trailing
> whitespace preceded by non-whitespace.
+1
> The reason is that many editors (especially those supporting indent-
> based code folding) keep 'empty' lines at the current indentation
> level.
As do some users, out of personal preference.
Josh
^ permalink raw reply
* [PATCH] mergetool-lib: specialize opendiff options when in diff mode
From: David Aguilar @ 2009-04-03 2:16 UTC (permalink / raw)
To: gitster; +Cc: charles, markus.heidelberg, git, David Aguilar
We don't need the '-merged "$MERGED"' option when in diff mode.
Signed-off-by: David Aguilar <davvid@gmail.com>
---
git-mergetool--lib.sh | 8 ++++++--
1 files changed, 6 insertions(+), 2 deletions(-)
diff --git a/git-mergetool--lib.sh b/git-mergetool--lib.sh
index 06d261a..b8566b2 100644
--- a/git-mergetool--lib.sh
+++ b/git-mergetool--lib.sh
@@ -189,8 +189,12 @@ run_mergetool () {
"$merge_tool_path" "$LOCAL" "$REMOTE" \
-ancestor "$BASE" -merge "$MERGED" | cat
else
- "$merge_tool_path" "$LOCAL" "$REMOTE" \
- -merge "$MERGED" | cat
+ if merge_mode; then
+ "$merge_tool_path" "$LOCAL" "$REMOTE" \
+ -merge "$MERGED" | cat
+ else
+ "$merge_tool_path" "$LOCAL" "$REMOTE" | cat
+ fi
fi
check_unchanged
;;
--
1.6.1.3
^ permalink raw reply related
* Re: Whitespace options
From: Miles Bader @ 2009-04-03 2:39 UTC (permalink / raw)
To: Gerd Knops; +Cc: git
In-Reply-To: <3C72F4A7-9B7A-44D0-B13D-FD534EB02C27@bitart.com>
Gerd Knops <gerti-git@bitart.com> writes:
> The reason is that many editors (especially those supporting indent-
> based code folding) keep 'empty' lines at the current indentation
> level. git (with default settings) flags all those lines.
That sounds like very fragile behavior on the part of the editor -- it
sounds like they assume that all source code was created by their
editor, and will never be touched by any other tool...
-Miles
--
Suburbia: where they tear out the trees and then name streets after them.
^ permalink raw reply
* Re: [PATCH] mailmap: resurrect lower-casing of email addresses
From: Johannes Schindelin @ 2009-04-03 2:52 UTC (permalink / raw)
To: A Large Angry SCM; +Cc: Junio C Hamano, git
In-Reply-To: <49D54799.9010607@gmail.com>
Hi,
On Thu, 2 Apr 2009, A Large Angry SCM wrote:
> Johannes Schindelin wrote:
>
> > On Thu, 2 Apr 2009, A Large Angry SCM wrote:
> >
> > > Junio C Hamano wrote:
> > > > Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> > > >
> > > > > > What part of the email address is this going to lowercase?
> > > > > > Only the domain name is case agnostic.
> > > >
> > > > That is my understanding of RFC, too. Let's see where this mail
> > > > goes to find out how much more lenient the real world is ;-).
> > > >
> > > Many email providers/servers are lenient when it comes to case in
> > > the local part of an email address (after all, they control the
> > > interpretation) but not every provider/server is and the RFC is VERY
> > > clear on this issue.
> >
> > And in one of my projects it is _very_ clear that this strict
> > interpretation of the RFC, which does not matter in reality,
> > _actively_ _hurts_.
>
> Care to provide actual justification for that statement.
Well, I _did_! I have at least _one_ repository where the case
insensitive email addresses worked, and got fscked over, by having Git
change behavior behind my back!
> > In the alternative, can I ask you to adjust my .mailmap in your free
> > time?
>
> _Your_ .mailmap file is your issue.
>
> So which standards do you choose to follow and which do you choose to
> ignore?
You chose a rather inappropriate moment to start one of those damned
flamewars -- I am in the middle of some rather important day-job meeting,
plus two projects in the deadline-is-looming GSoC frenzy.
In case it was not clear yet: if I have to chose between following a
standard and reality that just took over, I will _always_ choose the
latter.
If you take this mail to start a flamewar for real (i.e. not answer to my
concerns, but point out that standard X says bla, and that everybody else
should just obey, oh, and fix their ways as of 20 years), please do remove
me from the Cc: list.
Ciao,
Dscho
^ permalink raw reply
* [RFC] GSoC Proposal v2:
From: P Baker @ 2009-04-03 3:15 UTC (permalink / raw)
To: git; +Cc: Johannes Schindelin, Shawn O. Pearce, Andreas Ericsson
See below for a revised project application. More comments would be
appreciated. Thanks to Shawn, Dscho and Andreas for already offering
some help!
Title: git-submodule for multiple, active developers on active trees
Abstract:
This project focuses on upgrading git-submodule to manage code created in
external projects in ways that allow users to safely branch and merge that
code without loss of data or routine merge conflicts. This will incorporate
some unfinished patches, but will also include making substantial changes to
the underlying code of git-submodule.
Content:
Today, git-submodule is a solid component designed to allow developers to
leverage the work of others by incorporating external code into a project.
However, as most core developers are not heavy users of the feature its
implementation is underdeveloped [1], which creates problems when it does not
act according to developers’ expectations based on the robustness of other git
features. This project would devote a summer of work to filling in the gaps so
that git-submodule contains the features necessary to fully exploit its
potential to track, update and edit external codebases incorporated into a
super-project.
Submodules are unique in their goal. As opposed to “remotes,” which also
incorporate external code into a project, submodules maintain the distinct
nature of code and separate projects’ histories. This is perfect for the
intended nature of “embedding foreign repositories in dedicated subdirectories
of the source tree.”[2] For example, managing plug-ins within a larger,
standalone project that depends on them is an important technique to leverage
others' work and shorten the development process made much more difficult by
the shortcomings of git-submodule and require laborious workarounds or
explicit manual content management.[3] Adding the most commonly requested
features would give current users a desired tool, boost git’s credibility by
providing a common feature among revision control systems, make the adoption
of git for new and existing projects easier and, as a result, likely boost
git’s overall usage.
This project will consist of several stages: an initial community based
design review and investigation of specific requirements; specifying and
documenting the planned changes; and writing, debugging and merging the code
and related tests. A few specific changes that this project will likely
include are:
*move objects of submodules into base .git/ directory
**This would accomplish two goals. It would protect submodules from being
overwritten, and implicitly, modified content from potentially being lost.
This can happen when a branch with a submodule is replaced by checking out a
branch of a super-project that does not contain the submodule. As well, this
would centralize submodule management into one location. The added benefits of
fully using git's ability to branch and merge submodules makes it worth adding
complexity in the .git directory to accomplish this. Basically, this would add
support for local branches of submodules.[4]
*make git-submodule help with merging
**Instead of issuing merge conflicts on updated submodule references, this
will allow submodules on default detached HEAD so that changes from the local
repo can be committed without first pulling changes from the shared
repository. This made 'submodules...unsuitable for active development'.[5]
Clearly losing this kind of functionality impairs the overall usability of git
and should be fixed. Essentially, this would enable branch and merging between
local and remote repositories.
*protect changes in local submodules when doing “git submodule update”
**This is similar to the previous point, in that changes need to be protected
or merged or warnings issued when updating the submodule. The potential to
lose work with no warning is a big no-no.
*prevent unintentional super-project push without previous submodule push
**A common mistake made when using git-submodule is to commit and push the
super-project, without first pushing the latest commits in the submodule. This
problem will require some brainstorming to find a good solution.
*make git submodules easy to remove
** Adding a submodule has UI, removing one should as well.[6] There shouldn't
have to be a tutorial on how to do it.[7]
These major changes are in addition to some bug-fixes which include: git
submodule summary should output to the pager by default; and finishing the
implementation of git submodule recurse [8]. The tentative timeline is:
End of May – Conclusively finish the public discussion regarding
features to be added to git-submodule
Beginning of June – work on git submodule remove as a way to become
familiar with the code and accomplish an "easy" first win.
Middle of June – move objects of submodules into base .git/ directory.
This should take up the majority of the month and will likely
constitute the major portion of contributed code for the summer.
Middle of July – make submodules deal with updated references, this is
the second key component of upgrading submodules for use on active
trees.
End of July – protect changes in local submodules during “git
submodule update”. This will interact with the previous work, and
might implicitly be solved by it, if not, it
Middle of August – if time permits, finish git submodule recurse.
This timeline should allow adequate flexibility while establishing deadlines
that ensure that the project will be completed in a timely and efficient
manner. Most development will need to occur within git-submodules.sh, without
changing much plumbing, however, other files might be affected by more
substantial changes.
While git-submodule is stable and operational, it has not seen much change
beyond bug-fixes. After reaching its current feature complete status, the last
time a feature of any novelty was included in a public release was August
2008. However, some work has already been started by different contributors
who have started patches, but not seen their inclusion into a public
release.[9][10] The project will incorporate and conclude these patches.
At the end of the project, one metric by which to evaluate its success will
be its acceptance in online communities. The final goal is to make git a
top-tier version control system in its management of external code
repositories. My main usage of git started as an intern when managing a summer
project that had many of the requirements that make git-submodule problematic:
built in a web application framework and dependent on plug-ins, some of which
were managed in SVN. Even though the Ruby on Rails community has popularized
the use of git-submodule to manage plug-ins, and quite a bit has been written
on the topic, a significant portion of explanations end either in frustration
or convoluted workarounds. Personally, the problems and confusing nature of
git-submodule led me to give up on it altogether, and manage the code and
updates to it by hand. The need for improvement is clearly indicated by the
frequency with which improvements are requested (for example, in the Git 2009
User Survey responses [11]).
I currently am finishing my sophomore year as an Electrical Engineer at the
University of Pennsylvania (and dual-majoring in the Wharton School of
Business). I started to develop professionally when I took a year off between
high school and college to work for a small firm in Silicon Valley, California
developing diagnostic imaging software for quality assurance and research on
their products. Last summer I developed a Ruby on Rails-based engine to test
user-designed investment strategies for QED Benchmark, a boutique hedge fund.
[1]http://article.gmane.org/gmane.comp.version-control.git/79167
[2]http://www.kernel.org/pub/software/scm/git/docs/git-submodule.html
[3]http://flavoriffic.blogspot.com/2008/05/managing-git-submodules-with-gitrake.html?showComment=1210125780000#c1605130977296198852
[4]http://marc.info/?l=git&m=121726233001151&w=2
[5]http://flavoriffic.blogspot.com/2008/05/managing-git-submodules-with-gitrake.html?showComment=1211380200000#c3897235118548537475
[6]See http://pitupepito.homelinux.org/?p=24, for an example of how
the current process is hard.
[7]http://git.or.cz/gitwiki/GitSubmoduleTutorial
[8]http://article.gmane.org/gmane.comp.version-control.git/69834
[9]http://marc.info/?l=git&m=121676896924019&w=2
[10]http://article.gmane.org/gmane.comp.version-control.git/88724/match=gitmodules
[11]
Thanks,
P Baker
^ permalink raw reply
* Re: [PATCH 0/5] Header includes cleanup
From: Christian Couder @ 2009-04-03 3:58 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Nathaniel P Dawson, Johannes Sixt, git
In-Reply-To: <7v8wmjk4p6.fsf@gitster.siamese.dyndns.org>
Le jeudi 2 avril 2009, Junio C Hamano a écrit :
> Christian Couder <chriscool@tuxfamily.org> writes:
> > Ok, so I suggest the following simple guiding principles:
> >
> > - git-compat-util.h or cache.h or builtin.h should always be the first
> > #include in C files,
> >
> > - header files should include other incude files if and only if the
> > other includes are needed to compile them,
>
> This is unclear.
>
> Long before I started touching git, I used to be religious about making
> header files self contained. For a header file frotz.h in the project, I
> used to insist that
>
> $ cat >1.c <<\EOF
> #include "frotz.h"
> EOF
> $ cc -Wall -c 1.c
>
> did not fail.
>
> Are you talking about that by "to compile them"?
Well, I wanted to say that for a header file frotz.h in the project:
$ cat >1.c <<\EOF
#include "cache.h"
#include "frotz.h"
EOF
$ cc -Wall -c 1.c
should not fail.
(Ok, in practice, let's say that something like:
$ cc -Wall -DSHA1_HEADER='<openssl/sha.h>' -c 1.c
should not fail.)
> I stopped doing that long time ago, partly because the rule was
> cumbersome to enforce, but primarily because it was not helping much in
> the larger picture.
>
> Such a rule, together with strict rules such as the order of including
> other header files in the header files themselves, may make life easier
> for programmers who touch .c files but never .h files, because they can
> include only the necessary .h files and in any order. But in practice,
> people need to touch both .h and .c files and when they need to include
> new system header files, they need to follow the inclusion order rule
> somewhere anyway---at that point, it does not matter much if the rule
> applies to only .h files or both .h and .c files.
>
> So for example, you cannot compile
>
> $ cat >1.c <<\EOF
> #include "revision.h"
> EOF
> $ cc -Wll -c 1.c
>
> in git.git project, but I do not think it is a problem.
I think it may become a problem if a header needs more headers to be
included before it, and those latter headers again need more headers and so
on.
The advantage of having and using "cache.h" is that things are quite simple.
You include cache.h and then a few more headers for special features you
need, and, here you go, you can code up something quite interesting without
worrying too much about includes. (Though the compilation time is perhaps a
little longer than it could be.)
If we loose this simplicity because we don't take care or for some
theoretical reason, then I think we have lost everything that really
matters.
A simple patch like this:
---------8<------------
$ gdiff
diff --git a/revision.h b/revision.h
index 5adfc91..495d7eb 100644
--- a/revision.h
+++ b/revision.h
@@ -3,6 +3,8 @@
#include "parse-options.h"
#include "grep.h"
+#include "diff.h"
+#include "commit.h"
#define SEEN (1u<<0)
#define UNINTERESTING (1u<<1)
---------8<------------
makes the following just work(tm):
$ cat >1.c <<\EOF
#include "cache.h"
#include "revision.h"
EOF
$ cc -Wall -DSHA1_HEADER='<openssl/sha.h>' -c 1.c
$
(By the way it's this kind of patches that I hoped would get posted first.)
> > - a header file should be included in a C file only if it is needed to
> > compile the C file (it is not ok to include it only because it includes
> > many other headers that are needed)
I should have said "a header file other than git-compat-util.h or cache.h
should be included ..."
> If that is the rule, perhaps the problem lies not in a .c program that
> includes such a .h header, but in the .h itself that includes many other
> header files.
It depends if the .h that includes many other header files does that for a
good reason or not.
> > - other than the above rules, it is ok to reduce the number of includes
> > as much as possible
> >
> > What do you think?
>
> What you did not write and I forgot to mention, which is a logical
> conclusion of the first rule, is that C files should not directly include
> common system header files such as unistd, sys/stat, etc.
Yeah, I forgot to restate that.
> There are exceptions to any rule. For example, inclusion of syslog.h in
> daemon.c is OK because most of the rest of the system does not even use
> syslog. If we later find a platform whose syslog.h has some funny
> inter-header dependencies, however, we will need to include it in the
> git-compat-util.h and resolve the dependencies there, like we do for
> other system header files.
Ok, I will state that too.
If you agree I will post a patch to "Documentation/CodingGuidelines" with
the above clarifications. (I can also post an improved version of my patch
to "revision.h".)
Thanks,
Christian.
> > Or perhaps Junio would prefer that you work on a C file by C file
> > basis? Like for example:
> >
> > "delete useless includes in 'builtin-diff-files.c'"
> > "delete useless includes in 'builtin-diff-index.c'"
>
> If the series does not involve .h file clean-up, then a series that
> consists of one patch per .c file would be easier to handle, I think.
^ permalink raw reply related
* Re: [PATCH 0/5] Header includes cleanup
From: Christian Couder @ 2009-04-03 4:14 UTC (permalink / raw)
To: Jeff King; +Cc: Junio C Hamano, Nathaniel P Dawson, Johannes Sixt, git
In-Reply-To: <20090402112705.GD14599@sigill.intra.peff.net>
Hi,
Le jeudi 2 avril 2009, Jeff King a écrit :
> On Wed, Apr 01, 2009 at 10:25:09PM -0700, Junio C Hamano wrote:
> > > - a header file should be included in a C file only if it is needed
> > > to compile the C file (it is not ok to include it only because it
> > > includes many other headers that are needed)
> >
> > If that is the rule, perhaps the problem lies not in a .c program that
> > includes such a .h header, but in the .h itself that includes many
> > other header files.
>
> If this were combined with splitting gigantic .h files (like cache.h)
> into smaller logical units, then we could in theory speed up
> recompilation times with make (we would also need to correctly track
> header dependencies, but gcc -M can do this fairly easily).
>
> But it does come at the price of actually having to consider which
> include files are necessary. I can't think of more than half a dozen
> times in the last year I have actually had to add a #include while
> working on a git .c file, mostly because everything and the kitchen sink
> is included by cache.h.
Yeah, I think the best feature of the actual design is the simplicity, and
that's why we don't have to add new #include very often. So let's keep this
simplicity by having and applying rules to keep things simple for the
developer.
> So I don't know if it is worth it.
I am not sure what you are talking about here, but if you mean that you
don't think it's worth splitting gigantic .h files (like cache.h) into
smaller logical units, then I agree.
Best regards,
Christian.
^ permalink raw reply
* Re: [RFC] GSoC Proposal v2:
From: Sverre Rabbelier @ 2009-04-03 4:22 UTC (permalink / raw)
To: P Baker; +Cc: git, Johannes Schindelin, Shawn O. Pearce, Andreas Ericsson
In-Reply-To: <526944450904022015n67be674dwfab5d3dc597c806b@mail.gmail.com>
Heya,
On Fri, Apr 3, 2009 at 05:15, P Baker <me@retrodict.com> wrote:
> See below for a revised project application. More comments would be
> appreciated. Thanks to Shawn, Dscho and Andreas for already offering
> some help!
In case you haven't noticed the announcement, please submit your
proposal for GSoC to http://socghop.appspot.com as soon as possible!
Thanks :).
--
Cheers,
Sverre Rabbelier
^ permalink raw reply
* Damned terrorists!!!
From: Nancy @ 2009-04-03 6:36 UTC (permalink / raw)
To: git
Are you in the city now? http://kj.goodnewsdigital.com/main.php
^ permalink raw reply
* [PATCH] NO_PERL support
From: Robin H. Johnson @ 2009-04-03 7:03 UTC (permalink / raw)
To: Git Mailing List
[-- Attachment #1.1: Type: text/plain, Size: 599 bytes --]
The attached patch adds NO_PERL to the build system, in the same fashion
as NO_TCLTK.
Effects:
- No perl-based scripts or code are installed:
$SCRIPT_PERL
git-instaweb
gitweb
git-cvsserver
git-svn
- git-add does NOT have interactive support.
- None of the tests for the disabled stuff gets run.
This patch has been a optional part of the Gentoo build of Git for a
full year now, originally introduced with v1.5.4.4.
--
Robin Hugh Johnson
Gentoo Linux Developer & Infra Guy
E-Mail : robbat2@gentoo.org
GnuPG FP : 11AC BA4F 4778 E3F6 E4ED F38E B27B 944E 3488 4E85
[-- Attachment #1.2: 20090402-git-1.6.2.2-noperl.patch --]
[-- Type: text/plain, Size: 12384 bytes --]
Implement 95% of the NO_PERL functionality, to build Git without any Perl
support, because some Gentoo users want a Git without any Perl whatesoever
(Gentoo bug #214168).
Remaining bits are doing configure.ac as well as git-remote usage in:
t5502-quickfetch.sh
t5512-ls-remote.sh
t5520-pull.sh
Signed-off-by: Robin H. Johnson <robbat2@gentoo.org>
Updated-by: Bernd Lommerzheim <bernd@lommerzheim.com>
Bugzilla-URL: http://bugs.gentoo.org/show_bug.cgi?id=214168
Notes: Ported from 20080423-git-1.5.5.1-noperl.patch
Notes: Ported from 20080322-git-1.5.4.5-noperl.patch
Notes: Ported from 20080528-git-1.5.6.1-noperl.patch
Notes: Ported from 20080626-git-1.5.6.1-noperl.patch and 20081123-git-1.6.0.4-noperl-cvsserver.patch
Notes: Ported from 20090126-git-1.6.1.1-noperl.patch
Notes: t3701-add-interactive.sh block added 2009/04/02 as it was missed, broke
testsuite with USE=-perl.
diff --git a/Makefile b/Makefile
index 0675c43..0adb2b5 100644
--- a/Makefile
+++ b/Makefile
@@ -139,6 +139,8 @@ all::
# Define NO_PERL_MAKEMAKER if you cannot use Makefiles generated by perl's
# MakeMaker (e.g. using ActiveState under Cygwin).
#
+# Define NO_PERL if you do not want Perl scripts at all.
+#
# Define NO_TCLTK if you do not want Tcl/Tk GUI.
#
# The TCL_PATH variable governs the location of the Tcl interpreter
@@ -277,6 +279,8 @@ SCRIPT_SH += git-stash.sh
SCRIPT_SH += git-submodule.sh
SCRIPT_SH += git-web--browse.sh
+SCRIPTS = $(patsubst %.sh,%,$(SCRIPT_SH))
+ifndef NO_PERL
SCRIPT_PERL += git-add--interactive.perl
SCRIPT_PERL += git-archimport.perl
SCRIPT_PERL += git-cvsexportcommit.perl
@@ -285,10 +289,11 @@ SCRIPT_PERL += git-cvsserver.perl
SCRIPT_PERL += git-relink.perl
SCRIPT_PERL += git-send-email.perl
SCRIPT_PERL += git-svn.perl
-
-SCRIPTS = $(patsubst %.sh,%,$(SCRIPT_SH)) \
- $(patsubst %.perl,%,$(SCRIPT_PERL)) \
- git-instaweb
+SCRIPTS += $(patsubst %.perl,%,$(SCRIPT_PERL)) \
+ git-instaweb
+else
+SCRIPT_PERL =
+endif
# Empty...
EXTRA_PROGRAMS =
@@ -335,7 +340,10 @@ BUILT_INS += git-whatchanged$X
ALL_PROGRAMS = $(PROGRAMS) $(SCRIPTS)
# what 'all' will build but not install in gitexecdir
-OTHER_PROGRAMS = git$X gitweb/gitweb.cgi
+OTHER_PROGRAMS = git$X
+ifndef NO_PERL
+OTHER_PROGRAMS += gitweb/gitweb.cgi
+endif
# Set paths to tools early so that they can be used for version tests.
ifndef SHELL_PATH
@@ -868,6 +876,10 @@ else
endif
endif
+ifdef NO_PERL
+ BASIC_CFLAGS += -DNO_PERL
+endif
+
ifdef ZLIB_PATH
BASIC_CFLAGS += -I$(ZLIB_PATH)/include
EXTLIBS += -L$(ZLIB_PATH)/$(lib) $(CC_LD_DYNPATH)$(ZLIB_PATH)/$(lib)
@@ -1067,6 +1079,11 @@ endif
ifeq ($(TCLTK_PATH),)
NO_TCLTK=NoThanks
endif
+ifeq ($(PERL_PATH),)
+NO_PERL=NoThanks
+export NO_PERL
+export NO_PERL_MAKEMAKER
+endif
QUIET_SUBDIR0 = +$(MAKE) -C # space to separate -C and subdir
QUIET_SUBDIR1 =
@@ -1142,7 +1159,9 @@ ifndef NO_TCLTK
$(QUIET_SUBDIR0)git-gui $(QUIET_SUBDIR1) gitexecdir='$(gitexec_instdir_SQ)' all
$(QUIET_SUBDIR0)gitk-git $(QUIET_SUBDIR1) all
endif
+ifndef NO_PERL
$(QUIET_SUBDIR0)perl $(QUIET_SUBDIR1) PERL_PATH='$(PERL_PATH_SQ)' prefix='$(prefix_SQ)' all
+endif
$(QUIET_SUBDIR0)templates $(QUIET_SUBDIR1)
please_set_SHELL_PATH_to_a_more_modern_shell:
@@ -1189,6 +1208,7 @@ $(patsubst %.sh,%,$(SCRIPT_SH)) : % : %.sh
chmod +x $@+ && \
mv $@+ $@
+ifndef NO_PERL
$(patsubst %.perl,%,$(SCRIPT_PERL)): perl/perl.mak
perl/perl.mak: GIT-CFLAGS perl/Makefile perl/Makefile.PL
@@ -1248,6 +1268,7 @@ git-instaweb: git-instaweb.sh gitweb/gitweb.cgi gitweb/gitweb.css
$@.sh > $@+ && \
chmod +x $@+ && \
mv $@+ $@
+endif # NO_PERL
configure: configure.ac
$(QUIET_GEN)$(RM) $@ $<+ && \
@@ -1455,9 +1476,12 @@ install: all
$(INSTALL) -d -m 755 '$(DESTDIR_SQ)$(bindir_SQ)'
$(INSTALL) -d -m 755 '$(DESTDIR_SQ)$(gitexec_instdir_SQ)'
$(INSTALL) $(ALL_PROGRAMS) '$(DESTDIR_SQ)$(gitexec_instdir_SQ)'
- $(INSTALL) git$X git-upload-pack$X git-receive-pack$X git-upload-archive$X git-shell$X git-cvsserver '$(DESTDIR_SQ)$(bindir_SQ)'
+ $(INSTALL) git$X git-upload-pack$X git-receive-pack$X git-upload-archive$X git-shell$X '$(DESTDIR_SQ)$(bindir_SQ)'
$(MAKE) -C templates DESTDIR='$(DESTDIR_SQ)' install
+ifndef NO_PERL
$(MAKE) -C perl prefix='$(prefix_SQ)' DESTDIR='$(DESTDIR_SQ)' install
+ $(INSTALL) git-cvsserver '$(DESTDIR_SQ)$(bindir_SQ)'
+endif
ifndef NO_TCLTK
$(MAKE) -C gitk-git install
$(MAKE) -C git-gui gitexecdir='$(gitexec_instdir_SQ)' install
@@ -1565,9 +1589,11 @@ clean:
$(RM) -r $(GIT_TARNAME) .doc-tmp-dir
$(RM) $(GIT_TARNAME).tar.gz git-core_$(GIT_VERSION)-*.tar.gz
$(RM) $(htmldocs).tar.gz $(manpages).tar.gz
- $(RM) gitweb/gitweb.cgi
$(MAKE) -C Documentation/ clean
+ifndef NO_PERL
+ $(RM) gitweb/gitweb.cgi
$(MAKE) -C perl clean
+endif
$(MAKE) -C templates/ clean
$(MAKE) -C t/ clean
ifndef NO_TCLTK
diff --git a/builtin-add.c b/builtin-add.c
index 08443f2..01e18a1 100644
--- a/builtin-add.c
+++ b/builtin-add.c
@@ -15,7 +15,9 @@ static const char * const builtin_add_usage[] = {
"git add [options] [--] <filepattern>...",
NULL
};
+#ifndef NO_PERL
static int patch_interactive, add_interactive;
+#endif
static int take_worktree_changes;
static void fill_pathspec_matches(const char **pathspec, char *seen, int specs)
@@ -158,6 +160,7 @@ static const char **validate_pathspec(int argc, const char **argv, const char *p
return pathspec;
}
+#ifndef NO_PERL
int interactive_add(int argc, const char **argv, const char *prefix)
{
int status, ac;
@@ -186,6 +189,7 @@ int interactive_add(int argc, const char **argv, const char *prefix)
free(args);
return status;
}
+#endif
static struct lock_file lock_file;
@@ -199,8 +203,10 @@ static struct option builtin_add_options[] = {
OPT__DRY_RUN(&show_only),
OPT__VERBOSE(&verbose),
OPT_GROUP(""),
+#ifndef NO_PERL
OPT_BOOLEAN('i', "interactive", &add_interactive, "interactive picking"),
OPT_BOOLEAN('p', "patch", &patch_interactive, "interactive patching"),
+#endif
OPT_BOOLEAN('f', "force", &ignored_too, "allow adding otherwise ignored files"),
OPT_BOOLEAN('u', "update", &take_worktree_changes, "update tracked files"),
OPT_BOOLEAN('N', "intent-to-add", &intent_to_add, "record only the fact that the path will be added later"),
@@ -252,10 +258,12 @@ int cmd_add(int argc, const char **argv, const char *prefix)
argc = parse_options(argc, argv, builtin_add_options,
builtin_add_usage, 0);
+#ifndef NO_PERL
if (patch_interactive)
add_interactive = 1;
if (add_interactive)
exit(interactive_add(argc, argv, prefix));
+#endif
git_config(add_config, NULL);
diff --git a/builtin-commit.c b/builtin-commit.c
index 46e649c..944f3ac 100644
--- a/builtin-commit.c
+++ b/builtin-commit.c
@@ -100,7 +100,9 @@ static struct option builtin_commit_options[] = {
OPT_GROUP("Commit contents options"),
OPT_BOOLEAN('a', "all", &all, "commit all changed files"),
OPT_BOOLEAN('i', "include", &also, "add specified files to index for commit"),
+#ifndef NO_PERL
OPT_BOOLEAN(0, "interactive", &interactive, "interactively add files"),
+#endif
OPT_BOOLEAN('o', "only", &only, "commit only specified files"),
OPT_BOOLEAN('n', "no-verify", &no_verify, "bypass pre-commit hook"),
OPT_BOOLEAN(0, "amend", &amend, "amend previous commit"),
@@ -223,6 +225,7 @@ static char *prepare_index(int argc, const char **argv, const char *prefix)
struct string_list partial;
const char **pathspec = NULL;
+#ifndef NO_PERL
if (interactive) {
interactive_add(argc, argv, prefix);
if (read_cache_preload(NULL) < 0)
@@ -230,6 +233,7 @@ static char *prepare_index(int argc, const char **argv, const char *prefix)
commit_style = COMMIT_AS_IS;
return get_index_file();
}
+#endif
if (*argv)
pathspec = get_pathspec(prefix, argv);
diff --git a/t/lib-git-svn.sh b/t/lib-git-svn.sh
index 67c431d..83a5535 100644
--- a/t/lib-git-svn.sh
+++ b/t/lib-git-svn.sh
@@ -9,6 +9,12 @@ then
test_done
exit
fi
+if test -n "$NO_PERL"
+then
+ test_expect_success 'skipping git-svn tests, NO_PERL defined' :
+ test_done
+ exit
+fi
GIT_DIR=$PWD/.git
GIT_SVN_DIR=$GIT_DIR/svn/git-svn
diff --git a/t/t5505-remote.sh b/t/t5505-remote.sh
index eb63718..e3bcf20 100755
--- a/t/t5505-remote.sh
+++ b/t/t5505-remote.sh
@@ -3,6 +3,12 @@
test_description='git remote porcelain-ish'
. ./test-lib.sh
+if test -n "$NO_PERL"
+then
+ test_expect_success 'skipping git-cvsimport tests, NO_PERL defined' :
+ test_done
+ exit
+fi
setup_repository () {
mkdir "$1" && (
diff --git a/t/t7501-commit.sh b/t/t7501-commit.sh
index b4e2b4d..2e74ce5 100755
--- a/t/t7501-commit.sh
+++ b/t/t7501-commit.sh
@@ -38,7 +38,7 @@ test_expect_success \
"echo King of the bongo >file &&
test_must_fail git commit -m foo -a file"
-test_expect_success \
+[ -z "$NO_PERL" ] && test_expect_success \
"using paths with --interactive" \
"echo bong-o-bong >file &&
! (echo 7 | git commit -m foo --interactive file)"
@@ -119,7 +119,7 @@ test_expect_success \
"echo 'gak' >file && \
git commit -m 'author' --author 'Rubber Duck <rduck@convoy.org>' -a"
-test_expect_success \
+[ -z "$NO_PERL" ] && test_expect_success \
"interactive add" \
"echo 7 | git commit --interactive | grep 'What now'"
diff --git a/t/t9001-send-email.sh b/t/t9001-send-email.sh
index cb3d183..1d5355d 100755
--- a/t/t9001-send-email.sh
+++ b/t/t9001-send-email.sh
@@ -2,6 +2,12 @@
test_description='git send-email'
. ./test-lib.sh
+if test -n "$NO_PERL"
+then
+ test_expect_success 'skipping git-send-email tests, NO_PERL defined' :
+ test_done
+ exit
+fi
PROG='git send-email'
test_expect_success \
diff --git a/t/t9200-git-cvsexportcommit.sh b/t/t9200-git-cvsexportcommit.sh
index 245a7c3..6cd779a 100755
--- a/t/t9200-git-cvsexportcommit.sh
+++ b/t/t9200-git-cvsexportcommit.sh
@@ -13,6 +13,12 @@ then
test_done
exit
fi
+if test -n "$NO_PERL"
+then
+ test_expect_success 'skipping git-cvsexportcommit tests, NO_PERL defined' :
+ test_done
+ exit
+fi
CVSROOT=$(pwd)/cvsroot
CVSWORK=$(pwd)/cvswork
diff --git a/t/t9400-git-cvsserver-server.sh b/t/t9400-git-cvsserver-server.sh
index 6a37f71..84a0d31 100755
--- a/t/t9400-git-cvsserver-server.sh
+++ b/t/t9400-git-cvsserver-server.sh
@@ -17,6 +17,12 @@ then
test_done
exit
fi
+if test -n "$NO_PERL"
+then
+ test_expect_success 'skipping git-cvsserver tests, NO_PERL defined' :
+ test_done
+ exit
+fi
perl -e 'use DBI; use DBD::SQLite' >/dev/null 2>&1 || {
test_expect_success 'skipping git-cvsserver tests, Perl SQLite interface unavailable' :
test_done
diff --git a/t/t9500-gitweb-standalone-no-errors.sh b/t/t9500-gitweb-standalone-no-errors.sh
index 6ed10d0..d4580a4 100755
--- a/t/t9500-gitweb-standalone-no-errors.sh
+++ b/t/t9500-gitweb-standalone-no-errors.sh
@@ -72,6 +72,13 @@ safe_chmod () {
}
. ./test-lib.sh
+if test -n "$NO_PERL"
+then
+ test_expect_success 'skipping gitweb-standalone-no-errors tests, NO_PERL defined' :
+ test_done
+ exit
+fi
+
perl -MEncode -e 'decode_utf8("", Encode::FB_CROAK)' >/dev/null 2>&1 || {
test_expect_success 'skipping gitweb tests, perl version is too old' :
diff --git a/t/t9600-cvsimport.sh b/t/t9600-cvsimport.sh
index d2379e7..75bf178 100755
--- a/t/t9600-cvsimport.sh
+++ b/t/t9600-cvsimport.sh
@@ -16,6 +16,12 @@ then
test_done
exit
fi
+if test -n "$NO_PERL"
+then
+ test_expect_success 'skipping git-cvsimport tests, NO_PERL defined' :
+ test_done
+ exit
+fi
cvsps_version=`cvsps -h 2>&1 | sed -ne 's/cvsps version //p'`
case "$cvsps_version" in
diff a/t/t3701-add-interactive.sh b/t/t3701-add-interactive.sh
--- a/t/t3701-add-interactive.sh 2009-04-02 14:26:45.000000000 -0700
+++ b/t/t3701-add-interactive.sh 2009-04-02 23:06:20.543358154 -0700
@@ -3,6 +3,13 @@
test_description='add -i basic tests'
. ./test-lib.sh
+if test -n "$NO_PERL"
+then
+ test_expect_success 'skipping add-interactive tests, NO_PERL defined' :
+ test_done
+ exit
+fi
+
test_expect_success 'setup (initial)' '
echo content >file &&
git add file &&
[-- Attachment #2: Type: application/pgp-signature, Size: 330 bytes --]
^ permalink raw reply related
* [PATCHv2 0/2] git remote update: New option --prune (-p)
From: Finn Arne Gangstad @ 2009-04-03 9:00 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Jeff King, demerphq, git
In-Reply-To: <7vljqieq1r.fsf@gitster.siamese.dyndns.org>
On Thu, Apr 02, 2009 at 01:52:48PM -0700, Junio C Hamano wrote:
> Finn Arne Gangstad <finnag@pvv.org> writes:
>
> > On Thu, Apr 02, 2009 at 11:06:56AM -0700, Junio C Hamano wrote:
> >> [...]
> >>
> >> I gave the patch an only cursory look, so I wouldn't comment on the
> >> implementation; two things I would look at in the code would be if it
> >> makes two connections to the remote to learn the same information (which
> >> would be bad)
> >
> > How bad?
>
> I'd say only "could be improved later" bad.
Ok. I split the patch into two to make it easier to review.
1/2 just splits out prune_remote() as a separate function, and does not
change any behavior.
2/2 adds the new option to remote update.
Finn Arne Gangstad (2):
builtin-remote.c: Split out prune_remote as a separate function.
git remote update: New option --prune
Documentation/git-remote.txt | 4 ++-
builtin-remote.c | 76 ++++++++++++++++++++++++++----------------
2 files changed, 50 insertions(+), 30 deletions(-)
- Finn Arne
^ permalink raw reply
* [PATCHv2 1/2] builtin-remote.c: Split out prune_remote as a separate function.
From: Finn Arne Gangstad @ 2009-04-03 9:02 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Jeff King, demerphq, git
In-Reply-To: <20090403090036.GA23955@pvv.org>
prune_remote will be used in update(), so this function was split
out to avoid code duplication.
Signed-off-by: Finn Arne Gangstad <finnag@pvv.org>
---
builtin-remote.c | 56 +++++++++++++++++++++++++++++------------------------
1 files changed, 31 insertions(+), 25 deletions(-)
diff --git a/builtin-remote.c b/builtin-remote.c
index 9ef846f..9804d6c 100644
--- a/builtin-remote.c
+++ b/builtin-remote.c
@@ -26,6 +26,7 @@ static const char * const builtin_remote_usage[] = {
static int verbose;
static int show_all(void);
+static int prune_remote(const char *remote, int dry_run);
static inline int postfixcmp(const char *string, const char *postfix)
{
@@ -1128,46 +1129,51 @@ static int prune(int argc, const char **argv)
OPT__DRY_RUN(&dry_run),
OPT_END()
};
- struct ref_states states;
- const char *dangling_msg;
argc = parse_options(argc, argv, options, builtin_remote_usage, 0);
if (argc < 1)
usage_with_options(builtin_remote_usage, options);
- dangling_msg = (dry_run
- ? " %s will become dangling!\n"
- : " %s has become dangling!\n");
+ for (; argc; argc--, argv++)
+ result |= prune_remote(*argv, dry_run);
- memset(&states, 0, sizeof(states));
- for (; argc; argc--, argv++) {
- int i;
+ return result;
+}
- get_remote_ref_states(*argv, &states, GET_REF_STATES);
+static int prune_remote(const char *remote, int dry_run)
+{
+ int result = 0;
+ struct ref_states states;
+ const char *dangling_msg = dry_run
+ ? " %s will become dangling!\n"
+ : " %s has become dangling!\n";
- if (states.stale.nr) {
- printf("Pruning %s\n", *argv);
- printf("URL: %s\n",
- states.remote->url_nr
- ? states.remote->url[0]
- : "(no URL)");
- }
+ memset(&states, 0, sizeof(states));
+ int i;
- for (i = 0; i < states.stale.nr; i++) {
- const char *refname = states.stale.items[i].util;
+ get_remote_ref_states(remote, &states, GET_REF_STATES);
- if (!dry_run)
- result |= delete_ref(refname, NULL, 0);
+ if (states.stale.nr) {
+ printf("Pruning %s\n", remote);
+ printf("URL: %s\n",
+ states.remote->url_nr
+ ? states.remote->url[0]
+ : "(no URL)");
+ }
- printf(" * [%s] %s\n", dry_run ? "would prune" : "pruned",
- abbrev_ref(refname, "refs/remotes/"));
- warn_dangling_symref(dangling_msg, refname);
- }
+ for (i = 0; i < states.stale.nr; i++) {
+ const char *refname = states.stale.items[i].util;
- free_remote_ref_states(&states);
+ if (!dry_run)
+ result |= delete_ref(refname, NULL, 0);
+
+ printf(" * [%s] %s\n", dry_run ? "would prune" : "pruned",
+ abbrev_ref(refname, "refs/remotes/"));
+ warn_dangling_symref(dangling_msg, refname);
}
+ free_remote_ref_states(&states);
return result;
}
--
1.6.2.1.471.gdeb91.dirty
^ permalink raw reply related
* [PATCHv2 2/2] git remote update: New option --prune
From: Finn Arne Gangstad @ 2009-04-03 9:03 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Jeff King, demerphq, git
In-Reply-To: <20090403090036.GA23955@pvv.org>
With the --prune (or -p) option, git remote update will also prune
all the remotes that it fetches. Previously, you had to do a manual
git remote prune <remote> for each of the remotes you wanted to
prune, and this could be tedious with many remotes.
A single command will now update a set of remotes, and remove all
stale branches: git remote update -p [group]
Signed-off-by: Finn Arne Gangstad <finnag@pvv.org>
---
Documentation/git-remote.txt | 4 +++-
builtin-remote.c | 20 ++++++++++++++++----
2 files changed, 19 insertions(+), 5 deletions(-)
diff --git a/Documentation/git-remote.txt b/Documentation/git-remote.txt
index c9c0e6f..0b6e67d 100644
--- a/Documentation/git-remote.txt
+++ b/Documentation/git-remote.txt
@@ -16,7 +16,7 @@ SYNOPSIS
'git remote set-head' <name> [-a | -d | <branch>]
'git remote show' [-n] <name>
'git remote prune' [-n | --dry-run] <name>
-'git remote update' [group]
+'git remote update' [-p | --prune] [group]
DESCRIPTION
-----------
@@ -125,6 +125,8 @@ the configuration parameter remotes.default will get used; if
remotes.default is not defined, all remotes which do not have the
configuration parameter remote.<name>.skipDefaultUpdate set to true will
be updated. (See linkgit:git-config[1]).
++
+With `--prune` option, prune all the remotes that are updated.
DISCUSSION
diff --git a/builtin-remote.c b/builtin-remote.c
index 9804d6c..c8e5b17 100644
--- a/builtin-remote.c
+++ b/builtin-remote.c
@@ -15,7 +15,7 @@ static const char * const builtin_remote_usage[] = {
"git remote set-head <name> [-a | -d | <branch>]",
"git remote show [-n] <name>",
"git remote prune [-n | --dry-run] <name>",
- "git remote [-v | --verbose] update [group]",
+ "git remote [-v | --verbose] update [-p | --prune] [group]",
NULL
};
@@ -1210,10 +1210,18 @@ static int get_remote_group(const char *key, const char *value, void *cb)
static int update(int argc, const char **argv)
{
- int i, result = 0;
+ int i, result = 0, prune = 0;
struct string_list list = { NULL, 0, 0, 0 };
static const char *default_argv[] = { NULL, "default", NULL };
+ struct option options[] = {
+ OPT_GROUP("update specific options"),
+ OPT_BOOLEAN('p', "prune", &prune,
+ "prune remotes after fecthing"),
+ OPT_END()
+ };
+ argc = parse_options(argc, argv, options, builtin_remote_usage,
+ PARSE_OPT_KEEP_ARGV0);
if (argc < 2) {
argc = 2;
argv = default_argv;
@@ -1228,8 +1236,12 @@ static int update(int argc, const char **argv)
if (!result && !list.nr && argc == 2 && !strcmp(argv[1], "default"))
result = for_each_remote(get_one_remote_for_update, &list);
- for (i = 0; i < list.nr; i++)
- result |= fetch_remote(list.items[i].string);
+ for (i = 0; i < list.nr; i++) {
+ int err = fetch_remote(list.items[i].string);
+ result |= err;
+ if (!err && prune)
+ result |= prune_remote(list.items[i].string, 0);
+ }
/* all names were strdup()ed or strndup()ed */
list.strdup_strings = 1;
--
1.6.2.1.471.gdeb91.dirty
^ 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