* Re: [PATCH] Use 'fast-forward' all over the place
From: Junio C Hamano @ 2009-10-25 7:22 UTC (permalink / raw)
To: Felipe Contreras; +Cc: git, Michael J Gruber, Shawn O. Pearce
In-Reply-To: <7v4opoym7w.fsf@alter.siamese.dyndns.org>
Junio C Hamano <gitster@pobox.com> writes:
> Junio C Hamano <gitster@pobox.com> writes:
>
>> I'll queue your patch with the following interdiff for now.
>
> Sorry, I think I sent a wrong interdiff.
Nevermind; the one I sent out was the right one after all.
^ permalink raw reply
* Re: [PATCH] Use 'fast-forward' all over the place
From: Junio C Hamano @ 2009-10-25 7:19 UTC (permalink / raw)
To: Felipe Contreras; +Cc: git, Michael J Gruber, Shawn O. Pearce
In-Reply-To: <7vtyxoymfa.fsf@alter.siamese.dyndns.org>
Junio C Hamano <gitster@pobox.com> writes:
> I'll queue your patch with the following interdiff for now.
Sorry, I think I sent a wrong interdiff.
^ permalink raw reply
* Re: [PATCH 0/2] Speedup fetch with large numbers of refs
From: Junio C Hamano @ 2009-10-25 7:16 UTC (permalink / raw)
To: Julian Phillips; +Cc: Junio C Hamano, git
In-Reply-To: <20091022210444.18084.61685.julian@quantumfyre.co.uk>
Hmm, t5515 does not seem to pass with this series for me.
^ permalink raw reply
* Re: [PATCH] Use 'fast-forward' all over the place
From: Junio C Hamano @ 2009-10-25 7:15 UTC (permalink / raw)
To: Felipe Contreras; +Cc: git, Michael J Gruber, Shawn O. Pearce
In-Reply-To: <7v1vks2l8q.fsf@alter.siamese.dyndns.org>
I'll queue your patch with the following interdiff for now.
* user-manual.txt: do not change emphasis (typography) in this patch---if
it needs to be changed, that should be a separate patch.
* builtin-fetch.c: an instance of "non fast-forward" was left
unconverted; fix it.
* contrib/hooks/post-receive-email: likewise.
By the way, in Documentation/git-init.txt there also is another "non
fast-forward"; since it is not a fix-up to this patch, I left it as-is.
We may want to change it as well while we are at it.
* git-gui: this is a straight revert of your patch, so that Shawn can
apply an undated version of this patch to his tree first, and then I
can pull the result from him.
$ git grep -i -n -e 'fast forward' -- git-gui/
will show what need to be changed. This is a key string of "mc", so
msgid in *.po files and git-gui.pot file need to consistently change,
even though the translated strings in *.po files may stay as before.
If you spot misconversions in here (or other "fast forward" that need to be
converted but I missed), please holler.
Thanks.
---
Documentation/user-manual.txt | 2 +-
builtin-fetch.c | 2 +-
contrib/hooks/post-receive-email | 2 +-
git-gui/lib/branch_create.tcl | 2 +-
4 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/Documentation/user-manual.txt b/Documentation/user-manual.txt
index 42d92fd..269ec47 100644
--- a/Documentation/user-manual.txt
+++ b/Documentation/user-manual.txt
@@ -2115,7 +2115,7 @@ $ git checkout release && git pull
Important note! If you have any local changes in these branches, then
this merge will create a commit object in the history (with no local
-changes git will simply do a fast-forward merge). Many people dislike
+changes git will simply do a "fast-forward" merge). Many people dislike
the "noise" that this creates in the Linux history, so you should avoid
doing this capriciously in the "release" branch, as these noisy commits
will become part of the permanent history when you ask Linus to pull
diff --git a/builtin-fetch.c b/builtin-fetch.c
index 89cedc8..6303aa0 100644
--- a/builtin-fetch.c
+++ b/builtin-fetch.c
@@ -287,7 +287,7 @@ static int update_local_ref(struct ref *ref,
r ? "unable to update local ref" : "forced update");
return r;
} else {
- sprintf(display, "! %-*s %-*s -> %s (non fast-forward)",
+ sprintf(display, "! %-*s %-*s -> %s (non-fast-forward)",
SUMMARY_WIDTH, "[rejected]", REFCOL_WIDTH, remote,
pretty_ref);
return 1;
diff --git a/contrib/hooks/post-receive-email b/contrib/hooks/post-receive-email
index 3b075ad..58a35c8 100755
--- a/contrib/hooks/post-receive-email
+++ b/contrib/hooks/post-receive-email
@@ -316,7 +316,7 @@ generate_update_branch_email()
# List all of the revisions that were removed by this update, in a
# fast-forward update, this list will be empty, because rev-list O
- # ^N is empty. For a non fast-forward, O ^N is the list of removed
+ # ^N is empty. For a non-fast-forward, O ^N is the list of removed
# revisions
fast_forward=""
rev=""
diff --git a/git-gui/lib/branch_create.tcl b/git-gui/lib/branch_create.tcl
index f1235c7..3817771 100644
--- a/git-gui/lib/branch_create.tcl
+++ b/git-gui/lib/branch_create.tcl
@@ -77,7 +77,7 @@ constructor dialog {} {
-variable @opt_merge
pack $w.options.merge.no -side left
radiobutton $w.options.merge.ff \
- -text [mc "Fast-forward Only"] \
+ -text [mc "Fast Forward Only"] \
-value ff \
-variable @opt_merge
pack $w.options.merge.ff -side left
^ permalink raw reply related
* Re: [PATCH] Use 'fast-forward' all over the place
From: Junio C Hamano @ 2009-10-25 3:41 UTC (permalink / raw)
To: Felipe Contreras; +Cc: git, Michael J Gruber
In-Reply-To: <1256373092-15126-2-git-send-email-felipe.contreras@gmail.com>
This is the latter half of my review; please see
From: Junio C Hamano <gitster@pobox.com>
Subject: Re: [PATCH] Use 'fast-forward' all over the place
Date: Sat, 24 Oct 2009 10:50:05 -0700
Message-ID: <7v3a587kc2.fsf@alter.siamese.dyndns.org>
for the other half.
Felipe Contreras <felipe.contreras@gmail.com> writes:
> diff --git a/builtin-fetch--tool.c b/builtin-fetch--tool.c
Ok. We may want to consider moving this command to contrib/examples/ or
removing it, but that is a separate issue and can be done after we apply
this patch.
> diff --git a/builtin-fetch.c b/builtin-fetch.c
> @@ -269,7 +269,7 @@ static int update_local_ref(struct ref *ref,
> strcpy(quickref, find_unique_abbrev(current->object.sha1, DEFAULT_ABBREV));
> strcat(quickref, "..");
> strcat(quickref, find_unique_abbrev(ref->new_sha1, DEFAULT_ABBREV));
> - r = s_update_ref("fast forward", ref, 1);
> + r = s_update_ref("fast-forward", ref, 1);
This is creating a message in the reflog; I do not think we have any
script/program in-tree that relies on the exact wording of this one, so we
are probably safe ourselves, but I do not know about third-party scripts.
I'd be surprised if there are somebody who reads the reflog and acts
differently upon seeing that we fast-forwarded, but we'd never know until
we cook this in 'next' and see people complain.
The other hunk to this file is an end-user message from Porcelain, so it
should be Ok.
> diff --git a/builtin-merge.c b/builtin-merge.c
> diff --git a/builtin-push.c b/builtin-push.c
> @@ -159,7 +159,7 @@ static int do_push(const char *repo, int flags)
> error("failed to push some refs to '%s'", url[i]);
> if (nonfastforward && advice_push_nonfastforward) {
> printf("To prevent you from losing history, non-fast-forward updates were rejected\n"
> - "Merge the remote changes before pushing again. See the 'non-fast forward'\n"
> + "Merge the remote changes before pushing again. See the 'non-fast-forward'\n"
> "section of 'git push --help' for details.\n");
> }
Ok, except that I think we will be seeing merge conflicts with changes
that are pending for 1.7.0 with this hunk---I am not looking forward to
it, but I'll survive with help from rerere.
> diff --git a/builtin-receive-pack.c b/builtin-receive-pack.c
> diff --git a/builtin-remote.c b/builtin-remote.c
> diff --git a/builtin-send-pack.c b/builtin-send-pack.c
> diff --git a/contrib/examples/git-merge.sh b/contrib/examples/git-merge.sh
> diff --git a/contrib/examples/git-resolve.sh b/contrib/examples/git-resolve.sh
Ok.
> diff --git a/contrib/hooks/post-receive-email b/contrib/hooks/post-receive-email
> @@ -315,8 +315,8 @@ generate_update_branch_email()
> # "remotes/" will be ignored as well.
>
> # List all of the revisions that were removed by this update, in a
> - # fast forward update, this list will be empty, because rev-list O
> - # ^N is empty. For a non fast forward, O ^N is the list of removed
> + # fast-forward update, this list will be empty, because rev-list O
> + # ^N is empty. For a non fast-forward, O ^N is the list of removed
Wasn't non-fast-forward a single compound word of three?
> @@ -411,7 +411,7 @@ generate_update_branch_email()
> # revision because the base is effectively a random revision at this
> # point - the user will be interested in what this revision changed
> # - including the undoing of previous revisions in the case of
> - # non-fast forward updates.
> + # non-fast-forward updates.
> echo ""
> echo "Summary of changes:"
> git diff-tree --stat --summary --find-copies-harder $oldrev..$newrev
... like this hunk, that is.
> diff --git a/git-gui/lib/branch_create.tcl b/git-gui/lib/branch_create.tcl
> index 3817771..f1235c7 100644
> --- a/git-gui/lib/branch_create.tcl
> +++ b/git-gui/lib/branch_create.tcl
> @@ -77,7 +77,7 @@ constructor dialog {} {
> -variable @opt_merge
> pack $w.options.merge.no -side left
> radiobutton $w.options.merge.ff \
> - -text [mc "Fast Forward Only"] \
> + -text [mc "Fast-forward Only"] \
> -value ff \
> -variable @opt_merge
> pack $w.options.merge.ff -side left
Please leave git-gui out; (1) it is not managed by me and the patch should
be fed to Shawn separately, and (2) updating [mc] keystrings must need
matching updates to the translation file and the templates.
I also think this is a label string and the capitalization must be kept,
i.e. "Fast-Forward Only".
> diff --git a/git-merge-octopus.sh b/git-merge-octopus.sh
> diff --git a/git-pull.sh b/git-pull.sh
> diff --git a/git-rebase--interactive.sh b/git-rebase--interactive.sh
> diff --git a/git-rebase.sh b/git-rebase.sh
Ok.
> diff --git a/t/t1001-read-tree-m-2way.sh b/t/t1001-read-tree-m-2way.sh
> @@ -51,7 +51,7 @@ check_cache_at () {
> }
>
> cat >bozbar-old <<\EOF
> -This is a sample file used in two-way fast forward merge
> +This is a sample file used in two-way fast-forward merge
> tests. Its second line ends with a magic word bozbar
> which will be modified by the merged head to gnusto.
> It has some extra lines so that external tools can
Doesn't changing this change the actual test blob used? Do you know if
the test still passes when git is not broken?
The rest of the patches to t/ directory looked Ok.
> diff --git a/transport.c b/transport.c
> diff --git a/unpack-trees.c b/unpack-trees.c
Ok.
Thanks.
^ permalink raw reply
* Re: [PATCH v2 0/2] user-manual: new "getting started" section
From: Junio C Hamano @ 2009-10-25 3:08 UTC (permalink / raw)
To: Felipe Contreras
Cc: git, Michael J Gruber, Jonathan Nieder, J. Bruce Fields,
Hannu Koivisto, Jeff King, Wincent Colaiuta, Matthias Lederhofer
In-Reply-To: <94a0d4530910241316r3fc4136emd036d18aa45a4192@mail.gmail.com>
Felipe Contreras <felipe.contreras@gmail.com> writes:
>> I'm inclined to to discard the first patch.
>
> And you decided to mention that after many people including you, have
> agreed that it's a good idea?
This line of argument is wrong and counterproductive. Of course, after
reading what others said and thinking about it more myself, I can change
my mind based on their opinions. Otherwise there is no point in having
any mailing list discussion.
People propose changes, and two things can happen:
(1) I and others may think it is not a good idea, clarifying argument may
come from the original author and/or additional arguments defending
the change may come from others. People who thought it was not a
good idea may change their mind, and the patch gets accepted. git
becomes better.
If people cannot change their mind, it is useless to make supporting
arguments to nudge them to reconsider.
(2) I and others may think it is a good idea, a counterargument comes,
and people who originally thought it was a good idea may change their
mind, and the patch does not go in. git is saved from becoming
worse.
If people cannot change their mind, it is useless to make counter-
arguments to nudge them to reconsider.
Yes, I originally thought a "getting started" section may be a good idea.
There is no need to point it out to me.
But after I saw that the original author said "_if_ we have to do this,
keep it short", the comment made me question my previous assumption one
more time: is it really a good idea to add "getting started", and is it a
good idea to cover the config command in that section?
After re-reading the first thousand lines of the user manual, I realized
that the explanation was carefully laid out so that you do not have to be
taught "git config" in the beginning to be able to follow it. Now, after
applying your latest patch, if we do not have to teach "config" there,
what else is left in the section? --- Nothing.
What conclusion do you expect me to reach after such a consideration,
other than "then let's not have it"?
> If you read the results of the last git survey you'll see that the
> area that needs most improvement is the documentation.
Yes, I did read it, but what about it? You already know we both want to
have a good set of documentation.
Remember that "changing" and "improving" is different; some changes may
not necessarily be improvements. "It needs improving, so let's change it"
is not an argument. This isn't obviously limited to the documentation but
also applies to UI changes.
> Also I still
> see many people doing commits without configuring the user name and
> email properly and so I've tried very hard to improve the user manual
> to make it easier for them to understand they must do that.
The "unconfigured user.name is wrong" is the least of the problems for
people who start commiting without understanding the basic principles.
People may ask "how do I publish my changes", "how do I discard the
commit" and "how do I modify the commit two days ago", and teaching them
things like "reset HEAD^" and "rebase -i", without making them aware of
the implications will do disservice to them in the long run. That kind of
self-teaching is already done by people (and for doing so sometimes they
hurt themselves) by diving into man pages of individual commands before
understanding the distributedness and its implications, and my hope has
always been to keep the user-manual a document that teaches things in one
coherent and hopefully the most useful order.
The early part of the manual (the first thousand lines) does not talk
about making commits but lays out the groundwork for a good reason. And
in order to follow the current structure of the manual, you do not need to
be taught "config" as the first thing.
It is a totally different story if we are going to rewrite the manual in
such a way that we start from "hello world". I am not necessarily saying
it is a bad way to teach [*1*].
But the current "starting from a sightseer, while learning the basic
concepts like reachability and stuff, and then learn to build on top of
others' work" structure would also be a valid way to teach, and in that
presentation order, I do not think teaching "config" sits well at the
beginning.
[Footnote]
*1* Indeed, the book I did recently does just that, starting from a solo
user who develops on his own from scratch, and then uses another
repository as a back up repository, and then works on two different
machines with a repository each, still working solo no the same project.
After that working with other users collaboratively comes. If you teach in
that order, you have to cover config before you cover commit, which pretty
much means config is mentioned at the very beginning.
^ permalink raw reply
* Re: [PATCH v2 0/2] user-manual: new "getting started" section
From: J. Bruce Fields @ 2009-10-25 0:26 UTC (permalink / raw)
To: Felipe Contreras
Cc: Junio C Hamano, git, Michael J Gruber, Jonathan Nieder,
Hannu Koivisto, Jeff King, Wincent Colaiuta, Matthias Lederhofer
In-Reply-To: <94a0d4530910241316r3fc4136emd036d18aa45a4192@mail.gmail.com>
On Sat, Oct 24, 2009 at 11:16:51PM +0300, Felipe Contreras wrote:
> And let's not forget that the current text is broken for Windows users.
Just out of curiosity: do you have a list of what would need to be done
to make the manual work for windows users?
I haven't used any Windows/DOS commandline since, um, 1980-something, so
I'm a little clueless here.
--b.
^ permalink raw reply
* [PATCH] t7800-difftool: fix the effectless GIT_DIFFTOOL_PROMPT test
From: Markus Heidelberg @ 2009-10-24 23:39 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, David Aguilar, Markus Heidelberg
GIT_DIFFTOOL_PROMPT doesn't have any effect if overridden with --prompt.
Signed-off-by: Markus Heidelberg <markus.heidelberg@web.de>
---
t/t7800-difftool.sh | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/t/t7800-difftool.sh b/t/t7800-difftool.sh
index ebdccf9..fff6a6d 100755
--- a/t/t7800-difftool.sh
+++ b/t/t7800-difftool.sh
@@ -136,7 +136,7 @@ test_expect_success 'GIT_DIFFTOOL_PROMPT variable' '
GIT_DIFFTOOL_PROMPT=true &&
export GIT_DIFFTOOL_PROMPT &&
- prompt=$(echo | git difftool --prompt branch | tail -1) &&
+ prompt=$(echo | git difftool branch | tail -1) &&
prompt_given "$prompt" &&
restore_test_defaults
--
1.6.5.1.86.g7f7ff
^ permalink raw reply related
* Re: [PATCH] tar: on extract, -o is --no-same-owner
From: Denys Vlasenko @ 2009-10-24 23:32 UTC (permalink / raw)
To: Andreas Schwab; +Cc: Bernhard Reutner-Fischer, Junio C Hamano, busybox, git
In-Reply-To: <m2ocnxt6jl.fsf@whitebox.home>
[-- Attachment #1: Type: text/plain, Size: 1013 bytes --]
On Saturday 24 October 2009 12:44, Andreas Schwab wrote:
> Bernhard Reutner-Fischer <rep.dot.nop@gmail.com> writes:
>
> > On Sat, Oct 24, 2009 at 11:49:10AM +0200, Andreas Schwab wrote:
> >>Bernhard Reutner-Fischer <rep.dot.nop@gmail.com> writes:
> >>
> >>> I suppose xf - -o would work?
> >>
> >>Isn't that the same as 'xfo -'?
> >
> > Not really (if you do not permute the arguments which we don't in
> > busybox, for size reasons).
>
> There is no argument permutation. The traditional argument parsing of
> tar does not cluster option letters with option arguments.
>
> Of course, just using 'xof -' will work around this busybox bug.
From my side, I prefer to squash that busybox bug.
This is the second time people complain about it,
so it is a reoccurring problem.
The attached patch has been pushed to busybox git.
function old new delta
tar_main 702 751 +49
--
vda
[-- Attachment #2: 1.patch --]
[-- Type: text/x-diff, Size: 1316 bytes --]
diff -d -urpN busybox.0/archival/tar.c busybox.1/archival/tar.c
--- busybox.0/archival/tar.c 2009-10-20 22:11:09.000000000 +0200
+++ busybox.1/archival/tar.c 2009-10-25 01:27:38.000000000 +0200
@@ -841,6 +841,33 @@ int tar_main(int argc UNUSED_PARAM, char
#if ENABLE_FEATURE_TAR_LONG_OPTIONS
applet_long_options = tar_longopts;
#endif
+#if ENABLE_DESKTOP
+ if (argv[1][0] != '-') {
+ /* Compat:
+ * 1st argument without dash handles options with parameters
+ * differently from dashed one: it takes *next argv[i]*
+ * as paramenter even if there are more chars in 1st argument:
+ * "tar fx TARFILE" - "x" is not taken as f's param
+ * but is interpreted as -x option
+ * "tar -xf TARFILE" - dashed equivalent of the above
+ * "tar -fx ..." - "x" is taken as f's param
+ * getopt32 wouldn't handle 1st command correctly.
+ * Unfortunately, people do use such commands.
+ * We massage argv[1] to work around it by moving 'f'
+ * to the end of the string.
+ * More contrived "tar fCx TARFILE DIR" still fails,
+ * but such commands are much less likely to be used.
+ */
+ char *f = strchr(argv[1], 'f');
+ if (f) {
+ while (f[1] != '\0') {
+ *f = f[1];
+ f++;
+ }
+ *f = 'f';
+ }
+ }
+#endif
opt = getopt32(argv,
"txC:f:Opvk"
IF_FEATURE_TAR_CREATE( "ch" )
^ permalink raw reply
* Re: [ANNOUNCE] Stacked Git 0.15
From: Jakub Narebski @ 2009-10-24 23:20 UTC (permalink / raw)
To: Catalin Marinas; +Cc: Git Mailing List
In-Reply-To: <b0943d9e0910241541n7b1091ecp6b21fa896405afa0@mail.gmail.com>
Catalin Marinas <catalin.marinas@gmail.com> writes:
> StGit is a Python application providing functionality similar to Quilt
> (i.e. pushing/popping patches to/from a stack) on top of Git. These
> operations are performed using Git commands, and the patches are
> stored as Git commit objects, allowing easy merging of the StGit
> patches into other repositories using standard Git functionality.
>
> Download: http://download.gna.org/stgit/stgit-0.15.tar.gz
> Main repository: git://repo.or.cz/stgit.git
> Project homepage: http://www.procode.org/stgit/
> Mailing list: git@vger.kernel.org (please use "StGit" in the subject)
> Bug tracker: https://gna.org/bugs/?group=stgit
Is there RPM or SRPM (src.rpm) available somewhere? Or does tarball
include *.spec file, or an rpm target?
--
Jakub Narebski
Poland
ShadeHawk on #git
^ permalink raw reply
* [ANNOUNCE] Stacked Git 0.15
From: Catalin Marinas @ 2009-10-24 22:41 UTC (permalink / raw)
To: Git Mailing List, Linux Kernel Mailing List
StGit is a Python application providing functionality similar to Quilt
(i.e. pushing/popping patches to/from a stack) on top of Git. These
operations are performed using Git commands, and the patches are
stored as Git commit objects, allowing easy merging of the StGit
patches into other repositories using standard Git functionality.
Download: http://download.gna.org/stgit/stgit-0.15.tar.gz
Main repository: git://repo.or.cz/stgit.git
Project homepage: http://www.procode.org/stgit/
Mailing list: git@vger.kernel.org (please use "StGit" in the subject)
Bug tracker: https://gna.org/bugs/?group=stgit
The main changes since release 0.14.3 are
- New core infrastructure for repository operations, including
+ Infinite undo/redo operations and corresponding commands.
+ Automatic rollback of changes following a failed operation
(using transactions)---this ensures that StGit commands either
succeed or do nothing. Previously, every commands had its own
ad hoc implementation of this.
- Some commands were added, including
+ "stg squash", for combining two or more patches into one.
+ "stg publish", for maintaining merge-friendly branches (which
are not rebased).
+ "stg prev/next" for printing the name of the previous or next
patch in the series.
- The commands "stg add", "stg rm", "stg cp", and "stg resolved"
were removed, since there are corresponding Git equivalents.
- The "stg import" and "stg fold" commands support the "-p N" option
for stripping leading slashes from diff paths.
- The "stg import" and "stg fold" commands support the "--reject"
option for leaving rejected hunks in corresponding *.rej files.
- New patch identification syntax: <branch>:<patch> (see
documentation for the "stg id" command).
- Autosigning of imported patches when "sign.autosign" configuration
option is set.
- A powerful Emacs mode for StGit was added to the "contrib"
directory. It displays the patch stack in an Emacs buffer, and can
handle all common StGit tasks.
- Improved bash tab-completion, automatically generated from the stg
command definitions.
- Man pages and an improved tutorial.
Special thanks go to Karl Wiberg for the hard work done on the new
StGit features, to Catalin Marinas for many new features and bugfixes,
and to David Kågedal and Gustav Hållberg for the Emacs mode.
Credits:
Karl Wiberg (192):
Let parse_patch take a string instead of a file parameter
Make generic --message/--file/--save-template flags
Name the exit codes to improve legibility
Emacs mode: Show keybindings when user presses "h" or "?"
Emacs mode: Add an explanatory header
Emacs mode: Makefile for building stgit.el
Emacs mode: push/pop next patch, not patch at point
Emacs mode: Let "P" push or pop patch at point
Emacs mode: Bind "G" to "stg goto"
Emacs mode: show patches' short description
Write removed fields for backwards compatibility
Nicer conflict markers
Better error message if merge fails
Fix "stg resolved" to work with new conflict representation
Refactoring: pass more than one file to resolved()
We keep the different stages of a conflict in the index now
Remove "stg add"
Remove "stg rm"
Remove "stg cp"
New StGit core infrastructure: repository operations
Write metadata files used by the old infrastructure
Upgrade older stacks to newest version
Let "stg clean" use the new infrastructure
Add "stg coalesce"
Let "stg applied" and "stg unapplied" use the new infrastructure
Teach the new infrastructure about the index and worktree
Let "stg clean" use the new transaction primitives
Let "stg goto" use the new infrastructure
Convert "stg uncommit" to the new infrastructure
New infrastructure: Make sure that the branch is initialized
Expose transaction abort function
stg coalesce: Support --file and --save-template
Set exit code to 3 on merge conflict
Convert "stg commit" to new infrastructure
Make "stg commit" fancier
Test that "stg goto" can be called from a subdirectory
Make "stg goto" subdirectory safe
Don't keep old committer when rewriting a commit
Homogenize buffer names
Remove unused default values
Refactor --diff-opts handling
Create index and worktree objects just once
Wrap excessively long line
Eliminate temp variable that's used just once
Simplify editor selection logic
Let the caller supply the diff text to diffstat()
Don't clean away patches with conflicts
Don't check out files if we don't have index+workdir
Make documentation less confusing
Reduce number of backslashes by using raw strings
Let "stg show" use the unified --diff-opts handling
Read default diff options from the user's config
Teach new infrastructure about the default author and committer
Teach new infrastructure to apply patches
Teach new infrastructure to diff two trees
Parse the date instead of treating it as an opaque string
Convert "stg edit" to the new infrastructure
Emacs mode: It's possible to edit unapplied patches now
Remove unused data field
Emacs mode: change "stg repair" binding
Use a special exit code for bugs
Make sure patches with no parents have an empty list of parents
Try uncommitting a commit with not exactly one parent
Make sure that we only uncommit commits with exactly one parent
New test: conflicting push in dirty worktree
Handle failed pushes differently depending on cause
Merge branch 'stable' into stable-master-merge
Don't both change directory and set GIT_WORK_TREE
Log environment and cwd as well as the actual command
emacs mode: handle "stg status" output with #
If a patch is not changed when pushing, reuse the same commit object
Handle commandline parsing errors gracefully
Use hardcoded author and committer names in tests
Steal more test-lib.sh updates from git
Get rid of backticks in test-lib.sh
Use test_cmp instead of diff -u in the test suite
Remove "stg" from start of log messages
Import version to a separate namespace
Better StGit version tracking
Emacs mode: automatically cd up to root of worktree
Try the built-in version string before git-describe
Disable patchlog test for "stg new"
Convert "stg new" to the new infrastructure
Refactor --author/--committer options
Let "stg new" support more message options
Emacs mode: use "stg new --file"
Convert "stg delete" to the new infrastructure
Emacs mode: delete patches
Prevent most commands from running when there are conflicts
Add property with a list of all patch names
Merge branch 'stable' into stable-master-merge
Wrap the text of error messages
Some API documentation for the new infrastructure
Fix typo
Try "stg sink" without applied patches
Fix "stg sink" with no applied patches (bug 11887)
Merge branch 'stable' into stable-master-merge
Test "stg status" with renames
Don't allow extra diff options with "stg status"
Merge branch 'stable'
Test "stg status" with -M in stgit.diff-opts
Test for specific exit code
Test for "stg edit"
Test that we can add a new file to a non-topmost patch with refresh -p
Merge branch 'stable'
Test for exit code with command_error()
stg uncommit should never touch the branch head
Make sure that stg uncommit doesn't touch the branch head
Fix uncommit status message
Discard stderr output from git apply if the caller wants
Do simple in-index merge with diff+apply instead of read-tree
Reuse the same temp index in a transaction
Library functions for tree and blob manipulation
Teach stgit.lib.transaction about hidden patches
Test operations on hidden patches
stg goto: Handle hidden patches more gracefully
Add utility function for reordering patches
Add some performance testing scripts
Log subprocess activity to a file
Show full command in subprocess profiling
Log subprocess calls during performance testing
Global performance logging
Add some tests of refreshing removed files
Fix some remaining old-style stg id calls
Don't use the dashed for of git commands
Merge branch 'stable'
Remove unneeded import
Refactoring: move shared options to their own module
Auto-generate man pages for all StGit commands
asciidoc.conf: Steal updates from git
Generate command lists automatically
Write to a stack log when stack is modified
New command: stg reset
Log conflicts separately
Log conflicts separately for all commands
Add a --hard flag to stg reset
Don't write a log entry if there were no changes
Move stack reset function to a shared location
New command: stg undo
New command: stg redo
Log and undo external modifications
Test that stg coalesce handles head != top gracefully
Check for top == head at the start of every transaction
Make "stg log" show stack log instead of patch log
Convert "stg refresh" to the new infrastructure
New refresh tests
Remove --undo flags from stg commands and docs
Refactor stgit.commands.edit
Invoke the correct interactive editor
Implement "stg refresh --edit" again
Automatic bash completion
Untabify
Add myself to the AUTHORS file
Remove misleading "stg delete" documentation
Add a new flag, --spill, to stg delete
Test the new stg delete --spill flag
Fix typo
Merge branch 'stable'
Remove unused variable
Remove TODO items that have already been addressed
We're half-way there with the separate indexes
Add 1.0 TODO items from recent discussion by private mail
Refresh the main stg man page
Refresh and expand the tutorial (not finished)
Tutorial: Talk about conflicts when introducing StGit
Tutorial: Explain diffs a little bit better
Tutorial: Cover "stg mail"
Tutorial: Write about rebasing
Tutorial: Importing patches
stg series: Explain the list format better
stg files: Don't write just an empty line
Steal Documentation/SubmittingPatches from Git
SubmittingPatches: adapt to StGit
Return None instead of crashing on undefined integer config items
Merge branch 'stable'
Rename "stg coalesce" to "stg squash"
stg squash: Improve documentation
Documentation: Ignore generated .xml files
Documentation: Rename link macros
Newer gits return 128 when git config --{rename,remove}-section fails
Transaction.push_patch(): Set self.head only when we have a merge conflict
Pass "git config" flags in the right order
Karl got married
t2800: Adapt to changes in git's conflict markers
Work around performance bug in subprocess.Popen.communicate()
Merge branch 'proposed' of git://github.com/gustavh/stgit
Release notes: Turn the 0.15-rc1 release notes into 0.15 release notes
Release notes: Reformat for better legibility, and update
Documentation: Rename remaining link macros
Tutorial: Use the new StGit repo URL in clone example
When reading a config value, pick the last value, not the first
squash: Make commit message editing more convenient
Catalin Marinas (131):
Re-add the interactive merge
Don't assume there is always a stage 2 in git.get_conflicts
Remove multiple stages returned by git.ls_files
Remove unused git functions like add, rm, copy
Remove a newline from the e-mail template
Don't set the default authdate if none specified
Allow pick to import multiple patches
Check for unnecessary push/pop in 'float'
Allow the synchronisation of the unapplied patches
Modify 'series' to use '#' instead of '|'
Set umask to 0022 during the setup.py execution
Refuse to send empty patches
Add a boundary to parse_patches in pick.py
Fix sync to push the popped patches back after sync'ing
Remove the reordering side-effect of the latter sync changes
Allow picking of one commit id
Merge branch 'stable'
Merge branch 'stable'
Merge branch 'stable'
Merge branch 'stable'
Refactor the Commitdata class to CommitData
Rewrite the "series" command for the new infrastructure
Allow the Repository.get_stack() to get a default argument
Fix error in status.py when calling git.resolved
Convert "top" to the new infrastructure
Convert "export" to the new infrastructure
Merge branch 'stable'
Merge commit 'kha/safe'
Fix the parse_patches() function to work with tuples
Allow stack.patchorder.all to return hidden patches
Rename Repository.head to Repository.head_ref
Create a git.Branch class as ancestor of stack.Stack
Add stack creation and initialisation support to lib.Stack
Convert "init" to the new StGIT infrastructure
Add test_patches target to Makefile
Merge branch 'stable'
Fix export error introduced by recent convertion
Allow e-mails to be sent with the Unix sendmail tool
Implement a new patch identification scheme and id command
Convert git_id() to the new id format
Remove the applied/unapplied commands
Remove the duplicate utils.strip_leading function
Fix the importing of config in series.py
Fix import to work properly in subdirectories
Merge branch 'stable'
Do not crash if a patch log ref is missing
Autosign newly created patches
Fix the sink command for various test cases
Merge branch 'stable'
Use --diff rather than --patch in log.py
Fix "show" to allow multiple branch:patch arguments
Change e-mail user agent header to StGit
Add parse_patches boundary in the delete.py file
Remove the --committer options
Remove e-mail address duplicates
Refresh of remove-e-mail-address-duplicat
Allow pick --fold to work without applied patches
Generate a different patch name if it already exists
Add 'pick' test script
Merge branch 'proposed'
Display (empty) when appropriate for the goto command
Fix the HEAD updating during a conflicting push (bug #12609)
s/GIT/Git/ in the README
Add "tags" target to Makefile
Do not append a new line to the backwards compat files (bug #12656)
Print conflict details with the new infrastructure (bug #11181)
Merge branch 'proposed'
Fix the patch argument parsing for the "show" command
Pass the diff flags when statistics are required
Merge branch 'stable'
Add --file option to pick
Check for local changes with "goto"
Add mergetool support to the classic StGit infrastructure
Add automatic git-mergetool invocation to the new infrastructure
Convert "sink" to the new infrastructure
Convert "float" to the lib infrastructure
Use a default "hidden" argument in StackTransaction.reorder_patches
Add the --merged option to goto
Convert "pop" to the lib infrastructure
Convert "push" to the lib infrastructure
Show "Pushing <patch>...done" when pushing a patch
Show some progress information when checking for upstream merges.
Do not sleep after the last patch sent by e-mail
Convert 'clone' to the use stgit.lib
Convert 'hide' to the lib infrastructure
Convert 'unhide' to the lib infrastructure
Reinstate the --annotate option for refresh
Add the log --clear option
Add support for merge-friendly branches
Add "stg id" support for "{public}" ref
Use the default git colouring scheme rather than specific scripts
Remove the resolved command
Improve the "publish" merge message to give slightly more information
Only allow publishing to refs/heads/*
Rename out.start() to out.inf() in the publish command
Add --reject option to import
Add --stat option to show
Do not replace '-' with '.' in the version string
Merge commit 'kha/safe'
Set the LESS environment if the pager is 'less'
Fix the import --url command
Merge commit 'kha/safe'
Handle multi-line Subject header better
Improve the description/diff splitting when parsing patches
Only get the first line from 'git describe --all'
Reverse commit 9876a650 - return the first line from git describe
Add release notes file
Add the next/prev commands to the RELEASENOTES file
Add stg-build, stg-dbg and RELEASENOTES to the MANIFEST.in file
Merge commit 'kha/safe'
Import git show output easily
Merge commit 'kha/safe'
Add import -p option
Preserve the given author date during import
Generate binary diffs by default
Remove the 'fail_dump' argument to git.apply_patch()
Add the --reject option to fold
Do not create an empty patch if import failed without --reject
Add the -p option to fold
Autosign imported patches
Allow importing of 'application/octet-stream' attachments
Allow 'stg diff ..<commit>'
Delete the hidden patches as well when deleting a branch
Fast-forward the published head when possible
Do not delete the builtin_version.py file after setup
Ignore the git-config exit code
Do not use stdout instead of stderr
Update the RELEASENOTES file with latest changes
The '--file' option for 'new' should show 'FILE' rather than 'MESSAGE'
Pick --revert option (formerly --reverse)
Slightly modify the "publish" command description
Gustav Hållberg (101):
stgit.el: Compact code for populating stgit-mode-map
stgit.el: Add 'q' for stgit-quit
stgit.el: Add 'm' as alias for stgit-mark
stgit.el: Add stgit-unmark-down
stgit.el: Fix some indentation
stgit.el: Add stgit-git-status
stgit.el: Fix working directory bug in stgit-new
stgit.el: Unify help text formatting
stgit.el: Add flag to signal errors in stgit-patch-at-point
stgit.el: Automatically update git-status buffer when necessary
stgit.el: Add support for showing which files are affected by a patch
stgit.el: Add an stgit customization group
stgit.el: Use 'git diff-stat' to show files in a patch
Add '--help' to tab completion for all commands
stg mail: Improve error message for unknown sender identity
stgit.el: Also show mode and type changes of files in patches
man pages: Bugfixed man pages for --sign and --ack flags; e.g.,
for stg-new
stgit.el: Make prefix argument to stgit-new add a Signed-off-by: line
stgit.el: Bugfix stgit-unmark-down on the last patch
stgit.el: Fix some too wide lines
stgit.el: Add some missing help texts
stgit.el: Canonicalize some error messages
stgit.el: Consistently use symbols rather than strings for patch names
stgit.el: Make single file diff buffer read-only
stgit.el: Include stat summary in patch diff
stgit.el: Add message when there are no patches in the series
stgit.el: Indicate empty patches
stgit.el: Minor beautification
stgit.el: Add optional count argument to stgit-commit
stgit.el: make stgit-delete with prefix argument spill patch
contents to index
stgit.el: Add "B" for stgit-branch
stgit.el: Manually draw/erase the mark in stgit-{add,remove}-mark
stgit.el: Clarify documentation of stgit-capture-output
stgit.el: Add "M" for stgit-move-patches
stgit.el: Run 'git show' with -M to detect renames when showing
entire patch
stgit.el: Break out stgit-sort-patches to a separate function
for future reuse
stgit.el: Sort patches correctly before merging them in stgit-squash
stgit.el: Handle errors in first phase of stgit squash
stgit.el: Bind line movement keys in a sane way
stgit.el: Correct documentation for stgit-insert-patch-files
stgit.el: Remove unused variable stgit-work-ewoc
stgit.el: Refactor: remove unused argument to two functions
stgit.el: Run "git rm" with "-q" to reduce spam
stgit.el: Bugfix moving symlinks to/from index
stgit.el: Make stgit-{index,worktree}-node buffer local
stgit new: Do not open editor if --save-template was specified
stgit.el: Add stgit-branch-name-face
stgit.el: Move stgit-{un,}commit to \C-c\C-{u,c}
stgit.el: Add "U" for stgit-revert-file
stgit.el: Change key binding for stgit-repair from "R" to "\C-u g"
stgit.el: Add "R" for stgit-resolve-file
stgit.el: Refresh from work tree when index is empty
stgit.el: Refactor: add stgit-find-copies-harder-diff-arg helper function
stgit.el: Allow showing patch on Index and Work tree
stgit.el: Open the destination file on applied renames or copies
stgit.el: Forbid stgit-{delete,edit,mark,rename} on index and work tree
stgit.el: Add customizable face for "Index" and "Work tree" titles
stgit.el: Make it configurable where to show index and work tree
stgit.el: Default to expanding index and work tree
stgit.el: Garbage collect selected patches on reload
stgit.el: Document stgit-select properly
stgit.el: Allow operating on the end of each line
stgit.el: Refactor: simplify temporary marker handling
stgit.el: Fix face "spilling" in some places
stgit.el: Refactor: simplify stgit-patch-pp a bit
stgit.el: Add "t i/u" for showing files ignored by or unknown to git
stgit.el: Move point properly after stgit-{file-toggle-index,reload}
stgit.el: Handle negative argument to stgit-{un,}commit
stgit.el: Rename stgit-expand-find-copies-harder to
stgit-find-copies-harder
stgit.el: Handle unmerged files better
stgit.el: Add "d" for a few diff commands, similar to git.el
stgit.el: Ignore space in diff with prefix argument
stgit.el: Set patch names to be word syntax throughout
stgit.el: Add stgit-redo as C-c C-_ and C-c C-/
stgit.el: Verify that we're running on Emacs 22 or later
stgit.el: Default to showing index and work tree
stgit.el: Bugfix listing copied/renamed files
stgit.el: Abbreviate renames/copies with common prefix/suffix
stgit.el: Move point correctly after stgit-revert-file
stgit.el: Move point in sane way after stgit-file-toggle-index on renames
stgit.el: Allow moving ignored files to index
stgit.el: Minor documentation corrections
stgit.el: Bugfix mode change display
stgit.el: Add better help text for stgit-mode
stgit.el: Add C-c C-b for stgit-rebase
stgit.el: Improve use of def{group,custom,face}
stgit.el: Bugfix of stgit-move-patches to top of stack
stgit.el: Fix problem where standard-output isn't bound correctly
stgit.el: Bugfix "P" when point is not on a patch line
stgit.el: Fix some incorrect indentation
stgit.el: Add +/- to expand/collapse selected patches
stgit.el: Allow revert on index and work tree
stgit.el: Allow toggle-index on index and work tree
stgit.el: Verify we're in stgit-mode before running commands
stgit.el: Add stgit-toggle-mark
stgit.el: Add menu bar menu
stgit.el: Add flags to stgit-patches-marked-or-at-point
stgit.el: Consistently use "marked" about marked patches
stgit.el: Make sure "M" retains the order of the patches
stgit.el: Allow "P" to operate on all marked files
stgit.el: Improve stgit-mode help text slightly
David Kågedal (49):
Added --save-template flag to edit command
Treat filename '-' as stdin/stdout in edit
Add an StGit mode for emacs
Emacs mode: Improve the output buffer state
Emacs mode: Bind n and p
Emacs mode: add stgit-repair
Emacs mode: added stgit-commit and stgit-uncommit
Emacs mode: Add stgit-edit command
Emacs mode: added fontification
Emacs mode: Added stgit-new
Check bottom and invariants
Remove the 'bottom' field
Remove the 'top' field
Split git.merge into two functions
Leave working dir and index alone after failed (conflicting) push
Added a test case to check what happens when push finds a conflict
Simplify merge_recursive
Use the output from merge-recursive to list conflicts
Ask git about unmerged files
Emacs mode: Add mark command
Emacs mode: coalesce command
Add support for initializing a branch for stgit from Emacs.
stgit.el: Add numeric prefix argument to push and pop commands.
stgit.el: Adapt to new output from stg series.
stgit.el: Add undo command
stgit.el: Try to make the point stay on the coalesced patch
stgit.el: Rename stgit-refresh to stgit-reload
stgit.el: Move stgit-rename to C-c C-r
stgit.el: Add the stgit-refresh command
stgit.el: Show running commands
Use separate column for zero in output of stg series -e
stgit.el: Expand or collapse only the patch at point, instead of
rerunning stg-reload.
Add a --set-tree flag to stg push
stgit.el: Use declare to hint the debugger and indentation
stgit.el: Remove the unused allow-file parameter to stgit-patch-at-point
stgit.el: Rename stgit-toggle-patch-file-list to stgit-select-patch
stgit.el: Use an 'entry-type text property
stgit.el: Use a defstruct to store patch data
stgit.el: Use ewoc to keep track of the patch list.
stgit.el: Invalidate ewoc node when marking or unmarking instead
of modifying buffer directly
stgit.el: Get rid of the stgit-patchsym property
stgit.el: Refactor file list formatting
stgit.el: Use ewoc to keep track of the file list.
stgit.el: Add work tree and index as pseudo-patches
stgit.el: Add the stgit-file-toggle-index command
stgit.el: Add stgit-toggle-worktree to toggle visibility of
index and working tree
stgit.el: Only refresh the relevant parts when the index or
worktree changes
stgit.el: Add stgit-new-and-refresh command
Escape patch name when creating regexp
Daniel White (11):
Fixed default install location
Fix Makefile to correctly pass prefix option
Remove variables regarding section 7 man pages
Fix default install location for manpages
Add install-doc target to makefile
Add install-html target to makefile
Remove installation of documentation from setup.py
Updated INSTALL with documentation of Makefile
debian/rules: take advantage of new build targets
Remove dashed form of git command still in comment
Fixes for auto-generation of man pages
Samuel Tardieu (4):
Find CmdException in common
Do not insert an empty line before the diffstat info
Do not mess-up with commit message formatting when sending email
Load the whole config at once and cache it for future use
Clark Williams (3):
Patch to allow import from compressed files (gzip and bzip2)
Ignore compiled elisp files
Teach "stg import" to import patch series from tar archives
Peter Oberndorfer (3):
Don't mention removed "stg refresh" options
replace "git repo-config" usage by "git config"
Add an --index option to "stg refresh"
Alex Chiang (2):
Better "stg rebase" help text
fix stg mail %(shortlog)s order
Dan Williams (2):
mail: add some commonly used tags to --auto
fix export -s
Hannes Eder (2):
fix "stg float -s FILE" for FILE != "-"
Add 'stg prev' and 'stg next'
Miklos Vajna (2):
setup.py: don't try to import stgit.run before the python version check
setup.py: fix error message when running with python-2.3
Onno Kortmann (2):
Simple rename of top-most patch
Test the 'stg rename' command
Pavel Roskin (2):
Fix "stg edit --sign"
Add test to ensure that "stg clean" preserves conflicting patches
Shinya Kuribayashi (2):
diffcol.sh: Use /bin/bash explicitly
stgit-completion.bash: Remove add/applied/cp/rm/unapplied
Ted Pavlic (2):
Modify bash completion to support help, version, and copyright.
Make bash completion fail to bashdefault before default completion.
Angus Salkeld (1):
stg mail crashes when there is no patch description
Chris Packham (1):
Re-send [StGit BUG/PATCH] config.py: fix unset
Jakob Stoklund Olesen (1):
Never skip rebase
Jason Green (1):
Patch to clarify the "unsolved conflicts" message in Stacked Git
Pete Wyckoff (1):
stgit.namelength is an integer
Toby Allsopp (1):
Fix "stg branch --delete" on a nonexistent branch
--
Catalin
^ permalink raw reply
* Re: [PATCH 2/2] gitk: Provide a default mc function if msgcat is not available
From: Junio C Hamano @ 2009-10-24 22:08 UTC (permalink / raw)
To: Bernt Hansen; +Cc: git, Paul Mackerras
In-Reply-To: <1256415640-10328-3-git-send-email-bernt@norang.ca>
Bernt Hansen <bernt@norang.ca> writes:
> Msgcat is available since Tcl 8.1. For really old versions of Tcl
> provide a default mc that just returns the text untranslated. This
> allows the Tcl version check to return the error in a window instead
> of making Tcl abort when attempting to load the msgcat package.
>
> Signed-off-by: Bernt Hansen <bernt@norang.ca>
> ---
> I'm not sure if we care about Tcl versions older than 8.1 but this at
> least shows the error in the window with the [OK] button.
Both patches sound very sensible.
^ permalink raw reply
* [PATCH 2/2] gitk: Provide a default mc function if msgcat is not available
From: Bernt Hansen @ 2009-10-24 20:20 UTC (permalink / raw)
To: git; +Cc: Paul Mackerras, Bernt Hansen
In-Reply-To: <1256415640-10328-1-git-send-email-bernt@norang.ca>
Msgcat is available since Tcl 8.1. For really old versions of Tcl
provide a default mc that just returns the text untranslated. This
allows the Tcl version check to return the error in a window instead
of making Tcl abort when attempting to load the msgcat package.
Signed-off-by: Bernt Hansen <bernt@norang.ca>
---
I'm not sure if we care about Tcl versions older than 8.1 but this at
least shows the error in the window with the [OK] button.
gitk | 13 +++++++++----
1 files changed, 9 insertions(+), 4 deletions(-)
diff --git a/gitk b/gitk
index d4cd566..bff891d 100755
--- a/gitk
+++ b/gitk
@@ -11019,10 +11019,15 @@ if { [info exists ::env(GITK_MSGSDIR)] } {
## Internationalization (i18n) through msgcat and gettext. See
## http://www.gnu.org/software/gettext/manual/html_node/Tcl.html
-package require msgcat
-namespace import ::msgcat::mc
-## And eventually load the actual message catalog
-::msgcat::mcload $gitk_msgsdir
+if {[catch {package require msgcat}]} {
+ proc mc {arg} {
+ return $arg
+ }
+} else {
+ namespace import ::msgcat::mc
+ ## And eventually load the actual message catalog
+ ::msgcat::mcload $gitk_msgsdir
+}
# Check that Tcl/Tk is recent enough
if {[catch {package require Tk 8.4} err]} {
--
1.6.5.1.69.g36942
^ permalink raw reply related
* [PATCH 1/2] gitk: Initialize msgcat before first use
From: Bernt Hansen @ 2009-10-24 20:20 UTC (permalink / raw)
To: git; +Cc: Paul Mackerras, Bernt Hansen
In-Reply-To: <1256415640-10328-1-git-send-email-bernt@norang.ca>
The error text generated when your version of Tcl is too old is
translated with msgcat (mc) before msgcat is initialized. This
causes Tcl to abort with:
Error in startup script: invalid command name "mc"
We now initialize msgcat first before we check the Tcl version. Msgcat
is available since Tcl 8.1.
Signed-off-by: Bernt Hansen <bernt@norang.ca>
---
gitk | 41 +++++++++++++++++++++--------------------
1 files changed, 21 insertions(+), 20 deletions(-)
diff --git a/gitk b/gitk
index a0214b7..d4cd566 100755
--- a/gitk
+++ b/gitk
@@ -11004,7 +11004,27 @@ proc get_path_encoding {path} {
return $tcl_enc
}
-# First check that Tcl/Tk is recent enough
+# First setup up mc for translating text
+## For msgcat loading, first locate the installation location.
+if { [info exists ::env(GITK_MSGSDIR)] } {
+ ## Msgsdir was manually set in the environment.
+ set gitk_msgsdir $::env(GITK_MSGSDIR)
+} else {
+ ## Let's guess the prefix from argv0.
+ set gitk_prefix [file dirname [file dirname [file normalize $argv0]]]
+ set gitk_libdir [file join $gitk_prefix share gitk lib]
+ set gitk_msgsdir [file join $gitk_libdir msgs]
+ unset gitk_prefix
+}
+
+## Internationalization (i18n) through msgcat and gettext. See
+## http://www.gnu.org/software/gettext/manual/html_node/Tcl.html
+package require msgcat
+namespace import ::msgcat::mc
+## And eventually load the actual message catalog
+::msgcat::mcload $gitk_msgsdir
+
+# Check that Tcl/Tk is recent enough
if {[catch {package require Tk 8.4} err]} {
show_error {} . [mc "Sorry, gitk cannot run with this version of Tcl/Tk.\n\
Gitk requires at least Tcl/Tk 8.4."]
@@ -11096,25 +11116,6 @@ if {[tk windowingsystem] eq "aqua"} {
set ctxbut <Button-3>
}
-## For msgcat loading, first locate the installation location.
-if { [info exists ::env(GITK_MSGSDIR)] } {
- ## Msgsdir was manually set in the environment.
- set gitk_msgsdir $::env(GITK_MSGSDIR)
-} else {
- ## Let's guess the prefix from argv0.
- set gitk_prefix [file dirname [file dirname [file normalize $argv0]]]
- set gitk_libdir [file join $gitk_prefix share gitk lib]
- set gitk_msgsdir [file join $gitk_libdir msgs]
- unset gitk_prefix
-}
-
-## Internationalization (i18n) through msgcat and gettext. See
-## http://www.gnu.org/software/gettext/manual/html_node/Tcl.html
-package require msgcat
-namespace import ::msgcat::mc
-## And eventually load the actual message catalog
-::msgcat::mcload $gitk_msgsdir
-
catch {source ~/.gitk}
font create optionfont -family sans-serif -size -12
--
1.6.5.1.69.g36942
^ permalink raw reply related
* [PATCH 0/2] gitk: Fix error display when Tcl is too old
From: Bernt Hansen @ 2009-10-24 20:20 UTC (permalink / raw)
To: git; +Cc: Paul Mackerras, Bernt Hansen
The following patch series cleans up error message reporting when your
version of Tcl is too old.
The old code checked the Tcl version first and then tried to report
the error with show_error. show_error uses msgcat for translation but
msgcat is not yet initialized when we are checking the Tcl version
requirement.
The first patch moves the initialization of msgcat before the check
for the Tcl version. This version will fail is msgcat is not
available.
The second patch handles the case where the msgcat package is not
available by providing a default mc procedure than just returns the
argument text unchanged (essentially bypassing message text
translation).
This lets us continue to use show_error as-is.
Bernt Hansen (2):
gitk: Initialize msgcat before first use
gitk: Provide a default mc function if msgcat is not available
gitk | 46 ++++++++++++++++++++++++++--------------------
1 files changed, 26 insertions(+), 20 deletions(-)
^ permalink raw reply
* Re: [PATCH v2 0/2] user-manual: new "getting started" section
From: Felipe Contreras @ 2009-10-24 20:16 UTC (permalink / raw)
To: Junio C Hamano
Cc: git, Michael J Gruber, Jonathan Nieder, J. Bruce Fields,
Hannu Koivisto, Jeff King, Wincent Colaiuta, Matthias Lederhofer
In-Reply-To: <7vr5ss64e5.fsf@alter.siamese.dyndns.org>
On Sat, Oct 24, 2009 at 9:19 PM, Junio C Hamano <gitster@pobox.com> wrote:
> Junio C Hamano <gitster@pobox.com> writes:
>
>> Felipe Contreras <felipe.contreras@gmail.com> writes:
>>
>>> Reworded the getting started section based on comments from Michael J Gruber,
>>> Jonathan Nieder and Junio C Hamano.
>>
>> Hmm, I thought JBF also had some input...
>
> Ah, nevermind. Yes, he did have input, and I tend to agree with him, and
> more importantly trust his judgement on the manual.
JBF said this[1]:
If we have to do this, just keep it short....
And I am trying to keep it short.
> I think a "Getting started" section that only covers "git config" looks
> way out of place in the beginning of this document.
Now you are saying that the fact that it's short is a bad thing? That
goes against to what JBF said.
And let's not forget your previous comments
[2]: I think a "getting started" section near the beginning of the manual is a
good idea (and ll.40- is a very early part of the manual).
[3]: I actually wish this section appeared a lot earlier in the document, but
that is a separate issue.
> Manuals by other people that teach "here is how you would do a hello-world
> repository" would want to teach user.name before reaching that point, but
> because the user-manual is written in such a way that it first introduces
> concepts to understand what is going on without changing anything, we do
> not have much need user.name until it gets to "Developing with git"
> section.
>
> "Many people prefer to teach it this way" does not justify "everybody must
> teach it this way" an iota, when teaching "config user.name" upfront will
> fit the flow of how they teach but does not fit the flow of how this
> manual teaches [*1*].
Nobody argued that "everybody must teach it this way", the argument
was that most people find it easier, and considering the section is
about "developing with git" it is sensible to avoid burdening the
reader with concepts that don't pertain to the objective at hand,
which is getting them to configure their user.
And let's not forget that the current text is broken for Windows users.
> I'm inclined to to discard the first patch.
And you decided to mention that after many people including you, have
agreed that it's a good idea?
> The point of the original text the second patch touches was to show how
> simple the contents of the configuration file is and give the users that
> there is nothing magic there. While I do not like the second patch as-is,
> because it destroys that nice property and treats the end users mindless
> "cut-and-paste without thinking" sheeples,
What's wrong with teaching one thing at a time? Configuring the user
is something so essential, I don't think it makes sense to make the
task difficult on purpose. Some people might avoid doing it precisely
because of that.
> I think that it is rather vague
> and unhelpful to the current target audience to say:
>
> ... The easiest way to do so is to make sure the following lines
> appear in a file named .gitconfig in your home directory:
>
> and the parts can use some improvement. For example, "home directory"
> does not hold true for people on platforms that lack the concept. Keeping
> the current "the following lines appear", rewording "in a file named
> .gitconfig in your home directory" with "in your per-user configuration
> file", keeping the display that shows how the config snippet should look
> like, and using "config --global -e" might be a better approach.
If you read the results of the last git survey you'll see that the
area that needs most improvement is the documentation. Also I still
see many people doing commits without configuring the user name and
email properly and so I've tried very hard to improve the user manual
to make it easier for them to understand they must do that. In the
process I've added the --edit option to 'git config' and the new
"getting started" section, in order to address all the issues
mentioned in previous threads and gone through several iterations of
these patches already.
I'm starting to think that all the previous "constructive" feedback
was actually targeted to deter people from making any changes.
I'm CC'ing people that have been involved in previous threads.
> [Footnote]
>
> *1* Unless you are changing the flow of how this manual teaches at the
> same time, that is. And no, I am not suggesting that we should start from
> "let's do a hello-world repository from scratch". I think the current
> "start from read-only and then learn how to grow history later" is one
> valid way to teach.
I also don't think the flow should be changed, that's why I didn't put
the user configuration on the "getting started" section. It goes into
the "developing with git" section.
[1] http://article.gmane.org/gmane.comp.version-control.git/130236
[2] http://article.gmane.org/gmane.comp.version-control.git/115649
[3] http://article.gmane.org/gmane.comp.version-control.git/106667
--
Felipe Contreras
^ permalink raw reply
* Re: [PATCH] Use 'fast-forward' all over the place
From: Junio C Hamano @ 2009-10-24 19:44 UTC (permalink / raw)
To: Felipe Contreras; +Cc: git, Michael J Gruber
In-Reply-To: <94a0d4530910241212s5d644eb6u66c6f96feafcaf10@mail.gmail.com>
Felipe Contreras <felipe.contreras@gmail.com> writes:
>> I suspect the patch would have been much easier to the reviewers it it
>> stated somewhere in the log message:
>>
>> (1) how the mechanical change was produced;
>
> There wasn't such.
That is actually a bad news; it is even worse than mechanical spotting
followed by manual inspection. It would force us feel _more_ worried, as
we would then need to grep for leftovers that your manual conversion may
not have caught. Sigh...
>> (2) what criteria was used to choose between leaving the mechanical
>> change as-is and rewording them manually; and
>
> If it wasn't straight forward. I considered the following straightforward:
> fast forward -> fast-forward
> fast forwarded -> fast-forwarded
> fast forwarding -> fast-forwarding
> fast forwardable -> fast-forwardable
> non-fast forward -> non-fast-forward
> Fast forward -> Fast-forward
> Fast forwarding -> Fast-forwarding
All of these are what "s/([fF])ast forward/$1ast-forward/g" does, aren't
they?
> I couldn't parse that. From what I can see "Fast forward" was
> emphasized because the author thought the words didn't make much sense
> separated. Now that the word is fast-forward, there's no need to
> emphasize.
Even after your patch, hunk beginning on line 1384 of the
user-manual says
... then git just performs a "fast-forward"; the head of the ...
and I think you did the right thing by keeping these dq here. This is the
first occurrence of the word followed by its explanation and for that
reason, the word deserves to be emphasized---IOW, the context calls for an
emphasis.
In the "Important note!" part, we talk about the pull operation that
normally creates a merge commit, and _in contrast_, under a particular
condition (namely, "no local changes"), it does something different
(namely, a "fast-forward"). We should keep the emphasis on "fast-forward"
here for exactly the same reason---the context calls for an emphasis.
I was about to read the rest of the patch (the non-doc part) but instead I
ended up spending another 20 minutes writing this message, so the review
by me on the remainder has to wait til sometime later.
^ permalink raw reply
* Re: [PATCH 3/3] git checkout --nodwim
From: Junio C Hamano @ 2009-10-24 19:25 UTC (permalink / raw)
To: David Roundy
Cc: Johannes Schindelin, Nanako Shiraishi, Avery Pennarun,
Alex Riesen, git, Jay Soffian
In-Reply-To: <117f2cc80910240759oa9f57e7h67f06816d37e328c@mail.gmail.com>
David Roundy <roundyd@physics.oregonstate.edu> writes:
> Perhaps a universal --plumbing flag would be handy?
Yes in general but it is unclear what aspect of its behaviour we will
be casting in stone with a generic --plumbing option in this case. I
also think that "checkout" Porcelain is not yet mature enough for us
to do this right now. For example, I am reasonably sure that somebody
motivated enough will teach it to touch submodule trees when switching
to another branch by default, and it is unclear if we should turn off
these expected additions when --plumbing is seen.
^ permalink raw reply
* Re: [PATCH] add tests for git diff --submodule
From: Junio C Hamano @ 2009-10-24 19:25 UTC (permalink / raw)
To: Jens Lehmann; +Cc: Junio C Hamano, git, Johannes Schindelin
In-Reply-To: <4AE192AD.70603@web.de>
Jens Lehmann <Jens.Lehmann@web.de> writes:
> Apart from your changes necessary to make the test run again my changes are:
>
> - rename from "t4041-diff-submodule-summary.sh" to "t4041-diff-submodule.sh"
> - corrected all comments still speaking of "summary"
> - added tests to test the behaviour of "--submodule" and "--submodule=short"
Thanks for a nice summary.
^ permalink raw reply
* Re: [PATCH] tar: on extract, -o is --no-same-owner
From: Junio C Hamano @ 2009-10-24 19:25 UTC (permalink / raw)
To: Andreas Schwab
Cc: Bernhard Reutner-Fischer, Junio C Hamano, vda.linux, busybox, git
In-Reply-To: <m2ocnxuej2.fsf@igel.home>
Andreas Schwab <schwab@linux-m68k.org> writes:
> Like this.
Yeah, correct and it beautifly explains the issue. Thanks.
>>From ebadb41b346c305b94f27e3bb787bf0ba6bb8a5b Mon Sep 17 00:00:00 2001
> From: Andreas Schwab <schwab@linux-m68k.org>
> Date: Sat, 24 Oct 2009 15:01:03 +0200
> Subject: [PATCH] Work around option parsing bug in the busybox tar implementation
>
> Traditionally the first argument of the tar command was interpreted a
> bundle of letters specifying the mode of operation and additional options,
> with any option arguments taken from subsequent words on the command line
> as needed. The implementation of tar in busybox apparently treats this
> bundle as if preceded by a dash and then parses it by getopt rules, which
> mishandles 'tar xfo -'. Use 'tar xof -' instead which is parsed the same
> way by both traditional tar implementations and busybox.
>
> Signed-off-by: Andreas Schwab <schwab@linux-m68k.org>
> ---
> templates/Makefile | 2 +-
> 1 files changed, 1 insertions(+), 1 deletions(-)
>
> diff --git a/templates/Makefile b/templates/Makefile
> index a12c6e2..408f013 100644
> --- a/templates/Makefile
> +++ b/templates/Makefile
> @@ -50,4 +50,4 @@ clean:
> install: all
> $(INSTALL) -d -m 755 '$(DESTDIR_SQ)$(template_instdir_SQ)'
> (cd blt && $(TAR) cf - .) | \
> - (cd '$(DESTDIR_SQ)$(template_instdir_SQ)' && umask 022 && $(TAR) xfo -)
> + (cd '$(DESTDIR_SQ)$(template_instdir_SQ)' && umask 022 && $(TAR) xof -)
> --
> 1.6.5.1
>
>
> --
> Andreas Schwab, schwab@linux-m68k.org
> GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5
> "And now for something completely different."
^ permalink raw reply
* Re: [PATCH] Use 'fast-forward' all over the place
From: Felipe Contreras @ 2009-10-24 19:12 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Michael J Gruber
In-Reply-To: <7v3a587kc2.fsf@alter.siamese.dyndns.org>
On Sat, Oct 24, 2009 at 8:50 PM, Junio C Hamano <gitster@pobox.com> wrote:
> Is this meant to replace the previous one that is already queued: a0c0ecb
> (user-manual: use 'fast-forward', 2009-10-11)?
Yes.
> It seems that these mostly match a mechanical token replacement
> "s/([fF])ast forward/$1ast-forward/g" in the Documentation area,
> but I suspect there may be some manual fixes.
>
> Token-replace is much harder to review than to produce, as the result of
> such mechanical substitution needs to be examined to see if each change
> makes sense individually.
I manually replaced each instance, and reviewed the patch myself. Most
of the changes are essentially the same, except a few instances:
"Fast forward" -> fast-forward
Fast Forward Only -> Fast-forward Only
> I suspect the patch would have been much easier to the reviewers it it
> stated somewhere in the log message:
>
> (1) how the mechanical change was produced;
There wasn't such.
> (2) what criteria was used to choose between leaving the mechanical
> change as-is and rewording them manually; and
If it wasn't straight forward. I considered the following straightforward:
fast forward -> fast-forward
fast forwarded -> fast-forwarded
fast forwarding -> fast-forwarding
fast forwardable -> fast-forwardable
non-fast forward -> non-fast-forward
Fast forward -> Fast-forward
Fast forwarding -> Fast-forwarding
> (3) where these non-mechanical changes are.
Mentioned on the second comment.
> Here are the list of paths I looked at (during this sitting which did
> not go til the end of the patch):
>
>> diff --git a/Documentation/config.txt b/Documentation/config.txt
>
> OK
>
>> diff --git a/Documentation/git-http-push.txt b/Documentation/git-http-push.txt
>
> OK
>
>> diff --git a/Documentation/git-push.txt b/Documentation/git-push.txt
>
> OK, except for two hunks below I am not absolutely sure.
>
>> @@ -60,7 +60,7 @@ EXAMPLES below for details.
>> Pushing an empty <src> allows you to delete the <dst> ref from
>> the remote repository.
>> +
>> -The special refspec `:` (or `{plus}:` to allow non-fast forward updates)
>> +The special refspec `:` (or `{plus}:` to allow non-fast-forward updates)
>> directs git to push "matching" branches: for every branch that exists on
>> the local side, the remote side is updated if a branch of the same name
>> already exists on the remote side. This is the default operation mode
>
> Hmm, is non-fast-forward a yet another compound word?
Yes. AFAIK.
>> @@ -342,9 +342,9 @@ git push origin :experimental::
>
> Likewise.
>
>> diff --git a/Documentation/git-read-tree.txt b/Documentation/git-read-tree.txt
>> diff --git a/Documentation/git-receive-pack.txt b/Documentation/git-receive-pack.txt
>> diff --git a/Documentation/git-reset.txt b/Documentation/git-reset.txt
>> diff --git a/Documentation/git-send-pack.txt b/Documentation/git-send-pack.txt
>> diff --git a/Documentation/gitcore-tutorial.txt b/Documentation/gitcore-tutorial.txt
>> diff --git a/Documentation/githooks.txt b/Documentation/githooks.txt
>> diff --git a/Documentation/glossary-content.txt b/Documentation/glossary-content.txt
>> diff --git a/Documentation/howto/maintain-git.txt b/Documentation/howto/maintain-git.txt
>> diff --git a/Documentation/howto/revert-branch-rebase.txt b/Documentation/howto/revert-branch-rebase.txt
>> diff --git a/Documentation/howto/update-hook-example.txt b/Documentation/howto/update-hook-example.txt
>> diff --git a/Documentation/user-manual.txt b/Documentation/user-manual.txt
>
> OK, except for this hunk I am not sure about.
>
>> @@ -2115,7 +2115,7 @@ $ git checkout release && git pull
>>
>> Important note! If you have any local changes in these branches, then
>> this merge will create a commit object in the history (with no local
>> -changes git will simply do a "Fast forward" merge). Many people dislike
>> +changes git will simply do a fast-forward merge). Many people dislike
>> the "noise" that this creates in the Linux history, so you should avoid
>> doing this capriciously in the "release" branch, as these noisy commits
>> will become part of the permanent history when you ask Linus to pull
>
> It may be Ok not to emphasize this word but that is not about "fast
> forward" vs "fast-forward". It is more about "in this context, this word
> does not have to be emphasized" kind of copy-editing which does not have
> to be limited to the case where the "word" is 'fast-forward'.
I couldn't parse that. From what I can see "Fast forward" was
emphasized because the author thought the words didn't make much sense
separated. Now that the word is fast-forward, there's no need to
emphasize.
Cheers.
--
Felipe Contreras
^ permalink raw reply
* Re: [PATCH v2 0/2] user-manual: new "getting started" section
From: Junio C Hamano @ 2009-10-24 18:19 UTC (permalink / raw)
To: Felipe Contreras; +Cc: Junio C Hamano, git, Michael J Gruber, Jonathan Nieder
In-Reply-To: <7vy6n065os.fsf@alter.siamese.dyndns.org>
Junio C Hamano <gitster@pobox.com> writes:
> Felipe Contreras <felipe.contreras@gmail.com> writes:
>
>> Reworded the getting started section based on comments from Michael J Gruber,
>> Jonathan Nieder and Junio C Hamano.
>
> Hmm, I thought JBF also had some input...
Ah, nevermind. Yes, he did have input, and I tend to agree with him, and
more importantly trust his judgement on the manual.
I think a "Getting started" section that only covers "git config" looks
way out of place in the beginning of this document.
Manuals by other people that teach "here is how you would do a hello-world
repository" would want to teach user.name before reaching that point, but
because the user-manual is written in such a way that it first introduces
concepts to understand what is going on without changing anything, we do
not have much need user.name until it gets to "Developing with git"
section.
"Many people prefer to teach it this way" does not justify "everybody must
teach it this way" an iota, when teaching "config user.name" upfront will
fit the flow of how they teach but does not fit the flow of how this
manual teaches [*1*].
I'm inclined to to discard the first patch.
The point of the original text the second patch touches was to show how
simple the contents of the configuration file is and give the users that
there is nothing magic there. While I do not like the second patch as-is,
because it destroys that nice property and treats the end users mindless
"cut-and-paste without thinking" sheeples, I think that it is rather vague
and unhelpful to the current target audience to say:
... The easiest way to do so is to make sure the following lines
appear in a file named .gitconfig in your home directory:
and the parts can use some improvement. For example, "home directory"
does not hold true for people on platforms that lack the concept. Keeping
the current "the following lines appear", rewording "in a file named
.gitconfig in your home directory" with "in your per-user configuration
file", keeping the display that shows how the config snippet should look
like, and using "config --global -e" might be a better approach.
[Footnote]
*1* Unless you are changing the flow of how this manual teaches at the
same time, that is. And no, I am not suggesting that we should start from
"let's do a hello-world repository from scratch". I think the current
"start from read-only and then learn how to grow history later" is one
valid way to teach.
^ permalink raw reply
* Re: [PATCH v2 0/2] user-manual: new "getting started" section
From: Junio C Hamano @ 2009-10-24 17:51 UTC (permalink / raw)
To: Felipe Contreras; +Cc: git, Junio C Hamano, Michael J Gruber, Jonathan Nieder
In-Reply-To: <1256377489-16719-1-git-send-email-felipe.contreras@gmail.com>
Felipe Contreras <felipe.contreras@gmail.com> writes:
> Reworded the getting started section based on comments from Michael J Gruber,
> Jonathan Nieder and Junio C Hamano.
Hmm, I thought JBF also had some input...
^ permalink raw reply
* Re: [PATCH] Use 'fast-forward' all over the place
From: Junio C Hamano @ 2009-10-24 17:50 UTC (permalink / raw)
To: Felipe Contreras; +Cc: git, Michael J Gruber
In-Reply-To: <1256373092-15126-2-git-send-email-felipe.contreras@gmail.com>
Is this meant to replace the previous one that is already queued: a0c0ecb
(user-manual: use 'fast-forward', 2009-10-11)?
It seems that these mostly match a mechanical token replacement
"s/([fF])ast forward/$1ast-forward/g" in the Documentation area,
but I suspect there may be some manual fixes.
Token-replace is much harder to review than to produce, as the result of
such mechanical substitution needs to be examined to see if each change
makes sense individually.
I suspect the patch would have been much easier to the reviewers it it
stated somewhere in the log message:
(1) how the mechanical change was produced;
(2) what criteria was used to choose between leaving the mechanical
change as-is and rewording them manually; and
(3) where these non-mechanical changes are.
Here are the list of paths I looked at (during this sitting which did
not go til the end of the patch):
> diff --git a/Documentation/config.txt b/Documentation/config.txt
OK
> diff --git a/Documentation/git-http-push.txt b/Documentation/git-http-push.txt
OK
> diff --git a/Documentation/git-push.txt b/Documentation/git-push.txt
OK, except for two hunks below I am not absolutely sure.
> @@ -60,7 +60,7 @@ EXAMPLES below for details.
> Pushing an empty <src> allows you to delete the <dst> ref from
> the remote repository.
> +
> -The special refspec `:` (or `{plus}:` to allow non-fast forward updates)
> +The special refspec `:` (or `{plus}:` to allow non-fast-forward updates)
> directs git to push "matching" branches: for every branch that exists on
> the local side, the remote side is updated if a branch of the same name
> already exists on the remote side. This is the default operation mode
Hmm, is non-fast-forward a yet another compound word?
> @@ -342,9 +342,9 @@ git push origin :experimental::
Likewise.
> diff --git a/Documentation/git-read-tree.txt b/Documentation/git-read-tree.txt
> diff --git a/Documentation/git-receive-pack.txt b/Documentation/git-receive-pack.txt
> diff --git a/Documentation/git-reset.txt b/Documentation/git-reset.txt
> diff --git a/Documentation/git-send-pack.txt b/Documentation/git-send-pack.txt
> diff --git a/Documentation/gitcore-tutorial.txt b/Documentation/gitcore-tutorial.txt
> diff --git a/Documentation/githooks.txt b/Documentation/githooks.txt
> diff --git a/Documentation/glossary-content.txt b/Documentation/glossary-content.txt
> diff --git a/Documentation/howto/maintain-git.txt b/Documentation/howto/maintain-git.txt
> diff --git a/Documentation/howto/revert-branch-rebase.txt b/Documentation/howto/revert-branch-rebase.txt
> diff --git a/Documentation/howto/update-hook-example.txt b/Documentation/howto/update-hook-example.txt
> diff --git a/Documentation/user-manual.txt b/Documentation/user-manual.txt
OK, except for this hunk I am not sure about.
> @@ -2115,7 +2115,7 @@ $ git checkout release && git pull
>
> Important note! If you have any local changes in these branches, then
> this merge will create a commit object in the history (with no local
> -changes git will simply do a "Fast forward" merge). Many people dislike
> +changes git will simply do a fast-forward merge). Many people dislike
> the "noise" that this creates in the Linux history, so you should avoid
> doing this capriciously in the "release" branch, as these noisy commits
> will become part of the permanent history when you ask Linus to pull
It may be Ok not to emphasize this word but that is not about "fast
forward" vs "fast-forward". It is more about "in this context, this word
does not have to be emphasized" kind of copy-editing which does not have
to be limited to the case where the "word" is 'fast-forward'.
It is my policy not to look at one patch for more than 30 minutes in one
sitting, because I'll get sloppier toward the end, so I'll stop here for
now. Help in reviewing the rest is appreciated.
^ permalink raw reply
* Re: [PATCH 3/3] git checkout --nodwim
From: David Roundy @ 2009-10-24 14:59 UTC (permalink / raw)
To: Junio C Hamano
Cc: Johannes Schindelin, Nanako Shiraishi, Avery Pennarun,
Alex Riesen, git, Jay Soffian
In-Reply-To: <7vzl7h8fjp.fsf@alter.siamese.dyndns.org>
On Sat, Oct 24, 2009 at 2:35 AM, Junio C Hamano <gitster@pobox.com> wrote:
>> My take on it:
>>
>> 1) --no-porcelain
>>
>> 2) we all are bike-shedding, not being constructive at all
>
> You are right about (2), regarding the option name. I've queued one that
> uses --no-guess.
Perhaps a universal --plumbing flag would be handy? It'd be nice to be
able to pass any command --plumbing and it'll either behave in a
stable, predictable, plumbing-like way, or die with an error message
stating that it isn't a plumbing command. Right now, it's sort of
hard to figure out what is plumbing and what is porcelain. Some
commands are clear, but other commands labelled as plumbing in git(1)
are deprecated in favor of commands labelled as porcelain.
David
^ 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