* Re: git checkout --orphan skips reflogging
From: Junio C Hamano @ 2011-09-13 23:04 UTC (permalink / raw)
To: Dmitry Ivankov; +Cc: Git List
In-Reply-To: <CA+gfSn-tVgj=FYiVGK7kmH4gpnXF3HUbs+f=DfRey6GrpadVYg@mail.gmail.com>
Dmitry Ivankov <divanorama@gmail.com> writes:
> In short, git checkout --orphan doesn't write
> HEAD_sha1 -> 00000
> entry to logs/HEAD, while git-comit will write
> 00000 -> new_orphan_HEAD_sha1
> entry. And then reflog backward walk will stop on 000 -> entry and
> won't see earlier history.
Funny. From the point of view of the _current_ branch, it sort of makes
sense to stop the traversal at that point, but I agree for HEAD reflog
that records branch switching, the traversal should not stop.
I am not sure if recording 0{40} after --orphan is the right thing to do
either (for that matter, I do not necessarily think running --orphan is a
sane thing to do, but that is a separate issue).
> Isn't it also a bug in reflog walking that we rely on each old_sha1
> being new_sha1 of a previous entry?
I am not all that familiar with the reflog walking (which is admittedly a
bolted-on hack that injects commits with fake ancestry) code, but I think
it assumes the old sha1 field on the current entry matches the new sha1
field on the previous entry, and we could change it to be a bit more
robust.
The attached patch _may_ (I didn't even compile test it) remove the
dependency on osha1[] and make the code consistently use nsha1[], but I
think stopping at the 0{40} is pretty much fundamental in the revision
walking machinery the reflog walking code is piggy-backing on, and I do
not think this patch would change that.
reflog-walk.c | 17 ++++++++++++-----
1 files changed, 12 insertions(+), 5 deletions(-)
diff --git a/reflog-walk.c b/reflog-walk.c
index 5d81d39..261d300 100644
--- a/reflog-walk.c
+++ b/reflog-walk.c
@@ -211,6 +211,13 @@ int add_reflog_for_walk(struct reflog_walk_info *info,
return 0;
}
+static struct reflog_info *peek_reflog_ent(struct commit_reflog *clog)
+{
+ if (clog->recno < 0)
+ return NULL;
+ return &clog->reflogs->items[clog->recno];
+}
+
void fake_reflog_parent(struct reflog_walk_info *info, struct commit *commit)
{
struct commit_info *commit_info =
@@ -223,20 +230,20 @@ void fake_reflog_parent(struct reflog_walk_info *info, struct commit *commit)
return;
commit_reflog = commit_info->util;
- if (commit_reflog->recno < 0) {
+ reflog = peek_reflog_ent(commit_reflog);
+ if (!reflog) {
commit->parents = NULL;
return;
}
-
- reflog = &commit_reflog->reflogs->items[commit_reflog->recno];
info->last_commit_reflog = commit_reflog;
commit_reflog->recno--;
- commit_info->commit = (struct commit *)parse_object(reflog->osha1);
- if (!commit_info->commit) {
+ reflog = peek_reflog_ent(commit_reflog);
+ if (!reflog) {
commit->parents = NULL;
return;
}
+ commit_info->commit = (struct commit *)parse_object(reflog->nsha1);
commit->parents = xcalloc(sizeof(struct commit_list), 1);
commit->parents->item = commit_info->commit;
}
^ permalink raw reply related
* Re: [PATCH v4] gitk: Allow commit editing
From: Michal Sojka @ 2011-09-13 23:11 UTC (permalink / raw)
To: Paul Mackerras; +Cc: Jeff King, git
In-Reply-To: <20110908205945.GB8091@bloggs.ozlabs.ibm.com>
On Thu, 08 Sep 2011, Paul Mackerras wrote:
> On Sat, Aug 27, 2011 at 02:31:02PM +0200, Michal Sojka wrote:
> > Here is a new version with the micro-optimization.
> >
> > Another minor change is that this patch now applies to gitk repo
> > (http://git.kernel.org/pub/scm/gitk/gitk.git) instead of the main git
> > repo.
> >
> > -Michal
> >
> > --8<---------------cut here---------------start------------->8---
> > I often use gitk to review patches before pushing them out and I would
> > like to have an easy way to edit commits. The current approach with
> > copying the commitid, switching to terminal, invoking git rebase -i,
> > editing the commit and switching back to gitk is a way too complicated
> > just for changing a single letter in the commit message or removing a
> > debug printf().
> >
> > This patch adds "Edit this commit" item to gitk's context menu which
> > invokes interactive rebase in a non-interactive way :-). git gui is
> > used to actually edit the commit.
> >
> > Besides editing the commit message, splitting of commits, as described
> > in git-rebase(1), is also supported.
> >
> > The user is warned if the commit to be edited is contained in another
> > ref besides the current branch and the stash (e.g. in a remote
> > branch). Additionally, error box is displayed if the user attempts to
> > edit a commit not contained in the current branch.
>
> I have to say that this patch makes me pretty nervous. I can see the
> attractiveness of the feature, but I don't like making gitk
> unresponsive for a potentially long time, i.e. until git gui exits.
> It may not be clear to users that the reason gitk isn't responding is
> because some other git gui window is still running.
I understand this. See below for a possible solution.
> Also, if some subsequent commit no longer applies because of the
> changes you make to a commit, it's going to abort the rebase
> completely and thus lose the changes you made. That could be
> annoying.
Agreed. A solution could be to create a ref called for example
refs/gitk/failed-rebase and then abort the rebase together with
displaying the error message explaining what happened. The edited commit
would remain visible and a user can manually cherry pick remaining
commits and then reset the original branch to this failed-rebase ref.
> I usually do this by starting a new branch just before the commit I
> want to change and then use a combination of the cherry-pick menu item
> and git commit --amend. Maybe something to make that simpler for
> users would be good, i.e. automate it a bit but still have it be a
> step-by-step process if necessary. Part of the problem of course is
> that neither gitk nor git gui are really designed to be an editing
> environment.
So what about the following:
1) When user selects "Edit commit", git rebase -i is called, git citool
is started on background and things will be set up (I do not know yet
how exactly) so that same callback is called when git citool exits.
2) gitk updates the list of commits and marks the current (detached)
head by a tag (colored box) saying that there is rebase in progress.
The same tag would appear if gitk is executed manually during
interactive rebase.
3) When git citool exits (or when you explicitly select something from
rebase tag's context menu), rebase would continue.
> In fact you really want an edit/compile/test environment so you don't
> introduce new bugs.
Another possibility would be to allow only editing of the commit
message. Then you don't need compile/test steps and the rebase should
not fail due to conflicts.
I do not think I would like this limitation, but it would certainly be
better then nothing.
-Michal
^ permalink raw reply
* Re: [PATCH 2/3] Fix some "variable might be used uninitialized" warnings
From: Ramsay Jones @ 2011-09-13 22:39 UTC (permalink / raw)
To: Junio C Hamano; +Cc: GIT Mailing-list
In-Reply-To: <7vpqj6olfa.fsf@alter.siamese.dyndns.org>
Junio C Hamano wrote:
> Ramsay Jones <ramsay@ramsay1.demon.co.uk> writes:
>
>> In particular, gcc complains as follows:
>>
>> CC tree-walk.o
>> tree-walk.c: In function `traverse_trees':
>> tree-walk.c:347: warning: 'e' might be used uninitialized in this \
>> function
>>
>> CC builtin/revert.o
>> builtin/revert.c: In function `verify_opt_mutually_compatible':
>> builtin/revert.c:113: warning: 'opt2' might be used uninitialized in \
>> this function
>
> Could you also add something to this effect to the commit log message:
>
> but I have verified that these are gcc being not careful
> enough and they are never used uninitialized.
see below for the v2 patch.
> If that is what you indeed have done, that is.
Indeed. The builtin/revert.c warning is straight-forward, but the tree-walk.c
warning is somewhat less so! ;-)
Imagine traverse_trees() (tree-walk.c:324) was called with n == 0 (let's ignore
the effective calls to xmalloc(0) and xcalloc(0,..) at the start of that function).
At first blush it looked like 'e' would remain uninitialized in the call to
prune_traversal() at line 403. Indeed it *would* be if you ever got to that line.
However, since the 'mask' variable (set at line 391) remains set to zero at line 401,
the flow of control leaves the loop before 'e' is used.
[I don't think traverse_trees() would ever be called with n == 0 anyway; the call
site in builtin/merge-tree.c is called with the constant 3, and the call-chains(s)
which start from unpack_trees() are protected by "if (len)", where 'len' is unsigned.]
ATB,
Ramsay Jones
-- >8 --
Subject: [PATCH v2 2/3] Fix some "variable might be used uninitialized" warnings
In particular, gcc complains as follows:
CC tree-walk.o
tree-walk.c: In function `traverse_trees':
tree-walk.c:347: warning: 'e' might be used uninitialized in this \
function
CC builtin/revert.o
builtin/revert.c: In function `verify_opt_mutually_compatible':
builtin/revert.c:113: warning: 'opt2' might be used uninitialized in \
this function
However, I have verified that the analysis performed by gcc was too
conservative and that these variables are not, in fact, used while
uninitialized.
In order to suppress the warnings, we add an NULL pointer initializer
to the declarations of the 'e' and 'opt2' variables.
Signed-off-by: Ramsay Jones <ramsay@ramsay1.demon.co.uk>
---
builtin/revert.c | 2 +-
tree-walk.c | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/builtin/revert.c b/builtin/revert.c
index ba27cf1..200149e 100644
--- a/builtin/revert.c
+++ b/builtin/revert.c
@@ -110,7 +110,7 @@ static void verify_opt_compatible(const char *me, const char *base_opt, ...)
static void verify_opt_mutually_compatible(const char *me, ...)
{
- const char *opt1, *opt2;
+ const char *opt1, *opt2 = NULL;
va_list ap;
va_start(ap, me);
diff --git a/tree-walk.c b/tree-walk.c
index 808bb55..a8d8a66 100644
--- a/tree-walk.c
+++ b/tree-walk.c
@@ -344,7 +344,7 @@ int traverse_trees(int n, struct tree_desc *t, struct traverse_info *info)
unsigned long mask, dirmask;
const char *first = NULL;
int first_len = 0;
- struct name_entry *e;
+ struct name_entry *e = NULL;
int len;
for (i = 0; i < n; i++) {
--
1.7.6
^ permalink raw reply related
* Re: [PATCH 1/3] make-static: master
From: Ramsay Jones @ 2011-09-13 22:51 UTC (permalink / raw)
To: Junio C Hamano; +Cc: GIT Mailing-list
In-Reply-To: <7vhb4in4j7.fsf@alter.siamese.dyndns.org>
Junio C Hamano wrote:
> Many symbols that are exported to the global scope do not have to be.
>
> Signed-off-by: Junio C Hamano <junio@pobox.com>
> ---
> * To be applied on top of 3793ac5 (RelNotes/1.7.7: minor fixes, 2011-09-07)
>
[snipped patch]
commit f34196da7b55cbf9f2651e095b6559430aff0baf (make-static: master, 11-09-2011)
in the next branch (at repo.or.cz), but *not* this patch, breaks the build on
cygwin.
The failure is caused by this part of the commit:
diff --git a/environment.c b/environment.c
index e96edcf..478f2afa 100644
--- a/environment.c
+++ b/environment.c
@@ -147,11 +147,6 @@ int is_bare_repository(void)
return is_bare_repository_cfg && !get_git_work_tree();
}
-int have_git_dir(void)
-{
- return !!git_dir;
-}
-
const char *get_git_dir(void)
{
if (!git_dir)
since have_git_dir() is used in compat/cygwin.c (line 117).
ATB,
Ramsay Jones
^ permalink raw reply
* Re: [PATCH 2/2] obstack.c: Fix some sparse warnings
From: Ramsay Jones @ 2011-09-13 23:18 UTC (permalink / raw)
To: Sverre Rabbelier; +Cc: Junio C Hamano, GIT Mailing-list
In-Reply-To: <CAGdFq_ifU2WWbCpRY_EFY=_hwwtFs0eqMhJ7sRoUhrivABFoFw@mail.gmail.com>
Sverre Rabbelier wrote:
> Heya,
>
> On Sun, Sep 11, 2011 at 21:26, Ramsay Jones <ramsay@ramsay1.demon.co.uk> wrote:
>> compat/obstack.c:399:1: error: symbol 'print_and_abort' redeclared with \
>> different type (originally declared at compat/obstack.c:95) \
>> - different modifiers
>
>> @@ -395,7 +395,6 @@ _obstack_memory_used (struct obstack *h)
>> # endif
>>
>> static void
>> -__attribute__ ((noreturn))
>> print_and_abort (void)
>> {
>> /* Don't change any of these strings. Yes, it would be possible to add
>
> Wouldn't the better solution be to add noreturn to the declaration at
> compat/obstack.c:95?
Hmm, well ... maybe; it is at least debatable. But I decided no! :-D
First, although I would not dismiss the possibility of some optimization
of the code of print_and_abort() (the *callee*), the main benefit of the
noreturn attribute should in fact be at the call sites (ie the *caller*).
So, yes, in general, the declaration of the function should have the
noreturn attribute applied, in addition to the definition, in order to
allow the compiler to apply some optimizations to the call sites.
[Note, also, that we should use the NORETURN and NORETURN_PTR macros.]
In this case, however, there are no (direct) call sites. This function
would only be called indirectly via the 'obstack_alloc_failed_handler'
function pointer. So, this would require the use of NORETURN_PTR on
that function pointer. In order to keep both the compiler(s) and sparse
happy, the required change would look like the diff given at the end
of this mail.
This would work fine, and I would happily change the patch to include
this if it is deemed the better approach. However, I looked at the
call sites in _obstack_begin[_1](), and _obstack_newchunck() and could
not see any great opportunity for optimizing the code ... so I decided
to go for the simpler patch ...
ATB,
Ramsay Jones
-- >8 --
diff --git a/compat/obstack.c b/compat/obstack.c
index a89ab5b..2029b8f 100644
--- a/compat/obstack.c
+++ b/compat/obstack.c
@@ -92,8 +92,8 @@ enum
abort gracefully or use longjump - but shouldn't return. This
variable by default points to the internal function
`print_and_abort'. */
-static void print_and_abort (void);
-void (*obstack_alloc_failed_handler) (void) = print_and_abort;
+static void NORETURN print_and_abort (void);
+NORETURN_PTR void (*obstack_alloc_failed_handler) (void) = print_and_abort;
# ifdef _LIBC
# if SHLIB_COMPAT (libc, GLIBC_2_0, GLIBC_2_3_4)
@@ -395,7 +395,7 @@ _obstack_memory_used (struct obstack *h)
# endif
static void
-__attribute__ ((noreturn))
+NORETURN
print_and_abort (void)
{
/* Don't change any of these strings. Yes, it would be possible to add
diff --git a/compat/obstack.h b/compat/obstack.h
index d178bd6..122f93f 100644
--- a/compat/obstack.h
+++ b/compat/obstack.h
@@ -194,7 +194,7 @@ void obstack_free (struct obstack *, void *);
more memory. This can be set to a user defined function which
should either abort gracefully or use longjump - but shouldn't
return. The default action is to print a message and abort. */
-extern void (*obstack_alloc_failed_handler) (void);
+extern NORETURN_PTR void (*obstack_alloc_failed_handler) (void);
\f
/* Pointer to beginning of object being allocated or to be allocated next.
Note that this might not be the final address of the object
^ permalink raw reply related
* Re: [Survey] Signed push
From: Guenter Roeck @ 2011-09-13 23:26 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vaaa8xufi.fsf@alter.siamese.dyndns.org>
On Tue, Sep 13, 2011 at 12:45:37PM -0400, Junio C Hamano wrote:
[ ... ]
> 1. Improved pull requests.
>
noise for me
[ ... ]
> 2. Signed pushes.
>
Excellent idea, long since overdue.
Guenter
^ permalink raw reply
* Re: [PATCH/RFC] bash: add --word-diff option to diff auto-completion
From: SZEDER Gábor @ 2011-09-13 23:29 UTC (permalink / raw)
To: Jonathan Nieder
Cc: SZEDER Gábor, Rodrigo Rosenfeld Rosas, Thomas Rast, git
In-Reply-To: <20110913191448.GC14917@elie>
Hi,
On Tue, Sep 13, 2011 at 02:14:48PM -0500, Jonathan Nieder wrote:
> From: Rodrigo Rosenfeld Rosas <rr.rosas@gmail.com>
> Date: Tue, 13 Sep 2011 15:24:38 -0300
>
> Add "--word-diff" to diff completion, since this is a common
> desired option when looking at diffs.
>
> Signed-off-by: Rodrigo Rosenfeld Rosas <rr.rosas@gmail.com>
> ---
> Hi Gábor,
>
> Here's a patch. What do you think?
Looks obviously good to me, ...
> I was thinking it would be nice to complete --word-diff-regex, too,
> and to be able to do
>
> git diff --color-words=<TAB>
> git diff --word-diff=<TAB>
... but yeah, there is room for while-at-its ;)
The completion script currently only offers --color-words but not
--color-words=. This is sort of OK, because --color-words' parameters
are optional. However, in several cases the completion script offers
both --option and --option= to indicate that it takes an optional
parameter, see e.g.
diff --dirstat --dirstat-by-file
commit --untracked-files
format-patch --thread
init --shared
log --decorate
(But we don't do this in all such cases, see e.g. diff --stat --color
or log --branches --tags --remotes.)
So I think it's fine to offer both --color-words and --color-words=,
and both --word-diff and --word-diff=.
> but I couldn't find any examples of the latter to crib from
I'm not sure what you mean by git diff --color-words=<TAB>, because it
takes a regexp. Or is it just too late here and I'm missing something
obvious?
Completing the mode for --word-diff=<TAB> is a good idea, but c'mon,
there are plenty of examples ;) Have a look at _git_am(),
_git_format_patch(), or _git_init() for something easy, and
_git_commit(), _git_log(), or _git_notes() for something fancy.
Note that --word-diff= is also valid for log and shortlog, so the same
can be done there, too.
Best,
Gábor
^ permalink raw reply
* Re: [PATCH/RFC] bash: add --word-diff option to diff auto-completion
From: SZEDER Gábor @ 2011-09-13 23:37 UTC (permalink / raw)
To: Jonathan Nieder; +Cc: Rodrigo Rosenfeld Rosas, Thomas Rast, git
In-Reply-To: <20110913232941.GC2078@goldbirke>
On Wed, Sep 14, 2011 at 01:29:41AM +0200, SZEDER Gábor wrote:
> Or is it just too late here and I'm missing something
> obvious?
>
> Completing the mode for --word-diff=<TAB> is a good idea, but c'mon,
> there are plenty of examples ;) Have a look at _git_am(),
> _git_format_patch(), or _git_init() for something easy, and
> _git_commit(), _git_log(), or _git_notes() for something fancy.
>
> Note that --word-diff= is also valid for log and shortlog, so the same
> can be done there, too.
Not shortlog, show. It's definitely too late... ;)
^ permalink raw reply
* Re: [PATCH 1/3] make-static: master
From: Junio C Hamano @ 2011-09-13 23:46 UTC (permalink / raw)
To: Ramsay Jones; +Cc: GIT Mailing-list
In-Reply-To: <4E6FDE71.9050606@ramsay1.demon.co.uk>
Ramsay Jones <ramsay@ramsay1.demon.co.uk> writes:
> Junio C Hamano wrote:
>> Many symbols that are exported to the global scope do not have to be.
>>
>> Signed-off-by: Junio C Hamano <junio@pobox.com>
>> ---
>> * To be applied on top of 3793ac5 (RelNotes/1.7.7: minor fixes, 2011-09-07)
>>
> [snipped patch]
>
> commit f34196da7b55cbf9f2651e095b6559430aff0baf (make-static: master, 11-09-2011)
> in the next branch (at repo.or.cz), but *not* this patch, breaks the build on
> cygwin.
Thanks.
This kind of breakage report was exactly what I was looking for by
merging it early to 'next'. Hopefully no other (function / platform) combo
has such dependencies...
environment.c | 9 +++++++++
1 files changed, 9 insertions(+), 0 deletions(-)
diff --git a/environment.c b/environment.c
index 478f2afa..e810f6b 100644
--- a/environment.c
+++ b/environment.c
@@ -147,6 +147,15 @@ int is_bare_repository(void)
return is_bare_repository_cfg && !get_git_work_tree();
}
+/*
+ * This symbol might be unreferenced in normal builds but
+ * compat/cygwin.c refers to it. Do not remove without checking!
+ */
+int have_git_dir(void)
+{
+ return !!git_dir;
+}
+
const char *get_git_dir(void)
{
if (!git_dir)
^ permalink raw reply related
* Re: [Survey] Signed push
From: Junio C Hamano @ 2011-09-13 23:50 UTC (permalink / raw)
To: Guenter Roeck; +Cc: Junio C Hamano, git
In-Reply-To: <20110913232640.GA4189@ericsson.com>
Guenter Roeck <guenter.roeck@ericsson.com> writes:
> On Tue, Sep 13, 2011 at 12:45:37PM -0400, Junio C Hamano wrote:
> [ ... ]
>
>> 1. Improved pull requests.
>>
> noise for me
Are you among the ones who respond to pull requests?
^ permalink raw reply
* Re: [Survey] Signed push
From: Junio C Hamano @ 2011-09-14 0:02 UTC (permalink / raw)
To: Guenter Roeck; +Cc: git
In-Reply-To: <7v1uvkvw68.fsf@alter.siamese.dyndns.org>
Junio C Hamano <gitster@pobox.com> writes:
> Guenter Roeck <guenter.roeck@ericsson.com> writes:
>
>> On Tue, Sep 13, 2011 at 12:45:37PM -0400, Junio C Hamano wrote:
>> [ ... ]
>>
>>> 1. Improved pull requests.
>>>
>> noise for me
>
> Are you among the ones who respond to pull requests?
Sorry, this didn't come out quite the way I intended.
As I do not know every developer on earth, I would like to know in what
capacity you (figuratively---I mean everybody who gives his opinion on
this topic) fit in your ecosystem. Otherwise I cannot tell if many people
who receive pull requests find it noise but senders do not care, or many
people who send them find it noise but receivers do appreciate, etc.
For the purpose of commenting on "pull requests" topic, one can be (1)
a bystander, who does not request nor respond to pull requests, (2) who
gets requests to pull, or (3) who sends requests to pull.
The same for "signed pushes". In this case, one can be (1) who pushes, (2)
who fetches and wants to verify what he gets, (3) both (e.g. Linus
playing role (3) while fetching from his lieutenants and then role (1)
when pushing his integration results out).
^ permalink raw reply
* Re: [Survey] Signed push
From: Sam Vilain @ 2011-09-14 0:31 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Linus Torvalds, git, linux-kernel
In-Reply-To: <7vaaa8xufi.fsf@alter.siamese.dyndns.org>
On 9/13/11 9:45 AM, Junio C Hamano wrote:
> * You push out your work with "git push -s";
>
> * "git push" prepares a "push certificate" (it is meant to certify "these
> are the commits I place at the tips of these refs"), which is a human
> and machine readable text file in core, that may look like this:
>
> Push-Certificate-Version: 0
> Pusher: Junio C Hamano<gitster@pobox.com>
> Update: 3793ac56b4c4f9bf0bddc306a0cec21118683728 refs/heads/master
> Update: 12850bec0c24b529c9a9df6a95ad4bdeea39373e refs/heads/next
>
> and asks you to GPG sign it. You only unlock your GPG key and the
> command internally runs GPG, just like "tag -s".
>
> * When "git push" finishes, the receiving end has this record in its
> refs/notes/signed-push notes tree, together with your previous pushes
> (as this is not a shared repository, it will record only your pushes).
> The notes annnotate the commits named on the "Update:" lines above.
If the push certificate also has the previous commit IDs for the changed
refs, then you actually have an audit log. Otherwise, it does not
certify the commit range they pushed.
This is an important prerequisite for a fully distributed, peer to peer
git. For this case it would also need something to distinguish which
repository is to be updated; such as a canonical repository URL (or list
of URLs), or just a short project name. A P2P protocol can then know
projects as (KEYID, projectname).
Sam
^ permalink raw reply
* Re: [Survey] Signed push
From: Shawn Pearce @ 2011-09-14 0:39 UTC (permalink / raw)
To: Sam Vilain; +Cc: Junio C Hamano, Linus Torvalds, git
In-Reply-To: <4E6FF5D9.3080709@vilain.net>
On Tue, Sep 13, 2011 at 17:31, Sam Vilain <sam@vilain.net> wrote:
> On 9/13/11 9:45 AM, Junio C Hamano wrote:
>>
>> * "git push" prepares a "push certificate" (it is meant to certify "these
>> are the commits I place at the tips of these refs"), which is a human
>> and machine readable text file in core, that may look like this:
>>
>> Push-Certificate-Version: 0
>> Pusher: Junio C Hamano<gitster@pobox.com>
>> Update: 3793ac56b4c4f9bf0bddc306a0cec21118683728 refs/heads/master
>> Update: 12850bec0c24b529c9a9df6a95ad4bdeea39373e refs/heads/next
>
> If the push certificate also has the previous commit IDs for the changed
> refs, then you actually have an audit log. Otherwise, it does not certify
> the commit range they pushed.
Is that necessary? The range they are certifying is that commit, and
its entire ancestry. If the pusher doesn't trust his ancestry, why is
he working with it? Similar to an annotated tag. I make a signed
annotated tag, I am asserting that revision and its ancestry is
something I like as far as a project build goes. You don't need the
old revision to realize I like this commit.
If you want to get into the game of, maybe I push a branch, then
rewind it, and push something differently, and you want to be able to
verify that the 2nd push is the "right thing" and the 1st push should
be ignored, you can already see that by looking at the timestamp of
the push certificates (/me assumes there is a timestamp in there). If
you can create multiple signed pushes by yourself, using your GPG key,
within the same second, and they are conflicting... well, stop using
automated tools to create conflicting assertions as yourself. If you
are creating signed pushes on systems with clock skew, learn how to
configure NTP date.
> This is an important prerequisite for a fully distributed, peer to peer git.
> For this case it would also need something to distinguish which repository
> is to be updated; such as a canonical repository URL (or list of URLs), or
> just a short project name. A P2P protocol can then know projects as (KEYID,
> projectname).
Why do we need a project name? Most Git based projects are uniquely
identified by the set of root commits they have. Why? Because most
root commits were created by different people, at different times,
with different commit messages, and different initial trees, resulting
in a unique commit SHA-1 for that root commit. Projects with more than
one root commit also disambiguate themselves from other projects that
maybe contain one of those roots (e.g. git.git vs. gitk).
If you wanted to identify a project on a P2P network, I think you
would want to do it based off the root commits, not some random name
people came up with and might try to publish forgeries under.
--
Shawn.
^ permalink raw reply
* Re: [Survey] Signed push
From: Sam Vilain @ 2011-09-14 1:03 UTC (permalink / raw)
To: Shawn Pearce; +Cc: Junio C Hamano, Linus Torvalds, git
In-Reply-To: <CAJo=hJt-n0Xn85g7-7eEgxZhsBu8wd843dvvbaJgdYSx3t4Xug@mail.gmail.com>
On 9/13/11 5:39 PM, Shawn Pearce wrote:
> > If the push certificate also has the previous commit IDs for the changed
> > refs, then you actually have an audit log. Otherwise, it does not certify
> > the commit range they pushed.
> Is that necessary? The range they are certifying is that commit, and
> its entire ancestry. If the pusher doesn't trust his ancestry, why is
> he working with it? Similar to an annotated tag. I make a signed
> annotated tag, I am asserting that revision and its ancestry is
> something I like as far as a project build goes. You don't need the
> old revision to realize I like this commit.
Perhaps because they didn't notice what happened. Someone else pushed
to the server without a signed push somehow, and then they pulled,
pushed ... and now as far as you know, those commits are certified like
any other. Having this extra information, not much information, will
help figure out what happens in this sort of situation.
>> This is an important prerequisite for a fully distributed, peer to peer git.
>> For this case it would also need something to distinguish which repository
>> is to be updated; such as a canonical repository URL (or list of URLs), or
>> just a short project name. A P2P protocol can then know projects as (KEYID,
>> projectname).
> Why do we need a project name? Most Git based projects are uniquely
> identified by the set of root commits they have. Why? Because most
> root commits were created by different people, at different times,
> with different commit messages, and different initial trees, resulting
> in a unique commit SHA-1 for that root commit. Projects with more than
> one root commit also disambiguate themselves from other projects that
> maybe contain one of those roots (e.g. git.git vs. gitk).
>
> If you wanted to identify a project on a P2P network, I think you
> would want to do it based off the root commits, not some random name
> people came up with and might try to publish forgeries under.
>
Yes, this is true, but it also makes it a lot harder to figure out if
two projects are from the same real project, or whether they just shared
some history. In general, git repositories are partitioned by URL or
project, and so this makes a soft case for a distributed system to
partition itself by URL or project also.
Sam
^ permalink raw reply
* Re: What's cooking in git.git (Sep 2011, #04; Mon, 12)
From: Jonathon Mah @ 2011-09-14 2:34 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Dan McGee, David Aguilar, git
In-Reply-To: <7vipox2wd6.fsf@alter.siamese.dyndns.org>
On 2011-09-12, at 14:59, Junio C Hamano wrote:
>> [Stalled]
>>
>> * jm/mergetool-pathspec (2011-06-22) 2 commits
>> - mergetool: Don't assume paths are unmerged
>> - mergetool: Add tests for filename with whitespace
>>
>> I think this is a good idea, but it probably needs a re-roll.
>> Cf. $gmane/176254, 176255, 166256
>
> What's the plan for this series? Do we still want to pursue it within the
> timeframe for the next round?
>
> Is there any mergetool/difftool expert who volunteers to help moving this
> topic forward?
I'd love this to stay alive. As I've mentioned before, my relationship with shell is tenuous. My biggest problem is I don't have a mental model of how quoting works, so I end up writing tests and performing trial-and-error until it works.
On 2011-06-22, at 14:33, Junio C Hamano wrote:
> Why do you need a loop here in the else clause, instead of just a single:
>
> files=$(git ls-files -u -- "$@" |...)
See above (the dumb loop isn't necessary; your suggestion is much better). Should I bother re-submitting with just this change?
Jonathon Mah
me@JonathonMah.com
^ permalink raw reply
* Setting up Git Server
From: Joshua Stoutenburg @ 2011-09-14 2:46 UTC (permalink / raw)
To: Git List
Looking for some guidance in setting up a git server customized to my
specific needs. Could anybody walk me through the process?
I have a VirtualBox VM server on which I want to set up a cluster of VMs
each one for a different purpose -- experimentation, web hosting, and,
of course, git.
I'm using Ubuntu 10.04 LTS for the operating system. I have a single
public ip address.
I will want to access the git server over the internet. I want to
easily control git users, groups, and permissions apart from the linux
user system, specifying who can access what repositories.
I don't mind CLI, as opposed to GUI, as long as it is well explained,
and it is the most efficient way to do it.
After setting up the server, I'd also like some guidance setting up
individual workstations (*nix and Winblows) to use git in the Eclipse
IDE.
You're guidance greatly appreciated.
I'd gladly put together a step-by-step guide as we figure it out for
other users looking to do the same.
^ permalink raw reply
* Helping on Git development
From: Eduardo D'Avila @ 2011-09-14 3:05 UTC (permalink / raw)
To: git
In-Reply-To: <CAOz-D1JW8RSR8kVWhT7v-DCbWayU8KhbePJwWrWvJwbmueRezQ@mail.gmail.com>
Hi,
I have being using Git for some time now and I am very satisfied with it.
Now I'm considering giving back by helping on its development.
Is there any bug listing which I can check if there is some point I can help?
Any suggestions on other ways to help are also welcomed. :-)
Thanks,
Eduardo R. D'Avila
^ permalink raw reply
* Re: Helping on Git development
From: Andrew Ardill @ 2011-09-14 5:16 UTC (permalink / raw)
To: Eduardo D'Avila; +Cc: git
In-Reply-To: <CAOz-D1+77JZRXa57GLz=vZyrcGs4Ojj6Wa0cSD4QcEkMP3PPsA@mail.gmail.com>
On 14 September 2011 13:05, Eduardo D'Avila <erdavila@gmail.com> wrote:
> Hi,
>
> I have being using Git for some time now and I am very satisfied with it.
> Now I'm considering giving back by helping on its development.
> Is there any bug listing which I can check if there is some point I can help?
> Any suggestions on other ways to help are also welcomed. :-)
Hi Eduardo, as stated in the README,
The messages titled "A note from the maintainer", "What's in git.git
(stable)" and "What's cooking in git.git (topics)" and the discussion
following them on the mailing list give a good reference for project
status, development direction and remaining tasks.
Additionally, I think the README should include something like
If you are looking to contribute to the project, a good place to start
is http://git-blame.blogspot.com/p/note-from-maintainer.html and in
Documentation/howto/maintain-git.txt
because it took me forever to find them, and contributing will be
difficult until you have read them.
Regards,
Andrew Ardill
^ permalink raw reply
* Re: [PATCH 3/7] refactor argv_array into generic code
From: Christian Couder @ 2011-09-14 5:54 UTC (permalink / raw)
To: Jeff King; +Cc: Junio C Hamano, Jens Lehmann, git
In-Reply-To: <20110913215757.GC24490@sigill.intra.peff.net>
Hi Peff,
On Tue, Sep 13, 2011 at 11:57 PM, Jeff King <peff@peff.net> wrote:
> diff --git a/argv-array.c b/argv-array.c
> new file mode 100644
> index 0000000..a50507a
> --- /dev/null
> +++ b/argv-array.c
> @@ -0,0 +1,52 @@
> +#include "cache.h"
> +#include "argv-array.h"
> +#include "strbuf.h"
> +
> +static const char *empty_argv_storage = NULL;
> +const char **empty_argv = &empty_argv_storage;
> +
> +void argv_array_init(struct argv_array *array)
> +{
> + array->argv = empty_argv;
> + array->argc = 0;
> + array->alloc = 0;
> +}
> +
> +static void argv_array_push_nodup(struct argv_array *array, const char *value)
> +{
> + if (array->argv == empty_argv)
> + array->argv = NULL;
> +
> + ALLOC_GROW(array->argv, array->argc + 2, array->alloc);
> + array->argv[array->argc++] = value;
> + array->argv[array->argc] = NULL;
> +}
> +
> +void argv_array_push(struct argv_array *array, const char *value)
> +{
> + argv_array_push_nodup(array, xstrdup(value));
> +}
> +
> +void argv_array_pushf(struct argv_array *array, const char *fmt, ...)
> +{
> + va_list ap;
> + struct strbuf v = STRBUF_INIT;
> +
> + va_start(ap, fmt);
> + strbuf_vaddf(&v, fmt, ap);
> + va_end(ap);
> +
> + argv_array_push_nodup(array, strbuf_detach(&v, NULL));
> +}
In sha1-array you called the "push" function "sha1_array_append"
instead of "sha1_array_push", so I wonder why here you call them
"*_push*" instead of "*_append*"?
Thanks for doing this anyway,
Christian.
^ permalink raw reply
* Re: [PATCH 1/3] make-static: master
From: Johannes Sixt @ 2011-09-14 6:50 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Ramsay Jones, GIT Mailing-list
In-Reply-To: <7v62kwvwe9.fsf@alter.siamese.dyndns.org>
Am 9/14/2011 1:46, schrieb Junio C Hamano:
> This kind of breakage report was exactly what I was looking for by
> merging it early to 'next'. Hopefully no other (function / platform) combo
> has such dependencies...
There is! prepare_git_cmd is used from the Windows section in run-command.c.
Therefore, the following hunks of the patch should be reverted.
diff --git a/exec_cmd.c b/exec_cmd.c
index 171e841..1dddbf4 100644
--- a/exec_cmd.c
+++ b/exec_cmd.c
@@ -113,7 +113,7 @@ void setup_path(void)
strbuf_release(&new_path);
}
-const char **prepare_git_cmd(const char **argv)
+static const char **prepare_git_cmd(const char **argv)
{
int argc;
const char **nargv;
diff --git a/exec_cmd.h b/exec_cmd.h
index e2b546b..f5d2cdd 100644
--- a/exec_cmd.h
+++ b/exec_cmd.h
@@ -5,7 +5,6 @@ extern void git_set_argv_exec_path(const char *exec_path);
extern const char *git_extract_argv0_path(const char *path);
extern const char *git_exec_path(void);
extern void setup_path(void);
-extern const char **prepare_git_cmd(const char **argv);
extern int execv_git_cmd(const char **argv); /* NULL terminated */
extern int execl_git_cmd(const char *cmd, ...);
extern const char *system_path(const char *path);
^ permalink raw reply related
* Re: "git archive" seems to be broken wrt zip files
From: Linus Torvalds @ 2011-09-14 6:55 UTC (permalink / raw)
To: Andreas Schwab
Cc: Jeff King, René Scharfe, Junio C Hamano, Git Mailing List
In-Reply-To: <CA+55aFxsaE5btVJmM_QaUMcDzBg4df-g8X7NknC6t9UM+oQATw@mail.gmail.com>
Re-sent as this clearly never seems to have gone anywhere due to me
not realizing that the LF problems meant that while incoming email
worked fine, going out through smpt.linux-foundation.org didn't work.
Linus
On Sun, Sep 11, 2011 at 11:07 AM, Linus Torvalds
<torvalds@linux-foundation.org> wrote:
> On Sun, Sep 11, 2011 at 6:14 AM, Andreas Schwab <schwab@linux-m68k.org> wrote:
>>
>> It is. This only happens if you have more then 16k entries and when one
>> of the 16k entry infos is reused it happend to be previously used for a
>> symlink entry.
>
> Thanks for the explanation.
>
>> Here's a patch for unzip60 for reference:
>
> Is this problem known to the unzip developers? Is it actively
> maintained any more? The 6.0 release seems to have been from April
> 2009, and the web page seems to have a "last updated" of September
> 2009.. Is there some other unofficial archive for bugfixes like this?
> Distros?
>
> Linus
>
^ permalink raw reply
* Fwd: [Survey] Signed push
From: Linus Torvalds @ 2011-09-14 7:06 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, linux-kernel
In-Reply-To: <CA+55aFxAQTR3sT7gekAD4qih8J+z-qwri7ZmNCPUd811xgci6w@mail.gmail.com>
Recovering lost emails. Or maybe you get duplicates. Sorry about that if so,
Linus
---------- Forwarded message ----------
From: Linus Torvalds <torvalds@linux-foundation.org>
Date: Tue, Sep 13, 2011 at 10:48 AM
Subject: Re: [Survey] Signed push
To: Junio C Hamano <gitster@pobox.com>
Cc: git@vger.kernel.org, linux-kernel@vger.kernel.org
On Tue, Sep 13, 2011 at 9:45 AM, Junio C Hamano <gitster@pobox.com> wrote:
>
> We have a tentative patch to add an extra line after the "URL branch" line
> that is for your cut & paste that looks like:
>
> are available in the git repository at:
> git://git.kernel.org/pub/flobar.git/ master
> for you to fetch changes up to 5738c9c21e53356ab5020912116e7f82fd2d428f
>
> I often see you respond to a pull request on the kernel mailing list with
> "I see nothing new; forgot to push?", and having this extra line may also
> help communication.
I think that would probably be a good idea, although I'd actually
prefer you to be more verbose, and more human-friendly, and actually
talk about the commit in a readable way. Get rid of the *horrible*
BRANCH-NOT-VERIFIED message (that actually messes up pull requests if
mirroring is a bit delayed and throws away more important
information), and instead just have a blurb afterwards saying
something human-readable like
Top commit 1f51b001cccf: "Merge branches 'cns3xxx/fixes',
'omap/fixes' and 'davinci/fixes' into fixes"
and at *that* point you might have a "UNVERIFIED" notice for people
to check if they forgot to push.
So I'd much prefer something like that over:
> An alternative that I am considering is to let the requester say this
> instead:
>
> are available in the git repository at:
> git://git.kernel.org/pub/flobar.git/ 5738c9c21e53356ab5020912116e7f82fd2d428f
>
> without adding the extra line.
The extra line in the pull request is cheap - it's not like we need to
ration them. The above format, in contrast, requires that the person
doing the *pull* have a recent enough git client, otherwise the merge
commit message will be just horrible.
And even if you do have a new git client that turns the commit into a
branch name, that's ambigious. What if both 'master' and
'experimental' have the same top commit, because experimental ended up
being tested and was percolated to master? Which branch name would you
pick? And what if the branch was updated since, so *no* branch name
matches - does that mean that you'd disallow the pull entirely?
> 2. Signed pushes.
>
> You tag official releases and release candidates with your GPG key, and
> everybody who works within the kernel ecosystem trusts the history behind
> the commits pointed by them, but there is no easy way to verify that
> commits and merges between the last tagged commit and the tip of your
> branch(es) are indeed from you, or if an intruder piled fake ones on top
> of your commits (until you try to push again and discover that the history
> does not fast-forward, that is).
>
> We have been discussing an addition of "git push -s" to let people sign
> their pushes (instead of having to sign every commit or add signed
> tag). The implementation alternatives were being bikeshed but not of much
> interest in this message, but the user experience would go like this:
Also, if we're adding branch information, I'd say that a description
of the branch is more important than a signature. Right now we lack
even that.
It would be lovely if people could annotate their branches with
descriptions, so that when I pull a "for-linus" branch, if it has a
description, the description of the branch makes it into the merge
message. Our merge messages are often not very informative.
I realize that cryptographic signature sound very important right now,
but in the end, *real* trust comes from people, not from signatures.
Realistically, I checked a few signatures this time around due to the
k.org issues, but at the same thing, the thing that made me trust most
of it was just looking at commits and the email messages. The
unconscious and non-cryptographic "signature" of a person acting like
you expect a person to act.
Technical measures can be subverted, and I think we should also think
about the social side. Every time somebody mentions a signature, I
want to also mention "human readability", because I think that matters
as much, if not more.
So I'm not against signed pushes, but quite frankly, if you add some
per-branch signature, I would argue against it unless that signature
also comes with information that allows us to do a better job of human
communication too. Like a branch description.
Imagine, for example, than when you do a
git push -s ..
git would *require* you to actually write a message about what you are
pushing. And when somebody pulls it, and creates a merge commit, that
explanation would become part of the merge message. The "signature"
part of the "-s" should be thought of as the *much* less interesting
part - that's just a small detail that git can use to verify
something, but it doesn't actually matter for the contents of the
pull. Not like the actual human-readable message would.
Now *that* would be lovely. No?
Linus
^ permalink raw reply
* Re: [PATCH] git-p4: import utf16 file properly
From: Luke Diamand @ 2011-09-14 7:55 UTC (permalink / raw)
To: Chris Li; +Cc: git, Pete Wyckoff, Junio C Hamano
In-Reply-To: <CANeU7QndA0yv1OzU3vta5B8r8nCRdBSqTy0Rboc_bbpst+1pcw@mail.gmail.com>
On 13/09/11 22:33, Chris Li wrote:
> The current git-p4 does not handle utf16 files properly.
> The "p4 print" command, when output to stdout, converts the
> utf16 file into utf8. That effectively imported the utf16 file
> as utf8 for git. In other words, git-p4 import a different
> file compare to file check out by perforce. This breakes my
> windows build in the company project.
>
> The fix is simple, just ask perforce to print the depot
> file into a real file. This way perforce will not performe
> the utf16 to utf8 conversion. Git can import the exact same
> file as perforce checkout.
Does this change do the right thing with RCS keywords in UTF16 files?
If p4CmdList() fails, e.g. due to running out of diskspace, will this
just happily import a truncated/corrupt file?
(And I could be wrong about this, but does you patch have newline
damage? It didn't seem to apply for me).
Regards!
Luke
> ---
> contrib/fast-import/git-p4 | 5 +++++
> 1 files changed, 5 insertions(+), 0 deletions(-)
>
> diff --git a/contrib/fast-import/git-p4 b/contrib/fast-import/git-p4
> index 6b9de9e..5fb1ac7 100755
> --- a/contrib/fast-import/git-p4
> +++ b/contrib/fast-import/git-p4
> @@ -1239,6 +1239,11 @@ class P4Sync(Command, P4UserMap):
> contents = map(lambda text:
> re.sub(r'(?i)\$(Id|Header):[^$]*\$',r'$\1$', text), contents)
> elif file['type'] in ('text+k', 'ktext', 'kxtext',
> 'unicode+k', 'binary+k'):
> contents = map(lambda text:
> re.sub(r'\$(Id|Header|Author|Date|DateTime|Change|File|Revision):[^$\n]*\$',r'$\1$',
> text), contents)
> + elif file['type'] == 'utf16':
> + tmpFile = tempfile.NamedTemporaryFile()
> + p4CmdList("print -o %s %s"%(tmpFile.name, file['depotFile']))
> + contents = [ open(tmpFile.name).read() ]
> + tmpFile.close()
>
> self.gitStream.write("M %s inline %s\n" % (mode, relPath))
>
^ permalink raw reply
* Re: [PATCH] contrib: add a credential helper for Mac OS X's keychain
From: John Szakmeister @ 2011-09-14 8:01 UTC (permalink / raw)
To: Jay Soffian; +Cc: git, Junio C Hamano, Jeff King
In-Reply-To: <1315683874-95583-1-git-send-email-jaysoffian@gmail.com>
On Sat, Sep 10, 2011 at 3:44 PM, Jay Soffian <jaysoffian@gmail.com> wrote:
> A credential helper which uses /usr/bin/security to add, search,
> and remove entries from the Mac OS X keychain.
>
> Tested with 10.6.8.
>
> Signed-off-by: Jay Soffian <jaysoffian@gmail.com>
> ---
> This is a quick script to explore the new credential API. A more robust
> implementation would be to link to OS X's Security framework from C.
[snip]
> +def add_internet_password(protocol, hostname, username, password):
> + # We do this over a pipe so that we can provide the password more
> + # securely than as an argument which would show up in ps output.
> + # Unfortunately this is possibly less robust since the security man
> + # page does not document how to quote arguments. Emprically it seems
> + # that using the double-quote, escaping \ and " works properly.
I'm not sure this comment is correct... it looks like you're passing
the password on the command line...
> + username = username.replace('\\', '\\\\').replace('"', '\\"')
> + password = password.replace('\\', '\\\\').replace('"', '\\"')
> + command = ' '.join([
> + 'add-internet-password', '-U',
> + '-r', protocol,
> + '-s', hostname,
> + '-a "%s"' % username,
> + '-w "%s"' % password,
...right here. :-(
-John
^ permalink raw reply
* Re: Setting up Git Server
From: Philippe Vaucher @ 2011-09-14 8:09 UTC (permalink / raw)
To: Joshua Stoutenburg; +Cc: Git List
In-Reply-To: <CAOZxsTqFfOR+Eb3rqz5hZSJRTe=a1N-CEM--GGGGO2yayT-HLA@mail.gmail.com>
> I will want to access the git server over the internet. I want to
> easily control git users, groups, and permissions apart from the linux
> user system, specifying who can access what repositories.
Have a look at gitolite (https://github.com/sitaramc/gitolite).
It's not very hard to setup and then it's pretty easy to work with. It
can also be integrated with stuffs like redmine.
Philippe
^ 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