* Re: [PATCH] Use dashless git commands in setgitperms.perl
From: Todd Zullinger @ 2008-09-20 0:48 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git
In-Reply-To: <gb1ej9$bg2$1@ger.gmane.org>
[-- Attachment #1: Type: text/plain, Size: 1233 bytes --]
Jakub Narebski wrote:
> Todd Zullinger wrote:
>
>> # To save permissions/ownership data, place this script in your .git/hooks
>> # directory and enable a `pre-commit` hook with the following lines:
>> # #!/bin/sh
>> -# SUBDIRECTORY_OK=1 . git-sh-setup
>> +# SUBDIRECTORY_OK=1 . git sh-setup
>> # $GIT_DIR/hooks/setgitperms.perl -r
>> #
>> # To restore permissions/ownership data, place this script in your .git/hooks
>> # directory and enable a `post-merge` and `post-checkout` hook with the
>> # following lines:
>> # #!/bin/sh
>> -# SUBDIRECTORY_OK=1 . git-sh-setup
>> +# SUBDIRECTORY_OK=1 . git sh-setup
>> # $GIT_DIR/hooks/setgitperms.perl -w
>> #
>
> The rest is probably O.K., but I don't think this change is good one.
I don't see git-sh-setup in /usr/bin with a default install of git
1.6, so without this change, wouldn't the comments be suggesting a
potentially broken hook configuration?
--
Todd OpenPGP -> KeyID: 0xBEAF0CE3 | URL: www.pobox.com/~tmz/pgp
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Suppose I were a member of Congress, and suppose I were an idiot. But,
I repeat myself.
-- Mark Twain
[-- Attachment #2: Type: application/pgp-signature, Size: 542 bytes --]
^ permalink raw reply
* Re: [EGIT] Checking out signed tags fails
From: Shawn O. Pearce @ 2008-09-20 0:26 UTC (permalink / raw)
To: Jonas Fonseca; +Cc: Jonas Flodddn, git
In-Reply-To: <2c6b72b30809161148p2b4ce08fh32ff5717ca85e773@mail.gmail.com>
Jonas Fonseca <jonas.fonseca@gmail.com> wrote:
> On Tue, Sep 16, 2008 at 14:58, Jonas Flodén <jonas.floden@gmail.com> wrote:
> > When trying to check-out a signed tag I get the following Error:
> > Unable to switch branches
> >
> > Reason:
> > Mapping commit: refs/tags/v1.3.1.1
> >
> > And in details:
> > Object XXX is not a commit.
> >
> > The object ID shown is actually the id for the tag object and not the
> > tagged commit.
> >
> > This was tested with the latest master. It seemed commit 1f460e2 (Tests
> > and fixes for dereferencing tags in Repository.resolve(), 2008-09-12)
> > would fix it, but it didn't.
>
> The fixes are only for the code path where reference expressions needs
> to be resolved. From what I understand, the problem you have
> encountered is due to resolve() falling back to using resolveSimple()
> which doesn't dereference any tags. Perhaps EGit could postfix ^{} or
> ^{commit} to the tag name before calling mapCommit(), or whatever it
> uses?
Yea, a ^{} is missing somwhere... this is now in the issue tracker.
I'm behind and probably won't look at it more this week, but its
probably a simple thing in the checkout UI.
--
Shawn.
^ permalink raw reply
* Re: [RFC PATCH] Documentation: add manpage about workflows
From: Santi Béjar @ 2008-09-20 0:22 UTC (permalink / raw)
To: Thomas Rast; +Cc: git, Junio C Hamano
In-Reply-To: <1221147585-5695-1-git-send-email-trast@student.ethz.ch>
On Thu, Sep 11, 2008 at 5:39 PM, Thomas Rast <trast@student.ethz.ch> wrote:
> This attempts to make a manpage about workflows that is both handy to
> point people at it and as a beginner's introduction.
>
> Signed-off-by: Thomas Rast <trast@student.ethz.ch>
> ---
> Documentation/Makefile | 2 +-
> Documentation/gitworkflows.txt | 326 +
+++++++++++++++++++++++++++++++++++++++
It should be linked/advertised from other pages (git, tutorial, everyday?)
> diff --git a/Documentation/gitworkflows.txt b/Documentation/gitworkflows.txt
> new file mode 100644
> index 0000000..3462000
> --- /dev/null
> +++ b/Documentation/gitworkflows.txt
[...]
> +To achieve this, try to commit your new work at least every couple
> +hours. You can always go back and edit the commits with `git rebase
> +--interactive` to further improve the history before you publish it.
I do not agree with this. I don´t much differences between a big patch
and the same patch divided randomly.
To achieve this, try to commit when you are minimally satisfied with
the new code or before large changes. You can always go back and edit
the commits with `git rebase --interactive` to further improve the
history before you publish it, or you could split a big patch as is
explained in gitlink:git-stash.
> +
> +
> +MANAGING BRANCHES
> +-----------------
> +
> +In the following, we will assume there are 'developers', 'testers' and
> +'users'. Even if the "Testers" are actually an automated test suite
> +and all "Users" are developers themselves, try to think in these terms
"Testers" -> 'testers', ...
> +as you follow a software change through its life cycle.
> +
> +Usually a change evolves in a few steps:
> +
> +* The developers implement a few iterations until it "seems to work".
> +
> +* The testers play with it, report bugs, test the fixes, eventually
> + clearing the change for stable releases.
> +
> +* As the users work with the new feature, they report bugs which will
> + have to be fixed.
> +
> +In the following sections we discuss some problems that arise from
> +such a "change flow", and how to solve them with Git.
> +
> +We consider a fictional project with (supported) stable branch
> +'maint', main testing/development branch 'master' and "bleeding edge"
> +branch 'next'. We collectively call these three branches 'main
> +branches'.
You mention the next branch but it is not explained.
> +
> +
> +Merging upwards
> +~~~~~~~~~~~~~~~
> +
> +Since Git is quite good at merges, one should try to use them to
> +propagate changes. For example, if a bug is fixed, you would want to
> +apply the corresponding fix to all main branches.
> +
> +A quick moment of thought reveals that you cannot do this by merging
> +"downwards" to older releases, since that would merge 'all' changes.
all development changes
> +Hence the following:
> +
> +.Merge upwards
> +[caption="Rule: "]
> +=====================================
> +Always commit your fixes to the oldest supported branch that require
> +them. Then (periodically) merge the main branches upwards into each
> +other.
> +=====================================
> +
> +This gives a very controlled flow of fixes. If you notice that you
> +have applied a fix to e.g. 'master' that is also required in 'maint',
> +you will need to cherry-pick it (using linkgit:git-cherry-pick[1])
> +downwards. This will happen a few times and is nothing to worry about
> +unless you do it all the time.
> +
> +
> +Topic branches
> +~~~~~~~~~~~~~~
> +
> +Any nontrivial feature will require several patches to implement, and
> +may get extra bugfixes or improvements during its lifetime. If all
> +such commits were in one long linear history chain (e.g. if they were
> +all committed directly to, 'master'), it becomes very hard to see how
> +they belong together.
> +
> +The key concept here is "topic branches". The name is pretty self
> +explanatory, with a minor caveat that comes from the "merge upwards"
> +rule above:
> +
> +.Topic branches
> +[caption="Rule: "]
> +=====================================
> +Make a side branch for every topic. Fork it off at the oldest main
> +branch that you will eventually want to merge it into.
> +=====================================
> +
> +Many things can then be done very naturally:
> +
> +* To get the feature/bugfix into a main branch, simply merge it. If
> + the topic has evolved further in the meantime, merge again.
> +
> +* If you find you need new features from an 'other' branch to continue
... from the branch 'other' to continue
> + working on your topic, merge 'other' to 'topic'. (However, do not
> + do this "just habitually", see below.)
> +
> +* If you find you forked off the wrong branch and want to move it
> + "back in time", use linkgit:git-rebase[1].
> +
> +Note that the last two points clash: a topic that has been merged
> +elsewhere should not be rebased. See the section on RECOVERING FROM
> +UPSTREAM REBASE in linkgit:git-rebase[1].
> +
> +We should point out that "habitually" (regularly for no real reason)
> +merging a main branch into your topics--and by extension, merging
> +anything upstream into anything downstream on a regular basis--is
> +frowned upon:
> +
> +.Merge to downstream only at well-defined points
> +[caption="Rule: "]
> +=====================================
> +Do not merge to downstream except:
> +
> +* with a good reason (such as upstream API changes that affect you), or
> +
> +* at well-defined points such as when an upstream release has been tagged.
Do not merge to downstream except with a good reasons:
* API changes that affect you branch
* your branch no longer merges cleanly
* when your branch is way not up-to-date.
And mainly at well-defined points, such as when an upstream release
has been tagged, preferably stable release.
> +=====================================
> +
> +Otherwise, the many resulting small merges will greatly clutter up
> +history. Anyone who later investigates the history of a file will
> +have to find out whether that merge affected the topic in
> +development. Linus hates it. An upstream might even inadvertently be
> +merged into a "more stable" branch. And so on.
Yes, the main point is that Linus hates it :-)
> +
> +
> +Integration branches
> +~~~~~~~~~~~~~~~~~~~~
> +
> +If you followed the last paragraph, you will now have many small topic
> +branches, and occasionally wonder how they interact. Perhaps the
> +result of merging them does not even work? But on the other hand, we
> +want to avoid merging them anywhere "stable" because such merges
> +cannot easily be undone.
> +
> +The solution, of course, is to make a merge that we can undo: merge
> +into a throw-away branch.
> +
> +.Integration branches
> +[caption="Rule: "]
> +=====================================
> +To test the interaction of several topics, merge them into a
> +throw-away branch.
> +=====================================
> +
> +If you make it (very) clear that this branch is going to be deleted
> +right after the testing, you can even publish this branch, for example
> +to give the testers a chance to work with it, or other developers a
> +chance to see if their in-progress work will be compatible.
> +
> +
> +SHARING WORK
> +------------
> +
> +After the last section, you should know how to manage topics. In
> +general, you will not be the only person working on the project, so
> +you will have to share your work.
> +
> +Roughly speaking, there are two important workflows. Their
> +distinguishing mark is whether they can be used to propagate merges.
and one keeps the branch history while the other rewrite it.
> +Medium to large projects will typically employ some mixture of the
> +two:
I would remove this.
The different actors share their work as:
> +
> +* "Upstream" in the most general sense 'pushes' changes to the
> + repositor(ies) holding the main history. Everyone can 'pull' from
> + there to stay up to date.
s/repositor(ies)/repository/
And:
She pull from her (trusted) downstreams, and applies the patches from
the others.
> +
> +* Frequent contributors, subsystem maintainers, etc. may use push/pull
> + to send their changes upstream.
?
Maybe:
* (Trusted) Downstreams act like the Upstreams but publish their
changes in their own repository.
> +
> +* The rest -- typically anyone more than one or two levels away from the
> + main maintainer -- send patches by mail.
> +
> +None of these boundaries are sharp, so find out what works best for
> +you.
> +
> +
> +Push/pull
> +~~~~~~~~~
> +
> +There are three main tools that can be used for this:
> +
> +* linkgit:git-push[1] copies your branches to a remote repository,
> + usually to one that can be read by all involved parties;
> +
> +* linkgit:git-fetch[1] that copies remote branches to your repository;
> + and
> +
> +* linkgit:git-pull[1] that is fetch and merge in one go.
> +
> +Note the last point. Do 'not' use 'git-pull' unless you actually want
> +to merge the remote branch.
No need to repeat what is explained in the tutorial.
> +
> +Getting changes out is easy:
> +
> +.Push/pull: Publishing branches/topics
> +[caption="Recipe: "]
> +=====================================
> +`git push <remote> <branch>` and tell everyone where they can fetch
> +from.
> +=====================================
> +
> +You will still have to tell people by other means, such as mail. (Git
s/tell/inform/
> +provides the linkgit:request-pull[1] to send preformatted pull
> +requests to upstream maintainers to simplify this task.)
> +
> +If you just want to get the newest copies of the main branches,
> +staying up to date is easy too:
> +
> +.Push/pull: Staying up to date
> +[caption="Recipe: "]
> +=====================================
> +Use `git fetch <remote>` or `git remote update` to stay up to date.
> +=====================================
> +
> +Then simply fork your topic branches from the stable remotes as
> +explained earlier.
> +
In tutorial.txt. And it applies to everybody (upstream, contributors,...)
> +If you are a maintainer and would like to merge other people's topic
> +branches to the main branches, they will typically send a request to
> +do so by mail. Such a request might say
> +
> +-------------------------------------
> +Please pull from
> + git://some.server.somewhere/random/repo.git mytopic
> +-------------------------------------
> +
> +In that case, 'git-pull' can do the fetch and merge in one go, as
> +follows.
> +
> +.Push/pull: Merging remote topics
> +[caption="Recipe: "]
> +=====================================
> +`git pull <url> <branch>`
> +=====================================
> +
In tutorial. I think they are well explained in the tutorial. No need
to repeat it here. You could just mentions the tools and the recipies.
> +Occasionally, the maintainer may get merge conflicts when he tries to
> +pull changes from downstream. In this case, he can ask downstream to
> +do the merge and resolve the conflicts themselves (perhaps they will
> +know better how to react). It is one of the rare cases where
> +downstream 'should' merge from upstream.
> +
> +
> +format-patch/am
> +~~~~~~~~~~~~~~~
> +
> +If you are a contributor that sends changes upstream in the form of
> +emails, you should use topic branches as usual (see above). Then use
> +linkgit:git-format-patch[1] to generate the corresponding emails
> +(highly recommended over manually formatting them because it makes the
> +maintainer's life easier).
> +
> +.format-patch/am: Publishing branches/topics
> +[caption="Recipe: "]
> +=====================================
> +`git format-patch -M upstream..topic` and send out the resulting files.
> +=====================================
> +
> +See the linkgit:git-format-patch[1] manpage for further usage notes.
> +Also you should be aware that the maintainer may impose further
> +restrictions, such as "Signed-off-by" requirements.
the further restrictions are not only for git-format-patch users.
> +
> +If the maintainer tells you that your patch no longer applies to the
> +current upstream, you will have to rebase your topic (you cannot use a
> +merge because you cannot format-patch merges):
> +
> +.format-patch/am: Keeping topics up to date
> +[caption="Recipe: "]
> +=====================================
> +`git rebase upstream`
> +=====================================
git rebase <upstream>
> +
> +You can then fix the conflicts during the rebase. Presumably you have
> +not published your topic other than by mail, so rebasing it is not a
> +problem.
> +
> +If you receive such a patch (as maintainer, or perhaps reader of the
as a reader
> +mailing list it was sent to), save the mail to a file and use
> +'git-am':
> +
> +.format-patch/am: Publishing branches/topics
> +[caption="Recipe: "]
> +=====================================
> +`git am < patch`
> +=====================================
> +
> +One feature worth pointing out is the three-way merge, which can help
> +if you get conflicts because of renames: `git am -3` will use index
> +information contained in patches to reconstruct a merge base. See
> +linkgit:git-am[1] for other options.
> +
> +
> +SEE ALSO
> +--------
> +linkgit:gittutorial[7],
> +linkgit:git-push[1],
> +linkgit:git-pull[1],
> +linkgit:git-merge[1],
> +linkgit:git-rebase[1],
> +linkgit:git-format-patch[1],
> +linkgit:git-am[1]
> +
> +GIT
> +---
> +Part of the linkgit:git[1] suite.
> --
Santi-
^ permalink raw reply
* Re: [PATCH] Use dashless git commands in setgitperms.perl
From: Jakub Narebski @ 2008-09-20 0:02 UTC (permalink / raw)
To: git
In-Reply-To: <20080919234234.GL2939@inocybe.teonanacatl.org>
Todd Zullinger wrote:
> # To save permissions/ownership data, place this script in your .git/hooks
> # directory and enable a `pre-commit` hook with the following lines:
> # #!/bin/sh
> -# SUBDIRECTORY_OK=1 . git-sh-setup
> +# SUBDIRECTORY_OK=1 . git sh-setup
> # $GIT_DIR/hooks/setgitperms.perl -r
> #
> # To restore permissions/ownership data, place this script in your .git/hooks
> # directory and enable a `post-merge` and `post-checkout` hook with the
> # following lines:
> # #!/bin/sh
> -# SUBDIRECTORY_OK=1 . git-sh-setup
> +# SUBDIRECTORY_OK=1 . git sh-setup
> # $GIT_DIR/hooks/setgitperms.perl -w
> #
The rest is probably O.K., but I don't think this change is good one.
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
^ permalink raw reply
* Re: [PATCH] bash: use for-each-ref format 'refname:short'
From: Shawn O. Pearce @ 2008-09-19 23:51 UTC (permalink / raw)
To: SZEDER GGGbor; +Cc: Junio C Hamano, git
In-Reply-To: <1221862525-20574-1-git-send-email-szeder@ira.uka.de>
SZEDER GGGbor <szeder@ira.uka.de> wrote:
> Using this format simplifies the code for completing refs and (in some
> cases) improves performance significantly.
>
> For repositories like the current git.git (with more than 200 refs)
> there is no real performance difference, but for a repository with 2000
> refs the total time needed to complete the refs is reduced by ~25% (from
> around 400ms to around 305ms).
>
> Signed-off-by: SZEDER Gábor <szeder@ira.uka.de>
Nice improvement.
Acked-by: Shawn O. Pearce <spearce@spearce.org>
> OK, so after the refname:short patch hit master, here is the updated
> patch to use it in bash completion. The patch itself is the same as
> the original one, except, of course, the for-each-ref format name. I
> have also adjusted the performance numbers in the commit message.
>
> contrib/completion/git-completion.bash | 26 ++++++--------------------
> 1 files changed, 6 insertions(+), 20 deletions(-)
>
> diff --git a/contrib/completion/git-completion.bash b/contrib/completion/git-completion.bash
> index d3fb6ae..fccb499 100755
> --- a/contrib/completion/git-completion.bash
> +++ b/contrib/completion/git-completion.bash
> @@ -154,11 +154,8 @@ __git_heads ()
> {
> local cmd i is_hash=y dir="$(__gitdir "$1")"
> if [ -d "$dir" ]; then
> - for i in $(git --git-dir="$dir" \
> - for-each-ref --format='%(refname)' \
> - refs/heads ); do
> - echo "${i#refs/heads/}"
> - done
> + git --git-dir="$dir" for-each-ref --format='%(refname:short)' \
> + refs/heads
> return
> fi
> for i in $(git ls-remote "$1" 2>/dev/null); do
> @@ -175,11 +172,8 @@ __git_tags ()
> {
> local cmd i is_hash=y dir="$(__gitdir "$1")"
> if [ -d "$dir" ]; then
> - for i in $(git --git-dir="$dir" \
> - for-each-ref --format='%(refname)' \
> - refs/tags ); do
> - echo "${i#refs/tags/}"
> - done
> + git --git-dir="$dir" for-each-ref --format='%(refname:short)' \
> + refs/tags
> return
> fi
> for i in $(git ls-remote "$1" 2>/dev/null); do
> @@ -197,16 +191,8 @@ __git_refs ()
> local cmd i is_hash=y dir="$(__gitdir "$1")"
> if [ -d "$dir" ]; then
> if [ -e "$dir/HEAD" ]; then echo HEAD; fi
> - for i in $(git --git-dir="$dir" \
> - for-each-ref --format='%(refname)' \
> - refs/tags refs/heads refs/remotes); do
> - case "$i" in
> - refs/tags/*) echo "${i#refs/tags/}" ;;
> - refs/heads/*) echo "${i#refs/heads/}" ;;
> - refs/remotes/*) echo "${i#refs/remotes/}" ;;
> - *) echo "$i" ;;
> - esac
> - done
> + git --git-dir="$dir" for-each-ref --format='%(refname:short)' \
> + refs/tags refs/heads refs/remotes
> return
> fi
> for i in $(git ls-remote "$dir" 2>/dev/null); do
--
Shawn.
^ permalink raw reply
* Re: What's cooking in git.git (Sep 2008, #03; Fri, 19)
From: david @ 2008-09-19 23:43 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Thomas Rast, git
In-Reply-To: <7vk5d7pxep.fsf@gitster.siamese.dyndns.org>
On Fri, 19 Sep 2008, Junio C Hamano wrote:
> Thomas Rast <trast@student.ethz.ch> writes:
>
>> Regarding _the_ recommended workflow, I can think of a few possible
>> approaches:
>>
>> a) Authoritative: either because we really believe it's the One True
>> Workflow, or just because we want to sound so.
>>
>> b) Descriptive: describe it as the workflow "we" use (presumably this
>> includes linux.git which may be worth mentioning; I haven't touched
>> the kernel though).
>>
>> c) Encyclopedic: describe and classify as many recipes (building
>> blocks) and workflows as possible in an attempt to build a
>> complete reference of sorts.
>>
>> d) Blind eye: we're just the tool. Others can devise workflows.
>>
>> I certainly aimed the patch at (a), since I wanted to be able to point
>> people at it (mostly on #git). The resources I learned Git with,
>> except for the videos, just show simple examples of pull/push usage,
>> which I found both unsatisfactory (e.g. I want to know _why_ it's a
>> good idea to make topic branches) and incomplete. This list is an
>> excellent place to learn, but I doubt that's an effort the average
>> user is willing to put in.
>
> I think we should be honest and not try to do (a) nor (c). And as I
> already said, as (b) your description looked fine, but it wasn't very
> encouraging that not many people commented on it (nor said "Yeah, that's
> what I was missing, thanks").
there is no workflow that is right for every situation, so only describing
one (A or B) is very limiting (even if you don't claim that it's the One
True way)
We've seen that D doesn't work well (people are confused and create
horribly bad workflows, decide that git is too confusing and too limited,
and tell everyone they know)
I think C is best. this doesn't mean that we need to imagine and create
every possible workflow, but including the workflows that we are sent (and
commenting on advantages/disadvantages of them) would be very helpful for
people just getting started with a project. Having a catagory of 'how not
to use git' with some of the worst examples would be very educational.
In almost all cases where people have spoken up and described their
workflow (and the pains involved with it) the git experts here have been
able to simplify things for the user (either by pointing out better ways
to do the same thing, or in some cases by tweaking git to better support
the different class of workflow)
David Lang
^ permalink raw reply
* [PATCH] Use dashless git commands in setgitperms.perl
From: Todd Zullinger @ 2008-09-19 23:42 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Josh England, git
Signed-off-by: Todd Zullinger <tmz@pobox.com>
---
contrib/hooks/setgitperms.perl | 8 ++++----
1 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/contrib/hooks/setgitperms.perl b/contrib/hooks/setgitperms.perl
index dab7c8e..5c1fa91 100644
--- a/contrib/hooks/setgitperms.perl
+++ b/contrib/hooks/setgitperms.perl
@@ -8,14 +8,14 @@
# To save permissions/ownership data, place this script in your .git/hooks
# directory and enable a `pre-commit` hook with the following lines:
# #!/bin/sh
-# SUBDIRECTORY_OK=1 . git-sh-setup
+# SUBDIRECTORY_OK=1 . git sh-setup
# $GIT_DIR/hooks/setgitperms.perl -r
#
# To restore permissions/ownership data, place this script in your .git/hooks
# directory and enable a `post-merge` and `post-checkout` hook with the
# following lines:
# #!/bin/sh
-# SUBDIRECTORY_OK=1 . git-sh-setup
+# SUBDIRECTORY_OK=1 . git sh-setup
# $GIT_DIR/hooks/setgitperms.perl -w
#
use strict;
@@ -50,7 +50,7 @@ if ((@ARGV < 0) || !GetOptions(
)) { die $usage; }
die $usage unless ($read_mode xor $write_mode);
-my $topdir = `git-rev-parse --show-cdup` or die "\n"; chomp $topdir;
+my $topdir = `git rev-parse --show-cdup` or die "\n"; chomp $topdir;
my $gitdir = $topdir . '.git';
my $gitmeta = $topdir . '.gitmeta';
@@ -155,7 +155,7 @@ elsif ($read_mode) {
open (OUT, ">$gitmeta.tmp") or die "Could not open $gitmeta.tmp for writing: $!\n";
}
- my @files = `git-ls-files`;
+ my @files = `git ls-files`;
my %dirs;
foreach my $path (@files) {
--
1.6.0.2
--
Todd OpenPGP -> KeyID: 0xBEAF0CE3 | URL: www.pobox.com/~tmz/pgp
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
What a terrible thing to have lost one's mind. Or not to have a mind
at all. How true that is.
-- Dan Quayle, speaking to the United Negro College Fund
^ permalink raw reply related
* Re: What's cooking in git.git (Sep 2008, #03; Fri, 19)
From: Santi Béjar @ 2008-09-19 22:57 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Thomas Rast, git
In-Reply-To: <7vk5d7pxep.fsf@gitster.siamese.dyndns.org>
On Sat, Sep 20, 2008 at 12:45 AM, Junio C Hamano <gitster@pobox.com> wrote:
[...]
> And as I
> already said, as (b) your description looked fine, but it wasn't very
> encouraging that not many people commented on it (nor said "Yeah, that's
> what I was missing, thanks").
A bit late, but I think it is a very good addition, thanks. I'll review it.
Santi
> --
> To unsubscribe from this list: send the line "unsubscribe git" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
^ permalink raw reply
* Re: What's cooking in git.git (Sep 2008, #03; Fri, 19)
From: Junio C Hamano @ 2008-09-19 22:45 UTC (permalink / raw)
To: Thomas Rast; +Cc: git
In-Reply-To: <200809200020.32285.trast@student.ethz.ch>
Thomas Rast <trast@student.ethz.ch> writes:
> Regarding _the_ recommended workflow, I can think of a few possible
> approaches:
>
> a) Authoritative: either because we really believe it's the One True
> Workflow, or just because we want to sound so.
>
> b) Descriptive: describe it as the workflow "we" use (presumably this
> includes linux.git which may be worth mentioning; I haven't touched
> the kernel though).
>
> c) Encyclopedic: describe and classify as many recipes (building
> blocks) and workflows as possible in an attempt to build a
> complete reference of sorts.
>
> d) Blind eye: we're just the tool. Others can devise workflows.
>
> I certainly aimed the patch at (a), since I wanted to be able to point
> people at it (mostly on #git). The resources I learned Git with,
> except for the videos, just show simple examples of pull/push usage,
> which I found both unsatisfactory (e.g. I want to know _why_ it's a
> good idea to make topic branches) and incomplete. This list is an
> excellent place to learn, but I doubt that's an effort the average
> user is willing to put in.
I think we should be honest and not try to do (a) nor (c). And as I
already said, as (b) your description looked fine, but it wasn't very
encouraging that not many people commented on it (nor said "Yeah, that's
what I was missing, thanks").
^ permalink raw reply
* Re: [RFC Redux] strbuf: Add method to convert byte-size to human readable form
From: Junio C Hamano @ 2008-09-19 22:37 UTC (permalink / raw)
To: Marcus Griep; +Cc: Git Mailing List
In-Reply-To: <7v1vzfrebs.fsf@gitster.siamese.dyndns.org>
Junio C Hamano <gitster@pobox.com> writes:
> Marcus Griep <marcus@griep.us> writes:
>
>> This is a redux of a prior patch as part of a series on count-objects
>> but is now split off and submitted on its own as an RFC for a library
>> function to be added to strbuf.
>
> Ok, so I looked at the patch again.
>...
> For example, if I hand 1638 to you, you would give 1.599Ki back to me, but
> if I give you only 4 digits to work with, you do not want to say 1.59Ki;
> instead you would rather say 1.60Ki, right?
This also takes me back to this part...
>/*
> * strbuf_append_human_readable
> *
> * 'val': value to be metrically-reduced to a human-readable number
> * 'maxlen': maximum number of characters to be taken up by the reduced 'val'
> * not including the sign or magnitude (i.e. 'Ki') characters;
> * when 'maxlen' is 0 length is controled by 'scale'
> * 'scale': when 'val' is greater than 'scale', 'val' is reduced by the
> * period (default 1024, see 'flags') until it is less than 'scale';
> * when 'scale' is 0, 'val' is reduced until it fits in 'maxlen';
> * when 'scale' and 'maxlen' are both zero, 'scale' defaults to 1000
> * 'flags': HR_USE_SI: uses a period of 1000 and uses SI magnitude prefixes
> * HR_SPACE: inserts a space between the reduced 'val' and the units
> * HR_PAD_UNIT: instead of an empty string for singles, pads with
> * spaces to the length of the magnitude prefixes
> *
> * Returns 0 if 'val' is successfully reduced and fits in 'maxlen', otherwise
> * returns -n where n is the number of additional characters necessary to
> * fully fit the reduced value.
> */
The lines are overlong but that is not my main complaint.
I do not see how the above definition of "scale" can be useful.
First, for the case of scale=0, if I tell you to format 1638 into 7 spaces
(without HR_PAD_UNIT), you could give me one of:
1638
1.560Ki
0.002Mi
0.000Gi
...
It is clear that 1638 is better than 1.560Ki which in turn is better than
0.002Mi, because the earlier ones give the information in better precision
with a shorter string than the later ones. Typically the smaller unit
would give you the better answer but does that match "reduced repeatedly
until it fits in 'maxlen'" rule? I do not think so ("1638 " is more
precise than "1.56Ki", even with HR_PAD_UNIT on).
Second, why is the default of "scale" independent from "period"? Scale
that defaults to 1000 in binary system would mean that you would give
...
998 998.0000
999 999.0000
1000 0.976562Ki
1001 0.977539Ki
...
I have this feeling that the "scale" knob does not match well with human
expectations. Admittedly, "most precision within the allocated space"
rule may not match human expectation either (e.g. when you have a
sequence of three numbers "520", "1048", "9999" and you are expecting to
see approximation in binary system, you would probably expect to see
0.51k, 1.02k, and 9.76k, instead of the original integers), but I think it
at least matches human expectations better than the "scale" system.
By the way, about the internal math you do for "repeatedly reduce", I do
not think repeatedly dividing with "period" is kosher. I'd very much
prefer seeing something like:
double magnitude = fabs(value);
double scaler;
for (unit = 0, scaler = 1.0;
scaler < magnitude && unit < max_units;
unit++)
scaler *= period;
printf("%f%s", value / scaler, unit_names[unit]);
modulo the terminating condition --- it may make more sense to stop one
step before "scaler < magnitude" happens so that we won't see "0.9765Ki"
but instead see "1000".
After thinking about this longer, I unfortunately have to say that the
only thing I like about the current iteration of the patch is the name of
the function "strbuf_append_human_readable" and what goal (at the abstract
level) it wants to achieve.
^ permalink raw reply
* Re: What's cooking in git.git (Sep 2008, #03; Fri, 19)
From: Thomas Rast @ 2008-09-19 22:20 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vprmzrh7w.fsf@gitster.siamese.dyndns.org>
[-- Attachment #1: Type: text/plain, Size: 2480 bytes --]
Junio C Hamano wrote:
> * tr/workflow-doc (Sat Sep 13 18:11:01 2008 +0200) 2 commits
> + Documentation: Refer to git-rebase(1) to warn against rewriting
> + Documentation: new upstream rebase recovery section in git-rebase
>
> I think the last one on "recommended practice" needs discussion. I do not
> think it describes _the_ recommended workflow, although I think (1) what
> is recommended in the draft does make sense within its own scope, and (2)
> it may be impossible to come up with _the_ recommended workflow anyway.
[The patch referred to is
http://article.gmane.org/gmane.comp.version-control.git/95806
and the only response so far, to an earlier version,
http://article.gmane.org/gmane.comp.version-control.git/95620 ]
I was hoping for more feedback, but maybe the list is not the right
audience: the intended readers of the document probably aren't as
active on the list and confident about patch review.
Regarding _the_ recommended workflow, I can think of a few possible
approaches:
a) Authoritative: either because we really believe it's the One True
Workflow, or just because we want to sound so.
b) Descriptive: describe it as the workflow "we" use (presumably this
includes linux.git which may be worth mentioning; I haven't touched
the kernel though).
c) Encyclopedic: describe and classify as many recipes (building
blocks) and workflows as possible in an attempt to build a
complete reference of sorts.
d) Blind eye: we're just the tool. Others can devise workflows.
I certainly aimed the patch at (a), since I wanted to be able to point
people at it (mostly on #git). The resources I learned Git with,
except for the videos, just show simple examples of pull/push usage,
which I found both unsatisfactory (e.g. I want to know _why_ it's a
good idea to make topic branches) and incomplete. This list is an
excellent place to learn, but I doubt that's an effort the average
user is willing to put in.
That being said, I'm certainly willing to rewrite it in the direction
of (b), and possibly help with the writeup (though not brainstorming)
of (c), if either of those is the list consensus.
- Thomas
PS: Anyone else noticed the striking number of "we have <setup>, what
is the best workflow and how do I implement it" mails in the past few
days? Is that just a statistical anomaly, or another need for
documentation?
--
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: use for-each-ref format 'refname:short'
From: SZEDER Gábor @ 2008-09-19 22:15 UTC (permalink / raw)
To: Junio C Hamano, Shawn O. Pearce; +Cc: git, SZEDER Gábor
Using this format simplifies the code for completing refs and (in some
cases) improves performance significantly.
For repositories like the current git.git (with more than 200 refs)
there is no real performance difference, but for a repository with 2000
refs the total time needed to complete the refs is reduced by ~25% (from
around 400ms to around 305ms).
Signed-off-by: SZEDER Gábor <szeder@ira.uka.de>
---
OK, so after the refname:short patch hit master, here is the updated
patch to use it in bash completion. The patch itself is the same as
the original one, except, of course, the for-each-ref format name. I
have also adjusted the performance numbers in the commit message.
contrib/completion/git-completion.bash | 26 ++++++--------------------
1 files changed, 6 insertions(+), 20 deletions(-)
diff --git a/contrib/completion/git-completion.bash b/contrib/completion/git-completion.bash
index d3fb6ae..fccb499 100755
--- a/contrib/completion/git-completion.bash
+++ b/contrib/completion/git-completion.bash
@@ -154,11 +154,8 @@ __git_heads ()
{
local cmd i is_hash=y dir="$(__gitdir "$1")"
if [ -d "$dir" ]; then
- for i in $(git --git-dir="$dir" \
- for-each-ref --format='%(refname)' \
- refs/heads ); do
- echo "${i#refs/heads/}"
- done
+ git --git-dir="$dir" for-each-ref --format='%(refname:short)' \
+ refs/heads
return
fi
for i in $(git ls-remote "$1" 2>/dev/null); do
@@ -175,11 +172,8 @@ __git_tags ()
{
local cmd i is_hash=y dir="$(__gitdir "$1")"
if [ -d "$dir" ]; then
- for i in $(git --git-dir="$dir" \
- for-each-ref --format='%(refname)' \
- refs/tags ); do
- echo "${i#refs/tags/}"
- done
+ git --git-dir="$dir" for-each-ref --format='%(refname:short)' \
+ refs/tags
return
fi
for i in $(git ls-remote "$1" 2>/dev/null); do
@@ -197,16 +191,8 @@ __git_refs ()
local cmd i is_hash=y dir="$(__gitdir "$1")"
if [ -d "$dir" ]; then
if [ -e "$dir/HEAD" ]; then echo HEAD; fi
- for i in $(git --git-dir="$dir" \
- for-each-ref --format='%(refname)' \
- refs/tags refs/heads refs/remotes); do
- case "$i" in
- refs/tags/*) echo "${i#refs/tags/}" ;;
- refs/heads/*) echo "${i#refs/heads/}" ;;
- refs/remotes/*) echo "${i#refs/remotes/}" ;;
- *) echo "$i" ;;
- esac
- done
+ git --git-dir="$dir" for-each-ref --format='%(refname:short)' \
+ refs/tags refs/heads refs/remotes
return
fi
for i in $(git ls-remote "$dir" 2>/dev/null); do
--
1.6.0.2.294.g50836f
^ permalink raw reply related
* Re: [RFC Redux] strbuf: Add method to convert byte-size to human readable form
From: Junio C Hamano @ 2008-09-19 21:55 UTC (permalink / raw)
To: Marcus Griep; +Cc: Git Mailing List
In-Reply-To: <1221279997-9336-1-git-send-email-marcus@griep.us>
Marcus Griep <marcus@griep.us> writes:
> This is a redux of a prior patch as part of a series on count-objects
> but is now split off and submitted on its own as an RFC for a library
> function to be added to strbuf.
Ok, so I looked at the patch again.
> diff --git a/.gitignore b/.gitignore
> index bbaf9de..251537b 100644
> --- a/.gitignore
> +++ b/.gitignore
> @@ -147,6 +147,7 @@ test-date
> test-delta
> test-dump-cache-tree
> test-genrandom
> +test-human-read
> test-match-trees
> test-parse-options
> test-path-utils
Is it just me or should the test called "test-human-readable"?
> diff --git a/strbuf.c b/strbuf.c
> index 720737d..d9888fb 100644
> --- a/strbuf.c
> +++ b/strbuf.c
> @@ -308,3 +308,95 @@ int strbuf_read_file(struct strbuf *sb, const char *path, size_t hint)
> ...
> +{
> + const int maxscale = 7;
This is unused as far as I can tell.
> + strbuf_addf(sb, "%f", sign * val);
> +
> + if (maxlen) {
> + int signlen = sign == -1 ? 1 : 0;
> + maxlen -= (sb->buf[maxlen-1+signlen] == '.' ? 1 : 0);
> + if (maxlen <= 0) {
> + strbuf_setlen(sb, 0);
> + retval = maxlen - 1;
> + } else {
> + strbuf_setlen(sb, maxlen + signlen);
> + }
> + }
This means you print to the buffer and then _truncate_ down to precision,
doesn't it? Shouldn't you be rounding (possibly up if it is above the
midway point)?
For example, if I hand 1638 to you, you would give 1.599Ki back to me, but
if I give you only 4 digits to work with, you do not want to say 1.59Ki;
instead you would rather say 1.60Ki, right?
You would need to compute the number of digits you would want to see
upfront and format the value using "%.*f" with appropriate precision.
> diff --git a/test-human-read.c b/test-human-read.c
> new file mode 100644
> index 0000000..7890922
> --- /dev/null
> +++ b/test-human-read.c
> @@ -0,0 +1,23 @@
> +#include "builtin.h"
> +#include "strbuf.h"
> +
> +int main(int argc, char **argv) {
> + if (argc != 6) {
> + exit(-1);
> + }
> +
> + struct strbuf sb;
Decl after statement.
> + strbuf_init(&sb, 0);
> +
> + int retval = strbuf_append_human_readable(&sb,
> + atof(argv[1]), atoi(argv[2]), atoi(argv[3]), atoi(argv[4]));
> +
> + int failed = strcmp(sb.buf, argv[5]);
> +
> + fprintf( stderr, failed ? "Failure" : "Success" );
> + fprintf( stderr, ": Act '%s'; Exp '%s'\n", sb.buf, argv[5] );
> + fprintf( stderr, "Return Value: %d\n", retval );
Style.
> +
> + if(failed) return -1;
Style.
> + return retval;
> +}
> --
> 1.6.0.1.451.gc8d31
^ permalink raw reply
* [PATCH] [TOPGIT] Use git-mailinfo to extract author informations from .topmsg
From: Uwe Kleine-König @ 2008-09-19 21:27 UTC (permalink / raw)
To: git
This has the benefit that the [PATCH] prefixes are stripped and so it
might help to prevent you sending mails with two prefixes. (As happend
to me after I git-format-patch'd an exported series and sent it out with
git-send-email.)
Moreover it should make the code more robust and it allows to remove a
helper function.
And it allows you to set add a Date: line to .topmsg which is then used
as author date.
Signed-off-by: Uwe Kleine-König <ukleinek@strlen.de>
---
tg-export.sh | 45 +++++++++++++--------------------------------
1 files changed, 13 insertions(+), 32 deletions(-)
diff --git a/tg-export.sh b/tg-export.sh
index 654b38b..335f698 100644
--- a/tg-export.sh
+++ b/tg-export.sh
@@ -38,17 +38,6 @@ trap 'rm -rf "$playground"' EXIT
## Collapse driver
-# Trusty Cogito code:
-load_author()
-{
- if [ -z "$GIT_AUTHOR_NAME" ] && echo "$1" | grep -q '^[^< ]'; then
- export GIT_AUTHOR_NAME="$(echo "$1" | sed 's/ *<.*//')"
- fi
- if [ -z "$GIT_AUTHOR_EMAIL" ] && echo "$1" | grep -q '<.*>'; then
- export GIT_AUTHOR_EMAIL="$(echo "$1" | sed 's/.*<\(.*\)>.*/\1/')"
- fi
-}
-
# pretty_tree NAME
# Output tree ID of a cleaned-up tree without tg's artifacts.
pretty_tree()
@@ -69,19 +58,16 @@ collapsed_commit()
>"$playground/^body"
# Get commit message and authorship information
- git cat-file blob "$name:.topmsg" >"$playground/^msg"
- while read line; do
- if [ -z "$line" ]; then
- # end of header
- cat >"$playground/^body"
- break
- fi
- case "$line" in
- From:*) load_author "${line#From: }";;
- Subject:*) echo "${line#Subject: }" >>"$playground/^pre";;
- *) echo "$line" >>"$playground/^post";;
- esac
- done <"$playground/^msg"
+ git cat-file blob "$name:.topmsg" | git mailinfo "$playground/^msg" /dev/null > "$playground/^info"
+
+ GIT_AUTHOR_NAME="$(sed -n '/^Author/ s/Author: //p' "$playground/^info")"
+ GIT_AUTHOR_EMAIL="$(sed -n '/^Email/ s/Email: //p' "$playground/^info")"
+ GIT_AUTHOR_DATE="$(sed -n '/^Date/ s/Date: //p' "$playground/^info")"
+ SUBJECT="$(sed -n '/^Subject/ s/Subject: //p' "$playground/^info")"
+
+ test -n "$GIT_AUTHOR_NAME" && export GIT_AUTHOR_NAME
+ test -n "$GIT_AUTHOR_EMAIL" && export GIT_AUTHOR_EMAIL
+ test -n "$GIT_AUTHOR_DATE" && export GIT_AUTHOR_DATE
# Determine parent
parent="$(cut -f 1 "$playground/$name^parents")"
@@ -95,14 +81,9 @@ collapsed_commit()
$(for p in $parent; do echo -p $p; done))"
fi
- {
- if [ -s "$playground/^pre" ]; then
- cat "$playground/^pre"
- echo
- fi
- cat "$playground/^body"
- [ ! -s "$playground/^post" ] || cat "$playground/^post"
- } | git commit-tree "$(pretty_tree "$name")" -p "$parent"
+ (printf '%s\n\n' "$SUBJECT"; cat "$playground/^msg") |
+ git stripspace |
+ git commit-tree "$(pretty_tree "$name")" -p "$parent"
echo "$name" >>"$playground/^ticker"
}
--
1.5.6.5
^ permalink raw reply related
* Re: [RFC Redux] strbuf: Add method to convert byte-size to human readable form
From: Daniel Barkalow @ 2008-09-19 20:59 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Marcus Griep, Git Mailing List
In-Reply-To: <7vzlm3ri50.fsf@gitster.siamese.dyndns.org>
On Fri, 19 Sep 2008, Junio C Hamano wrote:
> Marcus Griep <marcus@griep.us> writes:
>
> > If there is no comment on this, Junio, would you be ok accepting this as
> > a patch, even as a feature-branch on pu or next?
>
> We (collectively as the development community) should be doing better than
> that. "No comment" should not mean "no objection with huge silent
> support". "No comment" simply means "no support".
IIRC people commentted positively on the feature, but there were
implementation issues, which got resolved, and then nothing.
-Daniel
*This .sig left intentionally blank*
^ permalink raw reply
* What's cooking in git.git (Sep 2008, #03; Fri, 19)
From: Junio C Hamano @ 2008-09-19 20:52 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.
By the way, I'll be on vacation from Sep 24 til Oct 08, but e-mail based
proposal/review/discussion/improvement cycle and the distributed nature of
git mean that it shouldn't keep the participants from further working on
the system. Hopefully when I come back I'll see a much improved git ;-).
----------------------------------------------------------------
[New Topics]
* mg/maint-remote-fix (Thu Sep 18 18:11:02 2008 +0200) 1 commit
- make "git remote" report multiple URLs
Still with a minor nit but I think this is an improvement.
* pb/submodule (Fri Sep 12 23:09:19 2008 +0200) 1 commit
- t7400: Add short "git submodule add" testsuite
Waiting for a reroll.
* tr/workflow-doc (Sat Sep 13 18:11:01 2008 +0200) 2 commits
+ Documentation: Refer to git-rebase(1) to warn against rewriting
+ Documentation: new upstream rebase recovery section in git-rebase
I think the last one on "recommended practice" needs discussion. I do not
think it describes _the_ recommended workflow, although I think (1) what
is recommended in the draft does make sense within its own scope, and (2)
it may be impossible to come up with _the_ recommended workflow anyway.
* bc/maint-diff-hunk-header-fix (Thu Sep 18 17:44:33 2008 -0500) 3 commits
+ diff.*.xfuncname which uses "extended" regex's for hunk header
selection
+ diff.c: associate a flag with each pattern and use it for
compiling regex
+ diff.c: return pattern entry pointer rather than just the hunk
header pattern
* bc/master-diff-hunk-header-fix (Thu Sep 18 20:32:50 2008 -0700) 4 commits
+ Merge branch 'bc/maint-diff-hunk-header-fix' into bc/master-diff-
hunk-header-fix
+ diff.*.xfuncname which uses "extended" regex's for hunk header
selection
+ diff.c: associate a flag with each pattern and use it for
compiling regex
+ diff.c: return pattern entry pointer rather than just the hunk
header pattern
I've commented on these two branches in a separate message.
----------------------------------------------------------------
[Graduated to "master"]
* mh/maint-honor-no-ssl-verify (Thu Feb 21 15:10:37 2008 -0800) 1 commit
+ Don't verify host name in SSL certs when GIT_SSL_NO_VERIFY is set
* dp/maint-rebase-fix (Tue Sep 9 16:05:26 2008 +0400) 2 commits
+ git-rebase--interactive: auto amend only edited commit
+ git-rebase-interactive: do not squash commits on abort
* jc/maint-checkout-keep-remove (Sun Sep 7 19:49:25 2008 -0700) 1 commit
+ checkout: do not lose staged removal
* jc/maint-template-permbits (Thu Aug 21 19:31:50 2008 -0500) 1 commit
+ Fix permission bits on sources checked out with an overtight umask
* np/pack (Tue Sep 2 10:22:22 2008 -0400) 4 commits
+ t5300: improve SHA1 collision test
+ pack-objects: don't include missing preferred base objects
+ sha1write: don't copy full sized buffers
+ Merge branch 'np/maint-safer-pack' into np/pack
* bw/shortref (Fri Sep 5 23:16:23 2008 +0200) 1 commit
+ for-each-ref: `:short` format for `refname`
* rs/decorate (Thu Sep 4 23:40:03 2008 +0200) 3 commits
+ add '%d' pretty format specifier to show decoration
+ move load_ref_decorations() to log-tree.c and export it
+ log: add load_ref_decorations()
* tr/rev-list-reverse (Mon Sep 1 00:31:37 2008 +0200) 2 commits
+ t6013: replace use of 'tac' with equivalent Perl
+ rev-list: fix --reverse interaction with --parents
* cc/bisect (Sat Sep 6 07:27:03 2008 +0200) 3 commits
+ bisect: remove "checkout_done" variable used when checking merge
bases
+ bisect: only check merge bases when needed
+ bisect: test merge base if good rev is not an ancestor of bad rev
* jc/setlinebuf-setvbuf (Wed Sep 3 20:33:29 2008 -0700) 1 commit
+ daemon.c: avoid setlinebuf()
* jc/maint-diff-quiet (Mon Sep 1 23:20:26 2008 -0700) 2 commits
+ diff --quiet: make it synonym to --exit-code >/dev/null
+ diff Porcelain: do not disable auto index refreshing on -C -C
* jc/maint-name-hash-clear (Sat Aug 23 13:05:10 2008 -0700) 1 commit
+ discard_cache: reset lazy name_hash bit
* jc/diff-prefix (Mon Aug 18 20:08:09 2008 -0700) 1 commit
+ diff: vary default prefix depending on what are compared
----------------------------------------------------------------
[Stalled -- Needs Action to Proceed (or to be dropped)]
* bd/blame (Thu Aug 21 18:22:01 2008 -0500) 5 commits
- Use xdiff caching to improve git blame performance
- Allow xdiff machinery to cache hash results for a file
- Always initialize xpparam_t to 0
- Bypass textual patch generation and parsing in git blame
- Allow alternate "low-level" emit function from xdl_diff
Réne had good comments on how the callback should be structured.
* kb/am-directory (Fri Aug 29 15:27:50 2008 -0700) 1 commit
- git-am: Pass the --directory option through to git-apply
I think this is still buggy and drops the option when am stops with
conflicts.
----------------------------------------------------------------
[Will be merged to "master" soon]
* mv/merge-recursive (Sat Sep 6 18:29:49 2008 +0200) 11 commits
+ builtin-merge: release the lockfile in try_merge_strategy()
+ merge-recursive: get rid of virtual_id
+ merge-recursive: move current_{file,directory}_set to struct
merge_options
+ merge-recursive: move the global obuf to struct merge_options
+ merge-recursive: get rid of the index_only global variable
+ merge-recursive: move call_depth to struct merge_options
+ cherry-pick/revert: make direct internal call to merge_tree()
+ builtin-merge: avoid run_command_v_opt() for recursive and subtree
+ merge-recursive: introduce merge_options
+ merge-recursive.c: Add more generic merge_recursive_generic()
+ Split out merge_recursive() to merge-recursive.c
* ho/dirstat-by-file (Fri Sep 5 22:27:35 2008 +0300) 1 commit
+ diff --dirstat-by-file: count changed files, not lines
* jc/safe-c-l-d (Tue Sep 2 14:10:15 2008 -0700) 1 commit
+ safe_create_leading_directories(): make it about "leading"
directories
* jc/apply-include-exclude (Mon Aug 25 01:05:31 2008 -0700) 1 commit
+ git-apply:--include=pathspec
* mv/commit-tree (Wed Sep 10 22:10:33 2008 +0200) 3 commits
+ t7603: add new testcases to ensure builtin-commit uses
reduce_heads()
+ builtin-commit: use commit_tree()
+ commit_tree(): add a new author parameter
* pb/autocorrect-wrapper (Wed Sep 10 17:54:28 2008 +0200) 1 commit
+ git wrapper: also use aliases to correct mistyped commands
* pb/commit-where (Mon Sep 8 01:05:41 2008 +0200) 1 commit
+ builtin-commit.c: show on which branch a commit was added
* jc/better-conflict-resolution (Thu Sep 4 23:48:48 2008 +0200) 15 commits
+ Fix AsciiDoc errors in merge documentation
+ git-merge documentation: describe how conflict is presented
+ checkout --conflict=<style>: recreate merge in a non-default style
+ checkout -m: recreate merge when checking out of unmerged index
+ Merge branch 'jc/maint-checkout-fix' into 'jc/better-conflict-
resolution'
+ git-merge-recursive: learn to honor merge.conflictstyle
+ merge.conflictstyle: choose between "merge" and "diff3 -m" styles
+ rerere: understand "diff3 -m" style conflicts with the original
+ rerere.c: use symbolic constants to keep track of parsing states
+ xmerge.c: "diff3 -m" style clips merge reduction level to EAGER or
less
+ xmerge.c: minimum readability fixups
+ xdiff-merge: optionally show conflicts in "diff3 -m" style
+ xdl_fill_merge_buffer(): separate out a too deeply nested function
+ checkout --ours/--theirs: allow checking out one side of a
conflicting merge
+ checkout -f: allow ignoring unmerged paths when checking out of
the index
* jc/alternate-push (Tue Sep 9 01:27:10 2008 -0700) 4 commits
+ push: receiver end advertises refs from alternate repositories
+ push: prepare sender to receive extended ref information from the
receiver
+ receive-pack: make it a builtin
+ is_directory(): a generic helper function
----------------------------------------------------------------
[Actively Cooking]
* am/status (Mon Sep 8 00:05:03 2008 +0200) 2 commits
+ wt-status: Teach how to discard changes in the working directory
+ wt-status: Split header generation into three functions
* lt/time-reject-fractional-seconds (Sat Aug 16 21:25:40 2008 -0700) 1 commit
+ date/time: do not get confused by fractional seconds
* jc/add-ita (Thu Aug 21 01:44:53 2008 -0700) 1 commit
+ git-add --intent-to-add (-N)
Teaches "git add" to record only the intent to add a path later.
I rerolled this without the fake empty blob object.
* jc/post-simplify (Fri Aug 15 01:34:51 2008 -0700) 2 commits
- revision --simplify-merges: incremental simplification
- revision --simplify-merges: prepare for incremental simplification
I started making this incremental but the progress is not so great.
----------------------------------------------------------------
[On Hold]
* jc/stripspace (Sun Mar 9 00:30:35 2008 -0800) 6 commits
- git-am --forge: add Signed-off-by: line for the author
- git-am: clean-up Signed-off-by: lines
- stripspace: add --log-clean option to clean up signed-off-by:
lines
- stripspace: use parse_options()
- Add "git am -s" test
- git-am: refactor code to add signed-off-by line for the committer
The one at second from the tip needs reworking.
* jc/send-pack-tell-me-more (Thu Mar 20 00:44:11 2008 -0700) 1 commit
- "git push": tellme-more protocol extension
* jc/merge-whitespace (Sun Feb 24 23:29:36 2008 -0800) 1 commit
- WIP: start teaching the --whitespace=fix to merge machinery
* jc/blame (Wed Jun 4 22:58:40 2008 -0700) 2 commits
- blame: show "previous" information in --porcelain/--incremental
format
- git-blame: refactor code to emit "porcelain format" output
* 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, but with the loud whining about moving git-foo out of $PATH we
have been hearing, it might not be a bad idea to drop this.
* 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.
^ permalink raw reply
* Re: [RFC Redux] strbuf: Add method to convert byte-size to human readable form
From: Junio C Hamano @ 2008-09-19 20:32 UTC (permalink / raw)
To: Marcus Griep; +Cc: Git Mailing List
In-Reply-To: <48D3CBBA.8060507@griep.us>
Marcus Griep <marcus@griep.us> writes:
> If there is no comment on this, Junio, would you be ok accepting this as
> a patch, even as a feature-branch on pu or next?
We (collectively as the development community) should be doing better than
that. "No comment" should not mean "no objection with huge silent
support". "No comment" simply means "no support".
If I recall correctly (I did read the patch myself when it was posted), I
did not spot anything glaringly wrong in it, but I have to go back to make
sure if we are going to queue this in 'next'.
I have deliberately been trying to keep myself from commenting on series
that I have read. The thing is, it seems to me that that seeing my
comments on the list somehow discourages others from reviewing and
commenting, and I would really like to see people on the list to review
and help improve more patches from others.
^ permalink raw reply
* Re: [PATCH v2 4/4] diff.c: convert builtin funcname patterns to non-GNU extended regex syntax
From: Junio C Hamano @ 2008-09-19 20:29 UTC (permalink / raw)
To: Brandon Casey
Cc: Arjen Laarhoven, Mike Ralphson, Johannes Sixt, Jeff King,
Boyd Lynn Gerber, Git Mailing List, Avery Pennarun, Johan Herland,
Andreas Ericsson, Kirill Smelkov, Giuseppe Bilotta,
Gustaf Hendeby, Jonathan del Strother
In-Reply-To: <4i0Mu795rKpv37JoHytmE6kODBjwgwITn0-DuKdZiFs3ZnUlyJC-Fw@cipher.nrlssc.navy.mil>
Brandon Casey <casey@nrlssc.navy.mil> writes:
> The 'non-GNU' part of this basic RE to extended RE conversion means '\\s' was
> converted to ' '.
I think a large part of this series should be in 'maint', as the existing
hunk head pattern engine does _not_ work for people without GNU regexp.
I've created two branches to house this topic:
- bc/maint-diff-hunk-header-fix is rebased to 'maint', so that after
testing we can merge it to 'maint' for 1.6.0.3 and later versions.
Its current tip is at 45d9414;
- bc/master-diff-hunk-header-fix forks from the above, and merges later
"language" additions that happened on 'master'. We can merge this
after testing to 'master' for 1.6.1.
Its current tip is at dde4af4.
Neither has [4/4] on it. I'd like two patches so that:
* [PATCH 1/2] applies to bc/maint-diff-hunk-header-fix, so that the
languages in 1.6.0.2 are fixed for non GNU platforms;
* After applying [1/2] to bc/maint-diff-hunk-header-fix, I'll merge the
branch to bc/master-diff-hunk-header-fix and then...
* [PATCH 2/2] applies on top of it to convert new languages that are
supported only on 'master' to use xfuncname.
^ permalink raw reply
* Re: [PATCH] make "git remote" report multiple URLs
From: Junio C Hamano @ 2008-09-19 20:28 UTC (permalink / raw)
To: Michael J Gruber; +Cc: git
In-Reply-To: <1221754262-15772-1-git-send-email-git@drmicha.warpmail.net>
Michael J Gruber <git@drmicha.warpmail.net> writes:
> This patch makes "git remote -v" and "git remote show" report multiple URLs
> rather than warn about them. Multiple URLs are OK for pushing into
> multiple repos simultaneously.
>
> Signed-off-by: Michael J Gruber <git@drmicha.warpmail.net>
> ---
Nice. But this makes "git remote show" to give duplicate results, which
you might want to cull.
> builtin-remote.c | 11 +++++++----
> 1 files changed, 7 insertions(+), 4 deletions(-)
>
> This passes all tests, so I think the new output does not break anything.
Or just there is no existing tests that verify the output from this command.
> diff --git a/builtin-remote.c b/builtin-remote.c
> index 01945a8..ae560e7 100644
> --- a/builtin-remote.c
> +++ b/builtin-remote.c
> @@ -652,10 +652,13 @@ static int get_one_entry(struct remote *remote, void *priv)
> {
> struct string_list *list = priv;
>
> - string_list_append(remote->name, list)->util = remote->url_nr ?
> - (void *)remote->url[0] : NULL;
> - if (remote->url_nr > 1)
> - warning("Remote %s has more than one URL", remote->name);
> + if (remote->url_nr > 0) {
> + int i;
> +
> + for (i = 0; i < remote->url_nr; i++)
> + string_list_append(remote->name, list)->util = (void *)remote->url[i];
> + } else
> + string_list_append(remote->name, list)->util = NULL;
>
> return 0;
> }
> --
> 1.6.0.2.249.g97d7f
^ permalink raw reply
* Re: [PATCH] Documentation: warn against merging in a dirty tree
From: Junio C Hamano @ 2008-09-19 20:28 UTC (permalink / raw)
To: Linus Torvalds
Cc: Avery Pennarun, Thomas Rast, git, Jakub Narebski, Miklos Vajna
In-Reply-To: <alpine.LFD.1.10.0809180804100.3337@nehalem.linux-foundation.org>
Linus Torvalds <torvalds@linux-foundation.org> writes:
> That said, it's actually kind of sad that we don't expose a real
> capability that the git plumbing does have. Namely
>
> git read-tree -u -m HEAD ORIG_HEAD
I do not think this is quite enough. "read-tree --reset -u" is probably
closer, but it may discard the entries added (and got conflicted) by the
merge before actually updating the working tree (the right thing there
would be to remove them).
^ permalink raw reply
* Re* [RFC/PATCH] extend meaning of "--root" option to index comparisons
From: Junio C Hamano @ 2008-09-19 20:27 UTC (permalink / raw)
To: Jeff King; +Cc: Anatol Pomozov, sverre, Git Mailing List
In-Reply-To: <20080919142537.GA1287@coredump.intra.peff.net>
Jeff King <peff@peff.net> writes:
> On Thu, Sep 18, 2008 at 09:31:24AM -0700, Anatol Pomozov wrote:
>
>> > Can you think of any other cases?
>>
>> git log??
>>
>> git log --root for empty repo should not print anything (instead of
>> error message that we have now).
>
> I'm not sure that's the same as "--root", though. In existing --root
> cases, we are saying "pretend that beyond the initial commit, there is a
> commit that contains the empty tree". The logical extension of git-log
> here would be to print out that commit.
I would say:
(1) A user getting an error message from "git init && git log" may be
annoyed, but he very well knows there is no history yet _anyway_.
This initial annoyance will pass immediately after creating any
commit, so I do not think it is a big issue.
"bad default revision 'HEAD'" is a cryptic way to give that indicaion
that can be improved but that is a separate issue. Rewording it so
that it explains the situation better in user's terms would be a
worthy improvement.
(2) "--root" is about "do we show a creation event as a huge diff from
emptyness?". Yes, we turn it on for "git log" but it does not have
anything to do with the issue of yet to be born branch, where there
isn't even a big creation event yet.
I am reluctant to agree with the opinion that "git log" should be _silent_
in a world without any history.
Perhaps something like this would be a good compromise? I dunno.
builtin-log.c | 9 ++++++++-
1 files changed, 8 insertions(+), 1 deletions(-)
diff --git c/builtin-log.c w/builtin-log.c
index 081e660..881324c 100644
--- c/builtin-log.c
+++ w/builtin-log.c
@@ -42,7 +42,14 @@ static void cmd_log_init(int argc, const char **argv, const char *prefix,
if (default_date_mode)
rev->date_mode = parse_date_format(default_date_mode);
- argc = setup_revisions(argc, argv, rev, "HEAD");
+ argc = setup_revisions(argc, argv, rev, NULL);
+ if (!rev->pending.nr) {
+ add_head_to_pending(rev);
+ if (!rev->pending.nr) {
+ printf("No commits (yet).\n");
+ exit(0);
+ }
+ }
if (rev->diffopt.pickaxe || rev->diffopt.filter)
rev->always_show_header = 0;
^ permalink raw reply related
* [PATCH v2] Bust the ghost of long-defunct diffcore-pathspec.
From: Yann Dirson @ 2008-09-19 20:12 UTC (permalink / raw)
To: git
In-Reply-To: <7vbpz7tqsb.fsf@gitster.siamese.dyndns.org>
This concept was retired by 77882f60d9df2fd410ba7d732b01738315643c05,
more than 2 years ago.
Signed-off-by: Yann Dirson <ydirson@altern.org>
---
This new version ought to address all points in the comments to my
original patch.
Documentation/gitdiffcore.txt | 55 ++++++++++++++++-------------------------
diffcore.h | 1 -
2 files changed, 22 insertions(+), 34 deletions(-)
diff --git a/Documentation/gitdiffcore.txt b/Documentation/gitdiffcore.txt
index 2bdbc3d..e8041bc 100644
--- a/Documentation/gitdiffcore.txt
+++ b/Documentation/gitdiffcore.txt
@@ -36,11 +36,25 @@ files:
- 'git-diff-tree' compares contents of two "tree" objects;
-In all of these cases, the commands themselves compare
-corresponding paths in the two sets of files. The result of
-comparison is passed from these commands to what is internally
-called "diffcore", in a format similar to what is output when
-the -p option is not used. E.g.
+In all of these cases, the commands themselves first optionally limit
+the two sets of files by any pathspecs given on their command-lines,
+and compare corresponding paths in the two resulting sets of files.
+
+The pathspecs are used to limit the world diff operates in. They remove
+the filepairs outside the specified sets of pathnames. E.g. If the
+input set of filepairs included:
+
+------------------------------------------------
+:100644 100644 bcd1234... 0123456... M junkfile
+------------------------------------------------
+
+but the command invocation was `git diff-files myfile`, then the
+junkfile entry would be removed from the list because only "myfile"
+is under consideration.
+
+The result of comparison is passed from these commands to what is
+internally called "diffcore", in a format similar to what is output
+when the -p option is not used. E.g.
------------------------------------------------
in-place edit :100644 100644 bcd1234... 0123456... M file0
@@ -52,9 +66,8 @@ unmerged :000000 000000 0000000... 0000000... U file6
The diffcore mechanism is fed a list of such comparison results
(each of which is called "filepair", although at this point each
of them talks about a single file), and transforms such a list
-into another list. There are currently 6 such transformations:
+into another list. There are currently 5 such transformations:
-- diffcore-pathspec
- diffcore-break
- diffcore-rename
- diffcore-merge-broken
@@ -62,38 +75,14 @@ into another list. There are currently 6 such transformations:
- diffcore-order
These are applied in sequence. The set of filepairs 'git-diff-{asterisk}'
-commands find are used as the input to diffcore-pathspec, and
-the output from diffcore-pathspec is used as the input to the
+commands find are used as the input to diffcore-break, and
+the output from diffcore-break is used as the input to the
next transformation. The final result is then passed to the
output routine and generates either diff-raw format (see Output
format sections of the manual for 'git-diff-{asterisk}' commands) or
diff-patch format.
-diffcore-pathspec: For Ignoring Files Outside Our Consideration
----------------------------------------------------------------
-
-The first transformation in the chain is diffcore-pathspec, and
-is controlled by giving the pathname parameters to the
-'git-diff-{asterisk}' commands on the command line. The pathspec is used
-to limit the world diff operates in. It removes the filepairs
-outside the specified set of pathnames. E.g. If the input set
-of filepairs included:
-
-------------------------------------------------
-:100644 100644 bcd1234... 0123456... M junkfile
-------------------------------------------------
-
-but the command invocation was `git diff-files myfile`, then the
-junkfile entry would be removed from the list because only "myfile"
-is under consideration.
-
-Implementation note. For performance reasons, 'git-diff-tree'
-uses the pathname parameters on the command line to cull set of
-filepairs it feeds the diffcore mechanism itself, and does not
-use diffcore-pathspec, but the end result is the same.
-
-
diffcore-break: For Splitting Up "Complete Rewrites"
----------------------------------------------------
diff --git a/diffcore.h b/diffcore.h
index cc96c20..8ae3578 100644
--- a/diffcore.h
+++ b/diffcore.h
@@ -92,7 +92,6 @@ extern struct diff_filepair *diff_queue(struct diff_queue_struct *,
struct diff_filespec *);
extern void diff_q(struct diff_queue_struct *, struct diff_filepair *);
-extern void diffcore_pathspec(const char **pathspec);
extern void diffcore_break(int);
extern void diffcore_rename(struct diff_options *);
extern void diffcore_merge_broken(void);
^ permalink raw reply related
* [PATCH] fix openssl headers conflicting with custom SHA1 implementations
From: Nicolas Pitre @ 2008-09-19 20:11 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Robert Shearman, git
On ARM I have the following compilation errors:
CC fast-import.o
In file included from cache.h:8,
from builtin.h:6,
from fast-import.c:142:
arm/sha1.h:14: error: conflicting types for 'SHA_CTX'
/usr/include/openssl/sha.h:105: error: previous declaration of 'SHA_CTX' was here
arm/sha1.h:16: error: conflicting types for 'SHA1_Init'
/usr/include/openssl/sha.h:115: error: previous declaration of 'SHA1_Init' was here
arm/sha1.h:17: error: conflicting types for 'SHA1_Update'
/usr/include/openssl/sha.h:116: error: previous declaration of 'SHA1_Update' was here
arm/sha1.h:18: error: conflicting types for 'SHA1_Final'
/usr/include/openssl/sha.h:117: error: previous declaration of 'SHA1_Final' was here
make: *** [fast-import.o] Error 1
This is because openssl header files are always included in
git-compat-util.h since commit 684ec6c63c whenever NO_OPENSSL is not
set, which somehow brings in <openssl/sha1.h> clashing with the custom
ARM version. Compilation of git is probably broken on PPC too for the
same reason.
Turns out that the only file requiring openssl/ssl.h and openssl/err.h
is imap-send.c. But only moving those problematic includes there
doesn't solve the issue as it also includes cache.h which brings in the
conflicting header. So also conditionally including SHA1_HEADER allows
for not including it when compiling imap-send.c.
Signed-off-by: Nicolas Pitre <nico@cam.org>
---
This is a bit ugly but given the rat nest of system includes we have I
don't know how to solve this any better.
diff --git a/Makefile b/Makefile
index 3c0664a..a0f86dd 100644
--- a/Makefile
+++ b/Makefile
@@ -1242,6 +1242,9 @@ endif
git-%$X: %.o $(GITLIBS)
$(QUIET_LINK)$(CC) $(ALL_CFLAGS) -o $@ $(ALL_LDFLAGS) $(filter %.o,$^) $(LIBS)
+imap-send.o: imap-send.c GIT-CFLAGS
+ $(QUIET_CC)$(CC) -o $*.o -c $(ALL_CFLAGS) -USHA1_HEADER $<
+
git-imap-send$X: imap-send.o $(GITLIBS)
$(QUIET_LINK)$(CC) $(ALL_CFLAGS) -o $@ $(ALL_LDFLAGS) $(filter %.o,$^) \
$(LIBS) $(OPENSSL_LINK) $(OPENSSL_LIBSSL)
diff --git a/cache.h b/cache.h
index de8c2b6..d93e086 100644
--- a/cache.h
+++ b/cache.h
@@ -5,7 +5,10 @@
#include "strbuf.h"
#include "hash.h"
+#ifdef SHA1_HEADER
#include SHA1_HEADER
+#endif
+
#include <zlib.h>
#if defined(NO_DEFLATE_BOUND) || ZLIB_VERNUM < 0x1200
diff --git a/git-compat-util.h b/git-compat-util.h
index db2836f..044f62b 100644
--- a/git-compat-util.h
+++ b/git-compat-util.h
@@ -99,11 +99,6 @@
#include <iconv.h>
#endif
-#ifndef NO_OPENSSL
-#include <openssl/ssl.h>
-#include <openssl/err.h>
-#endif
-
/* On most systems <limits.h> would have given us this, but
* not on some systems (e.g. GNU/Hurd).
*/
diff --git a/imap-send.c b/imap-send.c
index af7e08c..01f1c9a 100644
--- a/imap-send.c
+++ b/imap-send.c
@@ -22,11 +22,15 @@
* Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
*/
-#include "cache.h"
#ifdef NO_OPENSSL
typedef void *SSL;
+#else
+#include <openssl/ssl.h>
+#include <openssl/err.h>
#endif
+#include "cache.h"
+
struct store_conf {
char *name;
const char *path; /* should this be here? its interpretation is driver-specific */
Nicolas
^ permalink raw reply related
* Re: [PATCH v2 1/4] diff.c: return pattern entry pointer rather than just the hunk header pattern
From: Brandon Casey @ 2008-09-19 19:11 UTC (permalink / raw)
To: Boyd Lynn Gerber
Cc: Junio C Hamano, Arjen Laarhoven, Mike Ralphson, Johannes Sixt,
Jeff King, Git Mailing List, Avery Pennarun, Johan Herland,
Andreas Ericsson, Kirill Smelkov, Giuseppe Bilotta,
Gustaf Hendeby, Jonathan del Strother
In-Reply-To: <alpine.LNX.1.10.0809191209450.10710@suse104.zenez.com>
Boyd Lynn Gerber wrote:
> So on these patches,
> What do you want me to do? I applied them and things kinda worked.
Test t4018-diff-funcname.sh should pass. As Johan mentioned, in the
last patch '\\s' should have been converted to '[ \t]', rather than
to just ' ', but that should not affect the test and should only
affect html, python, and ruby patterns.
It would be nice if the tests were expanded.
> The
> problem is pine/alpine messes them up a bit and it is not easy to
> manually fix them. It would be easier to git clone/pull them from
> either a site or the trees.
I expect they will be in Junio's tree soon, most likely the master
branch.
>I do think that on some we should use the
> actual charact vers the C-syntax. "\t" for example.
"\t" is safe to use since it is interpreted by git in config.c: parse_value(),
not by the regex library. I was also concerned about that character until I
traced the code to parse_value(). Junio is right that better documentation of
this feature is needed.
-brandon
^ permalink raw reply
* Re: [PATCH 3/4] diff.*.xfuncname which uses "extended" regex's for hunk header selection
From: Brandon Casey @ 2008-09-19 18:14 UTC (permalink / raw)
To: Junio C Hamano
Cc: Arjen Laarhoven, Mike Ralphson, Johannes Sixt, Jeff King,
Git Mailing List
In-Reply-To: <7vd4j212gb.fsf@gitster.siamese.dyndns.org>
Junio C Hamano wrote:
> I personally think it was a mistake that the loop returns failure when
> there is any pattern that does not match (it is a useful feature that a
> match with a negated one forces an early return, though).
>
> We may want to fix the semantics to be something like:
>
> for (i = 0; i < regs->nr; i++) {
> struct ff_reg *reg = ®s->array[i];
> if (!regexec(®->re, line_buffer, 2, pmatch, 0)) {
> if (reg->negate) {
> free(line_buffer);
> return -1;
> }
> break;
> }
> }
> if (regs->nr <= i) {
> free(line_buffer);
> return -1;
> }
> ... use pmatch() ...
>
> I.e. (1) negative match forces an early return (useful for catching
> language keywords), (2) first positive match is used, and (3) no match is
> a failure.
>
> Of course, by definition the above "fix" changes the semantics, and will
> break people's existing setup if somebody has an existing custom pattern
> string that does use more than one positive regexp anded together with
> "\n", but I somehow suspect nobody sane depends on the current broken
> semantics.
>
> It would help making JdS's ObjC alternates easier to write. You can say:
>
>
> /* A or B */
> "...(A|B)$"
> "\n" /* or C or D */
> "...(C|D)$"
>
> and both captures around A|B and C|D would be saved in $1.
Just to let you know another pair of eyes has given the above a
once over, I agree with your proposal. "or" semantics makes more sense
than "and".
-brandon
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox