* [PATCH] Add 'git-p4 commit' as an alias for 'git-p4 submit'
From: Marius Storm-Olsen @ 2007-10-09 14:16 UTC (permalink / raw)
To: git; +Cc: simon, Marius Storm-Olsen
Given that git uses 'commit', git-p4's 'sumbit' was a bit confusing at times;
often making me do 'git submit' and 'git-p4 commit' instead.
Signed-off-by: Marius Storm-Olsen <marius@trolltech.com>
---
contrib/fast-import/git-p4 | 1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/contrib/fast-import/git-p4 b/contrib/fast-import/git-p4
index 557649a..52cd2a4 100755
--- a/contrib/fast-import/git-p4
+++ b/contrib/fast-import/git-p4
@@ -1651,6 +1651,7 @@ def printUsage(commands):
commands = {
"debug" : P4Debug,
"submit" : P4Submit,
+ "commit" : P4Submit,
"sync" : P4Sync,
"rebase" : P4Rebase,
"clone" : P4Clone,
--
1.5.3.4.1155.gfe96ee-dirty
^ permalink raw reply related
* Re: [PATCH] mergetool: add support for ECMerge
From: Alan Hadsell @ 2007-10-09 14:21 UTC (permalink / raw)
To: Steffen Prohaska; +Cc: Johannes Schindelin, Git Mailing List, Theodore Tso
In-Reply-To: <236E44B5-361E-4CE3-8C3D-BDAD0569642E@zib.de>
Steffen Prohaska writes:
> WinMerge doesn't support 3-way merges. At least I cannot find any
> indication for 3-way in the manual [1] and the comparison at [2] also
> tells that WinMerge doesn't support 3-way.
>From their FAQ:
Does WinMerge support merging three files? Sometimes it is called
3-way merge, where one file is ancestor. This would be useful for
version control!
Unfortunately not. We acknowledge it would be good feature but have no
plans to implement it in near future. This can be somewhat worked
around by using two WinMerge instances. (One developer has begun
preliminary work on this feature, but it is not yet available, even in
experimental releases.)
^ permalink raw reply
* Re: [PATCH] rebase -i: use diff plumbing instead of porcelain
From: Johannes Sixt @ 2007-10-09 14:26 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Git Mailing List
In-Reply-To: <Pine.LNX.4.64.0710091353140.4174@racer.site>
Johannes Schindelin schrieb:
> When diff drivers are installed, calling "git diff <tree1>..<tree2>"
> calls those drivers. This borks the patch generation of rebase -i.
> So use "git diff-tree -p" instead, which does not call diff drivers.
Thanks a lot! That works much better.
-- Hannes
^ permalink raw reply
* [PATCH] Support cvs via git-shell
From: Johannes Schindelin @ 2007-10-09 14:33 UTC (permalink / raw)
To: gitster, hjemli; +Cc: Jan Wielemaker, Git Mailing List
In-Reply-To: <200710051453.47622.wielemak@science.uva.nl>
This adds cvs support to the git-shell; You can now give new users
a restricted git-shell and they still can commit via git's cvs
emulator.
Note that either the gecos information must be accurate, or you must
provide a $HOME/.gitconfig with the appropriate user credentials.
Since the git-shell is too restricted to allow the user to do it
(on purpose!), it is up to the administrator to take care of that.
Based on an idea by Jan Wielemaker.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
---
Since Jan seems to be too busy to do it (in contrast to everybody
else), I ended up implementing my advices myself. At least that
way, I can take the credit, too, since not many things are left
from the original patch.
shell.c | 27 ++++++++++++++++++++++++++-
1 files changed, 26 insertions(+), 1 deletions(-)
diff --git a/shell.c b/shell.c
index c983fc7..cfe372b 100644
--- a/shell.c
+++ b/shell.c
@@ -1,6 +1,7 @@
#include "cache.h"
#include "quote.h"
#include "exec_cmd.h"
+#include "strbuf.h"
static int do_generic_cmd(const char *me, char *arg)
{
@@ -18,12 +19,34 @@ static int do_generic_cmd(const char *me, char *arg)
return execv_git_cmd(my_argv);
}
+static int do_cvs_cmd(const char *me, char *arg)
+{
+ const char *cvsserver_argv[3] = {
+ "cvsserver", "server", NULL
+ };
+ const char *oldpath = getenv("PATH");
+ struct strbuf newpath = STRBUF_INIT;
+
+ if (!arg || strcmp(arg, "server"))
+ die("git-cvsserver only handles server: %s", arg);
+
+ strbuf_addstr(&newpath, git_exec_path());
+ strbuf_addch(&newpath, ':');
+ strbuf_addstr(&newpath, oldpath);
+
+ setenv("PATH", strbuf_detach(&newpath, NULL), 1);
+
+ return execv_git_cmd(cvsserver_argv);
+}
+
+
static struct commands {
const char *name;
int (*exec)(const char *me, char *arg);
} cmd_list[] = {
{ "git-receive-pack", do_generic_cmd },
{ "git-upload-pack", do_generic_cmd },
+ { "cvs", do_cvs_cmd },
{ NULL },
};
@@ -32,8 +55,10 @@ int main(int argc, char **argv)
char *prog;
struct commands *cmd;
+ if (argc == 2 && !strcmp(argv[1], "cvs server"))
+ argv--;
/* We want to see "-c cmd args", and nothing else */
- if (argc != 3 || strcmp(argv[1], "-c"))
+ else if (argc != 3 || strcmp(argv[1], "-c"))
die("What do you think I am? A shell?");
prog = argv[2];
--
1.5.3.4.1169.g5fb8d
^ permalink raw reply related
* Re: Adding color to git-add--interactive
From: Wincent Colaiuta @ 2007-10-09 14:44 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Jonathan del Strother, Git Mailing List
In-Reply-To: <Pine.LNX.4.64.0710091503460.4174@racer.site>
El 9/10/2007, a las 16:04, Johannes Schindelin escribió:
> On Tue, 9 Oct 2007, Wincent Colaiuta wrote:
>
>> El 9/10/2007, a las 15:06, Jonathan del Strother escribió:
>>
>>> Or am I alone in finding interactive mode basically unreadable?
>>
>> I don't think you're alone. Compared with the nice colorized
>> output from
>> things like git-status, git-log, git-diff and friends, the output of
>> "git-add --interactive" is decidedly hard to read.
>
> And since git-add--interactive is still a script, there is no excuse:
> providing a patch should take the same time and amount of work as
> complaining about the lack of colour.
Why so combative, Johannes? I merely answered one of Jonathan's
questions. Nobody has proffered any "excuses".
And in any case, you're exaggerating. Jonathan said that he's already
invested time in trying to get it working, most certainly more time
than it has taken he, you or I, to write the emails in this thread,
and he's gotten as far as his Perl knowledge permits him.
Cheers,
Wincent
^ permalink raw reply
* [PATCH] Minor usage update in setgitperms.perl
From: Josh England @ 2007-10-09 16:04 UTC (permalink / raw)
To: git; +Cc: Josh England
Signed-off-by: Josh England <jjengla@sandia.gov>
---
contrib/hooks/setgitperms.perl | 7 ++++---
1 files changed, 4 insertions(+), 3 deletions(-)
diff --git a/contrib/hooks/setgitperms.perl b/contrib/hooks/setgitperms.perl
index 5e3b89d..bd48e27 100644
--- a/contrib/hooks/setgitperms.perl
+++ b/contrib/hooks/setgitperms.perl
@@ -8,13 +8,14 @@
# To save permissions/ownership data, place this script in your .git/hooks
# directory and enable a `pre-commit` hook with the following lines:
# #!/bin/sh
-# . git-sh-setup
+# SUBDIRECTORY_OK=1 . git-sh-setup
# $GIT_DIR/hooks/setgitperms.perl -r
#
# To restore permissions/ownership data, place this script in your .git/hooks
-# directory and enable a `post-merge` hook with the following lines:
+# directory and enable a `post-merge` and `post-checkout` hook with the
+# following lines:
# #!/bin/sh
-# . git-sh-setup
+# SUBDIRECTORY_OK=1 . git-sh-setup
# $GIT_DIR/hooks/setgitperms.perl -w
#
use strict;
--
1.5.3.2.111.g5166-dirty
^ permalink raw reply related
* Re: Merge problems with git-mingw
From: Steffen Prohaska @ 2007-10-09 16:33 UTC (permalink / raw)
To: Johannes Sixt; +Cc: Peter Karlsson, Git Mailing List, Johannes Schindelin
In-Reply-To: <470B43D2.6090307@viscovery.net>
On Oct 9, 2007, at 11:03 AM, Johannes Sixt wrote:
> Peter Karlsson schrieb:
>> C:\Program Files\Git\bin>git var -l
>> usage: git-var [-l | <variable>]
>> C:\Program Files\Git\bin>git-var -l
>> fatal: Not a git repository
>> C:\Program Files\Git\bin>git --version
>> git version 1.5.3.mingw.1
>
> For the time being, install this beast in a path without blanks.
>
> This needs fixing, appearently. :(
I have the printf 'callstack' below from the v1.5.3.mingw.1 version
(9c792c5)
Apparently spawnve, which is called in compat/mingw.c, corrupts argv.
I have no idea how to continue debugging. Maybe some one else can
take over.
Steffen
$ git var GIT_COMMITTER_IDENT
argv at git.c:429
3
C:\Program Files (x86)\Git\bin\git.exe
var
C:/Program Files (x86)/Git/bin/git-var
GIT_COMMITTER_IDENT
argv at compat/mingw.c:301
C:/Program Files (x86)/Git/bin/git-var
GIT_COMMITTER_IDENT
(null)
argv at var.c:54
4
C:/Program
Files
(x86)/Git/bin/git-var
GIT_COMMITTER_IDENT
usage: git-var [-l | <variable>]
^ permalink raw reply
* [take 2] Clean up "git log" format with DIFF_FORMAT_NO_OUTPUT
From: Linus Torvalds @ 2007-10-09 16:35 UTC (permalink / raw)
To: Git Mailing List; +Cc: Junio C Hamano
In-Reply-To: <alpine.LFD.0.999.0710081353290.4964@woody.linux-foundation.org>
Clean up "git log" format with DIFF_FORMAT_NO_OUTPUT
This fixes an unnecessary empty line that we add to the log message when
we generate diffs, but don't actually end up printing any due to having
DIFF_FORMAT_NO_OUTPUT set.
This can happen with pickaxe or with rename following. The reason is that
we normally add an empty line between the commit and the diff, but we do
that even for the case where we've then suppressed the actual printing of
the diff.
This also updates a couple of tests that assumed the extraneous empty
line would exist at the end of output.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
---
This is a resend of the original patch, with just the changes to the tests
added to make it pass them all. Both of the tests actually got cleaner, I
think (ie one had the sed script blindly just delete the last line in
order to match it up with the known input, for example).
Linus
log-tree.c | 3 ++-
t/t3900-i18n-commit.sh | 2 +-
t/t4013/diff.log_-SF_master | 1 -
3 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/log-tree.c b/log-tree.c
index 2319154..62edd34 100644
--- a/log-tree.c
+++ b/log-tree.c
@@ -304,7 +304,8 @@ int log_tree_diff_flush(struct rev_info *opt)
* output for readability.
*/
show_log(opt, opt->diffopt.msg_sep);
- if (opt->verbose_header &&
+ if ((opt->diffopt.output_format & ~DIFF_FORMAT_NO_OUTPUT) &&
+ opt->verbose_header &&
opt->commit_format != CMIT_FMT_ONELINE) {
int pch = DIFF_FORMAT_DIFFSTAT | DIFF_FORMAT_PATCH;
if ((pch & opt->diffopt.output_format) == pch)
diff --git a/t/t3900-i18n-commit.sh b/t/t3900-i18n-commit.sh
index fcbabe8..94b1c24 100755
--- a/t/t3900-i18n-commit.sh
+++ b/t/t3900-i18n-commit.sh
@@ -8,7 +8,7 @@ test_description='commit and log output encodings'
. ./test-lib.sh
compare_with () {
- git show -s $1 | sed -e '1,/^$/d' -e 's/^ //' -e '$d' >current &&
+ git show -s $1 | sed -e '1,/^$/d' -e 's/^ //' >current &&
git diff current "$2"
}
diff --git a/t/t4013/diff.log_-SF_master b/t/t4013/diff.log_-SF_master
index 6162ed2..c1599f2 100644
--- a/t/t4013/diff.log_-SF_master
+++ b/t/t4013/diff.log_-SF_master
@@ -4,5 +4,4 @@ Author: A U Thor <author@example.com>
Date: Mon Jun 26 00:02:00 2006 +0000
Third
-
$
^ permalink raw reply related
* Re: Merge problems with git-mingw
From: Johannes Sixt @ 2007-10-09 17:03 UTC (permalink / raw)
To: Steffen Prohaska; +Cc: Peter Karlsson, Git Mailing List, Johannes Schindelin
In-Reply-To: <BA71DD45-9226-4661-9C92-60EEEA8638D0@zib.de>
Steffen Prohaska schrieb:
>
> On Oct 9, 2007, at 11:03 AM, Johannes Sixt wrote:
>
>> Peter Karlsson schrieb:
>>> C:\Program Files\Git\bin>git var -l
>>> usage: git-var [-l | <variable>]
>>> C:\Program Files\Git\bin>git-var -l
>>> fatal: Not a git repository
>>> C:\Program Files\Git\bin>git --version
>>> git version 1.5.3.mingw.1
>>
>> For the time being, install this beast in a path without blanks.
>>
>> This needs fixing, appearently. :(
>
> I have the printf 'callstack' below from the v1.5.3.mingw.1 version
> (9c792c5)
> Apparently spawnve, which is called in compat/mingw.c, corrupts argv.
Thank you. Here is a quick-fix.
-- Hannes
diff --git a/compat/mingw.c b/compat/mingw.c
index 8bb0dba..361216f 100644
--- a/compat/mingw.c
+++ b/compat/mingw.c
@@ -303,7 +303,7 @@ void openlog(const char *ident, int option,
{
}
-static const char *quote_arg(const char *arg)
+const char *quote_arg(const char *arg)
{
/* count chars to quote */
int len = 0, n = 0;
diff --git a/exec_cmd.c b/exec_cmd.c
index bad4843..7ab5a0f 100644
--- a/exec_cmd.c
+++ b/exec_cmd.c
@@ -129,7 +129,8 @@ int execv_git_cmd(const char **argv)
*/
tmp = argv[0];
- argv[0] = git_command;
+ extern const char *quote_arg(const char *arg);
+ argv[0] = quote_arg(git_command);
trace_argv_printf(argv, -1, "trace: exec:");
^ permalink raw reply related
* Re: git: avoiding merges, rebasing
From: Benoit SIGOURE @ 2007-10-09 18:06 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git list
In-Reply-To: <Pine.LNX.4.64.0710091141440.4174@racer.site>
[-- Attachment #1: Type: text/plain, Size: 681 bytes --]
On Oct 9, 2007, at 12:43 PM, Johannes Schindelin wrote:
> Hi,
>
> On Mon, 8 Oct 2007, Benoit SIGOURE wrote:
>
>> [as usual, I forgot the attachment...]
>
> Two comments:
>
> - by not inlining you made it hard to review your script. Therefore I
> will not do it.
:|
>
> - Try to avoid naming the script git-merge-*; these scripts/
> programs are
> merge _strategies_, not merge _drivers_ (and yes, we already have
> two
> programs violating this rule -- merge-base and merge-file -- but
> that
> does not mean that you are free to add to the pile).
I'm open to better suggestions.
Cheers,
--
Benoit Sigoure aka Tsuna
EPITA Research and Development Laboratory
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 186 bytes --]
^ permalink raw reply
* Re: Merge problems with git-mingw
From: Linus Torvalds @ 2007-10-09 18:09 UTC (permalink / raw)
To: Johannes Sixt
Cc: Steffen Prohaska, Peter Karlsson, Git Mailing List,
Johannes Schindelin
In-Reply-To: <470BB44B.3030500@viscovery.net>
On Tue, 9 Oct 2007, Johannes Sixt wrote:
>
> + extern const char *quote_arg(const char *arg);
> + argv[0] = quote_arg(git_command);
Extern declarations inside a local scope will not work on more modern gcc
versions. Don't do it. Do proper prototyping in proper scope.
Linus
^ permalink raw reply
* GNU-style ChangeLog merge driver for Git (was: Re: git: avoiding merges, rebasing)
From: Benoit SIGOURE @ 2007-10-09 18:19 UTC (permalink / raw)
To: Bruno Haible; +Cc: bug-gnulib, git list
In-Reply-To: <200710091403.26047.bruno@clisp.org>
[-- Attachment #1: Type: text/plain, Size: 3366 bytes --]
On Oct 9, 2007, at 2:03 PM, Bruno Haible wrote:
> Hello Benoit,
>
> Thanks for working on this. But this merge driver has a few major
> nits.
>
>
> 1) While my ChangeLog file was locally unmodified but some pulled
> in commits
> should modify it, "git pull" stopped and said:
>
> ChangeLog: needs update
> fatal: Entry 'ChangeLog' not uptodate. Cannot merge.
>
> [I cannot swear on this, because I did not do a "git status" before
> the
> "git pull", but this is in a directory where I usually have no
> pending diffs.]
I'll check but I'm afraid that Git bails out before actually trying
the merge driver.
>
> The ChangeLog in question is the one from gnulib
> (git clone git://git.sv.gnu.org/gnulib).
>
>
> 2) This "merge driver" did much more than sorting in a merge: it
> sorted the
> entire file! In doing so,
> - It changed the order of ChangeLog entries in a way that does
> not represent
> the historical commit order.
> - For ChangeLog entries with multiple contributors, it shuffled
> around these
> extra contributors to other ChangeLog entries.
> - Near the end of the file, it made a change that I cannot explain.
>
> Find attached a context diff of all the bad changes that it did.
>
Yes, it's pretty stupid, I hacked this in a hurry. I'll try to
improve it so that it doesn't have these undesired side-effects.
>
> In my opinion, a merge driver should not do changes to the file except
> in the range of lines where the conflict occurred. For a ChangeLog
> driver,
> all uncommitted entries should be collected at the top of the file,
> because
> 1. ChangeLogs are kept in the order of historical commit in the
> central
> repository,
> 2. other developers always look at the top of the ChangeLog; if a
> ChangeLog
> entries is inserted second or third after some already present
> entries,
> the danger is too high that the change gets unnoticed.
>
> So "git-merge-changelog OLD CURRENT OTHERS" should IMO do the
> following:
> 1) Collect the changes between OLD and HEAD (I don't know if that
> is CURRENT
> or OTHERS?), in two categories:
> - added entries,
> - changed and removed entries.
> 2) Back out the added entries, keeping only the changed and removed
> entries
> as modifications.
> 3) Do a normal merge between this and the pulled in remote branch
> (I don't
> know if that is OTHERS or CURRENT?). If that merge gives a
> conflict,
> bail out.
> 4) Insert the added entries at the top, in the same order as they were
> originally (no sorting).
>
> Bruno
> <git-merge-changelog-blunder>
OK I'll try to rework the driver so that it implements this. It will
take some time though, I'm quite busy these days.
Akim Demaille would also like it to squash the commits added by the
merge (the new commits in OTHERS):
YYYY-MM-DD Author <who@where.com>
Merge whatever:
YYYY-MM-DD Someone Else <foo@bar.com>
Some change.
* FileChanged.c: Whatever.
YYYY-MM-DD Who Cares <who@cares.com>
Some other change.
* OtherFile.c: Do it.
I thought this was mandated by the GNU Coding Standards but I
checked, it doesn't say anything about merges. Would this sort of
strategy be useful to you? Should it be default (or enabled by some
--squash option)?
Cheers,
--
Benoit Sigoure aka Tsuna
EPITA Research and Development Laboratory
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 186 bytes --]
^ permalink raw reply
* Re: [PATCH] Fixed crash in fetching remote tags when there is not tags.
From: Alex Riesen @ 2007-10-09 18:20 UTC (permalink / raw)
To: Väinö Järvelä; +Cc: git, Junio C Hamano
In-Reply-To: <81553116-3A4F-4526-A772-9A43C53D3E22@pp.inet.fi>
Väinö Järvelä, Tue, Oct 09, 2007 12:52:01 +0200:
> Hi,
>
> These patches should have been numbered, sorry, The test patch was
> supposed be number 1 of 2.
>
> The patches were done on top of next. The fix should be checked, as
> it's mostly a quick fix to get it to work, probably not the correct
> way to fix that bug, or is it?
Your test does not crash on my system and your fix is obviously bogus.
Just take a look at the only call site of the tail_link_ref: ret
cannot be NULL. alloc_ref will crash in memset, if this were the case.
If you can reproduce the crash reliably, try compiling git with -g and
run it in your test with valgrind or gdb (assuming these are available
to you).
^ permalink raw reply
* Re: [PATCH] Add 'git-p4 commit' as an alias for 'git-p4 submit'
From: Simon Hausmann @ 2007-10-09 19:08 UTC (permalink / raw)
To: Marius Storm-Olsen; +Cc: git
In-Reply-To: <1191939369-18811-1-git-send-email-marius@trolltech.com>
[-- Attachment #1: Type: text/plain, Size: 316 bytes --]
On Tuesday 09 October 2007 16:16:09 Marius Storm-Olsen wrote:
> Given that git uses 'commit', git-p4's 'sumbit' was a bit confusing at
> times; often making me do 'git submit' and 'git-p4 commit' instead.
>
> Signed-off-by: Marius Storm-Olsen <marius@trolltech.com>
Acked-By: Simon Hausmann <simon@lst.de>
Simon
[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* [PATCH 1/2] git add -i: Fix parsing of abbreviated hunk headers
From: Jean-Luc Herren @ 2007-10-09 19:29 UTC (permalink / raw)
To: git; +Cc: gitster
The unified diff format allows one-line ranges to be abbreviated
by omiting the size. The hunk header "@@ -10,1 +10,1 @@" can be
expressed as "@@ -10 +10 @@", but this wasn't properly parsed in
all cases.
Such abbreviated hunk headers are generated when a one-line change
(add, remove or modify) appears without context; for example
because the file is a one-liner itself or because GIT_DIFF_OPTS
was set to '-u0'. If the user then runs 'git add -i' and enters
the 'patch' command for that file, perl complains about undefined
variables.
Signed-off-by: Jean-Luc Herren <jlh@gmx.ch>
---
git-add--interactive.perl | 11 +++++------
1 files changed, 5 insertions(+), 6 deletions(-)
diff --git a/git-add--interactive.perl b/git-add--interactive.perl
index be68814..15b3f5b 100755
--- a/git-add--interactive.perl
+++ b/git-add--interactive.perl
@@ -360,7 +360,9 @@ sub hunk_splittable {
sub parse_hunk_header {
my ($line) = @_;
my ($o_ofs, $o_cnt, $n_ofs, $n_cnt) =
- $line =~ /^@@ -(\d+)(?:,(\d+)) \+(\d+)(?:,(\d+)) @@/;
+ $line =~ /^@@ -(\d+)(?:,(\d+))? \+(\d+)(?:,(\d+))? @@/;
+ $o_cnt = 1 unless defined $o_cnt;
+ $n_cnt = 1 unless defined $n_cnt;
return ($o_ofs, $o_cnt, $n_ofs, $n_cnt);
}
@@ -705,9 +707,6 @@ sub patch_update_cmd {
parse_hunk_header($text->[0]);
if (!$_->{USE}) {
- if (!defined $o_cnt) { $o_cnt = 1; }
- if (!defined $n_cnt) { $n_cnt = 1; }
-
# We would have added ($n_cnt - $o_cnt) lines
# to the postimage if we were to use this hunk,
# but we didn't. So the line number that the next
@@ -719,10 +718,10 @@ sub patch_update_cmd {
if ($n_lofs) {
$n_ofs += $n_lofs;
$text->[0] = ("@@ -$o_ofs" .
- ((defined $o_cnt)
+ (($o_cnt != 1)
? ",$o_cnt" : '') .
" +$n_ofs" .
- ((defined $n_cnt)
+ (($n_cnt != 1)
? ",$n_cnt" : '') .
" @@\n");
}
--
1.5.3.4
^ permalink raw reply related
* [PATCH 2/2] git add -i: Remove unused variables
From: Jean-Luc Herren @ 2007-10-09 19:34 UTC (permalink / raw)
To: git; +Cc: gitster
Signed-off-by: Jean-Luc Herren <jlh@gmx.ch>
---
Maybe it's a matter of opinion which of the following is better.
The later makes it clearer that some return values are being
thrown away, but some people might consider it noise. I chose the
first one for now.
my ($a, $b) = function(...)
my ($a, $b, undef, undef) = function(...)
git-add--interactive.perl | 16 ++++++----------
1 files changed, 6 insertions(+), 10 deletions(-)
diff --git a/git-add--interactive.perl b/git-add--interactive.perl
index 15b3f5b..ac598f8 100755
--- a/git-add--interactive.perl
+++ b/git-add--interactive.perl
@@ -374,9 +374,8 @@ sub split_hunk {
# it can be split, but we would need to take care of
# overlaps later.
- my ($o_ofs, $o_cnt, $n_ofs, $n_cnt) = parse_hunk_header($text->[0]);
+ my ($o_ofs, undef, $n_ofs) = parse_hunk_header($text->[0]);
my $hunk_start = 1;
- my $next_hunk_start;
OUTER:
while (1) {
@@ -443,8 +442,8 @@ sub split_hunk {
for my $hunk (@split) {
$o_ofs = $hunk->{OLD};
$n_ofs = $hunk->{NEW};
- $o_cnt = $hunk->{OCNT};
- $n_cnt = $hunk->{NCNT};
+ my $o_cnt = $hunk->{OCNT};
+ my $n_cnt = $hunk->{NCNT};
my $head = ("@@ -$o_ofs" .
(($o_cnt != 1) ? ",$o_cnt" : '') .
@@ -459,7 +458,7 @@ sub split_hunk {
sub find_last_o_ctx {
my ($it) = @_;
my $text = $it->{TEXT};
- my ($o_ofs, $o_cnt, $n_ofs, $n_cnt) = parse_hunk_header($text->[0]);
+ my ($o_ofs, $o_cnt) = parse_hunk_header($text->[0]);
my $i = @{$text};
my $last_o_ctx = $o_ofs + $o_cnt;
while (0 < --$i) {
@@ -531,8 +530,7 @@ sub coalesce_overlapping_hunks {
for (grep { $_->{USE} } @in) {
my $text = $_->{TEXT};
- my ($o_ofs, $o_cnt, $n_ofs, $n_cnt) =
- parse_hunk_header($text->[0]);
+ my ($o_ofs) = parse_hunk_header($text->[0]);
if (defined $last_o_ctx &&
$o_ofs <= $last_o_ctx) {
merge_hunk($out[-1], $_);
@@ -699,7 +697,7 @@ sub patch_update_cmd {
@hunk = coalesce_overlapping_hunks(@hunk);
- my ($o_lofs, $n_lofs) = (0, 0);
+ my $n_lofs = 0;
my @result = ();
for (@hunk) {
my $text = $_->{TEXT};
@@ -806,8 +804,6 @@ sub main_loop {
}
}
-my @z;
-
refresh();
status_cmd();
main_loop();
--
1.5.3.4
^ permalink raw reply related
* Re: GNU-style ChangeLog merge driver for Git
From: Bruno Haible @ 2007-10-09 19:38 UTC (permalink / raw)
To: Benoit SIGOURE; +Cc: bug-gnulib, git list
In-Reply-To: <BC06CC09-FD81-4153-AA54-A1A74250946B@lrde.epita.fr>
Hello Benoit,
> Akim Demaille would also like it to squash the commits added by the
> merge (the new commits in OTHERS):
>
> YYYY-MM-DD Author <who@where.com>
>
> Merge whatever:
>
> YYYY-MM-DD Someone Else <foo@bar.com>
> Some change.
> * FileChanged.c: Whatever.
>
> YYYY-MM-DD Who Cares <who@cares.com>
> Some other change.
> * OtherFile.c: Do it.
>
> I thought this was mandated by the GNU Coding Standards but I
> checked, it doesn't say anything about merges. Would this sort of
> strategy be useful to you? Should it be default (or enabled by some
> --squash option)?
This merge is occurring in a different situation:
The situation where we need ChangeLog merging most often is when a developer
has made changes on his own and pulls in the changes from the remote repository
(via "git stash; git pull; git stash apply").
The situation that Akim is describing is that he pulls changes from the
repository of Someone Else and Who Cares, and then pushes them into the
central repository, under his responsibility.
For the first situation, the non-remote ChangeLog entries should be moved
to the top, without modification or indentation.
For the second situation, three different styles are in use at GNU
(because they don't use "Signed-off" lines):
1) unmodified copying of the ChangeLog entries:
YYYY-MM-DD Someone Else <foo@bar.com>
Some change.
* FileChanged.c: Whatever.
YYYY-MM-DD Who Cares <who@cares.com>
Some other change.
* OtherFile.c: Do it.
2) copying with lieutenant's email address, like Akim described it:
YYYY-MM-DD Lieu Tenant <who@where.com>
YYYY-MM-DD Someone Else <foo@bar.com>
Some change.
* FileChanged.c: Whatever.
YYYY-MM-DD Who Cares <who@cares.com>
Some other change.
* OtherFile.c: Do it.
3) similar, but with indentation of the entire copied-in ChangeLog entries:
YYYY-MM-DD Lieu Tenant <who@where.com>
YYYY-MM-DD Someone Else <foo@bar.com>
Some change.
* FileChanged.c: Whatever.
YYYY-MM-DD Who Cares <who@cares.com>
Some other change.
* OtherFile.c: Do it.
First of all, your merge driver could try to guess whether we're in the
first or second situation (maybe by testing whether the names in the
ChangeLog entry match the [user]name from the git config).
Then, for the second situation, there can be some flag in the driver or in
the git config that describes which of the 3 styles to apply.
Bruno
^ permalink raw reply
* Proposed command: git-sync
From: Sven Herzberg @ 2007-10-09 19:26 UTC (permalink / raw)
To: git
[-- Attachment #1: Type: text/plain, Size: 250 bytes --]
I really regularly find myself typing git pull directly after git push.
That's why I write a small shell script that might be added to the stock
git distribution.
Regards,
Sven
PS: Please add me to the CC of your replies, I don't read this list.
[-- Attachment #2: git-sync --]
[-- Type: text/plain, Size: 34 bytes --]
#!/bin/bash
git push && git pull
^ permalink raw reply
* Re: Proposed command: git-sync
From: Eyvind Bernhardsen @ 2007-10-09 19:50 UTC (permalink / raw)
To: Sven Herzberg; +Cc: git
In-Reply-To: <470BD5CF.9050201@imendio.com>
On 9. okt.. 2007, at 21.26, Sven Herzberg wrote:
> I really regularly find myself typing git pull directly after git
> push.
> That's why I write a small shell script that might be added to the
> stock
> git distribution.
>
> Regards,
> Sven
>
> PS: Please add me to the CC of your replies, I don't read this list.
> #!/bin/bash
>
> git push && git pull
I know this isn't really helpful, but you can accomplish the same
thing by putting the following in your ~/.gitconfig:
[alias]
sync = "! git push && git pull"
Eyvind Bernhardsen
^ permalink raw reply
* Re: Problem with git-cvsimport
From: Eyvind Bernhardsen @ 2007-10-09 19:41 UTC (permalink / raw)
To: Thomas Pasch; +Cc: git, Jan Wielemaker, Gerald (Jerry) Carter
In-Reply-To: <470B8049.1090308@samba.org>
On 9. okt.. 2007, at 15.21, Gerald (Jerry) Carter wrote:
> I would actually plug using cvs2svn to convert directly to git.
> See this thread for Michael's original announcement.
>
> http://marc.info/?l=git&m=118592701426175&w=2
Seconded! I've tried git-cvsimport, parsecvs, fromcvs, and cvs2svn on
my employer's many large CVS modules, and cvs2svn is the only one that
has never mangled an import.
That said, it is a work in progress, so there are some caveats:
* Setting up the direct conversion to git is more work than it should
(and probably will, eventually) be.
* There is no support for incremental importing, and git-cvsimport
_will_ mess up your git repository sooner or later if you try to use
it for subsequent incremental imports.
* Tags each get a branch with a single commit, with the actual tag
pointing to that commit. This makes it harder than necessary to
figure out what the history looks like; gitk's default view won't show
any tags, for example, since it only shows the master branch and not
the single-commit tag branches.
* Branches all get a useless commit at their branch point. All
branches from the main branch appear to be merged from the vendor
branch (ie, the useless commit has the vendor branch as an extra
parent), which might make sense to someone who knows what the vendor
branch is for, but makes no sense to me. This combined with the
previous point makes "gitk --all" look needlessly spaghetti-like if
you have a slightly complicated CVS history.
To sum up, cvs2svn gets the important stuff right, but has some sharp
corners you need to watch so you don't put an eye out.
Eyvind Bernhardsen
^ permalink raw reply
* [PATCH v2] mergetool: support setting path to tool as config var mergetool.<tool>.path
From: Steffen Prohaska @ 2007-10-09 20:54 UTC (permalink / raw)
To: tytso; +Cc: frank, Johannes.Schindelin, git, Steffen Prohaska
This commit adds a mechanism to provide absolute paths to the
external programs called by 'git mergetool'. A path can be
specified in the configuation variable mergetool.<tool>.path.
The configuration variable is similar to how we name branches
and remotes. It is extensible if we need to specify more details
about a tool.
The mechanism added by this patch is orthogonal to the existing
merge.tool configuration variable:
1) merge.tool selects a tool from a list of known programs for which
command line arguments and the mechanism for returning merge results is know.
2) mergetool.<tool>.path provides details on how to locate the selected
tool in the filesystem. Paths for several tools can be configured simultaneously.
The mechanism is especially useful on Windows, where external
programs are unlikely to be in PATH.
Signed-off-by: Steffen Prohaska <prohaska@zib.de>
---
Documentation/git-mergetool.txt | 6 ++
git-mergetool.sh | 97 +++++++++++++++++++++-----------------
2 files changed, 60 insertions(+), 43 deletions(-)
This updated patch is based on the the comments and suggestions by
Theodor, Frank, and Johannes.
Steffen
diff --git a/Documentation/git-mergetool.txt b/Documentation/git-mergetool.txt
index 6c32c6d..17a33e7 100644
--- a/Documentation/git-mergetool.txt
+++ b/Documentation/git-mergetool.txt
@@ -31,6 +31,12 @@ If a merge resolution program is not specified, 'git mergetool'
will use the configuration variable merge.tool. If the
configuration variable merge.tool is not set, 'git mergetool'
will pick a suitable default.
++
+You can explicitly provide a full path to the tool by setting the
+configuration variable mergetool.<tool>.path. For example, you
+can configure the absolute path to kdiff3 by setting
+mergetool.kdiff3.path. Otherise, 'git mergetool' assumes the tool
+is available in PATH.
Author
------
diff --git a/git-mergetool.sh b/git-mergetool.sh
index 9f4f313..1e4583f 100755
--- a/git-mergetool.sh
+++ b/git-mergetool.sh
@@ -192,10 +192,10 @@ merge_file () {
case "$merge_tool" in
kdiff3)
if base_present ; then
- (kdiff3 --auto --L1 "$path (Base)" --L2 "$path (Local)" --L3 "$path (Remote)" \
+ ("$merge_tool_path" --auto --L1 "$path (Base)" --L2 "$path (Local)" --L3 "$path (Remote)" \
-o "$path" -- "$BASE" "$LOCAL" "$REMOTE" > /dev/null 2>&1)
else
- (kdiff3 --auto --L1 "$path (Local)" --L2 "$path (Remote)" \
+ ("$merge_tool_path" --auto --L1 "$path (Local)" --L2 "$path (Remote)" \
-o "$path" -- "$LOCAL" "$REMOTE" > /dev/null 2>&1)
fi
status=$?
@@ -203,35 +203,35 @@ merge_file () {
;;
tkdiff)
if base_present ; then
- tkdiff -a "$BASE" -o "$path" -- "$LOCAL" "$REMOTE"
+ "$merge_tool_path" -a "$BASE" -o "$path" -- "$LOCAL" "$REMOTE"
else
- tkdiff -o "$path" -- "$LOCAL" "$REMOTE"
+ "$merge_tool_path" -o "$path" -- "$LOCAL" "$REMOTE"
fi
status=$?
save_backup
;;
meld|vimdiff)
touch "$BACKUP"
- $merge_tool -- "$LOCAL" "$path" "$REMOTE"
+ "$merge_tool_path" -- "$LOCAL" "$path" "$REMOTE"
check_unchanged
save_backup
;;
gvimdiff)
touch "$BACKUP"
- gvimdiff -f -- "$LOCAL" "$path" "$REMOTE"
+ "$merge_tool_path" -f -- "$LOCAL" "$path" "$REMOTE"
check_unchanged
save_backup
;;
xxdiff)
touch "$BACKUP"
if base_present ; then
- xxdiff -X --show-merged-pane \
+ "$merge_tool_path" -X --show-merged-pane \
-R 'Accel.SaveAsMerged: "Ctrl-S"' \
-R 'Accel.Search: "Ctrl+F"' \
-R 'Accel.SearchForward: "Ctrl-G"' \
--merged-file "$path" -- "$LOCAL" "$BASE" "$REMOTE"
else
- xxdiff -X --show-merged-pane \
+ "$merge_tool_path" -X --show-merged-pane \
-R 'Accel.SaveAsMerged: "Ctrl-S"' \
-R 'Accel.Search: "Ctrl+F"' \
-R 'Accel.SearchForward: "Ctrl-G"' \
@@ -243,18 +243,18 @@ merge_file () {
opendiff)
touch "$BACKUP"
if base_present; then
- opendiff "$LOCAL" "$REMOTE" -ancestor "$BASE" -merge "$path" | cat
+ "$merge_tool_path" "$LOCAL" "$REMOTE" -ancestor "$BASE" -merge "$path" | cat
else
- opendiff "$LOCAL" "$REMOTE" -merge "$path" | cat
+ "$merge_tool_path" "$LOCAL" "$REMOTE" -merge "$path" | cat
fi
check_unchanged
save_backup
;;
emerge)
if base_present ; then
- emacs -f emerge-files-with-ancestor-command "$LOCAL" "$REMOTE" "$BASE" "$(basename "$path")"
+ "$merge_tool_path" -f emerge-files-with-ancestor-command "$LOCAL" "$REMOTE" "$BASE" "$(basename "$path")"
else
- emacs -f emerge-files-command "$LOCAL" "$REMOTE" "$(basename "$path")"
+ "$merge_tool_path" -f emerge-files-command "$LOCAL" "$REMOTE" "$(basename "$path")"
fi
status=$?
save_backup
@@ -297,17 +297,38 @@ do
shift
done
+valid_tool() {
+ case "$1" in
+ kdiff3 | tkdiff | xxdiff | meld | opendiff | emerge | vimdiff | gvimdiff)
+ ;; # happy
+ *)
+ return 1
+ ;;
+ esac
+}
+
+init_merge_tool_path() {
+ merge_tool_path=`git config mergetool.$1.path`
+ if test -z "$merge_tool_path" ; then
+ case "$merge_tool" in
+ emerge)
+ merge_tool_path=emacs
+ ;;
+ *)
+ merge_tool_path=$merge_tool
+ ;;
+ esac
+ fi
+}
+
+
if test -z "$merge_tool"; then
merge_tool=`git config merge.tool`
- case "$merge_tool" in
- kdiff3 | tkdiff | xxdiff | meld | opendiff | emerge | vimdiff | gvimdiff | "")
- ;; # happy
- *)
+ test -n "$merge_tool" || valid_tool "$merge_tool" || {
echo >&2 "git config option merge.tool set to unknown tool: $merge_tool"
echo >&2 "Resetting to default..."
unset merge_tool
- ;;
- esac
+ }
fi
if test -z "$merge_tool" ; then
@@ -329,40 +350,30 @@ if test -z "$merge_tool" ; then
merge_tool_candidates="$merge_tool_candidates opendiff emerge vimdiff"
echo "merge tool candidates: $merge_tool_candidates"
for i in $merge_tool_candidates; do
- if test $i = emerge ; then
- cmd=emacs
- else
- cmd=$i
- fi
- if type $cmd > /dev/null 2>&1; then
+ init_merge_tool_path $i
+ if type "$merge_tool_path" > /dev/null 2>&1; then
merge_tool=$i
break
fi
done
if test -z "$merge_tool" ; then
- echo "No available merge resolution programs available."
+ echo "No known merge resolution program available."
exit 1
fi
+else
+ valid_tool "$merge_tool" || {
+ echo >&2 "Unknown merge_tool $merge_tool"
+ exit 1
+ }
+
+ init_merge_tool_path "$merge_tool"
+
+ if ! type "$merge_tool_path" > /dev/null 2>&1; then
+ echo "The merge tool $merge_tool is not available as '$merge_tool_path'"
+ exit 1
+ fi
fi
-case "$merge_tool" in
- kdiff3|tkdiff|meld|xxdiff|vimdiff|gvimdiff|opendiff)
- if ! type "$merge_tool" > /dev/null 2>&1; then
- echo "The merge tool $merge_tool is not available"
- exit 1
- fi
- ;;
- emerge)
- if ! type "emacs" > /dev/null 2>&1; then
- echo "Emacs is not available"
- exit 1
- fi
- ;;
- *)
- echo "Unknown merge tool: $merge_tool"
- exit 1
- ;;
-esac
if test $# -eq 0 ; then
files=`git ls-files -u | sed -e 's/^[^ ]* //' | sort -u`
--
1.5.3.3.127.g40d17
^ permalink raw reply related
* Re: removing content from git history
From: Bill Lear @ 2007-10-09 20:58 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: Linus Torvalds, J. Bruce Fields, Michael Hendricks, git
In-Reply-To: <20070221212129.GD26525@spearce.org>
I'm resurrecting this old thread, as we have come across a similar need and
I could not tell if this has been settled. More below...
On Wednesday, February 21, 2007 at 16:21:30 (-0500) Shawn O. Pearce writes:
>Linus Torvalds <torvalds@linux-foundation.org> wrote:
>> The probnlem there is that most conversion scripts that use
>> "write_sha1_file()" will want to *read* that file later. If
>> git-fast-import hasn't generated the pack yet (because it's still waiting
>> for more data), that will not work at all.
>
>Yes, indeed...
>
>> So then you basically force the conversion script to keep remembering all
>> the old object data (using something like pretend_sha1_file), or you limit
>> it to things that just always re-write the whole object and never need any
>> old object references that they might have written.
>>
>> A lot of conversions tend to be incremental, ie they will depend on the
>> data they converted previously.
>
>Which is why I was actually thinking of flipping this on its head.
>Libify git-apply and embed that into fast-import, then one of the
>native input formats might just be an mbox, or something close enough
>that a simple C/perl/sed prefilter could make an mbox into the input.
>
>fast-import can (and does if necessary) go back to access the
>packfile it is writing. It has the index data held in memory and
>uses only OBJ_OFS_REF so that sha1_file.c can unpack deltas just
>fine, even though we lack an index file and have not completely
>checksummed the pack itself.
>
>So although no other Git process can use the packfile, it is usuable
>from within fast-import...
As I understand this thread, it does not appear that a resolution
was reached. Our company has content in our central git repository
that we need to remove per a contractual obligation. I believe the
content in question is limited to one sub-directory, that has existed
since (or near to) the beginning of the repo, if that matters. We
obviously would just like to issue a "git nuke" operation and be done
with it, if that is available. Barring that, we could probably follow
reasonably simple steps to purge the content and rebuild the repo.
So, what options do we have at present?
Bill
^ permalink raw reply
* Re: [StGit PATCH 09/13] Clear up the semantics of Series.new_patch
From: Catalin Marinas @ 2007-10-09 21:01 UTC (permalink / raw)
To: Karl Hasselström; +Cc: David Kågedal, git
In-Reply-To: <20071008132524.GA11253@diana.vm.bytemark.co.uk>
On 08/10/2007, Karl Hasselström <kha@treskal.com> wrote:
> On 2007-10-08 14:16:10 +0100, Catalin Marinas wrote:
>
> > On 14/09/2007, David Kågedal <davidk@lysator.liu.se> wrote:
> >
> > > + assert commit or (top and bottom)
> > > + assert not before_existing or (top and bottom)
> > > + assert not (commit and before_existing)
> > > + assert (top and bottom) or (not top and not bottom)
> > > + assert not top or (bottom == git.get_commit(top).get_parent())
> >
> > The last assertion here prevents the use of 'stg pick --reverse'.
> > This command creates an unapplied patch with top and bottom reversed
> > and pushes it to force a three-way merge.
> >
> > It seems to work OK if I comment it out but I wonder whether it will
> > break in the future with the planned removal of the top and bottom
> > files.
>
> I think the assert represents a real constraint, namely that there has
> to be a 1:1 correspondance between patches and commits.
>
> Couldn't "stg pick --reverse" create a new commit and use that? That
> is, given that we want to revert commit C, create a new commit C* with
Series.new_patch already creates a commit, why should we move the
functionality to 'pick'? The only call to new_patch with commit=False
seems to be from 'uncommit' (and it makes sense indeed).
> And shouldn't there be a test for this? :-)
Yes :-). I think there are many other tests needed. It would be useful
to do a code coverage with the existing tests to see what we are
missing. Unit testing might be useful as well but we all have limited
spare time.
--
Catalin
^ permalink raw reply
* Re: removing content from git history
From: J. Bruce Fields @ 2007-10-09 21:02 UTC (permalink / raw)
To: Bill Lear; +Cc: Shawn O. Pearce, Linus Torvalds, Michael Hendricks, git
In-Reply-To: <18187.60305.613904.547916@lisa.zopyra.com>
On Tue, Oct 09, 2007 at 03:58:57PM -0500, Bill Lear wrote:
> As I understand this thread, it does not appear that a resolution
> was reached. Our company has content in our central git repository
> that we need to remove per a contractual obligation. I believe the
> content in question is limited to one sub-directory, that has existed
> since (or near to) the beginning of the repo, if that matters. We
> obviously would just like to issue a "git nuke" operation and be done
> with it, if that is available. Barring that, we could probably follow
> reasonably simple steps to purge the content and rebuild the repo.
>
> So, what options do we have at present?
Have you looked at git-filter-branch in a recent version of git? The
man page has some good examples.
--b.
^ permalink raw reply
* [PATCH 4/6] manual: add some markup.
From: Ralf Wildenhues @ 2007-10-09 21:03 UTC (permalink / raw)
To: git
In-Reply-To: <20071009205755.GB31317@ins.uni-bonn.de>
---
Documentation/glossary.txt | 2 +-
Documentation/user-manual.txt | 10 +++++-----
2 files changed, 6 insertions(+), 6 deletions(-)
diff --git a/Documentation/glossary.txt b/Documentation/glossary.txt
index 5645177..fc18744 100644
--- a/Documentation/glossary.txt
+++ b/Documentation/glossary.txt
@@ -281,7 +281,7 @@ This commit is referred to as a "merge commit", or sometimes just a
[[def_pickaxe]]pickaxe::
The term <<def_pickaxe,pickaxe>> refers to an option to the diffcore
routines that help select changes that add or delete a given text
- string. With the --pickaxe-all option, it can be used to view the full
+ string. With the `--pickaxe-all` option, it can be used to view the full
<<def_changeset,changeset>> that introduced or removed, say, a
particular line of text. See gitlink:git-diff[1].
diff --git a/Documentation/user-manual.txt b/Documentation/user-manual.txt
index 2b1b324..df482e6 100644
--- a/Documentation/user-manual.txt
+++ b/Documentation/user-manual.txt
@@ -1536,7 +1536,7 @@ dangling tree b24c2473f1fd3d91352a624795be026d64c8841f
Dangling objects are not a problem. At worst they may take up a little
extra disk space. They can sometimes provide a last-resort method for
recovering lost work--see <<dangling-objects>> for details. However, if
-you wish, you can remove them with gitlink:git-prune[1] or the --prune
+you wish, you can remove them with gitlink:git-prune[1] or the `--prune`
option to gitlink:git-gc[1]:
-------------------------------------------------
@@ -1555,7 +1555,7 @@ Recovering lost changes
Reflogs
^^^^^^^
-Say you modify a branch with gitlink:git-reset[1] --hard, and then
+Say you modify a branch with `gitlink:git-reset[1] --hard`, and then
realize that the branch was the only reference you had to that point in
history.
@@ -1684,7 +1684,7 @@ $ git pull
More generally, a branch that is created from a remote branch will pull
by default from that branch. See the descriptions of the
branch.<name>.remote and branch.<name>.merge options in
-gitlink:git-config[1], and the discussion of the --track option in
+gitlink:git-config[1], and the discussion of the `--track` option in
gitlink:git-checkout[1], to learn how to control these defaults.
In addition to saving you keystrokes, "git pull" also helps you by
@@ -2412,7 +2412,7 @@ $ git rebase --continue
and git will continue applying the rest of the patches.
-At any point you may use the --abort option to abort this process and
+At any point you may use the `--abort` option to abort this process and
return mywork to the state it had before you started the rebase:
-------------------------------------------------
@@ -2481,7 +2481,7 @@ $ gitk origin..mywork &
and browse through the list of patches in the mywork branch using gitk,
applying them (possibly in a different order) to mywork-new using
-cherry-pick, and possibly modifying them as you go using commit --amend.
+cherry-pick, and possibly modifying them as you go using `commit --amend`.
The gitlink:git-gui[1] command may also help as it allows you to
individually select diff hunks for inclusion in the index (by
right-clicking on the diff hunk and choosing "Stage Hunk for Commit").
--
1.5.3.3.g34c6d
^ permalink raw reply related
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