* 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: 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: [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: 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: 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: 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: 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: 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: [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
* [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: 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
* 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
* [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: [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
* 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
* [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
* stgit 0.13 + git 1.5.3.5 bogus "empty patch" status, and other problems
From: Adam J. Richter @ 2007-11-12 0:39 UTC (permalink / raw)
To: catalin.marinas; +Cc: git
Hi Catalin,
I want to report two problems, at least one of which may be
due to some other environmental change such as a git upgrade.
The first bug is less perhaps serious, and perhaps not new,
but it's easier to describe this one first.
I have a small stack of patches in stgit for a source tree.
One of these patches modified a yacc grammer "parser.y", which, in
turn, causes the yacc files y.tab.{c,h} to be rebuilt. y.tab.{c,h}
are included in the source tree for build environments that lack yacc.
Sometimes my attempts to check out a new source tree and rebuild would
result in y.tab.{c,h} not being built, probably due to 1 second
timestamp granularity somewhere (the ext3 file system, make, git,
stgit, whatever), probably not stgit's fault.
So, did repeated "stg pop" commands to get to the point where
the change to parser.y is applied, did an "stg new", deleted
y.tab.{c,h}, did "stg rm y.tab.{c,h}" and "stg refresh". So far, so
good. Then I tried to do an "stg push" to re-integrate the next
patch, and I got a complaint from stgit about some git object not
existing. This patch did not touch y.tab.{c,h} or any files touched
by any of the other patches I had pushed on. I don't know stgit well
enough to recover from the situation gracefully, so I just wiped the
stgit tree and tried to apply the patches again, which brings me to
bug #2.
I made a new stgit tree of the program (bash), pulling from a
local git tree, and attempted to apply the first patch, with usuaul
"stg new...make changes...stg refresh". Then stg refresh informed
printed this message ("invalid_multibyte_sequence" is the name of the
new patch):
Checking for changes in the working directory ... done
Refreshing patch "invalid_multibyte_sequence" ... done (empty patch)
"stg diff" still shows the changes as if I had not done an
"stg refresh". Obviously, stg commits have worked for me in the past.
I suspect that a recent upgrade of git or other system software
triggered the break.
I'll try to pass along what I find if I start debugging this
problem, but I probably won't be able to get into that immediately, so
I am just passing this data along for now in the hopes that it may be
helpful for someone else.
Adam
^ permalink raw reply
* Re: Is it possible for git to remember the options preference for "git log"?
From: Jakub Narebski @ 2007-11-12 0:56 UTC (permalink / raw)
To: git
In-Reply-To: <f17812d70711111633u6c00d182u532fef1c16c3c94a@mail.gmail.com>
eric miao wrote:
> 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" :-)
You can always use (global) _git_ alias ;-p
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
^ permalink raw reply
* [PATCH,RFC 2/2] Remove hint to use "git help -a"
From: Theodore Ts'o @ 2007-11-12 0:57 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Git Mailing List, Theodore Ts'o
In-Reply-To: <1194829077-14320-1-git-send-email-tytso@mit.edu>
The newbie user will run away screaming when they see all possible
commands. The expert user will already know about the -a option from
reading the git man page.
Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
---
help.c | 1 -
1 files changed, 0 insertions(+), 1 deletions(-)
diff --git a/help.c b/help.c
index 1cd33ec..f539b80 100644
--- a/help.c
+++ b/help.c
@@ -162,7 +162,6 @@ static void list_common_cmds_help(void)
mput_char(' ', longest - strlen(common_cmds[i].name));
puts(common_cmds[i].help);
}
- puts("(use 'git help -a' to get a list of all installed git commands)");
}
static void show_man_page(const char *git_cmd)
--
1.5.3.5.623.g91546-dirty
^ permalink raw reply related
* [PATCH,RFC 1/2] Make the list of common commands more exclusive
From: Theodore Ts'o @ 2007-11-12 0:57 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Git Mailing List, Theodore Ts'o
In-Reply-To: <20071111235819.GB7392@thunk.org>
Remove apply, archive, cherry-pick, prune, revert, and show-branch, so
"git help" is less intimidating.
Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
---
generate-cmdlist.sh | 6 ------
1 files changed, 0 insertions(+), 6 deletions(-)
diff --git a/generate-cmdlist.sh b/generate-cmdlist.sh
index 17df47b..1ba27ec 100755
--- a/generate-cmdlist.sh
+++ b/generate-cmdlist.sh
@@ -11,12 +11,9 @@ static struct cmdname_help common_cmds[] = {"
sort <<\EOF |
add
-apply
-archive
bisect
branch
checkout
-cherry-pick
clone
commit
diff
@@ -26,15 +23,12 @@ init
log
merge
mv
-prune
pull
push
rebase
reset
-revert
rm
show
-show-branch
status
tag
EOF
--
1.5.3.5.623.g91546-dirty
^ permalink raw reply related
* Re: Is it possible for git to remember the options preference for "git log"?
From: Daniel Barkalow @ 2007-11-12 1:02 UTC (permalink / raw)
To: eric miao; +Cc: git
In-Reply-To: <f17812d70711111633u6c00d182u532fef1c16c3c94a@mail.gmail.com>
On Mon, 12 Nov 2007, eric miao wrote:
> 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" :-)
Git has a built-in alias mechanism, which is probably what you want. If
you put in your config file:
[alias]
xxx = log --abbrev-commit --pretty=online
then you can type "git xxx" and it'll do what you want. Changing the
default behavior of the basic commands is looked down on because there are
scripts that use them to get their input, and those scripts have
particular formats they expect.
-Daniel
*This .sig left intentionally blank*
^ permalink raw reply
* Re: Deprecate git-fetch-pack?
From: Ask Bjørn Hansen @ 2007-11-12 1:10 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Junio C Hamano, Theodore Tso, Daniel Barkalow, git
In-Reply-To: <Pine.LNX.4.64.0711112247350.4362@racer.site>
On Nov 11, 2007, at 2:50 PM, Johannes Schindelin wrote:
> I beg to differ. The biggest problem with a new user seeing all those
> completions is that this user is scared.
How about moving the plumbing commands to libexec/ or some such? (Or
libexec/git/ - then you can put it back in your PATH if you really
want easy access to run them directly).
Maybe I'm being pedantic, but it's not about "scaring the user" --
it's simply that the "visible commands" is part of the UI and having
it unnecessarily complex (many more commands than the user needs to
learn) makes it much harder to get started using git. It's a very
practical thing.
I strongly second Theodore's suggestions for cleaning up some of the
help texts, too.
- ask
--
http://develooper.com/ - http://askask.com/
^ permalink raw reply
* [PATCH] Make git-clean a builtin
From: Shawn Bohrer @ 2007-11-12 1:48 UTC (permalink / raw)
To: gitster; +Cc: git, johannes.schindelin, Shawn Bohrer
This replaces git-clean.sh with builtin-clean.c, and moves
git-clean.sh to the examples.
This also introduces a change in behavior when removing directories
explicitly specified as a path. For example currently:
1. When dir has only untracked files, these two behave differently:
$ git clean -n dir
$ git clean -n dir/
the former says "Would not remove dir/", while the latter would say
"Would remove dir/untracked" for all paths under it, but not the
directory itself.
With -d, the former would stop refusing, however since the user
explicitly asked to remove the directory the -d is no longer required.
2. When there are more parameters:
$ git clean -n dir foo
$ git clean -n dir/ foo
both cases refuse to remove dir/ unless -d is specified. Once again
since both cases requested to remove dir the -d is no longer required.
Thanks to Johannes Schindelin for the conversion to using the
parse-options API.
Signed-off-by: Shawn Bohrer <shawn.bohrer@gmail.com>
---
On Wed, Nov 07, 2007 at 11:37:50PM -0600, Shawn Bohrer wrote:
> On Wed, Nov 07, 2007 at 12:42:16PM -0800, Junio C Hamano wrote:
> >
> > Having said that, I do not particularly agree with the way the
> > new implementation resolves the existing inconsistencies.
> >
> > Wouldn't it be better to remove "dir" when the user explicitly
> > told you to clean "dir", with or without the trailing slash?
> > That's what the user asked you to do, isn't it?
>
> Yes I suppose I agree. Of course I need to spend some more time staring
> at the code to figure out how to do so. Perhaps I can figure out what
> is causing the original inconsistency in git-ls-files while I'm at it.
OK, I failed to fix the inconsistency between a single and multiple
paths so I'm not sure if this patch is much better. The problem appears
to be that when dir.show_others_directories is set directories that only
contain untracked files are not recursed, which is fine with a single
path because you can adjust the path, base and baselen to
read_directory(). With multiple paths you need to find a common prefix
to all of the paths before calling read_directory() which causes the
inconsistency.
If anyone as a suggestion on how to fix this I'm all for it, but even
with the inconsistency we are no worse than we were with git-clean.sh
Makefile | 3 +-
builtin-clean.c | 154 +++++++++++++++++++++++++
builtin.h | 1 +
git-clean.sh => contrib/examples/git-clean.sh | 0
git.c | 1 +
5 files changed, 158 insertions(+), 1 deletions(-)
create mode 100644 builtin-clean.c
rename git-clean.sh => contrib/examples/git-clean.sh (100%)
diff --git a/Makefile b/Makefile
index a2fcdb8..ef7420d 100644
--- a/Makefile
+++ b/Makefile
@@ -213,7 +213,7 @@ BASIC_LDFLAGS =
SCRIPT_SH = \
git-bisect.sh git-checkout.sh \
- git-clean.sh git-clone.sh git-commit.sh \
+ git-clone.sh git-commit.sh \
git-merge-one-file.sh git-mergetool.sh git-parse-remote.sh \
git-pull.sh git-rebase.sh git-rebase--interactive.sh \
git-repack.sh git-request-pull.sh \
@@ -329,6 +329,7 @@ BUILTIN_OBJS = \
builtin-check-attr.o \
builtin-checkout-index.o \
builtin-check-ref-format.o \
+ builtin-clean.o \
builtin-commit-tree.o \
builtin-count-objects.o \
builtin-describe.o \
diff --git a/builtin-clean.c b/builtin-clean.c
new file mode 100644
index 0000000..55658e7
--- /dev/null
+++ b/builtin-clean.c
@@ -0,0 +1,154 @@
+/*
+ * "git clean" builtin command
+ *
+ * Copyright (C) 2007 Shawn Bohrer
+ *
+ * Based on git-clean.sh by Pavel Roskin
+ */
+
+#include "builtin.h"
+#include "cache.h"
+#include "dir.h"
+#include "parse-options.h"
+
+static int force;
+
+static const char *const builtin_clean_usage[] = {
+ "git-clean [-d] [-f] [-n] [-q] [-x | -X] [--] <paths>...",
+ NULL
+};
+
+static int git_clean_config(const char *var, const char *value)
+{
+ if (!strcmp(var, "clean.requireforce"))
+ force = !git_config_bool(var, value);
+ return 0;
+}
+
+int cmd_clean(int argc, const char **argv, const char *prefix)
+{
+ int j;
+ int show_only = 0, remove_directories = 0, quiet = 0, ignored = 0;
+ int ignored_only = 0, baselen = 0;
+ struct strbuf directory;
+ struct dir_struct dir;
+ const char *path, *base;
+ static const char **pathspec;
+ struct option options[] = {
+ OPT__QUIET(&quiet),
+ OPT__DRY_RUN(&show_only),
+ OPT_BOOLEAN('f', NULL, &force, "force"),
+ OPT_BOOLEAN('d', NULL, &remove_directories,
+ "remove whole directories"),
+ OPT_BOOLEAN('x', NULL, &ignored, "remove ignored files, too"),
+ OPT_BOOLEAN('X', NULL, &ignored_only,
+ "remove only ignored files"),
+ OPT_END()
+ };
+
+ git_config(git_clean_config);
+ argc = parse_options(argc, argv, options, builtin_clean_usage, 0);
+
+ memset(&dir, 0, sizeof(dir));
+ if (ignored_only) {
+ dir.show_ignored =1;
+ dir.exclude_per_dir = ".gitignore";
+ }
+
+ if (ignored && ignored_only)
+ die("-x and -X cannot be used together");
+
+ if (!show_only && !force)
+ die("clean.requireForce set and -n or -f not given; refusing to clean");
+
+ dir.show_other_directories = 1;
+
+ if (!ignored) {
+ dir.exclude_per_dir = ".gitignore";
+ if (!access(git_path("info/exclude"), F_OK)) {
+ char *exclude_path = git_path("info/exclude");
+ add_excludes_from_file(&dir, exclude_path);
+ }
+ }
+
+ pathspec = get_pathspec(prefix, argv);
+ read_cache();
+
+ /*
+ * Calculate common prefix for the pathspec, and
+ * use that to optimize the directory walk
+ */
+ baselen = common_prefix(pathspec);
+ path = ".";
+ base = "";
+ if (baselen)
+ path = base = xmemdupz(*pathspec, baselen);
+ read_directory(&dir, path, base, baselen, pathspec);
+ strbuf_init(&directory, 0);
+
+ for (j = 0; j < dir.nr; ++j) {
+ struct dir_entry *ent = dir.entries[j];
+ int len, pos, specs;
+ struct cache_entry *ce;
+ struct stat st;
+ char *seen;
+
+ /*
+ * Remove the '/' at the end that directory
+ * walking adds for directory entries.
+ */
+ len = ent->len;
+ if (len && ent->name[len-1] == '/')
+ len--;
+ pos = cache_name_pos(ent->name, len);
+ if (0 <= pos)
+ continue; /* exact match */
+ pos = -pos - 1;
+ if (pos < active_nr) {
+ ce = active_cache[pos];
+ if (ce_namelen(ce) == len &&
+ !memcmp(ce->name, ent->name, len))
+ continue; /* Yup, this one exists unmerged */
+ }
+
+ if (!lstat(ent->name, &st) && (S_ISDIR(st.st_mode))) {
+ int matched_path = 0;
+ strbuf_addstr(&directory, ent->name);
+ if (pathspec) {
+ for (specs =0; pathspec[specs]; ++specs)
+ /* nothing */;
+ seen = xcalloc(specs, 1);
+ /* Check if directory was explictly passed as
+ * pathspec. If so we want to remove it */
+ if (match_pathspec(pathspec, ent->name, ent->len,
+ baselen, seen))
+ matched_path = 1;
+ free(seen);
+ }
+ if (show_only && (remove_directories || matched_path)) {
+ printf("Would remove %s\n", directory.buf);
+ } else if (quiet && (remove_directories || matched_path)) {
+ remove_dir_recursively(&directory, 0);
+ } else if (remove_directories || matched_path) {
+ printf("Removing %s\n", directory.buf);
+ remove_dir_recursively(&directory, 0);
+ } else if (show_only) {
+ printf("Would not remove %s\n", directory.buf);
+ } else {
+ printf("Not removing %s\n", directory.buf);
+ }
+ strbuf_reset(&directory);
+ } else {
+ if (show_only) {
+ printf("Would remove %s\n", ent->name);
+ continue;
+ } else if (!quiet) {
+ printf("Removing %s\n", ent->name);
+ }
+ unlink(ent->name);
+ }
+ }
+
+ strbuf_release(&directory);
+ return 0;
+}
diff --git a/builtin.h b/builtin.h
index 525107f..5476a92 100644
--- a/builtin.h
+++ b/builtin.h
@@ -24,6 +24,7 @@ extern int cmd_check_attr(int argc, const char **argv, const char *prefix);
extern int cmd_check_ref_format(int argc, const char **argv, const char *prefix);
extern int cmd_cherry(int argc, const char **argv, const char *prefix);
extern int cmd_cherry_pick(int argc, const char **argv, const char *prefix);
+extern int cmd_clean(int argc, const char **argv, const char *prefix);
extern int cmd_commit_tree(int argc, const char **argv, const char *prefix);
extern int cmd_count_objects(int argc, const char **argv, const char *prefix);
extern int cmd_describe(int argc, const char **argv, const char *prefix);
diff --git a/git-clean.sh b/contrib/examples/git-clean.sh
similarity index 100%
rename from git-clean.sh
rename to contrib/examples/git-clean.sh
diff --git a/git.c b/git.c
index 204a6f7..3fa8e4d 100644
--- a/git.c
+++ b/git.c
@@ -293,6 +293,7 @@ static void handle_internal_command(int argc, const char **argv)
{ "check-attr", cmd_check_attr, RUN_SETUP | NEED_WORK_TREE },
{ "cherry", cmd_cherry, RUN_SETUP },
{ "cherry-pick", cmd_cherry_pick, RUN_SETUP | NEED_WORK_TREE },
+ { "clean", cmd_clean, RUN_SETUP | NEED_WORK_TREE },
{ "commit-tree", cmd_commit_tree, RUN_SETUP },
{ "config", cmd_config },
{ "count-objects", cmd_count_objects, RUN_SETUP },
--
1.5.3.GIT
^ permalink raw reply related
* Re: Is it possible for git to remember the options preference for "git log"?
From: eric miao @ 2007-11-12 2:21 UTC (permalink / raw)
To: Daniel Barkalow; +Cc: git
In-Reply-To: <Pine.LNX.4.64.0711111954520.29952@iabervon.org>
On Nov 12, 2007 9:02 AM, Daniel Barkalow <barkalow@iabervon.org> wrote:
>
> On Mon, 12 Nov 2007, eric miao wrote:
>
> > 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" :-)
>
> Git has a built-in alias mechanism, which is probably what you want. If
> you put in your config file:
>
> [alias]
> xxx = log --abbrev-commit --pretty=online
>
Thanks, this is exactly what I want.
> then you can type "git xxx" and it'll do what you want. Changing the
> default behavior of the basic commands is looked down on because there are
> scripts that use them to get their input, and those scripts have
> particular formats they expect.
>
Ye, agree, I don't think that's a good idea either.
> -Daniel
> *This .sig left intentionally blank*
>
--
Cheers
- eric
^ permalink raw reply
* Re: [PATCH,RFC 1/2] Make the list of common commands more exclusive
From: Junio C Hamano @ 2007-11-12 2:21 UTC (permalink / raw)
To: Theodore Ts'o; +Cc: Git Mailing List
In-Reply-To: <1194829077-14320-1-git-send-email-tytso@mit.edu>
Theodore Ts'o <tytso@mit.edu> writes:
> Remove apply, archive, cherry-pick, prune, revert, and show-branch, so
> "git help" is less intimidating.
>
> Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
>
> -apply
> -archive
> -prune
> -revert
> -show-branch
I am fine with this list, perhaps except apply.
On the other hand, if you are shooting *really* for the absolute
minimum set for the beginners, I would kill rm and possibly mv)
in addition to your list:
- git-rm is always easier to do with "rm -fr file-or-dir",
followed by "git commit -a". Of course "git rm --cached" and
partial commits that contain removal cannot be emulated
easily this way, but this is an alternative suggestion to aim
for *real* beginners who do not use the index.
- git-mv is on my list for the same reason as "rm", but it is a
bit more cumbersome if you want to move a directory, because
"mv old new && git add new" would not work for people without
a correctly set-up .gitignore (and if we are talking about
beginners, we should expect user's .gitignore is borked).
I have a bit of reservation about revert, but I'd imagine we
could kill it, and also fetch, pull and push, if you are
shooting for *real* beginners who work alone. I think the only
valid justification to drop "revert" from the list is to assume
that the audience do not interact with the outside world, and
dropping fetch/pull/push from the list is in line with that.
^ 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