* Re: [PATCH 3/5] fast-import: check committer name more strictly
From: Junio C Hamano @ 2011-08-02 17:01 UTC (permalink / raw)
To: Dmitry Ivankov; +Cc: git, SASAKI Suguru
In-Reply-To: <1311831844-13123-4-git-send-email-divanorama@gmail.com>
Dmitry Ivankov <divanorama@gmail.com> writes:
> Signed-off-by: Dmitry Ivankov <divanorama@gmail.com>
> ---
Please describe how you check this field "more strictly" in the body of
the log message, iow, against what rule you are validating, perhaps
something like:
The identifier must be either "<address>" or "Name <address>" where
neither address nor Name can contain '<' nor '>'; otherwise the input
stream is rejected.
As fast-import is used to _create_ new objects, its input is a simple text
file that can be fixed-up as needed, it is a good idea to validate the
input more strictly and rejecting bad ones.
^ permalink raw reply
* Re: [PATCH 2/5] fast-import: don't fail on omitted committer name
From: Dmitry Ivankov @ 2011-08-02 17:07 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, SASAKI Suguru
In-Reply-To: <7voc07g3fr.fsf@alter.siamese.dyndns.org>
On Tue, Aug 2, 2011 at 10:53 PM, Junio C Hamano <gitster@pobox.com> wrote:
> Dmitry Ivankov <divanorama@gmail.com> writes:
>
>> fast-import format declares 'committer_name SP' to be optional. But SP
>> between empty or not name and a email is obligatory and checked by
>
> Sorry, cannot parse this.
Ok, the point is fast-import input format for identities is declared to be
'(name SP)? LT email GT' (followed by a datetime)
where name and email are allowed to be empty (and should not have
LF, LT, GT characters).
While git-fsck checks identities to be in form
'name SP LT email GT' (followed by a datetime)
where name and email are allowed to be empty (and should not have
LF, LT, GT characters).
So fast-import must prepend a space if the name part is omitted. This
patch makes it do so.
>
>> git-fsck, so fast-import must prepend the SP if the name is omitted.
>> Currently it doesn't.
>>
>> Name cannot contain LT or GT and ident always comes after SP in
>> fast-import. So reuse that SP as if a valid 'SP <email>' ident was passed.
>>
>> This fixes a ident parsing bug for a well-formed fast-import input.
>> Though the parsing is still loose and can accept a ill-formed input.
>>
>> Signed-off-by: Dmitry Ivankov <divanorama@gmail.com>
>> ---
>> fast-import.c | 4 ++++
>> t/t9300-fast-import.sh | 2 +-
>> 2 files changed, 5 insertions(+), 1 deletions(-)
>>
>> diff --git a/fast-import.c b/fast-import.c
>> index 9e8d186..3194f4e 100644
>> --- a/fast-import.c
>> +++ b/fast-import.c
>> @@ -1972,6 +1972,10 @@ static char *parse_ident(const char *buf)
>> size_t name_len;
>> char *ident;
>>
>> + /* ensure there is a space delimiter even if there is no name */
>> + if (*buf == '<')
>> + --buf;
>> +
>> gt = strrchr(buf, '>');
>> if (!gt)
>> die("Missing > in ident string: %s", buf);
>> diff --git a/t/t9300-fast-import.sh b/t/t9300-fast-import.sh
>> index a659dd4..09ef6ba 100755
>> --- a/t/t9300-fast-import.sh
>> +++ b/t/t9300-fast-import.sh
>> @@ -352,7 +352,7 @@ data <<COMMIT
>> empty commit
>> COMMIT
>> INPUT_END
>> -test_expect_failure 'B: accept and fixup committer with no name' '
>> +test_expect_success 'B: accept and fixup committer with no name' '
>> git fast-import <input &&
>> out=$(git fsck) &&
>> echo "$out" &&
>
^ permalink raw reply
* [RFC] branch: list branches by single remote
From: Michael Schubert @ 2011-08-02 17:17 UTC (permalink / raw)
To: git
I've always missed some option for "git branch" to limit the output to a single
remote. What's the right place to filter the output? The code below doesn't
look very smart..
---
builtin/branch.c | 16 +++++++++++++---
1 files changed, 13 insertions(+), 3 deletions(-)
diff --git a/builtin/branch.c b/builtin/branch.c
index 3142daa..22e6be2 100644
--- a/builtin/branch.c
+++ b/builtin/branch.c
@@ -17,7 +17,7 @@
#include "revision.h"
static const char * const builtin_branch_usage[] = {
- "git branch [options] [-r | -a] [--merged | --no-merged]",
+ "git branch [options] [-r | -a] [-R <remote>] [--merged | --no-merged]",
"git branch [options] [-l] [-f] <branchname> [<start-point>]",
"git branch [options] [-r] (-d | -D) <branchname>...",
"git branch [options] (-m | -M) [<oldbranch>] <newbranch>",
@@ -260,6 +260,7 @@ static char *resolve_symref(const char *src, const char *prefix)
struct append_ref_cb {
struct ref_list *ref_list;
+ const char *remote;
int ret;
};
@@ -297,6 +298,9 @@ static int append_ref(const char *refname, const unsigned char *sha1, int flags,
if ((kind & ref_list->kinds) == 0)
return 0;
+ if (cb->remote && strncmp(cb->remote, refname, strlen(cb->remote)))
+ return 0;
+
commit = NULL;
if (ref_list->verbose || ref_list->with_commit || merge_filter != NO_FILTER) {
commit = lookup_commit_reference_gently(sha1, 1);
@@ -492,7 +496,7 @@ static void show_detached(struct ref_list *ref_list)
}
}
-static int print_ref_list(int kinds, int detached, int verbose, int abbrev, struct commit_list *with_commit)
+static int print_ref_list(int kinds, int detached, int verbose, int abbrev, struct commit_list *with_commit, const char *only)
{
int i;
struct append_ref_cb cb;
@@ -506,6 +510,7 @@ static int print_ref_list(int kinds, int detached, int verbose, int abbrev, stru
if (merge_filter != NO_FILTER)
init_revisions(&ref_list.revs, NULL);
cb.ref_list = &ref_list;
+ cb.remote = only;
cb.ret = 0;
for_each_rawref(append_ref, &cb);
if (merge_filter != NO_FILTER) {
@@ -618,6 +623,7 @@ int cmd_branch(int argc, const char **argv, const char *prefix)
enum branch_track track;
int kinds = REF_LOCAL_BRANCH;
struct commit_list *with_commit = NULL;
+ char *single_remote = NULL;
struct option options[] = {
OPT_GROUP("Generic options"),
@@ -647,6 +653,7 @@ int cmd_branch(int argc, const char **argv, const char *prefix)
OPT_GROUP("Specific git-branch actions:"),
OPT_SET_INT('a', NULL, &kinds, "list both remote-tracking and local branches",
REF_REMOTE_BRANCH | REF_LOCAL_BRANCH),
+ OPT_STRING('R', NULL, &single_remote, "remote", "list only branches by remote"),
OPT_BIT('d', NULL, &delete, "delete fully merged branch", 1),
OPT_BIT('D', NULL, &delete, "delete branch (even if not merged)", 2),
OPT_BIT('m', NULL, &rename, "move/rename a branch and its reflog", 1),
@@ -696,10 +703,13 @@ int cmd_branch(int argc, const char **argv, const char *prefix)
if (!!delete + !!rename + !!force_create > 1)
usage_with_options(builtin_branch_usage, options);
+ if (single_remote)
+ kinds = REF_REMOTE_BRANCH;
+
if (delete)
return delete_branches(argc, argv, delete > 1, kinds);
else if (argc == 0)
- return print_ref_list(kinds, detached, verbose, abbrev, with_commit);
+ return print_ref_list(kinds, detached, verbose, abbrev, with_commit, single_remote);
else if (rename && (argc == 1))
rename_branch(head, argv[0], rename > 1);
else if (rename && (argc == 2))
--
1.7.6.396.ge0613.dirty
^ permalink raw reply related
* Re: [PATCH v2 2/2] grep: long context options
From: René Scharfe @ 2011-08-02 17:24 UTC (permalink / raw)
To: Tait; +Cc: Git Mailing List, Sverre Rabbelier, Junio C Hamano
In-Reply-To: <20110802010143.GL13795@ece.pdx.edu>
Am 02.08.2011 03:01, schrieb Tait:
> René Scharfe <rene.scharfe_lsrfire.ath.cx> said (on 2011/08/01):
>> Take long option names for -A (--after-context), -B (--before-context)
>> and -C (--context) from GNU grep and add a similar long option name
>> for -W (--function-context).
>
> Why not just add --context=function? Then when I want --context=indent
> to give context based on the indent-level, it is an intuitive extension
> of the existing options. (Of course, --context=<number> would still do
> exactly what it does now.)
With the current patches, you can use --function-context together with
--context=<num> to specify a minimum number of context lines to show,
even beyond function boundaries.
I'd expect a --context=function option to be equivalent to -W -C0 and
--context=<num> to be equivalent to -C<num> --no-function-context, so
the syntax would be limited in that regard (or be unintuitive to me).
We can still add it on top, though.
René
^ permalink raw reply
* Re: [RFC 4/6] git-check-attr: Normalize paths
From: Junio C Hamano @ 2011-08-02 17:24 UTC (permalink / raw)
To: Michael Haggerty; +Cc: git
In-Reply-To: <1311849425-9057-5-git-send-email-mhagger@alum.mit.edu>
Michael Haggerty <mhagger@alum.mit.edu> writes:
> 1. I'm not sure whether it is correct to fix this problem at the level
> of git-check-attr, or whether the fix belongs in the API layer.
> What is the convention for API functions? Do they typically take
> path names relative to the CWD or relative to the working tree
> root, or ...?
I think passing down "prefix" (i.e. where your $(cwd) was relative to the
root level of the working tree) and the user-supplied "pathspec" (which
typically is relative to that original $(cwd)) is the canonical approach.
The very original git worked only at the root level of the working tree,
with paths specified relative to the root level of the tree, so many code
do:
- find out the root of the working tree;
- note where the $(cwd) was in "prefix";
- chdir to the root of the working tree;
- prepend the "prefix" to user supplied pathspec;
- forget all the complexity and work on the whole tree.
Then the "prefix" gets stripped away from the beginning of the paths when
reporting.
Your patch from a cursory look seems to follow that pattern, which is
good.
^ permalink raw reply
* Re: [PATCH 1/2] Diff patterns for POSIX shells
From: Junio C Hamano @ 2011-08-02 17:51 UTC (permalink / raw)
To: Giuseppe Bilotta; +Cc: git
In-Reply-To: <1312195069-10782-2-git-send-email-giuseppe.bilotta@gmail.com>
Giuseppe Bilotta <giuseppe.bilotta@gmail.com> writes:
> All diffs following a function definition will have that function name
> as chunck header, but this is the best we can do with the current
> userdiff capabilities.
>
> Signed-off-by: Giuseppe Bilotta <giuseppe.bilotta@gmail.com>
> ---
> userdiff.c | 3 +++
> 1 files changed, 3 insertions(+), 0 deletions(-)
>
> diff --git a/userdiff.c b/userdiff.c
> index 01d3a8b..70120c3 100644
> --- a/userdiff.c
> +++ b/userdiff.c
> @@ -107,6 +107,9 @@
> "(@|@@|\\$)?[a-zA-Z_][a-zA-Z0-9_]*"
> "|[-+0-9.e]+|0[xXbB]?[0-9a-fA-F]+|\\?(\\\\C-)?(\\\\M-)?."
> "|//=?|[-+*/<>%&^|=!]=|<<=?|>>=?|===|\\.{1,3}|::|[!=]~"),
> +PATTERNS("shell", "^[ \t]*([a-zA-Z_0-9]+)[ \t]*\\(\\).*",
> + /* -- */
> + "(--|\\$)?[a-zA-Z_0-9]+|&&|\\|\\|"),
Hmm, what is this "double-dash -- might be present before a name" about?
> PATTERNS("bibtex", "(@[a-zA-Z]{1,}[ \t]*\\{{0,1}[ \t]*[^ \t\"@',\\#}{~%]*).*$",
> "[={}\"]|[^={}\" \t]+"),
> PATTERNS("tex", "^(\\\\((sub)*section|chapter|part)\\*{0,1}\\{.*)$",
^ permalink raw reply
* Re: [PATCH 0/5] bisect: Add support for a --no-checkout option.
From: Junio C Hamano @ 2011-08-02 17:53 UTC (permalink / raw)
To: Jon Seymour; +Cc: Christian Couder, git, j6t, jnareb
In-Reply-To: <CAH3Anro-ve2ZoTnbEvWyNH7kEMBCQOoCDfqZbPPxymn12pzAbQ@mail.gmail.com>
Jon Seymour <jon.seymour@gmail.com> writes:
>> Then, the next series can add a --bisect-head option (instead of
>> --update-ref) to allow the head to be varied (defaulting to
>> BISECT_HEAD) if not specified.
>
> To clarify: --bisect-head would default to HEAD if mode is checkout,
> to BISECT_HEAD if the mode is update-ref.
I am not sure if we ever want to allow updating anything but HEAD under
checkout mode, so I would rather think --bisect-head is _always_ invalid
under that mode. IOW, as I said in the previous message, these two are not
independent options.
^ permalink raw reply
* Re: [PATCH v13 4/8] bisect: introduce support for --no-checkout option.
From: Junio C Hamano @ 2011-08-02 18:00 UTC (permalink / raw)
To: Jon Seymour; +Cc: git, chriscool, j6t, jnareb
In-Reply-To: <1312284545-2426-5-git-send-email-jon.seymour@gmail.com>
Jon Seymour <jon.seymour@gmail.com> writes:
> If --no-checkout is specified, then the bisection process uses:
>
> git update-ref --no-deref HEAD <trial>
>
> at each trial instead of:
>
> git checkout <trial>
> ...
Ok.
> int cmd_bisect__helper(int argc, const char **argv, const char *prefix)
> {
> int next_all = 0;
> + int no_checkout = 0;
> + char *bisect_mode=NULL;
> struct option options[] = {
> OPT_BOOLEAN(0, "next-all", &next_all,
> "perform 'git bisect next'"),
> + OPT_STRING(0, "bisect-mode", &bisect_mode, "mode",
> + "the bisection mode either checkout or update-ref. defaults to checkout."),
I think this is a regression from naming perspective from the previous
round. You would be either the normal (checkout) mode or no-checkout mode,
and honestly, --no-checkout would be understood by anybody while update-ref
would be understood only by Gitz.
^ permalink raw reply
* Re: [PATCH v2 1/2] grep: add option to show whole function as context
From: René Scharfe @ 2011-08-02 18:08 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Git Mailing List, Sverre Rabbelier
In-Reply-To: <7vei14hgcd.fsf@alter.siamese.dyndns.org>
Am 02.08.2011 01:17, schrieb Junio C Hamano:
> René Scharfe <rene.scharfe@lsrfire.ath.cx> writes:
>
>> Add a new option, -W, to show the whole surrounding function of a match.
>
> Thanks, will queue both patches.
>
> It feels somewhat dirty to take the range between the previous "funcname"
> and the next "funcname" and consider it the whole function, as if there is
> nothing outside the function, though. I certainly understand that this is
> a natural and unfortunate consequence that "funcname" is a mechanism
> designed to mark only the _beginning_, and we didn't have any need for a
> mechanism to mark the _end_.
>
> I am not complaining; just making an observation. I do not offhand have a
> suggestion for improving this, and I think the obvious "then let's come up
> with another configuration to mark the end" is not an improvement but
> making things worse, so...
A certain amount of dirtyness is unavoidable unless we use a real
parser. Apropos, labels are function boundaries as well, so there we
have another limitation (i.e. we won't get a function whole if it
contains labels without leading whitespace).
Ideally I'd like to see the whole function text up to the closing brace
but including any leading comments, if present. Which is even more
complicated, of course.
For C-style and Shell files, /^}/ would probably suffice as a regex to
find function endings..
First I'm curious to see how useful the simple start-to-start heuristic
is, though. Even the -[ABC] options are kind of fuzzy -- how do you
know the number is high enough before running grep? Let's see how far
this quick and dirty approach to present a smarter context can take us.
René
^ permalink raw reply
* Re: [PATCH] commit: write out cache-tree information
From: Junio C Hamano @ 2011-08-02 18:13 UTC (permalink / raw)
To: trast; +Cc: git, Carlos Martín Nieto
In-Reply-To: <9f5e031045b55c4738de8bc9aae290827e128cd3.1312302862.git.trast@student.ethz.ch>
<trast@student.ethz.ch> writes:
> From: Thomas Rast <trast@student.ethz.ch>
>
> While write-tree has code to write out the cache-tree information
> (since we have to compute it anyway if the cache is stale), commit
> lost this capability when it became a builtin and moved away from
> using write-tree.
Earlier the code read from the index, made sure that it is not unmerged by
running cache_tere_update(), before running prepare-commit-msg hook. The
hook used to see the index that was read in this codepath which is the
same as what pre-commit left us.
Why run an extra I/O here? The index file could be quite large, and I do
not want people to writing it out without good reason.
The tree object that is committed is taken from active_cache_tree->sha1 in
cmd_commit() and not from the cache tree you are writing out to the index
file.
^ permalink raw reply
* Re: [PATCH v2 4/4] upload-archive: use start_command instead of fork
From: Jeff King @ 2011-08-02 18:13 UTC (permalink / raw)
To: René Scharfe; +Cc: Johannes Sixt, Erik Faye-Lund, Junio C Hamano, git
In-Reply-To: <4E3829DC.8070802@lsrfire.ath.cx>
On Tue, Aug 02, 2011 at 06:46:20PM +0200, René Scharfe wrote:
> The output of gzip is not simply always mangled, though (taken from my
> earlier email, all three are working):
>
> $ git archive v1.7.6 | gzip -cn | md5sum
> a0ca1c873a533a5fcd41d248fb325a5b *-
>
> $ git archive --format=tar.gz v1.7.6 | md5sum
> a0ca1c873a533a5fcd41d248fb325a5b *-
>
> $ git archive v1.7.6 | gzip -cn >a.tgz && md5sum <a.tgz
> a0ca1c873a533a5fcd41d248fb325a5b *-
>
> It's only broken if we call it from git archive:
>
> $ git archive --format=tar.gz v1.7.6 >a.tgz && md5sum <a.tgz
> 30886283af1aed05ae6a36fc5aeda077 *-
>
> $ git archive -o a.tgz v1.7.6 && md5sum <a.tgz
> 30886283af1aed05ae6a36fc5aeda077 *-
>
> But not if we stuff the result into a pipe instead of a file:
>
> $ git archive --format=tar.gz v1.7.6 | cat >a.tgz && md5sum <a.tgz
> a0ca1c873a533a5fcd41d248fb325a5b *-
>
> It _is_ confusing.
Hmm. So it's not _just_ the pipe vs file thing. What's different about
calling it from the shell, versus the way we call it from git-archive?
IOW, the pipe trick you mentioned is one way to fix it; but it may be
more elegant to do whatever it is the shell is doing to get those
results (unless the shell is secretly putting a "cat" into the pipeline
:) ).
-Peff
^ permalink raw reply
* Re: tracking submodules out of main directory.
From: Jens Lehmann @ 2011-08-02 18:42 UTC (permalink / raw)
To: henri GEIST
Cc: Alexei Sholik, Junio C Hamano, git, Sverre Rabbelier, Heiko Voigt
In-Reply-To: <1312287584.3261.798.camel@Naugrim.eriador.com>
Am 02.08.2011 14:19, schrieb henri GEIST:
> Le lundi 01 août 2011 à 21:39 +0200, Jens Lehmann a écrit :
>> Am 30.07.2011 23:55, schrieb henri GEIST:
>>> I can not see the difference with a gitlink.
>>
>> Then you can just use a config file for that, no? ;-)
>
> Off corse, I immediately start to work on it.
I'm looking forward to that!
^ permalink raw reply
* Re: Storing additional information in commit headers
From: Jeff King @ 2011-08-02 18:51 UTC (permalink / raw)
To: martin f krafft; +Cc: git discussion list, Petr Baudis, Clemens Buchacher
In-Reply-To: <20110802082810.GC29887@fishbowl.rw.madduck.net>
On Tue, Aug 02, 2011 at 10:28:10AM +0200, martin f krafft wrote:
> TopGit does what you suggest (a parallel ref structure), but there
> are three problems with this, which I am trying to address:
>
> 1. you need to ensure that these refs are pushed and fetched,
> which requires set up and possible migration issues when things
> change, and can cause big problems for contributors who just so
> happened to forget.
I agree that is an annoyance, but it is one we can deal with. In the
near term, I wonder if a "tg clone" would be appropriate to add the
extra fetch refspecs when cloning (or even a "tg init" inside an
existing git repo -- I don't actually use topgit, so I'm not sure what
the usual initialization process, if any, is).
In the longer term, it might be nice if git was better at sharing
third-party refs. The problem is that we don't know what the refs mean,
so we don't know which ones are appropriate for sharing. Maybe we could
do something like "refs/shared/topgit/*", and git by default would push
and pull items under refs/shared?
There have also been proposals to have a more mirror-like structure to
what we fetch from remotes. E.g., to put remote refs/tags into
refs/remotes/origin/refs/tags, and similar for notes. It may be that it
is sensible for us to just fetch everything from a remote into
refs/remotes, including unknown hierarchies like topgit.
> 2. the additional refs confuse people a lot — and I can attest to
> that because I have also at times found myself overwhelmed by
> them when staring at gitk.
Using "gitk --all", I assume? I agree it is annoying, though "gitk
--branches" probably better specifies what you want (unless you stick
the parallel ref structure under refs/heads above, which is also a
solution to the "should it be fetched" plan).
> 3. once a ref updates, we need to keep a pointer to the previous
> location, since one of the goals is the ability to be able to
> return to a point in history (e.g. for security updates to
> a stable package, or backports). Additional refs enhance the
> aforementioned two problems.
Reflogs provide a linear history of the ref updates, but I suspect you
want to be able to push and pull these histories. Which reflogs will not
do.
If you want to version the state of refs, then using raw refs isn't the
right answer. You want a separate commit history with trees that map ref
names to commits or other objects. Which is _almost_ what notes are;
they map commit sha1s, but you want to map ref names.
> Therefore I thought it would be sensible to store these data in
> commit. When the data change, there will always be a new commit to
> store these data, and we do *not* want to update the data in
> previous commits. Finding the data then becomes backtracking the
> branch history until a commit is found containing them.
That seems to me like you are sticking information in a commit that is
not actually about the commit, but about the ref that happens to point
to the commit. What if I have two refs that point to the same commit,
but with two different topgit bases? What about years later, when that
information isn't interesting anymore? You're still carrying the cruft
inside your commit objects.
> > However, implementing such a thing would mean you have an awkward
> > transition period where some versions of git think the referenced
> > object is relevant, and others do not. That's something we can
> > overcome, but it's going to require code in git, and possibly
> > a dormant introduction period.
>
> Indeed. This could be adressed by letting a tool like TopGit require
> a minimum version of Git. For a while, this will burden developers,
> but ensure that it works. Over time, this will cease to be
> a problem.
Keep in mind that your requirement is not just a local thing. Object
reachability is something that both sides of a transfer need to agree
on. So imagine you use TopGit with a new version of git, and you push to
a site like GitHub. The remote side will take your objects, but it will
not send them back to anyone who fetches from your repository (since it
has no idea they're relevant). And it will probably prune them after a
week or two.
> What do you think about using the idea of orphan parent commits
> (OPC) for now? These are conceptually closest to the x-*-ref
> pointers, do not require extra setup, pollute history only a little
> bit (IMHO), and slot in with Git and fsck/gc alright.
It doesn't seem like a good idea to me. Parent pointers have a
well-defined meaning, and other parts of git (and other tools, even) are
going to assume that's what your parent pointers mean. They are used in
merge base calculations, for example. I _think_ you are mostly safe
here, because your OPC wouldn't have any real history to it, so finding
a merge base down that path would be fruitless.
But consider something like "diff", which shows a merge commit
differently than a regular commit. Your commits will unexpectedly appear
as merges to git, and we will show a combined diff versus the OPC, which
is going to be ugly.
> I am not yet sure what information needs storing. Right now, I am
> keeping five fields:
> [...]
Thanks, that helped with getting a sense of what you're doing.
> I think there are two questions:
>
> 1. would x-*-ref be a suitable idea for Git core?
>
> I think the answer is yes, as (I think) it's well-defined and
> I cannot see any problems with it, really.
I think it's a nice idea for extensibility. And if it had been there
from day one, there would be no problems. But now we have to deal with
the transition period, and the fact that two different versions of git
will have different ideas about the set of objects that are reachable
from a given commit.
> 2. can we prevent abuse?
>
> No, never. But just like you cannot abuse X-* headers in the
> RFC822 format due to their design, x-*-ref abuse would only
> affect those who chose it.
I don't worry about abuse. You can already stick random cruft in a
commit header, and you can already connect objects to a commit via tree
entries. This idea is just giving git some rules for dealing with it.
I'm still not 100% convinced you want per-commit storage, though, and
not per-ref storage.
-Peff
^ permalink raw reply
* Re: [PATCH 1/2] Diff patterns for POSIX shells
From: Giuseppe Bilotta @ 2011-08-02 18:52 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vzkjrem6b.fsf@alter.siamese.dyndns.org>
On Tue, Aug 2, 2011 at 7:51 PM, Junio C Hamano <gitster@pobox.com> wrote:
> Giuseppe Bilotta <giuseppe.bilotta@gmail.com> writes:
>
>> All diffs following a function definition will have that function name
>> as chunck header, but this is the best we can do with the current
>> userdiff capabilities.
>>
>> Signed-off-by: Giuseppe Bilotta <giuseppe.bilotta@gmail.com>
>> ---
>> userdiff.c | 3 +++
>> 1 files changed, 3 insertions(+), 0 deletions(-)
>>
>> diff --git a/userdiff.c b/userdiff.c
>> index 01d3a8b..70120c3 100644
>> --- a/userdiff.c
>> +++ b/userdiff.c
>> @@ -107,6 +107,9 @@
>> "(@|@@|\\$)?[a-zA-Z_][a-zA-Z0-9_]*"
>> "|[-+0-9.e]+|0[xXbB]?[0-9a-fA-F]+|\\?(\\\\C-)?(\\\\M-)?."
>> "|//=?|[-+*/<>%&^|=!]=|<<=?|>>=?|===|\\.{1,3}|::|[!=]~"),
>> +PATTERNS("shell", "^[ \t]*([a-zA-Z_0-9]+)[ \t]*\\(\\).*",
>> + /* -- */
>> + "(--|\\$)?[a-zA-Z_0-9]+|&&|\\|\\|"),
>
> Hmm, what is this "double-dash -- might be present before a name" about?
>
Now that's a good question. I think it was a brainfart while testing
the regexp; came across a case switch where the candidate were
options, and somehow decided that it was better to include the --.
I'll prepare a patch without this stupidity.
--
Giuseppe "Oblomov" Bilotta
^ permalink raw reply
* Re: [RFC] Questions for "Git User's Survey 2011"
From: Jens Lehmann @ 2011-08-02 18:52 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git
In-Reply-To: <201107252233.02088.jnareb@gmail.com>
Am 25.07.2011 22:33, schrieb Jakub Narebski:
> I am planning doing annual Git User's Survey, and I'd like to ask for
> feedback.
I'd appreciate to get some user feedback on submodules. What about this:
=== xx. What do you use submodules for? ===
(multiple choice, with other)
+ I don't use submodules at all
+ to import repositories maintained by others
+ for your own (or your organization's) code shared between different projects
+ to separate large and/or many files for performance reasons
+ to separate data which you don't want (or aren't allowed) to disclose
+ Other, please specify
^ permalink raw reply
* Re: working prototype of orphan parent commits as datastores (was: Storing additional information in commit headers)
From: Jeff King @ 2011-08-02 18:57 UTC (permalink / raw)
To: martin f krafft; +Cc: git discussion list, Petr Baudis, Clemens Buchacher
In-Reply-To: <20110802150321.GA1390@fishbowl.rw.madduck.net>
On Tue, Aug 02, 2011 at 05:03:21PM +0200, martin f krafft wrote:
> tig output now:
> 2011-08-02 16:52 martin f. krafft M─┐ [master] two
> 2011-08-02 16:54 TopGit │ I TopGit data node
> 2011-08-02 16:52 martin f. krafft I one
> 2011-08-02 16:50 martin f. krafft M─┐ [origin/master] import first prototype
> 2011-08-02 16:50 TopGit │ I TopGit data node
> 2011-08-02 16:48 martin f. krafft I Initial (empty) root commit
Look at "git show origin/master" here. It ends up as a combined diff.
Which is kind of ugly.
-Peff
^ permalink raw reply
* Re: Storing additional information in commit headers
From: martin f krafft @ 2011-08-02 19:06 UTC (permalink / raw)
To: Jeff King, git discussion list, Petr Baudis, Clemens Buchacher
In-Reply-To: <20110802185154.GA2499@sigill.intra.peff.net>
[-- Attachment #1: Type: text/plain, Size: 2701 bytes --]
also sprach Jeff King <peff@peff.net> [2011.08.02.2051 +0200]:
> I agree that is an annoyance, but it is one we can deal with. In the
> near term, I wonder if a "tg clone" would be appropriate to add the
> extra fetch refspecs when cloning (or even a "tg init" inside an
> existing git repo -- I don't actually use topgit, so I'm not sure what
> the usual initialization process, if any, is).
Hey Jeff, thanks for your response.
TopGit does come with these commands to do the setup for you, but
that does not ensure that a new contributor without any idea about
TopGit won't forget to run them.
The argument against tg-clone is mainly that I really do not want to
encapsulate/abstract functionality, but rather stay as close as
possible to pure Git, and never to mandate anyone to use anything
else.
> In the longer term, it might be nice if git was better at sharing
> third-party refs. The problem is that we don't know what the refs
> mean, so we don't know which ones are appropriate for sharing.
> Maybe we could do something like "refs/shared/topgit/*", and git
> by default would push and pull items under refs/shared?
This could be an interesting and viable approach.
> > Therefore I thought it would be sensible to store these data in
> > commit. When the data change, there will always be a new commit to
> > store these data, and we do *not* want to update the data in
> > previous commits. Finding the data then becomes backtracking the
> > branch history until a commit is found containing them.
>
> That seems to me like you are sticking information in a commit that is
> not actually about the commit, but about the ref that happens to point
> to the commit. What if I have two refs that point to the same commit,
> but with two different topgit bases?
I don't think this can happen, but the point is valid.
> What about years later, when that information isn't interesting
> anymore? You're still carrying the cruft inside your commit
> objects.
[…]
> I'm still not 100% convinced you want per-commit storage, though,
> and not per-ref storage.
Yes, I do want per-ref storage. Your arguments against my orphan
parent pointer approach (which could later be a x-*-ref approach)
are valid.
It just seems to me that per-ref storage is a lot further away than
per-commit storage, and I'd really like to move forward with TopGit…
Thank you,
--
martin | http://madduck.net/ | http://two.sentenc.es/
"one should never trust a woman who tells her real age.
if she tells that, she will tell anything."
-- oscar wilde
spamtraps: madduck.bogus@madduck.net
[-- Attachment #2: Digital signature (see http://martin-krafft.net/gpg/sig-policy/999bbcc4/current) --]
[-- Type: application/pgp-signature, Size: 1124 bytes --]
^ permalink raw reply
* Re: Branch dependencies
From: martin f krafft @ 2011-08-02 19:08 UTC (permalink / raw)
To: Bert Wesarg, git discussion list, Petr Baudis
In-Reply-To: <CAKPyHN0kAJ-MVsrXam5NjsOYkta4nsSrZUvKoMSi-FeRUSuLEw@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 1554 bytes --]
also sprach Bert Wesarg <bert.wesarg@googlemail.com> [2011.08.02.1506 +0200]:
> while I appreciate, that you dig this topic up. I think you are trying
> to solve the wrong problem first. My main problem with the TopGit
> approach is, that you can't freely change the dependencies of a topic.
> This may be not the most common case in distro development. But in my
> eyes more problematic than maintaining the meta data.
Hello Bert, thank you for taking the time to respond!
Could you please try to illuminate me a bit on a use-case of
changing dependencies? I am aware that TopGit has had a problem with
changing dependencies due to renamed branches, and I think I have
a solution to that (encode the dependent ref, not the branch head),
but I cannot come up with a use case for freely changing
dependencies just like that.
> For my first mentioned problem, I think a new 'system' needs to be
> 'rebase' based, not merge based like TopGit.
The problem with rebasing is that you cannot publish the branches.
However, maybe I am simply not seeing the light here. Do you have
some further ideas about what this would be like? Please keep in
mind that what I seek is not just a way to bring feature branches
up-to-date with upstream, but also to have those branches be shared
among developers.
Thanks,
--
martin | http://madduck.net/ | http://two.sentenc.es/
"gott ist tot! und wir haben ihn getötet."
- friedrich nietzsche
spamtraps: madduck.bogus@madduck.net
[-- Attachment #2: Digital signature (see http://martin-krafft.net/gpg/sig-policy/999bbcc4/current) --]
[-- Type: application/pgp-signature, Size: 1124 bytes --]
^ permalink raw reply
* Re: working prototype of orphan parent commits as datastores (was: Storing additional information in commit headers)
From: martin f krafft @ 2011-08-02 19:09 UTC (permalink / raw)
To: Jeff King, git discussion list, Petr Baudis, Clemens Buchacher
In-Reply-To: <20110802185708.GB2499@sigill.intra.peff.net>
[-- Attachment #1: Type: text/plain, Size: 693 bytes --]
also sprach Jeff King <peff@peff.net> [2011.08.02.2057 +0200]:
> Look at "git show origin/master" here. It ends up as a combined diff.
> Which is kind of ugly.
Yes, absolutely. However, this would no longer be the case if
x-*-ref could be used. Right now, I am just using orphan parent
commits to avoid garbage collection.
--
martin | http://madduck.net/ | http://two.sentenc.es/
"he gave me his card
he said, 'call me if they die'
i shook his hand and said goodbye
ran out to the street
when a bowling ball came down the road
and knocked me off my feet"
-- bob dylan
spamtraps: madduck.bogus@madduck.net
[-- Attachment #2: Digital signature (see http://martin-krafft.net/gpg/sig-policy/999bbcc4/current) --]
[-- Type: application/pgp-signature, Size: 1124 bytes --]
^ permalink raw reply
* [ANNOUNCE/RFC] cj-git-patchtool: a "rebase -i" with more interaction
From: Christian Jaeger @ 2011-08-02 19:22 UTC (permalink / raw)
To: git
Hi
I've always been a frequent user of git rebase -i to clean up private
branches before publication. I like committing without thinking while
coding and then grouping the commits sensibly afterwards. But git
rebase -i didn't scale for me for this purpose, cleaning up several
days (or even weeks) of work would become a pain because frequently
I'd make some error, like when dealing with conflicts, and then
multiple rebase -i runs are needed, requiring to partially redo the
work.
So I've written a set of tools[1] that separates the acts of editing
and applying history changes. It does this by turning the history in
question into a set of git patch files and a file containing the list
of the patches (and optionally new commit messages), and allows to
edit both the list and the patch files themselves incrementally until
they can be applied cleanly again in the new order. In other words, an
(attempted) application (cj-git-patchtool's "app" command) will not
remove these files, and if there's a problem the existing files can be
further refined. There's also a command "wig" that uses "wiggle" (by
Neil Brown) to try to apply a patch automatically when git or patch
wouldn't accept it, and if successful, stores the result back into the
patch file so that it will be reused on subsequent "app" runs. For
convenience, these files, which are put inside a newly created
directory, are automatically checked into their own git repository,
too, so when doing something really complicated, the state of work can
be committed and reverted easily when reaching a dead end.
For more information see the README on Github.[1]
This works well for me, I'm now always using it whenever I need to do
more than a couple trivial changes to a Git history.
I don't know whether there are other tools offering the same now.
Also, I have written this "just for myself", and for this reason made
use of a set of never-before released Perl libraries of mine. If
there's general interest in this tool, I'll be glad to help get rid of
the dependency on these libraries (or clean them up and publish them
properly, too).
I welcome your comments.
Christian.
[1] https://github.com/pflanze/cj-git-patchtool
^ permalink raw reply
* Re: working prototype of orphan parent commits as datastores (was: Storing additional information in commit headers)
From: martin f krafft @ 2011-08-02 19:26 UTC (permalink / raw)
To: Jeff King, git discussion list, Petr Baudis, Clemens Buchacher
In-Reply-To: <20110802190923.GB16674@fishbowl.rw.madduck.net>
[-- Attachment #1: Type: text/plain, Size: 793 bytes --]
also sprach martin f krafft <madduck@madduck.net> [2011.08.02.2109 +0200]:
> Yes, absolutely. However, this would no longer be the case if
> x-*-ref could be used. Right now, I am just using orphan parent
> commits to avoid garbage collection.
refs/heads/master is a file, containing its payload in the first
line by format definition, right?
I mean: the storage is right there, isn't it?
Of course this opens a whole new can of worms: merging per-ref data.
--
martin | http://madduck.net/ | http://two.sentenc.es/
"'oh, that was easy,' says Man, and for an encore goes on to prove
that black is white and gets himself killed on the next zebra
crossing."
-- douglas adams, "the hitchhiker's guide to the galaxy"
spamtraps: madduck.bogus@madduck.net
[-- Attachment #2: Digital signature (see http://martin-krafft.net/gpg/sig-policy/999bbcc4/current) --]
[-- Type: application/pgp-signature, Size: 1124 bytes --]
^ permalink raw reply
* per-ref data storage (was: Storing additional information in commit headers)
From: martin f krafft @ 2011-08-02 19:27 UTC (permalink / raw)
To: Jeff King, git discussion list, Petr Baudis, Clemens Buchacher
In-Reply-To: <20110802190645.GB17322@fishbowl.rw.madduck.net>
[-- Attachment #1: Type: text/plain, Size: 775 bytes --]
[sorry, my previous message was a total reply FAIL]
also sprach martin f krafft <madduck@madduck.net> [2011.08.02.2106 +0200]:
> It just seems to me that per-ref storage is a lot further away than
> per-commit storage, and I'd really like to move forward with TopGit…
refs/heads/master is a file, containing its payload in the first
line by format definition, right?
I mean: the storage is right there, isn't it?
Of course this opens a whole new can of worms: merging per-ref data.
--
martin | http://madduck.net/ | http://two.sentenc.es/
"nothing can cure the soul but the senses,
just as nothing can cure the senses but the soul."
-- oscar wilde
spamtraps: madduck.bogus@madduck.net
[-- Attachment #2: Digital signature (see http://martin-krafft.net/gpg/sig-policy/999bbcc4/current) --]
[-- Type: application/pgp-signature, Size: 1124 bytes --]
^ permalink raw reply
* Re: [PATCH 5/5] fsck: improve committer/author check
From: Dmitry Ivankov @ 2011-08-02 19:50 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, SASAKI Suguru
In-Reply-To: <7vfwljg33p.fsf@alter.siamese.dyndns.org>
On Tue, Aug 2, 2011 at 11:00 PM, Junio C Hamano <gitster@pobox.com> wrote:
> Dmitry Ivankov <divanorama@gmail.com> writes:
>
>> Neither name nor email should contain < or >, so split the string with
>> these and check they come in that order and < is preceeded with a space.
>>
>> If < is missing don't say a confusing "missing space", say "bad name" if
>>> isn't missing and "missing email" if both < and > are missing.
>>
>> Signed-off-by: Dmitry Ivankov <divanorama@gmail.com>
>> ---
>
> Same comment as 3/5; before starting to talk about how you implemented
> your validation, please state what rules you are enforcing.
Thanks, will apply and reroll.
But before this, is it ok to reject "Name> <email>" idents in fsck and
fast-import?
fsck already denies '<' and '>' inside email, and '<' in name. But
accepts '>' in name.
It just hit me that Documentation/fast-import.c doesn't deny '>' in
name and it is
consistent with fsck, so there may be a reason behind it.
>
> Thanks.
>
^ permalink raw reply
* Re: [RFC/ PATCH] revert: Allow arbitrary sequencer instructions
From: Jonathan Nieder @ 2011-08-02 20:53 UTC (permalink / raw)
To: Ramkumar Ramachandra
Cc: Git List, Junio C Hamano, Christian Couder, Daniel Barkalow,
Jeff King
In-Reply-To: <1312260884-5087-2-git-send-email-artagnon@gmail.com>
Ramkumar Ramachandra wrote:
> Allow arbitrary sequencer instructions in the instruction sheet.
"So now I can ..." wait, what does this allow me to do? Your audience
hasn't read the patch yet.
> --- a/sequencer.h
> +++ b/sequencer.h
> @@ -32,6 +32,16 @@ struct replay_opts {
> size_t xopts_nr, xopts_alloc;
> };
>
> +struct replay_insn {
> + struct commit *commit;
> + enum replay_action action;
> +};
> +
> +struct replay_insn_list {
> + struct replay_insn *item;
> + struct replay_insn_list *next;
> +};
Ah, so this allows sequences like
revert A
pick B
pick C
revert D
Nit: why isn't the list-item struct something like
struct replay_insn item;
struct replay_insn_list *next;
which would save a little memory management and memory access
overhead (or even
enum replay_action action;
struct commit *operand;
struct replay_insn_list *next;
since every "struct replay_insn" exists in the context of an
insn list afaict)?
Anyway, the general idea seems good.
^ permalink raw reply
* Re: per-ref data storage
From: martin f krafft @ 2011-08-02 21:12 UTC (permalink / raw)
To: Jeff King, git discussion list, Petr Baudis, Clemens Buchacher
In-Reply-To: <20110802192727.GB20239@fishbowl.rw.madduck.net>
[-- Attachment #1: Type: text/plain, Size: 1020 bytes --]
also sprach martin f krafft <madduck@madduck.net> [2011.08.02.2127 +0200]:
> refs/heads/master is a file, containing its payload in the first
> line by format definition, right?
>
> I mean: the storage is right there, isn't it?
>
> Of course this opens a whole new can of worms: merging per-ref data.
origin/master can contain a different set of per-ref data than
master, and the consolidation would need to happen during the normal
merge.
But unless there's always a new commit associated with a change of
those data, git-push will happily overwrite those data on the
remote.
… unless the remote refuses to accept a ref update if the data have
changed. Conceivably that's could lead into a control path similar
to what happens on a non-fast-forward push — unless
receive.nonFastForwards is on.
What then?
--
martin | http://madduck.net/ | http://two.sentenc.es/
seminars, n.:
from "semi" and "arse", hence, any half-assed discussion.
spamtraps: madduck.bogus@madduck.net
[-- Attachment #2: Digital signature (see http://martin-krafft.net/gpg/sig-policy/999bbcc4/current) --]
[-- Type: application/pgp-signature, Size: 1124 bytes --]
^ 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