* Re: [msysGit] [FYI][PATCH] Customizing the WinGit installer
From: Johannes Schindelin @ 2008-10-06 14:22 UTC (permalink / raw)
To: Petr Baudis; +Cc: msysgit, git
In-Reply-To: <20081003122727.GE10360@machine.or.cz>
Hi,
On Fri, 3 Oct 2008, Petr Baudis wrote:
> -InfoBeforeFile=gpl-2.0.rtf
I'd rather keep it in, especially in a corporate environment.
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH] git init: --bare/--shared overrides system/global config
From: Shawn O. Pearce @ 2008-10-06 14:14 UTC (permalink / raw)
To: Deskin Miller; +Cc: git
In-Reply-To: <20081005194412.GE3052@riemann.deskinm.fdns.net>
Deskin Miller <deskinm@umich.edu> wrote:
> From b6144562983703079a1eba8cdac3506c18d751a3 Mon Sep 17 00:00:00 2001
> From: Deskin Miller <deskinm@umich.edu>
> Date: Sat, 4 Oct 2008 20:07:44 -0400
FWIW please don't include these lines in the commit message part
of the patch email. The only reason to include a "From: blah" line
(the 2nd one above) is when the name and/or email address that you
want to attribute the change to differs from the name/email that
the message is sent from. (E.g. sent from gmail.com but you want
to attribute to umich.edu.)
> If core.bare or core.sharedRepository are set in /etc/gitconfig or
> ~/.gitconfig, then 'git init' will read the values when constructing a
> new config file; [...]
> ---
Yikes.
> diff --git a/builtin-init-db.c b/builtin-init-db.c
> index 8140c12..38e282c 100644
> --- a/builtin-init-db.c
> +++ b/builtin-init-db.c
> @@ -191,6 +194,8 @@ static int create_default_files(const char *template_path)
> copy_templates(template_path);
>
> git_config(git_default_config, NULL);
> + is_bare_repository_cfg = init_is_bare_repository;
> + shared_repository = init_shared_repository;
Is this really the right thing to do? It seems like it would prevent
a user from setting core.sharedRepository = group in their template
and thus always have a shared repository on their system.
I think we should only be using the command line shared option if
it was supplied, but if it was not we should be honoring what we
recieved from git_config().
However I agree that is_bare shouldn't be inherited from the config.
Its a per-repository attribute and no matter what the user asked
for in their /etc/gitconfig or ~/.gitconfig we should correctly
set it for this current repository.
> diff --git a/t/t0001-init.sh b/t/t0001-init.sh
> index 620da5b..6a6bca0 100755
> --- a/t/t0001-init.sh
> +++ b/t/t0001-init.sh
> @@ -167,4 +167,21 @@ test_expect_success 'init with --template (blank)' '
> ! test -f template-blank/.git/info/exclude
> '
>
> +test_expect_success 'init --bare/--shared overrides system/global config' '
> + (
> + HOME="`pwd`" &&
> + export HOME &&
> + test_config="$HOME"/.gitconfig &&
> + unset GIT_CONFIG_NOGLOBAL &&
> + git config -f "$test_config" core.bare false &&
> + git config -f "$test_config" core.sharedRepository 0640 &&
> + mkdir init-bare-shared-override &&
> + cd init-bare-shared-override &&
> + git init --bare --shared=0666
> + ) &&
> + check_config init-bare-shared-override true unset &&
> + test 0666 = \
> + `git config -f init-bare-shared-override/config core.sharedRepository`
> +'
A second related test would be a ~/.gitconfig which sets
core.sharedRepository = 0666 and then does "git init". I think
the right outcome is a repository which has that set.
--
Shawn.
^ permalink raw reply
* Re: [PATCH] Use "git_config_string" to simplify "remote.c" code in "handle_config"
From: Johannes Schindelin @ 2008-10-06 14:13 UTC (permalink / raw)
To: David Bryson; +Cc: git
In-Reply-To: <20081003033937.GA11594@eratosthenes.cryptobackpack.org>
Hi,
On Thu, 2 Oct 2008, David Bryson wrote:
>
> Signed-off-by: David Bryson <david@statichacks.org>
>
> I tried to keep with the naming/coding conventions that I found in
> remote.c. Feedback welcome.
>
> ---
Usually this comment goes after the --- but other than that, the form is
as perfect as you can wish for.
> @@ -314,15 +315,15 @@ static int handle_config(const char *key, const char *value, void *cb)
> return 0;
> branch = make_branch(name, subkey - name);
> if (!strcmp(subkey, ".remote")) {
> - if (!value)
> - return config_error_nonbool(key);
> - branch->remote_name = xstrdup(value);
> + if (git_config_string(&v, key, value) )
> + return -1;
> + branch->remote_name = v;
What is the reason not to write
if (git_config_string(&branch->remote_name, key, value))
return -1;
? (Also note that we do not like the space between the two closing
parentheses.)
Ciao,
Dscho
^ permalink raw reply
* Re: Repairing fatal: ref HEAD is not a symbolic ref (git checkout of svn remote)
From: Shawn O. Pearce @ 2008-10-06 14:02 UTC (permalink / raw)
To: Jeff Kowalczyk; +Cc: git
In-Reply-To: <pan.2008.10.06.14.00.57.104051@yahoo.com>
Jeff Kowalczyk <jtk@yahoo.com> wrote:
> To test a particular upstream revision, on a git svn remote checkout (i.e.
> branches/1.2, 76c7af2...), I checked out the equivalent of HEAD^^ (git
> checkout 4a3d99c0c9).
>
> Now back at the branch tip, I get fatal: ref HEAD is not a symbolic ref
> on git svn rebase:
>
> (4a3d99c...) $ git checkout 76c7af2
> HEAD is now at 76c7af2... Minor changes to CONTRIBUTORS
> (76c7af2...) $ git svn rebase
> fatal: ref HEAD is not a symbolic ref Current branch HEAD is up to date.
> Segmentation fault
>
> How can I manually correct ref HEAD?
git checkout whateverbranchyouwereonbefore
git svn rebase
--
Shawn.
^ permalink raw reply
* Repairing fatal: ref HEAD is not a symbolic ref (git checkout of svn remote)
From: Jeff Kowalczyk @ 2008-10-06 14:00 UTC (permalink / raw)
To: git
To test a particular upstream revision, on a git svn remote checkout (i.e.
branches/1.2, 76c7af2...), I checked out the equivalent of HEAD^^ (git
checkout 4a3d99c0c9).
Now back at the branch tip, I get fatal: ref HEAD is not a symbolic ref
on git svn rebase:
(4a3d99c...) $ git checkout 76c7af2
HEAD is now at 76c7af2... Minor changes to CONTRIBUTORS
(76c7af2...) $ git svn rebase
fatal: ref HEAD is not a symbolic ref Current branch HEAD is up to date.
Segmentation fault
How can I manually correct ref HEAD?
Thanks.
(The segmentation fault is a separate issue)
^ permalink raw reply
* Re: how to restrict commit for a repo
From: Miklos Vajna @ 2008-10-06 13:00 UTC (permalink / raw)
To: Dilip M; +Cc: Git Mailing List
In-Reply-To: <c94f8e120810060509w5eaa9138m92f1df36c9c36db6@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 308 bytes --]
On Mon, Oct 06, 2008 at 05:39:39PM +0530, Dilip M <dilipm79@gmail.com> wrote:
> If I have a repository, how to prevent push from other repo's into
> mine master's? I want to prevent the commits from all developers and
> allow only few ppl to commit to masters..
Have you seen contrib/hooks/update-paranoid?
[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* how to restrict commit for a repo
From: Dilip M @ 2008-10-06 12:09 UTC (permalink / raw)
To: Git Mailing List
Hi all,
I am a new user to GIT. Read few docs in web ..I want to know few things..
If I have a repository, how to prevent push from other repo's into
mine master's? I want to prevent the commits from all developers and
allow only few ppl to commit to masters..
Thanks for sharing the info on this...
--
dm
^ permalink raw reply
* Re: Build bug report: 'make check' needs sparse, but configure doesn't check it
From: Ed Avis @ 2008-10-06 11:28 UTC (permalink / raw)
To: git
In-Reply-To: <20081006065847.GA27516@spearce.org>
Shawn O. Pearce <spearce <at> spearce.org> writes:
>Nah. We're not going to rename the target to "make sparse".
Fair enough. Can I suggest a one line patch to avoid any misunderstanding in
the future?
diff --git a/Makefile b/Makefile
index 3c0664a..c98b921 100644
--- a/Makefile
+++ b/Makefile
@@ -1354,6 +1354,7 @@ check-sha1:: test-sha1$X
./test-sha1.sh
check: common-cmds.h
+ @echo "'make check' runs the 'sparse' tool on all source files; say
'make test' to run the test suite."
for i in *.c; do sparse $(ALL_CFLAGS) $(SPARSE_FLAGS) $$i || exit; done
remove-dashes:
^ permalink raw reply related
* Re: git svn: Bad URL passed to RA layer: Unrecognized URL scheme
From: Thomas Rast @ 2008-10-06 9:47 UTC (permalink / raw)
To: Jeff Kowalczyk; +Cc: git
In-Reply-To: <pan.2008.10.06.02.28.35.643705@yahoo.com>
[-- Attachment #1: Type: text/plain, Size: 776 bytes --]
Jeff Kowalczyk wrote:
> However, each operation ends with a segmentation fault. This is the case
> with all git svn repositories (e.g. several different svn remote hosts).
>
> (master) $ git svn rebase
> M django/core/management/commands/makemessages.py
> M docs/topics/i18n.txt
> r9155 = 4c86e60f62366ac9c3fd9369c17c54801a8f2ea0 (trunk)
> First, rewinding head to replay your work on top of it...
> Fast-forwarded master to refs/remotes/trunk.
> Segmentation fault
Can you try to find out what exactly segfaults here? git-svn is
implemented in Perl, so that means it's either Perl itself (unlikely),
the SVN libraries hooked into Perl, or some git command run by
git-svn.
- Thomas
--
Thomas Rast
trast@{inf,student}.ethz.ch
[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* [QGIT PATCH] Rework the commit confirmation box a bit
From: Abdelrazak Younes @ 2008-10-06 9:11 UTC (permalink / raw)
To: Git Mailing List
The problem was that the dialog was too big for my whenever too many files
were changed. Now, the list of changed files is only shown whenever they are
less than 20; otherwise it is shown in the detailed text accessible though
the 'Show Detail' button.
---
src/commitimpl.cpp | 25 ++++++++++++++++++++-----
1 files changed, 20 insertions(+), 5 deletions(-)
diff --git a/src/commitimpl.cpp b/src/commitimpl.cpp
index 1540947..def5209 100644
--- a/src/commitimpl.cpp
+++ b/src/commitimpl.cpp
@@ -236,17 +236,32 @@ bool CommitImpl::checkConfirm(SCRef msg, SCRef
patchName, SCList selFiles, bool
(git->isStGITStack() ? "refresh top patch with" :
"amend last commit with") :
(git->isStGITStack() ? "create a new patch with" : "commit");
- QString text("Do you want to " + whatToDo + " the following
file(s)?\n\n" +
- selFiles.join("\n") + "\n\nwith the message:\n\n");
+ QString text("Do you want to " + whatToDo);
+
+ bool const fullList = selFiles.size() < 20;
+ if (fullList) {
+ text.append(" the following file(s)?\n\n" + selFiles.join("\n")
+ + "\n\nwith the message:\n\n");
+ } else {
+ text.append(" those " + QString::number(selFiles.size())
+ + " files the with the message:\n\n");
+ }
+
text.append(msg);
if (git->isStGITStack())
text.append("\n\nAnd patch name: " + patchName);
QTextCodec::setCodecForCStrings(tc);
- int but = QMessageBox::question(this, "Commit changes - QGit",
- text, "&Yes", "&No", QString(), 0, 1);
- return (but != 1);
+ QMessageBox msgBox(this);
+ msgBox.setWindowTitle("Commit changes - QGit");
+ msgBox.setText(text);
+ if (!fullList)
+ msgBox.setDetailedText(selFiles.join("\n"));
+ msgBox.setStandardButtons(QMessageBox::Yes | QMessageBox::No);
+ msgBox.setDefaultButton(QMessageBox::Yes);
+
+ return msgBox.exec() != QMessageBox::No;
}
void CommitImpl::pushButtonSettings_clicked() {
--
1.6.0.2.1172.ga5ed0
^ permalink raw reply related
* Re: [PATCH 0/4] diff text conversion filter
From: Johannes Sixt @ 2008-10-06 8:55 UTC (permalink / raw)
To: Jeff King; +Cc: Matthieu Moy, git
In-Reply-To: <20081006065212.GA19175@sigill.intra.peff.net>
Jeff King schrieb:
> On Mon, Oct 06, 2008 at 08:29:10AM +0200, Johannes Sixt wrote:
>
>> Does the series in any way change whether plumbing and porcelain invoke
>> the external diff drivers? I have this particular use-case, which I'd like
>> that still works:
>
> No, it tries to keep the behavior the same as it is now (in 2/4, note
> how the diff driver config reading is split into porcelain and plumbing
> sections). Let me know if you have a test case that doesn't work, or
> that you would like me to try.
A quick check shows that my use-case still works as expected. Thanks.
-- Hannes
^ permalink raw reply
* Re: [EGIT PATCH 3/6] Add a method to get refs by object Id
From: Shawn O. Pearce @ 2008-10-06 8:15 UTC (permalink / raw)
To: Robin Rosenberg; +Cc: git
In-Reply-To: <1223249802-9959-4-git-send-email-robin.rosenberg@dewire.com>
Robin Rosenberg <robin.rosenberg@dewire.com> wrote:
> diff --git a/org.spearce.jgit/src/org/spearce/jgit/lib/Repository.java b/org.spearce.jgit/src/org/spearce/jgit/lib/Repository.java
> index dfce1b8..3fc5236 100644
> --- a/org.spearce.jgit/src/org/spearce/jgit/lib/Repository.java
> +++ b/org.spearce.jgit/src/org/spearce/jgit/lib/Repository.java
> @@ -939,6 +940,33 @@ public String getBranch() throws IOException {
> }
>
> /**
> + * @return a map with all objects referenced by a peeled ref.
> + */
> + public Map<AnyObjectId, List<Ref>> getAllRefsByPeeledObjectId() {
Do we really want to promise List here? Can we make it just
Collection instead?
> + Map<String, Ref> allRefs = getAllRefs();
> + HashMap<AnyObjectId, List<Ref>> ret = new HashMap<AnyObjectId, List<Ref>>(allRefs.size());
> + for (Map.Entry<String,Ref> e : allRefs.entrySet()) {
> + Ref ref = e.getValue();
I think this is cleaner:
for (Ref ref : allRefs.values()) {
as you never use the key.
> + AnyObjectId target = ref.getPeeledObjectId();
> + if (target == null)
> + target = ref.getObjectId();
> + List<Ref> list = ret.get(target);
> + if (list == null) {
> + list = Collections.singletonList(ref);
> + } else {
> + if (list.size() == 1) {
> + ArrayList<Ref> list2 = new ArrayList<Ref>(2);
> + list2.add(list.get(0));
> + list = list2;
> + }
> + list.add(ref);
> + }
> + ret.put(target, list);
Hmm. Putting the list every time is pointless. This is may run
faster because we (on average) only do one hash lookup per target,
not 2:
List<Ref> nl = Collections.singletonList(ref);
List<Ref> ol = ret.put(target, nl);
if (ol != null) {
if (ol.size() == 1) {
nl = new ArrayList<Ref>(2);
nl.add(ol.get(0));
nl.add(ref);
ret.put(target, nl);
} else {
ol.add(ref)
ret.put(target, ol);
}
}
The trick is that most targets have exactly one Ref, so the first
ret.put will return null and we'll never worry about the expansion
cases. In the rare cases where more than one Ref points at the
same object we'll degrade into doing two hash lookups per target,
which is no worse than what you have right now.
--
Shawn.
^ permalink raw reply
* Re: [EGIT PATCH 4/6] Add tags to the graphical history display.
From: Shawn O. Pearce @ 2008-10-06 8:08 UTC (permalink / raw)
To: Robin Rosenberg; +Cc: git
In-Reply-To: <1223249802-9959-5-git-send-email-robin.rosenberg@dewire.com>
FYI, my comments don't fully cover this patch yet.
Robin Rosenberg <robin.rosenberg@dewire.com> wrote:
> diff --git a/org.spearce.jgit/src/org/spearce/jgit/revplot/PlotCommit.java b/org.spearce.jgit/src/org/spearce/jgit/revplot/PlotCommit.java
> index 5a5ef1e..fac89f5 100644
> --- a/org.spearce.jgit/src/org/spearce/jgit/revplot/PlotCommit.java
> +++ b/org.spearce.jgit/src/org/spearce/jgit/revplot/PlotCommit.java
> @@ -58,14 +59,19 @@
>
> PlotCommit[] children;
>
> + Ref[] refs;
> +
> /**
> * Create a new commit.
> *
> * @param id
> * the identity of this commit.
> + * @param tags
> + * the tags associated with this commit, null for no tags
> */
> - protected PlotCommit(final AnyObjectId id) {
> + protected PlotCommit(final AnyObjectId id, final Ref[] tags) {
> super(id);
> + this.refs = tags;
this.refs isn't final. There is no reason to be adding it to the
constructor and having this ripple effect all the way up into the
RevWalk class.
Maybe PlotWalk should override next() and only set PlotCommit.refs on
things returned from super.next()? This way we only do tag lookup
on commits that the filtering rules have said should be shown in
to the application, but the refs should still be inserted prior to
the application seeing the RevCommit.
> @@ -54,6 +66,7 @@
> public PlotWalk(final Repository repo) {
> super(repo);
> super.sort(RevSort.TOPO, true);
> + reverseRefMap = repo.getAllRefsByPeeledObjectId();
I wonder if this shouldn't be done as part of the StartGenerator
(or something like it but specialized for PlotWalk). I only say
that because a reused PlotWalk may want to make sure its ref map
is current with the repository its about to walk against.
> + @Override
> + protected Ref[] getTags(final AnyObjectId commitId) {
> + List<Ref> list = reverseRefMap.get(commitId);
> + Ref[] tags;
> + if (list == null)
> + tags = null;
> + else {
> + if (list != null && list.size() > 1) {
> + Collections.sort(list, new Comparator<Ref>() {
> + public int compare(Ref o1, Ref o2) {
> + try {
> + Object obj1 = getRepository().mapObject(o1.getObjectId(), o1.getName());
> + Object obj2 = getRepository().mapObject(o2.getObjectId(), o2.getName());
> + long t1 = timeof(obj1);
> + long t2 = timeof(obj2);
> + if (t1 > t2)
> + return -1;
> + if (t1 < t2)
> + return 1;
> + return 0;
> + } catch (IOException e) {
> + // ignore
> + return 0;
> + }
> + }
> + long timeof(Object o) {
> + if (o instanceof Commit)
> + return ((Commit)o).getCommitter().getWhen().getTime();
> + if (o instanceof Tag)
> + return ((Tag)o).getTagger().getWhen().getTime();
> + return 0;
You are inside of a PlotWalk, which extends RevWalk, which has very
aggressive caching of RevCommit and RevTag data instances, and very
fast parsers. Much faster than the legacy Commit and Tag classes.
I think we should use the RevCommit and RevTag classes to handle
sorting here. RevCommit already has the committer time cached
and stored in an int. RevCommit probably should learn to do the
same for its "tagger" field. The tiny extra bloat (1 word) that
adds to a RevTag instance is worth it when we consider implementing
something like this and/or git-describe where sorting tags by their
dates is useful.
> + tags = list.toArray(new Ref[list.size()]);
I wonder if using a Ref[] here even makes sense given that the data
is stored in a List<Ref>. I use RevCommit[] inside of RevCommit
generally because the number of entries in the array is 1 or 2 and
the array is smaller than say an ArrayList.
In hindsight those RevCommit[] probably should be a List<RevCommit>
with different list implementations based on the number of parents
needed:
0 parents: Collections.emptyList()
1 parent: Collections.singletonList()
2 parents: some especialized AbstractList subclass
3 parents: ArrayList
I think it would actually use less memory per instance, which is
a huge bonus, but we'd pay a downcasting penalty on each access.
HotSpot is supposed to be really good at removing the downcast
penalty from say java.util.List, but I don't if it can beat a typed
array access.
Sorry I got off on a bit of a tangent here. I'm just trying to
point out that the primary reason I've usd an array before is
probably moot here since the data is already in a List.
> diff --git a/org.spearce.jgit/src/org/spearce/jgit/revwalk/RevWalk.java b/org.spearce.jgit/src/org/spearce/jgit/revwalk/RevWalk.java
> index d7e4c58..41d57c6 100644
> --- a/org.spearce.jgit/src/org/spearce/jgit/revwalk/RevWalk.java
> +++ b/org.spearce.jgit/src/org/spearce/jgit/revwalk/RevWalk.java
> @@ -53,6 +53,7 @@
IMHO this class shouldn't need to be modified.
> @@ -541,7 +542,7 @@ public RevTree lookupTree(final AnyObjectId id) {
> public RevCommit lookupCommit(final AnyObjectId id) {
> RevCommit c = (RevCommit) objects.get(id);
> if (c == null) {
> - c = createCommit(id);
> + c = createCommit(id, getTags(id));
This code is performance critical to commit parsing. Trying to
lookup tags for every commit we evaluate, especially ones that we
will never show in the UI (because they are uninteresting) but that
we still need to parse in order to derive the merge base is just
a huge waste of time.
Same applies for the lookupAny and parseAny methods.
--
Shawn.
^ permalink raw reply
* Re: [EGIT PATCH 2/6] Peel annotated tags when getting all refs
From: Shawn O. Pearce @ 2008-10-06 7:43 UTC (permalink / raw)
To: Robin Rosenberg; +Cc: git
In-Reply-To: <1223249802-9959-3-git-send-email-robin.rosenberg@dewire.com>
FWIW I'm still going through the series. But this jumped out at me.
Robin Rosenberg <robin.rosenberg@dewire.com> wrote:
> For packed refs we got this automatically from packed-refs,
> but for loose tags we have to follow the tags and get the leaf
> object in order to comply with the documentation.
...
> diff --git a/org.spearce.jgit/src/org/spearce/jgit/lib/RefDatabase.java b/org.spearce.jgit/src/org/spearce/jgit/lib/RefDatabase.java
> index 5a1b85f..1ee70d9 100644
> --- a/org.spearce.jgit/src/org/spearce/jgit/lib/RefDatabase.java
> +++ b/org.spearce.jgit/src/org/spearce/jgit/lib/RefDatabase.java
> @@ -271,7 +271,16 @@ private void readOneLooseRef(final Map<String, Ref> avail,
> return;
> }
>
> - ref = new Ref(Ref.Storage.LOOSE, origName, refName, id);
> + Object tt = db.mapObject(id, refName);
> + if (tt != null && tt instanceof Tag) {
> + Tag t = (Tag)tt;
Owwww.
I don't want to be doing peeling of loose annotated tags anytime
we loop through the loose objects. That is just painful and very
expensive. I'd rather the peeling be caused on demand by callers
who need it, but if its done through a method on Repository then
we can push the peeled ObjectId back into the RefDatabase cache.
I'm thinking more like:
Repository db = ...;
...
ObjectId p = ref.getPeeledObjectId()
if (p == null)
p = db.peel(ref)
--
Shawn.
^ permalink raw reply
* Re: Git and tagging hook
From: Andreas Ericsson @ 2008-10-06 7:20 UTC (permalink / raw)
To: Kristis Makris; +Cc: git
In-Reply-To: <1223268332.4072.7.camel@localhost>
Next time, don't include a members-only list in the CC, please. The
usual action when replying to an email on git@vger is to "Reply All",
which doesn't play nicely with such lists and will render one list
archive incomplete (since people will inevitably cull that other
list from their CC's after having sent to it once).
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
^ permalink raw reply
* Re: Git and tagging hook
From: Andreas Ericsson @ 2008-10-06 7:17 UTC (permalink / raw)
To: Kristis Makris; +Cc: git, scmbug-users
In-Reply-To: <1223268332.4072.7.camel@localhost>
Kristis Makris wrote:
> Hello,
>
> It seems that Git (at least v1.5.6) does not offer hooks on tag creation
> (a pre-tag and a post-tag hook). I need such a hook for integrating tag
> activities with an issue-tracker. Is it possible to add this hook ?
>
What you want is probably the post-receive or 'update' hooks on whatever
repository you consider your public watering hole for your project.
Integrating with an issue-tracker from the developers machine would be
utterly stupid, as it would prevent tagging from happening while not
connected.
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
^ permalink raw reply
* Re: [PATCH 2/2] check-attr: Add --stdin-paths option
From: Johannes Sixt @ 2008-10-06 7:09 UTC (permalink / raw)
To: Dmitry Potapov; +Cc: Alexander Gavrilov, git, Shawn O. Pearce, Paul Mackerras
In-Reply-To: <1223173855-6173-2-git-send-email-dpotapov@gmail.com>
Dmitry Potapov schrieb:
> +static void check_attr_stdin_paths(int cnt, struct git_attr_check *check,
> + const char** name)
> +{
> + struct strbuf buf, nbuf;
> +
> + strbuf_init(&buf, 0);
> + strbuf_init(&nbuf, 0);
> + while (strbuf_getline(&buf, stdin, '\n') != EOF) {
> + if (buf.buf[0] == '"') {
> + strbuf_reset(&nbuf);
> + if (unquote_c_style(&nbuf, buf.buf, NULL))
> + die("line is badly quoted");
> + strbuf_swap(&buf, &nbuf);
> + }
> + check_attr(cnt, check, name, buf.buf);
> + }
> + strbuf_release(&buf);
> + strbuf_release(&nbuf);
> +}
> +
We know that you will want to use this feature in gitk to reduce the
number of fork()s. But you've a problem: gitk will first write a path to
git-check-addr's stdin, and then wait for the result on its stdout. But
this is a classic pitfall: You are not guaranteed that something will be
returned from stdout right away due to buffering. The least that is needed
is fflush(stdout) in this loop (after each iteration!) so that gitk sees
some result and does not hang forever.
-- Hannes
^ permalink raw reply
* Re: [PATCH] error out if path is invalid
From: Johannes Sixt @ 2008-10-06 7:02 UTC (permalink / raw)
To: Dmitry Potapov; +Cc: Shawn O. Pearce, git
In-Reply-To: <1223172881-4948-2-git-send-email-dpotapov@gmail.com>
Dmitry Potapov schrieb:
> if (!verify_path(path))
> - return -1;
> + return error("Invalid path '%s'", path);
Look at this change. Didn't the code error out before, too? Same in the
other cases. Hence, your patch subject does not describe the patch. And
I'd appreciate if you could at least show an example in the description
what the patch fixes.
-- Hannes
^ permalink raw reply
* Re: Build bug report: 'make check' needs sparse, but configure doesn't check it
From: Shawn O. Pearce @ 2008-10-06 6:58 UTC (permalink / raw)
To: Ed Avis; +Cc: git
In-Reply-To: <loom.20081005T094301-345@post.gmane.org>
Ed Avis <eda@waniasset.com> wrote:
> Dmitry Potapov <dpotapov <at> gmail.com> writes:
>
> >The whole point of 'make check' is to run 'sparce' on all files.
>
> >If you want to build
> >and to test the resulting binaries then you run 'make test'.
>
> To reduce confusion I suggest renaming the target to 'make sparse'. Then it's
> obvious what it does and it can't get confused with the more common usage of
> 'make check'.
Nah. We're not going to rename the target to "make sparse".
First off that sounds like we are compiling the sparse binary for
the user, and we will never do that. And existing developers who
use "make check" to run sparse are used to that calling convention.
--
Shawn.
^ permalink raw reply
* Re: Files with colons under Cygwin
From: Johannes Sixt @ 2008-10-06 6:54 UTC (permalink / raw)
To: Dmitry Potapov; +Cc: Giovanni Funchal, git, Shawn O. Pearce
In-Reply-To: <20081004233945.GM21650@dpotapov.dyndns.org>
Dmitry Potapov schrieb:
> Subject: [PATCH] correct verify_path for Windows
>
> Colon and backslash in names may be used on Windows to overwrite files
> outside of the working directory.
>
> Signed-off-by: Dmitry Potapov <dpotapov@gmail.com>
> ---
> read-cache.c | 10 ++++++++++
> 1 files changed, 10 insertions(+), 0 deletions(-)
>
> diff --git a/read-cache.c b/read-cache.c
> index 901064b..972592e 100644
> --- a/read-cache.c
> +++ b/read-cache.c
> @@ -701,6 +701,16 @@ inside:
> }
> return 0;
> }
> +#if defined(_WIN32) || defined(__CYGWIN__)
> + /*
> + * There is a bunch of other characters that are not allowed
> + * in Win32 API, but the following two create a security hole
> + * by allowing to overwrite files outside of the working tree,
> + * therefore they are explicitly prohibited.
> + */
> + else if (c == ':' || c == '\\')
> + return 0;
> +#endif
> c = *path++;
> }
> }
IIUC, verify_path() checks paths that were found in the database or the
index. As such, it checks for the integrity of the database. And paths
with backslashes or colons certainly do not violate the database integrity.
More precisely, the exchange of path names between the index and tree
objects (both directions) should not do this new check, nor if a path is
added to the index. The check is only meaningful[*] when a path is read
from the index or a tree object and "applied" to the working directory.
Unfortunately, I think there are lots of places where this happens.
[*] I say "meaningful" and not "necessary" because the situation is just
like when you grab some random SoftwarePackage.tar.gz, and run ./configure
without looking first what it is going to do.
-- Hannes
^ permalink raw reply
* Re: [PATCH 0/4] diff text conversion filter
From: Jeff King @ 2008-10-06 6:52 UTC (permalink / raw)
To: Johannes Sixt; +Cc: Matthieu Moy, git
In-Reply-To: <48E9B036.6090805@viscovery.net>
On Mon, Oct 06, 2008 at 08:29:10AM +0200, Johannes Sixt wrote:
> Does the series in any way change whether plumbing and porcelain invoke
> the external diff drivers? I have this particular use-case, which I'd like
> that still works:
No, it tries to keep the behavior the same as it is now (in 2/4, note
how the diff driver config reading is split into porcelain and plumbing
sections). Let me know if you have a test case that doesn't work, or
that you would like me to try.
-Peff
^ permalink raw reply
* Re: [PATCH 0/4] diff text conversion filter
From: Johannes Sixt @ 2008-10-06 6:29 UTC (permalink / raw)
To: Jeff King; +Cc: Matthieu Moy, git
In-Reply-To: <20081005214114.GA21875@coredump.intra.peff.net>
Jeff King schrieb:
> On Tue, Sep 30, 2008 at 12:45:45PM -0400, Jeff King wrote:
>
>> I am about 90% done cleaning it up for preparation (there is a bit of
>> refactoring, and I want to make sure I get that just right). I'll post
>> it in the next day or so.
>
> Sorry, I didn't get a chance to look at this until today. Patch series
> will follow. It is still missing documentation updates and tests, but I
> wanted to get you something to look at (and as I am proposing a new
> meaning for "diff driver", I would be curious to hear the general
> comments).
>
> This is on top of 'next', because it would otherwise conflict with the
> funcname pattern changes there.
Does the series in any way change whether plumbing and porcelain invoke
the external diff drivers? I have this particular use-case, which I'd like
that still works:
- In .git/info/attributes I have specified a diff driver:
*.doc diff=docdiff
The driver runs a script that literally loads the two version of the
file into MS Word and uses Word's diffing capability.
- git-gui should not use the diff driver. That is, plumbing should bypass
the diff driver and say "Binary files differ". [*]
- Running 'git diff foo.doc', i.e. porcelain, from a command line should
use the diff driver.
[*] I would not mind seeing a simplified textual diff in git-gui.
-- Hannes
^ permalink raw reply
* [PATCH] rebase --no-verify
From: Nanako Shiraishi @ 2008-10-06 5:14 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: git
In-Reply-To: <20081005222654.6117@nanako3.lavabit.com>
It is sometimes desirable to disable the safety net of pre-rebase hook
when the user knows what he is doing (for example, when the original
changes on the branch have not been shown to the public yet).
This teaches --no-verify option to git-rebase, which is similar to the way
pre-commit hook is bypassed by git-commit.
Signed-off-by: Nanako Shiraishi <nanako3@lavabit.com>
---
It probably is better to fix "rebase -i" to share more code with the main
"rebase" script to avoid duplicated run-pre-rebase-hook function, but it
is beyond what I can do right now. Perhaps people more smart and
beautiful than me can help (^_^;)
git-rebase--interactive.sh | 10 +++++++++-
git-rebase.sh | 7 ++++++-
t/t3409-rebase-hook.sh | 16 ++++++++++++++++
3 files changed, 31 insertions(+), 2 deletions(-)
diff --git a/git-rebase--interactive.sh b/git-rebase--interactive.sh
index 3350f90..b0d757d 100755
--- a/git-rebase--interactive.sh
+++ b/git-rebase--interactive.sh
@@ -26,6 +26,7 @@ i,interactive always used (no-op)
continue continue rebasing process
abort abort rebasing process and restore original branch
skip skip current patch and continue rebasing process
+no-verify override pre-rebase hook from stopping the operation
"
. git-sh-setup
@@ -41,6 +42,7 @@ PRESERVE_MERGES=
STRATEGY=
ONTO=
VERBOSE=
+OK_TO_SKIP_PRE_REBASE=
GIT_CHERRY_PICK_HELP=" After resolving the conflicts,
mark the corrected paths with 'git add <paths>', and
@@ -66,7 +68,8 @@ output () {
}
run_pre_rebase_hook () {
- if test -x "$GIT_DIR/hooks/pre-rebase"
+ if test -z "$OK_TO_SKIP_PRE_REBASE" &&
+ test -x "$GIT_DIR/hooks/pre-rebase"
then
"$GIT_DIR/hooks/pre-rebase" ${1+"$@"} || {
echo >&2 "The pre-rebase hook refused to rebase."
@@ -416,6 +419,11 @@ get_saved_options () {
while test $# != 0
do
case "$1" in
+ --no-verify)
+ OK_TO_SKIP_PRE_REBASE=yes
+ ;;
+ --verify)
+ ;;
--continue)
is_standalone "$@" || usage
get_saved_options
diff --git a/git-rebase.sh b/git-rebase.sh
index a30d40c..f2742aa 100755
--- a/git-rebase.sh
+++ b/git-rebase.sh
@@ -34,6 +34,7 @@ set_reflog_action rebase
require_work_tree
cd_to_toplevel
+OK_TO_SKIP_PRE_REBASE=
RESOLVEMSG="
When you have resolved this problem run \"git rebase --continue\".
If you would prefer to skip this patch, instead run \"git rebase --skip\".
@@ -145,7 +146,8 @@ is_interactive () {
}
run_pre_rebase_hook () {
- if test -x "$GIT_DIR/hooks/pre-rebase"
+ if test -z "$OK_TO_SKIP_PRE_REBASE" &&
+ test -x "$GIT_DIR/hooks/pre-rebase"
then
"$GIT_DIR/hooks/pre-rebase" ${1+"$@"} || {
echo >&2 "The pre-rebase hook refused to rebase."
@@ -170,6 +172,9 @@ fi
while test $# != 0
do
case "$1" in
+ --no-verify)
+ OK_TO_SKIP_PRE_REBASE=yes
+ ;;
--continue)
test -d "$dotest" -o -d "$GIT_DIR"/rebase-apply ||
die "No rebase in progress?"
diff --git a/t/t3409-rebase-hook.sh b/t/t3409-rebase-hook.sh
index bc93dda..1f1b850 100755
--- a/t/t3409-rebase-hook.sh
+++ b/t/t3409-rebase-hook.sh
@@ -123,4 +123,20 @@ test_expect_success 'pre-rebase hook stops rebase (2)' '
test 0 = $(git rev-list HEAD...side | wc -l)
'
+test_expect_success 'rebase --no-verify overrides pre-rebase (1)' '
+ git checkout test &&
+ git reset --hard side &&
+ git rebase --no-verify master &&
+ test "z$(git symbolic-ref HEAD)" = zrefs/heads/test &&
+ test "z$(cat git)" = zworld
+'
+
+test_expect_success 'rebase --no-verify overrides pre-rebase (2)' '
+ git checkout test &&
+ git reset --hard side &&
+ EDITOR=true git rebase --no-verify -i master &&
+ test "z$(git symbolic-ref HEAD)" = zrefs/heads/test &&
+ test "z$(cat git)" = zworld
+'
+
test_done
--
1.6.0.2
--
Nanako Shiraishi
http://ivory.ap.teacup.com/nanako3/
^ permalink raw reply related
* [PATCH] Teach rebase -i to honor pre-rebase hook
From: Nanako Shiraishi @ 2008-10-06 5:14 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: git
In-Reply-To: <20081005222654.6117@nanako3.lavabit.com>
The original git-rebase honored pre-rebase hook so that public branches
can be protected from getting rebased, but rebase --interactive ignored
the hook entirely. This fixes it.
Signed-off-by: Nanako Shiraishi <nanako3@lavabit.com>
---
git-rebase--interactive.sh | 11 ++++
git-rebase.sh | 18 ++++---
t/t3409-rebase-hook.sh | 126 ++++++++++++++++++++++++++++++++++++++++++++
3 files changed, 148 insertions(+), 7 deletions(-)
create mode 100755 t/t3409-rebase-hook.sh
diff --git a/git-rebase--interactive.sh b/git-rebase--interactive.sh
index edb6ec6..3350f90 100755
--- a/git-rebase--interactive.sh
+++ b/git-rebase--interactive.sh
@@ -65,6 +65,16 @@ output () {
esac
}
+run_pre_rebase_hook () {
+ if test -x "$GIT_DIR/hooks/pre-rebase"
+ then
+ "$GIT_DIR/hooks/pre-rebase" ${1+"$@"} || {
+ echo >&2 "The pre-rebase hook refused to rebase."
+ exit 1
+ }
+ fi
+}
+
require_clean_work_tree () {
# test if working tree is dirty
git rev-parse --verify HEAD > /dev/null &&
@@ -507,6 +517,7 @@ first and then run 'git rebase --continue' again."
;;
--)
shift
+ run_pre_rebase_hook ${1+"$@"}
test $# -eq 1 -o $# -eq 2 || usage
test -d "$DOTEST" &&
die "Interactive rebase already started"
diff --git a/git-rebase.sh b/git-rebase.sh
index 528b604..a30d40c 100755
--- a/git-rebase.sh
+++ b/git-rebase.sh
@@ -144,6 +144,16 @@ is_interactive () {
done && test -n "$1"
}
+run_pre_rebase_hook () {
+ if test -x "$GIT_DIR/hooks/pre-rebase"
+ then
+ "$GIT_DIR/hooks/pre-rebase" ${1+"$@"} || {
+ echo >&2 "The pre-rebase hook refused to rebase."
+ exit 1
+ }
+ fi
+}
+
test -f "$GIT_DIR"/rebase-apply/applying &&
die 'It looks like git-am is in progress. Cannot rebase.'
@@ -320,13 +330,7 @@ onto_name=${newbase-"$upstream_name"}
onto=$(git rev-parse --verify "${onto_name}^0") || exit
# If a hook exists, give it a chance to interrupt
-if test -x "$GIT_DIR/hooks/pre-rebase"
-then
- "$GIT_DIR/hooks/pre-rebase" ${1+"$@"} || {
- echo >&2 "The pre-rebase hook refused to rebase."
- exit 1
- }
-fi
+run_pre_rebase_hook ${1+"$@"}
# If the branch to rebase is given, that is the branch we will rebase
# $branch_name -- branch being rebased, or HEAD (already detached)
diff --git a/t/t3409-rebase-hook.sh b/t/t3409-rebase-hook.sh
new file mode 100755
index 0000000..bc93dda
--- /dev/null
+++ b/t/t3409-rebase-hook.sh
@@ -0,0 +1,126 @@
+#!/bin/sh
+
+test_description='git rebase with its hook(s)'
+
+. ./test-lib.sh
+
+test_expect_success setup '
+ echo hello >file &&
+ git add file &&
+ test_tick &&
+ git commit -m initial &&
+ echo goodbye >file &&
+ git add file &&
+ test_tick &&
+ git commit -m second &&
+ git checkout -b side HEAD^ &&
+ echo world >git &&
+ git add git &&
+ test_tick &&
+ git commit -m side &&
+ git checkout master &&
+ git log --pretty=oneline --abbrev-commit --graph --all &&
+ git branch test side
+'
+
+test_expect_success 'rebase' '
+ git checkout test &&
+ git reset --hard side &&
+ git rebase master &&
+ test "z$(cat git)" = zworld
+'
+
+test_expect_success 'rebase -i' '
+ git checkout test &&
+ git reset --hard side &&
+ EDITOR=true git rebase -i master &&
+ test "z$(cat git)" = zworld
+'
+
+test_expect_success 'setup pre-rebase hook' '
+ mkdir -p .git/hooks &&
+ cat >.git/hooks/pre-rebase <<EOF &&
+#!$SHELL_PATH
+echo "\$1,\$2" >.git/PRE-REBASE-INPUT
+EOF
+ chmod +x .git/hooks/pre-rebase
+'
+
+test_expect_success 'pre-rebase hook gets correct input (1)' '
+ git checkout test &&
+ git reset --hard side &&
+ git rebase master &&
+ test "z$(cat git)" = zworld &&
+ test "z$(cat .git/PRE-REBASE-INPUT)" = zmaster,
+
+'
+
+test_expect_success 'pre-rebase hook gets correct input (2)' '
+ git checkout test &&
+ git reset --hard side &&
+ git rebase master test &&
+ test "z$(cat git)" = zworld &&
+ test "z$(cat .git/PRE-REBASE-INPUT)" = zmaster,test
+'
+
+test_expect_success 'pre-rebase hook gets correct input (3)' '
+ git checkout test &&
+ git reset --hard side &&
+ git checkout master &&
+ git rebase master test &&
+ test "z$(cat git)" = zworld &&
+ test "z$(cat .git/PRE-REBASE-INPUT)" = zmaster,test
+'
+
+test_expect_success 'pre-rebase hook gets correct input (4)' '
+ git checkout test &&
+ git reset --hard side &&
+ EDITOR=true git rebase -i master &&
+ test "z$(cat git)" = zworld &&
+ test "z$(cat .git/PRE-REBASE-INPUT)" = zmaster,
+
+'
+
+test_expect_success 'pre-rebase hook gets correct input (5)' '
+ git checkout test &&
+ git reset --hard side &&
+ EDITOR=true git rebase -i master test &&
+ test "z$(cat git)" = zworld &&
+ test "z$(cat .git/PRE-REBASE-INPUT)" = zmaster,test
+'
+
+test_expect_success 'pre-rebase hook gets correct input (6)' '
+ git checkout test &&
+ git reset --hard side &&
+ git checkout master &&
+ EDITOR=true git rebase -i master test &&
+ test "z$(cat git)" = zworld &&
+ test "z$(cat .git/PRE-REBASE-INPUT)" = zmaster,test
+'
+
+test_expect_success 'setup pre-rebase hook that fails' '
+ mkdir -p .git/hooks &&
+ cat >.git/hooks/pre-rebase <<EOF &&
+#!$SHELL_PATH
+false
+EOF
+ chmod +x .git/hooks/pre-rebase
+'
+
+test_expect_success 'pre-rebase hook stops rebase (1)' '
+ git checkout test &&
+ git reset --hard side &&
+ test_must_fail git rebase master &&
+ test "z$(git symbolic-ref HEAD)" = zrefs/heads/test &&
+ test 0 = $(git rev-list HEAD...side | wc -l)
+'
+
+test_expect_success 'pre-rebase hook stops rebase (2)' '
+ git checkout test &&
+ git reset --hard side &&
+ EDITOR=true test_must_fail git rebase -i master &&
+ test "z$(git symbolic-ref HEAD)" = zrefs/heads/test &&
+ test 0 = $(git rev-list HEAD...side | wc -l)
+'
+
+test_done
--
1.6.0.2
--
Nanako Shiraishi
http://ivory.ap.teacup.com/nanako3/
^ permalink raw reply related
* Git and tagging hook
From: Kristis Makris @ 2008-10-06 4:45 UTC (permalink / raw)
To: git-u79uwXL29TY76Z2rM5mHXA; +Cc: scmbug-users-G8y9j4K4DsPiwOUmbS1EgQ
[-- Attachment #1.1: Type: text/plain, Size: 366 bytes --]
Hello,
It seems that Git (at least v1.5.6) does not offer hooks on tag creation
(a pre-tag and a post-tag hook). I need such a hook for integrating tag
activities with an issue-tracker. Is it possible to add this hook ?
I had asked about this in the past, but did not receive a response.
http://bugzilla.mkgnu.net/show_bug.cgi?id=991
Thanks,
Kristis
[-- Attachment #1.2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
[-- Attachment #2: Type: text/plain, Size: 188 bytes --]
_______________________________________________
scmbug-users mailing list
scmbug-users-G8y9j4K4DsPiwOUmbS1EgQ@public.gmane.org
http://lists.mkgnu.net/cgi-bin/mailman/listinfo/scmbug-users
^ 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