* Re: [PATCH 2/2] ls-tree: migrate to parse-options
From: Thiago Farina @ 2009-11-18 23:10 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Stephen Boyd, git
In-Reply-To: <7veinvcw7w.fsf@alter.siamese.dyndns.org>
On Wed, Nov 18, 2009 at 8:19 PM, Junio C Hamano <gitster@pobox.com> wrote:
> Stephen Boyd <bebarino@gmail.com> writes:
>
>> Junio C Hamano wrote:
>>>
>>> @@ -24,7 +24,7 @@ static int chomp_prefix;
>>> static const char *ls_tree_prefix;
>>> static const char * const ls_tree_usage[] = {
>>> - "git ls-tree [-d] [-r] [-t] [-l | --long] [-z] [--name-only] [--name-status] [--full-name] [--full-tree] [--abbrev[=<n>]] <tree-ish> [path...]",
>>> + "git ls-tree <options> <tree-ish> [path...]",
>>> NULL
>>> };
>>>
>>
>> Is it [<options>] or [<options>...] or <options> or even
>> <options>... though?
>
> Output from "git grep -e '<option' -- '*.c'" indicates that it
> should be "[<options>]"; thanks for spotting.
$ git grep -e '<option' -- '*.c' | wc -l
4
$ git grep -e '\[options' -- '*.c' | wc -l
42
$ git grep -e '\[<options' -- '*.c' | wc -l
2
Shouldn't be just "[options]"?
^ permalink raw reply
* Re: [PATCH] git am/mailinfo: Don't look at in-body headers when rebasing
From: Philip Hofstetter @ 2009-11-18 23:47 UTC (permalink / raw)
To: Lukas Sandström; +Cc: Jeff King, git
In-Reply-To: <4B0478ED.30306@gmail.com>
Hi,
On Wed, Nov 18, 2009 at 11:45 PM, Lukas Sandström <luksan@gmail.com> wrote:
> The actual change is that mailinfo doesn't look for in-body headers
> at all if --no-inbody-headers is passed. git-am now passes this option
> to mailinfo when rebasing.
after all the earlier discussion and a lot of thinking, I have to say,
that IMHO, this is the best option as it doesn't rely on heuristics
and now that you chose a descriptive command line switch, even the
small problem of "why exactly is this switch here?" seems to go away.
As I have no experience in git's codebase at all, I'll leave the
commenting on the patch itself to the people with clue, but
conceptionally, this feels much better than the method 1
> This won't handle the case when a "bad" patch is passed to git-am from
> somewhere else than git rebase.
of course, that leaves the question what "somewhere else" can contain.
If it's just manual calls to git-am, this is a non-issue as it's
easily fixed by the caller. If it's being called from other
higher-level operations though, you might run into the same issue
again.
Here too, I can't really provide any meaningful input though as I just
don't know well enough what really makes git tick.
Just my two cents :-)
Philip
^ permalink raw reply
* RE: Hey - A Conceptual Simplication....
From: George Dennie @ 2009-11-19 2:03 UTC (permalink / raw)
To: 'Jason Sewall', 'Jakub Narebski'
Cc: 'Jan Krüger', git
In-Reply-To: <31e9dd080911181152h665d5d9dr5c0736c0ca3234c1@mail.gmail.com>
Thanks Linus, Jason, and Jakub...
Linus Torvalds wrote....
>On Wed, 18 Nov 2009, George Dennie wrote:
>>
>> The Git model does not seem to go far enough conceptually, for some
>> unexplainable reason...
>
> Others already mentioned this, but the concept you missed is the git 'index', which is actually very
> central (it is actually the first part of git written, before even the object database) but is something
> that most people who get started with git can (and do) ignore.
Uhmmm, subtle. I hear you. Thanks for the heads up. But before that, I just put these two cents down...
One of the persistent problems with software documentation is that it often fails to define the "functional or usage" model, apart from a dry list of commands. I am sure there are many good reasons for this. For one thing, explaining stuff is hard. Now, I have not had occasions to do merges, as such. So I am finding the justification for the index vague. I am wondering whether this might be a great space to describe the functional model of git in a way that more clearly justifies the index...
Specifically, can there be a succinct description of the usage or functional model of Git that necessarily incorporates the index.
For example, the functional notion of the repository seems well defined: a growing web of immutable commits each created as either an isolated commit or more typically an update and/or merger of one or more pre-existing commits.
With such a description the rest of the structure becomes almost implicit: Commits may be annotated such as with release number labels. Commits that have not been linked to such as by an update or merger remain dangling like loose threads in the web and are called branches. Branches may be given special labels that the repository will then automatically update so as to refer to the latest commit to that branch.
I don't yet have such a clear model for the index. Yes it is a staging platform, but so is the IDE....I'll do more reading.
Jason Sewell wrote....
> I find this leads to big, shapeless commits and, as I mentioned before, it seriously limits the utility
> of 'git bisect'. I also fail to see how 'selectively saving parts of the document' is versioning and
> publishing - what is the publishing part? The act of committing is one thing (and 'saving...
The notion of a shapeless commit is curious. Intuitively, I consider a commit as capturing the state of my work at a transactional boundary (i.e. a successful unit test...or even lunch break). However, your characterization of "shape" suggest that you are constructing something other than the immediate functionality of the software. Consequently, your software document is not really the solution files alone but also this commit history that you meticulously craft.
Further, the participating of the IDE is not to compose within itself the committable document but rather to contribute to such a document in pieces. In fact, the closest metaphor to this process/workflow seems to be submitting articles to a magazine; except you are both the writer and editor/graphic artist; and each edition of the magazine becoming the committable version.
With this metaphor the index does play a clear role as a layout board of sorts for the complete magazine. And also clearly, the IDE does not "functionally" edit the entire committable document but rather parts of it. Even though it may effectively have the entirety of the index in its working tree; Git requires that it be submitted to the index which is the true committable document.
It begs the question, why is the working tree (the IDE document) so closely tied to the repository since it really amounts to a scratch pad. In fact, while the index may be attach to the working tree, the repository can be anywhere and have more than one index attached...yeah, I know, having a personal dedicated repository is cheap. (A great example of how expediency, the proximity of the repository, might obscure the functional model by making what is arbitrary and due to convention appear a functional necessity...; if, in fact, my above conclusion is correct of course :)
> What if you are hacking away and make changes to several parts of the code at once? Making the commits
> as fine-grained as possible makes it easier to cherry-pick, bisect, and understand the history.
You know Jason, it is often hard to isolate my changes to specific files. I have come to appreciate unit tests as a means of delineating changes. However, clearly the historically record of your solution tree is of substantially value to you. It is something I will have to pay closer attention in my case.
> Perhaps I don't understand your scheme, but it sounds like you're advocating 2 .gitignores:
>
> * .gitignore_track; with everything you don't automatically staged but which can be trashed by your cleaning checkout
> * .gitignore_keep; with things you don't want staged but which shouldn't be deleted by git during cleaning
Yep, that may be one implementation...but essentially the current .gitignores list exclusionary filters for the "git add ." command. The suggestion was to augment it to also include exclusionary filters for the proposed "git checkout -clean" command. By perhaps prefixing "+" and "-" symbols to the listed elements you can designate each filter's participation in the "do not add" and "do not delete" activities, respectively. However, this suggest was with the presumption that the work tree was the committable document, but clearly it is not.
> Who is pruning after a commit? Once nice thing about checkout is that it will refuse to move to a
> different commit if there are files that will get trashed. Then you can say 'oops, I should
> stash/commit/nuke that stuff before I change HEAD.
Not trashing files is a nice thing by checkout. However, are you referring to changes added to the index or changes made in the working tree but not yet added to the index. Base on my current understanding of the functional model, you would be referring to the index since the working tree is little more than a scratch pad. The pruning comment was in recognition that the working tree was not expected to be committable in its entirety.
George.
Thanks again for your input and if you have the time I welcome your response.
^ permalink raw reply
* [PATCH v4] git remote: Separate usage strings for subcommands
From: Tim Henigan @ 2009-11-19 2:59 UTC (permalink / raw)
To: Junio C Hamano, jrnieder; +Cc: git
When the usage string for a subcommand must be printed,
only print the information relevant to that command.
This commit also removes the options from the first line
of the usage string (replacing them with '<options>'
and lets them be documented in the paragraph below.
Signed-off-by: Tim Henigan <tim.henigan@gmail.com>
---
This patch is based on:
http://article.gmane.org/gmane.comp.version-control.git/132953
All usage strings are still only located at the top of file. However,
separate usage string arrays have been created for each subcommand.
v2 fixed line wrap issues present in v1.
v3 changes include:
- Changed usage strings to use '<options>...' rather than document
the options both in the actual string and in the OPT_x array
(as recommended by Junio).
- Removed the change made to the usage string array constructed
in 'cmd_remote'. v2 was broken because that change had made
the command stop recognizing the '-v' option. Added an extra
note here which explains that '-v' is only valid when placed
after 'git remote' and before any 'subcommand'.
- Updated the man page.
v4 changes include:
- Changed usage strings to use '<options>' rather than
'<options>...' based on feedback from Jonathan Nieder.
See [1] for details.
- Corrected "git remote set-head" usage string to show the
required [-a | -d | <branch>] portion of the command.
- Corrected "git remote update" usage string to show the
optional, but not otherwise documented [<group> | <remote>]
portion of the command.
- Removed 2 more instances of "<subcommand> specific options".
[1] http://thread.gmane.org/gmane.comp.version-control.git/133151/focus=133160
Documentation/git-remote.txt | 13 +++++----
builtin-remote.c | 60 +++++++++++++++++++++++++----------------
2 files changed, 43 insertions(+), 30 deletions(-)
diff --git a/Documentation/git-remote.txt b/Documentation/git-remote.txt
index 82a3d29..ee3dc80 100644
--- a/Documentation/git-remote.txt
+++ b/Documentation/git-remote.txt
@@ -9,14 +9,14 @@ git-remote - manage set of tracked repositories
SYNOPSIS
--------
[verse]
-'git remote' [-v | --verbose]
-'git remote add' [-t <branch>] [-m <master>] [-f] [--mirror] <name> <url>
+'git remote' [<options>]
+'git remote add' [<options>] <name> <url>
'git remote rename' <old> <new>
'git remote rm' <name>
-'git remote set-head' <name> [-a | -d | <branch>]
-'git remote show' [-n] <name>
-'git remote prune' [-n | --dry-run] <name>
-'git remote update' [-p | --prune] [group | remote]...
+'git remote set-head' <name> [<options>] [-a | -d | <branch>]
+'git remote show' [<options>] <name>
+'git remote prune' [<options>] <name>
+'git remote update' [<options>] [<group> | <remote>]...
DESCRIPTION
-----------
@@ -30,6 +30,7 @@ OPTIONS
-v::
--verbose::
Be a little more verbose and show remote url after name.
+ NOTE: This must be placed between `remote` and `subcommand`.
COMMANDS
diff --git a/builtin-remote.c b/builtin-remote.c
index 0777dd7..24a3ec0 100644
--- a/builtin-remote.c
+++ b/builtin-remote.c
@@ -7,18 +7,35 @@
#include "run-command.h"
#include "refs.h"
+#define REMOTE_BARE_USAGE "git remote [<options>]"
+#define REMOTE_ADD_USAGE "git remote add [<options>] <name> <url>"
+#define REMOTE_RENAME_USAGE "git remote rename <old> <new>"
+#define REMOTE_RM_USAGE "git remote rm <name>"
+#define REMOTE_SETHEAD_USAGE "git remote set-head <name> [-a | -d | <branch>]"
+#define REMOTE_SHOW_USAGE "git remote show [<options>] <name>"
+#define REMOTE_PRUNE_USAGE "git remote prune [<options>] <name>"
+#define REMOTE_UPDATE_USAGE "git remote update [<options>] [<group> | <remote>]..."
+
static const char * const builtin_remote_usage[] = {
- "git remote [-v | --verbose]",
- "git remote add [-t <branch>] [-m <master>] [-f] [--mirror] <name> <url>",
- "git remote rename <old> <new>",
- "git remote rm <name>",
- "git remote set-head <name> [-a | -d | <branch>]",
- "git remote show [-n] <name>",
- "git remote prune [-n | --dry-run] <name>",
- "git remote [-v | --verbose] update [-p | --prune] [group]",
+ REMOTE_BARE_USAGE,
+ REMOTE_ADD_USAGE,
+ REMOTE_RENAME_USAGE,
+ REMOTE_RM_USAGE,
+ REMOTE_SETHEAD_USAGE,
+ REMOTE_SHOW_USAGE,
+ REMOTE_PRUNE_USAGE,
+ REMOTE_UPDATE_USAGE,
NULL
};
+static const char * const builtin_remote_add_usage[] = { REMOTE_ADD_USAGE, NULL };
+static const char * const builtin_remote_rename_usage[] = { REMOTE_RENAME_USAGE, NULL };
+static const char * const builtin_remote_rm_usage[] = { REMOTE_RM_USAGE, NULL };
+static const char * const builtin_remote_sethead_usage[] = { REMOTE_SETHEAD_USAGE, NULL };
+static const char * const builtin_remote_show_usage[] = { REMOTE_SHOW_USAGE, NULL };
+static const char * const builtin_remote_prune_usage[] = { REMOTE_PRUNE_USAGE, NULL };
+static const char * const builtin_remote_update_usage[] = { REMOTE_UPDATE_USAGE, NULL };
+
#define GET_REF_STATES (1<<0)
#define GET_HEAD_NAMES (1<<1)
#define GET_PUSH_REF_STATES (1<<2)
@@ -70,7 +87,6 @@ static int add(int argc, const char **argv)
int i;
struct option options[] = {
- OPT_GROUP("add specific options"),
OPT_BOOLEAN('f', "fetch", &fetch, "fetch the remote branches"),
OPT_CALLBACK('t', "track", &track, "branch",
"branch(es) to track", opt_parse_track),
@@ -79,11 +95,11 @@ static int add(int argc, const char **argv)
OPT_END()
};
- argc = parse_options(argc, argv, NULL, options, builtin_remote_usage,
+ argc = parse_options(argc, argv, NULL, options, builtin_remote_add_usage,
0);
if (argc < 2)
- usage_with_options(builtin_remote_usage, options);
+ usage_with_options(builtin_remote_add_usage, options);
name = argv[0];
url = argv[1];
@@ -540,7 +556,7 @@ static int mv(int argc, const char **argv)
int i;
if (argc != 3)
- usage_with_options(builtin_remote_usage, options);
+ usage_with_options(builtin_remote_rename_usage, options);
rename.old = argv[1];
rename.new = argv[2];
@@ -681,7 +697,7 @@ static int rm(int argc, const char **argv)
int i, result;
if (argc != 2)
- usage_with_options(builtin_remote_usage, options);
+ usage_with_options(builtin_remote_rm_usage, options);
remote = remote_get(argv[1]);
if (!remote)
@@ -976,7 +992,6 @@ static int show(int argc, const char **argv)
{
int no_query = 0, result = 0, query_flag = 0;
struct option options[] = {
- OPT_GROUP("show specific options"),
OPT_BOOLEAN('n', NULL, &no_query, "do not query remotes"),
OPT_END()
};
@@ -984,7 +999,7 @@ static int show(int argc, const char **argv)
struct string_list info_list = { NULL, 0, 0, 0 };
struct show_info info;
- argc = parse_options(argc, argv, NULL, options, builtin_remote_usage,
+ argc = parse_options(argc, argv, NULL, options, builtin_remote_show_usage,
0);
if (argc < 1)
@@ -1081,14 +1096,13 @@ static int set_head(int argc, const char **argv)
char *head_name = NULL;
struct option options[] = {
- OPT_GROUP("set-head specific options"),
OPT_BOOLEAN('a', "auto", &opt_a,
"set refs/remotes/<name>/HEAD according to remote"),
OPT_BOOLEAN('d', "delete", &opt_d,
"delete refs/remotes/<name>/HEAD"),
OPT_END()
};
- argc = parse_options(argc, argv, NULL, options, builtin_remote_usage,
+ argc = parse_options(argc, argv, NULL, options, builtin_remote_sethead_usage,
0);
if (argc)
strbuf_addf(&buf, "refs/remotes/%s/HEAD", argv[0]);
@@ -1114,7 +1128,7 @@ static int set_head(int argc, const char **argv)
if (delete_ref(buf.buf, NULL, REF_NODEREF))
result |= error("Could not delete %s", buf.buf);
} else
- usage_with_options(builtin_remote_usage, options);
+ usage_with_options(builtin_remote_sethead_usage, options);
if (head_name) {
unsigned char sha1[20];
@@ -1138,16 +1152,15 @@ static int prune(int argc, const char **argv)
{
int dry_run = 0, result = 0;
struct option options[] = {
- OPT_GROUP("prune specific options"),
OPT__DRY_RUN(&dry_run),
OPT_END()
};
- argc = parse_options(argc, argv, NULL, options, builtin_remote_usage,
+ argc = parse_options(argc, argv, NULL, options, builtin_remote_prune_usage,
0);
if (argc < 1)
- usage_with_options(builtin_remote_usage, options);
+ usage_with_options(builtin_remote_prune_usage, options);
for (; argc; argc--, argv++)
result |= prune_remote(*argv, dry_run);
@@ -1228,13 +1241,12 @@ static int update(int argc, const char **argv)
struct string_list list = { NULL, 0, 0, 0 };
static const char *default_argv[] = { NULL, "default", NULL };
struct option options[] = {
- OPT_GROUP("update specific options"),
OPT_BOOLEAN('p', "prune", &prune,
"prune remotes after fetching"),
OPT_END()
};
- argc = parse_options(argc, argv, NULL, options, builtin_remote_usage,
+ argc = parse_options(argc, argv, NULL, options, builtin_remote_update_usage,
PARSE_OPT_KEEP_ARGV0);
if (argc < 2) {
argc = 2;
@@ -1334,7 +1346,7 @@ static int show_all(void)
int cmd_remote(int argc, const char **argv, const char *prefix)
{
struct option options[] = {
- OPT__VERBOSE(&verbose),
+ OPT_BOOLEAN('v', "verbose", &verbose, "be verbose; must be placed before a subcommand"),
OPT_END()
};
int result;
--
1.6.5.2.186.ga4d60
^ permalink raw reply related
* Re: [PATCH v4] git remote: Separate usage strings for subcommands
From: Nanako Shiraishi @ 2009-11-19 3:40 UTC (permalink / raw)
To: Tim Henigan; +Cc: Junio C Hamano, jrnieder, git
In-Reply-To: <4B04B4A2.8090001@gmail.com>
Quoting Tim Henigan <tim.henigan@gmail.com>
> When the usage string for a subcommand must be printed,
> only print the information relevant to that command.
I think this is a huge improvement.
> diff --git a/Documentation/git-remote.txt b/Documentation/git-remote.txt
> index 82a3d29..ee3dc80 100644
> --- a/Documentation/git-remote.txt
> +++ b/Documentation/git-remote.txt
> @@ -9,14 +9,14 @@ git-remote - manage set of tracked repositories
> SYNOPSIS
> --------
> [verse]
> -'git remote' [-v | --verbose]
> -'git remote add' [-t <branch>] [-m <master>] [-f] [--mirror] <name> <url>
> +'git remote' [<options>]
> +'git remote add' [<options>] <name> <url>
> 'git remote rename' <old> <new>
> 'git remote rm' <name>
> -'git remote set-head' <name> [-a | -d | <branch>]
> -'git remote show' [-n] <name>
> -'git remote prune' [-n | --dry-run] <name>
> -'git remote update' [-p | --prune] [group | remote]...
> +'git remote set-head' <name> [<options>] [-a | -d | <branch>]
> +'git remote show' [<options>] <name>
> +'git remote prune' [<options>] <name>
> +'git remote update' [<options>] [<group> | <remote>]...
Often people look at this part of the manual page to quickly remind
themselves what options are available, and it is better to keep the
current text. Some manual pages have to use [options...] when there
are too many to list, but each subcommand of git-remote doesn't have
that many options.
> diff --git a/builtin-remote.c b/builtin-remote.c
> index 0777dd7..24a3ec0 100644
> --- a/builtin-remote.c
> +++ b/builtin-remote.c
> @@ -7,18 +7,35 @@
> #include "run-command.h"
> #include "refs.h"
>
> +#define REMOTE_BARE_USAGE "git remote [<options>]"
> +#define REMOTE_ADD_USAGE "git remote add [<options>] <name> <url>"
> +#define REMOTE_RENAME_USAGE "git remote rename <old> <new>"
> +#define REMOTE_RM_USAGE "git remote rm <name>"
> +#define REMOTE_SETHEAD_USAGE "git remote set-head <name> [-a | -d | <branch>]"
> +#define REMOTE_SHOW_USAGE "git remote show [<options>] <name>"
> +#define REMOTE_PRUNE_USAGE "git remote prune [<options>] <name>"
> +#define REMOTE_UPDATE_USAGE "git remote update [<options>] [<group> | <remote>]..."
> +
> static const char * const builtin_remote_usage[] = {
> - "git remote [-v | --verbose]",
> - "git remote add [-t <branch>] [-m <master>] [-f] [--mirror] <name> <url>",
> - "git remote rename <old> <new>",
> - "git remote rm <name>",
> - "git remote set-head <name> [-a | -d | <branch>]",
> - "git remote show [-n] <name>",
> - "git remote prune [-n | --dry-run] <name>",
> - "git remote [-v | --verbose] update [-p | --prune] [group]",
> + REMOTE_BARE_USAGE,
> + REMOTE_ADD_USAGE,
> + REMOTE_RENAME_USAGE,
> + REMOTE_RM_USAGE,
> + REMOTE_SETHEAD_USAGE,
> + REMOTE_SHOW_USAGE,
> + REMOTE_PRUNE_USAGE,
> + REMOTE_UPDATE_USAGE,
> NULL
> };
For the same reason, I don't think this is a good change, if these
lines are used to show the first lines of 'git-remote -h' output.
^ permalink raw reply
* Re: [PATCHv3] Add branch management for releases to gitworkflows
From: Nanako Shiraishi @ 2009-11-19 4:11 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Thomas Rast, Raman Gupta, git, skillzero
In-Reply-To: <200911181559.02873.trast@student.ethz.ch>
Quoting Thomas Rast <trast@student.ethz.ch> writes:
> FWIW, you can add my
>
> Acked-by: Thomas Rast <trast@student.ethz.ch>
>
> to the final (squashed) patch.
Junio, please also add my
Acked-by: Nanako Shiraishi <nanako3@lavabit.com>
My changes were intended to be squashed into the final single patch, too.
--
Nanako Shiraishi
http://ivory.ap.teacup.com/nanako3/
^ permalink raw reply
* Re: [ANNOUNCE] codeBeamer MR - Easy ACL for Git
From: david @ 2009-11-19 6:06 UTC (permalink / raw)
To: Intland Software; +Cc: Petr Baudis, git
In-Reply-To: <4B03F451.4050709@intland.com>
On Wed, 18 Nov 2009, Intland Software wrote:
> More precisely: parts of the source code are actually open, including
> the wiki plugins and the remote clients, for instance. The core source
> is closed, because the same core is also used in our commercial offerings,
> and
> our commercial license doesn't (currently) allow publishing the
> complete code. We have quite some large customers from the defense space
> that would not be happy if we opened everything ;)
are you sure? did you see the recent memo about OpenSource by the DOD?
David Lang
> We are currently in the midst of rethinking our licensing scheme
> in general, to make things more liberal or to set up some kind of a
> dual license.
>
>> I think a lot of people wonder now, how does this compare to existing
>> solutions; from your announcement I thought it's something like
>> Gitosis/Gitolite, but in fact it seems more similar to Gitorious or
>> GitHub (if it was publicly available, of course); perhaps it would be
>> good idea to present comparison to these on the project homepage.
> Good point. More on this later.
> ---
> Intland
> --
> To unsubscribe from this list: send the line "unsubscribe git" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
^ permalink raw reply
* [PATCH 1/2] Documentation: fix typos and spelling in replace documentation
From: Christian Couder @ 2009-11-19 6:13 UTC (permalink / raw)
To: Junio C Hamano
Cc: git, Michael J Gruber, Jakub Narebski, Johannes Sixt, bill lam,
Andreas Schwab, Paul Mackerras
This patch fix a missing "s" at the end of an occurence of
"--no-replace-objects" and, while at it, it also improves spelling
and rendering.
Signed-off-by: Christian Couder <chriscool@tuxfamily.org>
---
Documentation/git-replace.txt | 21 +++++++++++----------
1 files changed, 11 insertions(+), 10 deletions(-)
This is a fix that could go into 'maint'.
diff --git a/Documentation/git-replace.txt b/Documentation/git-replace.txt
index 8adc1ef..69f704f 100644
--- a/Documentation/git-replace.txt
+++ b/Documentation/git-replace.txt
@@ -17,31 +17,32 @@ DESCRIPTION
Adds a 'replace' reference in `.git/refs/replace/`
The name of the 'replace' reference is the SHA1 of the object that is
-replaced. The content of the replace reference is the SHA1 of the
+replaced. The content of the 'replace' reference is the SHA1 of the
replacement object.
-Unless `-f` is given, the replace reference must not yet exist in
+Unless `-f` is given, the 'replace' reference must not yet exist in
`.git/refs/replace/` directory.
-Replace references will be used by default by all git commands except
-those doing reachability traversal (prune, pack transfer and fsck).
+Replacement references will be used by default by all git commands
+except those doing reachability traversal (prune, pack transfer and
+fsck).
-It is possible to disable use of replacement refs for any command
-using the --no-replace-objects option just after "git".
+It is possible to disable use of replacement references for any
+command using the `--no-replace-objects` option just after 'git'.
-For example if commit "foo" has been replaced by commit "bar":
+For example if commit 'foo' has been replaced by commit 'bar':
------------------------------------------------
-$ git --no-replace-object cat-file commit foo
+$ git --no-replace-objects cat-file commit foo
------------------------------------------------
-show information about commit "foo", while:
+shows information about commit 'foo', while:
------------------------------------------------
$ git cat-file commit foo
------------------------------------------------
-show information about commit "bar".
+shows information about commit 'bar'.
OPTIONS
-------
--
1.6.5.1.gaf97d
^ permalink raw reply related
* [PATCH 2/2] Documentation: talk a little bit about GIT_NO_REPLACE_OBJECTS
From: Christian Couder @ 2009-11-19 6:13 UTC (permalink / raw)
To: Junio C Hamano
Cc: git, Michael J Gruber, Jakub Narebski, Johannes Sixt, bill lam,
Andreas Schwab, Paul Mackerras
Signed-off-by: Christian Couder <chriscool@tuxfamily.org>
---
Documentation/git-replace.txt | 3 +++
1 files changed, 3 insertions(+), 0 deletions(-)
This patch should go in my series that introduced the
GIT_NO_REPLACE_OBJECTS env variable.
diff --git a/Documentation/git-replace.txt b/Documentation/git-replace.txt
index 69f704f..65a0da5 100644
--- a/Documentation/git-replace.txt
+++ b/Documentation/git-replace.txt
@@ -44,6 +44,9 @@ $ git cat-file commit foo
shows information about commit 'bar'.
+The 'GIT_NO_REPLACE_OBJECTS' environment variable can be set to
+achieve the same effect as the `--no-replace-objects` option.
+
OPTIONS
-------
-f::
--
1.6.5.1.gaf97d
^ permalink raw reply related
* Re: Hey - A Conceptual Simplication....
From: Björn Steinbrink @ 2009-11-19 7:42 UTC (permalink / raw)
To: George Dennie
Cc: 'Jason Sewall', 'Jakub Narebski',
'Jan Krüger', git
In-Reply-To: <009401ca68bc$7e4b12b0$7ae13810$@com>
On 2009.11.18 21:03:31 -0500, George Dennie wrote:
> Jason Sewell wrote....
> > I find this leads to big, shapeless commits and, as I mentioned
> > before, it seriously limits the utility of 'git bisect'. I also
> > fail to see how 'selectively saving parts of the document' is
> > versioning and publishing - what is the publishing part? The act of
> > committing is one thing (and 'saving...
>
> The notion of a shapeless commit is curious. Intuitively, I consider a
> commit as capturing the state of my work at a transactional boundary
> (i.e. a successful unit test...or even lunch break). However, your
> characterization of "shape" suggest that you are constructing
> something other than the immediate functionality of the software.
> Consequently, your software document is not really the solution files
> alone but also this commit history that you meticulously craft.
Your "lunch break" as a transaction boundary is a great example of
something that probably most people on this list would consider to
create commits that need rewriting before publishing them. Let's take an
extreme example:
You work on adding a feature to some webmail site that adds colors to
the mail being displayed, using different colors for the headers, quoted
sections and the text from the sender. The colors should be configurable
by the user.
*work*
git commit -m "Go for a coffee"
*work*
git commit -m "Lunch break"
*work*
git commit -m "Meeting"
*work*
git commit -m "Time to go home"
*come back to work*
*work*
git commit -m "Finished the mail coloring support"
This gives you:
* Finished the mail coloring support
|
* Time to go home
|
* Meeting
|
* Lunch break
|
* Go for a coffee
Such a history is basically completely useless. It's (ab)using the VCS
as a plain code dump. In a week, you'll be able to see that you had a
meeting that day, but it doesn't tell you anything about what you did to
the project. And even with less "insane" commit messages, the
"transactional boundaries" are totally arbitrary. They're aligned to
things you did that have absolutely nothing to do with the stuff you're
tracking in your VCS.
A far more useful history might look like this:
* Colorize quoted text in a mail, depending on its quoting depth
|
* Parse mails into a tree structure to represent sections of quoted text
|
* Colorize mail headers
|
* Add support for the user to change the colors used for mails
|
* Add configuration variable for the colors used for mails
At each step, something functionally changed about the software. The
commit messages tell you something about how the software evolved. And
if you get bogus values for the colors in the configuration, you can be
90% sure, by only looking at the commit messages, that you have a bug in
the "Add support for the user to change the colors ..." commit, and not
in one of the others. So you can run "git show $that_commit" to see the
diff of the changes you made in that commit and quickly check them for
your bug.
And while that's not sooo useful for commits that added new
functionality, it's extremely useful for commits that just made small
changes to existing functionality. Finding a bug in a large piece of
code (say 2000 lines) isn't trivial. But if you know that a commit that
changed 5 lines in that code is responsible for the breakage, all you
have to do is to identify the faulty change, which is a lot easier.
And with a large history, where it's not obvious in which commit
something got broken, "git bisect" can help to quickly find the bad
commit. Now consider "git bisect" finding your "Lunch break" commit.
Looking at the commit message tells nothing. The diff is pretty much
arbitrary, might be huge. Not much help. Finding the "Add support for
the user to change the colors ..." commit already tells you something
just because of the commit message. And the diff is about just one
specific change. It's all nicely separated, and that's a huge value.
Using git and producing nice commits is about _documenting_ the history
of your code. And having small, self-contained and well separated
commits is key to that.
And the index can be a great help with that. Given the above example,
you might already have some code to use the configured colors, just for
testing, so things aren't so boring. Maybe even some hack-up of the
code you'll be using later. If that part of the code would be committed
right away, you'd mess up your commit, because it wouldn't be about a
single change anymore, but would also have your testing code in there.
Bad.
But you don't want to throw the testing code away either, because it's
useful right now, and you might need it later, because it might evolve
into the final code used for the actual coloring. So, what now? You have
code that you want to commit, and some code you don't want to commit,
and which needs to go away temporarily, so you can test without it. No
problem, here comes the index.
Say you have:
config.c # Has changes for the colors
show_mail.c # Has changes to use the colors
whatever.c # Has some changes for both
You do:
git add config.c # Add to the index
git add -p whatever.c # Only add some hunks to the index
So now the index has what you want to commit, and the working tree still
has everything.
git stash save --keep-index
Now your working tree and index only have the things you want to commit.
You run your unit tests, everythings fine. You commit and get a nice
clean commit, for which you write a useful commit message.
git stash pop
You've got your changes back that you didn't want to commit just yet,
and you can continue working.
Another use-case I have found for myself is to use the index to separate
reviewed and not-yet-reviewed changes. Before I commit, I always review
the diff of the things I'm going to commit. So I start out with "git
diff" and start reading. When I finished reviewing a file, I can do "git
add $that_file", so the diff for that file will no longer be shown by
"git diff". That nicely cuts down the size of the "git diff" output to
things I'm still interested in. Quite useful when you are forced to do a
large commit, because you did some refactoring. If I find a bug during
the review, I can fix that and re-run "git diff", which will only show
changes to me that I didn't declare as "good" already by adding them to
the index.
Sure, it takes some pratice and discipline to generate a nice, useful
history. But that's not much different from writing code. Others will
hate you for writing unreadable spaghetti code, and so will they hate
you for producing a useless history that tells them that you had lunch,
instead of telling them what you did to the code ;-)
Björn
^ permalink raw reply
* [PATCH v2] git am/mailinfo: Don't look at in-body headers when rebasing
From: Lukas Sandström @ 2009-11-19 8:51 UTC (permalink / raw)
To: Philip Hofstetter, Junio C Hamano; +Cc: Lukas Sandström, Jeff King, git
In-Reply-To: <aa2993680911181547p4cbbf12cq74b482f63e59d007@mail.gmail.com>
When we are rebasing we know that the header lines in the
patch are good and that we don't need to pick up any headers
from the body of the patch.
This makes it possible to rebase commits whose commit message
start with "From" or "Date".
Test vectors by Jeff King.
Signed-off-by: Lukas Sandström <luksan@gmail.com>
---
Argh. I just realized that the change to t5100 in the previous patch
doesn't actually test the new option, since I forgot to change the
+ if test -f "$TEST_DIRECTORY"/t5100/msg$mail--use-first-header
line to "--no-inbody-headers", after my first attempt at an option name.
This time I checked that the tests actually fail when the test is broken.
Still passes, just one line changed since the previous version.
/Lukas
builtin-mailinfo.c | 5 +++++
git-am.sh | 13 ++++++++++---
t/t5100-mailinfo.sh | 6 +++++-
t/t5100/info0015 | 5 +++++
t/t5100/info0015--no-inbody-headers | 5 +++++
t/t5100/info0016 | 5 +++++
t/t5100/info0016--no-inbody-headers | 5 +++++
t/t5100/msg0015 | 2 ++
t/t5100/msg0015--no-inbody-headers | 3 +++
t/t5100/msg0016 | 2 ++
t/t5100/msg0016--no-inbody-headers | 4 ++++
t/t5100/patch0015 | 8 ++++++++
t/t5100/patch0015--no-inbody-headers | 8 ++++++++
t/t5100/patch0016 | 8 ++++++++
t/t5100/patch0016--no-inbody-headers | 8 ++++++++
t/t5100/sample.mbox | 33 +++++++++++++++++++++++++++++++++
16 files changed, 116 insertions(+), 4 deletions(-)
create mode 100644 t/t5100/info0015
create mode 100644 t/t5100/info0015--no-inbody-headers
create mode 100644 t/t5100/info0016
create mode 100644 t/t5100/info0016--no-inbody-headers
create mode 100644 t/t5100/msg0015
create mode 100644 t/t5100/msg0015--no-inbody-headers
create mode 100644 t/t5100/msg0016
create mode 100644 t/t5100/msg0016--no-inbody-headers
create mode 100644 t/t5100/patch0015
create mode 100644 t/t5100/patch0015--no-inbody-headers
create mode 100644 t/t5100/patch0016
create mode 100644 t/t5100/patch0016--no-inbody-headers
diff --git a/builtin-mailinfo.c b/builtin-mailinfo.c
index c90cd31..a81526e 100644
--- a/builtin-mailinfo.c
+++ b/builtin-mailinfo.c
@@ -26,6 +26,7 @@ static struct strbuf charset = STRBUF_INIT;
static int patch_lines;
static struct strbuf **p_hdr_data, **s_hdr_data;
static int use_scissors;
+static int use_inbody_headers = 1;
#define MAX_HDR_PARSED 10
#define MAX_BOUNDARIES 5
@@ -771,6 +772,8 @@ static int handle_commit_msg(struct strbuf *line)
return 0;
if (still_looking) {
+ if (!use_inbody_headers)
+ still_looking = 0;
strbuf_ltrim(line);
if (!line->len)
return 0;
@@ -1033,6 +1036,8 @@ int cmd_mailinfo(int argc, const char **argv, const char *prefix)
use_scissors = 1;
else if (!strcmp(argv[1], "--no-scissors"))
use_scissors = 0;
+ else if (!strcmp(argv[1], "--no-inbody-headers"))
+ use_inbody_headers = 0;
else
usage(mailinfo_usage);
argc--; argv++;
diff --git a/git-am.sh b/git-am.sh
index c132f50..96869a2 100755
--- a/git-am.sh
+++ b/git-am.sh
@@ -289,7 +289,7 @@ split_patches () {
prec=4
dotest="$GIT_DIR/rebase-apply"
sign= utf8=t keep= skip= interactive= resolved= rebasing= abort=
-resolvemsg= resume= scissors=
+resolvemsg= resume= scissors= no_inbody_headers=
git_apply_opt=
committer_date_is_author_date=
ignore_date=
@@ -322,7 +322,7 @@ do
--abort)
abort=t ;;
--rebasing)
- rebasing=t threeway=t keep=t scissors=f ;;
+ rebasing=t threeway=t keep=t scissors=f no_inbody_headers=t ;;
-d|--dotest)
die "-d option is no longer supported. Do not use."
;;
@@ -448,6 +448,7 @@ else
echo "$utf8" >"$dotest/utf8"
echo "$keep" >"$dotest/keep"
echo "$scissors" >"$dotest/scissors"
+ echo "$no_inbody_headers" >"$dotest/no_inbody_headers"
echo "$GIT_QUIET" >"$dotest/quiet"
echo 1 >"$dotest/next"
if test -n "$rebasing"
@@ -495,6 +496,12 @@ t)
f)
scissors=--no-scissors ;;
esac
+if test "$(cat "$dotest/no_inbody_headers")" = t
+then
+ no_inbody_headers=--no-inbody-headers
+else
+ no_inbody_headers=
+fi
if test "$(cat "$dotest/quiet")" = t
then
GIT_QUIET=t
@@ -549,7 +556,7 @@ do
# by the user, or the user can tell us to do so by --resolved flag.
case "$resume" in
'')
- git mailinfo $keep $scissors $utf8 "$dotest/msg" "$dotest/patch" \
+ git mailinfo $keep $no_inbody_headers $scissors $utf8 "$dotest/msg" "$dotest/patch" \
<"$dotest/$msgnum" >"$dotest/info" ||
stop_here $this
diff --git a/t/t5100-mailinfo.sh b/t/t5100-mailinfo.sh
index 0279d07..ebc36c1 100755
--- a/t/t5100-mailinfo.sh
+++ b/t/t5100-mailinfo.sh
@@ -11,7 +11,7 @@ test_expect_success 'split sample box' \
'git mailsplit -o. "$TEST_DIRECTORY"/t5100/sample.mbox >last &&
last=`cat last` &&
echo total is $last &&
- test `cat last` = 14'
+ test `cat last` = 16'
check_mailinfo () {
mail=$1 opt=$2
@@ -30,6 +30,10 @@ do
if test -f "$TEST_DIRECTORY"/t5100/msg$mail--scissors
then
check_mailinfo $mail --scissors
+ fi &&
+ if test -f "$TEST_DIRECTORY"/t5100/msg$mail--no-inbody-headers
+ then
+ check_mailinfo $mail --no-inbody-headers
fi
'
done
diff --git a/t/t5100/info0015 b/t/t5100/info0015
new file mode 100644
index 0000000..0114f10
--- /dev/null
+++ b/t/t5100/info0015
@@ -0,0 +1,5 @@
+Author:
+Email:
+Subject: check bogus body header (from)
+Date: Fri, 9 Jun 2006 00:44:16 -0700
+
diff --git a/t/t5100/info0015--no-inbody-headers b/t/t5100/info0015--no-inbody-headers
new file mode 100644
index 0000000..c4d8d77
--- /dev/null
+++ b/t/t5100/info0015--no-inbody-headers
@@ -0,0 +1,5 @@
+Author: A U Thor
+Email: a.u.thor@example.com
+Subject: check bogus body header (from)
+Date: Fri, 9 Jun 2006 00:44:16 -0700
+
diff --git a/t/t5100/info0016 b/t/t5100/info0016
new file mode 100644
index 0000000..38ccd0d
--- /dev/null
+++ b/t/t5100/info0016
@@ -0,0 +1,5 @@
+Author: A U Thor
+Email: a.u.thor@example.com
+Subject: check bogus body header (date)
+Date: bogus
+
diff --git a/t/t5100/info0016--no-inbody-headers b/t/t5100/info0016--no-inbody-headers
new file mode 100644
index 0000000..f4857d4
--- /dev/null
+++ b/t/t5100/info0016--no-inbody-headers
@@ -0,0 +1,5 @@
+Author: A U Thor
+Email: a.u.thor@example.com
+Subject: check bogus body header (date)
+Date: Fri, 9 Jun 2006 00:44:16 -0700
+
diff --git a/t/t5100/msg0015 b/t/t5100/msg0015
new file mode 100644
index 0000000..9577238
--- /dev/null
+++ b/t/t5100/msg0015
@@ -0,0 +1,2 @@
+- a list
+ - of stuff
diff --git a/t/t5100/msg0015--no-inbody-headers b/t/t5100/msg0015--no-inbody-headers
new file mode 100644
index 0000000..be5115b
--- /dev/null
+++ b/t/t5100/msg0015--no-inbody-headers
@@ -0,0 +1,3 @@
+From: bogosity
+ - a list
+ - of stuff
diff --git a/t/t5100/msg0016 b/t/t5100/msg0016
new file mode 100644
index 0000000..0d9adad
--- /dev/null
+++ b/t/t5100/msg0016
@@ -0,0 +1,2 @@
+and some content
+
diff --git a/t/t5100/msg0016--no-inbody-headers b/t/t5100/msg0016--no-inbody-headers
new file mode 100644
index 0000000..1063f51
--- /dev/null
+++ b/t/t5100/msg0016--no-inbody-headers
@@ -0,0 +1,4 @@
+Date: bogus
+
+and some content
+
diff --git a/t/t5100/patch0015 b/t/t5100/patch0015
new file mode 100644
index 0000000..ad64848
--- /dev/null
+++ b/t/t5100/patch0015
@@ -0,0 +1,8 @@
+---
+diff --git a/foo b/foo
+index e69de29..d95f3ad 100644
+--- a/foo
++++ b/foo
+@@ -0,0 +1 @@
++content
+
diff --git a/t/t5100/patch0015--no-inbody-headers b/t/t5100/patch0015--no-inbody-headers
new file mode 100644
index 0000000..ad64848
--- /dev/null
+++ b/t/t5100/patch0015--no-inbody-headers
@@ -0,0 +1,8 @@
+---
+diff --git a/foo b/foo
+index e69de29..d95f3ad 100644
+--- a/foo
++++ b/foo
+@@ -0,0 +1 @@
++content
+
diff --git a/t/t5100/patch0016 b/t/t5100/patch0016
new file mode 100644
index 0000000..ad64848
--- /dev/null
+++ b/t/t5100/patch0016
@@ -0,0 +1,8 @@
+---
+diff --git a/foo b/foo
+index e69de29..d95f3ad 100644
+--- a/foo
++++ b/foo
+@@ -0,0 +1 @@
++content
+
diff --git a/t/t5100/patch0016--no-inbody-headers b/t/t5100/patch0016--no-inbody-headers
new file mode 100644
index 0000000..ad64848
--- /dev/null
+++ b/t/t5100/patch0016--no-inbody-headers
@@ -0,0 +1,8 @@
+---
+diff --git a/foo b/foo
+index e69de29..d95f3ad 100644
+--- a/foo
++++ b/foo
+@@ -0,0 +1 @@
++content
+
diff --git a/t/t5100/sample.mbox b/t/t5100/sample.mbox
index 13fa4ae..de10312 100644
--- a/t/t5100/sample.mbox
+++ b/t/t5100/sample.mbox
@@ -650,3 +650,36 @@ index b0b5d8f..461c47e 100644
convert_to_utf8(line, charset.buf);
--
1.6.4.1
+From nobody Mon Sep 17 00:00:00 2001
+From: A U Thor <a.u.thor@example.com>
+Subject: check bogus body header (from)
+Date: Fri, 9 Jun 2006 00:44:16 -0700
+
+From: bogosity
+ - a list
+ - of stuff
+---
+diff --git a/foo b/foo
+index e69de29..d95f3ad 100644
+--- a/foo
++++ b/foo
+@@ -0,0 +1 @@
++content
+
+From nobody Mon Sep 17 00:00:00 2001
+From: A U Thor <a.u.thor@example.com>
+Subject: check bogus body header (date)
+Date: Fri, 9 Jun 2006 00:44:16 -0700
+
+Date: bogus
+
+and some content
+
+---
+diff --git a/foo b/foo
+index e69de29..d95f3ad 100644
+--- a/foo
++++ b/foo
+@@ -0,0 +1 @@
++content
+
--
1.6.4.4
^ permalink raw reply related
* Re: [PATCH v2 2/2] gitk: add --no-replace-objects option
From: Paul Mackerras @ 2009-11-19 9:01 UTC (permalink / raw)
To: Christian Couder
Cc: Junio C Hamano, git, Michael J Gruber, Jakub Narebski,
Johannes Sixt, bill lam, Andreas Schwab
In-Reply-To: <20091118065100.4206.48820.chriscool@tuxfamily.org>
Christian Couder writes:
> This option simply sets the GIT_NO_REPLACE_OBJECTS environment
> variable, and that is enough to make gitk ignore replace refs.
For the commit message, could you add a couple of lines telling us
what replace refs are and why you might want gitk to ignore them?
Paul.
^ permalink raw reply
* Re: [PATCH] gitk: Use git-difftool for external diffs
From: Paul Mackerras @ 2009-11-19 9:03 UTC (permalink / raw)
To: David Aguilar; +Cc: peff, sam, git
In-Reply-To: <1258341126-2108-1-git-send-email-davvid@gmail.com>
David Aguilar writes:
> This teaches gitk about git-difftool. A benefit of this change is
> that gitk's external diff now works with read-only repositories.
What version of git does git difftool first appear in? I prefer not
to introduce hard requirements on very recent versions of git into
gitk.
Paul.
^ permalink raw reply
* Re: [PATCH 2/2] Add gitk-git Hungarian translation
From: Paul Mackerras @ 2009-11-19 9:07 UTC (permalink / raw)
To: Laszlo Papp; +Cc: git, Laszlo Papp
In-Reply-To: <1258284204-17247-1-git-send-email-djszapi@archlinux.us>
Laszlo Papp writes:
> Signed-off-by: Laszlo Papp <djszapi@archlinux.us>
> ---
> gitk-git/po/hu.po | 1151 +++++++++++++++++++++++++++++++++++++++++++++++++++++
Is there a patch 1/2 that needs to be applied first, as the subject
line might imply?
Paul.
^ permalink raw reply
* Re: [gitk] [PATCH] Fix selection of tags.
From: Paul Mackerras @ 2009-11-19 9:33 UTC (permalink / raw)
To: Pat Thoyts; +Cc: git
In-Reply-To: <87r5s0vnas.fsf@users.sourceforge.net>
Pat Thoyts writes:
> When a tag is clicked an error is raised due to a missing parameter in
> a function call.
>
> Signed-off-by: Pat Thoyts <patthoyts@users.sourceforge.net>
Thanks, applied.
Paul.
^ permalink raw reply
* Re: git-svn of both trunk and tags while having no access to the 'parent' of those
From: Eric Wong @ 2009-11-19 9:53 UTC (permalink / raw)
To: Michael J Gruber; +Cc: Yaroslav Halchenko, git
In-Reply-To: <4B040D95.9040901@drmicha.warpmail.net>
Michael J Gruber <git@drmicha.warpmail.net> wrote:
> Yaroslav Halchenko venit, vidit, dixit 18.11.2009 15:23:
> >
> > On Wed, 18 Nov 2009, Michael J Gruber wrote:
> >>> git svn clone --no-minimize-url --prefix=upstream-svn/ -T trunk -t releases http://domain.com/svnrepo/trunk svnrepo.gitsvn
> >> Is the trunk really at svnrepo/trunk/trunk?
> > nope... it is just svnrepo/trunk but if I set url to point to parent --
> > git svn seeks authentication right away
> >
> >> I would try both
> >> git svn clone --no-minimize-url --prefix=upstream-svn/ -T trunk -t
> >> releases http://domain.com/svnrepo/ svnrepo.gitsvn
> >
> > asks for authentication since there is no public access to
> > http://domain.com/svnrepo/
> >
> >> and also the seemingly equivalent
> >
> >> git svn clone --no-minimize-url --prefix=upstream-svn/ -T
> >> http://domain.com/svnrepo/trunk -t http://domain.com/svnrepo/releases
> >> svnrepo.gitsvn
> > seems to not work since it wants url as a parameter
> >
> > Bad URL passed to RA layer: Illegal repository URL svnrepo.gitsvn at /usr/lib/git-core/git-svn line 940
Hi Michael, Yaroslav,
I think that second command syntax only works for "git svn init" right
now, not sure if it ever worked with "clone".
> >> Also, I assume you can svn list http://domain.com/svnrepo/trunk and
> >> http://domain.com/svnrepo/releases ;)
> > yeap -- I can list both of those but not their parent.
> >
>
> OK, so the way it's implemented --no-minimize-url might be half as
> useful as it could be. One last try (before asking Eric...) would be
>
> git svn clone --no-minimize-url --prefix=upstream-svn/ -T
> http://domain.com/svnrepo/trunk -t http://domain.com/svnrepo/releases
> http://domain.com/svnrepo/trunk svnrepo.gitsvn
>
> because that involves accessible URLs only and trunk and branch URLs are
> absolute.
>
> [Meanwhile I git the actual URL PMed by Yaroslov.]
Any chance I could get that URL? (I probably won't get a chance to
spend time debugging this until Friday). Might be worth it to get an
strace or tcpdump to see what exactly is going on. Or at least some
print statements around Git::SVN::Ra::new()...
> So, what happens with the above is that git-svn tries to set the URL
> config again from the URL part of an absolute tags argument. I don't
> know how absolute URLs (which are documented) for tags etc. could
> possibly work if git-svn tries to do that. Eric?
It looks like support for specifying absolute URLs with "clone"
has been broken for a while. Guess I'll need test cases...
> I tried also with two svn sections to circumvent this:
>
> [svn-remote "svn"]
> url = http://domain.com:/project/trunk
> fetch = :refs/remotes/trunk
> [svn-remote "svnr"]
> url = http://domain.com:/project/releases
> tags = /*:refs/remotes/tags/*
>
> Fetching -Rsvn works fine, but fetching -Rsvnr gives the same
> authentication problems. And fetch does not accept --no-minimize-url as
> an option. OTOH: If the option is not used it seems to me (from the
> source) that not minimizing is the default, which leaves me really
> stomped. Eric?? ;)
Odd that the svnr one doesn't work. Does changing:
tags = /*:refs/remotes/tags/*
to:
tags = *:refs/remotes/tags/*
help at all?
Minimizing should be the default in 1.6.5. I'm a bit stumped, too :x
I'd like to see what network traffic git svn is sending for
the "svnr" case vs "svn ls http://domain.com/project/releases"
--
Eric Wong
^ permalink raw reply
* Re: [ANNOUNCE] codeBeamer MR - Easy ACL for Git
From: Intland Software @ 2009-11-19 10:06 UTC (permalink / raw)
To: david; +Cc: Petr Baudis, git
In-Reply-To: <alpine.DEB.2.00.0911182205590.5646@asgard.lang.hm>
Hey David,
david@lang.hm wrote:
>> our commercial license doesn't (currently) allow publishing the
>> complete code. We have quite some large customers from the defense space
>> that would not be happy if we opened everything ;)
>
> are you sure? did you see the recent memo about OpenSource by the DOD?
> David Lang
Can you direct us to an URL please? Thanks.
---
Intland
^ permalink raw reply
* Re: Hey - A Conceptual Simplication....
From: Jakub Narebski @ 2009-11-19 10:27 UTC (permalink / raw)
To: George Dennie; +Cc: 'Jason Sewall', 'Jan Krüger', git
In-Reply-To: <009401ca68bc$7e4b12b0$7ae13810$@com>
Side-note: you are employing very strange line wrapping... you should
word wrap your lines so they do not exceed 70-76 characters, and you
should not (except when required for readability) rewrap quoted text.
On Thu, 19 Nov 2009, George Dennie wrote:
> Thanks Linus, Jason, and Jakub...
>
> Linus Torvalds wrote....
>>On Wed, 18 Nov 2009, George Dennie wrote:
>>>
>>> The Git model does not seem to go far enough conceptually, for some
>>> unexplainable reason...
>>
>> Others already mentioned this, but the concept you missed is the git
>> 'index', which is actually very central (it is actually the first
>> part of git written, before even the object database) but is
>> something that most people who get started with git can (and do)
>> ignore.
>
> Uhmmm, subtle. I hear you. Thanks for the heads up. But before that,
> I just put these two cents down...
> [...] Now, I have not had occasions to do merges, as such. So I am
> finding the justification for the index vague. [...]
Errr... you didn't do any merges? What is then your experience with
using version control, then?
As for using index during merge: merge is joining two (or more) lines
of history (lines of development), bringing contents of another branch
into current branch. Some of changes are independent, for example
if one branch changes one file, and other branch changed other file.
This is so called trivial merge, example of tree-level merge. Even
if branches merged touch the same file, if changes were made in separate
sections of file git can merge changes (using three-way merge / diff3
algorithm).
The problem starts if there are changes which touch the same sections
of a file. This generates so called merge conflict (contents conflict),
and you have to resolve such conflict manually.
During merge index helps to manage information about yet unmerged parts.
Let's assume for example that you made a mistake in merge resolution in
some file, and you want to scratch your attempt and try it anew.
Without index it would be very hard to do without trashing resolutions
of other conflicts.
> For example, the functional notion of the repository seems well
> defined: a growing web of immutable commits each created as either
> an isolated commit or more typically an update and/or merger of
> one or more pre-existing commits.
If by "web" you mean DAG (Directed Acyclic Graph) of commits, then
yes, it is _part_ of repository.
There are also refs (branches, tags, remote-tracking branches), which
are also part of repository, very important part. Those are named
references into DAG of commits.
As to commits being created as update of existing commit or from
scratch: that would depend on the way of development. Merge commits
are much, much more rare than ordinary commits (especially that git
favors fast-forwards by default when there is no need for merge).
>
> With such a description the rest of the structure becomes almost
> implicit: Commits may be annotated such as with release number labels.
> Commits that have not been linked to such as by an update or merger
> remain dangling like loose threads in the web and are called branches.
> Branches may be given special labels that the repository will then
> automatically update so as to refer to the latest commit to that
> branch.
Almost right.
> I don't yet have such a clear model for the index. Yes it is a staging
> platform, but so is the IDE....I'll do more reading.
The index is area where you prepare commits, if needed. But you
don't need to care that there is something like the index, and prepare
your commits in working area. But when you need it, it is there.
--
Jakub Narebski
Poland
^ permalink raw reply
* Re: [ANNOUNCE] codeBeamer MR - Easy ACL for Git
From: Jakub Narebski @ 2009-11-19 10:43 UTC (permalink / raw)
To: Intland Software; +Cc: david, Petr Baudis, git
In-Reply-To: <4B0518A3.90903@intland.com>
Intland Software <marketing@intland.com> writes:
> david@lang.hm wrote:
>>> our commercial license doesn't (currently) allow publishing the
>>> complete code. We have quite some large customers from the defense space
>>> that would not be happy if we opened everything ;)
>>
>> are you sure? did you see the recent memo about OpenSource by the
>> DOD?
>
> Can you direct us to an URL please? Thanks.
Indirect links:
* "New DoD memo on Open Source Software" (David A. Wheeler)
http://www.dwheeler.com/blog/2009/10/27/#dod-oss-2009
* "Notes about the DoD and OSS memo" (David A. Wheeler)
http://www.dwheeler.com/blog/2009/10/28/#dod-oss-2009-notes
--
Jakub Narebski
Poland
ShadeHawk on #git
^ permalink raw reply
* Re: [ANNOUNCE] codeBeamer MR - Easy ACL for Git
From: Rakotomandimby Mihamina @ 2009-11-19 11:39 UTC (permalink / raw)
To: git
In-Reply-To: <4B03F451.4050709@intland.com>
11/18/2009 04:19 PM, Intland Software::
> We have quite some large customers from the defense space
> that would not be happy if we opened everything
I think they are just dumb.
But they pay you, so let's just say it's OK. :-)
--
Architecte Informatique chez Blueline/Gulfsat:
Administration Systeme, Recherche & Developpement
+261 33 11 207 36
^ permalink raw reply
* Re: git-svn not fetching all revisions
From: Marcus Better @ 2009-11-19 12:07 UTC (permalink / raw)
To: Sam Vilain; +Cc: git
In-Reply-To: <4AFA36F0.6070501@vilain.net>
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Sam Vilain wrote:
> Marcus Better wrote:
>> The problem is that the trunk was replaced by a branch at some point.
> Yeah. Try doing it in parts - fetch the two stages of the history
> explicitly using the revision range arguments to 'git svn fetch' - and
> then graft the histories together and fix up with git filter-branch.
Ok, that works, but how can I now sync with the svn repository with git
svn rebase/dcommit? I think the filter-branch rewriting confuses git-svn.
Cheers,
Marcus
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iEYEARECAAYFAksFNPsACgkQXjXn6TzcAQkr+QCgxQ1r68v2O1Ux7YFoS5IQS1GT
/cgAoLoTgRcIK7vMTJWfmN2XAhcy0eOa
=dnet
-----END PGP SIGNATURE-----
^ permalink raw reply
* Re: [ANNOUNCE] codeBeamer MR - Easy ACL for Git
From: Aron Gombas @ 2009-11-19 12:15 UTC (permalink / raw)
To: Jakub Narebski; +Cc: david, Petr Baudis, git
In-Reply-To: <m33a4adcbu.fsf@localhost.localdomain>
Jakub Narebski wrote:
> Intland Software <marketing@intland.com> writes:
>
>> david@lang.hm wrote:
>
>>>> our commercial license doesn't (currently) allow publishing the
>>>> complete code. We have quite some large customers from the defense space
>>>> that would not be happy if we opened everything ;)
>>> are you sure? did you see the recent memo about OpenSource by the
>>> DOD?
>> Can you direct us to an URL please? Thanks.
>
> Indirect links:
> * "New DoD memo on Open Source Software" (David A. Wheeler)
> http://www.dwheeler.com/blog/2009/10/27/#dod-oss-2009
> * "Notes about the DoD and OSS memo" (David A. Wheeler)
> http://www.dwheeler.com/blog/2009/10/28/#dod-oss-2009-notes
Hmm, very interesting reading! Thanks a lot.
---
Intland
^ permalink raw reply
* Re: [ANNOUNCE] codeBeamer MR - Easy ACL for Git
From: Intland Software @ 2009-11-19 13:50 UTC (permalink / raw)
To: Petr Baudis; +Cc: git
In-Reply-To: <20091118120936.GL17748@machine.or.cz>
Petr Baudis wrote:
> I think a lot of people wonder now, how does this compare to existing
> solutions; from your announcement I thought it's something like
> Gitosis/Gitolite, but in fact it seems more similar to Gitorious or
> GitHub (if it was publicly available, of course); perhaps it would be
All right, some quick comparisons with codeBeamer Managed Repository (MR).
* MR against Gitosis
In terms of access control, MR has the concept of "role", and it makes our security model more fine grained. Permissions
can be set by role. One user account can have multiple roles. Roles are project-dependent. When you add a group to a
project, you can assign multiple roles to the group (which is equivalent with assigning those roles to each group member
one by one).
On the other hand, MR has a much broader scope than Gitosis. MR helps you to manage your repos, to track your
tasks/bugs/issues, to follow commit activities, to browse repos in the web, can be extended using its APIs, etc. (And
you don't have to install and maintain Git extensions for this.)
* MR against Gitolite
Pretty much the same applies here as well.
* MR against GitHub & Gitorious
Probably the most significant difference is that MR is available as free download, and can run behind your firewall.
MR was derived from the source code of our commercial product codeBeamer. CodeBeamer is a full-blown enterprise
collaboration solution, thus MR is likely to focus more on the enterprise needs, not on the "social" aspect.
^ permalink raw reply
* Re: [ANNOUNCE] codeBeamer MR - Easy ACL for Git
From: Thomas Rast @ 2009-11-19 14:01 UTC (permalink / raw)
To: Intland Software; +Cc: Petr Baudis, git
In-Reply-To: <4B054D0A.5030802@intland.com>
Intland Software wrote:
> * MR against GitHub & Gitorious
> Probably the most significant difference is that MR is available as free download
Umm... unlike Gitorious, you mean:
http://gitorious.org/gitorious
http://gitorious.org/gitorious/mainline/blobs/master/LICENSE
--
Thomas Rast
trast@{inf,student}.ethz.ch
^ permalink raw reply
* Re: [PATCH v4] git remote: Separate usage strings for subcommands
From: Tim Henigan @ 2009-11-19 14:51 UTC (permalink / raw)
To: Nanako Shiraishi; +Cc: Junio C Hamano, jrnieder, git
In-Reply-To: <20091119124040.6117@nanako3.lavabit.com>
On Wed, Nov 18, 2009 at 10:40 PM, Nanako Shiraishi <nanako3@lavabit.com> wrote:
> Quoting Tim Henigan <tim.henigan@gmail.com>
>
>> When the usage string for a subcommand must be printed,
>> only print the information relevant to that command.
>
> I think this is a huge improvement.
>
> Often people look at this part of the manual page to quickly remind
> themselves what options are available, and it is better to keep the
> current text. Some manual pages have to use [options...] when there
> are too many to list, but each subcommand of git-remote doesn't have
> that many options.
... snip ...
> For the same reason, I don't think this is a good change, if these
> lines are used to show the first lines of 'git-remote -h' output.
The original version of this patch [1] left the contents of the usage
strings intact. However, Junio expressed a preference to change
them to use the generic <options>. See this thread for the
discussion [2].
[1] http://article.gmane.org/gmane.comp.version-control.git/133048/
[2] http://thread.gmane.org/gmane.comp.version-control.git/132968/focus=133050
^ 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