* [PATCH] replace reference to git-rm with git-reset in git-commit doc
From: Jing Xue @ 2007-11-12 0:38 UTC (permalink / raw)
To: git
In-Reply-To: <20071111140518.GA3847@efreet.light.src>
On Sun, Nov 11, 2007 at 03:05:18PM +0100, Jan Hudec wrote:
>
> The message in git-commit suggesting to use 'git rm --cached' to unstage is
> just plain wrong. It really should mention 'git reset'.
Hopefully this makes it clearer. I have also updated the faq in wiki to
clarify.
Signed-off-by: Jing Xue <jingxue@digizenstudio.com>
---
Documentation/git-add.txt | 1 +
Documentation/git-commit.txt | 12 ++++++------
2 files changed, 7 insertions(+), 6 deletions(-)
diff --git a/Documentation/git-add.txt b/Documentation/git-add.txt
index 963e1ab..63829d9 100644
--- a/Documentation/git-add.txt
+++ b/Documentation/git-add.txt
@@ -224,6 +224,7 @@ See Also
--------
gitlink:git-status[1]
gitlink:git-rm[1]
+gitlink:git-reset[1]
gitlink:git-mv[1]
gitlink:git-commit[1]
gitlink:git-update-index[1]
diff --git a/Documentation/git-commit.txt b/Documentation/git-commit.txt
index e54fb12..7c63dd8 100644
--- a/Documentation/git-commit.txt
+++ b/Documentation/git-commit.txt
@@ -154,12 +154,12 @@ EXAMPLES
--------
When recording your own work, the contents of modified files in
your working tree are temporarily stored to a staging area
-called the "index" with gitlink:git-add[1]. Removal
-of a file is staged with gitlink:git-rm[1]. After building the
-state to be committed incrementally with these commands, `git
-commit` (without any pathname parameter) is used to record what
-has been staged so far. This is the most basic form of the
-command. An example:
+called the "index" with gitlink:git-add[1]. File changes
+previously staged can be removed with `git-reset
+HEAD -- <file>`. After building the state to be committed
+incrementally with these commands, `git commit` (without any
+pathname parameter) is used to record what has been staged so
+far. This is the most basic form of the command. An example:
------------
$ edit hello.c
^ permalink raw reply related
* Is it possible for git to remember the options preference for "git log"?
From: eric miao @ 2007-11-12 0:33 UTC (permalink / raw)
To: git
All,
Most of the time I'm using git-log for inspecting a brief history
and insert/remove/modify commits between, which I have to
type "git log --abbrev-commit --pretty=oneline" every time. Is
it possible for git to remember this command line options
preference?
And no, I don't really want to use shell's alias or something
else, I was just used to type "git xxx" :-)
--
Cheers
- eric
^ permalink raw reply
* Re: [PATCH] Documentation: Fix references to deprecated commands
From: Jonas Fonseca @ 2007-11-12 0:32 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Andreas Ericsson, Johannes Schindelin, git
In-Reply-To: <20071112002410.GA21970@diku.dk>
Subject: [PATCH] Documentation: Fix references to deprecated commands
... by changing git-tar-tree reference to git-archive and removing
seemingly unrelevant footnote about git-ssh-{fetch,upload}.
Signed-off-by: Jonas Fonseca <fonseca@diku.dk>
---
Documentation/core-tutorial.txt | 5 -----
Documentation/git-get-tar-commit-id.txt | 4 ++--
2 files changed, 2 insertions(+), 7 deletions(-)
Now with SOB and ...
Jonas Fonseca <fonseca@diku.dk> wrote Mon, Nov 12, 2007:
> diff --git a/Documentation/git-get-tar-commit-id.txt b/Documentation/git-get-tar-commit-id.txt
> index 9b5f86f..ef1b19c 100644
> --- a/Documentation/git-get-tar-commit-id.txt
> +++ b/Documentation/git-get-tar-commit-id.txt
> @@ -14,12 +14,12 @@ SYNOPSIS
> return code of 1. This can happen if <tarfile> had not been created
> -using git-tar-tree or if the first parameter of git-tar-tree had been
> +using git-archive or if the first parameter of git-tar-tree had been
> a tree ID instead of a commit ID or tag.
... s//g
diff --git a/Documentation/core-tutorial.txt b/Documentation/core-tutorial.txt
index ebd2492..401d1de 100644
--- a/Documentation/core-tutorial.txt
+++ b/Documentation/core-tutorial.txt
@@ -1090,11 +1090,6 @@ server like git Native transport does. Any stock HTTP server
that does not even support directory index would suffice. But
you must prepare your repository with `git-update-server-info`
to help dumb transport downloaders.
-+
-There are (confusingly enough) `git-ssh-fetch` and `git-ssh-upload`
-programs, which are 'commit walkers'; they outlived their
-usefulness when git Native and SSH transports were introduced,
-and are not used by `git pull` or `git push` scripts.
Once you fetch from the remote repository, you `merge` that
with your current branch.
diff --git a/Documentation/git-get-tar-commit-id.txt b/Documentation/git-get-tar-commit-id.txt
index 9b5f86f..ef1b19c 100644
--- a/Documentation/git-get-tar-commit-id.txt
+++ b/Documentation/git-get-tar-commit-id.txt
@@ -14,12 +14,12 @@ SYNOPSIS
DESCRIPTION
-----------
Acts as a filter, extracting the commit ID stored in archives created by
-git-tar-tree. It reads only the first 1024 bytes of input, thus its
+gitlink:git-archive[1]. It reads only the first 1024 bytes of input, thus its
runtime is not influenced by the size of <tarfile> very much.
If no commit ID is found, git-get-tar-commit-id quietly exists with a
return code of 1. This can happen if <tarfile> had not been created
-using git-tar-tree or if the first parameter of git-tar-tree had been
+using git-archive or if the <treeish> parameter of git-archive had been
a tree ID instead of a commit ID or tag.
--
Jonas Fonseca
^ permalink raw reply related
* [PATCH] Documentation: Fix references to deprecated commands
From: Jonas Fonseca @ 2007-11-12 0:24 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Andreas Ericsson, Johannes Schindelin, git
In-Reply-To: <7vy7d8xlej.fsf_-_@gitster.siamese.dyndns.org>
... by changing git-tar-tree reference to git-archive and removing
seemingly unrelevant footnote about git-ssh-{fetch,upload}.
---
Documentation/core-tutorial.txt | 5 -----
Documentation/git-get-tar-commit-id.txt | 4 ++--
2 files changed, 2 insertions(+), 7 deletions(-)
Maybe also fixing these references would be in order.
diff --git a/Documentation/core-tutorial.txt b/Documentation/core-tutorial.txt
index ebd2492..401d1de 100644
--- a/Documentation/core-tutorial.txt
+++ b/Documentation/core-tutorial.txt
@@ -1090,11 +1090,6 @@ server like git Native transport does. Any stock HTTP server
that does not even support directory index would suffice. But
you must prepare your repository with `git-update-server-info`
to help dumb transport downloaders.
-+
-There are (confusingly enough) `git-ssh-fetch` and `git-ssh-upload`
-programs, which are 'commit walkers'; they outlived their
-usefulness when git Native and SSH transports were introduced,
-and are not used by `git pull` or `git push` scripts.
Once you fetch from the remote repository, you `merge` that
with your current branch.
diff --git a/Documentation/git-get-tar-commit-id.txt b/Documentation/git-get-tar-commit-id.txt
index 9b5f86f..ef1b19c 100644
--- a/Documentation/git-get-tar-commit-id.txt
+++ b/Documentation/git-get-tar-commit-id.txt
@@ -14,12 +14,12 @@ SYNOPSIS
DESCRIPTION
-----------
Acts as a filter, extracting the commit ID stored in archives created by
-git-tar-tree. It reads only the first 1024 bytes of input, thus its
+gitlink:git-archive[1]. It reads only the first 1024 bytes of input, thus its
runtime is not influenced by the size of <tarfile> very much.
If no commit ID is found, git-get-tar-commit-id quietly exists with a
return code of 1. This can happen if <tarfile> had not been created
-using git-tar-tree or if the first parameter of git-tar-tree had been
+using git-archive or if the first parameter of git-tar-tree had been
a tree ID instead of a commit ID or tag.
--
Jonas Fonseca
^ permalink raw reply related
* Re: Deprecate git-fetch-pack?
From: Jakub Narebski @ 2007-11-12 0:16 UTC (permalink / raw)
To: git
In-Reply-To: <20071111235819.GB7392@thunk.org>
Theodore Tso wrote:
> 2) The command which are displayed by "git help" should use some
> serious rethinking. Ideally, it would be nice if the output fit in a
> single 24-line terminal window. Some candidates for removal:
>
> a) prune: "git prune" definitely doesn't deserve to be on the
> front and center as displayed by "git help". Maybe replace it
> with "gc", but now that we have gc.auto, I'm not sure it's
> worth it at all.
I would replace it by "git gc" (you have to run 'git gc --prune' by hand
on quiescent repository), or remove it altogether.
> b) revert: Is that really that common of a command?
It is useful command, perhaps short description should be improved.
BTW. if we have cherry-pick, then we should have revert.
> c) show-branch: The output is terrifying without explanation
I agree. I would replace it by gitk, or gui (git-gui / "git gui").
> There are other commands I'm not so sure about, but it is worth
> flagging them. One way that might be helpful is to group the commands
> into subcommands, much like gdb does, so you could do something like
> "git help other-repos" (where all commands that involve interacting
> with other repositories are summarized), and so on.
I think that "git-rm" could be removed, because "rm <file>; git commit ..."
works just fine.
See also discussion about results of Git User's Survey 2007, somewhere
around
http://thread.gmane.org/gmane.comp.version-control.git/59935/focus=62205
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
^ permalink raw reply
* Re: Deprecate git-fetch-pack?
From: Theodore Tso @ 2007-11-11 23:58 UTC (permalink / raw)
To: Johannes Schindelin
Cc: Junio C Hamano, Ask Bjørn Hansen, Daniel Barkalow, git
In-Reply-To: <Pine.LNX.4.64.0711112247350.4362@racer.site>
On Sun, Nov 11, 2007 at 10:50:26PM +0000, Johannes Schindelin wrote:
> I beg to differ. The biggest problem with a new user seeing all those
> completions is that this user is scared.
Well, if we introduce the new user only to "git subcomand", and the
documentation is relatively gentle, I would suspect would solve most
of the problem. Note BTW, that if your thesis is true, "git help -a"
(which is recommended in the last line of output by "git help") should
cause the typical new user to faint dead away. :-)
Some other areas that would be worth fixing, in terms of user usability.
1) The references to the tutorial, everyday git, etc., don't actually
have working references in the git man page. (i.e., what you see when
you run the command "man git"). It would be nice if that were fixed.
2) The command which are displayed by "git help" should use some
serious rethinking. Ideally, it would be nice if the output fit in a
single 24-line terminal window. Some candidates for removal:
a) prune: "git prune" definitely doesn't deserve to be on the
front and center as displayed by "git help". Maybe replace it
with "gc", but now that we have gc.auto, I'm not sure it's
worth it at all.
b) revert: Is that really that common of a command?
c) show-branch: The output is terrifying without explanation
There are other commands I'm not so sure about, but it is worth
flagging them. One way that might be helpful is to group the commands
into subcommands, much like gdb does, so you could do something like
"git help other-repos" (where all commands that involve interacting
with other repositories are summarized), and so on.
> But yes, I was only proposing to deprecate all usage of git-<bla> in the
> documentation.
I agree that de-emphasizing git-<blah> isn't a bad thing. But I think
we need to look at the big picture here, since "git help" is often one
of the first things a new user might try (and obviously very few git
developers look at it, or "prune" probably would have been removed
from git help a long time ago :-), and the last thing that git help
suggests (and so therefore it will very visible to the newbie user),
is "git help -a" --- and that displays every single git command under
creation, porcelain or plumbing, in one gigantic sorted list.
Oops, so much for first impressions. :-)
- Ted
^ permalink raw reply
* [PATCH] Fix rev-list when showing objects involving submodules
From: Johannes Schindelin @ 2007-11-11 23:35 UTC (permalink / raw)
To: git, gitster
The function mark_tree_uninteresting() assumed that the tree entries
are blob when they are not trees. This is not so. Since we do
not traverse into submodules (yet), the gitlinks should be ignored.
Noticed by Ilari on IRC.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
---
revision.c | 2 +-
t/t6008-rev-list-submodule.sh | 42 +++++++++++++++++++++++++++++++++++++++++
2 files changed, 43 insertions(+), 1 deletions(-)
create mode 100755 t/t6008-rev-list-submodule.sh
diff --git a/revision.c b/revision.c
index 931f978..81b5a93 100644
--- a/revision.c
+++ b/revision.c
@@ -69,7 +69,7 @@ void mark_tree_uninteresting(struct tree *tree)
while (tree_entry(&desc, &entry)) {
if (S_ISDIR(entry.mode))
mark_tree_uninteresting(lookup_tree(entry.sha1));
- else
+ else if (!S_ISGITLINK(entry.mode))
mark_blob_uninteresting(lookup_blob(entry.sha1));
}
diff --git a/t/t6008-rev-list-submodule.sh b/t/t6008-rev-list-submodule.sh
new file mode 100755
index 0000000..88e96fb
--- /dev/null
+++ b/t/t6008-rev-list-submodule.sh
@@ -0,0 +1,42 @@
+#!/bin/sh
+#
+# Copyright (c) 2007 Johannes E. Schindelin
+#
+
+test_description='git rev-list involving submodules that this repo has'
+
+. ./test-lib.sh
+
+test_expect_success 'setup' '
+ : > file &&
+ git add file &&
+ test_tick &&
+ git commit -m initial &&
+ echo 1 > file &&
+ test_tick &&
+ git commit -m second file &&
+ echo 2 > file &&
+ test_tick &&
+ git commit -m third file &&
+
+ rm .git/index &&
+
+ : > super-file &&
+ git add super-file &&
+ git submodule add . sub &&
+ git symbolic-ref HEAD refs/heads/super &&
+ test_tick &&
+ git commit -m super-initial &&
+ echo 1 > super-file &&
+ test_tick &&
+ git commit -m super-first super-file &&
+ echo 2 > super-file &&
+ test_tick &&
+ git commit -m super-second super-file
+'
+
+test_expect_success "Ilari's test" '
+ git rev-list --objects super master ^super^
+'
+
+test_done
--
1.5.3.5.1695.g146d07
^ permalink raw reply related
* Re: [PATCH] Move stripspace() and launch_editor() to strbuf.c
From: Junio C Hamano @ 2007-11-11 22:52 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git
In-Reply-To: <Pine.LNX.4.64.0711112227420.4362@racer.site>
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> Maybe call_editor() instead of edit_buffer()? Since we technically read
> the file specified by "path" into the buffer "buffer", after having called
> the editor.
Calling $EDITOR to edit the buffer is an implementation detail
of letting the user edit the buffer. I think the function name
should express what it does more than how it does it.
My suggested name does not convey the "letting the user" part,
though.
^ permalink raw reply
* Re: Obscure commit message formatting issue
From: Daniel Barkalow @ 2007-11-11 22:50 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Junio C Hamano, git
In-Reply-To: <Pine.LNX.4.64.0711112240350.4362@racer.site>
On Sun, 11 Nov 2007, Johannes Schindelin wrote:
> Hi,
>
> On Sun, 11 Nov 2007, Daniel Barkalow wrote:
>
> > On Sun, 11 Nov 2007, Junio C Hamano wrote:
> >
> > > Daniel Barkalow <barkalow@iabervon.org> writes:
> > >
> > > > The current code drops extra blank lines between the first line of a
> > > > commit message (the summary line) and the remainder.
> > >
> > > The patch application side does even more. It not just strips
> > > off the leading or trailing blank lines, but duplicate blank
> > > lines in the middle and trailing whitespaces at the end of each
> > > line.
> > >
> > > I am of two minds about the formatting side.
> > >
> > > The behaviour you found does not go far enough to correct all of
> > > the above whitespace breakage the application side will fix up
> > > on the generation side -- it only corrects one of them. We
> > > might want to do more, instead of less that you seem to be
> > > implying to favor.
> >
> > What I'm actually doing is working on a cover letter implementation.
>
> Funny.
>
> I am in the middle of cleaning out my personal git branch that has a messy
> history, since I never rebased, but always merged. Now I decided to go
> with rebasing.
>
> And there I found an implementation of a cover letter. You might want to
> be interested ;-)
>
> http://repo.or.cz/w/git/dscho.git?a=shortlog;h=cover-letter
I actually started from the patch you sent me a while back, but using code
from pretty.c instead of generating the message directly. I'll have to
check whether you added anything since the patch I got.
-Daniel
*This .sig left intentionally blank*
^ permalink raw reply
* Re: Deprecate git-fetch-pack?
From: Johannes Schindelin @ 2007-11-11 22:50 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Theodore Tso, Ask Bjørn Hansen, Daniel Barkalow, git
In-Reply-To: <7vabpkbebj.fsf@gitster.siamese.dyndns.org>
Hi,
On Sun, 11 Nov 2007, Junio C Hamano wrote:
> Theodore Tso <tytso@mit.edu> writes:
>
> > On Sun, Nov 11, 2007 at 01:16:09PM -0800, Junio C Hamano wrote:
> >> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> >> > This should be a non-issue. We really should start deprecating
> >> > "git-<command>" in favour of "git <command>" for real.
> >> >
> >> > New users should not even be told that this is correct usage.
> >>
> >> If you can write "git-commit" and "git commit" interchangeably
> >> while you cannot say "git-cat-file" and are forced to say "git
> >> cat-file", I suspect that would lead to a great confusion and
> >> unhappy users.
> >
> > One of the reasons why I use git-diff and git-commit and in particular
> > "git-rebase --interactive master" very often is that it allows my
> > shell's bang completion to work. (i.e., "!git-rebase"). If we tell
> > people they can not use "git-rebase", and must instead use "git
> > rebase" instead, I would consider that pretty annoying/obnoxious.
>
> Oh, of course.
>
> But my impression was that Johannes was talking about
> deprecating git-<foo> form only for plumbing, so that the users
> will only see git-<foo> for the Porcelain. That would not break
> your bang completion for the porcelain commands.
>
> If Johannes was talking about deprecating all git-<foo> form,
> then that would indeed break your bang completion, but it has
> conceptually a much bigger problem. The topic was about fixing
> "a new user sees too many git commands and gets scared" problem.
> Deprecaing all git-<foo> form just replaces the problem with "a
> new user sees too many git subcommands and gets scared" problem,
> without solving anything.
I beg to differ. The biggest problem with a new user seeing all those
completions is that this user is scared.
Just taking away that first shock would be helping very much. I mean, we
_still_ have the reputation of being more complex than other SCMs, but I
do not think that this reputation is completely deserved.
However, reputations are formed by first time impressions. It is _hard_
to get rid of a bad first time impression.
But yes, I was only proposing to deprecate all usage of git-<bla> in the
documentation.
Maybe I'm wrong. Wouldn't be the first time.
Ciao,
Dscho
^ permalink raw reply
* Re: Local branch to remote branch translation
From: Jon Smirl @ 2007-11-11 22:46 UTC (permalink / raw)
To: Steffen Prohaska; +Cc: Git Mailing List
In-Reply-To: <A7871D5B-9E05-4F9B-92AC-B74ECF35460B@zib.de>
On 11/11/07, Steffen Prohaska <prohaska@zib.de> wrote:
>
> On Nov 11, 2007, at 10:20 PM, Jon Smirl wrote:
>
> > On 11/11/07, Steffen Prohaska <prohaska@zib.de> wrote:
> >>> jonsmirl@terra:~/mpc5200b$ git remote show linus
> >>> * remote linus
> >>> URL: git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/
> >>> linux-2.6.git
> >>>
> >>> How do I push the definition of the linus remote repo?
> >>
> >> You can't. Remotes are local to a repository. They cannot be
> >> "pushed" nor will they be "cloned" or "fetched".
> >
> > Dreamhost is way slow compared to kernel.org, so it is better to clone
> > from kernel.org first and then pull from dreamhost. What is the right
> > sequence of commands so that a new user will end up with a kernel they
> > can use 'git pull' on to get updates from dreamhost? I'll add these to
> > the repo description page.
> >
> > I'm trying this locally and I can't figure out the right sequence of
> > git command to redirect origin from kernel.org to dreamhost.
>
> How about the following (untested sequence)
>
> mkdir linux-2.6
> cd linux-2.6
> git init
> git remote add linus git://git.kernel.org/pub/scm/linux/kernel/git/
> torvalds/linux-2.6.git
> git remote add origin ssh://jonsmirl1@git.digispeaker.com/~/
> mpc5200b.git
> git fetch linus
> git fetch origin
> git checkout -b master origin/master
>
> The general idea should be correct. You have a non-standard
> setup, so avoid git-clone.
What should I do to standardize the setup so that 'clone/pull' will
work on it? I created a master branch. I gave up on fighting with
gitweb and no branch named master.
I'd like to do this, but I can't figure out how.
git clone linus
move origin to digispeaker
git pull
There doesn't seem to be a simple way to redirect the origin.
--
Jon Smirl
jonsmirl@gmail.com
^ permalink raw reply
* Re: Obscure commit message formatting issue
From: Johannes Schindelin @ 2007-11-11 22:43 UTC (permalink / raw)
To: Daniel Barkalow; +Cc: Junio C Hamano, git
In-Reply-To: <Pine.LNX.4.64.0711111706490.29952@iabervon.org>
Hi,
On Sun, 11 Nov 2007, Daniel Barkalow wrote:
> On Sun, 11 Nov 2007, Junio C Hamano wrote:
>
> > Daniel Barkalow <barkalow@iabervon.org> writes:
> >
> > > The current code drops extra blank lines between the first line of a
> > > commit message (the summary line) and the remainder.
> >
> > The patch application side does even more. It not just strips
> > off the leading or trailing blank lines, but duplicate blank
> > lines in the middle and trailing whitespaces at the end of each
> > line.
> >
> > I am of two minds about the formatting side.
> >
> > The behaviour you found does not go far enough to correct all of
> > the above whitespace breakage the application side will fix up
> > on the generation side -- it only corrects one of them. We
> > might want to do more, instead of less that you seem to be
> > implying to favor.
>
> What I'm actually doing is working on a cover letter implementation.
Funny.
I am in the middle of cleaning out my personal git branch that has a messy
history, since I never rebased, but always merged. Now I decided to go
with rebasing.
And there I found an implementation of a cover letter. You might want to
be interested ;-)
http://repo.or.cz/w/git/dscho.git?a=shortlog;h=cover-letter
Ciao,
Dscho
^ permalink raw reply
* Re: Deprecate git-fetch-pack?
From: Junio C Hamano @ 2007-11-11 22:35 UTC (permalink / raw)
To: Theodore Tso
Cc: Johannes Schindelin, Ask Bjørn Hansen, Daniel Barkalow, git
In-Reply-To: <20071111222117.GA7392@thunk.org>
Theodore Tso <tytso@mit.edu> writes:
> On Sun, Nov 11, 2007 at 01:16:09PM -0800, Junio C Hamano wrote:
>> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
>> > This should be a non-issue. We really should start deprecating
>> > "git-<command>" in favour of "git <command>" for real.
>> >
>> > New users should not even be told that this is correct usage.
>>
>> If you can write "git-commit" and "git commit" interchangeably
>> while you cannot say "git-cat-file" and are forced to say "git
>> cat-file", I suspect that would lead to a great confusion and
>> unhappy users.
>
> One of the reasons why I use git-diff and git-commit and in particular
> "git-rebase --interactive master" very often is that it allows my
> shell's bang completion to work. (i.e., "!git-rebase"). If we tell
> people they can not use "git-rebase", and must instead use "git
> rebase" instead, I would consider that pretty annoying/obnoxious.
Oh, of course.
But my impression was that Johannes was talking about
deprecating git-<foo> form only for plumbing, so that the users
will only see git-<foo> for the Porcelain. That would not break
your bang completion for the porcelain commands.
If Johannes was talking about deprecating all git-<foo> form,
then that would indeed break your bang completion, but it has
conceptually a much bigger problem. The topic was about fixing
"a new user sees too many git commands and gets scared" problem.
Deprecaing all git-<foo> form just replaces the problem with "a
new user sees too many git subcommands and gets scared" problem,
without solving anything.
^ permalink raw reply
* Re: [BUG] git-rebase fails when a commit message contains a diff
From: Björn Steinbrink @ 2007-11-11 22:31 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Johannes Schindelin, Jonas Fonseca, git
In-Reply-To: <7v1wb0xhxq.fsf@gitster.siamese.dyndns.org>
On 2007.11.08 18:37:37 -0800, Junio C Hamano wrote:
> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
>
> > On Thu, 8 Nov 2007, Junio C Hamano wrote:
> >
> >> I wonder if this is a sensible thing to do, regardless of the issue of
> >> commit log message that contains anything.
> >>
> >> The patch replaces git-rebase with git-rebase--interactive. The only
> >> difference from the existing "git-rebase -i" is if the command is called
> >> without "-i" the initial "here is the to-do list. please rearrange the
> >> lines, modify 'pick' to 'edit' or whatever as appropriate" step is done
> >> without letting the user edit the list.
> >
> > Hmm. I don't know, really. I had the impression that the "git
> > format-patch | git am" pipeline would be faster.
>
> Heh, I did not read rebase--interactive carefully enough.
>
> Unless told to use merge with "rebase -m", rebase replays the
> change by extracting and applying patches, and speed comparison
> was about that vs merge based replaying; I thought make_patch
> was done in order to avoid using cherry-pick (which is based on
> merge-recursive) and doing patch application with three-way
> fallback. Apparently that is not what "interactive" does.
>
> Perhaps pick_one () could be taught to perform the 3-way
> fallback dance git-am plays correctly. The patch I sent to make
> git-rebase--interactive take over git-rebase would then become
> quite reasonable, I would think.
Note that git-rebase--interactive also doesn't really support the
--strategy parameter which git-rebase handles using git-merge-* instead
of git-am. Only merge commits during a -i -p run actually apply the
strategy.
Björn
^ permalink raw reply
* Re: Obscure commit message formatting issue
From: Daniel Barkalow @ 2007-11-11 22:30 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vprygbfwf.fsf@gitster.siamese.dyndns.org>
On Sun, 11 Nov 2007, Junio C Hamano wrote:
> Daniel Barkalow <barkalow@iabervon.org> writes:
>
> > The current code drops extra blank lines between the first line of a
> > commit message (the summary line) and the remainder.
>
> The patch application side does even more. It not just strips
> off the leading or trailing blank lines, but duplicate blank
> lines in the middle and trailing whitespaces at the end of each
> line.
>
> I am of two minds about the formatting side.
>
> The behaviour you found does not go far enough to correct all of
> the above whitespace breakage the application side will fix up
> on the generation side -- it only corrects one of them. We
> might want to do more, instead of less that you seem to be
> implying to favor.
What I'm actually doing is working on a cover letter implementation. I'd
like to use the same code that generates the subject line and message for
patches to generate the cover letter text from some source material, if
there is source material, but have "insert text here" markers if there is
no pre-existing text. But the "insert text here" marker for a paragraph
looks odd if it's a single line of vertical space, and it's annoying if
the space is full of text that has to be removed, and it's again odd if
the text isn't centered. So I want it to start with a blank line. But the
current code can't generate a text like that.
Reversability isn't all that important to me in this case, although it
seems to me to be generally desirable for rebase. For email that actually
goes through people, I'd expect it to get further manipulated by humans,
so it doesn't matter so much there, aside from being able to arrange the
input so that you can get the intermediate form you want.
-Daniel
*This .sig left intentionally blank*
^ permalink raw reply
* Re: [PATCH] Move stripspace() and launch_editor() to strbuf.c
From: Johannes Schindelin @ 2007-11-11 22:29 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vtznsbgcc.fsf@gitster.siamese.dyndns.org>
Hi,
On Sun, 11 Nov 2007, Junio C Hamano wrote:
> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
>
> > These functions are already declared in strbuf.h, so it is only
> > logical to move their implementations to the corresponding file.
> > Particularly, since strbuf.h is in LIB_H, but both functions
> > were missing from libgit.a.
>
> I think this makes sense for stripspace(), but I have trouble
> with launch_editor().
>
> I do not object to have a function in strbuf API that takes a
> buffer, allows the end user to interactively edit its content
> and returns the updated content. The function was perfectly
> fine as a special purpose helper for git-commit and git-tag, but
> if you look at the current launch_editor(), it is not suitable
> as a generic strbuf library function:
>
> * "Launch" feels as if we are initiating an async operation and
> returning from the function without waiting for its
> completion, but this is not "launch" but "launch, wait and
> return the resulting string". Probably this should be called
> edit_buffer() or something like that.
>
> * Instead of dying, it should return exit code and have the
> caller choose to die or take any alternative action. The
> library function definitely should not say "if you are in an
> environment where we cannot let you interactively edit, use
> -F or -m option".
All valid points. Will add to my TODO list and repost when done.
Maybe call_editor() instead of edit_buffer()? Since we technically read
the file specified by "path" into the buffer "buffer", after having called
the editor.
Ciao,
Dscho
^ permalink raw reply
* Re: Deprecate git-fetch-pack?
From: Theodore Tso @ 2007-11-11 22:21 UTC (permalink / raw)
To: Junio C Hamano
Cc: Johannes Schindelin, Ask Bjørn Hansen, Daniel Barkalow, git
In-Reply-To: <7vd4ugcwkm.fsf@gitster.siamese.dyndns.org>
On Sun, Nov 11, 2007 at 01:16:09PM -0800, Junio C Hamano wrote:
> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> > This should be a non-issue. We really should start deprecating
> > "git-<command>" in favour of "git <command>" for real.
> >
> > New users should not even be told that this is correct usage.
> >
>
> If you can write "git-commit" and "git commit" interchangeably
> while you cannot say "git-cat-file" and are forced to say "git
> cat-file", I suspect that would lead to a great confusion and
> unhappy users.
One of the reasons why I use git-diff and git-commit and in particular
"git-rebase --interactive master" very often is that it allows my
shell's bang completion to work. (i.e., "!git-rebase"). If we tell
people they can not use "git-rebase", and must instead use "git
rebase" instead, I would consider that pretty annoying/obnoxious.
- Ted
^ permalink raw reply
* Re: [PATCH 5/6] builtin-commit: resurrect behavior for multiple -m options
From: Pierre Habouzit @ 2007-11-11 22:13 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git, krh, gitster
In-Reply-To: <Pine.LNX.4.64.0711112039130.4362@racer.site>
[-- Attachment #1: Type: text/plain, Size: 778 bytes --]
On Sun, Nov 11, 2007 at 08:42:48PM +0000, Johannes Schindelin wrote:
> Well, I meant to mention it in the cover letter. My preference is to do
> away with the extra empty line. But this might break existing setups
> depending on that behaviour.
In fact I believe what matters is that if there is more than one -m,
you have a \n\n between the first and the second one, else it'll break
subjects, and that sucks, so I'd say we have to stay with "\n\n" at
least for the first aggregation, and I'm unsure if it's worth the hassle
to count how many times we aggregated to use '\n' then.
--
·O· Pierre Habouzit
··O madcoder@debian.org
OOO http://www.madism.org
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: [PATCH 5/6] builtin-commit: resurrect behavior for multiple -m options
From: Pierre Habouzit @ 2007-11-11 22:11 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git, krh, gitster
In-Reply-To: <Pine.LNX.4.64.0711112039130.4362@racer.site>
[-- Attachment #1: Type: text/plain, Size: 3190 bytes --]
On Sun, Nov 11, 2007 at 08:42:48PM +0000, Johannes Schindelin wrote:
> Hi,
>
> On Sun, 11 Nov 2007, Pierre Habouzit wrote:
>
> > On Sun, Nov 11, 2007 at 05:36:39PM +0000, Johannes Schindelin wrote:
> > >
> > > When more than one -m option is given, the message does not replace
> > > the previous, but is appended.
> > >
> > > Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
> > > ---
> > > builtin-commit.c | 26 ++++++++++++++++++++------
> > > 1 files changed, 20 insertions(+), 6 deletions(-)
> > >
> > > diff --git a/builtin-commit.c b/builtin-commit.c
> > > index 66d7e5e..069d180 100644
> > > --- a/builtin-commit.c
> > > +++ b/builtin-commit.c
> > > @@ -30,13 +30,27 @@ static char *use_message_buffer;
> > > static const char commit_editmsg[] = "COMMIT_EDITMSG";
> > > static struct lock_file lock_file;
> > >
> > > -static char *logfile, *force_author, *message, *template_file;
> > > +static char *logfile, *force_author, *template_file;
> > > static char *edit_message, *use_message;
> > > static int all, edit_flag, also, interactive, only, amend, signoff;
> > > static int quiet, verbose, untracked_files, no_verify;
> > >
> > > static int no_edit, initial_commit, in_merge;
> > > const char *only_include_assumed;
> > > +struct strbuf message;
> >
> > Unless I'm mistaken `static` keywords are missign for`message` and
> > `only_include_assumed`.
>
> Oh yeah. Will fix.
>
> > And you _have_ to initialize message with STRBUF_INIT (remember of the
> > slop).
>
> Not in this case, since I do not use message.buf as long as message.len ==
> 0. But I agree it would be cleaner to just use STRBUF_INIT.
I know that you don't use it, but who knows where this code will be
headed in its future right ? :) It's just good practice.
> > > +static int opt_parse_m(const struct option *opt, const char *arg, int unset)
> > > +{
> > > + struct strbuf *buf = opt->value;
> > > + if (unset)
> > > + strbuf_setlen(buf, 0);
> > > + else {
> > > + strbuf_addstr(buf, arg);
> > > + strbuf_addch(buf, '\n');
> > > + strbuf_addch(buf, '\n');
> > > + }
> > > + return 0;
> > > +}
> >
> > I believe such a callback could live in parse-options.[hc]. The need
> > to aggregate all string arguments into a strbuf looks generic enough to
> > me. Why are you adding two '\n' btw ? Isn't one enough ?
>
> Well, this empty line is needed to stay backwards compatible. It was
> added to pass the test that Junio added to 'next'. As such, this function
> is not really generic enough, right?
Well, you can make it generic enough using the defval to point to a
delimiter to use between lines :) But it's probably an overkill, and yes
if the "\n\n" is to be kept, then it's not generic "enough".
> Well, I meant to mention it in the cover letter. My preference is to do
> away with the extra empty line. But this might break existing setups
> depending on that behaviour.
Right.
--
·O· Pierre Habouzit
··O madcoder@debian.org
OOO http://www.madism.org
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: Obscure commit message formatting issue
From: Junio C Hamano @ 2007-11-11 22:01 UTC (permalink / raw)
To: Daniel Barkalow; +Cc: git
In-Reply-To: <Pine.LNX.4.64.0711111559220.29952@iabervon.org>
Daniel Barkalow <barkalow@iabervon.org> writes:
> The current code drops extra blank lines between the first line of a
> commit message (the summary line) and the remainder.
The patch application side does even more. It not just strips
off the leading or trailing blank lines, but duplicate blank
lines in the middle and trailing whitespaces at the end of each
line.
I am of two minds about the formatting side.
The behaviour you found does not go far enough to correct all of
the above whitespace breakage the application side will fix up
on the generation side -- it only corrects one of them. We
might want to do more, instead of less that you seem to be
implying to favor.
^ permalink raw reply
* Re: Local branch to remote branch translation
From: Steffen Prohaska @ 2007-11-11 22:01 UTC (permalink / raw)
To: Jon Smirl; +Cc: Git Mailing List
In-Reply-To: <9e4733910711111320u1deafe69r96d64babbb893adf@mail.gmail.com>
On Nov 11, 2007, at 10:20 PM, Jon Smirl wrote:
> On 11/11/07, Steffen Prohaska <prohaska@zib.de> wrote:
>>> jonsmirl@terra:~/mpc5200b$ git remote show linus
>>> * remote linus
>>> URL: git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/
>>> linux-2.6.git
>>>
>>> How do I push the definition of the linus remote repo?
>>
>> You can't. Remotes are local to a repository. They cannot be
>> "pushed" nor will they be "cloned" or "fetched".
>
> Dreamhost is way slow compared to kernel.org, so it is better to clone
> from kernel.org first and then pull from dreamhost. What is the right
> sequence of commands so that a new user will end up with a kernel they
> can use 'git pull' on to get updates from dreamhost? I'll add these to
> the repo description page.
>
> I'm trying this locally and I can't figure out the right sequence of
> git command to redirect origin from kernel.org to dreamhost.
How about the following (untested sequence)
mkdir linux-2.6
cd linux-2.6
git init
git remote add linus git://git.kernel.org/pub/scm/linux/kernel/git/
torvalds/linux-2.6.git
git remote add origin ssh://jonsmirl1@git.digispeaker.com/~/
mpc5200b.git
git fetch linus
git fetch origin
git checkout -b master origin/master
The general idea should be correct. You have a non-standard
setup, so avoid git-clone.
Steffen
^ permalink raw reply
* Re: [PATCH] Move stripspace() and launch_editor() to strbuf.c
From: Junio C Hamano @ 2007-11-11 21:52 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git, gitster
In-Reply-To: <Pine.LNX.4.64.0711111728380.4362@racer.site>
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> These functions are already declared in strbuf.h, so it is only
> logical to move their implementations to the corresponding file.
> Particularly, since strbuf.h is in LIB_H, but both functions
> were missing from libgit.a.
I think this makes sense for stripspace(), but I have trouble
with launch_editor().
I do not object to have a function in strbuf API that takes a
buffer, allows the end user to interactively edit its content
and returns the updated content. The function was perfectly
fine as a special purpose helper for git-commit and git-tag, but
if you look at the current launch_editor(), it is not suitable
as a generic strbuf library function:
* "Launch" feels as if we are initiating an async operation and
returning from the function without waiting for its
completion, but this is not "launch" but "launch, wait and
return the resulting string". Probably this should be called
edit_buffer() or something like that.
* Instead of dying, it should return exit code and have the
caller choose to die or take any alternative action. The
library function definitely should not say "if you are in an
environment where we cannot let you interactively edit, use
-F or -m option".
^ permalink raw reply
* Re: [PATCH] Use the best available exec path only
From: Johannes Schindelin @ 2007-11-11 21:40 UTC (permalink / raw)
To: Björn Steinbrink; +Cc: Junio C Hamano, Brian Gernhardt, Git Mailing List
In-Reply-To: <20071111211732.GA11871@atjola.homenet>
Hi,
On Sun, 11 Nov 2007, Bj?rn Steinbrink wrote:
> > In related news, IMO cmd_path should be made absolute if it is not
> > already the case.
>
> add_path() already takes care of that.
Yeah, and cmd_path is not used otherwise. Sorry for the noise.
Ciao,
Dscho
^ permalink raw reply
* Re: t7005 and vi in GIT_EXEC_PATH
From: Junio C Hamano @ 2007-11-11 21:29 UTC (permalink / raw)
To: Brian Gernhardt; +Cc: Johannes Schindelin, Git Mailing List
In-Reply-To: <7v3avcefg9.fsf@gitster.siamese.dyndns.org>
Junio C Hamano <gitster@pobox.com> writes:
> Brian Gernhardt <benji@silverinsanity.com> writes:
>
>> I'm sorry, I should have been more clear. I was referring to the
>> GIT_EXEC_PATH build variable, not the environment variable. The git
>> wrapper always adds the path determined during build to the front of
>> PATH. When I was changing my build script, this got set to "/usr/
>> local/bin" (I usually use /usr/local/stow/git, instead). Since I have
>> a /usr/local/bin/vim, PATH for git-commit.sh during the test was:
>>
>> - my git build directory
>> - /usr/local/bin (containing a symlink vi -> vim)
>> - the t/trash directory, added by the test via `PATH=".:$PATH"`
>> (containing the test vi script)
>> - my normal path
>
> Maybe that is what is broken. t/test-lib.sh makes the
> environment variable point at the build directory, and that
> should override the path that is compiled in, shouldn't it?
Ah, nevermind. I did not see the other messages in the thread.
^ permalink raw reply
* Obscure commit message formatting issue
From: Daniel Barkalow @ 2007-11-11 21:28 UTC (permalink / raw)
To: Junio C Hamano, git
The current code drops extra blank lines between the first line of a
commit message (the summary line) and the remainder. That is:
This is the summary
This is another bit
This is a third bit
turns into:
Subject: This is the summary
Other-Headers:
This is another bit
This is a third bit
This is an issue if you want to generate an email whose body starts with a
blank line, and I assume (although I haven't tried), that rebase would
lose a blank line out of commits formatted like that. We don't seem to
have any tests that require that line to get suppressed, and we also don't
suppress any other blank lines. Is there some reason to do it?
I'd guess that the "first" handling in pp_remainder() was intended to skip
the blank line between the summary line and the body, but that line has
already been consumed by other code.
-Daniel
*This .sig left intentionally blank*
^ 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