* [PATCH] gitweb: the commitdiff is very commonly used, it's needed on search page, too
From: Denis Cheng @ 2007-11-26 12:42 UTC (permalink / raw)
To: git; +Cc: dengxw
---
gitweb/gitweb.perl | 2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl
index 491a3f4..ff5daa7 100755
--- a/gitweb/gitweb.perl
+++ b/gitweb/gitweb.perl
@@ -3786,6 +3786,8 @@ sub git_search_grep_body {
"<td class=\"link\">" .
$cgi->a({-href => href(action=>"commit", hash=>$co{'id'})}, "commit") .
" | " .
+ $cgi->a({-href => href(action=>"commitdiff", hash=>$co{'id'})}, "commitdiff") .
+ " | " .
$cgi->a({-href => href(action=>"tree", hash=>$co{'tree'}, hash_base=>$co{'id'})}, "tree");
print "</td>\n" .
"</tr>\n";
--
1.5.3.4
^ permalink raw reply related
* Re: Rebase/cherry-picking idea
From: Johannes Sixt @ 2007-11-26 12:51 UTC (permalink / raw)
To: Wincent Colaiuta; +Cc: Benoit Sigoure, Git Mailing List
In-Reply-To: <CDF48716-F198-4B33-A5F5-8A2DE1F177EB@wincent.com>
Wincent Colaiuta schrieb:
> El 26/11/2007, a las 12:27, Wincent Colaiuta escribió:
>> So I think that misleading noise needs to be suppressed or reworded
>> when rebasing. Will look into it.
>
> How about something like this? It would obviously be nice if we could
> avoid adding another option to builtin-revert; perhaps when/if
> git-rebase becomes a builtin we can avoid that. The other alternative,
> and probably one I like I bit more, would be to auto-detect that a
> rebase is in progress by looking inside the GIT_DIR, although that would
> also alter the behaviour of manual invocations of git-revert and
> git-cherry-pick during an interactive rebase (do people actually do
> that?). What do you think?
Introduce an environment variable _GIT_CHERRY_PICK_HELP (note the leading
underscore), which git-rebase sets; if it's set, git-cherry-pick uses that
text instead of the usual one.
-- Hannes
^ permalink raw reply
* Re: Reordering lines in "git-rebase -i" task sheet
From: Andy Parkins @ 2007-11-26 13:14 UTC (permalink / raw)
To: git
In-Reply-To: <fi64ge$u1g$1@ger.gmane.org>
Andy Parkins wrote:
> I'm not convinced that this is a great idea.
I've just tried it and (for me) I don't like it.
- It's now harder to find the commits I want to edit, the cursor still
doesn't start in the right place, but now I can't get to the right place
quickly (the right place being the bottom of the list) because the
interesting bits are neither at the top nor at the bottom
- vim no longer automatically loads a reasonable syntax highlighting mode
making the comment lines appear the same as the pick lines.
- On a long rebase list the important message explaining what I'm looking
at isn't on screen.
Andy
--
Dr Andy Parkins, M Eng (hons), MIET
andyparkins@gmail.com
^ permalink raw reply
* Re: Rebase/cherry-picking idea
From: Wincent Colaiuta @ 2007-11-26 13:15 UTC (permalink / raw)
To: Johannes Sixt; +Cc: Benoit Sigoure, Git Mailing List
In-Reply-To: <474AC136.8060906@viscovery.net>
El 26/11/2007, a las 13:51, Johannes Sixt escribió:
> Wincent Colaiuta schrieb:
>> El 26/11/2007, a las 12:27, Wincent Colaiuta escribió:
>>> So I think that misleading noise needs to be suppressed or
>>> reworded when rebasing. Will look into it.
>> How about something like this? It would obviously be nice if we
>> could avoid adding another option to builtin-revert; perhaps when/
>> if git-rebase becomes a builtin we can avoid that. The other
>> alternative, and probably one I like I bit more, would be to auto-
>> detect that a rebase is in progress by looking inside the GIT_DIR,
>> although that would also alter the behaviour of manual invocations
>> of git-revert and git-cherry-pick during an interactive rebase (do
>> people actually do that?). What do you think?
>
> Introduce an environment variable _GIT_CHERRY_PICK_HELP (note the
> leading underscore), which git-rebase sets; if it's set, git-cherry-
> pick uses that text instead of the usual one.
Good idea, quite a bit less cruddy:
diff --git a/builtin-revert.c b/builtin-revert.c
index a0586f9..5a57574 100644
--- a/builtin-revert.c
+++ b/builtin-revert.c
@@ -229,7 +229,7 @@ static int revert_or_cherry_pick(int argc, const
char **argv)
unsigned char head[20];
struct commit *base, *next, *parent;
int i;
- char *oneline, *reencoded_message = NULL;
+ char *oneline, *reencoded_message = NULL, *help_message;
const char *message, *encoding;
const char *defmsg = xstrdup(git_path("MERGE_MSG"));
@@ -352,11 +352,13 @@ static int revert_or_cherry_pick(int argc, const
char **argv)
}
if (close(msg_fd) || commit_lock_file(&msg_file) < 0)
die ("Error wrapping up %s", defmsg);
+ help_message = getenv("_GIT_CHERRY_PICK_HELP");
fprintf(stderr, "Automatic %s failed. "
"After resolving the conflicts,\n"
"mark the corrected paths with 'git add <paths>' "
- "and commit the result.\n", me);
- if (action == CHERRY_PICK) {
+ "and %s.\n", me,
+ help_message ? help_message : "commit the result");
+ if (action == CHERRY_PICK && !help_message) {
fprintf(stderr, "When commiting, use the option "
"'-c %s' to retain authorship and message.\n",
find_unique_abbrev(commit->object.sha1,
diff --git a/git-rebase--interactive.sh b/git-rebase--interactive.sh
index bf44b6a..e5f9810 100755
--- a/git-rebase--interactive.sh
+++ b/git-rebase--interactive.sh
@@ -117,6 +117,7 @@ pick_one () {
sha1=$(git rev-parse --short $sha1)
output warn Fast forward to $sha1
else
+ export _GIT_CHERRY_PICK_HELP="run 'git rebase --continue'"
output git cherry-pick "$@"
fi
}
@@ -187,6 +188,7 @@ pick_one_preserving_merges () {
fi
;;
*)
+ export _GIT_CHERRY_PICK_HELP="run 'git rebase --continue'"
output git cherry-pick "$@" ||
die_with_patch $sha1 "Could not pick $sha1"
;;
^ permalink raw reply related
* Re: Rebase/cherry-picking idea
From: Johannes Schindelin @ 2007-11-26 13:26 UTC (permalink / raw)
To: Benoit Sigoure; +Cc: Wincent Colaiuta, Git Mailing List
In-Reply-To: <C3971B37-F75A-40EE-B30A-E88E5DAFAD55@lrde.epita.fr>
Hi,
On Mon, 26 Nov 2007, Benoit Sigoure wrote:
> On Nov 26, 2007, at 10:02 AM, Wincent Colaiuta wrote:
>
> > In using "git-rebase --interactive" to re-order commits you occasionally get
> > conflicts and will see a message like this:
> >
> > When commiting, use the option '-c %s' to retain authorship and
> > message
> >
> > I was thinking that it might be nice to stash away this commit id somewhere
> > in GIT_DIR so that the user didn't have to explicitly remember it, and add a
> > new switch to git-commit that could be used to automatically use that
> > stashed commit id, something like:
> >
> > git commit --retain
> >
> > Although I most often see this kind of message in interactive rebasing, the
> > message is generated in builtin-revert.c when cherry-picking, so you can
> > also see it in any other situation where you're cherry picking and there's a
> > conflict.
> >
> > What do people think? Would this be a nice usability improvement? Or is it
> > adding clutter?
>
>
> I'm not sure but I think this message is just some unwanted (misleading)
> noise, since when you rebase, once you solve the conflicts, you git-rebase
> --continue, you don't git-commit.
Yep. It is on my TODO list since a long time, but I am just as glad
somebody else is doing it. But I have to agree with Hannes that using an
environment variable is cleaner, more elegant and shorter.
Ciao,
Dscho
^ permalink raw reply
* Re: Rebase/cherry-picking idea
From: Johannes Schindelin @ 2007-11-26 13:41 UTC (permalink / raw)
To: Wincent Colaiuta; +Cc: Johannes Sixt, Benoit Sigoure, Git Mailing List
In-Reply-To: <451492C9-F3EA-4C37-A1AD-59FC72E0A0A2@wincent.com>
Hi,
On Mon, 26 Nov 2007, Wincent Colaiuta wrote:
> + help_message = getenv("_GIT_CHERRY_PICK_HELP");
Why on earth do you have a leading underscore? No existing git
environment variable does it that way.
Ciao,
Dscho
^ permalink raw reply
* Re: Rebase/cherry-picking idea
From: Wincent Colaiuta @ 2007-11-26 13:55 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Johannes Sixt, Benoit Sigoure, Git Mailing List
In-Reply-To: <Pine.LNX.4.64.0711261340470.27959@racer.site>
El 26/11/2007, a las 14:41, Johannes Schindelin escribió:
> Hi,
>
> On Mon, 26 Nov 2007, Wincent Colaiuta wrote:
>
>> + help_message = getenv("_GIT_CHERRY_PICK_HELP");
>
> Why on earth do you have a leading underscore? No existing git
> environment variable does it that way.
I was following the suggestion of Johannes Sixt:
El 26/11/2007, a las 13:51, Johannes Sixt escribió:
> Introduce an environment variable _GIT_CHERRY_PICK_HELP (note the
> leading underscore), which git-rebase sets; if it's set, git-cherry-
> pick uses that text instead of the usual one.
I imagine that he proposed it that way because it's an "internal use
only" thing.
Once I get a clear idea of what kind of change is likely to actually
get accepted I'll submit a proper patch.
Cheers,
Wincent
^ permalink raw reply
* Re: [PATCH] Don't add To: recipients to the Cc: header
From: Sergei Organov @ 2007-11-26 13:48 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Ask Bjørn Hansen, git
In-Reply-To: <7vejegsejz.fsf@gitster.siamese.dyndns.org>
Junio C Hamano <gitster@pobox.com> writes:
> Sergei Organov <osv@javad.com> writes:
>
>> Yeah, it's one valid interpretation. Here is another one:
>> ...
>> taken from here: <http://www.answers.com/topic/diff?cat=technology>
>
> Rants about how dangerous GNU patch liberally (mis)interprets a
> broken patch and git-apply is written deliberately more strict
> have been repeated on this list, and I would not steal it from
> Linus in this response.
Yeah, being strict when applying patches is a good idea, I agree, though
I fail to see how it is relevant to the problem at hand. I mean that if
we either remove the signature or put an empty line before it, the
resulting file won't become less conforming to the patch format, isn't
it?
>>> The diff editing mode of Emacs, at least the version that caused
>>> this issue, however did not make use of that information.
>>
>> IMHO it's rather useless to argue about it without strict definition of
>> correct format of a patch (do you have one?)
>
> Yes. 2004 POSIX does not talk about unified context, but Austin
> group's SD5-XCU-ERN-103/120 has additions to define unified
> context and renames the traditional '-c' output to "copied
> context". Obviously it defines what the numbers on the hunk
> header lines mean quite precisely.
I don't argue it. But the descriptions of the format I've seen suggest
that the hunks of the proper unified diff format could be easily
syntactically separated, thus providing a way to check a patch for
correctness by comparing what is written in headers with what is
gathered by syntactic analysis. Git's signature makes this rather
difficult.
IMHO, putting extra lines that don't follow the patch format precisely
is an extension, and being an extension, it should better be compatible
with as many tools as possible, and this signature of the format-patch
is known to break at least one tool. Unfortunately I don't have the
document you mention, but I doubt it discusses extensions, and therefore
I'm afraid we won't be able to conclude from it if putting signature
just after the hunk is allowed by the format or not.
As for Emacs, the problem is not that it doesn't know what the numbers
of the hunk header lines mean, but that it needs to re-build them from a
patch that has been arbitrary edited and could potentially be broken
from the beginning. Therefore, it needs hunks to be clearly
syntactically separated to rebuild header numbers from the context.
> GNU folks even managed to insert text that allows a completely empty
> line (not a line with a single SP on it) to express a context line
> that is empty, which means...
Really? That's a surprise for me. What I can tell for sure, Emacs' diff
mode doesn't support this, as it does interpret plain empty line as a
hunk delimiter, at least in Emacs 22.1.
[...]
>> Therefore I repeat my question: are there any objections to add such an
>> empty line by format-patch?
>
> ... there is a strong objection, if you are talking about adding
> an empty line before "-- \n" that is in front of the GIT version
> signature: such an empty line would not help at all.
Yes, I'm talking about exactly this, and the fact is that it does help,
at least in Emacs case. [How comes you think I didn't check it before
posting?!]
> A broken implementation will just skip over such an empty line,
> counting it as a line common to both preimage and postimage, and will
> still miscount the e-mail signature separator "-- \n" as a line
> removed from the preimage.
Emacs doesn't do it when empty line is present, -- it considers empty
line as hunk delimiter (along with any line that doesn't start with ' ',
'+', '-', or '!'). BTW, it counts lines starting with either '#' or '\'
as comments, i.e., just ignores them when counting the number of lines
in the hunk.
> If we wanted to have a workaround to this issue, we could simply
> remove these last two lines, and that would a be much better one
> than an extra blank line.
Why? I think it's nice idea to put git version as signature, and I see
no reason to remove it.
Besides, if empty line is put there before the signature, it'd be more
readable for human beings as well, as humans seem to prefer to put empty
line before their signature anyway.
--
Sergei.
^ permalink raw reply
* Re: [PATCH v2] builtin-commit: Include the diff in the commit message when verbose.
From: Kristian Høgsberg @ 2007-11-26 15:21 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Johannes Schindelin, git
In-Reply-To: <7vzlx63xey.fsf@gitster.siamese.dyndns.org>
On Thu, 2007-11-22 at 11:14 -0800, Junio C Hamano wrote:
> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
>
> > On Wed, 21 Nov 2007, Kristian Høgsberg wrote:
> >
> >> +
> >> + /* Truncate the message just before the diff, if any. */
> >> + p = strstr(sb.buf, "\ndiff --git a/");
> >> + if (p != NULL)
> >> + strbuf_setlen(&sb, p - sb.buf);
> >> +
> >
> > Is this related to the change in wt_status? If so, wouldn't we want to
> > suppress the diff, instead of generating it, and then killing it later?
>
> This corresponds to the sed script near l.545 in git-commit.sh.
>
> I've been wondering if it would be better not to have this logic
> but instead "git commit -v" to show the diff text prefixed with
> '# ' to make it a proper comment, by the way.
Yeah, that would be nicer... I think the best way to do this is to do a
formatting callback for the diff machinery as Jeff suggests, which can
then prefix '# ' and write it to a FILE *.
> > Besides, you'd want to leave the \n there: strbuf_setlen(&sb, p + 1 -
> > sb.buf);
>
> Yup.
Right, off-by-one. Effectively it doesn't make a difference, since
there will always be a comment line above the diff, When stripspace
removes the comments it fixes up the end-of-line problem. Patch below.
cheers,
Kristian
>From 58eac54a00d3eb6a311c6fb4faa67eb831c60e01 Mon Sep 17 00:00:00 2001
From: =?utf-8?q?Kristian=20H=C3=B8gsberg?= <krh@redhat.com>
Date: Mon, 26 Nov 2007 10:16:08 -0500
Subject: [PATCH] Fix off-by-one error when truncating the diff out of the commit message.
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 8bit
Signed-off-by: Kristian Høgsberg <krh@redhat.com>
---
builtin-commit.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/builtin-commit.c b/builtin-commit.c
index 45e51b1..330f778 100644
--- a/builtin-commit.c
+++ b/builtin-commit.c
@@ -762,7 +762,7 @@ int cmd_commit(int argc, const char **argv, const char *prefix)
/* Truncate the message just before the diff, if any. */
p = strstr(sb.buf, "\ndiff --git a/");
if (p != NULL)
- strbuf_setlen(&sb, p - sb.buf);
+ strbuf_setlen(&sb, p - sb.buf + 1);
stripspace(&sb, 1);
if (sb.len < header_len || message_is_empty(&sb, header_len)) {
--
1.5.3.4.206.g58ba4
^ permalink raw reply related
* Re: If you would write git from scratch now, what would you change?
From: Carlos Rica @ 2007-11-26 15:32 UTC (permalink / raw)
To: Adam Roben
Cc: Junio C Hamano, Steven Walter, Pierre Habouzit, Jakub Narebski,
git
In-Reply-To: <474A698A.70100@apple.com>
On Nov 26, 2007 7:36 AM, Adam Roben <aroben@apple.com> wrote:
> Junio C Hamano wrote:
> > Steven Walter <stevenrwalter@gmail.com> writes:
> > Let's clear the confusion. Although it is not bad like the above
> > "random 5 different operations", checkout does serve 2 quite different
> > purposes:
> >
> > (1) checkout a revision.
> > (2) checkout selected paths out of a commit (or the index).
> >
>
> Given the above, I'd argue that it serves 3 purposes:
>
> (1) check out a revision
> (2) check out selected paths out of a commit (or the index)
> (3) start working on a new branch
>
> It's true that (1) and (3) are very closely related, but I think in the
> minds of many git users (particularly new ones) they are distinct.
I think this is mostly due to the idea of a branch as a separated box
(like a directory) instead of a line of development like the notion which
comes from thinking in a branch as the place where HEAD is pointing to.
Personally, it is always difficult for me to understand git as a whole,
because I'm not sure what is the common use case for each command in
the most-usual-way-of-doing-the-things when using git, despite of having
long and complete documentation for each individual command. The question
is if we can give the power of git to their users in the same way they think,
or how git could be able to teach their users to think in the way it works.
An idea would be to study (and document) the most successful
use cases that git supports and check if it is already providing
unique and/or clear commands for them.
--Carlos
^ permalink raw reply
* Re: [PATCH] Make builtin-commit.c export GIT_INDEX_FILE for launch_editor as well.
From: Kristian Høgsberg @ 2007-11-26 15:27 UTC (permalink / raw)
To: Pierre Habouzit; +Cc: Jan Hudec, Git ML, Junio C Hamano
In-Reply-To: <20071126085927.GC23373@artemis.corp>
On Mon, 2007-11-26 at 09:59 +0100, Pierre Habouzit wrote:
> Signed-off-by: Pierre Habouzit <madcoder@debian.org>
> ---
>
> And here's the fix for this tiny problem …
That looks good to me.
Signed-off-by: Kristian Høgsberg <krh@redhat.com>
>
>
> builtin-commit.c | 9 ++++++---
> builtin-tag.c | 6 +++---
> strbuf.h | 2 +-
> 3 files changed, 10 insertions(+), 7 deletions(-)
>
> diff --git a/builtin-commit.c b/builtin-commit.c
> index 5d27102..6e6b9f2 100644
> --- a/builtin-commit.c
> +++ b/builtin-commit.c
> @@ -748,9 +748,12 @@ int cmd_commit(int argc, const char **argv, const char *prefix)
>
> /* Get the commit message and validate it */
> header_len = sb.len;
> - if (!no_edit)
> - launch_editor(git_path(commit_editmsg), &sb);
> - else if (strbuf_read_file(&sb, git_path(commit_editmsg), 0) < 0) {
> + if (!no_edit) {
> + char index[PATH_MAX];
> + const char *env[2] = { index, NULL };
> + snprintf(index, sizeof(index), "GIT_INDEX_FILE=%s", index_file);
> + launch_editor(git_path(commit_editmsg), &sb, env);
> + } else if (strbuf_read_file(&sb, git_path(commit_editmsg), 0) < 0) {
> rollback_index_files();
> die("could not read commit message\n");
> }
> diff --git a/builtin-tag.c b/builtin-tag.c
> index e89b201..8cc7f9c 100644
> --- a/builtin-tag.c
> +++ b/builtin-tag.c
> @@ -23,7 +23,7 @@ static const char * const git_tag_usage[] = {
>
> static char signingkey[1000];
>
> -void launch_editor(const char *path, struct strbuf *buffer)
> +void launch_editor(const char *path, struct strbuf *buffer, const char *const *env)
> {
> const char *editor, *terminal;
>
> @@ -49,7 +49,7 @@ void launch_editor(const char *path, struct strbuf *buffer)
> if (strcmp(editor, ":")) {
> const char *args[] = { editor, path, NULL };
>
> - if (run_command_v_opt(args, 0))
> + if (run_command_v_opt_cd_env(args, 0, NULL, env))
> die("There was a problem with the editor %s.", editor);
> }
>
> @@ -318,7 +318,7 @@ static void create_tag(const unsigned char *object, const char *tag,
> write_or_die(fd, tag_template, strlen(tag_template));
> close(fd);
>
> - launch_editor(path, buf);
> + launch_editor(path, buf, NULL);
>
> unlink(path);
> free(path);
> diff --git a/strbuf.h b/strbuf.h
> index 8334a9b..36d61db 100644
> --- a/strbuf.h
> +++ b/strbuf.h
> @@ -117,6 +117,6 @@ extern int strbuf_read_file(struct strbuf *sb, const char *path, size_t hint);
> extern int strbuf_getline(struct strbuf *, FILE *, int);
>
> extern void stripspace(struct strbuf *buf, int skip_comments);
> -extern void launch_editor(const char *path, struct strbuf *buffer);
> +extern void launch_editor(const char *path, struct strbuf *buffer, const char *const *env);
>
> #endif /* STRBUF_H */
^ permalink raw reply
* Re: If you would write git from scratch now, what would you change?
From: Daniel Barkalow @ 2007-11-26 16:40 UTC (permalink / raw)
To: Carlos Rica
Cc: Adam Roben, Junio C Hamano, Steven Walter, Pierre Habouzit,
Jakub Narebski, git
In-Reply-To: <1b46aba20711260732v297c5c35kbd007b9f13f351ff@mail.gmail.com>
On Mon, 26 Nov 2007, Carlos Rica wrote:
> On Nov 26, 2007 7:36 AM, Adam Roben <aroben@apple.com> wrote:
> > Junio C Hamano wrote:
> > > Steven Walter <stevenrwalter@gmail.com> writes:
> > > Let's clear the confusion. Although it is not bad like the above
> > > "random 5 different operations", checkout does serve 2 quite different
> > > purposes:
> > >
> > > (1) checkout a revision.
> > > (2) checkout selected paths out of a commit (or the index).
> > >
> >
> > Given the above, I'd argue that it serves 3 purposes:
> >
> > (1) check out a revision
> > (2) check out selected paths out of a commit (or the index)
> > (3) start working on a new branch
> >
> > It's true that (1) and (3) are very closely related, but I think in the
> > minds of many git users (particularly new ones) they are distinct.
>
> I think this is mostly due to the idea of a branch as a separated box
> (like a directory) instead of a line of development like the notion which
> comes from thinking in a branch as the place where HEAD is pointing to.
>
> Personally, it is always difficult for me to understand git as a whole,
> because I'm not sure what is the common use case for each command in
> the most-usual-way-of-doing-the-things when using git, despite of having
> long and complete documentation for each individual command. The question
> is if we can give the power of git to their users in the same way they think,
> or how git could be able to teach their users to think in the way it works.
>
> An idea would be to study (and document) the most successful
> use cases that git supports and check if it is already providing
> unique and/or clear commands for them.
I think that part of git's oddity comes from the fact that the UI is
organized around use cases rather than commands. That is, for each thing
that people commonly do, the sequence of commands is as short as possible
and each of the names makes sense in the context of this sequence. But
then the commands and options, in the list of commands and options outside
of the context of a use case, don't make any sense as a whole.
It's like trying to document the "take" command in a text adventure, where
"take [noun]" means to pick it up, "take off [noun]" means to remove it as
clothing, and "take off" means to leave.
There's a set of primitive git operations, but the git commands aren't
those; the git command schemas (not just the "command" part, but the type
of arguments following it) are semi-natural-language interfaces to
collections of primitive operations, and are set up to have a core "what
the user is saying to do" and all of the reasonable analogous extensions
to that. This means that the very same result can often be reached with
multiple entirely different commands, because there are different ways of
conceptualizing what you're doing that overlap. (E.g., "git checkout HEAD
." will check out the current directory from the current branch,
discarding local changes; "git reset --hard HEAD" will move the current
branch to its current state, bringing the working copy in line with it as
well; both of these have the effect of discarding all local changes while
keeping the branch state the same, but that's just because the aspects of
the two operations which are different don't matter with those particular
arguments)
I think git's UI design is, by and large, very good, but I'm not sure how
to document it so as to make it easy to learn, aside from giving a quick
explanation of how to use reflogs to recover from mistakes and telling
users to just try stuff in their local repository.
-Daniel
*This .sig left intentionally blank*
^ permalink raw reply
* Re: If you would write git from scratch now, what would you change?
From: Andy Parkins @ 2007-11-26 16:46 UTC (permalink / raw)
To: git
In-Reply-To: <200711252248.27904.jnareb@gmail.com>
Jakub Narebski wrote:
> If you would write git from scratch now, from the beginning, without
> concerns for backwards compatibility, what would you change, or what
> would you want to have changed?
Erm... (it's much harder to come with lists like these lately :-))
- "index", "cached" and "stage" are a definite source of confusion
- "git add" and "git rm" would be nicer as "git stage" and "git unstage"
(or something similar)
- libgit would have come first
- "git revert" should be called "git invert"
- "git revert" would (maybe) be "git reset"
- "git clone" wouldn't exist
- "git-gui" would be written in Qt (ducks)
- git-apply et al wouldn't be a disaster when the log message contains a
diff (change to git diff format?)
- empty directories in the repository (ducks again)
Andy
--
Dr Andy Parkins, M Eng (hons), MIET
andyparkins@gmail.com
^ permalink raw reply
* Re: [WIP PATCH] Add 'git fast-export', the sister of 'git fast-import'
From: Johannes Schindelin @ 2007-11-26 16:47 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: hanwen, git
In-Reply-To: <20071123205958.GC14735@spearce.org>
Hi,
On Fri, 23 Nov 2007, Shawn O. Pearce wrote:
> Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
> > On Thu, 22 Nov 2007, Han-Wen Nienhuys wrote:
> >
> > > > Maybe you want to specify if all blobs should be output first, and
> > > > then the commits? Or files should be used? But all of these things
> > > > seem to be useless to me.
> > >
> > > No, I want the program to wait for me to tell it what
> > > blobs/commits/trees I want. The commit I want to see secondly may depend
> > > on the output I read in the first request blob. Right now, for each data
> > > dependency I have to start a new git process.
> >
> > It does not seem like you want a mirror of fast-import, but rather a
> > driver. You might be happy to hear that you can do that already. Today.
> > However, you probably want to query different programs about certain
> > states of the repository. This will not change.
> >
> > > > > Besides being a nuisance, I actually run git on NFS, and every git
> > > > > process has to go to NFS a couple times to retrieve the same
> > > > > information. This has a noticeable performance impact.
>
> I have been considering creating a "git-gui daemon" process that links
> to libgit.a and can be driven bidirectionally through its stdin/stdout.
> Based on git-fast-export, sorta. But I haven't even started it...
>
> But the idea is sort of what Han-Wen wants. Why should I fork rev-parse
> to get a ref value? Or update-ref to change one?
I was thinking about this a little bit more. But I cannot think of a
really versatile way of enhancing fast-export enough to be of use there.
Well, if not doing something with SWIG, that is ;-)
Ciao,
Dscho
^ permalink raw reply
* Re: [WIP PATCH] Add 'git fast-export', the sister of 'git fast-import'
From: Johannes Schindelin @ 2007-11-26 16:48 UTC (permalink / raw)
To: Karl Hasselström; +Cc: Shawn O. Pearce, hanwen, git
In-Reply-To: <20071125170019.GB25800@diana.vm.bytemark.co.uk>
Hi,
On Sun, 25 Nov 2007, Karl Hasselstr?m wrote:
> On 2007-11-23 15:59:58 -0500, Shawn O. Pearce wrote:
>
> > I have been considering creating a "git-gui daemon" process that links
> > to libgit.a and can be driven bidirectionally through its
> > stdin/stdout. Based on git-fast-export, sorta. But I haven't even
> > started it...
> >
> > But the idea is sort of what Han-Wen wants. Why should I fork
> > rev-parse to get a ref value? Or update-ref to change one?
>
> Obviously, something like this would be very valuable for StGit as well.
Could you be a little more specific _what_ you want to do, and _how_ this
could be done with fast-export | fast-import?
Ciao,
Dscho
^ permalink raw reply
* Re: If you would write git from scratch now, what would you change?
From: Jon Smirl @ 2007-11-26 16:48 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git
In-Reply-To: <200711252248.27904.jnareb@gmail.com>
On 11/25/07, Jakub Narebski <jnareb@gmail.com> wrote:
> If you would write git from scratch now, from the beginning, without
> concerns for backwards compatibility, what would you change, or what
> would you want to have changed?
I would sit down and carefully design the command syntax. git's
biggest criticism is that it is hard to use and this is mainly caused
by the seemingly very complex commands. Much of this complexity could
be hidden from the user.
I'd also integrated a patch management system like stgit. I'm using
stgit commands for 90% of my tasks and it has a different syntax than
git (its trying to fix some of the problems).
Most current git users are knowledgeable programmers and could handle
a rework of the git command syntax. The sooner the syntax is reworked
the better in my opinion. The current syntax grew organically as we
learned what git needed. Now's the time to use this knowledge and
design an optimal command structure.
--
Jon Smirl
jonsmirl@gmail.com
^ permalink raw reply
* Re: [PATCH] Don't add To: recipients to the Cc: header
From: Junio C Hamano @ 2007-11-26 16:53 UTC (permalink / raw)
To: Sergei Organov; +Cc: Ask Bjørn Hansen, git
In-Reply-To: <87wss5p177.fsf@osv.gnss.ru>
Sergei Organov <osv@javad.com> writes:
>> GNU folks even managed to insert text that allows a completely empty
>> line (not a line with a single SP on it) to express a context line
>> that is empty, which means...
>
> Really? That's a surprise for me. What I can tell for sure, Emacs' diff
> mode doesn't support this, as it does interpret plain empty line as a
> hunk delimiter, at least in Emacs 22.1.
See b507b465f7831612b9d9fc643e3e5218b64e5bfa (git-apply: prepare for
upcoming GNU diff -u format change). Around the time that eventually
lead to this commit (mid October 2006) there was a discussion on this
mailing list on the issue, too. I do not doubt you checked with your
version of Emacs diff mode that it does not support this yet, but it's
only prudent to assume that a new version someday will.
^ permalink raw reply
* Re: If you would write git from scratch now, what would you change?
From: Benoit Sigoure @ 2007-11-26 17:10 UTC (permalink / raw)
To: Andy Parkins; +Cc: git
In-Reply-To: <fiet88$68n$1@ger.gmane.org>
On Nov 26, 2007, at 5:46 PM, Andy Parkins wrote:
> - libgit would have come first
I warmly second that.
> - "git revert" should be called "git invert"
> - "git revert" would (maybe) be "git reset"
But here, I have to disagree. Why would you want to call "git-
revert" "git-reset"?
I know it's annoying that commands with the same name do different
things in SVN/CVS but I don't think it's a reason to necessarily
adapt to them. There are plenty of misnomers already anyway
(checkout, commit, add).
While we're discussing bad names, as someone already pointed out, I
agree it's sad that "git push" is almost always understood as being
the opposite of "git pull".
--
Benoit Sigoure aka Tsuna
EPITA Research and Development Laboratory
^ permalink raw reply
* Re: If you would write git from scratch now, what would you change?
From: David Kastrup @ 2007-11-26 17:11 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git
In-Reply-To: <200711252248.27904.jnareb@gmail.com>
Jakub Narebski <jnareb@gmail.com> writes:
> If you would write git from scratch now, from the beginning, without
> concerns for backwards compatibility, what would you change, or what
> would you want to have changed?
Get rid of plumbing at the command line level. It is confusing to
users, and command line arguments, exec calls and I/O streams are not
efficient and reasonably typed mechanisms for the kind of operations
done in plumbing. Instead using a good extensible portable scripting
language (I consider Lua quite suitable in that regard, but it is
conceivable that something with a native list type supporting easy
sorts, merges and selections could be more efficient) and implementing
plumbing in that or in C would have been preferable for creating the
porcelain.
That would keep plumbing out of the hair of users and make it easier to
cobble together extensions and variations with non-trivial internal
dataflow.
Shell scripts have also proven to be a constant hassle with regard to
portability and bugs (like underquoting).
--
David Kastrup, Kriemhildstr. 15, 44793 Bochum
^ permalink raw reply
* Re: Rebase/cherry-picking idea
From: Junio C Hamano @ 2007-11-26 17:26 UTC (permalink / raw)
To: Johannes Sixt; +Cc: Wincent Colaiuta, Benoit Sigoure, Git Mailing List
In-Reply-To: <474AC136.8060906@viscovery.net>
Johannes Sixt <j.sixt@viscovery.net> writes:
> Introduce an environment variable _GIT_CHERRY_PICK_HELP (note the
> leading underscore), which git-rebase sets; if it's set,
> git-cherry-pick uses that text instead of the usual one.
With precedences like GIT_REFLOG_ACTION and GITHEAD_${objectname}, I
think it would be consistent without the leading underscore.
I would not object to renaming all of them to have the leading
underscore, though. That would make it clear that they are very
different from ordinary environment variables for the user to set
(e.g. GIT_INDEX_FILE, GIT_AUTHOR_NAME). Does any third party tool like
qgit already use GITHEAD_${objectname} and/or GIT_REFLOG_ACTION?
^ permalink raw reply
* Re: [PATCH] Add 'git fast-export', the sister of 'git fast-import'
From: Junio C Hamano @ 2007-11-26 17:55 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git
In-Reply-To: <Pine.LNX.4.64.0711261236280.27959@racer.site>
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> On Sun, 25 Nov 2007, Junio C Hamano wrote:
>
>> I am not sure if abort should be the default.
>
> I tried to be conservative.
>
>> If a straight dump-restore is made without rewriting, the result will be
>> identical to the original, right?
>
> Yep.
> ...
> I agree that for most serious operations sed is not good enough.
My comment was more about the perception from a new user (not a "new git
user", but a "new fast-export and fast-import user").
When you see a command pair foo-export and foo-import, and it is
advertised that you can pipe them together, a new user would first try a
straight dump-restore, and would see the warning even though he did not
do any editing on the stream.
Huh? Why does a tag signature become invalid because of merely
exporting and then importing? What is this warning about?
You would explain "yeah in your trial run you did not edit but the
command pair is to allow you editing the contents in between, and if you
do that, the object names might change.".
If the default were "straight copy", then the user will not get an
invalid signature on his trial run, but will get an invalid signature
when he rewrites the object stream. You would get a message on the list
like this:
Hello, I tried fast-export piped to fast-import so that I can
rewrite my repository, but I am getting invalid signature on
signed tags. It does not seem to happen if I do not edit but
just use the fast-export output without modification. What am I
doing wrong?
And that is the time the explanation first becomes useful. IOW, you are
warning at the wrong place. "It may or may not corrupt the signature, I
do not know. Because it depends on what you are going to do with my
output, I cannot know. I am warning you anyway to cover my backside".
I am wondering if fast-import input syntax can be extended to allow
checking inconsistencies. A command to import a tag could take an
additional object name and tell it to warn if the name of the tagged
object (the one sent with "from:%d\n" part) is different from that
object name. At that point, you know the object was rewritten and the
signature is invalid, and the choice of warning, stripping or aborting
becomes a useful thing to have.
^ permalink raw reply
* Re: [PATCH] Don't add To: recipients to the Cc: header
From: Sergei Organov @ 2007-11-26 18:29 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Ask Bjørn Hansen, git
In-Reply-To: <7v3autgd8q.fsf@gitster.siamese.dyndns.org>
Junio C Hamano <gitster@pobox.com> writes:
> Sergei Organov <osv@javad.com> writes:
>
>>> GNU folks even managed to insert text that allows a completely empty
>>> line (not a line with a single SP on it) to express a context line
>>> that is empty, which means...
>>
>> Really? That's a surprise for me. What I can tell for sure, Emacs' diff
>> mode doesn't support this, as it does interpret plain empty line as a
>> hunk delimiter, at least in Emacs 22.1.
>
> See b507b465f7831612b9d9fc643e3e5218b64e5bfa (git-apply: prepare for
> upcoming GNU diff -u format change). Around the time that eventually
> lead to this commit (mid October 2006) there was a discussion on this
> mailing list on the issue, too. I do not doubt you checked with your
> version of Emacs diff mode that it does not support this yet, but it's
> only prudent to assume that a new version someday will.
Thanks, -- it was interesting to read corresponding discussions.
Due to this change in GNU diff, it seems that empty line is indeed a
wrong choice for syntactic hunk separator :( I wonder if there is a
common way to say "here the patch ends" then[1]? My best guess is that
===
will do.
[1] I've checked bzr and hg. Bzr uses empty line for that (followed by
"# Begin bundle" line) in their "merge directive" format. Not
Emacs-friendly either :( Hg's "export" just EOFs after the patch.
--
Sergei.
^ permalink raw reply
* Re: If you would write git from scratch now, what would you change?
From: Jan Hudec @ 2007-11-26 18:56 UTC (permalink / raw)
To: Benoit Sigoure; +Cc: Andy Parkins, git
In-Reply-To: <2A34D324-48A4-49EF-9D4E-5B9469A0791D@lrde.epita.fr>
[-- Attachment #1: Type: text/plain, Size: 534 bytes --]
On Mon, Nov 26, 2007 at 18:10:10 +0100, Benoit Sigoure wrote:
> On Nov 26, 2007, at 5:46 PM, Andy Parkins wrote:
> While we're discussing bad names, as someone already pointed out, I agree
> it's sad that "git push" is almost always understood as being the opposite
> of "git pull".
Well, it is an oposite of pull. Compared to it, it is limited in that it will
not do a merge and on the other hand extended to *also* be an oposite of
fetch, but still oposite of pull is push.
--
Jan 'Bulb' Hudec <bulb@ucw.cz>
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: What's cooking in git.git (topics)
From: Nicolas Pitre @ 2007-11-26 19:11 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git
In-Reply-To: <fie23u$5tc$1@ger.gmane.org>
[ I get really really annoyed when your replies to me aren't directly
addressed to me, Jakub. Told you so repeatedly in the past as well.
Why are you the only one on this list apparently not able to use a
proper email setup? ]
On Mon, 26 Nov 2007, Jakub Narebski wrote:
> Nicolas Pitre wrote:
>
> > Some stuff gets rebased because it has to be refined before it is
> > merged in a more stable and more "official" repository. Working on
> > top of a rebased branch could be much easier if there was a
> > dedicated command to perform the local rebase of one's work after a
> > fetch, just like the pull command does a merge after a fetch, at
> > which point both work flows would be almost equivalent wrt ease of
> > use.
>
> There was idea of 'rebase' merge strategy (which was in some form
> implemented once under another name: check archives if you want).
> And there is an idea of --rebase switch git git-pull.
>
> What is left is the implementation ;-)
I thought that had been implemented already. But in fact I had forgot
about it altogether.
It shouldn't be much complicated than:
git fetch ${remote} && \
git rebase --onto ${remote} ${remote}"@{1}" ${local}
given that ${remote} did actually change during the fetch.
Nicolas
^ permalink raw reply
* Re: Rebase/cherry-picking idea
From: Marco Costalba @ 2007-11-26 19:12 UTC (permalink / raw)
To: Junio C Hamano
Cc: Johannes Sixt, Wincent Colaiuta, Benoit Sigoure, Git Mailing List
In-Reply-To: <7vy7ckgbpf.fsf@gitster.siamese.dyndns.org>
On Nov 26, 2007 6:26 PM, Junio C Hamano <gitster@pobox.com> wrote:
> (e.g. GIT_INDEX_FILE, GIT_AUTHOR_NAME). Does any third party tool like
> qgit already use GITHEAD_${objectname} and/or GIT_REFLOG_ACTION?
>
No, it doesn't.
Thanks for asking ;-)
Marco
^ 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