* Re: [PATCH 3/3] user-manual: use 'fast-forward'
From: Felipe Contreras @ 2009-10-12 10:05 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7veip9jj6z.fsf@alter.siamese.dyndns.org>
On Mon, Oct 12, 2009 at 8:05 AM, Junio C Hamano <gitster@pobox.com> wrote:
> Felipe Contreras <felipe.contreras@gmail.com> writes:
>
>> It's a compound word.
>
> Thanks.
>
> This removes 7 out of 37 "fast forward" in Documentation/ directory. Are
> we going to convert the remaining ones, too?
Sure. Once I finish pushing the patches I have for user-manual, which
is the one I'm interested right now.
--
Felipe Contreras
^ permalink raw reply
* Re: [PATCH 2/3] git config: clarify bool types
From: Felipe Contreras @ 2009-10-12 10:03 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7v7hv1kxyg.fsf@alter.siamese.dyndns.org>
On Mon, Oct 12, 2009 at 8:01 AM, Junio C Hamano <gitster@pobox.com> wrote:
> Felipe Contreras <felipe.contreras@gmail.com> writes:
>
>> The value is what it is, the --bool and --bool-or-int options don't
>> specify the value type, just how it is interpreted. For example: a value
>> of '1' can be interpreted as 'true'.
>
> It is not really about "interpreting", but about showing, isn't it?
Unless you are setting it, instead of reading it.
--
Felipe Contreras
^ permalink raw reply
* [PATCH] Let --decorate show HEAD position
From: Thomas Rast @ 2009-10-12 9:01 UTC (permalink / raw)
To: git; +Cc: Junio C Hamano, René Scharfe
'git log --graph --oneline --decorate --all' is a useful way to get a
general overview of the repository state, similar to 'gitk --all'.
Let it indicate the position of HEAD by loading that ref too, so that
the --decorate code can see it.
Signed-off-by: Thomas Rast <trast@student.ethz.ch>
---
log-tree.c | 1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/log-tree.c b/log-tree.c
index 1618f3c..f7d54f2 100644
--- a/log-tree.c
+++ b/log-tree.c
@@ -43,6 +43,7 @@ void load_ref_decorations(int flags)
if (!loaded) {
loaded = 1;
for_each_ref(add_ref_decoration, &flags);
+ head_ref(add_ref_decoration, &flags);
}
}
--
1.6.5.59.g76726.dirty
^ permalink raw reply related
* [PATCH] bash completion: complete refs for git-grep
From: Thomas Rast @ 2009-10-12 9:00 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: git
In-Reply-To: <200910071727.50770.trast@student.ethz.ch>
Before the --, always attempt ref completion. This helps with
entering the <treeish> arguments to git-grep. As a bonus, you can
work around git-grep's current lack of --all by hitting M-*, ugly as
the resulting command line may be.
Strictly speaking, completing the regular expression argument (or
option argument) makes no sense. However, we cannot prevent _all_
completion (it will fall back to filenames), so we dispense with any
additional complication to detect whether the user still has to enter
a regular expression.
Signed-off-by: Thomas Rast <trast@student.ethz.ch>
---
Sorry for taking so long; I was swamped all weekend by, well, the
weekend. ;-)
I wrote:
> Shawn O. Pearce wrote:
> > > This is still RFC because, as you can see in the code below, I tried
> > > to avoid completing at all while the user still needs to supply a
> > > regex. Sadly, bash turns the COMPREPLY=() into filename completion
> > > anyway. Is there a way to prevent this?
> >
> > Not that I know of. You can turn off default filename completion
> > when you register the completion function, but that then breaks
> > like every other git command for completion support because a lot
> > of them do want to complete filenames.
>
> So I'll roll a simpler patch that just always (before --) completes
> refs instead, if that's ok.
So that's what this patch does.
contrib/completion/git-completion.bash | 3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/contrib/completion/git-completion.bash b/contrib/completion/git-completion.bash
index 6fd7e1d..b08cd77 100755
--- a/contrib/completion/git-completion.bash
+++ b/contrib/completion/git-completion.bash
@@ -1048,7 +1048,8 @@ _git_grep ()
return
;;
esac
- COMPREPLY=()
+
+ __gitcomp "$(__git_refs)"
}
_git_help ()
--
1.6.5.61.g35405
^ permalink raw reply related
* Re: [PATCH] git-gui: Fixed _main window_ for screen height equal 600 px
From: Vietor Liu @ 2009-10-12 8:23 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Shawn O. Pearce, git
In-Reply-To: <alpine.DEB.1.00.0910120934420.4985@pacific.mpi-cbg.de>
On Mon, 2009-10-12 at 09:35 +0200, Johannes Schindelin wrote:
>
> So what you _actually_ do is reduce the space for the diff, no?
>
Yes.
The _main window_ support auto resize. I was tested some way, only
modify _diff body_ space could work. The _diff body_ is part of _main
window_.
Whether modify the commit message?
^ permalink raw reply
* Re: Re: [PATCH/RFC] builtin-checkout: suggest creating local branch when appropriate to do so
From: Johannes Schindelin @ 2009-10-12 7:49 UTC (permalink / raw)
To: Euguess; +Cc: Mikael Magnusson, Matthieu Moy, Jeff King, Jay Soffian, git
In-Reply-To: <0016e68fd0123a175304754694b4@google.com>
Hi,
On Tue, 6 Oct 2009, Euguess@gmail.com wrote:
> I'ma new user of git and I don't think i will ever have a commit in
> git.git, because I'm not a programmer (I'm QA).
Welcome!
Let me take this opportunity to express my deep sadness that your first
input to this list was brushed off so carelessly.
I sincerely hope that you give us another chance, and that you let us
benefit from your fresh and unbiased view of the usability issues in Git
(some of us use Git for so long, they think that Git has no usability
issues anymore).
> I was reading this topic as carefully as i could and I think that this
> makes a lot of sense to address this issue. As i understand when
> somebody fetches from remote repo in order to be able to start working
> on the code from this remote repo you should create tracking branch for
> one of the branches from remote and only then you should do your changes
> or perform merges.
>
> in case if you didn't do that and you try to checkout you will end up
> having detached HEAD which is quite scary;) for non-experienced user and
> as i see might lead to some unnecessary questions in this list or on IRC
> channel...
Right. We see that type of confusion in #git everyday, and blaming the
user would be a violation of http://c2.com/cgi/wiki?BlameTheRightThing
> As for the solution i would choose the "simplest thing that will work" -
> so i think that we just have to notify user about his suicide attempt to
> checkout nonlocal branch and offer him a correct syntax to go with.
>
> Something like below should work:
>
> % git clone git://git.git git
> % git checkout next
> You're attempting to checkout to non-local branch. This will lead to your HEAD
> being detached (our team is on its way!).
> Do you want to check out local branch 'next' tracking 'origin/next' instead?
> y/n
>
> if yes, then:
> Created branch "next" tracking "origin/next"
> You can update it with 'git pull'.
>
> If no - abort or continue with checkout to nonlocal branch? ('m not sure if
> detaching HEAD can provide some benefits if done on purpose)
>
> I hope I'm not missing anything...
No, I think that is something perfectly fine to expect in a software whose
UI complexity is unfortunately pretty much in disagreement with its
internal complexity.
One thing one might add for the technically inclined folks (i.e. those who
need to implement, and to see that Git is in dear need of some
user-friendliness first): "git checkout" is a porcelain (i.e. a program
meant for end-user consumption), and as such should not have a problem to
react to isatty(0) (i.e. "is the input coming directly from the
console?").
So yes, even if I was on the verge of giving up on this thread, I have
been encouraged enough to get this uphill battle going again, and to try
to overturn some stubborn resistance.
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH] git-gui: Fixed _main window_ for screen height equal 600 px
From: Johannes Schindelin @ 2009-10-12 7:35 UTC (permalink / raw)
To: Vietor Liu; +Cc: Shawn O. Pearce, git
In-Reply-To: <1255329194-2757-1-git-send-email-vietor@vxwo.org>
Hi,
On Mon, 12 Oct 2009, Vietor Liu wrote:
> When the screen height equal 600 px(e.g. Asus EeePC 1024x600), The
> _main window_ should be hide the _Push button_ and _Status bar_.
Your commit message disagrees with the patch:
> set ui_diff .vpane.lower.diff.body.t
> text $ui_diff -background white -foreground black \
> -borderwidth 0 \
> - -width 80 -height 15 -wrap none \
> + -width 80 -height 5 -wrap none \
> -font font_diff \
So what you _actually_ do is reduce the space for the diff, no?
Ciao,
Dscho
^ permalink raw reply
* Re: can't create a branch on remote
From: Auguste Mome @ 2009-10-12 7:19 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git
In-Reply-To: <m363aogqz9.fsf@localhost.localdomain>
OK thanks I'm going to try this out, let me ask a question because it
sounds my work flow is not good.
I don't want to push the work done in my local branch to head/master,
I want to push this work into
"long-live" branch of a central repository, which belongs to "admin",
and eventually this branch does not exist yet.
my-central-repo: master, origin = linux-2.6.git
branch1, branched at v2.6.21.7
branch2, branched at v2.6.21.7
-> I want (not admin) people to clone my-repo and work on branch1
and/or branch2.
-> I want some people to add a new branch3 at v2.6.21.7 into my-central-repo.
(This will not happen very often, can be restricted to admin)
Maybe in this case it is common to define more "public" repositories:
repo-branch1/ and repo-branch2/
I guess people could then clone repo-branchX and push the work done,
and up to owner of my-central-repo
to merge repo-branchX/master into my-central-repo/branchX?
Auguste.
2009/10/10 Jakub Narebski <jnareb@gmail.com>:
> Auguste Mome <augustmome@gmail.com> writes:
>
>> Hi,
>> I have two repositories /home/user/linux and /home/user/dev/linux,
>> same user on same machine.
>> Here is how I create a local branch at v2.6.21.7 in /home/user/dev/linux,
>> #pwd
>> /home/user/dev/linux
>> # git remote add l2621
>> git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-2.6.21.y.git
>> # git fetch l2621
>> # git branch mylocal26217 v2.6.21.7
>>
>> Now I would like to do the same from the other repository /home/user/linux:
>> # pwd
>> /home/user/linux
>> # git remote add other /home/guerin/dev/git/linux-2.6
>> # git fetch other
>> # git push /home/user/dev/git/linux-2.6
>> v2.6.21.7:refs/heads/new_feature_name26217
>> Total 0 (delta 0), reused 0 (delta 0)
>> error: Trying to write non-commit object
>
> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>
>> 170684ef0557d4b711a86595d31dcbebcb9d4ba2 to branch
>> refs/heads/new_feature_name26217
>> To /home/user/dev/git/linux-2.6
>> ! [remote rejected] v2.6.21.7 -> new_feature_name26217 (failed to write)
>> error: failed to push some refs to '/home/user/dev/git/linux-2.6'
>>
>> Maybe something to configure to authorize the creation of branch?
>
> You can't push tag to branch.
>
>
> I'm not sure if what you are trying to do makes sense at all, but the
> commit pointed by v2.6.21.7 is v2.6.21.7^{}
>
> --
> Jakub Narebski
> Poland
> ShadeHawk on #git
>
^ permalink raw reply
* Re: git log --graph
From: Matthieu Moy @ 2009-10-12 6:54 UTC (permalink / raw)
To: Dilip M; +Cc: Sverre Rabbelier, git
In-Reply-To: <c94f8e120910112001l50f9332fs43d0762bbd9207a3@mail.gmail.com>
Dilip M <dilipm79@gmail.com> writes:
> Understood. it shows only when I have merged conflicts!
>
> In case, it is a fast forward merge. It doesn't show. Which is good :)
Fast-forward and merge conflicts are two different things. Non-fast
forward occurs when you merge two branches which are not a direct
ancestor of each other, i.e. both have commits that the other do not
have.
In case of non-fast forward, if you didn't touch the same file in both
branches, the merge is still trivial and conflict-free. If you touched
the same files, then Git has to apply in-file merge strategy, but that
doesn't mean you'll get conflicts either. Conflicts will occur when
you touched the same part of the same file.
--
Matthieu Moy
http://www-verimag.imag.fr/~moy/
^ permalink raw reply
* Re: [RFC/PATCH] git: add --no-replace option to disable replacing
From: Johannes Sixt @ 2009-10-12 6:32 UTC (permalink / raw)
To: Christian Couder
Cc: Junio C Hamano, git, Jakub Narebski, bill lam, Andreas Schwab
In-Reply-To: <20091011153227.8487.81803.chriscool@tuxfamily.org>
Christian Couder schrieb:
> So there is no way to disable it for some commands, which is annoying
> when we want to get information about a commit that has been replaced.
>
> For example:
>
> $ git cat-file -p N
>
> would output information about the replacement commit if commit N is
> replaced.
>
> With the "--no-replace" option that this patch adds it is possible to
> get information about the original commit using:
>
> $ git --no-replace cat-file -p N
I think it makes sense. But given the exotic nature of this option, I'd
prefer a more specific name, e.g., --no-replace-objects.
-- Hannes
^ permalink raw reply
* [PATCH] git-gui: Fixed _main window_ for screen height equal 600 px
From: Vietor Liu @ 2009-10-12 6:33 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: git
When the screen height equal 600 px(e.g. Asus EeePC 1024x600), The
_main window_ should be hide the _Push button_ and _Status bar_.
Signed-off-by: Vietor Liu <vietor@vxwo.org>
---
git-gui.sh | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/git-gui.sh b/git-gui.sh
index 09b2720..037a1f2 100755
--- a/git-gui.sh
+++ b/git-gui.sh
@@ -3083,7 +3083,7 @@ frame .vpane.lower.diff.body
set ui_diff .vpane.lower.diff.body.t
text $ui_diff -background white -foreground black \
-borderwidth 0 \
- -width 80 -height 15 -wrap none \
+ -width 80 -height 5 -wrap none \
-font font_diff \
-xscrollcommand {.vpane.lower.diff.body.sbx set} \
-yscrollcommand {.vpane.lower.diff.body.sby set} \
--
1.6.5
^ permalink raw reply related
* Re: What's cooking in git.git (Oct 2009, #02; Sun, 11)
From: Sverre Rabbelier @ 2009-10-12 6:23 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vfx9pmhae.fsf@alter.siamese.dyndns.org>
Heya,
On Mon, Oct 12, 2009 at 05:18, Junio C Hamano <gitster@pobox.com> wrote:
> [Stalled]
>
> * sr/gfi-options (2009-09-06) 6 commits.
> - fast-import: test the new option command
> - fast-import: add option command
> - fast-import: test the new feature command
> - fast-import: add feature command
> - fast-import: put marks reading in it's own function
> - fast-import: put option parsing code in separate functions
>
> Ejected from 'next' as fast-import folks still seem to be discussing with
> how to proceed.
Thanks, I hope to have this re-rolled before 1.6.6 goes into RC.
--
Cheers,
Sverre Rabbelier
^ permalink raw reply
* [RFC/PATCH] gitweb: linkify author/committer names with search
From: Stephen Boyd @ 2009-10-12 6:19 UTC (permalink / raw)
To: git; +Cc: Jakub Narebski
It's nice to search for an author by merely clicking on their name in
gitweb. This is usually faster than selecting the name, copying the
selection, pasting it into the search box, selecting between
author/committer and then hitting enter.
Signed-off-by: Stephen Boyd <bebarino@gmail.com>
---
Cc'ed Jakub as he seems to be resident gitweb expert.
I thought this might be a nice addition.
The problem is I can't get it to work with UTF-8 characters. I'm not sure
if it's my system or not, so I'm just posting here to see if others
experience the same problem and if there's interest.
gitweb/gitweb.perl | 18 ++++++++++++++----
1 files changed, 14 insertions(+), 4 deletions(-)
diff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl
index 24b2193..349e734 100755
--- a/gitweb/gitweb.perl
+++ b/gitweb/gitweb.perl
@@ -1604,7 +1604,10 @@ sub format_author_html {
my $author = chop_and_escape_str($co->{'author_name'}, @_);
return "<$tag class=\"author\">" .
git_get_avatar($co->{'author_email'}, -pad_after => 1) .
- $author . "</$tag>";
+ $cgi->a({-href => href(action=>"search", hash=>$hash,
+ searchtext=>$co->{'author_name'},
+ searchtype=>"author"), class=>"list"}, $author) .
+ "</$tag>";
}
# format git diff header line, i.e. "diff --(git|combined|cc) ..."
@@ -3373,10 +3376,13 @@ sub git_print_authorship {
my $co = shift;
my %opts = @_;
my $tag = $opts{-tag} || 'div';
+ my $author = $co->{'author_name'};
my %ad = parse_date($co->{'author_epoch'}, $co->{'author_tz'});
print "<$tag class=\"author_date\">" .
- esc_html($co->{'author_name'}) .
+ $cgi->a({-href => href(action=>"search", searchtext=>$author,
+ searchtype=>"author"), class=>"list"},
+ esc_html($author)) .
" [$ad{'rfc2822'}";
print_local_time(%ad) if ($opts{-localtime});
print "]" . git_get_avatar($co->{'author_email'}, -pad_before => 1)
@@ -3395,8 +3401,12 @@ sub git_print_authorship_rows {
@people = ('author', 'committer') unless @people;
foreach my $who (@people) {
my %wd = parse_date($co->{"${who}_epoch"}, $co->{"${who}_tz"});
- print "<tr><td>$who</td><td>" . esc_html($co->{$who}) . "</td>" .
- "<td rowspan=\"2\">" .
+ print "<tr><td>$who</td><td>" .
+ $cgi->a({-href => href(action=>"search",
+ searchtext=>$co->{"${who}_name"},
+ searchtype=>$who), class=>"list"},
+ esc_html($co->{$who})) .
+ "</td><td rowspan=\"2\">" .
git_get_avatar($co->{"${who}_email"}, -size => 'double') .
"</td></tr>\n" .
"<tr>" .
--
1.6.5.1.g53fd
^ permalink raw reply related
* Re: [PATCH/RFC 0/4] plumbing to help fix git-gui
From: Jonathan Nieder @ 2009-10-12 5:45 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Jens Lehmann, git, Shawn O. Pearce
In-Reply-To: <20091012052536.GA11106@progeny.tock>
Jonathan Nieder wrote:
> Junio C Hamano wrote:
>> Perhaps an interface to give a cleaned-up version, e.g.
>>
>> $ git check-ref-format --print refs/heads//foo/bar
>> refs/heads/foo/bar
>>
>> is what you want in order to fix git-gui? I dunno.
>
> The following packages do exactly that.
s/packages/patches/
I better sleep...
Sorry for the confusion,
Jonathan
^ permalink raw reply
* Git: "No you can't handle my root!" (?)
From: sylvain @ 2009-10-12 5:28 UTC (permalink / raw)
To: git
Git is good, Git is great! All praise the Git! :-D
What do you people think about this strange phenomena?
localhost / # git --version
git version 1.6.4.4
localhost / # git init
Initialized empty Git repository in //.git/
localhost / # cd etc
localhost etc # git add X11/xorg.conf
fatal: pathspec 'etc/X11/xorg.conf' did not match any files
Aside from the obvious question of why would I want to Git the whole
tree ("But all files deserve the Holy Presence of the Git!"), why does
Git refuse the love offering from "/etc/X11/xorg.conf"? Is it because
it contains font directory configurations?
Commit and [ENTER] to all,
S! :-)
^ permalink raw reply
* [PATCH/RFC 4/4] check-ref-format: simplify --print implementation
From: Jonathan Nieder @ 2009-10-12 5:33 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Jens Lehmann, git, Shawn O. Pearce
In-Reply-To: <20091012052536.GA11106@progeny.tock>
normalize_path_copy() is a complicated function, but most of its
functionality will never apply to a ref name that has been checked
with check_ref_format().
Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
---
builtin-check-ref-format.c | 25 +++++++++++++++++++++++--
1 files changed, 23 insertions(+), 2 deletions(-)
diff --git a/builtin-check-ref-format.c b/builtin-check-ref-format.c
index b97b61a..e439136 100644
--- a/builtin-check-ref-format.c
+++ b/builtin-check-ref-format.c
@@ -7,6 +7,28 @@
#include "builtin.h"
#include "strbuf.h"
+/*
+ * Replace each run of adjacent slashes in src with a single slash,
+ * and write the result to dst.
+ *
+ * This function is similar to normalize_path_copy(), but stripped down
+ * to meet check_ref_format's simpler needs.
+ */
+static void collapse_slashes(char *dst, const char *src)
+{
+ char ch;
+ char prev = '\0';
+
+ while (ch = *src++) {
+ if (prev == '/' && ch == prev)
+ continue;
+
+ *dst++ = ch;
+ prev = ch;
+ }
+ *dst = '\0';
+}
+
int cmd_check_ref_format(int argc, const char **argv, const char *prefix)
{
if (argc == 3 && !strcmp(argv[1], "--branch")) {
@@ -22,8 +44,7 @@ int cmd_check_ref_format(int argc, const char **argv, const char *prefix)
if (check_ref_format(argv[2]))
exit(1);
- if (normalize_path_copy(refname, argv[2]))
- die("Could not normalize ref name '%s'", argv[2]);
+ collapse_slashes(refname, argv[2]);
printf("%s\n", refname);
exit(0);
}
--
1.6.5.rc1.199.g596ec
^ permalink raw reply related
* [PATCH/RFC 3/4] git check-ref-format --print
From: Jonathan Nieder @ 2009-10-12 5:31 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Jens Lehmann, git, Shawn O. Pearce
In-Reply-To: <20091012052536.GA11106@progeny.tock>
Tolerating empty path components in ref names means each ref does
not have a unique name. This creates difficulty for porcelains
that want to see if two branches are equal. Add a helper associating
to each ref a canonical name.
If a user asks a porcelain to create a ref "refs/heads//master",
the porcelain can run "git check-ref-format --print refs/heads//master"
and only deal with "refs/heads/master" from then on.
In the future, it would be very nice if this command could be
modified to transform Unicode ref names to some appropriate
normalization form, to make Unicode ref names usable in Mac OS X,
too, and less confusing everywhere.
Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
---
Documentation/git-check-ref-format.txt | 25 +++++++++++++++++++------
builtin-check-ref-format.c | 10 ++++++++++
t/t1402-check-ref-format.sh | 17 +++++++++++++++++
3 files changed, 46 insertions(+), 6 deletions(-)
diff --git a/Documentation/git-check-ref-format.txt b/Documentation/git-check-ref-format.txt
index e9b3b40..0aeef24 100644
--- a/Documentation/git-check-ref-format.txt
+++ b/Documentation/git-check-ref-format.txt
@@ -9,6 +9,7 @@ SYNOPSIS
--------
[verse]
'git check-ref-format' <refname>
+'git check-ref-format' --print <refname>
'git check-ref-format' --branch <branchname-shorthand>
DESCRIPTION
@@ -63,19 +64,31 @@ reference name expressions (see linkgit:git-rev-parse[1]):
. at-open-brace `@{` is used as a notation to access a reflog entry.
+With the `--print` option, if 'refname' is acceptable, it prints the
+canonicalized name of a hypothetical reference with that name. That is,
+it prints 'refname' with any extra `/` characters removed.
+
With the `--branch` option, it expands the ``previous branch syntax''
`@{-n}`. For example, `@{-1}` is a way to refer the last branch you
were on. This option should be used by porcelains to accept this
syntax anywhere a branch name is expected, so they can act as if you
typed the branch name.
-EXAMPLE
--------
-
-git check-ref-format --branch @{-1}::
-
-Print the name of the previous branch.
+EXAMPLES
+--------
+* Print the name of the previous branch:
++
+------------
+$ git check-ref-format --branch @{-1}
+------------
+
+* Determine the reference name to use for a new branch:
++
+------------
+$ ref=$(git check-ref-format --print "refs/heads/$newbranch") ||
+die "we do not like '$newbranch' as a branch name."
+------------
GIT
---
diff --git a/builtin-check-ref-format.c b/builtin-check-ref-format.c
index f9381e0..b97b61a 100644
--- a/builtin-check-ref-format.c
+++ b/builtin-check-ref-format.c
@@ -17,6 +17,16 @@ int cmd_check_ref_format(int argc, const char **argv, const char *prefix)
printf("%s\n", sb.buf + 11);
exit(0);
}
+ if (argc == 3 && !strcmp(argv[1], "--print")) {
+ char *refname = xmalloc(strlen(argv[2]) + 1);
+
+ if (check_ref_format(argv[2]))
+ exit(1);
+ if (normalize_path_copy(refname, argv[2]))
+ die("Could not normalize ref name '%s'", argv[2]);
+ printf("%s\n", refname);
+ exit(0);
+ }
if (argc != 2)
usage("git check-ref-format refname");
return !!check_ref_format(argv[1]);
diff --git a/t/t1402-check-ref-format.sh b/t/t1402-check-ref-format.sh
index 382bc6e..eb45afb 100644
--- a/t/t1402-check-ref-format.sh
+++ b/t/t1402-check-ref-format.sh
@@ -41,4 +41,21 @@ test_expect_success "check-ref-format --branch @{-1}" '
refname2=$(git check-ref-format --branch @{-2}) &&
test "$refname2" = master'
+valid_ref_normalized() {
+ test_expect_success "ref name '$1' simplifies to '$2'" "
+ refname=\$(git check-ref-format --print '$1') &&
+ test \"\$refname\" = '$2'"
+}
+invalid_ref_normalized() {
+ test_expect_success "check-ref-format --print rejects '$1'" "
+ test_must_fail git check-ref-format --print '$1'"
+}
+
+valid_ref_normalized 'heads/foo' 'heads/foo'
+valid_ref_normalized 'refs///heads/foo' 'refs/heads/foo'
+invalid_ref_normalized 'foo'
+invalid_ref_normalized 'heads/foo/../bar'
+invalid_ref_normalized 'heads/./foo'
+invalid_ref_normalized 'heads\foo'
+
test_done
--
1.6.5.rc1.199.g596ec
^ permalink raw reply related
* [PATCH 1/4] Add tests for git check-ref-format
From: Jonathan Nieder @ 2009-10-12 5:27 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Jens Lehmann, git, Shawn O. Pearce
In-Reply-To: <20091012052536.GA11106@progeny.tock>
The "git check-ref-format" command is a basic command various
porcelains rely on. Test its functionality to make sure it does
not unintentionally change.
Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
---
t/t1402-check-ref-format.sh | 44 +++++++++++++++++++++++++++++++++++++++++++
1 files changed, 44 insertions(+), 0 deletions(-)
create mode 100644 t/t1402-check-ref-format.sh
diff --git a/t/t1402-check-ref-format.sh b/t/t1402-check-ref-format.sh
new file mode 100644
index 0000000..382bc6e
--- /dev/null
+++ b/t/t1402-check-ref-format.sh
@@ -0,0 +1,44 @@
+#!/bin/sh
+
+test_description='Test git check-ref-format'
+
+. ./test-lib.sh
+
+valid_ref() {
+ test_expect_success "ref name '$1' is valid" \
+ "git check-ref-format '$1'"
+}
+invalid_ref() {
+ test_expect_success "ref name '$1' is not valid" \
+ "test_must_fail git check-ref-format '$1'"
+}
+
+valid_ref 'heads/foo'
+invalid_ref 'foo'
+valid_ref 'foo/bar/baz'
+valid_ref 'refs///heads/foo'
+invalid_ref 'heads/foo/'
+invalid_ref './foo'
+invalid_ref '.refs/foo'
+invalid_ref 'heads/foo..bar'
+invalid_ref 'heads/foo?bar'
+valid_ref 'foo./bar'
+invalid_ref 'heads/foo.lock'
+valid_ref 'heads/foo@bar'
+invalid_ref 'heads/v@{ation'
+invalid_ref 'heads/foo\bar'
+
+test_expect_success "check-ref-format --branch @{-1}" '
+ T=$(git write-tree) &&
+ sha1=$(echo A | git commit-tree $T) &&
+ git update-ref refs/heads/master $sha1 &&
+ git update-ref refs/remotes/origin/master $sha1
+ git checkout master &&
+ git checkout origin/master &&
+ git checkout master &&
+ refname=$(git check-ref-format --branch @{-1}) &&
+ test "$refname" = "$sha1" &&
+ refname2=$(git check-ref-format --branch @{-2}) &&
+ test "$refname2" = master'
+
+test_done
--
1.6.5.rc1.199.g596ec
^ permalink raw reply related
* [PATCH 2/4] Documentation: describe check-ref-format --branch
From: Jonathan Nieder @ 2009-10-12 5:28 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Jens Lehmann, git, Shawn O. Pearce
In-Reply-To: <20091012052536.GA11106@progeny.tock>
Unless one already knew, it was not obvious what sort of shorthand
"git check-ref-format --branch" expands. Explain it.
The --branch argument is not optional.
Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
---
Documentation/git-check-ref-format.txt | 9 ++++++---
1 files changed, 6 insertions(+), 3 deletions(-)
diff --git a/Documentation/git-check-ref-format.txt b/Documentation/git-check-ref-format.txt
index 0b7982e..e9b3b40 100644
--- a/Documentation/git-check-ref-format.txt
+++ b/Documentation/git-check-ref-format.txt
@@ -9,7 +9,7 @@ SYNOPSIS
--------
[verse]
'git check-ref-format' <refname>
-'git check-ref-format' [--branch] <branchname-shorthand>
+'git check-ref-format' --branch <branchname-shorthand>
DESCRIPTION
-----------
@@ -63,8 +63,11 @@ reference name expressions (see linkgit:git-rev-parse[1]):
. at-open-brace `@{` is used as a notation to access a reflog entry.
-With the `--branch` option, it expands a branch name shorthand and
-prints the name of the branch the shorthand refers to.
+With the `--branch` option, it expands the ``previous branch syntax''
+`@{-n}`. For example, `@{-1}` is a way to refer the last branch you
+were on. This option should be used by porcelains to accept this
+syntax anywhere a branch name is expected, so they can act as if you
+typed the branch name.
EXAMPLE
-------
--
1.6.5.rc1.199.g596ec
^ permalink raw reply related
* [PATCH/RFC 0/4] plumbing to help fix git-gui
From: Jonathan Nieder @ 2009-10-12 5:25 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Jens Lehmann, git, Shawn O. Pearce
In-Reply-To: <7vws327wbp.fsf@alter.siamese.dyndns.org>
Junio C Hamano wrote:
> Jens Lehmann <Jens.Lehmann@web.de> writes:
>> I became aware of this issue while looking into problems occuring
>> when a user created a branch starting with a '/' in git gui (e.g.
>> "/foo"). Strange things happen, while git gui shows the current
>> branch as "/foo" under the hood a branch "foo" (without the slash)
>> had been created. But then you can't delete "/foo" from git gui,
>> because a branch of that name doesn't exist.
>
> Perhaps an interface to give a cleaned-up version, e.g.
>
> $ git check-ref-format --print refs/heads//foo/bar
> refs/heads/foo/bar
>
> is what you want in order to fix git-gui? I dunno.
The following packages do exactly that. I tried to use it to fix
git gui, but my Tcl-fu was not up to it, at least for tonight.
It is not obvious to me that this interface is the one that would be
most helpful for git gui: probably a command to just munge the branch
name would be more convenient, though less general.
Is the --print option useful? Right now, it seems that its main use is
documentation. But in the future, it would be very nice if this command
could be used to transform Unicode ref names to some appropriate
normalization form, to make Unicode ref names usable in Mac OS X and
less confusing everywhere.
I look forward to your thoughts.
Jonathan Nieder (4):
Add tests for git check-ref-format
Documentation: describe check-ref-format --branch in more detail
check-ref-format: add option to print canonical name
check-ref-format: Simplify --print implementation
Documentation/git-check-ref-format.txt | 32 ++++++++++++----
builtin-check-ref-format.c | 31 ++++++++++++++++
t/t1402-check-ref-format.sh | 61 ++++++++++++++++++++++++++++++++
3 files changed, 116 insertions(+), 8 deletions(-)
create mode 100644 t/t1402-check-ref-format.sh
^ permalink raw reply
* Re: What's cooking in git.git (Oct 2009, #02; Sun, 11)
From: Jeff King @ 2009-10-12 5:14 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vfx9pmhae.fsf@alter.siamese.dyndns.org>
On Sun, Oct 11, 2009 at 08:18:17PM -0700, Junio C Hamano wrote:
> * jk/1.7.0-status (2009-09-05) 5 commits.
> - docs: note that status configuration affects only long format
> (merged to 'next' on 2009-10-11 at 65c8513)
> + commit: support alternate status formats
> + status: add --porcelain output format
> + status: refactor format option parsing
> + status: refactor short-mode printing to its own function
> (this branch uses jc/1.7.0-status.)
>
> Gives the --short output format to post 1.7.0 "git commit --dry-run" that
> is similar to that of post 1.7.0 "git status".
>
> * jc/1.7.0-status (2009-09-05) 4 commits.
> (merged to 'next' on 2009-10-11 at 9558627)
> + status: typo fix in usage
> + git status: not "commit --dry-run" anymore
> + git stat -s: short status output
> + git stat: the beginning of "status that is not a dry-run of commit"
> (this branch is used by jk/1.7.0-status.)
>
> With this, "git status" is no longer "git commit --dry-run".
Hmm. I thought you wanted to re-order some of these for to put the
porcelain and short formats into v1.6.6, but leave the status switchover
for v1.7.0.
We can always revert selectively, but I though the post-v1.6.5 rewind
would be a good time to re-order.
-Peff
^ permalink raw reply
* Re: [PATCH] git-add--interactive: never skip files included in index
From: Jeff King @ 2009-10-12 5:11 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Pauli Virtanen, git
In-Reply-To: <7v63alpbwx.fsf@alter.siamese.dyndns.org>
On Sun, Oct 11, 2009 at 07:46:06PM -0700, Junio C Hamano wrote:
> Jeff King <peff@peff.net> writes:
>
> > So now I am doubly confused. Did this feature exist, and was broken, and
> > you actually fixed it in 63d285c, creating what looked like a regression
> > but was actually intentional?
>
> I do not think it was an intentional change. I _think_ the comment at the
> beginning of show_files() tells us quite a bit---we don't do read-dir when
> showing the indexed files, and I suspect that we used to rely on the fact
> that not doing the read-dir made exclusion mechanism a no-op. After the
> lazy .gitignore reading, I suspect that excluded() call started to
> initialize the exclude mechanism lazily, and that is how the bug was
> introduced, isn't it?
I did a bit more looking, and the situation is a bit more complex than
that. Hopefully the commit message below explains it.
-- >8 --
Subject: [PATCH] ls-files: excludes should not impact tracked files
In all parts of git, .gitignore and other exclude files
impact only how we treat untracked files; they should have
no effect on files listed in the index.
This behavior was originally implemented very early on in
9ff768e, but only for --exclude-from. Later, commit 63d285c
accidentally caused us to trigger the behavior for
--exclude-per-directory.
This patch totally ignores excludes for files found in the
index. This means we are reversing the original intent of
9ff768e, while at the same time fixing the accidental
behavior of 63d285c. This is a good thing, though, as the
way that 9ff768e behaved does not really make sense with the
way exclusions are used in modern git.
Signed-off-by: Jeff King <peff@peff.net>
---
One other option would be to retain the --exclude-from behavior but
eliminate the --exclude-per-directory behavior. I don't think this is
very easy, though, as it involves separating out which excludes came
from which file. And I think expecting excludes to impact the list of
index files is crazy, anyway, since no other part of git does so. But we
should recognize that we are changing existing behavior; I consider it a
bug fix, though.
I also still think that Pauli's patch makes sense; there is no point in
passing --exclude-standard there. It should be a no-op.
builtin-ls-files.c | 8 --------
t/t3003-ls-files-exclude.sh | 32 ++++++++++++++++++++++++++++++++
2 files changed, 32 insertions(+), 8 deletions(-)
create mode 100755 t/t3003-ls-files-exclude.sh
diff --git a/builtin-ls-files.c b/builtin-ls-files.c
index 2c95ca6..c5c0407 100644
--- a/builtin-ls-files.c
+++ b/builtin-ls-files.c
@@ -170,10 +170,6 @@ static void show_files(struct dir_struct *dir, const char *prefix)
if (show_cached | show_stage) {
for (i = 0; i < active_nr; i++) {
struct cache_entry *ce = active_cache[i];
- int dtype = ce_to_dtype(ce);
- if (excluded(dir, ce->name, &dtype) !=
- !!(dir->flags & DIR_SHOW_IGNORED))
- continue;
if (show_unmerged && !ce_stage(ce))
continue;
if (ce->ce_flags & CE_UPDATE)
@@ -186,10 +182,6 @@ static void show_files(struct dir_struct *dir, const char *prefix)
struct cache_entry *ce = active_cache[i];
struct stat st;
int err;
- int dtype = ce_to_dtype(ce);
- if (excluded(dir, ce->name, &dtype) !=
- !!(dir->flags & DIR_SHOW_IGNORED))
- continue;
if (ce->ce_flags & CE_UPDATE)
continue;
err = lstat(ce->name, &st);
diff --git a/t/t3003-ls-files-exclude.sh b/t/t3003-ls-files-exclude.sh
new file mode 100755
index 0000000..fc1e379
--- /dev/null
+++ b/t/t3003-ls-files-exclude.sh
@@ -0,0 +1,32 @@
+#!/bin/sh
+
+test_description='ls-files --exclude does not affect index files'
+. ./test-lib.sh
+
+test_expect_success 'create repo with file' '
+ echo content >file &&
+ git add file &&
+ git commit -m file &&
+ echo modification >file
+'
+
+check_output() {
+test_expect_success "ls-files output contains file ($1)" "
+ echo '$2' >expect &&
+ git ls-files --exclude-standard --$1 >output &&
+ test_cmp expect output
+"
+}
+
+check_all_output() {
+ check_output 'cached' 'file'
+ check_output 'modified' 'file'
+}
+
+check_all_output
+test_expect_success 'add file to gitignore' '
+ echo file >.gitignore
+'
+check_all_output
+
+test_done
--
1.6.5.rc3.240.g77692
^ permalink raw reply related
* Re: git log --graph
From: B Smith-Mannschott @ 2009-10-12 5:08 UTC (permalink / raw)
To: Dilip M; +Cc: git
In-Reply-To: <c94f8e120910111127q102aa6a1qc3c0850f8a8a1509@mail.gmail.com>
On Sun, Oct 11, 2009 at 20:27, Dilip M <dilipm79@gmail.com> wrote:
> I am using: git version 1.6.3.2
>
> Somehow not getting text graph as mentioned in
> http://www.gitready.com/intermediate/2009/01/26/text-based-graph.html
>
> Any hints would really help..
>
> I am trying git log --graph. (has commits in two branches...). But
> always see one line :(
"one line"?
1 of history? (i.e. the history of the current branch, but not the other)
2 of text?
3 --pretty=oneline?
assuming your problem is 1:
git log --all --graph
//ben
^ permalink raw reply
* Re: [PATCH 3/3] user-manual: use 'fast-forward'
From: Junio C Hamano @ 2009-10-12 5:05 UTC (permalink / raw)
To: Felipe Contreras; +Cc: git
In-Reply-To: <1255293973-17444-4-git-send-email-felipe.contreras@gmail.com>
Felipe Contreras <felipe.contreras@gmail.com> writes:
> It's a compound word.
Thanks.
This removes 7 out of 37 "fast forward" in Documentation/ directory. Are
we going to convert the remaining ones, too?
^ permalink raw reply
* Re: [PATCH 2/3] git config: clarify bool types
From: Junio C Hamano @ 2009-10-12 5:01 UTC (permalink / raw)
To: Felipe Contreras; +Cc: git
In-Reply-To: <1255293973-17444-3-git-send-email-felipe.contreras@gmail.com>
Felipe Contreras <felipe.contreras@gmail.com> writes:
> The value is what it is, the --bool and --bool-or-int options don't
> specify the value type, just how it is interpreted. For example: a value
> of '1' can be interpreted as 'true'.
It is not really about "interpreting", but about showing, isn't it?
With this in your .git/config file:
[core]
repositoryformatversion = 0
you would see
$ git config --bool-or-int core.repositoryformatversion
0
$ git config --bool core.repositoryformatversion
false
$ git config --int core.repositoryformatversion
0
So it would be more like...
show value as boolean
show value as integer or boolean
show value as integer
wouldn't it?
> Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com>
> ---
> builtin-config.c | 4 ++--
> 1 files changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/builtin-config.c b/builtin-config.c
> index a2d656e..29d7b75 100644
> --- a/builtin-config.c
> +++ b/builtin-config.c
> @@ -66,9 +66,9 @@ static struct option builtin_config_options[] = {
> OPT_STRING(0, "get-color", &get_color_slot, "slot", "find the color configured: [default]"),
> OPT_STRING(0, "get-colorbool", &get_colorbool_slot, "slot", "find the color setting: [stdout-is-tty]"),
> OPT_GROUP("Type"),
> - OPT_BIT(0, "bool", &types, "value is \"true\" or \"false\"", TYPE_BOOL),
> + OPT_BIT(0, "bool", &types, "value is intepreted as bool (\"true\" or \"false\")", TYPE_BOOL),
> OPT_BIT(0, "int", &types, "value is decimal number", TYPE_INT),
> - OPT_BIT(0, "bool-or-int", &types, "value is --bool or --int", TYPE_BOOL_OR_INT),
> + OPT_BIT(0, "bool-or-int", &types, "value is interpreted either as bool or int", TYPE_BOOL_OR_INT),
> OPT_GROUP("Other"),
> OPT_BOOLEAN('z', "null", &end_null, "terminate values with NUL byte"),
> OPT_END(),
> --
> 1.6.5.4.g31fc3
^ 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