* 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
* Re: If you would write git from scratch now, what would you change?
From: David Kastrup @ 2007-11-26 19:12 UTC (permalink / raw)
To: Jan Hudec; +Cc: Benoit Sigoure, Andy Parkins, git
In-Reply-To: <20071126185600.GA25784@efreet.light.src>
Jan Hudec <bulb@ucw.cz> writes:
> 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.
With the same reasoning the opposite of a duck is a lobster, since a
lobster has not only fewer wings, but also more legs.
--
David Kastrup, Kriemhildstr. 15, 44793 Bochum
^ permalink raw reply
* Re: If you would write git from scratch now, what would you change?
From: Dana How @ 2007-11-26 19:18 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git, danahow
In-Reply-To: <200711252248.27904.jnareb@gmail.com>
On Nov 25, 2007 1:48 PM, 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?
Currently data can be quickly copied from pack to pack,
but data cannot be quickly copied blob->pack or pack->blob
(there was an alternate blob format that supported this,
but it was deprecated). Using the pack format for blobs
would fix this. It would also mean blobs wouldn't need to
be uncompressed to get the blob type or size I believe.
So far this has prevented me from deploying git here
(and is half the reason I have not been active recently).
Currently we use p4 and we have large files.
When a large file is checked in (submitted),
it is compressed *once* and sent over the network --
these are the only delays that end-users experience.
The equivalent operation in git would require the creation of
the blob, and then of a temporary pack to send to the server.
This requires 3 calls to zlib for each blob, which for very
large files is not acceptable at my site.
Yes, git has much better features.
But 80%+ of my workgroup will not use them,
and only notice that git is "slower".
Thanks,
--
Dana L. How danahow@gmail.com +1 650 804 5991 cell
^ permalink raw reply
* Re: What's cooking in git.git (topics)
From: David Kastrup @ 2007-11-26 19:24 UTC (permalink / raw)
To: Nicolas Pitre; +Cc: Jakub Narebski, git
In-Reply-To: <alpine.LFD.0.99999.0711261358410.9605@xanadu.home>
Nicolas Pitre <nico@cam.org> writes:
> [ 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? ]
X-Injected-Via-Gmane: http://gmane.org/
And Jakub by far is not the only one using gmane for reading and writing
to the list.
I am reading and writing on a number of mailing lists with either
explicit or implicit gateways to news servers. But the git mailing list
is the only one where I ever encountered a semi-permanent stream of
(sometimes quite rude) complaints because people insist on getting
replies at least twice: once by the mailing list, and once by personal
Email. In contrast to claims made here, it is _not_ common netiquette
to create extra personal copies. In fact, for articles sent through
Usenet servers, it is generally considered an _annoyance_ to include
unannounced "courtesy copies" since replies to them will not usually
reach the list and will require redoing.
And I have received complaints about accumulating Cc lists from mailing
list moderators as well, since list servers tend to queue stuff for
moderation once the Cc header reaches a certain size.
I really don't get the point of those demands for personal extra copies:
do people or don't they read the mailing list?
On the current computer setup, I am answering to the list. On a
different computer, all mail to the mailing list disappears into a black
hole without any indication why. So I _have_ to use gmane there. And I
don't see why I should get heat for that when apparently the
automoderation of the list is set up as rabidly as to quietly censor
everything I send via Email (everybody else is able to receive mail
through that account from me).
--
David Kastrup, Kriemhildstr. 15, 44793 Bochum
^ permalink raw reply
* Re: If you would write git from scratch now, what would you change?
From: Marco Costalba @ 2007-11-26 19:25 UTC (permalink / raw)
To: Andy Parkins; +Cc: git
In-Reply-To: <fiet88$68n$1@ger.gmane.org>
On Nov 26, 2007 5:46 PM, Andy Parkins <andyparkins@gmail.com> wrote:
> 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 :-))
>
> - "git-gui" would be written in Qt (ducks)
But...wait...Qt would require...(I'm scared to say!)... that awful,
painful, hopeless thing called C++. Probably you didn't mean what you
said ;-)
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