* Re: gitk: Update Japanese translation
From: Paul Mackerras @ 2009-11-14 11:14 UTC (permalink / raw)
To: Mizar; +Cc: git, gitster
In-Reply-To: <d092a4360911060557v970753fn2294124aedda93ec@mail.gmail.com>
Mizar writes:
> The main changes are as follows.
> Several issues remain and is pending because there is no improvement.
> http://github.com/mizar/gitk/issues
Thanks, applied.
Paul.
^ permalink raw reply
* Re: [PATCH] gitk: disable checkout of remote branch
From: Paul Mackerras @ 2009-11-14 11:14 UTC (permalink / raw)
To: Sitaram Chamarty; +Cc: Git Mailing List
In-Reply-To: <2e24e5b90911030800j22b00372r99a56c3f847a3644@mail.gmail.com>
Sitaram Chamarty writes:
> This prevents a lot of detached HEAD commits by new users.
>
> Signed-off-by: Sitaram Chamarty <sitaramc@gmail.com>
Thanks, applied.
Paul.
^ permalink raw reply
* Re: [PATCH] gitk: Fix "git gui blame" invocation when called from topdir
From: Paul Mackerras @ 2009-11-14 11:14 UTC (permalink / raw)
To: Markus Heidelberg; +Cc: git
In-Reply-To: <1257290501-21093-1-git-send-email-markus.heidelberg@web.de>
Markus Heidelberg writes:
> In this case "git rev-parse --git-dir" doesn't return an absolute path,
> but merely ".git", so the selected file has a relative path.
> The function make_relative then tries to make the already relative path
> relative, which results in a path like "../../../../Makefile" with as
> much ".." as the number of parts [pwd] consists of.
>
> This regression was introduced by commit 9712b81 (gitk: Fix bugs in
> blaming code, 2008-12-06), which fixed "git gui blame" when called from
> subdirs.
>
> This also fixes it for bare repositories.
>
> Signed-off-by: Markus Heidelberg <markus.heidelberg@web.de>
Thanks, applied.
Paul.
^ permalink raw reply
* Re: [gitk] [PATCH] 0/2 Merging master into dev
From: Paul Mackerras @ 2009-11-14 11:20 UTC (permalink / raw)
To: Pat Thoyts; +Cc: git, Johannes Schindelin
In-Reply-To: <871vkbw7x2.fsf@users.sourceforge.net>
Pat Thoyts writes:
> I've merged the current changes for gitk master onto the dev branch
> and fixed some conflicts and then modified the default colour
> assignments for windows to use the system colours so that it will pick
> up the stock colours defined via the windows property pages.
>
> However, I'm not too certain how to post such a merge commit. Usually
> I do 'git format-patch -M' but in this case that emits all the commits
> that were merged. It looks like 'git show -p' is producing a merge
> patch so I am posting that for 1/2 and a normal patch for 2/2. If
> there is better way let me know and I will redo.
I don't think there is a way to send a merge commit by email. I think
you would have to put a repository somewhere with the merge in it and
invite me to pull it.
In any case, I have just merged the dev branch into the master branch
and then applied your second patch, and pushed out the result.
Paul.
^ permalink raw reply
* Re: [PATCH] Speed up bash completion loading
From: Jonathan Nieder @ 2009-11-14 11:01 UTC (permalink / raw)
To: Stephen Boyd
Cc: Kirill Smelkov, Sverre Rabbelier, Junio C Hamano, Shawn O. Pearce,
git
In-Reply-To: <4AFDC4F3.1050607@gmail.com>
Stephen Boyd wrote:
> I see a small problem, but it can be fixed in another patch. git
> merge -s <TAB><TAB> the first time when you're not in a git
> directory will make git merge -s <TAB><TAB> after never complete
> correctly even in a git directory.
Not good. I think the sanest thing to do is avoid caching the merge
strategy list entirely. Listing merge strategies takes about 100 ms
here, which is short enough not to be annoying.
> I guess this become more serious
> if git isn't in your path initially and you do git <TAB><TAB> and
> then git becomes part of your path and you try again. Here you lose
> porcelain completion. This is probably never going to happen though,
> right?
Right, if this happened to me I would not be too surprised. A similar
problem occurs when someone installs a new git subcommand in the
middle of a session. Starting a new session fixes the completion, but
should the completion script do something to help people before then?
It could provide a shell function with a slightly friendlier name than
"__git_compute_porcelain_commands" for the user to invoke explicitly.
It could retry "git help -a" each time completion was needed if it
gave no results last time (i.e. use "${__git_all_commands:=" instead
of "${__git_all_commands="). This would help with the missing git
problem (which seems unusual), but not the missing git-svn.
Maybe it could detect signs of user frustration (repeated attempts to
complete the same thing?) and add to the frustration by silently
fixing the cache.
-- %< --
Subject: completion: do not cache merge strategy list
If "git merge -s help" fails the first time we try it (e.g. if you're
not in a git directory), git merge -s <TAB><TAB> never completes
correctly within the same session.
Reported-by: Stephen Boyd <bebarino@gmail.com>
Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
---
contrib/completion/git-completion.bash | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/contrib/completion/git-completion.bash b/contrib/completion/git-completion.bash
index 748d4f9..634941f 100755
--- a/contrib/completion/git-completion.bash
+++ b/contrib/completion/git-completion.bash
@@ -332,7 +332,7 @@ __git_list_merge_strategies ()
__git_compute_merge_strategies ()
{
- : ${__git_merge_strategies=$(__git_list_merge_strategies)}
+ __git_merge_strategies=$(__git_list_merge_strategies)
}
__git_complete_file ()
--
1.6.5.2
^ permalink raw reply related
* Re: [PATCH] Speed up bash completion loading
From: Jonathan Nieder @ 2009-11-14 10:35 UTC (permalink / raw)
To: Stephen Boyd
Cc: Kirill Smelkov, Sverre Rabbelier, Junio C Hamano, Shawn O. Pearce,
git
In-Reply-To: <4AFDC4F3.1050607@gmail.com>
Stephen Boyd wrote:
> I was under the impression that setting variables during completion
> meant they were lost at the end of the completion cycle. So to be
> safe I put a 'sleep 5' in __git_list_porcelain_commands() and it
> only stalled me once :-)
Clever. :)
> Plus it seems that __git_all_commands is computed twice if I git
> <TAB><TAB> and then git help <TAB><TAB> after. Can that be avoided?
Sounds like a bug; thanks. I’ll squash in something like the following
for the next iteration.
-- %< --
Subject: completion: avoid computing command list twice
__git_all_commands is being computed twice on git <TAB><TAB> with
git help <TAB><TAB> after.
Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
---
contrib/completion/git-completion.bash | 1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/contrib/completion/git-completion.bash b/contrib/completion/git-completion.bash
index 6817953..748d4f9 100755
--- a/contrib/completion/git-completion.bash
+++ b/contrib/completion/git-completion.bash
@@ -588,6 +588,7 @@ __git_list_porcelain_commands ()
__git_compute_porcelain_commands ()
{
+ __git_compute_all_commands
: ${__git_porcelain_commands=$(__git_list_porcelain_commands)}
}
--
1.6.5.2
^ permalink raw reply related
* Re: GNU patch: new 2.6 release
From: Andreas Gruenbacher @ 2009-11-14 10:17 UTC (permalink / raw)
To: Björn Gustavsson; +Cc: git, bug-patch
In-Reply-To: <6672d0160911140045h70243c12w3c56ad925dc70d39@mail.gmail.com>
On Saturday 14 November 2009 09:45:11 am Björn Gustavsson wrote:
> Do you have any plans to support git-style binary patches?
Support for git's extended header lines for renames, copies, hashes, file
modes would be great. I'll happily take patches or eventually implement it
myself. Binary patches are not as high on my wish list, but feel free to send
code.
> That would be very useful in a workflow when you work in git (and have some
> binary files in the repository), but need to commit your finished work
> into another VCS (such as Clearcase).
Isn't there a better way to do this than with patches?
Thanks,
Andreas
^ permalink raw reply
* Re: [PATCHv3] Add branch management for releases to gitworkflows
From: Nanako Shiraishi @ 2009-11-14 9:01 UTC (permalink / raw)
To: Raman Gupta; +Cc: git, trast, gitster
In-Reply-To: <4AFE41AF.8050802@fastmail.fm>
Quoting Raman Gupta <rocketraman@fastmail.fm>
> Ok, another dumb question: since you have now submitted a patch on top
> of my patch, what is the proper etiquette for proceeding? Who
> maintains this patch series until it is committed? Since your patch
> applies on top of mine I can't really make any more changes without
> affecting your patch right? I can't find any guidance in the
> SubmittingPatches document.
What usually happens is that we wait now.
In this case we are in agreement that it is a good idea to apply
both of our patches (mine was only repeating what Junio said in
his comments), so if I were you, I would anticipate that Junio
would apply both of them and start preparing incremental updates
on top of them now, and send them when the patches appear in his
'pu' branch.
Junio has gone quiet for the past few days; maybe he is too busy
to read or respond to either of our patch. Instead of preparing
the final text you write in the document in a patch format, it
may be a better to bring up your ideas here and discuss them
first. What changes do you have in mind? I think the new section
now already is in a reasonable shape.
--
Nanako Shiraishi
http://ivory.ap.teacup.com/nanako3/
^ permalink raw reply
* Re: [PATCHv3] Add branch management for releases to gitworkflows
From: Björn Gustavsson @ 2009-11-14 8:59 UTC (permalink / raw)
To: Raman Gupta; +Cc: Nanako Shiraishi, git, trast, gitster
In-Reply-To: <4AFE41AF.8050802@fastmail.fm>
On Sat, Nov 14, 2009 at 6:35 AM, Raman Gupta <rocketraman@fastmail.fm> wrote:
>
> Ok, another dumb question: since you have now submitted a patch on top
> of my patch, what is the proper etiquette for proceeding? Who
> maintains this patch series until it is committed? Since your patch
> applies on top of mine I can't really make any more changes without
> affecting your patch right? I can't find any guidance in the
> SubmittingPatches document.
I can't answer the questions about proper etiquette, but you *can* do
more changes
if you first apply Nanako's patch on top of your previous changes.
/Björn
--
Björn Gustavsson, Erlang/OTP, Ericsson AB
^ permalink raw reply
* Re: GNU patch: new 2.6 release
From: Björn Gustavsson @ 2009-11-14 8:45 UTC (permalink / raw)
To: Andreas Gruenbacher; +Cc: git
In-Reply-To: <200911140109.34202.agruen@suse.de>
On Sat, Nov 14, 2009 at 1:09 AM, Andreas Gruenbacher <agruen@suse.de> wrote:
> I am pleased to announce my first release of GNU patch,
Nice to see a new release.
Do you have any plans to support git-style binary patches?
That would be very useful in a workflow when you work in git (and have some
binary files in the repository), but need to commit your finished work
into another VCS (such as Clearcase).
/Björn
--
Björn Gustavsson, Erlang/OTP, Ericsson AB
^ permalink raw reply
* [PATCH] rebase -i: Simplify handling of invalid commands.
From: Greg Price @ 2009-11-14 8:11 UTC (permalink / raw)
To: git; +Cc: Johannes Schindelin, Junio C Hamano, Jan Krüger
A few weeks ago there was a bug report that some invalid commands
produced confusing error messages. The fix could have made things
simpler. There's no need for die_with_patch in this case, because its
purpose is to tell rerere and a future rebase --continue about a
commit that we just attempted, and we didn't attempt any commit. So
just use a plain "die" unconditionally.
Signed-off-by: Greg Price <price@mit.edu>
---
git-rebase--interactive.sh | 7 +------
1 files changed, 1 insertions(+), 6 deletions(-)
diff --git a/git-rebase--interactive.sh b/git-rebase--interactive.sh
index 53ad248..6d0ca7b 100755
--- a/git-rebase--interactive.sh
+++ b/git-rebase--interactive.sh
@@ -416,12 +416,7 @@ do_next () {
;;
*)
warn "Unknown command: $command $sha1 $rest"
- if git rev-parse --verify -q "$sha1" >/dev/null
- then
- die_with_patch $sha1 "Please fix this in the file $TODO."
- else
- die "Please fix this in the file $TODO."
- fi
+ die "Please fix this in the file $TODO."
;;
esac
test -s "$TODO" && return
--
1.6.5.2.27.g906c6.dirty
^ permalink raw reply related
* Re: [PATCHv3] Add branch management for releases to gitworkflows
From: Raman Gupta @ 2009-11-14 5:35 UTC (permalink / raw)
To: Nanako Shiraishi; +Cc: git, trast, gitster
In-Reply-To: <20091114081040.6117@nanako3.lavabit.com>
Nanako Shiraishi wrote:
> Quoting Raman Gupta <rocketraman@fastmail.fm>
>> I noticed you removed the discussion I added about the situation in
>> which maint will *not* be a subset of master i.e. when the user has
>> cherry-picked commits from other branches. This type of cherry-pick is
>> described as a valid operation, though one to generally be avoided
>> earlier in the man page. If we tell users that the occasional
>> cherry-pick to maint is ok, then shouldn't we explain how that affects
>> the release process?
>
> It is irrelevant that you can cherry-pick to 'maint'.
>
> You can, and Junio does, cherry-pick some commits from master to
> maint from time to time. But even if you have such cherry-picked
> commits on the maintenance branch, the result, with zero or more
> other maintenance commits on top, is always merged back to the
> master branch (you can look at "gitk origin/maint origin/master"
> to see yourself).
>
> So when Junio tags the release from the tip of the master branch,
> it is a superset of the maintenace branch; it is irrelevant if
> maint has some commits that are cherry-picked from master.
Thanks for the explanation. Makes sense.
Ok, another dumb question: since you have now submitted a patch on top
of my patch, what is the proper etiquette for proceeding? Who
maintains this patch series until it is committed? Since your patch
applies on top of mine I can't really make any more changes without
affecting your patch right? I can't find any guidance in the
SubmittingPatches document.
Cheers,
Raman
^ permalink raw reply
* [PATCH 2/2] ls-tree: migrate to parse-options
From: Stephen Boyd @ 2009-11-14 4:34 UTC (permalink / raw)
To: git; +Cc: Junio C Hamano
In-Reply-To: <1258173248-31059-1-git-send-email-bebarino@gmail.com>
Signed-off-by: Stephen Boyd <bebarino@gmail.com>
---
builtin-ls-tree.c | 100 +++++++++++++++++++++-------------------------------
1 files changed, 40 insertions(+), 60 deletions(-)
diff --git a/builtin-ls-tree.c b/builtin-ls-tree.c
index 22008df..04408df 100644
--- a/builtin-ls-tree.c
+++ b/builtin-ls-tree.c
@@ -9,6 +9,7 @@
#include "commit.h"
#include "quote.h"
#include "builtin.h"
+#include "parse-options.h"
static int line_termination = '\n';
#define LS_RECURSIVE 1
@@ -22,8 +23,10 @@ static const char **pathspec;
static int chomp_prefix;
static const char *ls_tree_prefix;
-static const char ls_tree_usage[] =
- "git ls-tree [-d] [-r] [-t] [-l] [-z] [--name-only] [--name-status] [--full-name] [--full-tree] [--abbrev[=<n>]] <tree-ish> [path...]";
+static const char * const ls_tree_usage[] = {
+ "git ls-tree [-d] [-r] [-t] [-l | --long] [-z] [--name-only] [--name-status] [--full-name] [--full-tree] [--abbrev[=<n>]] <tree-ish> [path...]",
+ NULL
+};
static int show_recursive(const char *base, int baselen, const char *pathname)
{
@@ -117,76 +120,53 @@ int cmd_ls_tree(int argc, const char **argv, const char *prefix)
{
unsigned char sha1[20];
struct tree *tree;
+ int full_tree = 0;
+ const struct option ls_tree_options[] = {
+ OPT_BIT('d', NULL, &ls_options, "only show trees",
+ LS_TREE_ONLY),
+ OPT_BIT('r', NULL, &ls_options, "recurse into subtrees",
+ LS_RECURSIVE),
+ OPT_BIT('t', NULL, &ls_options, "show trees when recursing",
+ LS_SHOW_TREES),
+ OPT_SET_INT('z', NULL, &line_termination,
+ "terminate entries with NUL byte", 0),
+ OPT_BIT('l', "long", &ls_options, "include object size",
+ LS_SHOW_SIZE),
+ OPT_BIT(0, "name-only", &ls_options, "list only filenames",
+ LS_NAME_ONLY),
+ OPT_BIT(0, "name-status", &ls_options, "list only filenames",
+ LS_NAME_ONLY),
+ OPT_SET_INT(0, "full-name", &chomp_prefix,
+ "use full path names", 0),
+ OPT_BOOLEAN(0, "full-tree", &full_tree,
+ "list entire tree; not just current directory "
+ "(implies --full-name)"),
+ OPT__ABBREV(&abbrev),
+ OPT_END()
+ };
git_config(git_default_config, NULL);
ls_tree_prefix = prefix;
if (prefix && *prefix)
chomp_prefix = strlen(prefix);
- while (1 < argc && argv[1][0] == '-') {
- switch (argv[1][1]) {
- case 'z':
- line_termination = 0;
- break;
- case 'r':
- ls_options |= LS_RECURSIVE;
- break;
- case 'd':
- ls_options |= LS_TREE_ONLY;
- break;
- case 't':
- ls_options |= LS_SHOW_TREES;
- break;
- case 'l':
- ls_options |= LS_SHOW_SIZE;
- break;
- case '-':
- if (!strcmp(argv[1]+2, "name-only") ||
- !strcmp(argv[1]+2, "name-status")) {
- ls_options |= LS_NAME_ONLY;
- break;
- }
- if (!strcmp(argv[1]+2, "long")) {
- ls_options |= LS_SHOW_SIZE;
- break;
- }
- if (!strcmp(argv[1]+2, "full-name")) {
- chomp_prefix = 0;
- break;
- }
- if (!strcmp(argv[1]+2, "full-tree")) {
- ls_tree_prefix = prefix = NULL;
- chomp_prefix = 0;
- break;
- }
- if (!prefixcmp(argv[1]+2, "abbrev=")) {
- abbrev = strtoul(argv[1]+9, NULL, 10);
- if (abbrev && abbrev < MINIMUM_ABBREV)
- abbrev = MINIMUM_ABBREV;
- else if (abbrev > 40)
- abbrev = 40;
- break;
- }
- if (!strcmp(argv[1]+2, "abbrev")) {
- abbrev = DEFAULT_ABBREV;
- break;
- }
- /* otherwise fallthru */
- default:
- usage(ls_tree_usage);
- }
- argc--; argv++;
+
+ argc = parse_options(argc, argv, prefix, ls_tree_options,
+ ls_tree_usage, 0);
+ if (full_tree) {
+ ls_tree_prefix = prefix = NULL;
+ chomp_prefix = 0;
}
/* -d -r should imply -t, but -d by itself should not have to. */
if ( (LS_TREE_ONLY|LS_RECURSIVE) ==
((LS_TREE_ONLY|LS_RECURSIVE) & ls_options))
ls_options |= LS_SHOW_TREES;
- if (argc < 2)
- usage(ls_tree_usage);
- if (get_sha1(argv[1], sha1))
- die("Not a valid object name %s", argv[1]);
+ if (argc < 1)
+ usage_with_options(ls_tree_usage, ls_tree_options);
+ if (get_sha1(argv[0], sha1))
+ die("Not a valid object name %s", argv[0]);
- pathspec = get_pathspec(prefix, argv + 2);
+ pathspec = get_pathspec(prefix, argv + 1);
tree = parse_tree_indirect(sha1);
if (!tree)
die("not a tree object");
--
1.6.5.2.155.gbb47
^ permalink raw reply related
* [PATCH 1/2] t3101: test more ls-tree options
From: Stephen Boyd @ 2009-11-14 4:34 UTC (permalink / raw)
To: git; +Cc: Junio C Hamano
In-Reply-To: <1258173248-31059-1-git-send-email-bebarino@gmail.com>
Add tests for --full-name, --full-tree, --abbrev, and --name-only.
Signed-off-by: Stephen Boyd <bebarino@gmail.com>
---
t/t3101-ls-tree-dirname.sh | 89 +++++++++++++++++++++++++++++++++++++++++++-
1 files changed, 87 insertions(+), 2 deletions(-)
diff --git a/t/t3101-ls-tree-dirname.sh b/t/t3101-ls-tree-dirname.sh
index 51cb4a3..99458e4 100755
--- a/t/t3101-ls-tree-dirname.sh
+++ b/t/t3101-ls-tree-dirname.sh
@@ -39,8 +39,8 @@ test_expect_success \
tree=`git write-tree` &&
echo $tree'
-_x40='[0-9a-f][0-9a-f][0-9a-f][0-9a-f][0-9a-f]'
-_x40="$_x40$_x40$_x40$_x40$_x40$_x40$_x40$_x40"
+_x5='[0-9a-f][0-9a-f][0-9a-f][0-9a-f][0-9a-f]'
+_x40="$_x5$_x5$_x5$_x5$_x5$_x5$_x5$_x5"
test_output () {
sed -e "s/ $_x40 / X /" <current >check
test_cmp expected check
@@ -141,4 +141,89 @@ test_expect_success 'ls-tree filter is leading path match' '
test_output
'
+test_expect_success 'ls-tree --full-name' '
+ (
+ cd path0 &&
+ git ls-tree --full-name $tree a
+ ) > current &&
+ cat >expected <<\EOF &&
+040000 tree X path0/a
+EOF
+ test_output
+'
+
+test_expect_success 'ls-tree --full-tree' '
+ (
+ cd path1/b/c &&
+ git ls-tree --full-tree $tree
+ ) > current &&
+ cat >expected <<\EOF &&
+100644 blob X 1.txt
+100644 blob X 2.txt
+040000 tree X path0
+040000 tree X path1
+040000 tree X path2
+040000 tree X path3
+EOF
+ test_output
+'
+
+test_expect_success 'ls-tree --full-tree -r' '
+ (
+ cd path3/ &&
+ git ls-tree --full-tree -r $tree
+ ) > current &&
+ cat >expected <<\EOF &&
+100644 blob X 1.txt
+100644 blob X 2.txt
+100644 blob X path0/a/b/c/1.txt
+100644 blob X path1/b/c/1.txt
+100644 blob X path2/1.txt
+100644 blob X path3/1.txt
+100644 blob X path3/2.txt
+EOF
+ test_output
+'
+
+test_expect_success 'ls-tree --abbrev=5' '
+ git ls-tree --abbrev=5 $tree > current.abbrev &&
+ sed -e "s/ $_x5 / X /" < current.abbrev > current &&
+ cat >expected <<\EOF &&
+100644 blob X 1.txt
+100644 blob X 2.txt
+040000 tree X path0
+040000 tree X path1
+040000 tree X path2
+040000 tree X path3
+EOF
+ test_output
+'
+
+test_expect_success 'ls-tree --name-only' '
+ git ls-tree --name-only $tree > current
+ cat >expected <<\EOF &&
+1.txt
+2.txt
+path0
+path1
+path2
+path3
+EOF
+ test_output
+'
+
+test_expect_success 'ls-tree --name-only -r' '
+ git ls-tree --name-only -r $tree > current
+ cat >expected <<\EOF &&
+1.txt
+2.txt
+path0/a/b/c/1.txt
+path1/b/c/1.txt
+path2/1.txt
+path3/1.txt
+path3/2.txt
+EOF
+ test_output
+'
+
test_done
--
1.6.5.2.155.gbb47
^ permalink raw reply related
* [PATCH 0/2] Migrate ls-tree to parse-opts
From: Stephen Boyd @ 2009-11-14 4:34 UTC (permalink / raw)
To: git; +Cc: Junio C Hamano
This looked pretty straightforward. I guess --name-status is there
for backward compatibility. Should it be there anymore?
Stephen Boyd (2):
t3101: test more ls-tree options
ls-tree: migrate to parse-options
builtin-ls-tree.c | 100 +++++++++++++++++--------------------------
t/t3101-ls-tree-dirname.sh | 89 ++++++++++++++++++++++++++++++++++++++-
2 files changed, 127 insertions(+), 62 deletions(-)
^ permalink raw reply
* Re: [PATCH] Re: Clarify documentation on the "ours" merge strategy.
From: Nanako Shiraishi @ 2009-11-14 2:12 UTC (permalink / raw)
To: Peter Krefting
Cc: Junio C Hamano, Thomas Rast, Nicolas Sebrecht, Baz,
Git Mailing List, Johannes.Schindelin, B.Steinbrink
In-Reply-To: <alpine.DEB.2.00.0911121034580.8825@ds9.cixit.se>
Quoting Peter Krefting <peter@softwolves.pp.se>
> The web tree checkout script uses rebase to avoid introducing merge
> commits every time the blog comment is updated, as it in 99 % of cases
> is unrelated to any other changes found in the central repo.
>
> In the few cases where the blog comment update from the web tree
> conflicts with a change in the central repo, I want the "git pull
> --rebase" call to overwrite any changes in the central repo with my
> changes in the web tree (meaning that I would later have to manually
> re-delete the spam comments, but I can live with that).
That sounds like "-Xours" merge option that was discussed some time
ago. See
http://thread.gmane.org/gmane.comp.version-control.git/76650/focus=89021
I remember that Junio and Petr were against it because it would
encourage a bad workflow. Dscho was against the syntax used to
pass the options also.
--
Nanako Shiraishi
http://ivory.ap.teacup.com/nanako3/
^ permalink raw reply
* [PATCH] git-add.txt: fix formatting of --patch section
From: Stephen Boyd @ 2009-11-14 1:45 UTC (permalink / raw)
To: git; +Cc: Junio C Hamano
Extra paragraphs should be prefixed with a plus sign.
Signed-off-by: Stephen Boyd <bebarino@gmail.com>
---
Documentation/git-add.txt | 8 ++++----
1 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/Documentation/git-add.txt b/Documentation/git-add.txt
index 45ebf87..e93e606 100644
--- a/Documentation/git-add.txt
+++ b/Documentation/git-add.txt
@@ -76,10 +76,10 @@ OPTIONS
work tree and add them to the index. This gives the user a chance
to review the difference before adding modified contents to the
index.
-
- This effectively runs ``add --interactive``, but bypasses the
- initial command menu and directly jumps to `patch` subcommand.
- See ``Interactive mode'' for details.
++
+This effectively runs `add --interactive`, but bypasses the
+initial command menu and directly jumps to the `patch` subcommand.
+See ``Interactive mode'' for details.
-e, \--edit::
Open the diff vs. the index in an editor and let the user
--
1.6.5.2.155.gbb47
^ permalink raw reply related
* Re: Resolving a merge conflict with git-svn
From: Daniele Segato @ 2009-11-14 0:58 UTC (permalink / raw)
To: Jens Kubieziel; +Cc: git
In-Reply-To: <76ee5f990911131630k41a91f70n5e717befb7693463@mail.gmail.com>
Il giorno sab, 14/11/2009 alle 01.30 +0100, Jens Kubieziel ha scritto:
> Hi,
>
> I recently came across a big conflict. Someone used Subversion and
> made a complete wrong commit. I did a 'git svn rebase' at some point
> and ran into the conflict. My goal at this point was to remove the
> wrong commit, but I found no way how to do it (git-revert needs a
> clean tree; git stash brought [fatal: git-write-tree: error building
> trees,Cannot save the current state]). What way would suggest to
> remove that wrong made commit and continue with the rebase?
I don't know if this could help but I tell you what I would do.
I would abort the conflicting rebase
"backing up" my branch by:
git checkout mybranch
git checkout -b mybranchBackup
then I would do a git reset --hard <last-committed-svn-commit>
at this point a:
git svn rebase
shouldn't give conflict since it should be a fast forward.
Then you should have two branch:
mybranch: which is SVN-up-to-date but has no one of your modification
mybranchBackup: which has an old SVN before the wrong commit but with
all your modifications...
at this point you can use git revert to revert the wrong commit into
your "mybranch".
and then you can cherry-pick all your modification from mybranchBackup
may be you could also been able to rebase upon it....
but I would do an interactive rebase to "see" what's going to do and
being able to control it
like:
git checkout mybranchBackup
git rebase -i mybranch
^ permalink raw reply
* Resolving a merge conflict with git-svn
From: Jens Kubieziel @ 2009-11-14 0:30 UTC (permalink / raw)
To: git
Hi,
I recently came across a big conflict. Someone used Subversion and
made a complete wrong commit. I did a 'git svn rebase' at some point
and ran into the conflict. My goal at this point was to remove the
wrong commit, but I found no way how to do it (git-revert needs a
clean tree; git stash brought [fatal: git-write-tree: error building
trees,Cannot save the current state]). What way would suggest to
remove that wrong made commit and continue with the rebase?
Thanks for any hints.
^ permalink raw reply
* GNU patch: new 2.6 release
From: Andreas Gruenbacher @ 2009-11-14 0:09 UTC (permalink / raw)
To: git
I am pleased to announce my first release of GNU patch,
available by anonymous FTP from:
ftp://ftp.gnu.org/gnu/patch/
The last release dates back to June 2004 with version 2.5.9. A new Savannah
project has been created with the new code repository and the bug-patch
mailing list archive at:
http://savannah.gnu.org/projects/patch
A lot of changes have accumulated since version 2.5.9. The following user
visible changes have been made:
* A regression test suite has been added ("make check").
* A --merge option has been added which will merge a patch file into
the original files similar to merge(1). See the patch(1) manual page for
documentation.
* Unless a file name has been specified on the command line, look only
for file names in the patch until one has been found. This prevents
patch from tripping over garbage that isn't a patch. When conforming
to POSIX, this behavior is turned off and patch will ask for a
file name when none is found.
* All reject files have file name headers now, which allows them to be used as
regular patches.
* When a patch file modifies the same file more than once, patch makes
sure it backs up the original version of the file rather than any
intermediary versions.
* In the above situation, if there are rejects in more than one of those
patches, they all go into the same reject file.
* When the file to be patched is specified on the command line, all patches
are applied to that file. (Previously, the first patch was applied to the
file specified on the command line, and the names of additional files to
patch were taken from header lines in the patch file.)
* The -r option now works correctly even if there are rejects in more than
one file. Use the - argument to discard rejects.
* Rejected hunks come out in unified diff format if the input patch was of
that format, otherwise in ordinary context diff form. Use the
--reject-format option to enforce either "context" or "unified" format.
Timestamps and the "diff -p" (--show-c-function) output are preserved.
Changed lines in context format reject files are correctly indicated
with '!' markers as the format defines. Added and removed lines are
still marked with '+' and '-', respectively.
* The file permissions of reject files are no longer set to match the files
they modify. Instead, they retain the default permissions. This is
consistent with reject files produced with the -r option.
* The --binary option disables the heuristic for stripping CRs from
line endings in patches. This allows to preserve CRs even in mangled
patches, or in patches generated on non-POSIX systems and without the
--binary option.
* Backup files for non-existing files are now created with default
permissions rather than with mode 0: backup files with mode 0 were
causing problems with applications which do not expect unreadable
files.
* The -B, -Y, and -z options (--prefix, --basename-prefix, --suffix) now
imply the simple version control mode, and can be combined.
* Patch rejects more malformed normal format commands and checks for trailing
garbage. It now recognizes ed commands without addresses.
* Change the default value of PATCH_GET to 0. (Previously, the default was 0
under POSIXLY_CORRECT and negative otherwise; this is causing problems
particularly with Perforce.)
* Handle missing timestamps better.
Please email bugs or suggestions to <bug-patch@gnu.org>. (Check the Savannah
project's bug tracker for a list of known issues.)
Thanks,
Andreas
^ permalink raw reply
* Re: [PATCH 1/3] gitweb: Refactor 'log' action generation, adding git_log_body()
From: Jakub Narebski @ 2009-11-13 23:59 UTC (permalink / raw)
To: Nanako Shiraishi; +Cc: git
In-Reply-To: <20091114081050.6117@nanako3.lavabit.com>
On Sat, 14 Nov 2009, Nanako Shiraishi wrote:
> Quoting Jakub Narebski <jnareb@gmail.com>
>
> > Put the main part of 'log' view generation into git_log_body,
> > similarly how it is done for 'shortlog' and 'history' views (and
> > also for 'tags' and 'heads' views).
> >
> > This is preparation for extracting common code between 'log',
> > 'shortlog' and 'history' actions.
> >
> > Signed-off-by: Jakub Narebski <jnareb@gmail.com>
> > ---
> > This is pure refactoring: output should change.
>
> Did you mean "should not change"?
Yes, of course, it should be "output should not change" (as opposed
to later patches, which unify not only code but some of looks).
--
Jakub Narebski
Poland
^ permalink raw reply
* Re: [PATCHv3] Add branch management for releases to gitworkflows
From: Nanako Shiraishi @ 2009-11-13 23:10 UTC (permalink / raw)
To: Raman Gupta; +Cc: Nanako Shiraishi, git, trast, gitster
In-Reply-To: <4AFDE421.5050307@fastmail.fm>
Quoting Raman Gupta <rocketraman@fastmail.fm>
> Nanako Shiraishi wrote:
>> .Update maint to new release
>> [caption="Recipe: "]
>> =====================================
>> -* `git checkout maint`
>> -* `git merge master`
>> +* `git checkout maint`
>> +* `git merge --ff-only master`
>> =====================================
>>
>> -This 'should' fast forward 'maint' from 'master'. If it is not a fast
>> -forward, then 'maint' contained some commits that were not included on
>> +This should fast-forward 'maint' from 'master'. If it is not a
>> +fast-forward, then 'maint' contained some commits that were not included on
>> 'master', which means that the recent feature release could be missing
>> -some fixes made on 'maint'. The exception is if there were any commits
>> -that were cherry-picked to 'maint' as described above in "Merging
>> -upwards". In this case, the merge will not be a fast forward.
>
> I noticed you removed the discussion I added about the situation in
> which maint will *not* be a subset of master i.e. when the user has
> cherry-picked commits from other branches. This type of cherry-pick is
> described as a valid operation, though one to generally be avoided
> earlier in the man page. If we tell users that the occasional
> cherry-pick to maint is ok, then shouldn't we explain how that affects
> the release process?
It is irrelevant that you can cherry-pick to 'maint'.
You can, and Junio does, cherry-pick some commits from master to
maint from time to time. But even if you have such cherry-picked
commits on the maintenance branch, the result, with zero or more
other maintenance commits on top, is always merged back to the
master branch (you can look at "gitk origin/maint origin/master"
to see yourself).
So when Junio tags the release from the tip of the master branch,
it is a superset of the maintenace branch; it is irrelevant if
maint has some commits that are cherry-picked from master.
--
Nanako Shiraishi
http://ivory.ap.teacup.com/nanako3/
^ permalink raw reply
* Re: [PATCH 1/3] gitweb: Refactor 'log' action generation, adding git_log_body()
From: Nanako Shiraishi @ 2009-11-13 23:10 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git
In-Reply-To: <1258074134-27011-2-git-send-email-jnareb@gmail.com>
Quoting Jakub Narebski <jnareb@gmail.com>
> Put the main part of 'log' view generation into git_log_body,
> similarly how it is done for 'shortlog' and 'history' views (and
> also for 'tags' and 'heads' views).
>
> This is preparation for extracting common code between 'log',
> 'shortlog' and 'history' actions.
>
> Signed-off-by: Jakub Narebski <jnareb@gmail.com>
> ---
> This is pure refactoring: output should change.
Did you mean "should not change"?
--
Nanako Shiraishi
http://ivory.ap.teacup.com/nanako3/
^ permalink raw reply
* Re: [PATCHv3] Add branch management for releases to gitworkflows
From: Raman Gupta @ 2009-11-13 22:56 UTC (permalink / raw)
To: Nanako Shiraishi; +Cc: git, trast, gitster
In-Reply-To: <20091114071946.6117@nanako3.lavabit.com>
Nanako Shiraishi wrote:
> .Update maint to new release
> [caption="Recipe: "]
> =====================================
> -* `git checkout maint`
> -* `git merge master`
> +* `git checkout maint`
> +* `git merge --ff-only master`
> =====================================
>
> -This 'should' fast forward 'maint' from 'master'. If it is not a fast
> -forward, then 'maint' contained some commits that were not included on
> +This should fast-forward 'maint' from 'master'. If it is not a
> +fast-forward, then 'maint' contained some commits that were not included on
> 'master', which means that the recent feature release could be missing
> -some fixes made on 'maint'. The exception is if there were any commits
> -that were cherry-picked to 'maint' as described above in "Merging
> -upwards". In this case, the merge will not be a fast forward.
I noticed you removed the discussion I added about the situation in
which maint will *not* be a subset of master i.e. when the user has
cherry-picked commits from other branches. This type of cherry-pick is
described as a valid operation, though one to generally be avoided
earlier in the man page. If we tell users that the occasional
cherry-pick to maint is ok, then shouldn't we explain how that affects
the release process?
Cheers,
Raman
^ permalink raw reply
* Re: [PATCH] Update 'git remote' usage and man page to match.
From: Nanako Shiraishi @ 2009-11-13 22:19 UTC (permalink / raw)
To: Tim Henigan; +Cc: gitster, git
In-Reply-To: <32c343770911121715l7507b2d5j8c6cf8cccd1f1a61@mail.gmail.com>
Quoting Tim Henigan <tim.henigan@gmail.com> writes:
> This commit:
>
> 1) Removes documentation of '--verbose' from the synopsis portion
> of the usage string since it is a general option.
>
> 2) Removes the 'remote' option from 'git remote update' in the
> man page. This option had already been removed from the usage
> string in the code, but the man page was not updated to match.
>
> Signed-off-by: Tim Henigan <tim.henigan@gmail.com>
> ---
The second change is good but why do you remove -v from the
synopsis section? Why is it a good idea? Manual pages for
many other commands list --verbose in their synopsis section.
^ 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