* Re: Symbolic link documentation
From: Johannes Schindelin @ 2007-09-20 17:52 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: Matt Seitz (matseitz), git
In-Reply-To: <20070920172736.GU3099@spearce.org>
Hi,
On Thu, 20 Sep 2007, Shawn O. Pearce wrote:
> Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
> > On Thu, 20 Sep 2007, Matt Seitz (matseitz) wrote:
> >
> > > Where does the git user documentation discuss how git handles
> > > symbolic links?
> >
> > $ git grep symbolic Documentation/ | grep link
> > [...]
> > Documentation/config.txt: If false, symbolic links are checked out as small plain files that
> > Documentation/config.txt: symbolic links. True by default.
> > Documentation/git-update-index.txt:to 'false' (see gitlink:git-config[1]), symbolic links are checked out
> > Documentation/git-update-index.txt:from symbolic link to regular file.
> > Documentation/technical/racy-git.txt:files vs symbolic links) and executable bits (only for regular
>
> These are probably what Matt was looking for.
Well, he asked where the git user documentation talks about symbolic
links, and I provided a pointer.
Ciao,
Dscho
^ permalink raw reply
* [PATCH] new test from the submodule chapter of the user manual
From: Miklos Vajna @ 2007-09-20 17:08 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Johannes Schindelin, J. Bruce Fields
In-Reply-To: <Pine.LNX.4.64.0709201133590.28395@racer.site>
Signed-off-by: Miklos Vajna <vmiklos@frugalware.org>
---
On Thu, Sep 20, 2007 at 11:34:25AM +0100, Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
> On Wed, 19 Sep 2007, Junio C Hamano wrote:
> > Looks Ok to me, although I didn't verify the examples by
> > actually running them myself this time (last round I did).
>
> So maybe we should do the same as with the tutorial: stick the examples
> into a test script?
what about this?
t/t3060-subprojects-tutorial.sh | 62 +++++++++++++++++++++++++++++++++++++++
1 files changed, 62 insertions(+), 0 deletions(-)
create mode 100755 t/t3060-subprojects-tutorial.sh
diff --git a/t/t3060-subprojects-tutorial.sh b/t/t3060-subprojects-tutorial.sh
new file mode 100755
index 0000000..2fcf4ab
--- /dev/null
+++ b/t/t3060-subprojects-tutorial.sh
@@ -0,0 +1,62 @@
+#!/bin/sh
+#
+# Copyright (c) 2007 Miklos Vajna
+#
+
+test_description='A simple subprojects tutorial in the form of a test case'
+
+. ./test-lib.sh
+
+test_expect_success "create the submodules" '
+ for i in a b c d
+ do
+ mkdir $i &&
+ cd $i &&
+ git init &&
+ echo "module $i" > $i.txt &&
+ git add $i.txt &&
+ git commit -m "Initial commit, submodule $i" &&
+ cd ..
+ done
+'
+
+test_expect_success "create the superproject" '
+ mkdir super &&
+ cd super &&
+ git init &&
+ for i in a b c d
+ do
+ git submodule add '`pwd`'/$i
+ done
+'
+
+test_expect_success "commit in the superproject" '
+ git commit -m "Add submodules a, b, c and d." &&
+ cd ..
+'
+
+test_expect_success "clone the superproject" '
+ git clone super cloned &&
+ cd cloned
+'
+
+test_expect_success "submodule init" '
+ git submodule init
+'
+
+test_expect_success "submodule update" '
+ git submodule update
+'
+
+test_expect_success "update the submodule from within the superproject" '
+ cd a &&
+ echo "adding a line again" >> a.txt &&
+ git commit -a -m "Updated the submodule from within the superproject." &&
+ git push &&
+ cd .. &&
+ git add a &&
+ git commit -m "Updated submodule a." &&
+ git push
+'
+
+test_done
--
1.5.3.2.80.g077d6f-dirty
^ permalink raw reply related
* Re: Symbolic link documentation
From: Shawn O. Pearce @ 2007-09-20 17:27 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Matt Seitz (matseitz), git
In-Reply-To: <Pine.LNX.4.64.0709201819340.28395@racer.site>
Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
> On Thu, 20 Sep 2007, Matt Seitz (matseitz) wrote:
>
> > Where does the git user documentation discuss how git handles symbolic
> > links?
>
> $ git grep symbolic Documentation/ | grep link
> Documentation/RelNotes-1.5.0.2.txt: in place of the symbolic link. The default strategy,
> Documentation/RelNotes-1.5.0.2.txt: that was pointed at by the symbolic link. Both of these
> Documentation/RelNotes-1.5.0.2.txt: when changes to a symbolic link conflicted. It should have
> Documentation/RelNotes-1.5.0.2.txt: file the symbolic link pointed at.
> Documentation/RelNotes-1.5.1.5.txt: directory $PWD points at is a symbolic link.
> Documentation/RelNotes-1.5.1.6.txt: directory $PWD points at is a symbolic link.
> Documentation/RelNotes-1.5.1.txt: in place of the symbolic link. The default strategy,
> Documentation/RelNotes-1.5.1.txt: that was pointed at by the symbolic link. Both of these
> Documentation/RelNotes-1.5.1.txt: when changes to a symbolic link conflicted. It should have
> Documentation/RelNotes-1.5.1.txt: file the symbolic link pointed at.
> Documentation/RelNotes-1.5.3.2.txt: - an untracked symbolic link to a directory made it fart;
Many of these release notes are talking about bugs that we fixed
related to switching between revisions where in one revision the
path was a symlink and in the other revision it was a directory or
a file (or vice-versa).
> Documentation/config.txt: If false, symbolic links are checked out as small plain files that
> Documentation/config.txt: symbolic links. True by default.
> Documentation/git-update-index.txt:to 'false' (see gitlink:git-config[1]), symbolic links are checked out
> Documentation/git-update-index.txt:from symbolic link to regular file.
> Documentation/technical/racy-git.txt:files vs symbolic links) and executable bits (only for regular
These are probably what Matt was looking for.
> Documentation/config.txt: and other symbolic reference files, use symbolic links.
> Documentation/config.txt: expect HEAD to be a symbolic link.
> Documentation/core-tutorial.txt: This is similar to a symbolic link and points at
> Documentation/git-local-fetch.txt: Instead of regular file-to-file copying use symbolic links to the objects
> Documentation/git-symbolic-ref.txt:In the past, `.git/HEAD` was a symbolic link pointing at
> Documentation/git-symbolic-ref.txt:advertised (horrors). Therefore symbolic links are now deprecated
> Documentation/git-update-ref.txt:these symbolic pointers, whether they are symlinks or these
> Documentation/git-update-ref.txt:"regular file symbolic refs". It follows *real* symlinks only
> Documentation/glossary.txt: references are manipulated with the gitlink:git-symbolic-ref[1]
> Documentation/repository-layout.txt: a symbolic link instead of a symref that points at the current
These are all about how Git stores refs, and how HEAD used to be
a symbolic link but has since changed to a symbolic reference...
So less useful to what he was looking for I think.
--
Shawn.
^ permalink raw reply
* Re: Symbolic link documentation
From: Shawn O. Pearce @ 2007-09-20 17:25 UTC (permalink / raw)
To: Matt Seitz (matseitz); +Cc: git
In-Reply-To: <70952A932255A2489522275A628B97C3052E98EB@xmb-sjc-233.amer.cisco.com>
"Matt Seitz (matseitz)" <matseitz@cisco.com> wrote:
> Where does the git user documentation discuss how git handles symbolic
> links?
About the only mention I can find appears to be in git-config where
it talks a little bit about the core.symlinks configuration option.
But in general Git treats symlinks as though they were plain text
files. The content of the "file" is the target of the symlink.
Use `git-add link` to stage the symlink for the next commit (just
like a file), `git-mv` to rename a symlink (just like a file), etc.
Editing a symlink to point to a new target is just a matter of
using the OS' tools (e.g. `ln -sf newdst link`).
So long as core.symlinks isn't set or is set to true Git will
recreate the symlink upon checkout of the revision, just like it
recreates plain text files.
--
Shawn.
^ permalink raw reply
* Re: Symbolic link documentation
From: Johannes Schindelin @ 2007-09-20 17:20 UTC (permalink / raw)
To: Matt Seitz (matseitz); +Cc: git
In-Reply-To: <70952A932255A2489522275A628B97C3052E98EB@xmb-sjc-233.amer.cisco.com>
Hi,
On Thu, 20 Sep 2007, Matt Seitz (matseitz) wrote:
> Where does the git user documentation discuss how git handles symbolic
> links?
$ git grep symbolic Documentation/ | grep link
Documentation/RelNotes-1.5.0.2.txt: in place of the symbolic link. The default strategy,
Documentation/RelNotes-1.5.0.2.txt: that was pointed at by the symbolic link. Both of these
Documentation/RelNotes-1.5.0.2.txt: when changes to a symbolic link conflicted. It should have
Documentation/RelNotes-1.5.0.2.txt: file the symbolic link pointed at.
Documentation/RelNotes-1.5.1.5.txt: directory $PWD points at is a symbolic link.
Documentation/RelNotes-1.5.1.6.txt: directory $PWD points at is a symbolic link.
Documentation/RelNotes-1.5.1.txt: in place of the symbolic link. The default strategy,
Documentation/RelNotes-1.5.1.txt: that was pointed at by the symbolic link. Both of these
Documentation/RelNotes-1.5.1.txt: when changes to a symbolic link conflicted. It should have
Documentation/RelNotes-1.5.1.txt: file the symbolic link pointed at.
Documentation/RelNotes-1.5.3.2.txt: - an untracked symbolic link to a directory made it fart;
Documentation/config.txt: If false, symbolic links are checked out as small plain files that
Documentation/config.txt: symbolic links. True by default.
Documentation/config.txt: and other symbolic reference files, use symbolic links.
Documentation/config.txt: expect HEAD to be a symbolic link.
Documentation/core-tutorial.txt: This is similar to a symbolic link and points at
Documentation/git-local-fetch.txt: Instead of regular file-to-file copying use symbolic links to the objects
Documentation/git-symbolic-ref.txt:In the past, `.git/HEAD` was a symbolic link pointing at
Documentation/git-symbolic-ref.txt:advertised (horrors). Therefore symbolic links are now deprecated
Documentation/git-update-index.txt:to 'false' (see gitlink:git-config[1]), symbolic links are checked out
Documentation/git-update-index.txt:from symbolic link to regular file.
Documentation/git-update-ref.txt:these symbolic pointers, whether they are symlinks or these
Documentation/git-update-ref.txt:"regular file symbolic refs". It follows *real* symlinks only
Documentation/glossary.txt: references are manipulated with the gitlink:git-symbolic-ref[1]
Documentation/repository-layout.txt: a symbolic link instead of a symref that points at the current
Documentation/technical/racy-git.txt:files vs symbolic links) and executable bits (only for regular
Hth,
Dscho
^ permalink raw reply
* Symbolic link documentation
From: Matt Seitz (matseitz) @ 2007-09-20 17:17 UTC (permalink / raw)
To: git
[-- Attachment #1: Type: text/plain, Size: 170 bytes --]
Where does the git user documentation discuss how git handles symbolic
links?
--
Matt Seitz
Manager, File System Virtualization
Cisco Systems, Inc.
.:|:.:|:.
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: Matt Seitz.vcf --]
[-- Type: text/x-vcard; name="Matt Seitz.vcf", Size: 410 bytes --]
BEGIN:VCARD
VERSION:2.1
N:Seitz;Matt
FN:Matt Seitz
ORG:Cisco Systems, Inc
TITLE:Manager
TEL;WORK;VOICE:408-200-8000
ADR;WORK:;;3975 Freedom Circle, Floor 8;Santa Clara;CA;95054;United States of America
LABEL;WORK;ENCODING=QUOTED-PRINTABLE:3975 Freedom Circle, Floor 8=0D=0ASanta Clara, CA 95054=0D=0AUnited States o=
f America
EMAIL;PREF;INTERNET:matseitz@cisco.com
REV:20070709T234049Z
END:VCARD
^ permalink raw reply
* Re: [PATCH] Prevent using bold text in entire gui for some fonts sometimes
From: Shawn O. Pearce @ 2007-09-20 17:01 UTC (permalink / raw)
To: Simon Sasburg; +Cc: git
In-Reply-To: <981e6de60709181533o24ef0e45w7925070b5e78ef56@mail.gmail.com>
Simon Sasburg <simon.sasburg@gmail.com> wrote:
> When I first saw git-gui on windows, I noticed it wasn't using ugly
> bold fonts for it's entire gui like it was in linux. I came up with
> the following patch to fix this there.
>
> And it worked, trange thing was, even git-gui without this patch
> applied was using normal fonts now. The patch didn't seem to make any
> difference for me anymore. So I chalked this up to weirdness of my
> system.
>
> Yesterday though a saw that a friends git-gui was showing the same
> problem with the entire gui being in bold text. And this patch fixed
> it.
>
> So its a bit weird that this patch seemed to have 'permanent' effects
> for me, even after it was reverted.... but on the other hand it's
> really trivial.
Yea, I can't explain that either. But this patch is really trivial
so I'm applying it anyway. Doesn't break anyone who was already
using a normal weight on their font and it should prevent others
from picking up bold everywhere. Thanks.
--
Shawn.
^ permalink raw reply
* Re: [PATCH 1/5] strbuf API additions and enhancements.
From: Jeff King @ 2007-09-20 16:10 UTC (permalink / raw)
To: Kalle Olavi Niemitalo; +Cc: git
In-Reply-To: <87lkb1iz0i.fsf@Astalo.kon.iki.fi>
On Thu, Sep 20, 2007 at 10:20:29AM +0300, Kalle Olavi Niemitalo wrote:
> Normative text in 7.15p3 confirms this: "The object ap may be
> passed as an argument to another function; if that function
> invokes the va_arg macro with parameter ap, the value of ap in
> the calling function is indeterminate and shall be passed to the
> va_end macro prior to any further reference to ap."
>
> Therefore va_copy is needed here, at least in principle.
Not just in principle; a few months ago, I ran afoul of the same issue
using gcc + glibc6, so it is a real problem for our target platforms
(sorry, I don't have a test case anymore, but I recall getting
undefined-ish behavior from my print statements).
-Peff
^ permalink raw reply
* Re: [PATCH] [git-p4] Detect exec bit in more cases.
From: David Brown @ 2007-09-20 15:16 UTC (permalink / raw)
To: Simon Hausmann; +Cc: git
In-Reply-To: <200709192103.53526.simon@lst.de>
On Wed, Sep 19, 2007 at 09:03:50PM +0200, Simon Hausmann wrote:
>On Wednesday 19 September 2007 20:15:03 David Brown wrote:
>> git-p4 was missing the execute bit setting if the file had other attribute
>> bits set.
>> ---
>I'm fine with this, so unless you find a better way:
>
>Acked-By: Simon Hausmann <simon@lst.de>
I sent out an improved version of this patch yesterday
<1190232768445-git-send-email-git@davidb.org> that I'd like to get
approved. I guess I'm not quite sure what happens at this point with a
patch.
Thanks,
David
^ permalink raw reply
* Re: [RFC] Convert builin-mailinfo.c to use The Better String Library.
From: Andreas Ericsson @ 2007-09-20 14:56 UTC (permalink / raw)
To: Steven Burns; +Cc: git
In-Reply-To: <fctuo4$t93$1@sea.gmane.org>
Steven Burns wrote:
>> a = b + "/share/" + c + serial_num;
>>
>> where you can have absolutely no idea how many memory allocations are
>> done, due to type coercions, overloaded operators
>
> You are assuming (incorrectly) everybody will use dumb string classes like
> that.
>
Not really. He said "It's way to easy for idiots to do something like this:"
just prior to the line you quoted. I wholeheartedly agree, but in no way
does anyone assume that everybody will use dumb string classes.
I'm sure it's perfectly possible to write properly functioning programs in
C++. I know I use a few of them myself. That doesn't change the fact that
it's an idiot-friendly language to write code in that's extremely annoying
for competent programmers to fix up later.
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
^ permalink raw reply
* Re: [PATCH 0/3] the return of the strbuf
From: Shawn O. Pearce @ 2007-09-20 14:19 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Pierre Habouzit, git
In-Reply-To: <Pine.LNX.4.64.0709201248400.28395@racer.site>
Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
> On Mon, 17 Sep 2007, Shawn O. Pearce wrote:
>
> > $ git log --pretty=format:%an --since=6.months.ago -- fast-import.c \
> > | sort | uniq -c | sort -nr
...
> FWIW I'd do
>
> git shortlog -n --since=6.months.ago HEAD -- fast-import.c|grep "^[A-Z]"
>
> instead...
Yea, Junio pointed out how stupid I was being on #git. I don't
know why I didn't think of using shortlog here as this is one
of the things it was built for. Whatever. I forgot my git-fu
on Monday. :)
--
Shawn.
^ permalink raw reply
* Re: [RFC] Convert builin-mailinfo.c to use The Better String Library.
From: Steven Burns @ 2007-09-20 14:06 UTC (permalink / raw)
To: git
In-Reply-To: <20070907061554.GB30161@thunk.org>
> a = b + "/share/" + c + serial_num;
>
> where you can have absolutely no idea how many memory allocations are
> done, due to type coercions, overloaded operators
You are assuming (incorrectly) everybody will use dumb string classes like
that.
It is very possible to create a string class that instead of allocating all
those strings simply concatenates tiny temporary objects and performs one
single operation in the end. Not to mention those temporaries are optimized
away by any decent compiler and you end up with code that runs at the same
speed as your C code.
I've done it, many other programmers have. As a reference, I'd like to
mention Matthew Wilson's chapter on efficient string concatenation in his
book "Imperfect C++". He uses expression templates (that's the technique I
just described) and gets impressive results.
With that said, your point is valid. 90% of C++ programmers will use string
classes that are very inefficient for concatenation, starting with
std::string which I hate for that reason (and many other reasons, e.g. you
have to
resort to Boost for mundane things like trimming)
Steven Burns
"Theodore Tso" <tytso@mit.edu> wrote in message
news:20070907061554.GB30161@thunk.org...
> On Thu, Sep 06, 2007 at 08:09:23PM -0700, Dmitry Kakurin wrote:
>> > Total BS. The string/memory management is not at all relevant. Look at
>> > the
>> > code (I bet you didn't). This isn't the important, or complex part.
>>
>> Not only have I looked at the code, I've also debugged it quite a bit.
>> Granted most of my problems had to do with handling paths on Windows
>> (i.e. string manipulations).
>
> I consider string manipulation to be one of the places where C++ is a
> total disaster. It's way to easy for idiots to do something like this:
>
> a = b + "/share/" + c + serial_num;
>
> where you can have absolutely no idea how many memory allocations are
> done, due to type coercions, overloaded operators (good God, you can
> overload the comma operator in C++!!!), and then when something like
> that ends up in an inner loop, the result is a disaster from a
> performance point of view, and it's not even obvious *why*!
>
>> My goal is to *use* Git. When something does not work *for me* I want
>> to be able to fix it (and contribute the fix) in *shortest time
>> possible* and with *minimal efforts*. As for me it's a diversion from
>> my main activities.
>
> Yes, and if you contribute something the shortest time possible, and
> it ends up being crap, who gets to rewrite it and fix it? I've seen
> too many C++ programs which get this kind of crap added, and it's not
> noticed right away (because C++ is really good at hiding such
> performance killers so they are not visible), and then later on, it's
> even harder to find the performance problems and fix them.
>
>> Now, I realize that I'm a very infrequent contributor to Git, but I
>> want my opinion to be heard.
>
> And if git were written in C++, it's precisely the infrequent
> contributors (who are in a hurry, who only care about the quick hack
> to get them going, and not about the long-term maintainability and
> performance of the package) that are be in the position to do the
> most damage...
>
> - Ted
^ permalink raw reply
* Re: [PATCH 0/2] add support for per branch merge policy
From: Lars Hjemli @ 2007-09-20 13:38 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Junio C Hamano, git
In-Reply-To: <Pine.LNX.4.64.0709201424270.28395@racer.site>
[...joining two posts in one...]
On 9/20/07, Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
> > On 9/20/07, Lars Hjemli <hjemli@gmail.com> wrote:
> > > branch.<name>.integrationonly
> >
> > Btw: we might want to call this 'branch.<name>.mergepolicy' with the
> > possible values 'synchronize' and 'integrate'.
>
> IMHO this is way too limiting.
> Why not have something like branch.<name>.mergeOptions instead?
Yeah, that would be more powerful, I'll give it a try.
--
larsh
^ permalink raw reply
* Re: [PATCH 2/2] add support for branch.<name>.integrationonly
From: Matthieu Moy @ 2007-09-20 13:36 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Lars Hjemli, Junio C Hamano, git
In-Reply-To: <Pine.LNX.4.64.0709201413440.28395@racer.site>
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> On Thu, 20 Sep 2007, Lars Hjemli wrote:
>
>> +branch.<name>.integrationonly::
>
> Why not have something like branch.<name>.mergeOptions instead?
Why make it plural? I agree that it's better to have a multiple values
option than having just "true/false", which makes it more extensible,
but I don't understand the kind of things you could put here that
wouldn't be better located in a separate configuration option.
--
Matthieu
^ permalink raw reply
* Re: [PATCH 0/2] add support for per branch merge policy
From: Johannes Schindelin @ 2007-09-20 13:24 UTC (permalink / raw)
To: Lars Hjemli; +Cc: Junio C Hamano, git
In-Reply-To: <8c5c35580709200607s428e898ay32fd4cdad30f096e@mail.gmail.com>
Hi,
On Thu, 20 Sep 2007, Lars Hjemli wrote:
> On 9/20/07, Lars Hjemli <hjemli@gmail.com> wrote:
> > branch.<name>.integrationonly
>
> Btw: we might want to call this 'branch.<name>.mergepolicy' with the
> possible values 'synchronize' and 'integrate'.
IMHO this is way too limiting.
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH 2/2] add support for branch.<name>.integrationonly
From: Johannes Schindelin @ 2007-09-20 13:14 UTC (permalink / raw)
To: Lars Hjemli; +Cc: Junio C Hamano, git
In-Reply-To: <1190292789-16203-3-git-send-email-hjemli@gmail.com>
Hi,
On Thu, 20 Sep 2007, Lars Hjemli wrote:
> +branch.<name>.integrationonly::
Why not have something like branch.<name>.mergeOptions instead?
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH] Add git-rev-list --invert-match
From: Johannes Schindelin @ 2007-09-20 13:12 UTC (permalink / raw)
To: Bart Trojanowski; +Cc: git
In-Reply-To: <20070920123849.GD12076@jukie.net>
Hi,
On Thu, 20 Sep 2007, Bart Trojanowski wrote:
> * Johannes Schindelin <Johannes.Schindelin@gmx.de> [070920 06:34]:
> > On Wed, 19 Sep 2007, Bart Trojanowski wrote:
> > > git log --invert-match --grep="uninteresting"
> >
> > IMHO this is only half a solution. Some of us want to say "git log
> > --grep=this --but-not-(in-the-whole-message) --grep=that".
>
> I have noticed that unique negation flags are getting scarce... we
> already have --reverse, --inverse, and --not mean something elsewhere.
> --but-not maybe be good.
>
> I also agree that git-grep could use this extension.
>
> Anyways, I can see four solutions for adding "show me this but not that"
> functionality to git-rev-list:
>
> 1) adding a --but-not flag, as you suggested. It separates positive
> matches that precede it with negative matches that follow.
>
> Example:
> git log --grep=this --but-not --grep=that --committer="${MY_EMAIL}"
That is basically the approach taken by
http://article.gmane.org/gmane.comp.version-control.git/51874
(Yes, since you refused to search in the mailing list archives, I did it
for you... this time!)
> 2) Adding --not-grep, --not-author, --not-committer which add negative
> matches. Maybe even --grep!=PATTERN, --author!=PATTERN, ...
>
> Example:
> git log --grep=this --not-grep=that --committer!="${MY_EMAIL}"
That sounds sensible.
> 3) Extending the PATTERN we accept in --grep, --author, and --committer,
> such that a prefix in the pattern tells us how to use the match:
> --grep=!PATTERN
>
> Example:
> git log --grep=this --grep='!that' --committer="!${MY_EMAIL}"
Now you can no longer avoid defining clean semantics: what does that mean?
Does it mean that there is _one_ line that does not have "that" in it, or
is it the complete message?
Further, it probably makes sense to have the option to say _both_: "Find
me a commit that contains Bart in one line, but not Simpson, and that
does not contain the word "Sverdoolaege" at all."
> 4) (going on a limb here) Can this kind of match be done with perl
> regular expressions? Maybe we could use --perl-regexp
>
> Example:
> I've got nothing :)
This time you'll have to find the thread yourself. Hint: search for pcre.
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH 0/2] add support for per branch merge policy
From: Lars Hjemli @ 2007-09-20 13:07 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <1190292789-16203-1-git-send-email-hjemli@gmail.com>
On 9/20/07, Lars Hjemli <hjemli@gmail.com> wrote:
> branch.<name>.integrationonly
Btw: we might want to call this 'branch.<name>.mergepolicy' with the
possible values 'synchronize' and 'integrate'.
--
larsh
^ permalink raw reply
* [PATCH 2/2] add support for branch.<name>.integrationonly
From: Lars Hjemli @ 2007-09-20 12:53 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <1190292789-16203-2-git-send-email-hjemli@gmail.com>
This setting can be used to set --no-ff as default merge policy for
selected branches. There is also a new new merge-option, --ff, which can
be used to override the default.
Signed-off-by: Lars Hjemli <hjemli@gmail.com>
---
Documentation/config.txt | 7 ++++
Documentation/git-svn.txt | 4 ++
Documentation/merge-options.txt | 14 +++++++--
git-merge.sh | 19 ++++++++++-
t/t6029-merge-integration.sh | 64 ++++++++++++++++++++++++++++++++++++++-
5 files changed, 102 insertions(+), 6 deletions(-)
diff --git a/Documentation/config.txt b/Documentation/config.txt
index 015910f..fa7c3c1 100644
--- a/Documentation/config.txt
+++ b/Documentation/config.txt
@@ -337,6 +337,13 @@ branch.<name>.merge::
branch.<name>.merge to the desired branch, and use the special setting
`.` (a period) for branch.<name>.remote.
+branch.<name>.integrationonly::
+ When merging into branch <name>, this setting specifies whether
+ fast-forward merges are disallowed. The setting can be overridden
+ by the --ff and --no-ff options of gitlink:git-merge[1]. See
+ gitlink:git-svn[1] for information about this setting when
+ working with subversion branches. Defaults to false.
+
clean.requireForce::
A boolean to make git-clean do nothing unless given -f or -n. Defaults
to false.
diff --git a/Documentation/git-svn.txt b/Documentation/git-svn.txt
index 619023d..55828a3 100644
--- a/Documentation/git-svn.txt
+++ b/Documentation/git-svn.txt
@@ -487,6 +487,10 @@ merge using the --no-ff option:
$ git reset --hard HEAD@{1} ## undo the fast-forward merge
$ git merge --no-ff <branch>
+Alternatively, one can configure the appropriate local branches to use
+--no-ff as default by setting branch.<name>.integrationonly=true in
+$GIT_DIR/config.
+
DESIGN PHILOSOPHY
-----------------
diff --git a/Documentation/merge-options.txt b/Documentation/merge-options.txt
index b34b888..f83bba9 100644
--- a/Documentation/merge-options.txt
+++ b/Documentation/merge-options.txt
@@ -26,7 +26,15 @@
is used instead (`git-merge-recursive` when merging a single
head, `git-merge-octopus` otherwise).
+--ff::
+ Explicitly allow fast-forward merges. This can be used to
+ override the merge policy of the current branch, as specified
+ by the branch.<branch>.integrationonly configuration setting (see
+ gitlink:git-config[1] for further details).
+
--no-ff::
- Force the creation of a merge commit even when the merge would
- have resolved as a fast-forward operation. See gitlink:git-svn[1]
- for a use-case for this option.
+ Explicitly disallow fast-forward merges. This can be used to
+ override the merge policy of the current branch, as specified
+ by the branch.<branch>.integrationonly configuration setting (see
+ gitlink:git-config[1] for further details, and gitlink:git-svn[1]
+ for a use-case for this option).
diff --git a/git-merge.sh b/git-merge.sh
index 70ca5ff..4775767 100755
--- a/git-merge.sh
+++ b/git-merge.sh
@@ -3,7 +3,7 @@
# Copyright (c) 2005 Junio C Hamano
#
-USAGE='[-n] [--summary] [--no-commit] [--no-ff] [--squash] [-s <strategy>] [-m=<merge-message>] <commit>+'
+USAGE='[-n] [--summary] [--no-commit] [--ff] [--no-ff] [--squash] [-s <strategy>] [-m=<merge-message>] <commit>+'
SUBDIRECTORY_OK=Yes
. git-sh-setup
@@ -23,7 +23,7 @@ no_fast_forward_strategies='subtree ours'
no_trivial_strategies='recursive recur subtree ours'
use_strategies=
-allow_fast_forward=t
+allow_fast_forward=
allow_trivial_merge=t
dropsave() {
@@ -165,6 +165,9 @@ do
merge_msg="$1"
have_message=t
;;
+ --ff)
+ allow_fast_forward=t
+ ;;
--no-ff)
allow_fast_forward=f
;;
@@ -245,6 +248,18 @@ do
done
set x $remoteheads ; shift
+if test -z "$allow_fast_forward"
+then
+ branch=$(git-symbolic-ref HEAD | sed -e 's|^refs/heads/||')
+ integrate=$(git config --bool "branch.$branch.integrationonly")
+ if test -n "$branch" -a "$integrate" = "true"
+ then
+ allow_fast_forward=f
+ else
+ allow_fast_forward=t
+ fi
+fi
+
case "$use_strategies" in
'')
case "$#" in
diff --git a/t/t6029-merge-integration.sh b/t/t6029-merge-integration.sh
index 6ba7dd9..c5ffa34 100755
--- a/t/t6029-merge-integration.sh
+++ b/t/t6029-merge-integration.sh
@@ -31,6 +31,8 @@ test_expect_success 'merge c1' '
'
+test_debug 'gitk'
+
test_expect_success 'merge --no-ff c1' '
git reset --hard c0 &&
@@ -41,6 +43,66 @@ test_expect_success 'merge --no-ff c1' '
'
-test_debug 'gitk &'
+test_debug 'gitk'
+
+test_expect_success 'setup integrationonly' '
+
+ git config branch.master.integrationonly true
+
+'
+
+test_expect_success 'merge c1' '
+
+ git reset --hard c0 &&
+ test_tick &&
+ git merge c1 &&
+ test $c0 = $(git rev-parse HEAD^1) &&
+ test $c1 = $(git rev-parse HEAD^2)
+
+'
+
+test_debug 'gitk'
+
+test_expect_success 'merge c1 --ff' '
+
+ git reset --hard c0 &&
+ test_tick &&
+ git merge --ff c1 &&
+ test $c0 = $(git rev-parse HEAD^) &&
+ test $c1 = $(git rev-parse HEAD)
+
+'
+
+test_debug 'gitk'
+
+test_expect_success 'revert integrationonly' '
+
+ git config branch.master.integrationonly false
+
+'
+
+test_expect_success 'merge c1' '
+
+ git reset --hard c0 &&
+ test_tick &&
+ git merge c1 &&
+ test $c0 = $(git rev-parse HEAD^) &&
+ test $c1 = $(git rev-parse HEAD)
+
+'
+
+test_debug 'gitk'
+
+test_expect_success 'merge c1 --no-ff' '
+
+ git reset --hard c0 &&
+ test_tick &&
+ git merge --no-ff c1 &&
+ test $c0 = $(git rev-parse HEAD^1) &&
+ test $c1 = $(git rev-parse HEAD^2)
+
+'
+
+test_debug 'gitk'
test_done
--
1.5.3.2.82.g75c8d
^ permalink raw reply related
* [PATCH 0/2] add support for per branch merge policy
From: Lars Hjemli @ 2007-09-20 12:53 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
These two patches extends git-merge with the options --ff and --no-ff,
and uses the configuration setting branch.<name>.integrationonly to
select the default policy per branch (it obviously defaults to --ff), as
mentioned in http://article.gmane.org/gmane.comp.version-control.git/41980
This can also be used as a clean solution to the problem related to
fast-forward merges between git-svn tracking branches, especially if
git-svn could be taught to set integrationonly=true on all relevant
branches whenever this setting is undefined.
Diffstat:
Documentation/config.txt | 7 +++
Documentation/git-svn.txt | 17 ++++++
Documentation/merge-options.txt | 13 +++++
git-merge.sh | 30 ++++++++++-
t/t6029-merge-integration.sh | 108 +++++++++++++++++++++++++++++++++++++++
5 files changed, 172 insertions(+), 3 deletions(-)
^ permalink raw reply
* [PATCH 1/2] git-merge: add option --no-ff
From: Lars Hjemli @ 2007-09-20 12:53 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <1190292789-16203-1-git-send-email-hjemli@gmail.com>
This option forces all merges to create a "true" merge commit, i.e. a commit
with multiple parents.
A fast-forward merge will often be considered The Right Thing when working
in a distributed environment, but it doesn't work well when the branches to
be merged originated in subversion and the merge commit will be pushed back
with 'git svn dcommit'. In this case, a fast-forward merge will make git-svn
mistakenly think that the current branch is tracking the merged upstream
branch. But if the merge is created with --no-ff, 'git svn dcommit' will work
as expected (and the history in subversion and git will be equal).
There are also a use-case for --no-ff in 'native git' when integrating topic
branches: if the merge of a topic-branch results in a fast-forward operation,
there will be no way to detect that the topic-branch ever existed. This might
be good or bad dependent on project policy, but both options (ff/no-ff) are
technically sane.
Signed-off-by: Lars Hjemli <hjemli@gmail.com>
---
Documentation/git-svn.txt | 13 +++++++++++
Documentation/merge-options.txt | 5 ++++
git-merge.sh | 13 +++++++++-
t/t6029-merge-integration.sh | 46 +++++++++++++++++++++++++++++++++++++++
4 files changed, 75 insertions(+), 2 deletions(-)
create mode 100755 t/t6029-merge-integration.sh
diff --git a/Documentation/git-svn.txt b/Documentation/git-svn.txt
index e157c6a..619023d 100644
--- a/Documentation/git-svn.txt
+++ b/Documentation/git-svn.txt
@@ -475,6 +475,19 @@ use 'git-svn rebase' to update your work branch instead of 'git pull' or
when committing into SVN, which can lead to merge commits reversing
previous commits in SVN.
+If you use 'git-svn dcommit' to commit your local work to the upstream
+subversion branch, merge commits are usually handled correctly, i.e.
+git-svn will only follow the first parent of each merge commit and create
+a single subversion revision for each of them. An exception is when two
+subversion branches has been merged locally and the merge ended up as a
+fast-forward operation. This will make git-svn believe that there are no
+local changes to dcommit. To work around this issue, one can redo the
+merge using the --no-ff option:
+
+ $ git reset --hard HEAD@{1} ## undo the fast-forward merge
+ $ git merge --no-ff <branch>
+
+
DESIGN PHILOSOPHY
-----------------
Merge tracking in Subversion is lacking and doing branched development
diff --git a/Documentation/merge-options.txt b/Documentation/merge-options.txt
index d64c259..b34b888 100644
--- a/Documentation/merge-options.txt
+++ b/Documentation/merge-options.txt
@@ -25,3 +25,8 @@
If there is no `-s` option, a built-in list of strategies
is used instead (`git-merge-recursive` when merging a single
head, `git-merge-octopus` otherwise).
+
+--no-ff::
+ Force the creation of a merge commit even when the merge would
+ have resolved as a fast-forward operation. See gitlink:git-svn[1]
+ for a use-case for this option.
diff --git a/git-merge.sh b/git-merge.sh
index 3a01db0..70ca5ff 100755
--- a/git-merge.sh
+++ b/git-merge.sh
@@ -3,7 +3,7 @@
# Copyright (c) 2005 Junio C Hamano
#
-USAGE='[-n] [--summary] [--no-commit] [--squash] [-s <strategy>] [-m=<merge-message>] <commit>+'
+USAGE='[-n] [--summary] [--no-commit] [--no-ff] [--squash] [-s <strategy>] [-m=<merge-message>] <commit>+'
SUBDIRECTORY_OK=Yes
. git-sh-setup
@@ -165,6 +165,9 @@ do
merge_msg="$1"
have_message=t
;;
+ --no-ff)
+ allow_fast_forward=f
+ ;;
-*) usage ;;
*) break ;;
esac
@@ -444,7 +447,13 @@ done
# auto resolved the merge cleanly.
if test '' != "$result_tree"
then
- parents=$(git show-branch --independent "$head" "$@" | sed -e 's/^/-p /')
+ if test "$allow_fast_forward" = "f"
+ then
+ parents=$(git rev-parse "$head" "$@")
+ else
+ parents=$(git show-branch --independent "$head" "$@")
+ fi
+ parents=$(echo "$parents" | sed -e 's/^/-p /')
result_commit=$(printf '%s\n' "$merge_msg" | git commit-tree $result_tree $parents) || exit
finish "$result_commit" "Merge made by $wt_strategy."
dropsave
diff --git a/t/t6029-merge-integration.sh b/t/t6029-merge-integration.sh
new file mode 100755
index 0000000..6ba7dd9
--- /dev/null
+++ b/t/t6029-merge-integration.sh
@@ -0,0 +1,46 @@
+#!/bin/sh
+
+test_description='merge --no-ff'
+
+. ./test-lib.sh
+
+test_expect_success setup '
+ >file &&
+ git add file &&
+ test_tick &&
+ git commit -m initial &&
+ git tag c0 &&
+ c0=$(git rev-parse c0)
+
+ echo second >file &&
+ git add file &&
+ test_tick &&
+ git commit -m second &&
+ git tag c1 &&
+ c1=$(git rev-parse c1)
+ git branch test
+'
+
+test_expect_success 'merge c1' '
+
+ git reset --hard c0 &&
+ test_tick &&
+ git merge c1 &&
+ test $c0 = $(git rev-parse HEAD^) &&
+ test $c1 = $(git rev-parse HEAD)
+
+'
+
+test_expect_success 'merge --no-ff c1' '
+
+ git reset --hard c0 &&
+ test_tick &&
+ git merge --no-ff c1 &&
+ test $c0 = $(git rev-parse HEAD^1) &&
+ test $c1 = $(git rev-parse HEAD^2)
+
+'
+
+test_debug 'gitk &'
+
+test_done
--
1.5.3.2.82.g75c8d
^ permalink raw reply related
* Re: [PATCH] Add git-rev-list --invert-match
From: Bart Trojanowski @ 2007-09-20 12:38 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git
In-Reply-To: <Pine.LNX.4.64.0709201132381.28395@racer.site>
* Johannes Schindelin <Johannes.Schindelin@gmx.de> [070920 06:34]:
> On Wed, 19 Sep 2007, Bart Trojanowski wrote:
> > git log --invert-match --grep="uninteresting"
>
> IMHO this is only half a solution. Some of us want to say "git log
> --grep=this --but-not-(in-the-whole-message) --grep=that".
I have noticed that unique negation flags are getting scarce... we
already have --reverse, --inverse, and --not mean something elsewhere.
--but-not maybe be good.
I also agree that git-grep could use this extension.
Anyways, I can see four solutions for adding "show me this but not that"
functionality to git-rev-list:
1) adding a --but-not flag, as you suggested. It separates positive
matches that precede it with negative matches that follow.
Example:
git log --grep=this --but-not --grep=that --committer="${MY_EMAIL}"
2) Adding --not-grep, --not-author, --not-committer which add negative
matches. Maybe even --grep!=PATTERN, --author!=PATTERN, ...
Example:
git log --grep=this --not-grep=that --committer!="${MY_EMAIL}"
3) Extending the PATTERN we accept in --grep, --author, and --committer,
such that a prefix in the pattern tells us how to use the match:
--grep=!PATTERN
Example:
git log --grep=this --grep='!that' --committer="!${MY_EMAIL}"
4) (going on a limb here) Can this kind of match be done with perl
regular expressions? Maybe we could use --perl-regexp
Example:
I've got nothing :)
Personally I am currently in favour of 2. It seems intuitive, and
unlike option 3, the '!' cannot clash with the pattern. Although 3 has
the bonus of allowing other flags like extended regexp, perl regexp,
case insensitive, negation, etc.
Comments?
-Bart
--
WebSig: http://www.jukie.net/~bart/sig/
^ permalink raw reply
* Re: [PATCH] Add git-rev-list --invert-match
From: Bart Trojanowski @ 2007-09-20 12:18 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vbqbym15x.fsf@gitster.siamese.dyndns.org>
* Junio C Hamano <gitster@pobox.com> [070920 00:05]:
> > +--invert-match::
> > +
> > + Show those parts of history that do not match any of the regular
> > + expression patterns.
> > +
>
> Tabs and spaces?
Noted. Will fix after I address Johannes' request.
> I am afraid people may not understand what "any of the regular
> expression patterns" means. How about being a bit more
> explicit, like this?
>
> When filtering the commits based on log message (`--grep`)
> or people (`--author` and `--committer`), show commits
> that do not match the criteria.
Yes, that sounds better.
Thanks,
-Bart
--
WebSig: http://www.jukie.net/~bart/sig/
^ permalink raw reply
* Re: [PATCH 0/3] the return of the strbuf
From: Johannes Schindelin @ 2007-09-20 11:49 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: Pierre Habouzit, git
In-Reply-To: <20070918035721.GL3099@spearce.org>
Hi,
On Mon, 17 Sep 2007, Shawn O. Pearce wrote:
> $ git log --pretty=format:%an --since=6.months.ago -- fast-import.c \
> | sort | uniq -c | sort -nr
> 14 Shawn O. Pearce
> 3 Pierre Habouzit
> 3 Junio C Hamano
> 2 Simon Hausmann
> 2 Alex Riesen
> 1 Theodore Ts'o
> 1 Sven Verdoolaege
> 1 Sami Farin
> 1 Nicolas Pitre
> 1 Luiz Fernando N. Capitulino
> 1 Dana L. How
FWIW I'd do
git shortlog -n --since=6.months.ago HEAD -- fast-import.c|grep "^[A-Z]"
instead...
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH 2/5] Refactor struct transport_ops inlined into struct transport
From: Johannes Schindelin @ 2007-09-20 10:59 UTC (permalink / raw)
To: Daniel Barkalow; +Cc: Shawn O. Pearce, Junio C Hamano, git
In-Reply-To: <Pine.LNX.4.64.0709192226150.21941@iabervon.org>
Hi,
On Wed, 19 Sep 2007, Daniel Barkalow wrote:
> On Wed, 19 Sep 2007, Johannes Schindelin wrote:
>
> > On Wed, 19 Sep 2007, Shawn O. Pearce wrote:
> >
> > > diff --git a/transport.c b/transport.c
> > > index cc76e3f..d8458dc 100644
> > > --- a/transport.c
> > > +++ b/transport.c
> > > @@ -44,8 +44,6 @@ static int disconnect_walker(struct transport *transport)
> > > return 0;
> > > }
> > >
> > > -static const struct transport_ops rsync_transport;
> > > -
> > > static int curl_transport_push(struct transport *transport, int refspec_nr, const char **refspec, int flags) {
> > > const char **argv;
> > > int argc;
> > > @@ -431,18 +406,31 @@ struct transport *transport_get(struct remote *remote, const char *url)
> > > ret->url = url;
> > >
> > > if (!prefixcmp(url, "rsync://")) {
> > > - ret->ops = &rsync_transport;
> > > + /* not supported; don't populate any ops */
> > > +
> >
> > That is sneaky. What are the reasons to remove rsync support? I know it
> > is deprecated, but I'd still like to have it, especially for initial
> > clones on small-RAMed machines.
>
> It never got implemented in a way called from C. This is just removing the
> pointer to the empty struct where support would go. If anybody knows
> enough about interfacing with rsync to write the necessary functions, it
> can be restored.
Okay, will do once I find the time.
Ciao,
Dscho
^ 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