* 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
* [PATCH 5/6] manual: use 'URL' instead of 'url'.
From: Ralf Wildenhues @ 2007-10-09 21:03 UTC (permalink / raw)
To: git
In-Reply-To: <20071009205755.GB31317@ins.uni-bonn.de>
Just for consistency, use the spelling URL everywhere.
---
Documentation/user-manual.txt | 8 ++++----
1 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/Documentation/user-manual.txt b/Documentation/user-manual.txt
index df482e6..38e35d8 100644
--- a/Documentation/user-manual.txt
+++ b/Documentation/user-manual.txt
@@ -1782,7 +1782,7 @@ $ git clone /path/to/repository
$ git pull /path/to/other/repository
-------------------------------------------------
-or an ssh url:
+or an ssh URL:
-------------------------------------------------
$ git clone ssh://yourhost/~you/repository
@@ -1843,7 +1843,7 @@ Exporting a git repository via the git protocol
This is the preferred method.
If someone else administers the server, they should tell you what
-directory to put the repository in, and what git:// url it will appear
+directory to put the repository in, and what git:// URL it will appear
at. You can then skip to the section
"<<pushing-changes-to-a-public-repository,Pushing changes to a public
repository>>", below.
@@ -1880,8 +1880,8 @@ $ chmod a+x hooks/post-update
gitlink:git-update-server-info[1], and the documentation
link:hooks.html[Hooks used by git].)
-Advertise the url of proj.git. Anybody else should then be able to
-clone or pull from that url, for example with a command line like:
+Advertise the URL of proj.git. Anybody else should then be able to
+clone or pull from that URL, for example with a command line like:
-------------------------------------------------
$ git clone http://yourserver.com/~you/proj.git
--
1.5.3.3.g34c6d
^ permalink raw reply related
* [PATCH 0/6] manual: Fix or remove em dashes.
From: Ralf Wildenhues @ 2007-10-09 21:05 UTC (permalink / raw)
To: git
In-Reply-To: <20071009205755.GB31317@ins.uni-bonn.de>
em dashes were used inconsistently in the manual.
This changes them to the way they are used in US English.
---
Documentation/user-manual.txt | 20 ++++++++++----------
1 files changed, 10 insertions(+), 10 deletions(-)
diff --git a/Documentation/user-manual.txt b/Documentation/user-manual.txt
index 38e35d8..d99adc6 100644
--- a/Documentation/user-manual.txt
+++ b/Documentation/user-manual.txt
@@ -2756,7 +2756,7 @@ There are four different types of objects: "blob", "tree", "commit", and
"blob" objects into a directory structure. In addition, a tree object
can refer to other tree objects, thus creating a directory hierarchy.
- A <<def_commit_object,"commit" object>> ties such directory hierarchies
- together into a <<def_DAG,directed acyclic graph>> of revisions - each
+ together into a <<def_DAG,directed acyclic graph>> of revisions--each
commit contains the object name of exactly one tree designating the
directory hierarchy at the time of the commit. In addition, a commit
refers to "parent" commit objects that describe the history of how we
@@ -3029,7 +3029,7 @@ There are also other situations that cause dangling objects. For
example, a "dangling blob" may arise because you did a "git add" of a
file, but then, before you actually committed it and made it part of the
bigger picture, you changed something else in that file and committed
-that *updated* thing - the old state that you added originally ends up
+that *updated* thing--the old state that you added originally ends up
not being pointed to by any commit or tree, so it's now a dangling blob
object.
@@ -3044,7 +3044,7 @@ up pointing to them, so they end up "dangling" in your repository.
Generally, dangling objects aren't anything to worry about. They can
even be very useful: if you screw something up, the dangling objects can
be how you recover your old tree (say, you did a rebase, and realized
-that you really didn't want to - you can look at what dangling objects
+that you really didn't want to--you can look at what dangling objects
you have, and decide to reset your head to some old dangling state).
For commits, you can just use:
@@ -3088,10 +3088,10 @@ $ git prune
------------------------------------------------
and they'll be gone. But you should only run "git prune" on a quiescent
-repository - it's kind of like doing a filesystem fsck recovery: you
+repository--it's kind of like doing a filesystem fsck recovery: you
don't want to do that while the filesystem is mounted.
-(The same is true of "git-fsck" itself, btw - but since
+(The same is true of "git-fsck" itself, btw, but since
git-fsck never actually *changes* the repository, it just reports
on what it found, git-fsck itself is never "dangerous" to run.
Running it while somebody is actually changing the repository can cause
@@ -3483,7 +3483,7 @@ You write your current index file to a "tree" object with the program
$ git write-tree
-------------------------------------------------
-that doesn't come with any options - it will just write out the
+that doesn't come with any options--it will just write out the
current index into the set of tree objects that describe that state,
and it will return the name of the resulting top-level tree. You can
use that tree to re-generate the index at any time by going in the
@@ -3494,7 +3494,7 @@ object database -> index
~~~~~~~~~~~~~~~~~~~~~~~~
You read a "tree" file from the object database, and use that to
-populate (and overwrite - don't do this if your index contains any
+populate (and overwrite--don't do this if your index contains any
unsaved state that you might want to restore later!) your current
index. Normal operation is just
@@ -3542,7 +3542,7 @@ Tying it all together
To commit a tree you have instantiated with "git-write-tree", you'd
create a "commit" object that refers to that tree and the history
-behind it - most notably the "parent" commits that preceded it in
+behind it--most notably the "parent" commits that preceded it in
history.
Normally a "commit" has one parent: the previous state of the tree
@@ -3685,7 +3685,7 @@ Once you know the three trees you are going to merge (the one "original"
tree, aka the common tree, and the two "result" trees, aka the branches
you want to merge), you do a "merge" read into the index. This will
complain if it has to throw away your old index contents, so you should
-make sure that you've committed those - in fact you would normally
+make sure that you've committed those--in fact you would normally
always do a merge against your last commit (which should thus match what
you have in your current index anyway).
@@ -3957,7 +3957,7 @@ Two things are interesting here:
- `get_sha1()` returns 0 on _success_. This might surprise some new
Git hackers, but there is a long tradition in UNIX to return different
- negative numbers in case of different errors -- and 0 on success.
+ negative numbers in case of different errors--and 0 on success.
- the variable `sha1` in the function signature of `get_sha1()` is `unsigned
char \*`, but is actually expected to be a pointer to `unsigned
--
1.5.3.3.g34c6d
^ permalink raw reply related
* Re: Proposed command: git-sync
From: Pierre Habouzit @ 2007-10-09 21:08 UTC (permalink / raw)
To: Sven Herzberg; +Cc: git
In-Reply-To: <470BD5CF.9050201@imendio.com>
[-- Attachment #1: Type: text/plain, Size: 477 bytes --]
On Tue, Oct 09, 2007 at 07:26:07PM +0000, 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.
this is the default behavior of git push in recent gits.
--
·O· Pierre Habouzit
··O madcoder@debian.org
OOO http://www.madism.org
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: Status of kha/experimental
From: Catalin Marinas @ 2007-10-09 21:10 UTC (permalink / raw)
To: Karl Hasselström; +Cc: Yann Dirson, David Kågedal, Git Mailing List
In-Reply-To: <20071007213307.GA32210@diana.vm.bytemark.co.uk>
On 07/10/2007, Karl Hasselström <kha@treskal.com> wrote:
> On 2007-10-07 22:18:44 +0100, Catalin Marinas wrote:
>
> > How stable is the kha/experimental branch? Since there are more and
> > more bugs added to the tracking system, I'll have to start looking
> > at them before a 0.14 release. Is it worth merging the
> > kha/experimental now or we better wait for after 0.14?
>
> The idea is that experimental contains changes that need testing, but
> may not yet be ready for your master. (They are generally safe,
> though; I run StGit from my experimental branch at work, for example.)
> When I decide that they are ready, I move them to safe. If there are
> any patches you feel should be in safe rather than experimental, just
> ask. Or you could just take them directly from experimental without
> asking, of course. :-)
OK. My plan is to merge kha/safe and have a look at what seems safer
to merge from kha/experimental. Fix bugs (and freeze the current
features). Release 0.14. Merge kha/experimental entirely post 0.14 and
test/stabilize it over couple of months. How does this sound?
--
Catalin
^ permalink raw reply
* [PATCH 3/6] manual: Fix example finding commits referencing given content.
From: Ralf Wildenhues @ 2007-10-09 21:02 UTC (permalink / raw)
To: git
In-Reply-To: <20071009205755.GB31317@ins.uni-bonn.de>
If I'm handed a file, then it typically lives outside the
working directory. git-log only operates on in-tree files,
so the first 'filename' should be an in-tree one, or it should
look at all files. This patch does the latter, so it would
also find renamed files. However, it is also slower.
---
Documentation/user-manual.txt | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/Documentation/user-manual.txt b/Documentation/user-manual.txt
index 6adeca7..2b1b324 100644
--- a/Documentation/user-manual.txt
+++ b/Documentation/user-manual.txt
@@ -926,7 +926,7 @@ file such that it contained the given content either before or after the
commit. You can find out with this:
-------------------------------------------------
-$ git log --raw --abbrev=40 --pretty=oneline -- filename |
+$ git log --raw --abbrev=40 --pretty=oneline |
grep -B 1 `git hash-object filename`
-------------------------------------------------
--
1.5.3.3.g34c6d
^ permalink raw reply related
* [PATCH 2/6] Fix wording in push definition.
From: Ralf Wildenhues @ 2007-10-09 21:01 UTC (permalink / raw)
To: git
In-Reply-To: <20071009205755.GB31317@ins.uni-bonn.de>
Make the definition of push in the glossary readable.
---
Documentation/glossary.txt | 4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/Documentation/glossary.txt b/Documentation/glossary.txt
index d99fa19..5645177 100644
--- a/Documentation/glossary.txt
+++ b/Documentation/glossary.txt
@@ -301,8 +301,8 @@ This commit is referred to as a "merge commit", or sometimes just a
[[def_push]]push::
Pushing a <<def_branch,branch>> means to get the branch's
<<def_head_ref,head ref>> from a remote <<def_repository,repository>>,
- find out if it is an ancestor to the branch's local
- head ref is a direct, and in that case, putting all
+ find out if it is a direct ancestor to the branch's local
+ head ref, and in that case, putting all
objects, which are <<def_reachable,reachable>> from the local
head ref, and which are missing from the remote
repository, into the remote
--
1.5.3.3.g34c6d
^ permalink raw reply related
* [PATCH 0/6] Some small documentation fixes
From: Ralf Wildenhues @ 2007-10-09 20:57 UTC (permalink / raw)
To: git
Hello git list,
Being rather new to git, I've read the manual, and found some
minor issues. Posting them in the hope that they are useful,
and that you don't mind me splitting them up in small pieces.
Please Cc: me on replies.
Cheers,
Ralf, thanks for a cool tool :-)
^ permalink raw reply
* [PATCH 1/6] Fix some typos, punctuation, missing words, minor markup.
From: Ralf Wildenhues @ 2007-10-09 21:00 UTC (permalink / raw)
To: git
In-Reply-To: <20071009205755.GB31317@ins.uni-bonn.de>
---
Documentation/config.txt | 4 ++--
Documentation/git-diff.txt | 2 +-
Documentation/git-index-pack.txt | 2 +-
Documentation/git-merge-index.txt | 2 +-
Documentation/git-stash.txt | 2 +-
Documentation/git-svn.txt | 2 +-
Documentation/git-tag.txt | 2 +-
Documentation/git.txt | 4 ++--
Documentation/glossary.txt | 6 +++---
Documentation/user-manual.txt | 27 ++++++++++++++-------------
10 files changed, 27 insertions(+), 26 deletions(-)
diff --git a/Documentation/config.txt b/Documentation/config.txt
index 015910f..6afc1dc 100644
--- a/Documentation/config.txt
+++ b/Documentation/config.txt
@@ -188,7 +188,7 @@ core.worktree::
Set the path to the working tree. The value will not be
used in combination with repositories found automatically in
a .git directory (i.e. $GIT_DIR is not set).
- This can be overriden by the GIT_WORK_TREE environment
+ This can be overridden by the GIT_WORK_TREE environment
variable and the '--work-tree' command line option.
core.logAllRefUpdates::
@@ -588,7 +588,7 @@ merge.verbosity::
message if conflicts were detected. Level 1 outputs only
conflicts, 2 outputs conflicts and file changes. Level 5 and
above outputs debugging information. The default is level 2.
- Can be overriden by 'GIT_MERGE_VERBOSITY' environment variable.
+ Can be overridden by 'GIT_MERGE_VERBOSITY' environment variable.
merge.<driver>.name::
Defines a human readable name for a custom low-level
diff --git a/Documentation/git-diff.txt b/Documentation/git-diff.txt
index db2eb46..ce0f502 100644
--- a/Documentation/git-diff.txt
+++ b/Documentation/git-diff.txt
@@ -125,7 +125,7 @@ $ git diff topic...master <3>
+
<1> Changes between the tips of the topic and the master branches.
<2> Same as above.
-<3> Changes that occured on the master branch since when the topic
+<3> Changes that occurred on the master branch since when the topic
branch was started off it.
Limiting the diff output::
diff --git a/Documentation/git-index-pack.txt b/Documentation/git-index-pack.txt
index a8a7f6f..bf5c2bd 100644
--- a/Documentation/git-index-pack.txt
+++ b/Documentation/git-index-pack.txt
@@ -43,7 +43,7 @@ OPTIONS
a default name determined from the pack content. If
<pack-file> is not specified consider using --keep to
prevent a race condition between this process and
- gitlink::git-repack[1] .
+ gitlink::git-repack[1].
--fix-thin::
It is possible for gitlink:git-pack-objects[1] to build
diff --git a/Documentation/git-merge-index.txt b/Documentation/git-merge-index.txt
index 17e9f10..b726ddf 100644
--- a/Documentation/git-merge-index.txt
+++ b/Documentation/git-merge-index.txt
@@ -40,7 +40,7 @@ If "git-merge-index" is called with multiple <file>s (or -a) then it
processes them in turn only stopping if merge returns a non-zero exit
code.
-Typically this is run with the a script calling git's imitation of
+Typically this is run with a script calling git's imitation of
the merge command from the RCS package.
A sample script called "git-merge-one-file" is included in the
diff --git a/Documentation/git-stash.txt b/Documentation/git-stash.txt
index 5723bb0..c0147b9 100644
--- a/Documentation/git-stash.txt
+++ b/Documentation/git-stash.txt
@@ -57,7 +57,7 @@ stash@{1}: On master: 9cc0589... Add git-stash
show [<stash>]::
- Show the changes recorded in the stash as a diff between the the
+ Show the changes recorded in the stash as a diff between the
stashed state and its original parent. When no `<stash>` is given,
shows the latest one. By default, the command shows the diffstat, but
it will accept any format known to `git-diff` (e.g., `git-stash show
diff --git a/Documentation/git-svn.txt b/Documentation/git-svn.txt
index e157c6a..488e4b1 100644
--- a/Documentation/git-svn.txt
+++ b/Documentation/git-svn.txt
@@ -404,7 +404,7 @@ section because they affect the 'git-svn-id:' metadata line.
BASIC EXAMPLES
--------------
-Tracking and contributing to a the trunk of a Subversion-managed project:
+Tracking and contributing to the trunk of a Subversion-managed project:
------------------------------------------------------------------------
# Clone a repo (like git clone):
diff --git a/Documentation/git-tag.txt b/Documentation/git-tag.txt
index 990ae4f..22a23bf 100644
--- a/Documentation/git-tag.txt
+++ b/Documentation/git-tag.txt
@@ -112,7 +112,7 @@ You really want to call the new version "X" too, 'even though'
others have already seen the old one. So just use "git tag -f"
again, as if you hadn't already published the old one.
-However, Git does *not* (and it should not)change tags behind
+However, Git does *not* (and it should not) change tags behind
users back. So if somebody already got the old tag, doing a "git
pull" on your tree shouldn't just make them overwrite the old
one.
diff --git a/Documentation/git.txt b/Documentation/git.txt
index abce801..bba8d54 100644
--- a/Documentation/git.txt
+++ b/Documentation/git.txt
@@ -325,7 +325,7 @@ For a more complete list of ways to spell object names, see
File/Directory Structure
------------------------
-Please see link:repository-layout.html[repository layout] document.
+Please see the link:repository-layout.html[repository layout] document.
Read link:hooks.html[hooks] for more details about each hook.
@@ -335,7 +335,7 @@ Higher level SCMs may provide and manage additional information in the
Terminology
-----------
-Please see link:glossary.html[glossary] document.
+Please see the link:glossary.html[glossary] document.
Environment Variables
diff --git a/Documentation/glossary.txt b/Documentation/glossary.txt
index 3f7b1e4..d99fa19 100644
--- a/Documentation/glossary.txt
+++ b/Documentation/glossary.txt
@@ -52,8 +52,8 @@ GIT Glossary
[[def_cherry-picking]]cherry-picking::
In <<def_SCM,SCM>> jargon, "cherry pick" means to choose a subset of
changes out of a series of changes (typically commits) and record them
- as a new series of changes on top of different codebase. In GIT, this is
- performed by "git cherry-pick" command to extract the change introduced
+ as a new series of changes on top of a different codebase. In GIT, this is
+ performed by the "git cherry-pick" command to extract the change introduced
by an existing <<def_commit,commit>> and to record it based on the tip
of the current <<def_branch,branch>> as a new commit.
@@ -347,7 +347,7 @@ This commit is referred to as a "merge commit", or sometimes just a
it as my origin branch head". And `git push
$URL refs/heads/master:refs/heads/to-upstream` means "publish my
master branch head as to-upstream branch at $URL". See also
- gitlink:git-push[1]
+ gitlink:git-push[1].
[[def_repository]]repository::
A collection of <<def_ref,refs>> together with an
diff --git a/Documentation/user-manual.txt b/Documentation/user-manual.txt
index c7fdf25..6adeca7 100644
--- a/Documentation/user-manual.txt
+++ b/Documentation/user-manual.txt
@@ -1495,7 +1495,7 @@ Ensuring good performance
-------------------------
On large repositories, git depends on compression to keep the history
-information from taking up to much space on disk or in memory.
+information from taking up too much space on disk or in memory.
This compression is not performed automatically. Therefore you
should occasionally run gitlink:git-gc[1]:
@@ -1920,7 +1920,7 @@ As with git-fetch, git-push will complain if this does not result in
a <<fast-forwards,fast forward>>. Normally this is a sign of
something wrong. However, if you are sure you know what you're
doing, you may force git-push to perform the update anyway by
-proceeding the branch name by a plus sign:
+preceding the branch name by a plus sign:
-------------------------------------------------
$ git push ssh://yourserver.com/~you/proj.git +master
@@ -2040,7 +2040,7 @@ $ git branch --track test origin/master
$ git branch --track release origin/master
-------------------------------------------------
-These can be easily kept up to date using gitlink:git-pull[1]
+These can be easily kept up to date using gitlink:git-pull[1].
-------------------------------------------------
$ git checkout test && git pull
@@ -2132,7 +2132,7 @@ changes are in a specific branch, use:
$ git log linux..branchname | git-shortlog
-------------------------------------------------
-To see whether it has already been merged into the test or release branches
+To see whether it has already been merged into the test or release branches,
use:
-------------------------------------------------
@@ -2145,12 +2145,12 @@ or
$ git log release..branchname
-------------------------------------------------
-(If this branch has not yet been merged you will see some log entries.
+(If this branch has not yet been merged, you will see some log entries.
If it has been merged, then there will be no output.)
Once a patch completes the great cycle (moving from test to release,
then pulled by Linus, and finally coming back into your local
-"origin/master" branch) the branch for this change is no longer needed.
+"origin/master" branch), the branch for this change is no longer needed.
You detect this when the output from:
-------------------------------------------------
@@ -2479,7 +2479,7 @@ $ git checkout -b mywork-new origin
$ gitk origin..mywork &
-------------------------------------------------
-And browse through the list of patches in the mywork branch using gitk,
+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.
The gitlink:git-gui[1] command may also help as it allows you to
@@ -2739,7 +2739,7 @@ others:
- Git can quickly determine whether two objects are identical or not,
just by comparing names.
-- Since object names are computed the same way in ever repository, the
+- Since object names are computed the same way in every repository, the
same content stored in two repositories will always be stored under
the same name.
- Git can detect errors when it reads an object, by checking that the
@@ -3425,9 +3425,10 @@ The Workflow
------------
High-level operations such as gitlink:git-commit[1],
-gitlink:git-checkout[1] and git-reset[1] work by moving data between the
-working tree, the index, and the object database. Git provides
-low-level operations which perform each of these steps individually.
+gitlink:git-checkout[1] and gitlink:git-reset[1] work by moving data
+between the working tree, the index, and the object database. Git
+provides low-level operations which perform each of these steps
+individually.
Generally, all "git" operations work on the index file. Some operations
work *purely* on the index file (showing the current state of the
@@ -3704,7 +3705,7 @@ Merging multiple trees, continued
---------------------------------
Sadly, many merges aren't trivial. If there are files that have
-been added.moved or removed, or if both branches have modified the
+been added, moved or removed, or if both branches have modified the
same file, you will be left with an index tree that contains "merge
entries" in it. Such an index tree can 'NOT' be written out to a tree
object, and you will have to resolve any such merge clashes using
@@ -4061,7 +4062,7 @@ $ git branch new # create branch "new" starting at current HEAD
$ git branch -d new # delete branch "new"
-----------------------------------------------
-Instead of basing new branch on current HEAD (the default), use:
+Instead of basing a new branch on current HEAD (the default), use:
-----------------------------------------------
$ git branch new test # branch named "test"
--
1.5.3.3.g34c6d
^ permalink raw reply related
* [PATCH] exec_git_cmd: fix executing commands if path contains spaces
From: Steffen Prohaska @ 2007-10-09 21:39 UTC (permalink / raw)
To: j.sixt; +Cc: Johannes.Schindelin, git, Steffen Prohaska
In-Reply-To: <470BB44B.3030500@viscovery.net>
This patch fixed executing of non-builtins if installation
dir contains spaces. That is 'git var' works now.
The original patch is by Johannes Sixt <j.sixt@viscovery.net>.
Signed-off-by: Steffen Prohaska <prohaska@zib.de>
---
compat/mingw.c | 2 +-
exec_cmd.c | 2 +-
git-compat-util.h | 1 +
3 files changed, 3 insertions(+), 2 deletions(-)
Ok, this is what I created from the quick-fix. It works for
me in msysgit.
Should the patch be polished that it can be applied to git.git
or will we only apply it to 4msysgit?
If it should be polished, what would be the right way?
ifdef in exec_cmd.c?
Steffen
diff --git a/compat/mingw.c b/compat/mingw.c
index 6632192..0dd0cb0 100644
--- a/compat/mingw.c
+++ b/compat/mingw.c
@@ -196,7 +196,7 @@ void openlog(const char *ident, int option, int facility)
{
}
-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 2a8e48b..4c7c7ca 100644
--- a/exec_cmd.c
+++ b/exec_cmd.c
@@ -132,7 +132,7 @@ int execv_git_cmd(const char **argv)
*/
tmp = argv[0];
- argv[0] = git_command;
+ argv[0] = quote_arg(git_command);
trace_argv_printf(argv, -1, "trace: exec:");
diff --git a/git-compat-util.h b/git-compat-util.h
index ba5a1a1..5276221 100644
--- a/git-compat-util.h
+++ b/git-compat-util.h
@@ -482,6 +482,7 @@ int mingw_socket(int domain, int type, int protocol);
#define fsync(x) 0
extern void quote_argv(const char **dst, const char **src);
+extern const char *quote_arg(const char *arg);
extern const char *parse_interpreter(const char *cmd);
extern __attribute__((noreturn)) int git_exit(int code);
--
1.5.3.mingw.1.13.g70ed-dirty
^ permalink raw reply related
* Re: [PATCH 0/6] manual: Fix or remove em dashes.
From: Thomas Adam @ 2007-10-09 21:41 UTC (permalink / raw)
To: Ralf Wildenhues, git
In-Reply-To: <20071009210530.GH31317@ins.uni-bonn.de>
Hello --
On 09/10/2007, Ralf Wildenhues <Ralf.Wildenhues@gmx.de> wrote:
> em dashes were used inconsistently in the manual.
> This changes them to the way they are used in US English.
I find this particular patch to be rather odd; there is nothing
invalid in the way the em-dashes are used. Why is it US English is
somehow de facto over, say, proper English? :)
-- Thomas Adam
^ permalink raw reply
* Re: Status of kha/experimental
From: Yann Dirson @ 2007-10-09 21:46 UTC (permalink / raw)
To: Catalin Marinas
Cc: Karl Hasselström, David Kågedal, Git Mailing List
In-Reply-To: <b0943d9e0710091410w1559f1a0yb5055182fd289646@mail.gmail.com>
On Tue, Oct 09, 2007 at 10:10:12PM +0100, Catalin Marinas wrote:
> On 07/10/2007, Karl Hasselström <kha@treskal.com> wrote:
> > On 2007-10-07 22:18:44 +0100, Catalin Marinas wrote:
> >
> > > How stable is the kha/experimental branch? Since there are more and
> > > more bugs added to the tracking system, I'll have to start looking
> > > at them before a 0.14 release. Is it worth merging the
> > > kha/experimental now or we better wait for after 0.14?
> >
> > The idea is that experimental contains changes that need testing, but
> > may not yet be ready for your master. (They are generally safe,
> > though; I run StGit from my experimental branch at work, for example.)
> > When I decide that they are ready, I move them to safe. If there are
> > any patches you feel should be in safe rather than experimental, just
> > ask. Or you could just take them directly from experimental without
> > asking, of course. :-)
>
> OK. My plan is to merge kha/safe and have a look at what seems safer
> to merge from kha/experimental. Fix bugs (and freeze the current
> features). Release 0.14. Merge kha/experimental entirely post 0.14 and
> test/stabilize it over couple of months. How does this sound?
Sounds like a good time to bring back my refactoring patches from the
hydra patchset. I have not addressed yet the remarks that were voiced
at that time, and the hydra patch itself has not been completed, and
in fact the refactorings touch so many parts of the code that I can't
envision mantaining them outside the tree (in fact, I left them bitrot
for that very reason). If there is no other remarks than those
already posted as replies to the patchset, maybe we could consider
merging them soon after kha/experimental ?
That would require that I update them, but I'm not sure Karl would
want them in kha/experimental, since virtually any other patch causes
a conflict... The best situation would be that there would be a code
freeze at some time, during which I could update those patches without
too much perturbations, but that may be asking a lot :)
The ideal situation would be if we would make diffcore and merge aware
of a (de)indentation type of change. That's something I have felt the
need for since ages, but I'm unfortunately not going to find the time
to implement that anytime soon :)
Best regards,
--
Yann
^ permalink raw reply
* Re: [PATCH 0/6] manual: Fix or remove em dashes.
From: Ralf Wildenhues @ 2007-10-09 21:52 UTC (permalink / raw)
To: Thomas Adam; +Cc: git
In-Reply-To: <18071eea0710091441n717c0a99p58a9b585d15cc778@mail.gmail.com>
Hello, and sorry, this patch should be number 6/6 of course.
* Thomas Adam wrote on Tue, Oct 09, 2007 at 11:41:41PM CEST:
> On 09/10/2007, Ralf Wildenhues <Ralf.Wildenhues@gmx.de> wrote:
> > em dashes were used inconsistently in the manual.
> > This changes them to the way they are used in US English.
>
> I find this particular patch to be rather odd; there is nothing
> invalid in the way the em-dashes are used.
No, not invalid, just inconsistent usage in the manual.
> Why is it US English is somehow de facto over, say, proper English?
> :)
Oh, that was written quoting from memory and experience. But here's a
quote to back it up, from <http://en.wikipedia.org/wiki/Dash> as of now:
| According to most American sources (e.g., The Chicago Manual of Style)
| and to some British sources (e.g., The Oxford Guide to Style), an em
| dash should always be set closed (not surrounded by spaces). But the
| practice in many parts of the English-speaking world[...] sets it
| open [...]
No, I did not write that! ;-)
Cheers,
Ralf
^ permalink raw reply
* Re: [PATCH 0/6] manual: Fix or remove em dashes.
From: Thomas Adam @ 2007-10-09 22:02 UTC (permalink / raw)
To: Ralf Wildenhues; +Cc: git
In-Reply-To: <20071009215255.GB3146@ins.uni-bonn.de>
On 09/10/2007, Ralf Wildenhues <Ralf.Wildenhues@gmx.de> wrote:
> Hello, and sorry, this patch should be number 6/6 of course.
>
> * Thomas Adam wrote on Tue, Oct 09, 2007 at 11:41:41PM CEST:
> > On 09/10/2007, Ralf Wildenhues <Ralf.Wildenhues@gmx.de> wrote:
> > > em dashes were used inconsistently in the manual.
> > > This changes them to the way they are used in US English.
> >
> > I find this particular patch to be rather odd; there is nothing
> > invalid in the way the em-dashes are used.
>
> No, not invalid, just inconsistent usage in the manual.
>
> > Why is it US English is somehow de facto over, say, proper English?
> > :)
>
> Oh, that was written quoting from memory and experience. But here's a
> quote to back it up, from <http://en.wikipedia.org/wiki/Dash> as of now:
>
> | According to most American sources (e.g., The Chicago Manual of Style)
> | and to some British sources (e.g., The Oxford Guide to Style), an em
> | dash should always be set closed (not surrounded by spaces). But the
> | practice in many parts of the English-speaking world[...] sets it
> | open [...]
>
> No, I did not write that! ;-)
Well, I don't see why it needs to change, to be honest. I use
em-dashes all the time surrounded by spaces, as do many academics.
The fact that may here in the UK do not use the letter z in place of s
to satisfy the OSD is also of equal testament to this.
-- Thomas Adam
^ 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