* Re: [PATCH 3/4] Documentation: mention branches rather than heads
From: Junio C Hamano @ 2009-01-19 3:46 UTC (permalink / raw)
To: Anders Melchiorsen; +Cc: git
In-Reply-To: <1232289418-25627-4-git-send-email-mail@cup.kalibalik.dk>
Anders Melchiorsen <mail@cup.kalibalik.dk> writes:
> Most of the git push page talks about branches, so make it consistent
> also in this paragraph.
> Signed-off-by: Anders Melchiorsen <mail@cup.kalibalik.dk>
> ---
> Documentation/git-push.txt | 4 ++--
> 1 files changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/Documentation/git-push.txt b/Documentation/git-push.txt
> index 6d3c711..a7a6f4c 100644
> --- a/Documentation/git-push.txt
> +++ b/Documentation/git-push.txt
> @@ -57,8 +57,8 @@ Pushing an empty <src> allows you to delete the <dst> ref from
> the remote repository.
> +
> The special refspec `:` (or `+:` to allow non-fast forward updates)
> -directs git to push "matching" heads: for every head that exists on
> -the local side, the remote side is updated if a head of the same name
> +directs git to push "matching" branches: for every branch that exists on
> +the local side, the remote side is updated if a branch of the same name
> already exists on the remote side. This is the default operation mode
> if no explicit refspec is found (that is neither on the command line
> nor in any Push line of the corresponding remotes file---see below).
Consistency is good, and I agree "head" may be suboptimal here as this
part tries to give formal semantics to what various refspecs do.
I first thought it would make more sense to say "ref" instead, just like
the previous paragraph that talks about :<dst> form explains it is a way
to remove a "ref". But we do only matching branches with : syntax these
days since 098e711 ("git-push $URL" without refspecs pushes only matching
branches, 2007-07-01); I agree with the updated text for that reason, but
I think the commit log message is wrong.
Thanks.
^ permalink raw reply
* Re: [PATCH v2] git-svn: Add --localtime option to "fetch"
From: Junio C Hamano @ 2009-01-19 3:46 UTC (permalink / raw)
To: Eric Wong; +Cc: Pete Harlan, Git mailing list
In-Reply-To: <20090119004318.GA5128@untitled>
Thanks, both.
^ permalink raw reply
* Re: [PATCH/RFC v1 1/1] bug fix, diff whitespace ignore options
From: Johannes Schindelin @ 2009-01-19 3:53 UTC (permalink / raw)
To: Keith Cascio; +Cc: git, Junio C Hamano
In-Reply-To: <alpine.GSO.2.00.0901181754190.9333@kiwi.cs.ucla.edu>
Hi,
On Sun, 18 Jan 2009, Keith Cascio wrote:
> Fixed bug in diff whitespace ignore options.
> It is now OK to specify more than one whitespace ignore option
> on the command line. In unit test 4015, expect success rather
> than failure for 4 cases.
> Note: I do not fully understand why this fix works, but it passes
> all 68 t4???-* diff test scripts.
>
> The semantics of the three whitespace ignore flags
> { -w, -b, --ignore-space-at-eol }
> obey a relation of transitive implication, i.e. the stronger
> options imply the weaker options:
> -w implies the other two
> -b implies --ignore-space-at-eol
> --ignore-space-at-eol implies only itself
>
> Therefore it is never necessary to specify more than one of these
> on the command line. Yet we imagine scenarios where software
> wrappers (e.g. GUIs, etc) generate command lines that switch on
> more than one of these flags simultaneously. It is unreasonable
> to prohibit specifying more than one, since a new user might not
> immediately discern the implication relation. Now we call such
> a command line valid and legal.
>
> Signed-off-by: Keith Cascio <keith@cs.ucla.edu>
> ---
This does not really look all that similar to other commit messages.
For example, "Note: I do not fully understand why this fix works, but it
passes all 68 t4???-* diff test scripts." is rather discouraging. If you
are not convinced, how should we be?
However, I almost can excuse that, but...
> t/t4015-diff-whitespace.sh | 8 ++++----
> xdiff/xutils.c | 22 ++++++++++++----------
> 2 files changed, 16 insertions(+), 14 deletions(-)
>
> diff --git a/xdiff/xutils.c b/xdiff/xutils.c
> index d7974d1..b9bda86 100644
> --- a/xdiff/xutils.c
> +++ b/xdiff/xutils.c
> @@ -245,17 +245,19 @@ static unsigned long
> xdl_hash_record_with_whitespace(char const **data,
> while (ptr + 1 < top && isspace(ptr[1])
> && ptr[1] != '\n')
> ptr++;
> - if (flags & XDF_IGNORE_WHITESPACE_CHANGE
> - && ptr[1] != '\n') {
> - ha += (ha << 5);
> - ha ^= (unsigned long) ' ';
> - }
> - if (flags & XDF_IGNORE_WHITESPACE_AT_EOL
> - && ptr[1] != '\n') {
> - while (ptr2 != ptr + 1) {
> + if( ! ( flags & XDF_IGNORE_WHITESPACE
... this is just plain ugly, not to mention breaking the coding style of
the surrounding code in a rather blatant way.
> )){
> + if( flags & XDF_IGNORE_WHITESPACE_CHANGE
> + && ptr[1] != '\n') {
> ha += (ha << 5);
> - ha ^= (unsigned long) *ptr2;
> - ptr2++;
> + ha ^= (unsigned long) ' ';
> + }
> + else if( flags & XDF_IGNORE_WHITESPACE_AT_EOL
> + && ptr[1] != '\n') {
> + while (ptr2 != ptr + 1) {
> + ha += (ha << 5);
> + ha ^= (unsigned long) *ptr2;
> + ptr2++;
> + }
Besides, I think what you actually wanted is
if (flags & XDF_IGNORE_WHITESPACE)
; /* already handled */
else if (flags & XDF_IGNORE_WHITESPACE_CHANGE)
...
else if (flags & XDF_IGNORE_WHITESPACE_AT_EOL)
...
for improved readability both of the code and the patch.
Ciao,
Dscho
^ permalink raw reply
* [HELP] A local branch has disappeared
From: Johnny Lee @ 2009-01-19 3:54 UTC (permalink / raw)
To: git
Hi all,
Today I found my current branch (named cupcake) has disappeared.
git@tomato:~/golf$ git branch -a
htc_cupcake
tmo_cupcake
origin/HEAD
origin/cupcake
origin/device
As you can see, there is no "*" to mark the current branch.
But when I check the HEAD, it still pointed to the cupcake branch
git@tomato:~/golf$ cat .git/HEAD
ref: refs/heads/cupcake
But when I check the ref/heads, the cupcake is missing
git@tomato:~/golf$ ls .git/refs/heads/
htc_cupcake tmo_cupcake
And the cupcake in still in the config:
git@tomato:~/golf$ cat .git/config
[core]
repositoryformatversion = 0
filemode = true
bare = false
logallrefupdates = true
sharedRepository = 1
[remote "origin"]
url = /home/rick/golfresort/device/.git
fetch = +refs/heads/*:refs/remotes/origin/*
[branch "cupcake"]
remote = origin
merge = refs/heads/cupcake
I'm confused:
1. I didn't do any aggressive operations. Why the branch has
disappeared? Normally I have done these operation for this repo:
i. pull from parent repo
ii. cloned by children repo
iii. pulled by children repo
iv. pushed from children repo
2. Is there any way to resume the cupcake branch? Can I manually add
the cupcake to ref/heads?
Thanks very much for your considerations,
Johnny
--
we all have our crosses to bear
^ permalink raw reply
* git-svn updates
From: Eric Wong @ 2009-01-19 4:06 UTC (permalink / raw)
To: git
Hi all,
I've acked a few patches and pushed out several fixes of my own to
git://git.bogomips.org/git-svn.git
They should be reasonably safe to run, but I haven't been doing much
hacking in recent months so I may be a bit rusty. Extra eyes and
testing would be very much appreciated.
Eric Wong (4):
git-svn: handle empty files marked as symlinks in SVN
git-svn: better attempt to handle broken symlink updates
git-svn: fix SVN 1.1.x compatibility
git-svn: avoid importing nested git repos
Marcel Koeppen (1):
git-svn: Show UUID in svn info for added directories with svn 1.5.5
Pete Harlan (1):
git-svn: Add --localtime option to "fetch"
I'll try to get to splitting out the monster git-svn.perl file by next
weekend.
I also got a private bug report about EDITOR/VISUAL usage with `git svn
dcommit -e' when there was a space in the command. Perhaps introducing
a Git::Editor Perl module that emulates editor.c would be a start?
--
Eric Wong
^ permalink raw reply
* Re: git-patches list?
From: Johannes Schindelin @ 2009-01-19 4:29 UTC (permalink / raw)
To: Andreas Ericsson; +Cc: Junio C Hamano, Akira Kitada, git
In-Reply-To: <alpine.DEB.1.00.0901131158500.3586@pacific.mpi-cbg.de>
Hi,
On Tue, 13 Jan 2009, Johannes Schindelin wrote:
> http://gitrss.q42.co.uk/
>
> I am sure that Julian can be convinced to filter "[PATCH", too.
And he was nice enough to add a few more filters.
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH v2] contrib: add 'git-difftool' for launching common diff tools
From: Markus Heidelberg @ 2009-01-19 4:45 UTC (permalink / raw)
To: David Aguilar; +Cc: git, gitster
In-Reply-To: <1232324753-16137-1-git-send-email-davvid@gmail.com>
David Aguilar, 19.01.2009:
> 'git-difftool' is a git command that allows you to compare and edit files
> between revisions using common merge tools. 'git-difftool' does what
> 'git-mergetool' does but its use is for non-merge situations such as
> when preparing commits or comparing changes against the index.
> It uses the same configuration variables as 'git-mergetool' and
> provides the same command-line interface as 'git-diff'.
>
> Signed-off-by: David Aguilar <davvid@gmail.com>
> ---
>
> This newer version addresses the feedback from Markus Heidelberg.
> difftool is now more consistent with mergetool and it includes
> Markus's vimdiff enhancements for positioning the cursor at startup.
Your patch is already in master, you should send a patch against it.
Markus
^ permalink raw reply
* Re: [PATCH] contrib: add 'git difftool' for launching common merge tools
From: Markus Heidelberg @ 2009-01-19 5:03 UTC (permalink / raw)
To: David Aguilar; +Cc: Git mailing list
In-Reply-To: <402731c90901181634u32b39c87t6e88d9efef0d3485@mail.gmail.com>
David Aguilar, 19.01.2009:
> On Sun, Jan 18, 2009 at 11:25 AM, Markus Heidelberg
> <markus.heidelberg@web.de> wrote:
> > David Aguilar, 16.01.2009:
> >> + meld|vimdiff)
> >> + "$merge_tool_path" "$LOCAL" "$REMOTE"
> >> + ;;
> >> +
> >> + gvimdiff)
> >> + "$merge_tool_path" -f "$LOCAL" "$REMOTE"
> >> + ;;
> >
> > Maybe use '-c "wincmd l"' for Vim as in my patch for git-mergetool to
> > automatically place the cursor in the editable file? Useful for editing,
> > if git-difftool is used to diff a file from the working tree.
> >
> > See http://thread.gmane.org/gmane.comp.version-control.git/106109
>
>
> Very cool. When you have unstaged changes git diff sends the local
> filename as the 2nd argument so I changed the vim command to "wincmd
> r" so that vim places the cursor on the right hand side.
Well, in "wincmd l" "l" doesn't mean "left", it doesn't mean "put the
cursor into the left window", it just moves the cursor into the next
right window. So "wincmd r" doesn't mean "put the cursor into the right
window", but "rotate the window" (see :help ctrl-w_r).
So with "wincmd r" the local file would be moved to the left side and
the index file to the right side, still containing the cursor. Not what
we want.
With "wincmd l" the local file would stay on the right side, the index
file on the left side, but the cursor would move from the left to the
right side. Now we can edit the local file.
> > You have deleted all the '-' chars from git-command, but when using it as the
> > name I think it's the preferred method, only when used as command then without
> > slash.
>
> I was wondering about that. I think I tried to follow the lead from
> the git-diff.txt documentation, but "diff" is a builtin and thus
> doesn't have an actual git-diff, so I see why they should be
> different.
Hmm, I don't think it makes a difference, whether it's a builtin or not.
git-diff only exists behind the scenes, invoking it as "git-diff"
doesn't work anymore with default settings. On the other hand, I can
also invoke "git difftool" without the slash, git can find it. The same
way I can for example call "git svn", which also isn't a builtin.
Markus
^ permalink raw reply
* [PATCH 1/2] difftool: fix documentation problems
From: David Aguilar @ 2009-01-19 5:27 UTC (permalink / raw)
To: git; +Cc: gitster, David Aguilar
This patch makes the difftool docs always refer to the
git-difftool script using the dashed form of the name.
Only command examples use the non-dashed form now.
Signed-off-by: David Aguilar <davvid@gmail.com>
---
contrib/difftool/git-difftool | 5 ++---
contrib/difftool/git-difftool.txt | 20 ++++++++++----------
2 files changed, 12 insertions(+), 13 deletions(-)
diff --git a/contrib/difftool/git-difftool b/contrib/difftool/git-difftool
index 1fc087c..0cda3d2 100755
--- a/contrib/difftool/git-difftool
+++ b/contrib/difftool/git-difftool
@@ -4,7 +4,7 @@
# This is a wrapper around the GIT_EXTERNAL_DIFF-compatible
# git-difftool-helper script. This script exports
# GIT_EXTERNAL_DIFF and GIT_PAGER for use by git, and
-# GIT_NO_PROMPT and GIT_MERGE_TOOL for use by git-difftool-helper.
+# GIT_DIFFTOOL_NO_PROMPT and GIT_MERGE_TOOL for use by git-difftool-helper.
# Any arguments that are unknown to this script are forwarded to 'git diff'.
use strict;
@@ -18,8 +18,7 @@ my $DIR = abs_path(dirname($0));
sub usage
{
print << 'USAGE';
-
-usage: git difftool [--no-prompt] [--tool=tool] ["git diff" options]
+usage: git difftool [--tool=<tool>] [--no-prompt] ["git diff" options]
USAGE
exit 1;
}
diff --git a/contrib/difftool/git-difftool.txt b/contrib/difftool/git-difftool.txt
index 3940c70..ca3dbd2 100644
--- a/contrib/difftool/git-difftool.txt
+++ b/contrib/difftool/git-difftool.txt
@@ -11,16 +11,16 @@ SYNOPSIS
DESCRIPTION
-----------
-'git difftool' is a git command that allows you to compare and edit files
+'git-difftool' is a git command that allows you to compare and edit files
between revisions using common merge tools. At its most basic level,
-'git difftool' does what 'git mergetool' does but its use is for non-merge
+'git-difftool' does what 'git-mergetool' does but its use is for non-merge
situations such as when preparing commits or comparing changes against
the index.
'git difftool' is a frontend to 'git diff' and accepts the same
arguments and options.
-See linkgit:git-diff[7] for the full list of supported options.
+See linkgit:git-diff[1] for the full list of supported options.
OPTIONS
-------
@@ -30,7 +30,7 @@ OPTIONS
Valid merge tools are:
kdiff3, tkdiff, meld, xxdiff, emerge, vimdiff, gvimdiff, ecmerge, and opendiff
+
-If a merge resolution program is not specified, 'git difftool'
+If a merge resolution program is not specified, 'git-difftool'
will use the configuration variable `merge.tool`. If the
configuration variable `merge.tool` is not set, 'git difftool'
will pick a suitable default.
@@ -38,15 +38,15 @@ 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`. Otherwise, 'git difftool' assumes the
+`mergetool.kdiff3.path`. Otherwise, 'git-difftool' assumes the
tool is available in PATH.
+
Instead of running one of the known merge tool programs,
-'git difftool' can be customized to run an alternative program
+'git-difftool' can be customized to run an alternative program
by specifying the command line to invoke in a configuration
variable `mergetool.<tool>.cmd`.
+
-When 'git difftool' is invoked with this tool (either through the
+When 'git-difftool' is invoked with this tool (either through the
`-t` or `--tool` option or the `merge.tool` configuration variable)
the configured command line will be invoked with the following
variables available: `$LOCAL` is set to the name of the temporary
@@ -56,7 +56,7 @@ of the diff post-image. `$BASE` is provided for compatibility
with custom merge tool commands and has the same value as `$LOCAL`.
--no-prompt::
- Do not prompt before launching a merge tool.
+ Do not prompt before launching a diff tool.
CONFIG VARIABLES
----------------
@@ -81,13 +81,13 @@ See the `--tool=<tool>` option above for more details.
SEE ALSO
--------
-linkgit:git-diff[7]::
+linkgit:git-diff[1]::
Show changes between commits, commit and working tree, etc
linkgit:git-mergetool[1]::
Run merge conflict resolution tools to resolve merge conflicts
-linkgit:git-config[7]::
+linkgit:git-config[1]::
Get and set repository or global options
--
1.6.1.149.g7bbd8
^ permalink raw reply related
* [PATCH 2/2] difftool: put the cursor on the editable file for Vim
From: David Aguilar @ 2009-01-19 5:27 UTC (permalink / raw)
To: git; +Cc: gitster, David Aguilar
In-Reply-To: <1232342840-27459-1-git-send-email-davvid@gmail.com>
You only need to edit worktree files when comparing against
the worktree. Put the cursor automatically into its window for
vimdiff and gvimdiff to avoid doing <C-w>r every time.
Signed-off-by: David Aguilar <davvid@gmail.com>
---
contrib/difftool/git-difftool-helper | 8 ++++++--
1 files changed, 6 insertions(+), 2 deletions(-)
diff --git a/contrib/difftool/git-difftool-helper b/contrib/difftool/git-difftool-helper
index 0b266e3..a6f862f 100755
--- a/contrib/difftool/git-difftool-helper
+++ b/contrib/difftool/git-difftool-helper
@@ -78,12 +78,16 @@ launch_merge_tool () {
"$merge_tool_path" -o "$MERGED" "$LOCAL" "$REMOTE"
;;
- meld|vimdiff)
+ meld)
"$merge_tool_path" "$LOCAL" "$REMOTE"
;;
+ vimdiff)
+ "$merge_tool_path" -c "wincmd r" "$LOCAL" "$REMOTE"
+ ;;
+
gvimdiff)
- "$merge_tool_path" -f "$LOCAL" "$REMOTE"
+ "$merge_tool_path" -c "wincmd r" -f "$LOCAL" "$REMOTE"
;;
xxdiff)
--
1.6.1.149.g7bbd8
^ permalink raw reply related
* Re: [PATCH] contrib: add 'git difftool' for launching common merge tools
From: David Aguilar @ 2009-01-19 5:32 UTC (permalink / raw)
To: markus.heidelberg; +Cc: Git mailing list
In-Reply-To: <200901190603.06506.markus.heidelberg@web.de>
On Sun, Jan 18, 2009 at 9:03 PM, Markus Heidelberg
> Well, in "wincmd l" "l" doesn't mean "left", it doesn't mean "put the
> cursor into the left window", it just moves the cursor into the next
> right window. So "wincmd r" doesn't mean "put the cursor into the right
> window", but "rotate the window" (see :help ctrl-w_r).
oops.. i should know better. sorry... let's ignore 2/2 for now then.
I'll resend. duh.. I should have known better.. h left, j down, k up, l right.
>
> So with "wincmd r" the local file would be moved to the left side and
> the index file to the right side, still containing the cursor. Not what
> we want.
>
> With "wincmd l" the local file would stay on the right side, the index
> file on the left side, but the cursor would move from the left to the
> right side. Now we can edit the local file.
>
>> > You have deleted all the '-' chars from git-command, but when using it as the
>> > name I think it's the preferred method, only when used as command then without
>> > slash.
>>
>> I was wondering about that. I think I tried to follow the lead from
>> the git-diff.txt documentation, but "diff" is a builtin and thus
>> doesn't have an actual git-diff, so I see why they should be
>> different.
>
> Hmm, I don't think it makes a difference, whether it's a builtin or not.
> git-diff only exists behind the scenes, invoking it as "git-diff"
> doesn't work anymore with default settings. On the other hand, I can
> also invoke "git difftool" without the slash, git can find it. The same
> way I can for example call "git svn", which also isn't a builtin.
>
> Markus
>
>
--
David
^ permalink raw reply
* [PATCH (resend) 2/2] difftool: put the cursor on the editable file for Vim
From: David Aguilar @ 2009-01-19 5:34 UTC (permalink / raw)
To: git; +Cc: gitster, David Aguilar
You only need to edit worktree files when comparing against
the worktree. Put the cursor automatically into its window for
vimdiff and gvimdiff to avoid doing <C-w>l every time.
Signed-off-by: David Aguilar <davvid@gmail.com>
---
contrib/difftool/git-difftool-helper | 8 ++++++--
1 files changed, 6 insertions(+), 2 deletions(-)
diff --git a/contrib/difftool/git-difftool-helper b/contrib/difftool/git-difftool-helper
index 0b266e3..a6f862f 100755
--- a/contrib/difftool/git-difftool-helper
+++ b/contrib/difftool/git-difftool-helper
@@ -78,12 +78,16 @@ launch_merge_tool () {
"$merge_tool_path" -o "$MERGED" "$LOCAL" "$REMOTE"
;;
- meld|vimdiff)
+ meld)
"$merge_tool_path" "$LOCAL" "$REMOTE"
;;
+ vimdiff)
+ "$merge_tool_path" -c "wincmd l" "$LOCAL" "$REMOTE"
+ ;;
+
gvimdiff)
- "$merge_tool_path" -f "$LOCAL" "$REMOTE"
+ "$merge_tool_path" -c "wincmd l" -f "$LOCAL" "$REMOTE"
;;
xxdiff)
--
1.6.1.149.g7bbd8
^ permalink raw reply related
* Re: [HELP] A local branch has disappeared
From: Neil Macneale @ 2009-01-19 5:37 UTC (permalink / raw)
To: Johnny Lee; +Cc: git
In-Reply-To: <488807870901181954p558756f5v94c8a6681125e8bb@mail.gmail.com>
On Jan 18, 2009, at 7:54 PM, Johnny Lee wrote:
> Hi all,
>
> Today I found my current branch (named cupcake) has disappeared.
> git@tomato:~/golf$ git branch -a
> htc_cupcake
> tmo_cupcake
> origin/HEAD
> origin/cupcake
> origin/device
>
> As you can see, there is no "*" to mark the current branch.
>
> But when I check the HEAD, it still pointed to the cupcake branch
> git@tomato:~/golf$ cat .git/HEAD
> ref: refs/heads/cupcake
>
> But when I check the ref/heads, the cupcake is missing
> git@tomato:~/golf$ ls .git/refs/heads/
> htc_cupcake tmo_cupcake
>
> And the cupcake in still in the config:
> git@tomato:~/golf$ cat .git/config
> [core]
> repositoryformatversion = 0
> filemode = true
> bare = false
> logallrefupdates = true
> sharedRepository = 1
> [remote "origin"]
> url = /home/rick/golfresort/device/.git
> fetch = +refs/heads/*:refs/remotes/origin/*
> [branch "cupcake"]
> remote = origin
> merge = refs/heads/cupcake
>
> I'm confused:
> 1. I didn't do any aggressive operations. Why the branch has
> disappeared? Normally I have done these operation for this repo:
> i. pull from parent repo
> ii. cloned by children repo
> iii. pulled by children repo
> iv. pushed from children repo
> 2. Is there any way to resume the cupcake branch? Can I manually add
> the cupcake to ref/heads?
I don't know why the cupcake branch would be gone, but you can
probably get something from the logs:
$ cat .git/logs/refs/heads/cupcake
The last line should tell you what commit you were at before it was
destroyed. Then you can create the branch again.
$ git checkout -b cupcake <hash in the log>
Hope that helps,
Neil
^ permalink raw reply
* Re: git-svn updates
From: Junio C Hamano @ 2009-01-19 6:29 UTC (permalink / raw)
To: Eric Wong; +Cc: git
In-Reply-To: <20090119040615.GA11306@dcvr.yhbt.net>
Thanks, pulled.
^ permalink raw reply
* Re: [PATCH (resend) 2/2] difftool: put the cursor on the editable file for Vim
From: Junio C Hamano @ 2009-01-19 6:43 UTC (permalink / raw)
To: David Aguilar; +Cc: git
In-Reply-To: <1232343269-27665-1-git-send-email-davvid@gmail.com>
Ok, I see you updated from r to l.
Please do not mark such "an earlier one had a thinko, and here is a
corrected patch" as "resend". It is confusing, because "resend" usually
means "I sent this earlier but somehow it did not reach the list, so here
is another copy verbatim."
Instead, please add a sentence or two after "---" lines to explain the
situation, like...
You only need to edit worktree files when comparing against
the worktree. Put the cursor automatically into its window for
vimdiff and gvimdiff to avoid doing <C-w>r every time.
Signed-off-by: David Aguilar <davvid@gmail.com>
---
Markus pointed out that 'l' is not left (it is right as in vi key
bindings).
contrib/difftool/git-difftool-helper | 8 ++++++--
1 files changed, 6 insertions(+), 2 deletions(-)
and say "[PATCH 2/2 (corrected)]" so that I can easily tell which one was
a dud and which one I should take.
This time it wasn't confusing because the exchange between Markus and you
were the only unread messages before your three patches in my mailbox, but
you are not always that lucky.
Will take your original 1/2 and this one.
Thanks.
^ permalink raw reply
* Re: [HELP] A local branch has disappeared
From: Johnny Lee @ 2009-01-19 7:16 UTC (permalink / raw)
To: Neil Macneale; +Cc: git
In-Reply-To: <488807870901182219j763995c6y1796cf3c0a98a958@mail.gmail.com>
Sorry, I forgot to reply to all in the last mail, again..
Hi Neil,
I used "git lost-found" to find out the latest commits, and use git
checkout -b cupcake commit_hash to get my lost branch back.
Thanks!
Though, I'm still confused about what had happened. :(
Regards,
Johnny
On Mon, Jan 19, 2009 at 2:19 PM, Johnny Lee <johnnylee194@gmail.com> wrote:
> The log about cupcake is also gone..
>
> git@tomato:~/golf$ cat .git/logs/refs/heads/
> htc_cupcake tmo_cupcake
>
> And I can't get the latest hash by git log:
> git@tomato:~/golf$ git log
> fatal: bad default revision 'HEAD'
>
> Regards,
> Johnny
>
> On Mon, Jan 19, 2009 at 1:37 PM, Neil Macneale <mac4@theory.org> wrote:
>>
>> On Jan 18, 2009, at 7:54 PM, Johnny Lee wrote:
>>
>>> Hi all,
>>>
>>> Today I found my current branch (named cupcake) has disappeared.
>>> git@tomato:~/golf$ git branch -a
>>> htc_cupcake
>>> tmo_cupcake
>>> origin/HEAD
>>> origin/cupcake
>>> origin/device
>>>
>>> As you can see, there is no "*" to mark the current branch.
>>>
>>> But when I check the HEAD, it still pointed to the cupcake branch
>>> git@tomato:~/golf$ cat .git/HEAD
>>> ref: refs/heads/cupcake
>>>
>>> But when I check the ref/heads, the cupcake is missing
>>> git@tomato:~/golf$ ls .git/refs/heads/
>>> htc_cupcake tmo_cupcake
>>>
>>> And the cupcake in still in the config:
>>> git@tomato:~/golf$ cat .git/config
>>> [core]
>>> repositoryformatversion = 0
>>> filemode = true
>>> bare = false
>>> logallrefupdates = true
>>> sharedRepository = 1
>>> [remote "origin"]
>>> url = /home/rick/golfresort/device/.git
>>> fetch = +refs/heads/*:refs/remotes/origin/*
>>> [branch "cupcake"]
>>> remote = origin
>>> merge = refs/heads/cupcake
>>>
>>> I'm confused:
>>> 1. I didn't do any aggressive operations. Why the branch has
>>> disappeared? Normally I have done these operation for this repo:
>>> i. pull from parent repo
>>> ii. cloned by children repo
>>> iii. pulled by children repo
>>> iv. pushed from children repo
>>> 2. Is there any way to resume the cupcake branch? Can I manually add
>>> the cupcake to ref/heads?
>>
>> I don't know why the cupcake branch would be gone, but you can probably get
>> something from the logs:
>>
>> $ cat .git/logs/refs/heads/cupcake
>>
>> The last line should tell you what commit you were at before it was
>> destroyed. Then you can create the branch again.
>>
>> $ git checkout -b cupcake <hash in the log>
>>
>> Hope that helps,
>> Neil
>>
>
>
>
> --
> we all have our crosses to bear
>
--
we all have our crosses to bear
^ permalink raw reply
* Re: [RFC PATCH] Fix gitdir detection when in subdir of gitdir
From: Johannes Sixt @ 2009-01-19 7:17 UTC (permalink / raw)
To: SZEDER Gábor
Cc: Junio C Hamano, Johannes Schindelin, SZEDER Gábor, git
In-Reply-To: <20090119020311.GA8753@neumann>
SZEDER Gábor schrieb:
> if (is_git_directory(".")) {
> + char gd_rel_path[PATH_MAX];
> inside_git_dir = 1;
> if (!work_tree_env)
> inside_work_tree = 0;
> - setenv(GIT_DIR_ENVIRONMENT, ".", 1);
> + if (cdup_count) {
> + char *p = gd_rel_path;
> + while (cdup_count-- > 1) {
> + *p++ = '.'; *p++ = '.'; *p++ = '/';
> + }
> + *p++ = '.'; *p++ = '.';
> + *p = '\0';
> + } else {
> + gd_rel_path[0] = '.';
> + gd_rel_path[1] = '\0';
> + }
> + setenv(GIT_DIR_ENVIRONMENT, gd_rel_path, 1);
> check_repository_format_gently(nongit_ok);
> return NULL;
> }
This does not make sense because you don't chdir back to where you
started, so the relative path would be incorrect.
I have the feeling that it is not worth to support this particular
use-case with so many lines of code.
-- Hannes
^ permalink raw reply
* Re: how to track multiple upstreams in one repository
From: Ciprian Dorin, Craciun @ 2009-01-19 7:52 UTC (permalink / raw)
To: david; +Cc: Bryan Donlan, git
In-Reply-To: <alpine.DEB.1.10.0901181957070.20741@asgard.lang.hm>
[-- Attachment #1: Type: text/plain, Size: 1304 bytes --]
On Mon, Jan 19, 2009 at 5:58 AM, <david@lang.hm> wrote:
> On Sun, 18 Jan 2009, Bryan Donlan wrote:
>
>> On Sun, Jan 18, 2009 at 06:58:06PM -0800, david@lang.hm wrote:
>>>
>>> for linux I want to track both the linus tree and the -stable tree.
>>> Ideally I want to be able to do a checkout of tags from either tree from
>>> the same directory (along with diffs between items in both trees, etc)
>>>
>>> I have found documentation on how to clone from each of them, but I
>>> haven't found any simple documentation on how to work with both of them.
>>
>> After cloning from one:
>> git remote add remotename git://...
>> git fetch remotename
>>
>> You will now have the other repository fetched into your local
>> repository; tags from both will be replicated to your local tags.
>
> thanks, given the nature of git I figured it was something really simple,
> but I just wasn't able to find it.
>
> I've forwarded this to the kernel.org webmaster to update the 'how to follow
> linux development' page
>
> David Lang
I use something even simpler, please see the attached .git/config
file that I use. It also uses remote branches, and rewrites the refs
to something like: stable/v2.6.25/master or torvalds/v2.6/master. Also
in order to fetch them I use git fetch stable/v2.6.25
Ciprian Craciun.
[-- Attachment #2: config --]
[-- Type: application/octet-stream, Size: 1772 bytes --]
[core]
repositoryformatversion = 0
filemode = true
bare = false
logallrefupdates = true
[user]
name = Ciprian Dorin Craciun
email = ciprian.craciun@gmail.com
[url "git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/"]
insteadOf = torvalds:
[url "git://git.kernel.org/pub/scm/linux/kernel/git/stable/"]
insteadOf = stable:
[remote "torvalds/v2.6"]
url = torvalds:linux-2.6.git
fetch = refs/heads/master:refs/heads/torvalds/v2.6/master
[remote "stable/v2.6.17"]
url = stable:linux-2.6.17.y.git
fetch = refs/heads/master:refs/heads/stable/v2.6.17/master
[remote "stable/v2.6.18"]
url = stable:linux-2.6.18.y.git
fetch = refs/heads/master:refs/heads/stable/v2.6.18/master
[remote "stable/v2.6.19"]
url = stable:linux-2.6.19.y.git
fetch = refs/heads/master:refs/heads/stable/v2.6.19/master
[remote "stable/v2.6.20"]
url = stable:linux-2.6.20.y.git
fetch = refs/heads/master:refs/heads/stable/v2.6.20/master
[remote "stable/v2.6.21"]
url = stable:linux-2.6.21.y.git
fetch = refs/heads/master:refs/heads/stable/v2.6.21/master
[remote "stable/v2.6.22"]
url = stable:linux-2.6.22.y.git
fetch = refs/heads/master:refs/heads/stable/v2.6.22/master
[remote "stable/v2.6.23"]
url = stable:linux-2.6.23.y.git
fetch = refs/heads/master:refs/heads/stable/v2.6.23/master
[remote "stable/v2.6.24"]
url = stable:linux-2.6.24.y.git
fetch = refs/heads/master:refs/heads/stable/v2.6.24/master
[remote "stable/v2.6.25"]
url = stable:linux-2.6.25.y.git
fetch = refs/heads/master:refs/heads/stable/v2.6.25/master
[remote "stable/v2.6.26"]
url = stable:linux-2.6.26.y.git
fetch = refs/heads/master:refs/heads/stable/v2.6.26/master
[remote "stable/v2.6.27"]
url = stable:linux-2.6.27.y.git
fetch = refs/heads/master:refs/heads/stable/v2.6.27/master
^ permalink raw reply
* Re: [PATCH] interpret_nth_last_branch(): avoid traversing the reflogs twice
From: Junio C Hamano @ 2009-01-19 8:08 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Thomas Rast, git, Johannes Sixt, Johan Herland
In-Reply-To: <alpine.DEB.1.00.0901182152010.3586@pacific.mpi-cbg.de>
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> On Sat, 17 Jan 2009, Junio C Hamano wrote:
> ...
>> My HEAD reflog is 7MB long with 39000 entries, and among them, 13100
>> entries have "checkout: moving ".
>>
>> I know I will never want to switch back to the 10000th from the last
>> branch. I am quite sure that I would forget which branch I was on after
>> switching branches three or four times (hence my original hardcoded
>> limitation of 10 which "should be plenty"). When I know I only have to
>> keep track of 10 entries, having to keep track of 13100 entries, even if
>> it is 36kB (it would actually be 260kB in my case) feels there is
>> something wrong in the design.
>
> Hrm. So let's leave it as a two-pass thing?
Well, I would rather be in favor of something like this.
-- >8 --
Subject: interpret_nth_last_branch(): avoid traversing the reflog twice
You can have quite a many reflog entries, but you typically won't recall
which branch you were on after switching branches for more than several
times.
Instead of reading the reflog twice, this reads the branch switching event
and keeps the latest 16 (which is an arbitrary limitation that should be
plenty) such entry, to switch back to the branch we were recently on.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
---
sha1_name.c | 48 +++++++++++++++++++++------------------------
t/t2012-checkout-last.sh | 44 ++++++++++++++++++++++++++++++++++++++++++
2 files changed, 66 insertions(+), 26 deletions(-)
diff --git a/sha1_name.c b/sha1_name.c
index 9e1538e..d6622f2 100644
--- a/sha1_name.c
+++ b/sha1_name.c
@@ -684,10 +684,11 @@ static int get_sha1_oneline(const char *prefix, unsigned char *sha1)
return retval;
}
+#define MAX_PREVIOUS_BRANCH 16
+
struct grab_nth_branch_switch_cbdata {
- int counting;
- int nth;
- struct strbuf *buf;
+ long cnt;
+ struct strbuf buf[MAX_PREVIOUS_BRANCH];
};
static int grab_nth_branch_switch(unsigned char *osha1, unsigned char *nsha1,
@@ -697,6 +698,7 @@ static int grab_nth_branch_switch(unsigned char *osha1, unsigned char *nsha1,
struct grab_nth_branch_switch_cbdata *cb = cb_data;
const char *match = NULL, *target = NULL;
size_t len;
+ int nth;
if (!prefixcmp(message, "checkout: moving from ")) {
match = message + strlen("checkout: moving from ");
@@ -711,16 +713,9 @@ static int grab_nth_branch_switch(unsigned char *osha1, unsigned char *nsha1,
if (target[len] == '\n' && !strncmp(match, target, len))
return 0;
- if (cb->counting) {
- cb->nth++;
- return 0;
- }
-
- if (cb->nth-- <= 0) {
- strbuf_reset(cb->buf);
- strbuf_add(cb->buf, match, len);
- return 1;
- }
+ nth = cb->cnt++ % MAX_PREVIOUS_BRANCH;
+ strbuf_reset(&cb->buf[nth]);
+ strbuf_add(&cb->buf[nth], match, len);
return 0;
}
@@ -737,7 +732,8 @@ static int grab_nth_branch_switch(unsigned char *osha1, unsigned char *nsha1,
*/
int interpret_nth_last_branch(const char *name, struct strbuf *buf)
{
- int nth;
+ long nth;
+ int i;
struct grab_nth_branch_switch_cbdata cb;
const char *brace;
char *num_end;
@@ -750,19 +746,19 @@ int interpret_nth_last_branch(const char *name, struct strbuf *buf)
nth = strtol(name+3, &num_end, 10);
if (num_end != brace)
return -1;
-
- cb.counting = 1;
- cb.nth = 0;
- cb.buf = buf;
- for_each_reflog_ent("HEAD", grab_nth_branch_switch, &cb);
-
- if (cb.nth < nth)
- return 0;
-
- cb.counting = 0;
- cb.nth -= nth;
- cb.buf = buf;
+ if (nth <= 0 || MAX_PREVIOUS_BRANCH < nth)
+ return -1;
+ for (i = 0; i < MAX_PREVIOUS_BRANCH; i++)
+ strbuf_init(&cb.buf[i], 20);
+ cb.cnt = 0;
for_each_reflog_ent("HEAD", grab_nth_branch_switch, &cb);
+ if (cb.cnt < nth)
+ return -1;
+ i = (cb.cnt + MAX_PREVIOUS_BRANCH - nth) % MAX_PREVIOUS_BRANCH;
+ strbuf_reset(buf);
+ strbuf_add(buf, cb.buf[i].buf, cb.buf[i].len);
+ for (i = 0; i < MAX_PREVIOUS_BRANCH; i++)
+ strbuf_release(&cb.buf[i]);
return brace-name+1;
}
diff --git a/t/t2012-checkout-last.sh b/t/t2012-checkout-last.sh
index 320f6eb..87b30a2 100755
--- a/t/t2012-checkout-last.sh
+++ b/t/t2012-checkout-last.sh
@@ -47,4 +47,48 @@ test_expect_success '"checkout -" detaches again' '
test_must_fail git symbolic-ref HEAD
'
+test_expect_success 'more switches' '
+ for i in 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1
+ do
+ git checkout -b branch$i
+ done
+'
+
+more_switches () {
+ for i in 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1
+ do
+ git checkout branch$i
+ done
+}
+
+test_expect_success 'switch to the last' '
+ more_switches &&
+ git checkout @{-1} &&
+ test "z$(git symbolic-ref HEAD)" = "zrefs/heads/branch2"
+'
+
+test_expect_success 'switch to second from the last' '
+ more_switches &&
+ git checkout @{-2} &&
+ test "z$(git symbolic-ref HEAD)" = "zrefs/heads/branch3"
+'
+
+test_expect_success 'switch to third from the last' '
+ more_switches &&
+ git checkout @{-3} &&
+ test "z$(git symbolic-ref HEAD)" = "zrefs/heads/branch4"
+'
+
+test_expect_success 'switch to fourth from the last' '
+ more_switches &&
+ git checkout @{-4} &&
+ test "z$(git symbolic-ref HEAD)" = "zrefs/heads/branch5"
+'
+
+test_expect_success 'switch to twelfth from the last' '
+ more_switches &&
+ git checkout @{-12} &&
+ test "z$(git symbolic-ref HEAD)" = "zrefs/heads/branch13"
+'
+
test_done
--
1.6.1.245.gdd9f9
^ permalink raw reply related
* Re: [PATCH] interpret_nth_last_branch(): avoid traversing the reflogs twice
From: Junio C Hamano @ 2009-01-19 8:19 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Thomas Rast, git, Johannes Sixt, Johan Herland
In-Reply-To: <7vprijra52.fsf@gitster.siamese.dyndns.org>
Junio C Hamano <gitster@pobox.com> writes:
> Well, I would rather be in favor of something like this.
>
> -- >8 --
> Subject: interpret_nth_last_branch(): avoid traversing the reflog twice
>
> You can have quite a many reflog entries, but you typically won't recall
> which branch you were on after switching branches for more than several
> times.
>
> Instead of reading the reflog twice, this reads the branch switching event
> and keeps the latest 16 (which is an arbitrary limitation that should be
> plenty) such entry, to switch back to the branch we were recently on.
>
> Signed-off-by: Junio C Hamano <gitster@pobox.com>
> ---
> sha1_name.c | 48 +++++++++++++++++++++------------------------
> t/t2012-checkout-last.sh | 44 ++++++++++++++++++++++++++++++++++++++++++
> 2 files changed, 66 insertions(+), 26 deletions(-)
>
> diff --git a/sha1_name.c b/sha1_name.c
> index 9e1538e..d6622f2 100644
> --- a/sha1_name.c
> +++ b/sha1_name.c
> @@ -750,19 +746,19 @@ int interpret_nth_last_branch(const char *name, struct strbuf *buf)
> nth = strtol(name+3, &num_end, 10);
> if (num_end != brace)
> return -1;
> ...
> - if (cb.nth < nth)
> - return 0;
> ...
> + if (cb.cnt < nth)
> + return -1;
This should (obviously) be "return 0".
^ permalink raw reply
* Re: parent-filter loses my merged branch -- what am I doing wrong?
From: Johannes Sixt @ 2009-01-19 8:41 UTC (permalink / raw)
To: Ask Bjørn Hansen; +Cc: git
In-Reply-To: <7578B9A6-BF81-4096-B0FD-F433AD62A41E@develooper.com>
Ask Bjørn Hansen schrieb:
> On Sam Villain's recommendation I'm spending a bit of time cleaning up
> the branches and merges with git filter-branch, but I don't think I'm
> quite understanding how it's supposed to work.
Don't use --parent-filter for this; use grafts. You can see the history in
gitk right away. Later run filter-branch without a filter (except perhaps
the tag-name-filter).
-- Hannes
^ permalink raw reply
* What's cooking in git.git (Jan 2009, #04; Mon, 19)
From: Junio C Hamano @ 2009-01-19 9:13 UTC (permalink / raw)
To: git
Here are the topics that have been cooking. Commits prefixed with '-' are
only in 'pu' while commits prefixed with '+' are in 'next'. The ones
marked with '.' do not appear in any of the branches, but I am still
holding onto them.
The topics list the commits in reverse chronological order. The topics
meant to be merged to the maintenance series have "maint-" in their names.
----------------------------------------------------------------
[New Topics]
* jk/color-parse (Sat Jan 17 10:38:46 2009 -0500) 2 commits
+ expand --pretty=format color options
+ color: make it easier for non-config to parse color specs
* sb/hook-cleanup (Sat Jan 17 04:02:55 2009 +0100) 5 commits
+ run_hook(): allow more than 9 hook arguments
+ run_hook(): check the executability of the hook before filling
argv
+ api-run-command.txt: talk about run_hook()
+ Move run_hook() from builtin-commit.c into run-command.c (libgit)
+ checkout: don't crash on file checkout before running post-
checkout hook
* js/maint-all-implies-HEAD (Sat Jan 17 22:27:08 2009 -0800) 2 commits
- bundle: allow the same ref to be given more than once
- revision walker: include a detached HEAD in --all
* tr/previous-branch (Sat Jan 17 19:08:12 2009 +0100) 6 commits
- Fix parsing of @{-1}@{1}
- interpret_nth_last_branch(): avoid traversing the reflog twice
- checkout: implement "-" abbreviation, add docs and tests
- sha1_name: support @{-N} syntax in get_sha1()
- sha1_name: tweak @{-N} lookup
- checkout: implement "@{-N}" shortcut name for N-th last branch
* rs/ctype (Sat Jan 17 16:50:37 2009 +0100) 4 commits
+ Add is_regex_special()
+ Change NUL char handling of isspecial()
+ Reformat ctype.c
+ Add ctype test
* mh/unify-color (Sun Jan 18 21:39:12 2009 +0100) 2 commits
- move the color variables to color.c
- handle color.ui at a central place
* jf/am-failure-report (Sun Jan 18 19:34:31 2009 -0800) 2 commits
+ git-am: re-fix the diag message printing
+ git-am: Make it easier to see which patch failed
* cb/add-pathspec (Wed Jan 14 15:54:35 2009 +0100) 2 commits
- remove pathspec_match, use match_pathspec instead
- clean up pathspec matching
* sg/maint-gitdir-in-subdir (Fri Jan 16 16:37:33 2009 +0100) 1 commit
+ Fix gitdir detection when in subdir of gitdir
This has my "don't do the fullpath if you are directly inside .git"
squashed in, so it should be much safer.
* am/maint-push-doc (Sun Jan 18 15:36:58 2009 +0100) 4 commits
+ Documentation: avoid using undefined parameters
+ Documentation: mention branches rather than heads
+ Documentation: remove a redundant elaboration
+ Documentation: git push repository can also be a remote
* sp/runtime-prefix (Sun Jan 18 13:00:15 2009 +0100) 5 commits
- Windows: Revert to default paths and convert them by
RUNTIME_PREFIX
- Modify setup_path() to only add git_exec_path() to PATH
- Add calls to git_extract_argv0_path() in programs that call
git_config_*
- git_extract_argv0_path(): Move check for valid argv0 from caller
to callee
- Move computation of absolute paths from Makefile to runtime (in
preparation for RUNTIME_PREFIX)
----------------------------------------------------------------
[Stalled and may need help and prodding to go forward]
* jc/blame (Wed Jun 4 22:58:40 2008 -0700) 2 commits
+ blame: show "previous" information in --porcelain/--incremental
format
+ git-blame: refactor code to emit "porcelain format" output
This gives Porcelains (like gitweb) the information on the commit _before_
the one that the final blame is laid on, which should save them one
rev-parse to dig further. The line number in the "previous" information
may need refining, and sanity checking code for reference counting may
need to be resurrected before this can move forward.
* db/foreign-scm (Sun Jan 11 15:12:10 2009 -0500) 3 commits
- Support fetching from foreign VCSes
- Add specification of git-vcs helpers
- Add "vcs" config option in remotes
The "spec" did not seem quite well cooked yet, but in the longer term I
think something like this to allow interoperating with other SCMs as if
the other end is a native git repository is a very worthy goal.
----------------------------------------------------------------
[Actively cooking]
* kb/lstat-cache (Sun Jan 18 16:14:54 2009 +0100) 5 commits
+ lstat_cache(): introduce clear_lstat_cache() function
+ lstat_cache(): introduce invalidate_lstat_cache() function
+ lstat_cache(): introduce has_dirs_only_path() function
+ lstat_cache(): introduce has_symlink_or_noent_leading_path()
function
+ lstat_cache(): more cache effective symlink/directory detection
This is the tenth round, now in 'next'.
* lh/submodule-tree-traversal (Mon Jan 12 00:45:55 2009 +0100) 3 commits
- builtin-ls-tree: enable traversal of submodules
- archive.c: enable traversal of submodules
- tree.c: add support for traversal of submodules
Still getting active reviews.
* lt/maint-wrap-zlib (Wed Jan 7 19:54:47 2009 -0800) 1 commit
+ Wrap inflate and other zlib routines for better error reporting
Needs the "free our memory upon seeing Z_MEM_ERROR and try again" bits
extracted from Shawn's patch on top of this one.
* jk/signal-cleanup (Sun Jan 11 06:36:49 2009 -0500) 3 commits
- pager: do wait_for_pager on signal death
- refactor signal handling for cleanup functions
- chain kill signals for cleanup functions
Sorry, I lost track. What is the status of this one?
* js/diff-color-words (Sat Jan 17 17:29:48 2009 +0100) 7 commits
- color-words: make regex configurable via attributes
- color-words: expand docs with precise semantics
- color-words: enable REG_NEWLINE to help user
- color-words: take an optional regular expression describing words
- color-words: change algorithm to allow for 0-character word
boundaries
- color-words: refactor word splitting and use ALLOC_GROW()
- Add color_fwrite_lines(), a function coloring each line
individually
Dscho's series that was done in response to Thomas's original; two agreed
to work together on this codebase.
* ks/maint-mailinfo-folded (Tue Jan 13 01:21:04 2009 +0300) 5 commits
- mailinfo: tests for RFC2047 examples
- mailinfo: add explicit test for mails like '<a.u.thor@example.com>
(A U Thor)'
- mailinfo: more smarter removal of rfc822 comments from 'From'
+ mailinfo: 'From:' header should be unfold as well
+ mailinfo: correctly handle multiline 'Subject:' header
I think "more smarter" one is too aggressive for our purpose. Perhaps not
removing comments at all would be what we want.
* js/patience-diff (Thu Jan 1 17:39:37 2009 +0100) 3 commits
+ bash completions: Add the --patience option
+ Introduce the diff option '--patience'
+ Implement the patience diff algorithm
* js/notes (Tue Jan 13 20:57:16 2009 +0100) 6 commits
+ git-notes: fix printing of multi-line notes
+ notes: fix core.notesRef documentation
+ Add an expensive test for git-notes
+ Speed up git notes lookup
+ Add a script to edit/inspect notes
+ Introduce commit notes
* sc/gitweb-category (Fri Dec 12 00:45:12 2008 +0100) 3 commits
- gitweb: Optional grouping of projects by category
- gitweb: Split git_project_list_body in two functions
- gitweb: Modularized git_get_project_description to be more generic
----------------------------------------------------------------
[Graduated to "master"]
* ds/uintmax-config (Mon Nov 3 09:14:28 2008 -0900) 1 commit
+ autoconf: Enable threaded delta search when pthreads are supported
See if anybody screams.
* gb/gitweb-opml (Fri Jan 2 13:49:30 2009 +0100) 2 commits
+ gitweb: suggest name for OPML view
+ gitweb: don't use pathinfo for global actions
* mv/apply-parse-opt (Fri Jan 9 22:21:36 2009 -0800) 2 commits
+ Resurrect "git apply --flags -" to read from the standard input
+ parse-opt: migrate builtin-apply.
* tr/rebase-root (Fri Jan 2 23:28:29 2009 +0100) 4 commits
+ rebase: update documentation for --root
+ rebase -i: learn to rebase root commit
+ rebase: learn to rebase root commit
+ rebase -i: execute hook only after argument checking
Looked reasonable.
* mh/maint-commit-color-status (Thu Jan 8 19:53:05 2009 +0100) 2 commits
+ git-status -v: color diff output when color.ui is set
+ git-commit: color status output when color.ui is set
* rs/maint-shortlog-foldline (Tue Jan 6 21:41:06 2009 +0100) 1 commit
+ shortlog: handle multi-line subjects like log --pretty=oneline et.
al. do
* rs/fgrep (Sat Jan 10 00:18:34 2009 +0100) 2 commits
+ grep: don't call regexec() for fixed strings
+ grep -w: forward to next possible position after rejected match
* as/autocorrect-alias (Sun Jan 4 18:16:01 2009 +0100) 1 commit
+ git.c: make autocorrected aliases work
* tr/maint-no-index-fixes (Wed Jan 7 12:15:30 2009 +0100) 3 commits
+ diff --no-index -q: fix endless loop
+ diff --no-index: test for pager after option parsing
+ diff: accept -- when using --no-index
* jc/maint-format-patch (Sat Jan 10 12:41:33 2009 -0800) 1 commit
+ format-patch: show patch text for the root commit
* ap/clone-into-empty (Sun Jan 11 15:19:12 2009 +0300) 2 commits
+ Allow cloning to an existing empty directory
+ add is_dot_or_dotdot inline function
* gb/gitweb-patch (Thu Dec 18 08:13:19 2008 +0100) 4 commits
+ gitweb: link to patch(es) view in commit(diff) and (short)log view
+ gitweb: add patches view
+ gitweb: change call pattern for git_commitdiff
+ gitweb: add patch view
----------------------------------------------------------------
[Will merge to "master" soon]
* kb/am-directory (Wed Jan 14 16:29:59 2009 -0800) 2 commits
+ git-am: fix shell quoting
+ git-am: add --directory=<dir> option
This is "third-time-lucky, perhaps?" resurrection. I do not think I'd be
using this very often, but it originated from a real user request.
* jc/maint-format-patch-o-relative (Mon Jan 12 15:18:02 2009 -0800) 1 commit
+ Teach format-patch to handle output directory relative to cwd
----------------------------------------------------------------
[On Hold]
* jk/renamelimit (Sat May 3 13:58:42 2008 -0700) 1 commit
. diff: enable "too large a rename" warning when -M/-C is explicitly
asked for
* jc/stripspace (Sun Mar 9 00:30:35 2008 -0800) 6 commits
. git-am --forge: add Signed-off-by: line for the author
. git-am: clean-up Signed-off-by: lines
. stripspace: add --log-clean option to clean up signed-off-by:
lines
. stripspace: use parse_options()
. Add "git am -s" test
. git-am: refactor code to add signed-off-by line for the committer
* jc/post-simplify (Fri Aug 15 01:34:51 2008 -0700) 2 commits
. revision --simplify-merges: incremental simplification
. revision --simplify-merges: prepare for incremental simplification
* jk/valgrind (Thu Oct 23 04:30:45 2008 +0000) 2 commits
. valgrind: ignore ldso errors
. add valgrind support in test scripts
* wp/add-patch-find (Thu Nov 27 04:08:03 2008 +0000) 3 commits
. In add --patch, Handle K,k,J,j slightly more gracefully.
. Add / command in add --patch
. git-add -i/-p: Change prompt separater from slash to comma
* jc/grafts (Wed Jul 2 17:14:12 2008 -0700) 1 commit
. [BROKEN wrt shallow clones] Ignore graft during object transfer
* jc/replace (Fri Oct 31 09:21:39 2008 -0700) 1 commit
. WIP
^ permalink raw reply
* What's in git.git (Jan 2009, #02; Mon, 19)
From: Junio C Hamano @ 2009-01-19 9:13 UTC (permalink / raw)
To: git
Tonight's pushout has some git-svn updates included, in addition to a
handful of new features.
Perhaps 1.6.1.1 mid next week.
* The 'maint' branch has these fixes since the last announcement.
Christian Couder (1):
builtin-fsck: fix off by one head count
Johannes Schindelin (3):
http-push: fix off-by-path_len
http-push: when making directories, have a trailing slash in the path
name
t5540: clarify that http-push does not handle packed-refs on the remote
Junio C Hamano (2):
Update draft release notes to 1.6.1.1
Update draft release notes for 1.6.1.1
Markus Heidelberg (1):
Documentation: let asciidoc align related options
Michael J Gruber (2):
add test cases for "git mv -k"
fix handling of multiple untracked files for git mv -k
Miklos Vajna (1):
Make t3411 executable
Stephan Beyer (5):
t3501: check that commits are actually done
t3404: Add test case for aborted --continue after "edit"
t3404: Add test case for auto-amending only edited commits after "edit"
builtin-commit.c: do not remove COMMIT_EDITMSG
githooks.txt: add missing word
* The 'master' branch has these since the last announcement
in addition to the above.
Adeodato Simó (1):
git.c: make autocorrected aliases work
Alexander Potashev (2):
add is_dot_or_dotdot inline function
Allow cloning to an existing empty directory
Brandon Casey (1):
t7700: demonstrate misbehavior of 'repack -a' when local packs exist
David Aguilar (3):
contrib: add 'git difftool' for launching common merge tools
difftool: fix documentation problems
difftool: put the cursor on the editable file for Vim
David M. Syzdek (1):
autoconf: Enable threaded delta search when pthreads are supported
Eric Wong (4):
git-svn: handle empty files marked as symlinks in SVN
git-svn: better attempt to handle broken symlink updates
git-svn: fix SVN 1.1.x compatibility
git-svn: avoid importing nested git repos
Giuseppe Bilotta (6):
gitweb: add patch view
gitweb: change call pattern for git_commitdiff
gitweb: add patches view
gitweb: link to patch(es) view in commit(diff) and (short)log view
gitweb: don't use pathinfo for global actions
gitweb: suggest name for OPML view
Junio C Hamano (2):
Resurrect "git apply --flags -" to read from the standard input
format-patch: show patch text for the root commit
Keith Cascio (1):
test more combinations of ignore-whitespace options to diff
Marcel Koeppen (1):
git-svn: Show UUID in svn info for added directories with svn 1.5.5
Markus Heidelberg (4):
git-commit: color status output when color.ui is set
git-status -v: color diff output when color.ui is set
Documentation: let asciidoc align related options
mergetool: put the cursor on the editable file for Vim
Miklos Vajna (1):
parse-opt: migrate builtin-apply.
Pete Harlan (1):
git-svn: Add --localtime option to "fetch"
René Scharfe (3):
shortlog: handle multi-line subjects like log --pretty=oneline et. al. do
grep -w: forward to next possible position after rejected match
grep: don't call regexec() for fixed strings
SZEDER Gábor (3):
bash: remove unnecessary checks for long options with argument
bash: add missing format-patch command line options
bash: refactor 'git log --pretty=<format>' options
Ted Pavlic (3):
bash-completion: Support running when set -u is enabled
bash-completion: Try bash completions before simple filetype
bash-completion: Add comments to remind about required arguments
Thomas Rast (7):
rebase -i: execute hook only after argument checking
diff: accept -- when using --no-index
diff --no-index: test for pager after option parsing
diff --no-index -q: fix endless loop
rebase: learn to rebase root commit
rebase -i: learn to rebase root commit
rebase: update documentation for --root
^ permalink raw reply
* how to omit rename file when commit
From: Frank Li @ 2009-01-19 9:13 UTC (permalink / raw)
To: git
For example there are a file a.c at git repository.
use
git mv a.c b.c
git status:
# On branch master
# Changes to be committed:
# (use "git reset HEAD <file>..." to unstage)
#
# renamed: a.c -> b.c
If we don't want to stage this change at this commit, what can I do?
^ permalink raw reply
* Re: how to omit rename file when commit
From: Junio C Hamano @ 2009-01-19 9:16 UTC (permalink / raw)
To: Frank Li; +Cc: git
In-Reply-To: <1976ea660901190113l5407f108lff8f37d9a8331f58@mail.gmail.com>
"Frank Li" <lznuaa@gmail.com> writes:
> For example there are a file a.c at git repository.
> use
> git mv a.c b.c
>
> git status:
> # On branch master
> # Changes to be committed:
> # (use "git reset HEAD <file>..." to unstage)
> #
> # renamed: a.c -> b.c
>
> If we don't want to stage this change at this commit, what can I do?
I may be misunderstanding what you want to do, but wouldn't "git mv b.c
a.c" undo whatever you did?
^ 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