* Re: Hello All and Seeking Information
From: Bruce Stephens @ 2008-11-24 16:35 UTC (permalink / raw)
To: Tim Visher; +Cc: git
In-Reply-To: <c115fd3c0811240828y61e7bfecka1cacdd37865a4e8@mail.gmail.com>
"Tim Visher" <tim.visher@gmail.com> writes:
[...]
> However, there are some issues that I can't wrap my head around,
> such as how you can guarantee that all developers are working on the
> same code-base without a central repo.
You can't. That's the point.
If developers wish to use a central repository and always to work
based on that, then they can. But the tool doesn't enforce that.
<http://koweycode.blogspot.com/2008/11/iterative-commiting.html>
describes a common (IME) benefit.
[...]
^ permalink raw reply
* [RFC/PATCH v2] bisect: teach "skip" to accept special arguments like "A..B"
From: Christian Couder @ 2008-11-24 16:33 UTC (permalink / raw)
To: Junio C Hamano, Johannes Schindelin, Johannes Sixt; +Cc: git, H. Peter Anvin
The current "git bisect skip" syntax is "git bisect skip [<rev>...]"
so it's already possible to skip a range of revisions using
something like:
$ git bisect skip $(git rev-list A..B)
where A and B are the bounds of the range we want to skip.
This patch teaches "git bisect skip" to accept:
$ git bisect skip A..B
as an abbreviation for the former command.
This is done by checking each argument to see if it contains two
dots one after the other ('..'), and by expanding it using
"git rev-list" if that is the case.
Note that this patch will not make "git bisect skip" accept all
that "git rev-list" accepts, as things like "^A B" for exemple
will not work. But things like "A B..C D E F.. ..G H...I" should
work as expected.
Signed-off-by: Christian Couder <chriscool@tuxfamily.org>
---
git-bisect.sh | 19 ++++++++++++++++++-
1 files changed, 18 insertions(+), 1 deletions(-)
Change since last time: s/expend/expand/
I am still not sure if this patch is worth it because
this is a special case in many ways.
diff --git a/git-bisect.sh b/git-bisect.sh
index 0d0e278..6706bc1 100755
--- a/git-bisect.sh
+++ b/git-bisect.sh
@@ -191,6 +191,21 @@ check_expected_revs() {
done
}
+bisect_skip() {
+ all=''
+ for arg in "$@"
+ do
+ case "$arg" in
+ *..*)
+ revs=$(git rev-list "$arg") || die "Bad rev input: $arg" ;;
+ *)
+ revs="'$arg'" ;;
+ esac
+ all="$all $revs"
+ done
+ bisect_state 'skip' $all
+}
+
bisect_state() {
bisect_autostart
state=$1
@@ -630,8 +645,10 @@ case "$#" in
git bisect -h ;;
start)
bisect_start "$@" ;;
- bad|good|skip)
+ bad|good)
bisect_state "$cmd" "$@" ;;
+ skip)
+ bisect_skip "$@" ;;
next)
# Not sure we want "next" at the UI level anymore.
bisect_next "$@" ;;
--
1.6.0.4.617.g39d03
^ permalink raw reply related
* Hello All and Seeking Information
From: Tim Visher @ 2008-11-24 16:28 UTC (permalink / raw)
To: git
Hello Everyone,
I'm new to the list so I figured I'd introduce myself instead of just
wall-flowering... "Hello"... :)
Anyway, I really like a lot of the concepts found in Git and the
reported power and flexibility of it are very intriguing. However,
there are some issues that I can't wrap my head around, such as how
you can guarantee that all developers are working on the same
code-base without a central repo. I would classify a lot of my issues
as paradigm rather than technically related. I understand a lot of
Git's underpinnings and the basic usage of it, I just can't wrap my
head around the higher-order parts of it.
I've done some Googling and I can't find a good 'Introduction to
Distributed SCM Concepts for Centralized SCM Developers' article yet.
Ideally, this would be an article all about the high-level thought
processes that go into utilizing Distributed SCM in a team environment
where having a single canonical representation of your project that
all developers are working off of is important.
Anyway, looking forward to participating.
P.S. Anyone want to tell me why the Git Mailing List was set-up
monolithically rather than the typical git-dev, git-user, git-admin,
git-x etc.? I don't plan on hacking on Git so having the Dev mail in
the list is just noise for me. I'm sure other people think that too.
Just wondering.
--
In Christ,
Timmy V.
http://burningones.com/
http://five.sentenc.es/ - Spend less time on e-mail
^ permalink raw reply
* Re: gitsub{module,project}
From: Michael J Gruber @ 2008-11-24 16:01 UTC (permalink / raw)
Cc: Git Mailing List
In-Reply-To: <492ACE4E.1090506@drmicha.warpmail.net>
Michael J Gruber venit, vidit, dixit 24.11.2008 16:54:
> Dear all:
>
> Parts of git still use the term subproject rather then submodule. A
> simple grep/wc -l shows submodule as the winner by 10:1 or so. Are there
> any objections to consolidating that naming (in favour of submodule)?
...sorry, just to be clear: I only mean to change doc/error messages,
not the diff format. I guess that would mean running into a wall (and
bouncing back).
Michael
^ permalink raw reply
* gitsub{module,project}
From: Michael J Gruber @ 2008-11-24 15:54 UTC (permalink / raw)
To: Git Mailing List
Dear all:
Parts of git still use the term subproject rather then submodule. A
simple grep/wc -l shows submodule as the winner by 10:1 or so. Are there
any objections to consolidating that naming (in favour of submodule)?
Michael
^ permalink raw reply
* Re: How do I delete a git submodule?
From: Michael J Gruber @ 2008-11-24 15:51 UTC (permalink / raw)
To: Peter Krefting; +Cc: Git Mailing List
In-Reply-To: <Pine.LNX.4.64.0811241537580.22925@ds9.cixit.se>
Peter Krefting venit, vidit, dixit 24.11.2008 15:44:
> Hi!
>
> I am trying to remove a submodule from a project, but can't figure out
> how to do it. With "modules/aldc" as a submodule:
>
> $ cat .gitmodules
> [submodule "modules/aldc"]
> path = modules/aldc
> url = [...cut...]
> [...more entries here...]
> $ git status
> [...cut...]
> nothing to commit (working directory clean)
>
> Starting from a clean set-up.
>
> $ git submodule rm modules/aldc
> -ff17d9e0e76d01e99d26aa16b28cf327c5abb48a modules/aldc
> $ git status
> [...cut...]
> nothing to commit (working directory clean)
>
> The obvious command didn't give any errors, but didn't do anything,
> either. (I notice that there is no mention of a "git submodule rm" on
> the git-submodule man page.)
>
> $ git rm modules/aldc
> rm 'modules/aldc'
> fatal: git rm: modules/aldc: Permission denied
> $ git status
> [...cut...]
> nothing to commit (working directory clean)
>
> Nope, that didn't work either.
>
> What am I missing?
The last line of git help/man on git submodule status:
"This command is the default command for git-submodule."
git submodule ignores the "rm" (because it doesn't know that command)
and does a "status" on modules/aldc.
OTOH, git rm refuses to do its thing, as you noticed. The brute force
method seems to work:
rm -Rf modules/aldc
#remove module from .gitmodules
#remove module from .git/config
git add -u
git commit -m "get thee hence, modules/aldc"
I edited the two config files manually, but this can be scripted.
git log -p shows a perfect diff including removal of the subproject
commit, so I think the result of the above is fine. I think I'll work on
a patch if nobody stops or beats me...
Cheers,
Michael
^ permalink raw reply
* Re: Best practices for maintaining a subversion mirror?
From: Peter Harris @ 2008-11-24 15:37 UTC (permalink / raw)
To: Oliver Charles; +Cc: git
In-Reply-To: <5641883d0811240255i21aef729ld202bd5a3211dad9@mail.gmail.com>
On Mon, Nov 24, 2008 at 5:55 AM, Oliver Charles wrote:
> This seems to be working nicely as a readonly interface, but when I
> clone this repository (git clone git://foo/repo.git) - served via
> git-daemon - I can't seem to get svn rebase to work on it, which means
> I can't dcommit my changes back to Subversion.
>
> Am I doing things generally the right way, or am I doing it completely
> wrong? :-) Any tips appreciated!
First, make sure you aren't using the --no-metadata flag. git svn
rebase needs that metadata to rebuild its index.
Second, a simple "git clone" will not set up the svn remotes; you have
to do that by hand. This is what I do when I clone my svn mirror:
mkdir project
cd project
git init
git remote add origin git://mirror/project
git config --add remote.origin.fetch +refs/remotes/*:refs/remotes/*
git fetch
git svn init -Ttrunk svn://upstream/project
git config --add svn-remote.svn.fetch branches/foo:refs/remotes/foo
git config --add svn-remote.svn.fetch branches/bar:refs/remotes/bar
git reset --hard trunk
git svn rebase
Once you have it nailed down, you can put it into a script so all your
co-workers don't have to do that by hand too.
(Also, I quickly reset my cron job to run every five minutes; I found
an hour was way too long for my taste. YMMV, of course)
Peter Harris
^ permalink raw reply
* Re: [StGit PATCH] stgit.el: Show running commands
From: Karl Hasselström @ 2008-11-24 15:34 UTC (permalink / raw)
To: David Kågedal; +Cc: catalin.marinas, git
In-Reply-To: <20081124120136.9163.70947.stgit@krank>
Thanks, looks useful.
Sorry I haven't taken the time to apply & push out your patches. I'm
hoping it'll happen Real Soon Now(tm) ...
--
Karl Hasselström, kha@treskal.com
www.treskal.com/kalle
^ permalink raw reply
* Re: Not-quite-a-bug in pickaxe
From: Mikael Magnusson @ 2008-11-24 15:08 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git, gitster
In-Reply-To: <alpine.DEB.1.00.0811241238450.30769@pacific.mpi-cbg.de>
2008/11/24 Johannes Schindelin <Johannes.Schindelin@gmx.de>:
> Hi people,
>
> I do not know if I hit that behavior before,
I'm pretty sure it has,
http://thread.gmane.org/gmane.comp.version-control.git/100113/focus=100115
(at least i think that's the same case?)
> but now it hit me big time:
> if a commit moves a certain string from one place to another, "git log
> -S<string>" does not pick up that commit. The code responsible for this
> is in diffcore-pickaxe.c:
>
> else if (!diff_unmodified_pair(p) &&
> contains(p->one, needle, len, regexp) !=
> contains(p->two, needle, len, regexp))
> has_changes++;
>
> Basically, the "contains()" method says how often the needle was found,
> and pickaxe just assumes that a move of a string is not interesting
> enough.
>
> Now, this behavior is probably intended, as searching files is much
> cheaper than generating the diffs between them, yet it is something you'll
> have to keep in mind when using "-S".
--
Mikael Magnusson
^ permalink raw reply
* How do I delete a git submodule?
From: Peter Krefting @ 2008-11-24 14:44 UTC (permalink / raw)
To: Git Mailing List
Hi!
I am trying to remove a submodule from a project, but can't figure out
how to do it. With "modules/aldc" as a submodule:
$ cat .gitmodules
[submodule "modules/aldc"]
path = modules/aldc
url = [...cut...]
[...more entries here...]
$ git status
[...cut...]
nothing to commit (working directory clean)
Starting from a clean set-up.
$ git submodule rm modules/aldc
-ff17d9e0e76d01e99d26aa16b28cf327c5abb48a modules/aldc
$ git status
[...cut...]
nothing to commit (working directory clean)
The obvious command didn't give any errors, but didn't do anything,
either. (I notice that there is no mention of a "git submodule rm" on
the git-submodule man page.)
$ git rm modules/aldc
rm 'modules/aldc'
fatal: git rm: modules/aldc: Permission denied
$ git status
[...cut...]
nothing to commit (working directory clean)
Nope, that didn't work either.
What am I missing?
$ git --version
git version 1.6.0.2.1172.ga5ed0
(This is Git-1.6.0.2-preview20080923 on Windows XP)
--
\\// Peter - http://www.softwolves.pp.se/
^ permalink raw reply
* Re: Stgit and refresh-temp
From: Jon Smirl @ 2008-11-24 14:11 UTC (permalink / raw)
To: Karl Hasselström; +Cc: Catalin Marinas, Git Mailing List
In-Reply-To: <20081124111635.GA31986@diana.vm.bytemark.co.uk>
A useful future enhancement would be to adjust patches that insert
adjacent areas so that they can pass each other in a pop/pop
operation. The most common case of this being appends to end of file.
This would be a form of automatic conflict resolution. The pending
patch would be automatically corrected to resolve the adjacent insert
conflict. You might want a prompt asking if this was ok andt then
remember the answer so that question is not asked repeatedly.
It's a mechanism to say that multiple insertions at point X in the
original file don't matter in their order of insertion.
--
Jon Smirl
jonsmirl@gmail.com
^ permalink raw reply
* Re: git-svn and svnsync
From: Andriy Gapon @ 2008-11-24 12:56 UTC (permalink / raw)
To: git
In-Reply-To: <48F6F631.90709@icyb.net.ua>
on 16/10/2008 11:07 Andriy Gapon said the following:
>
> I did the following:
> 1. mirror svn repository using svnsync
> 2. clone the mirror with git-svn --use-svnsync-props and some tweaking[*]
> 3. run git svn info in the clone
> 4. get error "Unable to determine upstream SVN information from working
> tree history"
>
> git svn log and git svn rebase do not work either.
> git log does work.
>
> I have git version 1.6.0.2 (from FreeBSD ports).
> [*] About the tweaking - I manually massaged config file to get the
> branches I was interested in, so .git/config is this:
> [core]
> repositoryformatversion = 0
> filemode = true
> bare = false
> logallrefupdates = true
> [svn-remote "svn"]
> useSvnsyncProps = 1
> url = file:///system/devel/svn/base
> fetch = head:refs/remotes/trunk
> fetch = stable/6:refs/remotes/stable_6
> fetch = stable/7:refs/remotes/stable_7
> fetch = releng/6.3:refs/remotes/releng_6_3
> fetch = releng/6.4:refs/remotes/releng_6_4
> fetch = releng/7.0:refs/remotes/releng_7_0
> fetch = release/6.3.0:refs/remotes/release_6_3_0
> fetch = release/7.0.0:refs/remotes/release_7_0_0
>
> This is .git/svn/.metadata:
> ; This file is used internally by git-svn
> ; You should not have to edit it
> [svn-remote "svn"]
> reposRoot = file:///system/devel/svn/base
> uuid = ccf9f872-aa2e-dd11-9fc8-001c23d0bc1f
> svnsync-uuid = ccf9f872-aa2e-dd11-9fc8-001c23d0bc1f
> svnsync-url = svn://svn.freebsd.org/base
>
> So you can see the original svn repository URL.
>
> git log reports svn info like the following:
> git-svn-id: svn://svn.freebsd.org/base/stable/7@183898
> ccf9f872-aa2e-dd11-9fc8-001c23d0bc1f
>
> It seems that the problem is that the code in find_by_url() and/or
> read_all_remotes() subroutines (in git-svn.perl) are not aware of
> svnsync and do not realize an URL in logs and URL in svn-remote are
> different.
> BTW, I see that there is some special svm logic in read_all_remotes.
>
> Thank you very much for any help in advance.
>
Anyone?
I wonder if this is my local problem/misconfiguration or an issue with
git-svn.
--
Andriy Gapon
^ permalink raw reply
* [StGit PATCH] stgit.el: Show running commands
From: David Kågedal @ 2008-11-24 12:01 UTC (permalink / raw)
To: kha, catalin.marinas; +Cc: git
---
contrib/stgit.el | 16 +++++++++++-----
1 files changed, 11 insertions(+), 5 deletions(-)
diff --git a/contrib/stgit.el b/contrib/stgit.el
index 65af068..ec08a5b 100644
--- a/contrib/stgit.el
+++ b/contrib/stgit.el
@@ -68,9 +68,15 @@ Argument DIR is the repository path."
(display-buffer output-buf t)))))
(put 'stgit-capture-output 'lisp-indent-function 1)
-(defun stgit-run (&rest args)
+(defun stgit-run-silent (&rest args)
(apply 'call-process "stg" nil standard-output nil args))
+(defun stgit-run (&rest args)
+ (let ((msgcmd (mapconcat #'identity args " ")))
+ (message "Running stg %s..." msgcmd)
+ (apply 'call-process "stg" nil standard-output nil args)
+ (message "Running stg %s...done" msgcmd)))
+
(defun stgit-reload ()
"Update the contents of the stgit buffer"
(interactive)
@@ -79,8 +85,8 @@ Argument DIR is the repository path."
(curpatch (stgit-patch-at-point)))
(erase-buffer)
(insert "Branch: ")
- (stgit-run "branch")
- (stgit-run "series" "--description")
+ (stgit-run-silent "branch")
+ (stgit-run-silent "series" "--description")
(stgit-rescan)
(if curpatch
(stgit-goto-patch curpatch)
@@ -338,7 +344,7 @@ With numeric prefix argument, pop that many patches."
(set (make-local-variable 'stgit-edit-patch) patch)
(setq default-directory dir)
(let ((standard-output edit-buf))
- (stgit-run "edit" "--save-template=-" patch))))
+ (stgit-run-silent "edit" "--save-template=-" patch))))
(defun stgit-confirm-edit ()
(interactive)
@@ -402,7 +408,7 @@ With numeric prefix argument, pop that many patches."
(set (make-local-variable 'stgit-patches) patch-names)
(setq default-directory dir)
(let ((standard-output edit-buf))
- (apply 'stgit-run "coalesce" "--save-template=-" patch-names))))
+ (apply 'stgit-run-silent "coalesce" "--save-template=-" patch-names))))
(defun stgit-confirm-coalesce ()
(interactive)
^ permalink raw reply related
* Not-quite-a-bug in pickaxe
From: Johannes Schindelin @ 2008-11-24 11:43 UTC (permalink / raw)
To: git, gitster
Hi people,
I do not know if I hit that behavior before, but now it hit me big time:
if a commit moves a certain string from one place to another, "git log
-S<string>" does not pick up that commit. The code responsible for this
is in diffcore-pickaxe.c:
else if (!diff_unmodified_pair(p) &&
contains(p->one, needle, len, regexp) !=
contains(p->two, needle, len, regexp))
has_changes++;
Basically, the "contains()" method says how often the needle was found,
and pickaxe just assumes that a move of a string is not interesting
enough.
Now, this behavior is probably intended, as searching files is much
cheaper than generating the diffs between them, yet it is something you'll
have to keep in mind when using "-S".
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH] Display (empty) when appropriate for the goto command
From: Karl Hasselström @ 2008-11-24 11:19 UTC (permalink / raw)
To: Catalin Marinas; +Cc: git
In-Reply-To: <20081123212318.9835.53505.stgit@localhost.localdomain>
On 2008-11-23 21:23:18 +0000, Catalin Marinas wrote:
> This is a fix for bug #11810. The original implementation of goto
> used to display (empty patch) when a patch became empty during a
> push + merge operation. This patch adds this feature again.
>
> Signed-off-by: Catalin Marinas <catalin.marinas@gmail.com>
Acked-by: Karl Hasselström <kha@treskal.com>
--
Karl Hasselström, kha@treskal.com
www.treskal.com/kalle
^ permalink raw reply
* Re: Stgit and refresh-temp
From: Karl Hasselström @ 2008-11-24 11:16 UTC (permalink / raw)
To: Catalin Marinas; +Cc: Jon Smirl, Git Mailing List
In-Reply-To: <b0943d9e0811231320s804eff0k5aecbac84cb2ffe7@mail.gmail.com>
On 2008-11-23 21:20:59 +0000, Catalin Marinas wrote:
> 2008/11/12 Karl Hasselström <kha@treskal.com>:
>
> > On 2008-11-12 10:02:10 +0000, Catalin Marinas wrote:
> >
> > > I think it's just a matter of updating HEAD on the
> > > "merge_conflict" path but I'm still not fully confident in
> > > modifying the new lib infrastructure.
> >
> > You're probably right.
>
> The simple patch below seems to fix it the goto issue. Could you
> please confirm its correctness (the patch might be wrapped by the web
> interface)?
>
> diff --git a/stgit/lib/transaction.py b/stgit/lib/transaction.py
> index 6623645..0f414d8 100644
> --- a/stgit/lib/transaction.py
> +++ b/stgit/lib/transaction.py
> @@ -321,6 +321,7 @@ class StackTransaction(object):
> if any(getattr(cd, a) != getattr(orig_cd, a) for a in
> ['parent', 'tree', 'author', 'message']):
> comm = self.__stack.repository.commit(cd)
> + self.head = comm
> else:
> comm = None
> s = ' (unmodified)'
OK, so I just took a quick look, and my understanding of the problem
(without having had time to actually run any code to confirm) is that
the following happens:
1. In push_patch(), we delay the final stack update (the update()
function) since we want to record the state just before the
conflict in the stack log.
2. In run(), we update the branch head before running the delayed
stack update (self.__conflicting_push()).
Your patch works around this problem by explicitly specifying what the
branch head should be; this mechanism is used by undo etc. to be able
to set the branch head to something that isn't the stack top.
At first I thought it was something of a hack, and that the run()
function should probably be modified to do something clever when
self.__conflicting_push != None, such as writing the branch head
later. But there's a reason the checkout is done first in run(): it's
the one and only thing that can go wrong, in which case we have to
roll back. So I guess your solution is indeed at least as right and
proper as anything I would have come up with.
But I would recommend a big fat comment just before the line you
insert that explains why we have to set self.head hard in this case
(namely, that the update() function is run _after_ checkout in run()).
With that comment,
Acked-by: Karl Hasselström <kha@treskal.com>
--
Karl Hasselström, kha@treskal.com
www.treskal.com/kalle
^ permalink raw reply
* Re: [RFC PATCH 1/4] Refactor builtin-verify-tag.c
From: Johannes Schindelin @ 2008-11-24 11:04 UTC (permalink / raw)
To: Deskin Miller; +Cc: git
In-Reply-To: <1227497000-8684-2-git-send-email-deskinm@umich.edu>
Hi,
On Sun, 23 Nov 2008, Deskin Miller wrote:
> builtin-verify-tag.c didn't expose any of its functionality to be used
> internally. Refactor some of it into new verify-tag.c and expose
> verify_tag_sha1 able to be called from elsewhere in git.
>
> Signed-off-by: Deskin Miller <deskinm@umich.edu>
> ---
> Makefile | 2 +
> builtin-verify-tag.c | 61 ++-------------------------------------
> verify-tag.c | 77 ++++++++++++++++++++++++++++++++++++++++++++++++++
> verify-tag.h | 10 ++++++
> 4 files changed, 93 insertions(+), 57 deletions(-)
> create mode 100644 verify-tag.c
> create mode 100644 verify-tag.h
I'll comment on the output of "format-patch -n -C -C" instead, as that
makes it much easier to see what you actually did:
> Makefile | 2 +
> builtin-verify-tag.c | 61 ++-------------------------------
> builtin-verify-tag.c => verify-tag.c | 48 ++++-----------------------
> verify-tag.h | 10 +++++
> 4 files changed, 23 insertions(+), 98 deletions(-)
> copy builtin-verify-tag.c => verify-tag.c (56%)
> create mode 100644 verify-tag.h
>
> [...]
> diff --git a/builtin-verify-tag.c b/verify-tag.c
> similarity index 56%
> copy from builtin-verify-tag.c
> copy to verify-tag.c
> index 729a159..c9be331 100644
> --- a/builtin-verify-tag.c
> +++ b/verify-tag.c
> @@ -1,18 +1,12 @@
> /*
> - * Builtin "git verify-tag"
> + * Internals for "git verify-tag"
Agree.
> *
> - * Copyright (c) 2007 Carlos Rica <jasampler@gmail.com>
> + * Copyright (c) 2008 Deskin Miller <deskinm@umich.edu>
Disagree.
Even if Carlos seemed to stop his work on Git entirely, which I find
disappointing, you are _not_ free to pretend his work is yours. And given
this diff:
> *
> - * Based on git-verify-tag.sh
> */
> #include "cache.h"
> -#include "builtin.h"
> -#include "tag.h"
> +#include "object.h"
> #include "run-command.h"
> -#include <signal.h>
> -
> -static const char builtin_verify_tag_usage[] =
> - "git verify-tag [-v|--verbose] <tag>...";
>
> #define PGP_SIGNATURE "-----BEGIN PGP SIGNATURE-----"
>
> @@ -60,52 +54,24 @@ static int run_gpg_verify(const char *buf, unsigned long size, int verbose)
> return ret;
> }
>
> -static int verify_tag(const char *name, int verbose)
> +int verify_tag_sha1(const unsigned char *sha1, int verbose)
> {
> enum object_type type;
> - unsigned char sha1[20];
> char *buf;
> unsigned long size;
> int ret;
>
> - if (get_sha1(name, sha1))
> - return error("tag '%s' not found.", name);
> -
> type = sha1_object_info(sha1, NULL);
> if (type != OBJ_TAG)
> - return error("%s: cannot verify a non-tag object of type %s.",
> - name, typename(type));
> + return error("Cannot verify a non-tag object of type %s.",
> + typename(type));
>
> buf = read_sha1_file(sha1, &type, &size);
> if (!buf)
> - return error("%s: unable to read file.", name);
> + return error("Cnable to read file.");
>
> ret = run_gpg_verify(buf, size, verbose);
>
> free(buf);
> return ret;
> }
> -
> -int cmd_verify_tag(int argc, const char **argv, const char *prefix)
> -{
> - int i = 1, verbose = 0, had_error = 0;
> -
> - git_config(git_default_config, NULL);
> -
> - if (argc > 1 &&
> - (!strcmp(argv[i], "-v") || !strcmp(argv[i], "--verbose"))) {
> - verbose = 1;
> - i++;
> - }
> -
> - if (argc <= i)
> - usage(builtin_verify_tag_usage);
> -
> - /* sometimes the program was terminated because this signal
> - * was received in the process of writing the gpg input: */
> - signal(SIGPIPE, SIG_IGN);
> - while (i < argc)
> - if (verify_tag(argv[i++], verbose))
> - had_error = 1;
> - return had_error;
> -}
I think pretty much all you did was deleting (and thereby you do not gain
any copyright).
Except for one change: why on earth did you think it a good idea to
suppress telling the user the _name_ of the tag when an error occurs?
I, for one, would find it way less than helpful to read
Cannot verify a non-tag object of type blob.
than to read
refs/tags/dscho-key: cannot verify a non-tag object of type blob.
Besides, I do not see where you warn that "tag <name> not found." Changes
like this one need to be justified (by saying in the commit message where
the warning is already issued, and not letting the reviewer/reader leave
wondering).
Please, next time you submit a patch like this, do the -C -C yourself.
Letting all the reviewers do it looks lousy on the overall time balance
sheet, and it may also lead to a potential reviewer preferring to do
something else instead.
Now, Junio already said that he is not (yet) convinced that this change
should be in Git proper, rather than a hook, so it is up to you to decide
if you deem it important enough to try harder to convince people.
I, for one, would think that it may be a good change: AFAIK only hard-core
gits use hooks, everybody else avoids them. So if we deem verifying
signatures important enough, we might want to have better support for it
than some example hooks.
So color me half-convinced.
Ciao,
Dscho
^ permalink raw reply
* Best practices for maintaining a subversion mirror?
From: Oliver Charles @ 2008-11-24 10:55 UTC (permalink / raw)
To: git
Hi,
I just got myself a new server, and as I'm the major Git-using person
at my work, I'd like to set a mirror of our Subversion repository up
to hopefully convert a few more people. At the moment, I've done git
svn clone http://svn..., and then git clone --bare to make a --bare
version of this clone.
Now that I have this mirror, I have this entry in my crontab to update
it hourly:
0 * * * * cd /.git && /usr/bin/git --git-dir=. svn fetch &&
/usr/bin/git update-ref refs/heads/master refs/remotes/git-svn
This seems to be working nicely as a readonly interface, but when I
clone this repository (git clone git://foo/repo.git) - served via
git-daemon - I can't seem to get svn rebase to work on it, which means
I can't dcommit my changes back to Subversion.
Am I doing things generally the right way, or am I doing it completely
wrong? :-) Any tips appreciated!
- Oliver Charles
^ permalink raw reply
* Re: [RFC PATCH 4/4] Make git fetch verify signed tags
From: Johannes Schindelin @ 2008-11-24 10:44 UTC (permalink / raw)
To: Deskin Miller; +Cc: git
In-Reply-To: <1227497000-8684-5-git-send-email-deskinm@umich.edu>
Hi,
On Sun, 23 Nov 2008, Deskin Miller wrote:
> When git fetch downloads signed tag objects, make it verify them right
> then. This extends the output summary of fetch to include "(good
> signature)" for valid tags and "(BAD SIGNATURE)" for invalid tags. If
> the user does not have the correct key in the gpg keyring, gpg returns
> 2, verify_tag_sha1 returns -2 and nothing additional is output about the
> tag's validity.
This must be turned off by default, IMO. You cannot expect each and every
developer to have gpg _and_ all those public keys installed.
Ciao,
Dscho
^ permalink raw reply
* Re: [RFC PATCH 0/4] Teach git fetch to verify signed tags automatically
From: Johannes Schindelin @ 2008-11-24 10:41 UTC (permalink / raw)
To: Deskin Miller; +Cc: git
In-Reply-To: <1227497000-8684-1-git-send-email-deskinm@umich.edu>
Hi,
On Sun, 23 Nov 2008, Deskin Miller wrote:
> -What to do if a tag is found to have a bad signature?
Or even worse: if the public key was not found? In dubio pro reo, they
say, but OTOH you asked to verify the signatures...
Ciao,
Dscho
^ permalink raw reply
* Re: [RFC/PATCH] bisect: teach "skip" to accept special arguments like "A..B"
From: Johannes Schindelin @ 2008-11-24 10:35 UTC (permalink / raw)
To: Johannes Sixt; +Cc: Christian Couder, Junio C Hamano, git, H. Peter Anvin
In-Reply-To: <492A5346.1040405@viscovery.net>
Hi,
On Mon, 24 Nov 2008, Johannes Sixt wrote:
> Johannes Schindelin schrieb:
> > On Sun, 23 Nov 2008, Christian Couder wrote:
> >> Dscho wrote:
> >> > Would it not be more intuitive to have support for
> >> >
> >> > git bisect skip A..B
> >> >
> >> > ?
> >>
> >> Here is a patch to do that. I am not sure it's worth it
> >> because this is a special case in many ways.
> >
> > Why not have something like
> >
> > skip)
> > for arg in $(git rev-list "$@")
> > do
> > bisect_state skip $arg
> > done
>
> Because if you say
>
> $ git bisect skip
>
> this would be incorrectly calling rev-list; but more importantly, if you say
>
> $ git bisect skip A
>
> then this would skip A *and all its ancestors*. Not quite what you intended.
Good point indeed.
Thanks,
Dscho
^ permalink raw reply
* Re: [PATCH] config.txt: alphabetize configuration variable groups
From: Johannes Sixt @ 2008-11-24 7:28 UTC (permalink / raw)
To: Matt McCutchen; +Cc: git
In-Reply-To: <1227510109.32583.2.camel@mattlaptop2.local>
Matt McCutchen schrieb:
> @@ -963,6 +953,8 @@ man.<tool>.path::
> Override the path for the given tool that may be used to
> display help in the 'man' format. See linkgit:git-help[1].
>
> +include::merge-config.txt[]
> +
> merge.conflictstyle::
> Specify the style in which conflicted hunks are written out to
> working tree files upon merge. The default is "merge", which
Here, the list is not in alphabetic order anymore.
BTW, your commit message should emphasize the use-cases where an
alphabetic order is a real benefit. Otherwise, this is just code churn.
-- Hannes
^ permalink raw reply
* Re: [RFC/PATCH] bisect: teach "skip" to accept special arguments like "A..B"
From: Johannes Sixt @ 2008-11-24 7:09 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Christian Couder, Junio C Hamano, git, H. Peter Anvin
In-Reply-To: <alpine.DEB.1.00.0811240126430.30769@pacific.mpi-cbg.de>
Johannes Schindelin schrieb:
> On Sun, 23 Nov 2008, Christian Couder wrote:
>> Dscho wrote:
>> > Would it not be more intuitive to have support for
>> >
>> > git bisect skip A..B
>> >
>> > ?
>>
>> Here is a patch to do that. I am not sure it's worth it
>> because this is a special case in many ways.
>
> Why not have something like
>
> skip)
> for arg in $(git rev-list "$@")
> do
> bisect_state skip $arg
> done
Because if you say
$ git bisect skip
this would be incorrectly calling rev-list; but more importantly, if you say
$ git bisect skip A
then this would skip A *and all its ancestors*. Not quite what you intended.
-- Hannes
^ permalink raw reply
* [PATCH] config.txt: alphabetize configuration variable groups
From: Matt McCutchen @ 2008-11-24 7:01 UTC (permalink / raw)
To: git
Signed-off-by: Matt McCutchen <matt@mattmccutchen.net>
---
This is an update of the following patch I sent on October 18, which
received no comment:
http://marc.info/?l=git&m=122438056720340&w=2
Documentation/config.txt | 122 +++++++++++++++++++++++-----------------------
1 files changed, 61 insertions(+), 61 deletions(-)
diff --git a/Documentation/config.txt b/Documentation/config.txt
index d536732..c339f56 100644
--- a/Documentation/config.txt
+++ b/Documentation/config.txt
@@ -572,9 +572,6 @@ color.status.<slot>::
to red). The values of these variables may be specified as in
color.branch.<slot>.
-commit.template::
- Specify a file to use as the template for new commit messages.
-
color.ui::
When set to `always`, always use colors in all git commands which
are capable of colored output. When false (or `never`), never. When
@@ -582,6 +579,9 @@ color.ui::
terminal. When more specific variables of color.* are set, they always
take precedence over this setting. Defaults to false.
+commit.template::
+ Specify a file to use as the template for new commit messages.
+
diff.autorefreshindex::
When using 'git-diff' to compare with work tree
files, do not consider stat-only change as changed.
@@ -714,18 +714,6 @@ gc.rerereunresolved::
kept for this many days when 'git-rerere gc' is run.
The default is 15 days. See linkgit:git-rerere[1].
-rerere.autoupdate::
- When set to true, `git-rerere` updates the index with the
- resulting contents after it cleanly resolves conflicts using
- previously recorded resolution. Defaults to false.
-
-rerere.enabled::
- Activate recording of resolved conflicts, so that identical
- conflict hunks can be resolved automatically, should they
- be encountered again. linkgit:git-rerere[1] command is by
- default enabled if you create `rr-cache` directory under
- `$GIT_DIR`, but can be disabled by setting this option to false.
-
gitcvs.enabled::
Whether the CVS server interface is enabled for this repository.
See linkgit:git-cvsserver[1].
@@ -917,6 +905,10 @@ i18n.logOutputEncoding::
Character encoding the commit messages are converted to when
running 'git-log' and friends.
+imap::
+ The configuration variables in the 'imap' section are described
+ in linkgit:git-imap-send[1].
+
instaweb.browser::
Specify the program that will be used to browse your working
repository in gitweb. See linkgit:git-instaweb[1].
@@ -952,8 +944,6 @@ man.viewer::
Specify the programs that may be used to display help in the
'man' format. See linkgit:git-help[1].
-include::merge-config.txt[]
-
man.<tool>.cmd::
Specify the command to invoke the specified man viewer. The
specified command is evaluated in shell with the man page
@@ -963,6 +953,8 @@ man.<tool>.path::
Override the path for the given tool that may be used to
display help in the 'man' format. See linkgit:git-help[1].
+include::merge-config.txt[]
+
merge.conflictstyle::
Specify the style in which conflicted hunks are written out to
working tree files upon merge. The default is "merge", which
@@ -1079,6 +1071,41 @@ pull.octopus::
pull.twohead::
The default merge strategy to use when pulling a single branch.
+receive.fsckObjects::
+ If it is set to true, git-receive-pack will check all received
+ objects. It will abort in the case of a malformed object or a
+ broken link. The result of an abort are only dangling objects.
+ Defaults to false.
+
+receive.unpackLimit::
+ If the number of objects received in a push is below this
+ limit then the objects will be unpacked into loose object
+ files. However if the number of received objects equals or
+ exceeds this limit then the received pack will be stored as
+ a pack, after adding any missing delta bases. Storing the
+ pack from a push can make the push operation complete faster,
+ especially on slow filesystems. If not set, the value of
+ `transfer.unpackLimit` is used instead.
+
+receive.denyDeletes::
+ If set to true, git-receive-pack will deny a ref update that deletes
+ the ref. Use this to prevent such a ref deletion via a push.
+
+receive.denyNonFastForwards::
+ If set to true, git-receive-pack will deny a ref update which is
+ not a fast forward. Use this to prevent such an update via a push,
+ even if that push is forced. This configuration variable is
+ set when initializing a shared repository.
+
+receive.denyCurrentBranch::
+ If set to true or "refuse", receive-pack will deny a ref update
+ to the currently checked out branch of a non-bare repository.
+ Such a push is potentially dangerous because it brings the HEAD
+ out of sync with the index and working tree. If set to "warn",
+ print a warning of such a push to stderr, but allow the push to
+ proceed. If set to false or "ignore", allow such pushes with no
+ message. Defaults to "warn".
+
remote.<name>.url::
The URL of a remote repository. See linkgit:git-fetch[1] or
linkgit:git-push[1].
@@ -1128,6 +1155,18 @@ repack.usedeltabaseoffset::
"false" and repack. Access from old git versions over the
native protocol are unaffected by this option.
+rerere.autoupdate::
+ When set to true, `git-rerere` updates the index with the
+ resulting contents after it cleanly resolves conflicts using
+ previously recorded resolution. Defaults to false.
+
+rerere.enabled::
+ Activate recording of resolved conflicts, so that identical
+ conflict hunks can be resolved automatically, should they
+ be encountered again. linkgit:git-rerere[1] command is by
+ default enabled if you create `rr-cache` directory under
+ `$GIT_DIR`, but can be disabled by setting this option to false.
+
showbranch.default::
The default set of branches for linkgit:git-show-branch[1].
See linkgit:git-show-branch[1].
@@ -1164,6 +1203,11 @@ tar.umask::
archiving user's umask will be used instead. See umask(2) and
linkgit:git-archive[1].
+transfer.unpackLimit::
+ When `fetch.unpackLimit` or `receive.unpackLimit` are
+ not set, the value of this variable is used instead.
+ The default value is 100.
+
url.<base>.insteadOf::
Any URL that starts with this value will be rewritten to
start, instead, with <base>. In cases where some site serves a
@@ -1192,50 +1236,6 @@ user.signingkey::
unchanged to gpg's --local-user parameter, so you may specify a key
using any method that gpg supports.
-imap::
- The configuration variables in the 'imap' section are described
- in linkgit:git-imap-send[1].
-
-receive.fsckObjects::
- If it is set to true, git-receive-pack will check all received
- objects. It will abort in the case of a malformed object or a
- broken link. The result of an abort are only dangling objects.
- Defaults to false.
-
-receive.unpackLimit::
- If the number of objects received in a push is below this
- limit then the objects will be unpacked into loose object
- files. However if the number of received objects equals or
- exceeds this limit then the received pack will be stored as
- a pack, after adding any missing delta bases. Storing the
- pack from a push can make the push operation complete faster,
- especially on slow filesystems. If not set, the value of
- `transfer.unpackLimit` is used instead.
-
-receive.denyDeletes::
- If set to true, git-receive-pack will deny a ref update that deletes
- the ref. Use this to prevent such a ref deletion via a push.
-
-receive.denyNonFastForwards::
- If set to true, git-receive-pack will deny a ref update which is
- not a fast forward. Use this to prevent such an update via a push,
- even if that push is forced. This configuration variable is
- set when initializing a shared repository.
-
-receive.denyCurrentBranch::
- If set to true or "refuse", receive-pack will deny a ref update
- to the currently checked out branch of a non-bare repository.
- Such a push is potentially dangerous because it brings the HEAD
- out of sync with the index and working tree. If set to "warn",
- print a warning of such a push to stderr, but allow the push to
- proceed. If set to false or "ignore", allow such pushes with no
- message. Defaults to "warn".
-
-transfer.unpackLimit::
- When `fetch.unpackLimit` or `receive.unpackLimit` are
- not set, the value of this variable is used instead.
- The default value is 100.
-
web.browser::
Specify a web browser that may be used by some commands.
Currently only linkgit:git-instaweb[1] and linkgit:git-help[1]
--
1.6.0.2.593.g91df
^ permalink raw reply related
* [PATCH] git checkout: don't warn about unborn branch if -f is already passed
From: Matt McCutchen @ 2008-11-24 6:55 UTC (permalink / raw)
To: git
I think it's unnecessary to warn that the checkout has been forced due to an
unborn current branch if -f has been explicitly passed. For one project, I am
using git-new-workdir to create workdirs from a bare repository whose HEAD is
set to an unborn branch, and this warning started to irritate me.
Signed-off-by: Matt McCutchen <matt@mattmccutchen.net>
---
builtin-checkout.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/builtin-checkout.c b/builtin-checkout.c
index 464fd25..7f3bd7b 100644
--- a/builtin-checkout.c
+++ b/builtin-checkout.c
@@ -553,7 +553,7 @@ static int switch_branches(struct checkout_opts *opts, struct branch_info *new)
if (!opts->quiet && !old.path && old.commit && new->commit != old.commit)
describe_detached_head("Previous HEAD position was", old.commit);
- if (!old.commit) {
+ if (!old.commit && !opts->force) {
if (!opts->quiet) {
fprintf(stderr, "warning: You appear to be on a branch yet to be born.\n");
fprintf(stderr, "warning: Forcing checkout of %s.\n", new->name);
--
1.6.0.2.593.g91df
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox